From nobody Tue Jun 4 14:59:57 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 4D2D1120242; Tue, 4 Jun 2019 14:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_HELO_NONE=0.001, 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 6Gb1KKwqdTlL; Tue, 4 Jun 2019 14:59:51 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 8AFA5120397; Tue, 4 Jun 2019 14:59:50 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id b8so2602792edm.11; Tue, 04 Jun 2019 14:59:50 -0700 (PDT) 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=Fou7O1UO37XVxRjFgyAx8K2bFLFuzeV62MUnlqBHgi8=; b=l3V4ESBgkA8xlbwjvu1Z1yJclZrOTJXFVNjlqRMmaJE4V+Ctnl8g1yXi0+OzrIIxUz 703GTGKxoFo8bj8w4c+UqpqUZINERyz5oPF5ksj2vZCcuFO/8vq6c3HJChG7ATU7X+PX xJvfCWgx1GqbMfOz0Hm11nildXYLbfVML5IxlSWtcHLpun3GkVxXpv9hFubtIP7aYqqE jkKFLMRbpNpQv6XqE9xzna82eNlU/11v8NR6ERKXr2yeHrfogPOtf5j/TNgrUTzpUXRE cz15trnZki0+cxfs8xfv4E0VDQqRBsjgFI9f/7TlKQQ8fVzpSVC0FSTEIDpMUJ25zglW 9boA== 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=Fou7O1UO37XVxRjFgyAx8K2bFLFuzeV62MUnlqBHgi8=; b=RFntp05CI9Agu6SSrDoXIx8CRwGFlc5aXJViyb+IsFqmC8PI9aKlsFb3+yJWoGneFp 1t1cxCGxYqzNPznIePqIkt37gi3he94v+UJafzFkeXNdoaWN282MUN5ThJlYsAKOELKw KlY78x7J6VHZpgu8CZmxMQcEzUqPZfeFA0459ybfcfiy7Ww7YtCOV2ZQdhYa9FCM49Fr 69wdBSaH62PJLqGxY+pfWgesCQyOleAkLnLyz0reGD1UZUdlj/XkW/apiVsDyU8mn8sq v6s8eXL7y+5v55Y9fzaCD/XcEfYmySN/lXmBjy4Ae1UjOL6JsDNy+VhE9X1xnO7iMRFQ Wavg== X-Gm-Message-State: APjAAAXpBeCtKJitrqmwDTxMDeogfwM4leAT/k0dathjEmFFVD5Hwo6H xHbB2uo+tRz4lkxAlzORSn86j+ExJdYm8tTK21WxVA== X-Google-Smtp-Source: APXvYqwtnnaTZwN39h3i1lTJaJV7mmUZjagt1mYTLFjMe+c1u3qdUnTarSWxXbQnf9yOqPaVhFf2JW/LmkmKmps2+qc= X-Received: by 2002:a17:906:d799:: with SMTP id pj25mr24362265ejb.271.1559685588893; Tue, 04 Jun 2019 14:59:48 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Jun 2019 14:59:48 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 4 Jun 2019 14:59:48 -0700 Message-ID: To: draft-ietf-manet-dlep-lid-extension@ietf.org Cc: Justin Dean , manet@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="0000000000007cc696058a8699cc" 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, 04 Jun 2019 21:59:55 -0000 --0000000000007cc696058a8699cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping!! It=E2=80=99s now been more than 6 months! ... On February 12, 2019 at 4:14:12 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote: 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. --0000000000007cc696058a8699cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ping!!

It=E2=80=99s now been more than 6 months!

...

On February 12, 2019 at 4:14:12 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

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=A0Please 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=A0Please 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=A0I'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" comes 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", "SHALL", "SHALL = NOT",
117 =C2=A0 "SHOULD", "SHOULD= NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this<= /span>
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=A0 Operation

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=A0 However, 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 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.=C2=A0 Even though the discovery of the "last reachable node" is out of scope, it is important to know 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=A0 Because 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=A0 Identifier 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=A0Call 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=A0Why 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=A0A 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=A0 However, 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=A0 By 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=A0 A 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 looks 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=A0IOW, 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=A0 Security 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=A0 This
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=A0 Informative 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.
--0000000000007cc696058a8699cc-- From nobody Thu Jun 6 09:57:03 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3C120025; Thu, 6 Jun 2019 09:57:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155984022115.1971.8167616474104414082.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2019 09:57:01 -0700 Archived-At: Subject: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-manet-dlep-pause-extension-07=3A_=28with_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 16:57:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion! From nobody Thu Jun 6 11:22:44 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 88EAB1200C1; Thu, 6 Jun 2019 11:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 7f3qZGvDIXTy; Thu, 6 Jun 2019 11:22:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C4F12006E; Thu, 6 Jun 2019 11:22:30 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x56IMPrR026092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Jun 2019 14:22:28 -0400 Date: Thu, 6 Jun 2019 13:22:25 -0500 From: Benjamin Kaduk To: Lou Berger Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org, The IESG , manet-chairs@ietf.org Message-ID: <20190606182224.GC23396@kduck.mit.edu> References: <155494445891.22757.7399588752085896470.idtracker@ietfa.amsl.com> <20190506224055.GX19509@kduck.mit.edu> <10c43c45-877d-842d-b527-8ff0dd9cb600@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10c43c45-877d-842d-b527-8ff0dd9cb600@labn.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) 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: Thu, 06 Jun 2019 18:22:36 -0000 Hi Lou, Sorry for the long delay here; I'm in the process of moving from St. Louis to Seattle and have had to take a bunch of time off in the process. On Tue, May 07, 2019 at 10:34:57AM -0400, Lou Berger wrote: > Please see responses below... > > On 5/6/2019 6:40 PM, Benjamin Kaduk wrote: > > On Sun, May 05, 2019 at 09:22:16PM -0400, Lou Berger wrote: > >> Hi, > >> My apologies, I thought I responded to this, but can't seem to find the > >> response (hopefully my responses are consistent if I did!). > >> > >> On 4/10/19 9:00 PM, Benjamin Kaduk via Datatracker wrote: > >>> Benjamin Kaduk has entered the following ballot position for > >>> draft-ietf-manet-dlep-pause-extension-06: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the > >>> values 0-3 are assigned, leaving 4-16k usable. How will future values be > >>> assigned? > >>> > >> A future revision or update of this document. We discussed a IANA > >> registry, but thought it overkill as future additions seem quite unlikely. > > Okay. The Discuss was just to make sure it was considered in some fashion; > > we do have a bunch of documents that explictly note "additional values are > > to be allocated by updates to this specification" but I do not insist on > > it. > > > >>> In Section 3.1.1: > >>> > >>> DS Field Qn: > >>> > >>> The data item contains a sequence of 8 bit DS Fields. The number > >>> of DS Fields present MUST equal the sum of all Num DSCPs field > >>> values. > >>> > >>> Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global > >>> for this queue index, so there would just be one of them and no need to > >>> take a sum. > >> It's just saying that more than one DSCP can match to a single queue > >> index value. > > Okay, if I'm looking at the figure properly then this is just an editorial > > issue, then: > > > > 0 1 2 3 > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Queue Index | Queue Size Qn | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Num DSCPs Qn | DS Field Qn | ... : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : ... | DS Field Qn | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > So we have the chunk of stuff for a given queue (index), and the size of > > that queue, then a separate array/length for the DS values. The various DS > > values that can match this queue index are the contents of this array, but > > this is the only array in the sub data item describing this queue index. > > If that's correct, then isn't the description of "DS Field Qn" just "The > > sub data item contains a sequence of 8 bit DS Fields for this queue index. > > The number of DS Fields present MUST equal this value."? > > Yes - I'm fine with a specific text revision if you have one. How about: OLD: The data item contains a sequence of 8 bit DS Fields. The number of DS Fields present MUST equal the sum of all Num DSCPs field values. NEW: The data item contains a sequence of 8 bit DS Fields. The number of DS Fields present MUST equal the value of the Num DSCPs field. > > > > >>> In Section 3.3: > >>> > >>> A router which receives the Restart Data Item SHOULD resume > >>> transmission of the identified traffic to the modem. > >>> > >>> Why is this only a "SHOULD"? > >> to cover the case where the router is choosing not to send data, e.g., > >> due to lack of available data or other policy such as traffic rate shaping. > > Okay. Frequently documents will give the reader some hint as to what the > > exceptional cases might be, but I will not insist on it here. > > > > > >>> Section 4 > >>> > >>> The extension does not inherently > >>> introduce any additional vulnerabilities above those documented in > >>> [RFC8175]. [...] > >>> > >>> As noted by others, this sentence is just not true. > >>> I will not duplicate the suggestions for additional considerations that > >>> need to be documented. > >> Please see comments / discussion elsewhere on this. > > Sorry, most of these threads have aged out of my cache; could you give me a > > hint about whose ballot thread to look in, or a link? > > Perhaps it's just best to point you at the current text and see if > you're okay with it -- see > > https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-07#section-4 > > and let me/us know if you still have any unresolved comments. My main issue is with "does not inherently introduce any additional vunlerabilities" -- there's a new signal that if received by the router, causes all traffic to stop. There is some inherent risk of such a signal being received erroneously, even if an attacker that could introduce such a signal would need to be highly capable (and thus also capable of doing damage in other ways), and of course the risk of random accidents is always present. So I think the intent here may be to say instead that "this extension does not introduce any vulnerabilities that are inherently different from those documented in [RFC8175]", since there are already other ways that an attacker could cause the router to stop sending traffic to the modem. > > >>> In particular, I agree with Roman that the use > >>> of TLS needs to be mandatory, especially since this protocol is > >>> nominally only defined for use with radio links. > >> > >> As covered elsewhere, in particular this is really a comment on base > >> DLEP and I think this extension should be consistent with that document. > >> (Consider an example from when 8175 was issued, consider the case where > >> the modem and router use MACsec, 802.1X and 802.1 AE, why is TLS needed > >> as well.) > > Perhaps. I think it's highly dependent on whether DLEP is only conveyed > > over wired links and the physical scope of those links, though -- my > > understanding is that most of the IESG was treating this protocol as > > running over the radio link. > > umm, DLEP is *NEVER* expected to run over the air.  This is covered in > RFC8175 and is not impacted by this extension. I'm sorry that I (and the collective IESG) missed that; you are quite correct. (I think I was under severe time pressure reviewing this document and only did targetted keyword searches in 8175 as I was reading.) -Ben From nobody Thu Jun 13 11:26:31 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 7EA2E12023C for ; Thu, 13 Jun 2019 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.686 X-Spam-Level: ** X-Spam-Status: No, score=2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 OEvRVkbLKkZM for ; Thu, 13 Jun 2019 11:26:23 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB34120229 for ; Thu, 13 Jun 2019 11:26:20 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 25E37B42873F6 for ; Thu, 13 Jun 2019 12:26:17 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id bUQShWGXjsFwgbUQShP3jx; Thu, 13 Jun 2019 12:26:17 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=J/aEEjvS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=xqWC_Br6kY4A:10:nop_ipv6 a=dq6fvYVFJ5YA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=oVDSxFbo9Ya9f_9SELMA:9 a=vVICH83cBykVrxfP:21 a=8MauNC88WcY10SuP:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=mYAOWqAtFUkA:10:demote_hacked_domain_1 a=1dbGxDndw2gA:10:demote_hacked_domain_7 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ojKvDzd1IzbK8phQpCfzpADW/pMWDmSpi//D3dhRVqQ=; b=KUwkBsb9MnD57KEeyOiN+AEwTx B/eo+Tsbp+tna9TjBckcfHLbYe8UnrxTH/EsDF2Koc98+mJ0D530+PtbvXmEWwBJa9GOAItPNfBvQ R33JEWU7ZyMNZ3soOjubR6Acc; Received: from [127.0.0.1] (port=10801 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hbUQS-001eaG-O6; Thu, 13 Jun 2019 12:26:16 -0600 From: Lou Berger To: Benjamin Kaduk Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org, The IESG , manet-chairs@ietf.org References: <155494445891.22757.7399588752085896470.idtracker@ietfa.amsl.com> <20190506224055.GX19509@kduck.mit.edu> <10c43c45-877d-842d-b527-8ff0dd9cb600@labn.net> <20190606182224.GC23396@kduck.mit.edu> Message-ID: <93f68bb0-0366-4def-48c3-2a2465ccdcde@labn.net> Date: Thu, 13 Jun 2019 14:26:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20190606182224.GC23396@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1hbUQS-001eaG-O6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:10801 X-Source-Auth: lberger@labn.net X-Email-Count: 12 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) 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: Thu, 13 Jun 2019 18:26:27 -0000 Hi, No worries on the delay. On 6/6/2019 2:22 PM, Benjamin Kaduk wrote: > Hi Lou, > > Sorry for the long delay here; I'm in the process of moving from St. Louis > to Seattle and have had to take a bunch of time off in the process. > > On Tue, May 07, 2019 at 10:34:57AM -0400, Lou Berger wrote: >> Please see responses below... >> >> On 5/6/2019 6:40 PM, Benjamin Kaduk wrote: >>> On Sun, May 05, 2019 at 09:22:16PM -0400, Lou Berger wrote: >>>> Hi, >>>> My apologies, I thought I responded to this, but can't seem to find the >>>> response (hopefully my responses are consistent if I did!). >>>> >>>> On 4/10/19 9:00 PM, Benjamin Kaduk via Datatracker wrote: >>>>> Benjamin Kaduk has entered the following ballot position for >>>>> draft-ietf-manet-dlep-pause-extension-06: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the >>>>> values 0-3 are assigned, leaving 4-16k usable. How will future values be >>>>> assigned? >>>>> >>>> A future revision or update of this document. We discussed a IANA >>>> registry, but thought it overkill as future additions seem quite unlikely. >>> Okay. The Discuss was just to make sure it was considered in some fashion; >>> we do have a bunch of documents that explictly note "additional values are >>> to be allocated by updates to this specification" but I do not insist on >>> it. >>> >>>>> In Section 3.1.1: >>>>> >>>>> DS Field Qn: >>>>> >>>>> The data item contains a sequence of 8 bit DS Fields. The number >>>>> of DS Fields present MUST equal the sum of all Num DSCPs field >>>>> values. >>>>> >>>>> Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global >>>>> for this queue index, so there would just be one of them and no need to >>>>> take a sum. >>>> It's just saying that more than one DSCP can match to a single queue >>>> index value. >>> Okay, if I'm looking at the figure properly then this is just an editorial >>> issue, then: >>> >>> 0 1 2 3 >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Queue Index | Queue Size Qn | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Num DSCPs Qn | DS Field Qn | ... : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : ... | DS Field Qn | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> So we have the chunk of stuff for a given queue (index), and the size of >>> that queue, then a separate array/length for the DS values. The various DS >>> values that can match this queue index are the contents of this array, but >>> this is the only array in the sub data item describing this queue index. >>> If that's correct, then isn't the description of "DS Field Qn" just "The >>> sub data item contains a sequence of 8 bit DS Fields for this queue index. >>> The number of DS Fields present MUST equal this value."? >> Yes - I'm fine with a specific text revision if you have one. > How about: > > OLD: > > The data item contains a sequence of 8 bit DS Fields. The number > of DS Fields present MUST equal the sum of all Num DSCPs field > values. > > NEW: > > The data item contains a sequence of 8 bit DS Fields. The number > of DS Fields present MUST equal the value of the Num DSCPs field. yes, this is better. >>>>> In Section 3.3: >>>>> >>>>> A router which receives the Restart Data Item SHOULD resume >>>>> transmission of the identified traffic to the modem. >>>>> >>>>> Why is this only a "SHOULD"? >>>> to cover the case where the router is choosing not to send data, e.g., >>>> due to lack of available data or other policy such as traffic rate shaping. >>> Okay. Frequently documents will give the reader some hint as to what the >>> exceptional cases might be, but I will not insist on it here. >>> >>> >>>>> Section 4 >>>>> >>>>> The extension does not inherently >>>>> introduce any additional vulnerabilities above those documented in >>>>> [RFC8175]. [...] >>>>> >>>>> As noted by others, this sentence is just not true. >>>>> I will not duplicate the suggestions for additional considerations that >>>>> need to be documented. >>>> Please see comments / discussion elsewhere on this. >>> Sorry, most of these threads have aged out of my cache; could you give me a >>> hint about whose ballot thread to look in, or a link? >> Perhaps it's just best to point you at the current text and see if >> you're okay with it -- see >> >> https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-07#section-4 >> >> and let me/us know if you still have any unresolved comments. > My main issue is with "does not inherently introduce any additional > vunlerabilities" -- there's a new signal that if received by the router, > causes all traffic to stop. There is some inherent risk of such a signal > being received erroneously, even if an attacker that could introduce such a > signal would need to be highly capable (and thus also capable of doing > damage in other ways), and of course the risk of random accidents is always > present. > > So I think the intent here may be to say instead that "this extension does > not introduce any vulnerabilities that are inherently different from those > documented in [RFC8175]", since there are already other ways that an > attacker could cause the router to stop sending traffic to the modem. This works for me too. I'll push a new version in a few moments. Thanks, Lou >>>>> In particular, I agree with Roman that the use >>>>> of TLS needs to be mandatory, especially since this protocol is >>>>> nominally only defined for use with radio links. >>>> As covered elsewhere, in particular this is really a comment on base >>>> DLEP and I think this extension should be consistent with that document. >>>> (Consider an example from when 8175 was issued, consider the case where >>>> the modem and router use MACsec, 802.1X and 802.1 AE, why is TLS needed >>>> as well.) >>> Perhaps. I think it's highly dependent on whether DLEP is only conveyed >>> over wired links and the physical scope of those links, though -- my >>> understanding is that most of the IESG was treating this protocol as >>> running over the radio link. >> umm, DLEP is *NEVER* expected to run over the air.  This is covered in >> RFC8175 and is not impacted by this extension. > I'm sorry that I (and the collective IESG) missed that; you are quite > correct. (I think I was under severe time pressure reviewing this document > and only did targetted keyword searches in 8175 as I was reading.) > > -Ben > > From nobody Thu Jun 13 11:31:35 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 404991201C5; Thu, 13 Jun 2019 11:31:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: manet@ietf.org Message-ID: <156045068616.12515.18392162566844367274@ietfa.amsl.com> Date: Thu, 13 Jun 2019 11:31:26 -0700 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-pause-extension-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 18:31:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : DLEP Control Plane Based Pause Extension Authors : Bow-Nan Cheng David Wiggins Lou Berger Filename : draft-ietf-manet-dlep-pause-extension-08.txt Pages : 13 Date : 2019-06-13 Abstract: This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-08 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-pause-extension-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-pause-extension-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 14 16:21:40 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11748120100; Fri, 14 Jun 2019 16:21:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156055449206.28228.15422926470589153449.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2019 16:21:32 -0700 Archived-At: Subject: [manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-pause-extension-08: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 23:21:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my Discuss points! From nobody Mon Jun 17 13:17:23 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242F12006E; Mon, 17 Jun 2019 13:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, manet@ietf.org, aretana.ietf@gmail.com, The IESG , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156080263539.22364.13725901690777675106.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2019 13:17:15 -0700 Archived-At: Subject: [manet] Protocol Action: 'DLEP Control Plane Based Pause Extension' to Proposed Standard (draft-ietf-manet-dlep-pause-extension-08.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 20:17:16 -0000 The IESG has approved the following document: - 'DLEP Control Plane Based Pause Extension' (draft-ietf-manet-dlep-pause-extension-08.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ Technical Summary This document defines an extension to the DLEP protocol that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. Working Group Summary The WG process was smooth, there are no issues or concerns arising from this document. Document Quality The document is clear and well-written. Vendors have indicated a plan to implement the document once published. Personnel The Document Shepherd is Stan Ratliff. The Responsible Area Director is Alvaro Retana. From nobody Fri Jun 21 13:07:50 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 111C2120167; Fri, 21 Jun 2019 13:07:49 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Bt3KjGzCeV78; Fri, 21 Jun 2019 13:07:47 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 3AA55120144; Fri, 21 Jun 2019 13:07:44 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id p15so11682324eds.8; Fri, 21 Jun 2019 13:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=7xKXHmxbSIWjflKvBv0vQXiFWk6EbCIRqAN4Q0K0HAM=; b=gBUpnPpDPIfTZqiSs4Ip4sTSVpI1F/SodrswYr5mvrV2EkbXVEISw0iz0CUozzxXL/ Ye6rswsMPf0XY4UNI+whuBO77g89SgK1p04Jt1K1+UeFaN21GDWJAiL/Y0mmQmZJJSpJ UKNyLC2pdkpo4cKvYaR0XRto0yqkMARj3wQT7Yp3AYHAGS/aXb1foyo0iPaspW2VeIaV 4pclShbS2f3QuYp9Ot2gbwTN62mMNYFfon1Pwe9nAJ+XyZBqqyUAV8pBEkxHBLIgoQLd ZBhXkP41yqW2KgbB7MZDV7tiTMcGthGyKuYxvWtrLr3U6KuuT7VzIVcFsu2umx7tYOAc k7FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=7xKXHmxbSIWjflKvBv0vQXiFWk6EbCIRqAN4Q0K0HAM=; b=Kwlzj4++SJtb8zA2eiL4LMNymCkHxx0V3lkzI4OizEUs8GhUF8TkJEJbKcbdeXlTto OqXMzno3N3Tzx/Von1QujfH8rpm5Jmdiq19AOGDXSVPaEj7Gw6l/cID8YNozSb5cNHu6 Q+WkDHZYtE9snWJslvJSUsovWLW95SCpTGJbQyjbvMMfgBZAIiM/ySZs6OZ9Fr0PqdFq pBo7M3eUVtBWM1g412Qdz5O3ASm2JYwPxqwtybsuIhHMRReeWI6z9Rvorp2eA+UDTevB 93WNHAXTBjwG1gsr3GMsPPVN11hjSPe2yxp7jgNFjqUkAgQlTSjmwpXDXFsmA1Elwbew M25Q== X-Gm-Message-State: APjAAAVgWfaWI32U51GW0+9vqaCnOt/z+jQb0zzaUFZT+tWvcxZGD6Nl kVZns3Vsm6kMUwMij6EtY0+FgdDBHn62gOo4+rkJuA== X-Google-Smtp-Source: APXvYqwYqHhIaZtZR8pWMuhlE7ZgIZ6wzmLrjeCk1tsA0GgyIS8xwBVFQOGb9WCFAZ4tA5yoIbHt13nw3EY1fkBL7Ig= X-Received: by 2002:aa7:ca45:: with SMTP id j5mr50954927edt.217.1561147662611; Fri, 21 Jun 2019 13:07:42 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Jun 2019 16:07:41 -0400 From: Alvaro Retana MIME-Version: 1.0 Date: Fri, 21 Jun 2019 16:07:41 -0400 Message-ID: To: draft-ietf-manet-dlep-latency-extension@ietf.org Cc: Justin Dean , manet-chairs@ietf.org, manet@ietf.org Content-Type: multipart/alternative; boundary="000000000000df3822058bdb032f" Archived-At: Subject: [manet] AD Review of draft-ietf-manet-dlep-latency-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: Fri, 21 Jun 2019 20:07:49 -0000 --000000000000df3822058bdb032f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished reading this document. Sorry for the processing delay. I have only one issue. I'm starting the IETF Last Call because I believe we can take care of it with other LC comments. >From =C2=A73: "The Latency Range Data Item MAY be carried in any message wh= ere the Latency Data Item [RFC8175] is allowed and is carried as an additional data item." There is an exception to the "MAY be carried" part above; rfc8175 =C2=A712.= 6 (Session Initialization Response Message) says: All supported metric Data Items MUST be included in the Session Initialization Response Message, with default values to be used on a session-wide basis. This can be viewed as the modem "declaring" all supported metrics at DLEP session initialization. Receipt of any further DLEP Message containing a metric Data Item not included in the Session Initialization Response Message MUST be treated as an error, resulting in the termination of the DLEP session between router and modem. If any optional extensions are supported by the modem, they MUST be enumerated in the Extensions Supported Data Item. If an Extensions Supported Data Item does not exist in a Session Initialization Response Message, the router MUST conclude that there is no support for extensions in the modem. IOW, the Latency Range MUST be carried in the Session Initialization Response Message. Please add text to that effect. Thanks! Alvaro. --000000000000df3822058bdb032f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors:

I just finished = reading this document.=C2=A0 Sorry for the processing delay.

I have only one issue.= =C2=A0 I'm starting the IETF Last Call because I believe we can take ca= re of it with other LC comments.

<= div style=3D"margin:0px">From =C2=A73: "The Latency Range Data Item MA= Y be carried in any message where the Latency Data Item [RFC8175] is allowe= d and is carried as an additional data item."

There is an exception to the &qu= ot;MAY be carried" part above; rfc8175 =C2=A712.6 (Session Initializat= ion Response Message) says:

=C2=A0 =C2=A0All supported metric Data Items MUST be in= cluded in the Session
=C2=A0 =C2=A0Initializ= ation Response Message, with default values to be used on a
=C2=A0 =C2=A0session-wide basis.=C2=A0 This can be viewed a= s the modem "declaring" all
=C2=A0= =C2=A0supported metrics at DLEP session initialization.=C2=A0 Receipt of a= ny
=C2=A0 =C2=A0further DLEP Message contain= ing a metric Data Item not included in
=C2= =A0 =C2=A0the Session Initialization Response Message MUST be treated as an=
=C2=A0 =C2=A0error, resulting in the termin= ation of the DLEP session between
=C2=A0 =C2= =A0router and modem.

=C2=A0 =C2=A0If any optional extensions are supported by the m= odem, they MUST be
=C2=A0 =C2=A0enumerated i= n the Extensions Supported Data Item.=C2=A0 If an Extensions
=C2=A0 =C2=A0Supported Data Item does not exist in a Sessi= on Initialization
=C2=A0 =C2=A0Response Mess= age, the router MUST conclude that there is no support
=C2=A0 =C2=A0for extensions in the modem.


IOW, the Latency Range MUST be carried in the Session Initialization = Response Message.=C2=A0 Please add text to that effect.

Thanks!

Alvaro.


--000000000000df3822058bdb032f-- From nobody Fri Jun 21 13:18:17 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 428C512039A for ; Fri, 21 Jun 2019 13:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 QZ3QSPC7woHA for ; Fri, 21 Jun 2019 13:18:14 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51ECB120399 for ; Fri, 21 Jun 2019 13:18:14 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id C68101404EE for ; Fri, 21 Jun 2019 14:18:05 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id ePz3hfjrrsFwgePz3hWpTB; Fri, 21 Jun 2019 14:18:05 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=Evr8UxUA c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=dq6fvYVFJ5YA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=XGjl87NSc3RJax6vVAMA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=pGLkceISAAAA:8 a=D4u-l4WwtsH2SMSqVLwA:9 a=V1_i42d_f8WBHaPC:21 a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=K5UCAZbHhRYglaCv2CZ5e/Cn48+LkDkRaiH4MfS3I2g=; b=JDE30xT4699yZd+gI1ltvm1rd+ d5CjWbbibo0A6VQOUwkx1QIKKBFMsaOyenZSnBzNA+Cc9oJWQuHrlfR8Srhujk77iFeG1UhG8cei3 aaMh/wR9079d1ZtAxnB8gIv28; Received: from [127.0.0.1] (port=56699 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hePz3-002D5T-Fm; Fri, 21 Jun 2019 14:18:05 -0600 To: Alvaro Retana , draft-ietf-manet-dlep-latency-extension@ietf.org Cc: manet@ietf.org, manet-chairs@ietf.org References: From: Lou Berger Message-ID: <0bdaffca-02c8-ded5-9d84-a17fdb9ee740@labn.net> Date: Fri, 21 Jun 2019 16:18:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFC893ACF5BDA735BD109DE1" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1hePz3-002D5T-Fm X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:56699 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-latency-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: Fri, 21 Jun 2019 20:18:16 -0000 This is a multi-part message in MIME format. --------------CFC893ACF5BDA735BD109DE1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Alvaro,     good catch and will do. Lou On 6/21/2019 4:07 PM, Alvaro Retana wrote: > Dear authors: > > I just finished reading this document. Sorry for the processing delay. > > I have only one issue.  I'm starting the IETF Last Call because I > believe we can take care of it with other LC comments. > > From §3: "The Latency Range Data Item MAY be carried in any message > where the Latency Data Item [RFC8175] is allowed and is carried as an > additional data item." > > There is an exception to the "MAY be carried" part above; rfc8175 > §12.6 (Session Initialization Response Message) says: > >    All supported metric Data Items MUST be included in the Session >    Initialization Response Message, with default values to be used on a >    session-wide basis.  This can be viewed as the modem "declaring" all >    supported metrics at DLEP session initialization.  Receipt of any >    further DLEP Message containing a metric Data Item not included in >    the Session Initialization Response Message MUST be treated as an >    error, resulting in the termination of the DLEP session between >    router and modem. > >    If any optional extensions are supported by the modem, they MUST be >    enumerated in the Extensions Supported Data Item.  If an Extensions >    Supported Data Item does not exist in a Session Initialization >    Response Message, the router MUST conclude that there is no support >    for extensions in the modem. > > > IOW, the Latency Range MUST be carried in the Session Initialization > Response Message.  Please add text to that effect. > > Thanks! > > Alvaro. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------CFC893ACF5BDA735BD109DE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Alvaro,

    good catch and will do.

Lou

On 6/21/2019 4:07 PM, Alvaro Retana wrote:
Dear authors:

I just finished reading this document.  Sorry for the processing delay.

I have only one issue.  I'm starting the IETF Last Call because I believe we can take care of it with other LC comments.

From §3: "The Latency Range Data Item MAY be carried in any message where the Latency Data Item [RFC8175] is allowed and is carried as an additional data item."

There is an exception to the "MAY be carried" part above; rfc8175 §12.6 (Session Initialization Response Message) says:

   All supported metric Data Items MUST be included in the Session
   Initialization Response Message, with default values to be used on a
   session-wide basis.  This can be viewed as the modem "declaring" all
   supported metrics at DLEP session initialization.  Receipt of any
   further DLEP Message containing a metric Data Item not included in
   the Session Initialization Response Message MUST be treated as an
   error, resulting in the termination of the DLEP session between
   router and modem.

   If any optional extensions are supported by the modem, they MUST be
   enumerated in the Extensions Supported Data Item.  If an Extensions
   Supported Data Item does not exist in a Session Initialization
   Response Message, the router MUST conclude that there is no support
   for extensions in the modem.


IOW, the Latency Range MUST be carried in the Session Initialization Response Message.  Please add text to that effect.

Thanks!

Alvaro.



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--------------CFC893ACF5BDA735BD109DE1-- From nobody Fri Jun 21 13:32:43 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 799DE1203AE; Fri, 21 Jun 2019 13:32:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: manet-chairs@ietf.org, manet@ietf.org, aretana.ietf@gmail.com, bebemaster@gmail.com, Justin Dean , draft-ietf-manet-dlep-latency-extension@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156114915441.16585.2158582692805727278.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2019 13:32:34 -0700 Archived-At: Subject: [manet] Last Call: (DLEP Latency Range Extension) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 20:32:35 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'DLEP Latency Range Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jun 26 02:57:46 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 176CA12041E; Wed, 26 Jun 2019 02:57:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: manet@ietf.org, ietf@ietf.org, draft-ietf-manet-dlep-latency-extension.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <156154306499.20237.6931841641823410723@ietfa.amsl.com> Date: Wed, 26 Jun 2019 02:57:45 -0700 Archived-At: Subject: [manet] Genart last call review of draft-ietf-manet-dlep-latency-extension-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 09:57:45 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-manet-dlep-latency-extension-04 Reviewer: Stewart Bryant Review Date: 2019-06-26 IETF LC End Date: 2019-07-08 IESG Telechat date: Not scheduled for a telechat Summary: A very simple well written document ready for publication except for one nit and one question. Major issues: None. Minor issues: A 64-bit unsigned integer, representing the longest transmission delay, in microseconds, that a packet encounters as it is transmitted over the link. SB> That is a range 0..58000 years. I wonder if it would have been SB> useful to have used ns at a cost of limiting the range to SB> only 0..58 years? ========== Nits/editorial comments: DLEP Latency Range Extension draft-ietf-manet-dlep-latency-extension-04 Abstract This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. SB> I am not sure what the policy WRT to RFC titles is, but DLEP is SB> not well known and should be expanded in the abstract. ============== From nobody Fri Jun 28 15:59:45 2019 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B187D120968; Fri, 28 Jun 2019 15:57:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: manet@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267272.11015.12572794695198098554.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:52 -0700 Archived-At: Subject: [manet] manet - Requested session has been scheduled for IETF 105 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:57:59 -0000 Dear Stan Ratliff, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. manet Session 1 (1:00 requested) Tuesday, 23 July 2019, Afternoon Session III 1710-1810 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/manet.ics Request Information: --------------------------------------------------------- Working Group Name: Mobile Ad-hoc Networks Area Name: Routing Area Session Requester: Stan Ratliff Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: dtn teas detnet ipwave Second Priority: babel lsr roll People who must be present: Stan Ratliff Justin Dean Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 28 16:21:21 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 7A1BA1208ED for ; Fri, 28 Jun 2019 16:21:14 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2gmq5dLjgh0G for ; Fri, 28 Jun 2019 16:21:12 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 9CD251202C5 for ; Fri, 28 Jun 2019 16:21:12 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id k13so3223513pgq.9 for ; Fri, 28 Jun 2019 16:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yHCo6idLLXrY6wRGZR2ReMFwIUMV/UEgqtj53hVmAFo=; b=t7UtwE0DQd96gnKzwcMtl2BY5R2QtOywf0YcwA15fivLj2eyjI1wUGK7tGiBJbNus6 3ZGKplOCl8M43cGYl0Am2wiL7Zsfi6xH6KnMh31mBDyaW08TMqYUNTo9Ob6EB28so6jb A/X9tcst/TJ0KyTdmTots5moaw2F9W85VyaixBoHVp5H7IXxvnu+ixYn5ZfzaLOzQFrK 0PWDPRSFtLkv41mcyGr3KC0YSI8n/8+IXfLewOP/IVWtchXUBHill2PqEFq4Yj0wL73K 7HsR+RyaUchmgoP4VctsOPTsVRPd6rK6XabG12wFe+pCb96AvYJmK1H5+jufMKgpDE0X PF7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yHCo6idLLXrY6wRGZR2ReMFwIUMV/UEgqtj53hVmAFo=; b=k4HKh2RywNrniWtVTAjE9FIwHRjyIkOtRnjwMF6NyFS6EuvDG1B5wjV8W5v3jm+SHP oes8MfFsfRNsCUJaFmZQiRQ4g4kFLTVYycR7T8rkYjilX/ieG4wkH1OYeb0GmY45fXgF 4CPBn7BPyN3N5KfuUKGRgeoL7gez+VpjerrY+FfV1XDYCfly4P3L8IZ76vYAZ1xVwQDG SwZRwJEywIwufw1D9QGYt+q/vyLjnvBkPXvr1ET0oNqFTFQptRtW7xmj1m23Pa8DKUMA 18Pl3zwkHUsl5L+vFcO8PGi/h3IoGOk0dx3aDWNF0l/SEp8onGNWHiIxR2v+87mU0TzU MEQA== X-Gm-Message-State: APjAAAWKylLL7hxGg21dLi9973qsMrzlraUBvZaKNJnHOF5CmZjtPcX7 yIuTkT7Oz8lGeWpPa/TV+RXHLdXffzhL3/RsXrwTOq88 X-Google-Smtp-Source: APXvYqwNmuLWpTob7XhH7+PxZWH56hJ5HFZ+l4UO8kSUN319YdL50TEolVzqXPGjzcEHN+Yadb3mAdd0NfihC39rueY= X-Received: by 2002:a65:6210:: with SMTP id d16mr11504037pgv.180.1561764071866; Fri, 28 Jun 2019 16:21:11 -0700 (PDT) MIME-Version: 1.0 References: <156176267272.11015.12572794695198098554.idtracker@ietfa.amsl.com> In-Reply-To: <156176267272.11015.12572794695198098554.idtracker@ietfa.amsl.com> From: Stan Ratliff Date: Fri, 28 Jun 2019 19:21:01 -0400 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary="000000000000ba0771058c6a883c" Archived-At: Subject: [manet] Agenda items for IETF 105 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: Fri, 28 Jun 2019 23:21:16 -0000 --000000000000ba0771058c6a883c Content-Type: text/plain; charset="UTF-8" Hello Working Group Participants, As you can see, we have a 1-hour meeting set for Tuesday, the 23rd. If you have a desire to present at IETF 105, please let the chairs know. Regards, Stan ---------- Forwarded message --------- From: "IETF Secretariat" Date: Fri, Jun 28, 2019 at 7:04 PM Subject: [manet] manet - Requested session has been scheduled for IETF 105 To: , CC: Dear Stan Ratliff, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. manet Session 1 (1:00 requested) Tuesday, 23 July 2019, Afternoon Session III 1710-1810 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/manet.ics Request Information: --------------------------------------------------------- Working Group Name: Mobile Ad-hoc Networks Area Name: Routing Area Session Requester: Stan Ratliff Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: dtn teas detnet ipwave Second Priority: babel lsr roll People who must be present: Stan Ratliff Justin Dean Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --000000000000ba0771058c6a883c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Working Group Participants,

As you can see, we have a 1-hour mee= ting set for Tuesday, the 23rd. If you have a desire to present at IETF 105= , please let the chairs know.

Regards,
Stan

---------- Forwarded message= ---------
From: "I= ETF Secretariat" <agenda@ietf.org>
Date: Fri, Jun 28, 2019 at 7= :04 PM
Subject: [manet] manet - Requested session has been scheduled for= IETF 105
To: <sratliff@idir= ect.net>, <manet-chairs= @ietf.org>
CC: <manet@ietf.= org>


Dear Stan Ratliff,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.


=C2=A0 =C2=A0 manet Session 1 (1:00 requested)
=C2=A0 =C2=A0 Tuesday, 23 July 2019, Afternoon Session III 1710-1810
=C2=A0 =C2=A0 Room Name: Notre Dame size: 50
=C2=A0 =C2=A0 ---------------------------------------------


iCalendar: https://datatracker.ietf.org/m= eeting/105/sessions/manet.ics

Request Information:


---------------------------------------------------------
Working Group Name: Mobile Ad-hoc Networks
Area Name: Routing Area
Session Requester: Stan Ratliff

Number of Sessions: 1
Length of Session(s):=C2=A0 1 Hour
Number of Attendees: 20
Conflicts to Avoid:
=C2=A0First Priority: dtn teas detnet ipwave
=C2=A0Second Priority: babel lsr roll



People who must be present:
=C2=A0 Stan Ratliff
=C2=A0 Justin Dean
=C2=A0 Alvaro Retana

Resources Requested:

Special Requests:

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

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--000000000000ba0771058c6a883c--