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

[Joel Halpern Direct <[e-mail]>]

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:
> Hi Joel,
> At 02:57 PM 24-01-2020, Joel M. Halpern wrote:
>> 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.
> 
> 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