Thanks for summarizing. Responding to a couple of points inline: > > 3. The interaction between "independent" and modifications and/or > creation of IANA registries. > > There seems consensus that the document should not try to solve these > issues and that these issues will in practice be caught by the RFC > editor or IESG review. It has been suggested to raise awareness about > possible interactions with a reference to RFC2434 but it seems (my > opinion) that that sort of instruction is to detailed for this level > of document. I therefore propose not to include text along those lines. > > Are you saying RFC 3932 is the normative rule on that? I can buy that. But remember that these documents do not exist just to document the rules for our process. They will also be read by people who are considering submitting an RFC to one of the streams. To help them make the right decision I think it is essential to point to the IANA rules. We should not repeat the rules or start elaborating anything stated in RFC 3932, 2434 or any of the Standards Track RFCs that lay out the rules for IANA considerations in any specific case. But even from a truth-in-marketing point of view the document needs to warn people that they have to check whether the IANA rules allow non-IETF submissions. > 4. Independent publication of documents resulting from IETF process. > > My reading of the discussion is that this issue is a hot topic that > does not necessarily needs to be covered in the document. Under the > current independent text the RFC editor has sufficient flexibility to > set its own policy on publication of this set of document. > > I am carefully using the words "my reading of" since I am not sure if > consensus is reached. I would like to invite people that disagree with > dismissing this issue, to send in text.
This is indeed a hot topic, and one where we may still be learning for quite a while. Perhaps after that learning process we should write another RFC on the treatment of documents resulting from unsuccessfully terminated IETF processes. My take would be to provide a fairly small amount of guidance and without any hard rules about this topic in both draft-klensin and draft-iesg. I think we already do that, though as I recall there was a slight tone difference between the documents. Text needed. I feel responsible and promise to send some. > > 5. Requests to not publish the document by the IESG. > > The consensus in this (reappearing) discussion is that the IESG should > be able to provide their arguments against publication to the > RFC-editor. It is the RFC-editor has the purview for deciding on > publication. > > The inconsistency between 2 and 4.8 will need to be resolved with > appropriate text. Right. > > 7. Exact timing of interaction between IESG and RFC editor > > There seems to be consensus for the idea posted by John in point [1] > in > http://www1.ietf.org/mail-archive/web/independent/current/msg00226.html > Ack. > > > 6. RFC3932upd > > The references to 3932upd should be removed. I suggest that removing > the first paragraph of 1.2 is sufficient in this context and that the > second paragraph of 1.2 and the text in the second paragraph of 4.2 > reflect the consensus that I described in issue 5. > > Yep. Jari _______________________________________________ INDEPENDENT mailing list [email protected] https://www1.ietf.org/mailman/listinfo/independent
