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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
