Subject: [manet] Ben Campbell's No Objection on draft-ietf-manet-rfc5444-usage-06: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 04 Jul 2017 09:36:02 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-manet-rfc5444-usage-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

[The first comment is from my original DISCUSS position. I've cleared, because
I think conversation is moving enough in the right direction that I expect
people will "do the right thing". But I'm maintaining this as a comment because
I still think it's awkward to use 2119 keywords to describe some future
requirement, unless doing so as a direct "pre-quote". ]

<old-discuss>
-4.5, 2nd to last paragraph: The first sentence makes ambiguous use of 2119
keywords. Saying that it is RECOMMENDED that something MAY be defined reduces
to just MAY, which I don't think is what you want. Also, "only one" is
ambiguous, in that it can mean "exactly one" or "at most one". Does the
following capture the intent?

OLD:
   It is RECOMMENDED that a TLV Full Type MAY be defined so that there
   MUST only be one TLV of that Full Type associated with the packet
   (Packet TLV), message (Message TLV), or any value of any address
   (Address Block TLV).
NEW:
  If a TLV Full Type is defined, it SHOULD be defined such that at most one
  TLV of that Full Type can be associated with a given packet, message, or
  address block TLV.

</old-discuss>

- General: I find it confusing that this document combines normative updates to
RFC 5444 in the form of multiplexer rules with a bunch of rules for designing
extension protocols. The former seems perfectly reasonable in a standards track
document, but the latter really seems like BCP material. I don't expect this to
change this late in the process, but I'd encourage people to consider
separating that sort of thing in future work.

- 4.2,
-- 4th bullet: I don't agree that the requirement for the demuxer to remove
TLVs added by the muxer is an implementation detail. -- 6th bullet: "... this
processing will determine that the message MUST be ignored." That seems like a
statement of fact.

- Appendix B: The appendix contains 2119 keywords. If there are really
normative requirements, please consider promoting it to the main body of the
draft. Lots of readers will skip the appendixes.

Nits:

- General:
-- The draft has quite a bit of text that summarized content from other drafts.
A little of that can be useful but too much just adds unnecessary length.  I
suggest editing for conciseness. -- Please don't use "/" to substitute for
conjunctions.

-1, 2nd paragraph: I can't parse the first sentence. Does the following make
sense:

OLD:
   [RFC5444] was designed following experiences with [RFC3626], which
   attempted, but did not quite succeed in, providing a packet/message
   format accommodating for diverse protocol extensions.
NEW:
   [RFC5444] was designed following experiences with [RFC3626], which
   attempted, but did not quite succeed, in providing a packet and message
   format that accommodates diverse protocol extensions.

-1, third paragraph, last sentence:
It's not clear to me whether this means protocol and port numbers that were
allocated by 5498, allocated after 5498, or allocated following the rules in
5498.

-1.1, first paragraph: Why the scare quotes around "forward compatibility"?

-2: You include the 2119 boilerplate, but much of this draft uses those terms
in ways that are different than intended by 2119.  For example, using MUST,
SHOULD, etc to put requirements on how people design new protocols. I don't
object to using the language that way, but it would be good to clarify the
intent in section 2.

-3, first paragraph: s/"that are using"/"that use"

-4.3, 2nd paragraph: I'm a little confused by "MUST be recognized...". Does
"recognized" in this context mean the same as "identified"? If so, I suggest
using the latter. Also, that MUST seems like a statement of fact.

- 6.2: Does this mean to talk about attributes and addresses in the _same_
address block, rather than just attributes and addresses in an address block?

- 6.3
-- 3rd paragraph: s/"RFC7188] required" / RFC7188] requires"   ; unless it no
longer requires it. -- 5th paragraph: RFC7188] RECOMMENDS seems like a
statement of fact. (Please don't use 2119 keywords to describe requirements
that are defined elsewhere, unless in a direct quote.)

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 10 Jul 2017 15:09:33 +0200

> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/

I agree

>   TLV of that Full Type can be associated with a given packet, message, or

Ok

> separating that sort of thing in future work.

I agree with this

>    format that accommodates diverse protocol extensions.

I suggest we delete this word 'succeeded', because 5444 needs to be
flexible to be used and updated (it succeeded so far). So maybe we change
word 'succeed' to 'flexible',