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 |