From nobody Tue Sep 13 15:24:23 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EE112B0AC; Tue, 13 Sep 2016 15:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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=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 GelYpodf6FxO; Tue, 13 Sep 2016 15:24:17 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 7A53612B135; Tue, 13 Sep 2016 15:23:50 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id y2so405867243oie.0; Tue, 13 Sep 2016 15:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rLl5MJVW6wrXCxnLjuapDJaqIVBeG1n5ekW4o9CL1/Q=; b=JFzbUrv02Hdi0zVULaKif4x1LzOV6MKTbnLpQZXcP9RBJV6TE+bBqNuWiLeVFPf7i/ 4tuhvzI+fknn0F7IsMOkwSL6nK49iJrh9j1MclhJpXWCXrneHgKrs3Eq6znXCl+IB/ro oYxVc4nwkHn6CjMDCL+JNUFTU9WQ3DUVzQlU52qZKReysyFSqCc9sLaz3tdIiSGPob3n /2P9c+9U91MX+nckI+BzV8p62sIiWnvLS7qsbpQl/H3qmkzYsFThDP4zG64474NXVykl Fn2TtemM2PypNY6rvOg5cpQuJjn1NlxYhZAiw/9YIM4zcBQzBJ+h0VwWyAhBB1Gf5HUU Bs4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rLl5MJVW6wrXCxnLjuapDJaqIVBeG1n5ekW4o9CL1/Q=; b=Y3XX9xccWN51hGk+OkPxBlooI/gF/yhp3IDklsJLcX5dDy0Nv1OK8bF8c0YnhydeHf P3a7y0CZfqwrv7UwXw4XFHnKs+LNGGIIhvSOq9eLEPqgM4Lh4PhzwtJtJ2WQxrHbvEfC qAbthUqvSefsZE5gt9IuxB/D9eowvl63okH92i5Zt66C6xWvCvgCzZmAnB1QruW7IWhU vGZiDwGhFrhJ3d7Pzma+gb52XOp/Rdow6dR4T4ozJ2z7++Y1ew38KaAcRvjM8OJ6w5WY 49+x4mdmEYL6e+veftbb600r5+E5uoPbl6efkUBBx+YsY+iBTwCEq7hndd96GOQT0SJc DCAw== X-Gm-Message-State: AE9vXwOV+WuHn2SEpMVadjX4PjLQpC1jSDNT9GOLHkDMWpOlCgrvNykF50ZwDS2gTWSkpHJz3OYojr7zG8Z12w== X-Received: by 10.157.4.200 with SMTP id 66mr30499317otm.171.1473805429681; Tue, 13 Sep 2016 15:23:49 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.202.67.131 with HTTP; Tue, 13 Sep 2016 15:23:49 -0700 (PDT) In-Reply-To: References: From: Kerry Lynn Date: Tue, 13 Sep 2016 18:23:49 -0400 X-Google-Sender-Auth: ya1caaQDCgtHArnPhtm5K7R8tBI Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=94eb2c09c7e81ab2c3053c6b11b2 Archived-At: Cc: "6lo@ietf.org" <6lo@ietf.org>, "int-ads@ietf.org" , "draft-ietf-6lo-6lobac@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT-DIR review of draft-ietf-6lo-6lobac-05 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 22:24:21 -0000 --94eb2c09c7e81ab2c3053c6b11b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks very much for the review; sorry for the delayed response. Comments inline... On Thu, Aug 18, 2016 at 10:57 AM, Tim Chown wrote: > Hi, > > I am an assigned INT directorate reviewer for this draft. These comments > were written primarily for the benefit of the Internet Area Directors. > Document editors and shepherds should treat these comments just like they > would treat comments from any other IETF contributors and resolve them > along with any other Last Call comments that have been received. For more > details of the INT directorate, see directorate.html>. > > Summary > > This document defines the mechanisms for delivering IPv6 over > Master-Slave/Token Passing (MS/TP), which is a MAC protocol commonly used > in building automation networks. It includes the frame format for > transmitting IPv6 packets, as well as the method for forming link-local > and statelessly auto-configured IPv6 addresses. > > I was not familiar with the work prior to reading it, but found the text > to be well-written and easy to read, with it following a similar structur= e > to other IETF IPv6-over-foo documents. > > Some specific points of note regards MS/TP are that it has 8-bit MAC > addresses, it has no multicast (so multicast packets are sent to the 8-bi= t > broadcast destination address (255), it can support MTUs of 1280-1500 (an= d > above), and, as a wired protocol, it runs at around 115Kbit/s up to 1000m= . > > Comments: > > The introduction says that the =E2=80=9Cgeneral approach is to adapt elem= ents of > the 6LoWPAN specifications, RFC4944, RFC6282 and RFC6775=E2=80=9D. This = is > understandable given the constrained nature of nodes in building automati= on > scenarios. There are however places in the document where it=E2=80=99s no= t clear > where specifically these specifications are being drawn upon and are to b= e > used. Some more explicit pointers might be helpful. An example of this > lies in Section 8, which says unicast address mapping follows Section 7.2 > of RFC4861, but one might expect RFC6775 (on ND optimisation) to be used, > e.g. wrt solicited node multicast. > > This seems like a two-parter. Are you saying there are sections of the I-D that are adapted from the 6LoWPAN RFCs but aren't referenced? If so, what sections need fixing? Or are you saying you feel that some parts of the RFCs SHOULD be incorporated into this I-D, but aren't? If so, what text needs to changed? Re: RFC 6775, it appears to be mainly targeted at networks that don't have a multicast capability, which doesn't apply to 6LoBAC. The draft does call out use of ARO in section 6. > Section 2 has some =E2=80=9Cmusts=E2=80=9D that might be MUSTs, given RFC= 2119 language is > defined in Section 1.1. > > OK. > In Section 3 it says that all multicast packets SHOULD be broadcast at th= e > MAC layer. Why is this a SHOULD, and not a MUST? One would assume > unicasting multicast messages would be expensive in this type of > constrained network and given the token passing mechanism where the token > is passed after sending so many packets. > > This was also called out by Brian Haberman. This used to be a MUST, but was changed to a SHOULD after comments from two WG reviewers. For the record, I agree with you but I think we need to revisit the topic in the WG to make sure there's a rough consensus. > The introduction says header compression support as per RFC6282 is > REQUIRED, but Section 5 does not explicitly say that the compression > mechanism described there MUST be implemented. I=E2=80=99d suggest rewrit= ing the > first sentence of Section 5 to say something like =E2=80=9CDue to the rel= atively > low data rates of MS/TP, the header compression mechanism described in th= is > section MUST be implemented on all nodes.=E2=80=9D > > It used to be that both compressed and uncompressed headers were supported. I understand you're asking for an additional MUST and I'll figure out a way to word it. Section 5 defines the adaptation header. Is it clear that this MUST be implemented by all 6LoBAC nodes? The only header type defined is for LOWPAN_IPHC (whic= h is described in section 10). Can one not draw the inference that IPHC is required on all nodes? > Perhaps before Section 6, or at the start of it, there should be text > stating which addresses are formed, and which multicast groups are joined= . > Further, perhaps we can draw on draft-ietf-6man-default-iids-13, which is > now very close to publication, and refer to the recommendations in Sectio= n > 3 there, e.g. that RFC7217 SHOULD be used, and that you SHOULD NOT embed > a stable link-layer address in the IID. > > I do not want to be over-proscriptive. This I-D attempts to draw attention to cases where privacy addresses should be used. draft-ietf-6man-default-iids has thus far NOT been applied to 6lo specifications, and I don't want to set the precedent. In particular, that I-D currently reads: In some network technologies and adaptation layers, the use of an IID based on a link-layer address may offer some advantages. For example, the IP-over-IEEE802.15.4 standard in [RFC6775 ] allows for compression of IPv6 addresses when the IID is based on the underlying link-layer address. It seems the text is saying that RFC7217 is not to be used for link-local > IIDs; rather the text suggests using a SLAAC-style address (with the last= 8 > bits being the MAC address) to allow for efficient header compression. > Perhaps some explicit text here would help (i.e. SHOULD use RFC7217 for > global scope addresses, but RECOMMENDED that you use the SLAAC-a-like > mechanism for link-local addresses for header compression efficiency). > > Section 6 seems to be clear that it's recommending (but not mandating) link-local addresses based on MAC ID. By the same token, it recommends privacy IIDs for globally scoped addresses. (Brian H. asked for s/forwardable/globally scoped) > The text RECOMMENDING use of a privacy IID does not mention RFC4941, > presumably because RFC4941 targets IIDs with embedded IEEE MAC addresses, > but the principle for generating the privacy address is the same. As it > stands, the text does not define how a 64-bit privacy address is generate= d > (I think we assume it=E2=80=99s as per RFC4941, but be specific?). > > Section 6 says: A 64-bit privacy IID is RECOMMENDED for each globally scoped address and SHOULD be locally generated according to one of the methods cited in Section 12. Section 12 calls out RFCs 3315, 3972, 4941, 5535, and 7217. > One assumes RFC6724-based address selection is followed, in which case > privacy addresses would be preferred over public addresses, and thus for > all communications initiated by the device, it would be using > non-compression friendly addresses. Is this a concern? Or might you > explicitly say here only use privacy addresses for global scope prefixes, > again for efficiency. > > I think this has been answered. > Section 8 should clarify which elements of RFC6775 are used. As it=E2=80= =99s > written, I assume none, but that=E2=80=99s at odds with the introduction = text. > > I think this has been answered. > Section 12 (like Section 6, now I notice it) refers to =E2=80=9Cforwardab= le > addresses=E2=80=9D. Do you mean global scope addresses (which would inclu= de ULAs, > if used)? If so, I=E2=80=99d suggest using that terminology. > > As I said, Brian has already requested s/forwardable/globally scoped. When I wrote this, I was trying to use the RFC 6890 terminology, in which "forwardable" includes ULAs. > Scanning attacks where embedded 8-bit MAC addresses are used for the last > 8-bits would be quite trivial. I think the text here that basically says > =E2=80=9Cyou SHOULD use RFC7217" (for local scope addresses) should be em= phasised > in Section 6; it doesn=E2=80=99t need to be here, or if it is mentioned, = refer to > Section 6. I=E2=80=99m not sure of the relevance of DHCPv6 here(?), whil= e CGAs and > hash-based addresses are not (I believe) in common use. > > Scanning attacks are mitigated by the use of privacy IIDs for globally scoped addresses RECOMMENDED in section 6. The rationale is given in the first sentence of section 12. I don't see anything magic about RFC 7217; any method that can give a good approximation of a random 64-bit number is sufficient. My preference for 6lo networks would be to offload this to a service (e.g. DHCPv6) that could hand out random IIDs. > Are such wired networks not liable to casual snopping? What happens if I > unplug a device and plug my own in, using a master node MAC? Presumably t= he > MS/TP protocol defines mechanisms for protection against such attacks, th= at > you could cite? > > I've heard many voice concerns about being tracked through airports or in coffee shops by proximate attackers snooping on wireless links. I think it is a step beyond "casual" to get up into the ceiling tiles and install a promiscuous listener on a wired link. The mitigation for this is out of scope for an IP-over- foo specification, right? > You might add in Section 12 that ULAs may be appropriate for building > management systems where the communications are all intra-site. If > external communications are needed, an additional ISP-based prefix could = be > used. Though I appreciate ULAs can be a contentious subject, so if you wa= nt > to publish quickly you might choose to not say anything on the subject (b= ut > it will come up=E2=80=A6 :) > I guess I don't feel that an IP-over-foo spec should be a compleat treatise on how to correctly deploy IPv6, but others may disagree ;-) Regards, Kerry > > Tim > > > > --94eb2c09c7e81ab2c3053c6b11b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

Thanks very much for the review= ; sorry for the delayed response.
Comments inline...

On Thu, Aug 18, 2016 at = 10:57 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi,

I am an assigned INT dir= ectorate reviewer for this draft. These comments were written primarily for= the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comme= nts from any other IETF contributors and resolve them along with any other = Last Call comments that have been received. For more details of the INT dir= ectorate, see <http://www.ietf.org/iesg/directorate.html<= /a>>.
<= br>
Summary
<= br>
This document defines th= e mechanisms for delivering IPv6 over Master-Slave/Token Passing (MS/TP), w= hich is a MAC protocol commonly used in building automation networks. It includes the frame format for transmitting IPv6 packets,=C2= =A0 as well as the method for forming link-local and statelessly auto-confi= gured IPv6 addresses.
<= br>
I was not familiar with = the work prior to reading it, but found the text to be well-written and eas= y to read, with it following a similar structure to other IETF IPv6-over-foo documents.
<= br>
Some specific points of = note regards MS/TP are that it has 8-bit MAC addresses, it has no multicast= (so multicast packets are sent to the 8-bit broadcast destination address (255), it can support MTUs of 1280-1500 (and above), and, as a wir= ed protocol, it runs at around 115Kbit/s up to 1000m.
<= br>
Comments:
<= br>
The introduction says th= at the =E2=80=9Cgeneral approach is to adapt elements of the 6LoWPAN specif= ications, RFC4944, RFC6282 and RFC6775=E2=80=9D.=C2=A0 This is understandab= le given the constrained nature of nodes in building automation scenarios. There ar= e however places in the document where it=E2=80=99s not clear where specifi= cally these specifications are being drawn upon and are to be used. Some mo= re explicit pointers might be helpful. =C2=A0An example of this lies in Section 8, which says unicast address mapping foll= ows Section 7.2 of RFC4861, but one might expect RFC6775 (on ND optimisatio= n) to be used, e.g. wrt solicited node multicast.
<= br>


Re: RFC 6775, it appears to be mainly targeted at networks that don&#= 39;t have a multicast
capability, which doesn't apply to 6LoB= AC.=C2=A0 The draft does call out use of ARO in section 6.
=C2=A0=
Section 2 has some =E2= =80=9Cmusts=E2=80=9D that might be MUSTs, given RFC2119 language is defined= in Section 1.1.
<= br>
OK.=C2=A0
In Section 3 it says tha= t all multicast packets SHOULD be broadcast at the MAC layer.=C2=A0Why is t= his a SHOULD, and not a MUST? One would assume unicasting multicast messages would be expensive in this type of constrained network and given = the token passing mechanism where the token is passed after sending so many= packets.
<= br>
This was also called out by Brian Ha= berman.=C2=A0 This used to be a MUST, but was changed
to a SHOULD= after comments from two WG reviewers.=C2=A0 For the record, I agree with y= ou
but I think we need to revisit the topic in the WG to make sur= e there's a rough consensus.
The introducti= on says header compression support as per RFC6282 is REQUIRED, but Section = 5 does not explicitly say that the compression mechanism described there MU= ST be implemented. I=E2=80=99d suggest rewriting the first sentence of Section 5 to say somet= hing like =E2=80=9CDue to the relatively low data rates of MS/TP, the heade= r compression mechanism described in this section MUST be implemented on al= l nodes.=E2=80=9D=C2=A0
<= br>
It used to be that both compressed a= nd uncompressed headers were supported. I
understand you're a= sking for an additional MUST and I'll figure out a way to word it.
Section 5 defines the adaptation header.=C2=A0 Is it clear that this = MUST be implemented
by all 6LoBAC nodes?=C2=A0 The only header ty= pe defined is for LOWPAN_IPHC (which
is described in section 10).= =C2=A0 Can one not draw the inference that IPHC is required on
al= l nodes?
Perhaps before Section 6= , or at the start of it, there should be text stating which addresses are f= ormed, and which multicast groups are joined. Further, perhaps we can draw on draft-ietf-6man-default-iids-13, which is now v= ery close to publication, and refer to the recommendations in Section 3 the= re, e.g. that RFC7217 SHOULD be used, and that you SHOULD NOT embed a stable link-layer address in the IID.= =C2=A0

=C2=A0I do not want to be over-proscriptive.=C2= =A0 This I-D attempts to draw attention to cases
where privacy ad= dresses should be used. =C2=A0draft-ietf-6man-default-iids has thus far
NOT been applied to 6lo specifications, and I don't want to set = the precedent.=C2=A0 In
particular, that I-D currently reads:


A 64-bit privacy IID is RECOMMENDED for each globally =
scoped address
and SHOULD be locally generated according to one of the methods cited
= 
in Section 12.

S= ection 12 calls out RFCs 3315, 3972, 4941, 5535, and 7217.
=
One assumes RFC6724-based addr= ess selection is followed, in which case privacy addresses would be preferr= ed over public addresses, and thus for all communications initiated by the = device, it would be using non-compression friendly addresses. Is this a concern?=C2=A0 Or might you = explicitly say here only use privacy addresses for global scope prefixes, a= gain for efficiency.
<= br>
I think this has been answered.=C2= =A0
Section 8 should clarify= which elements of RFC6775 are used. As it=E2=80=99s written, I assume none= , but that=E2=80=99s at odds with the introduction text.
<= br>
I think this has been answered.=C2= =A0
Section 12 (like Section= 6, now I notice it) refers to =E2=80=9Cforwardable addresses=E2=80=9D. Do = you mean global scope addresses (which would include ULAs, if used)? If so, I=E2=80=99d suggest using that terminology.
<= br>
As I said, Brian has already request= ed s/forwardable/globally scoped.
When I wrote this, I was trying= to use the RFC 6890 terminology, in
which "forwardable"= ; includes ULAs.=C2=A0
Scanning attacks where e= mbedded 8-bit MAC addresses are used for the last 8-bits would be quite tri= vial.=C2=A0 I think the text here that basically says =E2=80=9Cyou SHOULD use RFC7217" (for local scope addresses) should be emphasised in Sect= ion 6; it doesn=E2=80=99t need to be here, or if it is mentioned, refer to = Section 6.=C2=A0 I=E2=80=99m not sure of the relevance of DHCPv6 here(?), w= hile CGAs and hash-based addresses are not (I believe) in common use.=C2=A0
<= br>
Scanning attacks are mitigated by th= e use of privacy IIDs for globally scoped
addresses RECOMMENDED i= n section 6.=C2=A0 The rationale is given in the first
sentence o= f section 12.=C2=A0 I don't see anything magic about RFC 7217; any
method that can give a good approximation of a random 64-bit number i= s
sufficient.=C2=A0 My preference for 6lo networks would be to of= fload this to a service
(e.g. DHCPv6) that could hand out random = IIDs.
Are such wired networks = not liable to casual snopping? What happens if I unplug a device and plug m= y own in, using a master node MAC? Presumably the MS/TP protocol defines mechanisms for protection against such attacks, that you could cit= e?
<= br>
I've heard many voice concerns a= bout being tracked through airports or in
coffee shops by proxima= te attackers snooping on wireless links.=C2=A0 I think it is a
st= ep beyond "casual" to get up into the ceiling tiles and install a= promiscuous
listener on a wired link.=C2=A0 The mitigation for t= his is out of scope for an IP-over-
foo specification, right?
You might add in Section= 12 that ULAs may be appropriate for building management systems where the = communications are all intra-site.=C2=A0 If external communications are needed, an additional ISP-based prefix could be used. Though I appreci= ate ULAs can be a contentious subject, so if you want to publish quickly yo= u might choose to not say anything on the subject (but it will come up=E2= =80=A6 :)

I guess = I don't feel that an IP-over-foo spec should be a compleat treatise on<= /div>
how to correctly deploy IPv6, but others may disagree ;-)

Regards, Kerry=C2=A0
<= br>
Tim
<= br>
<= br>


--94eb2c09c7e81ab2c3053c6b11b2-- From nobody Thu Sep 22 09:46:44 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1930312D925; Thu, 22 Sep 2016 09:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 AzipcSNx1C_K; Thu, 22 Sep 2016 09:46:41 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 2021812DA84; Thu, 22 Sep 2016 09:43:46 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id d69so55953066ybf.2; Thu, 22 Sep 2016 09:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=cIUqtoR8RHltZ1YNbP8qRZPCKAIF5JseBKmoXEnI9hk=; b=k/tv4sJ+LzQHGpQ00crjAZ428RD1SWq2HMChC5xGvFYBQc8/u8kn1rlJWSm7hyc+cZ N26bGKRQPr5LmXLRDZtEh/1PCiyt/g41sxHI180GHJgEf0fXgCtQV8iFuOrOBUr9v5KA f5ZVB6CrcDKcdYiQbenrcIgZUZ8pHbkkQQaZjg8+xTrlcflz38Ze17pyzLlXgQdhAwi5 vZpkE5Miv0OUwfAfNFF22sMILarQCs7AQLKWUoNdZIHcwSDPXaTgd7YMvkaIIMmo+voY tmGCe+MdO6PVfdjLgSbeAKtUm6//LSpG9M/WTAyjHFipsU6fWfRSFi4dzqPrKqv7L+Y+ 5Yvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cIUqtoR8RHltZ1YNbP8qRZPCKAIF5JseBKmoXEnI9hk=; b=I8kjBdOBYGR380N4Rl48sx678NIW/r4mUsdJFf1lGcSTkiRVnJfwTLbjVD3djC+15f W/L1WGuGUMdjM97A0zaOnxEXedwwNfENnNPuiv6t9/2qcW73sO02IVUvlZBF7SQw73ZR msmnZOJFk/v93PfMXQkZcZ4HMDZhpTzPSj1B7h6w24GQvOhPTK0v13VLtTQjko2lhx1F Q5ZbWa/QoEtJqLBWRxwqsduTHXUUUvW57CLTr2DtdfWTtgSBcGBQNYCkYFidwSDt7oiq ZUJhlmWEwMtiGHU+XQobYtYMnsxy8rLK+WQ/GQ7Ow4R+p+soYYucTFiKWQtWDJIpYNa2 HABg== X-Gm-Message-State: AE9vXwNqzW1tyHj/N5RKFG/uW521g8ObQ0+9wTCDpCfLBL7SbTTmCtoeIYvYLr49DSFK5B3ghZXxzdq34iOFcg== X-Received: by 10.37.173.165 with SMTP id z37mr2298293ybi.88.1474562625332; Thu, 22 Sep 2016 09:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.95.67 with HTTP; Thu, 22 Sep 2016 09:43:44 -0700 (PDT) From: jouni korhonen Date: Thu, 22 Sep 2016 09:43:44 -0700 Message-ID: To: "" , "int-ads@tools.ietf.org" , draft-ietf-6lo-privacy-considerations.all@ietf.org Content-Type: multipart/alternative; boundary=f403045dc3027b7477053d1b5d1c Archived-At: Subject: [Int-dir] Int-Dir review of draft-ietf-6lo-privacy-considerations-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 16:46:43 -0000 --f403045dc3027b7477053d1b5d1c Content-Type: text/plain; charset=UTF-8 I am an assigned INT directorate reviewer for draft-ietf-6lo-privacy- considerations-03 . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. Document: draft-ietf-6lo-privacy-considerations-03 Reviewer: Jouni Korhonen Review Date: 9/22/2016 IETF LC End Date: IESG Telechat date: (if known) Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: 1) Page 4 first paragraph states it takes a year to scan 26 bit of id space. Even if the math is given in the next paragraph it is not clear what are the assumptions to number of devices per link. I take it is one device on that link. 2) Page 5 table has "6 or ???" for NFC.. it would be good to either replace "???" with something meaningful or explain why "???". Regards, Jouni --f403045dc3027b7477053d1b5d1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am an assigned INT directorate reviewer fo= r draft-ietf-6lo-privacy-co= nsiderations-03. These comments were written primarily for the benefit = of the Internet Area Directors. Document editors and shepherd(s) should tre= at these comments just like they would treat comments from any other IETF c= ontributors and resolve them along with any other Last Call comments that h= ave been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directo= rate.html.

Document: draft-ietf-6lo-privacy-considerations-03 Reviewer: Jouni Korhonen
Review Date: 9/22/2016
IETF LC End Date:
IESG Telechat date: (if known)

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:

1) Page 4 first paragra= ph states it takes a year to scan 26 bit of id space. Even if the math is g= iven in the next paragraph it is not clear what are the assumptions to numb= er of devices per link. I take it is one device on that link.

=
2) Page 5 table has "6 or ???" for NFC.. it would b= e good to either replace "???" with something meaningful or expla= in why "???".

Regards,
=C2=A0Jouni

--f403045dc3027b7477053d1b5d1c-- From nobody Mon Sep 26 09:34:31 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1012B226; Mon, 26 Sep 2016 09:34:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 EjRKDqXY5xIo; Mon, 26 Sep 2016 09:34:28 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 C6E4012B320; Mon, 26 Sep 2016 09:34:27 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id l91so83281128qte.3; Mon, 26 Sep 2016 09:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=jEQBAdlgAh/7Hs4uhH78z8r7o3/UpNCxoUhQ17/HtDU=; b=CQ35M58iirm9iQuG3KE7T2PBYBetNEkgNC3NPiYp/nh4mR86LV1g3KNv0gzHRaK3iv sAfSU485SEeHTWLSQK0oWtCaEpKfuX/aeH6K4qmVtJtW8bQmVWL20+O6qcXWyRFdOq96 zvJRqP2LqfUzmrxrqVDtc3gyV5HAf56Ltwd0HEB5WnBDeTkX4elweTbZfaxzb6UlbTjT 4VJNzw6NElx+iZR/Z65yEIe/EboxhF5RWhK07NufY8MZJXGHj+xSOlKBqEN0zreE7COn 4zEgWJFz3u9nGCrXVZI1jjyPysS4XZJRSPSwQ3QL7ZmF3aJLrYNK4tlkmkuaWTTCBwwa uJQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=jEQBAdlgAh/7Hs4uhH78z8r7o3/UpNCxoUhQ17/HtDU=; b=MbWZfNOru2hdCfm2VE/cUvtXa59JbgsbKLtiZPaDnPEtLhGMGYmz/u/yOcZu+D4Muv hS+NC1rQdUBm47bX6lgeIPDS7QXyOLs6OzetNhRM1rnq+FkpdOTk9ORa0EWv6sR22T/R T1FAa4bwJfUeHoPXDPnYwiPxWTjEWPTY5/fKnd7xhFUSH1n+UrpZpRGyT42fEHRANXNw FxFRrY1GR1p+L8nprFObAYP1vDaYRvX9+2cd/qV731yfaQx6zDcI1a5mDfcQsfGzuQvn NNcoFSFZWfUHU6AX7wV6EwMrh3aQcH4LPxr6kSMFz4Xt8LqUGidgVQAw6zyPAuzUvs3+ NP/Q== X-Gm-Message-State: AA6/9Rl1v6IZ6HlMo7e5sVI/Kn5PgOelCGZrUFe562+7iONC7boH0Bd7D8mJSsFqFS+n9YN0qpypUsz4i7wS0w== X-Received: by 10.200.47.165 with SMTP id l34mr22521719qta.78.1474907666820; Mon, 26 Sep 2016 09:34:26 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.54.227 with HTTP; Mon, 26 Sep 2016 09:34:26 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 26 Sep 2016 09:34:26 -0700 X-Google-Sender-Auth: 0blnDIRdPGmvDCd3NQoubxWPlaM Message-ID: To: "" , int-ads@tools.ietf.org, draft-ietf-6lo-privacy-considerations.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Int-dir] INT-DIR review of draft-ietf-6lo-privacy-considerations-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:34:29 -0000 I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. This document is very well written and looks useful. I didn't find any obvious technical issues that may block publication. One possible point that my warrant a discussion is that this document doesn't seem to be very specific to resource constrained nodes (as the title and abstract suggests). I don't see anything tightly specific to such nodes except for some parts of Section 3. Even in Section 3 most of the discussions seem generic. I wonder whether such general privacy issues regarding IPv6 addresses are already covered by some existing documents. If so, this document could be much shorter by just referring to such documents and focusing on a few points specific to 6lo nodes. If not, we might rather consider publishing it as such a generic document. -- JINMEI, Tatuya From nobody Wed Sep 28 00:02:47 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1512B139 for ; Wed, 28 Sep 2016 00:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 H4Eq4jniAFuR for ; Wed, 28 Sep 2016 00:02:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3BB12B337 for ; Wed, 28 Sep 2016 00:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59847; q=dns/txt; s=iport; t=1475046161; x=1476255761; h=from:to:subject:date:message-id:references:mime-version; bh=ReCLHWH6SeufWArNR0LXkUWe4/LA7INfMtVicPV+Oqo=; b=Bpk7WDQE2BE91Oy1MVs6nZwuRtqN9Vg9iKUnKqUu/rtiKXktsSwL9wxx suhX8GATTO+yDloIttPmLPChG64Sl87I1KITCxV0IhbhRo236+hpgpH8s 249tKlSC+ZzhX/Ux8S0EtLl6d0O2CU+S750sn5nvdAikMX5ubQ797sOKh Y=; X-Files: ATT00001.txt : 124 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAQAIautX/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgwk2AQEBAQEeV3wHjSurG4IDAxkBCoV6AhyBPzgUAQIBAQEBAQE?= =?us-ascii?q?BXieEYQEBAQQBAQEXCQpBFwQCAQgRAwEBASEBBgMCAgIlCxQHAQEFAwIEARIIA?= =?us-ascii?q?QULiDQOsT6NBwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OhjeEVIE8glQGCwYBAiE?= =?us-ascii?q?HCQkMDIJMgloFlB6FWAGDQIF2cIJARIY5gXWEZIkajGyDfAEeNoMcARyBUHIBh?= =?us-ascii?q?FkOF4EJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,409,1470700800"; d="txt'?scan'208,217";a="157456728" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2016 07:02:40 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u8S72eI7008966 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Sep 2016 07:02:40 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Sep 2016 02:02:39 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 28 Sep 2016 02:02:39 -0500 From: "Pascal Thubert (pthubert)" To: "Bernie Volz (volz)" , "int-dir@ietf.org" Thread-Topic: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05 Thread-Index: AQHSEAfZ6dyMyYANN0GuFTSPcNU9/KCNH1vggAFrjVA= Date: Wed, 28 Sep 2016 07:02:37 +0000 Deferred-Delivery: Wed, 28 Sep 2016 07:01:43 +0000 Message-ID: <3514062807f14b6893377b38a5b510ca@XCH-RCD-001.cisco.com> References: <1474022898.8740.28.camel@it.uc3m.es> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.27] Content-Type: multipart/mixed; boundary="_002_3514062807f14b6893377b38a5b510caXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Int-dir] FW: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 07:02:46 -0000 --_002_3514062807f14b6893377b38a5b510caXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBCZXJuaWUgYW5kIGFsbDoNCg0KUGxlYXNlIG5vdGUgdGhhdCBJIHBvc3RlZCB0aGUgYXR0 YWNoZWQgcmV2aWV3IHBlciB0aGUgaW50IGFyZWEgYXNzaWdubWVudC4NCg0KVGFrZSBjYXJlLA0K DQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkgDQpTZW50OiBtYXJkaSAyNyBzZXB0ZW1icmUgMjAxNiAxMToxNw0KVG86 ICdjamJjQGl0LnVjM20uZXMnIDxjamJjQGl0LnVjM20uZXM+OyBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4NCkNjOiBCZXJuaWUgVm9seiAodm9seikgPHZv bHpAY2lzY28uY29tPjsgVGVycnkgTWFuZGVyc29uIDx0ZXJyeS5tYW5kZXJzb25AaWNhbm4ub3Jn PjsgU3VyZXNoIEtyaXNobmFuIDxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPg0KU3ViamVj dDogUkU6IEludCBBcmVhIERpcmVjdG9yYXRlIFJldmlldyBBc3NpZ25tZW50IC0gZHJhZnQtaWV0 Zi02bG8tZGVjdC11bGUtMDUNCg0KSSBwb3N0ZWQgbXkgcmV2aWV3IHRvIHRoZSA2bG8gbGlzdCBh bmQgdGhlIGRyYWZ0IGF1dGhvcnMsIENhcmxvcy4NCg0KUGxlYXNlIGZpbmQgaXQgYXR0YWNoZWQg Zm9yIHlvdXIgY29udmVuaWVuY2U7IA0KDQpUYWtlIGNhcmU7DQoNClBhc2NhbA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyBb bWFpbHRvOmNqYmNAaXQudWMzbS5lc10gDQpTZW50OiB2ZW5kcmVkaSAxNiBzZXB0ZW1icmUgMjAx NiAxMjo0OA0KVG86IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28u Y29tPjsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0KQ2M6 IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+OyBUZXJyeSBNYW5kZXJzb24gPHRl cnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmc+OyBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5h bkBlcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBJbnQgQXJlYSBEaXJlY3RvcmF0ZSBSZXZpZXcgQXNz aWdubWVudCAtIGRyYWZ0LWlldGYtNmxvLWRlY3QtdWxlLTA1DQoNCkhpIENhcmxvcyBhbmQgUGFz Y2FsOg0KDQpZb3UgYXJlIG5leHQgdXAgb24gdGhlIEludCBBcmVhIERpcmVjdG9yYXRlIHJldmll dyBhc3NpZ25tZW50IHF1ZXVlIGFuZCB0aGUgSW50IEFEcyBoYXZlIHJlcXVlc3RlZCBhIHJldmll dyBvZiBkcmFmdC1pZXRmLTZsby1kZWN0LXVsZS0wNcKgKHNlZSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi02bG8tZGVjdC11bGUtMDUpLiBQbGVhc2Ugbm90ZSB0aGUgcmVx dWVzdCBiZWxvdywgYnV0IGFnYWluLCB5b3UgYXJlIG9ubHkgYmVpbmcgYXNrZWQgdG8gcmV2aWV3 IE9ORSBvZiB0aGVzZSBkb2N1bWVudHMuDQoNClBsZWFzZSByZXNwb25zZSB0byB0aGlzIGVtYWls IGFzIHNvb24gYXMgcG9zc2libGUgKGFuZCB3aXRoaW4gNzIgaG91cnMpIHRvIGluZGljYXRlIHdo ZXRoZXIgeW91IENBTiBvciBDQU5OT1QgcmV2aWV3IHRoaXMgZG9jdW1lbnQuIFBsZWFzZSBhc3N1 bWUgdGhhdCB0aGUgcmV2aWV3IG5lZWRzIHRvIGJlIGNvbXBsZXRlZCB3aXRoaW4gMiB3ZWVrcyAo YnkgU2VwdGVtYmVyIDMwdGgpLg0KDQpGb3IgbW9yZSBkZXRhaWxzLCBzZWUgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9pbnRhcmVhLmh0bQ0KbC4NCg0KVGhhbmtzIG11Y2gg aW4gYWR2YW5jZSENCg0KLSBDYXJsb3MgKCYgQmVybmllKQ0K --_002_3514062807f14b6893377b38a5b510caXCHRCD001ciscocom_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 28 Sep 2016 07:02:34 GMT"; modification-date="Wed, 28 Sep 2016 07:02:34 GMT" Received: from xch-rcd-005.cisco.com (173.37.102.15) by xch-rcd-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Mailbox Transport; Tue, 27 Sep 2016 04:14:37 -0500 Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Sep 2016 04:14:36 -0500 Received: from alln-iport-1.cisco.com (173.37.142.88) by mail.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 27 Sep 2016 04:14:36 -0500 Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2016 09:14:36 +0000 Received: from alln-inbound-i.cisco.com (alln-inbound-i.cisco.com [173.37.147.239]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8R9EWI7017051 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Tue, 27 Sep 2016 09:14:36 GMT Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-i.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2016 09:14:31 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B13012B0A0; Tue, 27 Sep 2016 02:14:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2B12B09D for <6lo@ietfa.amsl.com>; Tue, 27 Sep 2016 02:14:28 -0700 (PDT) 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 wBcINqNkndhb for <6lo@ietfa.amsl.com>; Tue, 27 Sep 2016 02:14:23 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9268312B018 for <6lo@ietf.org>; Tue, 27 Sep 2016 02:14:23 -0700 (PDT) Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2016 09:14:21 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u8R9ELEW016030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Sep 2016 09:14:21 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Sep 2016 04:14:21 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 27 Sep 2016 04:14:21 -0500 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-dect-ule@tools.ietf.org" Subject: [6lo] INT-DIR review of draft-ietf-6lo-dect-ule-05 Thread-Topic: INT-DIR review of draft-ietf-6lo-dect-ule-05 Thread-Index: AdIYn0f9Bf46FmbqQ3GCrgJJ/R304w== Sender: 6lo <6lo-bounces@ietf.org> Date: Tue, 27 Sep 2016 09:13:53 +0000 Deferred-Delivery: Tue, 27 Sep 2016 09:13:43 +0000 Message-ID: <26b8f5639f5743d4bbed33d32e36f07b@XCH-RCD-001.cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: XCH-ALN-001.cisco.com X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49349; q=dns/txt; s=iport; t=1474967663; x=1476177263; h=from:to:subject:date:message-id:mime-version; bh=FTvB1H9iX3TWuyH1kO2eXXayn1F62YGF1GymURYHoCU=; b=c7hhdaXtbHw1NyHls4llKp4tdWaLCiTzB7tmMPDxpn3O+vOddaiA5VTW MJ1y7hGJnqLRH31taceIUH1rz1ttM36946D+wIXKBaCzpB5FwLsz/PEHF q3+Sh0HfDoATcJHVmxgcEo4XSaXCVAEsbp3MOXSJhjrIFoUJtrl0Dd2Vk A=; x-ironport-av: E=Sophos;i="5.30,404,1470700800"; d="scan'208,217";a="326723024" x-originating-ip: [10.55.22.5] list-post: delivered-to: 6lo@ietfa.amsl.com list-archive: x-beenthere: 6lo@ietf.org x-ironport-anti-spam-filtered: true x-from-outside-cisco: 4.31.198.44 authentication-results: alln-inbound-i.cisco.com; spf=Pass smtp.mailfrom=6lo-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org; dkim=hardfail (body hash did not verify [final]) header.i=@cisco.com; dmarc=fail (p=none dis=none) d=cisco.com x-virus-scanned: amavisd-new at amsl.com x-ironport-anti-spam-result: A0CrAQBGN+pX/5JdJa1dGgEBAQECAQEBAQgBAQEBgwk2AQEBAQEeV3wHjSyrToIGJIV6gWQ4FAECAQEBAQEBAV4nhGgaE14BHCQBPyYBBAEaARCINA7AAAEBAQEBAQQBAQEBAQEBAR+GN4YQglQRCSEHEgwMghSDEgWUHoVYAYhmRIY4j3OMa4N8AR42gxkBHIFQcgGEKYEufwEBAQ x-mailman-version: 2.1.17 x-spam-score: -16.836 x-spam-status: No, score=-16.836 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no x-spam-flag: NO x-spam-level: x-original-to: 6lo@ietfa.amsl.com errors-to: 6lo-bounces@ietf.org list-id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> received-spf: None (alln-inbound-i.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-i.cisco.com; envelope-from="6lo-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Content-Type: multipart/mixed; boundary="_004_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_" MIME-Version: 1.0 --_004_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_ Content-Type: multipart/alternative; boundary="_000_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_" --_000_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all : I am an assigned INT directorate reviewer for draft-ietf-6lo-dect-ule-05. T= hese comments were written primarily for the benefit of the Internet Area D= irectors. Document editors and shepherd(s) should treat these comments just= like they would treat comments from any other IETF contributors and resolv= e them along with any other Last Call comments that have been received. For= more details on the INT Directorate, see http://www.ietf.org/iesg/director= ate.html. Document: draft-ietf-6lo-dect-ule Transmission of IPv6 Packets over DECT Ultra Low Energy Reviewer: Pascal Thubert Review Date: Sept 27, 2016 IETF Last Call Date: TBD Summary: Issues concerning the subnet model that needs to be explicited. Major issues: - Reference to draft-ietf-6lo-privacy-considerations and privacy of address= es should be addressed (related to lifespan of IEEE EUI48 addresses, random= but permanent is still not too good) - Subnet model (Section 3.3) should be described in more details, indicatin= g NBMA Multi-Link SubNet (MLSN). Suggestion to review/emulate RFC 7668 (sec= tion 3.2.1 and last paragraph of 3.2.2) - Reference to draft-ietf-6lo-backbone-router could be made to address the = L3 perspective of node mobility - Some IMPERATIVE is extraneous. (RFC2119: "Imperatives of the type defined= in this memo must be used with care and sparingly. In particular, they MU= ST only be used where it is actually required for interoperation or to limi= t behavior which has potential for causing harm") Minor issues: - inline on the right of the original text, with a "<<" prefix --- 6Lo Working Group P. Mariager Internet-Draft J. Petersen, Ed. Intended status: Standards Track RTX A/S Expires: November 17, 2016 Z. Shelby ARM M. Van de Logt Gigaset Communications GmbH D. Barthel Orange Labs May 16, 2016 Transmission of IPv6 Packets over DECT Ultra Low Energy < snip> 1. Introduction DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface <= << spell DECT on first use technology building on the key fundamentals of traditional DECT / CAT-iq but with specific changes to significantly reduce the power consumption at the expense of data throughput. DECT (Digital <= << DECT spelling Enhanced Cordless Telecommunications) is a standard series [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced Technology - internet and quality) is a set of product certication and interoperability profiles [CAT-iq] defined by DECT Forum. DECT < snip> In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single FP defining the network with a number of PP attached. The MAC layer supports both traditional DECT as this is = << "both" is unclear, can you rephrase? used for services like discovery, pairing, security features etc. All these features have been reused from DECT. < snip> [DECT ULE PP]-----\ /-----[DECT ULE PP] \ / [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] / \ [DECT ULE PP]-----/ \-----[DECT ULE PP] Figure 2: DECT ULE star topology <= < suggestion to place a forward reference to section 3.3 on how IP uses th= at (MLSN) A significant difference between IEEE 802.15.4 and DECT ULE is that the former supports both star and mesh topology (and requires a routing protocol), whereas DECT ULE in it's primary configuration does not support the formation of multihop networks at the link layer. In consequence, the mesh header defined in [RFC4944] for mesh < snip> When bound to a FP, a PP is assigned a 20 bit TPUI which is unique = << in reference to draft-ietf-6lo-privacy-considerations it would be good = to indicate whether this is short lived or long lived, so as to figure if a= n IPv6 address can be derived or not. within the FP. This TPUI is used for addressing (layer 2) in messages between FP and PP. < snip> Optionally each DECT PP and DECT FP can be assigned a unique (IEEE) MAC-48 address additionally to the DECT identities to be used by the = << same as above, it would be good to indicate whether this is short lived= or long lived, so as to figure if an IPv6 address can be derived or not. 6LoWPAN. During the address registration of non-link-local addresses as specified by this document, the FP and PP can use such MAC-48 to construct the IID. < snip> support complete IP packets, the DLC layer of DECT ULE SHALL per this = << there is a MUST later in the document, no need to uppercase here; wheth= er this setting is needed is debatable specification be configured with a MTU size that fits the requirements from IPv6 data packets, hence [RFC4944] fragmentation/ reassembly is not required. = << unclear. .. since DLC supports fragmentation there is no need for 6LoWP= AN fragmentation is there? The adaptation described here only provides valu= e if the DLC fragmentation is armful. Is that the case ? It is expected that the LOWPAN_IPHC packet will fulfil all the requirements for header compression without spending unnecessary overhead for mesh addressing. It is important to realize that the usage of larger packets will be at the expense of battery life, as a large packet inside the DECT ULE stack will be fragmented into several or many MAC layer packets, each consuming power to transmit / receive. = << proof? fragments increase reliability and reduce the size of retried pie= ces. is there a paper showing pros vs cons or is this the author intuition = ? 2.5. Additional Considerations The DECT ULE standard allows PP to be registered (bind) to multiple FP and roaming between these FP. This draft does not consider the = << Why ?? this is where the backbone router becomes handy. If the subnet mo= del is clarified to NBMA / MLSN then it is possible to assign the same pref= ix to multiple 6LBRs and connect them through a 6lo backbone router scenarios of PP roaming between multiple FP. The use of repeater functionality is also not considered in this draft. < snip> 3.1. Protocol Stack In order to enable transmission of IPv6 packets over DECT ULE, a Permanent Virtual Circuit (PVC) has to be opened between FP and PP. This MUST be done by setting up a service call from PP to FP. The PP = << is this MUST coming from this spec or from DECT? if the latter then just= say "this is done by..." SHALL specify the <> in a service-change (other) message before sending a service-change (resume) message as defined in [TS102.939-1]. The <> SHALL define the ULE Application Protocol Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP MUST send a service-change-accept (resume) containing a valid paging descriptor. The PP MUST be pageable. < snip> 3.2. Link Model The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is layer 2. The DECT ULE implements already fragmentation and reassembly functionality, hence [RFC4944] fragmentation and = << this is repeating and sight contradictory. suggestions to keep the text = starting at RFC4944, dropping the beginning of the sentence reassembly function MUST NOT be used. The DECT ULE DLC link (PVC) MUST be configured with a minimum MTU size of at least 1280 octets in = << Not sure this is needed order to meet the size requirements of IPv6. < snip> compression context if any, and from address registration information (see Section 3.2.2). Due to DECT ULE star topology, each branch of the star is considered to be an individual link and thus the PPs cannot directly hear one = << indicate that this is NBMA, multilink subnet. See related text in 6LoWPA= N BTLE RFC 7668 another and cannot talk to one another with link-local addresses. However, the FP acts as a 6LBR for communication between the PPs. After the FP and PPs have connected at the DECT ULE level, the link can be considered up and IPv6 address configuration and transmission can begin. The FP ensures address collisions do not occur. 3.2.1. Stateless Address Autoconfiguration At network interface initialization, both 6LN and 6LBR SHALL generate and assign to the DECT ULE network interface IPv6 link-local addresses [RFC4862] based on the DECT device addresses (see Section 2.3) that were used for establishing the underlying DECT ULE connection. The DECT device addresses IPEI and RFPI MUST be used to derive the = << SHOULD vs. MUST: with a MUST, this means that the 6LoWPAN code does neve= r expect a link local that is not fully elided (3.2.4.1.)? IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR, respectively. < snip> see [RFC7136]. For example from RFPI=3D11.22.33.44.55 the derived IID is 80:11:22:ff:fe:33:44:55 and from IPEI=3D01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89. <= < This seems to be setting permanent addresses (admittedly Link local), and= the privacy properties of such addresses should be addressed, eg addresses= do not (lust not) leak in app layer in any fashion As defined in [RFC4291], the IPv6 link-local address is formed by appending the IID, to the prefix FE80::/64, as shown in Figure 4. < snip> (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque <= < This seems to be setting permanent addresses; discussion on renewing addr= esses would be good, ref to draft-ietf-6lo-privacy-considerations would hel= p, and the security section could just point here as opposed to use IMPERAT= IVE addresses [RFC7217] SHOULD be used by default. In situations where < snip> 2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT <<= the registration has 2 roles, DAD (which can be avoided for globally uniqu= e addresses) and SLLA mapping. This seems to indicate that SLLA is deduced = from the LL so there's special code to avoid using an ND cache? ULE 6LN MUST register its non-link-local addresses with the 6LBR by < snip> accordingly. The NS with the ARO option MUST be sent irrespective of the method used to generate the IID. The 6LN MUST register only one <<= why can't a device form more than one address? IPv6 address per available IPv6 prefix. < snip> the DAM field of the compressed IPv6 header as CID=3D1, DAC=3D1 and DAM=3D01 or DAM=3D11. Note that when a context is defined for the IPv6 = << considering the rest of the optimizations, why don't you have a /128 c= ontext for the 6LBR? destination address, the 6LBR can infer the elided destination prefix by using the context. < snip> 3.3. Subnets and Internet Connectivity Scenarios << Missing scenario= below, same /64, with backbone router 6LN 6LN \ / \ / 6LN --- 6LBR ------ 6LBR --- 6LN / \ / \ 6LN 6LN < snip> --_000_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Dear all :<= /p>

 

I am an assigned INT directorate reviewer for draft-= ietf-6lo-dect-ule-05. These comments were written primarily for the benefit= of the Internet Area Directors. Document editors and shepherd(s) should tr= eat these comments just like they would treat comments from any other IETF contributors and resolve them alo= ng with any other Last Call comments that have been received. For more deta= ils on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.<= o:p>

 

Document: draft-ietf-6lo-dect-ule  <= /p>

Transmission of IPv6 Packets over DECT Ultra Low Ene= rgy

Reviewer: Pascal Thubert

Review Date: Sept 27, 2016

IETF Last Call Date: TBD

 

Summary: Issues concerning the subnet model that nee= ds to be explicited.

 

Major issues:

 

- Reference to draft-ietf-6lo-privacy-considerations= and privacy of addresses should be addressed (related to lifespan of IEEE = EUI48 addresses, random but permanent is still not too good)

- Subnet model (Section 3.3) should be described in = more details, indicating NBMA Multi-Link SubNet (MLSN). Suggestion to revie= w/emulate RFC 7668 (section 3.2.1 and last paragraph of 3.2.2)

- Reference to draft-ietf-6lo-backbone-router could = be made to address the L3 perspective of node mobility

- Some IMPERATIVE is extraneous. (RFC2119: "Imp= eratives of the type defined in this memo must be used with care and sparin= gly.  In particular, they MUST only be used where it is actually requi= red for interoperation or to limit behavior which has potential for causing harm")

 

Minor issues:

 

- inline on the right of the original text, with a &= quot;<<" prefix

 

---

 

 

 

 

 

6Lo Working Group      = ;            &n= bsp;            = ;             P= . Mariager

Internet-Draft      &n= bsp;            = ;            &n= bsp;          J. Petersen, Ed.=

Intended status: Standards Track   &n= bsp;            = ;            &n= bsp;    RTX A/S

Expires: November 17, 2016    &n= bsp;            = ;            &n= bsp;       Z. Shelby

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          ARM

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           M. Van de= Logt

        &nbs= p;            &= nbsp;           &nbs= p;           Gigaset Comm= unications GmbH

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   D. Barthel

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Orange Labs

        &nbs= p;            &= nbsp;            &nb= sp;            =             &nb= sp;May 16, 2016

 

 

        Transmiss= ion of IPv6 Packets over DECT Ultra Low Energy

        &nbs= p;            &= nbsp;         

        &nbs= p;            &= nbsp;         

< snip>

 

 

1.  Introduction

 

   DECT Ultra Low Energy (DECT ULE or just= ULE) is an air interface       <<< = spell DECT on first use

   technology building on the key fundamen= tals of traditional DECT /

   CAT-iq but with specific changes to sig= nificantly reduce the power

   consumption at the expense of data thro= ughput.  DECT (Digital        =   <<<  DECT spelling

   Enhanced Cordless Telecommunications) i= s a standard series

   [EN300.175-part1-7] specified by ETSI a= nd CAT-iq (Cordless Advanced

   Technology - internet and quality) is a= set of product certication

   and interoperability profiles [CAT-iq] = defined by DECT Forum.  DECT

        &nbs= p;            &= nbsp;         

        &nbs= p;            &= nbsp;         

< snip>

 

 

   In its generic network topology, DECT i= s defined as a cellular

   network technology.  However, the = most common configuration is a star

   network with a single FP defining the n= etwork with a number of PP

   attached.  The MAC layer supports = both traditional DECT as this is       &= nbsp;  << "both" is unclear, can you rephrase?

   used for services like discovery, pairi= ng, security features etc.

   All these features have been reused fro= m DECT.

 

        &nbs= p;            &= nbsp;         

        &nbs= p;            &= nbsp;         

< snip>

 

 

 

 

       [DECT ULE PP]--= ---\            = ;     /-----[DECT ULE PP]

        &nbs= p;            &= nbsp;    \        &n= bsp;      /

       [DECT ULE PP]--= -----+[DECT ULE FP]+-------[DECT ULE PP]

        &nbs= p;            &= nbsp;    /        &n= bsp;      \

       [DECT ULE PP]--= ---/            = ;     \-----[DECT ULE PP]

 

 

       Figure 2: DECT = ULE star topology         &nbs= p;            &= nbsp;            <= ;< suggestion to place a forward reference to section 3.3  on how I= P uses that (MLSN)

 

 

 

   A significant difference between IEEE 8= 02.15.4 and DECT ULE is that

   the former supports both star and mesh = topology (and requires a

   routing protocol), whereas DECT ULE in = it's primary configuration

   does not support the formation of multi= hop networks at the link

   layer.  In consequence, the mesh h= eader defined in [RFC4944] for mesh      &nbs= p;            &= nbsp;         

  

        &nbs= p;            &= nbsp;         

< snip>

 

 

   When bound to a FP, a PP is assigned a = 20 bit TPUI which is unique       << in= reference to draft-ietf-6lo-privacy-considerations it would be good to ind= icate whether this is short lived or long lived, so as to figure if an IPv6= address can be derived or not.

   within the FP.  This TPUI is used = for addressing (layer 2) in

   messages between FP and PP.<= /p>

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

   Optionally each DECT PP and DECT FP can= be assigned a unique (IEEE)

   MAC-48 address additionally to the DECT= identities to be used by the     << same as abov= e, it would be good to indicate whether this is short lived or long lived, = so as to figure if an IPv6 address can be derived or not.

   6LoWPAN.  During the address regis= tration of non-link-local addresses

   as specified by this document, the FP a= nd PP can use such MAC-48 to

   construct the IID.

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

   support complete IP packets, the DLC la= yer of DECT ULE SHALL per this    << there is a MUST l= ater in the document, no need to uppercase here; whether this setting is ne= eded is debatable

   specification be configured with a MTU = size that fits the

   requirements from IPv6 data packets, he= nce [RFC4944] fragmentation/

   reassembly is not required.  =             &nb= sp;            =             &nb= sp;      << unclear. .. since DLC supports f= ragmentation there is no need for 6LoWPAN fragmentation is there? The adapt= ation described here only provides value if the DLC fragmentation is armful. Is that the case ?

 

   It is expected that the LOWPAN_IPHC pac= ket will fulfil all the

   requirements for header compression wit= hout spending unnecessary

   overhead for mesh addressing.

 

   It is important to realize that the usa= ge of larger packets will be

   at the expense of battery life, as a la= rge packet inside the DECT ULE

   stack will be fragmented into several o= r many MAC layer packets, each

   consuming power to transmit / receive.&= nbsp;           &nbs= p;            &= nbsp;        << proof? fragments i= ncrease reliability and reduce the size of retried pieces. is there a paper= showing pros vs cons or is this the author intuition ?

 

2.5.  Additional Considerations

 

   The DECT ULE standard allows PP to be r= egistered (bind) to multiple

   FP and roaming between these FP.  = This draft does not consider the      << Why= ?? this is where the backbone router becomes handy. If the subnet model is= clarified to NBMA / MLSN then it is possible to assign the same prefix to = multiple 6LBRs and connect them through a 6lo backbone router

   scenarios of PP roaming between mu= ltiple FP.  The use of repeater  

   functionality is also not consider= ed in this draft.

        &nbs= p;            &= nbsp;         

< snip>

 

 

3.1.  Protocol Stack

 

   In order to enable transmission of IPv6= packets over DECT ULE, a

   Permanent Virtual Circuit (PVC) has to = be opened between FP and PP.

   This MUST be done by setting up a servi= ce call from PP to FP.  The PP   << is this MUST comin= g from this spec or from DECT? if the latter then just say "this is do= ne by..."

   SHALL specify the <<IWU-ATTRIBUTE= S>> in a service-change (other)

   message before sending a service-change= (resume) message as defined

   in [TS102.939-1].  The <<IWU= -ATTRIBTES>> SHALL define the ULE

   Application Protocol Identifier to 0x06= and the MTU size to 1280

   octets or larger.  The FP MUST sen= d a service-change-accept (resume)

   containing a valid paging descriptor.&n= bsp; The PP MUST be pageable.

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

3.2.  Link Model

 

   The general model is that IPv6 is layer= 3 and DECT ULE MAC+DLC is

   layer 2.  The DECT ULE implements = already fragmentation and

   reassembly functionality, hence [RFC494= 4] fragmentation and         &= nbsp;   << this is repeating and sight contradictory. sugge= stions to keep the text starting at RFC4944, dropping the beginning of the = sentence

   reassembly function MUST NOT be us= ed.  The DECT ULE DLC link (PVC)

   MUST be configured with a minimum MTU s= ize of at least 1280 octets in   << Not sure this is needed=

   order to meet the size requirements of = IPv6.

 

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

 

   compression context if any, and from ad= dress registration information

   (see Section 3.2.2).

 

   Due to DECT ULE star topology, each bra= nch of the star is considered

   to be an individual link and thus the P= Ps cannot directly hear one      << indicate= that this is NBMA, multilink subnet. See related text in 6LoWPAN BTLE RFC = 7668

   another and cannot talk to one ano= ther with link-local addresses.

   However, the FP acts as a 6LBR for comm= unication between the PPs.

   After the FP and PPs have connected at = the DECT ULE level, the link

   can be considered up and IPv6 address c= onfiguration and transmission

   can begin.  The FP ensures address= collisions do not occur.

 

3.2.1.  Stateless Address Autoconfiguration

 

   At network interface initialization, bo= th 6LN and 6LBR SHALL generate

   and assign to the DECT ULE network inte= rface IPv6 link-local

   addresses [RFC4862] based on the DECT d= evice addresses (see

   Section 2.3) that were used for establi= shing the underlying DECT ULE

   connection.

 

   The DECT device addresses IPEI and RFPI= MUST be used to derive the      << SHOULD v= s. MUST: with a MUST, this means that the 6LoWPAN code does never expect a = link local that is not fully elided (3.2.4.1.)?

   IPv6 link-local 64 bit Interface I= dentifiers (IID) for 6LN and 6LBR,

   respectively.

 

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

 

   see [RFC7136].  For example from R= FPI=3D11.22.33.44.55 the derived IID      &nb= sp;

   is 80:11:22:ff:fe:33:44:55 and fro= m IPEI=3D01.23.45.67.89 the derived      &nbs= p;

   IID is 00:01:23:ff:fe:45:67:89.&nb= sp;            =             &nb= sp;            =   << This seems to be setting permanent addresses (admittedly Li= nk local), and the privacy properties of such addresses should be addressed= , eg addresses do not (lust not) leak in app layer in any fashion

 

   As defined in [RFC4291], the IPv6 link-= local address is formed by

   appending the IID, to the prefix FE80::= /64, as shown in Figure 4.

 

 

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

   (CGAs) [RFC3972], privacy extensions [R= FC4941], Hash-Based Addresses

   (HBAs) [RFC5535], DHCPv6 [RFC3315], or = static, semantically opaque     << This seems to = be setting permanent addresses; discussion on renewing addresses would be g= ood, ref to draft-ietf-6lo-privacy-considerations would help, and the security section could just point here as opposed to use IMPERATIVE

   addresses [RFC7217] SHOULD be used by d= efault.  In situations where

 

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

 

   2.  A DECT ULE 6LN MUST NOT regist= er its link-local address.  A DECT  << the registration has= 2 roles, DAD (which can be avoided for globally unique addresses) and SLLA= mapping. This seems to indicate that SLLA is deduced from the LL so there's special code to avoid using an ND cache?

   ULE 6LN MUST register its non-link-loca= l addresses with the 6LBR by

 

        &nbs= p;            &= nbsp;         

< snip>

 

 

   accordingly.  The NS with the ARO = option MUST be sent irrespective of

   the method used to generate the IID.&nb= sp; The 6LN MUST register only one  << why can't a device form m= ore than one address?

   IPv6 address per available IPv6 prefix.=

 

 

< snip>

 

   the DAM field of the compressed IPv6 he= ader as CID=3D1, DAC=3D1 and

   DAM=3D01 or DAM=3D11.  Note that w= hen a context is defined for the IPv6   << considering the = rest of the optimizations, why don't you have a /128 context for the 6LBR?<= o:p>

   destination address, the 6LBR can infer= the elided destination prefix

   by using the context.

 

 

 

< snip>

 

  

   

3.3.  Subnets and Internet Connectivity Scenari= os       << Missing scenario below, sam= e /64, with backbone router

 

 

 

 

        &nbs= p;            &= nbsp;   6LN      =            6LN 

     &nbs= p;            &= nbsp;       \    &nb= sp;            /

     &nbs= p;            &= nbsp;        \    &n= bsp;          /

     &nbs= p;            &= nbsp; 6LN --- 6LBR ------ 6LBR --- 6LN

     &nbs= p;            &= nbsp;        /   &= nbsp;           \

        &nbs= p;            &= nbsp;    /        &n= bsp;        \

        &nbs= p;            &= nbsp;   6LN         =         6LN

 

        &nbs= p;           <DECT ULE= > <Backbone> <DECT ULE>

 

 

 

 

< snip>

 

 

--_000_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_-- --_004_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=124; creation-date="Tue, 27 Sep 2016 09:14:37 GMT"; modification-date="Tue, 27 Sep 2016 09:14:37 GMT" Content-ID: <78B4DFF2829A2148A9BD56E7CA44FAD2@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZsbyBtYWls aW5nIGxpc3QNCjZsb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby82bG8NCg== --_004_26b8f5639f5743d4bbed33d32e36f07bXCHRCD001ciscocom_-- --_002_3514062807f14b6893377b38a5b510caXCHRCD001ciscocom_--