Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]