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(_at_)btconnect(_dot_)com>
To: "ietf" <ietf(_at_)ietf(_dot_)org>
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(_at_)ietf(_dot_)org>
To: "IETF-Announce" <ietf-announce(_at_)ietf(_dot_)org>
Cc: <ospf(_at_)ietf(_dot_)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
ietf(_at_)ietf(_dot_)org mailing lists by 2015-10-08. Exceptionally,
comments
may
be
sent to iesg(_at_)ietf(_dot_)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.