Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension
draft-ietf-manet-dlep-multi-hop-extension-07

[Ballot comment]
I support Roman's Discuss.

I think that there's room in the document to add some of the
clarifications made in response to the TSV-art review, especially
regarding the "exception cases" responsible for SHOULD-level
requirements as opposed to MUST-level requirements.

Section 1

  forwarding in intermediate modems.  This document refers to
  forwarding by intermediate modems as 'multi-hop forwarding'.  example
  using . DLEP Destination messages can be used to report such

nit: there seems to be some formatting issue or extraneous pasted text
here.

  It is important to note that the use of the hop control mechanism
  defined in this can result in connectivity changes and even loss of
  the ability to reach one or more destinations.  The defined mechanism

nit: missing word ("this document", perhaps?)

  will report such connectivity changes, but the details of what a
  router does or how it reacts to such are out scope of this document.

nit: maybe s/to such/to such reports/?

Section 2

  The use of the Multi-Hop Forwarding Extension SHOULD be configurable.
  To indicate that the extension is to be used, an implementation MUST
  include the Multi-Hop Forwarding Extension Type Value in the
  Extensions Supported Data Item.  [...]

Is the configurability for exposing that the feature is available (in
the Extensions Supported data item)?  (Independently of that answer?) I
don't think the second MUST is appropriate, as it is just duplicating a
requirement from RFC 8175.

Section 3.1

  The Hop Count Data Item is used by a modem to indicate the number of
  modem that transmits/sends data to reach a particular destination,

nit: "modems" plural and "transmit/send" to match.

  The Hop Count Data Item SHOULD be carried in the Destination Up,
  Destination Update, Destination Announce Response, and Link
  Characteristics Response Messages when the Hop Count to a destination
  is greater than one (1).

I'm not sure that the response to the tsv-art review addressed the key
question, namely: should this data item be carried in messages other
than the four listed here?  The current text makes no statement either
way, but the reviewer seemed to think that the intent was to suggest
that it did not make sense to carry the Hop Count Data Item in messages
not listed here.  Is that incorrect?

  A router receiving a Hop Count Data Item can use this information in
  its forwarding and routing decisions, and specific use is out of
  scope of this document.  The absence of the Hop Count Data Item MUST
  be interpreted by the router as a Hop Count value of one (1).

This "MUST" may not be forward-looking, in the case where some future
extension supersedes this one and so a message lacks a Hop Count Data
Item but has some other indicator of a greater-than-one hop count.  To
phrase it differently, in some sense this text is attempting to place a
constraint on implementations that do not implement this specification.
Perhaps the declarative "is interpreted" is less problematic.

Section 3.2

                                                        The modem MUST
  also notify the router of each destination that is not identified in
  the Link Characteristics Response Message and has a changed Hop Count
  impacted via a Destination Update Message.

nit: "changed" and "impacted" seem redundant.

For both the Session Update and Link Characteristic Request cases, we
only talk about Destination Down and Destination Update messages.  Is
there any case where we might need to send a Destination Up message in
response to the changes effected by a Hop Control Data Item (or is that
requirement already imposed by RFC 8175 in a part that I didn't read)?

Section 3.2.4

  A modem which receives the Suppress Forwarding Data Item in a Session
  Update Message MUST suppress multi-hop forwarding on a device wide
  basis.  This means that data traffic originating from the modem's
  peer router SHALL only be sent by the modem to destinations that are
  one modem hop away, and that any data traffic received by the modem
  from another modem that is not destined to the peer router SHALL be
  dropped.  [...]

nit(?): I'm not sure I understand the meaning of "destined to the peer
router", here.  It feels more natural if I instead say "destined to
itself", but perhaps this is because I am using "peer" to refer to
modem-level peering and this is instead intended to reflect a
relationship between the modem and router components of a single DLEP
entity.

Section 4

I don't think that "The extension does not inherently introduce any
additional threats above those documented in [RFC8175]." is really
correct -- as Roman notes, we are setting up control messages to change
the configuration of the radio hardware in ways not envisioned by RFC
8175 (i.e., "re-aiming the antenna"), as well as the explicit software
"suppress" controls.

                                        With the Link Characteristics
  Request Message, this risk is implicit.  With the Hop Control
  mechanism defined in this document it is more likely.  From a

nit: I don't think "implicit" conveys quite the intended meaning;
perhaps "implicit and small" is better.

  security perspective, implementations should be aware of this
  increased risk and may choose to implement additional configuration
  control mechanisms to ensure that the Hop Control mechanism is only
  used under conditions intended by the network operator.

(It seems like in practice this will mean the TLS requirement Roman
mentions, for almost all environments, though perhaps I am missing some
details.)

Section 5.3

I agree with Barry that some guidance to the expert is probably in
order.

[Ballot discuss]
This extension (much like draft-ietf-manet-dlep-pause-extension) seems to provide a mechanism to direct a modem to drop traffic in an unauthenticated fashion -- for directly connected networks via the terminate action; and for multi-hop networks via the suppress action.

For example, per the mobile scenario in Section 4 of RFC8175, a compromised laptop in the switch could use this extension instruct the modem to drop packets without authentication.

I saw in Warren’s comment ballet on draft-ietf-manet-dlep-pause-extension (https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ballot/) that

“Lou will add:
  Implementations of the extension defined in this document MUST support
  configuration of TLS usage, as describe in ,
  in order to protect configurations where injection attacks are
  possible, i.e., when the link between a modem and router is not
  otherwise protected.”

I believe the same caveat is needed in this draft as they are enabling similar behavior.  Please correct me if I’m conflating the capabilities of this extension with the pause extension.

[Ballot comment]
A few questions and an editorial nit.

(1) Section 1.  Editorial.  There is a sentence fragment “example using.” which likely needs to be removed.

(2) Section 2.  Per “The use of the Multi-Hop Forwarding Extension SHOULD be configurable”, what is meant by configurable?

(3) Section 3.2.2 and 3.2.3.  The Terminate and Direct Connection messages are not supposed to be (MUST NO) be sent in a Session Update Message.  How should the modem behave if it receives one anyway?

[Ballot comment]
Thank you for writing this -- I learnt a bunch while reading it.

I have a few minor comments:
1: "This document refers to forwarding by intermediate modems as 'multi-hop forwarding'.  example using . DLEP Destination messages"
There is a random ". exmaple using ." in the above.

2: "The Hop Count Data Item is used by a modem to indicate the number of modem that transmits/sends data to reach a particular destination, ..."
This is really hard to parse - I think you need "number of modem*s*" and s/transmits/transmit/". Or, perhaps something like "The Hop Count Data Item is used by a modem to indicate the number of modems that data will transit to reach ..."?

3: Question: "The data item also contains an indication of when a destination which currently has a hop count of greater than one (1) could be made directly reachable by a modem, e.g., by re-aiming an antenna." -- how can a modem know this? Unless it knows physically where a destination is, what the antenna information is, what objects might be between the antenna and destination exist, etc I cannot see how this might work -- but, then again, I know very little about this technology, so I'm happy to be educated...

4: IANA is likely to have questions about "Hop Control Actions Registry", like what the registration policy is, etc...

[Ballot comment]
Thanks to everyone who worked on this document. I have only two editorial
comments.

---------------------------------------------------------------------------

Please expand "DLEP" in the title and the abstract. See
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

---------------------------------------------------------------------------

§1:

> DLEP peers are comprised of a modem and a router.

Nit: This should be either "DLEP peers are composed of a modem and a router."
or "DLEP peers comprise a modem and a router."

[Ballot comment]
Clear and easy to read.

  == NITS ==

Section 1, there is a dangling ". example using ."

Section 3.2, the use of a 16-bit value for Hop Control Action suggest that there could be more than 4 values (indeed there is a IANA request for a registry for this field), suggest to mention that there could be more than 4 values in this section

[Ballot comment]
Hi,

thank you for this Document. I have a couple of questions

regarding:
  The absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1).
I know it is a bit nit-picking but would it be worth explicitly saying that this applies only in the case where the Multi-Hop Forwarding capability has been successfully negotiated?

regarding:
  Once the change is made, or fails or is rejected, the modem MUST respond with a Session Update Response Message with an appropriate Status Code.
I think you should specify which status code to use depending on the situation.

In sections 3.2.2 and .3 you have a requirement that says: "... MUST NOT be sent in a Session Update Message message" but in 3.2 you have some generic piece of text which says:
  A modem that receives the Hop Control Data Item in a Session Update
  Message SHOULD take whatever actions are needed to make the change
  indicated by the data item for all known destinations.
So if a router does not respect the MUST NOT then a modem might try to take some actions based on something it should have received.
Maybe it would be worth completing the "MUST NOT send" requirement with a "MUST discard/return error/log" type of requirement.

By the way, I'm not sure that the should in "... SHOULD take whatever actions ..." should be in caps. The actions that to be taken are described in detail in 3.2.1 to 3.2.4 and are not all SHOULDs (MUST clear, SHOULD attempt to establish, MUST suppress).

Thanks

[Ballot comment]
1) Maybe this is a bit of a blunt question because I might not know enough about DLEP but how does a modem know the number of hops? Is there any need to say something more about how to gather this information in the document?

2) Should the security consideration section maybe also say something about the frequency of re-configurations? Maybe that should be limited, also in order to not generate a large amount of signalling messages that could congest the link. Maybe you want to at least limit the rate of messages sent such that multiple re-configuration could be covered by one message in case there is a high rate of re-configurations. Or is there already such a limit in DLEP? If yes, it would be good to state that explicitly in this document as well.

nits:
- There seems to be a text fragment (“example using .”) in the intro text:
“This document refers to
  forwarding by intermediate modems as 'multi-hop forwarding'.  example
  using . DLEP Destination messages can be used to …”
- Sec 3.1: s/to indicate the number of modem/to indicate the number of modems/ -> plural: modemS

[Ballot comment]
Section 5.3 creates a registry that includes a Specification Required policy, which has a designated expert reviewing a specification and deciding whether to approve the registration request.  It would be useful to have at least brief guidance to the designated expert about what to consider when making that decision.  Should the only issue be whether the specification is sufficiently clear and complete?  Or are there other considerations that might warrant push-back to a registration request?

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

The IANA Functions Operator has completed its review of draft-ietf-manet-dlep-multi-hop-extension-06. 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 three actions which we must complete.

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 value is to be registered from the existing unassigned range as follows:

Code: [ TBD-at-Registration ]
Description: Multi-Hop Forwarding
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: Hop Count
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Hop Control
Reference: [ RFC-to-be ]

As this also 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.

Third, a new registry is to be created called the Hop Control Actions Values registry. The new registry will be located on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

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

Values 0-65519 are managed via Specification Required and values 65520-65534 are managed via Private Use as defined by RFC 8126. Value 65535 is reserved.

There are initial registrations in the new registry as follows:

Type Code: Description: Reference:
-----------+------------------------------+-----------------
0 Reserved
1 Terminate [ RFC-to-be ]
2 Direct Connection [ RFC-to-be ]
3 Suppress Forwarding [ RFC-to-be ]
4-65519 Unassigned
65520-65534 Private Use
65535 Reserved

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-04-05):

From: The IESG
To: IETF-Announce
CC: sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-dlep-multi-hop-extension@ietf.org, aretana.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DLEP Multi-Hop Forwarding Extension) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to
consider the following document: - 'DLEP Multi-Hop Forwarding 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-04-05. 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


  This document defines an extension to the DLEP protocol that enables
  the reporting and control of Multi-Hop Forwarding by DLEP capable
  modems.




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

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


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

=== AD Review of draft-ietf-manet-dlep-multi-hop-extension-05 ===
https://mailarchive.ietf.org/arch/msg/manet/KvpKUmBp8Br6LpfltAJAUlJs79I

Dear authors:

I just finished reading this document.  Please see my comments below.

The actions of the router may result in (unintended) unreachable
destinations. But there is no way (that I know of through DLEP) for the
router to know the result of any of its actions beforehand.  It is
important for this information to be clear in the document (either in a
dedicated Deployment Considerations sections or somewhere prominent in the
text).  Whether and how a router uses the Hop Count information or not
(already mentioned in §3.1), and whether and how it reacts to any
unreachable destinations as a result of its actions are out of scope of
this document...this fact should also be prominently mentioned.

Along similar lines, I think that the Security Considerations section
should also include (at least) a mention of the risks.

I'll wait for these points to be addressed before starting the IETF Last
Call.

Thanks!

Alvaro.


[Line numbers come from idnits.]

...
72 1.  Introduction
...
80  Some modem technologies support connectivity to destinations via
81  multi-hop forwarding.  DLEP Destination messages can be used to
82  report such connectivity, see [RFC8175], but do not provide any
83  information related to the number or capacity of the hops.  The
84  extension defined in this document enables modems to inform routers
85  when multi-hop forwarding is being used, and routers to request that
86  modems change multi-hop forwarding behavior.  The extension defined
87  in this document is referred to as "Multi-Hop Forwarding".

[major] Please define "multi-hop forwarding" in the context of the modems.

[minor] "Some modem technologies support connectivity to destinations via
multi-hop forwarding.  DLEP Destination messages can be used to report such
connectivity, see [RFC8175]..."  Where does rfc8175 talk about that?


...
101 2.  Extension Usage and Identification

103  The use of the Multi-Hop Forwarding Extension SHOULD be configurable.

[major] Is there a default recommended setting?


...
111 3.  Extension Data Items

113  Three data items are defined by this extension.  The Hop Count Data
114  Item is used by a modem to provide the number of network hops
115  traversed to reach a particular destination.  The Hop Control Data
116  Item is used by a router to request that a modem alter connectivity
117  to a particular destination.  The Suppress Forwarding Data Item is
118  used by a router to request that a modem disable multi-hop forwarding
119  on either a device or destination basis.

121 3.1.  Hop Count

123  The Hop Count Data Item is used by a modem to indicate the number of
124  physical hops between the modem and a specific destination.  In other
125  words, each hop represents a transmission and the number of hops is
126  equal to the number of transmissions required to go from a router
127  connected modem to the destination's connected modem.  The minimum
128  number of hops is 1, which represents transmission to destinations
129  that are directly reachable via the router's locally connected modem.

[minor] This section describes the hop count in terms of physical hops, but
§3 talks about "network hops".  Are these the same thing? Please clarify.

131  The data item also contains an indication of when a destination which
132  currently has a hop count of greater than one (1) could be made
133  direcly reachable by a modem, e.g., by re-aiming an antenna.

[nit] s/direcly/directly

...
140  A router receiving a Hop Count Data Item MAY use this information in
141  its forwarding and routing decisions, and specific use is out of
142  scope of this document.  The absence of the Hop Count Data Item MUST
143  be interpreted by the router as a Hop Count value of one (1).

[major] s/MAY/may  The rest of the sentence says that the use is out of
scope, so there's nothing normative here.

145  The format of the Hop Count Data Item is:

147        0                  1                  2                  3
148        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
149      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
150      | Data Item Type                | Length                        |
151      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
152      |P|  Reserved  |  Hop Count  |
153      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

155  Data Item Type:  TBA2

157  Length:  4

159  P:

161      The P-bit indicates that a destination is potentially directly
162      reachable.  When the P-bit is set, the router MAY request a direct
163      link to the associated destination using the Hop Control Data Item
164      described below.

[major] Should it only be set if the Hop Count is > 1?  I interpret the
definition ("potentially directly reachable") as saying that this bit
should not be set if Hop Count = 1, but I think it could be interpreted in
a different way.  Please clarify.

166  Reserved:

168      MUST be set to zero by the sender (a modem) and ignored by the
169      receiver (a router).

[major] I think that a registry for these bits is needed.  Otherwise anyone
can use them...

171  Hop Count:

173      An unsigned 8-bit integer indicating the number of network hops
174      required (i.e., number of times a packet will be transmitted) to
175      reach the destination indicated in the message.  The special value
176      of 255 (0xFF) is used to indicate that the number of hops is an
177      unknown number greater than one (1).  This field MUST contain a
178      value of at least one (1) if the associated destination is
179      reachable.

181      A value of zero (0) is used to indicated that processing of a Hop
182      Control action, see Section 3.2, has resulted in a destination no
183      longer being reachable.  A zero value MUST NOT be used in any
184      message other then a Link Characteristics Response Message.

[nit] s/indicated/indicate

[minor] s/has resulted in a destination no longer being reachable/has
resulted in the destination no longer being reachable  According to §3.2
the Hop Control message is about "a particular destination", so the result
can only be about it (the destination), and not about any destination ("a
destination").  Yes, this is really a nit...but it took me while to go
check rfc8175 to get that detail right.

186 3.2.  Hop Control
...
200  A modem that receives the Hop Control Data Item in a Link
201  Characteristics Request Message SHOULD attempt to make the change
202  indicated by the data item for the associated destination MAC
203  address.  Once the change is made, fails or is rejected, the modem
204  MUST respond with a Link Characteristics Response Message containing
205  an updated Hop Count Data Item.  Note that other destinations can be
206  impacted as a result of the change and such changes are reported in
207  Destination Down and Destination Update Messages.  The modem MUST
208  notify the router of each destination that is not identified in the
209  Link Characteristics Response Message and is no longer reachable via
210  a Destination Down Message.  The modem MUST also notify the router of
211  each destination that is not identified in the Link Characteristics
212  Response Message and has a changed Hop Count impacted via a
213  Destination Update Message.

[major] s/SHOULD attempt to make the change/SHOULD make the change  The
Normative action is to make the change, not to try to make it.  There are 2
more instances of the same phrase in the text.

215  A modem that receives the Hop Control Data Item in a Session Update
216  Message SHOULD attempt to make the change indicated by the data item
217  for all known destinations.  Once the change is made, or fails or is
218  rejected, the modem MUST respond with a Session Update Response
219  Message with an appropriate Status Code.  Destination specific impact
220  resulting from the processing of a Hop Control Data Item in a Session
221  Update Message is provided via Destination Down and Destination
222  Update Messages.  The modem MUST notify the router of each
223  destination that is no longer reachable via a Destination Down
224  Message.  The modem MUST notify the router of any changes in Hop
225  Counts via Destination Update Messages.

[minor] "Once the change is made, or fails or is rejected..."  Why could
the change fail?  Why would it be rejected?  I understand that the change
may fail if, for example, the destination is not directly reachable anymore
(and a Direct Connection was requested)...and I guess that there may be
"external" policy applied to the modem that could cause a
failure/rejection.  It might be worth clarifying that (specially the
rejection case) somewhere.

227  The format of the Hop Control Data Item is:

229        0                  1                  2                  3
230        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
231      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
232      | Data Item Type                | Length                        |
233      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
234      |      Hop Control Actions    |
235      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

237  Data Item Type:  TBA3

239  Length:  4

[major] The Length should be 2.

241  Hop Control Actions:

243      An unsigned 16-bit value with the following meaning:

245                      +-------+---------------------+
246                      | Value | Action              |
247                      +-------+---------------------+
248                      | 0    | Reset              |
249                      |      |                    |
250                      | 1    | Terminate          |
251                      |      |                    |
252                      | 2    | Direct Connection  |
253                      |      |                    |
254                      | 3    | Suppress Forwarding |
255                      +-------+---------------------+

257                    Table 1: Hop Control Actions Values

259 3.2.1.  Reset

261  The Reset Action requests that the default behavior be restored.
262  When received in a Session Update Message message, a modem SHOULD
263  clear all control actions that have previously been processed on a
264  device wide basis, and revert to its configured behavior.  When
265  received in a Link Characteristics Request Message, a modem SHOULD
266  clear all control actions that have previously been processed for the
267  destination indicated in the message.

[major] When would a modem not clear all control actions?  IOW, why use
SHOULD and not MUST?  I'm assuming that it may not be possible (simply
because of the nature of a manet), but I'm asking in case there are other
reasons.

269 3.2.2.  Terminate

271  The Terminate Action is only valid on a per destination basis and
272  MUST NOT be sent in a Session Update Message message.  It indicates
273  that a direct connection is no longer needed with the destination
274  identified in the message.  This request has no impact for multi-hop
275  destinations and may fail even in a single hop case, i.e. MAY result
276  in the Hop Count to the destination not being impacted by the
277  processing of the request.

[major] s/MAY/may  That is a non-Normative statement.

[minor] What is the difference between Reset and Terminate (for a
particular destination)?

279 3.2.3.  Direct Connection

281  The Direct Connection is only valid on a per destination basis and
282  MUST NOT be sent in a Session Update Message message.  It indicates
283  that the modem SHOULD attempt to establish a direct connection with
284  the destination identified in the message.  This action SHOULD only
285  be sent for destinations for which the Hop Count is greater than 1
286  and has the P-Bit set in the previously received Hop Count Data Item.
287  Results of the request for the destination identified in the message
288  are provided as described above.  If any other destination is
289  impacted in the processing of this action, the modem MUST send a
290  Destination Update Message for each impacted destination.

[minor] ...or send a Destination Down...  If pointing at the text above, I
think that the last sentence (and any other details) are not needed and
redundant.

292 3.2.4.  Suppress Forwarding
...
308  A modem which receives the Suppress Forwarding Data Item in a Link
309  Characteristics Request Message MUST suppress multi-hop forwarding
310  for only the destination indicated in the message.  This means that
311  data traffic originating from the modem's peer router SHALL be sent
312  by the modem to the destination indicated in the Link Characteristics
313  Request Message only when it is one modem hop away.  Notably, data
314  traffic received by the modem from another modem MAY be forwarded by
315  the modem per its normal processing.  Results are provided as
316  described above.

[major] s/MAY/may  There's nothing about the change that would make
forwarding optional.

318 4.  Security Considerations

320  The extension enables the reporting and control of forwarding
321  information by DLEP capable modems.  The extension does not
322  inherently introduce any additional threats above those documented in

324  [RFC8175].  The approach taken to Security in that document applies
325  equally when running the extension defined in this document.

[major] The use of this extension can result in unreachable destinations --
maybe an unintended consequence of, for example, re-aiming an antenna.  A
rogue (or compromised) router can take advantage of this.  A rogue (or
compromised) modem could indicate an incorrect hop count or P-bit setting
that may result in unreachable destinations (after the router acts on that
information).

rfc8175 already mentions some related risks.  However, I think that the
point still needs to be called out specifically because of the new
functionality introduced.


...
364 5.3.  Hop Control Actions Registry

366  Upon approval of this document, IANA is requested to create a new
367  DLEP registry, named "Hop Control Actions Values".  The following
368  table provides initial registry values and the [RFC8126]. defined
369  policies that should apply to the registry:

[nit] s/[RFC8126]./[RFC8126]


...
409 6.2.  Informative References

411  [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
412              Writing an IANA Considerations Section in RFCs", BCP 26,
413              RFC 8126, DOI 10.17487/RFC8126, June 2017,
414              ;.

[major] This reference should be Normative.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The document is being presented as a Proposed Standard. Current marking on the document reads "Standards Track".

(2)

Technical Summary

This document defines an extension to the DLEP protocol that enables
the reporting and control of Multi-Hop Forwarding by DLEP capable
modems.

Working Group Summary

  The Working Group process proceeded without any issues. The authors took most of the points raised on the mailing list and incorporated them into the document. The document reached last call without controversy.

Document Quality

  The document is well written. To the shepherd's knowledge, there are no implementations of the specification, however, vendors plan to implement. Are there existing implementations of the protocol?

Personnel

  The Document Shepherd is Stan Ratliff. The responsible Area Director is Alvaro Retana.

(3) The document shepherd has reviewed the document, and has found no issues with proceeding to publication.

(4) The document has been reviewed at a sufficient technical depth, and is ready for publication.

(5) No further reviews are needed.

(6) The shepherd has no concerns or issues for the responsible AD. The WG consensus behind this document is solid.

(7) Yes, each author has confirmed that no IPR exists.

(8) No IPR has been filed against this document.

(9) The WG as a whole understands the document, and agrees that it should be published.   

(10) No appeals have been threatened.

(11) No nits were found.

(12) The document does not reference a MIB, or media types. No additional reviews are required.

(13) All references are defined as either normative or informative.

(14) All normative references are already published RFCs.

(15) There are no downward references.

(16) This document will not change the status of any existing RFC.

(17) All IANA information has been properly addressed in the document, and this information is completely consistent with the rest of the document.

(18) The 'Extension Type Value' registry would require expert review. Experts were identified when the registry was created.

(19) No XML, BNF, or MIB text appears in the document.

As discussed at IETF 100 the document has been updated.  Now that the holidays are over people should have the time to look the document over.  Please also review the latency-extension draft as they are in last call at the same time.