OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering
draft-srisuresh-ospf-te-07

Just to have it in the log: this was the DNP note that was sent for -06.

From: The IESG
To: RFC Editor
Cc: The IESG ,
Subject: Re: Experimental RFC to be: draft-srisuresh-ospf-te-06.txt

The IESG recommends that 'OSPF-xTE: An experimental extension to OSPF for
Traffic Engineering'  NOT be published as
an Experimental RFC.

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.

The IESG contact person is Alex Zinin.

Thank you,

The IESG Secretary

[Note]: 'The previous concern was the use of an unallocated bit; the update uses the OSPF Capabilites LSA for signalling and draft-ietf-ospf-cap-06 assigns it bit # 9.' added by Bill Fenner

[Ballot discuss]
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.

[Ballot comment]
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.