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

From: t.p. <[email-masked]>
Date: Fri, 25 Sep 2015 08:34:00 +0100

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" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
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
> [email-masked] mailing lists by 2015-10-08. Exceptionally, comments may
be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: t.p. <[email-masked]>
Date: Mon, 28 Sep 2015 12:18:33 +0100

I find the IANA Considerations delightfully clear.   Acee has, most
promptly, incorporated my suggested text from last week into -05 which
resolves all my previous comments.

Tom Petch

----- Original Message -----
From: "t.p." <[email-masked]>
To: "ietf" <[email-masked]>
Sent: Friday, September 25, 2015 8:34 AM

>                      |           |
|
>                      |           |
|
>                      |           |
|
>                      |           |
|
>                      |           |
|
>                      |           |
|
>                      |           |
|
>                      |             |
|
>                      |             |
|
>                      |             |
|
>                      |             |
|
>                      |             |
|
>                      |             |
|
>                      |             |
|
>        fields Bit Number, Capability Name, and Document Reference.
The