From nobody Thu Aug 1 11:34:14 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 F34D91201D0; Thu, 1 Aug 2019 11:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdgyI5lZqm_K; Thu, 1 Aug 2019 11:34:10 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 95711120168; Thu, 1 Aug 2019 11:34:09 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id d4so70140154edr.13; Thu, 01 Aug 2019 11:34:09 -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=LqXt4Y3QWTIoYDbVq6KZ7rTEz4QTBBLsaBESnzvlB3w=; b=nXZpeJcospZ9wJHDd1ccT8rXjhZZRvt5bd3rRpg2ezwTObeLKHCzE+JaprbAUK0ymp mAivsvDL+XQaFY650Zoa6G7p8Mx+/Vouzk2I/mI5XeignkZE+OpETab7uLe3YS+HHOwp vLSxGOw/e8s/0G6dyit7MXg+H78163TsdRuFFn3TzFtVMSFtv+ozQTBQnj63vIxYcDo5 E1Mn7GmB859oBwnAYxevG1/ilaqnGPBs/LudbSCcEbaLyKXxdQlbTBT2WBRho1dNJ7lD vS/147zCR7NoSXhfHeMfDXlQAUMJOb8hdtkILyvVuBV5cQcruFnPAp5bRndLLGUamtYu Tj5Q== 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=LqXt4Y3QWTIoYDbVq6KZ7rTEz4QTBBLsaBESnzvlB3w=; b=B75ZQpzG9IkWfUKSb1S6gWx6/cQDoJsK4FYOWN8g1BX3hJDGilzyQP8dLCmxYBUUzm HNQ6EJdhnsTCviocMN6Dtrcw2FVpoNjOzIDwhJ3gBZbde/442sCcmfK08ff7GLiBYp/x 1cmOAL8kF+vZvTZQUmmp5RumYAuxbsEV/dTFb7UmVPXdiNSsnhdJ1SwHE+0GgvU9sBvn wxWkIcprPs2UlbGUeJ0qbsF0HIEFK/w3YSNZFFXcJD23GUkzjQKJE6eNTf0vwcc6p4mG 3pli5WfURbaFPFsKKavrU3y6sWpsHGBfAaKqkSCtkQ0CZgzuzAD/uZOHXapmov5GfA78 OkWg== X-Gm-Message-State: APjAAAXu8oMQql1qvgIXtAGVrCX1M6Qw7F/75tDjl9a89nTwJ9b8IQWx 63tp1T1StvmXwFgi+sIef0LujtHeRTjmwF50Ysc= X-Google-Smtp-Source: APXvYqwviPQzsfmOj2maA9KyzqpBVwau/AixRNmvEEybvyfTrjl5k6/y3yryZ8q5VtVFCjPWvccc1+FqYOCQJAXJEjA= X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr100271403ejb.265.1564684447962; Thu, 01 Aug 2019 11:34:07 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 1 Aug 2019 20:34:07 +0200 From: Alvaro Retana In-Reply-To: <602708730af3b1f89b37d39ba109e212a7ccb9d2.camel@tropicalstormsoftware.com> References: <602708730af3b1f89b37d39ba109e212a7ccb9d2.camel@tropicalstormsoftware.com> MIME-Version: 1.0 Date: Thu, 1 Aug 2019 20:34:07 +0200 Message-ID: To: Rick Taylor , "draft-ietf-manet-dlep-lid-extension@ietf.org" Cc: "manet@ietf.org" , "manet-chairs@ietf.org" , Justin Dean Content-Type: multipart/alternative; boundary="000000000000b4db9e058f127c2c" 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: Thu, 01 Aug 2019 18:34:12 -0000 --000000000000b4db9e058f127c2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On July 30, 2019 at 12:13:46 PM, Rick Taylor (rick@tropicalstormsoftware.co= m) wrote: Rick: Hi! I am starting the IETF LC. My only remaining comments are about security (see below), but we can deal with that as we get other reviews. Thanks! Alvaro. Comments inline, but a little forward: We have done a rewrite of most of the descriptive text, focussing on the use-cases, and attempting to clearly define terminology to aid the reader. I think that helps. :-) The new text in the Abstract/Introduction says: "The core specification of the protocol assumes that every modem in the radio network has an attached DLEP router, and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network=E2=80=A6= This document describes a DLEP Extension allowing modems that do not meet the strict requirement above=E2=80=A6=E2=80=9D. It is not clear if the =E2=80= =9Cstrict requirement=E2=80=9D you refer to is the assumption that a router is attached, or that its MAC address is used=E2=80=A6or both. I think this is important to justify tha= t, for example, other Security Considerations are not created. Just trying to cover our bases=E2=80=A6I don=E2=80=99t have anything specific to point out= . ... > ... > 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. I don't know how to avoid this - can you suggest some text please? s/[RFC8175]/(RFC8175) ;-) ... > > 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. Damn.. I missed this one. I shall have to uprev with specific Termination rules. Yup. ... > ... > 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. > Having called out the additional reasons for termination, I don't see that any of them cause any additional security considerations beyond normal DLEP. The consideration is: deviate from the protocol and your session will terminate - that's covered by DLEP. True=E2=80=A6but now with a bigger attack surface. I would love to see som= ething pointing at rogue routers/modems taking advantage of termination opportunities=E2=80=A6but we can also wait and see what the SecDir/SEC ADs = say=E2=80=A6 --000000000000b4db9e058f127c2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On July 30, 2019 at 12:13:46 PM, Rick Taylor (rick@tropicalstormsoftware.= com) wrote:

Ric= k:

Hi! =C2=A0
=

I am starting the IETF L= C.

My only remainin= g comments are about security (see below), but we can deal with that as we = get other reviews.

= Thanks!

=
Alvaro.




Comments inline= , but a little forward:=C2=A0<= br>
We have done a rewrite of most of the descriptive text, focussing on= =C2=A0
the use-cases, and a= ttempting to clearly define terminology to aid the=C2=A0
reader.= =C2=A0

I think that helps. := -)

The new text in the Abstract/Introduction says: "The core spe= cification of the protocol assumes that every modem in the radio network ha= s an attached DLEP router, and requires that the MAC address of the DLEP in= terface on the attached router be used to identify the destination in the n= etwork=E2=80=A6 =C2=A0This document describes a DLEP Extension allowing mod= ems that do not meet the strict requirement above=E2=80=A6=E2=80=9D. =C2=A0= It is not clear if the =E2=80=9Cstrict requirement=E2=80=9D you refer to i= s the assumption that a router is attached, or that its MAC address is used= =E2=80=A6or both. =C2=A0 I think this is important to justify that, for exa= mple, other Security Considerations are not created.=C2=A0 Just trying to c= over our bases=E2=80=A6I don=E2=80=99t have anything specific to point out.=


...

> ...=C2=A0<= /span>
> 11 Abstract=C2=A0
>=C2=A0
> 13 Th= ere exists a class of modems that would benefit from=C2=A0
> supporting the=C2=A0
> 14 Dynamic Link Exchange Protocol (DLEP= ) [RFC8175] but do not=C2=A0> present a=C2=A0
>= 15 single Layer 2 network domain as required by DLEP. Such=C2=A0
> devices may=C2=A0
> 16 be:=C2=A0
>=C2=A0<= /span>
> [nit] Don't include references in the Abstract.=C2=A0

I don't know how to a= void this - can you suggest some text please?=C2=A0

s/[RFC8175]/(= RFC8175) =C2=A0;-)


...

>=C2=A0
> 173 2.1. Identifier Restrictions=C2=A0
>=C2=A0
> 175 A Link Identifier is by default 4 octets = in length. If a=C2=A0
> = modem=C2=A0
> 176 wishes= to use a Link Identifier of a different length, it=C2=A0
> MUST be=C2=A0
> 177 announced using the Link Identifier Length = Data Item=C2=A0
> (Secti= on 3.1)=C2=A0
> 178 cont= ained in the DLEP Session Initialization Response=C2=A0
> message sent by=C2=A0
> 179 the modem to the router.=C2=A0
>=C2=A0
> 181 During the lifetime of a DLEP session,= the length of Link=C2=A0
&= gt; Identifiers=C2=A0
> = 182 MUST remain constant, i.e. the Length field of the Link=C2=A0
> Identifier=C2=A0
> 183 Data Item MUST NOT differ betwee= n destinations.=C2=A0
><= span class=3D"Apple-converted-space">=C2=A0
> [major] This is = another case where the session could be terminated if=C2=A0
> the wrong length is used... Call out = as a risk.=C2=A0

Damn..= I missed this one. I shall have to uprev with specific=C2=A0
Termination rules.=C2=A0

Yup.<= /p>


...

=
> ...=C2=A0=
> 281 4. Security Considerations=C2=A0
>=C2=A0<= br>> 283 As an extension to the core DLEP protocol, the security=C2=A0
> 284 considerations of t= hat protocol apply to this extension.= =C2=A0
> This=C2=A0
> 285 extension adds no additional security mechanisms or=C2=A0
> features.=C2=A0
>=C2=A0
> 287 None of the features introduced by this ex= tension require=C2=A0
> = extra=C2=A0
> 288 consid= eration by an implementation.=C2=A0
>=C2=A0
> [m= ajor] I think that the functionality in this extension may result=C2=A0
> in Invalid Data (and a te= rminated session) -- see the comments in=C2=A0
> =C2=A72/2.1 above. While this case may only be the= result of a rogue=C2=A0
&g= t; modem/router, and rfc8175 already says something general about that,=C2=A0
> it is important to = point it out here because the=C2=A0
> functionality/operation is new.=C2=A0
>=C2=A0

Having called out the additional reasons for termination, I do= n't see=C2=A0
that any = of them cause any additional security considerations beyond=C2=A0
normal DLEP. The consideration is: d= eviate from the protocol and your=C2= =A0
session will terminate - that's covered by DLEP.=C2=A0
<= /div>

True=E2=80=A6but now with a bigger attack surface= .=C2=A0 I would love to see something pointing at rogue routers/modems taki= ng advantage of termination opportunities=E2=80=A6but we can also wait and = see what the SecDir/SEC ADs say=E2=80=A6

--000000000000b4db9e058f127c2c-- From nobody Thu Aug 1 11:48: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 E592E12017D; Thu, 1 Aug 2019 11:48:37 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: manet-chairs@ietf.org, manet@ietf.org, aretana.ietf@gmail.com, draft-ietf-manet-dlep-lid-extension@ietf.org, bebemaster@gmail.com, Justin Dean Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156468531789.19289.13094232676664639255.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2019 11:48:37 -0700 Archived-At: Subject: [manet] Last Call: (DLEP Link Identifier 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: Thu, 01 Aug 2019 18:48:38 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'DLEP Link Identifier Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol assumes that every modem in the radio network has an attached DLEP router, and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination. This document describes a DLEP Extension allowing modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Aug 1 11:59:24 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 8CAEC120182; Thu, 1 Aug 2019 11:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB53uiSZ2qWY; Thu, 1 Aug 2019 11:59:21 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 F0901120168; Thu, 1 Aug 2019 11:59:20 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id s49so35349889edb.1; Thu, 01 Aug 2019 11:59:20 -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=KzLXPSmAb3A0Heje7g8YitusQ0h3WE1rJcKuU7Qbx0k=; b=Yex5HFK39LVyG53sn1mp4utDnbhzmrE8XcZOMFFMrimq4WrqjpLIPYHumDWo1VVlWG mY4unfYAh9y1ptcvqiZEHe0do7s18UT6c3jfVj6j3k2ioTNJTqBSyAmOz/3uKjLvLdKB B5fGg4YNJRTNL894FwThpAg4WCSfYXV103L/prk0j29NCOwxVAs3oo2ilqlIeyAqa8Sz qjNlDPQNgHU94QHaiBtfwBQea1+ps8G4azuzkC35Ug4y5SvbTfn4iQOKt6covMQD5kjN 9UoydCHr/+rMxMEcWyjfE8boGEBElT1VIH6XWhO7EQXL19mCpyD/C+9tY4Uj4EfiMCti ZMWQ== 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=KzLXPSmAb3A0Heje7g8YitusQ0h3WE1rJcKuU7Qbx0k=; b=IPhM/mkzSTao5p+PTRB/khSy1VPnofGhnOhpD7Mq/Vq+W76S+nIXr6MgA+Zmsiw5Yh EaD1KsJoX7ZuzosMeScPFSDa2lNsHx0i1F1ma8OFZLvGXnBzt5/3HVOcA6BTc9GaO1es yxaFdF+TsW3+Oz55NpZLQP090IHNtztb/3sh2lq7Z8dip2TWQnOcdwQWKO4ehLpeGWE4 aFs7Dq+DxibYdYsdKzgDpL3CSFEmd7HiN0DmqxuyL88+ua8k3eTQDxNydA+rgLn+HG5j xVXQFfy2mIHVcDwqIqbqdvpBuPE11sfBEhTEIUbi2cp9pgqnFCV//Wrf9qtib0V8Csl7 xNJw== X-Gm-Message-State: APjAAAU/yIeTYSi4aVi+M5MlhCrL7N1lAR8MLhdBwlwBEZ9betNc22bG iLkSKIdipk0f964UbWuOzAWM1cc+5sKtMDvenyE= X-Google-Smtp-Source: APXvYqwhYikXGJXI9kylIKteVC2KpzETk00edKA/NJBQuhb2M4/INMah2EI6bTYVXrTCHg2NM+0j+RTk2c9iFZskU8U= X-Received: by 2002:a50:a5ec:: with SMTP id b41mr111759644edc.52.1564685959485; Thu, 01 Aug 2019 11:59:19 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 1 Aug 2019 20:59:18 +0200 From: Alvaro Retana In-Reply-To: <602708730af3b1f89b37d39ba109e212a7ccb9d2.camel@tropicalstormsoftware.com> References: <602708730af3b1f89b37d39ba109e212a7ccb9d2.camel@tropicalstormsoftware.com> MIME-Version: 1.0 Date: Thu, 1 Aug 2019 20:59:18 +0200 Message-ID: To: Rick Taylor , "draft-ietf-manet-dlep-lid-extension@ietf.org" Cc: "manet@ietf.org" , "manet-chairs@ietf.org" , Justin Dean Content-Type: multipart/alternative; boundary="000000000000ccde41058f12d69e" 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: Thu, 01 Aug 2019 18:59:23 -0000 --000000000000ccde41058f12d69e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On July 30, 2019 at 12:13:46 PM, Rick Taylor (rick@tropicalstormsoftware.co= m) wrote: Rick: Hi! I am starting the IETF LC. My only remaining comments are about security (see below), but we can deal with that as we get other reviews. Thanks! Alvaro. Comments inline, but a little forward: We have done a rewrite of most of the descriptive text, focussing on the use-cases, and attempting to clearly define terminology to aid the reader. I think that helps. :-) The new text in the Abstract/Introduction says: "The core specification of the protocol assumes that every modem in the radio network has an attached DLEP router, and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network=E2=80=A6= This document describes a DLEP Extension allowing modems that do not meet the strict requirement above=E2=80=A6=E2=80=9D. It is not clear if the =E2=80= =9Cstrict requirement=E2=80=9D you refer to is the assumption that a router is attached, or that its MAC address is used=E2=80=A6or both. I think this is important to justify tha= t, for example, other Security Considerations are not created. Just trying to cover our bases=E2=80=A6I don=E2=80=99t have anything specific to point out= . ... > ... > 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. I don't know how to avoid this - can you suggest some text please? s/[RFC8175]/(RFC8175) ;-) ... > > 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. Damn.. I missed this one. I shall have to uprev with specific Termination rules. Yup. ... > ... > 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. > Having called out the additional reasons for termination, I don't see that any of them cause any additional security considerations beyond normal DLEP. The consideration is: deviate from the protocol and your session will terminate - that's covered by DLEP. True=E2=80=A6but now with a bigger attack surface. I would love to see som= ething pointing at rogue routers/modems taking advantage of termination opportunities=E2=80=A6but we can also wait and see what the SecDir/SEC ADs = say=E2=80=A6 --000000000000ccde41058f12d69e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On July 30, 2019 at 12:13:46 PM, Rick Taylor (rick@tropicalstormsoftware.com) wrote:

Rick:

Hi! =C2=A0

<= /div>
I am starting the IETF LC.

My only remaining comments are about security (see below), but we can dea= l with that as we get other reviews.

Thanks!

Alvaro.




Comments inline, but a little for= ward:=C2=A0

We have don= e a rewrite of most of the descriptive text, focussing on=C2=A0
the use-cases, and attempting to clear= ly define terminology to aid the=C2= =A0
reader.=C2=A0

I think that helps. :-)

The new= text in the Abstract/Introduction says: "The core specification of th= e protocol assumes that every modem in the radio network has an attached DL= EP router, and requires that the MAC address of the DLEP interface on the a= ttached router be used to identify the destination in the network=E2=80=A6 = =C2=A0This document describes a DLEP Extension allowing modems that do not = meet the strict requirement above=E2=80=A6=E2=80=9D. =C2=A0 It is not clear= if the =E2=80=9Cstrict requirement=E2=80=9D you refer to is the assumption= that a router is attached, or that its MAC address is used=E2=80=A6or both= . =C2=A0 I think this is important to justify that, for example, other Secu= rity Considerations are not created.=C2=A0 Just trying to cover our bases= =E2=80=A6I don=E2=80=99t have anything specific to point out.


...

> ...=C2=A0
>= 11 Abstract=C2=A0
>=C2=A0
> 13 There exists a c= lass of modems that would benefit from=C2=A0
> supporting the= =C2=A0
> 14 Dynamic Link Exchange Protocol (DLEP) [RFC8175] bu= t do not=C2=A0
> present= a=C2=A0
> 15 single Lay= er 2 network domain as required by DLEP. Such=C2=A0
> devices may=C2=A0
> 16 be:=C2= =A0
>=C2=A0
&g= t; [nit] Don't include references in the Abstract.=C2=A0

I don't know how to avoid this - = can you suggest some text please?=C2= =A0

s/[RFC8175]/(RFC8175) = =C2=A0;-)


...

>= =C2=A0
> 173 2.1. Identifier Restrictions=C2=A0
>=C2=A0
> 175 A Link Identifier is by default 4 octets in leng= th. If a=C2=A0
> modem=C2=A0
> 176 wishes to use= a Link Identifier of a different length, it=C2=A0
> MUST be= =C2=A0
> 177 announced using the Link Identifier Length Data I= tem=C2=A0
> (Section 3.1= )=C2=A0
> 178 contained = in the DLEP Session Initialization Response=C2=A0
> message sent by=C2=A0
> 179 the modem to the router.=C2=A0
>=C2=A0
> 181 During the lifetime of a DLEP session, the len= gth of Link=C2=A0
> Iden= tifiers=C2=A0
> 182 MUST= remain constant, i.e. the Length field of the Link=C2=A0
> Identifier=C2=A0
> 183 Data Item MUST NOT differ between destin= ations.=C2=A0
>=C2=A0
> [major] This is another = case where the session could be terminated if=C2=A0
> the wrong length is used... Call out as a ris= k.=C2=A0

Damn.. I misse= d this one. I shall have to uprev with specific=C2=A0
Termination rules.=C2=A0

Yup.

...

> ...=C2=A0
>= 281 4. Security Considerations=C2=A0=
>=C2=A0
> = 283 As an extension to the core DLEP protocol, the security=C2=A0
> 284 considerations of that prot= ocol apply to this extension.=C2=A0
> This=C2=A0
&g= t; 285 extension adds no additional security mechanisms or=C2=A0
> features.=C2=A0
>= =C2=A0
> 287 None of the features introduced by this extension= require=C2=A0
> extra=C2=A0
> 288 consideration= by an implementation.=C2=A0>=C2=A0
> [major] I= think that the functionality in this extension may result=C2=A0
> in Invalid Data (and a terminate= d session) -- see the comments in=C2= =A0
> =C2=A72/2.1 above. While this case may only be the resul= t of a rogue=C2=A0
> mod= em/router, and rfc8175 already says something general about that,=C2=A0
> it is important to point = it out here because the=C2=A0<= br>> functionality/operation is new.=C2=A0
>=C2=A0<= br>
Having called out the additional reasons for termination, I don'= t see=C2=A0
that any of the= m cause any additional security considerations beyond=C2=A0
normal DLEP. The consideration is: deviate= from the protocol and your=C2=A0
session will terminate - that's covered by DLEP.=C2=A0

True=E2=80=A6but now with a bigger attack surface.=C2=A0= I would love to see something pointing at rogue routers/modems taking adva= ntage of termination opportunities=E2=80=A6but we can also wait and see wha= t the SecDir/SEC ADs say=E2=80=A6

--000000000000ccde41058f12d69e-- From nobody Sun Aug 4 18:21:29 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 1DC7112013A; Sun, 4 Aug 2019 18:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-latency-extension@ietf.org, Justin Dean , aretana.ietf@gmail.com, manet-chairs@ietf.org, bebemaster@gmail.com, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156496808011.26446.1857465769617803647.idtracker@ietfa.amsl.com> Date: Sun, 04 Aug 2019 18:21:20 -0700 Archived-At: Subject: [manet] Roman Danyliw's No Objection on draft-ietf-manet-dlep-latency-extension-04: (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: Mon, 05 Aug 2019 01:21:20 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-manet-dlep-latency-extension-04: 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-latency-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few questions on unexpected values: ** Section 3. How do the maximum and minimum latency fields relate? For example, what happens if a receiver gets a message where the maximum latency is smaller than the minimum latency. ** Section 3. How do the latency data item and the latency range item relate? For example, what happens if a receiver gets a message that has both a latency data item and a latency range data item, and the reported latency is outside of the latency range? From nobody Tue Aug 6 02:03:55 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 E6ED712014F; Tue, 6 Aug 2019 02:03:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: draft-ietf-manet-dlep-lid-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <156508221782.19312.14665262406766852305@ietfa.amsl.com> Date: Tue, 06 Aug 2019 02:03:37 -0700 Archived-At: Subject: [manet] Genart last call review of draft-ietf-manet-dlep-lid-extension-05 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: Tue, 06 Aug 2019 09:03:38 -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-lid-extension-05 Reviewer: Stewart Bryant Review Date: 2019-08-06 IETF LC End Date: 2019-08-15 IESG Telechat date: Not scheduled for a telechat Summary: A well written document with a few nits that should be looked at. Major issues: None Minor issues: None Nits/editorial comments: " The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a" Nits says that the "[]" brackets should be removed ========== " None of the features introduced by this extension require extra consideration by an implementation." I think that should be "None of the features introduced by this extension require extra security consideration by an implementation." ============== "Assign a new DLEP Extensions Registry value (TBD1) from the" I think that should be "Assign a new DLEP Extensions Type Values Registry value (TBD1) from the" ============== From nobody Tue Aug 6 02:50:54 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 CDF2012027F; Tue, 6 Aug 2019 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 W97qjik2NtvP; Tue, 6 Aug 2019 02:50:29 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76609120153; Tue, 6 Aug 2019 02:50:26 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0468.000; Tue, 6 Aug 2019 10:50:24 +0100 From: Rick Taylor To: Stewart Bryant , "gen-art@ietf.org" CC: "draft-ietf-manet-dlep-lid-extension.all@ietf.org" , "manet@ietf.org" , "ietf@ietf.org" Thread-Topic: [manet] Genart last call review of draft-ietf-manet-dlep-lid-extension-05 Thread-Index: AQHVTDYAaRFIFE0oEkyVt2Y2uVRzqqbt39OQ Date: Tue, 6 Aug 2019 09:50:22 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801E6BFF315@tss-server1.home.tropicalstormsoftware.com> References: <156508221782.19312.14665262406766852305@ietfa.amsl.com> In-Reply-To: <156508221782.19312.14665262406766852305@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:1648:4000:120:15fe:c469:8a18:dba8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Genart last call review of draft-ietf-manet-dlep-lid-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 09:50:38 -0000 Hi Stewart, Thanks for the prompt review. We will wait for a few more reviews and publ= ish a fixed document. Many thanks, Rick > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stewart Bryant > via Datatracker > Sent: 06 August 2019 10:04 > To: gen-art@ietf.org > Cc: draft-ietf-manet-dlep-lid-extension.all@ietf.org; manet@ietf.org; > ietf@ietf.org > Subject: [manet] Genart last call review of draft-ietf-manet-dlep-lid- > extension-05 >=20 > Reviewer: Stewart Bryant > Review result: Ready with Nits >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-manet-dlep-lid-extension-05 > Reviewer: Stewart Bryant > Review Date: 2019-08-06 > IETF LC End Date: 2019-08-15 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: A well written document with a few nits that should be looked at= . >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 > " The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a" >=20 > Nits says that the "[]" brackets should be removed >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > " None of the features introduced by this extension require extra > consideration by an implementation." >=20 > I think that should be >=20 > "None of the features introduced by this extension require extra > security consideration by an implementation." >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > "Assign a new DLEP Extensions Registry value (TBD1) from the" >=20 > I think that should be >=20 > "Assign a new DLEP Extensions Type Values Registry value (TBD1) from the" >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Aug 6 10:59:40 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 769A1120630; Tue, 6 Aug 2019 10:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=S+TLb3A9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ch6FMa7y 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 xkEZz6ZSdPDw; Tue, 6 Aug 2019 10:59:22 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFDD12035A; Tue, 6 Aug 2019 10:59:19 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id AF6AA49D; Tue, 6 Aug 2019 13:59:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 06 Aug 2019 13:59:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=4 zwJ/mXtFJHNMi9HwIBwjIwL5bQC1XNAU1R0taTlwZQ=; b=S+TLb3A9nJIz0fZpI YKvyMFNCEMlr4RLZEJMiPjxbLVUzfWlYZJxixkNAtZWxHR9aXkiWN720QfY/Usby 5Z0VsZJUybAYnG+ojsINEyqE8x7J5/qSTO9gjqEpuil2Cvbzfj79/r1yGTcgDAQ4 HkxasehKCAStlEbFfbHo29G36TevsL3SGsJN+8K5NUJJCPzag5bHwzPfrN7eMK71 T0uwLNB1BxWkDwSkbFM8SK/C8B9TDDBtQP9jqU1wDQXWZolEnjv1svbnL7SGTiiv nNeCob+yrqsI11NbLtq99AC1EhzCeHPouaYEvHVcKekkXS5IKqeL/twykvYD9Azw cxgfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=4zwJ/mXtFJHNMi9HwIBwjIwL5bQC1XNAU1R0taTlw ZQ=; b=ch6FMa7yHZiHbckcE3GT7QH5O09LIPzSZnGWofbwurYI1koe/x4Ogle+M fXX3aZRy6y3Qq/CftcC1iiTbqkGVwJNRzrKfxLkfYO9n0SskJJzs/Ypc0AJFK1ft UQ2RLxOUxGWe0yiitOxrbU1v8u806g99KANfgXHI3xmSeJMkyJIe/U1jWijs2cCA 9/pL+PskiVndry/+Njn1+INVt8WqtNz6xhoAAYcLouLZaVj9X9nfFz5r0S2jg85N afvHzsaLdbYYXF1BtabjJyUhDKHGm/Y/8nc8wHsqmHk7zBMroSidEsal4P9qp3Au T+RdoyNT/Z+m3cjiUpanO4kwaAq+w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddutddguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id D3AE038008D; Tue, 6 Aug 2019 13:59:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156154306499.20237.6931841641823410723@ietfa.amsl.com> Date: Tue, 6 Aug 2019 13:59:16 -0400 Cc: gen-art@ietf.org, manet@ietf.org, ietf@ietf.org, draft-ietf-manet-dlep-latency-extension.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02F50F9B-CA8A-4B75-A1C9-9FB106A1E645@cooperw.in> References: <156154306499.20237.6931841641823410723@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [manet] [Gen-art] Genart last call 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: Tue, 06 Aug 2019 17:59:25 -0000 Stewart, thanks for your review. I entered a No Objection ballot. = Comments below. > On Jun 26, 2019, at 5:57 AM, Stewart Bryant via Datatracker = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready with Nits >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > 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 >=20 > Summary: A very simple well written document ready for publication = except for > one nit and one question. >=20 > Major issues: None. >=20 > Minor issues: >=20 > A 64-bit unsigned integer, representing the longest transmission > delay, in microseconds, that a packet encounters as it is > transmitted over the link. >=20 > 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? I can see the value in this, but presumably consistency with the units = for the base spec that defines the latency data item is more important = for implementation simplicity. Alissa >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Nits/editorial comments: >=20 > DLEP Latency Range Extension > draft-ietf-manet-dlep-latency-extension-04 >=20 > Abstract >=20 > This document defines an extension to the DLEP protocol to provide > the range of latency that may be experienced on a link. >=20 > 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. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Fri Aug 9 11:43:28 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 8DDFB12002F for ; Fri, 9 Aug 2019 11:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 JdntCev5xxz9 for ; Fri, 9 Aug 2019 11:43:24 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 ED9E5120019 for ; Fri, 9 Aug 2019 11:43:23 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id x79IhMOg045582 for ; Fri, 9 Aug 2019 14:43:22 -0400 From: "Wiggins, David - 0665 - MITLL" To: "manet@ietf.org" Thread-Topic: DLEP redundant Destination Ups Thread-Index: AQHVTuJFidsVE35B90GHgDX2g+eI7Q== Date: Fri, 9 Aug 2019 18:43:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3648206580_1142812520" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=908 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908090182 Archived-At: Subject: [manet] DLEP redundant Destination Ups 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, 09 Aug 2019 18:43:26 -0000 --B_3648206580_1142812520 Content-type: multipart/alternative; boundary="B_3648206580_1247471482" --B_3648206580_1247471482 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable If a modem sends two Destination Ups for the same destination without an in= tervening Destination Down for that destination, how should the router respo= nd? =20 a) This is a protocol error.=C2=A0 Terminate the session. b) Ignore the second Destination Up. c) Treat the second Destination Up as a Destination Update. d) something else =20 Thanks, David =20 --B_3648206580_1247471482 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

If a modem = sends two Destination Ups for the same destination without an intervening De= stination Down for that destination, how should the router respond?

 

a) This is = a protocol error.=C2=A0 Terminate the session.

b) Ignore the second Destination Up.

c) Tre= at the second Destination Up as a Destination Update.

<= p class=3DMsoNormal>d) something else

 

Thanks,=

David

 

--B_3648206580_1247471482-- --B_3648206580_1142812520 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUigYJKoZIhvcNAQcCoIIUezCCFHcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJQMIIE/jCCA+agAwIBAgITWQADvo+kDjDfv+QhfgAAAAO+jzANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMxODEzNTA1MFoXDTIyMDMx NzEzNTA1MFowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lucy5EYXZpZC5QLjUwMDE1MjA3 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoHcFpwES6qGfghStCyHNgTkrbxvz he4p2CB/4gtIFD18nYS25JrAn1AGK6+ZJleci5ChQJmSqF0lPNYk69n4XhMosSXtueb/RDUC xDO56fpJyOaaWNkKFJGEwMG937YRx4VKYqhFgnHKq8X3/u09805DTB6B0ucbMm77j235/pvb JOlp1aEfnXUteWwqromHZXcv81OdDMZz3hggAwUvsUiBV+m28PJxwxNZV55xxCBwjrRhrLnF bxR7E15QvsTsPdnlLBQapM/XoVK0EuxdM9YWCynddAgCzHOFgUK+MlN+GfTBIC1tupjqVmPf KZMoch9viZh+BwS/ZcyIPcDz+wIDAQABo4IBvDCCAbgwHQYDVR0OBBYEFMxxYWZdPlsQKWQT Oli11kLZ59XLMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQv77vGDR276Wr+rGfzBzsI dvZLWTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL2xs Y2E1MGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1 L2dldHRvL2xsY2E1MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3Aw PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/ inMCAWQCAQgwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwIwYDVR0RBBww GoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgw JwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsF AAOCAQEAQPSEoZ+9fCPazAOc9tOAskNiy+apnsqUvFVxshsZeTg/0q7zsTp5P5rL2GViH0by Ww+xrHWBczbjmSzsl7qgKWuCQkmOkNdBVf1kvQi4cpTmEIj4/lD8vo9e/JGsQkOb+QIZXwHY u02d+rDweRb90yKAMvAeKWZghb6XDV6hGGZKVGID5rJhQT4nPBHUFnxKmbdnb8WB7VXwNLcO ZklkKpehA/74XK1g6cKssRUp7sfj95eYtv0V69D81GWOPZ1DVTbD/E9oa+huK9yhDppGTr87 Y80RboGOUabPREB1r3v7YcouTOpyioUQvhnOOtWx5XcVKdUjLluEdx/L7viKHzCCBMAwggOo oAMCAQICAQYwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBD QS0yMB4XDTE3MDMwMjEyMDAwMFoXDTI2MDMwMjIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAd BgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsMA1BLSTETMBEGA1UEAwwK TUlUTEwgQ0EtNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKeagw69OR/DuerX 2atZrMZpr5DzdS/T4BNdPerqSv5YTEgwhnzsLvhYJxFem87u6/Hse8yxhYAUdb3fBDCGPK3E cg5mAo0nhWcZUNSX4ojuDSf35mO3eEHceEdty9t735jiPP5fMKIuXY5pi8gIpvG9sFIIu08R 5lDrHpNvoQrTKbSC9h4c7eS65j5IkckyW1usuchUvGNms1VLvvNcq+7pDeFJ2REgHuQmARd8 v6n/P/an3hsQRnZOdDPROQ6Mb4mrtSVeUVG2+xhwM8RAPdQ2RmxZxeALWFcbxMaSdRwCGUbF WGUqUUuY13vfjax4bLaz1jE0OdIT55dO1vQjkssCAwEAAaOCAZwwggGYMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFC/vu8YNHbvpav6sZ/MHOwh29ktZMB8GA1UdIwQYMBaAFP/J yWVMU4DxqQw8Ia6CKsfu+DL7MA4GA1UdDwEB/wQEAwIBhjBnBggrBgEFBQcBAQRbMFkwLgYI KwYBBQUHMAKGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTFJDQTIwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA0BgNVHR8ELTArMCmgJ6AlhiNodHRw Oi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMUkNBMjCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3 EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0G CyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIB AwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQAwlhHAs8n3Urt7aYDY2PXR bSjkkwdiRpr5y0vz/FjxDMgcUjkiP6LJ2k830oJif/hLLzRPdo2hiQWVLQZFBeF/SeyJjtNY nAArDgCI7/Infv+hEpGC3JGJy9onpGOUcJcE5qUUvD1S2mh0/j+J0LnWXHOyiVpBmtoGNV7s 8v3k+FLsP7bY198ifMt0hvUMF/ng3A5V88iAAG3EfV+FmuNrsSFH1GhTDkTU7qJZoC4//FaF JNAVaWHIDT+SQiL38ddpjSFieFyNxs8+qOnJ8iFIWONeGOoru3bA+tKsEUsVRucuI2WBAeu8 1gXkiqAh+dIFYiubet8uGllkn/Enth/oMIIDijCCAnKgAwIBAgIBATANBgkqhkiG9w0BAQsF ADBWMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9NSVRMTCBSb290IENBLTIwHhcNMTYwNDIwMTIwMDAwWhcN MzUwNDE5MjM1OTU5WjBWMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9NSVRMTCBSb290IENBLTIwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/dagEQY44m2bi5y9p/q8ogU+zzBq0J3pKbCr9 d5E2js/eM8jE0/AXf3xEYNSY8khcDuJ3MPqPSikUhb6QupjJ717vzw9XR2pomVfzzXx80NtI T7wHqGJ6opNHtV84jvhRVARQpVEW5EXDq5Vi6+B7DZOP8LZ0R57ft6u5CXmceRtXY6xadns7 7K35613odFxpcuU/2rxYqADcHu+Q5UgwIqgC5paP4EWrsr5Y2SLKL8p04f0mY6lvJEriNwDv FsucXwkVRI2DlzhjUEmsVpm2QJ4bo2b2nnbgaWWREXM+CmPxWJxX4Ar72tjTt1PHTaRii1Oc q7LRjEEDCxRfEBATAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFP/JyWVM U4DxqQw8Ia6CKsfu+DL7MB8GA1UdIwQYMBaAFP/JyWVMU4DxqQw8Ia6CKsfu+DL7MA4GA1Ud DwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOCAQEAeph8R//cnlowqGVhDQ+dQBswHyNlKv38 e+N84XTRysVQJ9KuobwlDCj5L+KrrqBynrYUSAnR9CQOBWDqb4LYROjUuhaJLGFgJ9xIhAQK WOVfBHzAVJrIXzbZLr0iq8eF2rh3nyNTqBiLqyyNTi/Cy+xUtEkqT+b8KD/DyBbpgczlqEEP r/kJx6XZ8juhKayQ733X6i2sLXVh8PAIW/PsCbSv4r2JWFJa1riGYi5XRgGJrTt5kpI7TYs+ BDxg7PeS7Ri36aHxVZEq7HYJxiMymT5YNXQEynvm2pvqmoEWRwq8QFerGD7z4b+6aOKLgfRz mS8mFpDLKRuY4qbE70hwkjCCBPgwggPgoAMCAQICCh+ce+UAAAAA6kQwDQYJKoZIhvcNAQEL BQAwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xOTAzMTgxNDEyMzFaFw0yMDEy MzEyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAfBgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIw NzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALkTZmZ3NPgqHJcYj7vburQKPzpI IksAdpgZ7SbGhxIRROLIdKDhHFzMAKMMu1vqIfuiaoavPZtG9HEP4sBsIre8r/aIee3N5v2V qiw+uhSMZsI3UC58GsFoJIEZcfCfH7cwtGBdQJq1xZ4hS+3U2r0/QDqGnJyyed1CX26RdLNr DXXMmj3BD4YlI4IBZD/494EQMzM1FGX64/mh987npZULmAoQeKzI11w9YfYjxuj7cZlLi0jh kj1cU1f32lOPg+5dxZVsZkTp1SHwKrXoappe+ML5KL82yc8iKzopsyGV0A6/LaTEpAoUX5Bc GHoBWQkd9llLgv0C45SuRa5GYykCAwEAAaOCAb8wggG7MB0GA1UdDgQWBBQAFD7iXQy8gJXq fQvOZnMaq54Z1DAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7I xxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9M TENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD 6+0gAgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1Ud IAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYDVR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQu ZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcN AQELBQADggEBAME3QtbTKQFZM21PzwrS5Nu0/2tZc+/S0ZN/pFBXXzKFmp3go+F/0Cw/ViVh dfpIGCGGvih4wwizPcfsSaCLKUaZfyLVt4DxhJAp/R5xhz0g2cPdzfA4ar2vJpT3msRi//Vl OtnlD9+6yQAiDFCB4ZgrYqJ14QHYa93b+tzaCG0m8lhslODb94KPYzubVPW8pSiEDYxPssiR Atn5O8Nxdrj9wcI+VR+bwKT9Tt4Iy1aYaSfOaoh8HenIZ8rOXQA9A6BcoPimxxjTVsx/DsBH q29lg08GbP+M0+26QZNx9gxWXzt3Kfnn2YxUKFePn2UV877SUBEP9W+jyPOgaHACGxQxggH+ MIIB+gIBATBoMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUCE1kAA76PpA4w37/kIX4A AAADvo8wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgx7/ECXAqiS0dQaGVsbYn FtCFatDv4AoXIxViHJVINZEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwODA5MTg0MzAwWjANBgkqhkiG9w0BAQEFAASCAQAUfu8H82tVTrg799Fzk10V jIdE/7mjP68cyta6JT9QeqlRPMmsYHG7lyEnSZiYv5QXBftdf0FteTuAG608q31i8KnXlJok KuIB42zT7n4PeqkEYmR7cKSZzepVn37Z8vm5ZKxZvx7gf4Wpks2fnz34f0Vrz+/vt6d0lJ/M XaOatyACsRtF0Fjt3dnA1uJp64JRYFwumk77ISG98uquXdWjmIb9C92IYXoLL85b6lMPIBHt ZanFE0uhVy0TkSk3WTftD7cESQvqyh5PkJt6tvc2fSibhl52VaUItDAvEC0FIcYTz7Q+HNMC jFBB7AML7pIvkpk75xnxW2ZL7agRCSi8 --B_3648206580_1142812520-- From nobody Fri Aug 9 12:33:15 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 B1073120019 for ; Fri, 9 Aug 2019 12:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 xyK-9x14xFWt for ; Fri, 9 Aug 2019 12:33:12 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 EEFB512002E for ; Fri, 9 Aug 2019 12:33:11 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id a93so45278403pla.7 for ; Fri, 09 Aug 2019 12:33:11 -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 :cc; bh=HgmMAauDrcf9J55PYy6uC6h6bg/HIXRaT1xqsotFJM0=; b=ZWGKIdhC+IK6GoOVBIKU1WPgJeOWmBel2pxMu16tzARxOt3KYoINsRvFO+tTCjOO3w kgL1iz+i+ecqBMiwpULzXZFamT3eZO4kPnrDd1DesKavqdxDbFuTNUlJS49dCwA7MgPR nHQjeFZzIbO5Rh4TNLbyTm5t/HrOi3toRVbqbbXqgrVxZIRM2zQc4O6LI+O4FsGddkLD Up4ct4y0a0OZ9aFF2210IKnZ/ieK+BTBUyVqxbQ0skVLJ8vpgS9nKW/smi7ldjmLzRc2 wDGBG9SmewJxbBBM+wQcyL+Fhq2KYk1U3AWnutInfN21e8GYPgX2rtn7FjLzBUYpIDFc xcIg== 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:cc; bh=HgmMAauDrcf9J55PYy6uC6h6bg/HIXRaT1xqsotFJM0=; b=LSAUUfxxQj2gdGg/jqTMv6i58LZCVxx2b1ET+ydC3EoOxpjjRKh0ZO8W0XeKObZr64 ALWTKeFQZ+vCvIY6E12UmlnlTjy2NiR4tYpJCZ4ZVJ2F3FYdu1vjbvFyq1fliQNBS5km hreh3n88R8j+ZfzRrD2IlmbfC8tk8e0/uU/aIos9vq0opdOIVUWyIsoTjiYBLU74rBVE 7lKKPNZrIdYWocaM8vYZYzkqygzu4YH7ihNyBZ+NzY2rvqRSB+YTupUGh0AgPhK/bsac ARYSvbf073MYN1mY1z7lOXw/KSyKcxksguRqBIGqWKihXYaPkysAWFsw6yHl2WXtwlFg gSwQ== X-Gm-Message-State: APjAAAVXrpPFgoY0YMZYv7SjXil4vOazkv/SREaiKccCp25zBGR4Yqb0 +l4x6/AYW/kq6ypUF/0VqcJKwfjh4ZJDdGQ0ATxL5g== X-Google-Smtp-Source: APXvYqz7k/tPbY9OSM/FAKD7zynMh7/rFtgQvNZrZC+vta3hzHzWEBrM/G599MoYU388BujNDL3oqPoLlKo8FYE9dA4= X-Received: by 2002:a17:902:23:: with SMTP id 32mr4835891pla.214.1565379191358; Fri, 09 Aug 2019 12:33:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stan Ratliff Date: Fri, 9 Aug 2019 15:33:00 -0400 Message-ID: To: "Wiggins, David - 0665 - MITLL" Cc: "manet@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a3c74a058fb43e0b" Archived-At: Subject: Re: [manet] DLEP redundant Destination Ups 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, 09 Aug 2019 19:33:14 -0000 --000000000000a3c74a058fb43e0b Content-Type: text/plain; charset="UTF-8" David, This looks like it's a candidate for an errata. I think what *should* be done is for the router to respond with a "Destination Up Response", using a new status code that effectively says "State Error", or "Destination is already up". Then I think the router should treat the second Destination Up as a *Destination Down*, which resets the state error. My rationale for not just ignoring the 2nd Dest up, or treating it as a Dest Update is that there *could be* associated data with the Dest Up, like IPv4/IPv6 address data items, and/or connected subnet data items, that may or may not clash with the new Dest Up. IMO, best to clean it up and try again "from scratch". I don't think this sould trigger a complete peer session outage. Other opinions? Regards, Stan On Fri, Aug 9, 2019 at 2:43 PM Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > If a modem sends two Destination Ups for the same destination without an > intervening Destination Down for that destination, how should the router > respond? > > > > a) This is a protocol error. Terminate the session. > > b) Ignore the second Destination Up. > > c) Treat the second Destination Up as a Destination Update. > > d) something else > > > > Thanks, > > David > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --000000000000a3c74a058fb43e0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David,

This looks like it's a= candidate for an errata. I think what *should* be done is for the router t= o respond with a "Destination Up Response", using a new status co= de that effectively says "State Error", or "Destination is a= lready up". Then I think the router should treat the second Destinatio= n Up as a *Destination Down*, which resets the state error.=C2=A0

<= /div>
My rationale for not just ignoring the 2nd Dest up, or treating i= t as a Dest Update is that there *could be* associated data with the Dest U= p, like IPv4/IPv6 address data items, and/or connected subnet data items, t= hat may or may not clash with the new Dest Up. IMO, best to clean it up and= try again "from scratch". I don't think this sould trigger a= complete peer session outage.=C2=A0

Other opinion= s?

Regards,
Stan

=C2=A0=C2=A0
--000000000000a3c74a058fb43e0b-- From nobody Fri Aug 9 13:50:03 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 76288120077 for ; Fri, 9 Aug 2019 13:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 AfaQ2_5kXdHp for ; Fri, 9 Aug 2019 13:49:59 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D304912006B for ; Fri, 9 Aug 2019 13:49:58 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0468.000; Fri, 9 Aug 2019 21:49:56 +0100 From: Rick Taylor To: Stan Ratliff , "Wiggins, David - 0665 - MITLL" CC: "manet@ietf.org" Thread-Topic: [manet] DLEP redundant Destination Ups Thread-Index: AQHVTuJFidsVE35B90GHgDX2g+eI7abzI/kAgAAlVeA= Date: Fri, 9 Aug 2019 20:49:56 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:1648:4000:120:15fe:c469:8a18:dba8] Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A715tssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP redundant Destination Ups 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, 09 Aug 2019 20:50:01 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A715tssserver1hom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQsDQoNCknigJltIG5vdCBzdXJlIHRoaXMgaXMgYW4gZXJyYXRhLCBidXQgc29tZSBjbGFy aWZpY2F0aW9uIG1heSBiZSByZXF1aXJlZC4gIEkgd291bGQgZXhwZWN0IGEgRGVzdGluYXRpb24g VXAgUmVzcG9uc2Ugd2l0aCBhbiBlcnJvciBzdGF0dXMgb2Yg4oCcSW52YWxpZCBEZXN0aW5hdGlv buKAnSAoVGVybWluYXRlKSBpZiB0aGUgcmVjZWl2ZXIgY2Fubm90IGhhbmRsZSB0aGUgc2l0dWF0 aW9uLCBvciBwZXJoYXBzIOKAnEluY29uc2lzdGVudCBEYXRh4oCdIGlmIGl0IGNhbiBjb250aW51 ZS4NCg0KRG9lcyB0aGF0IGhlbHA/DQoNCkNoZWVycywNClJpY2sNCg0KRnJvbTogbWFuZXQgW21h aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RhbiBSYXRsaWZmDQpT ZW50OiAwOSBBdWd1c3QgMjAxOSAyMDozMw0KVG86IFdpZ2dpbnMsIERhdmlkIC0gMDY2NSAtIE1J VExMDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVAgcmVkdW5k YW50IERlc3RpbmF0aW9uIFVwcw0KDQpEYXZpZCwNCg0KVGhpcyBsb29rcyBsaWtlIGl0J3MgYSBj YW5kaWRhdGUgZm9yIGFuIGVycmF0YS4gSSB0aGluayB3aGF0ICpzaG91bGQqIGJlIGRvbmUgaXMg Zm9yIHRoZSByb3V0ZXIgdG8gcmVzcG9uZCB3aXRoIGEgIkRlc3RpbmF0aW9uIFVwIFJlc3BvbnNl IiwgdXNpbmcgYSBuZXcgc3RhdHVzIGNvZGUgdGhhdCBlZmZlY3RpdmVseSBzYXlzICJTdGF0ZSBF cnJvciIsIG9yICJEZXN0aW5hdGlvbiBpcyBhbHJlYWR5IHVwIi4gVGhlbiBJIHRoaW5rIHRoZSBy b3V0ZXIgc2hvdWxkIHRyZWF0IHRoZSBzZWNvbmQgRGVzdGluYXRpb24gVXAgYXMgYSAqRGVzdGlu YXRpb24gRG93biosIHdoaWNoIHJlc2V0cyB0aGUgc3RhdGUgZXJyb3IuDQoNCk15IHJhdGlvbmFs ZSBmb3Igbm90IGp1c3QgaWdub3JpbmcgdGhlIDJuZCBEZXN0IHVwLCBvciB0cmVhdGluZyBpdCBh cyBhIERlc3QgVXBkYXRlIGlzIHRoYXQgdGhlcmUgKmNvdWxkIGJlKiBhc3NvY2lhdGVkIGRhdGEg d2l0aCB0aGUgRGVzdCBVcCwgbGlrZSBJUHY0L0lQdjYgYWRkcmVzcyBkYXRhIGl0ZW1zLCBhbmQv b3IgY29ubmVjdGVkIHN1Ym5ldCBkYXRhIGl0ZW1zLCB0aGF0IG1heSBvciBtYXkgbm90IGNsYXNo IHdpdGggdGhlIG5ldyBEZXN0IFVwLiBJTU8sIGJlc3QgdG8gY2xlYW4gaXQgdXAgYW5kIHRyeSBh Z2FpbiAiZnJvbSBzY3JhdGNoIi4gSSBkb24ndCB0aGluayB0aGlzIHNvdWxkIHRyaWdnZXIgYSBj b21wbGV0ZSBwZWVyIHNlc3Npb24gb3V0YWdlLg0KDQpPdGhlciBvcGluaW9ucz8NCg0KUmVnYXJk cywNClN0YW4NCg0KDQpPbiBGcmksIEF1ZyA5LCAyMDE5IGF0IDI6NDMgUE0gV2lnZ2lucywgRGF2 aWQgLSAwNjY1IC0gTUlUTEwgPERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTxtYWlsdG86RGF2aWQu V2lnZ2luc0BsbC5taXQuZWR1Pj4gd3JvdGU6DQpJZiBhIG1vZGVtIHNlbmRzIHR3byBEZXN0aW5h dGlvbiBVcHMgZm9yIHRoZSBzYW1lIGRlc3RpbmF0aW9uIHdpdGhvdXQgYW4gaW50ZXJ2ZW5pbmcg RGVzdGluYXRpb24gRG93biBmb3IgdGhhdCBkZXN0aW5hdGlvbiwgaG93IHNob3VsZCB0aGUgcm91 dGVyIHJlc3BvbmQ/DQoNCmEpIFRoaXMgaXMgYSBwcm90b2NvbCBlcnJvci4gIFRlcm1pbmF0ZSB0 aGUgc2Vzc2lvbi4NCmIpIElnbm9yZSB0aGUgc2Vjb25kIERlc3RpbmF0aW9uIFVwLg0KYykgVHJl YXQgdGhlIHNlY29uZCBEZXN0aW5hdGlvbiBVcCBhcyBhIERlc3RpbmF0aW9uIFVwZGF0ZS4NCmQp IHNvbWV0aGluZyBlbHNlDQoNClRoYW5rcywNCkRhdmlkDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGll dGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQNCg== --_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A715tssserver1hom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYXZpZCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PknigJltIG5vdCBzdXJlIHRoaXMgaXMgYW4gZXJyYXRhLCBidXQgc29tZSBjbGFyaWZpY2F0aW9u IG1heSBiZSByZXF1aXJlZC4mbmJzcDsgSSB3b3VsZCBleHBlY3QgYSBEZXN0aW5hdGlvbiBVcCBS ZXNwb25zZSB3aXRoIGFuIGVycm9yIHN0YXR1cyBvZiDigJxJbnZhbGlkIERlc3RpbmF0aW9u4oCd DQogKFRlcm1pbmF0ZSkgaWYgdGhlIHJlY2VpdmVyIGNhbm5vdCBoYW5kbGUgdGhlIHNpdHVhdGlv biwgb3IgcGVyaGFwcyDigJxJbmNvbnNpc3RlbnQgRGF0YeKAnSBpZiBpdCBjYW4gY29udGludWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Eb2VzIHRoYXQgaGVscD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmljazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3RhbiBSYXRsaWZmPGJyPg0K PGI+U2VudDo8L2I+IDA5IEF1Z3VzdCAyMDE5IDIwOjMzPGJyPg0KPGI+VG86PC9iPiBXaWdnaW5z LCBEYXZpZCAtIDA2NjUgLSBNSVRMTDxicj4NCjxiPkNjOjwvYj4gbWFuZXRAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gRExFUCByZWR1bmRhbnQgRGVzdGluYXRpb24g VXBzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EYXZpZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGxvb2tzIGxpa2UgaXQncyBhIGNhbmRpZGF0ZSBmb3IgYW4gZXJyYXRhLiBJIHRo aW5rIHdoYXQgKnNob3VsZCogYmUgZG9uZSBpcyBmb3IgdGhlIHJvdXRlciB0byByZXNwb25kIHdp dGggYSAmcXVvdDtEZXN0aW5hdGlvbiBVcCBSZXNwb25zZSZxdW90OywgdXNpbmcgYSBuZXcgc3Rh dHVzIGNvZGUgdGhhdCBlZmZlY3RpdmVseSBzYXlzICZxdW90O1N0YXRlIEVycm9yJnF1b3Q7LCBv ciAmcXVvdDtEZXN0aW5hdGlvbiBpcyBhbHJlYWR5IHVwJnF1b3Q7LiBUaGVuDQogSSB0aGluayB0 aGUgcm91dGVyIHNob3VsZCB0cmVhdCB0aGUgc2Vjb25kIERlc3RpbmF0aW9uIFVwIGFzIGEgKkRl c3RpbmF0aW9uIERvd24qLCB3aGljaCByZXNldHMgdGhlIHN0YXRlIGVycm9yLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcmF0aW9uYWxlIGZv ciBub3QganVzdCBpZ25vcmluZyB0aGUgMm5kIERlc3QgdXAsIG9yIHRyZWF0aW5nIGl0IGFzIGEg RGVzdCBVcGRhdGUgaXMgdGhhdCB0aGVyZSAqY291bGQgYmUqIGFzc29jaWF0ZWQgZGF0YSB3aXRo IHRoZSBEZXN0IFVwLCBsaWtlIElQdjQvSVB2NiBhZGRyZXNzIGRhdGEgaXRlbXMsIGFuZC9vciBj b25uZWN0ZWQgc3VibmV0IGRhdGEgaXRlbXMsIHRoYXQgbWF5IG9yIG1heSBub3QgY2xhc2gNCiB3 aXRoIHRoZSBuZXcgRGVzdCBVcC4gSU1PLCBiZXN0IHRvIGNsZWFuIGl0IHVwIGFuZCB0cnkgYWdh aW4gJnF1b3Q7ZnJvbSBzY3JhdGNoJnF1b3Q7LiBJIGRvbid0IHRoaW5rIHRoaXMgc291bGQgdHJp Z2dlciBhIGNvbXBsZXRlIHBlZXIgc2Vzc2lvbiBvdXRhZ2UuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk90aGVyIG9waW5pb25zPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U3RhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEF1ZyA5LCAyMDE5IGF0IDI6NDMgUE0gV2ln Z2lucywgRGF2aWQgLSAwNjY1IC0gTUlUTEwgJmx0OzxhIGhyZWY9Im1haWx0bzpEYXZpZC5XaWdn aW5zQGxsLm1pdC5lZHUiPkRhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SWYgYSBtb2RlbSBzZW5kcyB0d28gRGVzdGluYXRpb24gVXBzIGZvciB0aGUgc2FtZSBkZXN0 aW5hdGlvbiB3aXRob3V0IGFuIGludGVydmVuaW5nIERlc3RpbmF0aW9uIERvd24gZm9yIHRoYXQg ZGVzdGluYXRpb24sIGhvdyBzaG91bGQNCiB0aGUgcm91dGVyIHJlc3BvbmQ/PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ YSkgVGhpcyBpcyBhIHByb3RvY29sIGVycm9yLiZuYnNwOyBUZXJtaW5hdGUgdGhlIHNlc3Npb24u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+YikgSWdub3JlIHRoZSBzZWNvbmQgRGVzdGluYXRpb24gVXAuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+YykgVHJlYXQgdGhlIHNl Y29uZCBEZXN0aW5hdGlvbiBVcCBhcyBhIERlc3RpbmF0aW9uIFVwZGF0ZS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5kKSBzb21ldGhp bmcgZWxzZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EYXZpZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A715tssserver1hom_-- From nobody Sat Aug 10 08:56:09 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 D355D12009E for ; Sat, 10 Aug 2019 08:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 pPcAJiR01MzL for ; Sat, 10 Aug 2019 08:56:04 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 A9DA3120089 for ; Sat, 10 Aug 2019 08:56:04 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x7AFu1av017184; Sat, 10 Aug 2019 11:56:01 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , Stan Ratliff CC: "manet@ietf.org" Thread-Topic: [manet] DLEP redundant Destination Ups Thread-Index: AQHVTuJFidsVE35B90GHgDX2g+eI7abzd8sAgAAVfwCAAP0kAA== Date: Sat, 10 Aug 2019 15:55:58 +0000 Message-ID: <255BBAD2-529D-4C41-A763-1122448C64B5@ll.mit.edu> References: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3648282958_1469588457" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908100176 Archived-At: Subject: Re: [manet] DLEP redundant Destination Ups 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: Sat, 10 Aug 2019 15:56:08 -0000 --B_3648282958_1469588457 Content-type: multipart/alternative; boundary="B_3648282958_1749938944" --B_3648282958_1749938944 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Stan, Rick, =20 Thanks for the quick response.=C2=A0 It helps to know that you both think it sh= ould be an error (I do too), though we have different ideas on what the exac= t behavior should be.=C2=A0 I would probably go with Rick=E2=80=99s second suggestion,= =E2=80=9CInconsistent Data=E2=80=9D (Continue).=C2=A0 I=E2=80=99m not a fan of implementation-def= ined behavior, so I=E2=80=99d rather there be exactly one way to handle this.=C2=A0 Ac= tually I think =E2=80=9CInvalid Destination=E2=80=9D (Continue) would make a bit more se= nse, but the failure mode for =E2=80=9CInvalid Destination=E2=80=9D is defined to be Ter= minate, and there isn=E2=80=99t an easy way to change that. =20 This issue is one piece of the larger issue of how multicast destinations a= re handled.=C2=A0 I see in the minutes that was discussed at IETF 105; regrettab= ly, I wasn=E2=80=99t able to join the discussion.=C2=A0 So here is the difficulty I=E2=80=99= m having with multicast.=C2=A0 Let=E2=80=99s assume for a moment the following: =20 - Two Destination Ups for the same destination (without Down in between) is= a protocol error - A Destination Announce Response is exactly semantically equivalent to a D= estination Up - A Destination Announce w/ multicast destination is expressing a multicast= group join by the local node - A Destination Up w/ multicast destination expresses that some other node = has joined the multicast group =20 Then the following bad behavior can occur: =20 - Router sends Destination Announce w/ multicast destination (group) - Modem sends Destination Announce Response for that group, and this counts= as a Destination Up (by the above assumptions) - Some other node joins the same group, and this gets propagated via non-DL= EP means to the local modem - Modem sends a Destination Up for the group to let the router know there a= re other (unidentified) group members out there - Router considers this an error because it=E2=80=99s two Destination Ups for the= same destination =20 This is essentially what happens with our current implementation.=C2=A0 I=E2=80=99m v= ery interested in the intended way to handle this, as I=E2=80=99ll be updating our= implementation with whatever is decided. =20 Thanks, David =20 =20 =20 From: Rick Taylor Date: Friday, August 9, 2019 at 4:53 PM To: Stan Ratliff , "Wiggins, David - 0665 - MITLL" <= David.Wiggins@ll.mit.edu> Cc: "manet@ietf.org" Subject: RE: [manet] DLEP redundant Destination Ups =20 David, =20 I=E2=80=99m not sure this is an errata, but some clarification may be required. = I would expect a Destination Up Response with an error status of =E2=80=9CInvalid = Destination=E2=80=9D (Terminate) if the receiver cannot handle the situation, or p= erhaps =E2=80=9CInconsistent Data=E2=80=9D if it can continue. =20 Does that help? =20 Cheers, Rick =20 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff Sent: 09 August 2019 20:33 To: Wiggins, David - 0665 - MITLL Cc: manet@ietf.org Subject: Re: [manet] DLEP redundant Destination Ups =20 David, =20 This looks like it's a candidate for an errata. I think what *should* be do= ne is for the router to respond with a "Destination Up Response", using a ne= w status code that effectively says "State Error", or "Destination is alread= y up". Then I think the router should treat the second Destination Up as a *= Destination Down*, which resets the state error.=20 =20 My rationale for not just ignoring the 2nd Dest up, or treating it as a Des= t Update is that there *could be* associated data with the Dest Up, like IPv= 4/IPv6 address data items, and/or connected subnet data items, that may or m= ay not clash with the new Dest Up. IMO, best to clean it up and try again "f= rom scratch". I don't think this sould trigger a complete peer session outag= e.=20 =20 Other opinions? =20 Regards, Stan =20 =20 On Fri, Aug 9, 2019 at 2:43 PM Wiggins, David - 0665 - MITLL wrote: If a modem sends two Destination Ups for the same destination without an in= tervening Destination Down for that destination, how should the router respo= nd? =20 a) This is a protocol error. Terminate the session. b) Ignore the second Destination Up. c) Treat the second Destination Up as a Destination Update. d) something else =20 Thanks, David =20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --B_3648282958_1749938944 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Stan, Rick,

 

Thanks for the quick response.=C2=A0 It helps to know that you both= think it should be an error (I do too), though we have different ideas on w= hat the exact behavior should be.=C2=A0 I would probably go with Rick=E2=80=99s second= suggestion, =E2=80=9CInconsistent Data=E2=80=9D (Continue).=C2=A0 I=E2=80=99m not a fan of implem= entation-defined behavior, so I=E2=80=99d rather there be exactly one way to handl= e this.=C2=A0 Actually I think =E2=80=9CInvalid Destination=E2=80=9D (Continue) would make a= bit more sense, but the failure mode for =E2=80=9CInvalid Destination=E2=80=9D is defin= ed to be Terminate, and there isn=E2=80=99t an easy way to change that.=

 

This issue is one piece= of the larger issue of how multicast destinations are handled.=C2=A0 I see in t= he minutes that was discussed at IETF 105; regrettably, I wasn=E2=80=99t able to j= oin the discussion.=C2=A0 So here is the difficulty I=E2=80=99m having with multicast.= =C2=A0 Let=E2=80=99s assume for a moment the following:

 

- Two Destination Ups for the same destinat= ion (without Down in between) is a protocol error

- A Destination Announce Response is exactly semantically equivalent to a = Destination Up

- A Destination Announce w/ multi= cast destination is expressing a multicast group join by the local node=

- A Destination Up w/ multicast destination expresse= s that some other node has joined the multicast group

<= p class=3DMsoNormal> 

Then the following bad behavior can= occur:

 

- Rou= ter sends Destination Announce w/ multicast destination (group)

- Modem sends Destination Announce Response for that group, = and this counts as a Destination Up (by the above assumptions)

- Some other node joins the same group, and this gets propaga= ted via non-DLEP means to the local modem

- Mode= m sends a Destination Up for the group to let the router know there are othe= r (unidentified) group members out there

- Route= r considers this an error because it=E2=80=99s two Destination Ups for the same de= stination

 

Thi= s is essentially what happens with our current implementation.=C2=A0 I=E2=80=99m very = interested in the intended way to handle this, as I=E2=80=99ll be updating our imp= lementation with whatever is decided.

Thanks,

David

 

 

 

From: Rick Taylor <rick@tropicalstormsoftware.com>
Date: Fri= day, August 9, 2019 at 4:53 PM
To: Stan Ratliff <ratliffstan@gm= ail.com>, "Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.= mit.edu>
Cc: "manet@ietf.org" <manet@ietf.org><= br>Subject: RE: [manet] DLEP redundant Destination Ups

 

David,

 

I=E2=80=99m not sure this is an errata, but some clarification ma= y be required.  I would expect a Destination Up Response with an error = status of =E2=80=9CInvalid Destination=E2=80=9D (Terminate) if the receiver cannot handl= e the situation, or perhaps =E2=80=9CInconsistent Data=E2=80=9D if it can continue.

 =

Does that help?=

 

Cheers,

Rick=

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma",sans-serif'>From: manet [mai= lto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff
Sent:= 09 August 2019 20:33
To: Wiggins, David - 0665 - MITLL
Cc:<= /b> manet@ietf.org
Subject: Re: [manet] DLEP redundant Destination= Ups

 

David,

 

= This looks like it's a candidate for an errata. I think what *should* be don= e is for the router to respond with a "Destination Up Response", u= sing a new status code that effectively says "State Error", or &qu= ot;Destination is already up". Then I think the router should treat the= second Destination Up as a *Destination Down*, which resets the state error= . 

 = ;

My ra= tionale for not just ignoring the 2nd Dest up, or treating it as a Dest Upda= te is that there *could be* associated data with the Dest Up, like IPv4/IPv6= address data items, and/or connected subnet data items, that may or may not= clash with the new Dest Up. IMO, best to clean it up and try again "fr= om scratch". I don't think this sould trigger a complete peer session o= utage. 

 

Other opinions?

 

Regards,

Stan

 

  

On Fri, Aug 9, 2019 at 2:43 PM Wiggins, David = - 0665 - MITLL <David.Wiggins@l= l.mit.edu> wrote:

If a modem sends two Destination Ups = for the same destination without an intervening Destination Down for that de= stination, how should the router respond?

 

a) This is a protocol error.  Te= rminate the session.

b) Ignore the second Destination Up.

c) Treat the second Destinat= ion Up as a Destination Update.

d) something else

 

Thanks,

David

 

_______________________________________________
manet mai= ling list
manet@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/manet

=
--B_3648282958_1749938944-- --B_3648282958_1469588457 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUigYJKoZIhvcNAQcCoIIUezCCFHcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJQMIIE/jCCA+agAwIBAgITWQADvo+kDjDfv+QhfgAAAAO+jzANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMxODEzNTA1MFoXDTIyMDMx NzEzNTA1MFowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lucy5EYXZpZC5QLjUwMDE1MjA3 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoHcFpwES6qGfghStCyHNgTkrbxvz he4p2CB/4gtIFD18nYS25JrAn1AGK6+ZJleci5ChQJmSqF0lPNYk69n4XhMosSXtueb/RDUC xDO56fpJyOaaWNkKFJGEwMG937YRx4VKYqhFgnHKq8X3/u09805DTB6B0ucbMm77j235/pvb JOlp1aEfnXUteWwqromHZXcv81OdDMZz3hggAwUvsUiBV+m28PJxwxNZV55xxCBwjrRhrLnF bxR7E15QvsTsPdnlLBQapM/XoVK0EuxdM9YWCynddAgCzHOFgUK+MlN+GfTBIC1tupjqVmPf KZMoch9viZh+BwS/ZcyIPcDz+wIDAQABo4IBvDCCAbgwHQYDVR0OBBYEFMxxYWZdPlsQKWQT Oli11kLZ59XLMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQv77vGDR276Wr+rGfzBzsI dvZLWTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL2xs Y2E1MGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1 L2dldHRvL2xsY2E1MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3Aw PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/ inMCAWQCAQgwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwIwYDVR0RBBww GoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgw JwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsF AAOCAQEAQPSEoZ+9fCPazAOc9tOAskNiy+apnsqUvFVxshsZeTg/0q7zsTp5P5rL2GViH0by Ww+xrHWBczbjmSzsl7qgKWuCQkmOkNdBVf1kvQi4cpTmEIj4/lD8vo9e/JGsQkOb+QIZXwHY u02d+rDweRb90yKAMvAeKWZghb6XDV6hGGZKVGID5rJhQT4nPBHUFnxKmbdnb8WB7VXwNLcO ZklkKpehA/74XK1g6cKssRUp7sfj95eYtv0V69D81GWOPZ1DVTbD/E9oa+huK9yhDppGTr87 Y80RboGOUabPREB1r3v7YcouTOpyioUQvhnOOtWx5XcVKdUjLluEdx/L7viKHzCCBMAwggOo oAMCAQICAQYwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBD QS0yMB4XDTE3MDMwMjEyMDAwMFoXDTI2MDMwMjIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAd BgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsMA1BLSTETMBEGA1UEAwwK TUlUTEwgQ0EtNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKeagw69OR/DuerX 2atZrMZpr5DzdS/T4BNdPerqSv5YTEgwhnzsLvhYJxFem87u6/Hse8yxhYAUdb3fBDCGPK3E cg5mAo0nhWcZUNSX4ojuDSf35mO3eEHceEdty9t735jiPP5fMKIuXY5pi8gIpvG9sFIIu08R 5lDrHpNvoQrTKbSC9h4c7eS65j5IkckyW1usuchUvGNms1VLvvNcq+7pDeFJ2REgHuQmARd8 v6n/P/an3hsQRnZOdDPROQ6Mb4mrtSVeUVG2+xhwM8RAPdQ2RmxZxeALWFcbxMaSdRwCGUbF WGUqUUuY13vfjax4bLaz1jE0OdIT55dO1vQjkssCAwEAAaOCAZwwggGYMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFC/vu8YNHbvpav6sZ/MHOwh29ktZMB8GA1UdIwQYMBaAFP/J yWVMU4DxqQw8Ia6CKsfu+DL7MA4GA1UdDwEB/wQEAwIBhjBnBggrBgEFBQcBAQRbMFkwLgYI KwYBBQUHMAKGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTFJDQTIwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA0BgNVHR8ELTArMCmgJ6AlhiNodHRw Oi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMUkNBMjCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3 EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0G CyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIB AwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQAwlhHAs8n3Urt7aYDY2PXR bSjkkwdiRpr5y0vz/FjxDMgcUjkiP6LJ2k830oJif/hLLzRPdo2hiQWVLQZFBeF/SeyJjtNY nAArDgCI7/Infv+hEpGC3JGJy9onpGOUcJcE5qUUvD1S2mh0/j+J0LnWXHOyiVpBmtoGNV7s 8v3k+FLsP7bY198ifMt0hvUMF/ng3A5V88iAAG3EfV+FmuNrsSFH1GhTDkTU7qJZoC4//FaF JNAVaWHIDT+SQiL38ddpjSFieFyNxs8+qOnJ8iFIWONeGOoru3bA+tKsEUsVRucuI2WBAeu8 1gXkiqAh+dIFYiubet8uGllkn/Enth/oMIIDijCCAnKgAwIBAgIBATANBgkqhkiG9w0BAQsF ADBWMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9NSVRMTCBSb290IENBLTIwHhcNMTYwNDIwMTIwMDAwWhcN MzUwNDE5MjM1OTU5WjBWMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9NSVRMTCBSb290IENBLTIwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/dagEQY44m2bi5y9p/q8ogU+zzBq0J3pKbCr9 d5E2js/eM8jE0/AXf3xEYNSY8khcDuJ3MPqPSikUhb6QupjJ717vzw9XR2pomVfzzXx80NtI T7wHqGJ6opNHtV84jvhRVARQpVEW5EXDq5Vi6+B7DZOP8LZ0R57ft6u5CXmceRtXY6xadns7 7K35613odFxpcuU/2rxYqADcHu+Q5UgwIqgC5paP4EWrsr5Y2SLKL8p04f0mY6lvJEriNwDv FsucXwkVRI2DlzhjUEmsVpm2QJ4bo2b2nnbgaWWREXM+CmPxWJxX4Ar72tjTt1PHTaRii1Oc q7LRjEEDCxRfEBATAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFP/JyWVM U4DxqQw8Ia6CKsfu+DL7MB8GA1UdIwQYMBaAFP/JyWVMU4DxqQw8Ia6CKsfu+DL7MA4GA1Ud DwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOCAQEAeph8R//cnlowqGVhDQ+dQBswHyNlKv38 e+N84XTRysVQJ9KuobwlDCj5L+KrrqBynrYUSAnR9CQOBWDqb4LYROjUuhaJLGFgJ9xIhAQK WOVfBHzAVJrIXzbZLr0iq8eF2rh3nyNTqBiLqyyNTi/Cy+xUtEkqT+b8KD/DyBbpgczlqEEP r/kJx6XZ8juhKayQ733X6i2sLXVh8PAIW/PsCbSv4r2JWFJa1riGYi5XRgGJrTt5kpI7TYs+ BDxg7PeS7Ri36aHxVZEq7HYJxiMymT5YNXQEynvm2pvqmoEWRwq8QFerGD7z4b+6aOKLgfRz mS8mFpDLKRuY4qbE70hwkjCCBPgwggPgoAMCAQICCh+ce+UAAAAA6kQwDQYJKoZIhvcNAQEL BQAwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xOTAzMTgxNDEyMzFaFw0yMDEy MzEyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAfBgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIw NzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALkTZmZ3NPgqHJcYj7vburQKPzpI IksAdpgZ7SbGhxIRROLIdKDhHFzMAKMMu1vqIfuiaoavPZtG9HEP4sBsIre8r/aIee3N5v2V qiw+uhSMZsI3UC58GsFoJIEZcfCfH7cwtGBdQJq1xZ4hS+3U2r0/QDqGnJyyed1CX26RdLNr DXXMmj3BD4YlI4IBZD/494EQMzM1FGX64/mh987npZULmAoQeKzI11w9YfYjxuj7cZlLi0jh kj1cU1f32lOPg+5dxZVsZkTp1SHwKrXoappe+ML5KL82yc8iKzopsyGV0A6/LaTEpAoUX5Bc GHoBWQkd9llLgv0C45SuRa5GYykCAwEAAaOCAb8wggG7MB0GA1UdDgQWBBQAFD7iXQy8gJXq fQvOZnMaq54Z1DAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7I xxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9M TENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD 6+0gAgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1Ud IAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYDVR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQu ZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcN AQELBQADggEBAME3QtbTKQFZM21PzwrS5Nu0/2tZc+/S0ZN/pFBXXzKFmp3go+F/0Cw/ViVh dfpIGCGGvih4wwizPcfsSaCLKUaZfyLVt4DxhJAp/R5xhz0g2cPdzfA4ar2vJpT3msRi//Vl OtnlD9+6yQAiDFCB4ZgrYqJ14QHYa93b+tzaCG0m8lhslODb94KPYzubVPW8pSiEDYxPssiR Atn5O8Nxdrj9wcI+VR+bwKT9Tt4Iy1aYaSfOaoh8HenIZ8rOXQA9A6BcoPimxxjTVsx/DsBH q29lg08GbP+M0+26QZNx9gxWXzt3Kfnn2YxUKFePn2UV877SUBEP9W+jyPOgaHACGxQxggH+ MIIB+gIBATBoMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUCE1kAA76PpA4w37/kIX4A AAADvo8wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgh1eTAuB17VHvcr912Uyy lufyojr93FF2pC/FFDKBZycwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwODEwMTU1NTU4WjANBgkqhkiG9w0BAQEFAASCAQBEbZxdDrVHlZpuvY5fDrU/ Zy7YG8X2EV57z/JFT3UYMPZGRzn7y6oqMEzVwFFs4HEGpk7PqtZKJrKHlJ4CmqdVKE97LYHV 8uXZ4DyF38NWBhyd9Xq9LUicWJEg9cMrvZuELfPDdzf2YbeGRyNUc3rkrS3HVzm1dQ2FQJKN Vi7gQuaaTwnLQ2o/Y3dKFigM4X/js0gL2YLON332TElasr1FFAt+M5U8hI4yZe5WxESnTVFc 1b1AZpQimm/ffGruJEK1Ycy02E+Eh7MN1oVFzyZoFlztFKZu8xeYjzRkcZyFySOMOvAznLt/ 1CPHZ1ucdSKAFoHEiCMBB0VJaLmPU/Q7 --B_3648282958_1469588457-- From nobody Sat Aug 10 09:37:14 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 7E65C120046 for ; Sat, 10 Aug 2019 09:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FvhB0WuYmUW2 for ; Sat, 10 Aug 2019 09:37:09 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3A2120111 for ; Sat, 10 Aug 2019 09:37:09 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0468.000; Sat, 10 Aug 2019 17:37:06 +0100 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , Stan Ratliff CC: "manet@ietf.org" Thread-Topic: [manet] DLEP redundant Destination Ups Thread-Index: AQHVTuJFidsVE35B90GHgDX2g+eI7abzI/kAgAAlVeCAATBdAIAAG7Fg Date: Sat, 10 Aug 2019 16:37:04 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DB@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com> <255BBAD2-529D-4C41-A763-1122448C64B5@ll.mit.edu> In-Reply-To: <255BBAD2-529D-4C41-A763-1122448C64B5@ll.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:1648:4000:120:15fe:c469:8a18:dba8] Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DBtssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP redundant Destination Ups 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: Sat, 10 Aug 2019 16:37:13 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DBtssserver1hom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCkFzIGEgZmlyc3QgdGhvdWdodCDigJMgYW5kIEkgbmVlZCB0byBoYXZlIGEg bG9uZ2VyIHRoaW5rIHRvIGNoZWNrIG15IGFzc3VtcHRpb25zIOKAkyB5b3VyIHNlY29uZCDigJhv ZGTigJkgRGVzdGluYXRpb24gVXAgc2hvdWxkIHByb2JhYmx5IGJlIGEgRGVzdGluYXRpb24gVXBk YXRlLg0KDQpJbiBteSBtaW5kLCB0aGUgbW9kZW0gaXMgaW5mb3JtaW5nIHRoZSBtb2RlbSBvZiBh IGNoYW5nZSB0byBhbiAqZXhpc3RpbmcqIGRlc3RpbmF0aW9uLCBoZW5jZSB1cGRhdGUsIHJhdGhl ciB0aGFuIGEgKm5ldyogZGVzdGluYXRpb24uDQoNCkxldCBtZSBwb25kZXIgYSBsaXR0bGUgbW9y ZSwgYnV0IEnigJltIGludGVyZXN0ZWQgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCkNoZWVycywNCg0K Umljaw0KDQpGcm9tOiBXaWdnaW5zLCBEYXZpZCAtIDA2NjUgLSBNSVRMTCBbbWFpbHRvOkRhdmlk LldpZ2dpbnNAbGwubWl0LmVkdV0NClNlbnQ6IDEwIEF1Z3VzdCAyMDE5IDE2OjU2DQpUbzogUmlj ayBUYXlsb3I7IFN0YW4gUmF0bGlmZg0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTog W21hbmV0XSBETEVQIHJlZHVuZGFudCBEZXN0aW5hdGlvbiBVcHMNCg0KU3RhbiwgUmljaywNCg0K VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuICBJdCBoZWxwcyB0byBrbm93IHRoYXQgeW91 IGJvdGggdGhpbmsgaXQgc2hvdWxkIGJlIGFuIGVycm9yIChJIGRvIHRvbyksIHRob3VnaCB3ZSBo YXZlIGRpZmZlcmVudCBpZGVhcyBvbiB3aGF0IHRoZSBleGFjdCBiZWhhdmlvciBzaG91bGQgYmUu ICBJIHdvdWxkIHByb2JhYmx5IGdvIHdpdGggUmlja+KAmXMgc2Vjb25kIHN1Z2dlc3Rpb24sIOKA nEluY29uc2lzdGVudCBEYXRh4oCdIChDb250aW51ZSkuICBJ4oCZbSBub3QgYSBmYW4gb2YgaW1w bGVtZW50YXRpb24tZGVmaW5lZCBiZWhhdmlvciwgc28gSeKAmWQgcmF0aGVyIHRoZXJlIGJlIGV4 YWN0bHkgb25lIHdheSB0byBoYW5kbGUgdGhpcy4gIEFjdHVhbGx5IEkgdGhpbmsg4oCcSW52YWxp ZCBEZXN0aW5hdGlvbuKAnSAoQ29udGludWUpIHdvdWxkIG1ha2UgYSBiaXQgbW9yZSBzZW5zZSwg YnV0IHRoZSBmYWlsdXJlIG1vZGUgZm9yIOKAnEludmFsaWQgRGVzdGluYXRpb27igJ0gaXMgZGVm aW5lZCB0byBiZSBUZXJtaW5hdGUsIGFuZCB0aGVyZSBpc27igJl0IGFuIGVhc3kgd2F5IHRvIGNo YW5nZSB0aGF0Lg0KDQpUaGlzIGlzc3VlIGlzIG9uZSBwaWVjZSBvZiB0aGUgbGFyZ2VyIGlzc3Vl IG9mIGhvdyBtdWx0aWNhc3QgZGVzdGluYXRpb25zIGFyZSBoYW5kbGVkLiAgSSBzZWUgaW4gdGhl IG1pbnV0ZXMgdGhhdCB3YXMgZGlzY3Vzc2VkIGF0IElFVEYgMTA1OyByZWdyZXR0YWJseSwgSSB3 YXNu4oCZdCBhYmxlIHRvIGpvaW4gdGhlIGRpc2N1c3Npb24uICBTbyBoZXJlIGlzIHRoZSBkaWZm aWN1bHR5IEnigJltIGhhdmluZyB3aXRoIG11bHRpY2FzdC4gIExldOKAmXMgYXNzdW1lIGZvciBh IG1vbWVudCB0aGUgZm9sbG93aW5nOg0KDQotIFR3byBEZXN0aW5hdGlvbiBVcHMgZm9yIHRoZSBz YW1lIGRlc3RpbmF0aW9uICh3aXRob3V0IERvd24gaW4gYmV0d2VlbikgaXMgYSBwcm90b2NvbCBl cnJvcg0KLSBBIERlc3RpbmF0aW9uIEFubm91bmNlIFJlc3BvbnNlIGlzIGV4YWN0bHkgc2VtYW50 aWNhbGx5IGVxdWl2YWxlbnQgdG8gYSBEZXN0aW5hdGlvbiBVcA0KLSBBIERlc3RpbmF0aW9uIEFu bm91bmNlIHcvIG11bHRpY2FzdCBkZXN0aW5hdGlvbiBpcyBleHByZXNzaW5nIGEgbXVsdGljYXN0 IGdyb3VwIGpvaW4gYnkgdGhlIGxvY2FsIG5vZGUNCi0gQSBEZXN0aW5hdGlvbiBVcCB3LyBtdWx0 aWNhc3QgZGVzdGluYXRpb24gZXhwcmVzc2VzIHRoYXQgc29tZSBvdGhlciBub2RlIGhhcyBqb2lu ZWQgdGhlIG11bHRpY2FzdCBncm91cA0KDQpUaGVuIHRoZSBmb2xsb3dpbmcgYmFkIGJlaGF2aW9y IGNhbiBvY2N1cjoNCg0KLSBSb3V0ZXIgc2VuZHMgRGVzdGluYXRpb24gQW5ub3VuY2Ugdy8gbXVs dGljYXN0IGRlc3RpbmF0aW9uIChncm91cCkNCi0gTW9kZW0gc2VuZHMgRGVzdGluYXRpb24gQW5u b3VuY2UgUmVzcG9uc2UgZm9yIHRoYXQgZ3JvdXAsIGFuZCB0aGlzIGNvdW50cyBhcyBhIERlc3Rp bmF0aW9uIFVwIChieSB0aGUgYWJvdmUgYXNzdW1wdGlvbnMpDQotIFNvbWUgb3RoZXIgbm9kZSBq b2lucyB0aGUgc2FtZSBncm91cCwgYW5kIHRoaXMgZ2V0cyBwcm9wYWdhdGVkIHZpYSBub24tRExF UCBtZWFucyB0byB0aGUgbG9jYWwgbW9kZW0NCi0gTW9kZW0gc2VuZHMgYSBEZXN0aW5hdGlvbiBV cCBmb3IgdGhlIGdyb3VwIHRvIGxldCB0aGUgcm91dGVyIGtub3cgdGhlcmUgYXJlIG90aGVyICh1 bmlkZW50aWZpZWQpIGdyb3VwIG1lbWJlcnMgb3V0IHRoZXJlDQotIFJvdXRlciBjb25zaWRlcnMg dGhpcyBhbiBlcnJvciBiZWNhdXNlIGl04oCZcyB0d28gRGVzdGluYXRpb24gVXBzIGZvciB0aGUg c2FtZSBkZXN0aW5hdGlvbg0KDQpUaGlzIGlzIGVzc2VudGlhbGx5IHdoYXQgaGFwcGVucyB3aXRo IG91ciBjdXJyZW50IGltcGxlbWVudGF0aW9uLiAgSeKAmW0gdmVyeSBpbnRlcmVzdGVkIGluIHRo ZSBpbnRlbmRlZCB3YXkgdG8gaGFuZGxlIHRoaXMsIGFzIEnigJlsbCBiZSB1cGRhdGluZyBvdXIg aW1wbGVtZW50YXRpb24gd2l0aCB3aGF0ZXZlciBpcyBkZWNpZGVkLg0KDQpUaGFua3MsDQpEYXZp ZA0KDQoNCg0KRnJvbTogUmljayBUYXlsb3IgPHJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNv bT4NCkRhdGU6IEZyaWRheSwgQXVndXN0IDksIDIwMTkgYXQgNDo1MyBQTQ0KVG86IFN0YW4gUmF0 bGlmZiA8cmF0bGlmZnN0YW5AZ21haWwuY29tPiwgIldpZ2dpbnMsIERhdmlkIC0gMDY2NSAtIE1J VExMIiA8RGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1Pg0KQ2M6ICJtYW5ldEBpZXRmLm9yZyIgPG1h bmV0QGlldGYub3JnPg0KU3ViamVjdDogUkU6IFttYW5ldF0gRExFUCByZWR1bmRhbnQgRGVzdGlu YXRpb24gVXBzDQoNCkRhdmlkLA0KDQpJ4oCZbSBub3Qgc3VyZSB0aGlzIGlzIGFuIGVycmF0YSwg YnV0IHNvbWUgY2xhcmlmaWNhdGlvbiBtYXkgYmUgcmVxdWlyZWQuICBJIHdvdWxkIGV4cGVjdCBh IERlc3RpbmF0aW9uIFVwIFJlc3BvbnNlIHdpdGggYW4gZXJyb3Igc3RhdHVzIG9mIOKAnEludmFs aWQgRGVzdGluYXRpb27igJ0gKFRlcm1pbmF0ZSkgaWYgdGhlIHJlY2VpdmVyIGNhbm5vdCBoYW5k bGUgdGhlIHNpdHVhdGlvbiwgb3IgcGVyaGFwcyDigJxJbmNvbnNpc3RlbnQgRGF0YeKAnSBpZiBp dCBjYW4gY29udGludWUuDQoNCkRvZXMgdGhhdCBoZWxwPw0KDQpDaGVlcnMsDQpSaWNrDQoNCkZy b206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0 YW4gUmF0bGlmZg0KU2VudDogMDkgQXVndXN0IDIwMTkgMjA6MzMNClRvOiBXaWdnaW5zLCBEYXZp ZCAtIDA2NjUgLSBNSVRMTA0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0 XSBETEVQIHJlZHVuZGFudCBEZXN0aW5hdGlvbiBVcHMNCg0KRGF2aWQsDQoNClRoaXMgbG9va3Mg bGlrZSBpdCdzIGEgY2FuZGlkYXRlIGZvciBhbiBlcnJhdGEuIEkgdGhpbmsgd2hhdCAqc2hvdWxk KiBiZSBkb25lIGlzIGZvciB0aGUgcm91dGVyIHRvIHJlc3BvbmQgd2l0aCBhICJEZXN0aW5hdGlv biBVcCBSZXNwb25zZSIsIHVzaW5nIGEgbmV3IHN0YXR1cyBjb2RlIHRoYXQgZWZmZWN0aXZlbHkg c2F5cyAiU3RhdGUgRXJyb3IiLCBvciAiRGVzdGluYXRpb24gaXMgYWxyZWFkeSB1cCIuIFRoZW4g SSB0aGluayB0aGUgcm91dGVyIHNob3VsZCB0cmVhdCB0aGUgc2Vjb25kIERlc3RpbmF0aW9uIFVw IGFzIGEgKkRlc3RpbmF0aW9uIERvd24qLCB3aGljaCByZXNldHMgdGhlIHN0YXRlIGVycm9yLg0K DQpNeSByYXRpb25hbGUgZm9yIG5vdCBqdXN0IGlnbm9yaW5nIHRoZSAybmQgRGVzdCB1cCwgb3Ig dHJlYXRpbmcgaXQgYXMgYSBEZXN0IFVwZGF0ZSBpcyB0aGF0IHRoZXJlICpjb3VsZCBiZSogYXNz b2NpYXRlZCBkYXRhIHdpdGggdGhlIERlc3QgVXAsIGxpa2UgSVB2NC9JUHY2IGFkZHJlc3MgZGF0 YSBpdGVtcywgYW5kL29yIGNvbm5lY3RlZCBzdWJuZXQgZGF0YSBpdGVtcywgdGhhdCBtYXkgb3Ig bWF5IG5vdCBjbGFzaCB3aXRoIHRoZSBuZXcgRGVzdCBVcC4gSU1PLCBiZXN0IHRvIGNsZWFuIGl0 IHVwIGFuZCB0cnkgYWdhaW4gImZyb20gc2NyYXRjaCIuIEkgZG9uJ3QgdGhpbmsgdGhpcyBzb3Vs ZCB0cmlnZ2VyIGEgY29tcGxldGUgcGVlciBzZXNzaW9uIG91dGFnZS4NCg0KT3RoZXIgb3Bpbmlv bnM/DQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KT24gRnJpLCBBdWcgOSwgMjAxOSBhdCAyOjQzIFBN IFdpZ2dpbnMsIERhdmlkIC0gMDY2NSAtIE1JVExMIDxEYXZpZC5XaWdnaW5zQGxsLm1pdC5lZHU8 bWFpbHRvOkRhdmlkLldpZ2dpbnNAbGwubWl0LmVkdT4+IHdyb3RlOg0KSWYgYSBtb2RlbSBzZW5k cyB0d28gRGVzdGluYXRpb24gVXBzIGZvciB0aGUgc2FtZSBkZXN0aW5hdGlvbiB3aXRob3V0IGFu IGludGVydmVuaW5nIERlc3RpbmF0aW9uIERvd24gZm9yIHRoYXQgZGVzdGluYXRpb24sIGhvdyBz aG91bGQgdGhlIHJvdXRlciByZXNwb25kPw0KDQphKSBUaGlzIGlzIGEgcHJvdG9jb2wgZXJyb3Iu ICBUZXJtaW5hdGUgdGhlIHNlc3Npb24uDQpiKSBJZ25vcmUgdGhlIHNlY29uZCBEZXN0aW5hdGlv biBVcC4NCmMpIFRyZWF0IHRoZSBzZWNvbmQgRGVzdGluYXRpb24gVXAgYXMgYSBEZXN0aW5hdGlv biBVcGRhdGUuDQpkKSBzb21ldGhpbmcgZWxzZQ0KDQpUaGFua3MsDQpEYXZpZA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBs aXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo= --_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DBtssserver1hom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIERhdmlkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgYSBmaXJzdCB0aG91Z2h0IOKAkyBhbmQgSSBuZWVk IHRvIGhhdmUgYSBsb25nZXIgdGhpbmsgdG8gY2hlY2sgbXkgYXNzdW1wdGlvbnMg4oCTIHlvdXIg c2Vjb25kIOKAmG9kZOKAmSBEZXN0aW5hdGlvbiBVcCBzaG91bGQgcHJvYmFibHkgYmUgYSBEZXN0 aW5hdGlvbiBVcGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBteSBtaW5kLCB0aGUgbW9kZW0gaXMgaW5mb3Jt aW5nIHRoZSBtb2RlbSBvZiBhIGNoYW5nZSB0byBhbiAqPGI+ZXhpc3Rpbmc8L2I+KiBkZXN0aW5h dGlvbiwgaGVuY2UgdXBkYXRlLCByYXRoZXIgdGhhbiBhICo8Yj5uZXc8L2I+KiBkZXN0aW5hdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkxldCBtZSBwb25kZXIgYSBsaXR0bGUgbW9yZSwgYnV0IEnigJltIGludGVy ZXN0ZWQgd2hhdCBvdGhlcnMgdGhpbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SaWNr PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gV2lnZ2lucywgRGF2aWQgLSAwNjY1IC0gTUlUTEwgW21haWx0bzpEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTAgQXVndXN0IDIwMTkg MTY6NTY8YnI+DQo8Yj5Ubzo8L2I+IFJpY2sgVGF5bG9yOyBTdGFuIFJhdGxpZmY8YnI+DQo8Yj5D Yzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIERM RVAgcmVkdW5kYW50IERlc3RpbmF0aW9uIFVwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlN0YW4sIFJpY2ssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuJm5i c3A7IEl0IGhlbHBzIHRvIGtub3cgdGhhdCB5b3UgYm90aCB0aGluayBpdCBzaG91bGQgYmUgYW4g ZXJyb3IgKEkgZG8gdG9vKSwgdGhvdWdoIHdlIGhhdmUgZGlmZmVyZW50IGlkZWFzIG9uIHdoYXQg dGhlIGV4YWN0IGJlaGF2aW9yDQogc2hvdWxkIGJlLiZuYnNwOyBJIHdvdWxkIHByb2JhYmx5IGdv IHdpdGggUmlja+KAmXMgc2Vjb25kIHN1Z2dlc3Rpb24sIOKAnEluY29uc2lzdGVudCBEYXRh4oCd IChDb250aW51ZSkuJm5ic3A7IEnigJltIG5vdCBhIGZhbiBvZiBpbXBsZW1lbnRhdGlvbi1kZWZp bmVkIGJlaGF2aW9yLCBzbyBJ4oCZZCByYXRoZXIgdGhlcmUgYmUgZXhhY3RseSBvbmUgd2F5IHRv IGhhbmRsZSB0aGlzLiZuYnNwOyBBY3R1YWxseSBJIHRoaW5rIOKAnEludmFsaWQgRGVzdGluYXRp b27igJ0gKENvbnRpbnVlKSB3b3VsZA0KIG1ha2UgYSBiaXQgbW9yZSBzZW5zZSwgYnV0IHRoZSBm YWlsdXJlIG1vZGUgZm9yIOKAnEludmFsaWQgRGVzdGluYXRpb27igJ0gaXMgZGVmaW5lZCB0byBi ZSBUZXJtaW5hdGUsIGFuZCB0aGVyZSBpc27igJl0IGFuIGVhc3kgd2F5IHRvIGNoYW5nZSB0aGF0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlRoaXMgaXNzdWUgaXMgb25lIHBpZWNlIG9mIHRoZSBsYXJnZXIgaXNzdWUgb2Yg aG93IG11bHRpY2FzdCBkZXN0aW5hdGlvbnMgYXJlIGhhbmRsZWQuJm5ic3A7IEkgc2VlIGluIHRo ZSBtaW51dGVzIHRoYXQgd2FzIGRpc2N1c3NlZCBhdCBJRVRGIDEwNTsgcmVncmV0dGFibHksIEkg d2FzbuKAmXQNCiBhYmxlIHRvIGpvaW4gdGhlIGRpc2N1c3Npb24uJm5ic3A7IFNvIGhlcmUgaXMg dGhlIGRpZmZpY3VsdHkgSeKAmW0gaGF2aW5nIHdpdGggbXVsdGljYXN0LiZuYnNwOyBMZXTigJlz IGFzc3VtZSBmb3IgYSBtb21lbnQgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFR3byBEZXN0aW5h dGlvbiBVcHMgZm9yIHRoZSBzYW1lIGRlc3RpbmF0aW9uICh3aXRob3V0IERvd24gaW4gYmV0d2Vl bikgaXMgYSBwcm90b2NvbCBlcnJvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gQSBE ZXN0aW5hdGlvbiBBbm5vdW5jZSBSZXNwb25zZSBpcyBleGFjdGx5IHNlbWFudGljYWxseSBlcXVp dmFsZW50IHRvIGEgRGVzdGluYXRpb24gVXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4t IEEgRGVzdGluYXRpb24gQW5ub3VuY2Ugdy8gbXVsdGljYXN0IGRlc3RpbmF0aW9uIGlzIGV4cHJl c3NpbmcgYSBtdWx0aWNhc3QgZ3JvdXAgam9pbiBieSB0aGUgbG9jYWwgbm9kZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPi0gQSBEZXN0aW5hdGlvbiBVcCB3LyBtdWx0aWNhc3QgZGVzdGlu YXRpb24gZXhwcmVzc2VzIHRoYXQgc29tZSBvdGhlciBub2RlIGhhcyBqb2luZWQgdGhlIG11bHRp Y2FzdCBncm91cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlRoZW4gdGhlIGZvbGxvd2luZyBiYWQgYmVoYXZpb3IgY2FuIG9j Y3VyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPi0gUm91dGVyIHNlbmRzIERlc3RpbmF0aW9uIEFubm91bmNlIHcvIG11bHRp Y2FzdCBkZXN0aW5hdGlvbiAoZ3JvdXApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBN b2RlbSBzZW5kcyBEZXN0aW5hdGlvbiBBbm5vdW5jZSBSZXNwb25zZSBmb3IgdGhhdCBncm91cCwg YW5kIHRoaXMgY291bnRzIGFzIGEgRGVzdGluYXRpb24gVXAgKGJ5IHRoZSBhYm92ZSBhc3N1bXB0 aW9ucyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFNvbWUgb3RoZXIgbm9kZSBqb2lu cyB0aGUgc2FtZSBncm91cCwgYW5kIHRoaXMgZ2V0cyBwcm9wYWdhdGVkIHZpYSBub24tRExFUCBt ZWFucyB0byB0aGUgbG9jYWwgbW9kZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIE1v ZGVtIHNlbmRzIGEgRGVzdGluYXRpb24gVXAgZm9yIHRoZSBncm91cCB0byBsZXQgdGhlIHJvdXRl ciBrbm93IHRoZXJlIGFyZSBvdGhlciAodW5pZGVudGlmaWVkKSBncm91cCBtZW1iZXJzIG91dCB0 aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gUm91dGVyIGNvbnNpZGVycyB0aGlz IGFuIGVycm9yIGJlY2F1c2UgaXTigJlzIHR3byBEZXN0aW5hdGlvbiBVcHMgZm9yIHRoZSBzYW1l IGRlc3RpbmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBpcyBlc3NlbnRpYWxseSB3aGF0IGhhcHBlbnMgd2l0 aCBvdXIgY3VycmVudCBpbXBsZW1lbnRhdGlvbi4mbmJzcDsgSeKAmW0gdmVyeSBpbnRlcmVzdGVk IGluIHRoZSBpbnRlbmRlZCB3YXkgdG8gaGFuZGxlIHRoaXMsIGFzIEnigJlsbCBiZSB1cGRhdGlu ZyBvdXIgaW1wbGVtZW50YXRpb24NCiB3aXRoIHdoYXRldmVyIGlzIGRlY2lkZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhdmlkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+UmljayBUYXlsb3IgJmx0O3JpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBBdWd1c3QgOSwgMjAxOSBhdCA0OjUzIFBNPGJyPg0K PGI+VG86IDwvYj5TdGFuIFJhdGxpZmYgJmx0O3JhdGxpZmZzdGFuQGdtYWlsLmNvbSZndDssICZx dW90O1dpZ2dpbnMsIERhdmlkIC0gMDY2NSAtIE1JVExMJnF1b3Q7ICZsdDtEYXZpZC5XaWdnaW5z QGxsLm1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDttYW5ldEBpZXRmLm9yZyZxdW90 OyAmbHQ7bWFuZXRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBbbWFuZXRd IERMRVAgcmVkdW5kYW50IERlc3RpbmF0aW9uIFVwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhdmlkLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKA mW0gbm90IHN1cmUgdGhpcyBpcyBhbiBlcnJhdGEsIGJ1dCBzb21lIGNsYXJpZmljYXRpb24gbWF5 IGJlIHJlcXVpcmVkLiZuYnNwOyBJIHdvdWxkIGV4cGVjdCBhIERlc3RpbmF0aW9uIFVwIFJlc3Bv bnNlIHdpdGgNCiBhbiBlcnJvciBzdGF0dXMgb2Yg4oCcSW52YWxpZCBEZXN0aW5hdGlvbuKAnSAo VGVybWluYXRlKSBpZiB0aGUgcmVjZWl2ZXIgY2Fubm90IGhhbmRsZSB0aGUgc2l0dWF0aW9uLCBv ciBwZXJoYXBzIOKAnEluY29uc2lzdGVudCBEYXRh4oCdIGlmIGl0IGNhbiBjb250aW51ZS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvZXMgdGhhdCBoZWxwPzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Q2hlZXJzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SaWNrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN0YW4gUmF0bGlmZjxicj4NCjxiPlNlbnQ6PC9i PiAwOSBBdWd1c3QgMjAxOSAyMDozMzxicj4NCjxiPlRvOjwvYj4gV2lnZ2lucywgRGF2aWQgLSAw NjY1IC0gTUlUTEw8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbbWFuZXRdIERMRVAgcmVkdW5kYW50IERlc3RpbmF0aW9uIFVwczwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5EYXZpZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhp cyBsb29rcyBsaWtlIGl0J3MgYSBjYW5kaWRhdGUgZm9yIGFuIGVycmF0YS4gSSB0aGluayB3aGF0 ICpzaG91bGQqIGJlIGRvbmUgaXMgZm9yIHRoZSByb3V0ZXIgdG8gcmVzcG9uZCB3aXRoIGEgJnF1 b3Q7RGVzdGluYXRpb24gVXAgUmVzcG9uc2UmcXVvdDssIHVzaW5nIGEgbmV3IHN0YXR1cyBjb2Rl IHRoYXQgZWZmZWN0aXZlbHkgc2F5cyAmcXVvdDtTdGF0ZQ0KIEVycm9yJnF1b3Q7LCBvciAmcXVv dDtEZXN0aW5hdGlvbiBpcyBhbHJlYWR5IHVwJnF1b3Q7LiBUaGVuIEkgdGhpbmsgdGhlIHJvdXRl ciBzaG91bGQgdHJlYXQgdGhlIHNlY29uZCBEZXN0aW5hdGlvbiBVcCBhcyBhICpEZXN0aW5hdGlv biBEb3duKiwgd2hpY2ggcmVzZXRzIHRoZSBzdGF0ZSBlcnJvci4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5NeSByYXRpb25hbGUgZm9yIG5vdCBqdXN0IGlnbm9y aW5nIHRoZSAybmQgRGVzdCB1cCwgb3IgdHJlYXRpbmcgaXQgYXMgYSBEZXN0IFVwZGF0ZSBpcyB0 aGF0IHRoZXJlICpjb3VsZCBiZSogYXNzb2NpYXRlZCBkYXRhIHdpdGggdGhlIERlc3QgVXAsIGxp a2UgSVB2NC9JUHY2IGFkZHJlc3MgZGF0YSBpdGVtcywgYW5kL29yIGNvbm5lY3RlZA0KIHN1Ym5l dCBkYXRhIGl0ZW1zLCB0aGF0IG1heSBvciBtYXkgbm90IGNsYXNoIHdpdGggdGhlIG5ldyBEZXN0 IFVwLiBJTU8sIGJlc3QgdG8gY2xlYW4gaXQgdXAgYW5kIHRyeSBhZ2FpbiAmcXVvdDtmcm9tIHNj cmF0Y2gmcXVvdDsuIEkgZG9uJ3QgdGhpbmsgdGhpcyBzb3VsZCB0cmlnZ2VyIGEgY29tcGxldGUg cGVlciBzZXNzaW9uIG91dGFnZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPk90aGVyIG9waW5pb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+U3RhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIEF1ZyA5LCAyMDE5IGF0IDI6 NDMgUE0gV2lnZ2lucywgRGF2aWQgLSAwNjY1IC0gTUlUTEwgJmx0OzxhIGhyZWY9Im1haWx0bzpE YXZpZC5XaWdnaW5zQGxsLm1pdC5lZHUiPkRhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5JZiBhIG1vZGVtIHNlbmRzIHR3byBEZXN0aW5hdGlvbiBVcHMg Zm9yIHRoZSBzYW1lIGRlc3RpbmF0aW9uIHdpdGhvdXQgYW4gaW50ZXJ2ZW5pbmcgRGVzdGluYXRp b24gRG93biBmb3IgdGhhdCBkZXN0aW5hdGlvbiwgaG93IHNob3VsZCB0aGUgcm91dGVyIHJlc3Bv bmQ/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ YSkgVGhpcyBpcyBhIHByb3RvY29sIGVycm9yLiZuYnNwOyBUZXJtaW5hdGUgdGhlIHNlc3Npb24u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+YikgSWdub3JlIHRoZSBzZWNvbmQgRGVzdGluYXRpb24g VXAuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+YykgVHJlYXQgdGhlIHNlY29uZCBEZXN0aW5hdGlv biBVcCBhcyBhIERlc3RpbmF0aW9uIFVwZGF0ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5kKSBz b21ldGhpbmcgZWxzZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRoYW5rcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EYXZpZDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DBtssserver1hom_-- From nobody Sat Aug 10 21:35:58 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 7FECA1208C8 for ; Sat, 10 Aug 2019 21:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[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] 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 xmgLj1qQ51tI for ; Sat, 10 Aug 2019 21:34:56 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0: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 55EFF120255 for ; Sat, 10 Aug 2019 18:38:53 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id o13so47718856pgp.12 for ; Sat, 10 Aug 2019 18:38:53 -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 :cc; bh=z8af4HVKU4QQ/jIyfIqALr9yHSVTk/Zs11j/EzHSCds=; b=SpEYoYWCmnHix1EogFlCySK6T2qUKPunIcKr85xBj7QiDF/SAWsx1oARur/Nx0OvcF xoGZeq5M09xBo/bDHxXxzpo/JNuyL2sH4KHREkXn0pykrM2Ubeov6/INV8LxIOQYt8if rhQAjvtZMAE4wPffwntqDYwZkL3y9l8gKqzc8hOffC1vYp81Su6KpMPzbWNSWBY8+0RK QU9M8dDbgyCnhc6GnPTVayWLjh1qRojOvgGinet7tAj6B8QVq6Ggnj72pjXEipn9aLMT d3riXet8Z0VJ8m9AGX5/8imwQCG2nB8mkMMzwnc183Aun5/Q9mzTNC1HBsvdJvPt0Kq1 6Jog== 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:cc; bh=z8af4HVKU4QQ/jIyfIqALr9yHSVTk/Zs11j/EzHSCds=; b=WwwFPUV2/JxYePcJvLbs1YNq2Wq8DZ06M7bnp3UHIyEghHXvxV1C2S3cRA3iXv62My f6wN0dCQbB2mdR89uVm9pr0oaW9gVCw1TJ0dqpJmdO9RC9PvY66h2bVBfhA1yHt7uuqk WLW9XY9DsmZ0NpcHF5MHRn3V1Usp2BYPiGtK0Eldrao4rs3ZpyRR76eqi9dMZ5ZvLcmo tiu9iTvQEl1jeDVwJQ9mwA9juX3N+OlobsDBeFJBOWvMrRZ8ljICP/Z4qd1sTKbxMc9/ 1iVs3UXuHQV4OckpxVvMu+p3bDFT+MJsJZjldc20FYr3lW2py5ylrcGVrl9KTDrJc6wX RTug== X-Gm-Message-State: APjAAAV9A6Y5UgJB+rAAHWMQRf8p5XEcBZKb0l8THpJjIZlh6TsS/AJI bn5lHivd7vt8YQ6J6R1SQpEHvK3rVw3s3iCIf3VhWA== X-Google-Smtp-Source: APXvYqz0LDA6ediLgNw5h9k5pcH3DIxA1zdlMDN5H2z6nVHanN5EW0W4UjLEYvqrR80g9VSNjxVzUZpujQKshF7XtvY= X-Received: by 2002:a62:e806:: with SMTP id c6mr932019pfi.132.1565487532588; Sat, 10 Aug 2019 18:38:52 -0700 (PDT) MIME-Version: 1.0 References: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com> <255BBAD2-529D-4C41-A763-1122448C64B5@ll.mit.edu> <38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DB@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DB@tss-server1.home.tropicalstormsoftware.com> From: Stan Ratliff Date: Sat, 10 Aug 2019 21:38:41 -0400 Message-ID: To: Rick Taylor Cc: "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047c2b9058fcd7869" Archived-At: Subject: Re: [manet] DLEP redundant Destination Ups 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: Sun, 11 Aug 2019 04:35:56 -0000 --00000000000047c2b9058fcd7869 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2019 at 12:37 PM Rick Taylor wrote: > Hi David, > > > > As a first thought =E2=80=93 and I need to have a longer think to check m= y > assumptions =E2=80=93 your second =E2=80=98odd=E2=80=99 Destination Up sh= ould probably be a > Destination Update. > > > > In my mind, the modem is informing the modem of a change to an **existing= ** > destination, hence update, rather than a **new** destination. > In the use case shown below, I believe Rick is correct - the second Destination Up should be a Destination Update. This is just a change to the logical destination represented by the MCAST group. Now, as to how the protocol should handle the presentation of a Destination Up on a MAC address that is already been the subject of an Up - I think the second Destination Up should be responded to with an error, and the Destination should be removed from the information base, for reasons I've already stated. For example, let's say the first Destination Up specifies an IPv4 Address Data Item Add of 1.2.3.4. The second Destination Up comes with an IPv4 Address Data Item add of 5.6.7.8. Is 1.2.3.4 supposed to be dropped? Or is 5.6.7.8 just supposed to be added to the first address? The same issue exists with attached subnets. Regards, Stan PS - I'm almost done with the initial draft on MCAST talked about at IETF 105. Will post ASAP (Provided next week's jury duty doesn't get in the way)= . > > > Let me ponder a little more, but I=E2=80=99m interested what others think= . > > > > Cheers, > > > > Rick > > > > *From:* Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu] > *Sent:* 10 August 2019 16:56 > *To:* Rick Taylor; Stan Ratliff > *Cc:* manet@ietf.org > *Subject:* Re: [manet] DLEP redundant Destination Ups > > > > Stan, Rick, > > > > Thanks for the quick response. It helps to know that you both think it > should be an error (I do too), though we have different ideas on what the > exact behavior should be. I would probably go with Rick=E2=80=99s second > suggestion, =E2=80=9CInconsistent Data=E2=80=9D (Continue). I=E2=80=99m = not a fan of > implementation-defined behavior, so I=E2=80=99d rather there be exactly o= ne way to > handle this. Actually I think =E2=80=9CInvalid Destination=E2=80=9D (Con= tinue) would make > a bit more sense, but the failure mode for =E2=80=9CInvalid Destination= =E2=80=9D is defined > to be Terminate, and there isn=E2=80=99t an easy way to change that. > > > > This issue is one piece of the larger issue of how multicast destinations > are handled. I see in the minutes that was discussed at IETF 105; > regrettably, I wasn=E2=80=99t able to join the discussion. So here is th= e > difficulty I=E2=80=99m having with multicast. Let=E2=80=99s assume for a= moment the > following: > > > > - Two Destination Ups for the same destination (without Down in between) > is a protocol error > > - A Destination Announce Response is exactly semantically equivalent to a > Destination Up > > - A Destination Announce w/ multicast destination is expressing a > multicast group join by the local node > > - A Destination Up w/ multicast destination expresses that some other nod= e > has joined the multicast group > > > > Then the following bad behavior can occur: > > > > - Router sends Destination Announce w/ multicast destination (group) > > - Modem sends Destination Announce Response for that group, and this > counts as a Destination Up (by the above assumptions) > > - Some other node joins the same group, and this gets propagated via > non-DLEP means to the local modem > > - Modem sends a Destination Up for the group to let the router know there > are other (unidentified) group members out there > > - Router considers this an error because it=E2=80=99s two Destination Ups= for the > same destination > > > > This is essentially what happens with our current implementation. I=E2= =80=99m > very interested in the intended way to handle this, as I=E2=80=99ll be up= dating our > implementation with whatever is decided. > > > > Thanks, > > David > > > > > > > > *From: *Rick Taylor > *Date: *Friday, August 9, 2019 at 4:53 PM > *To: *Stan Ratliff , "Wiggins, David - 0665 - > MITLL" > *Cc: *"manet@ietf.org" > *Subject: *RE: [manet] DLEP redundant Destination Ups > > > > David, > > > > I=E2=80=99m not sure this is an errata, but some clarification may be req= uired. I > would expect a Destination Up Response with an error status of =E2=80=9CI= nvalid > Destination=E2=80=9D (Terminate) if the receiver cannot handle the situat= ion, or > perhaps =E2=80=9CInconsistent Data=E2=80=9D if it can continue. > > > > Does that help? > > > > Cheers, > > Rick > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Stan Ratliff > *Sent:* 09 August 2019 20:33 > *To:* Wiggins, David - 0665 - MITLL > *Cc:* manet@ietf.org > *Subject:* Re: [manet] DLEP redundant Destination Ups > > > > David, > > > > This looks like it's a candidate for an errata. I think what *should* be > done is for the router to respond with a "Destination Up Response", using= a > new status code that effectively says "State Error", or "Destination is > already up". Then I think the router should treat the second Destination = Up > as a *Destination Down*, which resets the state error. > > > > My rationale for not just ignoring the 2nd Dest up, or treating it as a > Dest Update is that there *could be* associated data with the Dest Up, li= ke > IPv4/IPv6 address data items, and/or connected subnet data items, that ma= y > or may not clash with the new Dest Up. IMO, best to clean it up and try > again "from scratch". I don't think this sould trigger a complete peer > session outage. > > > > Other opinions? > > > > Regards, > > Stan > > > > > > On Fri, Aug 9, 2019 at 2:43 PM Wiggins, David - 0665 - MITLL < > David.Wiggins@ll.mit.edu> wrote: > > If a modem sends two Destination Ups for the same destination without an > intervening Destination Down for that destination, how should the router > respond? > > > > a) This is a protocol error. Terminate the session. > > b) Ignore the second Destination Up. > > c) Treat the second Destination Up as a Destination Update. > > d) something else > > > > Thanks, > > David > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --00000000000047c2b9058fcd7869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Aug 10, 2019 at 12:37 PM Rick= Taylor <rick@tropical= stormsoftware.com> wrote:

Hi David,

=C2=A0

As a first thought =E2=80=93 and I need to h= ave a longer think to check my assumptions =E2=80=93 your second =E2=80=98o= dd=E2=80=99 Destination Up should probably be a Destination Update.<= u>

=C2=A0

In my mind, the modem is informing the modem= of a change to an *existing* destination, hence update, rather than= a *new* destination.


In the use case shown below, I believe Rick is correct - the secon= d Destination Up should be a Destination Update. This is just a change to t= he logical destination represented by the MCAST group.=C2=A0

=
Now, as to how the protocol should handle the presentation of a = Destination Up on a MAC address that is already been the subject of an Up -= I think the second Destination Up should be responded to with an error, an= d the Destination should be removed from the information base, for reasons = I've already stated. For example, let's say the first Destination U= p specifies an IPv4 Address Data Item Add of 1.2.3.4. The second Destinatio= n Up comes with an IPv4 Address Data Item add of 5.6.7.8.=C2=A0
<= br>
Is 1.2.3.4 supposed to be dropped? Or is 5.6.7.8 just suppose= d to be added to the first address? The same issue exists with attached sub= nets.=C2=A0

Regards,
Stan

=
PS - I'm almost done with the initial draft on MCAST talked = about at IETF 105. Will post ASAP (Provided next week's jury duty doesn= 't get in the way).
=C2=A0

=C2=A0

Let me ponder a little more, but I=E2=80=99m= interested what others think.

=C2=A0

Cheers,

=C2=A0

Rick

=C2=A0

From: Wiggins, David - 0665 - MITLL = [mailto:David= .Wiggins@ll.mit.edu]
Sent: 10 August 2019 16:56
To: Rick Taylor; Stan Ratliff
Cc: manet@ietf.o= rg
Subject: Re: [manet] DLEP redundant Destination Ups

=C2=A0

Stan, Rick,

=C2=A0

Thanks for the quick response.=C2=A0 It helps to k= now that you both think it should be an error (I do too), though we have di= fferent ideas on what the exact behavior should be.=C2=A0 I would probably go with Rick=E2=80=99s second suggestion= , =E2=80=9CInconsistent Data=E2=80=9D (Continue).=C2=A0 I=E2=80=99m not a f= an of implementation-defined behavior, so I=E2=80=99d rather there be exact= ly one way to handle this.=C2=A0 Actually I think =E2=80=9CInvalid Destinat= ion=E2=80=9D (Continue) would make a bit more sense, but the failure mode for =E2=80=9CInvalid Destinati= on=E2=80=9D is defined to be Terminate, and there isn=E2=80=99t an easy way= to change that.

=C2=A0

This issue is one piece of the larger issue of how= multicast destinations are handled.=C2=A0 I see in the minutes that was di= scussed at IETF 105; regrettably, I wasn=E2=80=99t able to join the discussion.=C2=A0 So here is the difficulty I=E2=80=99m h= aving with multicast.=C2=A0 Let=E2=80=99s assume for a moment the following= :

=C2=A0

- Two Destination Ups for the same destination (wi= thout Down in between) is a protocol error

- A Destination Announce Response is exactly seman= tically equivalent to a Destination Up

- A Destination Announce w/ multicast destination = is expressing a multicast group join by the local node=

- A Destination Up w/ multicast destination expres= ses that some other node has joined the multicast group

=C2=A0

Then the following bad behavior can occur:<= u>

=C2=A0

- Router sends Destination Announce w/ multicast d= estination (group)

- Modem sends Destination Announce Response for th= at group, and this counts as a Destination Up (by the above assumptions)=

- Some other node joins the same group, and this g= ets propagated via non-DLEP means to the local modem

- Modem sends a Destination Up for the group to le= t the router know there are other (unidentified) group members out there=

- Router considers this an error because it=E2=80= =99s two Destination Ups for the same destination

=C2=A0

This is essentially what happens with our current = implementation.=C2=A0 I=E2=80=99m very interested in the intended way to ha= ndle this, as I=E2=80=99ll be updating our implementation with whatever is decided.

=C2=A0

Thanks,

David

=C2=A0

=C2=A0

=C2=A0

From: Rick Taylor <rick@tropica= lstormsoftware.com>
Date: Friday, August 9, 2019 at 4:53 PM
To: Stan Ratliff <ratliffstan@gmail.com>, "Wiggins, David - 0665 - MI= TLL" <David.Wiggins@ll.mit.edu>
Cc: "manet@= ietf.org" <= manet@ietf.org>
Subject: RE: [manet] DLEP redundant Destination Ups

=C2=A0

Da= vid,

= =C2=A0

I= =E2=80=99m not sure this is an errata, but some clarification may be requir= ed.=C2=A0 I would expect a Destination Up Response with an error status of =E2=80=9CInvalid Destination=E2=80=9D (Terminate) if th= e receiver cannot handle the situation, or perhaps =E2=80=9CInconsistent Da= ta=E2=80=9D if it can continue.

= =C2=A0

Do= es that help?

= =C2=A0

Ch= eers,

Ri= ck

= =C2=A0

From: man= et [mailto:mane= t-bounces@ietf.org] On Behalf Of Stan Ratliff
Sent: 09 August 2019 20:33
To: Wiggins, David - 0665 - MITLL
Cc: manet@ietf.o= rg
Subject: Re: [manet] DLEP redundant Destination Ups

=C2= =A0

Davi= d,

=C2= =A0

This= looks like it's a candidate for an errata. I think what *should* be do= ne is for the router to respond with a "Destination Up Response",= using a new status code that effectively says "State Error", or "Destination is already up". Then I think the ro= uter should treat the second Destination Up as a *Destination Down*, which = resets the state error.=C2=A0

=C2= =A0

My r= ationale for not just ignoring the 2nd Dest up, or treating it as a Dest Up= date is that there *could be* associated data with the Dest Up, like IPv4/I= Pv6 address data items, and/or connected subnet data items, that may or may not clash with the new Dest Up. IMO, be= st to clean it up and try again "from scratch". I don't think= this sould trigger a complete peer session outage.=C2=A0

=C2= =A0

Othe= r opinions?

=C2= =A0

Rega= rds,

Stan=

=C2= =A0

--00000000000047c2b9058fcd7869-- From nobody Mon Aug 12 13:27: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 B843C122617; Mon, 12 Aug 2019 13:27:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: draft-ietf-manet-dlep-lid-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nancy Cam-Winget Message-ID: <156564165569.17882.915608325158791837@ietfa.amsl.com> Date: Mon, 12 Aug 2019 13:27:35 -0700 Archived-At: Subject: [manet] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05 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, 12 Aug 2019 20:27:36 -0000 Reviewer: Nancy Cam-Winget Review result: Has Issues SECDIR review of draft-ietf-manet-dlep-lid-extension-05 Reviewer: Nancy Cam-Winget Review result: Ready with questions (issues?) I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document defines extensions to the Data Link Exchange Protocol (DLEP) to enable modems to advertise the status of wireless links that are not reachable beyond a device on the Layer 2 domain. The extension focuses on the inclusion of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3 connectivity. As this is not my area of domain expertise, I have the following questions: * It seems that WANs could include NATs but I see no consideration for how to treat the IP addresses in the presence of NAT. Is this not an issue? I think some mention of this should be included. * Section 2.1: What happens if Link Identifiers span multiple MAC Addresses or if they are reused? What does it mean for a link identifier to be reused (per session? or ever?) There is a reference to the destination MUST NOT be recycled, but I am not sure what recycled means in this context? What happens if they are reused? A note either here, or in the security considerations should describe these conditions. * Section 2.2: what happens if "link identifiers" is negotiated but no link identifiers are provided? * Security (no privacy considerations?): given that this draft is now including IP addresses, it seems that there is potential to determine a network topology and perhaps identification of a network used to mount attacks. I do see that RFC 8175 doesn't have privacy considerations, but given that this is now at the IP layer it may be good to provide one? From nobody Fri Aug 16 13:32:08 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 792C812008B; Fri, 16 Aug 2019 13:32:06 -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-lid-extension@ietf.org, Justin Dean , aretana.ietf@gmail.com, manet-chairs@ietf.org, bebemaster@gmail.com, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156598752648.32003.13612124024966975295.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2019 13:32:06 -0700 Archived-At: Subject: [manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-lid-extension-05: (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, 16 Aug 2019 20:32:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-manet-dlep-lid-extension-05: 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-lid-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not entirely sure I understand the expected mode of operation here. Clearly the overall goal is to advertise IP reachability, but it seems the way we do this is to construct an opaque "link identifier" to indicate to the DLEP peer that there is "some other link broader than layer-2" attached, and then rely on the existing IP address/attached-subnet data items to associate that opaque link identifier with the corresponding IP resources. But this document doesn't make it fully clear to me the details of associating IP resources with the link identifier: how are the two data items known to be bound together; what is the scope of attachment; is there potential for confusion if multiple bindings are transmitted in parallel; etc. As best as I can tell this is intended to be wrapped into the single line that "[t]he Link Identifier Data Item MAY be used wherever a MAC Address Data Item is defined as usable in core DLEP.", but spending another sentence or two for a brief overview and/or section reference might be worth the reader's time. (In some sense, we also don't really say how the semantics from the MAC Address Data Item transfer over to the Link Identifier Data Item usage, which could be helpful, too.) In a similar vein, I'm not sure that I understand the distinction between this mechanism and the existing IP address/attached-subnet data items from RFC 8175. My current understanding is that the semantics of the structures in RFC 8175 is to indicate IP resources that are "directly attached" to the indicated Destination, but that this new mechanism is needed for cases when the IP resources are not directly attached to, but are reachable via, the indicated Destination. Is that correct? It might be good to have some further discussion in the document about why the existing mechanisms are inadequate/insufficient for the described use cases (I mostly assume that having the additional Destination/link identifier allows for more granular updates, instead of having to reannounce the entire IP reachability via the layer-2 Destination's entry, but that's just an assumption). Section 1.1 I'm probably just confusing myself, but: Local Layer 2 domain: The Layer 2 domain that links the router and modem participants of the current DLEP session. uses "DLEP session", which suggests to me that it is indeed quite local, with the current DLEP session just involving the directly-connected router and modem. On the other hand: Layer 3 DLEP Destination: A DLEP Destination that is not directly addressable within the local Layer 2 domain, but is reachable via a node addressable within the local Layer 2 domain. (in combination with the introduction) is suggesting to me that the layer-3 destination is something with IP reachability via a device on the other end of a radio link from one of the local modems, and also implying that the router/modem at the other end of the radio link is itself supposed to be part of the "local Layer 2 domain". So I'm not sure how broad the local Layer 2 domain is supposed to be. Gateway Node: The last device with a MAC address reachable in the local Layer 2 domain on the path from the DLEP router participant, towards the Layer 3 DLEP Destination. This device is commonly the DLEP peer modem but could be another DLEP Destination in the Layer 2 domain. Just to check my understanding: the DLEP peer modem is the "directly attached" one, and another "DLEP Destination" would be a different router? Section 2 As only modems are initially aware of Layer 3 DLEP Destinations, Link Identifier Data Items referring to a new link MUST first appear in a DLEP Destination Up Message from the modem to the router. Once a nit/style: this statement of fact ("only modems are initially aware") comes a bit out of the blue and doesn't have any surrounding justification/explanation. It's fairly clear that it's just an inherent property of how the information flows around, but could perhaps be written in a more reader-friendly way. Section 2.2 If a modem requires support for this extension in order to describe destinations, and the router does not advertise support, then the "In order to describe destinations" is perhaps ambiguous about some vs. all attached destinations. Section 3.1 Am I supposed to only send this data item in the Session Initialization Response Message if I'm also negotiating the Link Identifiers extension? Section 4 It would be good to see a response to the secdir reviewer's question about potential privacy considerations of expanding the scope of IP connectivity described. Additionally, we require that the router "must not make any assumptions about the meaning of Link Identifiers, or how Link Identifiers are generated". To me, this suggests that various modem implementations are likely to reuse identifiers of some other nature as DLEP link identifiers, and we are imploring the routers to not rely on any specific such internal structure. In the general case, when this sort of "identifier reuse" occurs, we have to be careful to consider any security or privacy considerations should a router ignore the advice and attempt to look at the internal structure of the identifier. In this specific case of DLEP, there does not seem to be much of a concern, since we expect the router and modem to be fairly tightly integrated and at an equivalent trust level, but I did want to mention it as a possible consideration. It might also be appropriate to talk about collision probability when randomly assigned Link Identifiers are used and how that relates to the frequency of DLEP session creation and the churn rate of link identifiers. From nobody Sun Aug 18 17:32:54 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 5F84F12012D; Sun, 18 Aug 2019 17:32:44 -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 6kmHS2R8wOHO; Sun, 18 Aug 2019 17:32:41 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 DA724120052; Sun, 18 Aug 2019 17:32:41 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id n9so109677pgc.1; Sun, 18 Aug 2019 17:32:41 -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 :cc; bh=pAv0nHfvRc4YWW4/vSj2VoUfB1CYtGduyFqjjl+OQJY=; b=rwzuk8zyjLuosWDnD3621Lit7bg3/133cK60TFSjA2Qe0uvf/NopC9n9BaUQnvBQ26 o00VRUePwLoQzj5WSB+oE89uUnUxDPnu6Wd8lOoRUwFtQ3khBiq4LKdcRe1BFyxhVAcr vCTJgh6dqF3Gj8wj3z1isqWXUeKBqNYaGTEHZond8aNfRFgWGu5Pd+yl0+LQe5V4sSAg /RY9aP3S582qoNvFizP62FOZByfhQmbuZ6Qsto21v6BWKjAuSyfUNqNHqJoAcOhhvPK9 R0j9fiGxP9GCvR5CJTgalgpti8mfRH8SvgZKuTca4hEBuBAwaTLxVrOt/uFCIySDBYGS +PEg== 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:cc; bh=pAv0nHfvRc4YWW4/vSj2VoUfB1CYtGduyFqjjl+OQJY=; b=Cc+N1ecBPyG1z/QuXEb6TnrbhStSPUagem6jH107FibBE4vdMezscJwZxq8v//i21p zudbI7nSQ39apPLcD3zqkMWY875KykAhlxSQUDwBPjbfqE9oS4O06wT0Yo7nGlnOgKlk PaB5Sm1NVtb4bifIxeeAWdvV3OFlIkmIuZvsrEwTbSxb7LEQn3kLQBQ5CjqcGf2lokAZ +L75OvMD1317PaBTtuUjkgx820a5Tfv/GjxQUqwdoCN7MzIjHcJmL4qIHm5f0h4R08Jp MEG2BbgN61o43PK21RXM5VI21JmkeCIMC/sM96IsnRg3LZq7ZVowOmxEYE8XyYIXrB/g GpFg== X-Gm-Message-State: APjAAAVUxyp6h/bzNyj0BRPwMqOqfM4HMTgY4NIcUUqjfd04jEXZTFi+ wjC1MKfyJTWXxWU19G7CLBAqBh02jN7EwyIfU2A= X-Google-Smtp-Source: APXvYqzseGBuXGWJkPmsdmlSiPyrcYiIpe3BG6bQ1QLHRrFZqDjs8OWAcL2JjQzfPup9tTb9Tu+8xRvJBqZ34AZT+A4= X-Received: by 2002:a17:90a:35e3:: with SMTP id r90mr18460354pjb.34.1566174760178; Sun, 18 Aug 2019 17:32:40 -0700 (PDT) MIME-Version: 1.0 References: <156564165569.17882.915608325158791837@ietfa.amsl.com> In-Reply-To: <156564165569.17882.915608325158791837@ietfa.amsl.com> From: Stan Ratliff Date: Sun, 18 Aug 2019 20:32:29 -0400 Message-ID: To: Nancy Cam-Winget Cc: secdir@ietf.org, draft-ietf-manet-dlep-lid-extension.all@ietf.org, MANET IETF , ietf@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c981a05906d7a6b" Archived-At: Subject: Re: [manet] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 00:32:44 -0000 --0000000000003c981a05906d7a6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. Thank you for the review and comments. Responses inline. On Mon, Aug 12, 2019 at 4:28 PM Nancy Cam-Winget via Datatracker < noreply@ietf.org> wrote: > Reviewer: Nancy Cam-Winget > Review result: Has Issues > > SECDIR review of draft-ietf-manet-dlep-lid-extension-05 > > Reviewer: Nancy Cam-Winget > Review result: Ready with questions (issues?) > > I have reviewed this document as part of the security directorate's=C3=8A > ongoing effort to review all IETF documents being processed by the=C3=8A > IESG.=C3=8A=C3=8AThese comments were written primarily for the benefit of= the=C3=8A > security area directors.=C3=8A=C3=8ADocument editors and WG chairs should= treat=C3=8A > these comments just like any other last call comments. > > This document defines extensions to the Data Link Exchange Protocol (DLEP= ) > to > enable modems to advertise the status of wireless links that are not > reachable > beyond a device on the Layer 2 domain. The extension focuses on the > inclusion > of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3 > connectivity. > > As this is not my area of domain expertise, I have the following question= s: > * It seems that WANs could include NATs but I see no consideration for ho= w > to > treat the IP addresses in the presence of NAT. Is this not an issue? I > think > some mention of this should be included. > IP addresses that are contained in DLEP LID are assumed to be on the public side of any NAT (that is, post-NAT for egress traffic, pre-NAT for ingress traffic). We can work on including this assumption in the draft. > > * Section 2.1: What happens if Link Identifiers span multiple MAC > Addresses or > if they are reused? What does it mean for a link identifier to be reused > (per > session? or ever?) There is a reference to the destination MUST NOT be > recycled, but I am not sure what recycled means in this context? What > happens > if they are reused? A note either here, or in the security consideration= s > should describe these conditions. > Link identifiers MUST NOT span MAC addresses, nor can they be reused. This is what the text refers to when it discusses "recycling" LIDs.Having said that, we will work on strengthening the language. > > * Section 2.2: what happens if "link identifiers" is negotiated but no li= nk > identifiers are provided? > If identifiers are negotiated, and then not used, there is no impact to operation. The LID was introduced as a way for radio modems to introduce destinations that it knows about, but that it does not specifically manage from a Layer1/Layer2 perspective. > > * Security (no privacy considerations?): given that this draft is now > including > IP addresses, it seems that there is potential to determine a network > topology > and perhaps identification of a network used to mount attacks. I do see > that > RFC 8175 doesn't have privacy considerations, but given that this is now > at the > IP layer it may be good to provide one? > The notion of IP address vectors is in RFC 8175. The IP address(es) represent the unicast IP addresses of the destination specified, or potentially a Multicast address to be carried over the RF. IMO, the introduction of LIDs and their IP addresses does not increase the potential security exposure over and above the RFC 8175 flows that can contiain IP addressing information. I hope this addresses your concerns. Please let me know if additional discussion is needed. Regards, Stan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --0000000000003c981a05906d7a6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello. Thank you for the review and comments. Respons= es inline.


On Mon, Aug 12, 2019 at 4:28 PM Nancy Cam-Winget v= ia Datatracker <noreply@ietf.org= > wrote:
Reviewer: Nancy Cam-Winget
Review result: Has Issues

SECDIR review of draft-ietf-manet-dlep-lid-extension-05

Reviewer: Nancy Cam-Winget
Review result: Ready with questions (issues?)

I have reviewed this document as part of the security directorate's=C3= =8A
ongoing effort to review all IETF documents being processed by the=C3=8A IESG.=C3=8A=C3=8AThese comments were written primarily for the benefit of t= he=C3=8A
security area directors.=C3=8A=C3=8ADocument editors and WG chairs should t= reat=C3=8A
these comments just like any other last call comments.

This document defines extensions to the Data Link Exchange Protocol (DLEP) = to
enable modems to advertise the status of wireless links that are not reacha= ble
beyond a device on the Layer 2 domain. The extension focuses on the inclusi= on
of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3
connectivity.

As this is not my area of domain expertise, I have the following questions:=
* It seems that WANs could include NATs but I see no consideration for how = to
treat the IP addresses in the presence of NAT.=C2=A0 Is this not an issue?= =C2=A0 =C2=A0I think
some mention of this should be included.

IP addresses that are contained in DLEP LID are assumed to be on the publ= ic side of any NAT (that is, post-NAT for egress traffic, pre-NAT for ingre= ss traffic). We can work on including this assumption in the draft.=C2=A0
=C2=A0

* Section 2.1: What happens if Link Identifiers span multiple MAC Addresses= or
if they are reused?=C2=A0 What does it mean for a link identifier to be reu= sed (per
session? or ever?)=C2=A0 There is a reference to the destination MUST NOT b= e
recycled, but I am not sure what recycled means in this context?=C2=A0 What= happens
if they are reused?=C2=A0 A note either here, or in the security considerat= ions
should describe these conditions.

Link = identifiers MUST NOT span MAC addresses, nor can they be reused. This is wh= at the text refers to when it discusses "recycling" LIDs.Having s= aid that, we will work on strengthening the language.=C2=A0
=C2= =A0

* Section 2.2: what happens if "link identifiers" is negotiated b= ut no link
identifiers are provided?

If identifier= s are negotiated, and then not used, there is no impact to operation. The L= ID was introduced as a way for radio modems to introduce destinations that = it knows about, but that it does not specifically manage from a Layer1/Laye= r2 perspective.=C2=A0
=C2=A0

* Security (no privacy considerations?): given that this draft is now inclu= ding
IP addresses, it seems that there is potential to determine a network topol= ogy
and perhaps identification of a network used to mount attacks.=C2=A0 I do s= ee that
RFC 8175 doesn't have privacy considerations, but given that this is no= w at the
IP layer it may be good to provide one?

The notion of IP address vectors is in RFC 8175. The IP address(es) repres= ent the unicast IP addresses of the destination specified, or potentially a= Multicast address to be carried over the RF. IMO, the introduction of LIDs= and their IP addresses does not increase the potential security exposure o= ver and above the RFC 8175 flows that can contiain IP addressing informatio= n.=C2=A0

I hope this addresses your concerns. Plea= se let me know if additional discussion is needed.=C2=A0

Regards,
Stan




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--0000000000003c981a05906d7a6b-- From nobody Sun Aug 18 17:38:39 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 F39B212007A; Sun, 18 Aug 2019 17:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 xrl2VO3pUK2y; Sun, 18 Aug 2019 17:38:27 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 C94AB12004E; Sun, 18 Aug 2019 17:38:27 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id n190so117552pgn.0; Sun, 18 Aug 2019 17:38:27 -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 :cc; bh=P6NVar+kDZjKEh3rLtEAQ9DRxIgUEPTbtj5XqA6Wg68=; b=B1IOUeyWxnku9dvaBHFfuv6Jnaywe9R13/ScuWs9bQRpmm6AbE/DrFl1ZObmBvm1aI tHWeIPgid2cjX2HyLmMd9LVI3S8CcZjE3u693NcGTehNksPwcGjW6dubiTRe7U411Ymo k/v7FV7ODyvs/AJRPrJ67moc64wYpWjtjoa3fQIH3VKJ1XgV/n6+apm+Trh34zuq9BEH jL3GvzMx/YVuf0J7lJt0TNENKBAtrLks4FkHnjdW5tUsZn6i35O6GNUGBKizgvuFVpZi AwZ7lI8693yOZdxiZjfWe2aIuD5rNI2tZE5OEVOMGeFjcCXW68xvAND83BngraoLXj28 27pw== 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:cc; bh=P6NVar+kDZjKEh3rLtEAQ9DRxIgUEPTbtj5XqA6Wg68=; b=dVkpYxqxF7ptrT1Lc8YXDtOv41WQ9ahJYRKGWJlyq90PbjwzkKEK9k9eP8Q4AA9Uzt /o7TCDO12PRHNK3THzYPiHMCXH7/LLvrnGGyKtkjEZglQtP+X9xaUOz2FwVLDvweKDcp WizoghkqN6Zufh30g62NRwkrioGW+ok1LN2+598om5xn2i2bXw074omZSOEw9+P4f6BN FjiOsdqT8tn2ryBhFNTUEGrRGNOb9dq6eL/n8NjbGz49/UnQHVdrCcnps7eEmEOHi9Tr /Mc1dy6lK2lNhLSOdYjr/zXOA0RPKRLqSc1fDBM9Z94tY1CuMsIlPcFkFbUBRuhdwEvT qREA== X-Gm-Message-State: APjAAAVyzq1/wHXHrREC9tNdmTJ4bWG7HlTMAv9BQU0I1ip+jybRZ/nO JtEPHEN7EAYzJ+ibIneYJkeYFEyXqU7I7gQfWmwM3eFb X-Google-Smtp-Source: APXvYqy43tEPf9yg2/r2DdmQxc0GC7SImaoHc2G6RrTfwxoQZp1Zev3/Z+YnenUTQoSsYCAY3LlRRijCSNZOd+s86Fc= X-Received: by 2002:aa7:818b:: with SMTP id g11mr21904077pfi.122.1566175107330; Sun, 18 Aug 2019 17:38:27 -0700 (PDT) MIME-Version: 1.0 References: <156598752648.32003.13612124024966975295.idtracker@ietfa.amsl.com> In-Reply-To: <156598752648.32003.13612124024966975295.idtracker@ietfa.amsl.com> From: Stan Ratliff Date: Sun, 18 Aug 2019 20:38:16 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-manet-dlep-lid-extension@ietf.org, MANET IETF , manet-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000edb8b205906d8e6c" Archived-At: Subject: Re: [manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-lid-extension-05: (with 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: Mon, 19 Aug 2019 00:38:30 -0000 --000000000000edb8b205906d8e6c Content-Type: text/plain; charset="UTF-8" Benjamin, Thank you for the review and comments. I wanted to let you know that we (the authors) are in the process of discussing your comments, but we need a few more days to complete the process. Thanks again. Regards, Stan On Fri, Aug 16, 2019 at 4:32 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-manet-dlep-lid-extension-05: 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-lid-extension/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm not entirely sure I understand the expected mode of operation here. > Clearly the overall goal is to advertise IP reachability, but it seems > the way we do this is to construct an opaque "link identifier" to > indicate to the DLEP peer that there is "some other link broader than > layer-2" attached, and then rely on the existing IP > address/attached-subnet data items to associate that opaque link > identifier with the corresponding IP resources. But this document > doesn't make it fully clear to me the details of associating IP > resources with the link identifier: how are the two data items known to > be bound together; what is the scope of attachment; is there potential > for confusion if multiple bindings are transmitted in parallel; etc. > As best as I can tell this is intended to be wrapped into the single > line that "[t]he Link Identifier Data Item MAY be used wherever a MAC > Address Data Item is defined as usable in core DLEP.", but spending > another sentence or two for a brief overview and/or section reference > might be worth the reader's time. (In some sense, we also don't really > say how the semantics from the MAC Address Data Item transfer over to > the Link Identifier Data Item usage, which could be helpful, too.) > > In a similar vein, I'm not sure that I understand the distinction > between this mechanism and the existing IP address/attached-subnet data > items from RFC 8175. My current understanding is that the semantics of > the structures in RFC 8175 is to indicate IP resources that are > "directly attached" to the indicated Destination, but that this new > mechanism is needed for cases when the IP resources are not directly > attached to, but are reachable via, the indicated Destination. Is that > correct? It might be good to have some further discussion in the > document about why the existing mechanisms are inadequate/insufficient > for the described use cases (I mostly assume that having the additional > Destination/link identifier allows for more granular updates, instead of > having to reannounce the entire IP reachability via the layer-2 > Destination's entry, but that's just an assumption). > > Section 1.1 > > I'm probably just confusing myself, but: > > Local Layer 2 domain: The Layer 2 domain that links the router and > modem participants of the current DLEP session. > > uses "DLEP session", which suggests to me that it is indeed quite local, > with the current DLEP session just involving the directly-connected > router and modem. On the other hand: > > Layer 3 DLEP Destination: A DLEP Destination that is not directly > addressable within the local Layer 2 domain, but is reachable via > a node addressable within the local Layer 2 domain. > > (in combination with the introduction) is suggesting to me that the > layer-3 destination is something with IP reachability via a device on > the other end of a radio link from one of the local modems, and also > implying that the router/modem at the other end of the radio link is > itself supposed to be part of the "local Layer 2 domain". So I'm not > sure how broad the local Layer 2 domain is supposed to be. > > Gateway Node: The last device with a MAC address reachable in the > local Layer 2 domain on the path from the DLEP router participant, > towards the Layer 3 DLEP Destination. This device is commonly the > DLEP peer modem but could be another DLEP Destination in the Layer > 2 domain. > > Just to check my understanding: the DLEP peer modem is the "directly > attached" one, and another "DLEP Destination" would be a different > router? > > Section 2 > > As only modems are initially aware of Layer 3 DLEP Destinations, Link > Identifier Data Items referring to a new link MUST first appear in a > DLEP Destination Up Message from the modem to the router. Once a > > nit/style: this statement of fact ("only modems are initially aware") > comes a bit out of the blue and doesn't have any surrounding > justification/explanation. It's fairly clear that it's just an inherent > property of how the information flows around, but could perhaps be > written in a more reader-friendly way. > > Section 2.2 > > If a modem requires support for this extension in order to describe > destinations, and the router does not advertise support, then the > > "In order to describe destinations" is perhaps ambiguous about some vs. > all attached destinations. > > Section 3.1 > > Am I supposed to only send this data item in the Session Initialization > Response Message if I'm also negotiating the Link Identifiers extension? > > Section 4 > > It would be good to see a response to the secdir reviewer's question > about potential privacy considerations of expanding the scope of IP > connectivity described. > > Additionally, we require that the router "must not make any assumptions > about the meaning of Link Identifiers, or how Link Identifiers are > generated". To me, this suggests that various modem implementations are > likely to reuse identifiers of some other nature as DLEP link > identifiers, and we are imploring the routers to not rely on any > specific such internal structure. In the general case, when this sort > of "identifier reuse" occurs, we have to be careful to consider any > security or privacy considerations should a router ignore the advice and > attempt to look at the internal structure of the identifier. In this > specific case of DLEP, there does not seem to be much of a concern, > since we expect the router and modem to be fairly tightly integrated and > at an equivalent trust level, but I did want to mention it as a possible > consideration. > > It might also be appropriate to talk about collision probability when > randomly assigned Link Identifiers are used and how that relates to the > frequency of DLEP session creation and the churn rate of link > identifiers. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --000000000000edb8b205906d8e6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benjamin,=C2=A0

Thank you for the revie= w and comments. I wanted to let you know that we (the authors) are in the p= rocess of discussing your comments, but we need a few more days to complete= the process.=C2=A0

Thanks again.

Regards,
Stan


On Fri, Aug 16, 2019= at 4:32 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin = Kaduk has entered the following ballot position for
draft-ietf-manet-dlep-lid-extension-05: 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/s= tatement/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/do= c/draft-ietf-manet-dlep-lid-extension/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

Section 1.1

I'm probably just confusing myself, but:

=C2=A0 =C2=A0Local Layer 2 domain:=C2=A0 The Layer 2 domain that links the = router and
=C2=A0 =C2=A0 =C2=A0 modem participants of the current DLEP session.

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

=C2=A0 =C2=A0Layer 3 DLEP Destination:=C2=A0 A DLEP Destination that is not= directly
=C2=A0 =C2=A0 =C2=A0 addressable within the local Layer 2 domain, but is re= achable via
=C2=A0 =C2=A0 =C2=A0 a node addressable within the local Layer 2 domain.
(in combination with the introduction) is suggesting to me that the
layer-3 destination is something with IP reachability via a device on
the other end of a radio link from one of the local modems, and also
implying that the router/modem at the other end of the radio link is
itself supposed to be part of the "local Layer 2 domain".=C2=A0 S= o I'm not
sure how broad the local Layer 2 domain is supposed to be.

=C2=A0 =C2=A0Gateway Node:=C2=A0 The last device with a MAC address reachab= le in the
=C2=A0 =C2=A0 =C2=A0 local Layer 2 domain on the path from the DLEP router = participant,
=C2=A0 =C2=A0 =C2=A0 towards the Layer 3 DLEP Destination.=C2=A0 This devic= e is commonly the
=C2=A0 =C2=A0 =C2=A0 DLEP peer modem but could be another DLEP Destination = in the Layer
=C2=A0 =C2=A0 =C2=A0 2 domain.

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

Section 2

=C2=A0 =C2=A0As only modems are initially aware of Layer 3 DLEP Destination= s, Link
=C2=A0 =C2=A0Identifier Data Items referring to a new link MUST first appea= r in a
=C2=A0 =C2=A0DLEP Destination Up Message from the modem to the router.=C2= =A0 Once a

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

Section 2.2

=C2=A0 =C2=A0If a modem requires support for this extension in order to des= cribe
=C2=A0 =C2=A0destinations, and the router does not advertise support, then = the

"In order to describe destinations" is perhaps ambiguous about so= me vs.
all attached destinations.

Section 3.1

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

Section 4

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

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

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


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--000000000000edb8b205906d8e6c-- From nobody Mon Aug 19 14:02:52 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 739B1120045; Mon, 19 Aug 2019 14:02:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-manet-dlep-lid-extension@ietf.org, Justin Dean , aretana.ietf@gmail.com, manet-chairs@ietf.org, bebemaster@gmail.com, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156624856146.19699.12798015190476729792.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 14:02:41 -0700 Archived-At: Subject: [manet] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-manet-dlep-lid-extension-05=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: Mon, 19 Aug 2019 21:02:42 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-manet-dlep-lid-extension-05: 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-lid-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I have two questions in the COMMENT section that I would appreciate to be answered. Regards, -éric == COMMENTS == -- Section 3.1 -- Is there any use of the "link identifier length data item" as in section 3.2 the link identifier has a field for its length? -- Section 3.2 -- What is the expected behavior when the "link identifier data item" does not match the length ? From nobody Tue Aug 20 21:05:25 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 8775612007A; Tue, 20 Aug 2019 21:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-lid-extension@ietf.org, Justin Dean , aretana.ietf@gmail.com, manet-chairs@ietf.org, bebemaster@gmail.com, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156636032354.338.8497793648521076629.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 21:05:23 -0700 Archived-At: Subject: [manet] Suresh Krishnan's Discuss on draft-ietf-manet-dlep-lid-extension-05: (with DISCUSS) 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, 21 Aug 2019 04:05:24 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-manet-dlep-lid-extension-05: 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-lid-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.1. I might be missing something here but I think that the "MUST be used" in this session is wrong and must be relaxed by qualifying it. Here is why. In case the router does not advertise support by including the value 'Link Identifiers' in the Extension Data Item inside the Session Initialization Message, I feel that the modem MUST NOT send the Link Identifier Length Data Item as this will result in a Session Termination message from the router based on the rules specified in Section 12.1 of RFC8175 due to the unknown data item. If you agree with my assessment, I would suggest a change like this. If not, can you please clarify. OLD: It MUST be used during Session Initialization, contained in a Session Initialization Response Message, if the specified length is not the default value of 4 octets. NEW: If the router advertised support by including the value 'Link Identifiers' in the Extension Data Item inside the Session Initialization Message, this data item MUST be used during Session Initialization, contained in a Session Initialization Response Message, if the specified length is not the default value of 4 octets. If not, this Data Item MUST NOT be sent. From nobody Wed Aug 21 05:58:43 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 9029F1208A5; Wed, 21 Aug 2019 05:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 5prvaqT4zljC; Wed, 21 Aug 2019 05:58:30 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04AEC12004D; Wed, 21 Aug 2019 05:58:29 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0468.000; Wed, 21 Aug 2019 13:58:24 +0100 From: Rick Taylor To: "suresh@kaloom.com" , "iesg@ietf.org" CC: "manet-chairs@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep-lid-extension@ietf.org" Thread-Topic: [manet] Suresh Krishnan's Discuss on draft-ietf-manet-dlep-lid-extension-05: (with DISCUSS) Thread-Index: AQHVV9Wvij01mpbxp0+abUjg8D3YaKcFf8mA Date: Wed, 21 Aug 2019 12:58:23 +0000 Message-ID: References: <156636032354.338.8497793648521076629.idtracker@ietfa.amsl.com> In-Reply-To: <156636032354.338.8497793648521076629.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.32.1-2 x-originating-ip: [10.10.1.5] Content-Type: text/plain; charset="utf-8" Content-ID: <2946142A2FCA7D44BB691E6FD6847EF4@home.tropicalstormsoftware.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Suresh Krishnan's Discuss on draft-ietf-manet-dlep-lid-extension-05: (with DISCUSS) 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: Wed, 21 Aug 2019 12:58:33 -0000 SGkgU3VyZXNoLA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4NCg0KVGhpcyBpcyBhIGRpZmZp Y3VsdCBvbmUsIGFzIHRoZSB3aG9sZSBkb2N1bWVudCByZWZlcnMgdG8gYW4gZXh0ZW5zaW9uLA0K d2UgaW5jbHVkZSBjYW5vbmljYWwgdGV4dCBlYXJseSBvbiB0aGF0ICh0cmllcyB0bykgc3RhdGUg dGhhdCBpZiB5b3UNCnN1cHBvcnQgdGhpcyBleHRlbnNpb24sIHRoaXMgaXMgd2hhdCB5b3Ugc2hv dWxkIGRvLCBpZiBub3QgZG9uJ3QuIA0KDQpIb3dldmVyLCB5b3UgYXJlIHJpZ2h0IHRoYXQgaW4g dGhlIG1lc3NhZ2UgdGhhdCBpbmNsdWRlcyB0aGUgZXh0ZW5zaW9uDQpuZWdvdGlhdGlvbiBhbmQg cG9zc2libHkgdGhpcyBtZXNzYWdlLCB5b3VyIHN1Z2dlc3Rpb24gaXMgZ29vZC4NCg0KQ2hlZXJz LA0KDQpSaWNrDQoNCg0KT24gVHVlLCAyMDE5LTA4LTIwIGF0IDIxOjA1IC0wNzAwLCBTdXJlc2gg S3Jpc2huYW4gdmlhIERhdGF0cmFja2VyDQp3cm90ZToNCj4gU3VyZXNoIEtyaXNobmFuIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW1h bmV0LWRsZXAtbGlkLWV4dGVuc2lvbi0wNTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dA0KPiB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K PiANCj4gDQo+IFBsZWFzZSByZWZlciB0byANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo ZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1hbmV0 LWRsZXAtbGlkLWV4dGVuc2lvbi8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4g RElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4gDQo+ICogU2VjdGlvbiAzLjEuDQo+IA0K PiBJIG1pZ2h0IGJlIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUgYnV0IEkgdGhpbmsgdGhhdCB0aGUg Ik1VU1QgYmUgdXNlZCINCj4gaW4gdGhpcw0KPiBzZXNzaW9uIGlzIHdyb25nIGFuZCBtdXN0IGJl IHJlbGF4ZWQgYnkgcXVhbGlmeWluZyBpdC4gSGVyZSBpcyB3aHkuDQo+IEluIGNhc2UgdGhlDQo+ IHJvdXRlciBkb2VzIG5vdCBhZHZlcnRpc2Ugc3VwcG9ydCBieSBpbmNsdWRpbmcgdGhlIHZhbHVl ICdMaW5rDQo+IElkZW50aWZpZXJzJyBpbg0KPiB0aGUgRXh0ZW5zaW9uIERhdGEgSXRlbSBpbnNp ZGUgdGhlIFNlc3Npb24gSW5pdGlhbGl6YXRpb24gTWVzc2FnZSwgSQ0KPiBmZWVsIHRoYXQNCj4g dGhlIG1vZGVtIE1VU1QgTk9UIHNlbmQgdGhlIExpbmsgSWRlbnRpZmllciBMZW5ndGggRGF0YSBJ dGVtIGFzIHRoaXMNCj4gd2lsbA0KPiByZXN1bHQgaW4gYSBTZXNzaW9uIFRlcm1pbmF0aW9uIG1l c3NhZ2UgZnJvbSB0aGUgcm91dGVyIGJhc2VkIG9uIHRoZQ0KPiBydWxlcw0KPiBzcGVjaWZpZWQg aW4gU2VjdGlvbiAxMi4xIG9mIFJGQzgxNzUgZHVlIHRvIHRoZSB1bmtub3duIGRhdGEgaXRlbS4N Cj4gDQo+IElmIHlvdSBhZ3JlZSB3aXRoIG15IGFzc2Vzc21lbnQsIEkgd291bGQgc3VnZ2VzdCBh IGNoYW5nZSBsaWtlIHRoaXMuDQo+IElmIG5vdCwNCj4gY2FuIHlvdSBwbGVhc2UgY2xhcmlmeS4N Cj4gDQo+IE9MRDoNCj4gDQo+ICAgIEl0IE1VU1QgYmUgdXNlZCBkdXJpbmcgU2Vzc2lvbiBJbml0 aWFsaXphdGlvbiwgY29udGFpbmVkIGluIGENCj4gU2Vzc2lvbg0KPiAgICBJbml0aWFsaXphdGlv biBSZXNwb25zZSBNZXNzYWdlLCBpZiB0aGUgc3BlY2lmaWVkIGxlbmd0aCBpcyBub3QNCj4gdGhl DQo+ICAgIGRlZmF1bHQgdmFsdWUgb2YgNCBvY3RldHMuDQo+IA0KPiBORVc6DQo+IA0KPiAgICBJ ZiB0aGUgcm91dGVyIGFkdmVydGlzZWQgc3VwcG9ydCBieSBpbmNsdWRpbmcgdGhlIHZhbHVlICdM aW5rDQo+IElkZW50aWZpZXJzJw0KPiAgICBpbiB0aGUgRXh0ZW5zaW9uIERhdGEgSXRlbSBpbnNp ZGUgdGhlIFNlc3Npb24gSW5pdGlhbGl6YXRpb24NCj4gTWVzc2FnZSwgdGhpcw0KPiAgICBkYXRh IGl0ZW0gTVVTVCBiZSB1c2VkIGR1cmluZyBTZXNzaW9uIEluaXRpYWxpemF0aW9uLCBjb250YWlu ZWQgaW4NCj4gYSBTZXNzaW9uDQo+ICAgIEluaXRpYWxpemF0aW9uIFJlc3BvbnNlIE1lc3NhZ2Us IGlmIHRoZSBzcGVjaWZpZWQgbGVuZ3RoIGlzIG5vdA0KPiB0aGUgZGVmYXVsdA0KPiAgICB2YWx1 ZSBvZiA0IG9jdGV0cy4gSWYgbm90LCB0aGlzIERhdGEgSXRlbSBNVVNUIE5PVCBiZSBzZW50Lg0K PiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg== From nobody Wed Aug 21 06:13: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 76216120961; Wed, 21 Aug 2019 06:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=YE79HIN1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a72mU4GW 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 Pu4Oof6QzzkW; Wed, 21 Aug 2019 06:13:00 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647C012092F; Wed, 21 Aug 2019 06:13:00 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4E59D21EC3; Wed, 21 Aug 2019 09:12:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 21 Aug 2019 09:12:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=HVwb8bRa0Bd3rc6Ec2JYS21 jShWglIJVvgOGobobKiY=; b=YE79HIN1GdqNH6rD7VXX6GdX7l4D3Gx5mQgl87L i3SgycclcETho7nWwQiB57qqKJS28TO/OaaRnUbV0NP0CwTJsyKg6WhIqQM2WLAV S2AHcvSraAXFgFd7k/WYVURbM7oUFlrhUilSRT/Q1VIfXGBmG4XJE82tDTi8OaWk teRXk880xkDpXfnaiW8PmLR3svnCqeseZ4N90uwmoVA3pSzwUAtTj7qFOYNmNMcO mXucT7U80Td6JoUkoo2zF7OHLdZ7/JfocrwoFk/RaUIMGAb1wiz5E6aG0N/bpCXI TULYOvqkQNwGeZ27MC7Nw6N6zHlB3pABzRAXIahYyuuYHJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=HVwb8b Ra0Bd3rc6Ec2JYS21jShWglIJVvgOGobobKiY=; b=a72mU4GWHixt+NDRH0noig fS4hk3jvmath84uKI8nw+7Pv9grIHFDbiAHMzNs8i97hgkT4eBwsZgqS1VcrknBQ fZ3yD3+VzgcX6WzRugZtrbtjQOUZzbV/3RVxcU+7zLZSGSsALcuwX1/A6hGtG3CD WYNcFGKPcjJUt1qRnqtTXyVyXm4DMKyzM1PzATpFi+u3C+/1jW61iKMh9x8VkdlZ Vglg9rsBg9MUzBQz6s674hAQLW76fG5CtkSXF8HDFMQxC3m75MX6yJmizKsIjUY6 Zhg6OHcL1r9hZcyHkclHXcp1my/sFKi4D1ta4cZv5z5dyOc7rBuRybsw3DAjTmcA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudegfedgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppeduje efrdefkedruddujedrledvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrges tghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E7E6D6005F; Wed, 21 Aug 2019 09:12:56 -0400 (EDT) From: Alissa Cooper Message-Id: <16A52399-DEFB-4553-BC81-5E22F31558AD@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_35DAAD6A-7469-4CB8-ABD7-F72E18F6C477" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 21 Aug 2019 09:12:55 -0400 In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801E6BFF315@tss-server1.home.tropicalstormsoftware.com> Cc: "gen-art@ietf.org" , "draft-ietf-manet-dlep-lid-extension.all@ietf.org" , "manet@ietf.org" , "ietf@ietf.org" To: Rick Taylor , Stewart Bryant References: <156508221782.19312.14665262406766852305@ietfa.amsl.com> <38A5475DE83986499AEACD2CFAFC3F9801E6BFF315@tss-server1.home.tropicalstormsoftware.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [manet] [Gen-art] Genart last call review of draft-ietf-manet-dlep-lid-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:13:03 -0000 --Apple-Mail=_35DAAD6A-7469-4CB8-ABD7-F72E18F6C477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stewart, thanks for your review. Rick, thanks for agreeing to make the = changes. I enetered a No Objection ballot. Alissa > On Aug 6, 2019, at 5:50 AM, Rick Taylor = wrote: >=20 > Hi Stewart, >=20 > Thanks for the prompt review. We will wait for a few more reviews and = publish a fixed document. >=20 > Many thanks, >=20 > Rick >=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org = ] On Behalf Of Stewart Bryant >> via Datatracker >> Sent: 06 August 2019 10:04 >> To: gen-art@ietf.org >> Cc: draft-ietf-manet-dlep-lid-extension.all@ietf.org = ; = manet@ietf.org ; >> ietf@ietf.org >> Subject: [manet] Genart last call review of = draft-ietf-manet-dlep-lid- >> extension-05 >>=20 >> Reviewer: Stewart Bryant >> Review result: Ready with Nits >>=20 >> 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. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-manet-dlep-lid-extension-05 >> Reviewer: Stewart Bryant >> Review Date: 2019-08-06 >> IETF LC End Date: 2019-08-15 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: A well written document with a few nits that should be = looked at. >>=20 >> Major issues: None >>=20 >> Minor issues: None >>=20 >> Nits/editorial comments: >>=20 >> " The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a" >>=20 >> Nits says that the "[]" brackets should be removed >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> " None of the features introduced by this extension require extra >> consideration by an implementation." >>=20 >> I think that should be >>=20 >> "None of the features introduced by this extension require extra >> security consideration by an implementation." >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> "Assign a new DLEP Extensions Registry value (TBD1) from the" >>=20 >> I think that should be >>=20 >> "Assign a new DLEP Extensions Type Values Registry value (TBD1) from = the" >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet = >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_35DAAD6A-7469-4CB8-ABD7-F72E18F6C477 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Stewart, thanks for your review. Rick, thanks for agreeing to = make the changes. I enetered a No Objection ballot.

Alissa


On Aug 6, 2019, at 5:50 AM, Rick Taylor <rick@tropicalstormsoftware.com> wrote:

Hi Stewart,

Thanks for the prompt review. =  We will wait for a few more reviews and publish a fixed = document.

Many = thanks,

Rick

-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stewart = Bryant
via Datatracker
Sent: 06 August 2019 = 10:04
To: gen-art@ietf.org
Cc: draft-ietf-manet-dlep-lid-extension.all@ietf.org; manet@ietf.org;
ietf@ietf.org
Subject: [manet] Genart last = call review of draft-ietf-manet-dlep-lid-
extension-05

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: = draft-ietf-manet-dlep-lid-extension-05
Reviewer: Stewart = Bryant
Review Date: 2019-08-06
IETF LC End = Date: 2019-08-15
IESG Telechat date: Not scheduled for a = telechat

Summary: A well written document = with a few nits that should be looked at.

Major issues: None

Minor issues: = None

Nits/editorial comments:

" The Dynamic Link Exchange Protocol (DLEP) = [RFC8175] describes a"

Nits says that the = "[]" brackets should be removed

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 " None of the = features introduced by this extension require extra
  consideration by an implementation."

I think that should be

  "None of the features introduced by this = extension require extra
  security consideration = by an implementation."

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

"Assign a new DLEP = Extensions Registry value (TBD1) from the"

I = think that should be

"Assign a new DLEP = Extensions Type Values Registry value (TBD1) from the"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



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

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_35DAAD6A-7469-4CB8-ABD7-F72E18F6C477-- From nobody Wed Aug 21 14:01:17 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 059D9120091; Wed, 21 Aug 2019 14:01:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-lid-extension@ietf.org, Justin Dean , aretana.ietf@gmail.com, manet-chairs@ietf.org, bebemaster@gmail.com, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156642127601.25752.17640440568641989762.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 14:01:16 -0700 Archived-At: Subject: [manet] Barry Leiba's No Objection on draft-ietf-manet-dlep-lid-extension-05: (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: Wed, 21 Aug 2019 21:01:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-manet-dlep-lid-extension-05: 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-lid-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm sure it's just because I don't fully understand DLEP, but I don't get this bit in Section 2.2: However, the modem SHOULD NOT immediately terminate the DLEP session, rather it SHOULD use a combination of DLEP Session Messages and DLEP Attached Subnet Data Items to provide general information. Will implementers know, based on how DLEP works in general, what "general information" to provide? What good will that general information do? The implication here is that the modem will terminate the DLEP session after providing the general information (as it requires this feature and the feature isn't available). So what's the point of the general information the modem will provide before terminating? Is it worth saying a few more words here? From nobody Thu Aug 22 03:58:16 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 E8826120837; Thu, 22 Aug 2019 03:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 xUUmKQWbyM_g; Thu, 22 Aug 2019 03:58:05 -0700 (PDT) Received: from mo2.myeers.net (mo2.myeers.net [87.190.7.233]) (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 D0276120833; Thu, 22 Aug 2019 03:58:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,416,1559512800"; d="scan'208";a="97503897" Received: from unknown (HELO DE0-03HUB-P01.central.mail.corp) ([44.225.67.170]) by de0-03iro-p03-out.myeers.net with ESMTP/TLS/AES256-SHA; 22 Aug 2019 12:58:01 +0200 Received: from esa2e.demail.de.airbusds.corp (10.67.144.34) by DE0-03HUB-P01.central.mail.corp (44.225.67.172) with Microsoft SMTP Server id 15.0.1473.3; Thu, 22 Aug 2019 12:57:58 +0200 Received: from unknown (HELO CD1-4BDAG04-P04.cdmail.common.airbusds.corp) ([10.67.164.149]) by esa2i.demail.de.airbusds.corp with ESMTP; 22 Aug 2019 10:49:50 +0200 Received: from CD1-4BDAG04-P04.cdmail.common.airbusds.corp (10.67.164.149) by CD1-4BDAG04-P04.cdmail.common.airbusds.corp (10.67.164.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 10:49:50 +0200 Received: from CD1-4BDAG04-P04.cdmail.common.airbusds.corp ([10.67.164.149]) by CD1-4BDAG04-P04.cdmail.common.airbusds.corp ([10.67.164.149]) with mapi id 15.00.1473.003; Thu, 22 Aug 2019 10:49:50 +0200 From: "Taylor, Rick" To: Barry Leiba , The IESG CC: "draft-ietf-manet-dlep-lid-extension@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Barry Leiba's No Objection on draft-ietf-manet-dlep-lid-extension-05: (with COMMENT) Thread-Index: AQHVWGO0uv8C0qgK3kST30+csoM7+6cG3BFg Date: Thu, 22 Aug 2019 08:49:50 +0000 Message-ID: References: <156642127601.25752.17640440568641989762.idtracker@ietfa.amsl.com> In-Reply-To: <156642127601.25752.17640440568641989762.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-GM-Security: forwarded Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Barry Leiba's No Objection on draft-ietf-manet-dlep-lid-extension-05: (with 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, 22 Aug 2019 10:58:08 -0000 Hi Barry, Thanks for the feedback. This looks like a classic problem of being too close to the solution! I ag= ree with your comment that a few more words here would be useful for implem= enters less familiar with DLEP than the authors. Regards, Rick Rick Taylor Product Design Authority, Mobile IP Node Principal Engineer (eXpert), Mobile Communications Airbus Defence and Space=A0 Celtic Springs Coedkernew Newport NP10 8FZ =A0 Phone: +44 (0) 1633 71 5637=A0 rick.taylor@airbus.com www.airbusdefenceandspace.com -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Barry Leiba via Da= tatracker Sent: 21 August 2019 22:01 To: The IESG Cc: draft-ietf-manet-dlep-lid-extension@ietf.org; manet@ietf.org; manet-cha= irs@ietf.org Subject: [manet] Barry Leiba's No Objection on draft-ietf-manet-dlep-lid-ex= tension-05: (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-manet-dlep-lid-extension-05: 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-lid-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm sure it's just because I don't fully understand DLEP, but I don't get t= his bit in Section 2.2: However, the modem SHOULD NOT immediately terminate the DLEP session, rather it SHOULD use a combination of DLEP Session Messages and DLEP Attached Subnet Data Items to provide general information. Will implementers know, based on how DLEP works in general, what "general information" to provide? What good will that general information do? The implication here is that the modem will terminate the DLEP session after providing the general information (as it requires this feature and the feat= ure isn't available). So what's the point of the general information the modem will provide before terminating? Is it worth saying a few more words here? _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet This email and its attachments may contain confidential and/or privileged i= nformation. If you have received them in error you must not use, copy or d= isclose their content to any person. Please notify the sender immediately = and then delete this email from your system. This e-mail has been scanned = for viruses, but it is the responsibility of the recipient to conduct their= own security measures. Airbus Operations Limited is not liable for any los= s or damage arising from the receipt or use of this e-mail. Airbus Operations Limited, a company registered in England and Wales, regis= tration number, 3468788. Registered office: Pegasus House, Aerospace Aven= ue, Filton, Bristol, BS34 7PA, UK. From nobody Thu Aug 22 06:14:14 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 74E1F1200FA; Thu, 22 Aug 2019 06:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, 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 N_ZRSuOAoC1q; Thu, 22 Aug 2019 06:14:05 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 82FF11200F8; Thu, 22 Aug 2019 06:14:05 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id j4so3377779iog.11; Thu, 22 Aug 2019 06:14:05 -0700 (PDT) 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:cc; bh=AewmU3cVc2wvE0jf1T6o29IndCpWLK+EYYMKeQ8IZ/g=; b=n8Qn4ngUgMth0iXDluSNYtRiw6sCh4EMueyH4nHB4PFuHvlQ9jtc9nui8pt+7zFeAX PfUwXQsJQCjzKgD5pBGtvx32BeTbqePtEER5Y0ew2zK76J9Pv4KAprZu/0TQp9rg7IBt B399QlQLBCQGO02ujxlB1jCn2xjrZz1E9PyDfv57Lg/UUQiTh6gHlimmvlVx6/X1E2VW KuidWWFgsSjgEqM49/hCjSfhuoDJUrWPlFiQ4Z+y2OXwiqxj6LjAU6dWK3JyUWCSDuiZ 1prLkKMY7IcKtcuds4k2+oWh3wCZXpwaYiSKhWZXQaPhlmmOQZShhQQMN1BGzrlImvx0 TKlw== X-Gm-Message-State: APjAAAW3PTbWxlyorlqa3206PJCRcXf9NsPj47zDHqoBch3PKoFw5U0P Tr+DCAaZayEdul/+ZRMtNwtmM4YfzaxFAGnmL1s= X-Google-Smtp-Source: APXvYqzJS8fO7K13nd+uGmGGwtX84ezPZ9/BDYiLvlcDG1xEFACy8c996kX8mpjZSum7XSY3pGCvid3S5meWbc6PDCM= X-Received: by 2002:a05:6602:2492:: with SMTP id g18mr804189ioe.266.1566479644491; Thu, 22 Aug 2019 06:14:04 -0700 (PDT) MIME-Version: 1.0 References: <156642127601.25752.17640440568641989762.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Thu, 22 Aug 2019 09:13:52 -0400 Message-ID: To: "Taylor, Rick" Cc: The IESG , "draft-ietf-manet-dlep-lid-extension@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Barry Leiba's No Objection on draft-ietf-manet-dlep-lid-extension-05: (with 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, 22 Aug 2019 13:14:07 -0000 > This looks like a classic problem of being too close to the solution! I agree with your comment > that a few more words here would be useful for implementers less familiar with DLEP than the > authors. Thanks, Rick! Barry