Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
RFC 7188

[Ballot discuss]
I have no objection to the publication of this document, but I have two points that need discussing.  These should be easily addressed.

1. Section 4 has the following text: "This specification describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] SHOULD handle TLVs with other TLV Value fields." I am not sure why there is a "SHOULD" here.  *If* there was a need for a 2119 keyword, I believe a "MUST" is in order.  However, I don't think a 2119 keyword is needed at all.  I suggest replacing that sentence with: "This specification describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] handle TLVs with other TLV Value fields."

2. In Section 4.3.1, the text talks about creating an IANA registries to manage the allowed values in the various TLVs.  The second paragraph then says "An implementation of [RFC6130], receiving a TLV with any TLV Value other than those values used in that specification, MUST ignore that TLV Value and any corresponding attribute association to the address." Shouldn't the guidance be that values not in the *registry* are ignored?

[Ballot discuss]
Very easy-to-fix DISCUSS:
- section 4.1

  An implementation MUST NOT reject a message because it contains
  such a TLV.

"such a TLV" is described in the intro text of section 4.1
This sentence is key: this is THE specification, as it contains a MUST, and therefore must be self-contained.
Please make clear. For example:

  An implementation MUST NOT reject a message because it contains
  a unrecognized TLV value.

[Ballot comment]
  This document updates the specification of the protocols [OLSRv2] and
  [RFC6130].  As such it is applicable to all implementations of these
  protocols.
What does the second sentence add? Isn't it obvious if this document updates [OLSRv2] and
[RFC6130]? Maybe I'm missing a subtle concept?

[Ballot comment]

- I have to say that I found this pretty hard to comprehend
(whilst speed reading mind you;-). That's probably just me,
but I do wonder if others who aren't involved in the WG have
found the same or not.

- table 4, values 1 and 2 have the same text - seems odd

[Ballot discuss]
-- Section 5.1 --

The descriptions of Tables 4 and 5 have some similar wording, which I can't make sense out of:

  For all
  future allocations, the Expert Review MUST ensure that allocated bits
  MUST use the unset bit (0) to indicates no information, so that the
  case Value = 0 will always indicate that no information about this
  network address is provided.

Can you explain what this means, and perhaps come up with clearer wording?  I honestly have no idea what you're trying to say, and as it's a "MUST", that seems important.

IESG/Authors/WG Chairs:

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

IANA has questions for all actions requested in the IANA Considerations section of this document.  Further it appears that this document
is updating some new created registries as per draft-ietf-manet-olsrv2-19
which is in a state called "AUTH" according to the tracker. 

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

Upon approval of this document, IANA understands that there are five actions which IANA must complete.

First, section 5.1 of the document requests IANA to "create" a registry associated with the AddressBlock TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined in [RFC6130].  However, there already is such a registry located at:

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

IANA Questions --> Do the authors intend that the table (Table 1) provided in section 5.1 of the document REPLACE the existing LOCAL_IF Address Block TLV Type Extensions?  Should the text "IANA is requested to create
a registry" be changed to "replace" the registry?  Should the reference be updated to [ RFC-to-be ], left as [RFC6130], or both since this document
only updates RFC6130?  Should the spec "Type = 2, Type Extension = 0"
be added to the name of this sub-registry, two columns as depicted
in Table 6 in RFC6130, a note somewhere in the registry?  Or do nothing?

Second, also in section 5.1 of the document, there is a request for IANA to create a registry associated with the Address Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0) defined in [RFC6130].  Once again, there already is such a registry located at:

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

IANA Questions --> Do the authors intend that the table (Table 2) provided in section 5.1 of the document REPLACE the existing LINK_STATUS Address Block TLV Type Extensions?  Again, should the text "IANA is requested to create
a registry" be changed to "replace" the registry?  Should the reference be updated to [ RFC-to-be ], left as [RFC6130], or both since this
document only updates RFC6130?  Should the spec "Type = 3, Type
Extension = 0" be added to the name of this sub-registry,
two columns as depicted in Table 7 in RFC6130, a note somewhere in
the registry?  Or do nothing?

Third, again in section 5.1 of the document, there is a request for IANA to create a registry associated with the Address Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0) defined in [RFC6130].  Once again, there already is such a registry located at:

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

Same Questions --> Do the authors intend that the table (Table 3) provided in section 5.1 of the document REPLACE the existing OTHER_NEIGHB Address Block TLV Type Extensions?  Should the text "IANA is requested to create
a registry" be changed to "replace" the registry?  Should
the reference be updated to [ RFC-to-be ], left as [RFC6130], or
both since this document only updates RFC6130?  Should the spec
"Type = 4, Type Extension = 0" be added to the name of this sub-registry,
two columns as depicted in Table 8 in RFC6130, a note somewhere in
the registry? or do nothing?

Fourth, again in section 5.1 of the document, there is a request for IANA to create a registry associated with the Address Block TLV with name MPR (Type = 8, Type Extension = 0) defined in draft-ietf-manet-olsrv2-19.  As before, there already is such a registry located at:

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

IANA Questions --> Do the authors intend that the table (Table 4) provided in section 5.1 of the document REPLACE the existing MPR Address Block TLV Type Extensions?  More importantly, this sub-registry is created by
RFC-ietf-manet-olsrv2-19 which is in a state called "AUTH" according
to the tracker.  Are the authors intended to update the action
(Table 14) for RFC-ietf-manet-olsrv2-19? Or errata is intended? 

Again, the authors use the text "IANA is requested to create
a registry".  Is this new created sub-registry not the same one
called "MPR Address Block TLV Type Extensions" located at
http://www.iana.org/assignments/manet-parameters?  Then, should
the reference be updated to [ RFC-to-be ], left as [RFC-ietf-manet-olsrv2-19], or both since this document also updates [RFC-ietf-manet-olsrv2-19]?  Should the spec "Type = 8, Type Extension = 0" be added
to the name of this sub-registry, two columns as depicted in
Table 14 in draft-ietf-manet-olsrv2-19, a note somewhere in
the registry? or do nothing?

Fifth, again in section 5.1 of the document, there is a request for IANA to create a registry associated with the Address Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0) defined in draft-ietf-manet-olsrv2-19.  As before, there already is such a registry located at:

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

Same Quetions --> Do the authors intend that the table (Table 5) provided in section 5.1 of the document REPLACE the existing NBR_ADDR_TYPE Address Block TLV Type Extensions?  Again, this sub-registry is created by
RFC-ietf-manet-olsrv2-19 which is in "AUTH" according to the tracker. 
Are the authors intended to update the action (Table 15) for
RFC-ietf-manet-olsrv2-19?

Again, the authors use the text "IANA are requested to create
a registry".  Should "REPLACE" be used?  Should the reference be
updated to [ RFC-to-be ], left as [RFC-ietf-manet-olsrv2-19], or
both since this document also updates [RFC-ietf-manet-olsrv2-19]? 
Should the spec "Type = 9, Type Extension = 0" be added
to the name of this sub-registry, two columns as depicted in
Table 14 in draft-ietf-manet-olsrv2-19, a note somewhere in
the registry? or do nothing?

IANA understands that, in all five of these cases the registry that
is either created or replaced is to be managed via Expert Review as
defined in RFC 5226.

IANA also understands that, upon approval of this document, these
five actions are the only ones that need to be completed.

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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET
  Neighborhood Discovery Protocol (NHDP) Extension TLVs'
  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 2014-02-07. 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

  This specification describes extensions to definitions of TLVs used
  by the Optimized Link State Routing Protocol version 2 (OLSRv2) and
  the MANET Neighborhood Discovery Protocol (NHDP), to increase their
  abilities to accommodate protocol extensions.  This document updates
  OLSRv2 and RFC6130.


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

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


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

Hi,

Nice neat document. Thanks for the work.

I have a few comments. We could run these through as IETF last call
comments, but on balance I think it would be best to clean up at
least the IANA section comments before last call so that IANA gets an
unobstructed run at the text.  Anyway, knowing the authors, I suspect
they would like to tidy the document at this stage.

Let me know if I am wrong in my assumption or my comments.

Thanks,

Adrian

===

It might be useful to discuss backward compatibility very briefly in
Section 3.  The point being that it does not matter that existing
implementations and deployments do not include these extensions because
they will only be used for new protocol features that are, themselves,
not supported by those legacy implementations.  Thus, if a new
implementation attempts a TLV as described in this document, it will
not be a problem that a legacy implementation rejects it as badly
formed.

Conversely, a new implementation must still be able to cope (technically
and emotionally) with a legacy implementation that rejects a message as
badly formed.

---

Section 4.2

had some parsing problems with the first paragraph. Would this work?

OLD
  The TLVs specified in [RFC6130] and [OLSRv2] may be either single-
  value or multi-value TLVs.  In either case, the length of the
  information encoded in the TLV Value field is the "single-length",
  defined and calculated as in section 5.4.1 in [RFC5444].  All TLVs
  specified in [RFC6130] and [OLSRv2] describe TLVs with one or two
  octet TLV Value field single-length.  These are considered the
  expected values of single-length for a received TLV.
NEW
  The TLVs specified in [RFC6130] and [OLSRv2] may be either single-
  value or multi-value TLVs.  In either case, the length of the
  information encoded in the TLV Value field is the "single-length",
  defined and calculated as in section 5.4.1 in [RFC5444].  All TLVs
  specified in [RFC6130] and [OLSRv2] have a one or two octet TLV Value
  field and have a "single-length".  These are considered the expected
  values of the TLV Length field for a received TLV.
END

---

Section 4.2

  o  A received CONT_SEQ_NUM with a single-length < 2 SHOULD be
      considered an error.

I expect that the "SHOULD" is because you think there is a possibility
that a future reason might be found, but:
- is that likely
- if you do a "SHOULD" you really ought to supply a corresponding "MAY".

I suspect you could safely change this to "MUST" and let a future RFC
handle the exception if necessary.

---

4.3.2

  As the existing definitions
  of values 1, 2, and 3 behave in that manner, it is likely that this
  will involve no change to an implementation, but any test of (for
  example) Value = 1 or Value = 3 MUST be converted to a test of (for
  example) Value bitand 1 = 1, where "bitand" denotes a bitwise and
  operation.

I prefer not to use 2119 language to describe the inner workings of an
implementation. Enough, I think, to say "will need to be..."

---

4.3.3

I am similarly uneasy with the 2119 language in this section that seems
to be constraining what goes in the relevant registry.  Since this
document defines the registry, I think you can just use normal English.

---

Section 5.1

It will help IANA if you:
1. Say what the parent registry is
2. Give a name for each registry you are asking them to create

---

Section 5.1

  This
  replaces the Description column in Table 6 in [RFC6130] by a
  reference to this table.

It is pedantic, but Section 5 should be restricted to direct
instructions to IANA and not include anything else.  Thus this text
needs to be in a separate section (such as "Changes to RFC 6130") that
makes this statement.

Similarly for the other tables and other descriptive text in this
section (such as that after Tables 4 and 5).

---

Section 5.1 Table 4

It is probably sad (and at least amusing) that I puzzled over the
"value" column. How, I wondered, can bit 6 take the value 2?

I don't think there is anything to do here. Some registries use hex,
but the effect is the same. Some registries leave out this column.

(1) The request is to publish this document as a Standards Track RFC,
and this is indicated in the document header.

The Optimized Link State Routing Protocol version 2 (OLSRv2) has been published as Standards Track. This extension updates the OLSRv2 RFC by defining extensions to definitions of TLVs used by OLSRv2 and the MANET Neighborhood Discovery Protocol (NHDP), to increase their abilities to accommodate protocol extensions.

(2) Document Announcement Write-Up.

Technical Summary

The abstract of this document is included below.

This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP), to increase their abilities to accommodate protocol extensions.  This document updates OLSRv2 and RFC6130.


Working Group Summary

There was consensus to publish the document.


Document Quality

There is a number of independent implementations this extension to OLSRv2. Those
listed below have, explicitly, consented to be nominatively mentioned:

o Ecole Polytechnique, France
  (Contact: Thomas Clausen)

o BAE Systems Advanced Technology Centre, UK
  (Contact Christopher Dearlove)



Personnel

The Document Shepherd is Ulrich Herberg (ulrich@herberg.name); the
responsible Area Directors are Adrian Farrel and Stewart Bryant.

(3) The document Shepherd has participated in review both in the Working
Group, and has run the "idnits" tool against the draft.

(4) The Document Shepherd has no concerns about the reviews of the
document; they have been thorough.

(5) The authors do not believe that additional reviews are required,
aside from the usual directorate reviews during IETF last call.

(6) The Document Shepherd has no concerns with the document.

(7) All authors have confirmed that they are unaware of any IPR needing
disclosure; there are no known IPR claims related to this document.

(8) No IPR disclosures have been filed, as none are required.

(9) WG consensus appears to be strong.

(10) Nobody has threatened an appeal or otherwise indicated extreme discontent.

(11) Some ID nits were found, and should be addressed by the authors in the next revision. This can be done along with addressing other potential comments during IETF LC.

(12) Mib Doctor, media type, and URI reviews are not required.

(13) All references have been defined as either normative or
informative.

(14) No normative references exist to documents not ready for
advancement. Of the normative references, OLSRv2 is not yet an RFC, but has been approved for publication and is in the RFC editor queue.

(15) There are no normative downward references.

(16) Publication of this document will update OLSRv2 (no RFC number assigned yet) and RFC6130. The two references are listed on the title page header, listed in the abstract, and discussed in the introduction.

(17) The Document Shepherd has reviewed the IANA considerations section
of the document, and it appears wholly consistent with the body of said
document. Extensions are associated with the appropriate reservations in
IANA registries. All IANA registries have been clearly defined.

(18) Impact on IANA registries :

There are several new registries:
- a registry associated with the Address Block TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined
in [RFC6130], specifying the meaning of its single values.  This replaces the Description column in Table 6 in [RFC6130] by a reference to this table.
- a registry associated with the Address Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0)  defined in [RFC6130], specifying the meaning of its single values. This replaces the Description column in Table 7 in [RFC6130] by a reference to this table.
- a registry associated with the Address Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0)
defined in [RFC6130], specifying the meaning of its single values. This replaces the Description column in Table 8 in [RFC6130] by a reference to this table.
- a registry associated with the Address Block TLV with name MPR (Type = 8, Type Extension = 0) defined in  [OLSRv2], specifying the meaning of its single values in terms of the values of each bit of the value, from bit 0 (most significant) to bit 7 (least significant).  If multiple bits are set then each applies. This replaces the Description column in Table 14 in [OLSRv2] by a reference to this table.
- a registry associated with the Address Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0)
defined in [OLSRv2], specifying the meaning of its single values in terms of the values of each bit of the value, from bit 0 (most significant) to bit 7 (least significant).  If multiple bits are set then each applies.  This replaces the Description column in Table 15 in [OLSRv2] by a reference to this table.

IANA Experts should be chosen amongst candidates with thorough knowledge of the existing NHDP and OLSRv2 registries. The experts for these existing tables are the MANET WG chairs; the shepherd recommends to select the WG chairs as IANA Experts for these new registries as well.


(19) The Document Shepherd has run the idnits tool against the document; two remaining warnings will be resolved in a new revision to be submitted by the authors after the IETF LC.