Handling Normative References to Standards-Track Documents
RFC 4897

Note: This ballot was opened for revision 04 and is now closed.

(David Kessens) Discuss

Discuss (2006-08-02 for -)
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.
Comment (2006-08-02 for -)
No email
send info
Comment by Frank Kastenholz from the Ops Directorate:

anything that has the potential to speed up The Process is A Very
Very Good Thing and should automatically go to the head of the queue.

(Ron Bonica) (was No Objection, Discuss) Yes

(Brian Carpenter) Yes

(Russ Housley) (was Abstain, No Objection, Discuss) Yes

Comment (2007-01-05)
No email
send info
  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...

(Cullen Jennings) (was No Objection, No Record, Discuss) Yes

Magnus Westerlund (was No Objection) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

Comment (2006-07-18 for -)
No email
send info
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).

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-06-30 for -)
No email
send info
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.

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2006-07-17)
No email
send info
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).

(Chris Newman) No Objection

Comment (2007-04-04)
No email
send info
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).

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(Sam Hartman) (was Yes) Recuse

Comment (2007-02-11 for -)
No email
send info
I have joined as an author to help turn this into a BCP so I'm moving
to recuse.