Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension
draft-ietf-manet-dlep-lid-extension-06

[Ballot comment]
Thanks for addressing my DISCUSS point. I think the new MAY (I had suggested a conditional "if advertised ... MUST") might be a bit too relaxed but it is totally your call.

[Ballot comment]
I'm sure it's just because I don't fully understand DLEP, but I don't get this bit in Section 2.2:

  However, the modem SHOULD NOT immediately terminate the
  DLEP session, rather it SHOULD use a combination of DLEP Session
  Messages and DLEP Attached Subnet Data Items to provide general
  information.

Will implementers know, based on how DLEP works in general, what "general information" to provide?  What good will that general information do?  The implication here is that the modem will terminate the DLEP session after providing the general information (as it requires this feature and the feature isn't available).  So what's the point of the general information the modem will provide before terminating?  Is it worth saying a few more words here?

[Ballot discuss]
* Section 3.1.

I might be missing something here but I think that the "MUST be used" in this session is wrong and must be relaxed by qualifying it. Here is why. In case the router does not advertise support by including the value 'Link Identifiers' in the Extension Data Item inside the Session Initialization Message, I feel that the modem MUST NOT send the Link Identifier Length Data Item as this will result in a Session Termination message from the router based on the rules specified in Section 12.1 of RFC8175 due to the unknown data item.

If you agree with my assessment, I would suggest a change like this. If not, can you please clarify.

OLD:

  It MUST be used during Session Initialization, contained in a Session
  Initialization Response Message, if the specified length is not the
  default value of 4 octets.

NEW:

  If the router advertised support by including the value 'Link Identifiers' in the
  Extension Data Item inside the Session Initialization Message, this data item
  MUST be used during Session Initialization, contained in a Session
  Initialization Response Message, if the specified length is not the
  default value of 4 octets. If not, this Data Item MUST NOT be sent.

[Ballot comment]
Thank you for the work put into this document.  I have two questions in the COMMENT section that I would appreciate to be answered.

Regards,

-éric

== COMMENTS ==
-- Section 3.1 --
Is there any use of the "link identifier length data item" as in section 3.2 the link identifier has a field for its length?

-- Section 3.2 --
What is the expected behavior when the "link identifier data item" does not match the length ?

[Ballot comment]
I'm not entirely sure I understand the expected mode of operation here.
Clearly the overall goal is to advertise IP reachability, but it seems
the way we do this is to construct an opaque "link identifier" to
indicate to the DLEP peer that there is "some other link broader than
layer-2" attached, and then rely on the existing IP
address/attached-subnet data items to associate that opaque link
identifier with the corresponding IP resources.  But this document
doesn't make it fully clear to me the details of associating IP
resources with the link identifier: how are the two data items known to
be bound together; what is the scope of attachment; is there potential
for confusion if multiple bindings are transmitted in parallel; etc.
As best as I can tell this is intended to be wrapped into the single
line that "[t]he Link Identifier Data Item MAY be used wherever a MAC
Address Data Item is defined as usable in core DLEP.", but spending
another sentence or two for a brief overview and/or section reference
might be worth the reader's time.  (In some sense, we also don't really
say how the semantics from the MAC Address Data Item transfer over to
the Link Identifier Data Item usage, which could be helpful, too.)

In a similar vein, I'm not sure that I understand the distinction
between this mechanism and the existing IP address/attached-subnet data
items from RFC 8175.  My current understanding is that the semantics of
the structures in RFC 8175 is to indicate IP resources that are
"directly attached" to the indicated Destination, but that this new
mechanism is needed for cases when the IP resources are not directly
attached to, but are reachable via, the indicated Destination.  Is that
correct?  It might be good to have some further discussion in the
document about why the existing mechanisms are inadequate/insufficient
for the described use cases (I mostly assume that having the additional
Destination/link identifier allows for more granular updates, instead of
having to reannounce the entire IP reachability via the layer-2
Destination's entry, but that's just an assumption).

Section 1.1

I'm probably just confusing myself, but:

  Local Layer 2 domain:  The Layer 2 domain that links the router and
      modem participants of the current DLEP session.

uses "DLEP session", which suggests to me that it is indeed quite local,
with the current DLEP session just involving the directly-connected
router and modem.  On the other hand:

  Layer 3 DLEP Destination:  A DLEP Destination that is not directly
      addressable within the local Layer 2 domain, but is reachable via
      a node addressable within the local Layer 2 domain.

(in combination with the introduction) is suggesting to me that the
layer-3 destination is something with IP reachability via a device on
the other end of a radio link from one of the local modems, and also
implying that the router/modem at the other end of the radio link is
itself supposed to be part of the "local Layer 2 domain".  So I'm not
sure how broad the local Layer 2 domain is supposed to be.

  Gateway Node:  The last device with a MAC address reachable in the
      local Layer 2 domain on the path from the DLEP router participant,
      towards the Layer 3 DLEP Destination.  This device is commonly the
      DLEP peer modem but could be another DLEP Destination in the Layer
      2 domain.

Just to check my understanding: the DLEP peer modem is the "directly
attached" one, and another "DLEP Destination" would be a different
router?

Section 2

  As only modems are initially aware of Layer 3 DLEP Destinations, Link
  Identifier Data Items referring to a new link MUST first appear in a
  DLEP Destination Up Message from the modem to the router.  Once a

nit/style: this statement of fact ("only modems are initially aware")
comes a bit out of the blue and doesn't have any surrounding
justification/explanation.  It's fairly clear that it's just an inherent
property of how the information flows around, but could perhaps be
written in a more reader-friendly way.

Section 2.2

  If a modem requires support for this extension in order to describe
  destinations, and the router does not advertise support, then the

"In order to describe destinations" is perhaps ambiguous about some vs.
all attached destinations.

Section 3.1

Am I supposed to only send this data item in the Session Initialization
Response Message if I'm also negotiating the Link Identifiers extension?

Section 4

It would be good to see a response to the secdir reviewer's question
about potential privacy considerations of expanding the scope of IP
connectivity described.

Additionally, we require that the router "must not make any assumptions
about the meaning of Link Identifiers, or how Link Identifiers are
generated".  To me, this suggests that various modem implementations are
likely to reuse identifiers of some other nature as DLEP link
identifiers, and we are imploring the routers to not rely on any
specific such internal structure.  In the general case, when this sort
of "identifier reuse" occurs, we have to be careful to consider any
security or privacy considerations should a router ignore the advice and
attempt to look at the internal structure of the identifier.  In this
specific case of DLEP, there does not seem to be much of a concern,
since we expect the router and modem to be fairly tightly integrated and
at an equivalent trust level, but I did want to mention it as a possible
consideration.

It might also be appropriate to talk about collision probability when
randomly assigned Link Identifiers are used and how that relates to the
frequency of DLEP session creation and the churn rate of link
identifiers.

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

The IANA Functions Operator has completed its review of draft-ietf-manet-dlep-lid-extension-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Extension Type Values registry on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

https://www.iana.org/assignments/dlep-parameters/

a single, new registration is to be made as follows:

Code: [ TBD-at-Registration ]
Description: Link Identifiers
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Data Item Type Values registry also on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

https://www.iana.org/assignments/dlep-parameters/

two, new registrations are to be made as follows:

Type Code: [ TBD-at-Registration ]
Description: Link Identifier Length
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Link Identifier
Reference: [ RFC-to-be ]

As this also requests registrations in a or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-15):

From: The IESG
To: IETF-Announce
CC: manet-chairs@ietf.org, manet@ietf.org, aretana.ietf@gmail.com, draft-ietf-manet-dlep-lid-extension@ietf.org, bebemaster@gmail.com, Justin Dean
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DLEP Link Identifier Extension) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to
consider the following document: - 'DLEP Link Identifier Extension'
  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 2019-08-15. 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


  The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a
  protocol for modems to advertise the status of wireless links between
  reachable destinations to attached routers.  The core specification
  of the protocol assumes that every modem in the radio network has an
  attached DLEP router, and requires that the MAC address of the DLEP
  interface on the attached router be used to identify the destination
  in the network, for purposes of reporting the state and quality of
  the link to that destination.

  This document describes a DLEP Extension allowing modems that do not
  meet the strict requirement above to use DLEP to describe link
  availability and quality to one or more destinations reachable beyond
  a device on the Layer 2 domain.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ballot/


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

=== AD Review of draft-ietf-manet-dlep-lid-extension-04 ===
https://mailarchive.ietf.org/arch/msg/manet/7GVdOnIZz948Y6Rrt-iv9K7RBfQ

Dear authors:

I just finished reading this document -- thanks for the work!

I have some significant issues with the document, not the extension/functionality itself, but the text.  Please also take a look at my comments in the text.

(1) What problem are you trying to solve?  After reading the Abstract/Introduction it was not completely clear to me what is the problem -- I looked back at the meeting slides and the mailing list discussion to get a better picture.  I think I now have an understanding -- in general, I think the document could benefit form a little more content explaining the use cases.  [See more below.]

(2) Specificity of the specification.  Vague descriptions are used throughout the text, even associated to Normative language!  Examples include: "the last reachable node", it "might be the address", "some kind of backbone infrastructure", "some kind of sleight-of-hand"...  This is a Standards Track document, please be specific and clear.

(3) Terminate-resulting Errors and Security.  Because of how the operation is specified (for example, requiring "the Link Identifier Data Items referring to a new link [to] first appear in a DLEP Destination Up Message from the modem to the router"), there seem to be several opportunities for a rogue/compromised modem/router to terminate the DLEP session.  Please call these cases out in the Security Considerations section as potential risks.  The Shepherd's writeup mentions one implementation, so it is probably too late to change the operation to minimize the risk.  [I made some comments bellow pointing at items that I think should be mentioned as a risk.]

I will start the IETF Last Call when these issues have been addressed.

Thanks!

Alvaro.


[Line numbers come from idnits.]


...
11 Abstract

13   There exists a class of modems that would benefit from supporting the
14   Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not present a
15   single Layer 2 network domain as required by DLEP.  Such devices may
16   be:

[nit] Don't include references in the Abstract.

...
34   Note:

36   o  This document is intended as an extension to the core DLEP
37       specification, and readers are expected to be fully conversant
38       with the operation of core DLEP.

[minor] This note is not needed (specially in the Abstract) -- making DLEP a Normative Reference is enough.


...
89 1.  Introduction
...
[nit] Some of the sentences are very long...a couple of commas here and there would not hurt.

108   A Layer 3 destination may be an attached DLEP router, in the case of
109   a modem that provides Layer 3 wide area network connectivity between
110   devices, or a logical destination that describes a set of attached
111   subnets, when referring to some upstream backbone network
112   infrastructure.

[minor] To be honest, it took me several reads of the Abstract/Introduction for it to make sense to me -- I looked at the slides and read the mailing list as well.  I'm not sure that it will be clear to other readers (e.g. directorate reviewers, IESG).  Consider expanding on the use cases.

I'm missing how the reference to "some upstream backbone network infrastructure" comes into play here.  It sounds like you want to advertise non-directly-attached destination information, but it is not clear to me if the modem has a DLEP session with those remote nodes or not.  Among other things, understanding this is important because of the Security Considerations.

I think I now have a good mental picture, but the document should clearly explain as well.

114 1.1.  Requirements

116   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
117   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
118   document are to be interpreted as described in BCP 14, RFC 2119.

[major] Please use the template from rfc8174.

120 2.  Operation

122   To refer to a Layer 3 DLEP Destination, the DLEP session participant
123   adds a Link Identifier Data Item (Section 3.2) to the relevant
124   Destination Message, and (as usual) includes a MAC Address Data Item.
125   When paired with a Link Identifier Data Item, the MAC Address Data
126   Item MUST contain the MAC address of the last reachable node in the
127   Layer 2 domain beyond which the Layer 3 DLEP Destination resides.
128   For example, if the over-the-air network is not a single Layer 2
129   domain, the MAC Address Data Item might be the address of the LAN-
130   side interface of the local modem.  Alternatively, when used with
131   some kind of backbone infrastructure, the MAC Address Data Item would
132   be the address of the last device reachable on the local Layer 2
133   domain.  However, how such remote destinations are discovered is
134   beyond the scope of this specification.

[major] I think that the specification has to be more specific:

(1) "the last reachable node" -- the first example seems clear, even though the text points at a MAC address that "*might*" be it.  Not a warm a fuzzy feeling.

(2) "some kind of backbone infrastructure, the MAC Address Data Item would be the address of the last device reachable on the local Layer 2 domain" -- "*some kind*" is not clear.  Even though the discovery of the "last reachable node" is out of scope, it is important to know which node we're talking about!!  It has to be crystal clear because of the MUST above.

136   As only modems are initially aware of Layer 3 DLEP Destinations, Link
137   Identifier Data Items referring to a new link MUST first appear in a
138   DLEP Destination Up Message from the modem to the router.  Once a
139   link has been identified in this way, Link Identifier Data Items MAY
140   be used by either DLEP participant during the lifetime of a DLEP
141   session.  Because of this, a router MUST NOT send a DLEP Destination
142   Announce Message containing a Link Identifier Data Item referring to
143   a link that has not been mentioned in a prior DLEP Destination Up
144   Message.

[major] What if the Link Identifier Data Items referring to a new link don't first appear in a DLEP Destination Up Message from the modem to the router?  It seems to me that this case should result in an "Invalid Data" status, right?  If so, then I think it is important to call out as a risk.

[major] s/MAY/may  It is not specifying anything...just pointing out a fact.

146   Because the MAC Address associated with any DLEP Destination Message
147   containing a Link Identifier Data Item is not the Layer 2 address of
148   the destination, all DLEP Destination Up Messages MUST contain Layer
149   3 information.  In the case of modems that provide Layer 3 wide area
150   network connectivity between devices, this means one or more IPv4 or
151   IPv6 Address Data Items providing the Layer 3 address of the
152   destination.  When referring to some upstream backbone network
153   infrastructure, this means one or more IPv4 or IPv6 Attached Subnet
154   Data Items, for example: '0.0.0.0/0' or '::/0'.  This allows the DLEP
155   peer router to understand the properties of the link to those routes.

157   When the DLEP peer router wishes to forward packets to the Layer 3
158   destination or subnet, the MAC address associated with the link MUST
159   be used as the Layer 2 destination of the packet if it wishes to use
160   the modem network to forward the packet.

[minor] Is this MAC address the same as the one in the MAC Address Data Item from "the last reachable node"?  If so, then this seems to be a much better explanation than what was included above.

162   As most mainstream routers expect to populate their routing
163   information base with the IP address of the next router towards a
164   destination, implementations supporting this extension SHOULD
165   announce one or more valid IPv4 or IPv6 addresses of the last
166   reachable Layer 2 device, i.e. the device with the corresponding MAC
167   Address.

[major] Why use SHOULD and not MUST?  What is the advantage/disadvantage of advertising more than one address?

169   If the last reachable Layer 2 device is not the DLEP peer modem, then
170   the modem SHOULD announce a DLEP Destination with the required MAC
171   Address without including a Link Identifier Data Item.

[major] Isn't that what is already included in the MAC Address Data Item at the beginning of this section (but advertised *with* the Link Identifier Data Item)?

173 2.1.  Identifier Restrictions

175   A Link Identifier is by default 4 octets in length.  If a modem
176   wishes to use a Link Identifier of a different length, it MUST be
177   announced using the Link Identifier Length Data Item (Section 3.1)
178   contained in the DLEP Session Initialization Response message sent by
179   the modem to the router.

181   During the lifetime of a DLEP session, the length of Link Identifiers
182   MUST remain constant, i.e. the Length field of the Link Identifier
183   Data Item MUST NOT differ between destinations.

[major] This is another case where the session could be terminated if the wrong length is used...  Call out as a risk.

[minor] It seems to me that the intended Link Identifier Length could have also been derived form the first Link Identifier Data Item advertised by the modem.  Why is the extra Data Item required?  [It may be too late to change anything, I'm mostly wondering why the extra moving parts.]

185   The method for generating Link Identifiers is a modem implementation
186   matter and out of scope of this document.  Routers MUST NOT make any
187   assumptions about the meaning of Link Identifiers, or how Link
188   Identifiers are generated.

[major] s/MUST NOT/must not  There's no specification there...

190   Within a single DLEP session, all Link Identifiers MUST be unique per
191   MAC Address.  This means that a Layer 3 DLEP Destination is uniquely
192   identified by the pair: {MAC Address,Link Identifier}.

194   Link Identifiers MUST NOT be reused, i.e. a {MAC Address,Link
195   Identifier} pair that has been used to refer to one DLEP Destination
196   MUST NOT be recycled to refer to a different destination within the
197   lifetime of a single DLEP session.

[minor] Aren't these last 2 paragraphs redundant?

199 2.2.  Negotiation

201   To use this extension, as with all DLEP extensions, the extension
202   MUST be announced during DLEP session initialization.  A router
203   advertises support by including the value 'Link Identifiers' (TBD1),
204   Section 5, in the Extension Data Item within the Session
205   Initialization Message.  A modem advertises support by including the
206   value 'Link Identifiers' (TBD1) in the Extension Data Item within the
207   Session Initialization Response Message.  If both DLEP peers
208   advertise support for this extension then the Link Identifier Data
209   Item MAY be used.

[major] s/MAY/may

211   If a modem requires support for this extension in order to describe
212   destinations, and the router does not advertise support, then the
213   modem MUST NOT include a Link Identifier Data Item in any DLEP
214   Message.  However, the modem SHOULD NOT immediately terminate the
215   DLEP session, rather it SHOULD use session-wide DLEP Data Items to
216   announce general information about all reachable destinations via the
217   modem.  By doing this, a modem allows a router not supporting this
218   extension to at least make a best guess at the state of any reachable
219   network.  A modem MUST NOT attempt to re-use the MAC Address Data
220   Item to perform some kind of sleight-of-hand, assuming that the
221   router will notice the DLEP Peer Type of the modem is special in some
222   way.

[major] "SHOULD NOT immediately terminate"  But it may do it later?  Are there cases where it would/should?  Why not MUST NOT instead of SHOULD NOT?

There seems to be no reason for the session to be terminated -- yes, if the modem can't communicate what it need to, then there's no point in having the session...but that is not a reason to reset (or is it?).


[minor] What do you mean by "session-wide DLEP Data Items"?  From rfc8175 it looks like you mean Data Items in a Session Update Message.  Please be more specific.  In fact, it would be very nice if you expanded in how to do it.

[minor] "make a best guess"  It seems to me that the difference between using the new procedure defined in this document, and, simply using the Session Update Message is that the new functionality explicitly indicates that the destination is remote (vs giving the appearance that the destinations are attached to the router), any maybe being able to use different metrics.  Is that a correct interpretation?  IOW, it is not really be a guess...

[major] "MUST NOT...perform some kind of sleight-of-hand"  This is the first time that I see magic normatively prohibited.  :-(


...
232 3.1.  Link Identifier Length Data Item

234   The Link Identifier Length Data Item is used by a DLEP modem
235   implementation to specify the length of Link Identifier Data Items.
236   It MUST be used if the specified length is not the default value of 4
237   octets.

239   The Link Identifier Length Data Item MAY be used during Session
240   Initialization, contained in a Session Initialization Response
241   Message.

[minor] Perhaps reword to avoid an apparent Normative contradiction (MUST vs MAY)...for example: "It MUST be used during Session Initialization, contained in a Session Initialization Response Message, if the specified length is not the default value of 4 octets."

[major] If this Data Item is used (during Session Initialization, contained in a Session Initialization Response Message), but it indicates a Link Identifier Length of 4...what should happen?  Should it be considered Invalid Data or maybe an Unexpected Message, or ??  Specifying that it "MUST be used if the specified length is not the default value of 4 octets" seems to indicate that it should't be used otherwise... Maybe another risk...


...
281 4.  Security Considerations

283   As an extension to the core DLEP protocol, the security
284   considerations of that protocol apply to this extension.  This
285   extension adds no additional security mechanisms or features.

287   None of the features introduced by this extension require extra
288   consideration by an implementation.

[major] I think that the functionality in this extension may result in Invalid Data (and a terminated session) -- see the comments in §2/2.1 above.  While this case may only be the result of a rogue modem/router, and rfc8175 already says something general about that, it is important to point it out here because the functionality/operation is new.


...
318 6.2.  Informative References

320   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
321               IANA Considerations Section in RFCs", RFC 5226,
322               DOI 10.17487/RFC5226, May 2008,
323               .

[minor] There's no reference to rfc5226 in the text.

(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 appropriate as the document outlines an optional extension to a proposed standard protocol (DLEP) and working code exists.

(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: 
There exists a class of modems which would benefit from Dynamic Link Exchange Protocol (DLEP) [RFC8175] support but do not present a single  Layer 2 network domain as required by DLEP.  This document introduces an optional extension to the core DLEP specification, allowing DLEP to be used between routers and modems that operate in this way.

Working Group Summary:
There wasn’t anything of significant contention within the working group regarding the document either in text or protocol operation.

Document Quality:
There is an existing implementation of the protocol.  There is at least one vender who plans or has used the specification. I’ve (Justin Dean) have reviewed the document in detail and didn’t find any substantive issues.

Personnel:
  Document Shepherd?  Justin Dean
  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.
I’ve done a through review of the document and identified various nits and wordage issues.  The most substantial issue regarded some confusion in intent due to poor wording.  I’ve verified with the authors that rewording will fix the issue and no protocol functionality will need be changed.  The only other issue of note was identifying all protocol specific key words and using the same text to refer to those objects (specifically “Link Identifier”).  These changes and issues are all minor enough to be rolled into any future rev required by the IESG or IETF last call.

(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.
The Document Shepherd doesn’t have any issues or concerns with this document (excluding those mentioned)

(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?
There is solid WG consensus behind this document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There was one error:
The abstract seems to contain references ([RFC8175]), which it shouldn't. Please replace those with straight textual mentions of the documents in question.
And 3 warnings regarding references, 2 unused (due to being in the abstract) and 1 obsoleted.

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

(13) Have all references within this document been identified as either normative or informative?
Yes. They just need to be moved out of the abstract.

(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.
It won’t change the status but when optionally used it will update RFC8175 which is listed as a normative reference.

(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).
The Shepherd suggested an edit to improve clarity regarding which registries requested assignments were being made from.  The current text (non edited/updated) is sufficient for absolute correctness only lacks some in clarity.  The suggested edits were sent to the authors but the Shepherd wouldn’t be bothered if they keep the current text.

(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.
There are no new IANA registries only assignment requests.

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