Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444
draft-ietf-manet-rfc5444-usage-07

[Ballot comment]
I support Ben's non-DISCUSS.
The RFC2119 language usage feels odd, I think that people will do the right thing.

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

[Ballot 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". ]


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





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

[Ballot 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". ]

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



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

[Ballot discuss]
I have one discuss point that I hope will be easy to fix.

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

[Ballot comment]
Substantive Comments:

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

[Ballot comment]
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
      fields“

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

The IANA Services Operator has reviewed draft-ietf-manet-rfc5444-usage-06.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: manet-chairs@ietf.org, draft-ietf-manet-rfc5444-usage@ietf.org, manet@ietf.org, bebemaster@gmail.com, aretana@cisco.com, Justin Dean
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Rules for Designing Protocols Using the RFC 5444 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: - 'Rules for Designing Protocols Using the
RFC 5444 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 2017-06-29. 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


  RFC 5444 specifies a generalized MANET packet/message format and
  describes an intended use for multiplexed MANET routing protocol
  messages that is mandated to use on the port/protocol specified by
  RFC 5498.  This document updates RFC 5444 by providing rules and
  recommendations for how the multiplexer operates and how protocols
  can use the packet/message format.  In particular, the mandatory
  rules prohibit a number of uses that have been suggested in various
  proposals, and which would have led to interoperability problems, to
  the impediment of protocol extension development, and to an inability
  to use optional generic parsers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ballot/


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

Made significant progress on the latest version.  We need to get the Expert Review guidelines in the IANA Considerations section so we can get WG feedback and start the IETF Last Call.

=== AD Review of draft-ietf-manet-rfc5444-usage-04 ===

Hi!

I just finished reading this document.  I have several significant concerns and a lot of comments.  While my comments are mostly directed at the authors, I expect the WG Chairs to help provide more context (specifically when related to WG decisions/consensus) as needed.

A significant concern is (in some cases) the absolute rules when "one size rarely fits all".  At this point in the process I have to assume that WG consensus exists — the shepherd writeup supports that and just mentions "minor disagreements".  In some of my comments I do ask questions related to the decisions — pointing to a discussion on the list should be enough.  I think that the document would benefit from including an explanation of the considerations or examples of how things can go wrong if the recommendations are not followed -- maybe even in an Appendix (but I'll leave that decision to the authors/shepherd).  Section 4.4 is a good example (see some comments below).

I consider most of the comments Major, in most cases due to the use of normative language.  I find that some of the normative language is really hard to enforce (which is important since this document is in the Standards Track), and wonder whether some of the recommendations should become part of the DE evaluation guidelines instead. 

Except where I saw an overarching topic, I have ordered my comments by section.

Thanks!

Alvaro.



c1. The Multiplexer.  When I read rfc5444, my impression is that the description of the multiplexer/demultiplexer is non-normative: not only is it in an Appendix, but it is never mentioned/referenced in the text, and it seems to me like an implementation choice — those facts alone are not enough to make a conclusion on the normative status, but it caught my attention that starting with the Abstract the document makes the point to mention that rfc5444 is "mandated for use by RFC5498".  I thought that sounded a little weird, after all rfc5444 is where the packet format is specified.  I think that the sentence from rfc5498 that applies here is "All interoperable protocols running on these well-known IANA allocations MUST conform to [RFC5444].", which means that rfc5498 mandates the use of rfc5444, but only if a protocol uses the well-known numbers — that's it.  There's no mention in rfc5498 of multiplexing, Appendix A, or anything else related.  While it is not an unreasonable stretch to say that rfc5498 mandates Appendix A (and every other section) in rfc5444, I don't think it is completely factually correct.  This is a point where I would like to hear from the WG Chairs as to whether the WG considers the mux/demux as normative or not and whether a discussion about this topic has taken place or not.

c1.1 I would like to see the following changes related to the references to rfc5498:

c1.1.1 I don't think the references in the Abstract and Section 1.2 are needed.

c.1.1.2. Introduction:
OLD>
  [RFC5498] mandates the use of this packet/message format, and of the
  packet multiplexing process described in an Appendix to [RFC5444], by
  protocols operating over the manet IP protocol and port numbers that
  were allocated following [RFC5498].
NEW>
  [RFC5498] mandates the use of this packet/message format by
  protocols operating over the manet IP protocol and port numbers that
  were allocated there.

c1.2. The reference to rfc5498 should be Normative.



c2. Extensibility. 

c2.1. To extend…  In the rules in Section 4.4. (Addresses Require Attributes): "A protocol MUST NOT reject a message based on the inclusion of an unrecognized Value in a TLV of a recognized type.  The protocol MUST ignore any such Values when processing the message…[further down]…Rejecting a message because it contains an unrecognized TLV Type, or an unrecognized TLV Value, reduces the extensibility of the protocol."  Comments/questions:

c2.1.1. I understand the extensibility point.  However, I can think of multiple cases where it may be desired for a protocol to in fact react to unrecognized values.  For example, a TLV may be defined where the valid values are explicitly defined and anything else would be an error — ignoring the values may result in the protocol ending up in an unknown state.  As I think of these cases, I'm walking a fine line between unrecognized (which is probably the same as unknown) and undefined.  Part of that fine line represents the ability of a protocol to define values that are known and expected while allowing for future extensibility and being able to recognize cases where the sender is just wrong.

c2.1.2. Section 4.7. (Message Integrity) generalizes the rule in 4.4: "In addition to not rejecting a message due to unknown TLVs or TLV Values, a protocol MUST NOT fail to forward a message…and MUST NOT remove suchTLVs or TLV Values."  The normative language is not quite the same, but the meaning is.

c2.1.3. Also in 4.7: "If an incompatible protocol extension were defined, it would the responsibility of network management to ensure that incompatible routers were not both present in the MANET; this case is NOT RECOMMENDED."  An incompatible protocol extension seems to reflect my concern above.  The problem I still have is that the text says "NOT RECOMMENDED", vs all the "MUST/MUST NOTs" used before, which amounts to it being ok to have an incompatible extension in the network sometimes. 

c2.1.4. Solution

c2.1.4.1 Solution (Part 1): Given that an incompatible protocol extension can in fact be defined, I don't think you can specify an absolute requirement (MUST/MUST NOT).

c2.1.4.2. Solution (Part 2): explain when it is ok to have an incompatible protocol extension in the network, AND, please provide suggestions as to how network management can detect them (and fulfill its responsibility).


c2.2. …or not to extend.  In Section 5. (Structure) the opposite argument to extensibility seems to be made.  Even though RFC5444 does say that unknown flags "SHOULD be ignored on reception" (which basically allows for the extensibility argued for in 4.7), this section prohibits any extension by mandating a new version.  Questions/comments:

c2.2.1. Why the change?  Previous sections argued for accepting unknown TLVs and even Values.

c2.2.2. Is your intent to Update the parts of RFC5444 that say "SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception" to use "MUST" instead?  Note that the fact that the bits are Reserved doesn't preclude a future change.

c2.2.3. "An update that would be incompatible with the current specification of [RFC5444] SHOULD NOT be created…"  This piece of text is in conflict with the MUSTs used to mandate a new version.

c2.2.4. [minor] "The later addition of a 4 bit Message Address Length field later left no unused message flags bits, but other fields still have unused bits."  It really wasn't later, that field is specified in RFC5444.  If you want to include an example, maybe use one that doesn't include the message flag bits (as all are assigned).  Also, the text in this section needs to be clarified to not include the message flag bits.



c3. At this point in the process we don't need Section 1.3. (Status of This Document).



c4. Section 3. (Applicability Statement) says that "the constraints in this document apply to all protocols running over the manet protocol and port."  What about protocols that don't run over the ports, but use rfc5444?  I'm not only thinking about non-maned protocols that could reuse rfc5444, but also about the potential for a manet protocol that doesn't run over the ports.  Why would this document not apply in those cases?  The use of the multiplexer is probably obvious (why it doesn't apply), but this documents covers other things as well.



c5. Section 4.1. (Where to Record Information)

c5.1. "The second case (in a message of a type owned by another protocol) is only possible if the adding protocol is an extension to the owning protocol…  While this is not the most common case, protocols SHOULD be designed to enable this to be possible, and some of the rules in this document are to help facilitate that."  Questions/comments:

c5.1.1. [minor] What does "this" refer to?  Do you mean that this case is not the most common (of the 3 mentioned), or that having a protocol be an extension of another is not the most common, or something else…maybe both?  Please be specific about "this".  I think that "While this is not the most common case" doesn't add anything and may actually cause confusion — suggestion: delete that part.

c5.1.2. I don't understand what is being mandated here.  On one hand, if the second case is "only possible" in one scenario, why isn't the "SHOULD" a "MUST"?  More importantly, what does it mean for a protocol to be "designed to enable this"?  Assuming that you're talking about the case (using a message type owned by another protocol) -- what exactly does it mean from a design point of view for the owning protocol?  The text says that "some of the rules in this document are to help facilitate that" -- assuming that "that" is pointing at "this", maybe a pointer to where the documents helps would be useful.

c5.1.2.1. Related to the above, I think..  Section 4.2. (Message Multiplexing and Packets) says that "Outgoing messages are created by their owning protocol, and MAY be modified by any extending protocols if the owning protocol permits this."  To the design part above, does all this mean that when designing a protocol it must indicate whether it can be extended and whether those extensions can modify its packets…for any unknown application/protocol in the future?  I can see how (in the context of a manet) NHDP may assume that other protocols may want to extend it, but the statement is general and it seems to assume many things about future protocols…  Note that another way of writing the quoted sentence above is: "An owning protocol MUST allow modification of its packet before they can be extended by another protocol."  That absolute is what concerns me.


c5.2. This Section uses several rfc2119 keywords incorrectly.  Note that RFC2119 says that they keywords "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)  For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability."  In this section many of the rfc2119 are not used in cases where interoperability is required.  See below.

c5.2.1. "The third case…Protocols MUST be conservative in the number of new Message Types that they require…Protocol design SHOULD consider whether different functions can be implemented by differences in TLVs carried in the same Message Type, rather than using multiple Message Types.  If a protocol's needs can be covered by use of the second case, then this SHOULD be done."  Questions/comments:

c5.2.1.1. How can a protocols comply with "MUST be conservative in the number of new Message Types that they require"?  In this case, not only do I think that being conservative can't really be enforced, but the use of "MUST" doesn't fall into an item required for interoperability.  Having said that, yes, the space is small (even though only 2 values have been assigned).  Here's a suggestion: the registry has an "Expert Review" registration policy and RFC5444 has some guidelines for the Designated Experts.  However, those guidelines don't include a review of whether the requesting party is being conservative or not.  Some of the considerations mentioned above could be used to extend the criteria for the DE.  Another avenue is to change how the registry is structured to allow for a bigger space.  If you chose to follow either suggestion we'll need the Chairs to poll the WG for consensus.

c5.2.1.2. Same question/comment for the first "SHOULD"…  Again, the use of rfc2119 language seems unnecessary.

c5.2.1.3. Same question/comment for the last "SHOULD"… In this case, the "SHOULD" is in conflict with the "MUST" because it refers to a conservative option.

c5.2.2. "The TLV type space…SHOULD also be used efficiently."  Same as above…  Also, without this first sentence, the rest of this paragraph doesn't seem to make much sense.


c5.3. "Each Message Type has an associated block of Message-Type-specific TLV Types…TLV Types from within these blocks SHOULD be used in preference to the Message-Type-independent Message TLV Types…when a TLV is specific to a message."  This paragraph seems to boil down to: use message-type-specific TLVs when the TLV is specific to a message.  That sounds obvious to me — but it concerns me that the "SHOULD" is not really doing much because by definition it leaves the door open for someone to not use message-type-specific TLVs…  Why is that not a "MUST"?


c5.4. Still in Section 4.1. (Where to Record Information): "A message MUST be recognized by the combination of its Message Type, Originator Address and Message Sequence Number."  If I'm reading RFC5444 correctly, some messages may not contain all 3 of those elements.  The "MUST" seems unenforceable because of that.  Or is there something else I'm missing?  Appendix B (RFC5444) also talks about this, it qualifies: "If the  and  fields are both present…identifier consisting of the message's , , and .  These serve to uniquely identify the message in the MANET within the time period until  is repeated…"

c5.4.1.  [minor] In the same paragraph there's some text pointing at RFC7181.  Is that supposed to be an example?  If it is, it is not clear it is. Also, it doesn't seem straight forward how that example uses the text right before it…



c6. Section 4.2. (Message Multiplexing and Packets)

c6.1. The model that is being defined here puts the multiplexer/demultiplexer between the interfaces and the protocols.  In other words, the protocols don't have direct interaction with/visibility to the characteristics of the interfaces, where the packets came from, etc.  Is that true, or am I missing something somewhere?  If true…  Section 1.2.2 and 4.2 talk about the owning protocol indicating which interface, or destination address, or even (at least) keeping the MTU of the link in mind (text snippets below) -- should the multiplexer provide that information, or is there another mechanism that is not apparent here??

c6.1.1. Text snippets: "MANET protocols, which also indicate over which interface(s) the messages are to be sent, and to which destination address", "owning protocol MUST indicate which interface(s) the messages are to be sent on and their destination address", "creating suitable sized messages that will not cause the MTU to be exceeded if sent in a single message packet is the responsibility of the protocol generating the message"


c6.2. "The owning protocol MUST indicate which interface(s)…and MAY request that messages are kept together in a packet; the multiplexer SHOULD respect this request if at all possible."  I'm assuming that the "SHOULD" applies only to keeping the messages together, right?  The use of both "MAY" and "SHOULD" seems to be in conflict, even if referring to different things. Suggestion:
NEW>
      The owning
      protocol MUST indicate which interface(s) the messages are to be
      sent on and their destination address.  The multiplexer SHOULD keep
      messages together in a packet if requested to do so.


c6.3. "The multiplexer MAY delay messages briefly…It SHOULD respect any constraints on such delays requested by the protocol." In this case "MAY" and "SHOULD" refer to the multiplexer — suggestion: s/MAY/may  BTW, what does "briefly" mean?  When can it not respect the constraints?


c6.4. Following on the last point, where it talks about "constraints on such delays requested by the protocol", how does the protocol communicate that?  Other text also talks about "request that messages are kept together in a packet", "requested by a protocol, the multiplexer…include a Packet Sequence Number in the packet" -- how is that done?  Is there an indication in the messages about the priority/timeliness/grouping of the packets for the multiplexer to act on?  Maybe you want to leave it as implementation specific…or maybe it's time to think about some type of API for these "control messages" between the protocols and the multiplexer.  [Note that my comment above about information potentially coming from the multiplexer to the protocols falls in a similar category.]


c6.5. Another SHOULD/MAY pair: "If requested by a protocol, the multiplexer SHOULD, and otherwise MAY, include a Packet Sequence Number in the packet."  The Packet Sequence Number is already optional per RFC5444, so there's no need for "and otherwise MAY".  Is there any criteria (besides a protocol request) that should be considered when deciding whether a Packet Sequence Number should be sent or not?  Why would the multiplexer decide not to send a Packet Sequence Number if being requested to do so?  IOW, why is the "SHOULD" not a "MUST"?

c6.5.1. Knowing that the Messages can also have Sequence Numbers, and that Section 4.1 says that "A message MUST be recognized by the combination of its Message Type, Originator Address and Message Sequence Number" (see my comment about this above), can you provide guidance for when a protocol may want to request that the multiplexor also carry a Packet Sequence Number?

c6.5.2. What about reliability?  The multiplexer is responsible to send/receive packets on interfaces — the Packet Sequence Number seems like a way to determine in-order reception (if needed), or at least whether a packet is missing.  But I didn't find anything in this document, RFC5444 (or RFC6130, when I went looking for an application example) about ACK'ing or retransmissions, or using the Sequence Numbers for anything other than referring to link quality.  I know that RFC5444 is not defining a protocol (just packet formats), but because this document is providing guidance on "how protocols can use the packet/message format" than I think that talking about reliability (or maybe lack of) would be a good thing.


c6.6. "Note that, as per the errata to [RFC5444], this Packet Sequence Number MUST be specific to the interface on which the packet is sent."  The errata uses "SHOULD" not "MUST".  Because the normative language is really in RFC5444, then this text referring to that shouldn't use normative language.  Also, because the errata was Verified, a reference to RFC5444 should be enough.  [This is another case where the protocol seems to need some information about the interfaces to decide whether to request including a Packet Sequence Number or not.]


c6.7. This Section mentions both an "extension to the multiplexer" and an "extension to the demultiplexer" in the context of adding TLVs, verifying, etc..  Comments/questions:

c6.7.1. "extension to the multiplexer MAY add TLVs to the packet and/or the messages"  I am hoping that you meant only Packet TLVs, and not Message TLVs as well.  Earlier the text says that "Outgoing messages are created by their owning protocol, and MAY be modified by any extending protocols if the owning protocol permits this"  --  AFAICT, the multiplexer is not being positioned as an extension to any protocol.

c6.7.2. "For example [RFC7182] MAY be used…"  That "MAY" is out of place as it is being used in an example.

c6.7.3. The same bullet also says that "Whether [RFC7182] Message TLVs are added and verified by the multiplexer or by the protocol is an implementation detail."  Leaving the adding part for now, for the specific case of RFC7182 I can see how the integrity could be verified before handing off a message to a protocol…but that seems to be a "layer violation":  as mentioned in 1.2.2, the demux should only "Extract messages from received packets, and pass them to their owning protocols."  What happens if the verification fails?  Is the implication that the statement is also true for other things (besides RFC7182)?

c6.7.4. A little later the verification of messages is mentioned again: "When a packet is received, the following steps are required to be performed by the demultiplexer:  The packet and/or the messages it contains MAY be verified by an extension to the demultiplexer…"  Several questions/comments:

c6.7.4.1.  Even though "required" is not an RFC2119 keyword, I think that it is confusing given that the first bullet is optional ("MAY").

c6.7.4.2. Speaking of that optional part, how can packet verification be optional?  Isn't the packet header the responsibility of the demux?


c6.8. [minor] "When a packet is received, the following steps are required to be performed by the demultiplexer:"  Only the first 3 bullets under this header refer to what the demux should do.  The other 3 are about the owning protocol.


c6.9. "The demultiplexer MUST remove any TLVs added to the message by the multiplexer."  How does the demux tell the difference between a message TLV added by multiplexer or the owning protocol?


c6.10. "The owning protocol SHOULD verify each message for correctness…"  When would it not?  IOW, why isn't this "SHOULD" a "MUST"?  I suspect that it has to do with the second part of the sentence: "…it SHOULD allow any extending protocol(s) to also contribute…".  As written, there may exist cases where the owning protocols doesn't check, but neither does an extension. 

c6.10.1. Going back to the text about extensions ("Outgoing messages are created by their owning protocol, and MAY be modified by any extending protocols if the owning protocol permits this."), is the intent for the owning protocol to also indicate when an extension is responsible for verifying messages it has modified?


c6.11. "The owning protocol MUST process each message, or make an informed decision not to do so.  In the former case an owning protocol that permits this MUST allow any extending protocols to process or ignore the message."  The balance of the text seems to be that neither the owning protocol or an extension may end up processing a message.  This is concerning specially with 2 MUSTs.  I'm sure that is not the intent.  Please rewrite the text or clarify when a message may be ignored by everyone.



c7. Section 4.3. (Messages, Addresses and Attributes):  "A TLV Full Type MAY be (and this is RECOMMENDED whenever possible) defined so that there MUST only be one TLV…"  Suggestion: "It is RECOMMENDED that a TLV Full Type be defined so that only one TLV…"



c8. Section 4.4. (Addresses Require Attributes)

c8.1. "A receiving OLSRv2-aware implementation of NHDP MUST reject such a message…"  This phrase represents a statement of fact, so no normative language should be used.  s/MUST/must

c8.2. This section surprised me  a little.  Most of the other sections are about characterizing and recommending the use of RFC5444 — this section actually changes how RFC5444 was specified: "…requires that those methods of carrying information MUST NOT be used for any protocol using [RFC5444]."  Given the change, I would like to understand the reason since it seems to me that in some cases the "simple presence of an address" might be enough; but I'm more interested if there are interoperability issues (as mentioned in the Abstract). 

c8.3. I have to say that I find some of the rules to be very restrictive.  Note that the use of "SHOULD" would ease any concern I have. Some examples:
- "A protocol MUST NOT assign any meaning to the presence or absence of an address…to the ordering…"
- "A protocol MUST NOT reject a message based on the inclusion of a TLV of an unrecognized type."
- "A protocol MUST NOT reject a message based on the inclusion of an unrecognized Value in a TLV of a recognized type.  The protocol MUST ignore any such Values when processing the message…"  [I put in a separate comment above for this part.]



c9.  [minor] Please move Section 4.5. (Information Representation) to an Appendix.  Even though the text says that this is a non-normative section, it would be clearer if it was put elsewhere.



c10. Section 4.6. (TLVs)

c10.1. "A protocol MAY use any representation of information using TLVs that convey the required information.  A protocol SHOULD use an efficient representation, but this is a quality of implementation issue."  I don't think that rfc2119 language is appropriate here as there is nothing really normative about the statements.

c10.2. "…even if it chooses to (for example) only use multivalve TLVs, it MUST recognize single value TLVs (and vice versa)."  This is an example: s/MUST/must

c10.3. "A protocol defining new TLVs…SHOULD follow the guidance in [RFC7188]…"  Given that protocols can define new TLVs for uses other than NHDP and OLSRv2, please extract the guidance in this general document (as you already did in 4.4).

c10.3.1 "…except…when extending [RFC6130] or [RFC7181], when these MUST also be followed)."  I would assume that rules/recommendations for the extension of specific protocols supersede this document, is that true?  If so, then there's no need to list exceptions.  In fact, please explicitly indicate that (new) protocols may define their own rules.



c11. In Section 6. (Message Efficiency), I think that the text starting with "Note, however, that this does not apply when forwarding a message…" is not needed and the use of normative language causes confusion — also, all the points in that sentence have already been described elsewhere in this document.



c12.  Section 6.1. (Address Block Compression)  Maybe it's just me, but all I got out of this section was something to the effect of: you could do this or that, but nothing is really specified.  I found this (the fact that I got nothing out of it) a little sad (for me) given the use of "SHOULD" at the top, which gave me hope that a compression algorithm was actually specified.

c12.1. "Addresses in an Address Block can be compressed, and SHOULD be."  Suggestion: "Addresses in an Address Block SHOULD be compressed."  As I mentioned above, I was hoping for more prescriptive behavior here — but if the compression is left to the operator's choice, please be clear about it and about the effect of not agreeing on the way to do it inside a network, and how it should be agreed on, to be able to meet the "SHOULD".

c12.2. The 2 MAYs at the end of the section shouldn't be there because they seem to point at a fact and not really be specifying anything new: "An example…is a HELLO message from [RFC6130] which MAY be generated with local interface addresses…These MAY be in separate Address Blocks."

c12.3. [minor] IPv6 Example.  Idnits mentions it, and I know no one in the WG pressed for it.  However, I want to suggest that you include an example of compression where there is a common tail (just for completeness) -- if it happens to be an IPv6 example, then even better.



c13. [minor] Section 6.2. (TLVs):  As with the previous section, I was left waiting for something important to be mentioned/specified.  Instead, all I got was that sometimes things may be possible and sometimes they may not be…

c13.1. [minor] Please clarify what is meant by a "contiguous set of addresses".

c13.2. [minor]"Reorder the addresses.  It is, for example, possible (…and beyond the scope of this document to describe exactly how) to order all addresses…as specified in [RFC6130]…"  Is the ordering specified in RFC6130?  The rest of this paragraph doesn't really say much about the ability or not ro order…

c13.3. "(When only one Value is involved…one single value TLV SHOULD always be used.)"  When only one Value is involved, when would you not use a single value TLV?  IOW, why is this not a "MUST", and, isn't this point obvious?  Why in parenthesis, which gives the impression that it is just part of an example or afterthought.



c14. Section 6.3. (TLV Values):  "This approach was specified in [RFC7188], and REQUIRED for protocols that extend [RFC6130] and [RFC7181]."  This seems to be a statement of fact, so please don't use the rfc2119 keyword. 

c14.1.  There seems to be a normative contradiction in how "this approach (i.e., defining an UNSPECIFIED Value)" is to be used.  The text (as mentioned above) says that RFC7188 makes it "REQUIRED", but it is only "RECOMMENDED" in this document.

c14.2.  In the last paragraph the point is made that while the approach of the LINK_METRIC TLV was not to define an UNSPECIFIED value, the result is equivalent.  Suggestion:  the overall recommendation of this sub-section seems to be to allow for an UNSPECIFIED Value-like indication in a TLV, whether it is explicitly or not — refocusing the section that way and providing the two approaches as examples may prove clearer.



c15. Section 6.4. (Automation):  What is this section about?  "There is scope for creating a protocol-independent optimizer…"  Scope where?  This optimizer sounds like an implementation detail to me — do we really need it in this document?  I ask specially because there is no specific description of it (just what sounds to me like hand waving), but then there is normative language describing it's use.   

c15.1. Also, the point of not changing messages that are forwarded has been made several times…but in Section 4.2 it is only "strongly RECOMMENDED" (not REQUIRED) -- which means that the "MUST NOT" is at odds with the previous direction.



c16. Section 7. (Security Considerations)

c16.1. Section 4.2. (Message Multiplexing and Packets) RECOMMENDs not changing forwarded messages so that RFC7182 can be used.  The Security Considerations in RFC7182 requires that protocols/extension "MUST specify how to use the framework and the TLVs presented in this document…[and]….the protection…by using this framework MUST be described."  All that is not discussed in this document.  Note that I bring this up because of it being "RECOMMENDED", which menas that this is the expected course (unless a very good reason exists not to do it).  In other words, I think that to satisfy RFC7182 it is better/more efficient if the description was done here and protocols/extensions that don't conform can then justify why not (forcing them to think harder). 

c16.2. On the other hand, the above direction (RECOMMENDING RFC7182) is really at odds with RFC7182 itself:  as I read RFC7182, it presents an optional framework because "one size rarely fits all".  Making a blanket RECOMMENDATION makes assumptions about all future protocols, their operation, etc..



c17. References

c17.1. RFC7182 and RFC7631 should be Normative.

c17.2  [minor] The citation for RFC7188 mentions RFC7183 instead.

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

Proposed Standard is being requested.  The draft updates rules for using RFC5444 and provides recommendations on correct usage.  The header indicates the appropriate request.

(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

  RFC 5444 specifies a generalized MANET packet/message format and
  describes an intended use to multiplex MANET routing protocol
  messages that is mandated for use by RFC 5498.  This document updates
  RFC 5444 by providing rules and recommendations for how the
  multiplexer operates and how protocols can use the packet/message
  format.  In particular, the mandatory rules prohibit a number of uses
  of RFC 5444 that have been suggested in various proposals, and which
  would have led to interoperability problems, to the impediment of
  protocol extension development, and to an inability to use optional
  generic RFC 5444 parsers.

Working Group Summary

The document was originally requested as informational from working group members who were attempting to use RFC5444 for their protocol development.  The design principles of the packet format were not readily apparent and the proposed usage of RFC5444 would have caused issues into the future.  It was decided that certain behaviors were not just bad choices but should be disallowed and the document was moved to standard so that it could update RFC5444 normatively.  There was some minor disagreement regarding the amount of informational information regarding the rational of design decisions of RFC5444, there being enough vs wanting even more.

Document Quality

There are multiple implementations (~10 that the shepherd is aware of) of RFC5444 which are compliant with the updated rules. The reviews done within the working group last call didn’t raise any major issues.

Personnel

Who is the Document Shepherd?
Justin Dean
Who is the Responsible Area Director?
Alvaro Retana

(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 document Shepherd has read the document as well as implemented RFC5444 that complies with the rules provided.  The shepherd is okay with the rules provided in the draft.  The shepherd feels the document is ready and provides necessary rules and more detailed guidance for those wishing to use RFC5444.

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

No.

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

No.

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

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

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


The WG as a whole has consensus with moving the document forward.  There is support among both the authors and the members who requested the document be drafted.  No major issues were raised during last call with most comments supporting publication.

(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).
Comment of note: an IPv4 example but no IPv6 example.  The example (in section 6.1) is simple and having an IPv6 example as well would be needlessly redundant; IPv6 is explicitly mentioned in the previous line so it’s clear that it’s supported.

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

N/A

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

Yes.

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


Yes RFC5444 will be updated and it’s listed in the title as well as abstract.

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

N/A

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

N/A

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

N/A