John,
That was a long list of issues.
Let me start off by saying that RFC 3932 is already a part of the daily
procedures we operate on. Draft-housley was written to make an
incremental improvement on it. This incremental improvement is the
publication of the headers and boilerplates document, which allows us to
simplify the process for independent submissions and requires less use
of IESG notes. I believe we both share the opinion that these are
necessary and useful improvements. And, given that the headers and
boilerplates change is going forward I hope we can accomplish the 3932
revision at the same time.
Some more detailed answers:
(1) The IESG should never make an assertion that is known to be
false. ... Even if the IESG has not
reviewed a document, it doesn't imply that "the IETF" has not.
I agree that some independent submission stream documents have been in
the IETF discussions. The issue is whether any sort of final review
occurred. I'd be happy to see a wording change here. E.g., "Documents
published in streams other than the IETF Stream are not reviewed by the
IETF for such things ..." => "Documents published in streams other than
the IETF Stream do not get a full review and are not required to get any
review by the IETF for such things ..."
The second sentence of that paragraph should be
removed entirely unless the IESG wants to deprive itself of
flexibility to formally ask for community input by prohibiting
the use of Last Calls on Independent Submission drafts (a
flexibility that language in 4846 was intended to preserve).
As I commented to SM, I do believe the IESG needs to have the room to
make judgment calls. In the case that I mentioned in that e-mail, we
actually did ask for community input (after first getting some
unsolicited input :-), though not in the form of document review or a
last call. Again, I would like to see a change in the document on this.
(2) The numbered list in Section 3 is the substantive core of
this document. "Harmful" in Item 3 is "potentially damaging to,
or problematic for, the IETF Standards Process", not "harmful to
the Internet".
Yes. And this is what is says: "harmful to the IETF work".
"Potentially" is important there too. The IESG
should not be expected to foretell possible futures or provide
an analysis of how damage might occur: it should merely have to
have a reasonable basis for believing that WG or other standards
process disruption might occur or that an end-run is being
attempted.
I agree and I support adding this word.
On your sweeping issue: I believe most of the practical applicability of
RFC 3932 has been in the area of checking for conflict with WG process
(response 3) and IANA rules (response 4). Again, response 3 text is IMHO
already clear. That being said, I do believe there should be an
opportunity check for possible harm as stated in response 5 as well.
From my perspective that item is reserved for the cases where we, e.g.,
old protocols for which no IANA procedures have been defined. The
practical reality is that we find such cases daily. We could make the
text more specific, require more last calls and steps before such claims
can be made. But frankly, I do not want to turn the independent
submission process into a one that requires IETF review; it seems
counter-intuitive. The IESG should make a quick check as described in
the document, and if they screw up, the next step should be an appeal or
talking to the nomcom. Of course, as I already explained I don't mind
stating that a last call might be a useful tool in some special cases.
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf