From nobody Mon Dec 1 06:05:39 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB701A1BD4; Mon, 1 Dec 2014 06:05:25 -0800 (PST) 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 gbXUegD3IiS0; Mon, 1 Dec 2014 06:05:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1781A1BD7; Mon, 1 Dec 2014 06:05:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201140518.15998.35426.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 06:05:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Jph97qWMvNxpgp8QOUJiiPxwEE4 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 14:05:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-06.txt Pages : 31 Date : 2014-12-01 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 1 09:03:58 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB81A6FFA; Mon, 1 Dec 2014 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 JMOE7B1RuovV; Mon, 1 Dec 2014 09:03:54 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0A81A6FA9; Mon, 1 Dec 2014 09:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sB1H3j8F005191; Mon, 1 Dec 2014 18:03:45 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D55A331; Mon, 1 Dec 2014 18:03:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: Date: Mon, 1 Dec 2014 18:03:43 +0100 X-Mao-Original-Outgoing-Id: 439146223.499436-2156969aa0126bde1b27d069e54934b3 Content-Transfer-Encoding: quoted-printable Message-Id: <3CFC155E-AC8C-41B2-94C1-CDD30A64ECFD@tzi.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <239401C5-C9B7-4368-8008-164F902C68AD@tzi.org> To: Martin Turon X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HK2LPVi9iU3I99J4gklyswnn1Mc Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 17:03:56 -0000 On 01 Dec 2014, at 17:52, Martin Turon wrote: >=20 > Hi Carsten, >=20 > Yes, section 11 refers to the mesh header defined in section 5, but = does not claim exclusive use of it. No, but then section 5.2 points to section 11 for further explanation = what the Mesh Header is about. > My point really is to inspire people to rethink the long held dogma = that the mesh header and mesh-under are synonymous, and counter proposed = text that codifies that view. What I was trying to say is that 4944 was written from that view, and, = while it is interesting to open up the semantics of the header, this = would actually be a change already. > They need not be viewed that way, and my reading of RFC4944 doesn't = mandate that the two be equivalent. In fact, "Appendix A. Alternatives = for Delivery of Frames in a Mesh", covers some of the alternate use = cases, design ideas, and pros/cons of using the mesh header at layer 2 = or 3. Right. The problem really is that 4944=E2=80=99s Mesh Header is very = inflexible: It only provides (1) a (limited) hop count, (2) a source MAC = address, and (3) a destination MAC address. Whether that is useful = depends a lot on what your meshing protocol does; 4944 was rather = speculative here. Pascal=E2=80=99s idea is to open up the Mesh Header and make it = extensible, so it can still carry the three items the old Mesh Header = could carry, but can add and remove items, as needed by the forwarding = mechanism. This is achieved by going the TLV route. It would be rather = inefficient to leave the old inflexible Mesh Header consuming 1/3 of the = dispatch space, requiring more bytes for the new one: so Pascal proposes = reusing the space in networks configured that way. (RFC7400 6CIOs might be useful for achieving that configuration in an = automatic way, or not; this hasn=E2=80=99t been thought through.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 1 10:17:34 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882D1A87CD; Mon, 1 Dec 2014 10:17:25 -0800 (PST) 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 HybeBeDVtunT; Mon, 1 Dec 2014 10:17:21 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan38.extendcp.co.uk [176.32.230.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0EC1A87D2; Mon, 1 Dec 2014 10:16:47 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XvVWf-00061M-68; Mon, 01 Dec 2014 18:16:45 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XvVWd-0003SA-AJ; Mon, 01 Dec 2014 18:16:45 +0000 Received: from host86-167-76-190.range86-167.btcentralplus.com ([86.167.76.190] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XvVWb-0004hs-RW; Mon, 01 Dec 2014 18:16:42 +0000 Message-ID: <547CB095.8050709@gridmerge.com> Date: Mon, 01 Dec 2014 18:16:53 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020600050303060302020402" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/v8R1e_adow07NTL5rJCLU6RYeQw Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:17:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020600050303060302020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Pascal, I agree that with hindsight it could be considered a bit greedy of=20 RFC4944 to allocate 1/3 of the dispatch code space to the mesh header=20 (especially when the definition of it itself is questionable) but what=20 you are advocating is a replacement, not a framework extension. RFC6282=20 only deprecated an ESC code, i.e. something which had not yet been used, = which is not quite the same. This effectively makes this at best a new=20 version of 6lowpan (which is difficult to distinguish) or at worst=20 arguably a whole new protocol. Whilst hindsight is a wonderful thing, it can lead to the situation=20 where a standard never stands still and keeps evolving. This makes it=20 very difficult to develop products as there is always the fear that=20 something will change the next year. Upgrading products is often quite a = difficult process, especially in the case where there could quite=20 feasibly be thousands of deployed devices which may have limited upgrade = capability. I would like to hear what other people think about this. Also a comment re. section 8, I think the 'I' field needs to be 1, as=20 'Size' represents the HopsLft field, not the size of the header. It also = doesn't seem to cover the Deep Hops Left concept in RFC4944. Robert On 27/11/2014 2:03 PM, Pascal Thubert (pthubert) wrote: > Dear all: > > This is a response to the question about the compression of RFC 6553 on= top of RFC 6554. > It seems exaggerated to consume a dispatch type for the RPL option only= =2E > But here, we introduce a routing header which is the equivalent of the = mesh header in RFC 4944; we propose a compressed TLV format that can enco= de RH3, RPL option, IP-in-IP, and is further extensible, for instance for= upcoming BIER. > As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable= space for application only in Mesh-under. > This draft reuses that space in Route-over with the assumption that Rou= te-over will not co-exist in a sma enetwork with Mesh-under encoded in th= e RFC 4944 fashion. > If there is effectively a need for co-existence, devices have to implem= ent the new Mesh-under format that is also proposed in the draft. > > Comments welcome, > Pascal > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: jeudi 27 novembre 2014 14:36 > To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Touta= in; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann > Subject: New Version Notification for draft-thubert-6lo-routing-dispatc= h-00.txt > > > A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt > has been successfully submitted by Pascal Thubert and posted to the IET= F repository. > > Name: draft-thubert-6lo-routing-dispatch > Revision: 00 > Title: A Routing Header Dispatch for 6LoWPAN > Document date: 2014-11-25 > Group: Individual Submission > Pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-r= outing-dispatch-00.txt > Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-rout= ing-dispatch/ > Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-di= spatch-00 > > > Abstract: > This specification provides a new 6LoWPAN dispatch type for use in > Route-over and mixed Mesh-under and Route-over topologies, that > reuses the encoding of the mesh type defined in RFC 4944 for pure > Mesh-under topologies. This specification also defines a method to= > compress RPL Option (RFC6553) information and Routing Header type 3= > (RFC6554), an efficient IP-in-IP technique and opens the way for > further routing techniques. This extends 6LoWPAN Transmission of > IPv6 Packets (RFC4944), and is applicable to new link-layer types > where 6LoWPAN is being defined. > > = =20 > > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org= =2E > > The IETF Secretariat > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --------------ms020600050303060302020402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDEyMDExODE2NTNaMCMGCSqGSIb3DQEJBDEWBBS4+0bpZxIW4WclOrvryEtLW254zjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBJk+TIPDVFgHJseF11kH8241cgKu8iz0tR 8ERQ2WP4UNMcbYrH9mnDXl7c6rZiBp29N+lA9E0qYca/n0t554tATu0w5p4xeV+OSZLrGEIG vr9SaxN9QuDLDxsR63t1mhsSkJAuJNj4QRUxcJS+WocslshaqvUU1kfWM281xF+l4SkTh75P jYFZz7tGHmVIhw7DMyrx3L36R8vvFTxVeZpJiVNbpxv+TyeI2RIl6yaeh2K+LQNQfnJSBy+q HzoMU+hc8PQughwRog/Fwrl5A9SCq2GzMmW8hkCUEexA2DT8sAd1CtO74FVykkHSHXaKJzPs UC01k9kh/csKW5aywRHLAAAAAAAA --------------ms020600050303060302020402-- From nobody Mon Dec 1 10:51:15 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B781A6F2E for ; Mon, 1 Dec 2014 08:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 G-WL-PPCnb5H for ; Mon, 1 Dec 2014 08:17:41 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64DA1A6F20 for ; Mon, 1 Dec 2014 08:17:40 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rp18so9357928iec.24 for ; Mon, 01 Dec 2014 08:17:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j/oZfQjb6VR2G54q5zNrEbV74jEhpLvC5oxEHSNpC1k=; b=XP6XTNi57hAnlMAS1IsovJkHJrz77bW0c+/4r1H0urvTjJCPM132PQ63oH1dmV//Rx X18PL5tMktlVf+VA00ha1XG/sgliLGu7TMQ+snqqdPNj4qsZPYro0weMAnFK2kHpBSAv QI9Is4l8ub/x7TBgDEJ4AGUVwgFN2wa2mkBR8ZtWtQTZcdLzwB9BRac/0rPZ2F/vOaJh xUal0VT0J6+7fQ90eOpdxTiWUlvrDmRL9JdijhrzJCgL3WMFugNTMi2PEvKVP8x3D/PB KX2etYU1ypkrASVBZBag8a0kvcpqXyTVGnhLrcsT0Jo2etLUkngH6JSww2j0Fb5o6IDq 3IZg== X-Gm-Message-State: ALoCoQkQIgZiELIXAs7cZbQpJpzkESzQStB+ox/qwj1zAVJafDGWtk9jH85r3rvC8KWlJUb17yAq MIME-Version: 1.0 X-Received: by 10.107.5.76 with SMTP id 73mr16183299iof.74.1417450659925; Mon, 01 Dec 2014 08:17:39 -0800 (PST) Received: by 10.42.128.72 with HTTP; Mon, 1 Dec 2014 08:17:39 -0800 (PST) In-Reply-To: <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> Date: Mon, 1 Dec 2014 08:17:39 -0800 Message-ID: From: Martin Turon To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a113ef748128ed2050929f33d Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qk2bifADlVgBsw_XJBjkBABBxmQ X-Mailman-Approved-At: Mon, 01 Dec 2014 10:51:10 -0800 Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 16:17:45 -0000 --001a113ef748128ed2050929f33d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Pascal, On Sun, Nov 30, 2014 at 12:59 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > The discussion already caused a rethinking of the idea. If it is not > enough we can dig further. > Ok, this is certainly reassuring. I'll admit my initial reaction to the draft was based more on the understanding of intent from the call than on a thorough read of the text. Some of the initial text describes reassigning the 10 bits that signal a mesh header, and that spawned the concern. > The idea as presented in the draft now is not to deprecate the mesh heade= r > but to allow in a different network to use the bits differently knowing > that devices will have to be homogeneous inside one network. > Yes, providing a path to not preclude existing mesh header networks to live on in isolation is certainly a requirement. That mixed networks would have to adopt this new draft seems reasonable. > You were the advocate to protect the future by not consuming too many bit= s > in the NHC proposal. You also realize that the mesh header consumes 1/3 o= f > the whole dispatch space, without a way to extend what's done inside. Thi= s > is not protecting the future. > I won't argue with you there. I remain an advocate for protecting the future, while not overtly forcing deprecation on existing deployments. Given a a clear upgrade path, and proper forward support path for mesh header networks, your proposal certainly deserves proper review and consideration. > The new proposal allows to encode the existing MH with limited change but > now it is extensible. The price to pay is different network. And the > question to the group is whether that is acceptable. > Splitting old and new across different networks is certainly reasonable. One question inspired by this is how would newer dispatch implementations deploy to a legacy dispatch network? Imagine a large open network spanning a city, with multiple versions of 6lo, and multiple routing protocols running on top. It's a very academic, futuristic example, but triggers some basic questions like: how is versioning handled in 6lo? I believe versioning in 6lo currently is always done at deployment time. It may be worth considering a way to add an optional version dispatch in RHI to signal what version of 6lo is being used, so mixed version networks in the future can have a better chance of coexisting. > Even if there are implementations today, RFC 4944 is not an internet std > and we have just seen the very beginning of the IoT. Better fix things no= w > than later... > Only HC1 and HC2 were deprecated from RFC4944 as far as I know. Deprecating those was the right decision. There may be more in RFC4944 that can be changed or improved, but the point is that the assumption must be that most of it is in use today, and consideration for those networks that use it should be made. It sounds like you have been making those considerations, which is appreciated. Martin > Pascal > > > Le 29 nov. 2014 =C3=A0 20:24, Martin Turon a =C3= =A9crit : > > > > Hi Pascal, > > > > I thought the call where this idea of overloading the mesh header was > presented was met with general discontent. > > > > Also, the rfc4944 calls it the mesh header, it isn't called the > mesh-under header. The mesh header is very much in use today, and not > purely for mesh-under conceptual designs. > > > > I would be wary of proposals that greatly alter the 6lo header, > especially the dispatch bits, rather than extend it in very general ways. > > > > Martin > > > >> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" < > pthubert@cisco.com> wrote: > >> > >> Dear all: > >> > >> This is a response to the question about the compression of RFC 6553 o= n > top of RFC 6554. > >> It seems exaggerated to consume a dispatch type for the RPL option onl= y. > >> But here, we introduce a routing header which is the equivalent of the > mesh header in RFC 4944; we propose a compressed TLV format that can enco= de > RH3, RPL option, IP-in-IP, and is further extensible, for instance for > upcoming BIER. > >> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressabl= e > space for application only in Mesh-under. > >> This draft reuses that space in Route-over with the assumption that > Route-over will not co-exist in a sma enetwork with Mesh-under encoded in > the RFC 4944 fashion. > >> If there is effectively a need for co-existence, devices have to > implement the new Mesh-under format that is also proposed in the draft. > >> > >> Comments welcome, > >> Pascal > >> > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: jeudi 27 novembre 2014 14:36 > >> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent > Toutain; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann > >> Subject: New Version Notification for > draft-thubert-6lo-routing-dispatch-00.txt > >> > >> > >> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt > >> has been successfully submitted by Pascal Thubert and posted to the > IETF repository. > >> > >> Name: draft-thubert-6lo-routing-dispatch > >> Revision: 00 > >> Title: A Routing Header Dispatch for 6LoWPAN > >> Document date: 2014-11-25 > >> Group: Individual Submission > >> Pages: 19 > >> URL: > http://www.ietf.org/internet-drafts/draft-thubert-6lo-routing-dispatch-00= .txt > >> Status: > https://datatracker.ietf.org/doc/draft-thubert-6lo-routing-dispatch/ > >> Htmlized: > http://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-00 > >> > >> > >> Abstract: > >> This specification provides a new 6LoWPAN dispatch type for use in > >> Route-over and mixed Mesh-under and Route-over topologies, that > >> reuses the encoding of the mesh type defined in RFC 4944 for pure > >> Mesh-under topologies. This specification also defines a method to > >> compress RPL Option (RFC6553) information and Routing Header type 3 > >> (RFC6554), an efficient IP-in-IP technique and opens the way for > >> further routing techniques. This extends 6LoWPAN Transmission of > >> IPv6 Packets (RFC4944), and is applicable to new link-layer types > >> where 6LoWPAN is being defined. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch > --001a113ef748128ed2050929f33d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pascal,


On Sun, Nov 30, 2014 at 12:59 AM, Pasca= l Thubert (pthubert) <pthubert@cisco.com> wrote:
The discussion already caused a rethinking of the idea. If it is = not enough we can dig further.

Ok, this= is certainly reassuring.=C2=A0 I'll admit my initial reaction to the d= raft was based more on the understanding of intent from the call than on a = thorough read of the text.=C2=A0 Some of the initial text describes reassig= ning the 10 bits that signal a mesh header, and that spawned the concern.
=C2=A0
The idea as presented in the draft now is not to deprecate the mesh header = but to allow in a different network to use the bits differently knowing tha= t devices will have to be homogeneous inside one network.
<= div>
Yes, providing a path to not preclude existing mesh head= er networks to live on in isolation is certainly a requirement.=C2=A0 That = mixed networks would have to adopt this new draft seems reasonable. =C2=A0= =C2=A0
=C2=A0
You were the advocate to protect the future by not consuming too many bits = in the NHC proposal. You also realize that the mesh header consumes 1/3 of = the whole dispatch space, without a way to extend what's done inside. T= his is not protecting the future.

I won= 't argue with you there.=C2=A0 I remain an advocate for protecting the = future, while not overtly forcing deprecation on existing deployments.=C2= =A0 Given a a clear upgrade path, and proper forward support path for mesh = header networks, your proposal certainly deserves proper review and conside= ration. =C2=A0 =C2=A0=C2=A0
=C2=A0
The new proposal allows to encode the existing MH with limited change but n= ow it is extensible. The price to pay is different network. And the questio= n to the group is whether that is acceptable.

Splitting old and new across different networks is certainly reasona= ble.

One question inspired by this is how would ne= wer dispatch implementations deploy to a legacy dispatch network?=C2=A0 Ima= gine a large open network spanning a city, with multiple versions of 6lo, a= nd multiple routing protocols running on top.=C2=A0 It's a very academi= c, futuristic example, but triggers some basic questions like: how is versi= oning handled in 6lo?=C2=A0 I believe versioning in 6lo currently is always= done at deployment time.=C2=A0 It may be worth considering a way to add an= optional version dispatch in RHI to signal what version of 6lo is being us= ed, so mixed version networks in the future can have a better chance of coe= xisting.
=C2=A0
Even if there are implementations today, RFC 4944 is not an internet std an= d we have just seen the very beginning of the IoT. Better fix things now th= an later...

Only HC1 and HC2 were depre= cated from RFC4944 as far as I know.=C2=A0 Deprecating those was the right = decision.=C2=A0 There may be more in RFC4944 that can be changed or improve= d, but the point is that the assumption must be that most of it is in use t= oday, and consideration for those networks that use it should be made.=C2= =A0 It sounds like you have been making those considerations, which is appr= eciated.

Martin
=C2=A0
Pascal

> Le 29 nov. 2014 =C3=A0 20:24, Martin Turon <mturon@nestlabs.com> a =C3=A9crit :
>
> Hi Pascal,
>
> I thought the call where this idea of overloading the mesh header was = presented was met with general discontent.
>
> Also, the rfc4944 calls it the mesh header, it isn't called the me= sh-under header.=C2=A0 The mesh header is very much in use today, and not p= urely for mesh-under conceptual designs.
>
> I would be wary of proposals that greatly alter the 6lo header, especi= ally the dispatch bits, rather than extend it in very general ways.
>
> Martin
>
>> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)"= <pthubert@cisco.com> wrote= :
>>
>> Dear all:
>>
>> This is a response to the question about the compression of RFC 65= 53 on top of RFC 6554.
>> It seems exaggerated to consume a dispatch type for the RPL option= only.
>> But here, we introduce a routing header which is the equivalent of= the mesh header in RFC 4944; we propose a compressed TLV format that can e= ncode RH3, RPL option, IP-in-IP, and is further extensible, for instance fo= r upcoming=C2=A0 BIER.
>> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addres= sable space for application only in Mesh-under.
>> This draft reuses that space in Route-over with the assumption tha= t Route-over will not co-exist in a sma enetwork with Mesh-under encoded in= the RFC 4944 fashion.
>> If there is effectively a need for co-existence, devices have to i= mplement the new Mesh-under format that is also proposed in the draft.
>>
>> Comments welcome,
>> Pascal
>>
>>
>> -----Original Message-----
>> From: internet-drafts@= ietf.org [mailto:internet-d= rafts@ietf.org]
>> Sent: jeudi 27 novembre 2014 14:36
>> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent = Toutain; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann
>> Subject: New Version Notification for draft-thubert-6lo-routing-di= spatch-00.txt
>>
>>
>> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt >> has been successfully submitted by Pascal Thubert and posted to th= e IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-thubert-6lo-routing-dispatc= h
>> Revision:=C2=A0 =C2=A0 00
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 A Routing Header Dispatch for 6L= oWPAN
>> Document date:=C2=A0 =C2=A0 2014-11-25
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 19
>> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-thubert-6lo-routing-= dispatch-00.txt
>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-thubert-6lo-routing-dispatch/
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://too= ls.ietf.org/html/draft-thubert-6lo-routing-dispatch-00
>>
>>
>> Abstract:
>>=C2=A0 This specification provides a new 6LoWPAN dispatch type for = use in
>>=C2=A0 Route-over and mixed Mesh-under and Route-over topologies, t= hat
>>=C2=A0 reuses the encoding of the mesh type defined in RFC 4944 for= pure
>>=C2=A0 Mesh-under topologies.=C2=A0 This specification also defines= a method to
>>=C2=A0 compress RPL Option (RFC6553) information and Routing Header= type 3
>>=C2=A0 (RFC6554), an efficient IP-in-IP technique and opens the way= for
>>=C2=A0 further routing techniques.=C2=A0 This extends 6LoWPAN Trans= mission of
>>=C2=A0 IPv6 Packets (RFC4944), and is applicable to new link-layer = types
>>=C2=A0 where 6LoWPAN is being defined.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

--001a113ef748128ed2050929f33d-- From nobody Mon Dec 1 10:51:19 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BF21A6FCB for ; Mon, 1 Dec 2014 08:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 S3OjZJUOELSu for ; Mon, 1 Dec 2014 08:52:23 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155831A6FD0 for ; Mon, 1 Dec 2014 08:52:12 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id x19so9732928ier.41 for ; Mon, 01 Dec 2014 08:52:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eqGGUsBABGPMHo1KmZrWBT0ovBQDWdHc2StymoEdQrE=; b=KIHCEdns6l5Kzn0wAieJTD6xB5RVKc4Q/ZWXEI02hoMtqe3uiY3tgqnTlzNF59Majz 4t7rj3QufqrMu1eWJgYv/hVIeELkElN6vIfk+Sxwl46ceh5J2WyKYhANXp7PMQnfwMOD YBkOi6e3R6Zd5gqcD2UJeSOKWCyIzwLbTBazZIt5Q3Jk+1DcFUXhT7RTkhNckgI4n/18 f99r1gEXI9sfbJI+guTINd9B6GIaVliAVb9OI6Vk6leQihcaXbJkWTSS8aMlvgUSKrTM sLxItFE3LRJhxGVDjnoSjQJq0/xywn+matX1ix6mOpTvDulmwdHMgU98M/+FVV9H5Gwr qPVA== X-Gm-Message-State: ALoCoQlvvW17AYAVfW0AdncSkk9u2dBGHpae50DtzXiekxDi7WYwtvwBJvQXD/m3eVlgfqVdHYG8 MIME-Version: 1.0 X-Received: by 10.107.5.76 with SMTP id 73mr16370127iof.74.1417452730450; Mon, 01 Dec 2014 08:52:10 -0800 (PST) Received: by 10.42.128.72 with HTTP; Mon, 1 Dec 2014 08:52:10 -0800 (PST) In-Reply-To: <239401C5-C9B7-4368-8008-164F902C68AD@tzi.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <239401C5-C9B7-4368-8008-164F902C68AD@tzi.org> Date: Mon, 1 Dec 2014 08:52:10 -0800 Message-ID: From: Martin Turon To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113ef7487c517c05092a6e0c Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HqDH9XLnW6WRwDZV21ifICKqMVA X-Mailman-Approved-At: Mon, 01 Dec 2014 10:51:10 -0800 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 16:52:24 -0000 --001a113ef7487c517c05092a6e0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Yes, section 11 refers to the mesh header defined in section 5, but does not claim exclusive use of it. My point really is to inspire people to rethink the long held dogma that the mesh header and mesh-under are synonymous, and counter proposed text that codifies that view. They need not be viewed that way, and my reading of RFC4944 doesn't mandate that the two be equivalent. In fact, "Appendix A. Alternatives for Delivery of Frames in a Mesh", covers some of the alternate use cases, design ideas, and pros/cons of using the mesh header at layer 2 or 3. Martin On Sun, Nov 30, 2014 at 4:35 AM, Carsten Bormann wrote: > On 29 Nov 2014, at 20:24, Martin Turon wrote: > > > > The mesh header is very much in use today, and not purely for mesh-unde= r > conceptual designs. > > Hi Martin, > > I think it would benefit this discussion if we could learn more about > these use cases. > In RFC 4944, the =E2=80=9CMesh Header=E2=80=9D definitely was meant for m= esh-under; we > even have a section called > > 11. Frame Delivery in a Link-Layer Mesh*) > > to discuss the use of the Mesh Header in forwarding adaptation layer > packets between link-layer entities. But that of course doesn=E2=80=99t = mean there > aren=E2=80=99t other ways to make good use of the Mesh Header =E2=80=94 I= =E2=80=99d like to learn > more about those. > > Gr=C3=BC=C3=9Fe, Carsten > > *) The short forms =E2=80=9Cmesh-under=E2=80=9D and =E2=80=9Croute-over= =E2=80=9D weren=E2=80=99t as much in use in > 2007, so this is a long form trying to say =E2=80=9Cmesh-under=E2=80=9D. > > --001a113ef7487c517c05092a6e0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

Yes, section 11 refers to the mesh header defined in secti= on 5, but does not claim exclusive use of it.

My point really is to inspire peopl= e to rethink the long held dogma that the mesh header and mesh-under are sy= nonymous, and counter proposed text that codifies that view.

They need not be vie= wed that way, and my reading of RFC4944 doesn't mandate that the two be= equivalent.=C2=A0 In fact, "Appendix A. Alternatives for Delive= ry of Frames in a Mesh", covers some of the alternate use cases, desig= n ideas, and pros/cons of using the mesh header at layer 2 or 3.

Martin

On Sun, Nov 30= , 2014 at 4:35 AM, Carsten Bormann <cabo@tzi.org> wrote:
On 29 Nov 2014, at 20:24, Martin Turon <mturon@nestlabs.com> wrot= e:
>
> The mesh header is very much in use today, and not purely for mesh-und= er conceptual designs.

Hi Martin,

I think it would benefit this discussion if we could learn more about these= use cases.
In RFC 4944, the =E2=80=9CMesh Header=E2=80=9D definitely was meant for mes= h-under; we even have a section called

=C2=A0 11.=C2=A0 Frame Delivery in a Link-Layer Mesh*)

to discuss the use of the Mesh Header in forwarding adaptation layer packet= s between link-layer entities.=C2=A0 But that of course doesn=E2=80=99t mea= n there aren=E2=80=99t other ways to make good use of the Mesh Header =E2= =80=94 I=E2=80=99d like to learn more about those.

Gr=C3=BC=C3=9Fe, Carsten

*) The short forms =E2=80=9Cmesh-under=E2=80=9D and =E2=80=9Croute-over=E2= =80=9D weren=E2=80=99t as much in use in 2007, so this is a long form tryin= g to say =E2=80=9Cmesh-under=E2=80=9D.


--001a113ef7487c517c05092a6e0c-- From nobody Mon Dec 1 11:50:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44351A8ADA; Mon, 1 Dec 2014 11:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 cMoL095eJ9vp; Mon, 1 Dec 2014 11:50:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0651.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::651]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E31A1A8AD4; Mon, 1 Dec 2014 11:50:05 -0800 (PST) Received: from SN2PR0701MB1038.namprd07.prod.outlook.com (25.160.58.145) by SN2PR0701MB1039.namprd07.prod.outlook.com (25.160.58.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 1 Dec 2014 19:49:42 +0000 Received: from SN2PR0701MB1038.namprd07.prod.outlook.com ([25.160.58.145]) by SN2PR0701MB1038.namprd07.prod.outlook.com ([25.160.58.145]) with mapi id 15.01.0026.003; Mon, 1 Dec 2014 19:49:42 +0000 From: Richard Kelsey To: Routing Over Low power and Lossy networks , Martin Turon Thread-Topic: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQDHwRplMwidd3M0e2TQNMx932ZZx7JleN Date: Mon, 1 Dec 2014 19:49:42 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> , <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com>, <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> In-Reply-To: <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.236.254.7] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0701MB1039; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:SN2PR0701MB1039; x-forefront-prvs: 0412A98A59 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(189002)(199003)(377454003)(377424004)(24454002)(13464003)(95666004)(99396003)(15975445006)(120916001)(19580405001)(97736003)(99286002)(122556002)(40100003)(106116001)(15202345003)(77096004)(1720100001)(87936001)(105586002)(107046002)(101416001)(561944003)(86362001)(106356001)(33646002)(2656002)(46102003)(92566001)(4396001)(31966008)(76176999)(54356999)(50986999)(93886004)(21056001)(77156002)(62966003)(74316001)(2420400002)(19580395003)(20776003)(230783001)(76576001)(66066001)(64706001)(108616004)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0701MB1039; H:SN2PR0701MB1038.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: silabs.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/UqfNPWHv9dqru6YYmuMtT7ovhUU Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:50:09 -0000 Pascal, Given "we have just seen the very beginning of the IoT" and "... to allow in a different network to use the bits differently knowing that devices will have to be homogeneous inside one network." perhaps a better approach would be to define new 6LoWPAN encodings without nailing down where they go in the full space. Suppose this new draft instead of specifying meanings for 10xxxxxx specified a block of 64 consecutive encodings xxxxxx. If someone wants to use this new encoding and the 4944's MESH they could put the new encodings somewhere other than 10xxxxx. Or the MESH values somewhere else and put the new encodings at 10xxxxx. Allowing the actual codes used be determined by the network would avoid having to nail down which encodings were compatible with which other ones. You could mix and match. All a device needs to know is that encoding A starts at value N and encoding B starts at value M. In setting up a network the starting values could be chosen to make the dispatching bit-based as it is now, or some other scheme could be used. Just a thought. -Richard ________________________________________ From: Roll [roll-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [= pthubert@cisco.com] Sent: Sunday, November 30, 2014 3:59 AM Hi Martin, The discussion already caused a rethinking of the idea. If it is not enough= we can dig further. The idea as presented in the draft now is not to deprecate the mesh header = but to allow in a different network to use the bits differently knowing tha= t devices will have to be homogeneous inside one network. You were the advocate to protect the future by not consuming too many bits = in the NHC proposal. You also realize that the mesh header consumes 1/3 of = the whole dispatch space, without a way to extend what's done inside. This = is not protecting the future. The new proposal allows to encode the existing MH with limited change but n= ow it is extensible. The price to pay is different network. And the questio= n to the group is whether that is acceptable. Even if there are implementations today, RFC 4944 is not an internet std an= d we have just seen the very beginning of the IoT. Better fix things now th= an later... Pascal > Le 29 nov. 2014 =E0 20:24, Martin Turon a =E9crit : > > Hi Pascal, > > I thought the call where this idea of overloading the mesh header was pre= sented was met with general discontent. > > Also, the rfc4944 calls it the mesh header, it isn't called the mesh-unde= r header. The mesh header is very much in use today, and not purely for me= sh-under conceptual designs. > > I would be wary of proposals that greatly alter the 6lo header, especiall= y the dispatch bits, rather than extend it in very general ways. > > Martin > >> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" wrote: >> >> Dear all: >> >> This is a response to the question about the compression of RFC 6553 on = top of RFC 6554. >> It seems exaggerated to consume a dispatch type for the RPL option only. >> But here, we introduce a routing header which is the equivalent of the m= esh header in RFC 4944; we propose a compressed TLV format that can encode = RH3, RPL option, IP-in-IP, and is further extensible, for instance for upco= ming BIER. >> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable = space for application only in Mesh-under. >> This draft reuses that space in Route-over with the assumption that Rout= e-over will not co-exist in a sma enetwork with Mesh-under encoded in the R= FC 4944 fashion. >> If there is effectively a need for co-existence, devices have to impleme= nt the new Mesh-under format that is also proposed in the draft. >> >> Comments welcome, >> Pascal >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: jeudi 27 novembre 2014 14:36 >> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutai= n; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann >> Subject: New Version Notification for draft-thubert-6lo-routing-dispatch= -00.txt >> >> >> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt >> has been successfully submitted by Pascal Thubert and posted to the IETF= repository. >> >> Name: draft-thubert-6lo-routing-dispatch >> Revision: 00 >> Title: A Routing Header Dispatch for 6LoWPAN >> Document date: 2014-11-25 >> Group: Individual Submission >> Pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-ro= uting-dispatch-00.txt >> Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-routi= ng-dispatch/ >> Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-dis= patch-00 >> >> >> Abstract: >> This specification provides a new 6LoWPAN dispatch type for use in >> Route-over and mixed Mesh-under and Route-over topologies, that >> reuses the encoding of the mesh type defined in RFC 4944 for pure >> Mesh-under topologies. This specification also defines a method to >> compress RPL Option (RFC6553) information and Routing Header type 3 >> (RFC6554), an efficient IP-in-IP technique and opens the way for >> further routing techniques. This extends 6LoWPAN Transmission of >> IPv6 Packets (RFC4944), and is applicable to new link-layer types >> where 6LoWPAN is being defined. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Mon Dec 1 14:28:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01D71A8983 for ; Mon, 1 Dec 2014 11:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 3ZohYWV4VPbt for ; Mon, 1 Dec 2014 11:20:32 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4EC1A897C for ; Mon, 1 Dec 2014 11:20:30 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so4983354vcb.36 for ; Mon, 01 Dec 2014 11:20:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=rpiMxYYO9KCBNLlExb9YEMWMoiJfzao8RIVtGtkNhfU=; b=bQnubR0llM1qAdHqH59cy6OFf7a6AwqV6WnPRgvcv9NMJJcoNYa7AAK230Fy51E54L dMe8Pb+dUHQP7S5+t9jPUQ5K/laeyeoFm7TWjjYVOK1U2eGxVDNBS7lcsiCpG5rZtFS3 LuAlrOyvxgZ/eJF24YnpAQOrBgzXx3mia5WDIYFIWSd/sw+YPOtd5/FovofFI3Ocgbcq HJXAhNchiXxaWn4k/KzY0sQiZLRrT0C6dEtkX6Vect4mthnoNfoZ6NFyQuT/+I2T0FGo j4iRjGkRvV1OGTmUGr6PJLgTL0YlrLfOnjdas1jNWQPUvhu+XCQhtLxykG90kxjphRsN dQBg== X-Gm-Message-State: ALoCoQnZb2gx+MhR3aoqpZizBd/fUXDMJk8N6eIzmO+F6nNK0i0K8/RvZo2NQ7KDWLTLcD3hSDvo MIME-Version: 1.0 X-Received: by 10.221.4.73 with SMTP id ob9mr29722633vcb.13.1417461629287; Mon, 01 Dec 2014 11:20:29 -0800 (PST) Received: by 10.31.10.65 with HTTP; Mon, 1 Dec 2014 11:20:29 -0800 (PST) In-Reply-To: <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> Date: Mon, 1 Dec 2014 11:20:29 -0800 Message-ID: From: James Woodyatt To: "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e01160524e596b905092c80d8 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-NO-8pcN4CIouJtPcKYyI4-YVMQ X-Mailman-Approved-At: Mon, 01 Dec 2014 14:28:36 -0800 Subject: Re: [Roll] [6lo] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:20:34 -0000 --089e01160524e596b905092c80d8 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 30, 2014 at 12:59 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > [...] The new proposal allows to encode the existing MH with limited change but > now it is extensible. The price to pay is different network. And the > question to the group is whether that is acceptable. > I'm not sold... > Even if there are implementations today, RFC 4944 is not an internet std > and we have just seen the very beginning of the IoT. Better fix things now > than later... > According to the IETF Datatracker, RFC 4944 is a Proposed Standard, which puts it into the same category as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464 ], so I would never consider the fact that it doesn't have a STD number a good argument for ignoring back-compatibility with it. The statement "we have just seen the very beginning of the IoT" is a bit harder to get my hands around, but it sounds like a call for breaking existing deployments now while they are thought to be rare and not a very large sunk cost, which strikes me as a value judgment I would be wary about making. I agree with Martin that some consideration needs to be paid to version differentiation, at the very least, if we're going to consider deprecating the Mesh Header and replacing it with entirely different semantics, and even then, I may still not be sold. Shorter james: the draft doesn't seem acceptable to me at this time. Maybe I'm insufficiently frightened of the foreseeable consequences of rejecting it? -- james woodyatt Nest Labs, Communications Engineering --089e01160524e596b905092c80d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 30, 2014 at 12:59 AM, Pascal Thubert (pthubert) &= lt;pthubert@cisco.c= om> wrote:
[...]=C2=A0
The new proposal allows to encode th= e existing MH with limited change but now it is extensible. The price to pa= y is different network. And the question to the group is whether that is ac= ceptable.

I'm not sold...
=C2=A0
Even if there are implementations today, RFC 4944 is not an internet std an= d we have just seen the very beginning of the IoT. Better fix things now th= an later...

According to the IETF Datatracker, RFC 4944 is a Pro= posed Standard, which puts it into the same category as "Transmission = of IPv6 Packets over Ethernet Networks" [RFC 2464], so I would never consider the fact t= hat it doesn't have a STD number a good argument for ignoring back-comp= atibility with it.=C2=A0 The statement "we have just seen the very beg= inning of the IoT" is a bit harder to get my hands around, but it soun= ds like a call for breaking existing deployments now while they are thought= to be rare and not a very large sunk cost, which strikes me as a value jud= gment I would be wary about making.=C2=A0 I agree with Martin that some con= sideration needs to be paid to version differentiation, at the very least, = if we're going to consider deprecating the Mesh Header and replacing it= with entirely different semantics, and even then, I may still not be sold.=

Short= er james: the draft doesn't seem acceptable to me at this time. Maybe I= 'm insufficiently frightened of the foreseeable consequences of rejecti= ng it?


--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Com= munications Engineering
--089e01160524e596b905092c80d8-- From nobody Mon Dec 1 21:41:28 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ED91A00F8; Mon, 1 Dec 2014 21:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 mWxyGe1CYHV0; Mon, 1 Dec 2014 21:41:24 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10391A00BF; Mon, 1 Dec 2014 21:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sB25fKOO014781; Tue, 2 Dec 2014 06:41:20 +0100 (CET) Received: from [192.168.217.149] (p5489116E.dip0.t-ipconnect.de [84.137.17.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 188452C7; Tue, 2 Dec 2014 06:41:20 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: Date: Tue, 2 Dec 2014 06:41:17 +0100 X-Mao-Original-Outgoing-Id: 439191677.728692-52ef31a553036c03175302fd51915bd8 Content-Transfer-Encoding: quoted-printable Message-Id: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> To: James Woodyatt X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/oBQXg3wfzSm_n_QYZLgSDAtCLhM Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 05:41:25 -0000 On 01 Dec 2014, at 20:20, James Woodyatt wrote: >=20 > RFC 4944 is a Proposed Standard, which puts it into the same category = as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464],=20 That argument would be more convincing if the situations were indeed = comparable. RFC 2464 is the basis for widely deployed plug-and-play = interoperability. *That* is what makes it mostly immutable, not the standards status. (Which probably should be upgraded to match reality.) With RFC 4944, we haven=E2=80=99t reached that level of interoperability = yet. In particular, there is *no* way to achieve out-of-the-box = interoperability with the old mesh header =E2=80=94 there is no defined = way to use it, or even to find out that (and how) it should be used. So you already have to add configuration (as in, "use mesh forwarding = mechanism X") to use it. Pascal=E2=80=99s proposal does not change this situation one iota: It = doesn=E2=80=99t jeopardize interoperability where there was = interoperability before. (Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC = 4944 and replaced them with RFC 6282.) Again, I believe we need to learn more about those reported usages of = the old Mesh Header before we can meaningfully continue this argument. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 1 23:43:38 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D791A0154 for ; Mon, 1 Dec 2014 23:43:36 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 U6TOqMDLJcz1 for ; Mon, 1 Dec 2014 23:43:34 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7D41A015B for ; Mon, 1 Dec 2014 23:43:34 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id NXjY1p0064K0fSy01XjYKG; Tue, 02 Dec 2014 08:43:32 +0100 Received: from [2001:983:a264:1:e1c7:ef9d:aa45:25c0] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 02 Dec 2014 08:43:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Dec 2014 08:43:32 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20141201140518.15998.35426.idtracker@ietfa.amsl.com> References: <20141201140518.15998.35426.idtracker@ietfa.amsl.com> Message-ID: <7692e62a39e18ca12ec2935de42237e2@xs4all.nl> X-Sender: stokcons@xs4all.nl (WAawYp1r6pKCB9Wjwka/gykWYz3srZwy) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/bd3DOq_Sq6E-2mEHU8N3viqaEBo Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 07:43:37 -0000 Hi all, The new applicability draft solves issues #162 - #166 raised during wglc, and contains some clearer rephrasing. Peter internet-drafts@ietf.org schreef op 2014-12-01 15:05: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > Title : Applicability Statement: The use of the RPL > protocol suite in Home Automation and Building Control > Authors : Anders Brandt > Emmanuel Baccelli > Robert Cragie > Peter van der Stok > Filename : draft-ietf-roll-applicability-home-building-06.txt > Pages : 31 > Date : 2014-12-01 > > Abstract: > The purpose of this document is to provide guidance in the selection > and use of protocols from the RPL protocol suite to implement the > features required for control in building and home environments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Dec 2 07:31:47 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378EC1A1BE3; Tue, 2 Dec 2014 07:31:41 -0800 (PST) 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 9lZzHWaUZqFp; Tue, 2 Dec 2014 07:31:39 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA8D1A1B3D; Tue, 2 Dec 2014 07:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6187; q=dns/txt; s=iport; t=1417534298; x=1418743898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uHcgUAekgw7c8QA07bDaaH7kI5lU9fV2uexgzF7ObuI=; b=Np8b0YB+sJ14MACCCcmabIXsbZnOb+URLywMTr+bP1VgFOBu6ZO9YlB6 +Z/ItuRjQCMj/20TUgQkSgQnu3UZnwHlBzbTAbU3dTlr81sc4wXKjFqWm BHE39ZUbm5SV3LLZfSpdczihQxsL8BhSIKYVbAH3/R+A6TRXwM2ZQAkjl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAATbfVStJA2I/2dsb2JhbABbgwdSWQTEZoIcCoYfAoEeFgEBAQEBfYQCAQEBAwEBAQFrCQIFBwQCAQgRBAEBAQodBycLFAgBCAIEAQ0FCAGILgkN1jEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXimCFNwoMETEHBoMjgR8FikqGF4Q+iBM6gn6DGYkihAKCAiAVgURvgQQCHiKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="101917469" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 02 Dec 2014 15:31:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB2FVbDs012493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 15:31:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 09:31:37 -0600 From: "Pascal Thubert (pthubert)" To: "robert.cragie@gridmerge.com" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAb60YCAAPsekA== Date: Tue, 2 Dec 2014 15:31:36 +0000 Deferred-Delivery: Tue, 2 Dec 2014 15:31:00 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <547CB095.8050709@gridmerge.com> In-Reply-To: <547CB095.8050709@gridmerge.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.195.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QlzpDhvAg68RYzKZl6Venq-t3Yc Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:31:41 -0000 Hello Robert: I agree with you. This is exactly the dilemma. But I do not read your own = advice in there? For your questions on the draft: > Also a comment re. section 8, I think the 'I' field needs to be 1, as > 'Size' represents the HopsLft field, not the size of the header.=20 I think you got it reversed. ' I' set is the can-ignore case where the size= in a length in bytes to be skipped if not understood. The text says: "If the I Flag is set, the Size / Format field contains the Length of the 6= LoRH expressed in bytes." Which means=20 (I =3D=3D0 ) =3D> "Size field contains length in bytes" So=20 "the Size field does not contain the Length in bytes" =3D> (I=3D0) > It also doesn't seem to cover the Deep Hops Left concept in RFC4944. The ' Deep Hops Left ' comes from a structural limitation of the mesh heade= r in RFC 4944, which encodes a hops left. No such thing here. The idea is that you place as many consecutive RH3-6LoRH as you need. This = is how we do not max out the number of hops, and also how we handle the var= ious sizes of compressed addresses. But agreeably, we need to provide more = details on address compression and how the header is stripped hop by hop. Which we will do as a group if we take the 6LoRH path, but would be a waste= of time if the group rejects this approach overall. Thanks for your comments : ) Pascal > -----Original Message----- > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: lundi 1 d=E9cembre 2014 19:17 > To: Pascal Thubert (pthubert); 6lo@ietf.org > Cc: Routing Over Low power and Lossy networks; 6tisch@ietf.org > Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-rou= ting- > dispatch-00.txt >=20 > Hi Pascal, >=20 > I agree that with hindsight it could be considered a bit greedy of > RFC4944 to allocate 1/3 of the dispatch code space to the mesh header > (especially when the definition of it itself is questionable) but what > you are advocating is a replacement, not a framework extension. RFC6282 > only deprecated an ESC code, i.e. something which had not yet been used, > which is not quite the same. This effectively makes this at best a new > version of 6lowpan (which is difficult to distinguish) or at worst > arguably a whole new protocol. >=20 > Whilst hindsight is a wonderful thing, it can lead to the situation > where a standard never stands still and keeps evolving. This makes it > very difficult to develop products as there is always the fear that > something will change the next year. Upgrading products is often quite a > difficult process, especially in the case where there could quite > feasibly be thousands of deployed devices which may have limited upgrade > capability. >=20 > I would like to hear what other people think about this. >=20 > Also a comment re. section 8, I think the 'I' field needs to be 1, as > 'Size' represents the HopsLft field, not the size of the header. It also > doesn't seem to cover the Deep Hops Left concept in RFC4944. >=20 > Robert >=20 > On 27/11/2014 2:03 PM, Pascal Thubert (pthubert) wrote: > > Dear all: > > > > This is a response to the question about the compression of RFC 6553 on= top > of RFC 6554. > > It seems exaggerated to consume a dispatch type for the RPL option only= . > > But here, we introduce a routing header which is the equivalent of the = mesh > header in RFC 4944; we propose a compressed TLV format that can encode RH= 3, > RPL option, IP-in-IP, and is further extensible, for instance for upcomin= g BIER. > > As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable > space for application only in Mesh-under. > > This draft reuses that space in Route-over with the assumption that Rou= te- > over will not co-exist in a sma enetwork with Mesh-under encoded in the R= FC > 4944 fashion. > > If there is effectively a need for co-existence, devices have to implem= ent the > new Mesh-under format that is also proposed in the draft. > > > > Comments welcome, > > Pascal > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: jeudi 27 novembre 2014 14:36 > > To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Touta= in; > Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann > > Subject: New Version Notification for draft-thubert-6lo-routing-dispatc= h- > 00.txt > > > > > > A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt > > has been successfully submitted by Pascal Thubert and posted to the IET= F > repository. > > > > Name: draft-thubert-6lo-routing-dispatch > > Revision: 00 > > Title: A Routing Header Dispatch for 6LoWPAN > > Document date: 2014-11-25 > > Group: Individual Submission > > Pages: 19 > > URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-r= outing- > dispatch-00.txt > > Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-rout= ing- > dispatch/ > > Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-di= spatch-00 > > > > > > Abstract: > > This specification provides a new 6LoWPAN dispatch type for use in > > Route-over and mixed Mesh-under and Route-over topologies, that > > reuses the encoding of the mesh type defined in RFC 4944 for pure > > Mesh-under topologies. This specification also defines a method to > > compress RPL Option (RFC6553) information and Routing Header type 3 > > (RFC6554), an efficient IP-in-IP technique and opens the way for > > further routing techniques. This extends 6LoWPAN Transmission of > > IPv6 Packets (RFC4944), and is applicable to new link-layer types > > where 6LoWPAN is being defined. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo > > >=20 From nobody Tue Dec 2 08:28:54 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8C51A1C06; Tue, 2 Dec 2014 08:28:49 -0800 (PST) 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 LNuZRXmEr54X; Tue, 2 Dec 2014 08:28:48 -0800 (PST) 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 EC74C1A1BFB; Tue, 2 Dec 2014 08:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2792; q=dns/txt; s=iport; t=1417537728; x=1418747328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LMJ93jKACRzAzZy/+VXycnQt/C3KIe/GKauSpyEE+a8=; b=XeAtnHSilBGmGfIXIBs9QjpZIrDIEhyAND4bkHYlEWMDN8J4oCAI0Aml MurrWIsR1xdiqOK4MSEXwwBtFWAoygW88IcT1ukUA3V7WX6goe1mY4xgA /2GMr+L4929B7w6g1tT8CgPi8j9Q8jiF9fvhasws/d3hEa1NJ0NY4vUoT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwJAG3nfVStJA2N/2dsb2JhbABbgwdSWQSDAcFlghwKhh8CHIEGFgEBAQEBfYQCAQEBBAEBASAROgkCDAQCAQYCEQQBAQECAgYZBAMCAgIlCxQBBwEIAgQBDQUIiDgNom+cbZZlAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBK452DBExBwaCbzSBHwEEjmKBf6BGgjeBRG+BBkCBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="101942026" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 02 Dec 2014 16:28:47 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB2GSlhR003626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 16:28:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 10:28:47 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , James Woodyatt Thread-Topic: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQDfKgO7xFn46TMk+1F4HGj8l9D5x8fVVw Date: Tue, 2 Dec 2014 16:28:46 +0000 Deferred-Delivery: Tue, 2 Dec 2014 16:28:00 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org> In-Reply-To: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.155] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ybqQmsWLcfzNyXcSrvKeE8SBe8o Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:28:50 -0000 KzENCg0KSSB3YW50ZWQgdG8gYW5zd2VyIEphbWVzIHdoZW4gSSBzYXcgdGhpcy4gDQpNeSBhbnN3 ZXIgd291bGQgaGF2ZSBiZWVuIHRoZSBleGFjdCBzYW1lIHRob3VnaCBJIHdvdWxkIGNlcnRhaW5s eSBoYXZlIGZhaWxlZCB0byBleHByZXNzIGl0IHNvIHdlbGwuDQoNClRoYW5rcyBDYXJzdGVuLg0K DQpQYXNjYWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbGwg W21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1h bm4NCj4gU2VudDogbWFyZGkgMiBkw6ljZW1icmUgMjAxNCAwNjo0MQ0KPiBUbzogSmFtZXMgV29v ZHlhdHQNCj4gQ2M6IDZ0aXNjaEBpZXRmLm9yZzsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQg TG9zc3kgbmV0d29ya3M7IDZsb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIFs2dGlz Y2hdIFs2bG9dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQt DQo+IDZsby1yb3V0aW5nLWRpc3BhdGNoLTAwLnR4dA0KPiANCj4gT24gMDEgRGVjIDIwMTQsIGF0 IDIwOjIwLCBKYW1lcyBXb29keWF0dCA8amh3QG5lc3RsYWJzLmNvbT4gd3JvdGU6DQo+ID4NCj4g PiBSRkMgNDk0NCBpcyBhIFByb3Bvc2VkIFN0YW5kYXJkLCB3aGljaCBwdXRzIGl0IGludG8gdGhl IHNhbWUgY2F0ZWdvcnkgYXMNCj4gIlRyYW5zbWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBF dGhlcm5ldCBOZXR3b3JrcyIgW1JGQyAyNDY0XSwNCj4gDQo+IFRoYXQgYXJndW1lbnQgd291bGQg YmUgbW9yZSBjb252aW5jaW5nIGlmIHRoZSBzaXR1YXRpb25zIHdlcmUgaW5kZWVkDQo+IGNvbXBh cmFibGUuDQo+IA0KPiBSRkMgMjQ2NCBpcyB0aGUgYmFzaXMgZm9yIHdpZGVseSBkZXBsb3llZCBw bHVnLWFuZC1wbGF5IGludGVyb3BlcmFiaWxpdHkuDQo+ICpUaGF0KiBpcyB3aGF0IG1ha2VzIGl0 IG1vc3RseSBpbW11dGFibGUsIG5vdCB0aGUgc3RhbmRhcmRzIHN0YXR1cy4NCj4gKFdoaWNoIHBy b2JhYmx5IHNob3VsZCBiZSB1cGdyYWRlZCB0byBtYXRjaCByZWFsaXR5LikNCj4gDQo+IFdpdGgg UkZDIDQ5NDQsIHdlIGhhdmVu4oCZdCByZWFjaGVkIHRoYXQgbGV2ZWwgb2YgaW50ZXJvcGVyYWJp bGl0eSB5ZXQuDQo+IEluIHBhcnRpY3VsYXIsIHRoZXJlIGlzICpubyogd2F5IHRvIGFjaGlldmUg b3V0LW9mLXRoZS1ib3ggaW50ZXJvcGVyYWJpbGl0eSB3aXRoDQo+IHRoZSBvbGQgbWVzaCBoZWFk ZXIg4oCUIHRoZXJlIGlzIG5vIGRlZmluZWQgd2F5IHRvIHVzZSBpdCwgb3IgZXZlbiB0byBmaW5k IG91dCB0aGF0DQo+IChhbmQgaG93KSBpdCBzaG91bGQgYmUgdXNlZC4NCj4gU28geW91IGFscmVh ZHkgaGF2ZSB0byBhZGQgY29uZmlndXJhdGlvbiAoYXMgaW4sICJ1c2UgbWVzaCBmb3J3YXJkaW5n DQo+IG1lY2hhbmlzbSBYIikgdG8gdXNlIGl0Lg0KPiBQYXNjYWzigJlzIHByb3Bvc2FsIGRvZXMg bm90IGNoYW5nZSB0aGlzIHNpdHVhdGlvbiBvbmUgaW90YTogSXQgZG9lc27igJl0IGplb3BhcmRp emUNCj4gaW50ZXJvcGVyYWJpbGl0eSB3aGVyZSB0aGVyZSB3YXMgaW50ZXJvcGVyYWJpbGl0eSBi ZWZvcmUuDQo+IA0KPiAoTm90ZSBhbHNvIHRoYXQgd2UgYWxyZWFkeSBkaXNjYXJkZWQgTE9XUEFO X0hDMSBhbmQgTE9XUEFOX0hDMiBmcm9tDQo+IFJGQyA0OTQ0IGFuZCByZXBsYWNlZCB0aGVtIHdp dGggUkZDIDYyODIuKQ0KPiANCj4gQWdhaW4sIEkgYmVsaWV2ZSB3ZSBuZWVkIHRvIGxlYXJuIG1v cmUgYWJvdXQgdGhvc2UgcmVwb3J0ZWQgdXNhZ2VzIG9mIHRoZSBvbGQNCj4gTWVzaCBIZWFkZXIg YmVmb3JlIHdlIGNhbiBtZWFuaW5nZnVsbHkgY29udGludWUgdGhpcyBhcmd1bWVudC4NCj4gDQo+ IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Tue Dec 2 09:35:48 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A751A1EF7 for ; Tue, 2 Dec 2014 09:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.087 X-Spam-Level: * X-Spam-Status: No, score=1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 9LDF38XOFP_v for ; Tue, 2 Dec 2014 09:35:42 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388EB1A6F28 for ; Tue, 2 Dec 2014 09:35:38 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id r2so16657782igi.1 for ; Tue, 02 Dec 2014 09:35:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6UMeiHxiIYjKcWflfelZBeMzAWm0ExkldtWyAGN2kWE=; b=BgMMZG2UigezVL8KqAZhyhGBGEf0CeeUukW7RTOWcdfkSeu2IF19t9fyK2OqgiyJir 67vv8Qkl0Gcue2IptnuGPD1L2redVdDZEXaHODOuxooJyRS2G1UIToc/yM30Sq3SPTrJ TxgbcsqSMVzsa1uXL1k36ixgskSjZ1Z9f4wBZjTcpvBHKcmYrnuXz4SkHOg3yuGLymzM u+WZ2eEaTw/35opCB97rTEHE2L2Z1w/bC8CldWd3ODMSZNLhTsJ6MJqGNctm5sTg2hh/ Ktr+cAXxwYJ/P5u3slqCVZEyNqc+t014pdiXC47P2RypDi22VQIVH53MxNxXQKeW4Sbs BR+A== X-Gm-Message-State: ALoCoQlxvsGcIrJoj1TTb0bKJe3X1tWaGAIwb0s8jSel9x1SE/wmKqsWtZgypt5tXEfOFD7WmeHn MIME-Version: 1.0 X-Received: by 10.50.103.3 with SMTP id fs3mr52326501igb.6.1417541737482; Tue, 02 Dec 2014 09:35:37 -0800 (PST) Received: by 10.42.128.72 with HTTP; Tue, 2 Dec 2014 09:35:37 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Dec 2014 09:35:37 -0800 Message-ID: From: Martin Turon To: Carsten Bormann , James Woodyatt , "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Content-Type: multipart/alternative; boundary=047d7b2e15d7b7ab9605093f2718 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/wcAb0i0hSGMCcq2BHlKXqIkNR5c Subject: Re: [Roll] Roll Digest, Vol 83, Issue 3 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:35:44 -0000 --047d7b2e15d7b7ab9605093f2718 Content-Type: text/plain; charset=UTF-8 Hi Carsten, I think the semantics of the mesh header are clear: the source inserts it's own address, and the address of a multi-hop final destination address, and then sends it to the best next hop on "the path". Each node that receives it, also forwards to the next best hop on "the path", decrementing hops left as it does. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0|V|F|HopsLft| originator address, final address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Mesh Addressing Type and Header How the best path is determined depends on the routing protocol running on that node. If RPL is running, it could use the tree for upstream or unknown paths, or cached best-next-hop for downstream paths. My understanding of the wide research in this area is that local route decisions are much more efficient and scalable than source routing, and I'm frankly surprised RPL doesn't use the mesh header more! Why not? Just call it a highly compressed layer 3 ip-in-ip encapsulation within 6lo. It certainly isn't any less clear than how RPL does source routing: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ Size indicates the number of compressed addresses Figure 3: The RH3-6LoRH The answers to many questions would be the same: How are the hopN addresses determined in RPL source routing? Which node inserts those addresses? How does a single node know the optimal path through the mesh? How is that use any more clear than the mesh header? I would argue that all that knowledge, coupled with an assumption that intermediate hops can be determined locally within the mesh, could just as easily generate a valid mesh header usable by RPL. Regarding other candidate dispatch bits for repurposing in RFC4844, how about 010 xxxx 0? We know LOWPAN_HC1 has been deprecated. Any LOWPAN_BC0 fans out there? My personal preference with all this would be to stabilize 6lo, preserve backwards compatibility as much as possible, similar to how x86 did, and extend it very carefully with new, full byte dispatch sequences: Pattern Header Type +------------+-----------------------------------------------+ | 00 xxxxxx | NALP - Not a LoWPAN frame | | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | | 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 | | 01 000011 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 01 001111 | reserved - Reserved for future use | | 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast | | 01 010001 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | *01 011111 | LOWPAN_RH - **draft-thubert-6lo-routing-dispatch-00* | | *01 1xxxxx | LOWPAN_IPHC - RFC6282 * | | 01 111111 | ESC - Additional Dispatch byte follows | | 10 xxxxxx | MESH - Mesh Header | | 11 000xxx | FRAG1 - Fragmentation Header (first) | | 11 001000 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 11 011111 | reserved - Reserved for future use | | 11 100xxx | FRAGN - Fragmentation Header (subsequent)| | 11 101000 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 11 111111 | reserved - Reserved for future use | +------------+-----------------------------------------------+ As everyone seems to agree, IoT is maturing, 6lo is growing in adoption, and we don't want to create a confused situation before it even gets started by forking the protocol arbitrarily. Changes should stay on the conservative side, and adding a clear versioning method needs to be strongly considered. Martin > Message: 2 > Date: Tue, 2 Dec 2014 06:41:17 +0100 > From: Carsten Bormann > To: James Woodyatt > Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and > Lossy networks , "6lo@ietf.org" <6lo@ietf.org> > Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for > draft-thubert-6lo-routing-dispatch-00.txt > Message-ID: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org> > Content-Type: text/plain; charset=utf-8 > > On 01 Dec 2014, at 20:20, James Woodyatt wrote: > > > > RFC 4944 is a Proposed Standard, which puts it into the same category as > "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464], > > That argument would be more convincing if the situations were indeed > comparable. > > RFC 2464 is the basis for widely deployed plug-and-play interoperability. > *That* is what makes it mostly immutable, not the standards status. > (Which probably should be upgraded to match reality.) > > With RFC 4944, we haven?t reached that level of interoperability yet. > In particular, there is *no* way to achieve out-of-the-box > interoperability with the old mesh header ? there is no defined way to use > it, or even to find out that (and how) it should be used. > So you already have to add configuration (as in, "use mesh forwarding > mechanism X") to use it. > Pascal?s proposal does not change this situation one iota: It doesn?t > jeopardize interoperability where there was interoperability before. > > (Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC > 4944 and replaced them with RFC 6282.) > > Again, I believe we need to learn more about those reported usages of the > old Mesh Header before we can meaningfully continue this argument. > > Gr??e, Carsten > > --047d7b2e15d7b7ab9605093f2718 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Carsten,

I think the semantics = of the mesh header are clear: the source inserts it's own address, and = the address of a multi-hop final destination address, and then sends it to = the best next hop on "the path".=C2=A0 Each node that receives it= , also forwards to the next best hop on "the path", decrementing = hops left as it does.

                           1                   2                  =
 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 0|V|F|HopsLft| originator address, final address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: Mesh Addressing Type and Header

How the best path is determined depends on = the routing protocol running on that node.=C2=A0 If RPL is running, it coul= d use the tree for upstream or unknown paths, or cached best-next-hop for d= ownstream paths.=C2=A0 My understanding of the wide research in this area i= s that local route decisions are much more efficient and scalable than sour= ce routing, and I'm frankly surprised RPL doesn't use the mesh head= er more!=C2=A0 Why not?=C2=A0 Just call it a highly compressed layer 3 ip-i= n-ip encapsulation within 6lo.

It certainly isn= 9;t any less clear than how RPL does source routing:
      0    =
               1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+
      |1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+

            Size indicates the number of compressed addresses

                          Figure 3: The RH3-6LoRH
The answe= rs to many questions would be the same: =C2=A0How are the hopN addresses de= termined in RPL source routing?=C2=A0 Which node inserts those addresses?= =C2=A0 How does a single node know the optimal path through the mesh?=C2=A0= How is that use any more clear than the mesh header?=C2=A0 I would argue t= hat all that knowledge, coupled with an assumption that intermediate hops c= an be determined locally within the mesh, could just as easily generate a v= alid mesh header usable by RPL.

Regarding other ca= ndidate dispatch bits for repurposing in RFC4844, how about 010 xxxx 0?=C2= =A0 We know LOWPAN_HC1 has been deprecated.=C2=A0 Any LOWPAN_BC0 fans out t= here? =C2=A0

My personal preference with all this = would be to stabilize 6lo, preserve backwards compatibility as much as poss= ible, similar to how x86 did, and extend it very carefully with new, full b= yte dispatch sequences:

           Pattern    Header Type
         +------------+-----------------------------------------------+
         | 00  xxxxxx | NALP       - Not a LoWPAN frame               |
         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
         | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
         | 01  000011 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 01  001111 | reserved   - Reserved for future use          |
         | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |

         | 01  010001 | reserved   - Reserved for futur=
e use          |

         |   ...      | reserved   - Reserved for future use         =
 |

         | 01  011111 | LOWPAN_RH  - draft-thubert-6lo-routing-dispatch-00    =
     |
         | 01  1xxxxx | LOWPAN_IPHC - R=
FC6282                         |
         | 01  111111 | ESC        - Additional Dispatch byte follows |
         | 10  xxxxxx | MESH       - Mesh Header                      |
         | 11  000xxx | FRAG1      - Fragmentation Header (first)     |
         | 11  001000 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 11  011111 | reserved   - Reserved for future use          |
         | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|
         | 11  101000 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 11  111111 | reserved   - Reserved for future use          |
         +------------+-----------------------------------------------+

As everyone seems to agree, IoT is maturing, 6l= o is growing in adoption, and we don't want to create a confused situat= ion before it even gets started by forking the protocol arbitrarily.=C2=A0 = Changes should stay on the conservative side, and adding a clear versioning= method needs to be strongly considered.

Martin
=C2=A0
Message: 2
Date: Tue, 2 Dec 2014 06:41:17 +0100
From: Carsten Bormann <cabo@tzi.org>
To: James Woodyatt <jhw@nestlabs.com>
Cc: "6tisch@ietf.= org" <6tis= ch@ietf.org>, Routing Over Low power and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy networks <roll@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-thubert-6lo-routing-dispatch-00.txt
Message-ID: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org>=
Content-Type: text/plain; charset=3Dutf-8

On 01 Dec 2014, at 20:20, James Woodyatt <jhw@nestlabs.com> wrote:
>
> RFC 4944 is a Proposed Standard, which puts it into the same category = as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 246= 4],

That argument would be more convincing if the situations were indeed compar= able.

RFC 2464 is the basis for widely deployed plug-and-play interoperability. *That* is what makes it mostly immutable, not the standards status.
(Which probably should be upgraded to match reality.)

With RFC 4944, we haven?t reached that level of interoperability yet.
In particular, there is *no* way to achieve out-of-the-box interoperability= with the old mesh header ? there is no defined way to use it, or even to f= ind out that (and how) it should be used.
So you already have to add configuration (as in, "use mesh forwarding = mechanism X") to use it.
Pascal?s proposal does not change this situation one iota: It doesn?t jeopa= rdize interoperability where there was interoperability before.

(Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC 494= 4 and replaced them with RFC 6282.)

Again, I believe we need to learn more about those reported usages of the o= ld Mesh Header before we can meaningfully continue this argument.

Gr??e, Carsten

--047d7b2e15d7b7ab9605093f2718-- From nobody Tue Dec 2 12:05:30 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AB51A700A for ; Tue, 2 Dec 2014 12:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Plo0C-7_4tm9 for ; Tue, 2 Dec 2014 12:05:07 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA2E1A6FEB for ; Tue, 2 Dec 2014 12:05:05 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id im17so6059900vcb.32 for ; Tue, 02 Dec 2014 12:05:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fUn5GlNqZDSEw64D+7+pSXDcb/IoncwoeSshK0z45/k=; b=D6KAJLH5heY7XjcM42V3GzfZJv3xLjg15whq9atILbrOfcaFNhckKI+riBN+DluSmk cFOewWCtHFI+RMeKhwVk/ax8JbeCYYgb6n6rTlAW6XK4zm3ffPsnkD8qglnvUSJFcuxv 8/rwDuldDGQBIn/8SzxQISldegrudIDg/me5/p465Nar2Rrf7d1OQ2Th6tjvNRY2wndY e0RD+8GFXgjgH5eteaScSmdfGDk23HKgomtlq+dgtkUbefGZybybd79jtwcmuJK0UX4Y k8xlIApGfBNR0xymeMk+WhKn7Ul1siatD21TPJrusWMUPelaQodxIC6GiPe2m6gBQiG8 9CQg== X-Gm-Message-State: ALoCoQmwjoOgQYVB1VE0rt60faeHyFUGYR1118FiFG7FsUGXRHfAfuDOC/i/VWsf5/ATZRauZ6xQ MIME-Version: 1.0 X-Received: by 10.52.83.196 with SMTP id s4mr667169vdy.50.1417550703064; Tue, 02 Dec 2014 12:05:03 -0800 (PST) Received: by 10.31.10.65 with HTTP; Tue, 2 Dec 2014 12:05:02 -0800 (PST) In-Reply-To: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org> Date: Tue, 2 Dec 2014 12:05:02 -0800 Message-ID: From: James Woodyatt To: "6lo@ietf.org" <6lo@ietf.org> Content-Type: multipart/alternative; boundary=001a1136afd81b8cc10509413eeb Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fMhSMxuoO-YBdjJYdauoicdw8ig Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:05:14 -0000 --001a1136afd81b8cc10509413eeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 1, 2014 at 9:41 PM, Carsten Bormann wrote: > On 01 Dec 2014, at 20:20, James Woodyatt wrote: > > > > RFC 4944 is a Proposed Standard, which puts it into the same category a= s > "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464], > > That argument would be more convincing if the situations were indeed > comparable. > > RFC 2464 is the basis for widely deployed plug-and-play interoperability. > *That* is what makes it mostly immutable, not the standards status. > (Which probably should be upgraded to match reality.) > > With RFC 4944, we haven=E2=80=99t reached that level of interoperability = yet. > Yes, well=E2=80=94 I wasn't trying to make an argument that Proposed Standa= rd category implies the Expensive Mutability quality. I was rebutting what seemed to be Pascal's argument that Not Standard implies Inexpensive Mutability by attempting to provide an existence proof in the form of RFC 2464. In particular, there is *no* way to achieve out-of-the-box interoperability > with the old mesh header =E2=80=94 there is no defined way to use it, or = even to > find out that (and how) it should be used. > So you already have to add configuration (as in, "use mesh forwarding > mechanism X") to use it. > Pascal=E2=80=99s proposal does not change this situation one iota: It doe= sn=E2=80=99t > jeopardize interoperability where there was interoperability before. > Not quite true. We should be mindful of the possibility of existing interoperability already obtained by conformance to external specifications derived from RFC 4944. Because it's a Proposed Standard, I'm generally not comfortable assuming that the Mesh Header is a sand castle that can be safely demolished and rebuilt. Again, I think that's a value judgment about existing deployments that we should be wary about making. > (Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC > 4944 and replaced them with RFC 6282.) > > Again, I believe we need to learn more about those reported usages of the > old Mesh Header before we can meaningfully continue this argument. > I'm not sure that's a Need so much as a Desire, and a curious one at that. I don't see the harm in proceeding to develop a coexistence strategy for dealing with any existing implementations that may currently be using the existing Mesh Header despite its rather fluid definition in the Proposed Standard. Why is taking that precaution not a good idea? --=20 james woodyatt Nest Labs, Communications Engineering --001a1136afd81b8cc10509413eeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 1, 2014 at 9:41 PM, Carsten Bormann <cabo@tzi.org> wrot= e:
On 01 Dec 2014, at 20= :20, James Woodyatt <jhw@nestlabs.co= m> wrote:
>
> RFC 4944 is a Proposed Standard, which puts it into the same category = as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 246= 4],

That argument would be more convincing if the situations were indeed= comparable.

RFC 2464 is the basis for widely deployed plug-and-play interoperability. *That* is what makes it mostly immutable, not the standards status.
(Which probably should be upgraded to match reality.)

With RFC 4944, we haven=E2=80=99t reached that level of interoperability ye= t.

Yes, well=E2=80=94 I wasn't tryi= ng to make an argument that Proposed Standard category implies the Expensiv= e Mutability quality.=C2=A0 I was rebutting what seemed to be Pascal's = argument that Not Standard implies Inexpensive Mutability by attempting to = provide an existence proof in the form of RFC 2464.

In particular, there is *no* way to achieve out-of-the-box interoperability= with the old mesh header =E2=80=94 there is no defined way to use it, or e= ven to find out that (and how) it should be used.
So you already have to add configuration (as in, "use mesh forwarding = mechanism X") to use it.
Pascal=E2=80=99s proposal does not change this situation one iota: It doesn= =E2=80=99t jeopardize interoperability where there was interoperability bef= ore.

Not quite true. We should be mindf= ul of the possibility of existing interoperability already obtained by conf= ormance to external specifications derived from RFC 4944. Because it's = a Proposed Standard, I'm generally not comfortable assuming that the Me= sh Header is a sand castle that can be safely demolished and rebuilt. Again= , I think that's a value judgment about existing deployments that we sh= ould be wary about making.
=C2=A0
(Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC 494= 4 and replaced them with RFC 6282.)

Again, I believe we need to learn more about those reported usages of the o= ld Mesh Header before we can meaningfully continue this argument.

I'm not sure that's a Need so much as a Desi= re, and a curious one at that. I don't see the harm in proceeding to de= velop a coexistence strategy for dealing with any existing implementations = that may currently be using the existing Mesh Header despite its rather flu= id definition in the Proposed Standard. Why is taking that precaution not a= good idea?


--
james woodyatt <jhw@nestlabs.com>
Nest Labs= , Communications Engineering
--001a1136afd81b8cc10509413eeb-- From nobody Tue Dec 2 12:09:16 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5721A6FFA; Tue, 2 Dec 2014 12:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.445 X-Spam-Level: X-Spam-Status: No, score=-11.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_61=0.6, 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 1wkWXYXva674; Tue, 2 Dec 2014 12:08:31 -0800 (PST) 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 EF0EE1A1B19; Tue, 2 Dec 2014 12:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54346; q=dns/txt; s=iport; t=1417550911; x=1418760511; h=from:to:subject:date:message-id:mime-version; bh=0OYDJuT+VE6mu5oUrsa9DkPFWS9jZ1UvsiHsNlqbcIY=; b=R0ncs+UAaFd5JuIfsc3ky99mYpDEOvNjZo9YY12RlvR2asuGWIh4/+Rm MIoySrdNggXizn7e9Ju4cSivnD9nGdmlkDo/coQx30kDTpFsDLtLCEahZ IPR5URo0MLRUdT2ebETEth/jHs9tNCXSjx6oPesJTM1isoUtbvuTGI59u Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggJAHYbflStJV2Q/2dsb2JhbABbgkNEUlkEgwHBaYhFAhyBChYBAQEBAX2EAgEBAQQjCl4BFgMDAQEBAQoWAQYDAgQwFAkJAQQBEgiIOMARllMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkB4BAQEMETcHgm80gR8FhXyKZYZ0hV2GUYkihAKDe2+BBgcXBhyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208,217";a="376939570" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 02 Dec 2014 20:08:29 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB2K8TB3006779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 20:08:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 14:08:25 -0600 From: "Pascal Thubert (pthubert)" To: Martin Turon , Carsten Bormann , "James Woodyatt" , "6tisch@ietf.org" <6tisch@ietf.org>, "Routing Over Low power and Lossy networks" , "6lo@ietf.org" <6lo@ietf.org>, Geoff Mulligan Thread-Topic: 6LoRH Thread-Index: AdAOa5PcvP6nQxWYQ0mFGApswLHfUw== Date: Tue, 2 Dec 2014 20:08:25 +0000 Deferred-Delivery: Tue, 2 Dec 2014 20:08:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.155] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A86297xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/vUazFsM4sIZhjQ_uWUTzMbPnKn0 Subject: [Roll] 6LoRH X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:08:45 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A86297xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFydGluOg0KDQpJ4oCZZCBnbGFkbHkgZXhjaGFuZ2Ugd2l0aCB5b3Ugb24gYWxsIHRo ZSB0b3BpY3MgeW91IHJhaXNlLCBhbGwgcmVsZXZhbnQgYW5kIGludGVyZXN0aW5nLiBCdXQgZm9y IHRoaXMgcGFydGljdWxhciBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIG1vdmUgZm9y d2FyZCB3aXRoIDZMb1JILCBJIHdvdWxkIG5vdCBkaXNjdXNzIHRoZSB3b3JraW5ncyBvZiBSUEwu IFdoZXRoZXIgUlBMIG9yIHNvbWV0aGluZyBlbHNlIHNldHMgdGhlIFJIIGlzIGlycmVsZXZhbnQg dG8gdGhpcyBkcmFmdDsgd2hhdOKAmXMgcmVsZXZhbnQgaXMgdGhlIGV4YWN0IHNlbWFudGljcyBv ZiB0aGUgZW50cmllcyBpbiB0aGUgUkgsIGUuZy4gbG9vc2UgdnMuIHN0cmljdCwgYWRkcmVzcyBj b21wcmVzc2lvbiB0ZWNobmlxdWUsIGV0Y+KApiBZZXQgY2VydGFpbmx5LCBpZiB5b3Ugd2lzaCwg d2UgY2FuIGhhdmUgYSBjaGF0IG9uIFJQTCBhdCBST0xMLg0KDQpGcm9tIHlvdXIgbWFpbCBJIHJl YWQgYSBkZXNpcmUgdG8gc3BsaXQgdGhlIG9yaWdpbmFsIHF1ZXN0aW9uIGluIDI6DQoNCjEpICAg ICAgU2hvdWxkIHdlIGJlIGRvaW5nIDZMb1JIIGF0IGFsbA0KDQoyKSAgICAgIElmIHdlIGRvLCB3 aGVyZSBkbyB3ZSB0YWtlIHRoZSBiaXRzDQoNCkNhbiBJIHJlYWQgdGhhdCB5b3XigJlkIGFuc3dl ciB5ZXMgdG8gcXVlc3Rpb24gMSkgYnV0IHByb3Bvc2UgYW4gYWx0ZXJuYXRlIGZyb20gdGhlIGRy YWZ0IGFwcHJvYWNoIGZvciAyKSA/DQoNCkkgd291bGQgYWRkIHRvIHRoZSBwaWN0dXJlIHRoYXQg cmVnYXJkbGVzcyBvZiB0aGUgc3BlY2lmaWMgZm9ybWF0cyBvZiB0aGUgUkZDIDQ5NDQgbWVzaCBo ZWFkZXIgYW5kIFJIMy02TG9SSCwgdGhlcmUgaXMgYSBuZWVkIHRvIGRlZmluZSBhbiBpbnRlcm9w ZXJhYmxlIG9wZXJhdGlvbiBvbiBzZXR0aW5nIHRoZSBlbnRyaWVzIGluIHRoZSBSSCwgYW5kIHRo ZW4gZm9yd2FyZGluZyBmcmFtZXMgYmFzZWQgb24gd2hhdOKAmXMgdGhlcmUuIFRoaXMgaXMgY2Vy dGFpbmx5IHNvbWV0aGluZyB0aGF0IEkgd2FudCB0byBzZWUgZGV0YWlsZWQgaW4gNkxvUkgsIHRo b3VnaCBhZG1pdHRlZGx5IGl04oCZcyBub3QgZG9uZSB5ZXQuDQoNClRoaXMgbWF5IG5vdCBoYXZl IGJlZW4gc28gY2xlYXJseSBzcGVsbGVkIG91dCBpbiBSRkMgNDk0NCwgZWl0aGVyLCBidXQsIGJl Y2F1c2UgNkxvV1BBTiB3YXMgY2hhcnRlcmVkIGZvciA4MDIuMTUuNCwgaXQgd2FzIGltcGxpY2l0 bHkgODAyLjE1LjQgYWRkcmVzc2VzLCB3aGljaCB3ZXJlIGV4cHJlc3NlZCBlaXRoZXIgYXMgc2hv cnQgYWRkcmVzc2VzLCBQQU5JRCArIHNob3J0IGFkZHJlc3MsIG9yIGZ1bGwgTUFDNjQuIFdpdGgg dGhpcyBpbiBtaW5kLCBpbnRlcm9wZXJhdGlvbiB3YXMgZWZmZWN0aXZlbHkgZ3VhcmFudGVlZCBh cyBzaG91bGQgYmUgZm9yIGFueSBSRkMuIFRoaXMgaXMgd2h5IEkgdGFrZSB0aGF0IGJhc2VsaW5l IGFzIHRoZSByZWZlcmVuY2UgZm9yIGNsYWltaW5nIDZMb1dQQU4gY29tcGxpYW5jZSBhbmQgZG8g bm90IGJ1eSBhbiBvdmVybG9hZCB0byBMMyBhZGRyZXNzZXMgYXMgY29tcGxpYW50Lg0KDQpPVE9I LCB3aXRoIDZsbywgd2UgYXJlIGV4dGVuZGluZyA2TG9XUEFOIGJleW9uZCA4MDIuMTUuNC4gTG9j a2luZyAxLzMgb2YgdGhlIGRpc3BhdGNoIHNwYWNlIHRvIDgwMi4xNS40IHNwZWNpZmljIGZvcm1h dHMgaXMganVzdCBub3QgYWNjZXB0YWJsZSwgYW5kIGZvciB0aGF0IHJlYXNvbiwgSSBjb21wbGV0 ZWx5IGFncmVlIHdpdGggeW91ciBzdWdnZXN0aW9uIHRvIHJldXNlIHRob3NlIGJpdHMgZm9yIEwz IG9wZXJhdGlvbnMuDQoNClRoZSBjYXZlYXQgaXMgd2hldGhlciBvbmUgbWFrZXMgdGhlIGNob2lj ZSB0byBsb29rIGFuZCBmZWVsIGxpa2UgdGhlIHN0YW5kYXJkLCBidXQsIGF0IHRoZSBzYW1lIHRp bWUsIGFjY2VwdHMgbm90IHRvIGludGVyb3BlcmF0ZSB3aXRoIGRldmljZXMgdGhhdCBpbXBsZW1l bnRlZCB0aGUgc3RhbmRhcmQgYXMgaXQgd2FzIGludGVuZGVkIGFuZCBpbXBsZW1lbnRlZCBvcmln aW5hbGx5LiBJZiBhIGdpdmVuIGltcGxlbWVudGF0aW9uIHBsYWNlcyBhIGNvbXByZXNzZWQg4oCT b3Igd29yc2UsIHVuY29tcHJlc3NlZC0gSVB2NiBhZGRyZXNzIGluIGEgTUgsIGFuZCBzb21lIG90 aGVyIGV4cGVjdHMgb25seSBjb21wcmVzc2VkIE1BQyBhZGRyZXNzZXMsIGNvbXBsaWFuY2UgdG8g dGhlIGZvcm1hdCBtYXkgYmUgZW5zdXJlZCwgYnV0IGludGVyb3BlcmF0aW9uIGlzIG5vdCBhY2hp ZXZlZCwgYW5kIHRoZSBwdXJwb3NlIG9mIHRoZSBzdGFuZGFyZCBpcyBkZWZlYXRlZC4NCg0KSSB0 aGluayBpbiBmYWN0IHRoYXQgaXQgaXMgY3JpdGljYWwgZm9yIHRoZSBJRVRGIHRvIHByZXNlcnZl IGl0cyByb2xlIGFzICBhIHN0YW5kYXJkIGJvZHkgdGhhdCBkZWZpbmVzIGludGVyb3BlcmFibGUg c3RhbmRhcmRzLCBhbmQgcGFydCBvZiB0aGF0IGlzIHRvIGNvbnRyb2wgd2hlbiBhIGJyZWFrYWdl IGlzIGhhcHBlbmluZyBpbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBBbmQgZWZmZWN0aXZlbHks IHRoZSA2TG9SSCBwcm9wb3NpbmcgYSBicmVhaywgdGhvdWdoIHRoZSB3YXkgaXQgaXMgc3BlbGxl ZCBvdXQsIHdlIHRyeSB0byByZXNwZWN0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBvZiA4MDIu MTUuNCBtZXNoIG5ldHdvcmtzLCB3aGV0aGVyIHRoZXkgYXJlIGZ1bGx5IGNvbXBsaWFudCB0byA2 TG9XUEFOIG9yIG5vdC4gVGhlIG9ubHkgd2F5IHRvIGRvIHRoYXQgaXMgdG8gYWNjZXB0IHRoYXQg aW5jb21wYXRpYmxlIG5ldHdvcmtzIGFyZSBzZWdyZWdhdGVkLiBPbiB0aGUgd2F5LCB3ZSBuZWVk IGEgY2xlYXIgc3RhdGVtZW50IG9mIHdoYXQgaXMgY29tcGF0aWJsZS4gQW5kIHdlIHRydXN0IHN0 YW5kYXJkIGNvbXBsaWFuY2UgdG8gaW5kaWNhdGUgY29tcGF0aWJpbGl0eS4NCg0KV2XigJlkIG5l ZWQgdGhlIGFuc3dlciB0byBDYXJzdGVu4oCZcyBxdWVzdGlvbiBhYm91dCBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMgdGhhdCB1c2UgdGhlIFJGQyA0OTQ0IE1IIGFuZCBjbGFpbSBjb21wbGlhbmNl IGluIG9yZGVyIHRvIGFzc2VzcyB0aGUgZGFtYWdlLCBpZiBhbnkuICBJZiB3ZSBhcmUgYWxyZWFk eSBpbiBhIHNpdHVhdGlvbiB3aGVyZSB3ZSBjYW5ub3QgZXhwZWN0IGludGVyb3BlcmF0aW9uIGJl dHdlZW4gYWxsIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucywgYnV0IG9ubHkgYmV0d2VlbiB0aG9z ZSB3aXRoIGEgc3BlY2lhbCBhZ3JlZW1lbnQgdGhhdCwgYnkgdGhlIHdheSwgd2FzIG5vdCB2YWxp ZGF0ZWQgYnkgdGhlIElFVEYsIHRoZW4gYWxyZWFkeSB3ZSBoYXZlIGltcGxlbWVudGF0aW9ucyB0 aGF0IGNhbm5vdCBiZSBkZXBsb3llZCBpbiBhIHNhbWUgbmV0d29yay4gNkxvUkggd291bGQgbm90 IGJlIGNoYW5naW5nIHRoYXQgcGljdHVyZSwgYnV0IGlzIGNsZWFybHkgYW4gYXR0ZW1wdCB0byBh dm9pZCBpdCBpbiB0aGUgZnV0dXJlIGJ5IHByb3ZpZGluZyBhbiBleHRlbnNpYmxlIGZyYW1ld29y ay4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRnJvbTogNmxvIFttYWlsdG86NmxvLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVHVyb24NClNlbnQ6IG1hcmRpIDIgZMOpY2Vt YnJlIDIwMTQgMDk6MzYNClRvOiBDYXJzdGVuIEJvcm1hbm47IEphbWVzIFdvb2R5YXR0OyA2dGlz Y2hAaWV0Zi5vcmc7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzOyA2 bG9AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbNmxvXSBSb2xsIERpZ2VzdCwgVm9sIDgzLCBJc3N1 ZSAzDQoNCg0KSGkgQ2Fyc3RlbiwNCg0KSSB0aGluayB0aGUgc2VtYW50aWNzIG9mIHRoZSBtZXNo IGhlYWRlciBhcmUgY2xlYXI6IHRoZSBzb3VyY2UgaW5zZXJ0cyBpdCdzIG93biBhZGRyZXNzLCBh bmQgdGhlIGFkZHJlc3Mgb2YgYSBtdWx0aS1ob3AgZmluYWwgZGVzdGluYXRpb24gYWRkcmVzcywg YW5kIHRoZW4gc2VuZHMgaXQgdG8gdGhlIGJlc3QgbmV4dCBob3Agb24gInRoZSBwYXRoIi4gIEVh Y2ggbm9kZSB0aGF0IHJlY2VpdmVzIGl0LCBhbHNvIGZvcndhcmRzIHRvIHRoZSBuZXh0IGJlc3Qg aG9wIG9uICJ0aGUgcGF0aCIsIGRlY3JlbWVudGluZyBob3BzIGxlZnQgYXMgaXQgZG9lcy4NCg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMw0KDQogICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQoNCiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAg IHwxIDB8VnxGfEhvcHNMZnR8IG9yaWdpbmF0b3IgYWRkcmVzcywgZmluYWwgYWRkcmVzcw0KDQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQoNCg0KICAgICAgICAgICAgICAgICBGaWd1cmUgMzogTWVzaCBBZGRy ZXNzaW5nIFR5cGUgYW5kIEhlYWRlcg0KDQpIb3cgdGhlIGJlc3QgcGF0aCBpcyBkZXRlcm1pbmVk IGRlcGVuZHMgb24gdGhlIHJvdXRpbmcgcHJvdG9jb2wgcnVubmluZyBvbiB0aGF0IG5vZGUuICBJ ZiBSUEwgaXMgcnVubmluZywgaXQgY291bGQgdXNlIHRoZSB0cmVlIGZvciB1cHN0cmVhbSBvciB1 bmtub3duIHBhdGhzLCBvciBjYWNoZWQgYmVzdC1uZXh0LWhvcCBmb3IgZG93bnN0cmVhbSBwYXRo cy4gIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHdpZGUgcmVzZWFyY2ggaW4gdGhpcyBhcmVhIGlz IHRoYXQgbG9jYWwgcm91dGUgZGVjaXNpb25zIGFyZSBtdWNoIG1vcmUgZWZmaWNpZW50IGFuZCBz Y2FsYWJsZSB0aGFuIHNvdXJjZSByb3V0aW5nLCBhbmQgSSdtIGZyYW5rbHkgc3VycHJpc2VkIFJQ TCBkb2Vzbid0IHVzZSB0aGUgbWVzaCBoZWFkZXIgbW9yZSEgIFdoeSBub3Q/ICBKdXN0IGNhbGwg aXQgYSBoaWdobHkgY29tcHJlc3NlZCBsYXllciAzIGlwLWluLWlwIGVuY2Fwc3VsYXRpb24gd2l0 aGluIDZsby4NCg0KSXQgY2VydGFpbmx5IGlzbid0IGFueSBsZXNzIGNsZWFyIHRoYW4gaG93IFJQ TCBkb2VzIHNvdXJjZSByb3V0aW5nOg0KDQogICAgICAwICAgICAgICAgICAgICAgICAgIDENCg0K ICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUNCg0KICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSAgICAtKy0gICAgLSsgLi4uICstICAgIC0rDQoNCiAg ICAgIHwxfDB8MHwgIFNpemUgICB8NkxvUkggVHlwZSAwLi40fCBIb3AxIHwgSG9wMiB8ICAgICB8 IEhvcE4gfA0KDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstICAgIC0r LSAgICAtKyAuLi4gKy0gICAgLSsNCg0KDQoNCiAgICAgICAgICAgIFNpemUgaW5kaWNhdGVzIHRo ZSBudW1iZXIgb2YgY29tcHJlc3NlZCBhZGRyZXNzZXMNCg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDM6IFRoZSBSSDMtNkxvUkgNClRoZSBhbnN3ZXJzIHRvIG1hbnkgcXVl c3Rpb25zIHdvdWxkIGJlIHRoZSBzYW1lOiAgSG93IGFyZSB0aGUgaG9wTiBhZGRyZXNzZXMgZGV0 ZXJtaW5lZCBpbiBSUEwgc291cmNlIHJvdXRpbmc/ICBXaGljaCBub2RlIGluc2VydHMgdGhvc2Ug YWRkcmVzc2VzPyAgSG93IGRvZXMgYSBzaW5nbGUgbm9kZSBrbm93IHRoZSBvcHRpbWFsIHBhdGgg dGhyb3VnaCB0aGUgbWVzaD8gIEhvdyBpcyB0aGF0IHVzZSBhbnkgbW9yZSBjbGVhciB0aGFuIHRo ZSBtZXNoIGhlYWRlcj8gIEkgd291bGQgYXJndWUgdGhhdCBhbGwgdGhhdCBrbm93bGVkZ2UsIGNv dXBsZWQgd2l0aCBhbiBhc3N1bXB0aW9uIHRoYXQgaW50ZXJtZWRpYXRlIGhvcHMgY2FuIGJlIGRl dGVybWluZWQgbG9jYWxseSB3aXRoaW4gdGhlIG1lc2gsIGNvdWxkIGp1c3QgYXMgZWFzaWx5IGdl bmVyYXRlIGEgdmFsaWQgbWVzaCBoZWFkZXIgdXNhYmxlIGJ5IFJQTC4NCg0KUmVnYXJkaW5nIG90 aGVyIGNhbmRpZGF0ZSBkaXNwYXRjaCBiaXRzIGZvciByZXB1cnBvc2luZyBpbiBSRkM0ODQ0LCBo b3cgYWJvdXQgMDEwIHh4eHggMD8gIFdlIGtub3cgTE9XUEFOX0hDMSBoYXMgYmVlbiBkZXByZWNh dGVkLiAgQW55IExPV1BBTl9CQzAgZmFucyBvdXQgdGhlcmU/DQoNCk15IHBlcnNvbmFsIHByZWZl cmVuY2Ugd2l0aCBhbGwgdGhpcyB3b3VsZCBiZSB0byBzdGFiaWxpemUgNmxvLCBwcmVzZXJ2ZSBi YWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhcyBtdWNoIGFzIHBvc3NpYmxlLCBzaW1pbGFyIHRvIGhv dyB4ODYgZGlkLCBhbmQgZXh0ZW5kIGl0IHZlcnkgY2FyZWZ1bGx5IHdpdGggbmV3LCBmdWxsIGJ5 dGUgZGlzcGF0Y2ggc2VxdWVuY2VzOg0KDQoNCiAgICAgICAgICAgUGF0dGVybiAgICBIZWFkZXIg VHlwZQ0KDQogICAgICAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICB8IDAwICB4eHh4eHggfCBOQUxQICAg ICAgIC0gTm90IGEgTG9XUEFOIGZyYW1lICAgICAgICAgICAgICAgfA0KDQogICAgICAgICB8IDAx ICAwMDAwMDEgfCBJUHY2ICAgICAgIC0gVW5jb21wcmVzc2VkIElQdjYgQWRkcmVzc2VzICAgICAg fA0KDQogICAgICAgICB8IDAxICAwMDAwMTAgfCBMT1dQQU5fSEMxIC0gTE9XUEFOX0hDMSBjb21w cmVzc2VkIElQdjYgICAgICAgfA0KDQogICAgICAgICB8IDAxICAwMDAwMTEgfCByZXNlcnZlZCAg IC0gUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UgICAgICAgICAgfA0KDQogICAgICAgICB8ICAgLi4u ICAgICAgfCByZXNlcnZlZCAgIC0gUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UgICAgICAgICAgfA0K DQogICAgICAgICB8IDAxICAwMDExMTEgfCByZXNlcnZlZCAgIC0gUmVzZXJ2ZWQgZm9yIGZ1dHVy ZSB1c2UgICAgICAgICAgfA0KDQogICAgICAgICB8IDAxICAwMTAwMDAgfCBMT1dQQU5fQkMwIC0g TE9XUEFOX0JDMCBicm9hZGNhc3QgICAgICAgICAgICAgfA0KDQogICAgICAgICB8IDAxICAwMTAw MDEgfCByZXNlcnZlZCAgIC0gUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UgICAgICAgICAgfA0KDQog ICAgICAgICB8ICAgLi4uICAgICAgfCByZXNlcnZlZCAgIC0gUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1 c2UgICAgICAgICAgfA0KDQogICAgICAgICB8IDAxICAwMTExMTEgfCBMT1dQQU5fUkggIC0gZHJh ZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC0wMCAgICAgICAgIHwNCg0KICAgICAgICAg fCAwMSAgMXh4eHh4IHwgTE9XUEFOX0lQSEMgLSBSRkM2MjgyICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCg0KICAgICAgICAgfCAwMSAgMTExMTExIHwgRVNDICAgICAgICAtIEFkZGl0aW9uYWwg RGlzcGF0Y2ggYnl0ZSBmb2xsb3dzIHwNCg0KICAgICAgICAgfCAxMCAgeHh4eHh4IHwgTUVTSCAg ICAgICAtIE1lc2ggSGVhZGVyICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgfCAx MSAgMDAweHh4IHwgRlJBRzEgICAgICAtIEZyYWdtZW50YXRpb24gSGVhZGVyIChmaXJzdCkgICAg IHwNCg0KICAgICAgICAgfCAxMSAgMDAxMDAwIHwgcmVzZXJ2ZWQgICAtIFJlc2VydmVkIGZvciBm dXR1cmUgdXNlICAgICAgICAgIHwNCg0KICAgICAgICAgfCAgIC4uLiAgICAgIHwgcmVzZXJ2ZWQg ICAtIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlICAgICAgICAgIHwNCg0KICAgICAgICAgfCAxMSAg MDExMTExIHwgcmVzZXJ2ZWQgICAtIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlICAgICAgICAgIHwN Cg0KICAgICAgICAgfCAxMSAgMTAweHh4IHwgRlJBR04gICAgICAtIEZyYWdtZW50YXRpb24gSGVh ZGVyIChzdWJzZXF1ZW50KXwNCg0KICAgICAgICAgfCAxMSAgMTAxMDAwIHwgcmVzZXJ2ZWQgICAt IFJlc2VydmVkIGZvciBmdXR1cmUgdXNlICAgICAgICAgIHwNCg0KICAgICAgICAgfCAgIC4uLiAg ICAgIHwgcmVzZXJ2ZWQgICAtIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlICAgICAgICAgIHwNCg0K ICAgICAgICAgfCAxMSAgMTExMTExIHwgcmVzZXJ2ZWQgICAtIFJlc2VydmVkIGZvciBmdXR1cmUg dXNlICAgICAgICAgIHwNCg0KICAgICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KQXMgZXZlcnlvbmUgc2VlbXMgdG8g YWdyZWUsIElvVCBpcyBtYXR1cmluZywgNmxvIGlzIGdyb3dpbmcgaW4gYWRvcHRpb24sIGFuZCB3 ZSBkb24ndCB3YW50IHRvIGNyZWF0ZSBhIGNvbmZ1c2VkIHNpdHVhdGlvbiBiZWZvcmUgaXQgZXZl biBnZXRzIHN0YXJ0ZWQgYnkgZm9ya2luZyB0aGUgcHJvdG9jb2wgYXJiaXRyYXJpbHkuICBDaGFu Z2VzIHNob3VsZCBzdGF5IG9uIHRoZSBjb25zZXJ2YXRpdmUgc2lkZSwgYW5kIGFkZGluZyBhIGNs ZWFyIHZlcnNpb25pbmcgbWV0aG9kIG5lZWRzIHRvIGJlIHN0cm9uZ2x5IGNvbnNpZGVyZWQuDQoN Ck1hcnRpbg0KDQpNZXNzYWdlOiAyDQpEYXRlOiBUdWUsIDIgRGVjIDIwMTQgMDY6NDE6MTcgKzAx MDANCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5v cmc+Pg0KVG86IEphbWVzIFdvb2R5YXR0IDxqaHdAbmVzdGxhYnMuY29tPG1haWx0bzpqaHdAbmVz dGxhYnMuY29tPj4NCkNjOiAiNnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlzY2hAaWV0Zi5vcmc+ IiA8NnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlzY2hAaWV0Zi5vcmc+PiwgUm91dGluZyBPdmVy IExvdyBwb3dlciBhbmQNCiAgICAgICAgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc8bWFp bHRvOnJvbGxAaWV0Zi5vcmc+PiwgIjZsb0BpZXRmLm9yZzxtYWlsdG86NmxvQGlldGYub3JnPiIg PDZsb0BpZXRmLm9yZzxtYWlsdG86NmxvQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbUm9sbF0g WzZ0aXNjaF0gWzZsb10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCiAgICAgICAg ZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC0wMC50eHQNCk1lc3NhZ2UtSUQ6IDw2 NjlCNTVERi00MjUwLTRFNDUtQjU1Ri0wM0Y3MDVGNERGQjBAdHppLm9yZzxtYWlsdG86NjY5QjU1 REYtNDI1MC00RTQ1LUI1NUYtMDNGNzA1RjRERkIwQHR6aS5vcmc+Pg0KQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04DQoNCk9uIDAxIERlYyAyMDE0LCBhdCAyMDoyMCwgSmFt ZXMgV29vZHlhdHQgPGpod0BuZXN0bGFicy5jb208bWFpbHRvOmpod0BuZXN0bGFicy5jb20+PiB3 cm90ZToNCj4NCj4gUkZDIDQ5NDQgaXMgYSBQcm9wb3NlZCBTdGFuZGFyZCwgd2hpY2ggcHV0cyBp dCBpbnRvIHRoZSBzYW1lIGNhdGVnb3J5IGFzICJUcmFuc21pc3Npb24gb2YgSVB2NiBQYWNrZXRz IG92ZXIgRXRoZXJuZXQgTmV0d29ya3MiIFtSRkMgMjQ2NF0sDQoNClRoYXQgYXJndW1lbnQgd291 bGQgYmUgbW9yZSBjb252aW5jaW5nIGlmIHRoZSBzaXR1YXRpb25zIHdlcmUgaW5kZWVkIGNvbXBh cmFibGUuDQoNClJGQyAyNDY0IGlzIHRoZSBiYXNpcyBmb3Igd2lkZWx5IGRlcGxveWVkIHBsdWct YW5kLXBsYXkgaW50ZXJvcGVyYWJpbGl0eS4NCipUaGF0KiBpcyB3aGF0IG1ha2VzIGl0IG1vc3Rs eSBpbW11dGFibGUsIG5vdCB0aGUgc3RhbmRhcmRzIHN0YXR1cy4NCihXaGljaCBwcm9iYWJseSBz aG91bGQgYmUgdXBncmFkZWQgdG8gbWF0Y2ggcmVhbGl0eS4pDQoNCldpdGggUkZDIDQ5NDQsIHdl IGhhdmVuP3QgcmVhY2hlZCB0aGF0IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgeWV0Lg0KSW4g cGFydGljdWxhciwgdGhlcmUgaXMgKm5vKiB3YXkgdG8gYWNoaWV2ZSBvdXQtb2YtdGhlLWJveCBp bnRlcm9wZXJhYmlsaXR5IHdpdGggdGhlIG9sZCBtZXNoIGhlYWRlciA/IHRoZXJlIGlzIG5vIGRl ZmluZWQgd2F5IHRvIHVzZSBpdCwgb3IgZXZlbiB0byBmaW5kIG91dCB0aGF0IChhbmQgaG93KSBp dCBzaG91bGQgYmUgdXNlZC4NClNvIHlvdSBhbHJlYWR5IGhhdmUgdG8gYWRkIGNvbmZpZ3VyYXRp b24gKGFzIGluLCAidXNlIG1lc2ggZm9yd2FyZGluZyBtZWNoYW5pc20gWCIpIHRvIHVzZSBpdC4N ClBhc2NhbD9zIHByb3Bvc2FsIGRvZXMgbm90IGNoYW5nZSB0aGlzIHNpdHVhdGlvbiBvbmUgaW90 YTogSXQgZG9lc24/dCBqZW9wYXJkaXplIGludGVyb3BlcmFiaWxpdHkgd2hlcmUgdGhlcmUgd2Fz IGludGVyb3BlcmFiaWxpdHkgYmVmb3JlLg0KDQooTm90ZSBhbHNvIHRoYXQgd2UgYWxyZWFkeSBk aXNjYXJkZWQgTE9XUEFOX0hDMSBhbmQgTE9XUEFOX0hDMiBmcm9tIFJGQyA0OTQ0IGFuZCByZXBs YWNlZCB0aGVtIHdpdGggUkZDIDYyODIuKQ0KDQpBZ2FpbiwgSSBiZWxpZXZlIHdlIG5lZWQgdG8g bGVhcm4gbW9yZSBhYm91dCB0aG9zZSByZXBvcnRlZCB1c2FnZXMgb2YgdGhlIG9sZCBNZXNoIEhl YWRlciBiZWZvcmUgd2UgY2FuIG1lYW5pbmdmdWxseSBjb250aW51ZSB0aGlzIGFyZ3VtZW50Lg0K DQpHcj8/ZSwgQ2Fyc3Rlbg0K --_000_E045AECD98228444A58C61C200AE1BD848A86297xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNzY3NzkyOTk7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03Njk5MDgyNDQgNjc2OTg3MDUgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gTWFydGluOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SeKAmWQgZ2xhZGx5IGV4Y2hhbmdlIHdpdGggeW91IG9uIGFsbCB0aGUgdG9waWNzIHlvdSBy YWlzZSwgYWxsIHJlbGV2YW50IGFuZCBpbnRlcmVzdGluZy4gQnV0IGZvciB0aGlzIHBhcnRpY3Vs YXIgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHdlIHNob3VsZCBtb3ZlIGZvcndhcmQNCiB3aXRoIDZM b1JILCBJIHdvdWxkIG5vdCBkaXNjdXNzIHRoZSB3b3JraW5ncyBvZiBSUEwuIFdoZXRoZXIgUlBM IG9yIHNvbWV0aGluZyBlbHNlIHNldHMgdGhlIFJIIGlzIGlycmVsZXZhbnQgdG8gdGhpcyBkcmFm dDsgd2hhdOKAmXMgcmVsZXZhbnQgaXMgdGhlIGV4YWN0IHNlbWFudGljcyBvZiB0aGUgZW50cmll cyBpbiB0aGUgUkgsIGUuZy4gbG9vc2UgdnMuIHN0cmljdCwgYWRkcmVzcyBjb21wcmVzc2lvbiB0 ZWNobmlxdWUsIGV0Y+KApiBZZXQgY2VydGFpbmx5LA0KIGlmIHlvdSB3aXNoLCB3ZSBjYW4gaGF2 ZSBhIGNoYXQgb24gUlBMIGF0IFJPTEwuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnJvbSB5b3VyIG1haWwgSSByZWFk IGEgZGVzaXJlIHRvIHNwbGl0IHRoZSBvcmlnaW5hbCBxdWVzdGlvbiBpbiAyOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U2hvdWxkIHdlIGJlIGRvaW5nIDZMb1JIIGF0IGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYg d2UgZG8sIHdoZXJlIGRvIHdlIHRha2UgdGhlIGJpdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNhbiBJIHJlYWQgdGhh dCB5b3XigJlkIGFuc3dlciB5ZXMgdG8gcXVlc3Rpb24gMSkgYnV0IHByb3Bvc2UgYW4gYWx0ZXJu YXRlIGZyb20gdGhlIGRyYWZ0IGFwcHJvYWNoIGZvciAyKSA/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGFk ZCB0byB0aGUgcGljdHVyZSB0aGF0IHJlZ2FyZGxlc3Mgb2YgdGhlIHNwZWNpZmljIGZvcm1hdHMg b2YgdGhlIFJGQyA0OTQ0IG1lc2ggaGVhZGVyIGFuZCBSSDMtNkxvUkgsIHRoZXJlIGlzIGEgbmVl ZCB0byBkZWZpbmUgYW4gaW50ZXJvcGVyYWJsZSBvcGVyYXRpb24NCiBvbiBzZXR0aW5nIHRoZSBl bnRyaWVzIGluIHRoZSBSSCwgYW5kIHRoZW4gZm9yd2FyZGluZyBmcmFtZXMgYmFzZWQgb24gd2hh dOKAmXMgdGhlcmUuIFRoaXMgaXMgY2VydGFpbmx5IHNvbWV0aGluZyB0aGF0IEkgd2FudCB0byBz ZWUgZGV0YWlsZWQgaW4gNkxvUkgsIHRob3VnaCBhZG1pdHRlZGx5IGl04oCZcyBub3QgZG9uZSB5 ZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGlzIG1heSBub3QgaGF2ZSBiZWVuIHNvIGNsZWFybHkgc3BlbGxlZCBv dXQgaW4gUkZDIDQ5NDQsIGVpdGhlciwgYnV0LCBiZWNhdXNlIDZMb1dQQU4gd2FzIGNoYXJ0ZXJl ZCBmb3IgODAyLjE1LjQsIGl0IHdhcyBpbXBsaWNpdGx5IDgwMi4xNS40IGFkZHJlc3Nlcywgd2hp Y2gNCiB3ZXJlIGV4cHJlc3NlZCBlaXRoZXIgYXMgc2hvcnQgYWRkcmVzc2VzLCBQQU5JRCAmIzQz OyBzaG9ydCBhZGRyZXNzLCBvciBmdWxsIE1BQzY0LiBXaXRoIHRoaXMgaW4gbWluZCwgaW50ZXJv cGVyYXRpb24gd2FzIGVmZmVjdGl2ZWx5IGd1YXJhbnRlZWQgYXMgc2hvdWxkIGJlIGZvciBhbnkg UkZDLiBUaGlzIGlzIHdoeSBJIHRha2UgdGhhdCBiYXNlbGluZSBhcyB0aGUgcmVmZXJlbmNlIGZv ciBjbGFpbWluZyA2TG9XUEFOIGNvbXBsaWFuY2UgYW5kIGRvDQogbm90IGJ1eSBhbiBvdmVybG9h ZCB0byBMMyBhZGRyZXNzZXMgYXMgY29tcGxpYW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T1RPSCwgd2l0aCA2bG8s IHdlIGFyZSBleHRlbmRpbmcgNkxvV1BBTiBiZXlvbmQgODAyLjE1LjQuIExvY2tpbmcgMS8zIG9m IHRoZSBkaXNwYXRjaCBzcGFjZSB0byA4MDIuMTUuNCBzcGVjaWZpYyBmb3JtYXRzIGlzIGp1c3Qg bm90IGFjY2VwdGFibGUsIGFuZCBmb3IgdGhhdA0KIHJlYXNvbiwgSSBjb21wbGV0ZWx5IGFncmVl IHdpdGggeW91ciBzdWdnZXN0aW9uIHRvIHJldXNlIHRob3NlIGJpdHMgZm9yIEwzIG9wZXJhdGlv bnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGUgY2F2ZWF0IGlzIHdoZXRoZXIgb25lIG1ha2VzIHRoZSBjaG9pY2Ug dG8gbG9vayBhbmQgZmVlbCBsaWtlIHRoZSBzdGFuZGFyZCwgYnV0LCBhdCB0aGUgc2FtZSB0aW1l LCBhY2NlcHRzIG5vdCB0byBpbnRlcm9wZXJhdGUgd2l0aCBkZXZpY2VzIHRoYXQgaW1wbGVtZW50 ZWQNCiB0aGUgc3RhbmRhcmQgYXMgaXQgd2FzIGludGVuZGVkIGFuZCBpbXBsZW1lbnRlZCBvcmln aW5hbGx5LiBJZiBhIGdpdmVuIGltcGxlbWVudGF0aW9uIHBsYWNlcyBhIGNvbXByZXNzZWQg4oCT b3Igd29yc2UsIHVuY29tcHJlc3NlZC0gSVB2NiBhZGRyZXNzIGluIGEgTUgsIGFuZCBzb21lIG90 aGVyIGV4cGVjdHMgb25seSBjb21wcmVzc2VkIE1BQyBhZGRyZXNzZXMsIGNvbXBsaWFuY2UgdG8g dGhlIGZvcm1hdCBtYXkgYmUgZW5zdXJlZCwgYnV0IGludGVyb3BlcmF0aW9uDQogaXMgbm90IGFj aGlldmVkLCBhbmQgdGhlIHB1cnBvc2Ugb2YgdGhlIHN0YW5kYXJkIGlzIGRlZmVhdGVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayBpbiBmYWN0IHRoYXQgaXQgaXMgY3JpdGljYWwgZm9yIHRoZSBJRVRGIHRv IHByZXNlcnZlIGl0cyByb2xlIGFzICZuYnNwO2Egc3RhbmRhcmQgYm9keSB0aGF0IGRlZmluZXMg aW50ZXJvcGVyYWJsZSBzdGFuZGFyZHMsIGFuZCBwYXJ0IG9mIHRoYXQgaXMgdG8gY29udHJvbA0K IHdoZW4gYSBicmVha2FnZSBpcyBoYXBwZW5pbmcgaW4gYmFja3dhcmQgY29tcGF0aWJpbGl0eS4g QW5kIGVmZmVjdGl2ZWx5LCB0aGUgNkxvUkggcHJvcG9zaW5nIGEgYnJlYWssIHRob3VnaCB0aGUg d2F5IGl0IGlzIHNwZWxsZWQgb3V0LCB3ZSB0cnkgdG8gcmVzcGVjdCBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgb2YgODAyLjE1LjQgbWVzaCBuZXR3b3Jrcywgd2hldGhlciB0aGV5IGFyZSBmdWxs eSBjb21wbGlhbnQgdG8gNkxvV1BBTiBvciBub3QuDQogVGhlIG9ubHkgd2F5IHRvIGRvIHRoYXQg aXMgdG8gYWNjZXB0IHRoYXQgaW5jb21wYXRpYmxlIG5ldHdvcmtzIGFyZSBzZWdyZWdhdGVkLiBP biB0aGUgd2F5LCB3ZSBuZWVkIGEgY2xlYXIgc3RhdGVtZW50IG9mIHdoYXQgaXMgY29tcGF0aWJs ZS4gQW5kIHdlIHRydXN0IHN0YW5kYXJkIGNvbXBsaWFuY2UgdG8gaW5kaWNhdGUgY29tcGF0aWJp bGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPldl4oCZZCBuZWVkIHRoZSBhbnN3ZXIgdG8gQ2Fyc3RlbuKAmXMgcXVl c3Rpb24gYWJvdXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHRoYXQgdXNlIHRoZSBSRkMgNDk0 NCBNSCBhbmQgY2xhaW0gY29tcGxpYW5jZSBpbiBvcmRlciB0byBhc3Nlc3MgdGhlIGRhbWFnZSwg aWYgYW55Lg0KICZuYnNwO0lmIHdlIGFyZSBhbHJlYWR5IGluIGEgc2l0dWF0aW9uIHdoZXJlIHdl IGNhbm5vdCBleHBlY3QgaW50ZXJvcGVyYXRpb24gYmV0d2VlbiBhbGwgZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zLCBidXQgb25seSBiZXR3ZWVuIHRob3NlIHdpdGggYSBzcGVjaWFsIGFncmVlbWVu dCB0aGF0LCBieSB0aGUgd2F5LCB3YXMgbm90IHZhbGlkYXRlZCBieSB0aGUgSUVURiwgdGhlbiBh bHJlYWR5IHdlIGhhdmUgaW1wbGVtZW50YXRpb25zIHRoYXQgY2Fubm90DQogYmUgZGVwbG95ZWQg aW4gYSBzYW1lIG5ldHdvcmsuIDZMb1JIIHdvdWxkIG5vdCBiZSBjaGFuZ2luZyB0aGF0IHBpY3R1 cmUsIGJ1dCBpcyBjbGVhcmx5IGFuIGF0dGVtcHQgdG8gYXZvaWQgaXQgaW4gdGhlIGZ1dHVyZSBi eSBwcm92aWRpbmcgYW4gZXh0ZW5zaWJsZSBmcmFtZXdvcmsuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gNmxvIFttYWlsdG86NmxvLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcnRpbiBUdXJvbjxicj4NCjxiPlNlbnQ6 PC9iPiBtYXJkaSAyIGTDqWNlbWJyZSAyMDE0IDA5OjM2PGJyPg0KPGI+VG86PC9iPiBDYXJzdGVu IEJvcm1hbm47IEphbWVzIFdvb2R5YXR0OyA2dGlzY2hAaWV0Zi5vcmc7IFJvdXRpbmcgT3ZlciBM b3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzOyA2bG9AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFs2bG9dIFJvbGwgRGlnZXN0LCBWb2wgODMsIElzc3VlIDM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBDYXJzdGVuLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIG1lc2ggaGVhZGVy IGFyZSBjbGVhcjogdGhlIHNvdXJjZSBpbnNlcnRzIGl0J3Mgb3duIGFkZHJlc3MsIGFuZCB0aGUg YWRkcmVzcyBvZiBhIG11bHRpLWhvcCBmaW5hbCBkZXN0aW5hdGlvbiBhZGRyZXNzLCBhbmQgdGhl biBzZW5kcyBpdCB0byB0aGUgYmVzdCBuZXh0IGhvcCBvbiAmcXVvdDt0aGUgcGF0aCZxdW90Oy4m bmJzcDsgRWFjaCBub2RlIHRoYXQgcmVjZWl2ZXMgaXQsIGFsc28gZm9yd2FyZHMNCiB0byB0aGUg bmV4dCBiZXN0IGhvcCBvbiAmcXVvdDt0aGUgcGF0aCZxdW90OywgZGVjcmVtZW50aW5nIGhvcHMg bGVmdCBhcyBpdCBkb2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0 eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJs aW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6Ymxh Y2siPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQu NHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDEgMHxWfEZ8SG9wc0xmdHwgb3JpZ2luYXRvciBhZGRyZXNz LCBmaW5hbCBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5l LWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAzOiBNZXNoIEFkZHJlc3NpbmcgVHlwZSBhbmQgSGVh ZGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhvdyB0aGUgYmVzdCBwYXRoIGlzIGRldGVybWluZWQgZGVwZW5kcyBvbiB0aGUg cm91dGluZyBwcm90b2NvbCBydW5uaW5nIG9uIHRoYXQgbm9kZS4mbmJzcDsgSWYgUlBMIGlzIHJ1 bm5pbmcsIGl0IGNvdWxkIHVzZSB0aGUgdHJlZSBmb3IgdXBzdHJlYW0gb3IgdW5rbm93biBwYXRo cywgb3IgY2FjaGVkIGJlc3QtbmV4dC1ob3AgZm9yIGRvd25zdHJlYW0gcGF0aHMuJm5ic3A7IE15 IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHdpZGUgcmVzZWFyY2gNCiBpbiB0aGlzIGFyZWEgaXMgdGhh dCBsb2NhbCByb3V0ZSBkZWNpc2lvbnMgYXJlIG11Y2ggbW9yZSBlZmZpY2llbnQgYW5kIHNjYWxh YmxlIHRoYW4gc291cmNlIHJvdXRpbmcsIGFuZCBJJ20gZnJhbmtseSBzdXJwcmlzZWQgUlBMIGRv ZXNuJ3QgdXNlIHRoZSBtZXNoIGhlYWRlciBtb3JlISZuYnNwOyBXaHkgbm90PyZuYnNwOyBKdXN0 IGNhbGwgaXQgYSBoaWdobHkgY29tcHJlc3NlZCBsYXllciAzIGlwLWluLWlwIGVuY2Fwc3VsYXRp b24gd2l0aGluIDZsby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SXQgY2VydGFpbmx5IGlzbid0IGFueSBsZXNzIGNsZWFyIHRoYW4gaG93IFJQ TCBkb2VzIHNvdXJjZSByb3V0aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSZuYnNwOyZuYnNwOyZuYnNwOyAtJiM0MzstJm5ic3A7Jm5i c3A7Jm5ic3A7IC0mIzQzOyAuLi4gJiM0MzstJm5ic3A7Jm5ic3A7Jm5ic3A7IC0mIzQzOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8MXwwfDB8Jm5ic3A7IFNpemUmbmJzcDsmbmJzcDsg fDZMb1JIIFR5cGUgMC4uNHwgSG9wMSB8IEhvcDIgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IEhvcE4gfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mbmJzcDsmbmJzcDsmbmJzcDsgLSYjNDM7LSZuYnNw OyZuYnNwOyZuYnNwOyAtJiM0MzsgLi4uICYjNDM7LSZuYnNwOyZuYnNwOyZuYnNwOyAtJiM0Mzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgU2l6ZSBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiBjb21wcmVzc2VkIGFk ZHJlc3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUg MzogVGhlIFJIMy02TG9SSDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFuc3dlcnMgdG8gbWFueSBxdWVzdGlvbnMgd291bGQg YmUgdGhlIHNhbWU6ICZuYnNwO0hvdyBhcmUgdGhlIGhvcE4gYWRkcmVzc2VzIGRldGVybWluZWQg aW4gUlBMIHNvdXJjZSByb3V0aW5nPyZuYnNwOyBXaGljaCBub2RlIGluc2VydHMgdGhvc2UgYWRk cmVzc2VzPyZuYnNwOyBIb3cgZG9lcyBhIHNpbmdsZSBub2RlIGtub3cgdGhlIG9wdGltYWwgcGF0 aCB0aHJvdWdoIHRoZSBtZXNoPyZuYnNwOyBIb3cgaXMgdGhhdCB1c2UgYW55IG1vcmUNCiBjbGVh ciB0aGFuIHRoZSBtZXNoIGhlYWRlcj8mbmJzcDsgSSB3b3VsZCBhcmd1ZSB0aGF0IGFsbCB0aGF0 IGtub3dsZWRnZSwgY291cGxlZCB3aXRoIGFuIGFzc3VtcHRpb24gdGhhdCBpbnRlcm1lZGlhdGUg aG9wcyBjYW4gYmUgZGV0ZXJtaW5lZCBsb2NhbGx5IHdpdGhpbiB0aGUgbWVzaCwgY291bGQganVz dCBhcyBlYXNpbHkgZ2VuZXJhdGUgYSB2YWxpZCBtZXNoIGhlYWRlciB1c2FibGUgYnkgUlBMLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRpbmcgb3RoZXIgY2FuZGlkYXRlIGRpc3BhdGNoIGJpdHMgZm9yIHJlcHVycG9zaW5nIGluIFJG QzQ4NDQsIGhvdyBhYm91dCAwMTAgeHh4eCAwPyZuYnNwOyBXZSBrbm93IExPV1BBTl9IQzEgaGFz IGJlZW4gZGVwcmVjYXRlZC4mbmJzcDsgQW55IExPV1BBTl9CQzAgZmFucyBvdXQgdGhlcmU/ICZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NeSBwZXJzb25hbCBwcmVmZXJlbmNlIHdpdGggYWxsIHRoaXMgd291bGQgYmUgdG8gc3RhYmls aXplIDZsbywgcHJlc2VydmUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYXMgbXVjaCBhcyBwb3Nz aWJsZSwgc2ltaWxhciB0byBob3cgeDg2IGRpZCwgYW5kIGV4dGVuZCBpdCB2ZXJ5IGNhcmVmdWxs eSB3aXRoIG5ldywgZnVsbCBieXRlIGRpc3BhdGNoIHNlcXVlbmNlczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGF0dGVybiZuYnNwOyZuYnNw OyZuYnNwOyBIZWFkZXIgVHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUt aGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMDAmbmJz cDsgeHh4eHh4IHwgTkFMUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE5v dCBhIExvV1BBTiBmcmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDAxJm5ic3A7IDAwMDAwMSB8IElQdjYmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBVbmNvbXByZXNzZWQgSVB2NiBBZGRyZXNzZXMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCAwMSZuYnNwOyAwMDAwMTAgfCBMT1dQQU5fSEMxIC0gTE9XUEFOX0hDMSBjb21w cmVzc2VkIElQdjYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAwMSZuYnNwOyAwMDAwMTEgfCByZXNlcnZlZCZu YnNwOyZuYnNwOyAtIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgLi4uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwgcmVzZXJ2ZWQmbmJzcDsmbmJzcDsgLSBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDAxJm5ic3A7IDAwMTExMSB8IHJlc2VydmVk Jm5ic3A7Jm5ic3A7IC0gUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCAwMSZuYnNwOyAwMTAwMDAgfCBMT1dQQU5fQkMwIC0gTE9XUEFOX0JD MCBicm9hZGNhc3QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCAwMSZuYnNwOyAwMTAwMDEgfCByZXNlcnZlZCZuYnNwOyZuYnNwOyAtIFJlc2VydmVk IGZvciBmdXR1cmUgdXNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUt aGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsgLi4uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgcmVzZXJ2ZWQmbmJzcDsm bmJzcDsgLSBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IDxiPjAxJm5ic3A7IDAxMTExMSB8IExPV1BBTl9SSCZuYnNwOyAtIDwvYj48L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5kcmFmdC10aHViZXJ0 LTZsby1yb3V0aW5nLWRpc3BhdGNoLTAwJm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCA8Yj4wMSZuYnNwOyAxeHh4eHgg fCBMT1dQQU5fSVBIQyAtIFJGQzYyODImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3w8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMDEmbmJzcDsgMTExMTExIHwg RVNDJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gQWRkaXRpb25h bCBEaXNwYXRjaCBieXRlIGZvbGxvd3MgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCAxMCZuYnNwOyB4eHh4eHggfCBNRVNIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0gTWVzaCBIZWFkZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCAxMSZuYnNwOyAwMDB4eHggfCBGUkFHMSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtIEZyYWdtZW50YXRpb24gSGVhZGVyIChmaXJzdCkmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWln aHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAxMSZuYnNwOyAw MDEwMDAgfCByZXNlcnZlZCZuYnNwOyZuYnNwOyAtIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgLi4uJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgcmVzZXJ2ZWQmbmJzcDsmbmJzcDsgLSBSZXNlcnZlZCBm b3IgZnV0dXJlIHVzZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhl aWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDExJm5ic3A7 IDAxMTExMSB8IHJlc2VydmVkJm5ic3A7Jm5ic3A7IC0gUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2Um bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAxMSZuYnNwOyAxMDB4eHggfCBGUkFH TiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEZyYWdtZW50YXRpb24gSGVhZGVyIChz dWJzZXF1ZW50KXw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVp Z2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMTEmbmJzcDsg MTAxMDAwIHwgcmVzZXJ2ZWQmbmJzcDsmbmJzcDsgLSBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IC4uLiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHJlc2VydmVkJm5ic3A7Jm5ic3A7IC0gUmVzZXJ2ZWQg Zm9yIGZ1dHVyZSB1c2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1o ZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAxMSZuYnNw OyAxMTExMTEgfCByZXNlcnZlZCZuYnNwOyZuYnNwOyAtIFJlc2VydmVkIGZvciBmdXR1cmUgdXNl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIGV2ZXJ5b25lIHNlZW1zIHRvIGFncmVlLCBJb1QgaXMgbWF0dXJpbmcsIDZsbyBpcyBncm93 aW5nIGluIGFkb3B0aW9uLCBhbmQgd2UgZG9uJ3Qgd2FudCB0byBjcmVhdGUgYSBjb25mdXNlZCBz aXR1YXRpb24gYmVmb3JlIGl0IGV2ZW4gZ2V0cyBzdGFydGVkIGJ5IGZvcmtpbmcgdGhlIHByb3Rv Y29sIGFyYml0cmFyaWx5LiZuYnNwOyBDaGFuZ2VzIHNob3VsZCBzdGF5IG9uIHRoZSBjb25zZXJ2 YXRpdmUgc2lkZSwgYW5kDQogYWRkaW5nIGEgY2xlYXIgdmVyc2lvbmluZyBtZXRob2QgbmVlZHMg dG8gYmUgc3Ryb25nbHkgY29uc2lkZXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFydGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+TWVzc2FnZTogMjxicj4NCkRhdGU6IFR1ZSwgMiBEZWMgMjAxNCAwNjo0MToxNyAmIzQz OzAxMDA8YnI+DQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpjYWJv QHR6aS5vcmciIHRhcmdldD0iX2JsYW5rIj5jYWJvQHR6aS5vcmc8L2E+Jmd0Ozxicj4NClRvOiBK YW1lcyBXb29keWF0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpod0BuZXN0bGFicy5jb20iIHRhcmdl dD0iX2JsYW5rIj5qaHdAbmVzdGxhYnMuY29tPC9hPiZndDs8YnI+DQpDYzogJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOjZ0aXNjaEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZ0aXNjaEBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj42dGlzY2hAaWV0Zi5vcmc8L2E+Jmd0OywgUm91dGluZyBPdmVyIExvdyBwb3dlciBh bmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTG9zc3kgbmV0d29ya3MgJmx0Ozxh IGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cm9sbEBpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86NmxvQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+NmxvQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZsb0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsb0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDog UmU6IFtSb2xsXSBbNnRpc2NoXSBbNmxvXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC10aHViZXJ0LTZsby1yb3V0 aW5nLWRpc3BhdGNoLTAwLnR4dDxicj4NCk1lc3NhZ2UtSUQ6ICZsdDs8YSBocmVmPSJtYWlsdG86 NjY5QjU1REYtNDI1MC00RTQ1LUI1NUYtMDNGNzA1RjRERkIwQHR6aS5vcmciIHRhcmdldD0iX2Js YW5rIj42NjlCNTVERi00MjUwLTRFNDUtQjU1Ri0wM0Y3MDVGNERGQjBAdHppLm9yZzwvYT4mZ3Q7 PGJyPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04PGJyPg0KPGJyPg0K T24gMDEgRGVjIDIwMTQsIGF0IDIwOjIwLCBKYW1lcyBXb29keWF0dCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpod0BuZXN0bGFicy5jb20iIHRhcmdldD0iX2JsYW5rIj5qaHdAbmVzdGxhYnMuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgUkZDIDQ5NDQgaXMgYSBQcm9wb3NlZCBT dGFuZGFyZCwgd2hpY2ggcHV0cyBpdCBpbnRvIHRoZSBzYW1lIGNhdGVnb3J5IGFzICZxdW90O1Ry YW5zbWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBFdGhlcm5ldCBOZXR3b3JrcyZxdW90OyBb UkZDIDI0NjRdLDxicj4NCjxicj4NClRoYXQgYXJndW1lbnQgd291bGQgYmUgbW9yZSBjb252aW5j aW5nIGlmIHRoZSBzaXR1YXRpb25zIHdlcmUgaW5kZWVkIGNvbXBhcmFibGUuPGJyPg0KPGJyPg0K UkZDIDI0NjQgaXMgdGhlIGJhc2lzIGZvciB3aWRlbHkgZGVwbG95ZWQgcGx1Zy1hbmQtcGxheSBp bnRlcm9wZXJhYmlsaXR5Ljxicj4NCipUaGF0KiBpcyB3aGF0IG1ha2VzIGl0IG1vc3RseSBpbW11 dGFibGUsIG5vdCB0aGUgc3RhbmRhcmRzIHN0YXR1cy48YnI+DQooV2hpY2ggcHJvYmFibHkgc2hv dWxkIGJlIHVwZ3JhZGVkIHRvIG1hdGNoIHJlYWxpdHkuKTxicj4NCjxicj4NCldpdGggUkZDIDQ5 NDQsIHdlIGhhdmVuP3QgcmVhY2hlZCB0aGF0IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgeWV0 Ljxicj4NCkluIHBhcnRpY3VsYXIsIHRoZXJlIGlzICpubyogd2F5IHRvIGFjaGlldmUgb3V0LW9m LXRoZS1ib3ggaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRoZSBvbGQgbWVzaCBoZWFkZXIgPyB0aGVy ZSBpcyBubyBkZWZpbmVkIHdheSB0byB1c2UgaXQsIG9yIGV2ZW4gdG8gZmluZCBvdXQgdGhhdCAo YW5kIGhvdykgaXQgc2hvdWxkIGJlIHVzZWQuPGJyPg0KU28geW91IGFscmVhZHkgaGF2ZSB0byBh ZGQgY29uZmlndXJhdGlvbiAoYXMgaW4sICZxdW90O3VzZSBtZXNoIGZvcndhcmRpbmcgbWVjaGFu aXNtIFgmcXVvdDspIHRvIHVzZSBpdC48YnI+DQpQYXNjYWw/cyBwcm9wb3NhbCBkb2VzIG5vdCBj aGFuZ2UgdGhpcyBzaXR1YXRpb24gb25lIGlvdGE6IEl0IGRvZXNuP3QgamVvcGFyZGl6ZSBpbnRl cm9wZXJhYmlsaXR5IHdoZXJlIHRoZXJlIHdhcyBpbnRlcm9wZXJhYmlsaXR5IGJlZm9yZS48YnI+ DQo8YnI+DQooTm90ZSBhbHNvIHRoYXQgd2UgYWxyZWFkeSBkaXNjYXJkZWQgTE9XUEFOX0hDMSBh bmQgTE9XUEFOX0hDMiBmcm9tIFJGQyA0OTQ0IGFuZCByZXBsYWNlZCB0aGVtIHdpdGggUkZDIDYy ODIuKTxicj4NCjxicj4NCkFnYWluLCBJIGJlbGlldmUgd2UgbmVlZCB0byBsZWFybiBtb3JlIGFi b3V0IHRob3NlIHJlcG9ydGVkIHVzYWdlcyBvZiB0aGUgb2xkIE1lc2ggSGVhZGVyIGJlZm9yZSB3 ZSBjYW4gbWVhbmluZ2Z1bGx5IGNvbnRpbnVlIHRoaXMgYXJndW1lbnQuPGJyPg0KPGJyPg0KR3I/ P2UsIENhcnN0ZW48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E045AECD98228444A58C61C200AE1BD848A86297xmbrcdx01ciscoc_-- From nobody Tue Dec 2 12:16:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B851A7023; Tue, 2 Dec 2014 12:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LITTLE=1.555, RCVD_IN_DNSWL_NONE=-0.0001] 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 7ibxBVv57r0F; Tue, 2 Dec 2014 12:16:01 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan11.extendcp.co.uk [79.170.45.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95A71A6FCA; Tue, 2 Dec 2014 12:16:00 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Xvtrb-0005n8-6I; Tue, 02 Dec 2014 20:15:59 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XvtrY-0003oV-Mg; Tue, 02 Dec 2014 20:15:59 +0000 Received: from host86-167-76-190.range86-167.btcentralplus.com ([86.167.76.190] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XvtrX-00056G-Sx; Tue, 02 Dec 2014 20:15:56 +0000 Message-ID: <547E1E07.8020800@gridmerge.com> Date: Tue, 02 Dec 2014 20:16:07 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <547CB095.8050709@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070306080205090906060509" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/x-zcmmGTlYWKRDSO2T9zt4FomRo Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:16:05 -0000 This is a cryptographically signed message in MIME format. --------------ms070306080205090906060509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Pascal, Comments inline. Robert On 02/12/2014 3:31 PM, Pascal Thubert (pthubert) wrote: > Hello Robert: > > I agree with you. This is exactly the dilemma. But I do not read your = own advice in there? The point I was trying to make is that whilst there may be a case=20 for changing something in an incompatible way due to "limited=20 deployment", it is a) hard to draw the line at what "limited" means and=20 b) it's sets a precedent for a specification to change further in the=20 future. Whilst I accept that progress is inevitable, it is=20 counterproductive if it happens too quickly. So what I was asking in=20 essence was which side of the "limited deployment" line do people see=20 the use of the mesh header? I confess I am sitting on the fence at the=20 moment. > > For your questions on the draft: > >> Also a comment re. section 8, I think the 'I' field needs to be 1, as >> 'Size' represents the HopsLft field, not the size of the header. > I think you got it reversed. ' I' set is the can-ignore case where the = size in a length in bytes to be skipped if not understood. > > The text says: > "If the I Flag is set, the Size / Format field contains the Length of t= he 6LoRH expressed in bytes." > > Which means > (I =3D=3D0 ) =3D> "Size field contains length in bytes" > > So > "the Size field does not contain the Length in bytes" =3D> (I=3D0) Yes, I did get it wrong. I do think the description of the 'I' bit=20 could be clearer. For example, why not describe the two cases like this: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .......... +-+ |1|0|0| TSE | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .......... +-+ <-- Implied length --> where 'TSE' means 'Type specific extension', which is described in each=20 case of type and the length is either implied or explicitly stated after = the type field. The other case is: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ |1|0|1| Length | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ <-- Length --> which is the length case, which can be skipped by implementations that=20 do not understand the type. 'Size' and 'length' are terms that are too=20 similar in my opinion. > > >> It also doesn't seem to cover the Deep Hops Left concept in RFC4944. > The ' Deep Hops Left ' comes from a structural limitation of the mesh h= eader in RFC 4944, which encodes a hops left. No such thing here. > The idea is that you place as many consecutive RH3-6LoRH as you need. We are talking about MH-6LoRH not RH3-6LoRH, aren't we? Hops left=20 can also be more than 6 bits? Perhaps an illustration would help. > This is how we do not max out the number of hops, and also how we han= dle the various sizes of compressed addresses. But agreeably, we need to = provide more details on address compression and how the header is strippe= d hop by hop. > Which we will do as a group if we take the 6LoRH path, but would be a w= aste of time if the group rejects this approach overall. > > Thanks for your comments : ) > > Pascal > > >> -----Original Message----- >> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >> Sent: lundi 1 d=E9cembre 2014 19:17 >> To: Pascal Thubert (pthubert); 6lo@ietf.org >> Cc: Routing Over Low power and Lossy networks; 6tisch@ietf.org >> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-= routing- >> dispatch-00.txt >> >> Hi Pascal, >> >> I agree that with hindsight it could be considered a bit greedy of >> RFC4944 to allocate 1/3 of the dispatch code space to the mesh header >> (especially when the definition of it itself is questionable) but what= >> you are advocating is a replacement, not a framework extension. RFC628= 2 >> only deprecated an ESC code, i.e. something which had not yet been use= d, >> which is not quite the same. This effectively makes this at best a new= >> version of 6lowpan (which is difficult to distinguish) or at worst >> arguably a whole new protocol. >> >> Whilst hindsight is a wonderful thing, it can lead to the situation >> where a standard never stands still and keeps evolving. This makes it >> very difficult to develop products as there is always the fear that >> something will change the next year. Upgrading products is often quite= a >> difficult process, especially in the case where there could quite >> feasibly be thousands of deployed devices which may have limited upgra= de >> capability. >> >> I would like to hear what other people think about this. >> >> Also a comment re. section 8, I think the 'I' field needs to be 1, as >> 'Size' represents the HopsLft field, not the size of the header. It al= so >> doesn't seem to cover the Deep Hops Left concept in RFC4944. >> >> Robert >> >> On 27/11/2014 2:03 PM, Pascal Thubert (pthubert) wrote: >>> Dear all: >>> >>> This is a response to the question about the compression of RFC 6553 = on top >> of RFC 6554. >>> It seems exaggerated to consume a dispatch type for the RPL option on= ly. >>> But here, we introduce a routing header which is the equivalent of th= e mesh >> header in RFC 4944; we propose a compressed TLV format that can encode= RH3, >> RPL option, IP-in-IP, and is further extensible, for instance for upco= ming BIER. >>> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressab= le >> space for application only in Mesh-under. >>> This draft reuses that space in Route-over with the assumption that R= oute- >> over will not co-exist in a sma enetwork with Mesh-under encoded in th= e RFC >> 4944 fashion. >>> If there is effectively a need for co-existence, devices have to impl= ement the >> new Mesh-under format that is also proposed in the draft. >>> Comments welcome, >>> Pascal >>> >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: jeudi 27 novembre 2014 14:36 >>> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Tou= tain; >> Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann >>> Subject: New Version Notification for draft-thubert-6lo-routing-dispa= tch- >> 00.txt >>> >>> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt >>> has been successfully submitted by Pascal Thubert and posted to the I= ETF >> repository. >>> Name: draft-thubert-6lo-routing-dispatch >>> Revision: 00 >>> Title: A Routing Header Dispatch for 6LoWPAN >>> Document date: 2014-11-25 >>> Group: Individual Submission >>> Pages: 19 >>> URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo= -routing- >> dispatch-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-ro= uting- >> dispatch/ >>> Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-= dispatch-00 >>> >>> >>> Abstract: >>> This specification provides a new 6LoWPAN dispatch type for use = in >>> Route-over and mixed Mesh-under and Route-over topologies, that >>> reuses the encoding of the mesh type defined in RFC 4944 for pur= e >>> Mesh-under topologies. This specification also defines a method= to >>> compress RPL Option (RFC6553) information and Routing Header typ= e 3 >>> (RFC6554), an efficient IP-in-IP technique and opens the way for= >>> further routing techniques. This extends 6LoWPAN Transmission o= f >>> IPv6 Packets (RFC4944), and is applicable to new link-layer type= s >>> where 6LoWPAN is being defined. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >> until the htmlized version and diff are available at tools.ietf.org. >>> The IETF Secretariat >>> >>> _______________________________________________ >>> 6lo mailing list >>> 6lo@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lo >>> > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --------------ms070306080205090906060509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDEyMDIyMDE2MDdaMCMGCSqGSIb3DQEJBDEWBBSqr5RHD3CpeDlmmtzAvq9pcIvNgjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQAeLxjwF3NzcrYQVz9GYKsmDTIUDAgGZlj/ jziK2EcfpE1Q1nMzcxpXf/vqa2kDmJfX41nsPYSt4ZywFXdyiDjEnDMhA+Thm1lHqT4tWgQu rpjudtG8OJpTBgWd39o72Dl8uy9u9FRwZlWBlrYgP6iNbwxjClpky1sv4BwI6WFIPyo9Z7DX ZVgThwUYktG9L3Iq7KFEdBW33CUib0+JkllL6TRzAomiueXTsejeCO9GOhBls66ddzFN/XEE I73WXtC00LAVCtGNuaHnz05ObfeZb4aS1+rcgf0VB1wRwiRVr45Og5TZL+X+Rebnt2gMD/be CAKpvChlv8XZS7PCKdXYAAAAAAAA --------------ms070306080205090906060509-- From nobody Tue Dec 2 13:46:00 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028CC1A8769; Tue, 2 Dec 2014 13:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.956 X-Spam-Level: X-Spam-Status: No, score=-12.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_LITTLE=1.555, 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 Jau-m3Ed5ger; Tue, 2 Dec 2014 13:45:55 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C061A874B; Tue, 2 Dec 2014 13:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9676; q=dns/txt; s=iport; t=1417556755; x=1418766355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vJNCapW/FKVuVJGfz0tPSqIXGeQhm+hmHPw5Vi0tX1I=; b=LiZfniOqsdPHLvvnMBE3zB/0KY7Mi6f/mMSaXd9qzfl2qu1EX9i4zM8Z NQDKatJBile0b4u2TeNHaDr0EV2/zmsy2JFOD6jOC5Cy9Q4IWuTZR5G3w G/EGviKrAhV7qXgf8/sLRV91jGN54YaRFYUExro74ep6TThQua0V/8ulZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAIwxflStJA2N/2dsb2JhbABbgwdSWQTEaoIcCoYfAoEgFgEBAQEBfYQCAQEBBAEBASRHCQIMBAIBCBEEAQEBCh0HJwsUCAEIAgQBDQUIAYg3DdZCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pghSwLCgwRBisHAgSDI4EfBYpKhBiBf4Q+iBM6gn6DGYkihAKCAiAVgURvgQQCHiKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="102058771" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2014 21:45:54 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB2Ljsbl025221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 21:45:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 15:45:53 -0600 From: "Pascal Thubert (pthubert)" To: "robert.cragie@gridmerge.com" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAhJ356AABfA8A== Date: Tue, 2 Dec 2014 21:45:52 +0000 Deferred-Delivery: Tue, 2 Dec 2014 21:45:00 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <547CB095.8050709@gridmerge.com> <547E1E07.8020800@gridmerge.com> In-Reply-To: <547E1E07.8020800@gridmerge.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.155] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zz8-qwDSLIuwCdL5tGfUAID4Nv0 Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 21:45:58 -0000 Hi Robert: I'm in sync with you now. I will apply the changes that you suggest. And yes, I was confused between MH and RH, and I need to add the deep hops = to the MH description. Finally, for the fence discussion, we try to avoid it by saying that both a= re legal but not in a same network, so we are creating exclusive features b= ut not deprecating them. I know it's a trick, but that's supposed to help the transition for those w= ho wish to transition at all. Thanks for this! Pascal > -----Original Message----- > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: mardi 2 d=E9cembre 2014 12:16 > To: Pascal Thubert (pthubert); 6lo@ietf.org > Cc: Routing Over Low power and Lossy networks; 6tisch@ietf.org > Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-rou= ting- > dispatch-00.txt >=20 > Hi Pascal, >=20 > Comments inline. >=20 > Robert >=20 >=20 > On 02/12/2014 3:31 PM, Pascal Thubert (pthubert) wrote: > > Hello Robert: > > > > I agree with you. This is exactly the dilemma. But I do not read your = own > advice in there? > The point I was trying to make is that whilst there may be a case > for changing something in an incompatible way due to "limited > deployment", it is a) hard to draw the line at what "limited" means and > b) it's sets a precedent for a specification to change further in the > future. Whilst I accept that progress is inevitable, it is > counterproductive if it happens too quickly. So what I was asking in > essence was which side of the "limited deployment" line do people see > the use of the mesh header? I confess I am sitting on the fence at the > moment. > > > > For your questions on the draft: > > > >> Also a comment re. section 8, I think the 'I' field needs to be 1, as > >> 'Size' represents the HopsLft field, not the size of the header. > > I think you got it reversed. ' I' set is the can-ignore case where the = size in a > length in bytes to be skipped if not understood. > > > > The text says: > > "If the I Flag is set, the Size / Format field contains the Length of t= he 6LoRH > expressed in bytes." > > > > Which means > > (I =3D=3D0 ) =3D> "Size field contains length in bytes" > > > > So > > "the Size field does not contain the Length in bytes" =3D> (I=3D0) > Yes, I did get it wrong. I do think the description of the 'I' bit > could be clearer. For example, why not describe the two cases like this: >=20 > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .......... +-+ > |1|0|0| TSE | Type | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .......... +-+ > <-- Implied length --> >=20 >=20 > where 'TSE' means 'Type specific extension', which is described in each > case of type and the length is either implied or explicitly stated after > the type field. The other case is: >=20 > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ > |1|0|1| Length | Type | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ > <-- Length --> >=20 >=20 > which is the length case, which can be skipped by implementations that > do not understand the type. 'Size' and 'length' are terms that are too > similar in my opinion. > >=20 > > > > > >> It also doesn't seem to cover the Deep Hops Left concept in RFC4944. > > The ' Deep Hops Left ' comes from a structural limitation of the mesh h= eader in > RFC 4944, which encodes a hops left. No such thing here. > > The idea is that you place as many consecutive RH3-6LoRH as you need. > We are talking about MH-6LoRH not RH3-6LoRH, aren't we? Hops left > can also be more than 6 bits? Perhaps an illustration would help. > > This is how we do not max out the number of hops, and also how we han= dle > the various sizes of compressed addresses. But agreeably, we need to prov= ide > more details on address compression and how the header is stripped hop by > hop. > > Which we will do as a group if we take the 6LoRH path, but would be a w= aste > of time if the group rejects this approach overall. > > > > Thanks for your comments : ) > > > > Pascal > > > > > >> -----Original Message----- > >> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > >> Sent: lundi 1 d=E9cembre 2014 19:17 > >> To: Pascal Thubert (pthubert); 6lo@ietf.org > >> Cc: Routing Over Low power and Lossy networks; 6tisch@ietf.org > >> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo- > routing- > >> dispatch-00.txt > >> > >> Hi Pascal, > >> > >> I agree that with hindsight it could be considered a bit greedy of > >> RFC4944 to allocate 1/3 of the dispatch code space to the mesh header > >> (especially when the definition of it itself is questionable) but what > >> you are advocating is a replacement, not a framework extension. RFC628= 2 > >> only deprecated an ESC code, i.e. something which had not yet been use= d, > >> which is not quite the same. This effectively makes this at best a new > >> version of 6lowpan (which is difficult to distinguish) or at worst > >> arguably a whole new protocol. > >> > >> Whilst hindsight is a wonderful thing, it can lead to the situation > >> where a standard never stands still and keeps evolving. This makes it > >> very difficult to develop products as there is always the fear that > >> something will change the next year. Upgrading products is often quite= a > >> difficult process, especially in the case where there could quite > >> feasibly be thousands of deployed devices which may have limited upgra= de > >> capability. > >> > >> I would like to hear what other people think about this. > >> > >> Also a comment re. section 8, I think the 'I' field needs to be 1, as > >> 'Size' represents the HopsLft field, not the size of the header. It al= so > >> doesn't seem to cover the Deep Hops Left concept in RFC4944. > >> > >> Robert > >> > >> On 27/11/2014 2:03 PM, Pascal Thubert (pthubert) wrote: > >>> Dear all: > >>> > >>> This is a response to the question about the compression of RFC 6553 = on > top > >> of RFC 6554. > >>> It seems exaggerated to consume a dispatch type for the RPL option on= ly. > >>> But here, we introduce a routing header which is the equivalent of th= e mesh > >> header in RFC 4944; we propose a compressed TLV format that can encode > RH3, > >> RPL option, IP-in-IP, and is further extensible, for instance for upco= ming > BIER. > >>> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressab= le > >> space for application only in Mesh-under. > >>> This draft reuses that space in Route-over with the assumption that R= oute- > >> over will not co-exist in a sma enetwork with Mesh-under encoded in th= e RFC > >> 4944 fashion. > >>> If there is effectively a need for co-existence, devices have to impl= ement > the > >> new Mesh-under format that is also proposed in the draft. > >>> Comments welcome, > >>> Pascal > >>> > >>> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: jeudi 27 novembre 2014 14:36 > >>> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Tou= tain; > >> Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann > >>> Subject: New Version Notification for draft-thubert-6lo-routing-dispa= tch- > >> 00.txt > >>> > >>> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt > >>> has been successfully submitted by Pascal Thubert and posted to the I= ETF > >> repository. > >>> Name: draft-thubert-6lo-routing-dispatch > >>> Revision: 00 > >>> Title: A Routing Header Dispatch for 6LoWPAN > >>> Document date: 2014-11-25 > >>> Group: Individual Submission > >>> Pages: 19 > >>> URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo= -routing- > >> dispatch-00.txt > >>> Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-ro= uting- > >> dispatch/ > >>> Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-= dispatch- > 00 > >>> > >>> > >>> Abstract: > >>> This specification provides a new 6LoWPAN dispatch type for use = in > >>> Route-over and mixed Mesh-under and Route-over topologies, that > >>> reuses the encoding of the mesh type defined in RFC 4944 for pur= e > >>> Mesh-under topologies. This specification also defines a method= to > >>> compress RPL Option (RFC6553) information and Routing Header typ= e 3 > >>> (RFC6554), an efficient IP-in-IP technique and opens the way for > >>> further routing techniques. This extends 6LoWPAN Transmission o= f > >>> IPv6 Packets (RFC4944), and is applicable to new link-layer type= s > >>> where 6LoWPAN is being defined. > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >>> The IETF Secretariat > >>> > >>> _______________________________________________ > >>> 6lo mailing list > >>> 6lo@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lo > >>> > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo > > >=20 From nobody Wed Dec 3 15:37:42 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5901ACEDF; Wed, 3 Dec 2014 15:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 rrQhaqjFTdyA; Wed, 3 Dec 2014 15:37:11 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27821A1B93; Wed, 3 Dec 2014 15:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9848; q=dns/txt; s=iport; t=1417649832; x=1418859432; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vaafSvkC2Kd5RxSG8wdCSHTthOZGJdm5o7m/FQEJl5U=; b=ayJRJHR5hYPFY7JTBK0jcpjFGCxBKnL+rAv0zsdVtoiVXWcVCvxB0sj4 ENK15Q5GnZ+d79P09825NIS5gexl3XuTC/uaEJrJ/q1aKnDRdFeReqg8u ptTZIAfwuYCpI9z6Vd3s7Bao8bVdcBfUJif3nR5tmN+YwaawpKkSNPPHa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8IAIOdf1StJA2M/2dsb2JhbABagkNDUlyDAcEjhCEBhBsCHHkWAQEBAQF9hAMBAQQjCkoCEAIBCA4UIAICAjAcCQIEDg2INsBElkYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkDUxB4JxM4EeBZAPnmCCNYFDgjSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,511,1413244800"; d="scan'208,217";a="377700820" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 03 Dec 2014 23:37:11 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB3NbACn004074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 23:37:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 17:37:10 -0600 From: "Pascal Thubert (pthubert)" To: Martin Turon Thread-Topic: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAPpEACAAH86VIACcTaAgAM5E1A= Date: Wed, 3 Dec 2014 23:37:10 +0000 Deferred-Delivery: Wed, 3 Dec 2014 23:37:00 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> 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.155.144.106] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A88B15xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/VF8tMUt7T3x_nbRYXN-0QdUjwJM Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 23:37:14 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A88B15xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFydGluOg0KDQoNCk9uZSBxdWVzdGlvbiBpbnNwaXJlZCBieSB0aGlzIGlzIGhvdyB3 b3VsZCBuZXdlciBkaXNwYXRjaCBpbXBsZW1lbnRhdGlvbnMgZGVwbG95IHRvIGEgbGVnYWN5IGRp c3BhdGNoIG5ldHdvcms/ICBJbWFnaW5lIGEgbGFyZ2Ugb3BlbiBuZXR3b3JrIHNwYW5uaW5nIGEg Y2l0eSwgd2l0aCBtdWx0aXBsZSB2ZXJzaW9ucyBvZiA2bG8sIGFuZCBtdWx0aXBsZSByb3V0aW5n IHByb3RvY29scyBydW5uaW5nIG9uIHRvcC4gIEl0J3MgYSB2ZXJ5IGFjYWRlbWljLCBmdXR1cmlz dGljIGV4YW1wbGUsIGJ1dCB0cmlnZ2VycyBzb21lIGJhc2ljIHF1ZXN0aW9ucyBsaWtlOiBob3cg aXMgdmVyc2lvbmluZyBoYW5kbGVkIGluIDZsbz8gIEkgYmVsaWV2ZSB2ZXJzaW9uaW5nIGluIDZs byBjdXJyZW50bHkgaXMgYWx3YXlzIGRvbmUgYXQgZGVwbG95bWVudCB0aW1lLiAgSXQgbWF5IGJl IHdvcnRoIGNvbnNpZGVyaW5nIGEgd2F5IHRvIGFkZCBhbiBvcHRpb25hbCB2ZXJzaW9uIGRpc3Bh dGNoIGluIFJISSB0byBzaWduYWwgd2hhdCB2ZXJzaW9uIG9mIDZsbyBpcyBiZWluZyB1c2VkLCBz byBtaXhlZCB2ZXJzaW9uIG5ldHdvcmtzIGluIHRoZSBmdXR1cmUgY2FuIGhhdmUgYSBiZXR0ZXIg Y2hhbmNlIG9mIGNvZXhpc3RpbmcuDQoNCltQVF0gV2VsbCwgYXMgbG9uZyBhcyB3ZSByb3V0ZSwg d2UgY2FuIGludGVyY29ubmVjdCBkaWZmZXJlbnQgbmV0d29ya3MuIFRoZXNlIGNvdWxkIGJlIGRp ZmZlcmVudCB0ZWNobm9sb2dpZXMgbGlrZSBQTEMgYW5kIDE1LjQsIG9yIHRoZXNlIGNvdWxkIGJl IHR3byA4MDIuMTUuNCBuZXR3b3Jrcywgb25lIHVzaW5nIHRoZSBSRkMgNDk0NCBNSCBhbmQgdGhl IG90aGVyIHVzaW5nIHRoZSBMb1JILiBBcyBsb25nIGFzIHRoZSBJUHY2IHBhY2tldCBpcyByZWZv cm1lZCwgcm91dGVkLCBhbmQgdGhlbiByZWNvbXByZXNzZWQgdG8gYWRhcHQgdG8gdGhlIDZMbyBj b21wcmVzc2lvbiBvZiB0aGUgb3V0Z29pbmcgbGluaywgd2UgYXJlIHNhZmUuDQoNCkV2ZW4gaWYg dGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB0b2RheSwgUkZDIDQ5NDQgaXMgbm90IGFuIGludGVy bmV0IHN0ZCBhbmQgd2UgaGF2ZSBqdXN0IHNlZW4gdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoZSBJ b1QuIEJldHRlciBmaXggdGhpbmdzIG5vdyB0aGFuIGxhdGVyLi4uDQoNCk9ubHkgSEMxIGFuZCBI QzIgd2VyZSBkZXByZWNhdGVkIGZyb20gUkZDNDk0NCBhcyBmYXIgYXMgSSBrbm93LiAgRGVwcmVj YXRpbmcgdGhvc2Ugd2FzIHRoZSByaWdodCBkZWNpc2lvbi4gIFRoZXJlIG1heSBiZSBtb3JlIGlu IFJGQzQ5NDQgdGhhdCBjYW4gYmUgY2hhbmdlZCBvciBpbXByb3ZlZCwgYnV0IHRoZSBwb2ludCBp cyB0aGF0IHRoZSBhc3N1bXB0aW9uIG11c3QgYmUgdGhhdCBtb3N0IG9mIGl0IGlzIGluIHVzZSB0 b2RheSwgYW5kIGNvbnNpZGVyYXRpb24gZm9yIHRob3NlIG5ldHdvcmtzIHRoYXQgdXNlIGl0IHNo b3VsZCBiZSBtYWRlLiAgSXQgc291bmRzIGxpa2UgeW91IGhhdmUgYmVlbiBtYWtpbmcgdGhvc2Ug Y29uc2lkZXJhdGlvbnMsIHdoaWNoIGlzIGFwcHJlY2lhdGVkLg0KDQpbUFRdIFRoYW5rcyB0byB5 b3UgZm9yIGEgbGFyZ2UgcGllY2UuDQoNCkNoZWVycw0KDQpQYXNjYWwNCg0K --_000_E045AECD98228444A58C61C200AE1BD848A88B15xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg NzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBNYXJ0aW46PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgcXVlc3Rpb24gaW5zcGlyZWQgYnkgdGhpcyBpcyBob3cg d291bGQgbmV3ZXIgZGlzcGF0Y2ggaW1wbGVtZW50YXRpb25zIGRlcGxveSB0byBhIGxlZ2FjeSBk aXNwYXRjaCBuZXR3b3JrPyZuYnNwOyBJbWFnaW5lIGEgbGFyZ2Ugb3BlbiBuZXR3b3JrIHNwYW5u aW5nIGEgY2l0eSwgd2l0aCBtdWx0aXBsZSB2ZXJzaW9ucyBvZiA2bG8sIGFuZCBtdWx0aXBsZSBy b3V0aW5nIHByb3RvY29scyBydW5uaW5nIG9uIHRvcC4mbmJzcDsNCiBJdCdzIGEgdmVyeSBhY2Fk ZW1pYywgZnV0dXJpc3RpYyBleGFtcGxlLCBidXQgdHJpZ2dlcnMgc29tZSBiYXNpYyBxdWVzdGlv bnMgbGlrZTogaG93IGlzIHZlcnNpb25pbmcgaGFuZGxlZCBpbiA2bG8/Jm5ic3A7IEkgYmVsaWV2 ZSB2ZXJzaW9uaW5nIGluIDZsbyBjdXJyZW50bHkgaXMgYWx3YXlzIGRvbmUgYXQgZGVwbG95bWVu dCB0aW1lLiZuYnNwOyBJdCBtYXkgYmUgd29ydGggY29uc2lkZXJpbmcgYSB3YXkgdG8gYWRkIGFu IG9wdGlvbmFsIHZlcnNpb24gZGlzcGF0Y2gNCiBpbiBSSEkgdG8gc2lnbmFsIHdoYXQgdmVyc2lv biBvZiA2bG8gaXMgYmVpbmcgdXNlZCwgc28gbWl4ZWQgdmVyc2lvbiBuZXR3b3JrcyBpbiB0aGUg ZnV0dXJlIGNhbiBoYXZlIGEgYmV0dGVyIGNoYW5jZSBvZiBjb2V4aXN0aW5nLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W1BUXSBXZWxsLCBhcyBsb25nIGFzIHdlIHJvdXRlLCB3ZSBjYW4gaW50 ZXJjb25uZWN0IGRpZmZlcmVudCBuZXR3b3Jrcy4gVGhlc2UgY291bGQgYmUgZGlmZmVyZW50IHRl Y2hub2xvZ2llcyBsaWtlIFBMQyBhbmQgMTUuNCwgb3IgdGhlc2UgY291bGQgYmUgdHdvJm5ic3A7 ODAyLjE1LjQNCiBuZXR3b3Jrcywgb25lIHVzaW5nIHRoZSBSRkMgNDk0NCBNSCBhbmQgdGhlIG90 aGVyIHVzaW5nIHRoZSBMb1JILiBBcyBsb25nIGFzIHRoZSBJUHY2IHBhY2tldCBpcyByZWZvcm1l ZCwgcm91dGVkLCBhbmQgdGhlbiByZWNvbXByZXNzZWQgdG8gYWRhcHQgdG8gdGhlIDZMbyBjb21w cmVzc2lvbiBvZiB0aGUgb3V0Z29pbmcgbGluaywgd2UgYXJlIHNhZmUuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB0aGVyZSBhcmUgaW1wbGVt ZW50YXRpb25zIHRvZGF5LCBSRkMgNDk0NCBpcyBub3QgYW4gaW50ZXJuZXQgc3RkIGFuZCB3ZSBo YXZlIGp1c3Qgc2VlbiB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhlIElvVC4gQmV0dGVyIGZpeCB0 aGluZ3Mgbm93IHRoYW4gbGF0ZXIuLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9ubHkgSEMxIGFuZCBIQzIgd2VyZSBkZXByZWNh dGVkIGZyb20gUkZDNDk0NCBhcyBmYXIgYXMgSSBrbm93LiZuYnNwOyBEZXByZWNhdGluZyB0aG9z ZSB3YXMgdGhlIHJpZ2h0IGRlY2lzaW9uLiZuYnNwOyBUaGVyZSBtYXkgYmUgbW9yZSBpbiBSRkM0 OTQ0IHRoYXQgY2FuIGJlIGNoYW5nZWQgb3IgaW1wcm92ZWQsIGJ1dCB0aGUgcG9pbnQgaXMgdGhh dCB0aGUgYXNzdW1wdGlvbiBtdXN0IGJlIHRoYXQgbW9zdCBvZiBpdCBpcyBpbg0KIHVzZSB0b2Rh eSwgYW5kIGNvbnNpZGVyYXRpb24gZm9yIHRob3NlIG5ldHdvcmtzIHRoYXQgdXNlIGl0IHNob3Vs ZCBiZSBtYWRlLiZuYnNwOyBJdCBzb3VuZHMgbGlrZSB5b3UgaGF2ZSBiZWVuIG1ha2luZyB0aG9z ZSBjb25zaWRlcmF0aW9ucywgd2hpY2ggaXMgYXBwcmVjaWF0ZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltQVF0gVGhhbmtzIHRv IHlvdSBmb3IgYSBsYXJnZSBwaWVjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NC44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5QYXNjYWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E045AECD98228444A58C61C200AE1BD848A88B15xmbrcdx01ciscoc_-- From nobody Wed Dec 3 16:15:35 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE441ACF5E; Wed, 3 Dec 2014 16:15:10 -0800 (PST) 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 2eyhhOdxZJlI; Wed, 3 Dec 2014 16:15:03 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627D71A8A0D; Wed, 3 Dec 2014 16:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7196; q=dns/txt; s=iport; t=1417652104; x=1418861704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mzeWqeNqJTws7hKvFD6KkoNl4KN3pwtATKxDHbQsJiU=; b=ALAvYY7hus+FjKhBe2FlPPnn2OURclIlPQLGbqDbQVyqt99IBkt5F1wd D1aevMa81dZhsGKEDOjw9bW5+BCkYCCwfmdF3JhtKPord0Fpm6H41ss+L 0B4BXgp8/fvyVK26cvDb1WE0tzVrKH8fIv+6Ze37mMI/eRjX6pG62SK71 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAN6mf1StJA2J/2dsb2JhbABagwZSWATEJIIcCoF7AYNLUAKBFRYBAQEBAX2EAgEBAQQBAQFrCQIMBAIBCBEEAQEBCh0HJwsUCAEIAgQBDQUIAYg1DdZHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pahTQKHTEHBoMegR4FiiGFboQWh1Y4gnWPR4I1gUNvgQNCgQABAQE X-IronPort-AV: E=Sophos;i="5.07,511,1413244800"; d="scan'208";a="102455880" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 04 Dec 2014 00:15:02 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB40F2jj027086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 00:15:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 18:15:02 -0600 From: "Pascal Thubert (pthubert)" To: Richard Kelsey , "Routing Over Low power and Lossy networks" , Martin Turon Thread-Topic: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAPpEACAAH86VIACrHUAgAMJP3A= Date: Thu, 4 Dec 2014 00:15:01 +0000 Deferred-Delivery: Thu, 4 Dec 2014 00:14:00 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> , <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com>, <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> 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.155.144.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/H52kgZEaJ0xtaczLp4dMvBYKjNc Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:15:11 -0000 This is interesting, Richard. At the same time, we need to keep it globally simple, such that by reading = a value on a box we can figure interoperability. Maybe we could have profiles that define where the various ranges are taken= from? Cheers, Pascal > -----Original Message----- > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Richard Kelsey > Sent: lundi 1 d=E9cembre 2014 11:50 > To: Routing Over Low power and Lossy networks; Martin Turon > Cc: 6tisch@ietf.org; 6lo@ietf.org > Subject: Re: [6tisch] FW: New Version Notification for draft-thubert-6lo-= routing- > dispatch-00.txt >=20 > Pascal, >=20 > Given >=20 > "we have just seen the very beginning of the IoT" >=20 > and >=20 > "... to allow in a different network to use the bits > differently knowing that devices will have to be > homogeneous inside one network." >=20 > perhaps a better approach would be to define new 6LoWPAN encodings withou= t > nailing down where they go in the full space. Suppose this new draft ins= tead of > specifying meanings for 10xxxxxx specified a block of 64 consecutive enco= dings > xxxxxx. > If someone wants to use this new encoding and the 4944's MESH they could = put > the new encodings somewhere other than 10xxxxx. > Or the MESH values somewhere else and put the new encodings at 10xxxxx. >=20 > Allowing the actual codes used be determined by the network would avoid > having to nail down which encodings were compatible with which other ones= . > You could mix and match. > All a device needs to know is that encoding A starts at value N and encod= ing B > starts at value M. In setting up a network the starting values could be = chosen to > make the dispatching bit-based as it is now, or some other scheme could b= e > used. >=20 > Just a thought. >=20 > -Richard >=20 > ________________________________________ > From: Roll [roll-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) > [pthubert@cisco.com] > Sent: Sunday, November 30, 2014 3:59 AM >=20 > Hi Martin, >=20 > The discussion already caused a rethinking of the idea. If it is not enou= gh we can > dig further. >=20 > The idea as presented in the draft now is not to deprecate the mesh heade= r but > to allow in a different network to use the bits differently knowing that = devices > will have to be homogeneous inside one network. >=20 > You were the advocate to protect the future by not consuming too many bit= s in > the NHC proposal. You also realize that the mesh header consumes 1/3 of t= he > whole dispatch space, without a way to extend what's done inside. This is= not > protecting the future. >=20 > The new proposal allows to encode the existing MH with limited change but= now > it is extensible. The price to pay is different network. And the question= to the > group is whether that is acceptable. >=20 > Even if there are implementations today, RFC 4944 is not an internet std = and we > have just seen the very beginning of the IoT. Better fix things now than = later... >=20 > Pascal >=20 > > Le 29 nov. 2014 =E0 20:24, Martin Turon a =E9crit= : > > > > Hi Pascal, > > > > I thought the call where this idea of overloading the mesh header was > presented was met with general discontent. > > > > Also, the rfc4944 calls it the mesh header, it isn't called the mesh-un= der > header. The mesh header is very much in use today, and not purely for me= sh- > under conceptual designs. > > > > I would be wary of proposals that greatly alter the 6lo header, especia= lly the > dispatch bits, rather than extend it in very general ways. > > > > Martin > > > >> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" > wrote: > >> > >> Dear all: > >> > >> This is a response to the question about the compression of RFC 6553 o= n top > of RFC 6554. > >> It seems exaggerated to consume a dispatch type for the RPL option onl= y. > >> But here, we introduce a routing header which is the equivalent of the= mesh > header in RFC 4944; we propose a compressed TLV format that can encode RH= 3, > RPL option, IP-in-IP, and is further extensible, for instance for upcomin= g BIER. > >> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressabl= e > space for application only in Mesh-under. > >> This draft reuses that space in Route-over with the assumption that Ro= ute- > over will not co-exist in a sma enetwork with Mesh-under encoded in the R= FC > 4944 fashion. > >> If there is effectively a need for co-existence, devices have to imple= ment the > new Mesh-under format that is also proposed in the draft. > >> > >> Comments welcome, > >> Pascal > >> > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: jeudi 27 novembre 2014 14:36 > >> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent > >> Toutain; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann > >> Subject: New Version Notification for > >> draft-thubert-6lo-routing-dispatch-00.txt > >> > >> > >> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt > >> has been successfully submitted by Pascal Thubert and posted to the IE= TF > repository. > >> > >> Name: draft-thubert-6lo-routing-dispatch > >> Revision: 00 > >> Title: A Routing Header Dispatch for 6LoWPAN > >> Document date: 2014-11-25 > >> Group: Individual Submission > >> Pages: 19 > >> URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-= routing- > dispatch-00.txt > >> Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-rou= ting- > dispatch/ > >> Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-d= ispatch-00 > >> > >> > >> Abstract: > >> This specification provides a new 6LoWPAN dispatch type for use in > >> Route-over and mixed Mesh-under and Route-over topologies, that > >> reuses the encoding of the mesh type defined in RFC 4944 for pure > >> Mesh-under topologies. This specification also defines a method to > >> compress RPL Option (RFC6553) information and Routing Header type 3 > >> (RFC6554), an efficient IP-in-IP technique and opens the way for > >> further routing techniques. This extends 6LoWPAN Transmission of > >> IPv6 Packets (RFC4944), and is applicable to new link-layer types > >> where 6LoWPAN is being defined. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of subm= ission > until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Thu Dec 4 08:32:41 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD01AD4C1; Thu, 4 Dec 2014 08:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 H9ZoYC-uVJNg; Thu, 4 Dec 2014 08:32:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF80E1AD4BB; Thu, 4 Dec 2014 08:32:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A8B4E2002A; Thu, 4 Dec 2014 11:35:57 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C7381637F4; Thu, 4 Dec 2014 11:32:33 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AFBE3637EA; Thu, 4 Dec 2014 11:32:33 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" In-Reply-To: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3NjjKdbtUwIGuiV9O1oR82mqlLY Cc: Routing Over Low power and Lossy networks , Martin Turon , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 16:32:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > One question inspired by this is how would newer dispatch > implementations deploy to a legacy dispatch network? Imagine a large > open network spanning a city, with multiple versions of 6lo, and > multiple routing protocols running on top. It's a very academic, > futuristic example, but triggers some basic questions like: how is > versioning handled in 6lo? I believe versioning in 6lo currently is > always done at deployment time. It may be worth considering a way to > add an optional version dispatch in RHI to signal what version of 6lo > is being used, so mixed version networks in the future can have a > better chance of coexisting.=20 I think that we will manage to version 6lo(wpan) only by create seperate L2 networks... and I think that's okay, we have L3 mesh. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVICMnoCLcPvd0N1lAQJQowf+MLeUITyQie76nxY20ihHOI0UhpvYhFka vrBvbBl8pEYN47pSkNlqDuD85oih5Gjo4CcaT1p1vMKXHyV89Fyt4gZMakLO5WtJ bl+pwxmFprdqAFBv9GxXA295bVUPxIxj0lRjW/NDA6vo/p5HCMKDUA17fGeE4+BF kIEFyFL79IRhT2ROl93rjBm2rnVXinpJN1wZacHz9KBqNg/sAM8lyhyzYf5NAx13 rmnjRzCEjslVzicCwxl6gX3t6E5ZH/Ux+z6YTzTXv6f7G3fzTHhu+TWKHb0X8zjo CatEQyLeILMhuykkgr2pu57KzmxzhWiM/wZFq6w3LFaOQHH4eDxMRQ== =bdvY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 5 02:43:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41361ACE27 for ; Fri, 5 Dec 2014 02:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 eJpmh7DXTkSa; Fri, 5 Dec 2014 02:43:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 069A61ACE33; Fri, 5 Dec 2014 02:43:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205104341.3386.22318.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 02:43:41 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/lCcaKDYO8WfAKBCNefmxTiwxn4o Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 10:43:45 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Fri Dec 5 02:59:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07211ACE3D for ; Fri, 5 Dec 2014 02:59:49 -0800 (PST) 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 7IZHwi1TeI8k; Fri, 5 Dec 2014 02:59:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F081ACE27; Fri, 5 Dec 2014 02:59:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205105948.3846.32482.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 02:59:48 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZVz3wCBYM6F9l43xFAWnebR4k4w Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 10:59:49 -0000 IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation Point raised with document shepherd to check on the status of IPR disclosures. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Fri Dec 5 08:50:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ED31AD039 for ; Fri, 5 Dec 2014 08:50:44 -0800 (PST) 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 ue8WD3yj0bEM; Fri, 5 Dec 2014 08:50:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 386341AD056; Fri, 5 Dec 2014 08:50:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205165039.1253.1760.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 08:50:39 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Nver8AzGx3QiLE_9QoZMvmX20DI Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 16:50:44 -0000 IESG state changed to AD Evaluation from AD Evaluation::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Mon Dec 8 10:47:45 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100731ACD9D for ; Mon, 8 Dec 2014 10:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 Jw2Uq3lkH8Bz for ; Mon, 8 Dec 2014 10:47:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6450D1ACD96 for ; Mon, 8 Dec 2014 10:47:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DFB9420098; Mon, 8 Dec 2014 13:51:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AC23D637F5; Mon, 8 Dec 2014 13:47:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9086A637F4; Mon, 8 Dec 2014 13:47:34 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DGLNIO5Uh5qzxLNjoTd5xAOjJYE Cc: roll@ietf.org, Anders Brandt Subject: Re: [Roll] home-building-requirements section 7.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:47:44 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable You ask: > What are enrollment tools? By this, I mean that the combination of protocols and/or provisioning equipment that allows an installer to make a lightbulb join a particular network. That's why I want to know, if you are going the EAP-PANA route, that one needs to know what EAP methods ought to be supported. peter van der Stok wrote: > thanks for the encouragement. > Concerning bootstrap and security in general. Many things are going o= n and > there are two approaches to this document: > 1) a conservative one; restrict to what exists and is is proven to wo= rk > 2) leaving the doubt that exists today. > For the moment I like to leave the doubt, because in 5 years, what is= sure > today will not be implemented is my conviction > Concerning switching on/off: > That is SDO stuff; KNX , BACnet , etc... are preparing additional sta= ndards. > What are enrollment tools? > Peter > Michael Richardson schreef op 2014-11-23 22:16: >> I am very pleased with the document; I hope the WG is reading it, an= d is >> also happy with it. >> >> In secton 7.1 you mention use of PANA to secure new nodes. >> The reference seems very hesistant, and the DTLS relay is just kind = of >> thrown in. Can you make this recommendation more concrete? Or remo= ve it. >> >> If it's PANA, I assume EAP is involved, and so what what EAP methods= should >> be used? >> >> I think that, having read this document, I ought to be able to creat= e a >> light-bulb or light switch --- I think that I can make it function i= n the >> network, but I don't think it will use the same enrollment tools at = all, >> and >> I'd sure like to change that. I don't mind being really really spec= ific >> here: I encourage it. >> >> I also don't know what protocol to use for turning lights on/off, bu= t I >> acknowledge that is out of scope for the ROLL WG to specify. Perhap= s there >> is an informative reference I missed. >> >> I think that unless you have a specific way to use the DTLS relay, y= ou >> should >> remove the reference -- it doesn't help anyone trying to implement an >> interoperable device. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIXyQ4CLcPvd0N1lAQJd3gf+KdgD1ytlTGmfkEt+15wwG1iMoot4wUhz Ly3F+NlGFI8IkQjGyN48fotorer+iiMcNMcj4pbX6ZrUMDX3P2hgVVIFJycCutWZ wApNVloDVkUmV+QJzPOpsyP6SPoZw8pN65c4pLc76Bh8w7YIZtJdy3OTb8kFNfml ZMYOXktcqsg41IQ4RMAWNe1Bl1CDm3Y+M3sSpoMgtr+rxQ7qoYoKaHSS3tKh28VX sDeuRQ7JhEXh1tF4sHfu3mWQQzzhXM7HCUftpPdOWdvp4+peUWZYWI5pSnXexxXL ThjCMXcmeUaDXBKFAZgqhvBumzD34WbMSz9gNcIYAJxQhLh/mbG2dQ== =goat -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 8 23:55:38 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A861A6EDB for ; Mon, 8 Dec 2014 23:55:37 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 7HIUrRI4DvMl for ; Mon, 8 Dec 2014 23:55:34 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1E21A6EE6 for ; Mon, 8 Dec 2014 23:55:33 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id RKvX1p0074VN29601KvXlu; Tue, 09 Dec 2014 08:55:32 +0100 Received: from [2001:983:a264:1:d111:17bf:4c43:8d3a] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 09 Dec 2014 08:55:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Dec 2014 08:55:31 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8571.1418064454@sandelman.ca> References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> Message-ID: <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> X-Sender: stokcons@xs4all.nl (zl5Vwylfn5Fmnh6Jw45KDu6j9+fv5aeU) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/uiP6qPWKyKGMIviMfdER839ZIiw Cc: roll@ietf.org, mcr@sandelman.ca, Anders Brandt Subject: Re: [Roll] home-building-requirements section 7.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 07:55:37 -0000 Probably we are not going the EAP-PANA route because EAP PANA imposes an order of joining determined by the network topology. Today, that order will not, cannot, is unlikely to, be respected by the installation protocol. Consequently, I like to keep the uncertainty in the document. Michael Richardson schreef op 2014-12-08 19:47: > You ask: > What are enrollment tools? > > By this, I mean that the combination of protocols and/or provisioning > equipment that allows an installer to make a lightbulb join a > particular > network. > > That's why I want to know, if you are going the EAP-PANA route, that > one > needs to know what EAP methods ought to be supported. > > > peter van der Stok wrote: > > thanks for the encouragement. > > Concerning bootstrap and security in general. Many things are > going on and > > there are two approaches to this document: > > 1) a conservative one; restrict to what exists and is is proven > to work > > 2) leaving the doubt that exists today. > > > For the moment I like to leave the doubt, because in 5 years, > what is sure > > today will not be implemented is my conviction > > > Concerning switching on/off: > > That is SDO stuff; KNX , BACnet , etc... are preparing > additional standards. > > > What are enrollment tools? > > > Peter > > > > Michael Richardson schreef op 2014-11-23 22:16: > >> I am very pleased with the document; I hope the WG is reading > it, and is > >> also happy with it. > >> > >> In secton 7.1 you mention use of PANA to secure new nodes. > >> The reference seems very hesistant, and the DTLS relay is just > kind of > >> thrown in. Can you make this recommendation more concrete? Or > remove it. > >> > >> If it's PANA, I assume EAP is involved, and so what what EAP > methods should > >> be used? > >> > >> I think that, having read this document, I ought to be able to > create a > >> light-bulb or light switch --- I think that I can make it > function in the > >> network, but I don't think it will use the same enrollment tools > at all, > >> and > >> I'd sure like to change that. I don't mind being really really > specific > >> here: I encourage it. > >> > >> I also don't know what protocol to use for turning lights > on/off, but I > >> acknowledge that is out of scope for the ROLL WG to specify. > Perhaps there > >> is an informative reference I missed. > >> > >> I think that unless you have a specific way to use the DTLS > relay, you > >> should > >> remove the reference -- it doesn't help anyone trying to > implement an > >> interoperable device. From nobody Wed Dec 10 09:33:06 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A6A1A8789 for ; Wed, 10 Dec 2014 09:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 PgKPDL_PLWNA; Wed, 10 Dec 2014 09:33:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3711A8766; Wed, 10 Dec 2014 09:33:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210173301.24597.70042.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 09:33:01 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CPoCdu58W3JW2XqheJLoAoi3AKU Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 17:33:06 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Wed Dec 10 09:33:22 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DD11A877D for ; Wed, 10 Dec 2014 09:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 h62pMa77GAwb for ; Wed, 10 Dec 2014 09:33:18 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16E21A8791 for ; Wed, 10 Dec 2014 09:33:11 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAHX9KD029973; Wed, 10 Dec 2014 17:33:09 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAHX8bK029952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:33:08 GMT From: "Adrian Farrel" To: Date: Wed, 10 Dec 2014 17:33:02 -0000 Message-ID: <00d401d0149f$5a27d5a0$0e7780e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01D0149F.5A2DF020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAUns1ZeEFdemsRToicEMjWtYKqkg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21166.001 X-TM-AS-Result: No--9.973-10.0-31-10 X-imss-scan-details: No--9.973-10.0-31-10 X-TMASE-MatchedRID: J1szhq7AkrGnykMun0J1wnBRIrj8R47F2aYdnwn7qHccVJCT3tVgarsI asnPqvyQBanBF8QGgaZzE0lHhciiaLqUgEs+NGTpPmVMROjFDVWEDRWMikvPr0+0uGVOF08Qfak zcDIig/r/0JAKNeBLGBCg2PoqeXoJtVWReSlqXeouLk8NfSpYeqAPS3vFyaW6TDoylMQmcK9kwP NPtwx5z8XTAxA0oGwP0GLM4Oc8DhnwVBpSQYeaV05GBIYERk6jGGXRndNt79VZHPhWEMwl32kxA fYuAMQ88WLYesSso7RMh8d3WwUaAv29AWmTKYuEdAg4yd14qATTDXgcUlCNo2so23uKlCJjyukE y6JD/uYHY+yWZHCX2tgTRdG1XXJ3D0VXqQ1iI8dCnGIuUMP0VToSfZud5+GgGNAPebYwJ/vqSqR s8y+G0dmd6fJDFhEQLb6XLHjqIvRHW+94FA8JF0K9qlwiTElfrogFtKd/P7fSlkoRLCKfE56QVn lXMIygXrfYosn++oqhIBgkfoHq9iIdmtkBwO3DlwOGeK/WrXNT4DtiSkMnWBON+Q7elv5YPSawi BLK6fcf9nvUckM1oVpzKEH0vVqvEnerDpp3+WMAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH6 RuK0zz8NRz8HpCmSZEZKdSp4I705BGX7329oyQwfhKwa9GwDWq9ln3+CkiGlF7MF/8ayEtQaDtB Vy9LI//nkqRz73/pz3XExg2oeRXAUwvUpRIyqTVa+L3Zgqc7RaXpm7mwQnLkY3WUw/B8Xu8iyJC yNt6l2+AZuxakJy3inb860CrQoRezVZvE21UueAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vbyah9aCYUCHq8PW4IxJUDbAiNggLo/5lOLzop1boWPUaLUHuAwT92Ibu2aKJC+Rb4x/oyK7 JsdAwp4Mc0I73sYNePgBUtf89WzH1sHCOz44 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/1wgaEhOCPgAxsXGbDDorQgICO2w Cc: roll@ietf.org Subject: [Roll] AD review of draft-ietf-roll-admin-local-policy X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 17:33:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D5_01D0149F.5A2DF020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi authors, Thanks for this document. Sorry I sat on it for a little while. The document is very readable and doesn't waste words. There are a few small nits that need to be sorted out. I think we can handle these as part of the IETF last call, so I will start that process and then send these comments as last call comments. Thanks for the work, Adrian === "MPL" is not a well-known abbreviation so we need to expand it: - in the document title OLD MPL forwarder policy for multicast with admin-local scope NEW Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL) - in the Abstract OLD The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router. NEW The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low power and Lossy Networks (MPL) multicast messages with admin-local scope in a border router. - in the third paragraph of the Introduction OLD The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the MPL forwarding of multicast messages with admin-local scope within a border router. NEW The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the Multicast Protocol for Low power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast] forwarding of multicast messages with admin-local scope within a border router. --- I think it would be worth scoping the term "border router" in the Introduction. Something like... OLD multicast messages with admin-local scope within a border router. NEW multicast messages with admin-local scope within a border router that lies between a network running MPL and some other network. --- The last paragraph of the Introduction reads... It is expected that the network of an organization, building, or home, is connected to the Internet via the edge routers provided by an ISP. The intention is that within the network of an organization, building, or home, MPL messages with multicast addresses of admin- local scope are freely forwarded but are never forwarded to edge routers which MUST NOT enable their interfaces for MPL messages. This suggests that your vision is... ISP network --- Access --- Border --- MPL network Router Router That is fine. But wouldn't it be possible to have an access router that also served as a border router? --------------------- | Access Router | | | | -----------| MPL i/f |non-MPL | multicast +---------- MPL network ISP network --- +---------| forwarder | |traffic | | MPL i/f | | +---------- MPL network | -----------| --------------------- What you wrote may be a reflection of the boxes on the market today, and that is fine, but perhaps you are being too limiting of future developments. --- A few more abbreviations need to be expanded on first use. Section 2.1 "PAN" Section 2.2 "SSID" --- In section 2.4 you note that Bluetooth does not have the concept of associating more than one network with a channel. You say that the way to handle this is to set the network identifier of a BTLE link is "any". Add the head of section 2 you say When no network identifier exists for a given link, the network identifier has the value "undefined". Are these two statements consistent? --- Section 3 s/with an scope/with a scope/ --- Section 3 You have "MPL zone". Do you mean "MPL4 zone"? --- Please add a note to Section 10 saying that the change log can be removed before publication as an RFC. ------=_NextPart_000_00D5_01D0149F.5A2DF020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = authors,

 

Thanks for this document. Sorry I sat on it for a = little while.

 

The = document is very readable and doesn't waste words.

 

There = are a few small nits that need to be sorted out. I think we can =

handle these as part of the IETF = last call, so I will start that process

and then send these comments as last call = comments.

 

Thanks for the work,

Adrian

 

=3D=3D=3D

 

"MPL" is not a well-known abbreviation so = we need to expand it:

- in the = document title

  OLD

  =      MPL = forwarder policy for multicast with admin-local scope

  = NEW

    Forwarder policy = for multicast with admin-local scope in the

     Multicast = Protocol for Low power and Lossy Networks (MPL)

- in the Abstract

  = OLD

   The purpose of this = document is to specify an automated policy for

   = the routing of MPL multicast messages with admin-local scope in = a

   border = router.

  NEW

   = The purpose of this document is to specify an automated policy = for

   the routing of Multicast = Protocol for Low power and Lossy Networks

   (MPL) multicast = messages with admin-local scope in a border router.

- in the third paragraph of the = Introduction

  OLD

   = The admin-local scope must therefore be administratively = configured.

   This draft describes an = automated policy for the MPL forwarding of

   = multicast messages with admin-local scope within a border = router.

  NEW

   = The admin-local scope must therefore be administratively = configured.

   This draft describes an = automated policy for the Multicast Protocol

   for Low power and = Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast]

   = forwarding of multicast messages with admin-local scope within a =

   border = router.

 

---

 

I = think it would be worth scoping the term "border router" in = the

Introduction. Something = like...

 

OLD

   multicast messages with = admin-local scope within a border router.

NEW

   multicast messages with = admin-local scope within a border router

   = that lies between a network running MPL and some other = network.

 

---

 

The = last paragraph of the Introduction reads...

 

   It is expected that the = network of an organization, building, or

   = home, is connected to the Internet via the edge routers provided = by

   an ISP.  The intention is that within = the network of an organization,

   = building, or home, MPL messages with multicast addresses of = admin-

   local scope are freely = forwarded but are never forwarded to edge

   = routers which MUST NOT enable their interfaces for MPL = messages.

 

This suggests that your vision = is...

 

  ISP network --- Access --- = Border --- MPL network

       &nbs= p;          = Router     = Router

 

That = is fine. But wouldn't it be possible to have an access router that =

also served as a border router? =

 

       &nbs= p;           = ---------------------

       &nbs= p;          |       = Access Router |

       &nbs= p;          |       &nbs= p;            = ; |

       &nbs= p;          |       &nbs= p;  -----------| MPL i/f

       &nbs= p;          = |non-MPL  | = multicast +---------- MPL network

  ISP network --- +---------| = forwarder |

       &nbs= p;          = |traffic  |           | MPL i/f

       &nbs= p;          |       &nbs= p; |       &nbs= p;   +---------- MPL network

       &nbs= p;          |       &nbs= p;  -----------|

       &nbs= p;           = ---------------------

 

What = you wrote may be a reflection of the boxes on the market today, = and

that is fine, but perhaps you = are being too limiting of future

developments.

 

---

 

A few = more abbreviations need to be expanded on first use.

 

Section 2.1  = "PAN"

Section = 2.2  = "SSID"

 

---

 

In = section 2.4 you note that Bluetooth does not have the concept of =

associating more than one network = with a channel. You say that the way

to handle this is to set the network identifier of = a BTLE link is "any".

 

Add = the head of section 2 you say

  When no network identifier = exists for a given link, the network

  identifier has the value = "undefined".

 

Are = these two statements consistent?

 

---

 

Section 3

s/with an scope/with a scope/

 

---

 

Section 3

You = have "MPL zone". Do you mean "MPL4 = zone"?

 

---

 

Please = add a note to Section 10 saying that the change log can = be

removed before publication as = an RFC.

------=_NextPart_000_00D5_01D0149F.5A2DF020-- From nobody Wed Dec 10 10:24:31 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02101A8771; Wed, 10 Dec 2014 10:24:27 -0800 (PST) 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 secvhIG7Fl82; Wed, 10 Dec 2014 10:24:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D011A03AA; Wed, 10 Dec 2014 10:24:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141210182425.6387.29651.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 10:24:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Ftvpo0d88L4ZawuZ74kU98VBFvs Cc: roll@ietf.org Subject: [Roll] Last Call: (MPL forwarder policy for multicast with admin-local scope) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:24:28 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'MPL forwarder policy for multicast with admin-local scope' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 10 10:24:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C961A1A0C for ; Wed, 10 Dec 2014 10:24:47 -0800 (PST) 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 bwYjw3X5yxFy; Wed, 10 Dec 2014 10:24:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA71A8771; Wed, 10 Dec 2014 10:24:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210182428.6387.49536.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 10:24:28 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Tw0YsgPdUqXIfGYrJ-doHL69leI Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:24:47 -0000 Last call has been made for draft-ietf-roll-admin-local-policy and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Wed Dec 10 10:45:53 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEF11A1B80; Wed, 10 Dec 2014 10:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 trFBliDZUOIM; Wed, 10 Dec 2014 10:45:26 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9334E1A1B57; Wed, 10 Dec 2014 10:44:03 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAIi1pc024583; Wed, 10 Dec 2014 18:44:01 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAIhtFQ024548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 18:44:01 GMT From: "Adrian Farrel" To: References: <20141210182425.6387.29651.idtracker@ietfa.amsl.com> In-Reply-To: <20141210182425.6387.29651.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 18:43:50 -0000 Message-ID: <010101d014a9$40b50ca0$c21f25e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGDspU+bH+68Bq5vmYqQRhEa360FJ0h6lCg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21166.001 X-TM-AS-Result: No--13.799-10.0-31-10 X-imss-scan-details: No--13.799-10.0-31-10 X-TMASE-MatchedRID: gzVbiXtWD9szx9GDMr0HvzYTypjB3iDVuikHZcC6ceATVJPv0YKEKWn7 AlTb8W2x9Us4ZrjPeq9kG+By0KzAPUIFCJ5KkAbPVo6mn+xXmdXZph2fCfuodxxUkJPe1WBquwh qyc+q/JDlZ3R4RzLT0TgJ1V1R6K4hUapouPacYiqMcPlFNKd81tMGD8JuBXZPc4wJc2thNaIZ4o BrlanIO2CX9xIquPuxS9KN/ejlLD5cNOa3zFU5Xy97pb4g5HCtCI3p+Ju8mqqijw51EnZ2OCzyb VqWyY2NeC7pQ35xbkrI0IFszHQxmZV35HEp+SsiVUIE0/jxA/257wrN/2ZIygW3kEiN4kyf7fKx aM2xqkABDoeeLVMaqIlf3U2W48KAKgsbwct+M1+PmEs8Jfdl0/a/bRHEsPI3xaQNbiRXdZqLtYN ZwGGp+8CzDGl+ASOWO29ybNxer1TUzvcPSorAlMAmcZEx8XHJWjRJreaOWv5UjspoiX02F2qzO+ SzheZk4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjOwBXM346/+ykql3fPsqGp5HaT/Y1b5k3fYrZ1 x3xCqKyxDIsQDDebUDy1pMfzQL9 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/hr8kgvMDz5_2TaHT090AcPxzJOw Cc: roll@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org Subject: Re: [Roll] Last Call: (MPL forwarder policy for multicast with admin-local scope) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:45:27 -0000 All, My usual AD review of this document threw up a few small issues that don't need to delay the start of IETF last call. Could you please treat them as last call comments and address them with any other points that are raised. Thanks, Adrian === Hi authors, Thanks for this document. Sorry I sat on it for a little while. The document is very readable and doesn't waste words. There are a few small nits that need to be sorted out. I think we can handle these as part of the IETF last call, so I will start that process and then send these comments as last call comments. Thanks for the work, Adrian === "MPL" is not a well-known abbreviation so we need to expand it: - in the document title OLD MPL forwarder policy for multicast with admin-local scope NEW Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL) - in the Abstract OLD The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router. NEW The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low power and Lossy Networks (MPL) multicast messages with admin-local scope in a border router. - in the third paragraph of the Introduction OLD The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the MPL forwarding of multicast messages with admin-local scope within a border router. NEW The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the Multicast Protocol for Low power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast] forwarding of multicast messages with admin-local scope within a border router. --- I think it would be worth scoping the term "border router" in the Introduction. Something like... OLD multicast messages with admin-local scope within a border router. NEW multicast messages with admin-local scope within a border router that lies between a network running MPL and some other network. --- The last paragraph of the Introduction reads... It is expected that the network of an organization, building, or home, is connected to the Internet via the edge routers provided by an ISP. The intention is that within the network of an organization, building, or home, MPL messages with multicast addresses of admin- local scope are freely forwarded but are never forwarded to edge routers which MUST NOT enable their interfaces for MPL messages. This suggests that your vision is... ISP network --- Access --- Border --- MPL network Router Router That is fine. But wouldn't it be possible to have an access router that also served as a border router? --------------------- | Access Router | | | | -----------| MPL i/f |non-MPL | multicast +---------- MPL network ISP network --- +---------| forwarder | |traffic | | MPL i/f | | +---------- MPL network | -----------| --------------------- What you wrote may be a reflection of the boxes on the market today, and that is fine, but perhaps you are being too limiting of future developments. --- A few more abbreviations need to be expanded on first use. Section 2.1 "PAN" Section 2.2 "SSID" --- In section 2.4 you note that Bluetooth does not have the concept of associating more than one network with a channel. You say that the way to handle this is to set the network identifier of a BTLE link is "any". Add the head of section 2 you say When no network identifier exists for a given link, the network identifier has the value "undefined". Are these two statements consistent? --- Section 3 s/with an scope/with a scope/ --- Section 3 You have "MPL zone". Do you mean "MPL4 zone"? --- Please add a note to Section 10 saying that the change log can be removed before publication as an RFC. From nobody Wed Dec 10 15:24:15 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5EC1AC427 for ; Wed, 10 Dec 2014 15:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 HKPlcudesAxZ for ; Wed, 10 Dec 2014 15:24:05 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAE71A1B29 for ; Wed, 10 Dec 2014 15:24:04 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sBANO20T012643; Thu, 11 Dec 2014 08:24:02 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sBANO2pu028500; Thu, 11 Dec 2014 08:24:02 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA28499; Thu, 11 Dec 2014 08:24:02 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sBANO1je016882; Thu, 11 Dec 2014 08:24:01 +0900 (JST) Received: from TGXML208.toshiba.local by toshiba.co.jp id sBANO1Pv026986; Thu, 11 Dec 2014 08:24:01 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by TGXML208.toshiba.local ([133.199.70.17]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 08:24:01 +0900 From: To: , , Thread-Topic: [Roll] home-building-requirements section 7.1 Thread-Index: AQHQB2K8SS6vkJ4SZ0O9+e3jdZRW4Jxux9mAgBbBXQCAANwmgIADJ4gg Date: Wed, 10 Dec 2014 23:24:00 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0F485@TGXML210.toshiba.local> References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> In-Reply-To: <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.221] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CbrtPu0MA7s6JsP-Btv5RtrpaX8 Cc: mcr@sandelman.ca, abr@sdesigns.dk Subject: Re: [Roll] home-building-requirements section 7.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 23:24:12 -0000 It depends on the requirements on the target system. If the target system = is formed in a totally ad-hoc fashon, then the joining order is not determi= ned by network topology. =20 But in home and building networks where some a central management entity ty= pically exists, there will be a connectivity issue if the joining order is = not determined by network topology. In such a managed network, the applicat= ion in a node should be ready to work when the node successfully connected = to the network, which happens when the node successfully connected to its n= eighbor that is "already" connected to the network (that's why joining orde= r comes). Having said that I think it is OK to mention PANA in section 7.1. For EAP = methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for Wi-SUN HAN, = AFAIK. On the other hand, I do not mind having DTLS-relay and ongoing 6ti= sch security work. Regards, Yoshihiro Ohba -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Tuesday, December 9, 2014 4:56 PM To: Michael Richardson Cc: roll@ietf.org; mcr@sandelman.ca; Anders Brandt Subject: Re: [Roll] home-building-requirements section 7.1 Probably we are not going the EAP-PANA route because EAP PANA imposes an or= der of joining determined by the network topology. Today, that order will not, cannot, is unlikely to, be respected by the ins= tallation protocol. Consequently, I like to keep the uncertainty in the document. Michael Richardson schreef op 2014-12-08 19:47: > You ask: > What are enrollment tools? >=20 > By this, I mean that the combination of protocols and/or provisioning=20 > equipment that allows an installer to make a lightbulb join a=20 > particular network. >=20 > That's why I want to know, if you are going the EAP-PANA route, that=20 > one needs to know what EAP methods ought to be supported. >=20 >=20 > peter van der Stok wrote: > > thanks for the encouragement. > > Concerning bootstrap and security in general. Many things are=20 > going on and > > there are two approaches to this document: > > 1) a conservative one; restrict to what exists and is is proven=20 > to work > > 2) leaving the doubt that exists today. >=20 > > For the moment I like to leave the doubt, because in 5 years,=20 > what is sure > > today will not be implemented is my conviction >=20 > > Concerning switching on/off: > > That is SDO stuff; KNX , BACnet , etc... are preparing=20 > additional standards. >=20 > > What are enrollment tools? >=20 > > Peter >=20 >=20 > > Michael Richardson schreef op 2014-11-23 22:16: > >> I am very pleased with the document; I hope the WG is reading=20 > it, and is > >> also happy with it. > >> > >> In secton 7.1 you mention use of PANA to secure new nodes. > >> The reference seems very hesistant, and the DTLS relay is just=20 > kind of > >> thrown in. Can you make this recommendation more concrete? Or > remove it. > >> > >> If it's PANA, I assume EAP is involved, and so what what EAP=20 > methods should > >> be used? > >> > >> I think that, having read this document, I ought to be able to=20 > create a > >> light-bulb or light switch --- I think that I can make it=20 > function in the > >> network, but I don't think it will use the same enrollment=20 > tools at all, > >> and > >> I'd sure like to change that. I don't mind being really really=20 > specific > >> here: I encourage it. > >> > >> I also don't know what protocol to use for turning lights=20 > on/off, but I > >> acknowledge that is out of scope for the ROLL WG to specify. > Perhaps there > >> is an informative reference I missed. > >> > >> I think that unless you have a specific way to use the DTLS=20 > relay, you > >> should > >> remove the reference -- it doesn't help anyone trying to=20 > implement an > >> interoperable device. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Thu Dec 11 01:06:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7B1ACD24; Thu, 11 Dec 2014 01:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 pKwN3ChM_thH; Thu, 11 Dec 2014 01:06:00 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABF41ACD39; Thu, 11 Dec 2014 01:05:36 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud2.xs4all.net with ESMTP id S95Y1p00P4NtgTm0195YKt; Thu, 11 Dec 2014 10:05:34 +0100 Received: from [2001:983:a264:1:f876:6e0:dbd0:cb40] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 11 Dec 2014 10:05:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 11 Dec 2014 10:05:32 +0100 From: peter van der Stok To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <010101d014a9$40b50ca0$c21f25e0$@olddog.co.uk> References: <20141210182425.6387.29651.idtracker@ietfa.amsl.com> <010101d014a9$40b50ca0$c21f25e0$@olddog.co.uk> Message-ID: <998b4a1ea725e8ab778f39d63cbe8c7a@xs4all.nl> X-Sender: stokcons@xs4all.nl (b2q1NWzWj4sXfeVKSUxe9KbPTf+tjpAz) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zZtO4mMRJ7dmso1eLsHvlA-Wapo Cc: ietf@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org Subject: Re: [Roll] Last Call: (MPL forwarder policy for multicast with admin-local scope) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 09:06:03 -0000 Hi Adrian, Many thanks for your comments and in particular your suggestions. Using them will be my pleasure. Your edge router/border router drawing is absolutely right. I will rephrase to cover possible future cases as well. concerning "any" and "undefined": Although originally they were distinct in my head, I see that effectively there is no distinction. I will remove "undefined". I will wait for more LC comments and produce a new version, including text addressing all comments on this version 02. Greetings, Peter Adrian Farrel schreef op 2014-12-10 19:43: > All, > > My usual AD review of this document threw up a few small issues that > don't need > to delay the start of IETF last call. Could you please treat them as > last call > comments and address them with any other points that are raised. > > Thanks, > Adrian > > === > > Hi authors, > > Thanks for this document. Sorry I sat on it for a little while. > > The document is very readable and doesn't waste words. > > There are a few small nits that need to be sorted out. I think we can > handle these as part of the IETF last call, so I will start that > process > and then send these comments as last call comments. > > Thanks for the work, > Adrian > > === > > "MPL" is not a well-known abbreviation so we need to expand it: > - in the document title > OLD > MPL forwarder policy for multicast with admin-local scope > NEW > Forwarder policy for multicast with admin-local scope in the > Multicast Protocol for Low power and Lossy Networks (MPL) > - in the Abstract > OLD > The purpose of this document is to specify an automated policy for > the routing of MPL multicast messages with admin-local scope in a > border router. > NEW > The purpose of this document is to specify an automated policy for > the routing of Multicast Protocol for Low power and Lossy Networks > (MPL) multicast messages with admin-local scope in a border router. > - in the third paragraph of the Introduction > OLD > The admin-local scope must therefore be administratively configured. > This draft describes an automated policy for the MPL forwarding of > multicast messages with admin-local scope within a border router. > NEW > The admin-local scope must therefore be administratively configured. > This draft describes an automated policy for the Multicast Protocol > for Low power and Lossy Networks (MPL) > [[I-D.ietf-roll-trickle-mcast] > forwarding of multicast messages with admin-local scope within a > border router. > > --- > > I think it would be worth scoping the term "border router" in the > Introduction. Something like... > > OLD > multicast messages with admin-local scope within a border router. > NEW > multicast messages with admin-local scope within a border router > that lies between a network running MPL and some other network. > > --- > > The last paragraph of the Introduction reads... > > It is expected that the network of an organization, building, or > home, is connected to the Internet via the edge routers provided by > an ISP. The intention is that within the network of an > organization, > building, or home, MPL messages with multicast addresses of admin- > local scope are freely forwarded but are never forwarded to edge > routers which MUST NOT enable their interfaces for MPL messages. > > This suggests that your vision is... > > > ISP network --- Access --- Border --- MPL network > Router Router > > > That is fine. But wouldn't it be possible to have an access router that > also served as a border router? > > --------------------- > | Access Router | > | | > | -----------| MPL i/f > |non-MPL | multicast +---------- MPL network > ISP network --- +---------| forwarder | > |traffic | | MPL i/f > | | +---------- MPL network > | -----------| > --------------------- > > What you wrote may be a reflection of the boxes on the market today, > and > that is fine, but perhaps you are being too limiting of future > developments. > > --- > > A few more abbreviations need to be expanded on first use. > > Section 2.1 "PAN" > Section 2.2 "SSID" > > --- > > In section 2.4 you note that Bluetooth does not have the concept of > associating more than one network with a channel. You say that the way > to handle this is to set the network identifier of a BTLE link is > "any". > > Add the head of section 2 you say > When no network identifier exists for a given link, the network > identifier has the value "undefined". > > Are these two statements consistent? > > --- > > Section 3 > s/with an scope/with a scope/ > > --- > > Section 3 > You have "MPL zone". Do you mean "MPL4 zone"? > > --- > > Please add a note to Section 10 saying that the change log can be > removed before publication as an RFC. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Dec 15 14:59:56 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3219C1A6F62; Mon, 15 Dec 2014 14:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 qOnYgwop3MA2; Mon, 15 Dec 2014 14:59:50 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4FB1A1EED; Mon, 15 Dec 2014 14:59:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B429A1BC82AF; Mon, 15 Dec 2014 14:59:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-121.clppva.east.verizon.net [70.106.135.121]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8572F1BC82AE; Mon, 15 Dec 2014 14:59:49 -0800 (PST) Message-ID: <548F67D8.9080402@joelhalpern.com> Date: Mon, 15 Dec 2014 17:59:36 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gen-art@ietf.org, maria.ines.robles@ericsson.com, IETF discussion list References: <548A29DC.6080303@nostrum.com> In-Reply-To: <548A29DC.6080303@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/UxiFSiOeuha6cgM6GObu2Kb4rTk Cc: roll@ietf.org, "A. Jean Mahoney" Subject: [Roll] [Gen-art] review: draft-ietf-roll-admin-local-policy-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:59:52 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-admin-local-policy-02 MPL forwarder policy for multicast with admin-local scope Reviewer: Joel M. Halpern Review Date: 15-December-2014 IETF LC End Date: 24-December-2014 IESG Telechat date: N/A Summary: This document is not ready for publication as an Informational RFC. Major issues: There seems to be a disconnect between the notion of administratively configured and the behavior described in this draft for admin-local multicast scope. As far as I can tell, the forwarding behavior described here has no mechanism for administratively configuring the administrative boundary. The only knob that is used is PROACTIVE_FORWARDING, which is used for intra-realm multicast forwarding. Thus, if you have a roll multicast router with two interfaces in one realm and two interfaces in another realm, in order to provide realm multicast services for each realm, this router according to this draft will always forward admin-local multicast messages between the two realms. That does not seem to me to match the requirement for administrative configuration of the admin-local scope. Minor issues: I believe that MPL In the title should be expanded. It should also be expanded upon first use within the document. Nits/editorial comments: From nobody Mon Dec 15 15:19:23 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995F81A6FBA for ; Mon, 15 Dec 2014 15:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K3Fvg_eVztNh for ; Mon, 15 Dec 2014 15:19:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 052981A6F93 for ; Mon, 15 Dec 2014 15:19:19 -0800 (PST) Received: from localhost ([::1]:53187 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y0eux-0000Ke-Pv; Mon, 15 Dec 2014 15:19:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-admin-local-policy@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 15 Dec 2014 23:19:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/167 Message-ID: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> X-Trac-Ticket-ID: 167 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-admin-local-policy@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: consultancy@vanderstok.org, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/19CDrTgfdYvTtL0E8lz4x24ng2s Cc: roll@ietf.org Subject: [Roll] [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:19:21 -0000 #167: Not match the requirement for administrative configuration of the admin- local scope From: Joel M. Halpern Date: 2014-12-16 0:59 GMT+02:00 Major issues: There seems to be a disconnect between the notion of administratively configured and the behavior described in this draft for admin-local multicast scope. As far as I can tell, the forwarding behavior described here has no mechanism for administratively configuring the administrative boundary. The only knob that is used is PROACTIVE_FORWARDING, which is used for intra-realm multicast forwarding. Thus, if you have a roll multicast router with two interfaces in one realm and two interfaces in another realm, in order to provide realm multicast services for each realm, this router according to this draft will always forward admin-local multicast messages between the two realms. That does not seem to me to match the requirement for administrative configuration of the admin-local scope -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll-admin- mariainesrobles@gmail.com | local-policy@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: admin-local-policy | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Dec 15 15:23:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4571A701C for ; Mon, 15 Dec 2014 15:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wEtWDVWR-Bbr for ; Mon, 15 Dec 2014 15:23:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 519271A6FBE for ; Mon, 15 Dec 2014 15:23:45 -0800 (PST) Received: from localhost ([::1]:53772 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y0ezL-0000fk-EN; Mon, 15 Dec 2014 15:23:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-admin-local-policy@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 15 Dec 2014 23:23:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/168 Message-ID: <067.bc060c97f072e7fceebc88a26ab4814e@trac.tools.ietf.org> X-Trac-Ticket-ID: 168 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-admin-local-policy@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: consultancy@vanderstok.org, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/mqigbNQ9QBda2FLrGFpw-YDfeX4 Cc: roll@ietf.org Subject: [Roll] [roll] #168 (admin-local-policy): Editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:23:49 -0000 #168: Editorial comments From: Joel M. Halpern Date: 2014-12-16 0:59 GMT+02:00 I believe that MPL In the title should be expanded. It should also be expanded upon first use within the document. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll-admin- mariainesrobles@gmail.com | local-policy@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: admin-local-policy | Version: Severity: In WG Last Call | Keywords: Request to expand MPL -------------------------------------+------------------------------------- Ticket URL: roll From nobody Tue Dec 16 02:41:27 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE5E1A1A8C for ; Tue, 16 Dec 2014 02:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 Z-rJ0JQNn6rE for ; Tue, 16 Dec 2014 02:41:24 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E3F1A1A86 for ; Tue, 16 Dec 2014 02:41:23 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id UAhL1p00N4Hiz6i01AhLyy; Tue, 16 Dec 2014 11:41:21 +0100 Received: from [2001:983:a264:1:5d19:b93e:1469:6b2f] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 16 Dec 2014 11:41:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Dec 2014 11:41:20 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <067.bc060c97f072e7fceebc88a26ab4814e@trac.tools.ietf.org> References: <067.bc060c97f072e7fceebc88a26ab4814e@trac.tools.ietf.org> Message-ID: <96416c949028d1cb4e188a1779e1f0fc@xs4all.nl> X-Sender: stokcons@xs4all.nl (5uHN1WP+liC0Nnrbwxl0Cq3tr/Tkdg4M) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/KI1Ev-1GKtYXIsnRivqroInxpUM Cc: draft-ietf-roll-admin-local-policy@tools.ietf.org Subject: Re: [Roll] [roll] #168 (admin-local-policy): Editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 10:41:25 -0000 Hi Joel, I think the editorial issue is addressed by taking over the suggestions by Adrian Farrel. _____ "MPL" is not a well-known abbreviation so we need to expand it: - in the document title OLD MPL forwarder policy for multicast with admin-local scope NEW Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL) - in the Abstract OLD The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router. NEW The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low power and Lossy Networks (MPL) multicast messages with admin-local scope in a border router. - in the third paragraph of the Introduction OLD The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the MPL forwarding of multicast messages with admin-local scope within a border router. NEW The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the Multicast Protocol for Low power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast] forwarding of multicast messages with admin-local scope within a border router. ---- Greetings Peter roll issue tracker schreef op 2014-12-16 00:23: > #168: Editorial comments > > From: Joel M. Halpern > Date: 2014-12-16 0:59 GMT+02:00 > > I believe that MPL In the title should be expanded. It should > also be > expanded upon first use within the document. From nobody Tue Dec 16 08:08:25 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1701A1B75 for ; Tue, 16 Dec 2014 08:08:23 -0800 (PST) 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 qHSmOlXujiKE for ; Tue, 16 Dec 2014 08:08:21 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF3E1A1B30 for ; Tue, 16 Dec 2014 08:08:20 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so7619345iga.3 for ; Tue, 16 Dec 2014 08:08:20 -0800 (PST) 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=cSXu+3CLmAVdd0yiNBsibq/kximv6Zm2V77KZ6+ooq8=; b=PMz7hSWK+K9uOyd5yp4lLH/eP5RwpgEqDzV4LTK8D9K85uWhZfYND9fTyuxdHmoWNt ivi5T5rORp58OaCvkU/v8+ZDjMH4CC7ejCikmt3BANgdLYa1xqs2tI5I0ZJl/gON6a3L LBi6oZpvHwV+U0hNQDDV1a/VR6h2ezMDRhcJNGuWnTuLb6F1tJoBYq3vUmK8eHVFEsI4 U7y4eJIxPuzNwbL5ZR4WmZ23H6uZYLlpF1Pnrqgcd4FlkeUb93/s/Xz33YLAywIHFp3G xclu3GBk8PNczeZLVvrnxHfosruzLE2SO+iaHCtmp6yclrILLA68eAw8qWmjISjXIGrb d2rw== X-Received: by 10.50.134.65 with SMTP id pi1mr3318781igb.32.1418746100011; Tue, 16 Dec 2014 08:08:20 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id q196sm460837ioe.5.2014.12.16.08.08.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 08:08:19 -0800 (PST) Message-ID: <549058E9.7040507@gmail.com> Date: Tue, 16 Dec 2014 11:08:09 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> In-Reply-To: <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/7fSZOGwsBCKSserIyD7ulkrB72g Cc: mcr@sandelman.ca, Anders Brandt Subject: [Roll] home-building-requirements section 7.2 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:08:23 -0000 Hi Peter: When contemplating some joining protocol details, I was wondering about incremental deployment (as mentioned in clause 7.2 of your draft). This was also one of the scenarios that came up with hallway discussions with Sandeep Kumar during IETF-91. From your email below, it seems that you would like to have the join protocol have the following features: a) the order of joining should be orthogonal to routing protocol topology considerations, if it all possible. b) in particular, not all installations follow the pattern where one has an operational network and where all non-local communications during the join protocol not of the type {joining node - neighbor router} are within the operational network (case in point: tree-like structure, where network is built from tree root up onwards). The joining process consists of various stages, including authentication, authorization, and configuration, where configuration and possibly authentication and authorization may require a communication path between joining node and a network management node that may be multiple hops away, where the latter typically takes place via the neighbor router. If the joining process is aimed to provide security services, the main requirement on the communication path between neighbor node and network management node(s) is "that it is there" (i.e., there is connectivity) although there may be additional requirement to counter, e.g., denial of service attacks on communications related to the joining process emanating from the neighbor node. Do you think that designing the join process so as to minimize dependencies between joining process and routing protocol would be beneficial for your use case of facilitating "random" installation process flows? (An alternative would be to intertwine routing and joining processes, but it seems to conflict item #b above.) Obviously, once a node is part of the network, it should be able to route packets (but that is not part of the join protocol itself, but next-stage phase). Any insights on incremental deployment scenarios appreciated. Best regards, Rene On 12/9/2014 2:55 AM, peter van der Stok wrote: > Probably we are not going the EAP-PANA route because EAP PANA imposes > an order of joining determined by the network topology. > Today, that order will not, cannot, is unlikely to, be respected by > the installation protocol. > > Consequently, I like to keep the uncertainty in the document. > > > > Michael Richardson schreef op 2014-12-08 19:47: >> You ask: > What are enrollment tools? >> >> By this, I mean that the combination of protocols and/or provisioning >> equipment that allows an installer to make a lightbulb join a particular >> network. >> >> That's why I want to know, if you are going the EAP-PANA route, that one >> needs to know what EAP methods ought to be supported. >> >> >> peter van der Stok wrote: >> > thanks for the encouragement. >> > Concerning bootstrap and security in general. Many things are >> going on and >> > there are two approaches to this document: >> > 1) a conservative one; restrict to what exists and is is proven >> to work >> > 2) leaving the doubt that exists today. >> >> > For the moment I like to leave the doubt, because in 5 years, >> what is sure >> > today will not be implemented is my conviction >> >> > Concerning switching on/off: >> > That is SDO stuff; KNX , BACnet , etc... are preparing >> additional standards. >> >> > What are enrollment tools? >> >> > Peter >> >> >> > Michael Richardson schreef op 2014-11-23 22:16: >> >> I am very pleased with the document; I hope the WG is reading >> it, and is >> >> also happy with it. >> >> >> >> In secton 7.1 you mention use of PANA to secure new nodes. >> >> The reference seems very hesistant, and the DTLS relay is just >> kind of >> >> thrown in. Can you make this recommendation more concrete? Or >> remove it. >> >> >> >> If it's PANA, I assume EAP is involved, and so what what EAP >> methods should >> >> be used? >> >> >> >> I think that, having read this document, I ought to be able to >> create a >> >> light-bulb or light switch --- I think that I can make it >> function in the >> >> network, but I don't think it will use the same enrollment >> tools at all, >> >> and >> >> I'd sure like to change that. I don't mind being really >> really specific >> >> here: I encourage it. >> >> >> >> I also don't know what protocol to use for turning lights >> on/off, but I >> >> acknowledge that is out of scope for the ROLL WG to specify. >> Perhaps there >> >> is an informative reference I missed. >> >> >> >> I think that unless you have a specific way to use the DTLS >> relay, you >> >> should >> >> remove the reference -- it doesn't help anyone trying to >> implement an >> >> interoperable device. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Dec 16 23:40:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB511A066B for ; Tue, 16 Dec 2014 23:40:06 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ze3BLecMGmIy for ; Tue, 16 Dec 2014 23:40:03 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CCF1A1A94 for ; Tue, 16 Dec 2014 23:40:02 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id UXfz1p0094VN29601XfzFM; Wed, 17 Dec 2014 08:39:59 +0100 Received: from [2001:983:a264:1:84e4:c65a:f9ca:92c0] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 17 Dec 2014 08:39:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 17 Dec 2014 08:39:59 +0100 From: peter van der Stok To: Rene Struik Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <549058E9.7040507@gmail.com> References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> <549058E9.7040507@gmail.com> Message-ID: <885b361c8b320419b6f81390af619654@xs4all.nl> X-Sender: stokcons@xs4all.nl (2Ug8UZDWpbEH4Nv4oFiEsF9OpsMMQGy1) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2ZjX-Op7Bf_c51uY1134crBh60A Cc: Routing Over Low power and Lossy networks , mcr@sandelman.ca, Anders Brandt Subject: Re: [Roll] home-building-requirements section 7.2 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 07:40:06 -0000 Hi Rene, I think you got most requirements right. Sandeep and I will prepare an I-D for 6lo in which we will motivate the order of joining in more detail. We think that the joining operation as explained in draft-richardson-6tisch--security-6top-04 covers already many aspects. Concerning routing: I expect that separating routing protocol operation from the joining process is beneficial. e.g. Routing is started up before network is secured, or use an inefficient nd-related routing during joining, etc. Hope this helps, Greetings, Peter Rene Struik schreef op 2014-12-16 17:08: > Hi Peter: > > When contemplating some joining protocol details, I was wondering > about incremental deployment (as mentioned in clause 7.2 of your > draft). This was also one of the scenarios that came up with hallway > discussions with Sandeep Kumar during IETF-91. > > From your email below, it seems that you would like to have the join > protocol have the following features: > a) the order of joining should be orthogonal to routing protocol > topology considerations, if it all possible. > b) in particular, not all installations follow the pattern where one > has an operational network and where all non-local communications > during the join protocol not of the type {joining node - neighbor > router} are within the operational network (case in point: tree-like > structure, where network is built from tree root up onwards). > > The joining process consists of various stages, including > authentication, authorization, and configuration, where configuration > and possibly authentication and authorization may require a > communication path between joining node and a network management node > that may be multiple hops away, where the latter typically takes place > via the neighbor router. > > If the joining process is aimed to provide security services, the main > requirement on the communication path between neighbor node and > network management node(s) is "that it is there" (i.e., there is > connectivity) although there may be additional requirement to counter, > e.g., denial of service attacks on communications related to the > joining process emanating from the neighbor node. > > Do you think that designing the join process so as to minimize > dependencies between joining process and routing protocol would be > beneficial for your use case of facilitating "random" installation > process flows? (An alternative would be to intertwine routing and > joining processes, but it seems to conflict item #b above.) > > Obviously, once a node is part of the network, it should be able to > route packets (but that is not part of the join protocol itself, but > next-stage phase). > > Any insights on incremental deployment scenarios appreciated. > > Best regards, Rene > > On 12/9/2014 2:55 AM, peter van der Stok wrote: >> Probably we are not going the EAP-PANA route because EAP PANA imposes >> an order of joining determined by the network topology. >> Today, that order will not, cannot, is unlikely to, be respected by >> the installation protocol. >> >> Consequently, I like to keep the uncertainty in the document. >> >> >> >> Michael Richardson schreef op 2014-12-08 19:47: >>> You ask: > What are enrollment tools? >>> >>> By this, I mean that the combination of protocols and/or provisioning >>> equipment that allows an installer to make a lightbulb join a >>> particular >>> network. >>> >>> That's why I want to know, if you are going the EAP-PANA route, that >>> one >>> needs to know what EAP methods ought to be supported. >>> >>> >>> peter van der Stok wrote: >>> > thanks for the encouragement. >>> > Concerning bootstrap and security in general. Many things are >>> going on and >>> > there are two approaches to this document: >>> > 1) a conservative one; restrict to what exists and is is proven >>> to work >>> > 2) leaving the doubt that exists today. >>> >>> > For the moment I like to leave the doubt, because in 5 years, >>> what is sure >>> > today will not be implemented is my conviction >>> >>> > Concerning switching on/off: >>> > That is SDO stuff; KNX , BACnet , etc... are preparing >>> additional standards. >>> >>> > What are enrollment tools? >>> >>> > Peter >>> >>> >>> > Michael Richardson schreef op 2014-11-23 22:16: >>> >> I am very pleased with the document; I hope the WG is reading >>> it, and is >>> >> also happy with it. >>> >> >>> >> In secton 7.1 you mention use of PANA to secure new nodes. >>> >> The reference seems very hesistant, and the DTLS relay is just >>> kind of >>> >> thrown in. Can you make this recommendation more concrete? >>> Or >>> remove it. >>> >> >>> >> If it's PANA, I assume EAP is involved, and so what what EAP >>> methods should >>> >> be used? >>> >> >>> >> I think that, having read this document, I ought to be able to >>> create a >>> >> light-bulb or light switch --- I think that I can make it >>> function in the >>> >> network, but I don't think it will use the same enrollment >>> tools at all, >>> >> and >>> >> I'd sure like to change that. I don't mind being really >>> really specific >>> >> here: I encourage it. >>> >> >>> >> I also don't know what protocol to use for turning lights >>> on/off, but I >>> >> acknowledge that is out of scope for the ROLL WG to specify. >>> Perhaps there >>> >> is an informative reference I missed. >>> >> >>> >> I think that unless you have a specific way to use the DTLS >>> relay, you >>> >> should >>> >> remove the reference -- it doesn't help anyone trying to >>> implement an >>> >> interoperable device. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From nobody Wed Dec 17 00:30:02 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BC1A1B57; Wed, 17 Dec 2014 00:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 GcCSV7HxoJJY; Wed, 17 Dec 2014 00:29:58 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3491A016F; Wed, 17 Dec 2014 00:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8115; q=dns/txt; s=iport; t=1418804998; x=1420014598; h=from:to:cc:subject:date:message-id:mime-version; bh=B576+RyKd6xviScfywULFDBIWA7Q7BJWVUncXdODths=; b=k12+/2jWz0jRFvBnRpaemSV3b2Q0+NxRDqe4ZT0tqalMm0DOsmY0x4+i we55A0VeG1pBOQpio1NHvB1AYUTyYGHBs6uSLMRY1NbBPAMOG3/7hE42l 14cyhuZNZbfIKjyRAmg86Aktkwc4YGCfIgqoiHRqecYBo/kk1mCubh9N6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukFAKs9kVStJV2c/2dsb2JhbABagkNDUlzDU4IlhGSBDgKBGhYBAQEBAX2EDgEEHRBMEgEqViYBBAENDYgkDdQWAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPQS0Egx2BEwWOB4M+gX6EP4ohhg0ig2yBcyQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208,217";a="111243869" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by mtv-iport-3.cisco.com with ESMTP; 17 Dec 2014 08:29:57 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBH8TuGi024174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 08:29:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 02:29:56 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org>, "int-ads@tools.ietf.org" Thread-Topic: call for consensus for the RPL RPI / RH3 compression Thread-Index: AdAZ03ma+k+kJWwbTKWgpTyyptAZgQ== Date: Wed, 17 Dec 2014 08:29:53 +0000 Deferred-Delivery: Wed, 17 Dec 2014 08:29:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.197.231] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848AC2314xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-GJ1VlfKkrILtHerEuzOhixXgnc Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, Routing Over Low power and Lossy networks Subject: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 08:30:01 -0000 --_000_E045AECD98228444A58C61C200AE1BD848AC2314xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG : We are now in last call for draft-ietf-6tisch-minimal-04 which describes an= interoperable operation of RPL over 802.15.4e TSCH. In order to guarantee interop, the draft must indicate which compression te= chnique to use for the RPL option, and, if any, the RH3 as well. The question was apparently solved at the ROLL meeting in Toronto, and we w= ere going to use the IPv6 flow label to carry the RPI, with no compression = for the RH3. Adrian noted that since this is a deviation to RFC 6437, we should go to 6M= AN to validate. We went to 6MAN in April (https://tools.ietf.org/html/draft= -thubert-6man-flow-label-for-rpl) and got support from Brian Carpenter. The= ask in 4 points was discussed again in Hawaii. But still no final decision= to date that we could reset/reuse the flow label in LLNs. Considering the lack of progress at 6MAN earlier in the year, we studied an= alternate compression technique for the RPI at 6lo (https://tools.ietf.org= /html/draft-thubert-6lo-rpl-nhc). Decision in Hawaii was that the NHC draft= could not be accepted as is, since we should compress also the RH3, and wi= thout a clear view of how that would happen, the details of the NHC compres= sion could not be determined. So the NHC approach was abandoned and we prop= osed a new 6lowpan routing header that would reuse for Route-over the 1/3 o= f the total dispatch space that is used for Mesh header in Mesh-under (http= s://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch). There were int= eresting discussions and an update but there we are, no WG document anywher= e that we can reference, and no consensus that 6lo will adopt that work. Yet we need to choose one compression for the minimal version that we will = submit to IESG. At some point we hoped that the NHC would cut it but as I s= aid, the meeting in Hawaii left us with little hope that this would happen.= So what should we do now? I think we need to call to 6lo and 6MAN for a de= cision on the topics we have been asking. And since a decision may not come= in time, we also need to define our default. My personal take is lex parsimoniae. By default, we should fall back to the= simplest to implement, which is also the least change in existing implemen= tations, and that is the original flow label approach; and I'm calling the = group for consensus on that default approach. What do you think? Pascal --_000_E045AECD98228444A58C61C200AE1BD848AC2314xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG :

 

We are now in last call for draft-ietf-6tisch-minima= l-04 which describes an interoperable operation of RPL over 802.15.4e TSCH.=

In order to guarantee interop, the draft must indica= te which compression technique to use for the RPL option, and, if any, the = RH3 as well.

 

The question was apparently solved at the ROLL meeti= ng in Toronto, and we were going to use the IPv6 flow label to carry the RP= I, with no compression for the RH3.

Adrian noted that since this is a deviation to RFC 6= 437, we should go to 6MAN to validate. We went to 6MAN in April (https://to= ols.ietf.org/html/draft-thubert-6man-flow-label-for-rpl) and got support fr= om Brian Carpenter. The ask in 4 points was discussed again in Hawaii. But still no final decision to date that we= could reset/reuse the flow label in LLNs.

 

Considering the lack of progress at 6MAN earlier in = the year, we studied an alternate compression technique for the RPI at 6lo = (https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc). Decision in Hawaii= was that the NHC draft could not be accepted as is, since we should compress also the RH3, and without a cl= ear view of how that would happen, the details of the NHC compression could= not be determined. So the NHC approach was abandoned and we proposed a new= 6lowpan routing header that would reuse for Route-over the 1/3 of the total dispatch space that is used for = Mesh header in Mesh-under (https://tools.ietf.org/html/draft-thubert-6lo-ro= uting-dispatch). There were interesting discussions and an update but there we are, no WG document anywhere that w= e can reference, and no consensus that 6lo will adopt that work.=

 

Yet we need to choose one compression for the minima= l version that we will submit to IESG. At some point we hoped that the NHC = would cut it but as I said, the meeting in Hawaii left us with little hope = that this would happen. So what should we do now? I think we need to call to 6lo and 6MAN for a decision on the t= opics we have been asking. And since a decision may not come in time, we al= so need to define our default.

 

My personal take is lex parsimoniae. By default, we = should fall back to the simplest to implement, which is also the least chan= ge in existing implementations, and that is the original flow label approac= h; and I’m calling the group for consensus on that default approach.

 

What do you think?

 

Pascal

--_000_E045AECD98228444A58C61C200AE1BD848AC2314xmbrcdx01ciscoc_-- From nobody Wed Dec 17 15:09:36 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE11A004C for ; Wed, 17 Dec 2014 15:09:33 -0800 (PST) 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 WjdzgssqDng6; Wed, 17 Dec 2014 15:09:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B611A0041; Wed, 17 Dec 2014 15:09:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217230930.25895.36542.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 15:09:30 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rJ0sY1fF6m7zHOsB0bh5nSMKVLU Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:09:33 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Thu Dec 18 08:40:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C592C1A1B78; Thu, 18 Dec 2014 08:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=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 IXaNUGA25z1L; Thu, 18 Dec 2014 08:40:10 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E041A1B2C; Thu, 18 Dec 2014 08:39:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7696B20012; Thu, 18 Dec 2014 11:43:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8501C63745; Thu, 18 Dec 2014 11:39:17 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 64A1A63741; Thu, 18 Dec 2014 11:39:17 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5LV9B67O7Zdn05ZHw7CWRKMQog0 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:40:12 -0000 --=-=-= Pascal Thubert (pthubert) wrote: > We are now in last call for draft-ietf-6tisch-minimal-04 which > describes an interoperable operation of RPL over 802.15.4e TSCH. ... > My personal take is lex parsimoniae. By default, we should fall back to > the simplest to implement, which is also the least change in existing > implementations, and that is the original flow label approach; and I'm > calling the group for consensus on that default approach. > What do you think? Not wearing any hat: I'm personally happy with the flow label approach. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVJMDMoCLcPvd0N1lAQICYgf7B99Hb5ubYc5BDacOiHMPzDIQc8yJOeL8 X9/wdje2mEHFdgq+GakNKcvCW+84YcXE1yLzyOCFbb66c4olwubOueCnx5P47oQl DnSiHOZ++PPTV61YL2I31/mQVmNpvttbvsFPIxShUnDYklVUws4CIisGsTW56zwm YpZfrLnZnftvysnNZUpclLWLHxOQvWrWrH6dEAl6nNe7CUZGwk1jwh/qFmZMWhZN oUCIwPoZW4WrOCOEzD+yWbphZYFy/IvWp4zdgpa/3U/3kkzb5xuWH0+xVbQuTJ4t yq7OnAVu5xpZEkPDYjDkzY5+VwqDwEq2yUcEXXG2wpvMXQXwZhR2ZQ== =m6Un -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 18 12:28:57 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3461A1B7A; Thu, 18 Dec 2014 12:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 YWgeJmXyhvWd; Thu, 18 Dec 2014 12:28:51 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B721AC3F9; Thu, 18 Dec 2014 12:28:41 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so2660363wgg.7; Thu, 18 Dec 2014 12:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hIRdE8WI4FJwTfMEpT5TZGahsmDDneGgC0rNJ2pDyaA=; b=Srs9ysLOIApyQXD/sXF74uwNSQyzegwf/GxKPdyseecrAjdtUkCIPdg3oASRjHrZP4 0Xd9nlvZpC2sPwKWkAg+oLuxgO/U8IDEzVBkjA8wc7I3L3C30damVCxIMYZ5d6FYGNu8 5fv8oNbTuZVMgSKVlnEnLZpHxd9eGDbjZRRdJiAGkm8hN0bn8d/NTtYhtmNsRdveaG9+ iZnJH20NISI9ObFMcdX5NbshF2vXVM9aaoJWMtimJMvsc5vOV4+/OSygCiNqvYc1RiR7 Qi3l6yonIQw4c9mcdTHHEH/GzOeKlYBGVx/3Lj8dlFhVMXWq/i/8SSQf2AwN6OEKHNEI R4Vg== MIME-Version: 1.0 X-Received: by 10.194.81.1 with SMTP id v1mr7050418wjx.50.1418934520326; Thu, 18 Dec 2014 12:28:40 -0800 (PST) Sender: xvilajosana@gmail.com Received: by 10.27.210.201 with HTTP; Thu, 18 Dec 2014 12:28:40 -0800 (PST) In-Reply-To: <10328.1418920757@sandelman.ca> References: <10328.1418920757@sandelman.ca> Date: Thu, 18 Dec 2014 21:28:40 +0100 X-Google-Sender-Auth: skuxZQptV3U3LMYTQ7SBzIJYQ6I Message-ID: From: Xavier Vilajosana To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7bb048760b315d050a83700f Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HcvcYCyRdOhy28WbEe2R3h5aQjo Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , Routing Over Low power and Lossy networks , "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:28:53 -0000 --047d7bb048760b315d050a83700f Content-Type: text/plain; charset=UTF-8 Hi, my 5 cents. I like flow label, but we (at 6tisch) discussed for a very long time the approach to be taken (NHC and lately the new draft that also compresses RH3). I will support it (flow label) but IMHO we have to make sure there is no other thing we can do to make the current proposal at 6lo to move forward or at least get strong arguments against it. In terms of coherence, NHC it seems a more natural way to go as we are extending the use of the dispatch and headers are all parsed following a coherent rule. regards, Xavi 2014-12-18 17:39 GMT+01:00 Michael Richardson : > > > Pascal Thubert (pthubert) wrote: > > We are now in last call for draft-ietf-6tisch-minimal-04 which > > describes an interoperable operation of RPL over 802.15.4e TSCH. > > ... > > > My personal take is lex parsimoniae. By default, we should fall back > to > > the simplest to implement, which is also the least change in existing > > implementations, and that is the original flow label approach; and > I'm > > calling the group for consensus on that default approach. > > > What do you think? > > Not wearing any hat: I'm personally happy with the flow label approach. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --047d7bb048760b315d050a83700f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

my 5 cents. I like flow label, but = we (at 6tisch) discussed for a very long time the approach to be taken (NHC= and lately the new draft that also compresses RH3). I will support it (flo= w label) but IMHO we have to make sure there is no other thing we can do to= make the current proposal at 6lo to move forward or at least get strong ar= guments against it. In terms of coherence, NHC it seems a more natural way = to go as we are extending the use of the dispatch and headers are all parse= d following a coherent rule.

regards,
Xavi
<= div>


2014-12-18 17:39 GMT+01:00 Michael Richardson <mcr+ietf@sandelman.ca>:

Pascal Thubert (pthubert) <pthuber= t@cisco.com> wrote:
=C2=A0 =C2=A0 > We are now in last call for draft-ietf-6tisch-minimal-04= which
=C2=A0 =C2=A0 > describes an interoperable operation of RPL over 802.15.= 4e TSCH.

...

=C2=A0 =C2=A0 > My personal take is lex parsimoniae. By default, we shou= ld fall back to
=C2=A0 =C2=A0 > the simplest to implement, which is also the least chang= e in existing
=C2=A0 =C2=A0 > implementations, and that is the original flow label app= roach; and I'm
=C2=A0 =C2=A0 > calling the group for consensus on that default approach= .

=C2=A0 =C2=A0 > What do you think?

Not wearing any hat: I'm personally happy with the flow label ap= proach.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
6tisch mailing list
6tisch@ietf.org
= https://www.ietf.org/mailman/listinfo/6tisch

--047d7bb048760b315d050a83700f-- From nobody Fri Dec 19 00:17:38 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550C51A1F70; Fri, 19 Dec 2014 00:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] 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 S-XKuoXnST4l; Fri, 19 Dec 2014 00:17:36 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CC01A6F20; Fri, 19 Dec 2014 00:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sBJ8HW8j016764; Fri, 19 Dec 2014 09:17:32 +0100 (CET) Received: from [IPv6:2002:5489:adc::6808:fbcd:141:fd50] (unknown [IPv6:2002:5489:adc:0:6808:fbcd:141:fd50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3k3jcC33Dkz7wgK; Fri, 19 Dec 2014 09:17:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: Date: Fri, 19 Dec 2014 09:17:29 +0100 X-Mao-Original-Outgoing-Id: 440669849.57781-3faa6d6f23ae1f2b2a2a1a43a0411230 Content-Transfer-Encoding: quoted-printable Message-Id: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> References: To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/4s858NUnhmEa-2J6iZV4ffCL8t8 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 08:17:37 -0000 On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) = wrote: >=20 > Decision in Hawaii was that the NHC draft could not be accepted as is, = since we should compress also the RH3, and without a clear view of how = that would happen, the details of the NHC compression could not be = determined. So the NHC approach was abandoned That is not at all what I recollect from Hawaii. The current smorgasbord is: =E2=80=94 various ways to hijack the flow label (dead) =E2=80=94 the 6553-NHC proposal =E2=80=94 ideas for a new mesh header I=E2=80=99m not going to beat the dead horse of the flow label hijack. The 6553-NHC proposal mainly needs a decision between the three variants = (flip a coin, if need be). If time is of the essence, 6553-NHC is the natural thing to do. We can always do an RFC 6554 NHC compression separately. The MH proposal is forward-looking and probably the right thing for the = evolution of 6lo, but probably also not compatible with a tight time = schedule. Now, what is the rush? RFC 6553/6554 do exist. So we get to choose between rushing 6553-NHC to completion or using = 6553/6554 for now and doing the MH work right (or. more likely than just = the first, both). I don=E2=80=99t have an opinion on wether we need to rush 6553-NHC, but = if we need to rush anything, this one it is. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 19 03:59:52 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB9B1A8F50; Fri, 19 Dec 2014 03:59:50 -0800 (PST) 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 rtoCfpMf0l-Y; Fri, 19 Dec 2014 03:59:48 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACAE1A9129; Fri, 19 Dec 2014 03:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3142; q=dns/txt; s=iport; t=1418990387; x=1420199987; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NK9THQDqOoFdHeoJwBHdH3CkPAr4EUxKbYF3RgTNYvU=; b=leG1eSLb7Ro3P1L7FCdrc2/Nzailshp2Q4BCIP8x3GuTv8yN+9p7LFJL UmfKrJrm3lwSxEQUgSWtiKrG5St4m7ZtLPhaePq0qZeNrrDutsFAHypUt JbQqgsSFla3Q+nvz4h1UfKW6QrzHhZ38z5Zu9kHOB/0VuSxFcIJzCp38q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwIAB8SlFStJA2K/2dsb2JhbABagwZSWASDAcB6ghsKhGOBDgIcfhYBAQEBAX2EDAEBAQQBAQEaBhE6CwwEAgEGAhEEAQEBAgIGHQMCAgIlCxQBCAgCBA4FCIgkDZxMnGiWPwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGOAx0xBwaCYi6BEwEEjgyJfY0Cgzkig2xvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="381331057" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 19 Dec 2014 11:59:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBJBxkFO006382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 11:59:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 05:59:46 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] call for consensus for the RPL RPI / RH3 compression Thread-Index: AQHQG2REggF8pnpY6Ey+ZkTiXklmHZyWzn+w Date: Fri, 19 Dec 2014 11:59:44 +0000 Deferred-Delivery: Fri, 19 Dec 2014 11:59:00 +0000 Message-ID: References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> In-Reply-To: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/7Nv94r2wn0yXs7xjlcWbeROzYuw Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:59:50 -0000 VGhlIHJ1c2ggQ2Fyc3RlbiwgDQoNCmlzIHRoYXQgdGhlIGRvY3VtZW50IHRoYXQgd2lsbCBiZSB0 aGUgYmFzZSBmb3IgdGhlIDZUaVNDSCBpbnRlcm9wIHRlc3QgaW4gUHJhZ3VlIGlzIG5vdyBpbiBs YXN0IGNhbGwsIGFuZCB0aGF0IGRvY3VtZW50IHJlZmVycyB0byB0aGUgTkhDIGRyYWZ0Lg0KVGhl IHF1ZXN0aW9uIGlzIHdoYXQgc2hvdWxkIGl0IHJlZmVyIHRvLCBhbmQgd2hhdGV2ZXIgaXQgcmVm ZXJzIHRvIHNob3VsZCBiZSBzdGFibGUgYW5kIGltcGxlbWVudGFibGUgYnkgbm93Lg0KDQpKdXN0 IHRoZSBmaXJzdCAocGVyIHlvdXIgd29yZHMpIGlzIGp1c3QgZmluZSB3aXRoIG1lLiANCg0KQ2hl ZXJzLA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBS b2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBC b3JtYW5uDQo+IFNlbnQ6IHZlbmRyZWRpIDE5IGTDqWNlbWJyZSAyMDE0IDA5OjE3DQo+IFRvOiBS b3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jrcw0KPiBDYzogNm1hbi1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc7IGludC1hZHNAdG9vbHMuaWV0Zi5vcmc7IDZ0aXNjaEBpZXRmLm9y ZzsgNmxvLQ0KPiBjaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBj YWxsIGZvciBjb25zZW5zdXMgZm9yIHRoZSBSUEwgUlBJIC8gUkgzIGNvbXByZXNzaW9uDQo+IA0K PiBPbiAxNyBEZWMgMjAxNCwgYXQgMDk6MjksIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0 aHViZXJ0QGNpc2NvLmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBEZWNpc2lvbiBpbiBIYXdhaWkg d2FzIHRoYXQgdGhlIE5IQyBkcmFmdCBjb3VsZCBub3QgYmUgYWNjZXB0ZWQgYXMgaXMsDQo+ID4g c2luY2Ugd2Ugc2hvdWxkIGNvbXByZXNzIGFsc28gdGhlIFJIMywgYW5kIHdpdGhvdXQgYSBjbGVh ciB2aWV3IG9mIGhvdw0KPiA+IHRoYXQgd291bGQgaGFwcGVuLCB0aGUgZGV0YWlscyBvZiB0aGUg TkhDIGNvbXByZXNzaW9uIGNvdWxkIG5vdCBiZQ0KPiA+IGRldGVybWluZWQuIFNvIHRoZSBOSEMg YXBwcm9hY2ggd2FzIGFiYW5kb25lZA0KPiANCj4gVGhhdCBpcyBub3QgYXQgYWxsIHdoYXQgSSBy ZWNvbGxlY3QgZnJvbSBIYXdhaWkuDQo+IA0KPiBUaGUgY3VycmVudCBzbW9yZ2FzYm9yZCBpczoN Cj4gDQo+IOKAlCB2YXJpb3VzIHdheXMgdG8gaGlqYWNrIHRoZSBmbG93IGxhYmVsIChkZWFkKSDi gJQgdGhlIDY1NTMtTkhDIHByb3Bvc2FsIOKAlA0KPiBpZGVhcyBmb3IgYSBuZXcgbWVzaCBoZWFk ZXINCj4gDQo+IEnigJltIG5vdCBnb2luZyB0byBiZWF0IHRoZSBkZWFkIGhvcnNlIG9mIHRoZSBm bG93IGxhYmVsIGhpamFjay4NCj4gDQo+IFRoZSA2NTUzLU5IQyBwcm9wb3NhbCBtYWlubHkgbmVl ZHMgYSBkZWNpc2lvbiBiZXR3ZWVuIHRoZSB0aHJlZSB2YXJpYW50cyAoZmxpcA0KPiBhIGNvaW4s IGlmIG5lZWQgYmUpLg0KPiBJZiB0aW1lIGlzIG9mIHRoZSBlc3NlbmNlLCA2NTUzLU5IQyBpcyB0 aGUgbmF0dXJhbCB0aGluZyB0byBkby4NCj4gV2UgY2FuIGFsd2F5cyBkbyBhbiBSRkMgNjU1NCBO SEMgY29tcHJlc3Npb24gc2VwYXJhdGVseS4NCj4gDQo+IFRoZSBNSCBwcm9wb3NhbCBpcyBmb3J3 YXJkLWxvb2tpbmcgYW5kIHByb2JhYmx5IHRoZSByaWdodCB0aGluZyBmb3IgdGhlDQo+IGV2b2x1 dGlvbiBvZiA2bG8sIGJ1dCBwcm9iYWJseSBhbHNvIG5vdCBjb21wYXRpYmxlIHdpdGggYSB0aWdo dCB0aW1lIHNjaGVkdWxlLg0KPiANCj4gTm93LCB3aGF0IGlzIHRoZSBydXNoPw0KPiBSRkMgNjU1 My82NTU0IGRvIGV4aXN0Lg0KPiANCj4gU28gd2UgZ2V0IHRvIGNob29zZSBiZXR3ZWVuIHJ1c2hp bmcgNjU1My1OSEMgdG8gY29tcGxldGlvbiBvciB1c2luZw0KPiA2NTUzLzY1NTQgZm9yIG5vdyBh bmQgZG9pbmcgdGhlIE1IIHdvcmsgcmlnaHQgKG9yLiBtb3JlIGxpa2VseSB0aGFuIGp1c3QgdGhl DQo+IGZpcnN0LCBib3RoKS4NCj4gSSBkb27igJl0IGhhdmUgYW4gb3BpbmlvbiBvbiB3ZXRoZXIg d2UgbmVlZCB0byBydXNoIDY1NTMtTkhDLCBidXQgaWYgd2UgbmVlZCB0bw0KPiBydXNoIGFueXRo aW5nLCB0aGlzIG9uZSBpdCBpcy4NCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGlu ZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsDQo= From nobody Fri Dec 19 05:25:52 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1221AC40B; Fri, 19 Dec 2014 05:25:47 -0800 (PST) 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 sUCZbGVd-doW; Fri, 19 Dec 2014 05:25:45 -0800 (PST) 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 E0BB51A1AC6; Fri, 19 Dec 2014 05:25:45 -0800 (PST) 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 A5C458812D; Fri, 19 Dec 2014 05:25:45 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 034A071C0002; Fri, 19 Dec 2014 05:25:44 -0800 (PST) Message-ID: <54942758.6090705@innovationslab.net> Date: Fri, 19 Dec 2014 08:25:44 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iag1oLwpPv5XB2LI1FiK74BOP438lOdBB" Archived-At: http://mailarchive.ietf.org/arch/msg/roll/mOBivfbogTAgThJeBLZXn9QI_4I Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 13:25:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iag1oLwpPv5XB2LI1FiK74BOP438lOdBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal, On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote: > The rush Carsten, >=20 > is that the document that will be the base for the 6TiSCH interop > test in Prague is now in last call, and that document refers to the > NHC draft. The question is what should it refer to, and whatever it > refers to should be stable and implementable by now. So, do you view the code for the interop being "set in stone"? As Adrian pointed out, the interop could be a way to work out the tradeoffs of these multiple approaches. That is, running code leads to an IETF specification rather than the other way around. Regards, Brian >=20 > Just the first (per your words) is just fine with me. >=20 > Cheers, >=20 > Pascal >=20 >> -----Original Message----- From: Roll >> [mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: >> vendredi 19 d=C3=A9cembre 2014 09:17 To: Routing Over Low power and >> Lossy networks Cc: 6man-chairs@tools.ietf.org; >> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-=20 >> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus for >> the RPL RPI / RH3 compression >>=20 >> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) >> wrote: >>>=20 >>> Decision in Hawaii was that the NHC draft could not be accepted >>> as is, since we should compress also the RH3, and without a clear >>> view of how that would happen, the details of the NHC compression >>> could not be determined. So the NHC approach was abandoned >>=20 >> That is not at all what I recollect from Hawaii. >>=20 >> The current smorgasbord is: >>=20 >> =E2=80=94 various ways to hijack the flow label (dead) =E2=80=94 the 6= 553-NHC >> proposal =E2=80=94 ideas for a new mesh header >>=20 >> I=E2=80=99m not going to beat the dead horse of the flow label hijack.= >>=20 >> The 6553-NHC proposal mainly needs a decision between the three >> variants (flip a coin, if need be). If time is of the essence, >> 6553-NHC is the natural thing to do. We can always do an RFC 6554 >> NHC compression separately. >>=20 >> The MH proposal is forward-looking and probably the right thing for >> the evolution of 6lo, but probably also not compatible with a tight >> time schedule. >>=20 >> Now, what is the rush? RFC 6553/6554 do exist. >>=20 >> So we get to choose between rushing 6553-NHC to completion or >> using 6553/6554 for now and doing the MH work right (or. more >> likely than just the first, both). I don=E2=80=99t have an opinion on >> wether we need to rush 6553-NHC, but if we need to rush anything, >> this one it is. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ Roll mailing list=20 >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --iag1oLwpPv5XB2LI1FiK74BOP438lOdBB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUlCdYAAoJEBOZRqCi7goqLNIIAJ3r66/QMDGS3fNB/u3BGaLM CGPUr53k4kwwLcfHIzeCAlWkvd19EgpgCpdKtQ7o9VjeDok+pmHJ08wvbmmG1/Dq kz5DKa0ellm7AKkCvNbZ1RLTiepfBQk3uIeXneMwv1UfoO1tbhv/YVIyS6bGkv6/ ksCKcka8tPhnaBaHjzYpQS2JARF6g3evKHXAdEV7zDJui03AGKzHs7RsmzpDlJxX YuGQMW135UmHl+sc1KqUWXg8HQH3XbWICaKSEfoD9CidX8AThSvCbNByvIGm4pxo FXuN7My5PjmhfYBs1KpCRIu2t9/2vu6PpVc4i+VAcb2O05fB11SEbU6qsbc+URo= =FMER -----END PGP SIGNATURE----- --iag1oLwpPv5XB2LI1FiK74BOP438lOdBB-- From nobody Fri Dec 19 07:01:34 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F51A8952; Fri, 19 Dec 2014 07:01:32 -0800 (PST) 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 oAVF-5gh_E24; Fri, 19 Dec 2014 07:01:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481931A700D; Fri, 19 Dec 2014 07:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5314; q=dns/txt; s=iport; t=1419001290; x=1420210890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zBRflTmIilS3IKfq4j7pC7wNYk9wsxmPq4x5zjL79rU=; b=CE6y41DXbRHPM5X0fAyltoD6KcXg848TWUzf0Q8JD/IHi/KjHpM86FXy TGZBjMxNrArc4aXSFWcsDCHokLg+PPf+Z3TvvxP2u1f3xop5SDEfBC8Lh ng03WODlxTmHl+wv1Nl/ihv1Q1svjL24pd3fkM0ziUAvoFUybGryRa4UD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroGAMA8lFStJV2S/2dsb2JhbABagwZSWASDAcB7ghsKhGOBDgIcgQAWAQEBAQF9hAwBAQEEAQEBGgYRMwcLDAQCAQYCEQQBAQECAgYdAwICAiULFAEICAIEDgUIiCQNnTScaJYqAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIY4DHTEHBoJiLoETBY4NiX+NAoM5IoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208";a="378243598" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 19 Dec 2014 15:01:29 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBJF1TW3006927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 15:01:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 09:01:29 -0600 From: "Pascal Thubert (pthubert)" To: Brian Haberman , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] call for consensus for the RPL RPI / RH3 compression Thread-Index: AQHQG49KOTT/hQZ1Sli00GcxCDRZVZyXAHrg Date: Fri, 19 Dec 2014 15:01:28 +0000 Deferred-Delivery: Fri, 19 Dec 2014 15:01:00 +0000 Message-ID: References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <54942758.6090705@innovationslab.net> In-Reply-To: <54942758.6090705@innovationslab.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fsGcPUs-KtnMLSeWilVfN2KDDFA Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:01:32 -0000 VGhhdCdzIGludGVyZXN0aW5nLCBCcmlhbi4NCg0KV2UgZGVjaWRlZCB0aGF0IGZvciBjb21wbGV0 ZW5lc3Mgb2YgaXRzIGV4cHJlc3Npb24gb2YgdGhlIFJQTCBvcGVyYXRpb24sIHRoZSBkcmFmdCBz aG91bGQgcHJvdmlkZSBhIHBvaW50ZXIgb24gdGhlIHdheSB0aGUgUlBMIGluZm8gaXMgY2Fycmll ZC4NCldlIG5lZWQgYSBtaW5pbXVtIHNldCBvZiBjb21tb24gc3R1ZmYgdG8gaW50ZXJvcCBhbmQg dGhlIHdheSB0byBleHByZXNzIHRoZSBSUEwgaW5mb3JtYXRpb24gaXMgb25lLiBXZSBjYW4gbGl2 ZSB3aXRoIGFueSBkZWZhdWx0IGFzIGxvbmcgYXMgZXZlcnlvbmUgaW1wbGVtZW50cyBpdC4NCk5v dyBpZiBvcHRpb25hbGx5IHBlb3BsZSBzdXBwb3J0IGFkZGl0aW9uYWwgd2F5cyB0byBtYWtlIGNv bXBhcmlzb25zIHdpdGggdGhhdCByZWZlcmVuY2UsIHRoYXQgd291bGQgY2VydGFpbmx5IGJlIGdv b2QsIGlmIHRoZSBxdWVzdGlvbiBpcyBzdGlsbCBvcGVuIGF0IHRoYXQgdGltZS4NCkFsbCBpbiBh bGwsIGlmIHlvdSBhZ3JlZSwgd2UgY2FuIHByb2dyZXNzIHRoZSBkcmFmdCBpbiBJRVNHIHJldmll dyBsZWF2aW5nIHRoYXQgcGFydGljdWxhciByZWZlcmVuY2Ugb3BlbiB0byBiZSBjaGFuZ2VkIHRp bGwgbGF0ZXIgaW4gdGhlIHByb2Nlc3M/DQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gSGFiZXJtYW4gW21haWx0bzpicmlhbkBpbm5vdmF0 aW9uc2xhYi5uZXRdDQo+IFNlbnQ6IHZlbmRyZWRpIDE5IGTDqWNlbWJyZSAyMDE0IDE0OjI2DQo+ IFRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFu ZCBMb3NzeSBuZXR3b3Jrcw0KPiBDYzogNm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGludC1h ZHNAdG9vbHMuaWV0Zi5vcmc7IDZ0aXNjaEBpZXRmLm9yZzsgNmxvLQ0KPiBjaGFpcnNAdG9vbHMu aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBjYWxsIGZvciBjb25zZW5zdXMgZm9yIHRo ZSBSUEwgUlBJIC8gUkgzIGNvbXByZXNzaW9uDQo+IA0KPiBQYXNjYWwsDQo+IA0KPiBPbiAxMi8x OS8xNCA2OjU5IEFNLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+IFRoZSBy dXNoIENhcnN0ZW4sDQo+ID4NCj4gPiBpcyB0aGF0IHRoZSBkb2N1bWVudCB0aGF0IHdpbGwgYmUg dGhlIGJhc2UgZm9yIHRoZSA2VGlTQ0ggaW50ZXJvcCB0ZXN0DQo+ID4gaW4gUHJhZ3VlIGlzIG5v dyBpbiBsYXN0IGNhbGwsIGFuZCB0aGF0IGRvY3VtZW50IHJlZmVycyB0byB0aGUgTkhDDQo+ID4g ZHJhZnQuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IHNob3VsZCBpdCByZWZlciB0bywgYW5kIHdoYXRl dmVyIGl0IHJlZmVycw0KPiA+IHRvIHNob3VsZCBiZSBzdGFibGUgYW5kIGltcGxlbWVudGFibGUg Ynkgbm93Lg0KPiANCj4gU28sIGRvIHlvdSB2aWV3IHRoZSBjb2RlIGZvciB0aGUgaW50ZXJvcCBi ZWluZyAic2V0IGluIHN0b25lIj8gIEFzIEFkcmlhbiBwb2ludGVkDQo+IG91dCwgdGhlIGludGVy b3AgY291bGQgYmUgYSB3YXkgdG8gd29yayBvdXQgdGhlIHRyYWRlb2ZmcyBvZiB0aGVzZSBtdWx0 aXBsZQ0KPiBhcHByb2FjaGVzLiAgVGhhdCBpcywgcnVubmluZyBjb2RlIGxlYWRzIHRvIGFuIElF VEYgc3BlY2lmaWNhdGlvbiByYXRoZXIgdGhhbiB0aGUNCj4gb3RoZXIgd2F5IGFyb3VuZC4NCj4g DQo+IFJlZ2FyZHMsDQo+IEJyaWFuDQo+IA0KPiA+DQo+ID4gSnVzdCB0aGUgZmlyc3QgKHBlciB5 b3VyIHdvcmRzKSBpcyBqdXN0IGZpbmUgd2l0aCBtZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPg0K PiA+IFBhc2NhbA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFJv bGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+IE9uIEJlaGFsZiBPZiBDYXJz dGVuIEJvcm1hbm4gU2VudDoNCj4gPj4gdmVuZHJlZGkgMTkgZMOpY2VtYnJlIDIwMTQgMDk6MTcg VG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5DQo+ID4+IG5ldHdvcmtzIENjOiA2 bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgaW50LWFkc0B0b29scy5pZXRmLm9yZzsNCj4gPj4g NnRpc2NoQGlldGYub3JnOyA2bG8tIGNoYWlyc0B0b29scy5pZXRmLm9yZyBTdWJqZWN0OiBSZTog W1JvbGxdIGNhbGwNCj4gPj4gZm9yIGNvbnNlbnN1cyBmb3IgdGhlIFJQTCBSUEkgLyBSSDMgY29t cHJlc3Npb24NCj4gPj4NCj4gPj4gT24gMTcgRGVjIDIwMTQsIGF0IDA5OjI5LCBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpDQo+ID4+IDxwdGh1YmVydEBjaXNjby5jb20+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+IERlY2lzaW9uIGluIEhhd2FpaSB3YXMgdGhhdCB0aGUgTkhDIGRyYWZ0IGNvdWxkIG5v dCBiZSBhY2NlcHRlZCBhcw0KPiA+Pj4gaXMsIHNpbmNlIHdlIHNob3VsZCBjb21wcmVzcyBhbHNv IHRoZSBSSDMsIGFuZCB3aXRob3V0IGEgY2xlYXIgdmlldw0KPiA+Pj4gb2YgaG93IHRoYXQgd291 bGQgaGFwcGVuLCB0aGUgZGV0YWlscyBvZiB0aGUgTkhDIGNvbXByZXNzaW9uIGNvdWxkDQo+ID4+ PiBub3QgYmUgZGV0ZXJtaW5lZC4gU28gdGhlIE5IQyBhcHByb2FjaCB3YXMgYWJhbmRvbmVkDQo+ ID4+DQo+ID4+IFRoYXQgaXMgbm90IGF0IGFsbCB3aGF0IEkgcmVjb2xsZWN0IGZyb20gSGF3YWlp Lg0KPiA+Pg0KPiA+PiBUaGUgY3VycmVudCBzbW9yZ2FzYm9yZCBpczoNCj4gPj4NCj4gPj4g4oCU IHZhcmlvdXMgd2F5cyB0byBoaWphY2sgdGhlIGZsb3cgbGFiZWwgKGRlYWQpIOKAlCB0aGUgNjU1 My1OSEMNCj4gPj4gcHJvcG9zYWwg4oCUIGlkZWFzIGZvciBhIG5ldyBtZXNoIGhlYWRlcg0KPiA+ Pg0KPiA+PiBJ4oCZbSBub3QgZ29pbmcgdG8gYmVhdCB0aGUgZGVhZCBob3JzZSBvZiB0aGUgZmxv dyBsYWJlbCBoaWphY2suDQo+ID4+DQo+ID4+IFRoZSA2NTUzLU5IQyBwcm9wb3NhbCBtYWlubHkg bmVlZHMgYSBkZWNpc2lvbiBiZXR3ZWVuIHRoZSB0aHJlZQ0KPiA+PiB2YXJpYW50cyAoZmxpcCBh IGNvaW4sIGlmIG5lZWQgYmUpLiBJZiB0aW1lIGlzIG9mIHRoZSBlc3NlbmNlLA0KPiA+PiA2NTUz LU5IQyBpcyB0aGUgbmF0dXJhbCB0aGluZyB0byBkby4gV2UgY2FuIGFsd2F5cyBkbyBhbiBSRkMg NjU1NCBOSEMNCj4gPj4gY29tcHJlc3Npb24gc2VwYXJhdGVseS4NCj4gPj4NCj4gPj4gVGhlIE1I IHByb3Bvc2FsIGlzIGZvcndhcmQtbG9va2luZyBhbmQgcHJvYmFibHkgdGhlIHJpZ2h0IHRoaW5n IGZvcg0KPiA+PiB0aGUgZXZvbHV0aW9uIG9mIDZsbywgYnV0IHByb2JhYmx5IGFsc28gbm90IGNv bXBhdGlibGUgd2l0aCBhIHRpZ2h0DQo+ID4+IHRpbWUgc2NoZWR1bGUuDQo+ID4+DQo+ID4+IE5v dywgd2hhdCBpcyB0aGUgcnVzaD8gUkZDIDY1NTMvNjU1NCBkbyBleGlzdC4NCj4gPj4NCj4gPj4g U28gd2UgZ2V0IHRvIGNob29zZSBiZXR3ZWVuIHJ1c2hpbmcgNjU1My1OSEMgdG8gY29tcGxldGlv biBvciB1c2luZw0KPiA+PiA2NTUzLzY1NTQgZm9yIG5vdyBhbmQgZG9pbmcgdGhlIE1IIHdvcmsg cmlnaHQgKG9yLiBtb3JlIGxpa2VseSB0aGFuDQo+ID4+IGp1c3QgdGhlIGZpcnN0LCBib3RoKS4g SSBkb27igJl0IGhhdmUgYW4gb3BpbmlvbiBvbiB3ZXRoZXIgd2UgbmVlZCB0bw0KPiA+PiBydXNo IDY1NTMtTkhDLCBidXQgaWYgd2UgbmVlZCB0byBydXNoIGFueXRoaW5nLCB0aGlzIG9uZSBpdCBp cy4NCj4gPj4NCj4gPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBSb2xsIG1haWxpbmcgbGlzdA0KPiA+ PiBSb2xsQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bA0KDQo= From nobody Fri Dec 19 07:12:41 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66D91A88D3 for ; Fri, 19 Dec 2014 07:12:37 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Bby_lPTe_oDz for ; Fri, 19 Dec 2014 07:12:34 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B58A1A89A9 for ; Fri, 19 Dec 2014 07:12:25 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id VTCP1p0064K0fSy01TCPF2; Fri, 19 Dec 2014 16:12:23 +0100 Received: from [2001:983:a264:1:fc06:6827:b427:cb66] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 19 Dec 2014 16:12:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Dec 2014 16:12:23 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> References: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> Message-ID: <208b67fefd88553f27c1ce6d7902e84d@xs4all.nl> X-Sender: stokcons@xs4all.nl (SWIdeaQncSUwhf/zIsiW6vn4o3KPFUYz) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/y5Kx_pHVN5E29IS8YPPn01WEi-E Subject: Re: [Roll] [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:12:37 -0000 Hi Joel, Thanks for pointing this out. After some thought, the best solution seems to embed the MPL admin local scope within the zone concept. I propose the following addition: MPL4 messages remain bounded within a zone. Consequently, MPL4 messages cannot be routed between interfaces belonging to different zones. For example, consider a router with 5 interfaces where interfaces A and B beloing to zone 1 and interfaces C,D, and E belong to zone 2. Mpl4 messages can be routed freely between interfaces A and B, and freely between C,D, and E. However, a MPL4 message MUST NOT be routed from Interface A to interface B. When the concept of zone is unknown or disabled in a router, all interfaces belong to the same zone. This means adding the zone concept to rules of section 4.2, and text to relate zone better to MPL4 zone. Does this address your issue? If yes, I will make a new draft along these lines beginning January 2015. Greetings, Peter roll issue tracker schreef op 2014-12-16 00:19: > #167: Not match the requirement for administrative configuration of the > admin- > local scope > > From: Joel M. Halpern > Date: 2014-12-16 0:59 GMT+02:00 > > Major issues: > There seems to be a disconnect between the notion of > administratively > configured and the behavior described in this draft for admin-local > multicast scope. As far as I can tell, the forwarding behavior > described > here has no mechanism for administratively configuring the > administrative > boundary. The only knob that is used is PROACTIVE_FORWARDING, which > is > used for intra-realm multicast forwarding. Thus, if you have a roll > multicast router with two interfaces in one realm and two interfaces > in > another realm, in order to provide realm multicast services for each > realm, this router according to this draft will always forward > admin-local > multicast messages between the two realms. That does not seem to me > to > match the requirement for administrative configuration of the > admin-local > scope From nobody Fri Dec 19 07:15:09 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDA31A897E; Fri, 19 Dec 2014 07:15:07 -0800 (PST) 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 aJZ1Mv_EWl7C; Fri, 19 Dec 2014 07:15:05 -0800 (PST) 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 E8DB01A884B; Fri, 19 Dec 2014 07:15:04 -0800 (PST) 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 C9DE9880F5; Fri, 19 Dec 2014 07:15:04 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 98ADF71C0002; Fri, 19 Dec 2014 07:15:03 -0800 (PST) Message-ID: <549440F0.8040407@innovationslab.net> Date: Fri, 19 Dec 2014 10:14:56 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <54942758.6090705@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3IsO6AJl1kB7N4tmhQ7uMIJJPR5ESPD0c" Archived-At: http://mailarchive.ietf.org/arch/msg/roll/10txAwSss9E30g6XLaC3a8Heaoo Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:15:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3IsO6AJl1kB7N4tmhQ7uMIJJPR5ESPD0c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote: > That's interesting, Brian. >=20 > We decided that for completeness of its expression of the RPL > operation, the draft should provide a pointer on the way the RPL info > is carried. We need a minimum set of common stuff to interop and the > way to express the RPL information is one. We can live with any > default as long as everyone implements it. Now if optionally people > support additional ways to make comparisons with that reference, that > would certainly be good, if the question is still open at that time.=20 > All in all, if you agree, we can progress the draft in IESG review > leaving that particular reference open to be changed till later in > the process? Why would you expect that to be acceptable? If a piece of the spec is needed for interoperability, it needs to be there during the review. Why send it to the IESG if there are still questions on how that piece will be done? If it is left out, how will anyone know if there is consensus on the spec as a whole? It seems to me that: 1. There have been several proposals put forth 2. Issues have been raised on each one So, it seems prudent (to me) to look at each of the alternatives and determine which warts everyone concerned is willing to live with. Running code is a good way to do that. Making that determination needs to be done before the spec is sent to the IESG. Regards, Brian >=20 > Pascal >=20 >=20 >> -----Original Message----- From: Brian Haberman >> [mailto:brian@innovationslab.net] Sent: vendredi 19 d=C3=A9cembre 2014= >> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and >> Lossy networks Cc: 6man-chairs@tools.ietf.org; >> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-=20 >> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus for >> the RPL RPI / RH3 compression >>=20 >> Pascal, >>=20 >> On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote: >>> The rush Carsten, >>>=20 >>> is that the document that will be the base for the 6TiSCH interop >>> test in Prague is now in last call, and that document refers to >>> the NHC draft. The question is what should it refer to, and >>> whatever it refers to should be stable and implementable by now. >>=20 >> So, do you view the code for the interop being "set in stone"? As >> Adrian pointed out, the interop could be a way to work out the >> tradeoffs of these multiple approaches. That is, running code >> leads to an IETF specification rather than the other way around. >>=20 >> Regards, Brian >>=20 >>>=20 >>> Just the first (per your words) is just fine with me. >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>>> -----Original Message----- From: Roll >>>> [mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann >>>> Sent: vendredi 19 d=C3=A9cembre 2014 09:17 To: Routing Over Low >>>> power and Lossy networks Cc: 6man-chairs@tools.ietf.org; >>>> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo- >>>> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus >>>> for the RPL RPI / RH3 compression >>>>=20 >>>> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert)=20 >>>> wrote: >>>>>=20 >>>>> Decision in Hawaii was that the NHC draft could not be >>>>> accepted as is, since we should compress also the RH3, and >>>>> without a clear view of how that would happen, the details of >>>>> the NHC compression could not be determined. So the NHC >>>>> approach was abandoned >>>>=20 >>>> That is not at all what I recollect from Hawaii. >>>>=20 >>>> The current smorgasbord is: >>>>=20 >>>> =E2=80=94 various ways to hijack the flow label (dead) =E2=80=94 the= 6553-NHC=20 >>>> proposal =E2=80=94 ideas for a new mesh header >>>>=20 >>>> I=E2=80=99m not going to beat the dead horse of the flow label hijac= k. >>>>=20 >>>> The 6553-NHC proposal mainly needs a decision between the >>>> three variants (flip a coin, if need be). If time is of the >>>> essence, 6553-NHC is the natural thing to do. We can always do >>>> an RFC 6554 NHC compression separately. >>>>=20 >>>> The MH proposal is forward-looking and probably the right thing >>>> for the evolution of 6lo, but probably also not compatible with >>>> a tight time schedule. >>>>=20 >>>> Now, what is the rush? RFC 6553/6554 do exist. >>>>=20 >>>> So we get to choose between rushing 6553-NHC to completion or >>>> using 6553/6554 for now and doing the MH work right (or. more >>>> likely than just the first, both). I don=E2=80=99t have an opinion o= n >>>> wether we need to rush 6553-NHC, but if we need to rush >>>> anything, this one it is. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >=20 --3IsO6AJl1kB7N4tmhQ7uMIJJPR5ESPD0c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUlED2AAoJEBOZRqCi7goqjAwIAKeQvba06QNQ0clMmNbZnocq ZHiQuoVEYcsOZYuM2bK8xIe982cLBHwAHquonATEwN2mROKBpJ+RfD6EqlxHEYmq 2YBujeW0djxQB2bg5NOfeDOiqWCgoiH0YcvRc2DdBx7zKpOiqKF3e4Swra34LKa6 pKtEg+4Ol68K+F+19WmYsS0ht0ArbPu0hidD60rB4Z49Yq+igrA49pKvFccyYfaX GiTUa19mcbMY6wtBvJM0J4Ap1AhZWVJ7l1TU08iFRYGdE67i0WVLIi4seWPOqkrT bV4xzpoARNzSiO2LSN71EgKZ1BXAIlb84SEgBzhBAJvyX7r1HCAD7v/qYPnbAfw= =doW8 -----END PGP SIGNATURE----- --3IsO6AJl1kB7N4tmhQ7uMIJJPR5ESPD0c-- From nobody Fri Dec 19 07:54:49 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173571A89C4; Fri, 19 Dec 2014 07:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ey3c4F-Q2v5m; Fri, 19 Dec 2014 07:54:41 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2C21A89B9; Fri, 19 Dec 2014 07:54:40 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Y1zt0-0005m8-1G; Fri, 19 Dec 2014 15:54:38 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Y1zsy-0001qU-Jl; Fri, 19 Dec 2014 15:54:37 +0000 Received: from [12.234.128.141] (helo=[100.68.5.120]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Y1zst-0002rc-UH; Fri, 19 Dec 2014 15:54:32 +0000 Message-ID: <54944A36.4000101@gridmerge.com> Date: Fri, 19 Dec 2014 15:54:30 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <54942758.6090705@innovationslab.net> <549440F0.8040407@innovationslab.net> In-Reply-To: <549440F0.8040407@innovationslab.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703010502080204070200" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DN_9_dv7rHhjvDeagloftCB2AYM Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:54:45 -0000 This is a cryptographically signed message in MIME format. --------------ms010703010502080204070200 Content-Type: multipart/alternative; boundary="------------030805020801050105090602" This is a multi-part message in MIME format. --------------030805020801050105090602 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable +1. It sounds like an interop would be the ideal place to test out the=20 various hypotheses on the respective proposals. Robert On 19/12/2014 15:14, Brian Haberman wrote: > > On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote: >> That's interesting, Brian. >> >> We decided that for completeness of its expression of the RPL >> operation, the draft should provide a pointer on the way the RPL info >> is carried. We need a minimum set of common stuff to interop and the >> way to express the RPL information is one. We can live with any >> default as long as everyone implements it. Now if optionally people >> support additional ways to make comparisons with that reference, that >> would certainly be good, if the question is still open at that time. >> All in all, if you agree, we can progress the draft in IESG review >> leaving that particular reference open to be changed till later in >> the process? > Why would you expect that to be acceptable? If a piece of the spec is > needed for interoperability, it needs to be there during the review. > Why send it to the IESG if there are still questions on how that piece > will be done? If it is left out, how will anyone know if there is > consensus on the spec as a whole? > > It seems to me that: > > 1. There have been several proposals put forth > > 2. Issues have been raised on each one > > So, it seems prudent (to me) to look at each of the alternatives and > determine which warts everyone concerned is willing to live with. > Running code is a good way to do that. > > Making that determination needs to be done before the spec is sent to > the IESG. > > Regards, > Brian > >> Pascal >> >> >>> -----Original Message----- From: Brian Haberman >>> [mailto:brian@innovationslab.net] Sent: vendredi 19 d=E9cembre 2014 >>> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and >>> Lossy networks Cc: 6man-chairs@tools.ietf.org; >>> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo- >>> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus for >>> the RPL RPI / RH3 compression >>> >>> Pascal, >>> >>> On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote: >>>> The rush Carsten, >>>> >>>> is that the document that will be the base for the 6TiSCH interop >>>> test in Prague is now in last call, and that document refers to >>>> the NHC draft. The question is what should it refer to, and >>>> whatever it refers to should be stable and implementable by now. >>> So, do you view the code for the interop being "set in stone"? As >>> Adrian pointed out, the interop could be a way to work out the >>> tradeoffs of these multiple approaches. That is, running code >>> leads to an IETF specification rather than the other way around. >>> >>> Regards, Brian >>> >>>> Just the first (per your words) is just fine with me. >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>>> -----Original Message----- From: Roll >>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann >>>>> Sent: vendredi 19 d=E9cembre 2014 09:17 To: Routing Over Low >>>>> power and Lossy networks Cc: 6man-chairs@tools.ietf.org; >>>>> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo- >>>>> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus >>>>> for the RPL RPI / RH3 compression >>>>> >>>>> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) >>>>> wrote: >>>>>> Decision in Hawaii was that the NHC draft could not be >>>>>> accepted as is, since we should compress also the RH3, and >>>>>> without a clear view of how that would happen, the details of >>>>>> the NHC compression could not be determined. So the NHC >>>>>> approach was abandoned >>>>> That is not at all what I recollect from Hawaii. >>>>> >>>>> The current smorgasbord is: >>>>> >>>>> =97 various ways to hijack the flow label (dead) =97 the 6553-NHC >>>>> proposal =97 ideas for a new mesh header >>>>> >>>>> I=92m not going to beat the dead horse of the flow label hijack. >>>>> >>>>> The 6553-NHC proposal mainly needs a decision between the >>>>> three variants (flip a coin, if need be). If time is of the >>>>> essence, 6553-NHC is the natural thing to do. We can always do >>>>> an RFC 6554 NHC compression separately. >>>>> >>>>> The MH proposal is forward-looking and probably the right thing >>>>> for the evolution of 6lo, but probably also not compatible with >>>>> a tight time schedule. >>>>> >>>>> Now, what is the rush? RFC 6553/6554 do exist. >>>>> >>>>> So we get to choose between rushing 6553-NHC to completion or >>>>> using 6553/6554 for now and doing the MH work right (or. more >>>>> likely than just the first, both). I don=92t have an opinion on >>>>> wether we need to rush 6553-NHC, but if we need to rush >>>>> anything, this one it is. >>>>> >>>>> Gr=FC=DFe, Carsten >>>>> >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------030805020801050105090602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1.

It sounds like an interop would be the ideal place to test out the various hypotheses on the respective proposals.

Robert

On 19/12/2014 15:14, Brian Haberman wrote:

On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:

That's interesting, Brian.

We decided that for completeness of its expression of the RPL
operation, the draft should provide a pointer on the way the RPL info
is carried. We need a minimum set of common stuff to interop and the
way to express the RPL information is one. We can live with any
default as long as everyone implements it. Now if optionally people
support additional ways to make comparisons with that reference, that
would certainly be good, if the question is still open at that time.=20
All in all, if you agree, we can progress the draft in IESG review
leaving that particular reference open to be changed till later in
the process?

Why would you expect that to be acceptable?  If a piece of the spec is
needed for interoperability, it needs to be there during the review.
Why send it to the IESG if there are still questions on how that piece
will be done?  If it is left out, how will anyone know if there is
consensus on the spec as a whole?

It seems to me that:

1. There have been several proposals put forth

2. Issues have been raised on each one

So, it seems prudent (to me) to look at each of the alternatives and
determine which warts everyone concerned is willing to live with.
Running code is a good way to do that.

Making that determination needs to be done before the spec is sent to
the IESG.

Regards,
Brian


Pascal



-----Original Message----- From: Brian Haberman
[mailto:brian@innovationslab.net] Sent: vendredi 19 d=E9cembre 201=
4
14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
Lossy networks Cc: 6man-chairs@tools.ietf.org;
int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-=20
chairs@tools.ietf.org Subject: Re: [Roll] call for consensus for
the RPL RPI / RH3 compression

Pascal,

On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:

The rush Carsten,

is that the document that will be the base for the 6TiSCH interop
test in Prague is now in last call, and that document refers to
the NHC draft. The question is what should it refer to, and
whatever it refers to should be stable and implementable by now.

So, do you view the code for the interop being "set in stone"?  As
Adrian pointed out, the interop could be a way to work out the
tradeoffs of these multiple approaches.  That is, running code
leads to an IETF specification rather than the other way around.

Regards, Brian


Just the first (per your words) is just fine with me.

Cheers,

Pascal


-----Original Message----- From: Roll
[mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: vendredi 19 d=E9cembre 2014 09:17 To: Routing Over Low
power and Lossy networks Cc: 6man-chairs@tools.ietf.org;
int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-
chairs@tools.ietf.org Subject: Re: [Roll] call for consensus
for the RPL RPI / RH3 compression

On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert)=20
<=
;pthubert@cisco.com> wrote:

Decision in Hawaii was that the NHC draft could not be
accepted as is, since we should compress also the RH3, and
without a clear view of how that would happen, the details of
the NHC compression could not be determined. So the NHC
approach was abandoned

That is not at all what I recollect from Hawaii.

The current smorgasbord is:

=97 various ways to hijack the flow label (dead) =97 the 6553-NHC=20
proposal =97 ideas for a new mesh header

I=92m not going to beat the dead horse of the flow label hijack.

The 6553-NHC proposal mainly needs a decision between the
three variants (flip a coin, if need be). If time is of the
essence, 6553-NHC is the natural thing to do. We can always do
an RFC 6554 NHC compression separately.

The MH proposal is forward-looking and probably the right thing
for the evolution of 6lo, but probably also not compatible with
a tight time schedule.

Now, what is the rush? RFC 6553/6554 do exist.

So we get to choose between rushing 6553-NHC to completion or
using 6553/6554 for now and doing the MH work right (or. more
likely than just the first, both). I don=92t have an opinion on
wether we need to rush 6553-NHC, but if we need to rush
anything, this one it is.

Gr=FC=DFe, Carsten

_______________________________________________ Roll mailing
list =
Roll@ietf.org https://www.ietf.org/mailman/listinfo/rol=
l


      

      

      

      

      

      
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll


    

    

  


--------------030805020801050105090602--

--------------ms010703010502080204070200
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC
BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3
o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU
a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU
q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK
LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ
Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo
//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN
IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/
cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B
EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR
2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E
BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js
LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE
KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB
DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1
uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX
aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW
ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla
4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5
MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa
MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN
MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD
VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu
Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp
ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt
UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT
DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j
qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF
mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6
7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD
qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH
CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4
xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1
cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy
bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0
LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa
1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1
5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr
Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m
LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5
WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ
BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEyMTkxNTU0MzBaMCMGCSqGSIb3DQEJBDEWBBQuoME2DKOHld3OVqgKMug/LNoDWTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g
UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0
T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBkOmE27Q+O3zCFYa9Co1Htw0MozCTZqjCt
YoRGTCfhqt5jjKHj8OwsNzqzyTTxu5izSc5VkaIlch/0KSEA1zh0Vdm4NKhU0xwTIfXXFi7s
rUZT+6cogxOdtq77/KQO4oFOME4debL7OtKRaV+9aP2Q+jpu8Kl5+tQhD6HvZgoqtInHsoCL
CHH/CvglRkKRnL4YLWl3xb3rRzIAMt4tzUtF8GY83YTHpkQ1OBUh6CQ2QN3//Q4ake+8HtjG
vaMqQ5eO0l7wXFuPRihDzcyCDLc9K+DfNiEzuooOp7FUMGiRFRhori2PpqfrCW802uihowjt
0xz2cX2gKVGj57f5v5i+AAAAAAAA
--------------ms010703010502080204070200--


From nobody Fri Dec 19 09:32:49 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4A1A9048; Fri, 19 Dec 2014 09:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 I4uzJ8RQfZct; Fri, 19 Dec 2014 09:32:42 -0800 (PST)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6321A9076; Fri, 19 Dec 2014 09:32:09 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id l18so1931802wgh.12; Fri, 19 Dec 2014 09:32:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uTgYA2c9GzNmQS1fbFEKXAz6SgAvGjDh1/eHXYYz+CU=; b=Z7qry5veDE25gtAb6NCWV2PnHLoBlyQ7SE5XPipHsveBHgKxwqIKM1msnRv4JydIdK HY0fJrWtHvOkroKM2KqY9yZAh1wvpHEnaJ1QX+gTYLlAts9QfPByfzedrpg50SxK3FvC yR0Dq0mNZs0Ub+ev0fauwUvgRydVd/4z6j6605mWtEQ65/nkDI3f86CQO9yV1RSDFdq9 zOJHA4NEnT/5d0VFgoK2BCda6khzR7bdlzCZiBr8+1ennSULvnzIRoCmAslenFqGBh/B Y7awBaEfZREjbgTnStmQqkJnGx/DKLdRmU9rDWwkQnyH6y+xXjFCqQmo3W94ZyQMv4OV qh1g==
MIME-Version: 1.0
X-Received: by 10.180.78.202 with SMTP id d10mr7979030wix.82.1419010327757; Fri, 19 Dec 2014 09:32:07 -0800 (PST)
Sender: xvilajosana@gmail.com
Received: by 10.27.210.201 with HTTP; Fri, 19 Dec 2014 09:32:07 -0800 (PST)
In-Reply-To: <54944A36.4000101@gridmerge.com>
References:  <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org>  <54942758.6090705@innovationslab.net>  <549440F0.8040407@innovationslab.net> <54944A36.4000101@gridmerge.com>
Date: Fri, 19 Dec 2014 18:32:07 +0100
X-Google-Sender-Auth: E1y8w485Br61uCXspVBKKPLQAWI
Message-ID: 
From: Xavier Vilajosana 
To: robert.cragie@gridmerge.com
Content-Type: multipart/alternative; boundary=f46d043c084884c83c050a9516f1
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/NI7iLLlFXoNGzwo2hmFWg4IY6_8
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, Routing Over Low power and Lossy networks , "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] [6tisch] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Dec 2014 17:32:46 -0000

--f46d043c084884c83c050a9516f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I do not think this is an implementation problem. It seems to me an
architectural problem. If we want to compress the HbH routing header we
have to decide for the best approach and do it once. Flow label is an
option that we tested but it is not aligned to the way IPHC headers are
compressed and we discussed this for weeks at 6tisch. We already know most
of the PROS and CONS of the approaches being discussed but the problem I
guess it is not performance or number of bytes saved but the coherence of
the procedure of compressing the header with respect to the IPHC approach.

If going for a NHC or RH3 may take years at 6lo we have the option to stay
with current HbH header approach or push for flow label knowing that due
time constraints we cannot do it better but I do not thing that testing
would solve this coherence problem.

regards,
Xavi



2014-12-19 16:54 GMT+01:00 Robert Cragie :
>
>  +1.
>
> It sounds like an interop would be the ideal place to test out the variou=
s
> hypotheses on the respective proposals.
>
> Robert
>
>
> On 19/12/2014 15:14, Brian Haberman wrote:
>
> On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:
>
>  That's interesting, Brian.
>
> We decided that for completeness of its expression of the RPL
> operation, the draft should provide a pointer on the way the RPL info
> is carried. We need a minimum set of common stuff to interop and the
> way to express the RPL information is one. We can live with any
> default as long as everyone implements it. Now if optionally people
> support additional ways to make comparisons with that reference, that
> would certainly be good, if the question is still open at that time.
> All in all, if you agree, we can progress the draft in IESG review
> leaving that particular reference open to be changed till later in
> the process?
>
>  Why would you expect that to be acceptable?  If a piece of the spec is
> needed for interoperability, it needs to be there during the review.
> Why send it to the IESG if there are still questions on how that piece
> will be done?  If it is left out, how will anyone know if there is
> consensus on the spec as a whole?
>
> It seems to me that:
>
> 1. There have been several proposals put forth
>
> 2. Issues have been raised on each one
>
> So, it seems prudent (to me) to look at each of the alternatives and
> determine which warts everyone concerned is willing to live with.
> Running code is a good way to do that.
>
> Making that determination needs to be done before the spec is sent to
> the IESG.
>
> Regards,
> Brian
>
>
>  Pascal
>
>
>
>  -----Original Message----- From: Brian Haberman
> [mailto:brian@innovationslab.net ] Sent: vendre=
di 19 d=C3=A9cembre 2014
> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
> Lossy networks Cc: 6man-chairs@tools.ietf.org;int-ads@tools.ietf.org; 6ti=
sch@ietf.org; 6lo- chairs@tools.ietf.org Subject: Re: [Roll] call for conse=
nsus for
> the RPL RPI / RH3 compression
>
> Pascal,
>
> On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:
>
>  The rush Carsten,
>
> is that the document that will be the base for the 6TiSCH interop
> test in Prague is now in last call, and that document refers to
> the NHC draft. The question is what should it refer to, and
> whatever it refers to should be stable and implementable by now.
>
>  So, do you view the code for the interop being "set in stone"?  As
> Adrian pointed out, the interop could be a way to work out the
> tradeoffs of these multiple approaches.  That is, running code
> leads to an IETF specification rather than the other way around.
>
> Regards, Brian
>
>
>  Just the first (per your words) is just fine with me.
>
> Cheers,
>
> Pascal
>
>
>  -----Original Message----- From: Roll
> [mailto:roll-bounces@ietf.org ] On Behalf Of Carst=
en Bormann
> Sent: vendredi 19 d=C3=A9cembre 2014 09:17 To: Routing Over Low
> power and Lossy networks Cc: 6man-chairs@tools.ietf.org;int-ads@tools.iet=
f.org; 6tisch@ietf.org; 6lo-chairs@tools.ietf.org Subject: Re: [Roll] call =
for consensus
> for the RPL RPI / RH3 compression
>
> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert)  =
 wrote:
>
>  Decision in Hawaii was that the NHC draft could not be
> accepted as is, since we should compress also the RH3, and
> without a clear view of how that would happen, the details of
> the NHC compression could not be determined. So the NHC
> approach was abandoned
>
>  That is not at all what I recollect from Hawaii.
>
> The current smorgasbord is:
>
> =E2=80=94 various ways to hijack the flow label (dead) =E2=80=94 the 6553=
-NHC
> proposal =E2=80=94 ideas for a new mesh header
>
> I=E2=80=99m not going to beat the dead horse of the flow label hijack.
>
> The 6553-NHC proposal mainly needs a decision between the
> three variants (flip a coin, if need be). If time is of the
> essence, 6553-NHC is the natural thing to do. We can always do
> an RFC 6554 NHC compression separately.
>
> The MH proposal is forward-looking and probably the right thing
> for the evolution of 6lo, but probably also not compatible with
> a tight time schedule.
>
> Now, what is the rush? RFC 6553/6554 do exist.
>
> So we get to choose between rushing 6553-NHC to completion or
> using 6553/6554 for now and doing the MH work right (or. more
> likely than just the first, both). I don=E2=80=99t have an opinion on
> wether we need to rush 6553-NHC, but if we need to rush
> anything, this one it is.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________ Roll mailing
> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing listRoll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

--f46d043c084884c83c050a9516f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I do not think this is an implement=
ation problem. It seems to me an architectural problem. If we want to compr=
ess the HbH routing header we have to decide for the best approach and do i=
t once. Flow label is an option that we tested but it is not aligned to the=
 way IPHC headers are compressed and we discussed this for weeks at 6tisch.=
 We already know most of the PROS and CONS of the approaches being discusse=
d but the problem I guess it is not performance or number of bytes saved bu=
t the coherence of the procedure of compressing the header with respect to =
the IPHC approach.

If going for a NHC or RH3 may t=
ake years at 6lo we have the option to stay with current HbH header approac=
h or push for flow label knowing that due time constraints we cannot do it =
better but I do not thing that testing would solve this coherence problem.<=
/div>

regards,
Xavi



2014-12-1=
9 16:54 GMT+01:00 Robert Cragie <robert.cragie@gridmerge.com=
>:

 =20
   =20
 =20
  

    +1.

    

    It sounds like an interop would be the ideal place to test out the
    various hypotheses on the respective proposals.<=
font color=3D"#888888">

    

    Robert


    

    
On 19/12/2014 15:14, Brian Haberman
      wrote:

    

    

      
On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:


      

        
That's interesting, Brian.

We decided that for completeness of its expression of the RPL
operation, the draft should provide a pointer on the way the RPL info
is carried. We need a minimum set of common stuff to interop and the
way to express the RPL information is one. We can live with any
default as long as everyone implements it. Now if optionally people
support additional ways to make comparisons with that reference, that
would certainly be good, if the question is still open at that time.=20
All in all, if you agree, we can progress the draft in IESG review
leaving that particular reference open to be changed till later in
the process?


      

      
Why would you expect that to be acceptable?  If a piece of the s=
pec is
needed for interoperability, it needs to be there during the review.
Why send it to the IESG if there are still questions on how that piece
will be done?  If it is left out, how will anyone know if there is
consensus on the spec as a whole?

It seems to me that:

1. There have been several proposals put forth

2. Issues have been raised on each one

So, it seems prudent (to me) to look at each of the alternatives and
determine which warts everyone concerned is willing to live with.
Running code is a good way to do that.

Making that determination needs to be done before the spec is sent to
the IESG.

Regards,
Brian



      

        
Pascal




        

          
-----Original Message----- From: Brian Haberman
[mailto:brian=
@innovationslab.net] Sent: vendredi 19 d=C3=A9cembre 2014
14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
Lossy networks Cc: 6man-chairs@tools.ietf.org;
int-ads@tools.i=
etf.org; 6tisch@ie=
tf.org; 6lo-=20
chairs@tools.iet=
f.org Subject: Re: [Roll] call for consensus for
the RPL RPI / RH3 compression

Pascal,

On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:


          

            
The rush Carsten,

is that the document that will be the base for the 6TiSCH interop
test in Prague is now in last call, and that document refers to
the NHC draft. The question is what should it refer to, and
whatever it refers to should be stable and implementable by now.


          

          
So, do you view the code for the interop being "set in =
stone"?  As
Adrian pointed out, the interop could be a way to work out the
tradeoffs of these multiple approaches.  That is, running code
leads to an IETF specification rather than the other way around.

Regards, Brian



          

            
Just the first (per your words) is just fine with me.

Cheers,

Pascal



            

              
-----Original Message----- From: Roll
[mailto:roll-bou=
nces@ietf.org] On Behalf Of Carsten Bormann
Sent: vendredi 19 d=C3=A9cembre 2014 09:17 To: Routing Over Low
power and Lossy networks Cc: 6man-chairs@tools.ietf.org;
int-ads@tools.i=
etf.org; 6tisch@ie=
tf.org; 6lo-
chairs@tools.iet=
f.org Subject: Re: [Roll] call for consensus
for the RPL RPI / RH3 compression

On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert)=20
<pthubert@cisco.=
com> wrote:


              

                
Decision in Hawaii was that the NHC draft could not be
accepted as is, since we should compress also the RH3, and
without a clear view of how that would happen, the details of
the NHC compression could not be determined. So the NHC
approach was abandoned


              

              
That is not at all what I recollect from Hawaii.

The current smorgasbord is:

=E2=80=94 various ways to hijack the flow label (dead) =E2=80=94 the 6553-N=
HC=20
proposal =E2=80=94 ideas for a new mesh header

I=E2=80=99m not going to beat the dead horse of the flow label hijack.

The 6553-NHC proposal mainly needs a decision between the
three variants (flip a coin, if need be). If time is of the
essence, 6553-NHC is the natural thing to do. We can always do
an RFC 6554 NHC compression separately.

The MH proposal is forward-looking and probably the right thing
for the evolution of 6lo, but probably also not compatible with
a tight time schedule.

Now, what is the rush? RFC 6553/6554 do exist.

So we get to choose between rushing 6553-NHC to completion or
using 6553/6554 for now and doing the MH work right (or. more
likely than just the first, both). I don=E2=80=99t have an opinion on
wether we need to rush 6553-NHC, but if we need to rush
anything, this one it is.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________ Roll mailing
list Roll@ietf.org <=
a href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/roll


            

          

        

        

      

      

      

      

      

      
_______________________________________________
Roll mailing list
Roll@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/roll


    

    

  



_______________________________________________

6tisch mailing list

6tisch@ietf.org

=
https://www.ietf.org/mailman/listinfo/6tisch




--f46d043c084884c83c050a9516f1--


From nobody Fri Dec 19 13:57:10 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F5F1A86F2; Fri, 19 Dec 2014 13:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 nSS5NBbILMbp; Fri, 19 Dec 2014 13:57:08 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044601A1BD2; Fri, 19 Dec 2014 13:57:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sBJLv0Js000519; Fri, 19 Dec 2014 22:57:00 +0100 (CET)
Received: from [192.168.217.149] (p54890ADC.dip0.t-ipconnect.de [84.137.10.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3k43nl5nvgz7xC2; Fri, 19 Dec 2014 22:56:59 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Carsten Bormann 
In-Reply-To: <549440F0.8040407@innovationslab.net>
Date: Fri, 19 Dec 2014 22:56:58 +0100
X-Mao-Original-Outgoing-Id: 440719016.832045-b05aeee497cfb7575977be876d1a58b7
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org>
References:  <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org>  <54942758.6090705@innovationslab.net>  <549440F0.8040407@innovationslab.net>
To: Routing Over Low power and Lossy networks 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/KKJJ9FuJSZjvzLyMwgIyaSf819g
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Dec 2014 21:57:09 -0000

On 19 Dec 2014, at 16:14, Brian Haberman  =
wrote:
>=20
> 1. There have been several proposals put forth
>=20
> 2. Issues have been raised on each one
>=20
> So, it seems prudent (to me) to look at each of the alternatives and
> determine which warts everyone concerned is willing to live with.
> Running code is a good way to do that.

I agree with Xavi here: This is a good way to gather data for =
implementation issues (such as the implementation complexity of the =
=E2=80=9Cefficient=E2=80=9D variant of the NHC approach).  It is not so =
good for architectural issues (flow label) or housekeeping issues (code =
point usage of the =E2=80=9Cgreedy=E2=80=9D variant; code point re-use =
in the revised MH proposal).  We should have an agreement on the latter =
ones before going into a plugfest.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Sat Dec 20 06:38:44 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B1C1A90B4; Sat, 20 Dec 2014 06:38:42 -0800 (PST)
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 gPvGN_nw16LU; Sat, 20 Dec 2014 06:38:41 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAE41A8AFE; Sat, 20 Dec 2014 06:38:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1199; q=dns/txt; s=iport; t=1419086321; x=1420295921; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ud+KgZ8+Saz365olM23VjeQvER7fPbOHU/DdkbTms5Q=; b=ktOEqOirUIJMAsCNHH5wzyCrnpaDZlmSrYsX9bMXAenEixm/ykLApxd8 /KPa6NFvZZk9hnOz2SzyAipwf+ukWxJshEb4+mwqFBlPVXMRIofY1669x oWZ1yzdvSkfgWFAXa8EPLBukVHypUNiPvoJE5P/MuKM6UR9QAWcuMb8cI Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmAFAKKIlVStJA2K/2dsb2JhbABbgwaBKsQJhweBDgKBERYBAQEBAX2EDAEBAQMBHVwFCwIBCA4KLjIlAgQOBYgkCNAuAQEBAQEBAQEBAQEBAQEBAQEBARmPPzMHgxaBEwEEjg+IcpFKIoNub4JDAQEB
X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="381575156"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 20 Dec 2014 14:38:40 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBKEcd87004603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Dec 2014 14:38:39 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 08:38:39 -0600
From: "Pascal Thubert (pthubert)" 
To: Carsten Bormann 
Thread-Topic: [Roll] call for consensus for the RPL RPI / RH3 compression
Thread-Index: AQHQG9a1OTT/hQZ1Sli00GcxCDRZVZyYjZsD
Date: Sat, 20 Dec 2014 14:38:38 +0000
Message-ID: <669D8C1D-2FBF-4E42-9002-92D3C1550C73@cisco.com>
References:  <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org>  <54942758.6090705@innovationslab.net>  <549440F0.8040407@innovationslab.net>, <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org>
In-Reply-To: <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/0flngsSm8VHnUkneFuK17V1aQ3w
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , Routing Over Low power and Lossy networks , "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Dec 2014 14:38:42 -0000

Same here,

The only case for which implementation would teach us something is the effi=
cient NHC proposal; but considering that we now have the routing header pro=
posal I doubt that any NHC will ever be implemented...

Cheers,

Pascal

> Le 19 d=E9c. 2014 =E0 22:57, Carsten Bormann  a =E9crit :
>=20
>> On 19 Dec 2014, at 16:14, Brian Haberman  wrot=
e:
>>=20
>> 1. There have been several proposals put forth
>>=20
>> 2. Issues have been raised on each one
>>=20
>> So, it seems prudent (to me) to look at each of the alternatives and
>> determine which warts everyone concerned is willing to live with.
>> Running code is a good way to do that.
>=20
> I agree with Xavi here: This is a good way to gather data for implementat=
ion issues (such as the implementation complexity of the =93efficient=94 va=
riant of the NHC approach).  It is not so good for architectural issues (fl=
ow label) or housekeeping issues (code point usage of the =93greedy=94 vari=
ant; code point re-use in the revised MH proposal).  We should have an agre=
ement on the latter ones before going into a plugfest.
>=20
> Gr=FC=DFe, Carsten
>=20


From nobody Tue Dec 23 00:52:46 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FFC1ACDA6 for ; Tue, 23 Dec 2014 00:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 J2gwEyAzspx8 for ; Tue, 23 Dec 2014 00:52:40 -0800 (PST)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D661ACDA8 for ; Tue, 23 Dec 2014 00:52:39 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud6.xs4all.net with ESMTP id WwsX1p00R4VN29601wsXRD; Tue, 23 Dec 2014 09:52:34 +0100
Received: from [2001:983:a264:1:c11c:e2db:8463:91a9] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 23 Dec 2014 09:52:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Dec 2014 09:52:31 +0100
From: peter van der Stok 
To: "Joel M. Halpern" , roll@ietf.org
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <5498334B.5010205@joelhalpern.com>
References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com>
Message-ID: <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl>
X-Sender: stokcons@xs4all.nl (JsxvhfXzGNBa6CmeHXCVt182bbYfbVcO)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/_5IZ-lwf15vSJ7EFy6kLIeKjuX0
Subject: Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 08:52:43 -0000

Hi Joel,

There has been a lot of discussion on the roll mailing list of what 
administratively configured means.
A message on the roll mailing list from Michael Richardson summarizes a 
meeting we had on the subject, and probably cuts to the core of your 
argument as well.
See:
http://www.ietf.org/mail-archive/web/roll/current/msg08335.html

In particular:

The origin of the second mis-understanding was that the text in
multicast-scopes (and rfc 4291) says:

          Admin-Local scope is the smallest scope that must be
          administratively configured, i.e., not automatically derived

The understanding of "administratively configured" for many people
implies truck rolls, or ssh logins or router CLI commands.  It was
only when this assumption was clearly articulated that the origin of the
conflict became clear to all parties.

The new understanding is that "administratively configured" is not
limited to the things that a human did it, but rather includes any
processes or operations that a human (including an IETF document) might
cause.   The intent of multicast-scopes is not to limit ways that
scopes 4+ can be determined, but to clarify that scopes <=3 are *not*
intended to be defined by a physical (or physical-like) topologies.


Does this indeed address your issue?
And, do you want me to site the explanation of administratively 
configured in the draft?
accompanied by text that the proposed policy is a default policy.

Greetings,

Peter

Joel M. Halpern schreef op 2014-12-22 16:05:
> There are two issues intertwined here.
> First, the spec you point to says that the behavior shall be
> administratively configured.  So we need to recognize the conflict
> between that assertion and the effort to define an automated policy.
> What I had thought on my previous reading was that you were resolving
> the conflict by having a small number of knobs which guided an
> automated behavior.
> 
> If I am reading your comments properly, what you are doing is defining
> a default policy, without any administrative configuration.  If so,
> you need to do two things:
> 
> 1) You need to identify that you are violating the underlying RFC in
> order to simplify operations.  At that point, it would be up to the
> community to decide if that is acceptable.  I would expect such a
> decision to be clearly identified in the last call.
> 
> 2) You need to describe the policy you want to implement as the default 
> policy.
> 
> With regard to item 2, the policy in the document or the policy you
> propose here are both defensible.  The question would be what policy
> the working group wants to enforce.
> 
> Yours,
> Joel
> 
> On 12/22/14 2:21 AM, peter van der Stok wrote:
>> 
>> Hi Joel,
>> 
>> Thanks for pointing this out.
>> After some thought, the best solution seems to embed the MPL admin 
>> local
>> scope within the zone concept.
>> I propose the following addition:
>> 
>> MPL4 messages remain bounded within a zone. Consequently, MPL4 
>> messages
>> cannot be routed between interfaces belonging to different zones.
>> For example, consider a router with 5 interfaces where interfaces A 
>> and
>> B beloing to zone 1 and interfaces C,D, and E belong to zone 2.
>> Mpl4 messages can be routed freely between interfaces A and B, and
>> freely between C,D, and E. However, a MPL4 message MUST NOT be routed
>> from Interface A to interface D.
>> 
>> When the concept of zone is unknown or disabled in a router, all
>> interfaces belong to the same zone.
>> 
>> This means adding the zone concept to rules of section 4.2, and text 
>> to
>> relate zone better to MPL4 zone.
>> 
>> Does this address your issue?
>> 
>> If yes, I will make a new draft along these lines beginning January 
>> 2015.
>> 
>> Greetings,
>> 
>> Peter
>> 
>> roll issue tracker schreef op 2014-12-16 00:19:
>>> #167: Not match the requirement for administrative configuration of
>>> the admin-
>>> local scope
>>> 
>>>  From: Joel M. Halpern 
>>>  Date: 2014-12-16 0:59 GMT+02:00
>>> 
>>>  Major issues:
>>>      There seems to be a disconnect between the notion of
>>> administratively
>>>  configured and the behavior described in this draft for admin-local
>>>  multicast scope.  As far as I can tell, the forwarding behavior
>>> described
>>>  here has no mechanism for administratively configuring the
>>> administrative
>>>  boundary.  The only knob that is used is PROACTIVE_FORWARDING, which 
>>> is
>>>  used for intra-realm multicast forwarding.  Thus, if you have a roll
>>>  multicast router with two interfaces in one realm and two interfaces 
>>> in
>>>  another realm, in order to provide realm multicast services for each
>>>  realm, this router according to this draft will always forward
>>> admin-local
>>>  multicast messages between the two realms.  That does not seem to me 
>>> to
>>>  match the requirement for administrative configuration of the
>>> admin-local
>>>  scope


From nobody Tue Dec 23 08:19:24 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C951A9106 for ; Tue, 23 Dec 2014 08:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 nxtq_T826ALG for ; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43B91A1A00 for ; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 907161BC1A7F; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-121.clppva.east.verizon.net [70.106.135.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 738391BC1A65; Tue, 23 Dec 2014 08:19:20 -0800 (PST)
Message-ID: <54999605.1010402@joelhalpern.com>
Date: Tue, 23 Dec 2014 11:19:17 -0500
From: "Joel M. Halpern" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: consultancy@vanderstok.org, roll@ietf.org
References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com> <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl>
In-Reply-To: <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2CCNYmbJJzXhggyhzUI-UTHWIaw
Subject: Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 16:19:24 -0000

Looking at that quote, I can not see how a behavior that the device 
exhibits without any human intervention can possibly be 
"administratively configured, i.e., not automatically derived" since 
what you are defining is an automatic derivation process.

I Suppose if you had a knob with two settings, one of which was 
"admin-local <== realm" and one of which was "admin-local <== this 
procedure" you would meet the minimum requirement of the text you quote. 
  That at least would have a human cause something.  In the document as 
written, I do not see a human agent.

Yours,
Joel

On 12/23/14 3:52 AM, peter van der Stok wrote:
> Hi Joel,
>
> There has been a lot of discussion on the roll mailing list of what
> administratively configured means.
> A message on the roll mailing list from Michael Richardson summarizes a
> meeting we had on the subject, and probably cuts to the core of your
> argument as well.
> See:
> http://www.ietf.org/mail-archive/web/roll/current/msg08335.html
>
> In particular:
> 
> The origin of the second mis-understanding was that the text in
> multicast-scopes (and rfc 4291) says:
>
>           Admin-Local scope is the smallest scope that must be
>           administratively configured, i.e., not automatically derived
>
> The understanding of "administratively configured" for many people
> implies truck rolls, or ssh logins or router CLI commands.  It was
> only when this assumption was clearly articulated that the origin of the
> conflict became clear to all parties.
>
> The new understanding is that "administratively configured" is not
> limited to the things that a human did it, but rather includes any
> processes or operations that a human (including an IETF document) might
> cause.   The intent of multicast-scopes is not to limit ways that
> scopes 4+ can be determined, but to clarify that scopes <=3 are *not*
> intended to be defined by a physical (or physical-like) topologies.
> 
>
> Does this indeed address your issue?
> And, do you want me to site the explanation of administratively
> configured in the draft?
> accompanied by text that the proposed policy is a default policy.
>
> Greetings,
>
> Peter
>
> Joel M. Halpern schreef op 2014-12-22 16:05:
>> There are two issues intertwined here.
>> First, the spec you point to says that the behavior shall be
>> administratively configured.  So we need to recognize the conflict
>> between that assertion and the effort to define an automated policy.
>> What I had thought on my previous reading was that you were resolving
>> the conflict by having a small number of knobs which guided an
>> automated behavior.
>>
>> If I am reading your comments properly, what you are doing is defining
>> a default policy, without any administrative configuration.  If so,
>> you need to do two things:
>>
>> 1) You need to identify that you are violating the underlying RFC in
>> order to simplify operations.  At that point, it would be up to the
>> community to decide if that is acceptable.  I would expect such a
>> decision to be clearly identified in the last call.
>>
>> 2) You need to describe the policy you want to implement as the
>> default policy.
>>
>> With regard to item 2, the policy in the document or the policy you
>> propose here are both defensible.  The question would be what policy
>> the working group wants to enforce.
>>
>> Yours,
>> Joel
>>
>> On 12/22/14 2:21 AM, peter van der Stok wrote:
>>>
>>> Hi Joel,
>>>
>>> Thanks for pointing this out.
>>> After some thought, the best solution seems to embed the MPL admin local
>>> scope within the zone concept.
>>> I propose the following addition:
>>>
>>> MPL4 messages remain bounded within a zone. Consequently, MPL4 messages
>>> cannot be routed between interfaces belonging to different zones.
>>> For example, consider a router with 5 interfaces where interfaces A and
>>> B beloing to zone 1 and interfaces C,D, and E belong to zone 2.
>>> Mpl4 messages can be routed freely between interfaces A and B, and
>>> freely between C,D, and E. However, a MPL4 message MUST NOT be routed
>>> from Interface A to interface D.
>>>
>>> When the concept of zone is unknown or disabled in a router, all
>>> interfaces belong to the same zone.
>>>
>>> This means adding the zone concept to rules of section 4.2, and text to
>>> relate zone better to MPL4 zone.
>>>
>>> Does this address your issue?
>>>
>>> If yes, I will make a new draft along these lines beginning January
>>> 2015.
>>>
>>> Greetings,
>>>
>>> Peter
>>>
>>> roll issue tracker schreef op 2014-12-16 00:19:
>>>> #167: Not match the requirement for administrative configuration of
>>>> the admin-
>>>> local scope
>>>>
>>>>  From: Joel M. Halpern 
>>>>  Date: 2014-12-16 0:59 GMT+02:00
>>>>
>>>>  Major issues:
>>>>      There seems to be a disconnect between the notion of
>>>> administratively
>>>>  configured and the behavior described in this draft for admin-local
>>>>  multicast scope.  As far as I can tell, the forwarding behavior
>>>> described
>>>>  here has no mechanism for administratively configuring the
>>>> administrative
>>>>  boundary.  The only knob that is used is PROACTIVE_FORWARDING,
>>>> which is
>>>>  used for intra-realm multicast forwarding.  Thus, if you have a roll
>>>>  multicast router with two interfaces in one realm and two
>>>> interfaces in
>>>>  another realm, in order to provide realm multicast services for each
>>>>  realm, this router according to this draft will always forward
>>>> admin-local
>>>>  multicast messages between the two realms.  That does not seem to
>>>> me to
>>>>  match the requirement for administrative configuration of the
>>>> admin-local
>>>>  scope


From nobody Wed Dec 24 00:09:47 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2571ACD64; Wed, 24 Dec 2014 00:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 L7PeBwNlCQcv; Wed, 24 Dec 2014 00:09:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEA21ACD95; Wed, 24 Dec 2014 00:09:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: DraftTracker Mail System 
To: iesg@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141224080927.21137.44563.idtracker@ietfa.amsl.com>
Date: Wed, 24 Dec 2014 00:09:27 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/1TeZfKkMc29-EEX0b8UFDHLN18w
Cc: iesg-secretary@ietf.org
Subject: [Roll] Last Call Expired: 
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Dec 2014 08:09:31 -0000

Please DO NOT reply to this email.

I-D: 
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/

IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.


From nobody Sun Dec 28 01:08:11 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03581ACEDB for ; Sun, 28 Dec 2014 01:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 e1GzrBkiV8TW for ; Sun, 28 Dec 2014 01:08:05 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EB81A0233 for ; Sun, 28 Dec 2014 01:08:03 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBS9813m019101; Sun, 28 Dec 2014 09:08:01 GMT
Received: from 950129200 (089144210161.atnat0019.highway.a1.net [89.144.210.161]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBS980i4019071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2014 09:08:01 GMT
From: "Adrian Farrel" 
To: "'Joel M. Halpern'" , , 
References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com> <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl> <54999605.1010402@joelhalpern.com>
In-Reply-To: <54999605.1010402@joelhalpern.com>
Date: Sun, 28 Dec 2014 09:08:03 -0000
Message-ID: <013101d0227d$c9f04ed0$5dd0ec70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJI/7OLDlTF41nk7gcK/y72upR0VgHjCxusAVIxm4ABboW6G5uN2z+g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21206.006
X-TM-AS-Result: No--23.816-10.0-31-10
X-imss-scan-details: No--23.816-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtHoSitJVour/QPZZctd3P4B1KoSW5Ji1XtMOjKUxCZwr4Ya XGWS53EtzCcwoePov91vm+yDr9EXkt5ZY75Y7Tbeww5lzZPqy6UQtuqs6BbPJ2vCgbU1auyVvL4 BuAuBsSkvp8M1kuFRq8TpSUFbWSmY7bzFTf/STMpbuDP8ZuCmXjQAp53S718Hv+26ZYWzwkJ5L2 Bpc0g4FU1i8No7236cXEGAbuaD8OXsrfmvTLX/nq73FVUimLHPhA0VjIpLz69PtLhlThdPEIN2p Mn0FcvGIHvHLq6y9SYh2g+vUv+I1Xsk5ijHlPQNXhKwXj03jsBFwwTiVVDSS9hxLDhMiTYXROXa pu6XX6SBjqMA8l05bjeT288mssTUE2ZRbV2rc3Epa6LJktEjgAuK1hIitSIHW+jwVKpqvlLFSSE Uw76he9fL1aQHfEsz+6bI4L940xwyZi98qxHMyPKUR83BvqIteJ1OirYwzAP0Sl72zvn8E8HQPY 9gF7ZMDBD37DJ+PFi3DO15nGjZ07rCfWg2KQ28lTsGW3DmpUt5y+Nu7/EOOkiO8DX9hL7Rvb4+3 z1qe64jxAElV3kh9pPwtSeaJxgGQrA7SYdNSRP0hv/rD7WVZNFqG4/BpDVaGfvHtnLRItvbBBOH LZEaSCuPUjbSJUmas3m4RuLBjYg31PP76HdjIQhWgIsZuXlPEtdrY/Wb3fMNht78/JfyBDIKIy6 kcPuwfwPEe5pI6+mPdResNmQLt1GGCYEVy9x6oxWB033D5MJHRJfU7CVkWuML255sueyGsxEmql 4PhxxpkXmrE6Fyz9ycg6BlL+PIol3YK5SmaeeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0=
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/9HR7uRgbzxU13TBay1cts8nujuc
Subject: Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Dec 2014 09:08:08 -0000

To reduce this to the most trivial (and put it in IPv4 terms)...
Is the configuration of 127.0.0.1 "administratively configured" as the loopback
address?
Clearly no human intervention is needed to make it happen, yet there is no
"process" that is run.

I think the 4291 quote is not very helpful since it defines "administratively
configured" as "not automatically derived." In particular, an NMS might be
unsupervised and include software that issues addresses as if it were a human
making configuration choices. That is clearly "automatic" yet still qualifies as
"administratively configured" in my mind.

This document is trying to use a different definition of "administratively
configured" as Peter has stated. I don't believe this has to be derived from
4291, but perhaps it should be clearly stated in this document as he has
offered.

Peter/authors: you have some minor edits to do, and perhaps you can work up a
clear definition and include it early in the document with a statement like "In
this document, the term administratively configured is used to mean..."

Cheers,
Adrian

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: 23 December 2014 16:19
> To: consultancy@vanderstok.org; roll@ietf.org
> Cc: Adrian Farrel
> Subject: Re: Fwd: Re: [roll] #167 (admin-local-policy): Not match the
requirement
> for administrative configuration of the admin-local scope
> 
> Looking at that quote, I can not see how a behavior that the device
> exhibits without any human intervention can possibly be
> "administratively configured, i.e., not automatically derived" since
> what you are defining is an automatic derivation process.
> 
> I Suppose if you had a knob with two settings, one of which was
> "admin-local <== realm" and one of which was "admin-local <== this
> procedure" you would meet the minimum requirement of the text you quote.
>   That at least would have a human cause something.  In the document as
> written, I do not see a human agent.
> 
> Yours,
> Joel
> 
> On 12/23/14 3:52 AM, peter van der Stok wrote:
> > Hi Joel,
> >
> > There has been a lot of discussion on the roll mailing list of what
> > administratively configured means.
> > A message on the roll mailing list from Michael Richardson summarizes a
> > meeting we had on the subject, and probably cuts to the core of your
> > argument as well.
> > See:
> > http://www.ietf.org/mail-archive/web/roll/current/msg08335.html
> >
> > In particular:
> > 
> > The origin of the second mis-understanding was that the text in
> > multicast-scopes (and rfc 4291) says:
> >
> >           Admin-Local scope is the smallest scope that must be
> >           administratively configured, i.e., not automatically derived
> >
> > The understanding of "administratively configured" for many people
> > implies truck rolls, or ssh logins or router CLI commands.  It was
> > only when this assumption was clearly articulated that the origin of the
> > conflict became clear to all parties.
> >
> > The new understanding is that "administratively configured" is not
> > limited to the things that a human did it, but rather includes any
> > processes or operations that a human (including an IETF document) might
> > cause.   The intent of multicast-scopes is not to limit ways that
> > scopes 4+ can be determined, but to clarify that scopes <=3 are *not*
> > intended to be defined by a physical (or physical-like) topologies.
> > 
> >
> > Does this indeed address your issue?
> > And, do you want me to site the explanation of administratively
> > configured in the draft?
> > accompanied by text that the proposed policy is a default policy.
> >
> > Greetings,
> >
> > Peter
> >
> > Joel M. Halpern schreef op 2014-12-22 16:05:
> >> There are two issues intertwined here.
> >> First, the spec you point to says that the behavior shall be
> >> administratively configured.  So we need to recognize the conflict
> >> between that assertion and the effort to define an automated policy.
> >> What I had thought on my previous reading was that you were resolving
> >> the conflict by having a small number of knobs which guided an
> >> automated behavior.
> >>
> >> If I am reading your comments properly, what you are doing is defining
> >> a default policy, without any administrative configuration.  If so,
> >> you need to do two things:
> >>
> >> 1) You need to identify that you are violating the underlying RFC in
> >> order to simplify operations.  At that point, it would be up to the
> >> community to decide if that is acceptable.  I would expect such a
> >> decision to be clearly identified in the last call.
> >>
> >> 2) You need to describe the policy you want to implement as the
> >> default policy.
> >>
> >> With regard to item 2, the policy in the document or the policy you
> >> propose here are both defensible.  The question would be what policy
> >> the working group wants to enforce.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 12/22/14 2:21 AM, peter van der Stok wrote:
> >>>
> >>> Hi Joel,
> >>>
> >>> Thanks for pointing this out.
> >>> After some thought, the best solution seems to embed the MPL admin local
> >>> scope within the zone concept.
> >>> I propose the following addition:
> >>>
> >>> MPL4 messages remain bounded within a zone. Consequently, MPL4
> messages
> >>> cannot be routed between interfaces belonging to different zones.
> >>> For example, consider a router with 5 interfaces where interfaces A and
> >>> B beloing to zone 1 and interfaces C,D, and E belong to zone 2.
> >>> Mpl4 messages can be routed freely between interfaces A and B, and
> >>> freely between C,D, and E. However, a MPL4 message MUST NOT be routed
> >>> from Interface A to interface D.
> >>>
> >>> When the concept of zone is unknown or disabled in a router, all
> >>> interfaces belong to the same zone.
> >>>
> >>> This means adding the zone concept to rules of section 4.2, and text to
> >>> relate zone better to MPL4 zone.
> >>>
> >>> Does this address your issue?
> >>>
> >>> If yes, I will make a new draft along these lines beginning January
> >>> 2015.
> >>>
> >>> Greetings,
> >>>
> >>> Peter
> >>>
> >>> roll issue tracker schreef op 2014-12-16 00:19:
> >>>> #167: Not match the requirement for administrative configuration of
> >>>> the admin-
> >>>> local scope
> >>>>
> >>>>  From: Joel M. Halpern 
> >>>>  Date: 2014-12-16 0:59 GMT+02:00
> >>>>
> >>>>  Major issues:
> >>>>      There seems to be a disconnect between the notion of
> >>>> administratively
> >>>>  configured and the behavior described in this draft for admin-local
> >>>>  multicast scope.  As far as I can tell, the forwarding behavior
> >>>> described
> >>>>  here has no mechanism for administratively configuring the
> >>>> administrative
> >>>>  boundary.  The only knob that is used is PROACTIVE_FORWARDING,
> >>>> which is
> >>>>  used for intra-realm multicast forwarding.  Thus, if you have a roll
> >>>>  multicast router with two interfaces in one realm and two
> >>>> interfaces in
> >>>>  another realm, in order to provide realm multicast services for each
> >>>>  realm, this router according to this draft will always forward
> >>>> admin-local
> >>>>  multicast messages between the two realms.  That does not seem to
> >>>> me to
> >>>>  match the requirement for administrative configuration of the
> >>>> admin-local
> >>>>  scope


From nobody Sun Dec 28 01:09:25 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED27F1ACEE6 for ; Sun, 28 Dec 2014 01:09:21 -0800 (PST)
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 rN9KrUTsNGqp; Sun, 28 Dec 2014 01:09:20 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F941ACEDB; Sun, 28 Dec 2014 01:09:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141228090917.32449.15379.idtracker@ietfa.amsl.com>
Date: Sun, 28 Dec 2014 01:09:17 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/R9ZLL5pGABoNXXfh1gdk9haW7ac
Subject: [Roll] ID Tracker State Update Notice: 
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Dec 2014 09:09:22 -0000

IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/


From nobody Wed Dec 31 11:43:38 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE531A1A39 for ; Wed, 31 Dec 2014 11:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.5
X-Spam-Level: 
X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 lysMYbW94hlD for ; Wed, 31 Dec 2014 11:43:35 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B761A1A32 for ; Wed, 31 Dec 2014 11:43:35 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBVJhWLW006910 for ; Wed, 31 Dec 2014 19:43:32 GMT
Received: from 950129200 (089144195071.atnat0004.highway.a1.net [89.144.195.71]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBVJhVa9006904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2014 19:43:32 GMT
From: "Adrian Farrel" 
To: 
Date: Wed, 31 Dec 2014 19:43:30 -0000
Message-ID: <008901d02532$0f196760$2d4c3620$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdAlMD93Kj7eRSc6SMWPsD5QaVRNdQ==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21214.002
X-TM-AS-Result: No--4.013-10.0-31-10
X-imss-scan-details: No--4.013-10.0-31-10
X-TMASE-MatchedRID: PpPKM1mRYk+4EooHfudG2oDqq/69HfgsR0SX1OwlZFpiZCTkFQiKcD6l 3VPPG5Ga/1MonfGaXN+YEbuXS5luVQzyMxeMEX6wOX/V8P8ail3Yr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDXMt0UeqHawsO2WT+9CjczJXROBvEtA7CitHgh/kzLs2gyucSfejV6hNhaOBHxzal2OTC SnRTeg+iPVIUGLlI4nRt01ZrBZr35mO3qi78sNJA==
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Dx8Fys_FTDEtxLU8zhZmGaHVyl8
Subject: [Roll] Two IETF last calls of interest to you
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Dec 2014 19:43:37 -0000

Hi,

Please be aware that of two IETF last calls running until 14th January.
Send any comments to the main IETF list.

- 'Management of Networks with Constrained Devices: Problem Statement and
   Requirements'
   as Informational RFC

- 'Management of Networks with Constrained Devices: Use Cases'
   as Informational RFC

Regards,
Adrian



From nobody Wed Dec 31 11:58:21 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54921A1A6E; Wed, 31 Dec 2014 11:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level: 
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, 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 MN28R8vDGFWw; Wed, 31 Dec 2014 11:58:16 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4521A1A5E; Wed, 31 Dec 2014 11:58:15 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E4C120012; Wed, 31 Dec 2014 15:03:13 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 9B21A637FE; Wed, 31 Dec 2014 14:58:14 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 87D26637F4; Wed, 31 Dec 2014 14:58:14 -0500 (EST)
From: Michael Richardson 
To: Routing Over Low power and Lossy networks 
In-Reply-To: <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org>
References:  <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org>  <54942758.6090705@innovationslab.net>  <549440F0.8040407@innovationslab.net> <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-32YVtRxvqB5gp1gWSD_DbfV0gc
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>
Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Dec 2014 19:58:18 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


someone wrote;
    >> So, it seems prudent (to me) to look at each of the alternatives and
    >> determine which warts everyone concerned is willing to live with.
    >> Running code is a good way to do that.

Carsten Bormann  wrote:
    > I agree with Xavi here: This is a good way to gather data for
    > implementation issues (such as the implementation complexity of the
    > =E2=80=9Cefficient=E2=80=9D variant of the NHC approach).  It is not =
so good

so, I think that we have consensus that this can not be left to the plugfes=
t.
A number of people have not replied; some ADs and some WG chairs.
(I realize that Gabriel Montenegro is new in this position; maybe he can
bring a fresh viewpoint?)

I am going to put up a doodle poll for the week of Jan. 12.
My goal is not to need it, that we will have a plan for the Jan 9, 6tisch
call.  Please: how do we proceed?

=2D-
Michael Richardson , Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVKRVVoCLcPvd0N1lAQJccAf9FdD/JrmF56fMShkhYj83IvNHxxn1kj+K
vyhnDCDj9ZoLZFt/0aLZ64uZnDbD2GQAz5aoBJW05+50AfCOIjbfF4iCr7qQpAJN
O4znzYyFbzDJ6icZ7HJ90KTBDw5a5Fu9LuUs9CKQKxmrimlCdPjAfc5ThvmjzxbI
rEA25Z+i4ufYySPtdjc4vT9n3JBZ5/IIZEfjEoZDsqFwdSeBr5/OsCyex3Hl+1ZA
VdlXPQcORLKBInxfjSuZaXp7Qa8I7QR0Xr2X4CITdqVGbHe+ETuRpo4KV9PpiUql
DnJhUH192rKEI+9kcY8Oo/QPQYkDmXGMyajrha/SZuTgbwp73OSYbA==
=9eue
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Dec 31 15:46:15 2014
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6351A1A54 for ; Wed, 31 Dec 2014 15:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 HD5lh40nd56v for ; Wed, 31 Dec 2014 15:46:12 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A910D1A1A4A for ; Wed, 31 Dec 2014 15:46:11 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBVNk9fp023941 for ; Wed, 31 Dec 2014 23:46:09 GMT
Received: from 950129200 (089144195094.atnat0004.highway.a1.net [89.144.195.94]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBVNjxmg023912 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2014 23:46:07 GMT
From: "Adrian Farrel" 
To: 
Date: Wed, 31 Dec 2014 23:45:57 -0000
Message-ID: <000001d02553$f2c9d050$d85d70f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdAlMD93Kj7eRSc6SMWPsD5QaVRNdQ==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21214.003
X-TM-AS-Result: No--4.013-10.0-31-10
X-imss-scan-details: No--4.013-10.0-31-10
X-TMASE-MatchedRID: PpPKM1mRYk+4EooHfudG2oDqq/69HfgsR0SX1OwlZFpiZCTkFQiKcD6l 3VPPG5Ga/1MonfGaXN+YEbuXS5luVQzyMxeMEX6wOX/V8P8ail3Yr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDXMt0UeqHawsO2WT+9CjczJXROBvEtA7CitHgh/kzLs2gyucSfejV6hNhaOBHxzal2OTC SnRTeg+iPVIUGLlI4nRt01ZrBZr35mO3qi78sNJA==
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/YpK-_ORUXN5PcU9kAIqJqqimzYc
Subject: [Roll] Two IETF last calls of interest to you
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Dec 2014 23:46:14 -0000

Hi,

Please be aware that of two IETF last calls running until 14th January.
Send any comments to the main IETF list.

- 'Management of Networks with Constrained Devices: Problem Statement and
   Requirements'
   as Informational RFC

- 'Management of Networks with Constrained Devices: Use Cases'
   as Informational RFC

Regards,
Adrian