From nobody Tue Feb 12 13:11:47 2019 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE34312DF71; Tue, 12 Feb 2019 13:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJB4rhe079Cn; Tue, 12 Feb 2019 13:11:42 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACED1128B36; Tue, 12 Feb 2019 13:11:38 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id i5so199331oto.9; Tue, 12 Feb 2019 13:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=bkVvjL8TtnmFcj9luqe9rd72xLtlycozaKliLDESrjs=; b=Nj2S1RX7CEUEzCsechQPLEu4R/A3NhFFQ1Qm04pE2Hj37YVWFWFwohzI1ndK3sQqcp BIQYp1xjAw4DTIGSnrKZ8qrVU7wwkvm/KQwHe7HNKjduiWATTHYtPOZqcp20lKq5baM2 9mrkdWq7p+nslJB0CX3JZDFoHCDKxnpqq0j8w4guKaU3M8weHWXIfhM8v5KKl07sEvNf ViJH/WpuCduYb96U84VPVZkgZw9rw1K6kGuc1DSNGUC6l1YyEdWaeK7Q4avZ49NCxrQv kn3ckACWfpj6lTx8fH34Pb6JnAS1oQ/zQwFZqii2TRDCqfDozdmSzLyey803LIXS31Ck D73Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=bkVvjL8TtnmFcj9luqe9rd72xLtlycozaKliLDESrjs=; b=iVR4Z9DIC09A6XieRMdRTef3C/P7vwQJyxQgwgjcCiG1StecZ4VibB5ak21d7+ggbP UTts0ng+mWVPEF7uqcPXBdKEDlfBvktUkWFk1vV4PmD+IozZLPoYgOpYl2oqNDQobfVj iT5ZwuEHUQNenrPhe3Um7Yx71AUWLJf4pZh+Ib44S9UWo7SUqdvVPPZXjPt1pYyVjK6Q PaFIf0TlFEOoXjpzc58nT4vD85OoidZ5t4K3nbym0q0iCIC0dRS01wpswTAJwkBBn5Yi LLGeqqTihFhe4ZqrmEEtPItkL8p7oOnJWqpwt372VAj6HTd7WpLyvmA68NeDvugCzidL 0Srg== X-Gm-Message-State: AHQUAuYet7A11CNSE7vqi/4sdLIJ7Csz0wWkeGpK6s++r3Kx111XVLxO tY99i577QN57YuNuUrM5W3CwTRARctTqDWgPiVyGRA== X-Google-Smtp-Source: AHgI3IYwmNsqS9ypDKIoeGTW+MYh/SL4nspCOkT6MtHmxqANfhF6YB2rQia4dlhSJL87bzKDPkxzJqjygxqMj2ZDmcE= X-Received: by 2002:a9d:3de2:: with SMTP id l89mr5992511otc.239.1550005897623; Tue, 12 Feb 2019 13:11:37 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 12 Feb 2019 13:11:36 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 12 Feb 2019 13:11:36 -0800 Message-ID: To: draft-ietf-manet-dlep-multi-hop-extension@ietf.org Cc: "Ratliff, Stanley" , manet@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="000000000000ed7bc00581b8de3b" Archived-At: Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-multi-hop-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:11:45 -0000 --000000000000ed7bc00581b8de3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping! Just wondering where we are with this document. Alvaro. On November 20, 2018 at 3:50:17 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote: 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 =C2=A73.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 =C2=A73 talks about "network hops". Are these the same thing? Please clari= fy. 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 =3D 1, but I think it could be interpreted i= n 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 =C2=A73= .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. --000000000000ed7bc00581b8de3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ping!

Just wondering where we are with this document.

Alvaro.

On November 20, 2018 at 3:50:17 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

Dear authors:

I just finished reading this document.=C2=A0 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.=C2=A0 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).=C2=A0 Whether and how a router uses the Hop Count information or not (already mentioned in =C2=A73.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. =C2=A0Introduction
...
80 =C2=A0 Some modem technologies support connectivity to destinations via
81 =C2=A0 multi-hop forwarding.=C2=A0 DLEP Destination messages can be used to
82 =C2=A0 report such connectivity, see [RFC8175], but do not provide any
83 =C2=A0 information related to the number or capacity of the hops. =C2=A0The
84 =C2=A0 extension defined in this document enables modems to inform routers
85 =C2=A0 when multi-hop forwarding is being used, and routers to request that
86 =C2=A0 modems change multi-hop forwarding behavior.=C2=A0 The extension defined
87 =C2=A0 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.=C2=A0 DLEP Destination messages can be used to report such connectivity, see [RFC8175]..." =C2=A0Where does rfc8175 talk about that?


...
101 2. =C2=A0Extension Usage and Identification

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

[major] Is there a default recommended setting?


...
111 3. =C2=A0Extension Data Items

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

121 3.1.=C2=A0 Hop Count

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

[minor] This section describes the hop count in terms of physical hops, but =C2=A73 talks about "network hops".=C2=A0 Are these the same thing? Pleas= e clarify.

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

[nit] s/direcly/directly

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

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

145 =C2=A0 The format of the Hop Count Data Item is:

147 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
148 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
150 =C2=A0 =C2=A0 =C2=A0 | Data Item Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
151 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
152 =C2=A0 =C2=A0 =C2=A0 |P| =C2=A0Reserved =C2=A0 | =C2=A0 Hop Count =C2=A0 |
153 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

155 =C2=A0 Data Item Type: =C2=A0TBA2

157 =C2=A0 Length: =C2=A04

159 =C2=A0 P:

161 =C2=A0 =C2=A0 =C2=A0The P-bit indicates that a destination is potentially directly
162 =C2=A0 =C2=A0 =C2=A0reachable.=C2=A0 When the P-bit is set, the router MAY request a direct
163 =C2=A0 =C2=A0 =C2=A0link to the associated destination using the Hop Control Data Item
164 =C2=A0 =C2=A0 =C2=A0described below.

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

166 =C2=A0 Reserved:

168 =C2=A0 =C2=A0 =C2=A0MUST be set to zero by the sender (a modem) and ignored by the
169 =C2=A0 =C2=A0 =C2=A0receiver (a router).

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

171 =C2=A0 Hop Count:

173 =C2=A0 =C2=A0 =C2=A0An unsigned 8-bit integer indicating the number of network hops
174 =C2=A0 =C2=A0 =C2=A0required (i.e., number of times a packet will be transmitted) to
175 =C2=A0 =C2=A0 =C2=A0reach the destination indicated in the message.=C2=A0 The special value
176 =C2=A0 =C2=A0 =C2=A0of 255 (0xFF) is used to indicate that the number of hops is an
177 =C2=A0 =C2=A0 =C2=A0unknown number greater than one (1).=C2=A0 This field MUST contain a
178 =C2=A0 =C2=A0 =C2=A0value of at least one (1) if the associated destination is
179 =C2=A0 =C2=A0 =C2=A0reachable.

181 =C2=A0 =C2=A0 =C2=A0A value of zero (0) is used to indicated that processing of a Hop
182 =C2=A0 =C2=A0 =C2=A0Control action, see Section 3.2, has resulted in a destination no
183 =C2=A0 =C2=A0 =C2=A0longer being reachable.=C2=A0 A zero value MUST NOT be used in any
184 =C2=A0 =C2=A0 =C2=A0message 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 =C2=A0According to =C2=A73.2 the Hop Control message is about "a particular destination", so t= he result can only be about it (the destination), and not about any destination ("a destination").=C2=A0 Yes, this is really a nit...but it took me while to go check rfc8175 to get that detail right.

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

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

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

[minor] "Once the change is made, or fails or is rejected..." =C2=A0Why could the change fail?=C2=A0 Why would it be rejected?=C2=A0 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.=C2=A0 It might be worth clarifying that (specially the rejection case) somewhere.

227 =C2=A0 The format of the Hop Control Data Item is:

229 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
230 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
232 =C2=A0 =C2=A0 =C2=A0 | Data Item Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
233 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
234 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Hop Control Actions =C2=A0 =C2=A0 |
235 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

237 =C2=A0 Data Item Type: =C2=A0TBA3

239 =C2=A0 Length: =C2=A04

[major] The Length should be 2.

241 =C2=A0 Hop Control Actions:

243 =C2=A0 =C2=A0 =C2=A0An unsigned 16-bit value with the following meaning:

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

257 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Table 1: Hop Control Actions Values

259 3.2.1. =C2=A0Reset

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

[major] When would a modem not clear all control actions?=C2=A0 IOW, why use SHOULD and not MUST?=C2=A0 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. =C2=A0Terminate

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

[major] s/MAY/may =C2=A0That is a non-Normative statement.

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

279 3.2.3. =C2=A0Direct Connection

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

[minor] ...or send a Destination Down... =C2=A0 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. =C2=A0Suppress Forwarding
...
308 =C2=A0 A modem which receives the Suppress Forwarding Data Item in a Link
309 =C2=A0 Characteristics Request Message MUST suppress multi-hop forwarding
310 =C2=A0 for only the destination indicated in the message.=C2=A0 This means that
311 =C2=A0 data traffic originating from the modem's peer router SHALL be sent
312 =C2=A0 by the modem to the destination indicated in the Link Characteristics
313 =C2=A0 Request Message only when it is one modem hop away.=C2=A0 Notably, data
314 =C2=A0 traffic received by the modem from another modem MAY be forwarded by
315 =C2=A0 the modem per its normal processing.=C2=A0 Results are provided as
316 =C2=A0 described above.

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

318 4. =C2=A0Security Considerations

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

324 =C2=A0 [RFC8175].=C2=A0 The approach taken to Security in that document applies
325 =C2=A0 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. =C2=A0A rogue (or compromised) router can take advantage of this. =C2=A0A 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.=C2=A0 However, I think that the point still needs to be called out specifically because of the new functionality introduced.


...
364 5.3.=C2=A0 Hop Control Actions Registry

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

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


...
409 6.2. =C2=A0Informative References

411 =C2=A0 [RFC8126] =C2=A0Cotton, M., Leiba, B., and T. Narten, "Guidelines for
412 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Writing an IANA Considerations Section in RFCs", BCP 26,
413 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 8126, DOI 10.17487/RFC8126, June 2017,
414 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.r= fc-editor.org/info/rfc8126>.

[major] This reference should be Normative.
--000000000000ed7bc00581b8de3b-- From nobody Tue Feb 12 13:13:02 2019 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3212DF71; Tue, 12 Feb 2019 13:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.262 X-Spam-Level: *** X-Spam-Status: No, score=3.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQv8Me6d2eqF; Tue, 12 Feb 2019 13:12:57 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FD1128B36; Tue, 12 Feb 2019 13:12:54 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id 32so175348ota.12; Tue, 12 Feb 2019 13:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/FMAhz42wx/l+XiBg7ltEEyknSw/WSyJewbwnmBnJSI=; b=ouH8Sq+GeGi1RzTOmqAArzM4XyR3AMw6DonSS4d+oePM+UvOVZ08QUd56qqfSVtOSH 8mNCwdGp+xRHwEBK3z1T6wcl2IpanXdghP0qoWRWdxhwUcvQ7TMGmslA9Bxg/ZyqYGk2 /HA9vfwW1pvnkEJiJMrwaYbTgV9DsD3Y+yWYHRMqHJ+EKhntN+lMRrnVe3KkuXMLbD7q yxSKXguDOPeoI5mTi5+XQOhs7foCKukC2zp29wUQz39FbGRppiBz01/e9BM/aGgs+AlX XMhLrNk1YcGYYwf66CK5EuXV17v2tTVBZvUD0NmOyRspWeIcedZgJdjk62Sjl2rapFr6 MYAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/FMAhz42wx/l+XiBg7ltEEyknSw/WSyJewbwnmBnJSI=; b=Z8pnNda3wSGpDqxRJgc/QUCw5FRIItHUl9Si3fRP2/S7FmfvIEDvRrq3AeA7CP5yW0 hE++WDwk0XoVxpD5mJjqEk9NSo/NeTRvyINLyj+iPZsDd+1nznn9CtXsKl6ODfJBNLpf JKtE47xIIQwhWfFsMfuLbXH8Cvqi8OddEidWFJyCspHayFg6HW+b8zmdJU0fGbGEJKeX zqwL34wSBaDvn6UtMxxBT5+qMvW/Trxgi1tbSTnhcYb8PdyMGpZTQkovFQJJwesVKQPe ttn01w4sxdZRcAUTH9XS+S6wbefkgfFPHoT49Cu7zu/F5+4dGZbGehwLT1RLcxmtmP9b vgzQ== X-Gm-Message-State: AHQUAuaJr2MnTnbzdAOYh+Yq+MEKex/XCKXtUX21K/a8aMkE9QYaZTIr dyutmLX+AMJjDm969f8PLHhViNddl1vEojZe4ujIhw== X-Google-Smtp-Source: AHgI3IaGJTmzVyCyR4VYMKBfxr5xIxO6K/PYY3kSXzuc+1YpSivhf+Y8X/y+YFhTxU0Eur60gZE9IyvGf2KnTCkFUy0= X-Received: by 2002:a9d:282:: with SMTP id 2mr5772541otl.287.1550005973011; Tue, 12 Feb 2019 13:12:53 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 12 Feb 2019 13:12:52 -0800 From: Alvaro Retana In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801E5557AFA@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801E5557AFA@tss-server1.home.tropicalstormsoftware.com> MIME-Version: 1.0 Date: Tue, 12 Feb 2019 13:12:52 -0800 Message-ID: To: "draft-ietf-manet-dlep-pause-extension@ietf.org" Cc: "manet@ietf.org" , Rick Taylor , Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="0000000000006bd2c80581b8e3a7" Archived-At: Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:13:00 -0000 --0000000000006bd2c80581b8e3a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping! Where are we with this document? I haven=E2=80=99t seen related discussion= to Rick=E2=80=99s point either. Alvaro. On November 17, 2018 at 5:13:26 AM, Rick Taylor ( rick@tropicalstormsoftware.com) wrote: (Sorry for the top post=E2=80=A6 damn outlook) Hi Authors, If I remember correctly =E2=80=93 and there has been a bit of delay with th= is draft, with the CCAMP/not-CCAMP move =E2=80=93 the intention of the authors= was to make the pause extension simple and self-contained, avoiding getting caught up in the DiffServ Aware/Credit Window/Sub-TLV draft reference reorganization that has happened. If this is still the intention, then I agree with Alvaro that trying to define generic Sub-TLVs in this document is unnecessary, and should be removed. However, given the DiffServ Aware/CW drafts have almost caught up with the Pause extension, do the authors/WG want to rethink their intention? Cheers, Rick *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Alvaro Retana *Sent:* 16 November 2018 22:00 *To:* draft-ietf-manet-dlep-pause-extension@ietf.org *Cc:* manet@ietf.org; Mobile Ad-hoc Networks Working Group *Subject:* [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04 Dear authors: I just finished reviewing this document. I have several comments (see below) and a couple of significant issues, which I'm mentioning in the next 2 bullets. I will wait for these to be addressed before starting the IETF LC. (1) This is a comment for the WG (not just the authors): This is the first draft that specifies a Sub Data Item. Given that rfc8175 says that the Value in a Data Item "contains data specific to a particular Data Item", I don't think it is necessary to define a generic DLEP Sub Data Item.. However, not all future extensions may follow the same model. Is there a need/interest in normatively specifying the characteristics of a Sub Data Item? (2) Security Considerations: The extension in itself doesn't change the security characteristics of DLEP, I agree with that. However, I think that the functionality does -- please see specific comments below. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1. Introduction .... 78 The base DLEP specification does not include any data plane flow 79 control capability. Various flow control methods are possible, e.g., 80 see [I-D.ietf-manet-credit-window]. The extension defined in this ... [minor] A reference to something other than I-D.ietf-manet-credit-window (expired, etc.) may be more appropriate. ... 103 2. Extension Usage and Identification 105 The use of the Control Plane Based Pause Extension SHOULD be 106 configurable. To indicate that the Control Plane Based Pause 107 Extension is to be used, an implementation MUST include the Control 108 Plane Based Pause Extension Type Value in the Extensions Supporte= d 109 Data Item. The Extensions Supported Data Item is sent and processed 110 according to [RFC8175]. [minor] "The use of the Control Plane Based Pause Extension SHOULD be configurable." Is there a default recommended configuration? ... 201 3.1.1. Queue Parameter Sub Data Item ... 234 Sub Data Item Type: 236 A 16-bit unsigned integer that indicates the type and 237 corresponding format of the Sub Data Item's Value field. Sub Data 238 Item Types are scoped within the Data Item in which they are 239 carried, i.e., the Sub Data Item Type field MUST be used together 240 with the Data Item Type to identify the format of the Sub Data 241 Item. This field MUST be set to one (1) for the Queue Parameter 242 Sub Data Item. [minor] "...the Sub Data Item Type field MUST be used together with the Data Item Type to identify the format of the Sub Data Item." It sounds as if this text wants to specify the behavior for *any* Sub Data Item Type. Please reword to be specific in to this document. [Also, see my note at the top.] [major] Please define a registry for the Sub Data Item Types to be used with the Queue Parameters Data Item. 244 Length: Variable 246 Copying [RFC8175], Length is the number of octets in the sub data 247 item, excluding the Type and Length fields. [minor] Copying? As far as I can tell, rfc8175 doesn't define any sub data items. 249 Queue Index: 251 An 8-bit field indicating the queue index of the queue parameter 252 represented in the sub data item. Only the first instance a a 253 particular Queue Index value is meaningful. Subsequent sub data 254 items containing the same Queue Index values, if present, MAY be 255 logged via a management interface and MUST otherwise be ignored. [nit] s/a a/of a [minor] Pause and Restart reserve the Queue Index of 255 to indicate "all traffic", but that value is not reserved here. Should it? ... 269 DS Field Qn: 271 The data item contains a sequence of 8 bit DS Fields. The 272 position in the sequence identifies the associated queue index= . 273 The number of DS Fields present should equal the sum of all Nu= m 274 DSCPs field values. [major] "should equal", or "MUST equal"? If the number of DS Fields doesn't add up, should the sub data item be considered invalid? I assume that would invalidate the whole data item. ... 286 3.2. Pause ... 293 A modem may indicate that traffic is to be suppressed on a device 294 wide or destination specific basis. An example of when a modem might 295 use device wide indications is when output queues are shared across 296 all destinations, and destination specific might be used when per 297 destination queuing is used. To indicate that suppression applies to 298 all destinations, a modem MAY send the Pause Data Item in a Session 299 Update Message. To indicate that suppression applies to a particular 300 destination a modem MAY send the Pause Data Item in a Destination 301 Update Message. [major] I think that the two MAYs above are out of place. I understand that sending the Pause Data Item in the corresponding Update Message is optional, but the sentences say that "To indicate that suppression applies...", which means that if the Pause Data Item is not sent, then there is no indication...so sending it is not optional. ... 312 A router which receives the Pause Data Item MUST cease sending th= e 313 identified traffic to the modem. This may of course translate into 314 the router's queues exceeding their own thresholds. If a receive= d 315 Pause Data Item contains a Queue Index value other than 0, 255, or a 316 queue index established by a Session Initialization or Session Update 317 Message, the router MUST terminate the session with a Status Data 318 Item indicating Invalid Data. [major] Terminating the session seems drastic to me given that the wrong index relates to a single destination and the action has an impact over all= . ... 347 3.3. Restart ... 354 The sending of this data item parallels the Pause Data Item, see the 355 previous section, and follows the same rules. This includes that to 356 indicate that transmission can resume to all destinations, a mode= m 357 MAY send the Restart Data Item in a Session Update Message. It also 358 includes that to indicate that transmission can resume to a 359 particular destination a modem MAY send the Pause Restart Item in a 360 Destination Update Message. Finally, the same rules apply to queue 361 indexes. [major] Same comment as above about the MAYs. 363 A router which receives the Restart Data Item SHOULD resume 364 transmission of the identified traffic to the modem. [minor] Should the Restart always follow a Pause? I think that is the intent. The question is whether it MUST happen that way? As is, the text leaves the possibility open for a modem to send a Restart without having sent a Pause. I think that is ok, just checking... ... 384 4. Security Considerations 386 The extension introduces a new mechanism for flow control between a 387 router and modem using the DLEP protocol. The extension does not 388 inherently introduce any additional threats above those documented in 389 [RFC8175]. The approach taken to Security in that document applies 390 equally when running the extension defined in this document. [major] The extension gives the modem the ability to stop the traffic sent by a router.. A rogue or compromised modem could stop traffic sent by the attached router. Protecting the modem is out of scope, but I think the threat should at least be pointed out. rfc8175 already mentions the risk that "an attacker might pretend to be a DLEP participant...by injection of DLEP Messages once a session has been established", which is related to this case. However, I think that the point still needs to be called out specifically because of the new functionality introduced. ... 466 Appendix A. Acknowledgments 468 The sub data item format was inspired by Rick Taylor's "Data Item 469 Containers". [nit] Is this a draft? Reference? --0000000000006bd2c80581b8e3a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ping!

Where are we with this document?=C2=A0 I haven=E2=80=99t seen= related discussion to Rick=E2=80=99s point either.

Alvaro.

= On November 17, 2018 at 5:13:26 AM, Rick Taylor (rick@tropicalstormsoftware.com) wrote:

(Sorry for the top post= =E2=80=A6 damn outlook)

=C2=A0

Hi Authors,

=C2=A0

If I remember correctly = =E2=80=93 and there has been a bit of delay with this draft, with the CCAMP= /not-CCAMP move =E2=80=93 the intention of the authors was to make the paus= e extension simple and self-contained, avoiding getting caught up in the Dif= fServ Aware/Credit Window/Sub-TLV draft reference reorganization that has h= appened.

=C2=A0

If this is still the inte= ntion, then I agree with Alvaro that trying to define generic Sub-TLVs in t= his document is unnecessary, and should be removed.

=C2=A0

However, given the DiffSe= rv Aware/CW drafts have almost caught up with the Pause extension, do the a= uthors/WG want to rethink their intention?

=C2=A0

Cheers,

=C2=A0

Rick

=C2=A0

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Alvaro Retana
Sent: 16 November 2018 22:00
To: draft-ietf-manet-dlep-pause-extension@ietf.org
Cc: manet@ietf.org; Mobile Ad-= hoc Networks Working Group
Subject: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-= 04

=C2=A0

Dear authors:

=C2=A0

I just finished reviewing this docume= nt.=C2=A0 I have several comments (see below) and a couple of significant i= ssues, which I'm mentioning in the next 2 bullets.=C2=A0 I will wait for these to be addressed before starting the IETF LC.

=C2=A0

(1) This is a comment for the WG (not= just the authors):

=C2=A0

This is the first draft that specifie= s a Sub Data Item.=C2=A0 Given that rfc8175 says that the Value in a Data I= tem "contains data specific to a particular Data Item", I don'= ;t think it is necessary to define a generic DLEP Sub Data Item..=C2=A0 Howev= er, not all future extensions may follow the same model.=C2=A0 Is there a n= eed/interest in normatively specifying the characteristics of a Sub Data It= em?

=C2=A0

(2) Security Considerations: =C2=A0Th= e extension in itself doesn't change the security characteristics of DL= EP, I agree with that.=C2=A0 However, I think that the functionality does -- please see specific comments below.

=C2=A0

Thanks!

=C2=A0

Alvaro.

=C2=A0

=C2=A0

[Line numbers from idnits.]

=C2=A0

...

70=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.=C2=A0 Introduction

....

78=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The base DLEP specification does not include any data plane f= low

79=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 control capability.=C2=A0 Various flow control methods are po= ssible, e.g.,

80=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 see [I-D.ietf-manet-credit-window].=C2=A0 The extension defin= ed in this

...

=C2=A0

[minor] A reference to something othe= r than I-D.ietf-manet-credit-window (expired, etc.) may be more appropriate= .

=C2=A0

=C2=A0

...

103=C2= =A0=C2=A0=C2=A0=C2=A0 2.=C2=A0 Extension Usage and Identification

=C2=A0

105=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 The use of the Control Plane Based Pause Extension SHOULD be<= /span>

106=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 configurable.=C2=A0 To indicate that the Control Plane Based = Pause

107=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Extension is to be used, an implementation MUST include the C= ontrol

108=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Plane Based Pause Extension Type Value in the Extensions Supp= orted

109=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Data Item.=C2=A0 The Extensions Supported Data Item is sent a= nd processed

110=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 according to [RFC8175].

=C2=A0

[minor] "The use of the Control = Plane Based Pause Extension SHOULD be configurable." =C2=A0Is there a = default recommended configuration?

=C2=A0

=C2=A0

...

201=C2= =A0=C2=A0=C2=A0=C2=A0 3.1.1.=C2=A0 Queue Parameter Sub Data Item

...

234=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Sub Data Item Type:

=C2=A0

236=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0A 16-bit unsigned integer that indicates the typ= e and

237=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0corresponding format of the Sub Data Item's = Value field.=C2=A0 Sub Data

238=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Item Types are scoped within the Data Item in wh= ich they are

239=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0carried, i.e., the Sub Data Item Type field MUST= be used together

240=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0with the Data Item Type to identify the format o= f the Sub Data

241=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Item.=C2=A0 This field MUST be set to one (1) fo= r the Queue Parameter

242=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Sub Data Item.

=C2=A0

[minor] "...the Sub Data Item Ty= pe field MUST be used together with the Data Item Type to identify the form= at of the Sub Data Item." =C2=A0It sounds as if this text wants to specify the behavior for *any* Sub Data Item Type.=C2=A0 Please reword to = be specific in to this document. =C2=A0[Also, see my note at the top.]

=C2=A0

[major] Please define a registry for = the Sub Data Item Types to be used with the Queue Parameters Data Item.

=C2=A0

244=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Length: =C2=A0Variable

=C2=A0

246=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Copying [RFC8175], Length is the number of octet= s in the sub data

247=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0item, excluding the Type and Length fields.

=C2=A0

[minor] Copying?=C2=A0 As far as I ca= n tell, rfc8175 doesn't define any sub data items.

=C2=A0

249=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Queue Index:

=C2=A0

251=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0An 8-bit field indicating the queue index of the= queue parameter

252=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0represented in the sub data item.=C2=A0 Only the= first instance a a

253=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0particular Queue Index value is meaningful.=C2= =A0 Subsequent sub data

254=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0items containing the same Queue Index values, if= present, MAY be

255=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0logged via a management interface and MUST other= wise be ignored.

=C2=A0

[nit] s/a a/of a

=C2=A0

[minor] Pause and Restart reserve the= Queue Index of 255 to indicate "all traffic", but that value is = not reserved here.=C2=A0 Should it?

=C2=A0

=C2=A0

...

269=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 DS Field Qn:

=C2=A0

271=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0The data item contains a sequence of 8 bit DS Fi= elds.=C2=A0 The

272=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0position in the sequence identifies the associat= ed queue index.

273=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0The number of DS Fields present should equal the= sum of all Num

274=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0DSCPs field values.

=C2=A0

[major] "should equal", or = "MUST equal"?=C2=A0 If the number of DS Fields doesn't add up= , should the sub data item be considered invalid?=C2=A0 I assume that would= invalidate the whole data item.

=C2=A0

=C2=A0

...

286=C2= =A0=C2=A0=C2=A0=C2=A0 3.2.=C2=A0 Pause

...

293=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 A modem may indicate that traffic is to be suppressed on a de= vice

294=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 wide or destination specific basis.=C2=A0 An example of when = a modem might

295=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 use device wide indications is when output queues are shared = across

296=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 all destinations, and destination specific might be used when= per

297=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 destination queuing is used.=C2=A0 To indicate that suppressi= on applies to

298=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 all destinations, a modem MAY send the Pause Data Item in a S= ession

299=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Update Message.=C2=A0 To indicate that suppression applies to= a particular

300=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 destination a modem MAY send the Pause Data Item in a Destina= tion

301=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Update Message.

=C2=A0

[major] I think that the two MAYs abo= ve are out of place.=C2=A0 I understand that sending the Pause Data Item in= the corresponding Update Message is optional, but the sentences say that "To indicate that suppression applies...", which means = that if the Pause Data Item is not sent, then there is no indication...so s= ending it is not optional.

=C2=A0

=C2=A0

...

312=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 A router which receives the Pause Data Item MUST cease sendin= g the

313=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 identified traffic to the modem.=C2=A0 This may of course tra= nslate into

314=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 the router's queues exceeding their own thresholds.=C2=A0= If a received

315=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Pause Data Item contains a Queue Index value other than 0, 25= 5, or a

316=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 queue index established by a Session Initialization or Sessio= n Update

317=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Message, the router MUST terminate the session with a Status = Data

318=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Item indicating Invalid Data.

=C2=A0

[major] Terminating the session seems= drastic to me given that the wrong index relates to a single destination a= nd the action has an impact over all.

=C2=A0

=C2=A0

...

347=C2= =A0=C2=A0=C2=A0=C2=A0 3.3.=C2=A0 Restart

...

354=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 The sending of this data item parallels the Pause Data Item, = see the

355=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 previous section, and follows the same rules.=C2=A0 This incl= udes that to

356=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 indicate that transmission can resume to all destinations, a = modem

357=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 MAY send the Restart Data Item in a Session Update Message.= =C2=A0 It also

358=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 includes that to indicate that transmission can resume to a

359=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 particular destination a modem MAY send the Pause Restart Ite= m in a

360=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Destination Update Message.=C2=A0 Finally, the same rules app= ly to queue

361=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 indexes.

=C2=A0

[major] Same comment as above about t= he MAYs.

=C2=A0

363=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 A router which receives the Restart Data Item SHOULD resume

364=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 transmission of the identified traffic to the modem.

=C2=A0

[minor] Should the Restart always fol= low a Pause?=C2=A0 I think that is the intent.=C2=A0 The question is whethe= r it MUST happen that way?=C2=A0 As is, the text leaves the possibility open for a modem to send a Restart without having sent a Pause.=C2=A0 I th= ink that is ok, just checking...

=C2=A0

=C2=A0

...

384=C2= =A0=C2=A0=C2=A0=C2=A0 4.=C2=A0 Security Considerations

=C2=A0

386=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 The extension introduces a new mechanism for flow control bet= ween a

387=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 router and modem using the DLEP protocol.=C2=A0 The extension= does not

388=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 inherently introduce any additional threats above those docum= ented in

389=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 [RFC8175].=C2=A0 The approach taken to Security in that docum= ent applies

390=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 equally when running the extension defined in this document.<= /span>

=C2=A0

[major] The extension gives the modem= the ability to stop the traffic sent by a router..=C2=A0 A rogue or compro= mised modem could stop traffic sent by the attached router.=C2=A0 Protecting the modem is out of scope, but I think the threat should at lea= st be pointed out.

=C2=A0

rfc8175 already mentions the risk tha= t "an attacker might pretend to be a DLEP participant...by injection o= f DLEP Messages once a session has been established", which is related to this case.=C2=A0 However, I think that the point still needs to= be called out specifically because of the new functionality introduced.

=C2=A0

=C2=A0

...

466=C2= =A0=C2=A0=C2=A0=C2=A0 Appendix A.=C2=A0 Acknowledgments

=C2=A0

468=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 The sub data item format was inspired by Rick Taylor's &q= uot;Data Item

469=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 Containers".

=C2=A0

[nit] Is this a draft?=C2=A0 Referenc= e?

=C2=A0
--0000000000006bd2c80581b8e3a7-- From nobody Tue Feb 12 13:14:23 2019 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC59D12F1A6; Tue, 12 Feb 2019 13:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8WpYITOhGzc; Tue, 12 Feb 2019 13:14:16 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5D9128B36; Tue, 12 Feb 2019 13:14:13 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id n71so201975ota.10; Tue, 12 Feb 2019 13:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Ge/+bo2j1FIGGDbZ5i9CSLK4ShWpRcC2Q6f2ue/WQLI=; b=FM4iSbyt+7PNfXGzA2T2N7Jc5bo4jWyt62ZCdlVl0pfIA0dzzDexqXs9zzytnzDldW 8stwyIsdMuvwG9CQ3WoWowOMK86FkZrSryoo0jgwThAqI2V1Ph2Md7BrWT/K8pBEIoUY iqRHlsyGyGj7nMdTJ1arl5jGQAz82NOXKFsVGWirshaDMFwUjXjdWodTpQMdUwpQ79B+ W1w5p9VYFmDycPEEPDcxyUgNfv9VC3bVrsR8n6Hfeqg6MWUT/PtCQl/QnRca92Ow7RYI fYLW3Jgz45N2qcAjlVPklM+aIv6tVcpUPgdoX8Tr72rG7i4mq7qFSjx2mgF2AZOIwrs1 vxIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Ge/+bo2j1FIGGDbZ5i9CSLK4ShWpRcC2Q6f2ue/WQLI=; b=nt5uQHvzIhmL+vWvtoAHLAbPzBS7+VQxqkTDxazdVaroPduusuq3cd+980RgM7aJ5t ph65IIpLmkKizWBJ+kHreIPVy+m872PTnadLATL09Tn7yKxuXvmcYI/ZwDqdmiGpuMdK 4u7wtQEopSUeCEwywm7N1B11dTs5EKFRk5QhFLbIRlVEC9Dq67HUTKDwViIBTyTdnWI4 MiHiSDrE0JWk5FTBh/Y96DmrYZMWEsRnFmMRKmQ5Y2BLnTjHzeVdqOK4oll/SQIjGr3i UYenIOuZRPQj7tAvIuv6L1fCfCgbcBlwd9R/zQyx11uStVh+YbDK0V/fybx/X/a1tkAm oLtg== X-Gm-Message-State: AHQUAuYtGlA9P9UFhtYqNre4Gl+AJUo4Ca36kmIXQyRPIKOLy0d0AVy/ MxVXGhrIRjgV6qy3sTpaAPlFbQcY5SWZEGP8hQDdBg== X-Google-Smtp-Source: AHgI3IYOBKk3sg4vkdO1mLsPj7ChERLK2EC7T9Bl16WyPLAeul1oeWePUXtTlor7BKKOWergT5JK1Um8I2GHiAXJCCY= X-Received: by 2002:a9d:4c0f:: with SMTP id l15mr6067048otf.139.1550006052621; Tue, 12 Feb 2019 13:14:12 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 12 Feb 2019 13:14:12 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 12 Feb 2019 13:14:12 -0800 Message-ID: To: draft-ietf-manet-dlep-lid-extension@ietf.org Cc: Mobile Ad-hoc Networks Working Group , manet@ietf.org, Justin Dean Content-Type: multipart/alternative; boundary="0000000000002a95870581b8e8c2" Archived-At: Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-lid-extension-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:14:22 -0000 --0000000000002a95870581b8e8c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping! Where are we on this document? Alvaro. On November 21, 2018 at 12:00:50 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote: 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 =C2=A72/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. --0000000000002a95870581b8e8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ping!

Where are we on this document?

Alvaro.

On November = 21, 2018 at 12:00:50 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

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.=C2=A0 Please also take a look at my comments in the text.

(1) What problem are you trying to solve?=C2=A0 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.=C2=A0 I think I now have an understanding -- in general, I think the document could benefit form a little more content explaining the use cases. =C2=A0[See more below.]

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

(3) Terminate-resulting Errors and Security.=C2=A0 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.=C2=A0 Please call these cases out in the Security Considerations section as potential risks.=C2=A0 The Shepherd's writeup mentions one implementation, so it is probably too late to change the operation to minimize the risk. =C2=A0[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 =C2=A0 There exists a class of modems that would benefit from supporting the
14 =C2=A0 Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not present a
15 =C2=A0 single Layer 2 network domain as required by DLEP.=C2=A0 Such devices may
16 =C2=A0 be:

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

...
34 =C2=A0 Note:

36 =C2=A0 o =C2=A0This document is intended as an extension to the core DLEP
37 =C2=A0 =C2=A0 =C2=A0specification, and readers are expected to be fully conversant
38 =C2=A0 =C2=A0 =C2=A0with the operation of core DLEP.

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


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

108 =C2=A0 A Layer 3 destination may be an attached DLEP router, in the case of
109 =C2=A0 a modem that provides Layer 3 wide area network connectivity between
110 =C2=A0 devices, or a logical destination that describes a set of attached
111 =C2=A0 subnets, when referring to some upstream backbone network
112 =C2=A0 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.=C2=A0 I'm not sure that it will be clear to other readers (e.g. directorate reviewers, IESG).=C2=A0 Consider expanding on the use cases.

I'm missing how the reference to "some upstream backbone network infrastructure" come= s into play here.=C2=A0 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.=C2=A0 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. =C2=A0Requirements

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

[major] Please use the template from rfc8174.

120 2. =C2=A0Operation

122 =C2=A0 To refer to a Layer 3 DLEP Destination, the DLEP session participant
123 =C2=A0 adds a Link Identifier Data Item (Section 3.2) to the relevant
124 =C2=A0 Destination Message, and (as usual) includes a MAC Address Data Item.
125 =C2=A0 When paired with a Link Identifier Data Item, the MAC Address Data
126 =C2=A0 Item MUST contain the MAC address of the last reachable node in the
127 =C2=A0 Layer 2 domain beyond which the Layer 3 DLEP Destination resides.
128 =C2=A0 For example, if the over-the-air network is not a single Layer 2
129 =C2=A0 domain, the MAC Address Data Item might be the address of the LAN-
130 =C2=A0 side interface of the local modem.=C2=A0 Alternatively, when used with
131 =C2=A0 some kind of backbone infrastructure, the MAC Address Data Item would
132 =C2=A0 be the address of the last device reachable on the local Layer 2
133 =C2=A0 domain. =C2=A0However, how such remote destinations are discovered is
134 =C2=A0 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.=C2=A0 Not a wa= rm 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.=C2=A0 Even though the discovery of the "last reachable node" is out of scope, it is important to kno= w which node we're talking about!!=C2=A0 It has to be crystal clear because of the MUST above.

136 =C2=A0 As only modems are initially aware of Layer 3 DLEP Destinations, Link
137 =C2=A0 Identifier Data Items referring to a new link MUST first appear in a
138 =C2=A0 DLEP Destination Up Message from the modem to the router.=C2=A0 Once a
139 =C2=A0 link has been identified in this way, Link Identifier Data Items MAY
140 =C2=A0 be used by either DLEP participant during the lifetime of a DLEP
141 =C2=A0 session. =C2=A0Because of this, a router MUST NOT send a DLEP Destination
142 =C2=A0 Announce Message containing a Link Identifier Data Item referring to
143 =C2=A0 a link that has not been mentioned in a prior DLEP Destination Up
144 =C2=A0 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?=C2=A0 It seems to me that this case should result in an "Invalid Data" status, right?=C2=A0 If so, then I think it is important to call out as a risk.

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

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

157 =C2=A0 When the DLEP peer router wishes to forward packets to the Layer 3
158 =C2=A0 destination or subnet, the MAC address associated with the link MUST
159 =C2=A0 be used as the Layer 2 destination of the packet if it wishes to use
160 =C2=A0 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"?=C2=A0 If so, then this seems to be a much better explanation than what was included above.

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

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

169 =C2=A0 If the last reachable Layer 2 device is not the DLEP peer modem, then
170 =C2=A0 the modem SHOULD announce a DLEP Destination with the required MAC
171 =C2=A0 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. =C2=A0Identifier Restrictions

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

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

[major] This is another case where the session could be terminated if the wrong length is used...=C2=A0 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.=C2=A0 Why is the extra Data Item required? =C2=A0[It may be too late to change anything, I'm mostly wondering why the extra moving parts.]

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

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

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

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

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

199 2.2. =C2=A0Negotiation

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

[major] s/MAY/may

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

[major] "SHOULD NOT immediately terminate" =C2=A0 But it may do it later?=C2=A0 Are there cases where it would/should?=C2=A0 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"?=C2=A0 From rfc8175 it loo= ks like you mean Data Items in a Session Update Message.=C2=A0 Please be more specific.=C2=A0 In fact, it would be very nice if you expanded in how to do it.

[minor] "make a best guess" =C2=A0It 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.=C2=A0 Is that a correct interpretation?=C2=A0 IOW, it is not really be a guess...

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


...
232 3.1.=C2=A0 Link Identifier Length Data Item

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

239 =C2=A0 The Link Identifier Length Data Item MAY be used during Session
240 =C2=A0 Initialization, contained in a Session Initialization Response
241 =C2=A0 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?=C2=A0 Should it be considered Invalid Data or maybe an Unexpected Message, or ?? =C2=A0Specifying 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. =C2=A0Security Considerations

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

287 =C2=A0 None of the features introduced by this extension require extra
288 =C2=A0 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 =C2=A72/2.1 above. =C2=A0While 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. =C2=A0Informative References

320 =C2=A0 [RFC5226] =C2=A0Narten, T. and H. Alvestrand, "Guidelines for Writing an
321 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA Considerations Section in RFCs", RFC 5226,
322 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC5226, May 2008,
323 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.r= fc-editor.org/info/rfc5226>.

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


--0000000000002a95870581b8e8c2--