Subject: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment]

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 Jul 2018 08:56:41 +0100

Buried in this thread there was...

>>   As opposed to publication as FOO 7974, that is.
> 
> [Med] I'm not sure about the possible implication on documents review, but I
> don't see much difference except reducing the page count as the notes
> mentioned above are likely to be deleted because this will be implied by the FOO
> label itself.

That's an interesting point.

Suppose a document contained the specification of a protocol that competed with an IETF consensus protocol. Suppose further that implementation of the specified protocol likely caused negative interactions with the IETF consensus protocol and so risked the stability of the Internet.

- Where the document is in the IETF stream, we know how to handle it.
- Where the document is in the IRTF or Independent Streams we have a
   time-tested mechanism and (I think) no evidence of harm through
   publication.
- If the IRTF and Independent Stream documents became FOO and BAR 
  documents, we would need to understand what control/input the IESG
  expected to have.
- If the publication is moved to another venue, the only thing the IESG
   can do is plead or bang shoes on tables.

There seems to be an correlation: the closer to looking like an IETF consensus document, the more IESG input.

Now, it might be thought (this is possibly a branding thing) that the further from looking like an IETF consensus document the less we have to care about the "protocol conflict problem", but I would argue that the less input the IESG has, the more we have to worry. Thus, were an alternative venue for publishing competing specifications to be developed, I would claim that this is harmful to the RFC band and to both the IETF's brand and raison d'être.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jul 2018 19:52:19 +1000

Firstly, to answer the question in the subject line.  There was no
mention of RFC 5742 (conflict review) in the proposed experiment.  I
mentioned it in my write-up, but it's probably worth repeating: there
was a perception of significant value in the process (non-binding as
it is), and fulfilling the IESG end was not a burden.  Thus, no
proposed change there.

> There seems to be an correlation: the closer to looking like an IETF consensus document, the more IESG input.

Are you suggesting that if this step is taken, then there will be less
incentive for the IESG to provide their input for things like IRTF and
Independent documents?  To the extent that we choose people who care
about what is good for the Internet, which is still the primary
desiderata by my reckoning, I don't see much risk of that happening.
On the contrary, where conflict arises, I've seen the IESG take care
to provide feedback well outside of our little circle, even if that is
a job that usually falls to the IAB.

> were an alternative venue for publishing competing specifications to be developed

I'd say a lot more has to change than a label before that becomes a
serious concern.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 Jul 2018 11:22:52 +0100

Thanks Martin,

> it is), and fulfilling the IESG end was not a burden.  Thus, no

Clarity is always welcomed.
We refer to 5742 reviews, and that is a helpful label that everyone understands. But just to note that 5742 describes how the IESG (currently) plans to handle "conflict reviews" as set out in 4846.

I'm glad to hear that you hear that 5742 reviews are not perceived (by the IESG) as being a burden on the IESG.

But I wasn't asking about the reviews (nor was the subject line) but about "IESG notes". So...

> a job that usually falls to the IAB.

Hmmm.
I am not suggesting anything. I'm asking.
I have no doubt that the IESG is empowered to review or delegate review of anything. And I assume that all Right-Thinking People (TM) will listen carefully to any input they get from that source.
I'm asking whether the IESG believes that if it asks (say) the IRTF to include an "IESG Note" on a document published as IRD9003 (instead of RFC9003) it is just as likely to be listened to as it is today.

And you (sort of answered)...

> I'd say a lot more has to change than a label before that becomes a

And this may (hopefully) be true.

It is worth considering, however, what it is that bonds the IRTF and IS to the IETF (beyond the obvious technology relationship). The "misconception" that the RFC series is an amorphous mass might be exactly the thing that makes the IRTF and IS keep close to the IETF.

To be pedantic about this, 4846 says it describes the editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher." Someone might argue that the rules and procedures in 4846 are important and adhered to precisely because the IS documents are published in the RFC series alongside the IETF documents. In other words, the very "confusion" you talk about in your draft necessitates the procedures, but take IS documents out of the RFC series and (regardless of the use of the same primary publisher) then nothing in 4846 applies. 

Now, for an abundance of clarity [(c) Terry Manderson], please understand that I am not expressing a view or promoting an opinion: I am asking what people think and why.

Thanks,
Adrian

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jul 2018 09:24:36 -0400

--On Wednesday, July 4, 2018 19:52 +1000 Martin Thomson
<[email-masked]> wrote:

> Firstly, to answer the question in the subject line.  There
> was no mention of RFC 5742 (conflict review) in the proposed
> experiment.  I mentioned it in my write-up, but it's probably
> worth repeating: there was a perception of significant value
> in the process (non-binding as it is), and fulfilling the IESG
> end was not a burden.  Thus, no proposed change there.

You mean "no intentional proposed change".  Considering my
comments some hours ago about impact factors and Eliot's (IMO
very insightful and relevant) analysis of labeling/experiments/
and ramifications.  Suppose that "IRTFnnnn" rather than
"RFCnnnn" causes impact scores and/or the near-term perception
of review quality and the like to drop and that causes some of
those whose participate in the IRTF (or support for that
participation) depends on those types of publication credits.
If the number of those people started to have significant
negative consequences for the amount of quality that could be
done and the IRTF were completely rational about it, it would be
appropriate for them to consider jumping ship, possibly taking
the series to a commercial academic publisher with a large and
effective marketing and public relations department.  That, in
turn, could have two side effects: (1) Unless new and careful
arrangements were made, the IESG, as an authority, would end up
with zero input, conflict review or otherwise. (2) Whether or
not that occurred, the perceived value of the RFC Series/ brand
would probably go down as the publisher would have significant
incentives to promote their IRTF journal as the premium product
in the Internet space with the left-behind parts of the RFC
Series representing lower quality from an academic, etc.,
standpoint.

The ISE situation is different, but not much different.

Am I confident that any of those things would happen?   No.
But I think the risks are clear enough that we should include
them in our considerations.

    john

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 6 Jul 2018 09:33:15 -0400

> On Jul 4, 2018, at 3:56 AM, Adrian Farrel <[email-masked]> wrote:
> 

I agree with this conclusion, modulo the ability for liaison statements and cross-participation in other venues to have an influence on what gets published in other venues. All of the above seems to be by design. 

> Now, it might be thought (this is possibly a branding thing) that the further from looking like an IETF consensus document the less we have to care about the "protocol conflict problem", but I woul…

I’m not following this. If someone cares about how the Internet works, then having a poorly designed specification that risks the Internet’s stability published in any venue is a problem. That doesn’t mean the IESG or any individual participant is necessarily going to be able to address that problem, but it’s still a problem. Having that specification labeled with “RFC” means the IESG and the IETF face the potential additional problem of having the specification confused for an IETF consensus output.

Alternative venues for publishing competing specifications already exist (e.g., https://url.spec.whatwg.org/ <https://url.spec.whatwg.org/>). They may or may not be harmful to the Internet, but I don’t see how they’re specifically harmful to the RFC brand. They’re certainly not more harmful to the RFC brand than competing specifications labeled “RFC."

Alissa

> 
> 
> 
> _______________________________________________
> Rfcplusplus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfcplusplus

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Jul 2018 10:12:18 +1200

> I’m not following this. If someone cares about how the Internet works, then having a poorly designed specification that risks the Internet’s stability published in any venue is a problem. That does…

Ultimately the IESG and the IETF don't matter, and in particular our pride doesn't matter in the least. What matters is whether the Internet works better or works worse as the result of a particular document being published. What a number of us here are saying is that document labels are largely irrelevant to that question. Implementers and operators do what *they* think is best for the Internet, and very often that doesn't include reading the labels or boilerplate on documents.
 
> Alternative venues for publishing competing specifications already exist (e.g., https://url.spec.whatwg.org/ <https://url.spec.whatwg.org/>). They may or may not be harmful to the Internet, but I d…

That depends on what you think the value of the "Request for Comments" brand is. I think it's the fact that it says right up front that the document is tentative, might be wrong, and needs to be read critically and commented upon. And for those in the know, that it comes from one section or another of the wider Internet technical community after open peer review.

If that isn't how the IETF wants its standards to be branded, that's fine, but it means starting a new series for IETF standards that doesn't bear the label "Request for Comments". Unfortunately we can't call them "IS" because that's already taken.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Jul 2018 15:51:32 -0700

On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter <
[email-masked]> wrote:

> That depends on what you think the value of the "Request for Comments"
> brand is. I think it's the fact that it says right up front that the
> document is tentative, might be wrong, and needs to be read critically and
> commented upon. And for those in the know, that it comes from one section
> or another of the wider Internet technical community after open peer review.
>

I want to focus on this point a bit, as I've heard it a few times. I
recognize that formally "RFC" stands for "Request for Comments", but my
suspicion is that at this point it's much more like "laser" or 'scuba",
i.e., it's an acronym but people don't bother to think of the expansion at
all but just chunk it as a name. As I said, it's just my opinion, but I'd
be interested in any evidence you have that the broader community thinks
otherwise.

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Jul 2018 19:08:13 -0400

Sent from my mobile device

> On Jul 6, 2018, at 6:51 PM, Eric Rescorla <[email-masked]> wrote:
> 
>> On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter <[email-masked]> wrote:
> I want to focus on this point a bit, as I've heard it a few times. I recognize that formally "RFC" stands for "Request for Comments", but my suspicion is that at this point it's much more like "laser" or 'scuba", i.e., it's an acronym but people don't bother to think of the expansion at all but just chunk it as a name. As I said, it's just my opinion, but I'd be interested in any evidence you have that the broader community thinks otherwise.

The errata process supports the idea of Request For Comments and it’s used quite a bit.  Bis drafts are evidence too as are experimental documents later becoming standards track, and proposed standard moving to standards track.

The clearest problem statement I’ve heard just points in the direction that we should be using STD more to further disambiguate document status.  I think that would be a positive step toward the stated goals, but would require effort or a change in process to make it easier for documents to begin in this state if there are enough interoperable implementations at time of publication.

Best,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Jul 2018 16:13:01 -0700

On Fri, Jul 6, 2018 at 4:08 PM, Kathleen Moriarty <
[email-masked]> wrote:

> The errata process supports the idea of Request For Comments and it’s used
> quite a bit.  Bis drafts are evidence too as are experimental documents
> later becoming standards track, and proposed standard moving to standards
> track.
>

Hmm... I'm not sure how persuaded I am by this. Other standards bodies have
errata processes (e.g., ITU corrigendum), bis documents (cf. V42.bis), and
multilevel standards (cf. W3C CR and PR), even though their standards
aren't named RFC. So I agree that people expect that standards are
imperfect and need revision, but this doesn't seem like evidence that
naming them RFC makes people think that they are any more provisional than
naming them Recommendation.

-Ekr

> The clearest problem statement I’ve heard just points in the direction
> that we should be using STD more to further disambiguate document status.
> I think that would be a positive step toward the stated goals, but would
> require effort or a change in process to make it easier for documents to
> begin in this state if there are enough interoperable implementations at
> time of publication.
>
> Best,
> Kathleen
>
>
> -Ekr
>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Jul 2018 19:34:31 -0400

> On Jul 6, 2018, at 7:13 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Fri, Jul 6, 2018 at 4:08 PM, Kathleen Moriarty <[email-masked]> wrote:
>> 
>> 
> Hmm... I'm not sure how persuaded I am by this. Other standards bodies have errata processes (e.g., ITU corrigendum), bis documents (cf. V42.bis), and multilevel standards (cf. W3C CR and PR), even though their standards aren't named RFC. So I agree that people expect that standards are imperfect and need revision, but this doesn't seem like evidence that naming them RFC makes people think that they are any more provisional than naming them Recommendation.

Having spent a few years attending ITU meetings and assisting with ISO 27000 for my organization, I disagree.  The IETF process is more open, contributions follow a much less formal process (we take email on a list as input from anyone, whereas in the ITU and other standards bodies, a member has to formally submit a contribution within a certain time period while the document is open for review).  For the IETF, this can happen at any point in the process.  While standards may be reopened in other bodies, the process is more formal.  RFCs means we are open to input from anyone (hopefully reasonable and helpful input) without restriction.

Best regards,
Kathleen

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 Jul 2018 16:54:36 -0400

Kathleen,

--On Friday, July 6, 2018 19:08 -0400 Kathleen Moriarty
<[email-masked]> wrote:

>...
> The clearest problem statement I've heard just points in the
> direction that we should be using STD more to further
> disambiguate document status.  I think that would be a
> positive step toward the stated goals, but would require
> effort or a change in process to make it easier for documents
> to begin in this state if there are enough interoperable
> implementations at time of publication.

Addressing just this one issue, it seems to me that you just
re-invented the original intent of the distinction between
Proposed and Draft Standard.   In principle, because the 2026
definition of Proposed Standard has never been changed, Proposed
Standards are supposed to be well-thought-out, with no known
technical defects, but, in general, with no requirement for
deployment or implementation experience at all.   Draft
Standard, by contrast, still does not require community
consensus that the document is a really good idea and that the
spec is solid, but does require more than one implementation and
some experience in use.

We eliminated Draft Standard some years ago with RFC 6410.   If
I recall, the assumption was that doing so would result in more
specifications moving to Full Standard because there has been
only one step.   However, I think one problem has been that the
typical bar for Proposed Standards has risen even further.  That
issue, as of the discussion leading up toe 6410, is discussed in
the long-expired draft-bradner-restore-proposed-00.  If that
document were taken as predictive, I think the prediction has
largely played out.

The proposals (e.g., draft-klensin-std-numbers-02 and the much
earlier draft-klensin-newtrk-std-repurposing-00 and
draft-ietf-newtrk-docid-00) to just give all standards-track
documents STD numbers so we can better talk about current
versions (and, if we are fussing with labels, better use that
one) assumed that, if the Internet was going to run on Proposed
Standards, it was time that we be less critical about the
numbers but not try to differentiate between better and worse
quality proposed standards -- solutions to a slightly different
set of problems.

In poking through old drafts to get the references above, I was
accidentally reminded that we've looked at the question of
separating IETF process documents from the BCPs that actually
talk about Internet operational procedures and the like
(draft-ietf-newtrk-sd-00).   We've been over a _lot_ of the
territory covered in these discussions before and, in Newtrk,
devised (and Brian and others have pointed out) a comprehensive
model rather than assuming that a few small patches here and
there (like new labels or even blowing non-IETF documents out of
the RFC Series) were going to accomplish enough to be worthwhile.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Jul 2018 04:01:31 -0400

--On Friday, July 6, 2018 09:33 -0400 Alissa Cooper
<[email-masked]> wrote:

>> Now, it might be thought (this is possibly a branding thing)
>> that the further from looking like an IETF consensus document
>> the less we have to care about the "protocol conflict
>> problem", but I would argue that the less input the IESG has,
>> the more we have to worry. Thus, were an alternative venue
>> for publishing competing specifications to be developed, I
>> would claim that this is harmful to the RFC band and to both
>> the IETF's brand and raison d'être. 
> 
> I'm not following this. If someone cares about how the
> Internet works, then having a poorly designed specification
> that risks the Internet's stability published in any venue
> is a problem. 

It seems to me that view makes a strong argument for having as
many specifications as possible in the RFC Series (or perhaps
some equivalent series controlled by the RFC Editor) so that we,
as a community can exercise at least some control over both
technical and editorial quality.   However --and here we may
have to agree to disagree-- I'd much rather see it published
with either an IESG note that says "this is a terrible idea
because..." or with a separate critique (ideally at the same
time and with a consecutive RFC number) that explains why it is
a bad idea than drive the author into some other publication
venue or even some competitive standards body where the risk to
the Internet's stability might be much higher and we are in no
position to comment.

> That doesn't mean the IESG or any individual
> participant is necessarily going to be able to address that
> problem, but it's still a problem. Having that specification
> labeled with "RFC" means the IESG and the IETF face the
> potential additional problem of having the specification
> confused for an IETF consensus output.

As I've said earlier in more detail, there are two kinds of
users of specifications, those who actually look at them and
those who don't.  For those who do, while there is lots of
generic evidence that people skim over boilerplate that appears,
superficially, on every document, there is no evidence that they
do not read and understand carefully-written and
specification-specific disclaimers and critiques.  In that
regard, the following are possibilities in ascending order of
usefulness and likely effectiveness.

 (i) This is not an IETF consensus specification
 (ii) This specification conflicts with IETF consensus
	specifications.
 (iii) This specification conflicts with IETF consensus
	specifications documented in XXX, YYY, and ZZZ.
 (iv) This specification conflicts with IETF consensus
	specifications documented in XXX, YYY, and ZZZ.  This
	approach is considered a less desirable approach than
	those because... and dangerous to the stability of the
	Internet because ...

IMO, if published documents continue to bear copyright notices
and rights statements connected to the IETF Trust and IETF, the
odds that simply changing labels (at least for those who read
the documents) will be any more effective that (i) --which we
are already doing-- is just about zero because, if the IETF
claims to be the publisher of the document, any risks of having
the IETF be blamed aren't going to be changed.  

For the people who don't read the specifications themselves,
I've argued elsewhere that they will be subject to deliberate
deception about the IETF status of the documents even if they
are only posted as I-Ds (or, perhaps, in I-D format with the
author contemplating posting them as I-Ds.  We have seen such
claims in the past, so that is not speculation.

> Alternative venues for publishing competing specifications
> already exist (e.g., https://url.spec.whatwg.org/
> <https://url.spec.whatwg.org/>). They may or may not be
> harmful to the Internet, but I don't see how they're
> specifically harmful to the RFC brand. They're certainly not
> more harmful to the RFC brand than competing specifications
> labeled "RFC."

No, they probably aren't.  But, using that example, they may be
far more harmful to the Internet, if only because WHATWG tends
to be narrowly focused on the web and to essentially be a
consortium of a small number of vendors.  That has some
advantages but (apparently) doesn't give them the perspective
needed to say "that might make a web browser work better, but
will reduce overall Internet performance or stability" or any of
the other things that we claim and hope can come out of
cross-area review.

As to the harm caused by competing specifications labeled "RFC",
it seems to me that "harm" is a much stronger claim than
"confusion about whether something is an IETF consensus
specification or not".   It would seem to imply that the
technical review processes used in at least the IRTF and
Independent Streams are intrinsically of lower quality than the
IETF one.  As far as I can tell (but I don't watch them at all
closely), the IRTF does a rather good job within its area of
scope.  And, while some things have been published that I don't
like or for which I would have suggested additional work, I
think Nevil and, so far, Adrian have done an outstanding job of
assembling and using editorial review processes and reviewers of
very high quality and to stand by a principle that, if reviewers
and reviews of sufficient quality cannot be found, the document
does not get published.

By contrast, recent years have shown us several examples of WGs
with small numbers of active participants, all or almost all
from the same cooperating cluster of companies and more than a
few AD-sponsored documents that have made it through the system
with substantially no substantive community input on IETF Last
Call and then get through the IESG with the minimum number of
"yes" votes and many "no objections", presumably deferring to
the AD who made the decision to sponsor the document.  

If we think the kind of renaming that is being proposed is
needed to differentiate between documents that are published
with IETF consensus and those that are not, I suggest that the
IESG should eliminate AD Sponsored documents entirely (or at
least push them off into another series) and establish criteria
for breadth and balance in WGs, dealing differently with those
that don't obviously manifest those properties.

best,
     john

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Jul 2018 14:04:24 +0100

[snip]

>> Now, it might be thought (this is possibly a branding thing) that the further from 
>> looking like an IETF consensus document the less we have to care about the 
>> "protocol conflict problem", but I would argue that the less input the IESG has,
>> the more we have to worry. Thus, were an alternative venue for publishing
>> competing specifications to be developed, I would claim that this is harmful
>> to the RFC brand and to both the IETF's brand and raison d'être. 
>
> I’m not following this. If someone cares about how the Internet works, then
> having a poorly designed specification that risks the Internet’s stability published
> in any venue is a problem. That doesn’t mean the IESG or any individual 
> participant is necessarily going to be able to address that problem, but it’s still a
> problem. Having that specification labeled with “RFC” means the IESG and the 
> IETF face the potential additional problem of having the specification confused
> for an IETF consensus output.

I'm trying to avoid looping the discussion or coming to any early conclusions on the right answer, but I will push again on this...

I believe I read you as saying that the IESG would not, as a matter of course, read or consider FOO9002 on its way to publication if that publication is out of the IETF Stream. They would not expect to be notified of the progress of that work towards publication.  In some cases, the IESG might become aware of the work and have comments that they wish to send to the publish body (such as, through a liaison statement). While the IESG might have some hope of being listened to, they would have no expectation of that, and would, in particular, not request the inclusion of an "IESG Note" in any such document.

That was the clarity I was hoping for.

My point about branding was manifold:
- The IETF would like to remain *the* source for documents that describe and define the Internet. Any action that weakens that (such as by giving another venue or publication) is unfortunate.
- The IESG would like to remain authoritative evaluators and commentators on the merit and consensus of Internet standards
- "RFC" as a label may cause confusion as to the source of the work, but buys the ability to influence the content by review and input.

> Alternative venues for publishing competing specifications already exist (e.g.,
> https://url.spec.whatwg.org/). They may or may not be harmful to the Internet,
> but I don’t see how they’re specifically harmful to the RFC brand. They’re certainly
> not more harmful to the RFC brand than competing specifications labeled “RFC."

It needs to be noted that the non-IETF stream sources of RFCs constitute "venues" for publication. The proposal on the table opens the gap between those venues and the IETF. That might or might not be a good thing, but it is important to understand the implications.

Adrian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Jul 2018 06:45:17 -0700

Responding on a narrow point.

> the AD who made the decision to sponsor the document.

I certainly wouldn't argue with the claim that many poor quality documents
get through the IETF with minimal review, etc. However, I would be wary of
drawing that conclusion based on the IETF ballots. Once a ballot is on the
agenda, it almost always has a Yes from the AD who put it there (whether it
is a WG document or AD-sponsored), and so the actual effect of "Yes" and
"No-objection" is the same [0]. For that reason, I almost always ballot
No-Objection, rather than try to distinguish between the cases where I
think it's good and I just don't care [1]. My sense is that balloting
procedures vary within the IESG, but I don't think I'm unique in this
respect. I suppose one could argue that I'm (we're)  Doing It Wrong and
that the ballot procedures ought to be clarified/improved, but in any case
it's not a signal that I'm just deferring to the AD.

> that don't obviously manifest those properties
>

I tend to agree with you that it would be good to sharply reduce
AD-sponsored documents, though I don't know if it's possible to eliminate
them entirely, because it's not uncommon to use them for small matters that
you wouldn't spin up a WG for. E.g,,
https://datatracker.ietf.org/doc/draft-housley-suite-b-to-historic/.

I also share your concern about the breadth and balance of WGs, but I'm
having trouble seeing what procedures we could actually put in place to
address that. Would of course be interested in hearing any suggestions you
might have on that front.

-Ekr

[0] Leaving aside the Alternate ballot procedure.
[1] cf. https://en.wikipedia.org/wiki/Approval_voting

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Jul 2018 10:04:42 -0400

> On Jul 9, 2018, at 9:45 AM, Eric Rescorla <[email-masked]> wrote:
> 
> I certainly wouldn't argue with the claim that many poor quality documents get through the IETF with minimal review, etc. However, I would be wary of drawing that conclusion based on the IETF ballots.. Once a ballot is on the agenda, it almost always has a Yes from the AD who put it there (whether it is a WG document or AD-sponsored), and so the actual effect of "Yes" and "No-objection" is the same [0].. For that reason, I almost always ballot No-Objection, rather than try to distinguish between the cases where I think it's good and I just don't care [1]. My sense is that balloting procedures vary within the IESG, but I don't think I'm unique in this respect. I suppose one could argue that I'm (we're)  Doing It Wrong and that the ballot procedures ought to be clarified/improved, but in any case it's not a signal that I'm just deferring to the AD. 

For non-sponsoring ADs, a YES means they believe in the work strongly enough that they would also be happy to sponsor it.  That’s come up as important as ADs roll off. I’ve used no objection in a similar way, but purposefully used YES on documents as well. For no objection, it means I trust the AD (person balloting didn’t have enough time), my parts are ok (no major security issues), or I read the document thoroughly and only have comment level suggestions and am fine publishing it anyway.  That maps well to the Alternate ballot procedure where no objection is the same as yes - it’s fine to publish this.

Best,
Kathleen 

> I tend to agree with you that it would be good to sharply reduce AD-sponsored documents, though I don't know if it's possible to eliminate them entirely, because it's not uncommon to use them for small matters that you wouldn't spin up a WG for. E.g,, https://datatracker.ietf.org/doc/draft-housley-suite-b-to-historic/.
> 
> I also share your concern about the breadth and balance of WGs, but I'm having trouble seeing what procedures we could actually put in place to address that. Would of course be interested in hearing any suggestions you might have on that front.
> 
> -Ekr
> 
> 
>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 10 Jul 2018 21:57:04 -0400

Hi Adrian,

> On Jul 9, 2018, at 9:04 AM, Adrian Farrel <[email-masked]> wrote:
> 
> [snip]
> 

Actually when I wrote the above I was thinking about it in the present tense. Documents get published in other venues today — other SDOs, web sites, journals, etc. Those specifications might risk the Internet’s stability. That is less than ideal, but the ability of the IESG and the IETF community to prevent it is limited. I think one difference between such a document and the exact same document being published with an RFC number is that the chance of the RFC being confused for an IETF consensus output is greater than the chance of the non-RFC being confused for an IETF consensus output. So I wasn’t commenting about a hypothetical change of series identifier, but rather the difference between documents in other venues (where “venue” means something outside the scope of the current RFC series) and RFCs in the current RFC series.

I do have an opinion on IESG notes and conflict reviews if the stream identifiers were to change but it’s not my opinion that matters here so I’ll keep it to myself. :)

Alissa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Jul 2018 17:01:44 -0500

File under "your mileage may vary" ...

On Mon, Jul 9, 2018 at 9:04 AM Kathleen Moriarty <
[email-masked]> wrote:

> drawing that conclusion based on the IETF ballots.. Once a ballot is on the
> "No-objection" is the same [0].. For that reason, I almost always ballot
> respect.. I suppose one could argue that I'm (we're)  Doing It Wrong and
> For non-sponsoring ADs, a YES means they believe in the work strongly
> enough that they would also be happy to sponsor it.  That’s come up as
> important as ADs roll off. I’ve used no objection in a similar way, but
> purposefully used YES on documents as well. For no objection, it means I
> trust the AD (person balloting didn’t have enough time), my parts are ok
> (no major security issues), or I read the document thoroughly and only have
> comment level suggestions and am fine publishing it anyway.  That maps well
> to the Alternate ballot procedure where no objection is the same as yes -
> it’s fine to publish this.
>

Keeping in mind that I served on the IESG with Kathleen for four years ...

I've balloted Yes on documents I wasn't responsible for,

   - when I thought the drafts were really the right thing to do, enough to
   have sponsored them if asked,
   - and usually, when I think I understand the document well enough to
   have been responsible for it (AD Evaluation, Last Call and Review Team
   comments, IESG Evaluation resolution ballots, and stuff like that).

Someone on the first IESG I served on suggested that mindset to me, and I
have no idea who that would have been now. Practice varies between ADs, at
least a bit.

Of course, literally the first RFC I was "responsible" for, was at Adrian
Farrel's request, because he had a doc that basically everyone even
marginally involved with the document was sponsored in some way by the same
company, and I wasn't, so I had to ballot Yes while marginally
understanding the draft, and under no delusion that I was a RTG AD or
likely to be one on this planet.

The details are at https://datatracker.ietf.org/doc/rfc7026/ballot/. It was
... short.

Spencer