Subject: Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 16:56:11 -0800

Hi,

Without any judgement, I wondered how this document relates to the IESG's
discuss criteria.[0]

In particular, this part: "Does this document represent an end run around
the IETF's working groups or its procedures?"

How does this document relate to this IESG procedure? Would publishing a
dissenting document on the independent stream constitute such an "end run"?

thanks,
Rob

[0] https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jan 2020 17:17:36 -0800

On Fri, Jan 24, 2020 at 4:56 PM Rob Sayre <[email-masked]> wrote:

> How does this document relate to this IESG procedure?
>

It would preclude the IESG from publishing non-consensus documents, which
seems like a chance in procedure.

Would publishing a dissenting document on the independent stream constitute
> such an "end run"?

I don't see how that relates to this document given that independent stream
documents are by definition not in the IETF stream and therefore are not
subject to IESG discusses. See https://tools.ietf.org/rfcmarkup?doc=5742
for more on this.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 17:44:20 -0800

> seems like a chance in procedure.

OK, I see. I support this change. They can always allow it on the other
streams, as detailed below.

> Would publishing a dissenting document on the independent stream
>> constitute such an "end run"?
>>
>
> I don't see how that relates to this document given that independent
> stream documents are by definition not in the IETF stream and therefore are
> not subject to IESG discusses. See
> https://tools.ietf.org/rfcmarkup?doc=5742 for more on this.
>

Maybe I'm confused about this, or shouldn't have used the term "discuss
criteria" (though [0] contained the term, as well as the section on
"Document Classes Reviewed by the IESG"). However, there are a bunch of
ways for the IESG to block publication of IRTF or Independent Stream
documents given in RFC 5742.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jan 2020 17:48:32 -0800

On Fri, Jan 24, 2020 at 5:44 PM Rob Sayre <[email-masked]> wrote:

>>> Without any judgement, I wondered how this document relates to the
>>> IESG's discuss criteria.[0]
>>>
>>> In particular, this part: "Does this document represent an end run
>>> around the IETF's working groups or its procedures?"
>>>
> "Document Classes Reviewed by the IESG").
>

All of these document classes apply only to the IETF stream.

However, there are a bunch of ways for the IESG to block publication of
> IRTF or Independent Stream documents given in RFC 5742.
>

This seems off topic for this document, which, as noted above, only refers
to the IETF stream.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 17:54:28 -0800

> All of these document classes apply only to the IETF stream.

Then where do "Document Actions (from RFC-Editor)" originate?

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jan 2020 20:55:57 -0500

This document makes no change to the interaction of the IESG with other 
streams.  It is strictly about the IETF stream.  As such, the rest of 
this is out of scope for the document.

As a matter of documented procedure, the IESG can request various things 
of the IRTF stream or the Independent Stream, but can not block 
publication.  (For example, they can request non-publication of 
Independent Stream documents, but the final decision rests with the 
ISE.)  This is either a feature or a bug, depending upon a lot of other 
views one has.

Yours,
Joel

On 1/24/2020 8:44 PM, Rob Sayre wrote:
> 
> 
> On Fri, Jan 24, 2020 at 5:18 PM Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Fri, Jan 24, 2020 at 4:56 PM Rob Sayre <sayrer@gmail..com
>     <mailto:[email-masked]>> wrote:
> 
>         Hi,
> 
>         Without any judgement, I wondered how this document relates to
>         the IESG's discuss criteria.[0]
> 
>         In particular, this part: "Does this document represent an end
>         run around the IETF's working groups or its procedures?"
> 
>     It would preclude the IESG from publishing non-consensus documents,
>     which seems like a chance in procedure.
> 
> 
>     stream documents are by definition not in the IETF stream and
>     therefore are not subject to IESG discusses. See

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2020 15:03:29 +1300

On 25-Jan-20 14:48, Eric Rescorla wrote:
...
>>     However, there are a bunch of ways for the IESG to block publication of IRTF or Independent Stream documents given in RFC 5742.
> 
> 
> This seems off topic for this document, which, as noted above, only refers to the IETF stream.

Also it's inaccurate. The IESG has no blocking power. The most the IESG can do is request the Independent Stream Editor not to publish a draft, or to request them to insert a specific IESG note, but the ISE has the final say. Similarly for IRTF drafts, where authority lies with the IRSG.

   Brian

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 18:06:38 -0800

> ISE.)  This is either a feature or a bug, depending upon a lot of other

Sure, I just think there's an angle here that's not being considered. I
agree with the goal of the document.

Maybe also give the IESG a SHOULD requirement to recommend one of the
RFC 5742 nastygrams detailed in section 3 of that
document, should publication be requested on another stream.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 18:08:09 -0800

On Fri, Jan 24, 2020 at 6:03 PM Brian E Carpenter <
[email-masked]> wrote:

> >>     However, there are a bunch of ways for the IESG to block
> publication of IRTF or Independent Stream documents given in RFC 5742.
> >
> >
> Also it's inaccurate. The IESG has no blocking power. The most the IESG
> can do is request the Independent Stream Editor not to publish a draft, or
> to request them to insert a specific IESG note, but the ISE has the final
> say. Similarly for IRTF drafts, where authority lies with the IRSG.
>

Has the IESG ever been crossed in this way? I've seen some RFCs with IESG
disapproval notes, but nothing more.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jan 2020 18:20:17 -0800

> Then where do "Document Actions (from RFC-Editor)" originate?

My mistake. The DISCUSS criteria only apply to Protocol actions.

"Protocol Actions are naturally subject to greater scrutiny than Document
Actions; Area Directors are not even required to state a position on a
Document Action (the default being "No Objection"). Accordingly, the exact
criteria used to evaluate Protocol Actions would benefit from greater
scrutiny. The remainder of this document focuses on the use of DISCUSS for
standards-track and BCP documents."

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jan 2020 18:20:53 -0800

> document, should publication be requested on another stream.

You should feel free to propose this via the GENDISPATCH process, but
that's not what this document is about. It has nothing to do with the ISE.

-Ekr

>> > [0]
>> https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/
>> >
>>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2020 15:28:29 +1300

On 25-Jan-20 15:08, Rob Sayre wrote:
> 
> 
> On Fri, Jan 24, 2020 at 6:03 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Has the IESG ever been crossed in this way? I've seen some RFCs with IESG disapproval notes, but nothing more.

You'd better ask that question on the [email-masked] list.

    Brian

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 18:35:33 -0800

> that's not what this document is about. It has nothing to do with the ISE.

A close reading of RFC 5742, something I suggest the authors undertake,
would show this not to be the case.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jan 2020 18:39:34 -0800

> would show this not to be the case.

Well, I've red 5742, and I don't see what you are getting it. I would
suggest you make your point explicitly.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 19:01:35 -0800

> suggest you make your point explicitly.

Well, it doesn't appear that you (as a document author) had read
https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/

since you used RFC 5742 as an objection, although it in fact details some
of the "iesg-discuss-criteria" procedures you said didn't exist. You've
also said RFC 5742 is irrelevant, and yet it also updates 2026 in
similar cases, so I suggest taking a closer look.

I think the name "RFC" is what matters to most submitters, and the stream
less so. I also don't think a club of 50-100 people who decide what's
allowed to be published (based on how they feel) is very healthy. That's
why I'd suggest actually considering policy around documents that fail to
achieve consensus. Where are these "Informational or Experimental RFCs to
be published without IETF rough consensus" going to go? Should the IESG
recommend them for the independent stream? Or would they be an "end-run"?

What are the specific recent cases this draft is seeking to address? It
might be helpful to look at recent drafts that would not qualify under this
proposed BCP.

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jan 2020 22:31:29 -0500

Rob, this document deliberately addresses a very narrow issue that while 
admittedly rare has come up a few times.

If you want to write a document to change the interaction between the 
IESG and the ISE (and thus the IESG and the Independent Stream) I can't 
stop you.  But I will not use this document to take sides on what should 
or should not change in that space.  And what was approved by the 
Gendispatch group, and sponsored by the general AD, is this narrow scope.

Yours,
Joel

On 1/24/2020 10:01 PM, Rob Sayre wrote:
> On Fri, Jan 24, 2020 at 6:40 PM Eric Rescorla <[email-masked] 
>     Well, I've red 5742, and I don't see what you are getting it. I
>     would suggest you make your point explicitly.
> 
> 
> since you used RFC 5742 as an objection, although it in fact details 
> some of the "iesg-discuss-criteria" procedures you said didn't exist. 
> You've also said RFC 5742 is irrelevant, and yet it also updates 2026 in 
> I think the name "RFC" is what matters to most submitters, and the 
> stream less so. I also don't think a club of 50-100 people who decide 
> what's allowed to be published (based on how they feel) is very healthy. 
> That's why I'd suggest actually considering policy around documents that 
> fail to achieve consensus. Where are these "Informational or 
> Experimental RFCs to be published without IETF rough consensus" going to 
> go? Should the IESG recommend them for the independent stream? Or would 
> they be an "end-run"?
> 
> might be helpful to look at recent drafts that would not qualify under 
> this proposed BCP.
> 
> thanks,
> Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 20:25:32 -0800

> admittedly rare has come up a few times.

It would help if you could describe the documents your draft applies to:

Document Classes Reviewed by the IESG
1) Protocol Actions
2) Document Actions (WG)
3) Document Actions (Individual)
4) Document Actions (from RFC-Editor)

I'm assuming the draft does not apply to #1, since those would not be
Informational or Experimental. If the draft is not intended to apply to #4
(even as an "end run"), that would be helpful to state.

That leaves #2 or #3. If the draft is concerned about #3, I think it
should state what the IESG is to do if the draft reappears as individual
submission.

If the document is about #2, that would be good to state as well.

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jan 2020 00:48:33 -0500

You seem to be looking for some categorization other than what the 
document says.  I am unclear why.

The document states clearly that it applies to all Informational and 
Experimental documents on the IETF stream.  (I suppose I might have 
written one for standards track, but it is not needed as the rules for 
that are already clear.)

Yours,
Joel

On 1/24/2020 11:25 PM, Rob Sayre wrote:
> On Fri, Jan 24, 2020 at 7:31 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Informational or Experimental. If the draft is not intended to apply to 
> #4 (even as an "end run"), that would be helpful to state.
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 22:12:00 -0800

> document says.  I am unclear why.

I asked for some example documents. Could you provide some?

> Experimental documents on the IETF stream.

Yes, but not what happens next. Which leaves it incomplete.

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jan 2020 01:23:06 -0500

I have no idea what you are asking for.
The existing rules permit certain behavior which, if the community 
approves this document, will now be prohibited.  that is all it does. 
There are very few if any examples of documents that were permitted but 
would now be prohibited.

At this point, I will leave it to the document shepherd and AD to tell 
me if there is something more needed.

Yours,
Joel

On 1/25/2020 1:12 AM, Rob Sayre wrote:
> On Fri, Jan 24, 2020 at 9:48 PM Joel M. Halpern <[email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 22:28:41 -0800

> I have no idea what you are asking for.

Really?

> There are very few if any examples of documents that were permitted but

I just wrote "I asked for some example documents. Could you provide some?"

Are there "very few" examples, or none?

If the answer is none, what problem does the document solve?

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jan 2020 01:42:27 -0500

The problem is that the current rules permit the IESG to publish 
Informational or Experimental documents without IETF consensus on the 
IETF stream.  This recently came up because someone thought it might 
actually be a good idea to do so to solve a problem.  I do know of one 
case where it was actually done.  The only way you can tell is that 
there is a line missing in the boilerplate of the RFC.  But I see no 
value in pointing to that example.

The case that brought this to my attention, and prompted the document, 
does not exist because the AD in question agreed after discussion that 
using the possible loophole would have been a bad idea.

The other example I know of (the published RFC) is complicated because 
there was a lot of politics.  So trying to analyze what would or should 
have happened if this rule were in place is just a game of what-if.  Not 
useful.

Rather, by publishing this document the community is saying that no, 
this is not an IESG choice.  The rules are fixed to prohibit it.

 From your notes, you seem to be trying to figure out if changing the 
rule would create a problem.  Given the existence of the other channels 
for publishing RFCs, which are NOT affected by this change, I do not see 
how it could be a major problem.   Whereas leaving the loophole in place 
struck me, and others, as a bad risk.  The loophole is an effect of the 
evolution of our processes over MANY years since RFC 2026.

Yours,
Joel

On 1/25/2020 1:28 AM, Rob Sayre wrote:
> On Fri, Jan 24, 2020 at 10:23 PM Joel M. Halpern <[email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 23:55:23 -0800

On Fri, Jan 24, 2020 at 10:42 PM Joel M. Halpern <[email-masked]>
wrote:

> This recently came up because someone thought it might
> case where it was actually done.
>
...

...

> there was a lot of politics.
>

More transparency would be controversial in the short term, but ultimately
lead to a stronger organization.

> how it could be a major problem.
>

I happen to think the other channels are needlessly restricted. But I think
that's because it's the "RFC" designation that matters, and the quality of
the IETF stream doesn't sell itself.

thanks,
Rob

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2020 10:27:56 -0500

Joel and EKR:
> 
>  this document deliberately addresses a very narrow issue that while admittedly rare has come up a few times.

In 2007, the IESG published this statement: https://ietf.org/about/groups/iesg/statements/area-director-sponsoring-documents/ <https://ietf.org/about/groups/iesg/statements/area-director-sponsoring-documents/>

In this statement, the IESG says that it will not approve any document without an IETF Last Call.  See the first paragraph of Section 4.

I suggest a better way forward would be to post an updated IESG statement that requires consensus as well.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 25 Jan 2020 15:31:14 +0000

*   I suggest a better way forward would be to post an updated IESG statement that requires consensus as well.

And what prevents a future IESG from changing its mind next year?

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2020 10:35:17 -0500

> On Jan 25, 2020, at 10:31 AM, Salz, Rich <[email-masked]> wrote:
> 

Nothing.  That said, the procedures in this statement have been followed since 2007, and the proposed change is really building on things that are in this statement, like the requirement for the IETF Last Call, which is not in RFC 2026.

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jan 2020 10:41:29 -0500

Why do you think a new IESG statement is better than an RFC.  The only 
difference I can see is that it leaves the IESG an out.  Which seems to 
me to be the wrong answer.  This issue ought not, it seems to me, be one 
of IESG judgment.

Yours,
Joel

On 1/25/2020 10:27 AM, Russ Housley wrote:
> In 2007, the IESG published this statement: 
> https://ietf.org/about/groups/iesg/statements/area-director-sponsoring-documents/
> 
> In this statement, the IESG says that it will not approve any document 
> without an IETF Last Call.  See the first paragraph of Section 4.
> 
> I suggest a better way forward would be to post an updated IESG 
> statement that requires consensus as well.
> 
> Russ
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 25 Jan 2020 08:59:45 -0800

On 25 Jan 2020, at 7:41, Joel M. Halpern wrote:

> difference I can see is that it leaves the IESG an out.  Which seems 
> to me to be the wrong answer.  This issue ought not, it seems to me, 
> be one of IESG judgment.

If you distrust the IESG so deeply about their process, you should 
probably distrust them on calling a rough consensus.

I do think that having an RFC is a good thing, but for a different 
reason: until Russ posted his message, none of us would have thought to 
look in the IESG statements archive to see if anything applied. We look 
to RFCs.

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2020 12:26:44 -0500

Joel:

It seems to me that you would need to pot other things that are in this IESG statement into the BCP that updates RFC 2026.  You are really building on top of the procedure that are required by the existing IESG statement.  For example, RFC 2026 does not require an IETF Last Call for an informational or experimental document at all.

Russ

> On Jan 25, 2020, at 10:41 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Why do you think a new IESG statement is better than an RFC.  The only difference I can see is that it leaves the IESG an out.  Which seems to me to be the wrong answer.  This issue ought not, it seems to me, be one of IESG judgment.
> 
> Yours,
> Joel
> 
>> In 2007, the IESG published this statement: https://ietf.org/about/groups/iesg/statements/area-director-sponsoring-documents/
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sat, 25 Jan 2020 12:32:28 -0500

> On Jan 25, 2020, at 12:26 PM, Russ Housley <[email-masked]> wrote:
> 
> Joel:
> 

that was the non-requirement at the time

working groups wanted to be able to publish informational (at least) documents, for example, background information, whenever
they wanted to without the effort entailed in a IETF last-call

i.e., the omission was on purpose (at the time)

Scott

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Jan 2020 17:59:30 -0000

Hi Russ,

I believe you are misreading what the IESG statement says.

The first paragraph of Section 4 refers to “AD Sponsored documents to Standards Track” and to “AD Sponsored documents to Experimental/Informational”. It does not mention documents coming out of a working group.

It was a fine IESG statement (if a bit lengthy 😊) but seems designed to cover AD sponsored documents only.

For almost as long as I can recall, the IESG has applied a policy of always holding an IETF last call on every document. That seems to be an IESG prerogative, but I don’t see it written down anywhere.

It is, of course, possible for the IESG to issue a further statement on this. I believe Joel’s point may be that what the IESG giveth, the IESG may take away: but if the community likes the idea of a last call on all documents then putting it into the process of record would be the right thing.

I think Joel makes one other point which may be splitting hairs, or might be paranoid, but does no harm to fix. Holding an IETF last call, is not the same as not publishing a document until there is rough consensus.

Cheers,

Adrian

From: last-call <[email-masked]> On Behalf Of Russ Housley
Sent: 25 January 2020 15:28
To: [email-masked]
Cc: Eric Rescorla <[email-masked]>; Joel Halpern <[email-masked]>
Subject: Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice

Joel and EKR:

Russ

---

From: Joel Halpern Direct <[email-masked]>
Date: Sat, 25 Jan 2020 13:13:23 -0500

Russ, I do not see why this needs to incorporate the rest of the IESG 
statement.  For example, this says that it shall be IETF rough 
consensus.  The question of how the IESG determines rough consensus is 
not something this document asks to change or document more strictly.

I am not trying to remove IESG statements.  In this case there seems to 
be a clear community view on what is appropriate.  Updating our 
documentation (process RFCs) to reflect that rough consensus seems 
entirely appropriate.

Yours,
Joel

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2020 13:26:19 -0500

Joel:

It just seemed like an easier way to get the IESG commitment that you are seeking.

Russ

> On Jan 25, 2020, at 1:13 PM, Joel Halpern Direct <[email-masked]> wrote:
> 
> Russ, I do not see why this needs to incorporate the rest of the IESG statement.  For example, this says that it shall be IETF rough consensus.  The question of how the IESG determines rough consensus is not something this document asks to change or document more strictly.
> 
> I am not trying to remove IESG statements.  In this case there seems to be a clear community view on what is appropriate.  Updating our documentation (process RFCs) to reflect that rough consensus seems entirely appropriate.
> 
> Yours,
> Joel
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2020 13:29:40 -0500

Adrian:

The meet of the document is:

   The IETF MUST NOT publish RFCs on the IETF stream without
   establishing IETF rough consensus for publication.

This seems to apply to AD sponsored and WG sponsored documents.  My thought was that an IESG statement would get the same result with less effort.

Russ

> On Jan 25, 2020, at 12:59 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Russ,
>  
> From: last-call <[email-masked] <mailto:[email-masked]>> On Behalf Of Russ Housley
> To: [email-masked] <mailto:[email-masked]>
> Cc: Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Joel Halpern <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Jan 2020 10:45:50 -0800

Apologies for the pedanticism, but there are some frequently confused
items in here (and the terminology of
https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ has
since evolved).

> 3) Document Actions (Individual)

This is "Individual submission to an AD" (i.e., IETF-stream AD-sponsored),
as distinct from "Independent submission to the ISE" (i.e., ISE-stream).

> 4) Document Actions (from RFC-Editor)

The current terminology used for these (e.g., at
https://datatracker.ietf.org/iesg/agenda/) is to talk of a "(RFC 5742)
conflict-review response" for the "IRTF and Independent Submission stream
documents" (i.e., item 3.4 on the linked IESG agenda).  The "Document
Actions (From RFC-Editor)" terminology used in the IESG statement on
discuss-criteria seems confusing at least to me, so I'm not sad to see it
go.

> should state what the IESG is to do if the draft reappears as individual

I assume you mean Independent Submission here (i.e., via ISE).

> If the document is about #2, that would be good to state as well.

In light of the above, it seems clear that this draft is proposing changes
to (2) and (3).

-Ben

---

From: Rob Sayre <[email-masked]>
Date: Sat, 25 Jan 2020 11:44:10 -0800

> https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ has

Perhaps we need an ITAB (IESG Terminology Architecture Board). :)

> I assume you mean Independent Submission here (i.e., via ISE).

Yes.

> In light of the above, it seems clear that this draft is proposing changes

OK. The questions in my original message are still unanswered. Currently,
dissenting or non-consensus Informational or Experimental documents can be
published through any of the channels, with the rationale that they don't
require consensus anyway. While I understand (and have understood this
entire time...) that this document only intends to change the IETF stream
process, my question is whether it would also add to the set of documents
that are considered an "end run".

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jan 2020 08:59:38 +1300

Russ,

> It seems to me that you would need to pot other things that are in this IESG statement into the BCP that updates RFC 2026.  You are really building on top of the procedure that are required by the…

More pedantically, BCP 9 does not require an IETF Last Call for an informational or experimental document at all. When this draft is approved, BCP 9 will do so, because that's how we determine IETF rough consensus. That is rock solid, whereas an IESG statement can always be reversed.

I agree that we will still depend on the IESG's assessment of IETF rough consensus, but there is no way round that.

(BCP 9 is irrelevant for non-IETF documents, since it defines IETF process.)

     Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jan 2020 15:10:13 -0500

Rob, I can see no reason why this document would change what is or is 
not considered an end-run.

Yours,
Joel

On 1/25/2020 2:44 PM, Rob Sayre wrote:
> 
> 
> On Sat, Jan 25, 2020 at 10:45 AM Benjamin Kaduk <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> OK. The questions in my original message are still unanswered. 
> Currently, dissenting or non-consensus Informational or Experimental 
> documents can be published through any of the channels, with the 
> rationale that they don't require consensus anyway. While I understand 
> (and have understood this entire time...) that this document only 
> intends to change the IETF stream process, my question is whether it 
> would also add to the set of documents that are considered an "end run".
> 
> thanks,
> Rob
>

---

From: Rob Sayre <[email-masked]>
Date: Sat, 25 Jan 2020 12:24:35 -0800

> not considered an end-run.

OK. I think the document should cite RFC 5742 in its description of the
other streams. Given your statement, I propose this edit:

   One could argue that there is a need for publishing some documents
   that the community can not agree on.  However, we have an explicit
   procedure for such publication, namely the Independent Stream.  Or,
   for research documents, the IRTF stream, which explicitly publishes
   many minority opinion Informational RFCs. RFC 5742 describes the
   IESG procedures for the handling of those streams, and this document
   introduces no new requirements to those procedures.

Editorial nits:

- The capitalization of "Stream" is inconsistent.
- typo: "the IAB SHOULD use its authorithy"

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jan 2020 15:30:18 -0500

With regard to citing RFC 5742, I will leave it to the judgment of the 
document shepherd and AD as to whether they believe that is called for. 
It seems more distracting than useful to me, but I will act as they direct.

With regard to the Stream typo, that is noted, and will be corrected.

With regard to the "authority" typo, I will correct it, although that 
paragraph will be removed before this becomes an RFC.

Yours,
Joel

On 1/25/2020 3:24 PM, Rob Sayre wrote:
> On Sat, Jan 25, 2020 at 12:10 PM Joel M. Halpern <[email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Sat, 25 Jan 2020 13:10:22 -0800

> It seems more distracting than useful to me, but I will act as they direct.

Whether or not my proposal is accepted, the document does need a reference
to define those streams.

RFC 4844 or RFC 5742 would do. Minimally, the authors could simply add
[RFC4844] to the existing text.

My proposal is clearer, though.

thanks,
Rob

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 26 Jan 2020 12:09:36 -0800

> It seems more distracting than useful to me, but I will act as they direct.

For the reason above, I do not think citing RFC 5742 is necessary.

> paragraph will be removed before this becomes an RFC.

Thanks, Joel!

Best,
Chris

---

From: Rob Sayre <[email-masked]>
Date: Sun, 26 Jan 2020 15:03:53 -0800

> For the reason above, I do not think citing RFC 5742 is necessary.

There are 4 cases that could happen now:

Document Actions (WG) [ No IETF Last Call Issued ]
Document Actions (WG) [ Last Call Issued, No Consensus ]
Document Actions (Individual to AD) [ No IETF Last Call Issued ]
Document Actions (Individual to AD) [ Last Call Issued, No Consensus ]

For each of these cases, there will be some interaction with RFC 5742 if
the document is to be published on another stream (the alternative proposed
in the draft).

Whether or not this draft is edited, it would be helpful to know what
people think is going to happen to these cases. No publication at all? Or
publication with one of the IESG messages in 5742? I looked for some
Informational and Experimental documents languishing in the IESG queue,
since the authors don't seem comfortable discussing the concrete examples
they are reacting to.

https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/  (676 days ago)
https://datatracker.ietf.org/doc/draft-gutmann-scep/ (153 days ago)
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/  (318 days
ago)
https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/   (269
days ago)

IESG reviews that result in case #4 or #5 from RFC 5742 would likely lead
to no publication at all. As others have pointed out, the RFC Editor could
theoretically ignore this, but that doesn't seem likely in today's
environment.

It's not clear if this proposal intends to leave some documents unpublished
(maybe that is ok, but it should be clear).

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Jan 2020 18:11:39 -0500

In my view, the question of how one could / may / should / might publish 
a document that does not achieve IETF rough consensus is not the task of 
this document.  The text simply observes that there are means outside of 
the IETF stream to publish (some of) such documents as RFCs.

This is an IETF process RFC, not a publication tutorial.

Yours,
Joel

On 1/26/2020 6:03 PM, Rob Sayre wrote:
> On Sun, Jan 26, 2020 at 12:10 PM Christopher Wood <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > document shepherd and AD as to whether they believe that is
>     called for..
> the document is to be published on another stream (the alternative 
> proposed in the draft).
> 
> people think is going to happen to these cases. No publication at all? 
> Or publication with one of the IESG messages in 5742? I looked for some 
> since the authors don't seem comfortable discussing the concrete 
> examples they are reacting to.
> 
> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/  (318 
> days ago)
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/   (269 days 
> ago)
> 
> IESG reviews that result in case #4 or #5 from RFC 5742 would likely 
> lead to no publication at all. As others have pointed out, the RFC 
> Editor could theoretically ignore this, but that doesn't seem likely in 
> today's environment.
> 
> It's not clear if this proposal intends to leave some documents 
> unpublished (maybe that is ok, but it should be clear).
> 
> thanks,
> Rob
> 
> 
> 
>

---

From: Rob Sayre <[email-masked]>
Date: Sun, 26 Jan 2020 15:37:06 -0800

Hi,

I didn't ask for any edits to your document in that message. I was just
wondering what might happen to these documents, in the absence of a
concrete example (which you refuse to provide).

For example, this draft could prevent publication of security technologies
that disintermediate some vocal subset of IETF participants (like, say,
router manufacturers). As I reflect on this draft, I am not sure it is a
good idea. I could see it curbing process abuses, but I can also see it
entrenching insecure protocols that people make money from exploiting.
That's why I want to learn about some concrete examples.

thanks,
Rob

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 27 Jan 2020 09:02:55 -0500

> On Jan 26, 2020, at 3:09 PM, Christopher Wood <[email-masked]> wrote:
> 

I agree.
Alissa

---

From: S Moonesamy <[email-masked]>
Date: Tue, 28 Jan 2020 12:32:25 -0800

Hi Rob,
At 03:03 PM 26-01-2020, Rob Sayre wrote:
>For each of these cases, there will be some interaction with RFC 
>5742 if the document is to be published on another stream (the 
>alternative proposed in the draft).
>
>Whether or not this draft is edited, it would be helpful to know 
>what people think is going to happen to these cases. No publication 
>at all? Or publication with one of the IESG messages in 5742? I 
>looked for some Informational and Experimental documents languishing 
>in the IESG queue, since the authors don't seem comfortable 
>discussing the concrete examples they are reacting to.

The documents are likely stuck there as the relevant working group is 
either unable to address the issues or not interested in putting 
effort in the work.  It is not easy to have a clear view of potential 
problems when a matter is not discussed in concrete terms.  It is up 
to authors to determine how this proposal may affect their documents in future.

Regards,
S. Moonesamy

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Jan 2020 20:25:37 -0800

> since the authors don't seem comfortable discussing the concrete examples

I don't think there's a universal answer here, and what happens would be
evaluated on a case-by-case basis.  I could imagine some documents that are
controversial in the IETF and fail to gather consensus but describe
protocols that do not harm the Internet and do not try to modify or usurp
IETF protcols; the ISE is a fine venue for such documents.  On the other
hand, if the failure to attain IETF consensus was due to attempting to
change the normative behavior of an existing IETF specification, then an
attempt to publish via the ISE would receive a conflict-review response
that notes the conflict with IETF work and indicates the harm of publishing
the document anyway.  That said, as is well-covered in this thread, the
IESG conflict-review response is just a recommendation as far as the ISE is
concerned, and the ISE will act wholly independently in deciding whether or
not to publish.

-Ben