John, I read this draft a few days ago, and was generally very happy with it. A few comments, however:
1. There is no mention of IANA rules that sometimes dictate what kind of documents may allocate new numbers. While the rules and their use is defined in other documents (the actual protocol RFCs, RFC 2434, RFC 3932), it would seem useful to mention the issue here as well. If not for other reasons, at least for the benefit of folks who consider making an independent submission. 2. I would like to synchronize draft-iesg-sponsoring- guidelines and this draft. Here's what this draft currently says: > o Documents considered by IETF Working Groups but not standardized. > While many documents of this type are published via the IESG > approval path (see RFC 3932, Section 1 [RFC3932]), the independent > submission path has traditionally been open to them. Because of > their intimate connection to the IETF Standards Process and WG > activites and the consequent sensitivity to exact statements of > relationships and to timing, there is reason to believe that all > such documents should be published only at IESG request. In any > event, these documents are published for the historical record. and here's my planned text for the next revision of the IESG draft wrt. AD sponsoring historical record RFCs: > Relevance > > ... > > A document specifying a particular vendor's proprietary protocol > is typically more suitable as an independent submission than being > sponsored by an AD. A document specifying an alternate approach > to an existing Standards Track solution is typically not a likely > candidate either. But this is a judgment call. For instance, if > there is general agreement in a WG for publishing a "road not > followed" document for the record, but the WG itself considers it > out of scope, AD sponsoring might be appropriate. > > History > > Sometimes the IETF, IESG, and the WG has more information about > the history of the document than the RFC Editor. This is the case > with the "road not followed" documents mentioned above as well as > with other documents recently seriously considered in the IETF. > If the publication of these documents is appropriate, they are > likely > more suitable as individual submissions than as independent > submissions. This seems generally aligned, but the IESG draft is slightly less strict, leaving some room for interpretation. Note that "considered by a WG" is not an exact definition. Any guidance from this list on this matter? 3. At the end of Section 2, you explain how the RFC Editor and the IESG work together with regards to conflicts with the IETF standards process. But this explanation only talks about delays and IESG notes, not the possibility of not publishing at all which Section 4.8 lists also as a possibility. Please update Section 2. 4. Is the below reference correct, or should you simply be pointing to RFC 2026? (Draft-iab-rfc-editor refers to RFC 2026 and draft-iesg- sponsoring-guidelines when it talks about the IETF stream.) > o Documents considered by IETF Working Groups but not standardized. > While many documents of this type are published via the IESG > approval path (see RFC 3932, Section 1 [RFC3932]), 5. I cannot find this reference, even after searching for it from the set of old drafts: > [RFC3932upd] > Klensin, J., Ed., "IESG Notes on Independent Submissions > to the RFC Editor". 6. It was not obvious to me what the issues mentioned below are. It also seems more appropriate to deal with those issues in the RFC 3932bis work, than here. Or are they so deeply related that we cannot talk about them separately? > This document contains text that, if agreed to by the community, may > suggest a reexamination of and a corresponding update to RFC 3932 > [RFC3932]. Those issues, and proposals for changes, are discussed in > a different document [RFC3932upd], but they are semi-independent of > the content of this document, which focuses on the review and > approval process for independent submissions. 7. I am not sure that the second step may be taken out of order below. If it was taken out of order, would it imply that the RFC Editor is performing reviews etc. even before the request for publication comes in? > ... at the > discretion of the RFC Editor, steps after the first may be taken out > of order. > > 4.1. Posting of Draft > > The author(s) or editor(s) of a document post it as an Internet > Draft. > > 4.2. Request for Publication 8. I am somewhat concerned that we're building quite a lot of process for the independent submission path. I like the transparency, use of reviewers, ability to escalate a problem to the IAB, etc, but we should not attempt to build a process which is similar to the IETF. In particular, Section 4.8 says: > ... comments on conflicts can be sent to the IESG > with copies to the RFC Editor. Additional mechanisms may be > developed from time to time to inform a community that a document is > entering formal prepublication review. Comments not directly related > to IETF procedures or conflicts may be sent directly to the author(s) > and RFC Editor. I hope we are not developing an "RFC Editor Last Call" procedure where the same community of Internet experts is expected to provide feedback to both IETF and independent submissions. Yet another mailing list to subscribe for everyone; yet more documents to look at in a situation where we already get too little LC review per document. I like the independent submission process very much, and have a lot of trust in the RFC editor and their selected reviewers for doing competent publication decisions. But I think one of the values of this system is that is indeed run by an independent set of people, not calling for the general community review in the same manner as IETF does. I would suggest deleting the text in question. 9. Are these two text excerpts consistent: > o Documents considered by IETF Working Groups but not standardized. > While many documents of this type are published via the IESG > approval path (see RFC 3932, Section 1 [RFC3932]), the independent > submission path has traditionally been open to them. Because of > their intimate connection to the IETF Standards Process and WG > activites and the consequent sensitivity to exact statements of > relationships and to timing, there is reason to believe that all > such documents should be published only at IESG request. > However, the RFC Editor prefers that documents created > through IETF processes (e.g., working group output) be considered by > the IESG and submitted using this path only if a working group, or > the IESG, decline to publish it. Jari _______________________________________________ INDEPENDENT mailing list [email protected] https://www1.ietf.org/mailman/listinfo/independent
