Hi Tom, Thanks much for the text - I agree this is much clearer and will use this a template for future BIS documents. I have incorporated your text in the 05 version of the document. Thanks, Acee
On 9/25/15, 3:35 AM, "OSPF on behalf of t.petch" <ospf-boun...@ietf.org on behalf of ie...@btconnect.com> wrote: >Acee > >As requested. > >Tom Petch > > >----- Original Message ----- >From: "t.p." <daedu...@btconnect.com> >To: "ietf" <i...@ietf.org> >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" <iesg-secret...@ietf.org> >> To: "IETF-Announce" <ietf-annou...@ietf.org> >> Cc: <ospf@ietf.org> >> 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 >> > i...@ietf.org mailing lists by 2015-10-08. Exceptionally, comments >may >> be >> > sent to i...@ietf.org 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 >> > OSPF@ietf.org >> > https://www.ietf.org/mailman/listinfo/ospf >> > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
