Subject: [manet] AD review of draft-ietf-manet-nhdp-olsrv2-tlv-extension

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Jan 2014 22:12:59 -0000

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.