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 steering group member) (was Yes) Discuss

Discuss [Treat as non-blocking comment] (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) No Record

No Record (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Isn't this an RFC Editor document?

(Bill Fenner; former steering group member) No Record

No Record (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.