Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana Yes

(Alia Atlas) No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2017-07-04 for -06)
No email
send info
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". ]

-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?

   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).
  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.


- 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. 


- 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:

   [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. 
   [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.)

(Benoît Claise) No Objection

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-07-05 for -06)
No email
send info
I support Ben's non-DISCUSS.
The RFC2119 language usage feels odd, I think that people will do the right thing.

Section 1.3 (Status of this document) and Section 2 (Terminology) are on page 7 - this is about a 3rd of the way through the document -- the into and history are useful and interesting, but I feel it might be nice to re-order the sections so that the status and terminology are higher (esp. the Status bit). 
I've balloted No Objection, so feel free to ignore this :-)

I have a minor nit,  you might want to fix if if doing any other edits:

Section 1.2.1 - Packet / Message Format
O: "... a packet transmission following a successful packet reception is by design of a new packet that may include all, some, or none..."
P: "... a packet transmission following a successful packet reception is by design a new packet that may include all, some, or none..."
C: Removed the extra "of"

(Mirja Kühlewind) No Objection

Comment (2017-07-01 for -06)
No email
send info
One question:
I’m wondering why the following is not a MUST. Can you maybe provide more information in the draft when modification might be okay?
„It is strongly RECOMMENDED that messages are not modified in the
      latter case, other than updates to their hop count and hop limit

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Eric Rescorla) No Objection

(Adam Roach) No Objection

Comment (2017-07-05 for -06)
No email
send info
Please expand "MANET" upon first use; see for guidance.