From nobody Mon Apr 13 01:55:17 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857481B2FCC for ; Mon, 13 Apr 2015 01:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Bf2vn262EPgN for ; Mon, 13 Apr 2015 01:55:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2811B2FC9 for ; Mon, 13 Apr 2015 01:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2079; q=dns/txt; s=iport; t=1428915314; x=1430124914; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UXJPXRYo2BcW2zdG+zR4OHMPRWXM71ZwVJiLtq9fvS8=; b=XO70/fcjSXVwT9RElrNg8gNgK6TWcP7DrGE5ZSvHFSfiZRSBLNegQp3h CWkv5+Vuu4upByhCuU6a/BIg4yTd9x9bbIayGGZmfPL2hGq8+fJ/Q5nBd rQj1lDj4/2A++3VkUmio5y4B0+q+N0n55wc9EwOBwqA5eHqjiT3kycjf7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBABKgytV/4sNJK1cgwxSYcQDZgmBToYBAoEyOBQBAQEBAQEBfYQgAQEEOk8CASoUEDIPFgEBBBuIIg3LdAEBAQEBAQEBAQEBAQEBAQEBARYEj3Y4gxeBFgWRDIN5hheBHIM3kBgiggAfgVCCM38BAQE X-IronPort-AV: E=Sophos;i="5.11,568,1422921600"; d="scan'208";a="140666840" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 13 Apr 2015 08:55:13 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3D8tDT8023698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 Apr 2015 08:55:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.10]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 03:55:12 -0500 From: "Pascal Thubert (pthubert)" To: "int-dir@ietf.org" Thread-Topic: BTLE review Thread-Index: AdB1w474qSnlScEpTD+/RFuRo+naDAAA8e0Q Date: Mon, 13 Apr 2015 08:55:11 +0000 Deferred-Delivery: Mon, 13 Apr 2015 08:55:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Int-dir] BTLE review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 13 Apr 2015 08:55:15 -0000 Dear all: Please find a review on https://tools.ietf.org/html/draft-ietf-6lo-btle-10= =20 Long title is "Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy" b= ut the spec is really "IPv6 over Bluetooth LE" as indicated by the short ti= tle since it also includes 6LoPWAN ND by reference. Suggestion to change th= e long title. 2.2: The text says that "a radio hop is equivalent to an IPv6 link and vice= versa"; this yields the question whether s a single (Router ---- Node) con= nection a subnet? Or is a star topology as in fig 2 an NBMA multilink subne= t? It would be nice to indicate at that place how a subnet is deployed. Or tha= t this spec does not make any assumption and that all models are possible.= =20 2.2 "Hence, in the primary deployment scenario central and peripheral will = act as 6LoWPAN Border Router (6LBR) and a 6LoWPANNode (6LN), respectively."= This text could be moved to early section 3, after so intro that would ind= icate that 6LoWPAN ND is required by this specification. 2.4: The text discusses the capability "to transmit IPv6 packets of 1280 by= tes or larger". 6LoWPAN for a number of reasons forces MTU to 1280 so it d= oes not need or care for "larger". It would be good to mention here if this= spec aligns to 6LoWPAN. 3.: Suggestion to move the second paragraph to 1st paragraph so the depende= ncy on 6LoWPAN ND is clarified before the specs talks about 6LBRs and stuff= . ""6LoWPAN standards [RFC6775], and [RFC6282] provide useful functionality= "...: it could be made more clear that this specification implies that 6LoW= PAN ND is used, since it is mandatory for DAD. 3.2.4: I fail to understand the MLD snooping discussion. Shouldn't the 6LBR= support MLD (RFC 2710) as a router and the 6LN as a listener? I expect tha= t the router will route between 2 6LNs that are attached to it and that app= lies to multicast as well.=20 3.3 Then again, what is the subnet assumption? Could we indicate on the pic= ture how subnet(s) map(s) on the network?=20 Cheers Pascal From nobody Tue Apr 14 08:10:30 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866C21B2CC2; Tue, 14 Apr 2015 08:10:28 -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] autolearn=ham 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 iLzhgeDQ0JbF; Tue, 14 Apr 2015 08:10:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7221B2C9D; Tue, 14 Apr 2015 08:09:39 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5918E88124; Tue, 14 Apr 2015 08:09:39 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3BC9C1368271; Tue, 14 Apr 2015 08:09:34 -0700 (PDT) Message-ID: <552D2DB8.5030004@innovationslab.net> Date: Tue, 14 Apr 2015 11:09:44 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , int-ads@ietf.org, int-dir@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QCuXNgsCQRQFIUww6EdffTpjUsADrMxOK" Archived-At: Subject: Re: [Int-dir] BTLE review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2015 15:10:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QCuXNgsCQRQFIUww6EdffTpjUsADrMxOK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Pascal. Regards, Brian On 4/13/15 4:28 AM, Pascal Thubert (pthubert) wrote: > Dear all: >=20 > Please find a review on > https://tools.ietf.org/html/draft-ietf-6lo-btle-10 >=20 > Long title is "Transmission of IPv6 Packets over BLUETOOTH(R) Low > Energy" but the spec is really "IPv6 over Bluetooth LE" as indicated > by the short title since it also includes 6LoPWAN ND by reference. > Suggestion to change the long title. >=20 > 2.2: The text says that "a radio hop is equivalent to an IPv6 link > and vice versa"; this yields the question whether s a single (Router > ---- Node) connection a subnet? Or is a star topology as in fig 2 an > NBMA multilink subnet? It would be nice to indicate at that place how > a subnet is deployed. Or that this spec does not make any assumption > and that all models are possible. >=20 > 2.2 "Hence, in the primary deployment scenario central and peripheral > will act as 6LoWPAN Border Router (6LBR) and a 6LoWPANNode (6LN), > respectively." This text could be moved to early section 3, after so > intro that would indicate that 6LoWPAN ND is required by this > specification. >=20 > 2.4: The text discusses the capability "to transmit IPv6 packets of > 1280 bytes or larger". 6LoWPAN for a number of reasons forces MTU to > 1280 so it does not need or care for "larger". It would be good to > mention here if this spec aligns to 6LoWPAN. >=20 > 3.: Suggestion to move the second paragraph to 1st paragraph so the > dependency on 6LoWPAN ND is clarified before the specs talks about > 6LBRs and stuff. ""6LoWPAN standards [RFC6775], and [RFC6282] provide > useful functionality"...: it could be made more clear that this > specification implies that 6LoWPAN ND is used, since it is mandatory > for DAD. >=20 > 3.2.4: I fail to understand the MLD snooping discussion. Shouldn't > the 6LBR support MLD (RFC 2710) as a router and the 6LN as a > listener? I expect that the router will route between 2 6LNs that are > attached to it and that applies to multicast as well. >=20 > 3.3 Then again, what is the subnet assumption? Could we indicate on > the picture how subnet(s) map(s) on the network? >=20 >=20 > Cheers >=20 > Pascal >=20 >=20 --QCuXNgsCQRQFIUww6EdffTpjUsADrMxOK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVLS24AAoJEBOZRqCi7goqNnsH/Rhy33bF0zOSTeBRGBc3VHMZ LsVveDQnKaQVCNgRw3udO5SJSvWwGav8WL7bZ9tKU4/2oIo/kzOoefWs4ye8FSVf 4MIfCCHQIuRnrZJSL/wIdHIqXJQtYn7puf2V5vHIBO3srEWrDtNQodbFncs70iVH qUgXSWMbtvHhVvXHsQMxkxr+2RFhVjJseKAr8k1q7dUysRK1ISSC95R/j0tiG2Rh Nme5fLt2dz6k5cWmfffrxFo85xB5l+JhIPrGYqUjTfx8mdBBi8cbszIq3uvPU5vx J4hBtKMNFD/Jq04DtkX4pp5rBZ6OAnI2VFqbzz1n8sG9FdHTdwmTYrAmxMeiRjs= =OCLK -----END PGP SIGNATURE----- --QCuXNgsCQRQFIUww6EdffTpjUsADrMxOK-- From nobody Wed Apr 15 14:12:18 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C2D1A1A6D for ; Wed, 15 Apr 2015 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 Ed4X0_fUpNHp for ; Wed, 15 Apr 2015 14:09:14 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 AFD041A8F49 for ; Wed, 15 Apr 2015 14:09:14 -0700 (PDT) Received: by igblo3 with SMTP id lo3so36059748igb.0 for ; Wed, 15 Apr 2015 14:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=BoFmvUbiVnHhOt5aO4zigi60/DyKcyU8XQrfE0I864c=; b=xJcP0S/mEmotrjtG3u69Aj1JvD7NkygQrqqAVvaJ/GIPsen4f6/yawOO+Ks7Ad95PH 3sp8SVriz5a/pO6ZGUPA+5ObsMiu2w7U7k+NZ7w5VwkN8GIv3Id6GqKfHr3ureQH0qbX Pj4uDFsFhsj1l3MaDw0yj+V6t6xoixNVavyuw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=BoFmvUbiVnHhOt5aO4zigi60/DyKcyU8XQrfE0I864c=; b=dObWiD5FgoBoFV/B1oA1K1HnUyKqfno2S5YJPi1aUek/Dsja1Js76wJJbEta4JJgkl JpM0G3UfeaCNASVMXH+whsuoog9EvC5C929B2Nmb+5TgtWmW67g0vUFJeKDDmy9o2hJY fi9k+GIAX/ejDsSZAxS/kF0FLcI1tK8Hkx+RH5oWbmnUJVOKkDJbt/CuUt9txkcjuIci PC6Q4TJKlg56oRY8Q/qHoa6YqbNyFlkitOaaHcoHAN8wja2mTFiUCF9Hq7koFvRgVW7L OmYdS17jbikxkLVO6sf49G4l2W3HGtSiiQsh2HTqH6sdeOS07EEPVKuQMW5Vj7Q79+24 7VuQ== X-Gm-Message-State: ALoCoQmpQVW3tta4LNWL09W0IyoeycE2mXSJPWxK1Ect3unG34mg3yOzM2/B3z4exs09GqsJ1M1Q X-Received: by 10.50.36.103 with SMTP id p7mr1128158igj.20.1429132151716; Wed, 15 Apr 2015 14:09:11 -0700 (PDT) Received: from ?IPv6:2001:470:b399:3001:fdb4:96a1:8936:4eed? ([2001:470:b399:3001:fdb4:96a1:8936:4eed]) by mx.google.com with ESMTPSA id qs3sm3827757igb.8.2015.04.15.14.09.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Apr 2015 14:09:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C7545F08-B6AC-4F85-BFAF-1D8B990ADF3C"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Joe Abley In-Reply-To: <-1241603047215316522@unknownmsgid> Date: Wed, 15 Apr 2015 17:09:07 -0400 Message-Id: <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> References: <-1241603047215316522@unknownmsgid> To: Terry Manderson X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 14:12:17 -0700 Cc: Warren Kumari , Stephane Bortzmeyer , int-dir@ietf.org Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2015 21:09:16 -0000 --Apple-Mail=_C7545F08-B6AC-4F85-BFAF-1D8B990ADF3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. I have reviewed the document draft-ietf-dprive-problem-statement-04. General The document adopts a colloquial style which I think achieves the goal = of presenting the various aspects under consideration in a clear and = understandable way. The document structure makes sense and covers the = various angles well. The treatment seems comprehensive, as is the = document's self-stated goal. There are various DNS-specific acronyms which are not expanded at first = use and whose capitalisation occasionally varies from that seen in other = documents that have a DNS focus (e.g. qname vs. QNAME). There are also a = small number of grammatical/typographical errors. These are not = addressed in this review, since the RFC editor will do a better job at = it than I could. I picked out a few suggestions for improvement in the sections that = follow, but on the whole I think the document meets its objectives well = and as an individual contributor I would not object to it proceeding = without any further changes. Specific Section 1: Introduction Paragraph 2: the DNS specification (if we can suggest that one exists at = all, with a straight face) is more than just 1034/1035. Suggest s/is = specified/was originally specified in/. Paragraph 6: it seems reasonable to note that forwarders also don't see = the identity of the client that originated the DNS request either, since = the query they receive was originated from a downstream resolver rather = than an end user. Arguably, different privacy concerns exist with = knowledge of the identity of the stub resolver, the content of the = query, and the combination of the two. You cover this in section 2.2, = but I think foreshadowing that in the introduction is worth considering. Paragraph 7: DNSCurve provides another channel encryption mechanism. I = appreciate that it's not specified in the IETF, but it exists and people = use it. Paragraph 8: "almost all" seems like it would benefit from a citation = (that should not be hard to find). Section 4: Legalities I wonder about the wisdom of appearing to give legal advice in this = document. Unless we are able to cite a study by someone properly = qualified in international and all national laws, this section seems = awkward. It's fair to say that no DNS-specific laws are known to exist = by non-lawyers in the combined experience of the author and the = reviewers, but that level of qualification starts to look like we don't = really have anything to say. (review ends) --Apple-Mail=_C7545F08-B6AC-4F85-BFAF-1D8B990ADF3C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVLtN0AAoJENchHauGaHE03acP/iQtDRlokzJ+4Vv3DnIlMK+3 IOpJVTRH5mm/yPLXIy/CqViJicGt9/rZadc0GTqQKmMBCSRKJdrG2Uo1h7ERXZYZ NgJ1bLlA7t/9F/NcZORmh9JJJiIHNSEnOZXTB6fOrYK+CcyBU1O+7DuSEu+Z5fK8 iUp3Te4Eb8sb0LrhZUUwfohj7y7Jwa7ZINqInQcZHWMZ8cg9zixOgnMLpRSND8Vf pOgyNgdaSfMAmKQt7gRAUXOxasUxdGneiYM2/hxRdjIwkpegfP1F+dOuOUtBTBJ5 34XlWRHn2SriERFT9zeiOpQ1oLFurf/Za+SDM/OGpVEJbXc6EvRPl5dXX0xl0tel /I6yReswG1QK/eLzH7gQYVK1HmkPApQ+CBdPQ6YlrZCgtA/T2bIRpq5vexzmirA6 xvBoYje3Xzqyg8DT0REVdkM+Y5joqzsbadRcEYc76KllUDhb49ocaA/gyHypZOZ3 QbEj7KduKsJS7dnxQlm63brD6B4eEi0xmlb8MRWCJzJaO146PijPBb8pLZdBNbTT ziz1irQ2Vxnktg80POCba1/VfEhs9B/yVWZ4b+wQS/Uz0nnujV7BOSusdQf+Smug WBExuFKpqPn8lXTljNnULmf8oXw1soMXYXz+OacEhSt683UlO/MHnAEV1dLXKS+E lSpQdWhlDhHxysqACyyr =BA82 -----END PGP SIGNATURE----- --Apple-Mail=_C7545F08-B6AC-4F85-BFAF-1D8B990ADF3C-- From nobody Wed Apr 15 14:14:47 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1009B1A9053 for ; Wed, 15 Apr 2015 14:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 iTUai34uv2a0 for ; Wed, 15 Apr 2015 14:14:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481E91A904C for ; Wed, 15 Apr 2015 14:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3399; q=dns/txt; s=iport; t=1429132485; x=1430342085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SMsDpu86gfTNmI9qJHkxEe7jDSYPqUpUYiKtv16Ux/8=; b=IIlBi0BxhATKYiGKA7AqfYRSRWH6rfPt1FCIfIux37XHtpMZqaqNF9K5 jphncYP7Nzh0y5KoFlGhRqkg42ArWZI6I2W0DS0S8Cc8XyYLjzlUq87/d MJIWufbCSoRIQcFxk0+1PE6gVX15ptXE2UWIV+3+DnphFVOse78epesCW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQCU1C5V/4cNJK1TCYMMUlwFx0mGAwKBP0wBAQEBAQF+hCABAQEEOj8MBAIBCA4DBAEBCxQJBzIUCQgCBAENBQgBiCENxiIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyuEICsxAgUGgxGBFgWRFpYGiQsigjOBPG8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,583,1422921600"; d="scan'208";a="412126241" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 15 Apr 2015 21:14:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3FLEirc008795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Apr 2015 21:14:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.142]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 16:14:44 -0500 From: "Bernie Volz (volz)" To: Joe Abley , Terry Manderson Thread-Topic: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04 Thread-Index: AQHQd8DdF9LjEeywRUSKmASI3rOFHZ1OksTg Date: Wed, 15 Apr 2015 21:14:43 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CA6997F@xmb-rcd-x04.cisco.com> References: <-1241603047215316522@unknownmsgid> <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> In-Reply-To: <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "int-dir@ietf.org" Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2015 21:14:47 -0000 Thanks Joe!! - Bernie -----Original Message----- From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Joe Abley Sent: Wednesday, April 15, 2015 5:09 PM To: Terry Manderson Cc: Warren Kumari; Stephane Bortzmeyer; int-dir@ietf.org Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dpr= ive-problem-statement-04 I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the I= nternet Area Directors. Document editors and shepherd(s) should treat these= comments just like they would treat comments from any other IETF contribut= ors 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. I have reviewed the document draft-ietf-dprive-problem-statement-04. General The document adopts a colloquial style which I think achieves the goal of p= resenting the various aspects under consideration in a clear and understand= able way. The document structure makes sense and covers the various angles = well. The treatment seems comprehensive, as is the document's self-stated g= oal. There are various DNS-specific acronyms which are not expanded at first use= and whose capitalisation occasionally varies from that seen in other docum= ents that have a DNS focus (e.g. qname vs. QNAME). There are also a small n= umber of grammatical/typographical errors. These are not addressed in this = review, since the RFC editor will do a better job at it than I could. I picked out a few suggestions for improvement in the sections that follow,= but on the whole I think the document meets its objectives well and as an = individual contributor I would not object to it proceeding without any furt= her changes. Specific Section 1: Introduction Paragraph 2: the DNS specification (if we can suggest that one exists at al= l, with a straight face) is more than just 1034/1035. Suggest s/is specifie= d/was originally specified in/. Paragraph 6: it seems reasonable to note that forwarders also don't see the= identity of the client that originated the DNS request either, since the q= uery they receive was originated from a downstream resolver rather than an = end user. Arguably, different privacy concerns exist with knowledge of the = identity of the stub resolver, the content of the query, and the combinatio= n of the two. You cover this in section 2.2, but I think foreshadowing that= in the introduction is worth considering. Paragraph 7: DNSCurve provides another channel encryption mechanism. I appr= eciate that it's not specified in the IETF, but it exists and people use it= . Paragraph 8: "almost all" seems like it would benefit from a citation (that= should not be hard to find). Section 4: Legalities I wonder about the wisdom of appearing to give legal advice in this documen= t. Unless we are able to cite a study by someone properly qualified in inte= rnational and all national laws, this section seems awkward. It's fair to s= ay that no DNS-specific laws are known to exist by non-lawyers in the combi= ned experience of the author and the reviewers, but that level of qualifica= tion starts to look like we don't really have anything to say. (review ends) From nobody Wed Apr 15 17:16:14 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362341ACE52 for ; Wed, 15 Apr 2015 17:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 PSwp5_m-1ugB for ; Wed, 15 Apr 2015 17:16:11 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 B64451ACE39 for ; Wed, 15 Apr 2015 17:16:11 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so70594302pdb.0 for ; Wed, 15 Apr 2015 17:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=PlPavnaxH0Zju1AeDEB4EOC6xExIn7WWNBlamOthiKg=; b=d/+VEOjerLR2Ugb1RDFCMOvMoDmpZ1GcJeEyyYCJdtP+7fSfG9AmnLzbzqioTofESN ECCdCHGOBeHvDBtq1FBbHWPNhFnB2rQMjmFqGn2HLtZsvnzHrgMKQgbnt2iCWUa5FYfi IKwTX06VEQmVau5tXc6eUb0lXO1WEFpGiXPKWoAon6eHk3FZjg1LqXwKgQA//d2cqx/N m3Fe60rO+tYrFSmxFodeeOXWRUgeM/nT3hNvZR2AP/CAWcFBCraBSSHtxXuXPD4MetLW 9/4FMcTaEcl4jYEMDwBpmH8+/0bhfFXCBo672S6U6U9eLe2IswM+rSlgMtNcC0vDxF3r B1nQ== X-Received: by 10.68.87.35 with SMTP id u3mr51050839pbz.127.1429143371405; Wed, 15 Apr 2015 17:16:11 -0700 (PDT) Received: from [10.16.11.33] ([216.31.219.19]) by mx.google.com with ESMTPSA id k4sm5247270pdk.7.2015.04.15.17.16.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 17:16:10 -0700 (PDT) Message-ID: <552EFF48.7000806@gmail.com> Date: Wed, 15 Apr 2015 17:16:08 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: volz@cisco.com, draft-ietf-6lo-btle@tools.ietf.org, Christopher LILJENSTOLPE Subject: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2015 00:16:13 -0000 Hi, I was asked to do the Internet Directorate review of draft-ietf-6lo-btle-10. Technically I think the document is ready except for few nits. The comments are below: * Section 1 which means that low power consumption is essential. Bluetooth LE is an especially attractive technology for Internet of Things ^^ Would remove 'an' here' * Section 1 Considering the potential for the exponential growth in the number of sensors and Internet connected devices and things, IPv6 is an ideal ^^^^^^^ Although I know what you are after with the "things" it somehow does not seem to fit here. I recommend removing the word. * Section 2.3 These random device addresses have a very small chance of being in conflict, as Bluetooth LE does not support random device address collision avoidance or detection. I do not parse this sentence. Is it trying to say that there is no Bluetooth specific mechanims to avoid or detect duplicate Bluetooth devices addresses because the assumption is that such collision is very rare? * Section 3 Bluetooth SIG in the IPSP specification [IPSP]. In the rare case of Bluetooth LE random device address conflict, the 6LBR can detect multiple 6LNs with the same Bluetooth LE device address. The 6LBR MUST have at most one connection for a given Bluetooth LE device What happens if 6LN and 6LBR happen to have colliding device addresses? How is that handled? * Section 3.2.1 OLD: DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates must be registered with 6LBR as described in Section 3.2.2. NEW: DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates MUST be registered with 6LBR as described in Section 3.2.2. * Section 3.2.2 1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A Bluetooth LE 6LN MUST register its non-link-local addresses with the What is the case when a BT LE 6LN can go against the SHOULD NOT and register its link-local address? * Section 3.3 Is it possible for a 6LBR to be connected to another 6LBR instead of a 6LN (referring to Figure 7)? - JOuni From nobody Wed Apr 15 19:04:47 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1A1B2A47 for ; Wed, 15 Apr 2015 19:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 uwT4f23-LE9T for ; Wed, 15 Apr 2015 19:04:44 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722D21B2A3D for ; Wed, 15 Apr 2015 19:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2507; q=dns/txt; s=iport; t=1429149884; x=1430359484; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vgC0WXE/wdeUXCEOImDwnR+fzPEDMjMiBm9wDG/VxFE=; b=lssevzD5MAxINxSIK89EK1KVZMamfxlzR/HdGqXQVXS6Dcf57oR8oVzs swEted52Jv19XhGGTLJVFHlopILjYH1VZihL7hkKTfQ9VOhsXcFz3kTxk iwFPsIfM/Vb1yLzeVlE8lQ4qszniDSPv5i926UbYuZ0v7wXBhkBNrIbCn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBAAeGC9V/4cNJK1cgwyBLsV2CYdSAoE4OBQBAQEBAQEBfYQgAQEBAwE6PwULAgEIGB0BECERJQIEDgWIFgMJCMBvDYU5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4srgkiBZRwzB4MXgRYFjnqCHIhLgU2OO4Y+IoNvb4JDAQEB X-IronPort-AV: E=Sophos;i="5.11,585,1422921600"; d="scan'208";a="141659442" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 16 Apr 2015 02:04:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3G24hcv003671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Apr 2015 02:04:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.142]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 21:04:43 -0500 From: "Bernie Volz (volz)" To: Jouni Korhonen Thread-Topic: Review of draft-ietf-6lo-btle Thread-Index: AQHQd9qMaT60NrFYxkCqM+XskvCZ251O47K9 Date: Thu, 16 Apr 2015 02:04:42 +0000 Message-ID: <65D4DF10-955A-4213-A647-CA1DD4CA49E3@cisco.com> References: <552EFF48.7000806@gmail.com> In-Reply-To: <552EFF48.7000806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Christopher LILJENSTOLPE , "" Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2015 02:04:45 -0000 Thanks much Jouni! - Bernie (from iPad) > On Apr 15, 2015, at 8:16 PM, Jouni Korhonen wrot= e: >=20 > Hi, >=20 > I was asked to do the Internet Directorate review of draft-ietf-6lo-btle-= 10. >=20 > Technically I think the document is ready except for few nits. The commen= ts are below: >=20 > * Section 1 >=20 > which means that low power consumption is essential. Bluetooth LE is > an especially attractive technology for Internet of Things > ^^ >=20 > Would remove 'an' here' >=20 > * Section 1 >=20 > Considering the potential for the exponential growth in the number of > sensors and Internet connected devices and things, IPv6 is an ideal > ^^^^^^^ > Although I know what you are after with the "things" it somehow does not = seem to fit here. I recommend removing the word. >=20 > * Section 2.3 >=20 > These random device addresses have a very small chance of being in > conflict, as Bluetooth LE does not support random device address > collision avoidance or detection. >=20 > I do not parse this sentence. Is it trying to say that there is no Blueto= oth specific mechanims to avoid or detect duplicate Bluetooth devices addre= sses because the assumption is that such collision is very rare? >=20 > * Section 3 >=20 > Bluetooth SIG in the IPSP specification [IPSP]. In the rare case of > Bluetooth LE random device address conflict, the 6LBR can detect > multiple 6LNs with the same Bluetooth LE device address. The 6LBR > MUST have at most one connection for a given Bluetooth LE device >=20 > What happens if 6LN and 6LBR happen to have colliding device addresses? H= ow is that handled? >=20 > * Section 3.2.1 >=20 > OLD: > DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates must be > registered with 6LBR as described in Section 3.2.2. > NEW: > DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates MUST be > registered with 6LBR as described in Section 3.2.2. >=20 > * Section 3.2.2 >=20 > 1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A > Bluetooth LE 6LN MUST register its non-link-local addresses with the >=20 > What is the case when a BT LE 6LN can go against the SHOULD NOT and regis= ter its link-local address? >=20 > * Section 3.3 >=20 > Is it possible for a 6LBR to be connected to another 6LBR instead of a 6L= N (referring to Figure 7)? >=20 > - JOuni From nobody Wed Apr 15 19:08:37 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8841B2A60 for ; Wed, 15 Apr 2015 19:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 52ogVMfv_HQG for ; Wed, 15 Apr 2015 19:08:32 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E8E1B2A5E for ; Wed, 15 Apr 2015 19:08:32 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 15 Apr 2015 19:08:29 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 15 Apr 2015 19:08:29 -0700 From: Terry Manderson To: Joe Abley Thread-Topic: INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04 Thread-Index: AdBqirOlG+xdR9cGSiyifSRE2cIo3AARPCYAAzjRLoAAA2RFPQAuEIAA Date: Thu, 16 Apr 2015 02:08:29 +0000 Message-ID: References: <-1241603047215316522@unknownmsgid> <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> In-Reply-To: <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3512030914_37638665" MIME-Version: 1.0 Archived-At: Cc: "int-dir@ietf.org" Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2015 02:08:34 -0000 --B_3512030914_37638665 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks Joe!! Cheers Terry On 16/04/2015 7:09 am, "Joe Abley" wrote: >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. > >I have reviewed the document draft-ietf-dprive-problem-statement-04. > >General > >The document adopts a colloquial style which I think achieves the goal of >presenting the various aspects under consideration in a clear and >understandable way. The document structure makes sense and covers the >various angles well. The treatment seems comprehensive, as is the >document's self-stated goal. > >There are various DNS-specific acronyms which are not expanded at first >use and whose capitalisation occasionally varies from that seen in other >documents that have a DNS focus (e.g. qname vs. QNAME). There are also a >small number of grammatical/typographical errors. These are not addressed >in this review, since the RFC editor will do a better job at it than I >could. > >I picked out a few suggestions for improvement in the sections that >follow, but on the whole I think the document meets its objectives well >and as an individual contributor I would not object to it proceeding >without any further changes. > >Specific > >Section 1: Introduction > >Paragraph 2: the DNS specification (if we can suggest that one exists at >all, with a straight face) is more than just 1034/1035. Suggest s/is >specified/was originally specified in/. > >Paragraph 6: it seems reasonable to note that forwarders also don't see >the identity of the client that originated the DNS request either, since >the query they receive was originated from a downstream resolver rather >than an end user. Arguably, different privacy concerns exist with >knowledge of the identity of the stub resolver, the content of the query, >and the combination of the two. You cover this in section 2.2, but I >think foreshadowing that in the introduction is worth considering. > >Paragraph 7: DNSCurve provides another channel encryption mechanism. I >appreciate that it's not specified in the IETF, but it exists and people >use it. > >Paragraph 8: "almost all" seems like it would benefit from a citation >(that should not be hard to find). > >Section 4: Legalities > >I wonder about the wisdom of appearing to give legal advice in this >document. Unless we are able to cite a study by someone properly >qualified in international and all national laws, this section seems >awkward. It's fair to say that no DNS-specific laws are known to exist by >non-lawyers in the combined experience of the author and the reviewers, >but that level of qualification starts to look like we don't really have >anything to say. > >(review ends) > --B_3512030914_37638665 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLOw oZ2aK2ELTQDNdv92GqScxBXKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDQxNjAyMDgzNFowDQYJKoZIhvcNAQEBBQAEggEAU27tuLYEO8xdHK3zpBV4 wTTagmVIJeZesQ7jNg3JjwjSFZJ4fwzb2Wj2n5X3E1xk0jNP5abepkUQ4slB+xkSxXA6nA2c aqAfxnRXmBOn5LXvH+vnZkKcZwomXzoU9ztp+3e8pwvTN8RY+4t/bGv0V1W1o03au/WzOkWZ OwnNyk+CK9zYXtq/go8ZnjgSgRULN6hrBqhl7ZTN7wkOgq9FJyJgOfQ8565vwrmLuwODddCh dLGRGCpksKt8wjdSEEX0RdOGzD/ESGE2mSDrC2AHu3vGBDidlZs+VToDV8GMqIQwshR81CrD FTvTz3AEvsx9PpGGj5Aupi9rNjh6g9ctsQ== --B_3512030914_37638665-- From nobody Fri Apr 17 05:31:45 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6A1B2CA1 for ; Fri, 17 Apr 2015 01:51:42 -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] autolearn=ham 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 jzdoauhPJp03 for ; Fri, 17 Apr 2015 01:51:40 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809FF1B2CA0 for ; Fri, 17 Apr 2015 01:51:40 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3C0023BC6F; Fri, 17 Apr 2015 10:51:38 +0200 (CEST) Received: by tyrion (Postfix, from userid 1000) id A15AFF00A17; Fri, 17 Apr 2015 10:49:23 +0200 (CEST) Date: Fri, 17 Apr 2015 10:49:23 +0200 From: Stephane Bortzmeyer To: Joe Abley Message-ID: <20150417084923.GA16016@laperouse.bortzmeyer.org> References: <-1241603047215316522@unknownmsgid> <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <323BCBD1-F511-4E6E-85E0-113D61676C3E@dyn.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 14.04 (trusty) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 17 Apr 2015 05:31:44 -0700 Cc: Warren Kumari , int-dir@ietf.org, Stephane Bortzmeyer , Terry Manderson Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 17 Apr 2015 08:51:43 -0000 On Wed, Apr 15, 2015 at 05:09:07PM -0400, Joe Abley wrote a message of 100 lines which said: > resolve them along with any other Last Call comments that have been > received. OK, waiting for the Last Call to start. > There are various DNS-specific acronyms which are not expanded at > first use and whose capitalisation occasionally varies from that > seen in other documents that have a DNS focus (e.g. qname > vs. QNAME). This specific one is fixed in the reference repository but not yet in a published draft. > Section 1: Introduction > > Paragraph 2: the DNS specification (if we can suggest that one > exists at all, with a straight face) is more than just > 1034/1035. Suggest s/is specified/was originally specified in/. OK. TODO: read the other RFCs on DNS to see which text they use. For instance, RFC 4033 does exactly like the DPRIVE draft... > Paragraph 6: it seems reasonable to note that forwarders also don't > see the identity of the client that originated the DNS request > either, since the query they receive was originated from a > downstream resolver rather than an end user. Arguably, different > privacy concerns exist with knowledge of the identity of the stub > resolver, the content of the query, and the combination of the > two. You cover this in section 2.2, but I think foreshadowing that > in the introduction is worth considering. OK > Paragraph 7: DNSCurve provides another channel encryption > mechanism. I appreciate that it's not specified in the IETF, but it > exists and people use it. DNScrypt is used and could be mentioned. Nobody uses DNScurve. > Paragraph 8: "almost all" seems like it would benefit from a > citation (that should not be hard to find). TODO: read Hedgehog Web site :-) > Section 4: Legalities > > I wonder about the wisdom of appearing to give legal advice in this > document. Complicated issue. Postponed as issue #12 Thanks for the review. From nobody Fri Apr 17 06:41:19 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1091B2CBD for ; Fri, 17 Apr 2015 06:41:17 -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] autolearn=ham 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 W0WBD6kVaZiW for ; Fri, 17 Apr 2015 06:41:15 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54C01B2CBB for ; Fri, 17 Apr 2015 06:41:15 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C08E7880E5 for ; Fri, 17 Apr 2015 06:41:15 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8FF9D71B0001 for ; Fri, 17 Apr 2015 06:41:15 -0700 (PDT) Message-ID: <55310D88.4080506@innovationslab.net> Date: Fri, 17 Apr 2015 09:41:28 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: int-dir@ietf.org References: <552EFF48.7000806@gmail.com> In-Reply-To: <552EFF48.7000806@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R7O3a30nxt5M4xMnLum6LsvJTILOgTJrX" Archived-At: Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 17 Apr 2015 13:41:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R7O3a30nxt5M4xMnLum6LsvJTILOgTJrX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Jouni, Thanks for the review. Very helpful. Regards, Brian On 4/15/15 8:16 PM, Jouni Korhonen wrote: > Hi, >=20 > I was asked to do the Internet Directorate review of > draft-ietf-6lo-btle-10. >=20 > Technically I think the document is ready except for few nits. The > comments are below: >=20 > * Section 1 >=20 > which means that low power consumption is essential. Bluetooth LE i= s > an especially attractive technology for Internet of Things > ^^ >=20 > Would remove 'an' here' >=20 > * Section 1 >=20 > Considering the potential for the exponential growth in the number o= f > sensors and Internet connected devices and things, IPv6 is an ideal > ^^^^^^^ > Although I know what you are after with the "things" it somehow does no= t > seem to fit here. I recommend removing the word. >=20 > * Section 2.3 >=20 > These random device addresses have a very small chance of being in > conflict, as Bluetooth LE does not support random device address > collision avoidance or detection. >=20 > I do not parse this sentence. Is it trying to say that there is no > Bluetooth specific mechanims to avoid or detect duplicate Bluetooth > devices addresses because the assumption is that such collision is very= > rare? >=20 > * Section 3 >=20 > Bluetooth SIG in the IPSP specification [IPSP]. In the rare case of= > Bluetooth LE random device address conflict, the 6LBR can detect > multiple 6LNs with the same Bluetooth LE device address. The 6LBR > MUST have at most one connection for a given Bluetooth LE device >=20 > What happens if 6LN and 6LBR happen to have colliding device addresses?= > How is that handled? >=20 > * Section 3.2.1 >=20 > OLD: > DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates must b= e > registered with 6LBR as described in Section 3.2.2. > NEW: > DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates MUST b= e > registered with 6LBR as described in Section 3.2.2. >=20 > * Section 3.2.2 >=20 > 1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. = A > Bluetooth LE 6LN MUST register its non-link-local addresses with the= >=20 > What is the case when a BT LE 6LN can go against the SHOULD NOT and > register its link-local address? >=20 > * Section 3.3 >=20 > Is it possible for a 6LBR to be connected to another 6LBR instead of a > 6LN (referring to Figure 7)? >=20 > - JOuni >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir >=20 >=20 --R7O3a30nxt5M4xMnLum6LsvJTILOgTJrX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVMQ2IAAoJEBOZRqCi7goqvt8IAKyW2iul/lhE21bQpY6INquC MlMictno36WMt8rdpquApP2/l6ZTMtheu+JyWFwXXpSBPwMxQ6RrHAYMnpz1lOHa RYrVhLKMryTUKkGREwINBamo7PaA4AjpgVw88+1QFNOJJk5YPqpGJhpj/NYxH7N4 Cbh0XFNhSNZt5ZMjnS4l8BnZJa78MYUQmOkmr7rFPk7NYqDMRAvKQ1Q6ql7HR8+8 qvR2hGEeabGQLcoaTmfRXAZWpArlbd3XeCZOaZFW4dbZdCPpD/xHZpHQQAna5VSU TlQAtsUaJWNlmSCdnVfLxCuSABwnVfT3CB7LDokLaBRkLxAIsyGbVDRrMv4mtJ8= =Qonl -----END PGP SIGNATURE----- --R7O3a30nxt5M4xMnLum6LsvJTILOgTJrX-- From nobody Tue Apr 21 06:20:48 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF071A92FE for ; Tue, 21 Apr 2015 04:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 4S94BMrBVBRT for ; Tue, 21 Apr 2015 04:41:08 -0700 (PDT) Received: from nok-msg-3.service.capgemini.fi (nok-msg-3.service.capgemini.fi [145.247.12.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F221A92F7 for ; Tue, 21 Apr 2015 04:41:07 -0700 (PDT) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-3.service.capgemini.fi with ESMTP; 21 Apr 2015 14:41:03 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 21 Apr 2015 14:41:03 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.1044.021; Tue, 21 Apr 2015 14:41:02 +0300 From: "Savolainen Teemu (Nokia-TECH/Tampere)" To: ext Jouni Korhonen , "" Thread-Topic: Review of draft-ietf-6lo-btle Thread-Index: AQHQd9qVbGrrbxOxwE+f7d/vCL1tyZ1XXE4w Date: Tue, 21 Apr 2015 11:41:02 +0000 Message-ID: <93999e54a39d4b2b8d3b67eac98e00e3@NOKWDCFIEXCH02P.nnok.nokia.com> References: <552EFF48.7000806@gmail.com> In-Reply-To: <552EFF48.7000806@gmail.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.50.32.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 21 Apr 2015 06:20:47 -0700 Cc: "volz@cisco.com" , "draft-ietf-6lo-btle@tools.ietf.org" , Christopher LILJENSTOLPE Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2015 11:41:10 -0000 SGkgSm91bmksDQoNCkFuZCB0aGFua3MgZm9yIHJldmlldy4gUGxlYXNlIHNlZSByZXBsaWVzIGlu bGluZS4NCg0KPiAgICBhbiBlc3BlY2lhbGx5IGF0dHJhY3RpdmUgdGVjaG5vbG9neSBmb3IgSW50 ZXJuZXQgb2YgVGhpbmdzDQo+ICAgIF5eDQo+V291bGQgcmVtb3ZlICdhbicgaGVyZScNCg0KUmVt b3ZlZC4NCg0KPiAgICBzZW5zb3JzIGFuZCBJbnRlcm5ldCBjb25uZWN0ZWQgZGV2aWNlcyBhbmQg dGhpbmdzLCBJUHY2IGlzIGFuIGlkZWFsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF5eXl5eXl4gQWx0aG91Z2ggSSBrbm93IHdoYXQgeW91IGFyZSBhZnRl ciB3aXRoIHRoZSAidGhpbmdzIiBpdCBzb21laG93IGRvZXMgbm90IHNlZW0gdG8gZml0IGhlcmUu IEkgcmVjb21tZW5kIHJlbW92aW5nIHRoZSB3b3JkLg0KDQpSaWdodCwgc291bmRzIGJldHRlciBh ZnRlciByZW1vdmluZyB0aGUgd29yZC4NCg0KPiAgICBUaGVzZSByYW5kb20gZGV2aWNlIGFkZHJl c3NlcyBoYXZlIGEgdmVyeSBzbWFsbCBjaGFuY2Ugb2YgYmVpbmcgaW4NCj4gICAgY29uZmxpY3Qs IGFzIEJsdWV0b290aCBMRSBkb2VzIG5vdCBzdXBwb3J0IHJhbmRvbSBkZXZpY2UgYWRkcmVzcw0K PiAgICBjb2xsaXNpb24gYXZvaWRhbmNlIG9yIGRldGVjdGlvbi4NCj5JIGRvIG5vdCBwYXJzZSB0 aGlzIHNlbnRlbmNlLiBJcyBpdCB0cnlpbmcgdG8gc2F5IHRoYXQgdGhlcmUgaXMgbm8gQmx1ZXRv b3RoIHNwZWNpZmljIG1lY2hhbmltcyB0byBhdm9pZCBvciBkZXRlY3QgZHVwbGljYXRlIEJsdWV0 b290aCBkZXZpY2VzIGFkZHJlc3NlcyBiZWNhdXNlIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgc3Vj aCBjb2xsaXNpb24gaXMgdmVyeSByYXJlPw0KDQpZZXMuIFJld29yZGVkIGEgYml0Og0KLS0NClRo ZXNlIHJhbmRvbSBkZXZpY2UgYWRkcmVzc2VzIGhhdmUgYSB2ZXJ5IHNtYWxsIGNoYW5jZSBvZiBi ZWluZyBpbiBjb25mbGljdCwgYXMgdGhlcmUgYXJlIG5vIEJsdWV0b290aCBMRSBzcGVjaWZpYyBt ZWNoYW5pc21zIGZvciBzdXBwb3J0aW5nIHJhbmRvbSBkZXZpY2UgYWRkcmVzcyBjb2xsaXNpb24g ZGV0ZWN0aW9uIG9yIGF2b2lkYW5jZS4NCi0tDQoNCj4gICAgQmx1ZXRvb3RoIFNJRyBpbiB0aGUg SVBTUCBzcGVjaWZpY2F0aW9uIFtJUFNQXS4gIEluIHRoZSByYXJlIGNhc2Ugb2YNCj4gICAgQmx1 ZXRvb3RoIExFIHJhbmRvbSBkZXZpY2UgYWRkcmVzcyBjb25mbGljdCwgdGhlIDZMQlIgY2FuIGRl dGVjdA0KPiAgICBtdWx0aXBsZSA2TE5zIHdpdGggdGhlIHNhbWUgQmx1ZXRvb3RoIExFIGRldmlj ZSBhZGRyZXNzLiAgVGhlIDZMQlINCj4gICAgTVVTVCBoYXZlIGF0IG1vc3Qgb25lIGNvbm5lY3Rp b24gZm9yIGEgZ2l2ZW4gQmx1ZXRvb3RoIExFIGRldmljZQ0KPldoYXQgaGFwcGVucyBpZiA2TE4g YW5kIDZMQlIgaGFwcGVuIHRvIGhhdmUgY29sbGlkaW5nIGRldmljZSBhZGRyZXNzZXM/IA0KPkhv dyBpcyB0aGF0IGhhbmRsZWQ/DQoNCldlbGwsIHdoZW4gNkxCUiBpcyBzY2FubmluZyBmb3IgZGV2 aWNlcyBhbmQgaWYgaXQgZmluZHMgNkxOIHdpdGggc2FtZSBkZXZpY2UgYWRkcmVzcyB0aGFuIGl0 c2VsZiwgaXQganVzdCB3b3VsZCBoYXZlIHRvIGlnbm9yZSB0aGF0IDZMTiAodW50aWwgdGhlIDZM TiBjaGFuZ2VzIGl0cyBhZGRyZXNzIHRvIG9uZSBub3QgaW4gY29uZmxpY3QsIHdoaWNoIGl0IHdp bGwgd2hlbiB1c2luZyByYW5kb20gYWRkcmVzc2VzKS4gSG93IGFib3V0IHJld29yZGluZyB0aGUg YWJvdmUgdG86DQotLQ0KSW4gdGhlIHJhcmUgY2FzZSBvZiBCbHVldG9vdGggTEUgcmFuZG9tIGRl dmljZSBhZGRyZXNzIGNvbmZsaWN0LCBhIDZMQlIgY2FuIGRldGVjdCBtdWx0aXBsZSA2TE5zIHdp dGggdGhlIHNhbWUgQmx1ZXRvb3RoIExFIGRldmljZSBhZGRyZXNzIG9yIDZMTnMgd2l0aCB0aGUg c2FtZSBhZGRyZXNzIHRoZSA2TEJSIGlzIHVzaW5nLiBUaGUgNkxCUiBNVVNUIGlnbm9yZSA2TE5z IHdpdGggdGhlIHNhbWUgZGV2aWNlIGFkZHJlc3MgdGhlIDZMQlIgaGFzLCBhbmQgdGhlIDZMQlIg TVVTVCBoYXZlIGF0IG1vc3Qgb25lIGNvbm5lY3Rpb24gZm9yIGEgZ2l2ZW4gQmx1ZXRvb3RoIExF IGRldmljZSBhZGRyZXNzIGF0IGFueSBnaXZlbiBtb21lbnQuDQotLQ0KDQo+T0xEOg0KPiAgICBE SENQdjYgW1JGQzMzMTVdLiAgVGhlIG5vbi1saW5rLWxvY2FsIGFkZHJlc3NlcyA2TE4gZ2VuZXJh dGVzIG11c3QgYmUNCj4gICAgcmVnaXN0ZXJlZCB3aXRoIDZMQlIgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMy4yLjIuDQo+TkVXOg0KPiAgICBESENQdjYgW1JGQzMzMTVdLiAgVGhlIG5vbi1saW5r LWxvY2FsIGFkZHJlc3NlcyA2TE4gZ2VuZXJhdGVzIE1VU1QgYmUNCj4gICAgcmVnaXN0ZXJlZCB3 aXRoIDZMQlIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLjIuDQoNCkZpeGVkLg0KDQo+ICAg IDEuICBBIEJsdWV0b290aCBMRSA2TE4gU0hPVUxEIE5PVCByZWdpc3RlciBpdHMgbGluay1sb2Nh bCBhZGRyZXNzLiAgQQ0KPiAgICBCbHVldG9vdGggTEUgNkxOIE1VU1QgcmVnaXN0ZXIgaXRzIG5v bi1saW5rLWxvY2FsIGFkZHJlc3NlcyB3aXRoIHRoZQ0KPldoYXQgaXMgdGhlIGNhc2Ugd2hlbiBh IEJUIExFIDZMTiBjYW4gZ28gYWdhaW5zdCB0aGUgU0hPVUxEIE5PVCBhbmQgcmVnaXN0ZXIgaXRz IGxpbmstbG9jYWwgYWRkcmVzcz8NCg0KUmVnaXN0ZXJpbmcgbGluay1sb2NhbCBhZGRyZXNzIHdv dWxkIGJlIHdhc3RlIG9mIHJlc291cmNlcywgYnV0IGhvc3QgbWF5IHdhc3RlIHJlc291cmNlcyBp ZiBpdCBsaWtlczopIA0KDQpTZXJpb3VzbHksIGdvb2QgcG9pbnQuIEkgdGhpbmsgd2UgY2FuIGNo YW5nZSB0aGlzIHRvIE1VU1QgTk9UIGFzIHdlIG5vd2FkYXlzIHNheSBlYXJsaWVyIHRoYXQgbGlu ay1sb2NhbCBhZGRyZXNzZXMgYXJlIGFsd2F5cyBib3VuZCB0byBkZXZpY2UgYWRkcmVzcyBhIGRl dmljZSBoYXMuIEhlbmNlIHJlZ2lzdGVyaW5nIGl0IHByb2JhYmx5IHdvdWxkIGhhdmUgbm8gYmVu ZWZpdCBidXQgY291bGQgYmUgc291cmNlIG9mIGVycm9ycy4NCg0KTmV3IHRleHQ6IiAxLiAgQSBC bHVldG9vdGggTEUgNkxOIE1VU1QgTk9UIHJlZ2lzdGVyIGl0cyBsaW5rLWxvY2FsIGFkZHJlc3Mu Ii4NCg0KPklzIGl0IHBvc3NpYmxlIGZvciBhIDZMQlIgdG8gYmUgY29ubmVjdGVkIHRvIGFub3Ro ZXIgNkxCUiBpbnN0ZWFkIG9mIGEgNkxOIChyZWZlcnJpbmcgdG8gRmlndXJlIDcpPw0KDQpCTEUg bWVzaCBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgc28gbm8uLg0KDQpCZXN0IHJl Z2FyZHMsDQoNCglUZWVtdQ0K From nobody Tue Apr 21 13:07:15 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890171A03C7 for ; Tue, 21 Apr 2015 13:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 pc-AncjIsNRk for ; Tue, 21 Apr 2015 13:07:12 -0700 (PDT) Received: from smtp4.emailarray.com (smtp4.emailarray.com [65.39.216.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691C81A0366 for ; Tue, 21 Apr 2015 13:07:07 -0700 (PDT) Received: (qmail 57357 invoked by uid 89); 21 Apr 2015 20:07:06 -0000 Received: from unknown (HELO ?172.17.8.1?) (Y2RsQGFzZ2FhcmQub3JnQDguMjUuMjIyLjEw) (POLARISLOCAL) by smtp4.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Apr 2015 20:07:05 -0000 From: "Christopher LILJENSTOLPE" To: "Bernie Volz (volz)" Date: Tue, 21 Apr 2015 13:07:04 -0700 Message-ID: In-Reply-To: <65D4DF10-955A-4213-A647-CA1DD4CA49E3@cisco.com> References: <552EFF48.7000806@gmail.com> <65D4DF10-955A-4213-A647-CA1DD4CA49E3@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: Jouni Korhonen , "" Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2015 20:07:13 -0000 On 15 Apr 2015, at 19:04, Bernie Volz (volz) wrote: > Thanks much Jouni! +1 > > - Bernie (from iPad) > >> On Apr 15, 2015, at 8:16 PM, Jouni Korhonen >> wrote: >> >> Hi, >> >> I was asked to do the Internet Directorate review of >> draft-ietf-6lo-btle-10. >> >> Technically I think the document is ready except for few nits. The >> comments are below: >> >> * Section 1 >> >> which means that low power consumption is essential. Bluetooth LE is >> an especially attractive technology for Internet of Things >> ^^ >> >> Would remove 'an' here' >> >> * Section 1 >> >> Considering the potential for the exponential growth in the number of >> sensors and Internet connected devices and things, IPv6 is an ideal >> ^^^^^^^ >> Although I know what you are after with the "things" it somehow does >> not seem to fit here. I recommend removing the word. >> >> * Section 2.3 >> >> These random device addresses have a very small chance of being in >> conflict, as Bluetooth LE does not support random device address >> collision avoidance or detection. >> >> I do not parse this sentence. Is it trying to say that there is no >> Bluetooth specific mechanims to avoid or detect duplicate Bluetooth >> devices addresses because the assumption is that such collision is >> very rare? >> >> * Section 3 >> >> Bluetooth SIG in the IPSP specification [IPSP]. In the rare case of >> Bluetooth LE random device address conflict, the 6LBR can detect >> multiple 6LNs with the same Bluetooth LE device address. The 6LBR >> MUST have at most one connection for a given Bluetooth LE device >> >> What happens if 6LN and 6LBR happen to have colliding device >> addresses? How is that handled? >> >> * Section 3.2.1 >> >> OLD: >> DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates must be >> registered with 6LBR as described in Section 3.2.2. >> NEW: >> DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates MUST be >> registered with 6LBR as described in Section 3.2.2. >> >> * Section 3.2.2 >> >> 1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A >> Bluetooth LE 6LN MUST register its non-link-local addresses with the >> >> What is the case when a BT LE 6LN can go against the SHOULD NOT and >> register its link-local address? >> >> * Section 3.3 >> >> Is it possible for a 6LBR to be connected to another 6LBR instead of >> a 6LN (referring to Figure 7)? >> >> - JOuni -- 李柯睿 Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf From nobody Tue Apr 21 14:14:39 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECDB1B2B74 for ; Tue, 21 Apr 2015 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 6tJ3ji3GLtTr for ; Tue, 21 Apr 2015 14:14:36 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 425041B2B76 for ; Tue, 21 Apr 2015 14:14:36 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so253270291pdb.0 for ; Tue, 21 Apr 2015 14:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qoITeO6VQ8/+psmBzrGv92glF/+RRwEztRNbYguv3/8=; b=MVvpZuZ2F7N/d/y96L8Oxl+FjgpfbKJmPnap+0jcKcTtMKs0SAZTQAXxyqbdfXK2SL fZDC38WBGcLco6nSaXmw1B0MA9Jx5aDcjewaSXKb8rEKTHxkLmticD21U/Ljp+cjjLEN Hv0gVMUPVuFSv3d8Rh8CSPzstzSyBer5OsbN7hes9fLpt6qFhicmR+mfDgGUHsx9Cfb3 a2P1JoL5ILLmdMGFlM/Jsb1glJaHSj3iYT4faCLEJtmt8/TBMrwfbKjotVP/aIwqJWfo kVjkLh68sd93aZjClUnbYWY6L1wMoDvyMK8mla/rjyCtoKKgJgixSrNrht6SJTpAsaE3 M20Q== X-Received: by 10.68.209.193 with SMTP id mo1mr4326896pbc.142.1429650875958; Tue, 21 Apr 2015 14:14:35 -0700 (PDT) Received: from [10.16.10.172] ([216.31.219.19]) by mx.google.com with ESMTPSA id y4sm2957340pdm.9.2015.04.21.14.14.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 14:14:34 -0700 (PDT) Message-ID: <5536BDB8.60804@gmail.com> Date: Tue, 21 Apr 2015 14:14:32 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Savolainen Teemu (Nokia-TECH/Tampere)" , "" References: <552EFF48.7000806@gmail.com> <93999e54a39d4b2b8d3b67eac98e00e3@NOKWDCFIEXCH02P.nnok.nokia.com> In-Reply-To: <93999e54a39d4b2b8d3b67eac98e00e3@NOKWDCFIEXCH02P.nnok.nokia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "volz@cisco.com" , "draft-ietf-6lo-btle@tools.ietf.org" , Christopher LILJENSTOLPE Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2015 21:14:38 -0000 Hi Teemu, See my responses inline. 4/21/2015, 4:41 AM, Savolainen Teemu (Nokia-TECH/Tampere) kirjoitti: > Hi Jouni, > > And thanks for review. Please see replies inline. > >> an especially attractive technology for Internet of Things >> ^^ >> Would remove 'an' here' > > Removed. > >> sensors and Internet connected devices and things, IPv6 is an ideal >> ^^^^^^^ Although I know what you are after with the "things" it somehow does not seem to fit here. I recommend removing the word. > > Right, sounds better after removing the word. > >> These random device addresses have a very small chance of being in >> conflict, as Bluetooth LE does not support random device address >> collision avoidance or detection. >> I do not parse this sentence. Is it trying to say that there is no Bluetooth specific mechanims to avoid or detect duplicate Bluetooth devices addresses because the assumption is that such collision is very rare? > > Yes. Reworded a bit: > -- > These random device addresses have a very small chance of being in conflict, as there are no Bluetooth LE specific mechanisms for supporting random device address collision detection or avoidance. > -- I still find the wording confusing. Let me try: Bluetooth LE does not support device address collision avoidance or detection. However, these 48 bit random device addresses have a very small propability of being in conflict within a typical deployment. > >> Bluetooth SIG in the IPSP specification [IPSP]. In the rare case of >> Bluetooth LE random device address conflict, the 6LBR can detect >> multiple 6LNs with the same Bluetooth LE device address. The 6LBR >> MUST have at most one connection for a given Bluetooth LE device >> What happens if 6LN and 6LBR happen to have colliding device addresses? >> How is that handled? > > Well, when 6LBR is scanning for devices and if it finds 6LN with same device address than itself, it just would have to ignore that 6LN (until the 6LN changes its address to one not in conflict, which it will when using random addresses). How about rewording the above to: > -- > In the rare case of Bluetooth LE random device address conflict, a 6LBR > can detect multiple 6LNs with the same Bluetooth LE device address or 6LNs > with the same address the 6LBR is using. The 6LBR MUST ignore 6LNs with > the same device address the 6LBR has, and the 6LBR MUST have at most one > connection for a given Bluetooth LE device address at any given moment. > -- WFM. > >> OLD: >> DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates must be >> registered with 6LBR as described in Section 3.2.2. >> NEW: >> DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates MUST be >> registered with 6LBR as described in Section 3.2.2. > > Fixed. > >> 1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A >> Bluetooth LE 6LN MUST register its non-link-local addresses with the >> What is the case when a BT LE 6LN can go against the SHOULD NOT and register its link-local address? > > Registering link-local address would be waste of resources, but host may waste resources if it likes:) > > Seriously, good point. I think we can change this to MUST NOT as we nowadays say earlier that link-local addresses are always bound to device address a device has. Hence registering it probably would have no benefit but could be source of errors. > > New text:" 1. A Bluetooth LE 6LN MUST NOT register its link-local address.". WFM. > >> Is it possible for a 6LBR to be connected to another 6LBR instead of a 6LN (referring to Figure 7)? > > BLE mesh is out-of-scope of this document, so no.. Ack. - Jouni > > Best regards, > > Teemu > From nobody Thu Apr 23 08:21:26 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3451A9123 for ; Thu, 23 Apr 2015 08:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YqzGEzqKIefm for ; Thu, 23 Apr 2015 08:21:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C281A8A0B for ; Thu, 23 Apr 2015 08:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=698; q=dns/txt; s=iport; t=1429802479; x=1431012079; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0W9zSH19poHQjJflkliNJ3AM2oQU3IsQhm9Ckjwq714=; b=dG3HsMJLyvJK5b9PMhTY2LyB9zOEqI74Jzl/02sg4ksFtGVVnnXaC5Ko ogVWRrXoXX86R/adnhQafzs19CjO7H7pzm8SsWjuTA6EM7NlGrNYqIWH9 5jTjPo25YGnKPJCSLdYzeXhFA7qdiJUj+SUSDcpPe9k4b+FiArDFG12vZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUBADTDDlV/5FdJa1bgwyBM4MVwwoJh1UCHIEaOBQBAQEBAQEBgQqEIgEEIxFXASICBiACBDAVEQEEARqII7gAlGYBAQEBAQUBAQEBAR2BIY5pgyAvgRYBBJFKoAAjg3SCM4EAAQEB X-IronPort-AV: E=Sophos;i="5.11,631,1422921600"; d="scan'208";a="143870891" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Apr 2015 15:21:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3NFLI41010473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 15:21:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.164]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 10:21:18 -0500 From: "Bernie Volz (volz)" To: Christopher LILJENSTOLPE , "int-dir@ietf.org" Thread-Topic: Int Area Directorate Review requests Thread-Index: AdB92M9A28fg+HPLSOSoBXLVuSSuLg== Date: Thu, 23 Apr 2015 15:21:17 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CA90F0B@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Int-dir] Int Area Directorate Review requests X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2015 15:21:25 -0000 SGk6DQoNCkkgdGhpbmsgZ29pbmcgZm9yd2FyZCB3ZSBzaG91bGQgYXNzdW1lIHRoYXQgZWFjaCBy ZXZpZXcgaXMgdG8gYmUgY29tcGxldGVkIHdpdGhpbiAyIHdlZWtzICgxNCBjYWxlbmRhciBkYXlz KSBPRiBUSEUgUkVRVUVTVCB1bmxlc3Mgb3RoZXJ3aXNlIGluZGljYXRlZCBpbiB0aGUgcmV2aWV3 IHJlcXVlc3QuIEkgYmVsaWV2ZSBUZXJyeSBvciBCcmlhbiB1c3VhbGx5IHN0YXJ0cyB0aGVzZSB3 aGVuIHRoZSBkb2N1bWVudCBpcyBzdWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIGFuZCB0aGUgMiB3 ZWVrcyB3b3VsZCBvdmVybGFwIHRoZSBJRVRGIGxhc3QgY2FsbCBwcm9jZXNzICgrLy0gYSBmZXcg ZGF5cykuDQoNCk5vdGUgdGhhdCB0aGlzIG1heSByZXN1bHQgaW4gbGVzcyB0aGFuIDIgd2Vla3Mg Zm9yIHRoZSBtZW1iZXIgdG8gcmV2aWV3IGdpdmVuIHRoZSBwcm9jZXNzIChhcyBpdCBjb3VsZCB0 YWtlIGEgZmV3IGRheXMgdG8gY29uZmlybSBhIHJldmlld2VyKS4NCg0KLSBCZXJuaWUNCg== From nobody Thu Apr 23 08:23:59 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854641A8F43 for ; Thu, 23 Apr 2015 08:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, SPF_PASS=-0.001] autolearn=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 Qrpxum95xMYP for ; Thu, 23 Apr 2015 08:23:57 -0700 (PDT) Received: from smtp5.emailarray.com (smtp5.emailarray.com [65.39.216.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F221AC3A1 for ; Thu, 23 Apr 2015 08:23:44 -0700 (PDT) Received: (qmail 79687 invoked by uid 89); 23 Apr 2015 15:23:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (Y2RsQGFzZ2FhcmQub3JnQDU0LjIxMC4yNTQuMjA0) (POLARISLOCAL) by smtp5.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Apr 2015 15:23:43 -0000 Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14298026179440.9861314126756042" From: christopher liljenstolpe To: "Bernie Volz (volz)" In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CA90F0B@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1CA90F0B@xmb-rcd-x04.cisco.com> Date: Thu, 23 Apr 2015 08:23:36 -0700 X-Cm-Message-Id: 1429802617860654c411e113e5fe1f3287766b60a9f735c855390e79d229f801045386 X-Cm-Draft-Id: WyJhIiwxLCJkcmFmdF9pZCIsMTQyOTgwMjYxNjU4MywidiIsMV0= X-Mailer: CloudMagic Message-Id: <1429802622577-021ed14c-375aa6dc-72c98232@asgaard.org> MIME-Version: 1.0 X-PolarisMail-Flags: x Archived-At: Cc: int-dir@ietf.org Subject: Re: [Int-dir] Int Area Directorate Review requests X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2015 15:23:58 -0000 ------sinikael-?=_1-14298026179440.9861314126756042 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit Agreed. AD's let us know if a given request needs a +/- to the 14 day rule On Thu, Apr 23, 2015 at 8:21 AM, Bernie Volz (volz) < volz@cisco.com [volz@cisco.com] > wrote: Hi: I think going forward we should assume that each review is to be completed within 2 weeks (14 calendar days) OF THE REQUEST unless otherwise indicated in the review request. I believe Terry or Brian usually starts these when the document is submitted for publication and the 2 weeks would overlap the IETF last call process (+/- a few days). Note that this may result in less than 2 weeks for the member to review given the process (as it could take a few days to confirm a reviewer). - Bernie ------sinikael-?=_1-14298026179440.9861314126756042 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit

Agreed.  AD's let us know if a given request needs a +/- to the 14 day rule

On Thu, Apr 23, 2015 at 8:21 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

Hi:

I think going forward we should assume that each review is to be completed within 2 weeks (14 calendar days) OF THE REQUEST unless otherwise indicated in the review request. I believe Terry or Brian usually starts these when the document is submitted for publication and the 2 weeks would overlap the IETF last call process (+/- a few days).

Note that this may result in less than 2 weeks for the member to review given the process (as it could take a few days to confirm a reviewer).

- Bernie

------sinikael-?=_1-14298026179440.9861314126756042-- From nobody Thu Apr 23 09:48:48 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C475E1AC424 for ; Thu, 23 Apr 2015 09:48:46 -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] autolearn=ham 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 KFtBEjGJy0zj for ; Thu, 23 Apr 2015 09:48:45 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AE91ACCED for ; Thu, 23 Apr 2015 09:48:35 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DB2DA880E5 for ; Thu, 23 Apr 2015 09:48:35 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A35BB1368276 for ; Thu, 23 Apr 2015 09:48:35 -0700 (PDT) Message-ID: <55392262.7050102@innovationslab.net> Date: Thu, 23 Apr 2015 12:48:34 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: int-dir@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1CA90F0B@xmb-rcd-x04.cisco.com> <1429802622577-021ed14c-375aa6dc-72c98232@asgaard.org> In-Reply-To: <1429802622577-021ed14c-375aa6dc-72c98232@asgaard.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DJ89LnlOiUe5bk6vEhfiXHrvCsRxtFI1b" Archived-At: Subject: Re: [Int-dir] Int Area Directorate Review requests X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2015 16:48:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DJ89LnlOiUe5bk6vEhfiXHrvCsRxtFI1b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A 14-day window seems reasonable to me and if we need something different, we will let you know. Thanks, Brian On 4/23/15 11:23 AM, christopher liljenstolpe wrote: > Agreed. AD's let us know if a given request needs a +/- to the 14 day r= ule >=20 > On Thu, Apr 23, 2015 at 8:21 AM, Bernie Volz (volz) < volz@cisco.com > [volz@cisco.com] > wrote: > Hi: >=20 > I think going forward we should assume that each review is to be comple= ted > within 2 weeks (14 calendar days) OF THE REQUEST unless otherwise > indicated in > the review request. I believe Terry or Brian usually starts these when = the > document is submitted for publication and the 2 weeks would overlap the= > IETF > last call process (+/- a few days). >=20 > Note that this may result in less than 2 weeks for the member to review= > given > the process (as it could take a few days to confirm a reviewer). >=20 > - Bernie >=20 >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir >=20 --DJ89LnlOiUe5bk6vEhfiXHrvCsRxtFI1b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVOSJiAAoJEBOZRqCi7goqRpsH/271y25yAdN9HHppv4FJ7E+V rg8Nhgc/den4h7Cno+BPHuSsr36+WrAeaBvpzVALAn+WCYohN1DFCsB4DXpAckZL fGn9elEsgPB2+hFbBwjL17P6nqxnm/POXR0zQdT+14KeUalZ6MKlk1nBAHLYPMzf AXBHWsaseho97F1XFBFK9hV8Kz2WkHtIaSq7kev6vmOAy27UPPVDiOIWjtwJhbL9 aKSAz9/hZ5+gJFtw3v/RsWqVCERTHuDp4b8unVFshoLzDv0ThmvOHAX0pp10eGJ+ hpWkuweMtt+DPi/VwQRIsCHKaYzIlW1n/Ln2hrpvQ4mnthTCdRE/AnSZBs14ZYo= =cc6M -----END PGP SIGNATURE----- --DJ89LnlOiUe5bk6vEhfiXHrvCsRxtFI1b-- From nobody Fri Apr 24 06:32:40 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB161A8745 for ; Fri, 24 Apr 2015 03:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 R7TpOBfYVoIN for ; Fri, 24 Apr 2015 03:28:47 -0700 (PDT) Received: from nok-msg-3.service.capgemini.fi (nok-msg-3.service.capgemini.fi [145.247.12.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A6F1A872D for ; Fri, 24 Apr 2015 03:28:46 -0700 (PDT) Received: from unknown (HELO NOKWDCFIEXCH02P.nnok.nokia.com) ([10.50.38.50]) by noi-msg-3.service.capgemini.fi with ESMTP; 24 Apr 2015 13:28:44 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 24 Apr 2015 13:28:44 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.1044.021; Fri, 24 Apr 2015 13:28:44 +0300 From: "Savolainen Teemu (Nokia-TECH/Tampere)" To: ext Jouni Korhonen , "" Thread-Topic: Review of draft-ietf-6lo-btle Thread-Index: AQHQd9qVbGrrbxOxwE+f7d/vCL1tyZ1XXE4wgAByBACABDPY8A== Date: Fri, 24 Apr 2015 10:28:43 +0000 Message-ID: References: <552EFF48.7000806@gmail.com> <93999e54a39d4b2b8d3b67eac98e00e3@NOKWDCFIEXCH02P.nnok.nokia.com> <5536BDB8.60804@gmail.com> In-Reply-To: <5536BDB8.60804@gmail.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.50.32.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 24 Apr 2015 06:32:39 -0700 Cc: "volz@cisco.com" , "draft-ietf-6lo-btle@tools.ietf.org" , Christopher LILJENSTOLPE Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 24 Apr 2015 10:28:49 -0000 Pkkgc3RpbGwgZmluZCB0aGUgd29yZGluZyBjb25mdXNpbmcuIExldCBtZSB0cnk6DQo+ICAgICAg Qmx1ZXRvb3RoIExFIGRvZXMgbm90IHN1cHBvcnQgZGV2aWNlIGFkZHJlc3MgY29sbGlzaW9uIGF2 b2lkYW5jZQ0KPiAgICAgIG9yIGRldGVjdGlvbi4gSG93ZXZlciwgdGhlc2UgNDggYml0IHJhbmRv bSBkZXZpY2UgYWRkcmVzc2VzIGhhdmUgYQ0KPiAgICAgIHZlcnkgc21hbGwgcHJvcGFiaWxpdHkg b2YgYmVpbmcgaW4gY29uZmxpY3Qgd2l0aGluIGEgdHlwaWNhbA0KPiAgICAgIGRlcGxveW1lbnQu DQoNCkkgdXNlZCB0aGF0IHdpdGggYWRkaXRpb24gb2YgZGV0YWlsIGluZGljYXRpbmcgdGhhdCB0 aGlzIHJhbmRvbWl6YXRpb24gdHlwaWNhbGx5IGhhcHBlbnMgd2hlbiBwb3dlciBjeWNsZSBvY2N1 cnM6DQoNClRoZSByYW5kb20gZGV2aWNlIGFkZHJlc3NlcyBhcmUgZ2VuZXJhdGVkIGFzIGRlZmlu ZWQgaW4gdGhlIEJsdWV0b290aCBzcGVjaWZpY2F0aW9uLiBUaGlzIHR5cGljYWxseQ0KaGFwcGVu cyBhdCBldmVyeSBwb3dlciBjeWNsZSBvZiBhIGRldmljZS4gSW4gcmFuZG9tIGFkZHJlc3NlcyBh bGwgNDggYml0cyBhcmUgcmFuZG9taXplZC4gDQpCbHVldG9vdGggTEUgZG9lcyBub3Qgc3VwcG9y dCBkZXZpY2UgYWRkcmVzcyBjb2xsaXNpb24gYXZvaWRhbmNlIG9yIGRldGVjdGlvbi4gSG93ZXZl ciwgDQp0aGVzZSA0OCBiaXQgcmFuZG9tIGRldmljZSBhZGRyZXNzZXMgaGF2ZSBhIHZlcnkgc21h bGwgcHJvYmFiaWxpdHkgb2YgYmVpbmcgaW4gY29uZmxpY3Qgd2l0aGluIGEgdHlwaWNhbA0KZGVw bG95bWVudC4NCg0KPj4gSW4gdGhlIHJhcmUgY2FzZSBvZiBCbHVldG9vdGggTEUgcmFuZG9tIGRl dmljZSBhZGRyZXNzIGNvbmZsaWN0LCBhIA0KPj4gNkxCUg0KPj4gY2FuIGRldGVjdCBtdWx0aXBs ZSA2TE5zIHdpdGggdGhlIHNhbWUgQmx1ZXRvb3RoIExFIGRldmljZSBhZGRyZXNzIG9yIDZMTnMg IHdpdGggdGhlIHNhbWUgYWRkcmVzcyB0aGUgNkxCUiBpcyB1c2luZy4gVGhlIDZMQlIgTVVTVCBp Z25vcmUgNkxOcyB3aXRoICA+IHRoZSBzYW1lIGRldmljZSBhZGRyZXNzIHRoZSA2TEJSIGhhcywg YW5kIHRoZSA2TEJSIE1VU1QgaGF2ZSBhdCBtb3N0IG9uZSAgPiBjb25uZWN0aW9uIGZvciBhIGdp dmVuIEJsdWV0b290aCBMRSBkZXZpY2UgYWRkcmVzcyBhdCBhbnkgZ2l2ZW4gbW9tZW50Lg0KPj4g LS0NCj5XRk0uDQoNClR1bmVkIGEgYml0IG1vcmU6DQoNCkluIHRoZSByYXJlIGNhc2Ugb2YgQmx1 ZXRvb3RoIExFIHJhbmRvbSBkZXZpY2UNCmFkZHJlc3MgY29uZmxpY3QsIGEgNkxCUiBjYW4gZGV0 ZWN0IG11bHRpcGxlIDZMTnMgd2l0aCB0aGUgc2FtZSBCbHVldG9vdGggTEUgZGV2aWNlIGFkZHJl c3MsIGFzIHdlbGwgYXMgYSA2TE4NCndpdGggdGhlIHNhbWUgQmx1ZXRvb3RoIExFIGFkZHJlc3Mg YXMgdGhlIDZMQlIuIFRoZSA2TEJSIE1VU1QgaWdub3JlIDZMTnMgd2l0aCB0aGUgc2FtZSBkZXZp Y2UgYWRkcmVzcyB0aGUgNkxCUiBoYXMsIGFuZCB0aGUgNkxCUiBNVVNUIA0KaGF2ZSBhdCBtb3N0 IG9uZSBjb25uZWN0aW9uIGZvciBhIGdpdmVuIEJsdWV0b290aCBMRSBkZXZpY2UgYWRkcmVzcyBh dA0KYW55IGdpdmVuIG1vbWVudC4NCg0KQmVzdCByZWdhcmRzLA0KDQoJVGVlbXUNCg== From nobody Fri Apr 24 07:42:21 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68E31A6F11 for ; Fri, 24 Apr 2015 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 XK7M5FSixOun for ; Fri, 24 Apr 2015 07:42:17 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 984D71A6EF9 for ; Fri, 24 Apr 2015 07:42:17 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so50514626pac.1 for ; Fri, 24 Apr 2015 07:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pGuiNYP8YOyNr6ODr1zp45equ9ipEBUFKR9RYWtmokw=; b=ba0QGz5GSugTayTcftLZ4xzTxKnuiUJo8N9TYRspn1lLfnvcU8NLzDTspGNlywPw8J XGLj1mhgaTMtJ1uXiqJP7wA4yScFtgIR9e/1OnoCXmq4IcNby/EjNdIVrmopSKWyBLCT v9ic0A9GmX+OTuvGzlhhBX0y358MGYehtKNG/WO8WzoaaVxtfiV6lrqJM/LW/EK4VGlN w3qnUapEhaGjRn0XGGzi4iEl5bJc7nVqdk8jCArMDzoATXCOZmPcW3szX9hTK9+hq/fu 8B/4KEsf8S2ypKeQyu6MuBC8UlXq4UgV1XcGtEEgHvN06X8N7TzE+Xc0oU9W5kTGczox vjTw== X-Received: by 10.70.129.106 with SMTP id nv10mr6989337pdb.160.1429886537291; Fri, 24 Apr 2015 07:42:17 -0700 (PDT) Received: from [10.0.0.17] (c-73-202-54-75.hsd1.ca.comcast.net. [73.202.54.75]) by mx.google.com with ESMTPSA id xz3sm5410833pbc.13.2015.04.24.07.42.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Apr 2015 07:42:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jouni In-Reply-To: Date: Fri, 24 Apr 2015 07:42:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <552EFF48.7000806@gmail.com> <93999e54a39d4b2b8d3b67eac98e00e3@NOKWDCFIEXCH02P.nnok.nokia.com> <5536BDB8.60804@gmail.com> To: "Savolainen Teemu (Nokia-TECH/Tampere)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Christopher LILJENSTOLPE , "volz@cisco.com" , "draft-ietf-6lo-btle@tools.ietf.org" , "" Subject: Re: [Int-dir] Review of draft-ietf-6lo-btle X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 24 Apr 2015 14:42:19 -0000 > On 24 Apr 2015, at 03:28, Savolainen Teemu (Nokia-TECH/Tampere) = wrote: >=20 >> I still find the wording confusing. Let me try: >> Bluetooth LE does not support device address collision avoidance >> or detection. However, these 48 bit random device addresses have = a >> very small propability of being in conflict within a typical >> deployment. >=20 > I used that with addition of detail indicating that this randomization = typically happens when power cycle occurs: >=20 > The random device addresses are generated as defined in the Bluetooth = specification. This typically > happens at every power cycle of a device. In random addresses all 48 = bits are randomized.=20 > Bluetooth LE does not support device address collision avoidance or = detection. However,=20 > these 48 bit random device addresses have a very small probability of = being in conflict within a typical > deployment. Better and works for me.. The power cycle thing pretty much voids all = cleans ways to react to address collisions. >=20 >>> In the rare case of Bluetooth LE random device address conflict, a=20= >>> 6LBR >>> can detect multiple 6LNs with the same Bluetooth LE device address = or 6LNs with the same address the 6LBR is using. The 6LBR MUST ignore = 6LNs with > the same device address the 6LBR has, and the 6LBR MUST = have at most one > connection for a given Bluetooth LE device address = at any given moment. >>> -- >> WFM. >=20 > Tuned a bit more: >=20 > In the rare case of Bluetooth LE random device > address conflict, a 6LBR can detect multiple 6LNs with the same = Bluetooth LE device address, as well as a 6LN > with the same Bluetooth LE address as the 6LBR. The 6LBR MUST ignore = 6LNs with the same device address the 6LBR has, and the 6LBR MUST=20 > have at most one connection for a given Bluetooth LE device address at > any given moment. This is ok. Thanks, Jouni >=20 > Best regards, >=20 > Teemu From nobody Sun Apr 26 20:32:46 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DCE1B2850 for ; Sun, 26 Apr 2015 20:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o277xN2DYEfn for ; Sun, 26 Apr 2015 20:32:43 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE71AD373 for ; Sun, 26 Apr 2015 20:32:43 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sun, 26 Apr 2015 20:32:41 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Sun, 26 Apr 2015 20:32:41 -0700 From: Terry Manderson To: Brian Haberman , "int-dir@ietf.org" Thread-Topic: [Int-dir] Int Area Directorate Review requests Thread-Index: AdB92M9A28fg+HPLSOSoBXLVuSSuLgAO1ScAAAL3qQAAwlJ8gA== Date: Mon, 27 Apr 2015 03:32:40 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1CA90F0B@xmb-rcd-x04.cisco.com> <1429802622577-021ed14c-375aa6dc-72c98232@asgaard.org> <55392262.7050102@innovationslab.net> In-Reply-To: <55392262.7050102@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3512986357_45706355" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] Int Area Directorate Review requests X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 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, 27 Apr 2015 03:32:45 -0000 --B_3512986357_45706355 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Landed back home, almost over jetlag, catching up on backlog. I think a default of 14 days is perfect and by default I will be passing every draft from the WGs I am responsible for via int-dir. Terry On 24/04/2015 2:48 am, "Brian Haberman" wrote: >A 14-day window seems reasonable to me and if we need something >different, we will let you know. > >Thanks, >Brian > >On 4/23/15 11:23 AM, christopher liljenstolpe wrote: >> Agreed. AD's let us know if a given request needs a +/- to the 14 day >>rule >> >> On Thu, Apr 23, 2015 at 8:21 AM, Bernie Volz (volz) < volz@cisco.com >> [volz@cisco.com] > wrote: >> Hi: >> >> I think going forward we should assume that each review is to be >>completed >> within 2 weeks (14 calendar days) OF THE REQUEST unless otherwise >> indicated in >> the review request. I believe Terry or Brian usually starts these when >>the >> document is submitted for publication and the 2 weeks would overlap the >> IETF >> last call process (+/- a few days). >> >> Note that this may result in less than 2 weeks for the member to review >> given >> the process (as it could take a few days to confirm a reviewer). >> >> - Bernie >> >> >> _______________________________________________ >> Int-dir mailing list >> Int-dir@ietf.org >> https://www.ietf.org/mailman/listinfo/int-dir >> > --B_3512986357_45706355 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFK3X vudc9fd4Pp9bD1X8ZRC8/NXhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDQyNzAzMzIzN1owDQYJKoZIhvcNAQEBBQAEggEAG63+jwwNrH8RU5Sj61Es My+De6ArBVzLtevLVBDAko6V69Zuh5sj2gqR5TIdEbFYYxQTsnwihefyAJv+VgYUiqzD+G/8 TW1UPeqrHUwSHfVN0IY7XuaiZDni1LeT2d+4mC1wnSqfj+jYURMSlROKNHA6x9Cwway30/Xv +3ZL2YjbR6comS/Ou0/GznGK4TpOAk4LnFPmM8vkMT7eV9sl64xsqsMt7VoYqKWAG2qUAVGr qirKvnF9+wakOcQC2kS4v6GdNIY1pTEqw5SeNViYbcKJbxqsjEnDo5AkskJHz5Nm9MlVAbFn j7EqcoLJ2a7hZVv5xrdxDaH2+c6S2fiOCA== --B_3512986357_45706355--