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." <daedulus@xxxxxxxxxxxxx> To: "ietf" <ietf@xxxxxxxx> Sent: Friday, September 25, 2015 8:34 AM > 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" <iesg-secretary@xxxxxxxx> > To: "IETF-Announce" <ietf-announce@xxxxxxxx> > Cc: <ospf@xxxxxxxx> > 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 > > ietf@xxxxxxxx mailing lists by 2015-10-08. Exceptionally, comments may > be > > sent to iesg@xxxxxxxx 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.