John, > If a document is the result of an IETF process, then we > would prefer that the IESG consider it and render an > opinion of some sort before it is submitted to the RFC > Editor. That opinion might be a decision by an AD to > sponsor the document, it might be similar to any of the > comments or categories called out in RFC 3932, it might > be some less formal comment. But the expectation is > that the initial responsibility for a document emerging > from an IETF process lies with the IESG and its members. > An author or other proponent of such a document who > submits it to the RFC Editor (as an independent > submission) will be expected to present evidence that he > or she made a diligent effort to obtain IESG review or > comments. > > We believe that, in general, if the IESG wants something > published (as normative, historical, or anything in > between), then the IESG should say so. The condition of > an AD telling someone, about a document that resulted > from an IETF process, "the IESG doesn't care about this > enough to even consider it, why don't you try the RFC > Editor" has the odor of encouraging forum-shopping and > should be very rare. > > The term "resulting from an IETF process" is > (deliberately) even more vague than "considered by a WG" > but is a superset of it that includes products of > formally-constituted design teams, reports on the > conclusions of BOFs, etc. > > For documents that result from IETF processes that the > IESG does not decide to sponsor, the RFC Editor will > consider the IESG's comments, if any, as part of the > review process. IESG recommendations and comments (or a > decision to not comment, even on the degree of > historical importance) will be given especially strong > consideration when the relevant document is related to > IETF processes rather than having strong technical or > operational content. > > The net result of this model is that, if a document results from > an IETF process, it is unlikely to be published as an RFC unless > it receives either sponsorship or, at least a positive review > and recommendation, from the IESG _or_ it represents a critical > review of an IETF conclusion or inability to reach a conclusion. > This sounds reasonable to me. >> 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. >> > > ... However, many of us believe that it is very important > that the RFC Editor be permitted to publish documents that are > highly critical of IETF conclusions and, indeed, of the IETF. > That requirement implies not giving the IESG any sort of "DNP" > veto power. > Sure. But I was not commenting on the lack of veto power. I was commenting on the inconsistency between two document parts. I think its fine if the RFC Editor makes its own decision about the publication, having gotten IESG's input. That's what "independent" means. But your Section 4.8 and the current RFC 3932 implies that the IESG has the ability to provide the "DNP" input. I think that ability should be retained, and reflected in the same manner in Sections 2 and 4.8. > See above. If there is concensus about "advice, not control", > then this text can be removed after appropriate other text is > developed. > Ok. > As with almost everything else associated with the IETF and much > of the Internet community, there are times in which informal > inquiries and informal processes can save everyone a good deal > of time and energy. I can't speak for how much it has happened > in the past (and the answers for the recent past and the more > distant past may differ) but I certainly would not want to > prevent the RFC Editor from responding, informally, to an > inquiry about whether or not a document with some particular > outline or subject matter would be acceptable for publication. > And, yes, that implies a mini-review prior to a formal request > for publication. > Ok. >> 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. >> > > Personally, I share your concerns and would be happy to remove > that text. OK > However, during earlier discussions, there was a > great deal of interest expressed in more transparency, more > community review and input, etc. There is obviously a tradeoff > in this: if one wants more assurance of transparency and > community review, then it is difficult to avoid more process and > formality. The community needs to make up its collective mind. > Right. It is important that we settle on what the general direction is. I believe very much in transparency, ability to challenge bad decisions, etc. But I'm not sure adding significant community review is compatible with the idea of an independent submission process, at least if the community ~ the people who also attend the IETF.
Anyway, we are discussing about philosophy while the actual change that I suggested was fairly small... Jari _______________________________________________ INDEPENDENT mailing list [email protected] https://www1.ietf.org/mailman/listinfo/independent
