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

["Acee Lindem (acee)" <[e-mail]>]

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" <[e-mail] on
behalf of [e-mail]> wrote:

>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
>>
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf