My apologies. It refers to a well trodden ground (i.e. not green-field). My point is that if the work regards currently deployed protocols, maybe the process for getting an RFC should be a little stricter.
Hence my noting that this charter imposes a major policy change on acceptance of standards-track efforts and that such a change is not reasonable a) without explanation, and b) to initiate within a specialized working group charter.
In other words, something like this needs separate, focused, IETF-wide policy-oriented discussion, support, documentation and adoption as an explicit policy.
And contrary to Brian's assessment RFC 2026 does not cover
anything like the conditions specified in the new wg charter:
he question "Will this damage running code?" seems legitimate, and I
hope the IESG considers it whenever relevant.
That's a specific concern, not stated in the new working group charter.
The onerous barrier to adoption applies to everything that might be adopted, no matter how minor.
It's explicit in RFC 2026There is a massive difference between:
that "Usually, neither implementation nor operational experience is
required" for PS, so Dave is correct that this is a higher requirement
than normal. But it conforms to RFC 2026 because of that "Usually" and
the following paragraph:
~~~
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.
Prior to accepting any Standards Track document for development, there must
be a commitment to implement the resulting proposed standard from at least
two independent parties, as recorded on a related IETF mailing list.
and
prior to granting Proposed Standard status
The other requirement:
* When deciding to send any Standards Track work to the IESG, there must
first be produced a report documenting at least two (preferably more)
independent implementations with at least partial interoperation based on the
developed specification.
has IETF history in very specialized cases, not as a blanket rule
for all work to be done, no matter how minor.
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social
