John & Jari:
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 ..."
Even if such a document started in the IETF process, it did not
complete the IETF process.
I can imagine a situation where a document goes to IETF Last Call
that demonstrates that there is not consensus, and that document ends
up being published in the individual submission stream, but that has
not happened in my memory. It certainly is not the normal situation.
I suggest: "Documents published in streams other than the IETF Stream
do not receive full review by the IETF for such things as security,
congestion control, or inappropriate interaction with deployed protocols."
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.
I suggest a replacement sentence: "Generally, there is no attempt for
IETF consensus or IESG approval."
(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.
The revised sentence says: "The IESG finds that publication is
potentially harmful to the IETF work done in WG <X> and recommends
not publishing the document at this time."
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.
This was the whole point of RFC 3932 and the subsequent creation of
the RFC Editorial Board.
The IESG received the following comment. I think it is okay to share
here with the sender's identity removed.
| I think the draft is good as it is. I don't plan to respond in detail to
| John Klensin's comments, but my bottom line is that I think the proposed
| wording is correct. I do support the independence of the Independent stream,
| but I don't think that deprives the IESG of the right to speak for the
| IETF in asserting harm, etc.
I make this public to let people know that the IESG is also getting
private comments on this draft. To properly judge consensus, the
IESG needs to hear from the whole community, not just a few vocal members.
Thanks,
Russ
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf