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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Jan 2020 21:51:30 -0000

Hi,

Thanks for this document. I think it is a fine idea to make this small
change official even if (or perhaps particularly because) it describes what
the IESG has been doing for some time.

However, I think the document needs some work before it can be published.

1. The document is framed as a proposal. That was great for opening the
discussion, but when published as an RFC it needs to be phrased as a clear
statement of practice. Thus, you need to reword it accordingly. That's a
fairly easy change, but hits several places in the document.

2. The Introduction usefully sets out what 2026 requires. However, you also
need to say what this document does. I think it is conventional to make the
"updates" statement in the Introduction and to state what the update is:
such as, "This document updates [RCF2026] by stating rules for establishing
IETF consensus before the publication of any RFC on the IETF Stream."
There are also a couple of nits in the text you have:
a. "it should be remembered that this RFC predates" Since the draft will
(hopefully) be published as an RFC, the term "this RFC" will be
misinterpreted as meaning "this document". I think you can fix that as
"...remembered that that RFC..."
b. "As a consequence, it is currently permitted for the IETF to approve".
Once this document is published as an RFC your statement will be wrong and
confusing. Furthermore, I think you mean IESG not IETF. Maybe you fix this
as "As a consequence, RFC 2026 permitted the IESG to approve"

3. Section 4 is a bit of discussion that no-doubt helped form this document.
But I wonder whether you want this discussion to remain. You have already
decided that the final paragraph should be removed. Could you actually
remove the whole section without loss to the document?
If you decide to keep Section 4, it will need some work.
The first sentence of the first paragraph will not age well with the
publication of this document as an RFC. Maybe it could be rewritten as:
   The procedures defined in [RFC2026] permit the publication of
   some RFCs in the IETF stream without first establishing IETF
   consensus.
Additionally, while you are correct as to the letter of the 2007 IESG
statement, I hope you'll agree that the intent of that statement in having
IETF-wide review was that consensus would be reached. Finally, the
referenced IESG statement does not say that "no document will be issued
without first conducting an IETF Last Call", it talks only about "Individual
Submissions". The fact that the IESG now issues last calls on all IETF
Stream documents is an established behaviour, but is not (I think)
documented - IIRC, an IESG just decided to do it. That could all mean some
substantial clean-up and leads me to think that it is easier to drop the
rest of the text in the paragraph. 

4. You should decide whether to use "stream" or "Stream" and be consistent.

Thanks for the work,
Adrian

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of The IESG
Sent: 24 January 2020 18:09
To: IETF-Announce <[email-masked]>
Cc: [email-masked]
Subject: Last Call:
<draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream
Documents Require IETF Rough Consensus) to Best Current Practice

The IESG has received a request from an individual submitter to consider the
following document: - 'IETF Stream Documents Require IETF Rough Consensus'
  <draft-halpern-gendispatch-consensusinformational-02.txt> as Best Current
  Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-02-21. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

Abstract

   This document proposes that the IETF never publish any IETF stream
   RFCs without IETF rough consensus.  This updates RFC 2026.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformat
ional/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformat
ional/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2020 10:11:51 +1300

Friendly amendment:

> This document introduces no new security considerations. It is a process document about changes to the rules for certain corner cases in publishing IETF stream RFCs.

It seems to me that this document will potentially improve security. You could add:

However, it will prevent publication of IETF stream documents that have not reached rough consensus about their security aspects.

Nit:

Please be consistent about "stream" vs "Stream". For example,

>  ...namely the Independent Stream. Or, for research documents, the IRTF stream

is inconsistent.

Regards
   Brian Carpenter

On 25-Jan-20 07:08, The IESG wrote:
> be sent to [email-masked] instead. In either case, please retain the beginning
> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformational/
> 
> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformational/ballot/
> 
>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Jan 2020 14:20:36 -0800

Hello,
>[email-masked] mailing lists by 2020-02-21. Exceptionally, comments may

The usage of uppercase in Section 3 makes it look like the IETF only 
understands an absolute prohibition when it is written in 
uppercase.   Is that really necessary?

The current boilerplace (RFC 7841) states has the following text: "It 
represents the consensus of the IETF community".  Is there a reason 
why that that RFC if is not being update to match what Section 3 defines?

Which section of RFC 2026 will be updated?

An IETF participant is allowed to disagree with the IESG if he/she 
believes that the IESG is taking a bad decision by approving the 
publication of a document.  There hasn't been any such case in recent 
IETF history.  I don't understand the rationale for having such a 
significant change to address certain corner cases when there isn't 
any factual information about such cases.

Regards,
S. Moonesamy

---

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

Thanks Adrian. (And Brian.)
Alissa, do you think we should change the note to simply remove all of 
section 4?
I can make the other suggested changes.

Yours,
Joel

---

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

Thank you for reviewing this SM.
The reason this document does not directly update the boilerplate is 
that the last revision of the boilerplate RFCs explicitly said that from 
now on the IAB updates the boilerplate without needing a new RFC to do 
so.  Hence, this document is only concerned with tightening the rules, 
not writing the boilerplate.

With regard to updating 2026, this updates the text in 2026 that permits 
informational or experimental RFCs without IETF rough consensus.  it 
removes that permission from the IETF stream.  I do not know how to 
clarify the document in this regard.

Yours,
Joel

On 1/24/2020 5:20 PM, S Moonesamy wrote:
> understands an absolute prohibition when it is written in uppercase.   
> Is that really necessary?
> 
> represents the consensus of the IETF community".  Is there a reason why 
> that that RFC if is not being update to match what Section 3 defines?
> 
> significant change to address certain corner cases when there isn't any 
> factual information about such cases.
> 
> Regards,
> S. Moonesamy
> 
>

---

From: S Moonesamy <[email-masked]>
Date: Sat, 25 Jan 2020 02:04:19 -0800

Hi Joel,
At 02:57 PM 24-01-2020, Joel M. Halpern wrote:
>that the last revision of the boilerplate RFCs explicitly said that 
>from now on the IAB updates the boilerplate without needing a new 
>RFC to do so.  Hence, this document is only concerned with 
>tightening the rules, not writing the boilerplate.

Ok.

>With regard to updating 2026, this updates the text in 2026 that 
>permits informational or experimental RFCs without IETF rough 
>consensus.  it removes that permission from the IETF stream.  I do 
>not know how to clarify the document in this regard.

What you are attempting to do is, in my opinion, about IETF Stream 
policy.  There isn't a written policy as such for that Stream.  One 
alternative is for the IESG to issue a statement to affirm its 
intention not to publish non-standards track documents if it believes 
that there isn't rough consensus to publish.

There is a point which Mr Sayre made about transparency.  One of the 
advantages of operating in a transparent manner is that it helps the 
public to determine, for example, whether a person is acting in good faith.

Regards,
S. Moonesamy

---

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

As the document says, there already is an IESG statement.  There are 
several concerns with this.  The important one as far as I am concerned 
is that the IESG can change its policy.  While it might be bad practice 
to change it without IETF rough consensus, that is not aformally 
required.  This way, changing it DOES require IETF rough consensus.
And it seems to me (and others I have talked to) that it is quite 
appropriate for an IETF stream BCP to update IETF Stream policy. That is 
where we define such things.

Yours,
Joel

On 1/25/2020 5:04 AM, S Moonesamy wrote:
>> from now on the IAB updates the boilerplate without needing a new RFC 
>> to do so.  Hence, this document is only concerned with tightening the 
>> rules, not writing the boilerplate.
> 
> Ok.
> 
>> consensus.  it removes that permission from the IETF stream.  I do not 
>> know how to clarify the document in this regard.
> 
> alternative is for the IESG to issue a statement to affirm its intention 
> not to publish non-standards track documents if it believes that there 
> isn't rough consensus to publish.
>

---

From: S Moonesamy <[email-masked]>
Date: Sat, 25 Jan 2020 12:43:08 -0800

Hi Joel,
At 07:04 AM 25-01-2020, Joel Halpern Direct wrote:
>several concerns with this.  The important one as far as I am 
>concerned is that the IESG can change its policy.  While it might be 
>bad practice to change it without IETF rough consensus, that is not 
>aformally required.  This way, changing it DOES require IETF rough consensus.
>appropriate for an IETF stream BCP to update IETF Stream policy. 
>That is where we define such things.

A BCP does not prevent the IESG from approving the publication of a 
(IETF) RFC as it is the IESG which makes a determination about 
whether there is or there isn't rough consensus.  The available 
recourse in case of disagreement is to request the IESG to reverse 
its decision.  Has there been any appeal in such cases over the last 
five years?

Regards,
S. Moonesamy

---

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

I am not sure what your question is.

I have not researched whether there have been any appeals of IESG 
judgment of IETF rough consensus.  I am not trying to quesiton that part 
of the process.
Having said that, there does exist a process to appeal such if the IESG 
actually does get it wrong.  There is no process to appeal an IESG 
change of an IESG statement.

None of this seems particularly relevant to the question of whether our 
codified rules ought to match the community expectations.  Which is what 
this document does.

Yours,
Joel

On 1/25/2020 3:43 PM, S Moonesamy wrote:
>> appropriate for an IETF stream BCP to update IETF Stream policy. That 
>> is where we define such things.
> 
> (IETF) RFC as it is the IESG which makes a determination about whether 
> there is or there isn't rough consensus.  The available recourse in case 
> of disagreement is to request the IESG to reverse its decision.  Has 
> there been any appeal in such cases over the last five years?
> 
> Regards,
> S. Moonesamy

---

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

Hi Joel,

> On Jan 24, 2020, at 5:50 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Alissa, do you think we should change the note to simply remove all of section 4?

I think it’s better kept in the document so future readers can understand the context.

Thanks,
Alissa

> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call