OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering
draft-srisuresh-ospf-te-07
Note: This ballot was opened for revision 07 and is now closed.
Alex Zinin Former IESG member
(was Yes)
Discuss
Discuss
[Treat as non-blocking comment]
(2004-04-02)
Don't believe the document can be published as is. Bringing to the IESG telechat for a DNP note. Proposed DNP note: The IESG has consulted with the OSPF and CCAMP WG chairs regarding draft-srisuresh-ospf-te-06.txt. It has been pointed out that the document uses one of the OSPFv2 Options bits by simply assigning a meaning to an unused bit position. Given that OSPFv2 Options bits are a scarce resource (8 bits total, 1 bit left), and that the OSPF WG decided not to proceed with the proposed mechanism, publishing this document would be inappropriate. In fact, the assignment proposed in draft-srisuresh-ospf-te-06.txt is in direct conflict with the OSPF WG document draft-ietf-ospf-2547-dnbit-04.txt that has recently been approved by the IESG. With this new piece in mind, the IESG recommends that the RFC Editor does not publish draft-srisuresh-ospf-te-06.txt. If the authors of the document are interested in pursuing the approach described in the document further, it is recommended that they resolve this issue with the OSPF WG. Also, if the RFC Editor ever decides to publish this document in some form (presumably under the condition that issues with OSPF and CCAMP WGs have been resolved), the IESG would like to request that the following IESG note is put on it: This document was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document and in particular notes it has not had IETF review for security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor may choose to publish such documents at its discretion, but the appearance of such documents should not be taken as an IETF statement about the document's fitness for its stated purpose. Readers of this document should exercise caution in evaluating its fitness as a specification and should understand that its appearance does not indicate that the the IETF thought it to be a viable Internet standard.
Allison Mankin Former IESG member
No Record
No Record
(2004-04-02)
Isn't this an RFC Editor document?
Bill Fenner Former IESG member
No Record
No Record
(2004-04-02)
Yes, this is an RFC-Editor document. I submitted a ticket on Tuesday night to ask it to be moved to the right section of the agenda, but perhaps that wasn't possible to do before the final version of the agenda.