TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format
draft-ietf-manet-tlv-naming-05

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

A Standards Track RFC is requested.  This document makes changes,
primarily of names, to IANA registries specified by Proposed Standard
RFCs. Registry assignment for future requests is also changed from
current practice to align with the change in naming.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary: This document renames and makes minor changes to some
IANA registries that derive from RFC 5444. During progress of another draft
(draft-ietf-manet-olsrv2-multitopology) issues with current registry naming practices
were illustrated; specifically having different names for different TLV type extensions
was not allowed.  If this naming was enforced certain TLV types would share a "name"
but otherwise be completely divergent in meaning.  This draft reorganizes the registry
naming rules and does not change any protocol functionality.

Working Group Summary: This was regarded as a technical change, requested by the AD.
There was no particular interest in the draft (for or against), beyond being necessary to
progress draft (draft-ietf-manet-olsrv2-multitopology).

Document Quality: The document clearly states it's purpose, to change naming of IANA
registries for future assignments and to provide new versions of IANA registries to reflect
these rules.  It does this clearly and with detail.

Personnel:

Justin Dean (jdean@itd.nrl.navy.mil) is the document shepherd for this document. 
Alvaro Retana (aretana@cisco.com) is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has personally reviewed the document for quality and
for correctness in proposed IANA registry changes.  He believes it is
ready for forwarding to the IESG for publication.  While the document
only changes naming of registries this change is warranted as the current
rule set is needlessly confusing to the point of being broken.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document has had limited reviews, but has a very limited impact
(none on protocol operation).  A triple check that all of the appropriate
currently assigned IANA registries have been addressed by this draft with
updated naming would be helpful.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It's the Shepherd's opinion that no further reviews are required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Working group consensus is mostly silent with most support coming from
informed individuals.  The WG understands the changes this document
affects and as a whole agree that they are necessary and correct. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.


(13) Have all references within this document been identified as
either normative or informative?

The document has only normative references.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document updates the Expert Review guidelines from RFC5444 to
reflect the naming changes.  This is listed in the introduction.  This
document also appropriately renames IANA registry "Mobile Ad hoc NETwork
(MANET) Parameters" assignments from RFC5497, RFC6130, RFC7181, RFC7182,
and RFC7188.  Only names are changed, numbers assigned, their meaning and
protocol functioning is not.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document is essentially only an IANA consideration section, plus
rationale. It describes in detail the required changes for each registry
name change along with detailed listing of reference document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new IANA registries, just renaming and changes to of
existing "Mobile Ad hoc NETwork (MANET) Parameters" registries derived
from RFC5444.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There are no sections of the document written in a formal style.

[Ballot comment]
- I wonder if this document should only update RFC5444, or all the RFCs that are changed in IANA?
Let's take an example:
The IANA Registry "Message TLV Types" is changed to Table 1.

          +---------+-------------------------------+-----------+
          |  Type  | Description                  | Reference |
          +---------+-------------------------------+-----------+
          |    0    | Defined by Type Extension    | [RFC5497] |
          |    1    | Defined by Type Extension    | [RFC5497] |
          |  2-4  | Unassigned                    |          |
          |    5    | ICV                          | [RFC7182] |
          |    6    | TIMESTAMP                    | [RFC7182] |
          |    7    | Defined by Type Extension    | [RFC7181] |
          |    8    | Defined by Type Extension    | [RFC7181] |
          |  9-223  | Unassigned                    |          |
          | 224-255 | Reserved for Experimental Use | [RFC5444] |
          +---------+-------------------------------+-----------+

                        Table 1: Message TLV Types

The current IANA entries for that registry are:
Type Description Reference
0 INTERVAL_TIME [RFC5497]
1 VALIDITY_TIME [RFC5497]
2-4 Unassigned
5 ICV [RFC7182]
6 TIMESTAMP [RFC7182]
7 MPR_WILLING [RFC7181]
8 CONT_SEQ_NUM [RFC7181]
9-223 Unassigned
224-255 Reserved for Experimental Use [RFC5444]

I guess that, if I would read RFC 5497 and the new registry, the story would be complete since RFC5444 is updated by  draft-ietf-manet-tlv-naming-RFC-to-be. Anyway, just asking the question so that we doubleckeck. Basically, if Michelle Cotton is fine, I'm fine.

- I agree with Barry regarding the abstract length.

[Ballot comment]
The Abstract isn't very abstract -- which is to say it's very long.  Can you let the Introduction do the heavy lifting, and cut the Abstract back to, say, the last two paragraphs with a little editing (to expand "TLV" there and to replace "those registries" with something like "the MANET TLV registries defined in RFC 5444")?

Other than that, I have no comment but that this is a fine thing to do, and it doesn't surprise me that Adrian brought it up.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

A Standards Track RFC is requested.  This document makes changes, primarily of names, to IANA registries specified by Proposed Standard RFCs. Registry assignment for future requests is also changed from current practice to align with the change in naming.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary: This document renames and makes minor changes to some IANA registries that derive from RFC 5444. During progress of another draft (draft-ietf-manet-olsrv2-multitopology) issues with current registry naming practices were illustrated; specifically having different names for different TLV type extensions was not allowed.  If this naming was enforced certain TLV types would share a "name" but otherwise be completely divergent in meaning.  This draft reorganizes the registry naming rules and does not change any protocol functionality.

Working Group Summary: This was regarded as a technical change, requested by the AD. There was no particular interest in the draft (for or against), beyond being necessary to progress draft (draft-ietf-manet-olsrv2-multitopology).

Document Quality: The document clearly states it's purpose, to change naming of IANA registries for future assignments and to provide new versions of IANA registries to reflect these rules.  It does this clearly and with detail.

Personnel:

Justin Dean (jdean@itd.nrl.navy.mil) is the document shepherd for this document. 
Alvaro Retana (aretana@cisco.com) is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has personally reviewed the document for quality and for correctness in proposed IANA registry changes.  He believes it is ready for forwarding to the IESG for publication.  While the document only changes naming of registries this change is warranted as the current rule set is needlessly confusing to the point of being broken.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document has had limited reviews, but has a very limited impact (none on protocol operation).  A triple check that all of the appropriate currently assigned IANA registries have been addressed by this draft with updated naming would be helpful.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It's the Shepherd's opinion that no further reviews are required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Working group consensus is mostly silent with most support coming from informed individuals.  The WG understands the changes this document affects and as a whole agree that they are necessary and correct. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.


(13) Have all references within this document been identified as
either normative or informative?

The document has only normative references.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document updates the Expert Review guidelines from RFC5444 to reflect the naming changes.  This is listed in the introduction.  This document also appropriately renames IANA registry "Mobile Ad hoc NETwork (MANET) Parameters" assignments from RFC5497, RFC6130, RFC7181, RFC7182, and RFC7188.  Only names are changed, numbers assigned, their meaning and protocol functioning is not.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document is essentially only an IANA consideration section, plus rationale. It describes in detail the required changes for each registry name change along with detailed listing of reference document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new IANA registries, just renaming and changes to of existing "Mobile Ad hoc NETwork (MANET) Parameters" registries derived from RFC5444.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There are no sections of the document written in a formal style.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-tlv-naming-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about some of the actions requested in the IANA Considerations section of this document.

As this document requests revisions to an Expert Review sub-registries, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that, upon approval of this document, there are ten actions which must be completed.

First, for the following four registries in the Mobile Ad hoc NETwork (MANET) Parameters registry located in:

http://www.iana.org/assignments/manet-parameters/

- Packet TLV Types
- Message TLV Types
- Address Block TLV Types

IANA understands that the management of the registries will remain as Expert Review as defined in RFC 5266. IANA also understands that [ RFC-to-be ] provides additional Expert Review guidelines. IANA also understands that the document makes a recommendation that the Extensions registries for these registries should follow a particular naming convention.

IANA Question --> Should the titles of the existing Extensions registries for these subregistries be changed?

Second, in the Message TLV Type subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located in:

http://www.iana.org/assignments/manet-parameters/

IANA understands that the registry should be completely replaced with the following contents:

+---------+-------------------------------+-----------+
| Type | Description | Reference |
+---------+-------------------------------+-----------+
| 0 | Defined by Type Extension | [RFC5497] |
| 1 | Defined by Type Extension | [RFC5497] |
| 2-4 | Unassigned | |
| 5 | ICV | [RFC7182] |
| 6 | TIMESTAMP | [RFC7182] |
| 7 | Defined by Type Extension | [RFC7181] |
| 8 | Defined by Type Extension | [RFC7181] |
| 9-223 | Unassigned | |
| 224-255 | Reserved for Experimental Use | [RFC5444] |
+---------+-------------------------------+-----------+

Third, IANA notes that the text of section 3.2 specifically requests that:

"The IANA Registry "ICV Packet TLV Type Extensions" is unchanged.

The IANA Registry "TIMESTAMP Packet TLV Type Extensions" is unchanged."

IANA Question --> This seems inconsistent with the guidance provided in section 3.1 of the same document which suggests that: "For Packet TLV Types, that the Type Extension registry, created for the TLV Type, be named "Type XX Packet TLV Type Extensions", with XX replaced by the numerical value of the TLV Type." Are these two Packet TLV Type Extension Registries being singled out for special behavior or treatment?

Fourth, a set of existing registries in:

http://www.iana.org/assignments/manet-parameters/

are to be modified as follows:

The IANA Registry "INTERVAL_TIME Message TLV Type Extensions" is renamed as "Type 0 Message TLV Type Extensions" and changed to the following:

+-----------+---------------+---------------------------+-----------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+---------------+---------------------------+-----------+
| 0 | INTERVAL_TIME | The maximum time before | [RFC5497] |
| | | another message of the | |
| | | same type as this message | |
| | | from the same originator | |
| | | should be received | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC5497] |
| | | Use | |
+-----------+---------------+---------------------------+-----------+

The IANA Registry "VALIDITY_TIME Message TLV Type Extensions" is renamed as "Type 1 Message TLV Type Extensions" and changed to the following:

+-----------+---------------+---------------------------+-----------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+---------------+---------------------------+-----------+
| 0 | VALIDITY_TIME | The time from receipt of | [RFC5497] |
| | | the message during which | |
| | | the information contained | |
| | | in the message is to be | |
| | | considered valid | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC5497] |
| | | Use | |
+-----------+---------------+---------------------------+-----------+

Fifth, IANA notes that the text in section 3.2 (as above) specifically requests that:

"The IANA Registry "ICV Message TLV Type Extensions" is unchanged.

"The IANA Registry "TIMESTAMP Message TLV Type Extensions" is unchanged."

IANA Question --> This seems inconsistent with the guidance provided in section 3.1 of the same document which suggests that: "For Message TLV Types, that the Type Extension registry, created for the TLV Type, be named "Type XX Message TLV Type Extensions", with XX replaced by the numerical value of the TLV Type." Are these two Message TLV Type Extension Registries being singled out for special behavior or treatment?

Sixth, another set of existing registries in:

http://www.iana.org/assignments/manet-parameters/

are to be modified as follows:

The IANA Registry "MPR_WILLING Message Type Extensions" is renamed as "Type 7 Message TLV Type Extensions" and changed as follows:

+-----------+-------------+-----------------------------+-----------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+-------------+-----------------------------+-----------+
| 0 | MPR_WILLING | Bits 0-3 specify the | [RFC7181] |
| | | originating router's | |
| | | willingness to act as a | |
| | | flooding MPR; bits 4-7 | |
| | | specify the originating | |
| | | router's willingness to act | |
| | | as a routing MPR | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC7181] |
| | | Use | |
+-----------+-------------+-----------------------------+-----------+

The IANA Registry "CONT_SEQ_NUM Message Type Extensions" is renamed as "Type 8 Message TLV Type Extensions" and changed as follows:

+-----------+--------------+----------------------------+-----------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+--------------+----------------------------+-----------+
| 0 | CONT_SEQ_NUM | Specifies a content | [RFC7181] |
| | (COMPLETE) | sequence number for this | |
| | | complete message | |
| 1 | CONT_SEQ_NUM | Specifies a content | [RFC7181] |
| | (INCOMPLETE) | sequence number for this | |
| | | incomplete message | |
| 2-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC7181] |
| | | Use | |
+-----------+--------------+----------------------------+-----------+

Seventh, the Address Block TLV Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located in:

http://www.iana.org/assignments/manet-parameters/

is to be replace with the following:

+---------+-------------------------------+-----------+
| Type | Description | Reference |
+---------+-------------------------------+-----------+
| 0 | Defined by Type Extension | [RFC5497] |
| 1 | Defined by Type Extension | [RFC5497] |
| 2 | Defined by Type Extension | [RFC6130] |
| 3 | Defined by Type Extension | [RFC6130] |
| 4 | Defined by Type Extension | [RFC6130] |
| 5 | ICV | [RFC7182] |
| 6 | TIMESTAMP | [RFC7182] |
| 7 | LINK_METRIC | [RFC7181] |
| 8 | Defined by Type Extension | [RFC7181] |
| 9 | Defined by Type Extension | [RFC7181] |
| 10 | Defined by Type Extension | [RFC7181] |
| 11-223 | Unassigned | |
| 224-255 | Reserved for Experimental Use | [RFC5444] |
+---------+-------------------------------+-----------+

Eighth, another set of existing registries in:

http://www.iana.org/assignments/manet-parameters/

are to be modified as follows:

The IANA Registry "INTERVAL_TIME Address Block TLV Type Extensions" is renamed as "Type 0 Address Block TLV Type Extensions" and changed as follows:

+-----------+---------------+---------------------------+-----------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+---------------+---------------------------+-----------+
| 0 | INTERVAL_TIME | The maximum time before | [RFC5497] |
| | | another message of the | |
| | | same type as this message | |
| | | from the same originator | |
| | | and containing this | |
| | | address should be | |
| | | received | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC5497] |
| | | Use | |
+-----------+---------------+---------------------------+-----------+

The IANA Registry "VALIDITY_TIME Address Block Type Extensions" is renamed as "Type 1 Address Block TLV Type Extensions" and changed as follows:

+-----------+---------------+---------------------------+-----------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+---------------+---------------------------+-----------+
| 0 | VALIDITY_TIME | The time from receipt of | [RFC5497] |
| | | the address during which | |
| | | the information regarding | |
| | | this address is to be | |
| | | considered valid | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC5497] |
| | | Use | |
+-----------+---------------+---------------------------+-----------+

The IANA Registry "LOCAL_IF Address Block Type Extensions" is renamed as "Type 2 Address Block TLV Type Extensions" and changed as follows:

+-----------+----------+-----------------------+--------------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+----------+-----------------------+--------------------+
| 0 | LOCAL_IF | This value is to be | [RFC7188][RFC6130] |
| | | interpreted according | |
| | | to the registry | |
| | | [LOCAL_IF TLV Values] | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC6130] |
| | | Experimental Use | |
+-----------+----------+-----------------------+--------------------+

The IANA Registry "LINK_STATUS Address Block Type Extensions" is renamed as "Type 3 Address Block TLV Type Extensions" and changed as follows:

+-----------+-------------+--------------------+--------------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+-------------+--------------------+--------------------+
| 0 | LINK_STATUS | This value is to | [RFC7188][RFC6130] |
| | | be interpreted | |
| | | according to the | |
| | | registry | |
| | | [LINK_STATUS TLV | |
| | | Values] | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC6130] |
| | | Experimental Use | |
+-----------+-------------+--------------------+--------------------+

The IANA Registry "OTHER_NEIGHB Address Block Type Extensions" is renamed as "Type 4 Address Block TLV Type Extensions" and changed as follows:

+-----------+--------------+-------------------+--------------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+--------------+-------------------+--------------------+
| 0 | OTHER_NEIGHB | This value is to | [RFC7188][RFC6130] |
| | | be interpreted | |
| | | according to the | |
| | | registry | |
| | | [OTHER_NEIGHB TLV | |
| | | Values] | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC6130] |
| | | Experimental Use | |
+-----------+--------------+-------------------+--------------------+


Ninth, the document suggests in section 3.1 that, "For Address Block TLV Types, that the Type Extension registry, created for the TLV Type, be named "Type XX Address Block TLV Type Extensions", with XX replaced by the numerical value of the TLV Type." Yet, IANA notes in Section 3.2 the following request:

"The IANA Registry "ICV Address Block TLV Type Extensions" is unchanged.

The IANA Registry "TIMESTAMP Address Block TLV Type Extensions" is unchanged.

The IANA Registry "LINK_METRIC Address Block TLV Type Extensions" is unchanged."

IANA Question --> Are these three registries being singled out for special behavior or treatment?

Tenth, another set of existing registries in:

http://www.iana.org/assignments/manet-parameters/

are to be modified as follows:

The IANA Registry "MPR Address Block Type Extensions" is renamed as "Type 8 Address Block TLV Type Extensions" and changed as follows:

+-----------+------+---------------------------+--------------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+------+---------------------------+--------------------+
| 0 | MPR | This value is to be | [RFC7188][RFC7181] |
| | | interpreted according to | |
| | | the registry [MPR TLV Bit | |
| | | Values] | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [ RFC-to-be ] |
| | | Use | |
+-----------+------+---------------------------+--------------------+

The IANA Registry "NBR_ADDR_TYPES Address Block Type Extensions" is renamed as "Type 9 Address Block TLV Type Extensions" and changed as follows:

+-----------+----------------+-----------------+--------------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+----------------+-----------------+--------------------+
| 0 | NBR_ADDR_TYPES | This value is | [RFC7188][RFC7181] |
| | | to be | |
| | | interpreted | |
| | | according to | |
| | | the registry | |
| | | [NBR_ADDR_TYPE | |
| | | Address Block | |
| | | TLV Bit Values] | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for | [ RFC-to-be ] |
| | | Experimental | |
| | | Use | |
+-----------+----------------+-----------------+--------------------+

The IANA Registry "GATEWAY Address Block Type Extensions" is renamed as "Type 10 Address Block TLV Type Extensions" and changed as follows:

+-----------+---------+------------------------+--------------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+---------+------------------------+--------------------+
| 0 | GATEWAY | Specifies that a given | [RFC7188][RFC7181] |
| | | network address is | |
| | | reached via a gateway | |
| | | on the originating | |
| | | router, with value | |
| | | equal to the number of | |
| | | hops | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for | [ RFC-to-be ] |
| | | Experimental Use | |
+-----------+---------+------------------------+--------------------+

Eleventh, this document will be added to all impacted sub-registries as the additional
source of references.

IANA understands that these eleven actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TLV Naming in the MANET Generalized Packet/Message Format) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'TLV Naming in the MANET Generalized Packet/Message Format'
  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@ietf.org mailing lists by 2015-05-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  TLVs (type-length-value structures) as defined by RFC5444 have both a
  type (one octet) and a type extension (one octet), together forming a
  full type (of two octets).  RFC5444 sets up IANA registries for TLV
  types, specifying that an allocation of a TLV type entails creation
  of an IANA registry for the corresponding type extensions.

  In some cases, reserving all 256 type extensions for use for a common
  purpose for a given TLV is meaningful, and thus it makes sense to
  record a common name for such a TLV type (and all of its type
  extensions) in the corresponding IANA registries.  An example of such
  is a LINK_METRIC TLV Type, with its type extensions reserved for use
  to be indicating the "kind" of metric expressed by the value of the
  TLV.

  In some other cases, there may not be 256 full types that share a
  common purpose and, as such, it is not meaningful to record a common
  name for all the type extensions for a TLV type in the corresponding
  IANA registries.  Rather, it is appropriate to record an individual
  name per full type.

  This document reorganizes the naming of already allocated TLV types
  and type extensions in those registries to use names appropriately.
  It has no consequences in terms of any protocol implementation.

  This document also updates the Expert Review guidelines from RFC5444,
  so as to establish a policy for consistent naming of future TLV type
  and type extension allocations.  It makes no other changes to
  RFC5444.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

A Standards Track RFC is requested.  This document makes changes, primarily of names, to IANA registries specified by Proposed Standard RFCs. Registry assignment for future requests is also changed from current practice to align with the change in naming.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary: This document renames and makes minor changes to some IANA registries that derive from RFC 5444. During progress of another draft (draft-ietf-manet-olsrv2-multitopology) issues with current registry naming practices were illustrated; specifically having different names for different TLV type extensions was not allowed.  If this naming was enforced certain TLV types would share a "name" but otherwise be completely divergent in meaning.  This draft reorganizes the registry naming rules and does not change any protocol functionality.

Working Group Summary: This was regarded as a technical change, requested by the AD. There was no particular interest in the draft (for or against), beyond being necessary to progress draft (draft-ietf-manet-olsrv2-multitopology).

Document Quality: The document clearly states it's purpose, to change naming of IANA registries for future assignments and to provide new versions of IANA registries to reflect these rules.  It does this clearly and with detail.

Personnel:

Justin Dean (jdean@itd.nrl.navy.mil) is the document shepherd for this document. 
Adrian Farrel (adrian@olddog.co.uk) is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has personally reviewed the document for quality and for correctness in proposed IANA registry changes.  He believes it is ready for forwarding to the IESG for publication.  While the document only changes naming of registries this change is warranted as the current rule set is needlessly confusing to the point of being broken.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document has had limited reviews, but has a very limited impact (none on protocol operation).  A triple check that all of the appropriate currently assigned IANA registries have been addressed by this draft with updated naming would be helpful.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It's the Shepherd's opinion that no further reviews are required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Working group consensus is mostly silent with most support coming from informed individuals.  The WG understands the changes this document affects and as a whole agree that they are necessary and correct. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.


(13) Have all references within this document been identified as
either normative or informative?

The document has only normative references.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document updates the Expert Review guidelines from RFC5444 to reflect the naming changes.  This is listed in the introduction.  This document also appropriately renames IANA registry "Mobile Ad hoc NETwork (MANET) Parameters" assignments from RFC5497, RFC6130, RFC7181, RFC7182, and RFC7188.  Only names are changed, numbers assigned, their meaning and protocol functioning is not.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document is essentially only an IANA consideration section, plus rationale. It describes in detail the required changes for each registry name change along with detailed listing of reference document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new IANA registries, just renaming and changes to of existing "Mobile Ad hoc NETwork (MANET) Parameters" registries derived from RFC5444.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There are no sections of the document written in a formal style.