Handling Normative References to Standards-Track Documents
RFC 4897
Discuss
Yes
No Objection
Recuse
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert No Objection
Section 3., paragraph 1: > This document specifies a one-year RFC 3933 [RFC3933] process > experiment Would be good to explicitly state when that one-year timer starts ticking. "Publication date of this document as an RFC" may be OK. (I note that RFC3933 is vague on this.) Section 4., paragraph 2: > o Internet-Drafts of Standards Track documents for which IESG review > has been completed and Protocol Action or Document Action notices > have been issued. References to such documents would presumably > require the IESG and RFC Editor to work out some appropriate > reference mechanism and format. Standard industry practice would > be consistent with pre-assignment of an RFC number for the target > document and a notation of "forthcoming" in the source document. It may be worth cautioning authors that wish their documents to be part of this experiment that until such an "appropriate reference mechanism and format" is in place, those documents can't really be processed as part of the experiment.
(David Kessens; former steering group member) Discuss
I have a lot of concerns around this draft. One of the most important is that I am not convinced at all that there was consensus reached on the IETF list. There was a lot of discussion but I didn't see any of thew dissenters state that they were convinced and the number of people having issues was about the same as the number of people who approved. This didn't strike me as a case where there was "rough" consensus was clearly reached. Also, I am very concerned about our tendency to solve process issues by inventing new processes instead of obsoleting the old process and replacing it with something new and simpler. I really don't see what the value of an experiment is in this case. If the author believes that this works better than RFC 3967, why not propose this document as a BCP and be done with it. ]Basically, I am not convinced that this document is really a good candidate for a process experiment. The document states: Perhaps because of its fairly stringent requirements, RFC 3967 has not proven adequate either to clear the backlog of documents awaiting upgraded documents or to prevent additional documents from joining that queue. Is there any proof of this ? Even if there is, is the the issue perhaps caused by other issues than the procedure itself ? Like lack of adequate tools for the IESG to quickly and efficiently call out the issue of a downref in a Last Call message. The only thing this experiment really does is to replace the Last Call procedure from RFC 3967 with a text inside the draft itself. I am not convinced that this is actually really worth all the trouble of this experiment. To be fair it, it would also extend the use of RFC 3967 by not using it as the exception any longer, but as the rule. Would it perhaps not be easier to do an experiment that simply makes only this change and use the normal Last Call process? I actually kind of like it that this kind of issues are explicitly mentioned in a Last Call message. I don't agree that that is a very heavy mechanism and it would become a lot easier if there was a tool for the IESG to generate such lines to the Last Call message automatically. What is really so problematic about mentioning this in the Last Call message ? I actually believe that publishing rfcs with references to internet drafts is not a problem as long as we have an official archive of the drafts and we would call this out in the last call message. Obviously, this is beyond the scope of this experiment but I want to make it clear that I am against the idea of relaxing the rules here. However, I don't believe it is useful to allow this for already approved drafts as they are about to be published anyways and the proposed procedure will only serve to lower the quality of the reference section while there is no explicit reason to do so. Note that any reasons along the line of that the rfc editor process takes too much time is really beyond the point. That is a seperate issue and should be addressed in the discussions between the IAOC and the RFC editor on what kind service level the IETF expects from this service. The document states: o Internet-Drafts of Standards Track documents for which IESG review has been completed and Protocol Action or Document Action notices have been issued. References to such documents would presumably require the IESG and RFC Editor to work out some appropriate reference mechanism and format. Standard industry practice would be consistent with pre-assignment of an RFC number for the target document and a notation of "forthcoming" in the source document. The RFC editor has a long standing practise of not issuing early RFC numbers. I don't think it is appropriate to change that practise through the backdoor with an experiment. For the record: I actually disagree with this practise by the RFC editor. The document states: This proposal was suggested by a comment by Spencer Dawkins and many complaints about the negative impact of the current rules. The author is unsure about the validity of some of those complaints; the proposal is, in part, a way to test the validity question. This document causes quite a bit of work without even a single piece of data that this is actually a problem, or better, an analysis why this is the best way to deal with this problem if it exists. Experimenting with the IETF process, and with the publication process in specific and we should only do so if there is a real issue identified and possible solution identified. In this case, even the author admits that he doesn't know whether the complaints about the current procedure are valid and the Last Call discussions indicate that there is certainly no universal agreement that we need to conduct this experiment.
(Brian Carpenter; former steering group member) Yes
(Cullen Jennings; former steering group member) (was No Objection, No Record, Discuss) Yes
(Magnus Westerlund; former steering group member) (was No Objection) Yes
(Ron Bonica; former steering group member) (was No Objection, Discuss) Yes
(Russ Housley; former steering group member) (was Abstain, No Objection, Discuss) Yes
I think that a process experiment is the wrong thing for the IETF at this point in time. I firmly believe that an update to the BCP is the right thing to do. I think we have enough experience (good and bad) to simply update the BCP. I am even willing to do some of the writing...
(Bill Fenner; former steering group member) No Objection
(Chris Newman; former steering group member) No Objection
Good start but doesn't go far enough. I'd like this procedure to be applied to certain non-IETF references as well. It's clearly appropriate for references to textbooks or peer-reviewed journals for algorithms (e.g. Schneier's Applied Cryptography).
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
My personal opinion is that this goes in a desirable direction, but not far enough (in that the scope is too limited). However, a "too small" step in the right direction is still better than no step in the right direction (thus my "no objection" vote).
(Ted Hardie; former steering group member) (was Discuss) No Objection
This comment recapitulates some of the discussion in Montreal, so that it is available for the record. As I understand this, the IESG has considerable latitude in how to run this experiment. I believe the agreement reached was to note on approval that the clock does not start ticking on this experiment until the IESG has published the details of the experiment as it will be run. In particular, the IESG needs to identify which types of approved Internet-Drafts will be treated under this experiment (whether those with reference holds, for example, may be handled).
(Sam Hartman; former steering group member) (was Yes) Recuse
I have joined as an author to help turn this into a BCP so I'm moving to recuse.