[OSPF] Fw: Last Call: <draft-ietf-ospf-rfc4970bis-04.txt> (Extensions to OSPF for Advertising Optional Router Capabilities) to Proposed Standard

[t.petch <[e-mail]>]

Acee

As requested.

Tom Petch


----- Original Message -----
From: "t.p." <[e-mail]>
To: "ietf" <[e-mail]>
Sent: Friday, September 25, 2015 8:34 AM
Subject: Re: Last Call: <draft-ietf-ospf-rfc4970bis-04.txt> (Extensions
to OSPF for Advertising Optional Router Capabilities) to Proposed
Standard


> I find the IANA Considerations of this I-D most unclear.  What I think
> they are trying to say is
>
> NEW
>
> 5.  IANA Considerations
>
> 5.1
> [RFC4970] defined the Router Information opaque LSA as type 4 in the
> Opaque Link-State Advertisements (LSA) Option Types Registry.  IANA is
> asked to update the reference for that entry to point to this RFC.
>
> 5.2
>
> [RFC4970] created the registry for OSPFv3 LSA Function Codes.  IANA is
> requested to update the reference for that registry to point to this
> RFC.  References within that registry to [RFC4970] should be updated
to
> point to this RFC; references to other RFCs are unchanged.  The
> definition and assignment policy has been updated as follows.
>
> This registry  is now comprised of the fields Value, LSA function code
> name,
>        and Document Reference.  The OSPFv3 LSA function code is
defined
>        in section A.4.2.1 of [OSPFV3].  The OSPFv3 LSA function code
12
>        has been reserved for the OSPFv3 Router Information (RI) LSA.
>
>
>
+-----------+-------------------------------------+
>                      | Range     | Assignment Policy
|
>
+-----------+-------------------------------------+
>                      | 0         | Reserved (not to be assigned)
|
>                      |           |
|
>                      | 1-11      | Already assigned
|
>                      |           |
|
>                      | 12        | OSPFv3 RI LSA (Assigned herein)
|
>                      |           |
|
>                      | 13-15     | Already assigned
|
>                      |           |
|
>                      | 16-255    | Unassigned (IETF Review)
|
>                      |           |
|
>                      | 256-8175  | Reserved (No assignments)
|
>                      |           |
|
>                      | 8176-8183 | Experimentation (No assignments)
|
>                      |           |
|
>                      | 8184-8191 | Vendor Private Use (No assignments)
|
>
+-----------+-------------------------------------+
>
>                          OSPFv3 LSA Function Codes
>
>        *  OSPFv3 LSA function codes in the range 16-255 are not be
>           assigned subject to IETF Review.  New values are assigned
only
>           through RFCs that have been shepherded through the IESG as
AD-
>           Sponsored or IETF WG Documents [IANA-GUIDE].
>
>        *  OSPFv3 LSA function codes in the range 8176-8181 are for
>           experimental use; these will not be registered with IANA and
>           MUST NOT be mentioned by RFCs.
>
>        *  OSPFv3 LSAs with an LSA Function Code in the Vendor Private
>           Use range 8184-8191 MUST include the Vendor Enterprise Code
as
>           the first 4 octets following the 20 octets of LSA header.
>
>        *  If a new LSA Function Code is documented, the documentation
>           MUST include the valid combinations of the U, S2, and S1
bits
>           for the LSA.  It SHOULD also describe how the Link State ID
is
>           to be assigned.
>
> 5.3
>
> [RFC4970] created the registry for OSPF Router Information (RI) TLVs.
> IANA is requested to update the reference for this registry to point
to
> this RFC.  The definition and assignment policy has been updated as
> follows.  References within that registry to [RFC4970] should be
updated
> to point to this RFC; references to other RFCs are unchanged.  The
> definition and assignment policy has been updated as follows.
>
>
> The registry is now comprised of the fields Value, TLV Name, and
> Document Reference.
>        The value of 1 for the informational capabilities TLV is
defined
>        herein.  The value IANA TBD (suggested value 2) for the Router
>        Functional Capabilities TLV is also defined herein.
>
>
>
+-------------+-----------------------------------+
>                      | Range       | Assignment Policy
|
>
+-------------+-----------------------------------+
>                      | 0           | Reserved (not to be assigned)
|
>                      |             |
|
>                      | 1           | Informational Capabilities
|
>                      |             |
|
>                      | 2           | Unassigned (IETF Review)
|
>                      |             |
|
>                      | TBD         | Functional Capabilities
|
>                      |             |
|
>                      | 3-9         | Already Assigned
|
>                      |             |
|
>                      | 10-32767    | Unassigned (IETF Review)
|
>                      |             |
|
>                      | 32768-32777 | Experimentation (No assignments)
|
>                      |             |
|
>                      | 32778-65535 | Reserved (Not to be assigned)
|
>
+-----------+-------------------------------------+
>
>                                OSPF RI TLVs
>
>        *  Types in the range 2, 10-32767 are to be assigned subject to
>           IETF Review.  New values are assigned only through RFCs that
>           have been shepherded through the IESG as AD-Sponsored or
IETF
>           WG Documents [IANA-GUIDE].
>
>        *  Types in the range 32778-65535 are reserved and are not to
be
>           assigned at this time.  Before any assignments can be made
in
>           this range, there MUST be a Standards Track RFC that
specifies
>           IANA Considerations that covers the range being assigned.
>
>
> 5.4
>
> [RFC4970] created the registry for  OSPF Router Informational
Capability
> Bits.  IANA is requested to update the reference for this registry to
> point to this RFC.  The definition and assignment policy has been
> updated as follows.
>
>  - This registry is now comprised of the
>        fields Bit Number, Capability Name, and Document Reference.
The
>        values are defined in Section 2.4.  All Router Informational
>        Capability TLV additions are to be assigned through IETF
Review.
>
>
> 5.5
>
> IANA ia asked to create a registry for OSPF Router Functional
Capability
> Bits within the Open Shortest Path First v2 (OSPFv2) Parameters
Group.
>
> This registry will be comprised of the
>        fields Bit Number, Capability Name, and Document Reference.
>        Initially, the sub-registry will be empty but will be available
>        for future capabilities.  All Router Functional Capability TLV
>        additions are to be assigned through IETF Review.
>
>
> </NEW>
>
> but I could be wrong!
>
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "The IESG" <[e-mail]>
> To: "IETF-Announce" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, September 25, 2015 1:40 AM
> Subject: [OSPF] Last Call: <draft-ietf-ospf-rfc4970bis-04.txt>
> (Extensions to OSPF for Advertising Optional Router Capabilities) to
> Proposed Standard
>
>
> >
> > The IESG has received a request from the Open Shortest Path First
IGP
> WG
> > (ospf) to consider the following document:
> > - 'Extensions to OSPF for Advertising Optional Router Capabilities'
> >   <draft-ietf-ospf-rfc4970bis-04.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> > final comments on this action. Please send substantive comments to
the
> > [e-mail] mailing lists by 2015-10-08. Exceptionally, comments
may
> be
> > sent to [e-mail] instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
> >    know the capabilities of their neighbors and other routers in the
> >    routing domain.  This document proposes extensions to OSPFv2 and
> >    OSPFv3 for advertising optional router capabilities.  The Router
> >    Information (RI) Link State Advertisement (LSA) is defined for
this
> >    purpose.  In OSPFv2, the RI LSA will be implemented with an
opaque
> >    LSA type ID.  In OSPFv3, the RI LSA will be implemented with a
> unique
> >    LSA type function code.  In both protocols, the RI LSA can be
> >    advertised at any of the defined flooding scopes (link, area, or
> >    autonomous system (AS)).  This document obsoletes RFC 4970 by
> >    providing a revised specification including support for
> advertisement
> >    of multiple instances of the RI LSA and a TLV for functional
> >    capabilities.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc4970bis/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc4970bis/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf
>