Skip to main content

Handling Normative References to Standards-Track Documents
RFC 4897

Revision differences

Document history

Date Rev. By Action
2020-01-21
04 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2017-05-16
04 (System) Changed document authors from "John Klensin" to "John Klensin, Sam Hartman"
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Russ Housley
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Ronald Bonica
2007-06-14
04 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-06-14
04 Amy Vezza [Note]: 'RFC 4897<br>BCP 0097' added by Amy Vezza
2007-06-13
04 (System) RFC published
2007-04-16
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-04-10
04 (System) IANA Action state changed to No IC from In Progress
2007-04-10
04 (System) IANA Action state changed to In Progress
2007-04-09
04 Michael Lee IESG state changed to Approved-announcement sent
2007-04-09
04 Michael Lee IESG has approved the document
2007-04-09
04 Michael Lee Closed "Approve" ballot
2007-04-06
04 (System) Removed from agenda for telechat - 2007-04-05
2007-04-05
04 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2007-04-05
04 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-04-05
04 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Yes from No Objection by Magnus Westerlund
2007-04-04
04 Chris Newman
[Ballot comment]
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 …
[Ballot comment]
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).
2007-04-04
04 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2007-04-04
04 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to Yes from No Objection by Ron Bonica
2007-04-04
04 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss by Ron Bonica
2007-04-03
04 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Yes from No Objection by Cullen Jennings
2007-04-03
04 Cullen Jennings [Ballot discuss]
2007-04-03
04 Cullen Jennings [Ballot comment]
2007-04-03
04 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Yes from Abstain by Russ Housley
2007-04-03
04 Russ Housley State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley
2007-04-03
04 Ron Bonica
[Ballot discuss]
In Section 1 you say:

"While downward references to, e.g., Internet Drafts, are
  theoretically possible, they are not contemplated here."

While in …
[Ballot discuss]
In Section 1 you say:

"While downward references to, e.g., Internet Drafts, are
  theoretically possible, they are not contemplated here."

While in Section 5 you are more specific:

"The "downward reference by annotation" model specified here is
  applicable only to published standards track RFCs at lower maturity
  levels."

The sentence in Section 1 only confuses the issue. I would remove it.
2007-04-03
04 Ron Bonica [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica
2007-03-29
04 Russ Housley Placed on agenda for telechat - 2007-04-05 by Russ Housley
2007-03-29
04 Russ Housley Responsible AD has been changed to Russ Housley from Brian Carpenter
2007-03-28
04 (System) New version available: draft-klensin-norm-ref-04.txt
2007-03-16
04 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-02-21
04 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2007-02-16
04 Amy Vezza Last call sent
2007-02-16
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-02-16
04 Brian Carpenter State Changes to Last Call Requested from IESG Evaluation::AD Followup by Brian Carpenter
2007-02-16
04 Brian Carpenter Last Call was requested by Brian Carpenter
2007-02-14
04 Brian Carpenter State Change Notice email list have been change to klensin@jck.com, hartmans-ietf@mit.edu from klensin@jck.com
2007-02-14
04 Brian Carpenter [Note]: 'Target and scope changed from process experiment to BCP' added by Brian Carpenter
2007-02-14
04 Brian Carpenter Status date has been changed to 2007-02-14 from 2006-12-20
2007-02-14
04 Brian Carpenter Intended Status has been changed to BCP from Experimental
2007-02-13
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-13
03 (System) New version available: draft-klensin-norm-ref-03.txt
2007-02-11
04 Sam Hartman [Ballot comment]
I have joined as an author to help turn this into a BCP so I'm moving
to recuse.
2007-02-11
04 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Recuse from Yes by Sam Hartman
2007-01-11
04 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Amy Vezza
2007-01-09
04 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Undefined by Cullen Jennings
2007-01-09
04 Cullen Jennings
[Ballot comment]
I have a slight preference for just skip the experiment and make this a BCP but do not object to the experiment path …
[Ballot comment]
I have a slight preference for just skip the experiment and make this a BCP but do not object to the experiment path is that what people want to do.
2007-01-05
04 Russ Housley
[Ballot comment]
I think that a process experiment is the wrong thing for the IETF at
  this point in time.  I firmly believe that …
[Ballot comment]
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...
2007-01-05
04 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Abstain from No Objection by Russ Housley
2006-12-20
04 Brian Carpenter Status date has been changed to 2006-12-20 from 2006-04-11
2006-12-20
04 Brian Carpenter Placed on agenda for telechat - 2007-01-11 by Brian Carpenter
2006-12-20
04 Brian Carpenter [Note]: 'RFC 3933 process experiment, substantially reduced in scope in 02 version.' added by Brian Carpenter
2006-12-19
02 (System) New version available: draft-klensin-norm-ref-02.txt
2006-10-23
04 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings
2006-10-23
04 Cullen Jennings [Ballot discuss]
I assume we have found a way forward on this idea and can clear this off my list.
2006-08-30
04 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Undefined by Bill Fenner
2006-08-24
04 Brian Carpenter Placed on agenda for telechat - 2006-08-31 by Brian Carpenter
2006-08-03
04 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2006-08-02
04 David Kessens
[Ballot comment]
Comment by Frank Kastenholz from the Ops Directorate:

anything that has the potential to speed up The Process is A Very
Very Good …
[Ballot comment]
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.
2006-08-02
04 David Kessens
[Ballot discuss]
I have a lot of concerns around this draft. One of the most important is that I am not convinced
at all that …
[Ballot 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.
2006-08-02
04 David Kessens [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens
2006-07-27
04 Yoshiko Fong IANA Last Call comment:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2006-07-27
04 Brian Carpenter Placed on agenda for telechat - 2006-08-03 by Brian Carpenter
2006-07-22
04 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2006-07-20
04 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-07-20
04 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Amy Vezza
2006-07-20
04 Amy Vezza State Changes to IESG Evaluation from IESG Evaluation - Defer by Amy Vezza
2006-07-20
04 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman by Sam Hartman
2006-07-20
04 Bill Fenner [Ballot Position Update] New position, Undefined, has been recorded for Bill Fenner by Bill Fenner
2006-07-20
04 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-07-20
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-07-19
04 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-07-19
04 Cullen Jennings
[Ballot discuss]
This paragraph is not actionable but is here as a way of introduction to my other points... I don't think this experiment goes …
[Ballot discuss]
This paragraph is not actionable but is here as a way of introduction to my other points... I don't think this experiment goes far enough. It says lets have the IESG figure out how to deal with this which is in some way different than the currently specified process. It then suggests IESG do something so vague that it seems to me that the current process would satisfy this experiment. As such, I don't see this having any teeth and runs the risk of the IESG doing basically nothing. In your draft, you give a fair amount leeway to the IESG to define the actual experiment and thank your for that but I think what this needs before being finalized if the the IESG to figure out theses details. So on to actual actionable items...

Please work with IESG to specify in the draft the recommended text that goes along with a downref but note that other text can be used if appropriate.

Let's provide specific guidance for when downrefs are acceptable. I'm assuming this would be more or less the same as 3967.

With regards to section 3.2 - lets either specifically call out the document that we might process under this rule and explicitly list the procedure by which the IESG will handle theses documents. Alternatively, we could just remove section 3.2 or separate it to a different experiment. I see no evidence that sending an email to IETF Last Call a decision like this is in any way too much work for a decision of this type.

Add specific text on what happens in the rare case where a document donwnrefs a document that has been approved but not published then that document never gets published. Personally I think this is rare enough that I am happy with any sane solution to this but this is constantly brought up as an issue so I think we need to say something.

Clear up when the 1 year starts. I would be fine with "when the IESG sends an email" or just about any other approach as long as it is clear.

Finally this discuss is not actionably by the authors but is a topic for the responsible AD. On the call, I would like to understand the level of consensus for this document.
2006-07-19
04 Cullen Jennings
[Ballot discuss]
This paragraph is not actionable but is here as a way of introduction to my other points... I don't think this experiment goes …
[Ballot discuss]
This paragraph is not actionable but is here as a way of introduction to my other points... I don't think this experiment goes far enough. It says lets have the IESG figure out how to deal with this which is in some way different than the currently specified process. It then suggests IESG do something so vague that it seems to me that the current process would satisfy this experiment. As such, I don't see this having any teeth and runs the risk of the IESG doing basically nothing. In your draft, you give a fair amount leeway to the IESG to define the actual experiment and thank your for that but I think what this needs before being finalized if the the IESG to figure out theses details. So on to actual actionable items...

Please work with IESG to specify in the draft the recommended text that goes along with a downref but note that other text can be used if appropriate.

Let's provide specific guidance for when downrefs are acceptable. I'm assuming this would be more or less the same as 3967.

With regards to section 3.2 - lets either specifically call out the document that we might process under this rule and explicitly list the procedure by which the IESG will handle theses documents. Alternatively, we could just remove section 3.2 or separate it to a different experiment. I see no evidence that sending an email to IETF Last Call a decision like this is in any way too much work for a decision of this type.

Add specific text on what happens in the rare case where a document donwnrefs a document that has been approved but not published then that document never gets published. Personally I think this is rare enough that I am happy with any sane solution to this but this is constantly brought up as an issue so I think we need to say something.

Clear up when the 1 year starts. I would be fine with "when the IESG sends an email" or just about any other approach as long as it is clear.

Finally this discuss is not actionably by the authors but is a topic for the responsible AD. On the call, I would like to understand the level of consensus for this document.
2006-07-19
04 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded for Cullen Jennings by Cullen Jennings
2006-07-18
04 Ross Callon
[Ballot comment]
My personal opinion is that this goes in a desirable direction, but not far enough (in that the scope is too limited). However, …
[Ballot comment]
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).
2006-07-18
04 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-07-17
04 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-07-17
04 Ted Hardie
[Ballot discuss]
The IESG also needs to identify someone to write-up the details of the experiment to be run under these guidelines; the IESG also …
[Ballot discuss]
The IESG also needs to identify someone to write-up the details of the experiment to be run under these guidelines; the IESG also needs to decide how it will note to the community that the clock starts ticking on publication of the details.
2006-07-17
04 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie
2006-07-17
04 Ted Hardie
[Ballot comment]
This comment recapitulates some of the discussion in Montreal, so that it is available for the record. 

As I understand this, the IESG …
[Ballot comment]
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).
2006-07-17
04 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2006-07-17
04 Russ Housley
[Ballot comment]
It is unclear how the proposed experimental procedure is substantively
  different from the procedure found in RFC 3967, which says:
  …
[Ballot comment]
It is unclear how the proposed experimental procedure is substantively
  different from the procedure found in RFC 3967, which says:
  >
  > For Standards Track or BCP documents requiring normative reference to
  > documents of lower maturity, the normal IETF Last Call procedure will
  > be issued, with the need for the downward reference explicitly
  > documented in the Last Call itself.  Any community comments on the
  > appropriateness of downward references will be considered by the IESG
  > as part of its deliberations.
  >
  The proposed experimental procedure is:
  >
  > Obviously such downward references are part of the relevant source
  > document at last call and subject to comments from the community.
  >
  Other than the need for an explicit declaration by the author in the
  document, the end result seems to be the same.  Does this minor point
  merit an experiment and a new document?
2006-07-17
04 Russ Housley
[Ballot discuss]
The intention of this process experiment is to allow documents to
  proceed in the standards track even when they contain normative
  …
[Ballot discuss]
The intention of this process experiment is to allow documents to
  proceed in the standards track even when they contain normative
  references to documents at lower levels of maturity.  The author
  lists two cases::

  1) Published RFCs at lower maturity levels, either standards track
      or informational.

  2) 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.

  These cases are quite different.  In the first case, the reference
  points to an archival document, which may contain errors but will not
  change. In the second case, the reference points to a document which
  we expect to become archival, but may still be changed or withdrawn if
  errors are found.  The IETF has consistently maintained a policy that
  I-Ds are not archival or stable documents, this leads to a real chance
  that the document will disappear leading to a broken reference.
  Making I-Ds archival documents would be one way to address this
  concern.

  Documents sometimes change significantly after successful IESG
  evaluation. Having a normative dependency on an I-D means that a
  change could potentially ripple into dependent protocols.  This has
  potential security implications, and these concerns are not
  addressed in Section 6, which says:
  >
  > This document specifies an IETF procedure.  It is not believed to
  > raise any security issues although, in principle, relaxing the
  > normative downward reference rules for references associated with
  > security mechanisms could make a specification less stable and hence
  > less secure.
  >
  It is not purely a matter of making the specification less stable.
  When Spec-A includes a normative reference to Spec-B, the authors of
  Spec-A are expecting implementations of Spec-B to behave in a
  particular manner.  Imagine, for instance, that draft -47 of Spec-B
  has been approved, and it is in the RFC Editor Queue for a long time.
  Draft -47 of Spec-B contains an authorization check, but this check
  is removed in draft -48, with the approval of the shepherding Area
  Director.  Spec-A needs this authorization check, but it is now gone.
  This situations seems to call for a verification that all of the
  dependant parts if the referenced specification is revised in any way.
2006-07-17
04 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2006-07-03
04 Ted Hardie State Changes to IESG Evaluation - Defer from IESG Evaluation by Ted Hardie
2006-06-30
04 Lars Eggert
[Ballot comment]
Section 3., paragraph 1:

>    This document specifies a one-year RFC 3933 [RFC3933] process
>    experiment

  Would be …
[Ballot comment]
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.
2006-06-30
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-06-23
04 Brian Carpenter State Changes to IESG Evaluation from Waiting for Writeup by Brian Carpenter
2006-06-23
04 Brian Carpenter Placed on agenda for telechat - 2006-07-06 by Brian Carpenter
2006-06-23
04 Brian Carpenter [Ballot Position Update] New position, Yes, has been recorded for Brian Carpenter
2006-06-23
04 Brian Carpenter Ballot has been issued by Brian Carpenter
2006-06-23
04 Brian Carpenter Created "Approve" ballot
2006-06-15
04 Brian Carpenter State Change Notice email list have been change to klensin@jck.com from john-ietf@jck.com
2006-06-14
04 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-05-17
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-05-17
04 Brian Carpenter State Changes to Last Call Requested from AD Evaluation by Brian Carpenter
2006-05-17
04 Brian Carpenter Last Call was requested by Brian Carpenter
2006-05-17
04 (System) Ballot writeup text was added
2006-05-17
04 (System) Last call text was added
2006-05-17
04 (System) Ballot approval text was added
2006-04-11
04 Brian Carpenter State Changes to AD Evaluation from Publication Requested by Brian Carpenter
2006-04-11
04 Brian Carpenter Status date has been changed to 2006-04-11 from
2006-04-11
04 Brian Carpenter [Note]: 'RFC 3933 process experiment' added by Brian Carpenter
2006-04-11
04 Brian Carpenter Draft Added by Brian Carpenter in state Publication Requested
2006-04-04
01 (System) New version available: draft-klensin-norm-ref-01.txt
2006-03-27
00 (System) New version available: draft-klensin-norm-ref-00.txt