Subject: [manet] AD Review of draft-ietf-manet-rfc5444-usage-04

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 13 Sep 2016 15:02:28 +0000

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 <msg-orig-addr> and <msg-seq-num> fields are both present…identifier consisting of the message's <msg-orig-addr>, <msg-seq-num>, and <msg-type>.  These serve to uniquely identify the message in the MANET within the time period until <msg-seq-num> 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.