From nobody Mon Aug 1 13:48:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9CD12D0BF for ; Mon, 1 Aug 2016 13:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0vHb3bvuvFe for ; Mon, 1 Aug 2016 13:48:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0096.outbound.protection.outlook.com [104.47.0.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A42712D86D for ; Mon, 1 Aug 2016 13:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2ZMth0ogDECdCPUbQRsV70W1P6WB73i2DlNDAcNi81M=; b=T34BvI2HBjy4Y43rFlOhwRa3RZzqXxrYMBZ+c8ZhKjEacL0g2DImkyQ8FZ1xaITcRWwZLT7a3xpda+oJBm/DucBnEvYIhiBHD4s7OrWWIj7h7acuSLW/cw3nbFWx3nAIwWq7PuO5dlGIt9N9m3mBOdzXQ4+P4GV7qHPbWW7pNAo= Received: from HE1PR0601MB2203.eurprd06.prod.outlook.com (10.168.35.138) by HE1PR0601MB2201.eurprd06.prod.outlook.com (10.168.35.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 20:48:26 +0000 Received: from HE1PR0601MB2203.eurprd06.prod.outlook.com ([10.168.35.138]) by HE1PR0601MB2203.eurprd06.prod.outlook.com ([10.168.35.138]) with mapi id 15.01.0549.022; Mon, 1 Aug 2016 20:48:26 +0000 From: Somaraju Abhinav To: Michel Veillette , Andy Bierman Thread-Topic: [core] fixing YANG to CBOR Thread-Index: AQHR4+cHFCK5X3iKN0+hcBBpZTkg1KApIRsAgAAW5YCAAAVwAIAAF4YAgAAuXwCAAAKHgIAAFY2AgAABCYCAAAkKAIAAa+kAgAADEICACo/WUw== Date: Mon, 1 Aug 2016 20:48:25 +0000 Message-ID: References: <6DEC3424-1E9F-4B2C-9343-74501ED22ADA@nic.cz>, , <1B22215B-653D-46FA-A8E8-2437DA454AA5@trilliantinc.com> In-Reply-To: <1B22215B-653D-46FA-A8E8-2437DA454AA5@trilliantinc.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=abhinav.somaraju@tridonic.com; x-originating-ip: [89.144.225.161] x-ms-office365-filtering-correlation-id: 5be85abf-6311-4cac-c9fc-08d3ba4d2f8d x-microsoft-exchange-diagnostics: 1; HE1PR0601MB2201; 6:14TJGSg6S6idEJKfL86NwKS9CKMQXH2FRrCr3XSWPeRbDq1fHEIXhwBT6m/EMiHW/LDNa/vIj6FNTsJPUKZnd4j/U8RTseSTucW7j/B2NQZSHlqKukEEpAzrchFzyPuus6FU7Q69CW8ZAKyzMic+cu4N3TmijPkfKJydQjrUmlYRWjmMUNMVclC6nSl07hVu6KjnJcILlsmIPiwOfZ1LDgDRtdvN5O8jsy5tVcBb5Z9WSmJcLIXt7Xc++Fod8w1MHfaDrAkr7NSVtUKZ4W/S44fTsXOBiviDQdLjYi8JCttrcCrQJqqD73VnyxEBw3m4mJiSVArqUz3KTLpxg/2Ezw==; 5:j3bhg8OljNfsPXRYUIogMAeAzB/K/oiwHOlm+Fdw33jS1q4v34UI3uArk9Zl7kqJq93UgJjRtNjNE1VkhI1ErQVfcL/72egsi0Am7dlgCxT9nydUiGdOXQDglDEsyFt+Crei36RmbFBWfh3pM1KYlw==; 24:4WtYrRXXKm95mf8XdXnYoBBWsoJA70ZDbsYnkac943tcaP1y6mktSgEe7N7iWeqEl8QhwKGnxdw8UxMhMy3wEuT0YNUAFwJqusKCZaM+jTI=; 7:5gKo8buXKqzNcRTqb9SoNDD8JH2bHSUiOkhdEH3v8L/g7MSLTekGXL4APQE6FRDIsbBdpd/o6kRli0AYou2tQghZ4p2JbYwHS0bk5YApRSaEy3gG+EvMsLHPu/pd8GeTQpoTCgqnsYBGq5VfaiqMGJFKOVu5FbKA1HQC84kTGPDfcFAPY8SzIfhazShB7xuIJbhT9Xo/oR/34Cgeiq3vnhdXSRXr9mz379smzAKABTqetrOFYKhVYhMrl5BVlJAF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0601MB2201; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR0601MB2201; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0601MB2201; x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(13464003)(24454002)(377454003)(87936001)(3660700001)(5890100001)(102836003)(6116002)(3900700001)(9686002)(575784001)(86362001)(586003)(68736007)(74316002)(3280700002)(3846002)(7906003)(19580405001)(19580395003)(9886003)(93886004)(5002640100001)(7846002)(7696003)(7736002)(106116001)(76576001)(106356001)(101416001)(105586002)(66066001)(15975445007)(8936002)(4326007)(10400500002)(50986999)(76176999)(19617315012)(11100500001)(77096005)(81166006)(81156014)(8676002)(16236675004)(33656002)(2906002)(54356999)(122556002)(2900100001)(92566002)(97736004)(2950100001)(5001770100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0601MB2201; H:HE1PR0601MB2203.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: tridonic.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0601MB2203620043F3F647060A9650FC040HE1PR0601MB2203_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 20:48:25.9549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0601MB2201 Archived-At: Cc: Core Subject: Re: [core] fixing YANG to CBOR X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:48:34 -0000 --_000_HE1PR0601MB2203620043F3F647060A9650FC040HE1PR0601MB2203_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable +1 Sent from my Windows Phone ________________________________ From: Michel Veillette Sent: =FD26/=FD07/=FD2016 05:31 To: Andy Bierman Cc: Core Subject: Re: [core] fixing YANG to CBOR +1 Le 25 juil. 2016 =E0 23:20, Andy Bierman > a =E9crit : Hi, I think this "union type" corner-case is not bad enough to justify a really complicated design like tracking the order of union type syntax changes. We need to remove order dependencies, not add new ones. I should have realized this is too complicated. So I think the current tagging solution is good enough. Do not change it to count and order the member type-stmts. I will write YANG guidelines in 6087bis to attempt to prevent these corner-cases from occurring in IETF modules. Andy On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lhotka > wrote: > On 25 Jul 2016, at 22:21, Andy Bierman > wrote: > > > > On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka > wrote: > > > On 25 Jul 2016, at 21:00, Andy Bierman > wrote: > > > > > > > > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka > wrote: > > > > > On 25 Jul 2016, at 18:05, Michel Veillette > wrote: > > > > > > Hi Lada, Hi Andy > > > > > > The important questions we need answer to validate the current soluti= on are the following. > > > > > > - In a union, is it valid to define multiple enumerations which reuse= the same value(s) with a different semantic meaning? > > > - In a union, is it valid to define multiple bits which reuse the sam= e position(s) with a different semantic meaning? > > > > IMO, yes, in both cases. I am not saying that it's a good design though= . > > > > > > > > In the following examples, value or position 0 means both white and r= ed which I believe it's invalid. > > > > I don't think so. The member types are checked in the same order as the= y appear in the union's definition, and the first type for which a given va= lue is valid is used. > > > > > > > > That's the issue here. > > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent. > > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string. YANG union was designed only t= o work > > robustly with XML. > > I believe for JSON it is perfectly robust. The general rule should be thi= s: use whatever information you have to determine whether the received valu= e is valid for the first member type. If not, try the second member etc. > > > believe what youi want: > > > type union { > type string; > type int32; > } > > JSON produces different results than XML. > > If client A sets number 42 in JSON, then client B will read back string "= 42" in XML. > If the XML client sets string "42", the JSON client will read back string= "42". > This is the exact same issue facing CBOR conversion In my view, most implementations will eventually use just one encoding, and= this problem won't exist for them. XML, JSON and CBOR in reality pass different information, it is not like UT= F-8 versus UTF-16. Restricting all alternative media types only to features= supported in XML doesn't make much sense. Lada > > > > Lada > > > Andy > > > > > > > > If this is the case, the currently proposed solution to tag some spec= ific datatype (bits, enumeration, identityref, instance-identifier) when u= sed in a union resolve any potential ambiguities. > > > > Yes, I think this is a good idea because otherwise resolving the member= types may be difficult. Moreover, sometimes the sending side might want to= override the resolution algorithm - e.g., if a client wants to set a leaf = with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather= than IP address. > > > > > Can we move ahead with the current solution? > > > > The current solution is just as good and just as broken as the JSON sol= ution, > > and we already moved ahead with that in NETMOD WG. (So I guess that mea= ns yes?) > > > > > > Andy > > > > > > > > ENUMERATION EXAMPLE > > > > > > typedef A { > > > type union { > > > type enumeration { > > > enum white { > > > value 0; > > > } > > > enum black { > > > value 1; > > > } > > > } > > > type enumeration { > > > enum red { > > > value 0; > > > } > > > enum green { > > > value 1; > > > } > > > enum blue { > > > value 2; > > > } > > > } > > > } > > > } > > > > Values 0 and 1 are interpreted as "white" and "black", value 2 is "blue= ". > > > > > > > > BITS EXAMPLE > > > > > > typedef B { > > > type union { > > > type bits { > > > bit white { > > > position 0; > > > } > > > bit black { > > > position 1; > > > } > > > } > > > type bits { > > > bit red { > > > position 0; > > > } > > > bit green { > > > position 1; > > > } > > > bit blue { > > > position 2; > > > } > > > } > > > } > > > } > > > > Ditto. > > > > Lada > > > > > > > > Regards, > > > Michel > > > > > > -----Original Message----- > > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Ladislav Lhotka > > > Sent: Monday, July 25, 2016 10:41 AM > > > To: Andy Bierman > > > > Cc: Core > > > > Subject: Re: [core] fixing YANG to CBOR > > > > > > > > >> On 25 Jul 2016, at 16:21, Andy Bierman > wrote: > > >> > > >> > > >> > > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka > wrote: > > >> Andy Bierman > writes: > > >> > > >>> Hi, > > >>> > > >>> It seems to me that the only tagging actually needed would be to > > >>> identify the ordered list of member types within a union type. > > >>> > > >>> > > >>> typedef A { > > >>> type union { > > >>> type int32 ; // 1 > > >>> type string; // 2 > > >>> type B; // 3, 4, 5 > > >>> type identityref { base bar; } // 6 > > >>> } > > >>> } > > >>> > > >>> > > >>> typedef B { > > >>> type union { > > >>> type uint8; > > >>> type uint16; > > >>> type uint32; > > >>> } > > >>> } > > >>> > > >>> leaf foo { type A; } > > >>> > > >>> YANG allows the member types to be reordered if it does not change > > >>> the value set accepted by the type. It is not clear > > >> > > >> I don't think this is true. The only statement in 6020bis that is > > >> related to this issue is the bullet that you cite below, but IMO > > >> reordering member types in a union type definition may change the ty= pe > > >> semantics because the receiving side resolves the type according to > > >> the order of member types. > > >> > > >> > > >> > > >> This depends on the format, but non-overlapping member types can > > >> change position without changing syntax or semantics. > > > > > > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapp= ing members: "1.2.3.4" is valid as both "inet:ip-address" and "inet:domain-= name". > > > > > > Lada > > > > > >> The exact member type that matches is not important. > > >> > > >> typedef foo1 { > > >> type union { > > >> type int32 { range "1..10"; } > > >> type int32 { range "11..20"; } > > >> } > > >> } > > >> > > >> typedef foo2 { > > >> type union { > > >> type int32 { range "11..20"; } > > >> type int32 { range "1..10"; } > > >> } > > >> } > > >> > > >> > > >> > > >> Lada > > >> > > >> Andy > > >> > > >> > > >>> if new member types can be added in new module revisions. > > >>> > > >>> If new member types are allowed in typedef B, then the relative > > >>> position of (6) can change, even if typedef A does not change. > > >>> YANG does not explicitly state if this is allowed or not. > > >>> > > >>> bits and enumerations can be expanded in new revisions, which > > >>> changes the value set, but existing value and position numbers are > > >>> not allowed to change. > > >>> > > >>> The problematic text is in 6020bis, sec 11 > > >>> > > >>> o A "type" statement may be replaced with another "type" statemen= t > > >>> that does not change the syntax or semantics of the type. For > > >>> example, an inline type definition may be replaced with a type= def, > > >>> but an int8 type cannot be replaced by an int16, since the syn= tax > > >>> would change. > > >>> > > >>> > > >>> > > >>> In practice reordering member types would be very rare, but the SID > > >>> numbering would need to remember the member type order for each lea= f > > >>> or leaf-list that resolves to a union type. > > >>> > > >>> It doesn't help to tag any other type besides union. > > >>> > > >>> > > >>> Andy > > >>> _______________________________________________ > > >>> core mailing list > > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/core > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_HE1PR0601MB2203620043F3F647060A9650FC040HE1PR0601MB2203_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
+1

Sent from my Windows Phone
From: Michel Veillette=
Sent: =FD26= /=FD07/=FD2016 05:31
To: Andy Bierman
Cc: Core
Subject: Re: [= core] fixing YANG to CBOR

+1

Le 25 juil. 2016 =E0 23:20, Andy Bierman <andy@yumaworks.com> a =E9crit :

Hi,

I think this "union type" corner-case is not bad enough to
justify a really complicated design like tracking the order
of union type syntax changes.  We need to remove order
dependencies, not add new ones.  I should have realized
this is too complicated.

So I think the current tagging solution is good enough.
Do not change it to count and order the member type-stmts.

I will write YANG guidelines in 6087bis to attempt to prevent these
corner-cases from occurring in IETF modules.


Andy


On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lhotka= <lhotka@nic.cz>= ; wrote:

> On 25 Jul 2016, at 22:21, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 25 Jul 2016, at 21:00, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 25 Jul 2016, at 18:05, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote:
> > >
> > > Hi Lada, Hi Andy
> > >
> > > The important questions we need answer to validate the curre= nt solution are the following.
> > >
> > > - In a union, is it valid to define multiple enumerations wh= ich reuse the same value(s) with a different semantic meaning?
> > > - In a union, is it valid to define multiple bits which reus= e the same position(s) with a different semantic meaning?
> >
> > IMO, yes, in both cases. I am not saying that it's a good design = though.
> >
> > >
> > > In the following examples, value or position 0 means both wh= ite and red which I believe it's invalid.
> >
> > I don't think so. The member types are checked in the same order = as they appear in the union's definition, and the first type for which a gi= ven value is valid is used.
> >
> >
> >
> > That's the issue here.
> > The member type value spaces are allowed to overlap each other. > > The "first wins" depends on the value being sent.
> > The same problem exists for JSON for boolean and numeric types. > > Only XML passes everything as a string.  YANG union was desi= gned only to work
> > robustly with XML.
>
> I believe for JSON it is perfectly robust. The general rule should be = this: use whatever information you have to determine whether the received v= alue is valid for the first member type. If not, try the second member etc.=
>
>
> believe what youi want:
>
>
>    type union {
>        type string;
>        type int32;
>    }
>
> JSON produces different results than XML.
>
> If client A sets number 42 in JSON, then client B will read back strin= g "42" in XML.
> If the XML client sets string "42", the JSON client will rea= d back string "42".
> This is the exact same issue facing CBOR conversion

In my view, most implementations will eventually use just one encoding, and= this problem won't exist for them.

XML, JSON and CBOR in reality pass different information, it is not like UT= F-8 versus UTF-16. Restricting all alternative media types only to features= supported in XML doesn't make much sense.

Lada

>
>
>
> Lada
>
>
> Andy
>
> >
> >
> > > If this is the case, the currently proposed solution to tag = some specific datatype (bits,  enumeration, identityref, instance-iden= tifier) when used in a union resolve any potential ambiguities.
> >
> > Yes, I think this is a good idea because otherwise resolving the = member types may be difficult. Moreover, sometimes the sending side might w= ant to override the resolution algorithm - e.g., if a client wants to set a= leaf with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather than IP address.
> >
> > > Can we move ahead with the current solution?
> >
> > The current solution is just as good and just as broken as the JS= ON solution,
> > and we already moved ahead with that in NETMOD WG. (So I guess th= at means yes?)
> >
> >
> > Andy
> >
> > >
> > > ENUMERATION EXAMPLE
> > >
> > > typedef A {
> > >  type union {
> > >    type enumeration {
> > >      enum white {
> > >        value 0;
> > >      }
> > >      enum black {
> > >        value 1;
> > >      }
> > >    }
> > >    type enumeration {
> > >      enum red {
> > >        value 0;
> > >      }
> > >      enum green {
> > >        value 1;
> > >      }
> > >      enum blue {
> > >        value 2;
> > >      }
> > >    }
> > >  }
> > > }
> >
> > Values 0 and 1 are interpreted as "white" and "bla= ck", value 2 is "blue".
> >
> > >
> > > BITS EXAMPLE
> > >
> > > typedef B {
> > >  type union {
> > >    type bits {
> > >      bit white {
> > >        position 0;
> > >      }
> > >      bit black {
> > >        position 1;
> > >      }
> > >    }
> > >    type bits {
> > >      bit red {
> > >        position 0;
> > >      }
> > >      bit green {
> > >        position 1;
> > >      }
> > >      bit blue {
> > >        position 2;
> > >      }
> > >    }
> > >  }
> > > }
> >
> > Ditto.
> >
> > Lada
> >
> > >
> > > Regards,
> > > Michel
> > >
> > > -----Original Message-----
> > > From: core [mailto:= core-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> > > Sent: Monday, July 25, 2016 10:41 AM
> > > To: Andy Bierman <a= ndy@yumaworks.com>
> > > Cc: Core <core@ietf.org<= /a>>
> > > Subject: Re: [core] fixing YANG to CBOR
> > >
> > >
> > >> On 25 Jul 2016, at 16:21, Andy Bierman <andy@yumaworks.com> wrote:
> > >>
> > >>
> > >>
> > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >> Andy Bierman <a= ndy@yumaworks.com> writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> It seems to me that the only tagging actually needed= would be to
> > >>> identify the ordered list of member types within a u= nion type.
> > >>>
> > >>>
> > >>> typedef A {
> > >>>  type union {
> > >>>    type int32 ;   // 1
> > >>>    type string; // 2
> > >>>    type B;   // 3, 4, 5
> > >>>    type identityref { base bar; }  &n= bsp;// 6
> > >>>  }
> > >>> }
> > >>>
> > >>>
> > >>> typedef B {
> > >>>  type union {
> > >>>    type uint8;
> > >>>    type uint16;
> > >>>    type uint32;
> > >>>  }
> > >>> }
> > >>>
> > >>> leaf foo { type A; }
> > >>>
> > >>> YANG allows the member types to be reordered if it d= oes not change
> > >>> the value set accepted by the type.  It is not = clear
> > >>
> > >> I don't think this is true. The only statement in 6020bi= s that is
> > >> related to this issue is the bullet that you cite below,= but IMO
> > >> reordering member types in a union type definition may c= hange the type
> > >> semantics because the receiving side resolves the type a= ccording to
> > >> the order of member types.
> > >>
> > >>
> > >>
> > >> This depends on the format, but non-overlapping member t= ypes can
> > >> change position without changing syntax or semantics. > > >
> > > Yes, but, for instance, the "inet:host" type in RF= C 6991 has overlapping members: "1.2.3.4" is valid as both "= inet:ip-address" and "inet:domain-name".
> > >
> > > Lada
> > >
> > >> The exact member type that matches is not important.
> > >>
> > >>   typedef foo1 {
> > >>      type union {
> > >>         type int32 { range &quo= t;1..10"; }
> > >>         type int32 { range &quo= t;11..20"; }
> > >>      }
> > >>    }
> > >>
> > >>  typedef foo2 {
> > >>      type union {
> > >>         type int32 { range &quo= t;11..20"; }
> > >>         type int32 { range &quo= t;1..10"; }
> > >>      }
> > >>    }
> > >>
> > >>
> > >>
> > >> Lada
> > >>
> > >> Andy
> > >>
> > >>
> > >>> if new member types can be added in new module revis= ions.
> > >>>
> > >>> If new member types are allowed in typedef B, then t= he relative
> > >>> position of (6) can change, even if typedef A does n= ot change.
> > >>> YANG does not explicitly state if this is allowed or= not.
> > >>>
> > >>> bits and enumerations can be expanded in new revisio= ns, which
> > >>> changes the value set, but existing value and positi= on numbers are
> > >>> not allowed to change.
> > >>>
> > >>> The problematic text is in 6020bis, sec 11
> > >>>
> > >>>  o  A "type" statement may be re= placed with another "type" statement
> > >>>      that does not change the syntax = or semantics of the type.  For
> > >>>      example, an inline type definiti= on may be replaced with a typedef,
> > >>>      but an int8 type cannot be repla= ced by an int16, since the syntax
> > >>>      would change.
> > >>>
> > >>>
> > >>>
> > >>> In practice reordering member types would be very ra= re, but the SID
> > >>> numbering would need to remember the member type ord= er for each leaf
> > >>> or leaf-list that resolves to a union type.
> > >>>
> > >>> It doesn't help to tag any other type besides union.=
> > >>>
> > >>>
> > >>> Andy
> > >>> _______________________________________________
> > >>> core mailing list
> > >>> core@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/core
> > >>
> > >> --
> > >> Ladislav Lhotka, CZ.NIC Labs
> > >> PGP Key ID: E74E8C0C
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https://www.ietf.org/mailman/listinfo/core
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_HE1PR0601MB2203620043F3F647060A9650FC040HE1PR0601MB2203_-- From nobody Tue Aug 2 15:00:56 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F012D8D9 for ; Tue, 2 Aug 2016 15:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZbxZNQYbV_B for ; Tue, 2 Aug 2016 15:00:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F0D12D663 for ; Tue, 2 Aug 2016 15:00:51 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 15:12:16 -0700 From: Jim Schaad To: , Date: Tue, 2 Aug 2016 15:00:40 -0700 Message-ID: <036801d1ed09$507ef080$f17cd180$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0369_01D1ECCE.A424D370" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdHsNDP6Rd+0VoZ9RbOcD9Mip82KVw== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Review of draft-hartke-core-e2e-security-reqs-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:00:54 -0000 ------=_NextPart_000_0369_01D1ECCE.A424D370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Before anything else, let me re-iterate what I said at the F2F meeting. This document is so much clearer and easier to read than was the -00 version that it does not even appear to be the same document. I want to really thank you for the work you did in re-writing it. That being said, I still do have some comments on draft that I would like to you consider. Jim 1. Note that the title of the COSE document has changed you should pick that up. 2. Section 2.1.1 - Should "client receives a response" include * (Threat ?) The proxy returns a stale or outdated response based on data it previously obtained from the origin server or some fourth party. I'm thinking of both out of date caches and poisoned caches. Note that these are valid from a security point of view, but not 'fresh' 3. Section 2.1.1.3 - based on a brief look at mattsson-core-coap-actuators, it appears to have some solutions to the Withholding attack as well as the Delaying attack. This should probably be noted. 4. Section 2.1.1.5 - It is not clear to me that there is a requirement that all messages be protected from eavesdropping. It might just be the way things are stated here, but there is a difference between the fact that the solution must provide a method to deal with this and the fact that integrity protection might be sufficient in some cases. This would also influence the analysis below in some cases. 5. Section 2.1.1.5 - You need to have a better statement of what it means to provide forward secrecy. This requirement would appear to potentially rule out the use of the same session content encryption key for multiple messages. I do not believe that is true, but given that we are looking a message based security some people might think this is the case. I would expand this statement to define the conditions under which PFS must be provided. 6. Section 2.1.2 - Do you consider a proxy re-ordering requests to be a threat? 7. Section 2.1.2.1 - Next to last para. I am not sure that 'involve' is the correct word in this sentence. Perhaps you meant 'include' 8. Section 3 - when I look at figure 10, I keep feeling that it is not a complete picture of what you need to be looking at Security Assn Security Assn +-----------------+ +---------------+ | | | | ____________ __________ ___________ | | | | | | | |----->| |<------| | | Subscriber | | Broker | | Publisher | | |<-----| |------>| | |____________| |__________| |___________| : : '--------------------------------------' Security Association There needs to be a discussion of all of the different potential security associations in this diagram. Some of these can be reduced to simple client-server associations, but some of the implications of this diagram are potentially used for the entirety of the picture. Examples of things that can be looked at: a) The broker is the one that will do enforcement of access control. If this is not true then all subscription requests would really need to be passed onto the publisher to ensure that the subscriber is to have access. And we now have new thread of the broker granting access to a subscription stream when it should not. b) The broker may validate that messages from the publisher are in fact from the publisher, but be unable to look at the content of the message. c) The broker may need to have some details of the SA between the subscriber and the publisher. For example, what happens if the key used to encrypt/protect the message gets updated or if the publisher is generating the same stream but using two different group keys. In the first, is this an issue for the client or for the broker. In the second case there are effectively two different streams with the same name that need to be identified by the broker and the correct responses sent to the client. These are examples of what I meant in the F2F when I said that you have a semi-trusted broker. It is trusted with information about the subscription stream and allowed to enforce it. But it is not allowed to have access to the actual content of the stream. 9. Threats in section 3 also include * out of order delivery of items. * Issues about a broker either granting or denying access to a stream. * Subscriber does not receive a response because the broker pre-maturely unsubscribes the subscriber ------=_NextPart_000_0369_01D1ECCE.A424D370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Before anything else, let me re-iterate what I said = at the F2F meeting.  This document is so much clearer and easier to = read than was the -00 version that it does not even appear to be the = same document.   I want to really thank you for the work you = did in re-writing it.

 

That = being said, I still do have some comments on draft that I would like to = you consider.

 

Jim

 

 

1.  Note that the title of the COSE document = has changed you should pick that up.

 

2. = Section 2.1.1 - Should "client receives a response" include =

    * (Threat = ?) The proxy returns a stale or outdated response based on data it = previously obtained from the origin server or some fourth = party.

        &nbs= p;      I'm thinking of both out of date caches = and poisoned caches.  Note that these are valid from a security = point of view, but not 'fresh'

 

3.  Section 2.1.1.3 - based on a brief look at = mattsson-core-coap-actuators, it appears to have some solutions to the = Withholding attack as well as the Delaying attack.  This should = probably be noted.

 

4.  Section 2.1.1.5 - It is not clear to me = that there is a requirement that all messages be protected from = eavesdropping.  It might just be the way things are stated here, = but there is a difference between the fact that the solution must = provide a method to deal with this and the fact that integrity = protection might be sufficient in some cases.  This would also = influence the analysis below in some cases.

 

5.  Section 2.1.1.5 - You need to have a = better statement of what it means to provide forward secrecy.  This = requirement would appear to potentially rule out the use of the same = session content encryption key for multiple messages.  I do not = believe that is true, but given that we are looking a message based = security some people might think this is the case.  I would expand = this statement to define the conditions under which PFS must be = provided.

 

6. Section 2.1.2 - Do you consider a proxy = re-ordering requests to be a threat?

 

7.  Section 2.1.2.1 - Next to last para.  = I am not sure that 'involve' is the correct word in this sentence.  = Perhaps you meant 'include'

 

8.  Section 3 - when I look at figure 10, I = keep feeling that it is not a complete picture of what you need to be = looking at

 

 

           &= nbsp;       Security = Assn         Security = Assn

           &= nbsp;   +-----------------+     = +---------------+

           &= nbsp;   |         =         |   =   |          =      |

           = ____________        = __________         = ___________

           = |            = |      = |          = |       = |           = |

           = |            = |----->|          = |<------|           = |

           | = Subscriber |      |  Broker  = |       | Publisher = |

           = |            = |<-----|          = |------>|           = |

           = |____________|      = |__________|       = |___________|

           &= nbsp;     = :            =             &= nbsp;           &n= bsp; :

           &= nbsp;     = '--------------------------------------'

           &= nbsp;           &n= bsp;   Security Association

 

There needs to be = a discussion of all of the different potential security associations in = this diagram.  Some of these can be reduced to simple client-server = associations, but some of the implications of this diagram are = potentially used for the entirety of the picture.

 

Examples of = things that can be looked at:

a)      = The broker is the one that will do enforcement = of access control.  If this is not true then all subscription = requests would really need to be passed onto the publisher to ensure = that the subscriber is to have access.  And we now have  new = thread of the broker granting access to a subscription stream when it = should not.

b)     = The broker may validate that messages from the = publisher are in fact from the publisher, but be unable to look at the = content of the message.

c)      = The broker may need to have some details of the = SA between the subscriber and the publisher.   For example, = what happens if the key used to encrypt/protect the message gets updated = or if the publisher is generating the same stream but using two = different group keys.  In the first, is this an issue for the = client or for the broker.  In the second case there are effectively = two different streams with the same name that need to be identified by = the broker and the correct responses sent to the = client.

 

These are examples of what I meant in the F2F when I = said that you have a semi-trusted broker.  It is trusted with = information about the subscription stream and allowed to enforce = it.  But it is not allowed to have access to the actual content of = the stream.

 

9.  Threats in section 3 also include =

  * out of order delivery = of items.   

  * = Issues about a broker either granting or denying access to a = stream.

  * Subscriber does not = receive a response because the broker pre-maturely unsubscribes the = subscriber

 

 

 

------=_NextPart_000_0369_01D1ECCE.A424D370-- From nobody Wed Aug 3 00:46:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9321712D8B0 for ; Wed, 3 Aug 2016 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNpDTC26D2iN for ; Wed, 3 Aug 2016 00:46:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEF812D995 for ; Wed, 3 Aug 2016 00:46:44 -0700 (PDT) Received: from [192.168.10.132] ([88.117.91.175]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MBWIM-1bNfsK2dVO-00ATAA for ; Wed, 03 Aug 2016 09:46:42 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <860d61a8-4b1e-5a62-929f-af3ea6808081@gmx.net> Date: Wed, 3 Aug 2016 09:46:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VmGnS0TjHB6KdSkDQecW1kMBbaxCDQl9u" X-Provags-ID: V03:K0:I7/X3UocxFzKB+ltztuPV0ABRTt6GU2oTcoQQSW81hkIMxHmSUD 5IC1f2qUX6DMrY6yShMMV0KRpyvwD3uVZuayRbsaEN+DQ3D7fRkrSyZCYGFfh6q41qjNuef tLWHHWqPPaaLwdwzTNNY8dIACUClTezyehU09nSRSWO0R2ZUfVwyfjASWru89b3avJPkI1m lKYCvfSzopxj9DNR3kwYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ia8kXj3qwEk=:m6jWqSOMz7nPNqTqUQqeS0 5VZU6uH+xwXXuPK8jgZjCwk9ryQyNkKNShVAE7BH1clUeB03AB4SNCeq654QDqGNVDOf+Z9v/ MwtQyKK7uFa5p6/FdTt0ZmJqAXbB/N/GnENXUYhQskYHGKZsd9pLncxDvYxqYCUCG37M1ov4j VKHQoM1ihTE8pbVPTlUCiGhlqMZAvZWdaplkhhZdWFtkpjoWssuEDurEMZTs+xhEPREHvB4Gn 2WW7+Pqbc+LFZutL2qXMMt5yS6ENcRn7NdgoWXtxaUhBSJSj6iAPKf9hhGCpZby97Ct2JpiI3 yIdKr7t25w1ewVaCojzd5IuWOQdJZlUsA6Uz/KaDh1rrbFhcIXiwF50/sXrdG16ujFJaW7nrs H4lr7evqYoNkmMU3MAVQwngjQa/Kgn9UdsIaK98VKnBewelYrpnc7hhQMjxs/S5P2z1KFIREl 7l8OSM2VErmRmpNxyvtXNDgzDul6pG/kwZI8Tkn909rraUgCY8rObIHhIPdR54Ye19TYWYIXH SFjxhu1AdtHwUw2CpmgFsEJv0VS14+puHcj4ZIO3Hl5MUhYdy9/kMzOUCQ+rHC4oWaJdhJ/OF 6juf+tSI8CJAoWwCE3nk3CLVUifY+47mx7gdMyLcuAJ5+r9c3AuHNdp3HonrMtcrYhAAxuC0/ kqIzT2OccezvTqngaoooR0kzaoA5x0dgIX7qJytwzNUYfFf2b6P76W1kdiOVYmI7GCU+Y7ssE fLv32vOTudxaltLJN/De4lT2VtD86IrjSvmxYh1Ld9bFHqU15MFf6SACDvY= Archived-At: Subject: [core] My notes about draft-koster-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 07:46:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VmGnS0TjHB6KdSkDQecW1kMBbaxCDQl9u Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I read through draft-koster-core-coap-pubsub-05 and have a few questions.= The document makes sense to me. I do, however, wonder whether you could compare the described functionality with the LWM2M queue mode. There appear to be lots of similarities but the "caching" concept in LWM2M is better worked out. I am not sure whether the brokerless scenario makes sense given the described usage environment with sleepy nodes. Ciao Hannes --VmGnS0TjHB6KdSkDQecW1kMBbaxCDQl9u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXoaFrAAoJEGhJURNOOiAtyL8H/35/gtK+WxwE8t3EmjcQi5Sz KDOz8TlTYfPaXgFj5tDTGy0J8TnAmvd4eR4r6/QZ7djcTSYzFaagOGXJ8XGkJF9v rZXGj/Qr/PFm5Abnnz0J70TmdDUtOU4LshNMKHT//DvN+z3zHT3NRRoFnu9f+DRQ 0M7mVAp6nsMaI/vwha+AfAnJPNvPv2VbBAPQ/8PgHGFIRt3JcA0G2DPkMK6PAXaF mBxomTBDI7LQ2opnH3ENuKs3aJ+g3huRU6QAIRXzNe+ivir5V8E33ZsniGDXqz4E afvvRxkIJ/OOmqgC0lEdm00wv5e+JdmE/UP+0BsP8b3VXVArYR3jG6KpZP8RVMw= =8Ti0 -----END PGP SIGNATURE----- --VmGnS0TjHB6KdSkDQecW1kMBbaxCDQl9u-- From nobody Wed Aug 3 00:49:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136B712D8B0 for ; Wed, 3 Aug 2016 00:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEQHUZ7iMz4W for ; Wed, 3 Aug 2016 00:49:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3578112D876 for ; Wed, 3 Aug 2016 00:49:26 -0700 (PDT) Received: from [192.168.10.132] ([88.117.91.175]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LsCdj-1b7wGi1pPT-013tmZ for ; Wed, 03 Aug 2016 09:49:23 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 3 Aug 2016 09:49:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dqNA20hdlAprKJ6NAkIa5ti2m1xNiRK8U" X-Provags-ID: V03:K0:iava34P0ypTrmplkrXfjqrnAeH6j6Az+gkNEGtmBJgIN7/crv3k JOgh28SzPxKmrvRUW3dfVcHa4Xhx7Jy5hDrKI5ap9g4KyVfZjCNqbu3Y8e0wRNneI8tTIbl qzrzbIFx0H4hNjIXrzMmp1Sio+hwMC7Gab915JuEdCzY7YtFPhLi/rKD5gk0cxVPb0zHIdl Y3v+bI1U0UNuZbBgbas0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:NzI3qg7q2pk=:jZmJrvSXF3CbifU0fulgBK LpLSoeuGGUjDccKLpSQ1pHePiCiFCehC0gOIziJCY3rHkhAg2Ua32+BrBxB+T+a5u4ZZTfjwH 66qetqrD2u79Zk9k3FJdQSY7UY7x1/qbrBn+A4l/OPeoJVRJ+GmmiNXfJYIEUqmPW6LvC0ROp Aq9QIUnQj0WOr1AZj1pjRbbUiWCPYOFUBJXtiNzIhTeuR6rdB5UpfDckl8cz9wrI92Ohei1TV cHJu1YP5QnV0gaEOpyto1eetsZ8Dn1PkTNzmZFPSCk2xyqbILgijoTxWtS793GU73zzxnTVUr f1yBGvO0CM9SSujAkdRwlaF2VI2sVcpO2PlxmlKimMPuluY1vGUa9+A+ZX3cPG91gnyKy2epP z31yh4YItNrGMWBTxEit9oIo49kKYxBqzOSvD9UivpfdI6q+JKEEHgfc488Dzlm/3h+9t9hpU UIyXlem9AirCQGkv9HThea4CROxjae3ZFl6TcAuxxJm83uJc3HaMQEcDeNrzEf2K8SgLBxftl RDF3HTVqMkr3xEBJXbWinS0T8v2527JvJHSTKIYue8LiJpXjZ9hVU/Rzy8hNDRXoQ/ISInQ6K 1QYfBe7jawn2Qa+cETX7e53ycRKJlCvvWD6mpU0lp50utq8OhLT9lxM5DI+5gPOMWJzVVib4p h6wNqv2tNpU3sw/AIO8RpA1123i/A3sq2ssWf0orCX7tkEVYGEqWRPXxaT8GmxfSvexR2SdpS SmXVj6J9UkPZGFjnp4izDxHrkK46w+3NZdDiG+NpK7IpdY0HDjHPEp1JyVg= Archived-At: Subject: [core] My Notes about draft-ietf-core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 07:49:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dqNA20hdlAprKJ6NAkIa5ti2m1xNiRK8U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I read through draft-ietf-core-interfaces-05 and I have a few questions. I understand the functionality and the desire to standardize interfaces since the CoRE Link Format only introduces the concepts but leaves the details (i.e., the value for the if parameter) unspecified. 1) Who came up with these terms? Here, for example, is the definition of the 'collection': "A Collection is a resource which represents one or more related resources. Within this document, a collection refers to a collection with characteristics defined in this document." My understanding of the collection function is that of a view in an SQL database. Is this correct? The definition of function set, interface, and other terms also appears to be somewhat unusual. Isn't there something we could re-use from the Web context? 2) Is this document only applicable to CoAP or also to HTTP? In general, I get worried when functionality is only defined for use with CoAP and is not usable with HTTP, and HTTP/2. 3) Is it possible to include some practical examples? The document currently includes a number of examples but those are abstract. 4) I am curious why SenML was selected. I have been trying to understand the relationship with LWM2M and LWM2M, for example, does not use SenML. SenML feels like a somewhat heavy format since it includes meta-data that most applications don't need. 5) For most functionality no use cases are presented. The exception is the collection where a use case is presented in Section 4.2. I am, however, not sure that the 'Gradual Reveal' functionality is really useful as such. 6) Who is using the functionality described in this document? The editor's note talks about alignment with OCF. Since I am not familiar with the functionality standardized by the OCF I cannot say how much different this document is from the OCF-defined features. 7) The structure of the document is not well-balance. For example, Section 3 consists of one sentence. The content of Section 5.8 is meaningless and Section 6.3 "Versioning" is difficult to understand. The security consideration section as well as the IANA consideration section is at best incomplete. Appendix A contains no textual description of what is shown in the tables. 7) Who is the editor of this document? Ciao Hannes --dqNA20hdlAprKJ6NAkIa5ti2m1xNiRK8U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXoaIMAAoJEGhJURNOOiAtaIAH/0Fsex2fEJfnOgB53jyiu1OS TSli9zVkI2LRfIr/49tTsthupuofoBMgUsjQ8uUJJb+sf0TaLf95iwi4xJY2D+u/ 2JycYrqXWV+CrM5E9XLDTmJplkISL3Cb6dT7Jd498JS8UmPeNahEOStCjX4AQyOa FHoQD8yEiZ5X+t0o8reADJVo55je26/hEwBbrVth/VPiii0KtOGBgbDLUOmiOVVW KFjkOBuTL2JTMsDn+TEbLIO/f8zRnTiJQ5T5AbmIG3SZaeSuV3ax1Jh0Js8StBHL 5M3a5B6Tp8oigO/NP+oe5STxcTjcPt26ahk1Sc03H6ykdVfor+0Eu6OEL0l7qvo= =iHxw -----END PGP SIGNATURE----- --dqNA20hdlAprKJ6NAkIa5ti2m1xNiRK8U-- From nobody Wed Aug 3 00:50:04 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3923B12D960 for ; Wed, 3 Aug 2016 00:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PVNOn9oGPNv for ; Wed, 3 Aug 2016 00:50:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6102212D876 for ; Wed, 3 Aug 2016 00:50:01 -0700 (PDT) Received: from [192.168.10.132] ([88.117.91.175]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MfVYB-1btQ6e0951-00P5ua for ; Wed, 03 Aug 2016 09:49:59 +0200 To: "oauth@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 3 Aug 2016 09:50:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cmCdwbON7lAbhK0hbqE7EU9dpEv1u1TFT" X-Provags-ID: V03:K0:vlR5ltkKhV3KT+hxZt51iyFvlvc+235aAWPvPQ3ixwyWu97W8ky SJCyO5ac0pSCw6xrkRWNqDqgvnFx4Ti/bOyU4+jJAy+n952CuL6UI0QI+O0pJunC2gUn3MV 0VZhjMfAFqM4cerXoTbnk6w7ABZtGUCxHKQ82v6ZJgwgKAn1MKHiGFf00o7GMiixaT8pOsQ UQAchvSbf+ZpWPW/2zoRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:mEo4s45nkDM=:14YYV8gocd4KhybFrIlEMd U9p9TBwZuRdTsD7F2FHnUUeWK23DdJcF+RcLdsALw6el41GvcmYvmDYmVegDE7DRADAh+uPZV SCAebznYprpglNidz5q2swN8eZKMuV7ZFK5x1A5vL3xrNwUemzwLIVz4BP7gRmjeB2gOLRhMK KP0rHI8JFSb+r9dRjaQBRUPXefu6ZSdANzB3sKjkoRPun42aOY4wFgqmIA7JNpf/eGXQ0uR0O tdy1WuuPctPAbkeJSwjOIwNdno6pB/ftsYwV/3YE5X9uvxkghXtFCSE9kYckpmj2TIIngnCYO aiQzizXGjSArRyk9x7mKlSSrWwn1b2PPjX0bkDXaN73pzbaPvVVjrr2nJsRG8MUDIvtRN36a7 czifSb/V8dgwpcNRlUb7W04iCjgiHwgPJDhwywISwaswXa8QJD+43UFmLc+DvlhXxEAz9Cfjj WO12OOaaVcy8tMCcqNimH9WoDVKfwLo/oE2+15aRl3tpA2LoeLx/1jYHui9iOiuLeUOuzQnnh Pq99RXrJs6qWi4svRJp0xwu4kNH7jRkjyqralLYQySr3zxxPm02/G65nvTcqnePF5nsPTqyQI ZMqtmV0FUf7IANC3+n4iIq4ErkLKcpfU559+o/rhh4VvXoRE9G0VtNpmnL8DUh3ByGhu0a7Y/ cPm35hT7GFmrf2yH+wh7tDivGXkHXbRQfJ95OmxA3T/+Ukx8xJtCe2/5DkOAbqE8OMBRU0Fxb auRtkK5SItJme6MSc5nz28j6k88HNvgu3KByeoSIjtzu4uscYu32f/IzZM0= Archived-At: Subject: [core] Review of draft-ietf-oauth-amr-values-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 07:50:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cmCdwbON7lAbhK0hbqE7EU9dpEv1u1TFT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, Phil, Tony, I have read through draft-ietf-oauth-amr-values-01. My earlier comments have been addressed. As a shepherd I nevertheless have a few questions/remarks: 1) The term 'multiple-channel authentication' is unfamiliar to me. Could you give me an example or a reference to a specification? 2) PIN: The use of RFC 2119 language appears to be inappropriate. 3) Could you explain me what 'risk-based authentication' is? While you provided a reference 4) Could we generalize the term 'wia' to operating systems other than Windows as well? 5) I am not sure whether all normative references indeed need to be declared as such. For example, 'otp' is defined in a very generic fashion but you list HTOP, and TOTP as normative references. I would rather see HTOP and TOTP as a standardized examples of one-time-passwords. IMHO the story would be different if you indeed want to differentiate between the different technical mechanisms itself. This is a reasonable approach as well if the security differences between the mechanisms is important for the given application. Ciao Hannes --cmCdwbON7lAbhK0hbqE7EU9dpEv1u1TFT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXoaIvAAoJEGhJURNOOiAtZUcH/2GLlRQ65fzXZXxkxiyQEABg eIBOqoVWqzbso3V4WAS6S2D7vdp7KaP1IMmWodu0N3Ead30qkgPLVrs1eHWhsNKf g66Ks2UTeXgVg+mF2IDdE5STuVivCsNcw9/R6PreYaS4kX/O/TSCQ0Z2P0jfjGCl 5FSJu26M4t+DRFi+mh/97cLb2q8f59aO+AJJsPhnZPEKIc+cTQkelh6ZV6hGHagx 3I5CXvGCIoXHipmQ1mAl+yxqv/XNhrd7f+LosDxVNcZifK5mCkiU8zlsw4pRe6zG X+Gq4R4Q7DHFDJdCsEZ9vm+voIuO0ZTjeUYjkkNfgBvT3C+W5kwizUaQWooTiBM= =U764 -----END PGP SIGNATURE----- --cmCdwbON7lAbhK0hbqE7EU9dpEv1u1TFT-- From nobody Wed Aug 3 08:25:46 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878412D192 for ; Wed, 3 Aug 2016 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIx-_g5Ou5T0 for ; Wed, 3 Aug 2016 08:25:40 -0700 (PDT) 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 1E8A512DC86 for ; Wed, 3 Aug 2016 08:23:38 -0700 (PDT) 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 u73FNZGw002242 for ; Wed, 3 Aug 2016 17:23:35 +0200 (CEST) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3s4H0706B4zDDHk for ; Wed, 3 Aug 2016 17:23:35 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id o80so341620408wme.1 for ; Wed, 03 Aug 2016 08:23:35 -0700 (PDT) X-Gm-Message-State: AEkoouuVWJCFAoidtoDEvv7iPhFfpMfFhj55LtipPnBrirHGkQEdzoNFNXvO4HzN4CdAXKVTgXoCDQN3IKzgqA== X-Received: by 10.194.82.99 with SMTP id h3mr9301652wjy.9.1470237813620; Wed, 03 Aug 2016 08:23:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.86.200 with HTTP; Wed, 3 Aug 2016 08:22:53 -0700 (PDT) In-Reply-To: <036801d1ed09$507ef080$f17cd180$@augustcellars.com> References: <036801d1ed09$507ef080$f17cd180$@augustcellars.com> From: Klaus Hartke Date: Wed, 3 Aug 2016 17:22:53 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org, "core@ietf.org WG" Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:25:45 -0000 Hi Jim, thanks a lot for your review. Comments inline below. Klaus Jim Schaad wrote: > 1. Note that the title of the COSE document has changed you should pick > that up. Fixed. > 2. Section 2.1.1 - Should "client receives a response" include > > * (Threat ?) The proxy returns a stale or outdated response based on > data it previously obtained from the origin server or some fourth party. > > I'm thinking of both out of date caches and poisoned caches. > Note that these are valid from a security point of view, but not 'fresh' This is a part of (Threat 1:) The proxy spoofs a response. In the mitigation section (2.1.1.1.) we define that a response is valid from a security point of view only if it is fresh. (We use the term "authentic" instead of "valid" though, because "valid" is already used in the context of cache validation.) I've expanded the text with your suggestion: * (Threat 1:) The proxy spoofs a response. For example, the proxy could return a stale or outdated response based on data it previously obtained from the server or some fourth party, or could craft an illicit response itself. > 3. Section 2.1.1.3 - based on a brief look at mattsson-core-coap-actuators, > it appears to have some solutions to the Withholding attack as well as the > Delaying attack. This should probably be noted. I've opened an issue on GitHub for this: https://github.com/ektrah/coap-object-security/issues/5 > 4. Section 2.1.1.5 - It is not clear to me that there is a requirement that > all messages be protected from eavesdropping. It might just be the way > things are stated here, but there is a difference between the fact that the > solution must provide a method to deal with this and the fact that integrity > protection might be sufficient in some cases. This would also influence the > analysis below in some cases. Currently the text is written with the assumption that it is a requirement that all messages are protected from eavesdropping. However, as Carsten mentioned at the F2F meeting, there may indeed be use cases where it's desirable that the proxy can eavesdrop on the messages. We will clarify this in the draft. https://github.com/ektrah/coap-object-security/issues/6 > 5. Section 2.1.1.5 - You need to have a better statement of what it means > to provide forward secrecy. This requirement would appear to potentially > rule out the use of the same session content encryption key for multiple > messages. I do not believe that is true, but given that we are looking a > message based security some people might think this is the case. I would > expand this statement to define the conditions under which PFS must be > provided. https://github.com/ektrah/coap-object-security/issues/7 > 6. Section 2.1.2 - Do you consider a proxy re-ordering requests to be a > threat? No. If a client wants to ensure that a request is processed after another request, it needs to wait for the response to the first request before it makes the second request. > 7. Section 2.1.2.1 - Next to last para. I am not sure that 'involve' is > the correct word in this sentence. Perhaps you meant 'include' Fixed. > 8. Section 3 - when I look at figure 10, I keep feeling that it is not a > complete picture of what you need to be looking at > [...] > > There needs to be a discussion of all of the different potential security > associations in this diagram. Some of these can be reduced to simple > client-server associations, but some of the implications of this diagram are > potentially used for the entirety of the picture. > [...] https://github.com/ektrah/coap-object-security/issues/8 > 9. Threats in section 3 also include > > * out of order delivery of items. > > * Issues about a broker either granting or denying access to a stream. > > * Subscriber does not receive a response because the broker pre-maturely > unsubscribes the subscriber https://github.com/ektrah/coap-object-security/issues/9 From nobody Wed Aug 3 09:21:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2A12D5D3 for ; Wed, 3 Aug 2016 09:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WkNp_iqUcyg for ; Wed, 3 Aug 2016 09:21:47 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 7A33D12D1AF for ; Wed, 3 Aug 2016 09:21:42 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id u73GLeow018867 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 3 Aug 2016 18:21:40 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id u73GLe3l029033 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Aug 2016 18:21:40 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.89]) by DEFTHW99ERGMSX.ww902.siemens.net ([139.22.70.132]) with mapi id 14.03.0301.000; Wed, 3 Aug 2016 18:21:39 +0200 From: "Kovatsch, Matthias" To: "core@ietf.org" Thread-Topic: 1st International Workshop on Semantic Interoperability for the IoT (SIFI) Thread-Index: AdHtox0h/FwnZOhCQbu122usDoJnSg== Date: Wed, 3 Aug 2016 16:21:39 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C0184C7C2@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] 1st International Workshop on Semantic Interoperability for the IoT (SIFI) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:21:52 -0000 Dear all We are trying to get an academic community together that is interested in t= he sweetspot between semantics and practical IoT applications! This is dire= ctly related to the work in the WoT IG and the IRTF T2TRG. The workshop wil= l be co-located with the 6th International Conference on the Internet of Th= ings (IoT 2016) will take place November 7-9, 2016 in Stuttgart, Germany. http://sifi-workshop.github.io/ ## Call for Papers The International Workshop on Semantic Interoperability for the IoT (SIFI) = targets authors from the Semantic Web and the Internet of Things (IoT) appl= ication layer to form a community that explores machine-understandable info= rmation and interaction models for Thing-to-Thing communication. While the = IoT promises products and higher-value services based on the widespread and= integrated use of connected devices, we are currently witnessing applicati= on silos with custom interfaces, heterogeneous network communication mechan= isms, and individual data models. The workshop aims to overcome scenario-dr= iven, not reusable, isolated islands of solutions, so that everyday objects= are not only network-enabled, but can finally participate in integrated sc= enarios. The challenges include: * __Connectivity and Integration:__ There is a heterogeneous landscape of b= oth wired and wireless communication standards to fulfill different applica= tion requirements. Manual integration via gateways increases the implementa= tion effort and the complexity of the solutions. * __Information Models:__ Each application usually comes with its own data = model, although the information about the physical world is relevant even a= cross application domains. The IoT requires shared formats and models so th= at information can be understood and interpreted by all applications. * __Security and Privacy:__ Each IoT platform typically comes with its own = security mechanisms and policies. To make use of a common information model= and interact with integrated IoT devices, these must be declared in a mach= ine-understandable manner. * __Flexibility and Scalability:__ IT systems have usually been developed a= nd deploying with only the current or immediate future needs in mind. IoT s= ystems need to be able to handle change and evolve with their environment, = in particular when being part of long-lived infrastructure. * __Monitoring and Analysis:__ IoT systems will produce a huge stream of qu= asi real-time data. This requires innovative ways to analyze and assess inf= ormation to notify users in time or even to act autonomously. The first SIFI workshop primarily seeks position papers to gather researche= rs who want to follow a practical approach of Semantic Web technology or wh= o want to enrich their IoT applications, protocols, and security profiles w= ith semantic information. Promising concepts and solutions may be pursued f= urther within the IRTF [Thing-to-Thing Research Group](https://github.com/t= 2trg/) and the W3C [Web of Things Interest Group](https://www.w3.org/WoT/IG= /). ## Important Dates * __Paper submission deadline:__ September 19, 2016 * __Notification of acceptance:__ October 10, 2016 * __Camera-ready papers due:__ October 24, 2016 * __Workshop date:__ t.b.d. (November 7-9, 2016) ## Submissions * __Position paper (preferred):__ 1-4 ACM conference format pages * __Full paper (limited slots):__ 6-8 ACM conference format pages Both types of research paper must be original prior unpublished work and no= t under review elsewhere as they will be published to the ACM digital libra= ry and listed on DBLP. All submissions will be peer-reviewed and selected b= ased on their originality, merit, and relevance to the workshop. Submission= requires at least one author to present the paper on-site. If you can, we = encourage authors of accepted papers to bring a prototype and demonstrate i= t at the workshop, as part of an open demonstration session. ## Organizers * Matthias Kovatsch - Siemens AG and ETH Zurich, DE/CH * Maria Maleshkova - KIT, DE * Michael Mrissa - Universit=E9 de Pau, FR From nobody Wed Aug 3 09:45:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E785712D0CE for ; Wed, 3 Aug 2016 09:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxgb9awy054G for ; Wed, 3 Aug 2016 09:44:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003A512D56D for ; Wed, 3 Aug 2016 09:44:47 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 Aug 2016 09:56:02 -0700 From: Jim Schaad To: 'Klaus Hartke' References: <036801d1ed09$507ef080$f17cd180$@augustcellars.com> In-Reply-To: Date: Wed, 3 Aug 2016 09:44:21 -0700 Message-ID: <047701d1eda6$4af5c5b0$e0e15110$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFVQec6mZkH2zubcUsWpGYFrv/2RAEXD4dJoSgPgTA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org, core@ietf.org Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:44:59 -0000 > -----Original Message----- > From: Klaus Hartke [mailto:hartke@tzi.org] > Sent: Wednesday, August 03, 2016 8:23 AM > To: Jim Schaad > Cc: draft-hartke-core-e2e-security-reqs@tools.ietf.org; core@ietf.org = WG > > Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01 >=20 > Hi Jim, >=20 > thanks a lot for your review. Comments inline below. >=20 > Klaus >=20 >=20 > Jim Schaad wrote: >=20 > > 2. Section 2.1.1 - Should "client receives a response" include > > > > * (Threat ?) The proxy returns a stale or outdated response = based > > on data it previously obtained from the origin server or some fourth = party. > > > > I'm thinking of both out of date caches and poisoned = caches. > > Note that these are valid from a security point of view, but not = 'fresh' >=20 > This is a part of (Threat 1:) The proxy spoofs a response. >=20 > In the mitigation section (2.1.1.1.) we define that a response is = valid from a > security point of view only if it is fresh. >=20 > (We use the term "authentic" instead of "valid" though, because = "valid" is > already used in the context of cache validation.) >=20 > I've expanded the text with your suggestion: >=20 > * (Threat 1:) The proxy spoofs a response. For example, the > proxy could return a stale or outdated response based on data > it previously obtained from the server or some fourth party, = or > could craft an illicit response itself. >=20 My problem with this is that I view a spoof as different. To me a spoof = implies the attempt to create a new message that will pass muster as = oppose to doing something like a replay. It would probably be better to = use a different term. I'll try and remember to ponder on this. Jim From nobody Wed Aug 3 13:40:17 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F1C12B05E for ; Wed, 3 Aug 2016 13:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDyda5pRnMFY for ; Wed, 3 Aug 2016 13:40:12 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0127.outbound.protection.outlook.com [104.47.37.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93D812B01E for ; Wed, 3 Aug 2016 13:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jPxKURJSMF4A761eIptQAssSZbUhqvJWynf8g9aItbQ=; b=PauDXnx4EaRk+CJk3REX8W1THi9LU3nupEMI/aa/m3fXCOVk7M3nh/M3nDaJ/oKul0yvrZklTJCnsWMaMEXb0QknDbteUWoST1sC7UZYZ0PuZKfgz2kTfY9dLhlFbBdZgmnptvT5Dc4tbhota4Ev+UmJ0vQqck87qm6egOfyebA= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0719.namprd03.prod.outlook.com (10.160.97.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 3 Aug 2016 20:40:10 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0549.023; Wed, 3 Aug 2016 20:40:10 +0000 From: Dave Thaler To: "core@ietf.org" Thread-Topic: rt and if registry question Thread-Index: AdHtxnz2wdbZZVFCRkuIwoepMaBv0Q== Date: Wed, 3 Aug 2016 20:40:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:a::2d5] x-ms-office365-filtering-correlation-id: 0eb5a9b6-4db5-4f6d-3dbe-08d3bbde5d13 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0719; 6:3yCM11DaIqsjbLZaYpCAgFuzdNXdjSdTflUPGobezdygtsnURTJAS0rdQqSxf+P78qLuhoi+Wh9Yld5TrYxbi9enNDLRhb36qsAkUTrIfaL2N2QslaZYOfKhqriWMWUEBh1UgTWZ9nejylqDSJPoMxSjI4dbrGKElpA0dSrGo22Odl/f3syCnrqie6x/cWoZ/jnjeMq5gz2B2uR+HSksvWN9hY7qYdtSZOmswnlc0D9C34JbasrguRuENpAy6No95v/Uo0MtyE0DZ2I7v/jXtuV4pH62fyMWHrfTuL3bKYGqiU/Cu+AqMKsbcua6Rcu1NGv5z/xRTBt5d+k8XO+K7A==; 5:L8ACFvfhHSmd2bpB6vkiTpAPWf4XBaCgGw6rJfm4CPtjWYfftsvsXvHu7XDyCb53ZKhee2Ia9FsXPLwarq22chXNk5FaT6MHnhMp0WasDNNzmMncAs25+YbuEH/1tOOoNQfRZcK24Z4QGL0FkcfUgQ==; 24:ba+yMP0Y0P1a586DyAdMiXSNUgBiOcr4mcxl4cFqnf8vk5N8LkjmgsZFfSxTQDd+6PHdZfI8/VnrG5DdW2ED4Gnf77gd0L9WO4YKxn5Ur+Y=; 7:FRNZiuiItmE/dA2wXv/MfHLqkYHNRnL8tdWj2qTLi7Lt5qMVYqnTPCDls8psqWPsdPFV4npKrtahvFtckjVa5BWkstvn49MTCyTbhSiHk+iq4Q4LHJstg63ziompp5778CQ56l7JY0h7Eakt9FjMbjR/ZJWLy/RJ7HlhBHoOXMrm/44iZeInwjeBNl+G/KRTI90ElAu1EGA/bYSlGl2TNLg0ZsSnwXzOlpMl+HnDK4qux+w2h66McKlHynp9yUdz x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0719; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0719; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0719; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(11100500001)(19300405004)(105586002)(101416001)(19617315012)(7736002)(76576001)(7846002)(106356001)(10090500001)(110136002)(10400500002)(5002640100001)(10290500002)(2900100001)(8990500004)(586003)(2501003)(107886002)(6116002)(92566002)(19625215002)(102836003)(790700001)(5005710100001)(99286002)(229853001)(3660700001)(9686002)(2351001)(5640700001)(3280700002)(5630700001)(86362001)(87936001)(97736004)(86612001)(74316002)(15975445007)(16236675004)(81156014)(81166006)(2906002)(450100001)(68736007)(19580395003)(50986999)(1730700003)(8676002)(54356999)(189998001)(122556002)(77096005)(33656002)(8936002)(7906003)(7696003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0719; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 20:40:10.5525 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0719 Archived-At: Subject: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 20:40:15 -0000 --_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In some conversations I've been in, I've found that different people read R= FC 6690 different ways. Section 3.1 says: The Resource Type 'rt' attribute is an opaque string used to assign an application-specific semantic type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource, this could be, e.g., an application-specific semantic type like "outdoor-temperature" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple Resource Types MAY be included in the value of this parameter, each separated by a space, similar to the relation attribute. The registry for Resource Type values is defined in Section 7.4. Section 3.2 is similar for 'if' values. And section 7.4 says: For both sub-registries, values starting with the characters "core" are registered using the IETF Review registration policy [RFC5226]. All other values are registered using the Specification Required policy, which requires review by a designated expert appointed by the IESG or their delegate. ... o URIs are reserved for free use as extension values for these attributes and MUST NOT be registered. So the question is, what values can be used _without_ registering. Clearly= the last sentence above says URIs are allowed. But it's apparently ambiguous whether other values= like "outdoor-temperature" in 3.1 (or "x.outdoor-temperature" or similar variations) can be used by an= application without registering it. My reading of 3.1 is that registration is required for everything but URIs,= but others read section 3.1 differently. Can the WG clarify what the intent is? Thanks, Dave --_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In some conversations I’ve been in, I’ve= found that different people read RFC 6690 different ways.

 

Section 3.1 says:

   The =
Resource Type 'rt' attribute is an opaque string used to assign<=
/span>
   an a=
pplication-specific semantic type to a resource.  One can think
   of t=
his as a noun describing the resource.  In the case of a
   temp=
erature resource, this could be, e.g., an application-specific
   sema=
ntic type like "outdoor-temperature" or a URI referencing a<=
/o:p>
   spec=
ific concept in an ontology like
   &quo=
t;http://swe=
et.jpl.nasa.gov/2.0/phys.owl#Temperature".  Multiple
   Reso=
urce Types MAY be included in the value of this parameter, each<=
/span>
   sepa=
rated by a space, similar to the relation attribute.  The
   regi=
stry for Resource Type values is defined in Section 7.4.

 

Section 3.2 is similar for ‘if’ values.<= o:p>

 

And section 7.4 says:

   For =
both sub-registries, values starting with the characters "core"
   are =
registered using the IETF Review registration policy [RFC5226].
   All =
other values are registered using the Specification Required
   poli=
cy, which requires review by a designated expert appointed by the
   IESG=
 or their delegate.

…

  = ; o  URIs are reserved for free use as extension values for these=

      attributes and = MUST NOT be registered.

 

So the = question is, what values can be used _without_ registering.  Cl= early the last sentence above

says UR= Is are allowed.   But it’s apparently ambiguous whether oth= er values like “outdoor-temperature”

in 3.1 = (or “x.outdoor-temperature” or similar variations) can be used = by an application without registering it.

My read= ing of 3.1 is that registration is required for everything but URIs, but ot= hers read section 3.1 differently.

Can the= WG clarify what the intent is?

&n= bsp;

Thanks,=

Dave

--_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_-- From nobody Wed Aug 3 20:35:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3C12D69E; Wed, 3 Aug 2016 20:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLi6epRl9aqX; Wed, 3 Aug 2016 20:35:17 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B9C12D866; Wed, 3 Aug 2016 20:35:16 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 Aug 2016 20:46:53 -0700 From: Jim Schaad To: , Date: Wed, 3 Aug 2016 20:35:10 -0700 Message-ID: <04fe01d1ee01$35bf9120$a13eb360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdHt4Mmd/aVI+5qsSE+Tcxdmb21+Nw== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Review of draft-koster-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 03:35:20 -0000 I have a hard time saying that this is ready to be published, but that is in part because I think that the security aspects that are not being addressed in the document are important. Section 3.2 - The phrase "and potentially buffer messages" is causing me problems. By definition it must buffer the last data value that it includes. It would be good at this point to explain exactly why it is buffering messages here. I assume that you are talking about the flow control issues that are discussed later but I don't know this. Section 4.2 - What is the behavior of Max-Age for sub-topics? Is the topic deleted only if it has no current sub-topics? Publish rates of the topic and sub-topic may not be the same. Section 4.2 - How does a topic creator control who can a) publish to the topic, b) create sub-topics, c) subscribe to the topic. Based on how things are laid out I make the assumption that the broker is the entity that would enforce these rules. Section 4.3 - As we go forward into the world of having secure items, the rule on only publishing a fixed content type means that there will be no way for a broker to create other content types without losing the authentication source of a signature by the publisher on the content. It would be nice if it were possible to publish multiple content types at one point. I guess one method might be to look at a content type that would be list of contents w/ different content types but then the discovery method becomes odd. Also create would need to be modified to deal with the situation as well. Section 4.7 - The following language is driving me crazy. "A CoAP pubsub Client wishing to remove a topic MAY use the CoAP Delete operation". If you are going to say that it may do X, then you need to also say that what other things it could do to remove it. I think you should just remove the MAY here (and in similar places) and just say "to remove a topic uses the CoAP Delete operation". Section 7 - Should there be advice on how to distinguish between a new publish and a re-publish because a response was not received? Section 8 - DTLS will not provide authentication if there is a proxy in the way between the client and the broker that terminates the DTLS session. (The whole hop authentication vs end-to-end.) Section 8 - the last paragraph is giving me a problem. It appears to say that if the broker is not trusted hen it would have a problem doing the correct forwarding to subscribers since it would be unable to read the CoAP headers. Is that correct? Confirmation of messages. The system seems to be very light on telling one when confirmation of messages should be used and when it should not be used. For example, if notifications are being sent out from a broker - should all messages get confirmations before continuing, should only some messges get confirmations based either on the message published or on the notification that is being sent to the client. I.e. do you treat a removal from a subscription differently if it is deleted vs if the authorization for the subscriber expires? In one case doing the get will show that it no longer exists but in the other case the client will have missed messages when it was not subscribed. Jim From nobody Thu Aug 4 08:03:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5757812D0CC for ; Thu, 4 Aug 2016 08:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsapABar-Xjk for ; Thu, 4 Aug 2016 08:03:34 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0115.outbound.protection.outlook.com [104.47.32.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EBF12B031 for ; Thu, 4 Aug 2016 08:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fZDzdPBTLuhTx3nWc2tlyW/8k20z+bBylj1GKsbZi+g=; b=WfY4pSqaSuvqNwPUmJKZXmbfe5I1oNveKvT7TYnFtNOz8DLEsLwvjXgGZTz5bGAN197X04dTAUFrSURyKkrZPXfvEZwmIgWB6z5t9HLTSu6JBQMZ4AB1vkSB5DSURlmtmV1qbKGVTCXHTEVj3jtgrBBMx/GDv42/XewK5RhAK0o= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0718.namprd03.prod.outlook.com (10.160.97.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 4 Aug 2016 15:03:31 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0549.023; Thu, 4 Aug 2016 15:03:31 +0000 From: Dave Thaler To: "core@ietf.org" Thread-Topic: rt and if registry question Thread-Index: AdHtxnz2wdbZZVFCRkuIwoepMaBv0QAmhs1w Date: Thu, 4 Aug 2016 15:03:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [73.193.101.106] x-ms-office365-filtering-correlation-id: f023fba0-5274-4987-eb25-08d3bc787f9b x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 6:YIMK0/Q5sqYoIHLlny5Ny9WrifoBfgsPnQhK9yMKwcZBF8cJC1URbKjNH9Qg+Tnqoai/FycVEnNgX8hz3BBPb63fpvex74wlYQ/0vRUpWUseP8IrnCesNhG7L31zOcYHAFHXuO/5kYGHjwKricnFrxEmhzEPFRY5JUf8D1iYYdwM6PNPVvEuHjx8r1iHIR2ur1tbuvlQt0oKuTRvrHc02Mv64fuL22QOPn1g6/ywlI0y2OC88BCCrJP41kGcRD0BeBmmfXFEuHxVNlHyat8tRjwpCgqJx1E4vOJ0xTEwruI76TRV7zzeV9cKQQvicI6+qr1eLi2i3CKjRC18B/jl5A==; 5:fNyuwj+ClIEck2byfEE1gFyL8s8NVq25KILryklvjWrHocYKJ7n0k9ZjFFtjgewe8ZAgG2r0XDF+rKXyDM/732yUNJoRghJAhB66fhmPojbiSLE2ZWVuJri5E3npgxsNphEURHt3UtDXjrW2yrM4HA==; 24:2ByyFh+wHLtMXSo6OTAN27Ei/C77+s2C/iuX2mcmJlfOZc3kgyv+2opr82xGhopGkE9QkTe2jJgQzhWzivjYqHG0vrPy4HxxgWemN2aGLmc=; 7:J5z5BLk172x1i61TD7DBU1VKzAi8ZZmmFLnPVuNNOkG434RaPC1UK2te+dRu5HBHBjmhUoVVvVQVx8FUANaSqjlT/cpr3tjI7StF8X5SFQAjCZXlbjbcGCkC1EcG+9q3jkjtin0EzkySn0H0q16uQAxtXho6nvG3h+JIhFeEmL3edGa92+fpiDMAi6vAcEtzSxZMGet370J1Qg6Jmna+XI/6QUpAQhcZCkIPAY+Sn0r10PAfvFebnv4r3RB1xtqP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(199003)(189002)(377454003)(7696003)(106356001)(7906003)(77096005)(2501003)(74316002)(7736002)(7846002)(81156014)(189998001)(1730700003)(2950100001)(5640700001)(5630700001)(68736007)(81166006)(15975445007)(8676002)(2351001)(2900100001)(8936002)(2906002)(76576001)(19300405004)(19580405001)(19580395003)(99286002)(107886002)(66066001)(9686002)(3660700001)(11100500001)(76176999)(50986999)(3846002)(16236675004)(110136002)(54356999)(102836003)(3280700002)(5002640100001)(6116002)(19617315012)(122556002)(97736004)(586003)(19625215002)(101416001)(33656002)(790700001)(8990500004)(3900700001)(86362001)(5005710100001)(105586002)(450100001)(92566002)(10290500002)(87936001)(86612001)(10090500001)(10400500002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB07175E9EA387A588C0003CE0A3070DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2016 15:03:31.0842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718 Archived-At: Subject: Re: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 15:03:37 -0000 --_000_DM2PR0301MB07175E9EA387A588C0003CE0A3070DM2PR0301MB0717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I'm waiting for an answer to the question below, I'll ask a related q= uestion. Can a prefix be registered? In the appsawg discussion that led to RFC 7595, we discussed that question = in the context of URI scheme names and the WG consensus was no, there's no such thing as a prefix because it's tre= ated as "an opaque string". The text quoted from RFC 6690 section 3.1 below also says it's an opaque st= ring, which might be interpreted as "there's no such thing as a prefix", but then section 7.4 uses "core." as a= prefix. You might say "core.*" is a prefix for registration purposes but not for purposes of interpreting in code (I d= on't believe that argument is reasonable though since once you define it for one purpose, people will use it in code for re= gistration which will then bleed into other purposes, which is why appsawg disallowed any prefixes). But if "core.*" = is a prefix for registration purposes only, then the question about whether other prefixes can be registered is a valid= question. Comments? Dave From: Dave Thaler Sent: Wednesday, August 3, 2016 1:40 PM To: core@ietf.org Subject: rt and if registry question In some conversations I've been in, I've found that different people read R= FC 6690 different ways. Section 3.1 says: The Resource Type 'rt' attribute is an opaque string used to assign an application-specific semantic type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource, this could be, e.g., an application-specific semantic type like "outdoor-temperature" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple Resource Types MAY be included in the value of this parameter, each separated by a space, similar to the relation attribute. The registry for Resource Type values is defined in Section 7.4. Section 3.2 is similar for 'if' values. And section 7.4 says: For both sub-registries, values starting with the characters "core" are registered using the IETF Review registration policy [RFC5226]. All other values are registered using the Specification Required policy, which requires review by a designated expert appointed by the IESG or their delegate. ... o URIs are reserved for free use as extension values for these attributes and MUST NOT be registered. So the question is, what values can be used _without_ registering. Clearly= the last sentence above says URIs are allowed. But it's apparently ambiguous whether other values= like "outdoor-temperature" in 3.1 (or "x.outdoor-temperature" or similar variations) can be used by an= application without registering it. My reading of 3.1 is that registration is required for everything but URIs,= but others read section 3.1 differently. Can the WG clarify what the intent is? Thanks, Dave --_000_DM2PR0301MB07175E9EA387A588C0003CE0A3070DM2PR0301MB0717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While I’m waitin= g for an answer to the question below, I’ll ask a related question.

Can a prefix be regist= ered?

 

In the appsawg discuss= ion that led to RFC 7595, we discussed that question in the context of URI = scheme names and

the WG consensus was n= o, there’s no such thing as a prefix because it’s treated as &#= 8220;an opaque string”.

 

The text quoted from R= FC 6690 section 3.1 below also says it’s an opaque string, which migh= t be interpreted as

“there’s n= o such thing as a prefix”, but then section 7.4 uses “core.R= 21; as a prefix.   You might say “core.*” is a prefix=

for registration purpo= ses but not for purposes of interpreting in code (I don’t believe tha= t argument is reasonable though

since once you define = it for one purpose, people will use it in code for registration which will = then bleed into other

purposes, which is why= appsawg disallowed any prefixes).   But if “core.*” = is a prefix for registration purposes only,

then the question abou= t whether other prefixes can be registered is a valid question.<= /span>

 

Comments?

 

Dave=

 

 

From: Dave Thaler
Sent: Wednesday, August 3, 2016 1:40 PM
To: core@ietf.org
Subject: rt and if registry question

 

In some conversations I’ve been in, I’ve= found that different people read RFC 6690 different ways.

 

Section 3.1 says:

   The =
Resource Type 'rt' attribute is an opaque string used to assign<=
/span>
   an a=
pplication-specific semantic type to a resource.  One can think
   of t=
his as a noun describing the resource.  In the case of a
   temp=
erature resource, this could be, e.g., an application-specific
   sema=
ntic type like "outdoor-temperature" or a URI referencing a<=
/o:p>
   spec=
ific concept in an ontology like
   &quo=
t;http://swe=
et.jpl.nasa.gov/2.0/phys.owl#Temperature".  Multiple
   Reso=
urce Types MAY be included in the value of this parameter, each<=
/span>
   sepa=
rated by a space, similar to the relation attribute.  The
   regi=
stry for Resource Type values is defined in Section 7.4.

 

Section 3.2 is similar for ‘if’ values.<= o:p>

 

And section 7.4 says:

   For =
both sub-registries, values starting with the characters "core"
   are =
registered using the IETF Review registration policy [RFC5226].
   All =
other values are registered using the Specification Required
   poli=
cy, which requires review by a designated expert appointed by the
   IESG=
 or their delegate.

…

  = ; o  URIs are reserved for free use as extension values for these=

      attributes and = MUST NOT be registered.

 

So the = question is, what values can be used _without_ registering.  Cl= early the last sentence above

says UR= Is are allowed.   But it’s apparently ambiguous whether oth= er values like “outdoor-temperature”

in 3.1 = (or “x.outdoor-temperature” or similar variations) can be used = by an application without registering it.

My read= ing of 3.1 is that registration is required for everything but URIs, but ot= hers read section 3.1 differently.

Can the= WG clarify what the intent is?

&n= bsp;

Thanks,=

Dave

--_000_DM2PR0301MB07175E9EA387A588C0003CE0A3070DM2PR0301MB0717_-- From nobody Mon Aug 8 06:50:45 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C512D142; Mon, 8 Aug 2016 06:50:43 -0700 (PDT) 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: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147066424374.22974.10556677019154239237.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2016 06:50:43 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Last Call: (Guidelines for HTTP-to-CoAP Mapping Implementations) to Informational RFC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:50:44 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' 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 2016-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Aug 9 05:00:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F612D1A1 for ; Tue, 9 Aug 2016 05:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPtVglTuun4o for ; Tue, 9 Aug 2016 05:00:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC8E12D57B for ; Tue, 9 Aug 2016 05:00:10 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MMpYB-1bagjw0SVj-008WhH for ; Tue, 09 Aug 2016 14:00:07 +0200 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "core@ietf.org WG" Message-ID: Date: Tue, 9 Aug 2016 14:00:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="opUOst9RqqlirlmiJMEbdDQSaWWaUCUec" X-Provags-ID: V03:K0:eWTeRbA/uccELuZ+GsOmWZM8+h64DCTNJHp5A0MIA05fKYhHcnt 84b3mHq847EIMWaqR1UTlta0DE0D+cNspnNkEXK/GkkMOrA5bPq6bsOnSvp8JUmt3RZzaoz WB2PfUYqJgM4q1gAOM6SStsUrwGd1W05CdjcjHXVr1M0dPqj4Cb96hGqvYPEMsG41KIYjj1 9bfF1dYRoeQergwAB41wA== X-UI-Out-Filterresults: notjunk:1;V01:K0:zkzXebvPv2w=:BLMq/pALtTlL56w8+7RsGq a3etPs9LhApK68R8Iu5cGFUgbNQUDbzCdE3yiT3K1Hfm0h83of8HEE4OGdJR2I4yuE3sX3Nid dTZjVbbzn210zRuxKq/vvtaRDviA/4f6hJscZXpW/CKL1BILIJeuQ7GxxuiaKSytEGyfInnqL niuqI9qlu3JyblsBATNOsFb/it9jxA13TgEoFYrwFtICQ5fhOPLjLK43t1O6ZndZmQRNcgF/Y 4AFdqLnyaL4e8STUzpdtipfDK+0cJAe0exInFAkDVTvakXBFQGteSqj6XBMmM3npbjCyzZ4tA WkD3hb4y0ibmZKb4i9i99G6mu/J5Rr/Evmf5aw6R/TLE3zmfvtvXdYhtgEcThkphqn+9uQLDb vrtAL3poN6MoW5Cr+j2xDVCYcfEptVYJw5gqbDLmaIhCqkBwGNt3Y54ph4Usz9oso+jT2EIfh w2lX9RUNIFBBN+sCNgI3h+uDV+TVgErFI0UbJDVFPliwyPDfO/gZFhmT4hFp0u5K8PDDqdvzD VEPII/Yr6VIZ6HsTSi5zoGm4d9AyLcOJ1PjVXS0KmvGLVgvKM0XCfRxPsB6SvUVPEwO+N2iYy vSV/p3QGf+IlfEGwcp0W7f0q6IkfXavQDLUWDevKnsK84sBY7VDtWAeAZFGG5OvJewtExEENS sE9HRi2LRGsKhzNU+AsMvbUOgidRTa89K5nV77FvGq8vPQ+pYZIfYrbFrHOBnLUp/oJcVmY8N zyxvtzVtax9+lPnRPSnrkzNvZUcV3daYc097jkCcKI8tI/2+KujlhCtb1Wc= Archived-At: Subject: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 12:00:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --opUOst9RqqlirlmiJMEbdDQSaWWaUCUec Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi RD authors, Hi all, I have a question regarding the use of the /rd prefix in the path. The /rd path is used in the draft in various places, sometimes in examples (where the use of completely optional) and in other places where the use is recommended (but not mandated). The recommendation is stated in Section 6.3 regarding the use of the RD function set path. It is, however, not clear where in the text it was only used as an example and when it was used according to the recommendation. It appears that the use of the /rd in the path is only recommended for the registration procedure. Is this correct? Here is the relevant example: Req: POST coap://rd.example.com/rd?ep=3Dnode1 ^^^^^ +----- recommended Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 ^^^^ +------- example only Req: POST /rd?ep=3Dnode1 HTTP/1.1 ^^^^^ +----- recommended Host : example.com Content-Type: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 ^^^^ +------- example only Ciao Hannes --opUOst9RqqlirlmiJMEbdDQSaWWaUCUec Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXqcXFAAoJEGhJURNOOiAt6kMH/1YO4ZmZw/RvfTS91g/JAaDf k6aEhriXadaQT0fQqJIHXHSPQNNoxX/TY+KIKdhoxnLYpRuFHMSMiliv15j3cuvx /JKhtqiIxqIUHYyGAsc4v2mZwcHFy06mNaHbFImNETfh1l4YKT8PnlUiWD89CV3v zk3CrNMw1GeC0grfCc2jvHzM6Yqzqiy6/E3hT/5qVj+WNb7pgfGKSZZHOgFclVux XAsPSs4J8COl8ratPbt9zvZ7Pma/WTd/PoC/nPCHNCrCXG5ULc7Zh8upEjjr4W+y SiRFxOSp/NlXgeQ5r/btrMUehXJgJe73/WPbLKBfhkhPA8srhf8W+qmQUv8GtSo= =AGjM -----END PGP SIGNATURE----- --opUOst9RqqlirlmiJMEbdDQSaWWaUCUec-- From nobody Tue Aug 9 05:14:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9D612D53D for ; Tue, 9 Aug 2016 05:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVUVx3xEQ5KP for ; Tue, 9 Aug 2016 05:14:04 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D121212D0A8 for ; Tue, 9 Aug 2016 05:14:03 -0700 (PDT) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 8A3B6FB88B; Tue, 9 Aug 2016 14:14:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id DzCuyzRj5cB7; Tue, 9 Aug 2016 14:14:00 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3AA87FB887; Tue, 9 Aug 2016 14:14:00 +0200 (CEST) Message-ID: <57A9C906.3060704@tzi.org> Date: Tue, 09 Aug 2016 14:13:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 12:14:06 -0000 Hi Hannes, it's good that you bring this up. Section 6.2 says: 6.2. Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the path of its RD Function Set. There can be and goes on to describe how to look for the resource type "core.rd" to find the path to the resource directory "function set" (a term that we don't really like any more, but which will do for now -- this may be a bit like the OAuth "endpoints"; we need to find a better term for these sets of related resources). I'm not quite sure what to make of the recommendation in Section 6.3 to use "/rd" for the path that goes into the URI Template. On one hand, a convention like this can aid in debugging. On the other hand, conventions like this tend to ossify, and this turns the SHOULD into a borderline violation of RFC 7320 (BCP 190). I think I would be happier to change the SHOULD into what it is, a convention, which can be superseded by all kinds of considerations as per RFC 7320. More importantly, skipping the discovery step and going right for "/rd" would be bad client behavior and should not be condonable by that SHOULD. (The SHOULD is also making a rather implicit definition of when it can be superseded -- whenever the convention is "impossible"? What does that mean...) Grüße, Carsten Hannes Tschofenig wrote: > Hi RD authors, Hi all, > > I have a question regarding the use of the /rd prefix in the path. > > The /rd path is used in the draft in various places, sometimes in > examples (where the use of completely optional) and in other places > where the use is recommended (but not mandated). The recommendation is > stated in Section 6.3 regarding the use of the RD function set path. > > It is, however, not clear where in the text it was only used as an > example and when it was used according to the recommendation. > > It appears that the use of the /rd in the path is only recommended for > the registration procedure. Is this correct? > > Here is the relevant example: > > Req: POST coap://rd.example.com/rd?ep=node1 > ^^^^^ > +----- recommended > Content-Format: 40 > Payload: > ;ct=41;rt="temperature-c";if="sensor", > ;ct=41;rt="light-lux";if="sensor" > > Res: 2.01 Created > Location: /rd/4521 > ^^^^ > +------- example only > > > Req: POST /rd?ep=node1 HTTP/1.1 > ^^^^^ > +----- recommended > > Host : example.com > Content-Type: application/link-format > Payload: > ;ct=41;rt="temperature-c";if="sensor", > ;ct=41;rt="light-lux";if="sensor" > > Res: 201 Created > Location: /rd/4521 > ^^^^ > +------- example only > > > Ciao > Hannes > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 10 02:31:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1812D0D8 for ; Wed, 10 Aug 2016 02:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-ob33mXLdFX for ; Wed, 10 Aug 2016 02:31:17 -0700 (PDT) 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 A4DC412B02A for ; Wed, 10 Aug 2016 02:31:16 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id VMXD1t0074aYjWA01MXDeT; Wed, 10 Aug 2016 11:31:14 +0200 Received: from 2001:983:a264:1:9809:1e09:882f:5995 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 10 Aug 2016 11:31:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 10 Aug 2016 11:31:13 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57A9C906.3060704@tzi.org> References: <57A9C906.3060704@tzi.org> Message-ID: <009c0ecec6c3624520949baa9cccf554@xs4all.nl> X-Sender: stokcons@xs4all.nl (88V464WjCIAUvctSEFNtluk2E8qPhV4a) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 09:31:19 -0000 Hi Carsten, Do I understand correctly that you recommend to keep the current template wording? URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd := RD Function Set path (mandatory). This is the path of the RD Function Set, as obtained from discovery. An RD SHOULD use the value "rd" for this variable whenever possible. Peter Carsten Bormann schreef op 2016-08-09 14:13: > Hi Hannes, > > it's good that you bring this up. > > Section 6.2 says: > > 6.2. Discovery > > Before an endpoint can make use of an RD, it must first know the > RD's > address and port, and the path of its RD Function Set. There can be > > and goes on to describe how to look for the resource type "core.rd" to > find the path to the resource directory "function set" (a term that we > don't really like any more, but which will do for now -- this may be a > bit like the OAuth "endpoints"; we need to find a better term for these > sets of related resources). > > I'm not quite sure what to make of the recommendation in Section 6.3 to > use "/rd" for the path that goes into the URI Template. On one hand, a > convention like this can aid in debugging. On the other hand, > conventions like this tend to ossify, and this turns the SHOULD into a > borderline violation of RFC 7320 (BCP 190). I think I would be happier > to change the SHOULD into what it is, a convention, which can be > superseded by all kinds of considerations as per RFC 7320. More > importantly, skipping the discovery step and going right for "/rd" > would > be bad client behavior and should not be condonable by that SHOULD. > (The SHOULD is also making a rather implicit definition of when it can > be superseded -- whenever the convention is "impossible"? What does > that mean...) > > Grüße, Carsten > > > Hannes Tschofenig wrote: >> Hi RD authors, Hi all, >> >> I have a question regarding the use of the /rd prefix in the path. >> >> The /rd path is used in the draft in various places, sometimes in >> examples (where the use of completely optional) and in other places >> where the use is recommended (but not mandated). The recommendation is >> stated in Section 6.3 regarding the use of the RD function set path. >> >> It is, however, not clear where in the text it was only used as an >> example and when it was used according to the recommendation. >> >> It appears that the use of the /rd in the path is only recommended for >> the registration procedure. Is this correct? >> >> Here is the relevant example: >> >> Req: POST coap://rd.example.com/rd?ep=node1 >> ^^^^^ >> +----- recommended >> Content-Format: 40 >> Payload: >> ;ct=41;rt="temperature-c";if="sensor", >> ;ct=41;rt="light-lux";if="sensor" >> >> Res: 2.01 Created >> Location: /rd/4521 >> ^^^^ >> +------- example only >> >> >> Req: POST /rd?ep=node1 HTTP/1.1 >> ^^^^^ >> +----- recommended >> >> Host : example.com >> Content-Type: application/link-format >> Payload: >> ;ct=41;rt="temperature-c";if="sensor", >> ;ct=41;rt="light-lux";if="sensor" >> >> Res: 201 Created >> Location: /rd/4521 >> ^^^^ >> +------- example only >> >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 10 03:35:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B0012D697 for ; Wed, 10 Aug 2016 03:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10g4rBMI4TnL for ; Wed, 10 Aug 2016 03:35:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5650F12D505 for ; Wed, 10 Aug 2016 03:35:08 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MCtNr-1bNq4m15wB-009kdB; Wed, 10 Aug 2016 12:34:59 +0200 To: Carsten Bormann References: <57A9C906.3060704@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <6c29bd41-9d43-9fc5-8ed6-e10574e7a4c3@gmx.net> Date: Wed, 10 Aug 2016 12:34:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57A9C906.3060704@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8gDWXCkKa8JcORggRdeUPgSFAQcaUitoh" X-Provags-ID: V03:K0:yARZjwOQYnV5qh1tGgEaZTylab8ZDEeGiJ5ulv4fb4/uN/0f7Ok GACH1Xf8diVmSPluVvWS7lG22JV6sa7tMOEfBSctfLDt4D5CeziCF3P4DOnb8wOUoW9Ks9A eqSOzs3GB96mzWomwdZOb1ddA5N4pP0Xex/ThSJk2H60rJ4mfLNJ7LG2kuyLx0qjgDxY5w6 Ae+4qW1gF+8pRNrciIXww== X-UI-Out-Filterresults: notjunk:1;V01:K0:nMBvnVTSj6E=:2ykDPEi4DabjXHlNqV4XHn gMB82B0wHNAkFu2xtzs62urWq5pgP8g9pnK8hyXzDBs4e9vlbheIkmatYiAuaxFDZ6efRup80 +j9W9yCNHeNEwfyrUMspG3vbgP/cQSdLA0j3n0WVxdtDwo/2fXIvHZeOpfe0lf1yIHig+vz+r WgLqFHhsup6M++YkIamjwypqJmuTDI7mvLBwb3qmA94ERPG8Qjr1KWUtqogxVNGBILMvqslv5 /70/1HpCt/YGRTL53ikagi9heQBmTqoVsQpacCWpWxNQDEkyaAHSLPlBk1lDSeOJp3ZhRovVJ ksmbz9G1MvsjwtokJuPaaXZQdJ7qB8Dl97BpohN4uJi/xR64K72ATvIbtL9tnwfa6HoKxSa5D FgPGx//bQacigFZ9wv1SUPIus858wf3Hs4tnKV+0wh70STVPyXqb5sZQJiDtcV3ZRW7vVAOIf /F2rrp2NrAcvdwm/eCvhTVVD3IPdAyrk6/hQkUIYegKdomLiBIjgTl6DFvyyneEnbZK+hPTbA uut0w912Fnw/h9WPbjdWRoKTnlQgOAsmiJSbH/XMFE+QkwbTHgJYrK7iE0zf2JvqMoiLx6eJN S9Ck9y/cAr+c8FhyvpYkvDoFDXbpOMNTNgzK3vKZhdp0VdKy7RPSPimYZI6Nbwx9K28ClKnjn Ra9BbnyPj0Tvgb0YKzqITrcT/5QE/KLO5nloQSFBrIEP7upk2u5rgHRPJuI4vHEUVyt2xvBHc SHWbyOVHzelfvTvZgWRFPo++L3BPs3+cqEcUtolqSKJCoXrrVswCaDzFI5E= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 10:35:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8gDWXCkKa8JcORggRdeUPgSFAQcaUitoh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, I agree with you that 'function set' is probably not the best possible term and maybe there is a chance to replace it with something else. Regarding hard coding the path /rd instead of using discovery: I am not necessarily against hard coding since it avoids the need of discovery, particularly when it is unclear how often an IoT device needs to execute this discovery step. However, what I am less sure about is where in the document the /rd path is actually the result of hard coding vs. just used in as an example. Ciao Hannes On 08/09/2016 02:13 PM, Carsten Bormann wrote: > Hi Hannes, >=20 > it's good that you bring this up. >=20 > Section 6.2 says: >=20 > 6.2. Discovery >=20 > Before an endpoint can make use of an RD, it must first know the RD'= s > address and port, and the path of its RD Function Set. There can be >=20 > and goes on to describe how to look for the resource type "core.rd" to > find the path to the resource directory "function set" (a term that we > don't really like any more, but which will do for now -- this may be a > bit like the OAuth "endpoints"; we need to find a better term for these= > sets of related resources). >=20 > I'm not quite sure what to make of the recommendation in Section 6.3 to= > use "/rd" for the path that goes into the URI Template. On one hand, a= > convention like this can aid in debugging. On the other hand, > conventions like this tend to ossify, and this turns the SHOULD into a > borderline violation of RFC 7320 (BCP 190). I think I would be happier= > to change the SHOULD into what it is, a convention, which can be > superseded by all kinds of considerations as per RFC 7320. More > importantly, skipping the discovery step and going right for "/rd" woul= d > be bad client behavior and should not be condonable by that SHOULD. > (The SHOULD is also making a rather implicit definition of when it can > be superseded -- whenever the convention is "impossible"? What does > that mean...) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Hannes Tschofenig wrote: >> Hi RD authors, Hi all, >> >> I have a question regarding the use of the /rd prefix in the path. >> >> The /rd path is used in the draft in various places, sometimes in >> examples (where the use of completely optional) and in other places >> where the use is recommended (but not mandated). The recommendation is= >> stated in Section 6.3 regarding the use of the RD function set path. >> >> It is, however, not clear where in the text it was only used as an >> example and when it was used according to the recommendation. >> >> It appears that the use of the /rd in the path is only recommended for= >> the registration procedure. Is this correct? >> >> Here is the relevant example: >> >> Req: POST coap://rd.example.com/rd?ep=3Dnode1 >> ^^^^^ >> +----- recommended >> Content-Format: 40 >> Payload: >> ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", >> ;ct=3D41;rt=3D"light-lux";if=3D"sensor" >> >> Res: 2.01 Created >> Location: /rd/4521 >> ^^^^ >> +------- example only >> >> >> Req: POST /rd?ep=3Dnode1 HTTP/1.1 >> ^^^^^ >> +----- recommended >> >> Host : example.com >> Content-Type: application/link-format >> Payload: >> ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", >> ;ct=3D41;rt=3D"light-lux";if=3D"sensor" >> >> Res: 201 Created >> Location: /rd/4521 >> ^^^^ >> +------- example only >> >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core --8gDWXCkKa8JcORggRdeUPgSFAQcaUitoh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXqwNSAAoJEGhJURNOOiAttYMH/2oZtLWZhMuKV47iDPteN/Dc vPeeuheVyjnV3pryjM0MV80LZdgADbVem37GDhMU4KupWDoR6AKaeg4EDIX6XvdZ tgmU0yL8F34ScLydXoquLrDBXo3VNaNKKCGFYYgyzCstFBIVVxxj2Qvi8EdLxHm+ ruC9Ct7mkQJxK2Mwd5STJ0D5NdmADTtZlmEZNc3VY4lvCJ+B+GcRoNMMqXBj+RoT xbPrPV/DChA/fUKGI2ySNrlGRYRzHrSOvPcaOUtUVVNS1gZcn6r46SDCLblX7zrd drImJY3OGPTudgwOVz5vGz80XZD+4vHZWBHwWqNfupCZOfqZxmsKo+xvARbU3Xc= =6o0n -----END PGP SIGNATURE----- --8gDWXCkKa8JcORggRdeUPgSFAQcaUitoh-- From nobody Wed Aug 10 04:39:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA9912D739 for ; Wed, 10 Aug 2016 04:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuiHYo5iJvOv for ; Wed, 10 Aug 2016 04:39:33 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16D812D159 for ; Wed, 10 Aug 2016 04:39:32 -0700 (PDT) Received: from mfilter49-d.gandi.net (mfilter49-d.gandi.net [217.70.178.180]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 0A58F41C08A; Wed, 10 Aug 2016 13:39:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id thfgNOXw_JPW; Wed, 10 Aug 2016 13:39:29 +0200 (CEST) X-Originating-IP: 134.102.218.123 Received: from nar-4.local (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 20E0D41C099; Wed, 10 Aug 2016 13:39:28 +0200 (CEST) Message-ID: <57AB1270.3060801@tzi.org> Date: Wed, 10 Aug 2016 13:39:28 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: consultancy@vanderstok.org References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> In-Reply-To: <009c0ecec6c3624520949baa9cccf554@xs4all.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 11:39:34 -0000 peter van der Stok wrote: > Hi Carsten, > > Do I understand correctly that you recommend to keep the current > template wording? > > URI Template: /{+rd}{?ep,d,et,lt,con} > > URI Template Variables: > > rd := RD Function Set path (mandatory). This is the path of the > RD Function Set, as obtained from discovery. An RD SHOULD use > the value "rd" for this variable whenever possible. Maybe a better wording of the last sentence would be: As a convention that aids in debugging, a server can use the value "rd" unless it prefers a different value. Gets rid of the SHOULD, and makes it clear the the server is free to choose (as per RFC 7320). (And maybe we can get rid of "Function Set" in a separate effort.) Grüße, Carsten From nobody Wed Aug 10 07:11:20 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2128B12D73D; Wed, 10 Aug 2016 07:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147083828013.20506.13293821718138167588.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2016 07:11:20 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-etch-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 14:11:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Patch and Fetch Methods for Constrained Application Protocol (CoAP) Authors : Peter van der Stok Carsten Bormann Anuj Sehgal Filename : draft-ietf-core-etch-02.txt Pages : 17 Date : 2016-08-10 Abstract: The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-etch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-etch-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-etch-02 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 Wed Aug 10 07:25:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F60712D6AE for ; Wed, 10 Aug 2016 07:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4iDzSbcy-AV for ; Wed, 10 Aug 2016 07:25:07 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE1212D0DA for ; Wed, 10 Aug 2016 07:25:07 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 50F1DA80DC; Wed, 10 Aug 2016 16:25:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fIympddlosBl; Wed, 10 Aug 2016 16:25:03 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8139AA80DD; Wed, 10 Aug 2016 16:25:03 +0200 (CEST) Message-ID: <57AB393F.4090100@tzi.org> Date: Wed, 10 Aug 2016 16:25:03 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: core@ietf.org References: <147083828013.20506.13293821718138167588.idtracker@ietfa.amsl.com> In-Reply-To: <147083828013.20506.13293821718138167588.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-etch-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 14:25:08 -0000 The authors have posted the post-WGLC version -02 of draft-ietf-core-etch. This should handle all the WGLC comments. The detailed changes are at: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-etch-02 The summary is: -- Lots of editorial changes (thanks for all the input!). -- The examples have been fixed (and use the numeric Content-Format values, including the unspecified "NNN" for the Content-Format value of the hypothetical media type application/example-map-keys+json). -- These fixes include switching to 4.00 (Bad Request) with a diagnostic payload for the example showing a server reacting to a non-idempotent patch payload in an iPATCH. Remember that this is an example; there is no intention to elaborately specify what a server has to check for an iPATCH and how it should react if that is malformed. -- Technical change: 4.22 (Unprocessable entity) is now explicitly registered in the sub-registry "CoAP response codes". The authors believe this is now ready for submission to the IESG. Grüße, Carsten From nobody Wed Aug 10 08:40:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8415512D5CC for ; Wed, 10 Aug 2016 08:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_wtK8cd0-4C for ; Wed, 10 Aug 2016 08:40:22 -0700 (PDT) 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 E50A012D5F7 for ; Wed, 10 Aug 2016 08:40:21 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud3.xs4all.net with ESMTP id VTgK1t00C4CYHle01TgKHX; Wed, 10 Aug 2016 17:40:20 +0200 Received: from 2001:983:a264:1:51e3:d1c9:a16a:8c81 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 10 Aug 2016 17:40:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 10 Aug 2016 17:40:19 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57AB1270.3060801@tzi.org> References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> Message-ID: <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> X-Sender: stokcons@xs4all.nl (20U/SkqS0YeC3GvSFkv7MuadAx7fb97I) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 15:40:23 -0000 Hi Carsten, Thanks for the suggestions, but the changes do not look that essential for the iteroperability and implementation to me. I would prefer to get the draft out as is. Hannes thinks differently? Peter Carsten Bormann schreef op 2016-08-10 13:39: > peter van der Stok wrote: >> Hi Carsten, >> >> Do I understand correctly that you recommend to keep the current >> template wording? >> >> URI Template: /{+rd}{?ep,d,et,lt,con} >> >> URI Template Variables: >> >> rd := RD Function Set path (mandatory). This is the path of >> the >> RD Function Set, as obtained from discovery. An RD SHOULD >> use >> the value "rd" for this variable whenever possible. > > Maybe a better wording of the last sentence would be: > > As a convention that aids in debugging, a server can use the value "rd" > unless it prefers a different value. > > Gets rid of the SHOULD, and makes it clear the the server is free to > choose (as per RFC 7320). > > (And maybe we can get rid of "Function Set" in a separate effort.) > > Grüße, Carsten From nobody Wed Aug 10 18:05:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081B012D8AF for ; Wed, 10 Aug 2016 18:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0K_jhw3-GdV for ; Wed, 10 Aug 2016 18:05:21 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0133.outbound.protection.outlook.com [104.47.38.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AED512D898 for ; Wed, 10 Aug 2016 18:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XlpHCFR1huEtcADUHz0D7MyxvlgImP0W04aWa2qouwk=; b=k2NiXheGVjPZ6yIhPJOHCwEjfjemPkQODhfV81SBOj/s9Eoh1pEL+VXS25lrIKGC6CPFFdYA1CEHiylq7bqu62tCu/015RqWQOFV9Kb2XhMhNnpMaDyXqKK2ZaPhgbGuk+iodFXie25FtoUPp/pPJEohfGPv1wOU/cmpDqaNmXQ= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2721.namprd03.prod.outlook.com (10.173.144.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 01:05:18 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 01:05:18 +0000 From: Brian Raymor To: "core@ietf.org" Thread-Topic: Updates to coap-tcp-tls Thread-Index: AdHzatCWVXEOdWrbQLiOhi+qiefTng== Date: Thu, 11 Aug 2016 01:05:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 7fdc9022-6dea-4b1b-e881-08d3c1838fc6 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2721; 6:Rqyr5AYl9mQS5cGB44bDhFY+jZu6rM9iKv33IkINu7Ye6GwiOqKFmP22E1VX8ImnxGO7oFX2Z+1sEtI8AurMUCRXeuvtME1XXo9DlMNON25SFj3IQN2rjVwsCF7RStsX+hrTfJEaFx49lPA7tLi+VkcuXEAf7puHSfMNC8oGDKQsDzaXnAKCi1T4p0Tc6N2e88+vh6gPcoE/uFvI7eM+heiRDPvMttR9Nt7/eR1nA+4m0Zq504ZoKcPTPIw3K4qHS+uQc6l+ZtohLtwJmTNtyhZ44aeNa9cpnyzZAZxhoHYJKeqx3cVOFkQCScBOPGKJViy06RzVhl+aA5A9GwF8dw==; 5:F/phesfuvnaKaHQrz5ZtMV7b17ar/NmtODZy7lM+EnoxSllSnC8dPFVeQuas++Y52TAQauZ4N05B5m+xokb/mKFTpEGkQIn4iX+GT2ZTYIyR9Aw04ULIIgTcbA2a4wJjlaAk9nzJu9vW+7nGppA1XA==; 24:4NcUhzIEGPX4La+/JYqtqeBckE6bh2/XMCTKYWGiFL6dk1Bmf8LMsgXuGI+gHhEisAqdo31F1CHg4xmdp1vfes8rbO1HYGshX85iE0+aeQ0=; 7:KPqwE8NRC2Y0Khc3/ZBdsbm4OI37yyjnMTxDHAlHWD2wvuMGtY4SdcxnnnSCp8h1fXFCduJEmOIOqmmsc61Xwkjt7PMqHGmCPXzUEoe1bhvzvVRdRwpwq4iF02zQYnZDtxixcg4+p3VidsxEdF5Llo5fOGa2O2u1nPEp2JEbLHpCZPcywqU8ARpkJxaiitMcfmgQmMXkTvJUfzvOV12djEYQFCaOvforErl0Y2mFT+PsuH5rTxcQOedzPLKsizBD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2721; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040170)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2721; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2721; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(52044002)(189002)(86362001)(8990500004)(10290500002)(107886002)(10400500002)(102836003)(6116002)(189998001)(3846002)(97736004)(110136002)(5005710100001)(2501003)(66066001)(305945005)(87936001)(586003)(2906002)(10090500001)(99286002)(5002640100001)(105586002)(230783001)(86612001)(3280700002)(77096005)(54356999)(9686002)(11100500001)(50986999)(450100001)(2351001)(15975445007)(106356001)(229853001)(33656002)(5640700001)(7736002)(7846002)(74316002)(8676002)(7696003)(101416001)(122556002)(68736007)(81156014)(8936002)(3660700001)(92566002)(19580395003)(2900100001)(76576001)(81166006)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2721; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 01:05:18.4784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2721 Archived-At: Subject: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 01:05:23 -0000 I've started to address the open coap-tcp-tls issues - https://github.com/c= ore-wg/coap-tcp-tls/issues - discussed at the IETF 96 meeting in Berlin. M= y intention is to publish coap-tcp-tls-04 on or before August 22nd. For the TLS related issues: https://github.com/core-wg/coap-tcp-tls/issues/8 https://github.com/core-wg/coap-tcp-tls/issues/11 I've created a draft pull request - https://github.com/core-wg/coap-tcp-tls= /pull/52 For the ALPN issue: https://github.com/core-wg/coap-tcp-tls/issues/4 I've created a draft pull request - https://github.com/core-wg/coap-tcp-tls= /pull/53 Please review and feel free to comment on either the mailing list or in the= pull requests.=20 Thanks, ...Brian From nobody Wed Aug 10 23:29:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62E812D14F for ; Wed, 10 Aug 2016 23:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVZxjQzO34Oi for ; Wed, 10 Aug 2016 23:29:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B69126FDC for ; Wed, 10 Aug 2016 23:29:36 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LnPnu-1b0Icf2zNe-00hd7S; Thu, 11 Aug 2016 08:29:31 +0200 To: Brian Raymor , "core@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> Date: Thu, 11 Aug 2016 08:29:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="37pFUp6C6kM0ikrxPu0qTdsfNutGk2Fe0" X-Provags-ID: V03:K0:xCpapSpzw0qVhk1YE+91efKHduUnFNXXtvTckNaAwgqhPGDbwj7 c9g4vJPXPhcfFVm+JHdzy4zUiDbmOAHvz5HjkfHzSrFn8DN+SBUPckuWNpTcVbWhSosw347 Lp1Q4oejyciV/MxVkyXW/yxHZpQirEkSEJGVNX8cmmp+QPoj2VK+zmeZ5flMBcz63YXlXHZ jF4G6RNDuCr+s/UzAedwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:hANqEJy7LyI=:CUIBwTHfFY3Z7tsonJZCK+ scRFBBmmWZhc+59LiCrHKr++AYw1j7MANQNoodMIVnwKiZrHVTfvsblxTv9sQ4mtI5u1//VgN EvfOFBgcMFDTBHxwpjCNsDjZ57Fh9URsDYbU6rZXTmLrOtNYZPbrAG0ZQDryPazwsR9kH8g1e ziffBaCOY011m1TfPe+8C9IZGQztvLpCXcjIwECEHUNmz0fMHRVZK54mwlxj5Q7EIPEvdkAfK Y/v7DSYI9obXzBa7MOxe9K0o/GQsf91mvomeAPmP9xr49nlGv5tZcnvTqzrVGFm/6g46Qm442 PgFuYdk1ZsI/Iuf7rxmhHzP9IwnKdCYYBMHgvA5fH1Ft1s4A8O+LjEyU+7EZGNMxj+SWewanO LhsOa+8AmPfJV6AExJ4FOucOa3zVUBC3ItqKET2P8id+ogOfTcN9Cbuv2Li6m+zotBi19+63w Js9/h8ke99VrRE2zrcwUSGaiMjLEoPSeKyt//Wyyo58UDNC4ddExiuyywzW2m2TUQeWFzINMl v6TE+Q1o4ylSFRc3j4OM8Awy0JVkkIymLnmBAVpa+53CIAfIQtSSOXE4z3AAJJfWs1NoHSJ+f poXKcpp+jJqVUoV9HUYFWn0eoYEJzIrczJe8iJaYMloCTEw9ZMfCXyS1KHHkpFplSjOK8JxVz Dw9LzeV36psljRAZ+RffwNEjP1NqR8U33QCsBg4hJ6pvNeabbVofuv4mgJ3B/OJ4E8r7r9jzd aC3leiG9aKTjHjTYsih32fAGlVi1T+CFwYFXUPPPb2OFY7EZikjjCQKEWDE= Archived-At: Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 06:29:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --37pFUp6C6kM0ikrxPu0qTdsfNutGk2Fe0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Brian, thanks for the update. Regarding the TLS / ALPN case you have proposed the following wording: With the exception of TCP port 5684, implementations that support CoAP over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the "coap" protocol identifier defined in . What about using the following wording instead: Implementations that support CoAP over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the "coap" protocol identifier defined in unless in deployments where ALPN is not supported in the TLS protocol stack. Implementations MUST use port number 5684 for those TLS implementations that do not support ALPN. Regarding the pointers to RFC 7525 and RFC 7925. We should only reference RFC 7925 since the recommendations in the two documents are different and would lead to non-interoperable implementations. I did, of course, point this out in my reviews but the authors were not interested in IoT related concerns. Ciao Hannes On 08/11/2016 03:05 AM, Brian Raymor wrote: >=20 > I've started to address the open coap-tcp-tls issues - https://github.c= om/core-wg/coap-tcp-tls/issues - discussed at the IETF 96 meeting in Ber= lin. My intention is to publish coap-tcp-tls-04 on or before August 22nd.= >=20 > For the TLS related issues: >=20 > https://github.com/core-wg/coap-tcp-tls/issues/8 > https://github.com/core-wg/coap-tcp-tls/issues/11 >=20 > I've created a draft pull request - https://github.com/core-wg/coap-tcp= -tls/pull/52 >=20 > For the ALPN issue: >=20 > https://github.com/core-wg/coap-tcp-tls/issues/4 >=20 > I've created a draft pull request - https://github.com/core-wg/coap-tcp= -tls/pull/53 >=20 > Please review and feel free to comment on either the mailing list or in= the pull requests.=20 >=20 > Thanks, > ...Brian >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --37pFUp6C6kM0ikrxPu0qTdsfNutGk2Fe0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXrBtLAAoJEGhJURNOOiAtM7gH/jkKMAvTcGk4wUk2wRL8mDAm 2Uiygjt4LYF8xsAFJ4TPs2Gn/vWjmOv9ZmrvGsa6q+sKpkZQeyNvvED+xRRGYrFh ibUcTvb6fb63U2gnx7yDoHBObDKREvMBkVk3mYETuTu4ZUIaUWUz38LfmTA1Jaw9 eqcTxIcohHYnuCvF79bMrX5j+VXX+Ai0LKMlLae8sharR8BYt/HRa+mEoXV90QmA Em4hMU1yLVGkchSQB2SXRXmSpVnRk1xq5SKMKsxYDefW4XExKveBuaPTmU77xduD BUcmKO2Cj5bIBh0WVRSB/6gRns4J4NCvSlI40rJopVCRUVaJgc7dB8RzE1XxT8w= =VBgx -----END PGP SIGNATURE----- --37pFUp6C6kM0ikrxPu0qTdsfNutGk2Fe0-- From nobody Wed Aug 10 23:31:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214B212B031 for ; Wed, 10 Aug 2016 23:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqSbS_Cc6ojD for ; Wed, 10 Aug 2016 23:31:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF63126FDC for ; Wed, 10 Aug 2016 23:31:24 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LwrS8-1b9kVc10fI-016PgI; Thu, 11 Aug 2016 08:31:12 +0200 To: consultancy@vanderstok.org, Carsten Bormann References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 11 Aug 2016 08:31:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6dp5blmjetb889JIHgriN8oa3kpC2Rp7c" X-Provags-ID: V03:K0:JZYnxpc0rR1bgdsn8EewQ3niy/+sSvTIprrOX07Mc1eYl69qe7l Lb53lmd5MZYSY/xNYsWEv4V11FWof5nrBpSW15WY7mjlB1nmBsQSYiGUO2UB6NpNH/YxecX xVVIn9EKaHPykne/Q1FEfmxKqn72rYyGseYn8X3TgelK1KtT2JqB6nXsEN5/es7woFZJ46l Fb6Hi0st1LPUcHI/npbsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:xPDpshSh22I=:eHA/yvkiDZyTnqtrj9OrVj +1nhPjqDDx8j0WADr6WjcvuTr/5yJpgtoXo5Af+8I+Vdzy8fuQ2tw715APcC/4yS6jmqkQRAh CtHgUAFoeeKaZSFOuulRJGOe5v6qI3n7e4MboRkDSmaJ44eJeTvLx91OxhoCVzp6QDECwlJhf 1W6AAE3dXaUrMzuyaxOuDx+vDUBvJ0HA8/PphODlEGV5+BEl0tO/d/MRRucxPvfKFrsTjl3dT p69yDTKOERpRw4V4Cv3k7D/GeuTEp3pEPiwfnFtSZc92OkBA5fpRADmFnTRfwgZV5vDc1ueUs mU/0E2NbWAAA+xeDAYMNiXIuqF5QqzgzutZRfBU/W2fhbp/bfDdo1Ya/WW60AxKL9ERQ1kLHM UVdnNpSY4qZagRsQjLaScsrmHDTM+Wvd1sT3yGP6o9nQ83UhAQMpwF+CNVBGTfB30lc4J7WDY PDQo+VdxLECO5UBuAdljKegtHbC3mrAzqmLqBxA7EPE1nFFiIaAkD6WUpM7R4vEh+QOUoy0YL C0aJDkgVCjP5ECAcr6oo4jUZIcjQOVqUX0xth2UHyzjnUepFbsb4wf8XhM8/DR1LErQm/kPPE IeRk4PC7A3ZizUiforPLrE+TdOPBuicbHrgfIhMuixnTNHaHwqmcIMTqWi5snnZbma7mwiMtY LPUBZAnLZddpmc9EH4LMIQZ+a0T2cPzxvFhFL8QmDUs9kRxEzihP0TV3LP3xwzSE+KJ6iF9kQ 0V8AsndvkC+EM7ioIq97Pua4YbZHw18IKb17RPqfFtE9VYTeHEhLfMthcHs= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 06:31:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6dp5blmjetb889JIHgriN8oa3kpC2Rp7c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter, I only want to have clarify what use of /rd is there in the examples because of the recommendation and what has been chosen for convenience. Ciao Hannes On 08/10/2016 05:40 PM, peter van der Stok wrote: > Hi Carsten, >=20 > Thanks for the suggestions, but the changes do not look that essential > for the iteroperability and implementation to me. > I would prefer to get the draft out as is. > Hannes thinks differently? >=20 > Peter >=20 > Carsten Bormann schreef op 2016-08-10 13:39: >> peter van der Stok wrote: >>> Hi Carsten, >>> >>> Do I understand correctly that you recommend to keep the current >>> template wording? >>> >>> URI Template: /{+rd}{?ep,d,et,lt,con} >>> >>> URI Template Variables: >>> >>> rd :=3D RD Function Set path (mandatory). This is the path of= the >>> RD Function Set, as obtained from discovery. An RD SHOULD u= se >>> the value "rd" for this variable whenever possible. >> >> Maybe a better wording of the last sentence would be: >> >> As a convention that aids in debugging, a server can use the value "rd= " >> unless it prefers a different value. >> >> Gets rid of the SHOULD, and makes it clear the the server is free to >> choose (as per RFC 7320). >> >> (And maybe we can get rid of "Function Set" in a separate effort.) >> >> Gr=C3=BC=C3=9Fe, Carsten --6dp5blmjetb889JIHgriN8oa3kpC2Rp7c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXrBuwAAoJEGhJURNOOiAtZo8H/0Fr5eJ4ONK81Eq1CYzgKqSl hiAhFnVIbqwLmI2B6s3hti8v4xiKuLg9PNFRProWYx4W0TKIaHqYDBT158fWFmS3 Sfeci888BL5ZFyOuBgzs4W9NEVqH9Rj4r3W3yDbtY/G9oqdphiMq71QjBgNxTDpl mHl8Cs0kwdUjDsh836kaY/UmBf68cER8PEprN7Gnv+3jKH5eJebfilRPU+2FWCDc Le20UiXNBOS3Nsl5oxiP5+TinEAQEvNp2pwxdlloFudRp80P5x4UCxMDkxBSBSWI jDxGsuVX9n8Kt1W35M3pVrBqyKelRDHwcpKYIwrOSx8+rPYT3CUDCDQ+sA2TKIo= =GzKv -----END PGP SIGNATURE----- --6dp5blmjetb889JIHgriN8oa3kpC2Rp7c-- From nobody Thu Aug 11 01:16:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FA612D6AE; Thu, 11 Aug 2016 01:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPXnlrmnJ8Hn; Thu, 11 Aug 2016 01:16:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58B012D61B; Thu, 11 Aug 2016 01:16:18 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMShK-1bZOn53ppG-008FxM; Thu, 11 Aug 2016 10:16:06 +0200 To: Jim Schaad , draft-koster-core-coap-pubsub@ietf.org, core@ietf.org References: <04fe01d1ee01$35bf9120$a13eb360$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <0b8fc8d2-59b1-31a5-b201-cbdb81489497@gmx.net> Date: Thu, 11 Aug 2016 10:16:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <04fe01d1ee01$35bf9120$a13eb360$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rWXDIN94pjmD7bWRI9TQD6LkjXGvUUnhH" X-Provags-ID: V03:K0:4J3Vhz40fRmlsoEn3EFP2lxWz1wIeV0M1/rOjSb/fnp2Z/zDodx IisjxlVfNIZIVwbTV3o2spmTLuAQt4D331hwPTbAJvdUg2WklCqW9rS3gE+T4J8pzkMuR0B WIg8yrxnNGGKfDeUg+X2cHVfeHjGPtoV/GHyHh/ht4W5aOpYWgwGVvKmKtpe3uyPM6awyZP B7SICd1ogvruCMj7+a5OA== X-UI-Out-Filterresults: notjunk:1;V01:K0:lG3XXMzp78I=:eN73Pui4yS/g2qq0QbV75v CffSJft4f8y3pKfKjR/ONvpG+yejSob+HpIKMfaRgCpOth1cEZkDIeCifpaUpl55mvh+Eyb0e /qGfTphwbVAYZ6W7APl/u/LaQ3KbV4FaG3BUoPQeb0uShjwAdAFDQquzGi2XoS2vYzIiygtGV vGfLnq9Jp9HUuKBKousr2GaYKrKIB9WIdb+VZImSb4Bk007qt5x1QF8gPDnlVSabFm3vjxqQg NFwGnXYLu+eb3Tl6sk0FHB0D9hPs4P2hJ2shWH5E+GWkzOiBTN4tYs661vxNfUq1JHeikcutx DcVRepo0nt/hXRKAJPEgR1YiKn59ockjdL43vTBEcy+rC5EyBUXtEgK5kOM7bmXBoaA4f3q8K Y+Ivz5f7UV0HSIC1NyftwmKafg259xE9Jd7QkFR6g1EiPY7+Pk1FthYuUsHF9uSuQ/pCRnpaM 0/47Vz02WrSAqtYKcJs7QQKcLj/EtY8D/f2jLUZX1o+KmxkdGf6EEoPx9V7cm8nzW5LdWf3Gf bsSc7evOn4A1ouPpsMMKi7M44pm9e8y5wl8MbGsU6z+oNIbjglruJNd7O3bl278U6pjhRIZfF RsnPv4gzvNjwri74XTkwOndTect2XnmubA/XAOEDGT+SGvCi8dmgmot95F2cNJptxXLfUD3D/ NR6XNLdj3W/+erMuGuz/yD7+IhfjUNp7Tz94E7HggyxVhTyk+7otmu+IqAELrXVxI0ewlah5r /mnGQm6ZbeNrBW0+hm+ZUDy0OT7MPK3fqeOUVu01eutAyipcvNEOfiaPPR8= Archived-At: Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 08:16:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rWXDIN94pjmD7bWRI9TQD6LkjXGvUUnhH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jim, let me share my views on this document. On 08/04/2016 05:35 AM, Jim Schaad wrote: > I have a hard time saying that this is ready to be published, but that = is in > part because I think that the security aspects that are not being addre= ssed > in the document are important. >=20 >=20 > Section 3.2 - The phrase "and potentially buffer messages" is causing m= e > problems. By definition it must buffer the last data value that it > includes. It would be good at this point to explain exactly why it is > buffering messages here. I assume that you are talking about the flow > control issues that are discussed later but I don't know this. The reason why the pub/sub broker buffers messages is because the IoT device is sleeping most of the time. For that reason, it cannot always forward requests from applications immediately. This is functionality called 'queue mode' in LWM2M and other terms have been used in other IETF documents. In my review I have been wondering why we aren't re-using the concepts from LWM2M here. Regarding the "topics": I have read this a bit differently. For me, a node has resources and it publishes those. Then, there are applications (Web applications, smart phone apps) who sent requests for those resources. These resources have to be identified somehow and in LWM2M there is a specific way of addressing the standardized resources (and objects), as described in https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf. Maybe you want to be more generic here but I think it is important that there is a standardized structure here and that we are not only talking in the style of MQTT topics. Ciao Hannes --rWXDIN94pjmD7bWRI9TQD6LkjXGvUUnhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXrDRDAAoJEGhJURNOOiAt+goH/3bhPvQtoml8gm1uUWxLsfLs HbwwJoMz7iKqnJSGRldLISJPs/jgau058lpI9aFAtC5GmUbJkGqH7uFu7doWX1Fm 14DSoEuIKXcuI9r2Hu9XDdtHe1wzxpjLi27hadxmBUqHS5WjY4wG9GsFwDY2TEwR xy/xjAC6hcOLBM/eCK2fiAx/qAMGcKPhQMPCl9D1SjvfbJnZ7wBybEzw4iWPUaMe fypGFmF/LO9+HwT+R7wuVR80dvO7xXWYiMYcFwn/X6aRjL45WbOG68Icn2qqkkWC b8QquHPnQMU3tE28mO+XnECq66zJbSejsuy6IpRovgU8dFTm/t/xjBfsDfZ8boI= =8Uf3 -----END PGP SIGNATURE----- --rWXDIN94pjmD7bWRI9TQD6LkjXGvUUnhH-- From nobody Thu Aug 11 08:23:04 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4D12D794; Thu, 11 Aug 2016 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOr-hLkIiciz; Thu, 11 Aug 2016 08:23:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A829E12D7A5; Thu, 11 Aug 2016 08:23:00 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 11 Aug 2016 08:34:25 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , , References: <04fe01d1ee01$35bf9120$a13eb360$@augustcellars.com> <0b8fc8d2-59b1-31a5-b201-cbdb81489497@gmx.net> In-Reply-To: <0b8fc8d2-59b1-31a5-b201-cbdb81489497@gmx.net> Date: Thu, 11 Aug 2016 08:22:08 -0700 Message-ID: <00c001d1f3e4$21b973b0$652c5b10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG3pJDxelmvAuing/csVaSoHKSuEAHt2AncoGkPCvA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 15:23:02 -0000 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, August 11, 2016 1:16 AM > To: Jim Schaad ; draft-koster-core-coap- > pubsub@ietf.org; core@ietf.org > Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05 > > Hi Jim, > > let me share my views on this document. > > On 08/04/2016 05:35 AM, Jim Schaad wrote: > > I have a hard time saying that this is ready to be published, but that > > is in part because I think that the security aspects that are not > > being addressed in the document are important. > > > > > > Section 3.2 - The phrase "and potentially buffer messages" is causing > > me problems. By definition it must buffer the last data value that it > > includes. It would be good at this point to explain exactly why it is > > buffering messages here. I assume that you are talking about the flow > > control issues that are discussed later but I don't know this. > > The reason why the pub/sub broker buffers messages is because the IoT device > is sleeping most of the time. For that reason, it cannot always forward requests > from applications immediately. > > This is functionality called 'queue mode' in LWM2M and other terms have been > used in other IETF documents. I agree that having a 'queue mode' would be a nice feature, but I do not believe that this is documented anyplace in this document. Doing so would require some additional text. The current text says that messages are always forwarded when they are received to a client. If the client happens to be asleep then it needs to go back and ask for the current value when it wakes up. > > In my review I have been wondering why we aren't re-using the concepts from > LWM2M here. > > Regarding the "topics": I have read this a bit differently. For me, a node has > resources and it publishes those. Then, there are applications (Web applications, > smart phone apps) who sent requests for those resources. These resources have > to be identified somehow and in LWM2M there is a specific way of addressing > the standardized resources (and objects), as described in > https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf. Maybe > you want to be more generic here but I think it is important that there is a > standardized structure here and that we are not only talking in the style of MQTT > topics. I do not follow how this came from my review. Is this an independent item or is it following from something that I asked in my review? Jim > > > Ciao > Hannes From nobody Thu Aug 11 09:14:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DC312D5CA; Thu, 11 Aug 2016 09:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WNWqj4t2CJj; Thu, 11 Aug 2016 09:14:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A74126D74; Thu, 11 Aug 2016 09:14:47 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MfVYB-1bsbL7235f-00P6WV; Thu, 11 Aug 2016 18:14:34 +0200 To: Jim Schaad , draft-koster-core-coap-pubsub@ietf.org, core@ietf.org References: <04fe01d1ee01$35bf9120$a13eb360$@augustcellars.com> <0b8fc8d2-59b1-31a5-b201-cbdb81489497@gmx.net> <00c001d1f3e4$21b973b0$652c5b10$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <289ba921-e331-de8f-45ca-fa8dc6d61fd8@gmx.net> Date: Thu, 11 Aug 2016 18:14:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <00c001d1f3e4$21b973b0$652c5b10$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rnTJR6ko2obvsLOHsWe76wWPN0Ll7PTn7" X-Provags-ID: V03:K0:FpN3uJaWnZVBCPilBR0pWfLTNAyuKp6ho1LizGIP+vk4cYIWSFS h0VdQcKeRKLLSijb21YBEuSWRHHj+Ak1s3meqPXYVEEQIx3QdMNtO/Wnxyv31VJDAtdwz71 y/Yj+mqROnmlQEnNasA6HWOdeznsThedBZ/eVK+ZPCUJ6zFUFsIK27LsK2tNSa5lLUUjDVM 2ebDThwom4H/j0DCJghpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:MTfFE/FlLW8=:WXQM0kc0rim/ap74ZxYX9e 0z/vpNM4zOa4V9EqhLQG3f55tmnpsdC4ON5nf8foPdCnAj7lJ4Skf7B05CcFrRsBKQsdtGkFf Hwc3h7Db3Mv+1KivWf7BsGTd+AQseweUrWw7p1H7p0LrmcbDFYFCamsech5NX/SIW6XyNEd06 s3ZL5eiMr4UanCDp6e3A8sPn2pzqUJyOlwfkcUJRFk5NCA+E/Q5r6RHTbLduUm9bcvY//RrUU 8rOTcE4eRm7a1AjvFV3iScc6juK1sDb2JVczkR27v4WbPnDec31+I52jRDVdmPpfM35myvd0i DqwcDMzr4NWKNsbXPZ7h+/qQujy1t9TLPwVA4oX5TLqAROqqLkE18qXgwGbDZvXxPXRkXV7gB 3tom9blAJfRnUnG5n0XajmG8IBkNoe444ADfRzkeSRm16uXpy55YzGjvVbz3AJQa2PHjCYqrL 1A6g1vseYO6wn/rMa1FUyprCvWjIb13ThbAqvTu4kPY5XJN3pOV9UjyIm2XIQ1mGb3ieJF2l3 a9GywXCYQf3e6JkCRjn2CNWotiazJscA91Y9kwEjwwSwZxTyl6Z/bwmv8Yb4OboASt3yhNTdR uZcGTzGaVtDZZSqss5Hhn8vJZaMdWgsT3uD9jZHk/Q0YQL89H/SFbAGYVx9WDtgFHmbSAc2qn gtz/CUCzZ3bDKebVtR4B5iQpKzbdPi835FFABrXJsvC44I4bwsQMVdy3CZwgC/INyUS+Ng8ti qe4opWwvwsgSanuFlYkYVQuh75SoQiSRZMnIJaJ5Z5Oloc0WxNyrcsVaLYw= Archived-At: Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 16:14:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rnTJR6ko2obvsLOHsWe76wWPN0Ll7PTn7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jim, I agree that there is more text needed on the support of so-called sleepy nodes. I may have over-interpreted your remarks about the topic. Ciao Hannes On 08/11/2016 05:22 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Thursday, August 11, 2016 1:16 AM >> To: Jim Schaad ; draft-koster-core-coap- >> pubsub@ietf.org; core@ietf.org >> Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05 >> >> Hi Jim, >> >> let me share my views on this document. >> >> On 08/04/2016 05:35 AM, Jim Schaad wrote: >>> I have a hard time saying that this is ready to be published, but tha= t >>> is in part because I think that the security aspects that are not >>> being addressed in the document are important. >>> >>> >>> Section 3.2 - The phrase "and potentially buffer messages" is causing= >>> me problems. By definition it must buffer the last data value that i= t >>> includes. It would be good at this point to explain exactly why it i= s >>> buffering messages here. I assume that you are talking about the flo= w >>> control issues that are discussed later but I don't know this. >> >> The reason why the pub/sub broker buffers messages is because the IoT > device >> is sleeping most of the time. For that reason, it cannot always forwar= d > requests >> from applications immediately. >> >> This is functionality called 'queue mode' in LWM2M and other terms hav= e > been >> used in other IETF documents. >=20 > I agree that having a 'queue mode' would be a nice feature, but I do no= t > believe that this is documented anyplace in this document. Doing so wo= uld > require some additional text. The current text says that messages are > always forwarded when they are received to a client. If the client hap= pens > to be asleep then it needs to go back and ask for the current value whe= n it > wakes up. =20 >=20 >> >> In my review I have been wondering why we aren't re-using the concepts= > from >> LWM2M here. >> >> Regarding the "topics": I have read this a bit differently. For me, a = node > has >> resources and it publishes those. Then, there are applications (Web > applications, >> smart phone apps) who sent requests for those resources. These resourc= es > have >> to be identified somehow and in LWM2M there is a specific way of > addressing >> the standardized resources (and objects), as described in >> https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf. May= be >> you want to be more generic here but I think it is important that ther= e is > a >> standardized structure here and that we are not only talking in the st= yle > of MQTT >> topics. >=20 > I do not follow how this came from my review. Is this an independent i= tem > or is it following from something that I asked in my review? >=20 > Jim >=20 >> >> >> Ciao >> Hannes >=20 >=20 --rnTJR6ko2obvsLOHsWe76wWPN0Ll7PTn7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXrKRoAAoJEGhJURNOOiAtiVgH/RQAxqGG+ioMMIm/rZTDw3uR DxQA9LW/4qMSu0WURoYk0qrHzVLERQOKhhG+IS4DHiZlODVPkkhbpBhrN98yVsBC b1c805ZyX+HK4kxe8R/RBIDxlXQMlT1JqYjliCUqEjrUAVTn4NnDL3aKQhOiBep4 3plU6ZNktREg3zmVm1u7c9H8Qvs5YJYgqjJAOcIhLyOZU9vpcNUknWXsekv091cl RBBKn+l25RUHGbXB67Q/H2nq8jg3HC4DfMzEBa17CnUOhTgmhDcezd79r3U0hSQz 6cV7d9TC7uSiQNoAmzLtD1GXVX+kMvsSLBqrebX6EViezJ7SBWE6iHF/ay4vXuQ= =CdSC -----END PGP SIGNATURE----- --rnTJR6ko2obvsLOHsWe76wWPN0Ll7PTn7-- From nobody Thu Aug 11 13:09:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C1912B029 for ; Thu, 11 Aug 2016 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR7NsIs6qiwA for ; Thu, 11 Aug 2016 13:09:30 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0097.outbound.protection.outlook.com [104.47.36.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987EF127077 for ; Thu, 11 Aug 2016 13:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hRYfJsnI5PBU7cvK5oQ1256tFJV9X9W00DatH5s1Jqs=; b=dMzo4j4apCniDy5hADBO3CuuqCXYgwCl+mr1O6WaGqWOntwUi5jTYNdgek0TldNnT8rO32cW6v18HcsQ3rB4bnlYogOTyr+uKYKzBJy8J8GDPZRasjVohor062E8zBTIddPsBhZm8czNFhAYe1KVIAo3VuJOpHP5dvqAYHrx9mE= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 20:09:28 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 20:09:28 +0000 From: Brian Raymor To: Hannes Tschofenig , "core@ietf.org" Thread-Topic: [core] Updates to coap-tcp-tls Thread-Index: AdHzatCWVXEOdWrbQLiOhi+qiefTngALuagAABwOKmA= Date: Thu, 11 Aug 2016 20:09:27 +0000 Message-ID: References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> In-Reply-To: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 4fd7509d-30c6-4fe2-e8f1-08d3c2236605 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2724; 6:OD7qgU5+1YRcxT2tI3/AyP3kZXcPlC/AkSaFkijqIS62X8JYIcXXTUMYZjAWTzuAmvz1QbmZ+w1LvwWrvg5wZ8AToWnqZef3LGVcrrrXz6Pq4pf9paV+CTkmVoaCgqxybKjVVrJ9JijxHQUWGJKakRnhE0D2vNpo1oH1gZvAleNO12KER1VfqoxmOzsN04y/9hCFG039kPr1PLrIBcR2k+4lEXn6JxhGVT2tQUm036Co2tYXPGz5fJqnKMxyJHxVmRlbvoR+67O/1kf7V0tvmcJZtJcCJgnRTYeNYRvij1whZvoEHy83kTQYaFlayL5IIu3bu/HoM+FsXkJuFn6roA==; 5:1QfKYWnz/kLnv6A3m/AKETlL/RvOEjOwhoPIafqDAemsy745bsH6TCUt999ksWv1tWVJbjRCl7vfzVVQXee/6zHPuzhIzK0AE7Xiqg1B5C5+xyDr2ISssXsxxTp8ZRTkzKiEx2zReYojYTDY5rvq4A==; 24:l+nD08DOXgGS6WBu/mVU6T/kikfWOSFuD3W1A9LsedE47xhv3+NlXQRaTyPIOFwW0pVLWPDDaGT3VFH7NmMFGpiguikMwfLIeFJkJDHm4ag=; 7:mmllXbPNKr4jtgSbpkPdS5lpzD5m6dHYn8tk02GguR3cS2rD3XKx5WX5eAC1qd/AzdccqvGDmTyIuUBC/jHT7J+XQTulwe5vRkSThMkzfqrikboqoVn3+WjzVLZBaWDQ8+jbiSG4VBknOhkXN0DGJ4BTaA4lrfv6ScV40UwO9soSqC8J035uZPr7aqv/LMzrG0rH2F/Mz8R3gGxvNCuMA1dq5PQMqoXUR5QFXilwA+y3vG6h1qjpjqrvqIhWvxB0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2724; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040174)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2724; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2724; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(199003)(51914003)(377454003)(81156014)(33656002)(189998001)(11100500001)(81166006)(7696003)(586003)(3660700001)(107886002)(305945005)(106356001)(74316002)(7736002)(7846002)(97736004)(50986999)(15650500001)(76576001)(5001770100001)(86612001)(3280700002)(3846002)(2906002)(99286002)(9686002)(102836003)(54356999)(5002640100001)(19580405001)(122556002)(19580395003)(10290500002)(87936001)(230783001)(5005710100001)(10400500002)(86362001)(6116002)(8990500004)(76176999)(8676002)(2501003)(66066001)(77096005)(2900100001)(10090500001)(2950100001)(92566002)(101416001)(105586002)(8936002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2724; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 20:09:27.7316 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2724 Archived-At: Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 20:09:32 -0000 Hi Hannes- Thanks for the edit and the guidance about the TLS-related RFC(s). I'll inc= orporate into the pull request before I merge later today. ...Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Wednesday, August 10, 2016 11:30 PM To: Brian Raymor ; core@ietf.org Subject: Re: [core] Updates to coap-tcp-tls Hi Brian, thanks for the update. Regarding the TLS / ALPN case you have proposed the following wording: With the exception of TCP port 5684, implementations that support CoAP over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the "coap" protocol identifier defined in . What about using the following wording instead: Implementations that support CoAP over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the "coap" protocol identifier defined in unless in deployments where ALPN is not supported in the TLS protocol stack. Implementations MUST use port number 5684 for those TLS implementations that do not support ALPN. Regarding the pointers to RFC 7525 and RFC 7925. We should only reference RFC 7925 since the recommendations in the two documents are different and would lead to non-interoperable implementations. I did, of course, point this out in my reviews but the authors were not interested in IoT related concerns. Ciao Hannes From nobody Thu Aug 11 13:20:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7AA12D0A3 for ; Thu, 11 Aug 2016 13:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V17L5IpW3clk for ; Thu, 11 Aug 2016 13:20:18 -0700 (PDT) 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 CF0B212B02E for ; Thu, 11 Aug 2016 13:20:17 -0700 (PDT) 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 u7BKKEfJ001122 for ; Thu, 11 Aug 2016 22:20:14 +0200 (CEST) Received: from nar-4.local.mail (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3s9KBj73f9zDbGm; Thu, 11 Aug 2016 22:20:13 +0200 (CEST) Date: Thu, 11 Aug 2016 22:20:13 +0200 From: Carsten Bormann To: "=?utf-8?Q?core=40ietf.org_WG?=" Message-ID: In-Reply-To: <57934454.2090205@tzi.org> References: <57934454.2090205@tzi.org> X-Mailer: Airmail (382) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="57acddfd_654ff27d_8c0d" Archived-At: Subject: Re: [core] CoRE @ IETF96: minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 20:20:20 -0000 --57acddfd_654ff27d_8c0d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have uploaded draft minutes for the CoRE meetings =40IET=4696, extendin= g the summary (that was sent right after the meeting) by more detailed di= scussion notes: https://www.ietf.org/proceedings/96/minutes/minutes-96-core Thanks again for the note takers (Ari, Jaime, Matthias). If you said something during this meeting, please have a look and check t= hat your statement is represented well. Please send corrections to the chairs (core-chairs=40ietf.org) or, if the= y need discussion, as a wide-reply to this message. We have until=C2=A02016-09-12=C2=A0to fix mistakes, but the earlier the b= etter. Gr=C3=BC=C3=9Fe, Carsten --57acddfd_654ff27d_8c0d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

I note that = one of my comments was followed by a question mark.=C2=A0 Here is a = slightly expanded version that you can use if you = want.

 

Jim: Half of = the problems can be solved by tagging unions so that two branches will = never have the same CBOR tag.

 

From:<= /b> = core [mailto:core-bounces@ietf.org] On Behalf Of Carsten = Bormann
Sent: Thursday, August 11, 2016 1:20 PM
To: = core@ietf.org WG <core@ietf.org>
Subject: Re: [core] = CoRE @ IETF96: minutes

 

I have = uploaded draft minutes for the CoRE meetings @IETF96, extending the = summary (that was sent right after the meeting) by more detailed = discussion notes:

 =

 =

Thanks = again for the note takers (Ari, Jaime, = Matthias).

 =

If you = said something during this meeting, please have a look and check that = your statement is represented well.

Please = send corrections to the chairs (core-chairs@ietf.org) or, if = they need discussion, as a wide-reply to this = message.

We have = until 2016-09-12&nbs= p;to fix = mistakes, but the earlier the = better.

 =

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

 =

------=_NextPart_000_012B_01D1F3D5.FB456DF0-- From nobody Thu Aug 11 15:47:56 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E85A612D875 for ; Thu, 11 Aug 2016 15:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147095567495.21209.4624020463826924364.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2016 15:47:54 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 22:47:55 -0000 Changed milestone "Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/core/charter/ From nobody Thu Aug 11 21:14:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D736312D903 for ; Thu, 11 Aug 2016 21:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEKbXHzAM2zX for ; Thu, 11 Aug 2016 21:14:31 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 2FC3712D8E7 for ; Thu, 11 Aug 2016 21:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Arano1NFEAursUPAbWA41ctn2JTgpxHe52YEsMPKR9Q=; b=PsQC2ufHPU49J/+oXHFJQk5pt5 oLmT03p6SDafXNNc7lXQgrcMrxJoZUI+nopW3AcOvl1riLdSvSwvtdcHbgXQah8zC5NffoHlZGzF4 TGE1pb7rCmkQtBotu69rSDe3jW/fStXt3GlZoyR+EqOoPDxm4orjc15isEe/2z3Cf12k8Z/WueD7Z vJvcqdaZ2FSCnQMvXI2ZIHAo3TXajSqITOU8oKg/1ewSPya10xGVgWv4Ww6nq2hrNqVpMti43s4SX gaOEfPsg6cBGYpobRsHZ+fcsQrttaHwoVCo9XAoXlWTBR4eGMk2H4GLJ25iJxHBdFqkNqMYtBtrSp z2DmaGcQ==; Received: from ppp118-209-11-216.lns20.mel4.internode.on.net ([118.209.11.216]:50953 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bY3rZ-001CKK-De for core@ietf.org; Fri, 12 Aug 2016 14:14:29 +1000 To: core@ietf.org References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> From: Christian Groves Message-ID: <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> Date: Fri, 12 Aug 2016 14:14:25 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 04:14:33 -0000 Hello, To me the proposed update doesn't seem to read right having criteria at the start and end of the first sentence. Would the following be clearer? Implementations that support CoAP over TLS with ALPN support MUST perform protocol negotiation in TLS {{-alpn}} using the "coap" protocol identifier defined in . In deployments where the TLS protocol stack does not support ALPN, implementations MUST use port number 5684. Regards, Christian On 12/08/2016 6:09 AM, Brian Raymor wrote: > Hi Hannes- > > Thanks for the edit and the guidance about the TLS-related RFC(s). I'll incorporate into the pull request before I merge later today. > > ...Brian > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Wednesday, August 10, 2016 11:30 PM > To: Brian Raymor ; core@ietf.org > Subject: Re: [core] Updates to coap-tcp-tls > > Hi Brian, > > thanks for the update. > > Regarding the TLS / ALPN case you have proposed the following wording: > > > With the exception of TCP port 5684, implementations that support CoAP > over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the > "coap" protocol identifier defined in . > > What about using the following wording instead: > > Implementations that support CoAP over TLS MUST perform protocol > negotiation in TLS {{-alpn}} using the "coap" protocol identifier > defined in unless in deployments where ALPN > is not supported in the TLS protocol stack. Implementations MUST use > port number 5684 for those TLS implementations that do not support ALPN. > > Regarding the pointers to RFC 7525 and RFC 7925. We should only > reference RFC 7925 since the recommendations in the two documents are > different and would lead to non-interoperable implementations. I did, of > course, point this out in my reviews but the authors were not interested > in IoT related concerns. > > Ciao > Hannes > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Fri Aug 12 09:09:25 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56912D0A6 for ; Fri, 12 Aug 2016 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtmA80lmPJew for ; Fri, 12 Aug 2016 09:09:21 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0128.outbound.protection.outlook.com [104.47.34.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C903F12B018 for ; Fri, 12 Aug 2016 09:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Twiq8j1x5N9SR5ChSPkW7gdIqks/8h4iEEKrZN4J2kc=; b=VkXpD7aeQLRPuZbh9gBGmK/KLkzhHcKdSo1smYjXqg9iQ7bT++5KbzDxE67+zAm7YsmrDYpnnKGP8ZcS7ZE0qSCsjlgOCqsbUehYtJXw3Pk4vpUN9QZ0dzwb2QLejLHdAIwcd3NPCZYHOF2FF/Hpyi4YJtwYxqqqpoSHvFXgEXs= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2722.namprd03.prod.outlook.com (10.173.144.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 12 Aug 2016 16:09:19 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0549.027; Fri, 12 Aug 2016 16:09:19 +0000 From: Brian Raymor To: Christian Groves , "core@ietf.org" Thread-Topic: [core] Updates to coap-tcp-tls Thread-Index: AdHzatCWVXEOdWrbQLiOhi+qiefTngALuagAABwOKmAAEYS0gAAYxigg Date: Fri, 12 Aug 2016 16:09:19 +0000 Message-ID: References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> In-Reply-To: <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: c848e4c1-5235-4533-4f3e-08d3c2cb0464 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2722; 6:SpWLLQ4MXFailYZc2JPoeOGUHweOaLSgzi9AosSupf0cCW5HzpU5wJQrgIPQMeRZIjdjHsX/arlJsuB8YR9EjZZWjHnTo9Wl02fJo1SCeTwncXeRiFTEQLfjXvCKYU+9OTnLIYuZ8HPQuSCIbxzCNjKwaY/2NUoFO7ltaDpBavMP61eJv1KUutFF4WG8v0mJ07h6F+dmz75Pyhk+/E/fCV1xSkt4vpBOVxG9RJvMlyVAowmb++kAIaRsegjCRaSQKjhS7Ky4NX6wGuSJ4xDnkzQEBfyqW39DRRcO/+Oou3XIpiFJfbDOerLSBIOhRPyT8FXPLqCnOM18ww1SvpHC5A==; 5:sONxq+0uBQpByELOz2U6CM2jdve6y8CuUp+pKJyjcReBysKbgWstYkbUzgrdO4lBCmExMRX+5lF3C5hTti7rksdMI6bJjlKmSAMlfkWhOkxspz3eIzA8CcyvRSDQZoSOztgYh0VdxVPwlIfG/t3Kww==; 24:sj4lPENKsH2/Ohi7fIwWBMpUMMmiGzydfidM0czZEdO+OKFCW97eMYRBMd+oDuOnoFGxwbZHY0cgodtFt32l5+9UFucYAQtGMpspT/YqJ4I=; 7:YsMh9fs/3QQzY1Xwi3GmfmHJHezysH9h9lPNE6TGB2EmQpeK1QYJ7ic/YAyfeXyRGOeSCf91Gd5TVEBqzcHRuwef7ToxLsH5nSWKKsQMVCITPLIqG5evpkdTF9rTcgL191qI3jsGPCe6nRxUaZNTqIG7HsyR4ye0gmF9pfCN3W0TkxvijfEGxv5TUG05+E19SvGCVA8TBDIyp81qioRQDGCWw8+MKAjN8tVf5YeMzGU+PFvlfB+2AV8m8+rOlJdm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2722; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2722; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2722; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(13464003)(51914003)(24454002)(11100500001)(3280700002)(5001770100001)(10090500001)(76576001)(122556002)(7846002)(86612001)(8990500004)(93886004)(2900100001)(2950100001)(66066001)(77096005)(107886002)(189998001)(97736004)(15975445007)(8936002)(92566002)(10400500002)(86362001)(5005710100001)(81166006)(10290500002)(8676002)(81156014)(230783001)(3660700001)(87936001)(68736007)(9686002)(99286002)(105586002)(305945005)(15650500001)(19580405001)(19580395003)(7696003)(2906002)(5002640100001)(2501003)(7736002)(3846002)(102836003)(6116002)(586003)(101416001)(50986999)(33656002)(76176999)(106356001)(74316002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2722; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 16:09:19.4451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2722 Archived-At: Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 16:09:23 -0000 Hi Christian, Here's what I actually merged in my pull request yesterday which is availab= le in the editor's draft - https://core-wg.github.io/coap-tcp-tls/ If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is= available in the TLS protocol stack, CoAP over TLS implementations MUST pe= rform protocol negotiation in TLS using the "coap" protocol identifier defi= ned in Section 8.7. In exceptional cases where ALPN is unavailable, CoAP ov= er TLS implementations MUST use port number 5684. -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Christian Groves Sent: Thursday, August 11, 2016 9:14 PM To: core@ietf.org Subject: Re: [core] Updates to coap-tcp-tls Hello, To me the proposed update doesn't seem to read right having criteria at=20 the start and end of the first sentence. Would the following be clearer? Implementations that support CoAP over TLS with ALPN support MUST=20 perform protocol negotiation in TLS {{-alpn}} using the "coap" protocol identifier defined in . In deployments where the TLS=20 protocol stack does not support ALPN, implementations MUST use port number 5684. Regards, Christian On 12/08/2016 6:09 AM, Brian Raymor wrote: > Hi Hannes- > > Thanks for the edit and the guidance about the TLS-related RFC(s). I'll i= ncorporate into the pull request before I merge later today. > > ...Brian > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Wednesday, August 10, 2016 11:30 PM > To: Brian Raymor ; core@ietf.org > Subject: Re: [core] Updates to coap-tcp-tls > > Hi Brian, > > thanks for the update. > > Regarding the TLS / ALPN case you have proposed the following wording: > > > With the exception of TCP port 5684, implementations that support CoAP > over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the > "coap" protocol identifier defined in . > > What about using the following wording instead: > > Implementations that support CoAP over TLS MUST perform protocol > negotiation in TLS {{-alpn}} using the "coap" protocol identifier > defined in unless in deployments where ALPN > is not supported in the TLS protocol stack. Implementations MUST use > port number 5684 for those TLS implementations that do not support ALPN. > > Regarding the pointers to RFC 7525 and RFC 7925. We should only > reference RFC 7925 since the recommendations in the two documents are > different and would lead to non-interoperable implementations. I did, of > course, point this out in my reviews but the authors were not interested > in IoT related concerns. > > Ciao > Hannes > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Aug 12 12:03:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D079212D60E for ; Fri, 12 Aug 2016 12:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VorWUF4uPhXp for ; Fri, 12 Aug 2016 12:03:26 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2858E12D0E5 for ; Fri, 12 Aug 2016 12:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NvrFF7Bjzne3FsU7djNdRRFEXv5QCQRtZvnbZCCd4Ts=; b=PUqmJhUVruFEcizOG43Uju9H/nmyEMmrxJku5Ra4h/ewL3sfWKpYx7/azoLtI4Er+oeGFs+faC3EFhWO9/C4u7b2uIuVUidIwzZCytg4jtKVlKddYwHKphnPTZIeQ7YQlfAaKksZGF/PmYOAvOLtz33LF8RyX3O1g+/8QJWwmOs= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 12 Aug 2016 19:03:23 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0549.026; Fri, 12 Aug 2016 19:03:23 +0000 From: Dave Thaler To: "core@ietf.org" Thread-Topic: rt and if registry question Thread-Index: AdHtxnz2wdbZZVFCRkuIwoepMaBv0QAmhs1wAZrbq/A= Date: Fri, 12 Aug 2016 19:03:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [131.107.147.30] x-ms-office365-filtering-correlation-id: 6868ff63-2d31-4cbe-7ee9-08d3c2e3557b x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0717; 6:RFsP+uowr6ph3rb0PtYUN8jy5e5GXQ6xH4vVhaz3g8EP04ILfAObq/hene8+2ubxXVE+wTtnpH7zWirg78/PqgL9xlm2i9sNFMyVJqHOm+JFyvoDFysFQXLGpGRrLFEH/asotZRK1FKmAborUw5DteFRbPHNt+ANZkyq/DvAQB72huMcb+fMfZFb1PMHpFXbPQk7KK7/mOyv3I8KCsxNjI5lT7iq/EKmsMgi1BOSYgDM+4tJ9KmQi8S3p0erWk93ys6s4i1wUkwnd1KduhGsXY5YzePxL2Dm2Tp6PgX+/jmUdl8jfOXX5hRBzBoZlqaYYnKyL9yOqN+wIJ4np9vZTA==; 5:2e8704pMMLgFnQWhjAL6EI/lgwM6f6nycd9rr0Xp4c6Pg60l8jPY9DtIjCnYk1taHFcwMt/CJ+6R0NeaD/WanpQehkn6ImD+HdkdIDz6RBHaMX8npX4vap4SgVcebpjxdzQ4ODccNLiIV9ijHg12AQ==; 24:k2WiPi19qzHs9BA1a7gieQwsOFgyzV9QbqGyVMW0WX9nFCwHpgIlePjPXEgOnYDADac1EVXrRmp2C9whhYYKXa9fmbclYLcgzKfl/61iFo8=; 7:Com1Yt0jxRCV7/rMfrfaXnz39QM57HL6DwqAxgD/mM+e+cCK2ZSicaYsW+Sn4C4U5BQgKwpup9tmwQtXIxhkppVEP5aC0s7MZ9l2ZSMu/rS/sV5AeH7PG9yuX3ujNSJEZkIHW9b1A+cHBstef3gbHSU0Z2F8kLok1qbPNOcZjR6/gb3EE1xQziPnbDj0IsXPbVkTP1y8/HuCRT73rwJ6hNjptDXSJlv3ej2wX2xOc3FGt7dzOgX2dI9kT9jUQzZh x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0717; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0717; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0717; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(81156014)(122556002)(33656002)(5002640100001)(99286002)(81166006)(19580395003)(8676002)(19300405004)(86612001)(105586002)(19580405001)(1730700003)(101416001)(76576001)(10090500001)(9686002)(3280700002)(66066001)(50986999)(6116002)(54356999)(790700001)(97736004)(102836003)(3660700001)(189998001)(19617315012)(19625215002)(107886002)(76176999)(3846002)(7906003)(5640700001)(5630700001)(77096005)(15975445007)(87936001)(16236675004)(586003)(110136002)(11100500001)(8990500004)(8936002)(7696003)(2900100001)(106356001)(2950100001)(10400500002)(5005710100001)(10290500002)(7736002)(92566002)(2351001)(2906002)(2501003)(86362001)(68736007)(7846002)(3900700001)(74316002)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0717; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB071760A62E27C5AE9F4EBBD1A31F0DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 19:03:23.5081 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0717 Archived-At: Subject: Re: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 19:03:29 -0000 --_000_DM2PR0301MB071760A62E27C5AE9F4EBBD1A31F0DM2PR0301MB0717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending due to lack of response... Any of the authors or WG chairs care to state what the intended WG consensu= s was when RFC 6690 was published? From: Dave Thaler Sent: Thursday, August 4, 2016 8:04 AM To: core@ietf.org Subject: RE: rt and if registry question While I'm waiting for an answer to the question below, I'll ask a related q= uestion. Can a prefix be registered? In the appsawg discussion that led to RFC 7595, we discussed that question = in the context of URI scheme names and the WG consensus was no, there's no such thing as a prefix because it's tre= ated as "an opaque string". The text quoted from RFC 6690 section 3.1 below also says it's an opaque st= ring, which might be interpreted as "there's no such thing as a prefix", but then section 7.4 uses "core." as a= prefix. You might say "core.*" is a prefix for registration purposes but not for purposes of interpreting in code (I d= on't believe that argument is reasonable though since once you define it for one purpose, people will use it in code for re= gistration which will then bleed into other purposes, which is why appsawg disallowed any prefixes). But if "core.*" = is a prefix for registration purposes only, then the question about whether other prefixes can be registered is a valid= question. Comments? Dave From: Dave Thaler Sent: Wednesday, August 3, 2016 1:40 PM To: core@ietf.org Subject: rt and if registry question In some conversations I've been in, I've found that different people read R= FC 6690 different ways. Section 3.1 says: The Resource Type 'rt' attribute is an opaque string used to assign an application-specific semantic type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource, this could be, e.g., an application-specific semantic type like "outdoor-temperature" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple Resource Types MAY be included in the value of this parameter, each separated by a space, similar to the relation attribute. The registry for Resource Type values is defined in Section 7.4. Section 3.2 is similar for 'if' values. And section 7.4 says: For both sub-registries, values starting with the characters "core" are registered using the IETF Review registration policy [RFC5226]. All other values are registered using the Specification Required policy, which requires review by a designated expert appointed by the IESG or their delegate. ... o URIs are reserved for free use as extension values for these attributes and MUST NOT be registered. So the question is, what values can be used _without_ registering. Clearly= the last sentence above says URIs are allowed. But it's apparently ambiguous whether other values= like "outdoor-temperature" in 3.1 (or "x.outdoor-temperature" or similar variations) can be used by an= application without registering it. My reading of 3.1 is that registration is required for everything but URIs,= but others read section 3.1 differently. Can the WG clarify what the intent is? Thanks, Dave --_000_DM2PR0301MB071760A62E27C5AE9F4EBBD1A31F0DM2PR0301MB0717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending due to lack = of response...

Any of the authors or = WG chairs care to state what the intended WG consensus was when RFC 6690 wa= s published?

 

From: Dave Thaler
Sent: Thursday, August 4, 2016 8:04 AM
To: core@ietf.org
Subject: RE: rt and if registry question

 

While I’m waitin= g for an answer to the question below, I’ll ask a related question.

Can a prefix be regist= ered?

 

In the appsawg discuss= ion that led to RFC 7595, we discussed that question in the context of URI = scheme names and

the WG consensus was n= o, there’s no such thing as a prefix because it’s treated as &#= 8220;an opaque string”.

 

The text quoted from R= FC 6690 section 3.1 below also says it’s an opaque string, which migh= t be interpreted as

“there’s n= o such thing as a prefix”, but then section 7.4 uses “core.R= 21; as a prefix.   You might say “core.*” is a prefix=

for registration purpo= ses but not for purposes of interpreting in code (I don’t believe tha= t argument is reasonable though

since once you define = it for one purpose, people will use it in code for registration which will = then bleed into other

purposes, which is why= appsawg disallowed any prefixes).   But if “core.*” = is a prefix for registration purposes only,

then the question abou= t whether other prefixes can be registered is a valid question.<= /span>

 

Comments?

 

Dave=

 

 

From: Dave Thaler
Sent: Wednesday, August 3, 2016 1:40 PM
To: core@ietf.org
Subject: rt and if registry question

 

In some conversations I’ve been in, I’ve= found that different people read RFC 6690 different ways.

 

Section 3.1 says:

   The =
Resource Type 'rt' attribute is an opaque string used to assign<=
/span>
   an a=
pplication-specific semantic type to a resource.  One can think
   of t=
his as a noun describing the resource.  In the case of a
   temp=
erature resource, this could be, e.g., an application-specific
   sema=
ntic type like "outdoor-temperature" or a URI referencing a<=
/o:p>
   spec=
ific concept in an ontology like
   &quo=
t;http://swe=
et.jpl.nasa.gov/2.0/phys.owl#Temperature".  Multiple
   Reso=
urce Types MAY be included in the value of this parameter, each<=
/span>
   sepa=
rated by a space, similar to the relation attribute.  The
   regi=
stry for Resource Type values is defined in Section 7.4.

 

Section 3.2 is similar for ‘if’ values.<= o:p>

 

And section 7.4 says:

   For =
both sub-registries, values starting with the characters "core"
   are =
registered using the IETF Review registration policy [RFC5226].
   All =
other values are registered using the Specification Required
   poli=
cy, which requires review by a designated expert appointed by the
   IESG=
 or their delegate.

…

  = ; o  URIs are reserved for free use as extension values for these=

      attributes and = MUST NOT be registered.

 

So the = question is, what values can be used _without_ registering.  Cl= early the last sentence above

says UR= Is are allowed.   But it’s apparently ambiguous whether oth= er values like “outdoor-temperature”

in 3.1 = (or “x.outdoor-temperature” or similar variations) can be used = by an application without registering it.

My read= ing of 3.1 is that registration is required for everything but URIs, but ot= hers read section 3.1 differently.

Can the= WG clarify what the intent is?

&n= bsp;

Thanks,=

Dave

--_000_DM2PR0301MB071760A62E27C5AE9F4EBBD1A31F0DM2PR0301MB0717_-- From nobody Fri Aug 12 14:57:46 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A77812D1C1 for ; Fri, 12 Aug 2016 14:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se61rcYL1Op4 for ; Fri, 12 Aug 2016 14:57:43 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E73512B006 for ; Fri, 12 Aug 2016 14:57:43 -0700 (PDT) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1FA3F41C074; Fri, 12 Aug 2016 23:57:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 96Kpzzlatfm8; Fri, 12 Aug 2016 23:57:40 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id CCD4241C08E; Fri, 12 Aug 2016 23:57:39 +0200 (CEST) Message-ID: <57AE4652.7020306@tzi.org> Date: Fri, 12 Aug 2016 23:57:38 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Brian Raymor References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 21:57:45 -0000 Hi Brian, this text doesn't seem to address the case where the ALPN functionality isn't available at the other end. E.g., a server instance may very well have ALPN implemented, but still elects to offer a coaps://....:5684 server for clients that don't. Grüße, Carsten Brian Raymor wrote: > If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is available in the TLS protocol stack, CoAP over TLS implementations MUST perform protocol negotiation in TLS using the "coap" protocol identifier defined in Section 8.7. In exceptional cases where ALPN is unavailable, CoAP over TLS implementations MUST use port number 5684. From nobody Fri Aug 12 15:19:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219D112D78D for ; Fri, 12 Aug 2016 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fSwRXQM6GBe for ; Fri, 12 Aug 2016 15:19:34 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B1512D763 for ; Fri, 12 Aug 2016 15:19:33 -0700 (PDT) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9184041C084; Sat, 13 Aug 2016 00:19:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EBcDpxZY2mdk; Sat, 13 Aug 2016 00:19:31 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id BBD6E41C08A; Sat, 13 Aug 2016 00:19:30 +0200 (CEST) Message-ID: <57AE4B71.5090709@tzi.org> Date: Sat, 13 Aug 2016 00:19:29 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 22:19:35 -0000 Hi Dave, I'm not the foremost expert on this but I'll give it a try. Dave Thaler wrote: > Can a prefix be registered? No. There is nothing in section 7.4 of RFC 6690 that would create such a registry. (The concept of prefix is used in 4.1 for certain kinds of searches, but it is really used in its straight computer science meaning of "the beginning part".) The text about »values starting with the characters "core"« is about swapping out the registration policy, there is no other technical change. Note that the text following (that instructs the designated expert) is about avoiding the typical vagaries of choosing between link.format and linkformat and link-format, so it is a matter of style consistency that is meant to provide more predictability (and this memorability) of the values being registered. It uses "core." as an example, not in a normative way. ("core." doesn't occur in the entire RFC outside examples.) Actually, "coresident-sensors" or "coresident.sensors" have the same special IETF Review policy as "core.foo" -- the policy swap is in effect for »values starting with the characters "core"«. I believe the current text of RFC 6690 is sufficient to say all this and no retroactive analysis of proceedings or mailing lists is required to come to this conclusion. Grüße, Carsten From nobody Sun Aug 14 15:02:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F6B12D819 for ; Sun, 14 Aug 2016 15:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.811 X-Spam-Level: X-Spam-Status: No, score=-101.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtY1JvTn8aqT for ; Sun, 14 Aug 2016 15:02:06 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3559D12D1DC for ; Sun, 14 Aug 2016 15:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4iAMenHcKAJB8YtFFCHk7Evsf00oTWjbKQvxX6rs37Y=; b=gshPFCYTuztrU8OxIiIYYuATfy59GVhpdT6MqNf5BUD0GH/s+tQkLCT3/rdg9aQxf4t2W7aCMl/Jt7RyVYQ0DQNFLtXgeutpbjth901eZOtDc6NJprQnpa3jMo7UTIUnsWtfEO1+FkQGiEq9D7J9WndRilzqNm5AwWXW1VFgZCY= Received: from CY1PR0301MB0715.namprd03.prod.outlook.com (10.160.159.145) by CY1PR0301MB0715.namprd03.prod.outlook.com (10.160.159.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sun, 14 Aug 2016 22:02:01 +0000 Received: from CY1PR0301MB0715.namprd03.prod.outlook.com ([10.160.159.145]) by CY1PR0301MB0715.namprd03.prod.outlook.com ([10.160.159.145]) with mapi id 15.01.0549.027; Sun, 14 Aug 2016 22:02:01 +0000 From: Dave Thaler To: Carsten Bormann Thread-Topic: [core] rt and if registry question Thread-Index: AdHtxnz2wdbZZVFCRkuIwoepMaBv0QAmhs1wAZrbq/AABuQ2gABj3fRw Date: Sun, 14 Aug 2016 22:02:01 +0000 Message-ID: References: <57AE4B71.5090709@tzi.org> In-Reply-To: <57AE4B71.5090709@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [73.193.101.106] x-ms-office365-filtering-correlation-id: 2027370c-dc06-411a-21c2-08d3c48e9e85 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0715; 6:4in2fyUUqZ97QC79RGEHBOC6C7jBQhggRIOOWtyFyIWTXC/ARt/27dor2gTvFlSya+qDI5Ok9B/iwHCYhRliMYDXWgQ+EsriCU6Km8s6pSD0LnvNIiH1GSeXLrE2D5R2PTuDGkeGeOtpGNeCVbErDMf6DA6QQSQtXlpSTlCE358nvkZbwCtXDXoGB27oB985u6X2owiK0RsNU6ZZ3HSIjiOP/3db25XntDdBvKdvPYoppAb2V51bm4x0RrOiFhqKCsTihYRRSufQLaAGyEhnk9OirmbkCTuaZSQeQUb8eoqKvhEkqKY9PqZ2I5zFuIFYzkUrzy/NOxcP3el+5w/Kfg==; 5:2JyYhu+Pu5Xm9eJiua++P5YseiOl6mmqhpclJ8GSvvcpGLxf629KD0WBvioDwvybVRsrp3L8AYka8vGZxIptKOMd2g9jg3QTbS9mTbzFmDAK9ujtJ+YVM7kmZsEn4Klzu1JrHql8zjYAEza5Hiy1nA==; 24:0J9hy2mxVZEtY7RdhKWiolppnDPskmsdP03STbbpLjNM4yJTU0ZiCgYA/l/SZ12ypdciYREIVAz+vICAr9gj9Esk1nM4otBoauGa4igojGQ=; 7:aaozrnt2JA78KchF2rpGM6Xeqg+/H99PgK0xGWPsWp7B8Sti0+vvyUvvkleE5wClsnnZBxSCWD1mgkph405M+iLp4DqbU5ooXI85UXFG3ce+xbN2EEkTIM4HX9cHhfhQWBVdNFUzcxfz3xKyeubLIr20ezMV7msN/LWegDDQViq1FypxziM6TeEELj3sxCIRKJPxFi/+G2mYeyFDWOZ0U4aydLxOsUtD7+4TsQLNiPA08scbZ1LyFg23Ctf5ZezS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0715; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0715; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0715; x-forefront-prvs: 00342DD5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(377454003)(13464003)(24454002)(189002)(199003)(50986999)(11100500001)(87936001)(3660700001)(3280700002)(2906002)(19580405001)(68736007)(76176999)(4326007)(33656002)(54356999)(106356001)(19580395003)(305945005)(5890100001)(8936002)(74316002)(81156014)(2900100001)(7846002)(8676002)(8990500004)(7736002)(10090500001)(7696003)(2950100001)(110136002)(10290500002)(3846002)(6116002)(5002640100001)(586003)(81166006)(105586002)(5005710100001)(102836003)(10400500002)(189998001)(9686002)(93886004)(97736004)(66066001)(77096005)(92566002)(86362001)(122556002)(101416001)(86612001)(99286002)(99936001)(76576001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0715; H:CY1PR0301MB0715.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_CY1PR0301MB07157CA483A83C42BDF7729DA3110CY1PR0301MB0715_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2016 22:02:01.1765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0715 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 22:02:08 -0000 --_002_CY1PR0301MB07157CA483A83C42BDF7729DA3110CY1PR0301MB0715_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIENhcnN0ZW4gZm9yIHRoZSByZXNwb25zZSEgIFRoaXMgYW5zd2VycyBvbmUgb2YgdGhl IHR3byBxdWVzdGlvbnMgSSBhc2tlZC4gIEknbSBzdGlsbCB3YWl0aW5nIGZvciBhbg0KYW5zd2Vy IG9uIHRoZSBvdGhlciBxdWVzdGlvbiAoaW4gc2hvcnQsIGl0IHdhczogY2FuIHlvdSB1c2UgdmFs dWVzIG90aGVyIHRoYW4gVVJJcyB3aXRob3V0DQpyZWdpc3RlcmluZywgb3Igb25seSBVUklzPykg ICBUaGUgYXR0YWNoZWQgZW1haWwgaXMgdGhlIG9uZSBJJ20gc3RpbGwgd2FpdGluZyBmb3IgYW4g YW5zd2VyIG9uLg0KDQpJIGJlbGlldmUgSSBrbm93IHRoZSBhbnN3ZXIgYnV0IHNpbmNlIHRoZXJl J3MgYXBwYXJlbnRseSBjb25mdXNpb24sIEknZCBsaWtlIGNvbmZpcm1hdGlvbiBvbiB0aGUgbGlz dCBlaXRoZXIgd2F5Lg0KDQpEYXZlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0KPiBTZW50OiBGcmlk YXksIEF1Z3VzdCAxMiwgMjAxNiAzOjE5IFBNDQo+IFRvOiBEYXZlIFRoYWxlciA8ZHRoYWxlckBt aWNyb3NvZnQuY29tPg0KPiBDYzogY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVd IHJ0IGFuZCBpZiByZWdpc3RyeSBxdWVzdGlvbg0KPiANCj4gSGkgRGF2ZSwNCj4gDQo+IEknbSBu b3QgdGhlIGZvcmVtb3N0IGV4cGVydCBvbiB0aGlzIGJ1dCBJJ2xsIGdpdmUgaXQgYSB0cnkuDQo+ IA0KPiBEYXZlIFRoYWxlciB3cm90ZToNCj4gPiBDYW4gYSBwcmVmaXggYmUgcmVnaXN0ZXJlZD8N Cj4gDQo+IE5vLiAgVGhlcmUgaXMgbm90aGluZyBpbiBzZWN0aW9uIDcuNCBvZiBSRkMgNjY5MCB0 aGF0IHdvdWxkIGNyZWF0ZSBzdWNoIGENCj4gcmVnaXN0cnkuICAoVGhlIGNvbmNlcHQgb2YgcHJl Zml4IGlzIHVzZWQgaW4gNC4xIGZvciBjZXJ0YWluIGtpbmRzIG9mIHNlYXJjaGVzLA0KPiBidXQg aXQgaXMgcmVhbGx5IHVzZWQgaW4gaXRzIHN0cmFpZ2h0IGNvbXB1dGVyIHNjaWVuY2UgbWVhbmlu ZyBvZiAidGhlIGJlZ2lubmluZw0KPiBwYXJ0Ii4pDQo+IA0KPiBUaGUgdGV4dCBhYm91dCDCu3Zh bHVlcyBzdGFydGluZyB3aXRoIHRoZSBjaGFyYWN0ZXJzICJjb3JlIsKrIGlzIGFib3V0DQo+IHN3 YXBwaW5nIG91dCB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSwgdGhlcmUgaXMgbm8gb3RoZXIgdGVj aG5pY2FsIGNoYW5nZS4NCj4gDQo+IE5vdGUgdGhhdCB0aGUgdGV4dCBmb2xsb3dpbmcgKHRoYXQg aW5zdHJ1Y3RzIHRoZSBkZXNpZ25hdGVkIGV4cGVydCkgaXMgYWJvdXQNCj4gYXZvaWRpbmcgdGhl IHR5cGljYWwgdmFnYXJpZXMgb2YgY2hvb3NpbmcgYmV0d2VlbiBsaW5rLmZvcm1hdCBhbmQgbGlu a2Zvcm1hdA0KPiBhbmQgbGluay1mb3JtYXQsIHNvIGl0IGlzIGEgbWF0dGVyIG9mIHN0eWxlIGNv bnNpc3RlbmN5IHRoYXQgaXMgbWVhbnQgdG8gcHJvdmlkZQ0KPiBtb3JlIHByZWRpY3RhYmlsaXR5 IChhbmQgdGhpcyBtZW1vcmFiaWxpdHkpIG9mIHRoZSB2YWx1ZXMgYmVpbmcgcmVnaXN0ZXJlZC4g IEl0DQo+IHVzZXMgImNvcmUuIiBhcyBhbiBleGFtcGxlLCBub3QgaW4gYSBub3JtYXRpdmUgd2F5 LiAgKCJjb3JlLiIgZG9lc24ndCBvY2N1ciBpbg0KPiB0aGUgZW50aXJlIFJGQyBvdXRzaWRlIGV4 YW1wbGVzLikNCj4gDQo+IEFjdHVhbGx5LCAiY29yZXNpZGVudC1zZW5zb3JzIiBvciAiY29yZXNp ZGVudC5zZW5zb3JzIiBoYXZlIHRoZSBzYW1lIHNwZWNpYWwNCj4gSUVURiBSZXZpZXcgcG9saWN5 IGFzICJjb3JlLmZvbyIgLS0gdGhlIHBvbGljeSBzd2FwIGlzIGluIGVmZmVjdCBmb3Igwrt2YWx1 ZXMNCj4gc3RhcnRpbmcgd2l0aCB0aGUgY2hhcmFjdGVycyAiY29yZSLCqy4NCj4gDQo+IEkgYmVs aWV2ZSB0aGUgY3VycmVudCB0ZXh0IG9mIFJGQyA2NjkwIGlzIHN1ZmZpY2llbnQgdG8gc2F5IGFs bCB0aGlzIGFuZCBubw0KPiByZXRyb2FjdGl2ZSBhbmFseXNpcyBvZiBwcm9jZWVkaW5ncyBvciBt YWlsaW5nIGxpc3RzIGlzIHJlcXVpcmVkIHRvIGNvbWUgdG8gdGhpcw0KPiBjb25jbHVzaW9uLg0K PiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0K --_002_CY1PR0301MB07157CA483A83C42BDF7729DA3110CY1PR0301MB0715_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Sun, 14 Aug 2016 22:02:00 GMT"; modification-date="Sun, 14 Aug 2016 22:02:00 GMT" From: Dave Thaler To: "core@ietf.org" Subject: rt and if registry question Thread-Topic: rt and if registry question Thread-Index: AdHtxnz2wdbZZVFCRkuIwoepMaBv0Q== Date: Wed, 3 Aug 2016 20:40:10 +0000 Message-ID: Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-organization-originalclientipaddress: 2001:4898:80e8:a::2d5 x-ms-exchange-organization-originalserveripaddress: 2a01:111:e400:1429::23 x-ms-exchange-organization-submissionquotaskipped: False Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_" MIME-Version: 1.0 --_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In some conversations I've been in, I've found that different people read R= FC 6690 different ways. Section 3.1 says: The Resource Type 'rt' attribute is an opaque string used to assign an application-specific semantic type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource, this could be, e.g., an application-specific semantic type like "outdoor-temperature" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple Resource Types MAY be included in the value of this parameter, each separated by a space, similar to the relation attribute. The registry for Resource Type values is defined in Section 7.4. Section 3.2 is similar for 'if' values. And section 7.4 says: For both sub-registries, values starting with the characters "core" are registered using the IETF Review registration policy [RFC5226]. All other values are registered using the Specification Required policy, which requires review by a designated expert appointed by the IESG or their delegate. ... o URIs are reserved for free use as extension values for these attributes and MUST NOT be registered. So the question is, what values can be used _without_ registering. Clearly= the last sentence above says URIs are allowed. But it's apparently ambiguous whether other values= like "outdoor-temperature" in 3.1 (or "x.outdoor-temperature" or similar variations) can be used by an= application without registering it. My reading of 3.1 is that registration is required for everything but URIs,= but others read section 3.1 differently. Can the WG clarify what the intent is? Thanks, Dave --_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In some conversations I’ve been in, I’ve= found that different people read RFC 6690 different ways.

 

Section 3.1 says:

   The =
Resource Type 'rt' attribute is an opaque string used to assign<=
/span>
   an a=
pplication-specific semantic type to a resource.  One can think
   of t=
his as a noun describing the resource.  In the case of a
   temp=
erature resource, this could be, e.g., an application-specific
   sema=
ntic type like "outdoor-temperature" or a URI referencing a<=
/o:p>
   spec=
ific concept in an ontology like
   &quo=
t;http://swe=
et.jpl.nasa.gov/2.0/phys.owl#Temperature".  Multiple
   Reso=
urce Types MAY be included in the value of this parameter, each<=
/span>
   sepa=
rated by a space, similar to the relation attribute.  The
   regi=
stry for Resource Type values is defined in Section 7.4.

 

Section 3.2 is similar for ‘if’ values.<= o:p>

 

And section 7.4 says:

   For =
both sub-registries, values starting with the characters "core"
   are =
registered using the IETF Review registration policy [RFC5226].
   All =
other values are registered using the Specification Required
   poli=
cy, which requires review by a designated expert appointed by the
   IESG=
 or their delegate.

…

  = ; o  URIs are reserved for free use as extension values for these=

      attributes and = MUST NOT be registered.

 

So the = question is, what values can be used _without_ registering.  Cl= early the last sentence above

says UR= Is are allowed.   But it’s apparently ambiguous whether oth= er values like “outdoor-temperature”

in 3.1 = (or “x.outdoor-temperature” or similar variations) can be used = by an application without registering it.

My read= ing of 3.1 is that registration is required for everything but URIs, but ot= hers read section 3.1 differently.

Can the= WG clarify what the intent is?

&n= bsp;

Thanks,=

Dave

--_000_DM2PR0301MB0717289976DB2BFABAAAB900A3060DM2PR0301MB0717_-- --_002_CY1PR0301MB07157CA483A83C42BDF7729DA3110CY1PR0301MB0715_-- From nobody Mon Aug 15 08:05:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F36812D0BD; Mon, 15 Aug 2016 08:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieJBa_3jPKCE; Mon, 15 Aug 2016 08:05:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2B37812B01F; Mon, 15 Aug 2016 08:05:07 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-6e-57b1da210cf5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 9F.3E.04209.12AD1B75; Mon, 15 Aug 2016 17:05:05 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.13]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 17:05:04 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-groves-core-dynlink?= Thread-Index: AQHR9wZnlBtbQmo+DkyD1VuihglUrg== Date: Mon, 15 Aug 2016 15:05:04 +0000 Message-ID: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_4D4D8B9B-A914-4790-9CE0-BAC11C40F4DE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2J7iK7irY3hBn9b5CyOTLnLarHv7Xpm i1U/njA6MHssWfKTyWPaoswApigum5TUnMyy1CJ9uwSujJ3H/rIXnLGuWNX+m72BcYdFFyMn h4SAicTaeZeZuxi5OIQE1jNKrNh7gA3CWcwosfLrQjaQKjYBZ4lPzxrZQWwRATWJ1kmvwOLM AvkSKw99YAGxhQUqJLZ+Ws4GUVMr8fTva1YIW0/izrl2sDiLgKpE7+nNYDavgL3EmwfPwXoZ BcQkvp9awwQxU1zi1pP5TBDXiUg8vHiaDcIWlXj5+B8rhK0ksej2ZyaQQ5kFpjBKNL3YxQIx VFDi5MwnLBMYhWYhmTULWd0sJHUQRUkSjQe6mSFsbYllC18D2RxAto7E5IWMEGF5ie1v58CV fDx/hAnCNpV4ffQjVI21xIxfB9kgbEWJKd0P2Rcwcq9iFC1OLU7KTTcy1kstykwuLs7P08tL LdnECIzJg1t+q+5gvPzG8RCjAAejEg/vgo0bwoVYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCUR 3p6rG8OFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MAb3 3/DMNLLLuCNz4c3jA4Kbdv+/e0L+mJmjrM1Lcdv7zfePHvU8v724M7otbTrHIsYdU1Mdo1eX G95d7pnlyybyd6UPX+MjqZe7jk3UTL+/6qjmV7nMCsUyi/f5RsEvL+deLtqs0HRvWeDcZ5zK blvly9vsjD9azjXvsp7nmfXEObXiV2PKKyWW4oxEQy3mouJEAG/LXPnRAgAA Archived-At: Cc: "draft-groves-core-dynlink@ietf.org" Subject: [core] =?utf-8?q?_=F0=9F=94=94_Working_Group_Adoption_call_for_dr?= =?utf-8?q?aft-groves-core-dynlink?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 15:05:14 -0000 --Apple-Mail=_4D4D8B9B-A914-4790-9CE0-BAC11C40F4DE Content-Type: multipart/alternative; boundary="Apple-Mail=_EC9B63C2-417E-4F26-8922-2FF909E26557" --Apple-Mail=_EC9B63C2-417E-4F26-8922-2FF909E26557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear CoRE-WG, As we discussed at last IETF96, working group adoption has been = requested for draft-groves-core-dynlink. This draft is the result of a = document split and thus the initial status is that of adoption, = nevertheless that has to be confirmed on the list. Please reply with = your comments, including although not limited to whether or not you = support adoption. Non-authors are especially encouraged to comment. Since there are several concurrent WGA calls, we will end the call on = August 26, 2016. Thanks, Jaime and Carsten= --Apple-Mail=_EC9B63C2-417E-4F26-8922-2FF909E26557 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been requested for draft-groves-core-dynlink. This draft is the result of a document split and thus the initial status is that of adoption, nevertheless that has to be confirmed on the list. Please reply with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.

Since there are several concurrent WGA calls, we will end the call on August 26, 2016.

Thanks,
Jaime and Carsten --Apple-Mail=_EC9B63C2-417E-4F26-8922-2FF909E26557-- --Apple-Mail=_4D4D8B9B-A914-4790-9CE0-BAC11C40F4DE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MTUxNTA1MDRaMCMGCSqGSIb3DQEJBDEWBBRl SrIwOdctF78dvg7pCVcTxWWH0jBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQBzQGY52eTGuwbN/qaOfRch1dy806zzAzo7DtNBglm90wws30++9ZXwV2VE8O3X83v6BbdVdoDE MzDw2ow9N2FyjG9ZP5vWAULiyadIchoLFgnJVwy1IAxMkcAQFzwXWjWypRI2JP2VuwI8tXiSV7eD GHhFYmd+L4T2FmbcpAocaPIb0hgGxWoZ1SspPYmn5Cjd7QBtxXRSW54RWWJoU9EUkHsjsHLs/78t ACiI9omuznyTJmelUZgQDTgs7VykE1LTkyR4c9OlH1pE+rwIHYooghGrOxA8fnnv6t2CN1QUZsCV RZ8o6LuXkJgEH/xJsaVq3lmqBXeYhVNu5cxlpQMxAAAAAAAA --Apple-Mail=_4D4D8B9B-A914-4790-9CE0-BAC11C40F4DE-- From nobody Mon Aug 15 08:06:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C911012B01F; Mon, 15 Aug 2016 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abaSxATgxZey; Mon, 15 Aug 2016 08:06:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 65DC012B010; Mon, 15 Aug 2016 08:06:43 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-09-57b1da81782c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id C7.8E.04209.18AD1B75; Mon, 15 Aug 2016 17:06:41 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.13]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 17:06:40 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-somaraju-core-sid?= Thread-Index: AQHR9waf6/bJ+bHuyUKUc583312ekQ== Date: Mon, 15 Aug 2016 15:06:40 +0000 Message-ID: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_8D2B6B779FA44171959CD9080F6AF507ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdQLfx1sZwg9Z5xhZHptxltdj3dj2z xZN98g7MHkuW/GTymLYoM4ApissmJTUnsyy1SN8ugSvj7q/XTAW3hSoO3Wlkb2BsE+pi5OSQ EDCRePB4BXsXIxeHkMB6Rok1r/9COYsZJboa3jCCVLEJOEt8etbIDmKLCKhJtE56xQZiMwtk S+zZ+YUJxBYWKJPYdn41C0RNtcSF/TfZIGw9iZdNz8DmsAioSmy5Pw2snlfAXuLG8f+sIDaj gJjE91NrmCBmikvcejKfCeI6AYkle84zQ9iiEi8f/2OFsJUkFt3+DFWfLLFt1RsWiJmCEidn PmGZwCg0C8moWUjKZiEpm8XIARTXlFi/Sx+iRFFiSvdDdghbQ6J1zlwo21riy5bFjMhqFjBy rGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKKDW36r7mC8/MbxEKMAB6MSD++CjRvChVgT y4orcw8xSnAwK4nw9lzdGC7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampB ahFMlomDU6qBkffnSeUfAtK9Sw5+L/6xk/nnn1Ps3OcFveTmGB5puJej3KzCJmhd5jNpQqH4 ZqlXj44Zhqvq9h3sDc1qXapVlDudI/+2eWfqiifZaqJB1gpz+ZOzTu5Kueqqe0yvbiPfuuIl u2c/X/xGffPOeRu2ukt5uDO9Xcx08upaq01PYuzvfPTPZxO4psRSnJFoqMVcVJwIAL6iG3We AgAA Archived-At: Cc: "draft-somaraju-core-sid@ietf.org" Subject: [core] =?utf-8?q?_=F0=9F=94=94_Working_Group_Adoption_call_for_dr?= =?utf-8?q?aft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 15:06:45 -0000 --_000_8D2B6B779FA44171959CD9080F6AF507ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFLVdHLA0KDQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtpbmcg Z3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1zb21hcmFqdS1jb3Jl LXNpZC4gQXQgdGhlIElFVEYgbWVldGluZyB0aGUgcm9vbSBjb25zZW5zdXMgd2FzIGZvciBhZG9w dGlvbiAoMyBwZW9wbGUpLCBzaW5jZSBub3QgdG9vIG1hbnkgcGVvcGxlIGhhZCByZWFkIHRoZSBk cmFmdCB3ZSBoYXZlIHRvIHRha2UgaXQgdG8gdGhlIGxpc3QuIFBsZWFzZSByZXBseSB3aXRoIHlv dXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9y IG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5j b3VyYWdlZCB0byBjb21tZW50Lg0KDQpTaW5jZSB0aGVyZSBhcmUgc2V2ZXJhbCBjb25jdXJyZW50 IFdHQSBjYWxscywgd2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVndXN0IDI2LCAyMDE2Lg0KDQpU aGFua3MsDQpKYWltZSBhbmQgQ2Fyc3Rlbg0KDQo= --_000_8D2B6B779FA44171959CD9080F6AF507ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9094869106DDEC4C8F20A29233E629D7@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBDb1JFLVdHLDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29y a2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNvbWFyYWp1 LWNvcmUtc2lkLiBBdCB0aGUgSUVURiBtZWV0aW5nIHRoZSByb29tIGNvbnNlbnN1cyB3YXMgZm9y IGFkb3B0aW9uICgzIHBlb3BsZSksIHNpbmNlIG5vdCB0b28gbWFueSBwZW9wbGUgaGFkIHJlYWQg dGhlIGRyYWZ0IHdlIGhhdmUgdG8gdGFrZSBpdCB0byB0aGUgbGlzdC4mbmJzcDtQbGVhc2UgcmVw bHkNCiB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0 byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVz cGVjaWFsbHkmbmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KU2luY2UgdGhlcmUgYXJlIHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdl IHdpbGwgZW5kIHRoZSBjYWxsIG9uIDxiIGNsYXNzPSIiPg0KQXVndXN0IDI2LCAyMDE2PC9iPi48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KSmFpbWUg YW5kIENhcnN0ZW4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_8D2B6B779FA44171959CD9080F6AF507ericssoncom_-- From nobody Mon Aug 15 08:09:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1229612D123; Mon, 15 Aug 2016 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAYUFC3-UGyp; Mon, 15 Aug 2016 08:09:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9A11912D51F; Mon, 15 Aug 2016 08:08:58 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-03-57b1db07c32e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 2C.17.02493.70BD1B75; Mon, 15 Aug 2016 17:08:56 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.13]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 17:08:54 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1z?= =?utf-8?Q?elander-ace-object-security?= Thread-Index: AQHR9wbv++lBPHlWOkOzRYWQElHdPQ== Date: Mon, 15 Aug 2016 15:08:54 +0000 Message-ID: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_74A76AFBA3544FECB5FD89F180DECF9Fericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdVZfj9sZwg+/PZSyOTLnLarHv7Xpm i/tHP7A6MHssWfKTyWPaoswApigum5TUnMyy1CJ9uwSujNVHprEW9AtV/P19hKWBcZ9gFyMn h4SAicTuqZ8Yuxi5OIQE1jNKLNn6nhkkISSwmFHi/2VpEJtNwFni07NGdhBbREBNonXSKzaQ BmaBRkaJuc8XsYEkhAWqJf5+ec0MkhARaGCU+DHpOdBYDiBHT+LZ11SQGhYBVYmlP06A1fMK 2EusW3gSbBmjgJjE91NrmEBsZgFxiVtP5jNBXCcgsWTPeWYIW1Ti5eN/rBC2ksSi25+ZQMYz CyRLTL9dCTFSUOLkzCcsExiFZiGZNAuhahaSKoiwpsT6XfoQ1YoSU7ofskPYGhKtc+ZC2dYS C19tY0VWs4CRYxWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYAwd3PLbagfjweeOhxgFOBiV eHgXbNwQLsSaWFZcmXuIUYKDWUmEt+fqxnAh3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOF BNITS1KzU1MLUotgskwcnFINjBu6J3kK+FRc0zmocpHl+TwTrTd5l0pb5V7+mfc0PTLi2uXA VVufcca9Kr/tYJS5+MnRlo/c/Xort7D+LI937vbcfovvq9umO3JH5RNyNPXPa4i8ZblzR985 YPeOdd+/cHhOSvlvo/3k2sGpNa13hbTWnRY2CVsiNGFqdsLjag6PaQyulxjfsCqxFGckGmox FxUnAgC5sLUrnQIAAA== Archived-At: Cc: "draft-selander-ace-object-security@ietf.org" Subject: [core] =?utf-8?q?_=F0=9F=94=94_Working_Group_Adoption_of_draft-se?= =?utf-8?q?lander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 15:09:04 -0000 --_000_74A76AFBA3544FECB5FD89F180DECF9Fericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFLVdHLA0KDQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtpbmcg Z3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1zZWxhbmRlci1hY2Ut b2JqZWN0LXNlY3VyaXR5LiBBdCB0aGUgSUVURiBtZWV0aW5nIHRoZSByb29tIGNvbnNlbnN1cyB3 YXMgc3Ryb25nbHkgc3VwcG9ydGluZyBhZG9wdGlvbiAoMTAtMTIgcGVvcGxlKS4gUGxlYXNlIHJl cGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5v dCBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLiBOb24tYXV0 aG9ycyBhcmUgZXNwZWNpYWxseSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQoNClNpbmNlIHRoZXJl IGFyZSBzZXZlcmFsIGNvbmN1cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0aGUgY2FsbCBv biBBdWd1c3QgMjYsIDIwMTYuDQoNClRoYW5rcywNCkphaW1lIGFuZCBDYXJzdGVuDQoNCg== --_000_74A76AFBA3544FECB5FD89F180DECF9Fericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBDb1JFLVdHLDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29y a2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNlbGFuZGVy LWFjZS1vYmplY3Qtc2VjdXJpdHkuIEF0IHRoZSBJRVRGIG1lZXRpbmcgdGhlIHJvb20mbmJzcDtj b25zZW5zdXMgd2FzIHN0cm9uZ2x5IHN1cHBvcnRpbmcgYWRvcHRpb24gKDEwLTEyIHBlb3BsZSku Jm5ic3A7UGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVk aW5nDQogYWx0aG91Z2ggbm90Jm5ic3A7bGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3Vw cG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkmbmJzcDtlbmNvdXJhZ2Vk IHRvIGNvbW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2luY2UgdGhlcmUgYXJl IHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uJm5i c3A7PGIgY2xhc3M9IiI+QXVndXN0IDI2LCAyMDE2PC9iPi48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KSmFpbWUgYW5kIENhcnN0ZW4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_74A76AFBA3544FECB5FD89F180DECF9Fericssoncom_-- From nobody Mon Aug 15 08:09:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F612D123; Mon, 15 Aug 2016 08:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt4Gnyy0-Sdg; Mon, 15 Aug 2016 08:09:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 04CF912D0BD; Mon, 15 Aug 2016 08:09:32 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-75-57b1db2ad2ed Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 5C.27.02493.A2BD1B75; Mon, 15 Aug 2016 17:09:31 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.13]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 17:09:30 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1i?= =?utf-8?Q?ormann-core-cocoa?= Thread-Index: AQHR9wcF7XOEF78dYUGLLT8qNc8C1A== Date: Mon, 15 Aug 2016 15:09:29 +0000 Message-ID: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_9E8BCA5C30204BFC9C1D321A6F53DD7Eericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdQFf79sZwgwtfZCyOTLnLarHv7Xpm i4NvUh2YPZYs+cnkMW1RZgBTFJdNSmpOZllqkb5dAlfG2SuHmQs2C1Z8OLKYsYHxkUAXIyeH hICJxLRV91m6GLk4hATWM0psn3WWCcJZzCjx+sAiFpAqNgFniU/PGtlBbBEBNYnWSa/Yuhg5 OJgFciUOzNQECQsLFEp0fFzKCFFSJnG/pQfK1pP4OXc2K4jNIqAq0fPxNpjNK2AvcebULLCR jAJiEt9PrWECsZkFxCVuPZnPBHGcgMSSPeeZIWxRiZeP/7FC2EoSi25/hqpPlljyeB0TxExB iZMzn7BMYBSahWTULCRls5CUzQL7QFNi/S59iBJFiSndD9khbA2J1jlzoWxribdPFzAiq1nA yLGKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCGDm75bbWD8eBzx0OMAhyMSjy8CzZuCBdi TSwrrsw9xCjBwawkwmtza2O4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2amp BalFMFkmDk6pBsaFddkbhVZ+tDrVVCar83TtO6mYTS7MzWGtnVujPn/ZfNpzKpuNu+h8BVPG Q+93XVTYGtYzj/fbjyMFhi+0psl5cbTfZ1i72G6bwfuARrHNyzuWrv3FOKM/cZXWrsMla/nV Snfzcj/9ahP9rJUr+ePKRXNEWP/0xSfr/+YNVWCYUFNd9Tvs7WIlluKMREMt5qLiRACzIUyB nQIAAA== Archived-At: Cc: "draft-bormann-core-cocoa@ietf.org" Subject: [core] =?utf-8?q?_=F0=9F=94=94_Working_Group_Adoption_of_draft-bo?= =?utf-8?q?rmann-core-cocoa?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 15:09:37 -0000 --_000_9E8BCA5C30204BFC9C1D321A6F53DD7Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFLVdHLA0KDQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtpbmcg Z3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1ib3JtYW5uLWNvcmUt Y29jb2EuIEF0IHRoZSBJRVRGIG1lZXRpbmcgdGhlIHJvb20gY29uc2Vuc3VzIHdhcyBmb3IgYWRv cHRpb24uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1 ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBh ZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50 Lg0KDQpTaW5jZSB0aGVyZSBhcmUgc2V2ZXJhbCBjb25jdXJyZW50IFdHQSBjYWxscywgd2Ugd2ls bCBlbmQgdGhlIGNhbGwgb24gQXVndXN0IDI2LCAyMDE2Lg0KDQpUaGFua3MsDQpKYWltZSBhbmQg Q2Fyc3Rlbg0KDQo= --_000_9E8BCA5C30204BFC9C1D321A6F53DD7Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBDb1JFLVdHLDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29y a2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWJvcm1hbm4t Y29yZS1jb2NvYS4gQXQgdGhlIElFVEYgbWVldGluZyB0aGUgcm9vbSZuYnNwO2NvbnNlbnN1cyB3 YXMgZm9yIGFkb3B0aW9uLiZuYnNwO1BsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIg Y29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QmbmJzcDtsaW1pdGVkIHRvIHdoZXRoZXIg b3Igbm90IHlvdQ0KIHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5 Jm5ic3A7ZW5jb3VyYWdlZCB0byBjb21tZW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClNpbmNlIHRoZXJlIGFyZSBzZXZlcmFsIGNvbmN1cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVu ZCB0aGUgY2FsbCBvbiZuYnNwOzxiIGNsYXNzPSIiPkF1Z3VzdCAyNiwgMjAxNjwvYj4uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzLDxiciBjbGFzcz0iIj4NCkphaW1lIGFuZCBD YXJzdGVuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9E8BCA5C30204BFC9C1D321A6F53DD7Eericssoncom_-- From nobody Mon Aug 15 08:10:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D2412D123; Mon, 15 Aug 2016 08:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tedov7NYcPp; Mon, 15 Aug 2016 08:10:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2C0E412B010; Mon, 15 Aug 2016 08:10:27 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-1a-57b1db62a5f1 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id AC.47.02493.26BD1B75; Mon, 15 Aug 2016 17:10:26 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.13]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 17:10:24 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1r?= =?utf-8?Q?oster-core-coap-pubsub?= Thread-Index: AQHR9wcm3Yx0mHzzoEi7ZsSh5hZ+Zw== Date: Mon, 15 Aug 2016 15:10:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_CDE6F2247A6A4F899E5CE46AC9FACA35ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbE9XDfp9sZwg+n/lS2OTLnLarHv7Xpm i2+b+lkdmD2WLPnJ5DFtUWYAUxSXTUpqTmZZapG+XQJXxo7Vy1gK2oUqOmZOZG1g3CbYxcjJ ISFgIjFzwlG2LkYuDiGB9YwSHZ1TWEESQgKLGSXu3AsFsdkEnCU+PWtkB7FFBNQkWie9YgOx mQXKJdq7PoLZwgJlEv9/PmGEqKmWmLqznxnC1pP4NHEBE4jNIqAqsby3A8jm4OAVsJeYsL8K JMwoICbx/dQaJoiR4hK3nsxngrhNQGLJnvPMELaoxMvH/1ghbCWJRbc/Q9UnS2xvmgsW5xUQ lDg58wnLBEahWUhGzUJSNgtJ2SygK5gFNCXW79KHKFGUmNL9kB3C1pBonTMXyraWWPjtFguy mgWMHKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAmPo4JbfVjsYDz53PMQowMGoxMO7YOOG cCHWxLLiytxDjBIczEoivDa3NoYL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKa nZpakFoEk2Xi4JRqYFz8THWN0RQpxU2Wk8Mbchz4Wjba9swyPNBYLjx/xlEjOXbfhsTzeZJ1 81mOzuIr5dDMDfr9XHDvdK435/YHxx9aLVRb/ZlpwoEF78+W+6h9f33AbNIh27/af2fVLZqx /dwXX+ElVvLxnffNnVYnMmVcemQw9/r388fOPnY64SWiZNz9VFWe9aASS3FGoqEWc1FxIgB8 w/mHnQIAAA== Archived-At: Cc: "draft-koster-core-coap-pubsub@ietf.org" Subject: [core] =?utf-8?q?_=F0=9F=94=94_Working_Group_Adoption_of_draft-ko?= =?utf-8?q?ster-core-coap-pubsub?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 15:10:29 -0000 --_000_CDE6F2247A6A4F899E5CE46AC9FACA35ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFLVdHLA0KDQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtpbmcg Z3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1rb3N0ZXItY29yZS1j b2FwLXB1YnN1Yi4gQXQgdGhlIElFVEYgbWVldGluZyB0aGUgcm9vbSBjb25zZW5zdXMgd2FzIHN0 cm9uZ2x5IHN1cHBvcnRpbmcgYWRvcHRpb24gKH4xMCBwZW9wbGUpLiBQbGVhc2UgcmVwbHkgdG8g dGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0 ZWQgdG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFy ZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCg0KU2luY2UgdGhlcmUgYXJlIHNl dmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3Vz dCAyNiwgMjAxNi4NCg0KVGhhbmtzLA0KSmFpbWUgYW5kIENhcnN0ZW4NCg0K --_000_CDE6F2247A6A4F899E5CE46AC9FACA35ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBDb1JFLVdHLDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29y a2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWtvc3Rlci1j b3JlLWNvYXAtcHVic3ViLiBBdCB0aGUgSUVURiBtZWV0aW5nIHRoZSByb29tJm5ic3A7Y29uc2Vu c3VzIHdhcyBzdHJvbmdseSBzdXBwb3J0aW5nIGFkb3B0aW9uICh+MTAmbmJzcDtwZW9wbGUpLiZu YnNwO1BsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGlu ZyBhbHRob3VnaA0KIG5vdCZuYnNwO2xpbWl0ZWQgdG8gd2hldGhlciZuYnNwO29yIG5vdCB5b3Ug c3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkmbmJzcDtlbmNvdXJh Z2VkIHRvIGNvbW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2luY2UgdGhlcmUg YXJlIHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9u Jm5ic3A7PGIgY2xhc3M9IiI+QXVndXN0IDI2LCAyMDE2PC9iPi48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KSmFpbWUgYW5kIENhcnN0ZW4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CDE6F2247A6A4F899E5CE46AC9FACA35ericssoncom_-- From nobody Mon Aug 15 08:26:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733712D8D3 for ; Mon, 15 Aug 2016 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJzhIZ8U0djj for ; Mon, 15 Aug 2016 08:26:50 -0700 (PDT) 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 AB57812D89D for ; Mon, 15 Aug 2016 08:26:49 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.215]) by smtp-cloud6.xs4all.net with ESMTP id XTSn1t00f4eRkWy01TSn3X; Mon, 15 Aug 2016 17:26:47 +0200 Received: from 2001:983:a264:1:e4ec:b1fe:135b:cf39 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 15 Aug 2016 17:26:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 15 Aug 2016 17:26:47 +0200 From: peter van der Stok To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> Message-ID: X-Sender: stokcons@xs4all.nl (2iSnJfh9cBmp3Huv51SSf2Lqd6UPXuhA) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-somaraju-core-sid@ietf.org, "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 15:26:51 -0000 Hi All, Andy and I are preparing drafts which present alternatives (complements) to SID. Also we are preparing a draft which specifies a a content format that specifies the payload format for that alternative. Although I approve of the work done in the SID draft, I think that we first need to discuss the cited coming drafts because they may have an impact on the presentation and scope of the SID draft. Peter Jaime Jiménez schreef op 2016-08-15 17:06: > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been > requested for draft-somaraju-core-sid. At the IETF meeting the room > consensus was for adoption (3 people), since not too many people had > read the draft we have to take it to the list. Please reply with your > comments, including although not limited to whether or not you support > adoption. Non-authors are especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on > AUGUST 26, 2016. > > Thanks, > Jaime and Carsten > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 15 09:50:17 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CF412D73E for ; Mon, 15 Aug 2016 09:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9El5N0C-pu4 for ; Mon, 15 Aug 2016 09:50:14 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0120.outbound.protection.outlook.com [104.47.37.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C077712D1D5 for ; Mon, 15 Aug 2016 09:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8883ore1YrI3sfkCZhI+rI7HJNRGjzLAyvCnJeWdRGc=; b=JLnNcdj7+4w9bG223IHRPTmGcFZKy0SsQ3NvYtJdWVjw7BfSjtqJRAcN1ma8eURwxCD31ZQFNYh9ljDQhwaeX6/FiU0NljWDEsl6NFo1a6urZ+VQ9PJG/9CXQfwY+jrJGEoGjggl0g9ZK/cypsja4OhGbwOxgnc6xtzqsIq3M9U= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Mon, 15 Aug 2016 16:49:30 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0557.022; Mon, 15 Aug 2016 16:49:30 +0000 From: Brian Raymor To: Carsten Bormann Thread-Topic: [core] Updates to coap-tcp-tls Thread-Index: AdHzatCWVXEOdWrbQLiOhi+qiefTngALuagAABwOKmAAEYS0gAAYxiggAAxbvQAAAuvYoA== Date: Mon, 15 Aug 2016 16:49:30 +0000 Message-ID: References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> <57AE4652.7020306@tzi.org> In-Reply-To: <57AE4652.7020306@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2001:4898:80e8:9::e5] x-ms-office365-filtering-correlation-id: 5f714ed9-1ca3-488e-f093-08d3c52c20d1 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2724; 6:lMfWHAi4Fv1C4FqW95dr0u3HANHdugBigZTh6fzo4z+6hDtskJ4teWnJWhSplb9VQHOAzG6uNfTDWcTKKRng7aHn/qbwIsR6lwRD58UpeCBfdTZxeiFyi/OIwThbAPqiTSl/Pvzw3UB+lRr1YHrvQ7CMbRpphmDcPgMvfa0GQitIhA9zjG6iOS99g2GOkvNAHMGbuiZJFlc36+zlBcp+XDFZxgzo7NWlb1DC5iX3f0ApxvMIAVCZTMoQF8uA02/X/9RcVQrF42EilUnnTFusidI+B/fyaxfY6x3SASskiNky6qZeXk/2RoeTplU4oTNp2amru7OM7zXC0UWSPUob4Q==; 5:ew5aoZ9srhzdZ93I6ztYmsbQaWodu+yB/huUUi5OFh7nMC+dSoriXMty5c5E77GwycT7Y3LeR0rQb82lzRty673AS0WftiCA/PyVI8MSkCWdut58WRpP4ayFvHIJGQDBm9EaIwoGYRdp7QxizIiN3A==; 24:9Dt42pL5S2LvrG5vXn4bJRbLuRv+yJb+d6ItAaA3NHhyJVRMlprZ3KoyCG6H46lLo2JZC8YGyiXwiygZVqUoMGD2h7DAthz/jg/pPdE7rOw=; 7:7jA3hyMdSQNE61g9+2BcJEKN7+Im/cI+xXcPSQoH5DoX4f4JUcfkHzlz76LzdZhK1U2y3dtBwqt4db4DaIllXSbjo7XBaT5HjoDCcte9m7iYwqd8yBJKGU5EBPtmI32Xw2Ur6SPO4RU/LjfMq3L00hD083ekDiQnS+VHZNulP2L+jnfgEs9KRuM9NbWAlEaECvFgLA8IsQwiVkI/IuWV0hgHdhAymSe30uJP88YQ6AhD/bPvM5WTPygeUnFxFiyt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2724; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2724; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2724; x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(13464003)(24454002)(199003)(68736007)(8936002)(10400500002)(3660700001)(81166006)(81156014)(10290500002)(9686002)(5005710100001)(7696003)(86362001)(8990500004)(7846002)(7736002)(97736004)(74316002)(305945005)(8676002)(15650500001)(19580395003)(105586002)(87936001)(86612001)(189998001)(3280700002)(122556002)(92566002)(10090500001)(19580405001)(586003)(2900100001)(2906002)(4326007)(6116002)(93886004)(102836003)(2950100001)(54356999)(11100500001)(50986999)(76176999)(77096005)(101416001)(106356001)(33656002)(5002640100001)(99286002)(110136002)(230783001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2724; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2016 16:49:30.7442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2724 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:50:16 -0000 DQpIaSBDYXJzdGVuLA0KDQpHb29kIHBvaW50Lg0KDQpIb3cgYWJvdXQ6DQoNCklmIHRoZSBBcHBs aWNhdGlvbi1MYXllciBQcm90b2NvbCBOZWdvdGlhdGlvbiBFeHRlbnNpb24gKEFMUE4pIFtSRkM3 MzAxXSBpcyBhdmFpbGFibGUgaW4gYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgVExTIHByb3Rv Y29sIHN0YWNrcywgQ29BUCBvdmVyIFRMUyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBwZXJmb3JtIHBy b3RvY29sIG5lZ290aWF0aW9uIGluIFRMUyB1c2luZyB0aGUgImNvYXAiIHByb3RvY29sIGlkZW50 aWZpZXIgZGVmaW5lZCBpbiBTZWN0aW9uIDguNy4gVGhlIHNlcnZlciBNQVkgYWxzbyBvZmZlciBD b0FQIG92ZXIgVExTIG9ubHkgb24gcG9ydCBudW1iZXIgNTY4NCBmb3IgZXhjZXB0aW9uYWwgY2Fz ZXMgd2hlcmUgQUxQTiBpcyB1bmF2YWlsYWJsZSBvbiB0aGUgY2xpZW50IG9yIHRoZSBzZXJ2ZXIu DQoNCi4uLkJyaWFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVu IEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddIA0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTIs IDIwMTYgMjo1OCBQTQ0KVG86IEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5j b20+DQpDYzogQ2hyaXN0aWFuIEdyb3ZlcyA8Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb20+ OyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFVwZGF0ZXMgdG8gY29hcC10Y3At dGxzDQoNCkhpIEJyaWFuLA0KDQp0aGlzIHRleHQgZG9lc24ndCBzZWVtIHRvIGFkZHJlc3MgdGhl IGNhc2Ugd2hlcmUgdGhlIEFMUE4gZnVuY3Rpb25hbGl0eQ0KaXNuJ3QgYXZhaWxhYmxlIGF0IHRo ZSBvdGhlciBlbmQuICBFLmcuLCBhIHNlcnZlciBpbnN0YW5jZSBtYXkgdmVyeSB3ZWxsDQpoYXZl IEFMUE4gaW1wbGVtZW50ZWQsIGJ1dCBzdGlsbCBlbGVjdHMgdG8gb2ZmZXIgYSBjb2FwczovLy4u Li46NTY4NA0Kc2VydmVyIGZvciBjbGllbnRzIHRoYXQgZG9uJ3QuDQoNCkdyw7zDn2UsIENhcnN0 ZW4NCg0KQnJpYW4gUmF5bW9yIHdyb3RlOg0KPiBJZiB0aGUgQXBwbGljYXRpb24tTGF5ZXIgUHJv dG9jb2wgTmVnb3RpYXRpb24gRXh0ZW5zaW9uIChBTFBOKSBbUkZDNzMwMV0gaXMgYXZhaWxhYmxl IGluIHRoZSBUTFMgcHJvdG9jb2wgc3RhY2ssIENvQVAgb3ZlciBUTFMgaW1wbGVtZW50YXRpb25z IE1VU1QgcGVyZm9ybSBwcm90b2NvbCBuZWdvdGlhdGlvbiBpbiBUTFMgdXNpbmcgdGhlICJjb2Fw IiBwcm90b2NvbCBpZGVudGlmaWVyIGRlZmluZWQgaW4gU2VjdGlvbiA4LjcuIEluIGV4Y2VwdGlv bmFsIGNhc2VzIHdoZXJlIEFMUE4gaXMgdW5hdmFpbGFibGUsIENvQVAgb3ZlciBUTFMgaW1wbGVt ZW50YXRpb25zIE1VU1QgdXNlIHBvcnQgbnVtYmVyIDU2ODQuDQo= From nobody Mon Aug 15 12:10:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5F12D0D1 for ; Mon, 15 Aug 2016 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AXLapPywAkl for ; Mon, 15 Aug 2016 12:10:32 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B76412B053 for ; Mon, 15 Aug 2016 12:10:32 -0700 (PDT) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id CEA8C41C091; Mon, 15 Aug 2016 21:10:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id AcT7pJTFMLtz; Mon, 15 Aug 2016 21:10:29 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id B4BA941C093; Mon, 15 Aug 2016 21:10:22 +0200 (CEST) Message-ID: <57B2139D.4030202@tzi.org> Date: Mon, 15 Aug 2016 21:10:21 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Brian Raymor References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> <57AE4652.7020306@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 19:10:34 -0000 Brian Raymor wrote: > If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is available in both the client and server TLS protocol stacks, CoAP over TLS implementations MUST perform protocol negotiation in TLS using the "coap" protocol identifier defined in Section 8.7. The server MAY also offer CoAP over TLS only on port number 5684 for exceptional cases where ALPN is unavailable on the client or the server. That works for me. With these interoperability mandates, I'm generally in favor of being very specific about what an implementation is supposed to do or not supposed to do. Let me try to summarize: -- A TLS server MAY offer a coaps+tcp endpoint on TCP port 5864 if it doesn't support ALPN and/or to accommodate TLS clients that don't. A TLS server MAY offer coaps+tcp endpoints on TCP ports different from 5684 if it does support ALPN. -- On TCP ports different from 5684, a coaps+tcp TLS client MUST offer ALPN value 'coap', and the coaps+tcp TLS server only becomes active if the TLS server selects the ALPN value 'coap'. (If a different ALPN value is negotiated, or if the ALPN negotiation fails and thus causes a fatal alert, the present specification does become active.) -- On TCP port 5684, a TLS client MAY offer ALPN value 'coap' and a coaps+tcp TLS server MAY then select ALPN value 'coap'. (If a different ALPN value is negotiated, or if the ALPN negotiation fails and thus causes a fatal alert, the present specification does not become active. **) If the client does not send ALPN at all, coaps+tcp is assumed to be selected on port 5684 only. If the client does send ALPN, and the server does not support ALPN, the negotiation will result in no ALPN value being explicitly selected [check this], and, again, coaps+tcp is assumed to be selected on port 5684 only. **) If a different ALPN is selected on port 5864, [define behavior here]. Phew. Are these all the cases we need to worry about? Should it be allowed to negotiation ALPN ≠ 'coap' on port 5684? (Probably yes, to enable the negotiation of a 'coap2' etc.; we can't really restrict what can be negotiated here without predicting the future. Or we could completely disallow the use of ALPN on port 5684.) Grüße, Carsten From nobody Mon Aug 15 21:17:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96F126579; Mon, 15 Aug 2016 21:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWXtXbKTqrTc; Mon, 15 Aug 2016 21:17:12 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20BB124281; Mon, 15 Aug 2016 21:17:12 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l203so84781777oib.1; Mon, 15 Aug 2016 21:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qHbSw7vSIujPWu+i0UmvvIsC7VxG6hc13msLgWZoFoA=; b=Gt8UBLJXTnIHZLhWi5FfMu57jTb2NrELqiORs0Dly1oiSxJUMnp/e2Qd7pjJ78Nw/n 38Y45k4DCauV9R51liu812toOm2rWTKIolRAgRocUXE20Urd3JLNqtXYncNo5JtzRp1r miag+jipxRP+8sVpJHj80m+a5AhhAIcL+LZ304sXpsGK2enhNREeFZILL4+WMU3kbRfC PrzsYuoVMfas0Wp10WX7kvthq0g6gWOPZ0JxhiC3nG1AlGMBS+HPmA5A6oJIwxT0+WGF PgnPWGivG/+c5i4Yaa+hA1xJhr28UYrSifr+Q83ic58NJs1m5VzROqFh3f/PhcEWdRmC qlIQ== 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:from:date :message-id:subject:to:cc; bh=qHbSw7vSIujPWu+i0UmvvIsC7VxG6hc13msLgWZoFoA=; b=hKuGYyhrzqtsEwe8Pqa+pfM9aBMHfWxAB/KJ1ppL5exlGQIHNsSscJRhx3QR6SgA9u K/GC1YU3hpI0w+H+vqR3sh5N2JkzF3lRbY6jcLTZ4tBzEB+quu6jidcTUNAkXteb2JCm eqZcq0aIQNpHsxrTF6US3iOQiTSlvbbLC8EGOy/Ra096OgSj4hTlOrKpPbAWrs6SShaH d8jOUQJjVG9GwuquV2fPNd4Tzpu2dz+SiUC+3BjUwp6TpiMIU1YXqsht67rdfHhU2qDw LFyzo108Qyt8AHuoSx3SexFSYBSQI4nWFHvcZswE3FgYguNUNx611yRTnuyUIq6nSxD/ OzDQ== X-Gm-Message-State: AEkoouufBuGAL8IzKJPOToehU+YPLuUpO2W5SFDgVfWAyAGzE9V9E9dcQAOjWw0zAKTbL4UHS/jhSuukYzKTuQ== X-Received: by 10.157.25.165 with SMTP id k34mr10308556otk.169.1471321032024; Mon, 15 Aug 2016 21:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.181.193 with HTTP; Mon, 15 Aug 2016 21:17:11 -0700 (PDT) Received: by 10.202.181.193 with HTTP; Mon, 15 Aug 2016 21:17:11 -0700 (PDT) In-Reply-To: <982B626E107E334DBE601D979F31785C5D053452@blreml501-mbx> References: <982B626E107E334DBE601D979F31785C5D053452@blreml501-mbx> From: Rahul Jadhav Date: Tue, 16 Aug 2016 06:17:11 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary=94eb2c09d0b476e7be053a289f46 Archived-At: Cc: draft-bormann-core-cocoa@ietf.org Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-bor?= =?utf-8?q?mann-core-cocoa?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 04:17:14 -0000 --94eb2c09d0b476e7be053a289f46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support adoption of this work. The work is of significance in cases where the RTT is uneven amongst the nodes in LLNs and arriving at an optimal RTO will significantly save retransmission overhead. Will keep reviewing and testing the draft in the future. Thanks for this work. > > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Jaime Jim=C3=A9nez > Sent: 15 August 2016 PM 08:39 > To: core@ietf.org WG > Cc: draft-bormann-core-cocoa@ietf.org > Subject: [core] =F0=9F=94=94 Working Group Adoption of draft-bormann-core= -cocoa > > > > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been requested for draft-bormann-core-cocoa. At the IETF meeting the room consensus was for adoption. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on August 26, 2016. > > Thanks, > Jaime and Carsten > > --94eb2c09d0b476e7be053a289f46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I support adoption of this work. The work is of significance= in cases where the RTT is uneven amongst the nodes in LLNs and arriving at= an optimal RTO will significantly save retransmission overhead. Will keep = reviewing and testing the draft in the future.

Thanks for this work.

> =C2=A0
>
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Jaime Jim=C3=A9nez
> Sent: 15 August 2016 PM 08:39
> To: core@ietf.org WG
> Cc: draft-bormann= -core-cocoa@ietf.org
> Subject: [core] =F0=9F=94=94 Working Group Adoption of draft-bormann-c= ore-cocoa
>
> =C2=A0
>
> Dear CoRE-WG,
>
> As we discussed at last IETF96, working group adoption has been reques= ted for draft-bormann-core-cocoa. At the IETF meeting the room=C2=A0consens= us was for adoption.=C2=A0Please reply to the list with your comments, incl= uding although not=C2=A0limited to whether or not you support adoption. Non= -authors are especially=C2=A0encouraged to comment.
>
> Since there are several concurrent WGA calls, we will end the call on= =C2=A0August 26, 2016.
>
> Thanks,
> Jaime and Carsten
>
> =C2=A0

--94eb2c09d0b476e7be053a289f46-- From nobody Mon Aug 15 21:18:40 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C7F12B00A for ; Mon, 15 Aug 2016 21:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3ZC_I5LSBv9 for ; Mon, 15 Aug 2016 21:18:36 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 03AB8126579 for ; Mon, 15 Aug 2016 21:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=52mN43Qmj5GtV/c4zeBL33lqMwMF9pkGdq0ampiFbjs=; b=siX6yqgU3d26R3UG3f+UfbdzDd Ti4n3FGMcR5XBztBayx1KPcYWZBx12j12MF9YIojeP6oToQtJByVWqHcQDlovVdcKTPtvLF4fhG8q T6CG4M56gs2XpWpOI/SABt5b+yGuxlALohWwblo0SjPuET4ngI2WkQVdozqcdloa4IkgY3sKcjV72 FJeZns8BgklhZIjIXY/XagQU5TvP7rB9fz0WoFvko/TOxyyKZC4hrRI5e62C3cFz1UevwswQDz8AE v/jbi5YIFKDQBvn9xLARwbeaDQER/J6V0Kc/Zm9n7ro98itNhzBIobKCXWGENk3yIpGkhGI2f8eDy MVH2Q1Xg==; Received: from ppp118-209-188-70.lns20.mel8.internode.on.net ([118.209.188.70]:52356 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bZVpe-003var-2U; Tue, 16 Aug 2016 14:18:30 +1000 To: Carsten Bormann , Brian Raymor References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> <57AE4652.7020306@tzi.org> <57B2139D.4030202@tzi.org> From: Christian Groves Message-ID: Date: Tue, 16 Aug 2016 14:18:27 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57B2139D.4030202@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 04:18:38 -0000 "If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is available in both the client and server TLS protocol stacks..." seems to me to imply there's some prior knowledge of whether ALPN is supported in both the client and server. A CoAP client (TLS Client) will know whether it supports ALPN but not necessarily what the TLS server supports. A Client will send a clientHello with APLN "CoAP" and if the TLS server doesn't support the "CoAP" ALPN value, RFC7301 specifies that it should respond with a fatal alert. In that case the fallback would be to use port number 5684. Regards, Christian On 16/08/2016 5:10 AM, Carsten Bormann wrote: > Brian Raymor wrote: >> If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is available in both the client and server TLS protocol stacks, CoAP over TLS implementations MUST perform protocol negotiation in TLS using the "coap" protocol identifier defined in Section 8.7. The server MAY also offer CoAP over TLS only on port number 5684 for exceptional cases where ALPN is unavailable on the client or the server. > That works for me. With these interoperability mandates, I'm generally > in favor of being very specific about what an implementation is supposed > to do or not supposed to do. Let me try to summarize: > > -- A TLS server MAY offer a coaps+tcp endpoint on TCP port 5864 if it > doesn't support ALPN and/or to accommodate TLS clients that don't. A > TLS server MAY offer coaps+tcp endpoints on TCP ports different from > 5684 if it does support ALPN. > -- On TCP ports different from 5684, a coaps+tcp TLS client MUST offer > ALPN value 'coap', and the coaps+tcp TLS server only becomes active if > the TLS server selects the ALPN value 'coap'. (If a different ALPN > value is negotiated, or if the ALPN negotiation fails and thus causes a > fatal alert, the present specification does become active.) > -- On TCP port 5684, a TLS client MAY offer ALPN value 'coap' and a > coaps+tcp TLS server MAY then select ALPN value 'coap'. (If a different > ALPN value is negotiated, or if the ALPN negotiation fails and thus > causes a fatal alert, the present specification does not become active. > **) If the client does not send ALPN at all, coaps+tcp is assumed to be > selected on port 5684 only. If the client does send ALPN, and the > server does not support ALPN, the negotiation will result in no ALPN > value being explicitly selected [check this], and, again, coaps+tcp is > assumed to be selected on port 5684 only. > **) If a different ALPN is selected on port 5864, [define behavior here]. > > Phew. Are these all the cases we need to worry about? > > Should it be allowed to negotiation ALPN ≠ 'coap' on port 5684? > (Probably yes, to enable the negotiation of a 'coap2' etc.; we can't > really restrict what can be negotiated here without predicting the > future. Or we could completely disallow the use of ALPN on port 5684.) > > Grüße, Carsten > From nobody Mon Aug 15 22:45:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D075512D13A for ; Mon, 15 Aug 2016 22:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOWAvFBe7CE3 for ; Mon, 15 Aug 2016 22:45:51 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0120.outbound.protection.outlook.com [104.47.34.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D000612D135 for ; Mon, 15 Aug 2016 22:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dpWgBwBDtkTbewhPYhVsiO9OBq9oDo12pSbIqURc8Sw=; b=NvdzbARCd4ZfarylncdFRwIXurmhJVplkZcMpNDO3+BX2H5fDlJVdayyiC1S80YjjYJe398bfH1fVMsTdCtB2dQLLvffMCPJmksw+uPHNjpPQU1f93ta37KxuTcwHQ6vwUNmEVDe9232FhLuhYWZ7y9H6sFq3Pd8SbqwTP2jagQ= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2723.namprd03.prod.outlook.com (10.173.144.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 16 Aug 2016 05:45:48 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0557.022; Tue, 16 Aug 2016 05:45:48 +0000 From: Brian Raymor To: Christian Groves , Carsten Bormann Thread-Topic: [core] Updates to coap-tcp-tls Thread-Index: AdHzatCWVXEOdWrbQLiOhi+qiefTngALuagAABwOKmAAEYS0gAAYxiggAAxbvQAAAuvYoACOHFeAABMkZYAAAW1AEA== Date: Tue, 16 Aug 2016 05:45:48 +0000 Message-ID: References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> <57AE4652.7020306@tzi.org> <57B2139D.4030202@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 3635b364-55f9-4b17-c209-08d3c5989337 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2723; 6:LrjZlw4I9a+/JVxF7/AuVMNVjfemmycpD5lj6AL0HqWMJWsx03lDaxwdtQOVNTgupZLDL+pM0oRyhHkrNRpr0oySxIgwLG95sloLW5u+58ljouYveTz+qnG+R+6bb+/VZyEO0g0L3q8B76FVrzzHAYX2CqS9bo+4OdLELFO67aPKX1xUR/17uV2Cd0RsuUj99gmhqZMzCZR+Wxdcq0duLlIcHRwICPhx1m14k3Hfz2XPZQIsCOXGj93Vgb8+VTd9rjVvboZnJ1roeiWRQu9l3pBwfeJn/126SxRL+ljjPGiq8O1GysImmzJ8IHGBF4QkNlLPUsUv5guw0Jdg6tIJ8g==; 5:JXm9G/BJPDXryIFJhjh1O3IYRojt7rf2t2dgbIlSg3lAQCil19v+zsS7CH9NN45Mfy3tYAvH6CmmkFCTk/WYE6pHODNtd99CEBldfZV1oU533yrfqkNMSaEIAmwKHjtzUfX00tfqmKstoogYlk0gvw==; 24:if+dQtNbix3F4YDniERMop8RUubuUQNUtgY7si1/pHjtNMxLYo8SsAgKP6ndSFMUDi6IgB5OZdFxyWsT3usV6pcIgJQVAq0GUYBByn2ShS4=; 7:ZboK5ZHy/PHWatSX123wIlpwMzH9yVeYo33V9l5hg14GirLdhYAeCarPHbBcwDq95rjr2gEdfcDXWvNu5TcOwUzaEbHTMM6ZyKcDXL01LgLATBXcvycKBANnnf1EggPd0C/MgaQJ7Hyc1Eruw/Z7mkfyPHcTUaaHRm+d8iKKxt6zyV3Oi00T12KCXfM1k9R7fHse1wt2MRkzMBVHsPZJt84PeTm2fBFs0bFtwSdBMzJg58Xu4m/nkfn9xK1bOjge x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2723; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2723; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2723; x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(51914003)(377454003)(13464003)(24454002)(199003)(3280700002)(105586002)(86362001)(3846002)(102836003)(6116002)(122556002)(15650500001)(10090500001)(11100500001)(2900100001)(77096005)(68736007)(3660700001)(76576001)(189998001)(86612001)(19580395003)(19580405001)(87936001)(8936002)(99286002)(81166006)(586003)(93886004)(8676002)(33656002)(81156014)(50986999)(9686002)(106356001)(66066001)(5005710100001)(5002640100001)(4326007)(54356999)(10290500002)(76176999)(10400500002)(15975445007)(2950100001)(7696003)(101416001)(305945005)(97736004)(74316002)(7736002)(8990500004)(92566002)(230783001)(2906002)(7846002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2723; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 05:45:48.2615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2723 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 05:45:53 -0000 DQpJIGhhZCBiZWVuIGF0dGVtcHRpbmcgdG8gbGltaXQgY29tcGxleGl0eSBhbmQgZGUtZW1waGFz aXplIHRoZSB1c2Ugb2YgcG9ydCA1Njg0IGluIGZhdm9yIG9mIGJlaW5nIGNsZWFyIGFib3V0IHRo ZSByZXF1aXJlbWVudCB0byB1c2UgQUxQTiB3aGVyZSBhdmFpbGFibGU7IGhvd2V2ZXIsIGl0J3Mg b2J2aW91cyB0aGF0IEkgbmVlZCB0byBkb2N1bWVudCBhbGwgdGhlIHBvdGVudGlhbCBjbGllbnQg YW5kIHNlcnZlciBjb25maWd1cmF0aW9uL2NvbWJpbmF0aW9ucyBpbiBkZXRhaWwuIEknbGwgdGFr ZSBhbm90aGVyIHBhc3MgdG9tb3Jyb3cuICBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4NCg0KVGhl cmUgd2FzIGFsc28gYSBzdGF0ZW1lbnQgYXQgSUVURiA5NiB0aGF0IHRoZSB1c2Ugb2YgcG9ydCA1 Njg0IHdvdWxkIGJlICJzaW1pbGFyIHRvIHByaW9yIGtub3dsZWRnZSBpbiBIVFRQLzIiLiBJIHJl dmlld2VkIFJGQzc1NDAuIEFjdHVhbGx5LCBBTFBOIGlzIGFsd2F5cyByZXF1aXJlZCBmb3IgSFRU UC8yIG92ZXIgVExTOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzU0MCNzZWN0 aW9uLTMuNA0KLi4uIGltcGxlbWVudGF0aW9ucyB0aGF0IHN1cHBvcnQgSFRUUC8yIG92ZXIgVExT IE1VU1QgdXNlIHByb3RvY29sIG5lZ290aWF0aW9uIGluIFRMUyBbVExTLUFMUE5dLg0KDQpDb0FQ IG92ZXIgVExTIGlzIHNldHRpbmcgYSBwcmVjZWRlbnQgaW4gdGhpcyBjYXNlPw0KDQouLi5Ccmlh bg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RpYW4gR3JvdmVz IFttYWlsdG86Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb21dIA0KU2VudDogTW9uZGF5LCBB dWd1c3QgMTUsIDIwMTYgOToxOCBQTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3Jn PjsgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NCkNjOiBjb3JlQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFVwZGF0ZXMgdG8gY29hcC10Y3AtdGxzDQoNCiJJ ZiB0aGUgQXBwbGljYXRpb24tTGF5ZXIgUHJvdG9jb2wgTmVnb3RpYXRpb24gRXh0ZW5zaW9uIChB TFBOKSANCltSRkM3MzAxXSBpcyBhdmFpbGFibGUgaW4gYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2 ZXIgVExTIHByb3RvY29sIA0Kc3RhY2tzLi4uIiBzZWVtcyB0byBtZSB0byBpbXBseSB0aGVyZSdz IHNvbWUgcHJpb3Iga25vd2xlZGdlIG9mIHdoZXRoZXIgDQpBTFBOIGlzIHN1cHBvcnRlZCBpbiBi b3RoIHRoZSBjbGllbnQgYW5kIHNlcnZlci4gQSBDb0FQIGNsaWVudCAoVExTIA0KQ2xpZW50KSB3 aWxsIGtub3cgd2hldGhlciBpdCBzdXBwb3J0cyBBTFBOIGJ1dCBub3QgbmVjZXNzYXJpbHkgd2hh dCB0aGUgDQpUTFMgc2VydmVyIHN1cHBvcnRzLiBBIENsaWVudCB3aWxsIHNlbmQgYSBjbGllbnRI ZWxsbyB3aXRoIEFQTE4gIkNvQVAiIA0KYW5kIGlmIHRoZSBUTFMgc2VydmVyIGRvZXNuJ3Qgc3Vw cG9ydCB0aGUgIkNvQVAiIEFMUE4gdmFsdWUsIFJGQzczMDEgDQpzcGVjaWZpZXMgdGhhdCBpdCBz aG91bGQgcmVzcG9uZCB3aXRoIGEgZmF0YWwgYWxlcnQuIEluIHRoYXQgY2FzZSB0aGUgDQpmYWxs YmFjayB3b3VsZCBiZSB0byB1c2UgcG9ydCBudW1iZXIgNTY4NC4NCg0KUmVnYXJkcywgQ2hyaXN0 aWFuDQoNCg0KDQpPbiAxNi8wOC8yMDE2IDU6MTAgQU0sIENhcnN0ZW4gQm9ybWFubiB3cm90ZToN Cj4gQnJpYW4gUmF5bW9yIHdyb3RlOg0KPj4gSWYgdGhlIEFwcGxpY2F0aW9uLUxheWVyIFByb3Rv Y29sIE5lZ290aWF0aW9uIEV4dGVuc2lvbiAoQUxQTikgW1JGQzczMDFdIGlzIGF2YWlsYWJsZSBp biBib3RoIHRoZSBjbGllbnQgYW5kIHNlcnZlciBUTFMgcHJvdG9jb2wgc3RhY2tzLCBDb0FQIG92 ZXIgVExTIGltcGxlbWVudGF0aW9ucyBNVVNUIHBlcmZvcm0gcHJvdG9jb2wgbmVnb3RpYXRpb24g aW4gVExTIHVzaW5nIHRoZSAiY29hcCIgcHJvdG9jb2wgaWRlbnRpZmllciBkZWZpbmVkIGluIFNl Y3Rpb24gOC43LiBUaGUgc2VydmVyIE1BWSBhbHNvIG9mZmVyIENvQVAgb3ZlciBUTFMgb25seSBv biBwb3J0IG51bWJlciA1Njg0IGZvciBleGNlcHRpb25hbCBjYXNlcyB3aGVyZSBBTFBOIGlzIHVu YXZhaWxhYmxlIG9uIHRoZSBjbGllbnQgb3IgdGhlIHNlcnZlci4NCj4gVGhhdCB3b3JrcyBmb3Ig bWUuICBXaXRoIHRoZXNlIGludGVyb3BlcmFiaWxpdHkgbWFuZGF0ZXMsIEknbSBnZW5lcmFsbHkN Cj4gaW4gZmF2b3Igb2YgYmVpbmcgdmVyeSBzcGVjaWZpYyBhYm91dCB3aGF0IGFuIGltcGxlbWVu dGF0aW9uIGlzIHN1cHBvc2VkDQo+IHRvIGRvIG9yIG5vdCBzdXBwb3NlZCB0byBkby4gIExldCBt ZSB0cnkgdG8gc3VtbWFyaXplOg0KPg0KPiAtLSBBIFRMUyBzZXJ2ZXIgTUFZIG9mZmVyIGEgY29h cHMrdGNwIGVuZHBvaW50IG9uIFRDUCBwb3J0IDU4NjQgaWYgaXQNCj4gZG9lc24ndCBzdXBwb3J0 IEFMUE4gYW5kL29yIHRvIGFjY29tbW9kYXRlIFRMUyBjbGllbnRzIHRoYXQgZG9uJ3QuICBBDQo+ IFRMUyBzZXJ2ZXIgTUFZIG9mZmVyIGNvYXBzK3RjcCBlbmRwb2ludHMgb24gVENQIHBvcnRzIGRp ZmZlcmVudCBmcm9tDQo+IDU2ODQgaWYgaXQgZG9lcyBzdXBwb3J0IEFMUE4uDQo+IC0tIE9uIFRD UCBwb3J0cyBkaWZmZXJlbnQgZnJvbSA1Njg0LCBhIGNvYXBzK3RjcCBUTFMgY2xpZW50IE1VU1Qg b2ZmZXINCj4gQUxQTiB2YWx1ZSAnY29hcCcsIGFuZCB0aGUgY29hcHMrdGNwIFRMUyBzZXJ2ZXIg b25seSBiZWNvbWVzIGFjdGl2ZSBpZg0KPiB0aGUgVExTIHNlcnZlciBzZWxlY3RzIHRoZSBBTFBO IHZhbHVlICdjb2FwJy4gIChJZiBhIGRpZmZlcmVudCBBTFBODQo+IHZhbHVlIGlzIG5lZ290aWF0 ZWQsIG9yIGlmIHRoZSBBTFBOIG5lZ290aWF0aW9uIGZhaWxzIGFuZCB0aHVzIGNhdXNlcyBhDQo+ IGZhdGFsIGFsZXJ0LCB0aGUgcHJlc2VudCBzcGVjaWZpY2F0aW9uIGRvZXMgYmVjb21lIGFjdGl2 ZS4pDQo+IC0tIE9uIFRDUCBwb3J0IDU2ODQsIGEgVExTIGNsaWVudCBNQVkgb2ZmZXIgQUxQTiB2 YWx1ZSAnY29hcCcgYW5kIGENCj4gY29hcHMrdGNwIFRMUyBzZXJ2ZXIgTUFZIHRoZW4gc2VsZWN0 IEFMUE4gdmFsdWUgJ2NvYXAnLiAgKElmIGEgZGlmZmVyZW50DQo+IEFMUE4gdmFsdWUgaXMgbmVn b3RpYXRlZCwgb3IgaWYgdGhlIEFMUE4gbmVnb3RpYXRpb24gZmFpbHMgYW5kIHRodXMNCj4gY2F1 c2VzIGEgZmF0YWwgYWxlcnQsIHRoZSBwcmVzZW50IHNwZWNpZmljYXRpb24gZG9lcyBub3QgYmVj b21lIGFjdGl2ZS4NCj4gKiopICBJZiB0aGUgY2xpZW50IGRvZXMgbm90IHNlbmQgQUxQTiBhdCBh bGwsIGNvYXBzK3RjcCBpcyBhc3N1bWVkIHRvIGJlDQo+IHNlbGVjdGVkIG9uIHBvcnQgNTY4NCBv bmx5LiAgSWYgdGhlIGNsaWVudCBkb2VzIHNlbmQgQUxQTiwgYW5kIHRoZQ0KPiBzZXJ2ZXIgZG9l cyBub3Qgc3VwcG9ydCBBTFBOLCB0aGUgbmVnb3RpYXRpb24gd2lsbCByZXN1bHQgaW4gbm8gQUxQ Tg0KPiB2YWx1ZSBiZWluZyBleHBsaWNpdGx5IHNlbGVjdGVkIFtjaGVjayB0aGlzXSwgYW5kLCBh Z2FpbiwgY29hcHMrdGNwIGlzDQo+IGFzc3VtZWQgdG8gYmUgc2VsZWN0ZWQgb24gcG9ydCA1Njg0 IG9ubHkuDQo+ICoqKSBJZiBhIGRpZmZlcmVudCBBTFBOIGlzIHNlbGVjdGVkIG9uIHBvcnQgNTg2 NCwgW2RlZmluZSBiZWhhdmlvciBoZXJlXS4NCj4NCj4gUGhldy4gIEFyZSB0aGVzZSBhbGwgdGhl IGNhc2VzIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQ/DQo+DQo+IFNob3VsZCBpdCBiZSBhbGxvd2Vk IHRvIG5lZ290aWF0aW9uIEFMUE4g4omgICdjb2FwJyBvbiBwb3J0IDU2ODQ/DQo+IChQcm9iYWJs eSB5ZXMsIHRvIGVuYWJsZSB0aGUgbmVnb3RpYXRpb24gb2YgYSAnY29hcDInIGV0Yy47IHdlIGNh bid0DQo+IHJlYWxseSByZXN0cmljdCB3aGF0IGNhbiBiZSBuZWdvdGlhdGVkIGhlcmUgd2l0aG91 dCBwcmVkaWN0aW5nIHRoZQ0KPiBmdXR1cmUuICBPciB3ZSBjb3VsZCBjb21wbGV0ZWx5IGRpc2Fs bG93IHRoZSB1c2Ugb2YgQUxQTiBvbiBwb3J0IDU2ODQuKQ0KPg0KPiBHcsO8w59lLCBDYXJzdGVu DQo+DQoNCg== From nobody Tue Aug 16 00:36:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B1912D094 for ; Tue, 16 Aug 2016 00:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX3_9wtYODgL for ; Tue, 16 Aug 2016 00:35:59 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B932C12D0F4 for ; Tue, 16 Aug 2016 00:35:57 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id Xjbv1t0014h15BW01jbvLl; Tue, 16 Aug 2016 09:35:56 +0200 Received: from 2001:983:a264:1:9995:c7ab:57b:48a6 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 16 Aug 2016 09:35:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 16 Aug 2016 09:35:55 +0200 From: peter van der Stok To: Hannes Tschofenig Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> Message-ID: <9cf6e5c673abbbbe60e0d6771656f3cc@xs4all.nl> X-Sender: stokcons@xs4all.nl (2iBxwy0gJBKziU5tA2FXmUm183s5y2lI) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 07:36:01 -0000 Hi Hannes, Carsten, I will provide a phrase in the RD draft that the use of the path "/rd" in all examples is the convention used for the RD path in this draft. Concerning the template I propose: rd := RD Function Set path (mandatory). This is the path of the RD Function Set, as obtained from discovery. The value "rd" is used as an example value throughout this document and as a side: Replace RD Function Set path by: RD container path? Greetings, Peter Hannes Tschofenig schreef op 2016-08-11 08:31: > Hi Peter, > > I only want to have clarify what use of /rd is there in the examples > because of the recommendation and what has been chosen for convenience. > > Ciao > Hannes > > > On 08/10/2016 05:40 PM, peter van der Stok wrote: >> Hi Carsten, >> >> Thanks for the suggestions, but the changes do not look that essential >> for the iteroperability and implementation to me. >> I would prefer to get the draft out as is. >> Hannes thinks differently? >> >> Peter >> >> Carsten Bormann schreef op 2016-08-10 13:39: >>> peter van der Stok wrote: >>>> Hi Carsten, >>>> >>>> Do I understand correctly that you recommend to keep the current >>>> template wording? >>>> >>>> URI Template: /{+rd}{?ep,d,et,lt,con} >>>> >>>> URI Template Variables: >>>> >>>> rd := RD Function Set path (mandatory). This is the path of >>>> the >>>> RD Function Set, as obtained from discovery. An RD SHOULD >>>> use >>>> the value "rd" for this variable whenever possible. >>> >>> Maybe a better wording of the last sentence would be: >>> >>> As a convention that aids in debugging, a server can use the value >>> "rd" >>> unless it prefers a different value. >>> >>> Gets rid of the SHOULD, and makes it clear the the server is free to >>> choose (as per RFC 7320). >>> >>> (And maybe we can get rid of "Function Set" in a separate effort.) >>> >>> Grüße, Carsten From nobody Tue Aug 16 08:26:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E397112D873 for ; Tue, 16 Aug 2016 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2bB6DwdHqc7 for ; Tue, 16 Aug 2016 07:35:49 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 E2F0B12D872 for ; Tue, 16 Aug 2016 07:35:49 -0700 (PDT) Received: from localhost ([::1]:45489 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZfT1-0005Nn-Ga; Tue, 16 Aug 2016 07:35:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: consultancy@vanderstok.org X-Trac-Project: core Date: Tue, 16 Aug 2016 14:35:47 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/398#comment:1 Message-ID: <081.a68b4155a3957ddea8661ba75414b6db@trac.tools.ietf.org> References: <066.78a2d4a690a4650c0e11c6cfcb53c260@trac.tools.ietf.org> X-Trac-Ticket-ID: 398 In-Reply-To: <066.78a2d4a690a4650c0e11c6cfcb53c260@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Tue, 16 Aug 2016 08:26:51 -0700 Cc: core@ietf.org Subject: Re: [core] #398 (resource-directory): lighting example X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:35:51 -0000 #398: lighting example Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- ----------------------------------------+--------------------------------- Reporter: consultancy@vanderstok.org | Owner: peter van der Stok Type: editorial | Status: closed Priority: major | Milestone: Component: resource-directory | Version: Severity: Active WG Document | Resolution: fixed Keywords: lighting example | ----------------------------------------+--------------------------------- Ticket URL: core From nobody Tue Aug 16 08:26:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD86C12D876 for ; Tue, 16 Aug 2016 07:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUpFMpi28-Kf for ; Tue, 16 Aug 2016 07:36:20 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 C307C12D872 for ; Tue, 16 Aug 2016 07:36:20 -0700 (PDT) Received: from localhost ([::1]:45510 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZfTY-0007EF-NY; Tue, 16 Aug 2016 07:36:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: consultancy@vanderstok.org X-Trac-Project: core Date: Tue, 16 Aug 2016 14:36:20 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/399#comment:1 Message-ID: <081.32c7045bf70327ee7618278f33d2f972@trac.tools.ietf.org> References: <066.238820fc3c09fb38b50d80e817f7008d@trac.tools.ietf.org> X-Trac-Ticket-ID: 399 In-Reply-To: <066.238820fc3c09fb38b50d80e817f7008d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Tue, 16 Aug 2016 08:26:51 -0700 Cc: core@ietf.org Subject: Re: [core] #399 (resource-directory): message exchange figures X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:36:22 -0000 #399: message exchange figures Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- ----------------------------------------+--------------------------------- Reporter: consultancy@vanderstok.org | Owner: peter van der Stok Type: editorial | Status: closed Priority: major | Milestone: Component: resource-directory | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------------+--------------------------------- Ticket URL: core From nobody Tue Aug 16 08:27:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8D312D87C for ; Tue, 16 Aug 2016 07:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_OtD7xR6ezl for ; Tue, 16 Aug 2016 07:41:15 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 EBE9712D879 for ; Tue, 16 Aug 2016 07:41:15 -0700 (PDT) Received: from localhost ([::1]:45613 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZfYJ-00032F-OM; Tue, 16 Aug 2016 07:41:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Tue, 16 Aug 2016 14:41:15 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/372#comment:1 Message-ID: <073.d25baac5886c4372134979e20b18b965@trac.tools.ietf.org> References: <058.c36cf92e6c0a96dd8bcdea87acb0439c@trac.tools.ietf.org> X-Trac-Ticket-ID: 372 In-Reply-To: <058.c36cf92e6c0a96dd8bcdea87acb0439c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160816144115.EBE9712D879@ietfa.amsl.com> Resent-Date: Tue, 16 Aug 2016 07:41:15 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 16 Aug 2016 08:26:51 -0700 Cc: core@ietf.org Subject: Re: [core] #372 (resource-directory): Examples section with use cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:41:17 -0000 #372: Examples section with use cases Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- zach@sensinode.com | directory@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: resource- | Version: directory | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Aug 16 08:27:04 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1980412D84E for ; Tue, 16 Aug 2016 07:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-oKrsQO234L for ; Tue, 16 Aug 2016 07:42:36 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 ED1DE12D624 for ; Tue, 16 Aug 2016 07:42:36 -0700 (PDT) Received: from localhost ([::1]:45642 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZfZc-0003Ow-Rk; Tue, 16 Aug 2016 07:42:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Tue, 16 Aug 2016 14:42:36 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/413#comment:1 Message-ID: <075.095d84ab3b34cce37bbf57bbde51c37c@trac.tools.ietf.org> References: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> X-Trac-Ticket-ID: 413 In-Reply-To: <060.09fa07e8717ced2efb537fdfead3330c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160816144236.ED1DE12D624@ietfa.amsl.com> Resent-Date: Tue, 16 Aug 2016 07:42:36 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 16 Aug 2016 08:26:51 -0700 Cc: core@ietf.org Subject: Re: [core] #413 (resource-directory): Make Simple Directory Discovery really simple X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:42:39 -0000 #413: Make Simple Directory Discovery really simple Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: Fixed in version -08 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- kovatsch@inf.ethz.ch | directory@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: minor | Version: Component: resource- | Resolution: fixed directory | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Aug 16 08:27:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC7912D859 for ; Tue, 16 Aug 2016 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cef3_4Xuiz93 for ; Tue, 16 Aug 2016 07:43:47 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 3BAC012D879 for ; Tue, 16 Aug 2016 07:43:47 -0700 (PDT) Received: from localhost ([::1]:45663 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZfal-0003YI-3d; Tue, 16 Aug 2016 07:43:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Tue, 16 Aug 2016 14:43:47 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/412#comment:1 Message-ID: <075.9fcda971680a61c0d1a27cedf99d229e@trac.tools.ietf.org> References: <060.f687c9fcf5a1ac9cfb2d58eac188980d@trac.tools.ietf.org> X-Trac-Ticket-ID: 412 In-Reply-To: <060.f687c9fcf5a1ac9cfb2d58eac188980d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160816144347.3BAC012D879@ietfa.amsl.com> Resent-Date: Tue, 16 Aug 2016 07:43:47 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 16 Aug 2016 08:26:51 -0700 Cc: core@ietf.org Subject: Re: [core] #412 (resource-directory): Simple Directory Discovery text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:43:48 -0000 #412: Simple Directory Discovery text Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: fixed in version -08 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- kovatsch@inf.ethz.ch | directory@tools.ietf.org Type: editorial | Status: closed Priority: major | Milestone: Component: resource- | Version: directory | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Aug 16 11:39:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F68912D14A for ; Tue, 16 Aug 2016 11:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7QY_0D3EbVZ for ; Tue, 16 Aug 2016 11:39:18 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 5773512D134 for ; Tue, 16 Aug 2016 11:39:18 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 74so136344265uau.0 for ; Tue, 16 Aug 2016 11:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PPKSBfJbJhwG7gm022khq34yD/36hzhnnCIAIirbxgw=; b=nmZUzZYnZc9aT+KQKQhwzHju9O9tlB6zgXM1ikc9ymv1X1cDkAEHvpW2URGWwcS/2+ x1pnvNF3Qjyqy/yFK+CEkKSfxuDEqTDiE1k/1ZeihTDSUUcYVVwEm+LNaEorb7eKyvoJ t3emFPV4Q6cpdBDCbhkgjAy2+uwLk2TF99xY1DTtNUXD0oZeDdFyh/S/3L7I8p12L9fE 1My2B43NEVwYj4D44iR86KxJ6Flst9JmKF87UmQOiSTkNGutLn46PH7VQ8E/RnzfaKcq QsHSd54K6sZXgLgVaDSLro39l5GXro053QB4yKSRisMlxAG+BVd2/acPA0HyfwWTJBje XAgw== 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:from:date :message-id:subject:to; bh=PPKSBfJbJhwG7gm022khq34yD/36hzhnnCIAIirbxgw=; b=kA9w40lg0s0ip87ZWHUQeC3w0HTMqRAu/sq+AQ3u8G2EiaFu5J4g852ZBLZIAgXSYZ T0mG9yAQe7oAq+i4SqxpdzvZgXAdvnvNU3jH0DBQdcb5oMg23k086yp8jdaWR++4+2+7 z0dd2vvCvqJb0uS08rZgMi7KFEEV6jU5SdTcj2aQptylXELplcvlDVjeSTlvMIRorTQ4 DigGsTkvySoDJsMB4ZIg92hJ17Rao25VC2hBgvHr/9xnT3TpfNyz/OYI0am0B/SuYNxl UhLbHHx3OCRPP7I1DH8++xvCHjM7TOdjWJFZ+GZnD9Lf9BMF+MbSW5rWueavrcTt4BqZ Y+9Q== X-Gm-Message-State: AEkoous73cAN+oD3tin+tDd/Hoy+Ilar2SRJHNKHoJgyBqPrjTW2N79+mS1KYnAq0tSniUBPbwj5G9BUwigbew== X-Received: by 10.176.82.219 with SMTP id w27mr17911618uaw.121.1471372757161; Tue, 16 Aug 2016 11:39:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Tue, 16 Aug 2016 11:39:16 -0700 (PDT) In-Reply-To: <147137218567.23002.16239675741482547105.idtracker@ietfa.amsl.com> References: <147137218567.23002.16239675741482547105.idtracker@ietfa.amsl.com> From: Andy Bierman Date: Tue, 16 Aug 2016 11:39:16 -0700 Message-ID: To: Core Content-Type: multipart/alternative; boundary=94eb2c1915ee85f2c7053a34aa0f Archived-At: Subject: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 18:39:20 -0000 --94eb2c1915ee85f2c7053a34aa0f Content-Type: text/plain; charset=UTF-8 FYI, Peter and I have written a new draft called "Numeric YANG Identifiers" which replaces the "YANG Hash" draft. This draft combines hash-based and manual numbering and defines a simple registry-based process for management of module and object identifiers. The need for a rehash procedure and rehash errors has been removed. YANG Hash is now scoped by the module identifier so there are no inter-module interactions. Hash collisions within a module are not allowed. Manual assignments for colliding nodes are used to avoid the rare occurrence of a hash collision within the same module. Andy ---------- Forwarded message ---------- From: Date: Tue, Aug 16, 2016 at 11:29 AM Subject: New Version Notification for draft-bierman-core-yid-00.txt To: Peter van der Stok , Andy Bierman < andy@yumaworks.com> A new version of I-D, draft-bierman-core-yid-00.txt has been successfully submitted by Andy Bierman and posted to the IETF repository. Name: draft-bierman-core-yid Revision: 00 Title: Numeric YANG Identifiers Document date: 2016-08-16 Group: Individual Submission Pages: 33 URL: https://www.ietf.org/internet-drafts/draft-bierman-core-yid- 00.txt Status: https://datatracker.ietf.org/doc/draft-bierman-core-yid/ Htmlized: https://tools.ietf.org/html/draft-bierman-core-yid-00 Abstract: This document describes an encoding of YANG object identifiers using numeric values instead of string values. It combines several techniques to provide optimized serialization in protocol messages. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. 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 --94eb2c1915ee85f2c7053a34aa0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI,


Peter and I have wr= itten a new draft called "Numeric YANG Identifiers"
whi= ch replaces the "YANG Hash" draft.=C2=A0

This draft combines hash-based and manual numbering and defines
= a simple registry-based process for management of module and object identif= iers.

The need for a rehash procedure and rehash e= rrors has been removed.
YANG Hash is now scoped by the module ide= ntifier so there are no inter-module
interactions.=C2=A0 Hash col= lisions within a module are not allowed.
Manual assignments for c= olliding nodes are used to avoid the rare occurrence
of a hash co= llision within the same module.


Andy


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Aug 16, 2016= at 11:29 AM
Subject: New Version Notification for draft-bierman-core-yi= d-00.txt
To: Peter van der Stok <consultancy@vanderstok.org>, Andy Bierman <andy@yumaworks.com>



A new version of I-D, draft-bierman-core-yid-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bierman-core-yid
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Numeric YANG Identifiers
Document date:=C2=A0 2016-08-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bierman-core-yi= d-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/draft-bierman-core-yid/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-bierman-core-yid-00


Abstract:
=C2=A0 =C2=A0This document describes an encoding of YANG object identifiers= using
=C2=A0 =C2=A0numeric values instead of string values.=C2=A0 It combines sev= eral
=C2=A0 =C2=A0techniques to provide optimized serialization in protocol mess= ages.

Note

=C2=A0 =C2=A0Discussion and suggestions for improvement are requested, and = should
=C2=A0 =C2=A0be sent to core@ietf.org.=




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c1915ee85f2c7053a34aa0f-- From nobody Tue Aug 16 16:41:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B973B12D56F for ; Tue, 16 Aug 2016 16:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxfEKfdWLYq9 for ; Tue, 16 Aug 2016 16:41:52 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A2212D179 for ; Tue, 16 Aug 2016 16:41:51 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id ti13so30699626pac.0 for ; Tue, 16 Aug 2016 16:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0QpNdRKOc/LVVJnjdKoblyMvpi+nFXjDeKklh+sLFgk=; b=U83Ofi8H2JwJpxbUiwCw0zD9ODoVSdUfucr5TWuQ+NFsG0pkVpe5ZPUbYwJSPUpfqE pUSkeYH/NB1Xq9U4hvKImIp4DMkNS8foo6gQozwVr4nB/f9gAA3mvlikazwEMedQabcC D2iJ99np7lgfHmwWY6SxPtBonrlODN8HHMBrGrtDL7/QaCLTAkXNo9we7v44Jz6T23pV 1Z+NOvP+e0xa9vvWZqlU7SP/Bl2GDzAniOoZySJpHirtC6aBVKnDBJU8LPcyl4yOdetj my9vU6+He2zCb3klhY8gYmrICpIFJwfY9BYHw1b5zko706i71XeY1fbUNmnDa21pcIHs rrJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0QpNdRKOc/LVVJnjdKoblyMvpi+nFXjDeKklh+sLFgk=; b=hOnm41+xmMhMbn1Az2mU0dVoSP27CK89t8LY5AEP5HRwy0Ta84aUpuC/9G5VM4mWl9 jkoi3sf+P9PVMreGw6nyyUYX6eFYLPfptB8SPputOkXccrrGGaWpWD5VJhtSLPpeCxo5 utPp0RW84qvXUZwGf2EvBM7MCh2GZeYPMfoGHdjftLuze9PSmlCEMpLkWmCPERccAIFF 9q0lp/Ns9Y1vhURJguuSwYzEFkKL1FOwNhbn4R0qtkf9xWDB+DpOQCU7fKE8IVSzLr3g LprHK7/vcnvcvcwkKXxA3eZjIbnBubVy469cpMofp9Ts0BxIHh7CbKRaYMhK2tU6cmcv J35g== X-Gm-Message-State: AEkoousYQmTeeLjMLXWxUX9HlnO36ahuoc55vj2I06L9EEkG7LKeN0nbHpjdaSyrnki48A== X-Received: by 10.66.49.137 with SMTP id u9mr70149257pan.72.1471390911341; Tue, 16 Aug 2016 16:41:51 -0700 (PDT) Received: from [10.0.0.20] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id g27sm41905694pfd.47.2016.08.16.16.41.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 16:41:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <9cf6e5c673abbbbe60e0d6771656f3cc@xs4all.nl> Date: Tue, 16 Aug 2016 16:41:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <630F13BF-E488-4334-9EAB-50AF3C2E539F@gmail.com> References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> <9cf6e5c673abbbbe60e0d6771656f3cc@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:41:54 -0000 Hi, We define three "function sets" in RD. They are Registration = (rt=3Dcore.rd), Lookup (rt=3Dcore.rd-lookup) and Group = (rt=3Dcore.rd-group). Each of these has an API entry URI that we suggest = conventional usage of /rd, /rd-lookup, and /rd-group Whatever we do to improve the terminology from "function set" to "REST = API entry point" or whatever we choose, it needs to be done consistently = in the document for all 3 cases. I don't think "container path" is necessarily a better choice.=20 Hannes, Carsten, anyone, do you have a suggestion for what we should = call these different API entry points?=20 Best regards, Michael > On Aug 16, 2016, at 12:35 AM, peter van der Stok = wrote: >=20 > Hi Hannes, Carsten, >=20 > I will provide a phrase in the RD draft that the use of the path "/rd" = in all examples is the convention used for the RD path in this draft. >=20 > Concerning the template I propose: >=20 > rd :=3D RD Function Set path (mandatory). This is the path of the > RD Function Set, as obtained from discovery. The value "rd" is = used as an example value throughout this document >=20 > and as a side: > Replace RD Function Set path by: RD container path? >=20 > Greetings, >=20 > Peter >=20 >=20 > Hannes Tschofenig schreef op 2016-08-11 08:31: >> Hi Peter, >> I only want to have clarify what use of /rd is there in the examples >> because of the recommendation and what has been chosen for = convenience. >> Ciao >> Hannes >> On 08/10/2016 05:40 PM, peter van der Stok wrote: >>> Hi Carsten, >>> Thanks for the suggestions, but the changes do not look that = essential >>> for the iteroperability and implementation to me. >>> I would prefer to get the draft out as is. >>> Hannes thinks differently? >>> Peter >>> Carsten Bormann schreef op 2016-08-10 13:39: >>>> peter van der Stok wrote: >>>>> Hi Carsten, >>>>> Do I understand correctly that you recommend to keep the current >>>>> template wording? >>>>> URI Template: /{+rd}{?ep,d,et,lt,con} >>>>> URI Template Variables: >>>>> rd :=3D RD Function Set path (mandatory). This is the path = of the >>>>> RD Function Set, as obtained from discovery. An RD SHOULD = use >>>>> the value "rd" for this variable whenever possible. >>>> Maybe a better wording of the last sentence would be: >>>> As a convention that aids in debugging, a server can use the value = "rd" >>>> unless it prefers a different value. >>>> Gets rid of the SHOULD, and makes it clear the the server is free = to >>>> choose (as per RFC 7320). >>>> (And maybe we can get rid of "Function Set" in a separate effort.) >>>> Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Aug 16 16:57:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04B412D111 for ; Tue, 16 Aug 2016 16:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf9yu7kQgPfM for ; Tue, 16 Aug 2016 16:57:11 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0125.outbound.protection.outlook.com [104.47.40.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F80128E19 for ; Tue, 16 Aug 2016 16:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JbCrzYZZ/nQqZzu4sXkkRkK/PQxgomHgjuCvt2dd764=; b=R6+SjoC7hwO6lopilmXHZJy5YMlSMbCH/0SQfKYAiuaAP4EdXyHjGBJRd/hWuWMsobIAVAziTRHxuNduWh2TZD0V6pbRwPUXZE6ClGQ0sZENEDvLtg0RCw/R+Cz7jGd32hWEW1G5h1GkiPAua1G/5v7RvzBrbXkLnFB902qHIxU= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2722.namprd03.prod.outlook.com (10.173.144.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 16 Aug 2016 23:57:08 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0557.022; Tue, 16 Aug 2016 23:57:08 +0000 From: Brian Raymor To: Christian Groves , Carsten Bormann Thread-Topic: [core] Updates to coap-tcp-tls Thread-Index: AdHzatCWVXEOdWrbQLiOhi+qiefTngALuagAABwOKmAAEYS0gAAYxiggAAxbvQAAAuvYoACOHFeAABMkZYAAKQhcQA== Date: Tue, 16 Aug 2016 23:57:08 +0000 Message-ID: References: <431663ac-271a-5250-7118-58a51aea067d@gmx.net> <254432a9-9048-6809-1bdf-dce3bb17cb12@nteczone.com> <57AE4652.7020306@tzi.org> <57B2139D.4030202@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 3e29aaa8-5795-4e8d-47b0-08d3c631086f x-microsoft-exchange-diagnostics: 1; BN6PR03MB2722; 6:9q6yh3xg43Q3deW3mTOY6Omyba8s9AtgqlyQ/HMvSqQ4QIlPosx0UB2bMqweDxH8hCPIj5g62q/3mLHPeK80VyprryrTdPfdkNYFDtlV+ZYfb+/4kg2wvZMaS/C/g8WJB5wsLk6KN47AyLqxlsxGXTkMOw+M4VpIlCFNxEVhQn8cgyA2lkvJpprc1qMI7OZHzXOHpCC7lpk1F6dsc5a65r+c0R37VvjYACr8ArtzHa6IZDPcM1uQKuJ2oNrpiGfzE+FpkdTrW+CnyLcGGVTgn/FmOQTv/3MbhvdM/qCdqYlL2Yu6ahltaOiam9ovoiLOi9uj6FCHxRLjcgNXpVUe+g==; 5:v7vj72ydCL3G83EUh2mrNQaBDdNq/DM7MRnc+CXM8OUR+hkcq/9PRyMZHvm9RB8a9MmgwvjiJnXH2IYQ7SSXSM6WRGp18A10R04o9WgqemNjDySZtX5M90nY13PwBCmVU1qJCp/pouzwC6Vj/MGjBQ==; 24:OU/9sPWNQn/V0jkFsj/9tUNkye5X0mDev0UVfuIIU/ODTANk+pchjyLjKDntoIlg+JTxRuAHtPWIIW/YrVnetJY5GCNPuHKyTUklZaRwzF0=; 7:dpN167Xpuiaxv6TEktU6ykD1MbodIGzPk2XWxfAXkw8yY/B1mewUmFESYzveqo0ZD+nvvxmvtZDbizbL49t5x1BcY11SivZgwp2bvdGHZsTmMWOyiDTsiAIhU4wCFqVlKNaAN2vZdloGC9inS90VGVw+boN9aUGHaqCvnQY4kCQpuofYRWtDNrzaY2R6QJST9EEeeyrFMtFvkylWNTimW3yJ0U+dq1SjJRpd4KQIDSBu2kyqk1+dDEDvHTlh/V2b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2722; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2722; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2722; x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(377454003)(24454002)(189002)(101416001)(8990500004)(50986999)(2906002)(81166006)(7736002)(19580405001)(81156014)(19580395003)(4326007)(8676002)(2900100001)(76176999)(54356999)(86612001)(7846002)(9686002)(7696003)(102836003)(8936002)(305945005)(6116002)(561944003)(33656002)(3846002)(586003)(15650500001)(74316002)(97736004)(5001770100001)(76576001)(11100500001)(106356001)(10090500001)(5002640100001)(92566002)(77096005)(3280700002)(230783001)(66066001)(99286002)(93886004)(2950100001)(68736007)(5005710100001)(86362001)(189998001)(10290500002)(87936001)(3660700001)(10400500002)(105586002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2722; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 23:57:08.2676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2722 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Updates to coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:57:14 -0000 SGVyZSBpcyBhbiB1cGRhdGVkIGRyYWZ0IHByb3Bvc2FsIGJhc2VkIG9uIHRoZSBmZWVkYmFjay4g DQoNCg0KSWYgYSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBBTFBOIG9yIHdpc2hlcyB0byBhY2Nv bW1vZGF0ZSBjbGllbnRzIHRoYXQgZG8gbm90IHN1cHBvcnQgQUxQTiwgaXQgTUFZIG9mZmVyIGEg Y29hcHMrdGNwIGVuZHBvaW50IG9uIFRDUCBwb3J0IDU2ODQuICBUaGlzIGVuZHBvaW50IE1BWSBh bHNvIGJlIEFMUE4gZW5hYmxlZC4gQSBzZXJ2ZXIgTUFZIG9mZmVyIGNvYXBzK3RjcCBlbmRwb2lu dHMgb24gcG9ydHMgb3RoZXIgdGhhbiBUQ1AgcG9ydCA1Njg0LCB3aGljaCBNVVNUIGJlIEFMUE4g ZW5hYmxlZC4NCg0KRm9yIFRDUCBwb3J0cyBvdGhlciB0aGFuIHBvcnQgNTY4NCwgdGhlIGNsaWVu dCBNVVNUIHVzZSB0aGUgQUxQTiBleHRlbnNpb24gdG8gYWR2ZXJ0aXNlIHRoZSAiY29hcCIgcHJv dG9jb2wgaWRlbnRpZmllciAoZGVmaW5lZCBpbiBTZWN0aW9uIDguNykgaW4gdGhlIGxpc3Qgb2Yg cHJvdG9jb2xzIGluIGl0cyBDbGllbnRIZWxsby4gSWYgdGhlIHNlcnZlciBzZWxlY3RzIGFuZCBy ZXR1cm5zIHRoZSAiY29hcCIgcHJvdG9jb2wgaWRlbnRpZmllciB1c2luZyB0aGUgQUxQTiBleHRl bnNpb24gaW4gaXRzIFNlcnZlckhlbGxvLCB0aGVuIHRoZSBjb25uZWN0aW9uIHN1Y2NlZWRzLiBJ ZiB0aGUgc2VydmVyIGVpdGhlciBkb2VzIG5vdCBuZWdvdGlhdGUgdGhlIEFMUE4gZXh0ZW5zaW9u IG9yIHJldHVybnMgYSBub19hcHBsaWNhdGlvbl9wcm90b2NvbCBhbGVydCwgdGhlIGNsaWVudCBN VVNUIGNsb3NlIHRoZSBjb25uZWN0aW9uLg0KDQpGb3IgVENQIHBvcnQgNTY4NCwgYSBjbGllbnQg TUFZIHVzZSB0aGUgQUxQTiBleHRlbnNpb24gdG8gYWR2ZXJ0aXNlIHRoZSAiY29hcCIgcHJvdG9j b2wgaWRlbnRpZmllciBpbiB0aGUgbGlzdCBvZiBwcm90b2NvbHMgaW4gaXRzIENsaWVudEhlbGxv LiBJZiB0aGUgc2VydmVyIHNlbGVjdHMgYW5kIHJldHVybnMgdGhlICJjb2FwIiBwcm90b2NvbCBp ZGVudGlmaWVyIHVzaW5nIHRoZSBBTFBOIGV4dGVuc2lvbiBpbiBpdHMgU2VydmVySGVsbG8sIHRo ZW4gdGhlIGNvbm5lY3Rpb24gc3VjY2VlZHMuIGlmIHRoZSBzZXJ2ZXIgcmV0dXJucyBhIG5vX2Fw cGxpY2F0aW9uX3Byb3RvY29sIGFsZXJ0LCB0aGVuIHRoZSBjbGllbnQgTVVTVCBjbG9zZSB0aGUg Y29ubmVjdGlvbi4gSWYgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWdvdGlhdGUgdGhlIEFMUE4gZXh0 ZW5zaW9uLCB0aGVuIGNvYXBzK3RjcCBpcyBpbXBsaWNpdGx5IHNlbGVjdGVkLg0KDQpGb3IgVENQ IHBvcnQgNTY4NCwgaWYgdGhlIGNsaWVudCBkb2VzIG5vdCB1c2UgdGhlIEFMUE4gZXh0ZW5zaW9u IHRvIG5lZ290aWF0ZSB0aGUgcHJvdG9jb2wsIHRoZW4gY29hcHMrdGNwIGlzIGltcGxpY2l0bHkg c2VsZWN0ZWQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RpYW4g R3JvdmVzIFttYWlsdG86Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb21dIA0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMTUsIDIwMTYgOToxOCBQTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0 emkub3JnPjsgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NCkNjOiBj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFVwZGF0ZXMgdG8gY29hcC10Y3AtdGxz DQoNCiJJZiB0aGUgQXBwbGljYXRpb24tTGF5ZXIgUHJvdG9jb2wgTmVnb3RpYXRpb24gRXh0ZW5z aW9uIChBTFBOKSANCltSRkM3MzAxXSBpcyBhdmFpbGFibGUgaW4gYm90aCB0aGUgY2xpZW50IGFu ZCBzZXJ2ZXIgVExTIHByb3RvY29sIA0Kc3RhY2tzLi4uIiBzZWVtcyB0byBtZSB0byBpbXBseSB0 aGVyZSdzIHNvbWUgcHJpb3Iga25vd2xlZGdlIG9mIHdoZXRoZXIgDQpBTFBOIGlzIHN1cHBvcnRl ZCBpbiBib3RoIHRoZSBjbGllbnQgYW5kIHNlcnZlci4gQSBDb0FQIGNsaWVudCAoVExTIA0KQ2xp ZW50KSB3aWxsIGtub3cgd2hldGhlciBpdCBzdXBwb3J0cyBBTFBOIGJ1dCBub3QgbmVjZXNzYXJp bHkgd2hhdCB0aGUgDQpUTFMgc2VydmVyIHN1cHBvcnRzLiBBIENsaWVudCB3aWxsIHNlbmQgYSBj bGllbnRIZWxsbyB3aXRoIEFQTE4gIkNvQVAiIA0KYW5kIGlmIHRoZSBUTFMgc2VydmVyIGRvZXNu J3Qgc3VwcG9ydCB0aGUgIkNvQVAiIEFMUE4gdmFsdWUsIFJGQzczMDEgDQpzcGVjaWZpZXMgdGhh dCBpdCBzaG91bGQgcmVzcG9uZCB3aXRoIGEgZmF0YWwgYWxlcnQuIEluIHRoYXQgY2FzZSB0aGUg DQpmYWxsYmFjayB3b3VsZCBiZSB0byB1c2UgcG9ydCBudW1iZXIgNTY4NC4NCg0KUmVnYXJkcywg Q2hyaXN0aWFuDQoNCg0KDQpPbiAxNi8wOC8yMDE2IDU6MTAgQU0sIENhcnN0ZW4gQm9ybWFubiB3 cm90ZToNCj4gQnJpYW4gUmF5bW9yIHdyb3RlOg0KPj4gSWYgdGhlIEFwcGxpY2F0aW9uLUxheWVy IFByb3RvY29sIE5lZ290aWF0aW9uIEV4dGVuc2lvbiAoQUxQTikgW1JGQzczMDFdIGlzIGF2YWls YWJsZSBpbiBib3RoIHRoZSBjbGllbnQgYW5kIHNlcnZlciBUTFMgcHJvdG9jb2wgc3RhY2tzLCBD b0FQIG92ZXIgVExTIGltcGxlbWVudGF0aW9ucyBNVVNUIHBlcmZvcm0gcHJvdG9jb2wgbmVnb3Rp YXRpb24gaW4gVExTIHVzaW5nIHRoZSAiY29hcCIgcHJvdG9jb2wgaWRlbnRpZmllciBkZWZpbmVk IGluIFNlY3Rpb24gOC43LiBUaGUgc2VydmVyIE1BWSBhbHNvIG9mZmVyIENvQVAgb3ZlciBUTFMg b25seSBvbiBwb3J0IG51bWJlciA1Njg0IGZvciBleGNlcHRpb25hbCBjYXNlcyB3aGVyZSBBTFBO IGlzIHVuYXZhaWxhYmxlIG9uIHRoZSBjbGllbnQgb3IgdGhlIHNlcnZlci4NCj4gVGhhdCB3b3Jr cyBmb3IgbWUuICBXaXRoIHRoZXNlIGludGVyb3BlcmFiaWxpdHkgbWFuZGF0ZXMsIEknbSBnZW5l cmFsbHkNCj4gaW4gZmF2b3Igb2YgYmVpbmcgdmVyeSBzcGVjaWZpYyBhYm91dCB3aGF0IGFuIGlt cGxlbWVudGF0aW9uIGlzIHN1cHBvc2VkDQo+IHRvIGRvIG9yIG5vdCBzdXBwb3NlZCB0byBkby4g IExldCBtZSB0cnkgdG8gc3VtbWFyaXplOg0KPg0KPiAtLSBBIFRMUyBzZXJ2ZXIgTUFZIG9mZmVy IGEgY29hcHMrdGNwIGVuZHBvaW50IG9uIFRDUCBwb3J0IDU4NjQgaWYgaXQNCj4gZG9lc24ndCBz dXBwb3J0IEFMUE4gYW5kL29yIHRvIGFjY29tbW9kYXRlIFRMUyBjbGllbnRzIHRoYXQgZG9uJ3Qu ICBBDQo+IFRMUyBzZXJ2ZXIgTUFZIG9mZmVyIGNvYXBzK3RjcCBlbmRwb2ludHMgb24gVENQIHBv cnRzIGRpZmZlcmVudCBmcm9tDQo+IDU2ODQgaWYgaXQgZG9lcyBzdXBwb3J0IEFMUE4uDQo+IC0t IE9uIFRDUCBwb3J0cyBkaWZmZXJlbnQgZnJvbSA1Njg0LCBhIGNvYXBzK3RjcCBUTFMgY2xpZW50 IE1VU1Qgb2ZmZXINCj4gQUxQTiB2YWx1ZSAnY29hcCcsIGFuZCB0aGUgY29hcHMrdGNwIFRMUyBz ZXJ2ZXIgb25seSBiZWNvbWVzIGFjdGl2ZSBpZg0KPiB0aGUgVExTIHNlcnZlciBzZWxlY3RzIHRo ZSBBTFBOIHZhbHVlICdjb2FwJy4gIChJZiBhIGRpZmZlcmVudCBBTFBODQo+IHZhbHVlIGlzIG5l Z290aWF0ZWQsIG9yIGlmIHRoZSBBTFBOIG5lZ290aWF0aW9uIGZhaWxzIGFuZCB0aHVzIGNhdXNl cyBhDQo+IGZhdGFsIGFsZXJ0LCB0aGUgcHJlc2VudCBzcGVjaWZpY2F0aW9uIGRvZXMgYmVjb21l IGFjdGl2ZS4pDQo+IC0tIE9uIFRDUCBwb3J0IDU2ODQsIGEgVExTIGNsaWVudCBNQVkgb2ZmZXIg QUxQTiB2YWx1ZSAnY29hcCcgYW5kIGENCj4gY29hcHMrdGNwIFRMUyBzZXJ2ZXIgTUFZIHRoZW4g c2VsZWN0IEFMUE4gdmFsdWUgJ2NvYXAnLiAgKElmIGEgZGlmZmVyZW50DQo+IEFMUE4gdmFsdWUg aXMgbmVnb3RpYXRlZCwgb3IgaWYgdGhlIEFMUE4gbmVnb3RpYXRpb24gZmFpbHMgYW5kIHRodXMN Cj4gY2F1c2VzIGEgZmF0YWwgYWxlcnQsIHRoZSBwcmVzZW50IHNwZWNpZmljYXRpb24gZG9lcyBu b3QgYmVjb21lIGFjdGl2ZS4NCj4gKiopICBJZiB0aGUgY2xpZW50IGRvZXMgbm90IHNlbmQgQUxQ TiBhdCBhbGwsIGNvYXBzK3RjcCBpcyBhc3N1bWVkIHRvIGJlDQo+IHNlbGVjdGVkIG9uIHBvcnQg NTY4NCBvbmx5LiAgSWYgdGhlIGNsaWVudCBkb2VzIHNlbmQgQUxQTiwgYW5kIHRoZQ0KPiBzZXJ2 ZXIgZG9lcyBub3Qgc3VwcG9ydCBBTFBOLCB0aGUgbmVnb3RpYXRpb24gd2lsbCByZXN1bHQgaW4g bm8gQUxQTg0KPiB2YWx1ZSBiZWluZyBleHBsaWNpdGx5IHNlbGVjdGVkIFtjaGVjayB0aGlzXSwg YW5kLCBhZ2FpbiwgY29hcHMrdGNwIGlzDQo+IGFzc3VtZWQgdG8gYmUgc2VsZWN0ZWQgb24gcG9y dCA1Njg0IG9ubHkuDQo+ICoqKSBJZiBhIGRpZmZlcmVudCBBTFBOIGlzIHNlbGVjdGVkIG9uIHBv cnQgNTg2NCwgW2RlZmluZSBiZWhhdmlvciBoZXJlXS4NCj4NCj4gUGhldy4gIEFyZSB0aGVzZSBh bGwgdGhlIGNhc2VzIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQ/DQo+DQo+IFNob3VsZCBpdCBiZSBh bGxvd2VkIHRvIG5lZ290aWF0aW9uIEFMUE4g4omgICdjb2FwJyBvbiBwb3J0IDU2ODQ/DQo+IChQ cm9iYWJseSB5ZXMsIHRvIGVuYWJsZSB0aGUgbmVnb3RpYXRpb24gb2YgYSAnY29hcDInIGV0Yy47 IHdlIGNhbid0DQo+IHJlYWxseSByZXN0cmljdCB3aGF0IGNhbiBiZSBuZWdvdGlhdGVkIGhlcmUg d2l0aG91dCBwcmVkaWN0aW5nIHRoZQ0KPiBmdXR1cmUuICBPciB3ZSBjb3VsZCBjb21wbGV0ZWx5 IGRpc2FsbG93IHRoZSB1c2Ugb2YgQUxQTiBvbiBwb3J0IDU2ODQuKQ0KPg0KPiBHcsO8w59lLCBD YXJzdGVuDQo+DQoNCg== From nobody Wed Aug 17 05:34:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FB212D69A for ; Wed, 17 Aug 2016 05:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NflrPsBwlKpo for ; Wed, 17 Aug 2016 05:34:26 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B20512D67E for ; Wed, 17 Aug 2016 05:34:26 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id y134so37414800pfg.0 for ; Wed, 17 Aug 2016 05:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=WxF+Qx0ihazcej+aUq/ZFVnQR7DuJOTB6ijcuEO1LmM=; b=PtzKou6gvOv5N+Bon01rZCi31KaCB1CZMbD3WEMpepHeNwmO6gA6Ct8vNLyiqFS4CP thhXelJOFIym9gwH1mb4jrs8wfLrCGy06S/Cliil9Ri/aAFg0fDfptF5nRXkivJpHHep 6UH3wp/zQjQaYMoz/BY+vWtWnNGFTPb4ubSUGGpgZ8Is7fxVYuT9JjMHq0TM7porpIQG ilnOHBpy3smhsu7F1XUxSdRVXFgC/tSwY3OiRMl/OCDOupziZhwP8BsN7TeWEFmDLUWO va/5CzcLdxEQmzLOvJNndsBK+DjgU/i+QOJ5TGFTdAohInp3LRCYzO51E0A1xiTvsF5H Vg0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WxF+Qx0ihazcej+aUq/ZFVnQR7DuJOTB6ijcuEO1LmM=; b=FeP9YGFC3I+1s9UzbtcYwLaxKoTLIuIwWZRaqm0Z7lhgCIm9PHOh/5rYY/n7EIXM2L AoqpEIGjZL0/Yf4fJwKZCXPkRYgBtbyg1HaCj7AuJigja64CDCJfvoNwbsid2GzLcRNc t371v11E6gUVlab2K3dSAY155DDDTxFxNAS5gR4+YkDHVd7zp/G2TSgvh9zF/lnceAO0 npbsFONeJyHiE9G9Eu++icvYvRmxLyrOXnXMP37gYARyww0zRT1UtyrW5lk0LtjEh0K4 o+lEpBEXSMw9ETNStfzhRHIuYbbDjbfxfoNa3mgutzqws9YZmTtKMjbGEmQwe7fdMwba u4Og== X-Gm-Message-State: AEkooutL7Pn4j2bVOjSzIC5xTgyHt2kC2/uOuX0i3JvteL2VWENHw0YrFkbXPoVzN+qyTA== X-Received: by 10.98.87.90 with SMTP id l87mr74066115pfb.133.1471437266077; Wed, 17 Aug 2016 05:34:26 -0700 (PDT) Received: from [10.0.0.20] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 71sm47010517pfy.32.2016.08.17.05.34.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 05:34:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_600CEC55-392B-43E8-858C-B8BAC03E816D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Wed, 17 Aug 2016 05:34:23 -0700 Message-Id: <0A49F91D-DC01-48FF-AF01-7D788FD4D803@gmail.com> References: <57AE4B71.5090709@tzi.org> To: Dave Thaler X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 12:34:28 -0000 --Apple-Mail=_600CEC55-392B-43E8-858C-B8BAC03E816D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Assuming we must register rt and if values used in OCF, is the CoRE = Paramaters Registry an appropriate venue for registration? http://www.iana.org/assignments/core-parameters/core-parameters.xhtml = NB in OCF, rt is used for application semantics and there may be = hundreds to thousands of rt terms registered with more being added over = time. Will the CoRE Parameters Registry be appropriate for registration of = such a large volume of terms, or is there another preferred approach? Best regards, Michael > On Aug 14, 2016, at 3:02 PM, Dave Thaler = wrote: >=20 > Thanks Carsten for the response! This answers one of the two = questions I asked. I'm still waiting for an > answer on the other question (in short, it was: can you use values = other than URIs without > registering, or only URIs?) The attached email is the one I'm still = waiting for an answer on. >=20 > I believe I know the answer but since there's apparently confusion, = I'd like confirmation on the list either way. >=20 > Dave >=20 >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: Friday, August 12, 2016 3:19 PM >> To: Dave Thaler >> Cc: core@ietf.org >> Subject: Re: [core] rt and if registry question >>=20 >> Hi Dave, >>=20 >> I'm not the foremost expert on this but I'll give it a try. >>=20 >> Dave Thaler wrote: >>> Can a prefix be registered? >>=20 >> No. There is nothing in section 7.4 of RFC 6690 that would create = such a >> registry. (The concept of prefix is used in 4.1 for certain kinds of = searches, >> but it is really used in its straight computer science meaning of = "the beginning >> part".) >>=20 >> The text about =C2=BBvalues starting with the characters "core"=C2=AB = is about >> swapping out the registration policy, there is no other technical = change. >>=20 >> Note that the text following (that instructs the designated expert) = is about >> avoiding the typical vagaries of choosing between link.format and = linkformat >> and link-format, so it is a matter of style consistency that is meant = to provide >> more predictability (and this memorability) of the values being = registered. It >> uses "core." as an example, not in a normative way. ("core." doesn't = occur in >> the entire RFC outside examples.) >>=20 >> Actually, "coresident-sensors" or "coresident.sensors" have the same = special >> IETF Review policy as "core.foo" -- the policy swap is in effect for = =C2=BBvalues >> starting with the characters "core"=C2=AB. >>=20 >> I believe the current text of RFC 6690 is sufficient to say all this = and no >> retroactive analysis of proceedings or mailing lists is required to = come to this >> conclusion. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_600CEC55-392B-43E8-858C-B8BAC03E816D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Assuming we must register rt and if values used in OCF, is = the CoRE Paramaters Registry an appropriate venue for = registration?

http://www.iana.org/assignments/core-parameters/core-parameters= .xhtml

NB = in OCF, rt is used for application semantics and there may be hundreds = to thousands of rt terms registered with more being added over = time.

Will the = CoRE Parameters Registry be appropriate for registration of such a large = volume of terms, or is there another preferred approach?

Best regards,

Michael


On = Aug 14, 2016, at 3:02 PM, Dave Thaler <dthaler@microsoft.com> wrote:

Thanks Carsten for the response!  This = answers one of the two questions I asked.  I'm still waiting for = an
answer on the other = question (in short, it was: can you use values other than URIs = without
registering, or only = URIs?)   The attached email is the one I'm still waiting for = an answer on.

I believe I know the = answer but since there's apparently confusion, I'd like confirmation on = the list either way.

Dave

-----Original = Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: Friday, August 12, 2016 3:19 PM
To: Dave = Thaler <dthaler@microsoft.com>
Cc: core@ietf.org
Subject: Re: [core] rt and if registry question

Hi Dave,

I'm not = the foremost expert on this but I'll give it a try.

Dave Thaler wrote:
Can a prefix be registered?

No.  There is nothing in section 7.4 of RFC 6690 that = would create such a
registry.  (The concept of prefix = is used in 4.1 for certain kinds of searches,
but it is = really used in its straight computer science meaning of "the = beginning
part".)

The text = about =C2=BBvalues starting with the characters "core"=C2=AB is about
swapping out the registration policy, there is no other = technical change.

Note that the text = following (that instructs the designated expert) is about
avoiding the typical vagaries of choosing between link.format = and linkformat
and link-format, so it is a matter of style = consistency that is meant to provide
more predictability = (and this memorability) of the values being registered.  It
uses "core." as an example, not in a normative way. =  ("core." doesn't occur in
the entire RFC outside = examples.)

Actually, "coresident-sensors" = or "coresident.sensors" have the same special
IETF Review = policy as "core.foo" -- the policy swap is in effect for =C2=BBvalues
starting with the characters "core"=C2=AB.

I believe the current text of RFC 6690 is sufficient to say = all this and no
retroactive analysis of proceedings or = mailing lists is required to come to this
conclusion.

Gr=C3=BC=C3=9Fe, Carsten
<Mail = Attachment.eml>_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_600CEC55-392B-43E8-858C-B8BAC03E816D-- From nobody Wed Aug 17 07:22:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1E12DCD4; Wed, 17 Aug 2016 07:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz06lySs3QMk; Wed, 17 Aug 2016 07:22:38 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04EA12DCBE; Wed, 17 Aug 2016 07:22:29 -0700 (PDT) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 66D02A80BF; Wed, 17 Aug 2016 16:22:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MacoOJ8pT_UX; Wed, 17 Aug 2016 16:22:26 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id AC2B5A80F5; Wed, 17 Aug 2016 16:22:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Wed, 17 Aug 2016 16:22:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1626CDB8-4FED-44F1-AD5D-5CB12FCCE018@ackl.io> References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "core@ietf.org WG" , draft-somaraju-core-sid@ietf.org Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:22:40 -0000 Dear Peter, Thanks for approving the work on the SID draft.=20 It is indeed the generic work which follows a KISS rule - provide a = ultra-light way of assigning ranges. This leaves the flexibility (and = complexity) particular instances may wish to additional specification = (e.g. be it the registry policy, or other). Best, Alexander > Le 15 ao=C3=BBt 2016 =C3=A0 17:26, peter van der Stok = a =C3=A9crit : >=20 > Hi All, >=20 > Andy and I are preparing drafts which present alternatives = (complements) to SID. > Also we are preparing a draft which specifies a a content format that = specifies the payload format for that alternative. >=20 > Although I approve of the work done in the SID draft, I think that we = first need to discuss the cited coming drafts because they may have an = impact on the presentation > and scope of the SID draft. >=20 > Peter >=20 >=20 > Jaime Jim=C3=A9nez schreef op 2016-08-15 17:06: >> Dear CoRE-WG, >> As we discussed at last IETF96, working group adoption has been >> requested for draft-somaraju-core-sid. At the IETF meeting the room >> consensus was for adoption (3 people), since not too many people had >> read the draft we have to take it to the list. Please reply with your >> comments, including although not limited to whether or not you = support >> adoption. Non-authors are especially encouraged to comment. >> Since there are several concurrent WGA calls, we will end the call on >> AUGUST 26, 2016. >> Thanks, >> Jaime and Carsten >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 17 16:01:57 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6E12D1E3 for ; Wed, 17 Aug 2016 16:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uWVY2oydpKK for ; Wed, 17 Aug 2016 16:01:54 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0111.outbound.protection.outlook.com [104.47.32.111]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9324112D0F6 for ; Wed, 17 Aug 2016 16:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sZBtTt5RDPVNIyaHiXRp7kAq4lx3vpAbKHNQyThITCU=; b=PhNFMUwxB2ilju/lC3FwJaSlKAPZ60sCtQvT15/YBr95WsTnJBqdvOOEXcnaW0osfvJXD+6FWOXR9/EI4kHFrP4wajUpL65qLNAPZdEkIRfCHNU2sWViaM1TV9OkDBEax/dUxDfeGtbsYF+iY4Fx4yuT77RA+m4MencpvTeq6jw= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2723.namprd03.prod.outlook.com (10.173.144.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 17 Aug 2016 23:01:52 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0557.022; Wed, 17 Aug 2016 23:01:52 +0000 From: Brian Raymor To: "core@ietf.org" Thread-Topic: coap-tcp-tls pull requests available for review Thread-Index: AdH42bthbBI7f6bVQVe5RlXLgovKpg== Date: Wed, 17 Aug 2016 23:01:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 240f14c0-1005-4964-3721-08d3c6f27a0a x-microsoft-exchange-diagnostics: 1; BN6PR03MB2723; 6:o7XpcnzltS5i7FLs4bB/Uf61A4/lSQ9kuNDsDBd0+Wz/UFws3S1QADIBA/T7AwHnv+BA170atP0sPL0ANB4g+kChosBBlmuFuz+4iLCk4zDNgHZP4pCbN3+H+sOH1Nf9tt1T54ALQny5NB27VaI9HbjoQasTo9jWiTfoTn41mldfrqjW/HrC5zJB7zhIpot27cjpaOUeenzjdmFT2ukeDm41/h7e6bxelbG6zTczhi2DeRWNUpRqge38w3RBfqwtfuwRTsBUz8FGGvBCsmJUfPKspWRFSo8rG3OPRB6lJPjiVBbLQBuo2YRHjKgVRcJgVIpBdc0PL/Q9LbMMOSRwkw==; 5:LqEvU4BqidCu8a3GO4KePmgkb1JC+LGHQ5Ll6tu8uSy81l07GRsCDI2OB9ZjEnsRCcw3AG+DuaQ5x18befg4pXrKEZ70sZ6nC4yo0nSBBwUW9++e0m4LkqFUFRdlYsTSsP4OOvotSQK0oFq13ZiVuA==; 24:0dTqJPZdVIGOn3/DIHyBM/uMlUb9lKyUkIS1R8ZXZUQuaEKpn4iMMLecfZwmSaXtxN1UKYyUVbEyZu1VRrSzhnI7EmqtE/K8zsaSXn6J/TM=; 7:J10C6WvGqEukK/RMe5u5vPoZOW2iAbfB2sGnJjZOD3uPJ4TDjL/XYVxxg0EBTualgu8ua9sW5VcA5WGROhbrzxn35rS4npFJANpL51sEtJgJ/aQMcQHK4m13MjTYiLEwCTdX27TOtmI633DVkbHjYsKg79vfLRkbhj5g6BYVVPcBvYlXt8vk8VfzgVYY6r9VFrCt7juCpnwjEWepgKrAnEnU2HqTosYE3pDY2E3WzCWCA/RssNKAEin5iv7vSODH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2723; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2723; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2723; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(5002640100001)(10290500002)(5005710100001)(33656002)(19580395003)(54356999)(107886002)(81156014)(8676002)(106356001)(66066001)(110136002)(50986999)(9686002)(2906002)(230783001)(8936002)(229853001)(305945005)(15975445007)(101416001)(7846002)(92566002)(7736002)(11100500001)(2351001)(77096005)(122556002)(86612001)(10090500001)(189998001)(5640700001)(3660700001)(74316002)(3280700002)(76576001)(10400500002)(450100001)(105586002)(6116002)(68736007)(86362001)(3846002)(2501003)(102836003)(8990500004)(97736004)(99286002)(81166006)(87936001)(586003)(1730700003)(5640300001)(7696003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2723; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2016 23:01:51.8384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2723 Archived-At: Subject: [core] coap-tcp-tls pull requests available for review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 23:01:56 -0000 A pull request with the more detailed guidance on ALPN and port 5684 is ava= ilable - https://github.com/core-wg/coap-tcp-tls/pull/56 - Thanks to Carste= n and Christian for their earlier feedback. A pull request for the mandatory exchange of capability and setting message= s (csm) is available - https://github.com/core-wg/coap-tcp-tls/pull/55 One open question is whether we want to allow a client to immediately send = messages after sending its CSM without waiting for the server CSM. This wou= ld be similar to HTTP/2: https://tools.ietf.org/html/rfc7540#section-3.5 To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue. And there's a pull request for ping vs ping - https://github.com/core-wg/co= ap-tcp-tls/pull/54 From nobody Thu Aug 18 00:28:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E84512D0CA for ; Thu, 18 Aug 2016 00:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmh9YJXik1Ey for ; Thu, 18 Aug 2016 00:28:53 -0700 (PDT) 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 63C4112B011 for ; Thu, 18 Aug 2016 00:28:53 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud6.xs4all.net with ESMTP id YXUr1t0024d84Ai01XUr9b; Thu, 18 Aug 2016 09:28:51 +0200 Received: from 2001:983:a264:1:6061:1329:d2fe:fe9d by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 18 Aug 2016 09:28:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 18 Aug 2016 09:28:51 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <147150468854.21989.16408413147445931576.idtracker@ietfa.amsl.com> References: <147150468854.21989.16408413147445931576.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (Lqvmhb4EFCGpAjJA8nB8wx570YOsFyI2) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-cbor-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 07:28:56 -0000 Hi all, The draft below has been submitted to complement the draft on YANG Identifiers (YID) with a CBOR encoding of YID. The draft shows how the encoding of the numeric YANG identifiers can be removed from the YANG to CBOR document and delegated to a content-format specification. The draft uses delta encoding, specified in YANG to CBOR document throughout. This has 2 advantages in my opinion: 1) It removes a large burden from the YANG to CBOR document, which can now concentrate on the essentials which are more permanent. 2) It is possible to accommodate future identifier encoding in separate content-format drafts. Greetings, peter ___________________________________________________________________________________________________________________________ A new version of I-D, draft-vanderstok-core-cbor-yid-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-cbor-yid Revision: 00 Title: CBOR format for YIDs Document date: 2016-08-18 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-core-cbor-yid-00.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-cbor-yid/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-cbor-yid-00 Abstract: This document describes CoAP content formats to transport CBOR encoded YANG objects which use numeric YANG object identifiers. YANG objects are serialized according to the YANG to CBOR encoding. The object identifier is composed of a module number followed by a yang name numeric identifier Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. 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 From nobody Fri Aug 19 15:12:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AEB12D0B0 for ; Fri, 19 Aug 2016 15:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smartthings-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jZIWcgQLwYe for ; Fri, 19 Aug 2016 15:12:24 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 43E9912D096 for ; Fri, 19 Aug 2016 15:12:24 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id ti13so19671347pac.0 for ; Fri, 19 Aug 2016 15:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=RSk6yPxHco9/K5MSaqTbQtPPAqMjg6AELpc+eglnOOs=; b=FN/Bd53NERNGNLeY9APSLMlvZgkT5uZJP1rtu+mh6NT8xyop/AfV+JN8mA1L7kO3jG 05SUe9gHoTheUxOW6wmp+4ZUCOyUvm1f0GJgNV/27iDJuocKDv85MAcgd31UfIytUfUP AP1egwErYGDUxgv+oCAI6ASCtCCL9P78G9/hECCXK8oxz6fiAr+4tbmFaMpb2sEROFPp NXCyaTlCLcPun6W0QByerDRKAgDP59rUgHc6X0x+MhMzzOFxhU9gDz+4PoJIGG3Fk6ei CUnBakDNasjMI2t2J3hMzWgQD/9O0QYsBZUd1cNMWa8h6x9z72xrHD5IydliQwFJtOAE 00hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=RSk6yPxHco9/K5MSaqTbQtPPAqMjg6AELpc+eglnOOs=; b=Kn14YRMmm2sy6RSjyy5X44Let4Xm8bPE40CWnG+45fv3VU42c7kc0IdNsajuKUDOC6 LSsBu+DCFtvDvyppOdK3qBhjhxIel92Rop9EsoW1ff1RukX1vGs3lp3Tjp3w8W535aoB Cs/BeBFrnjHKQVjwS9ZWVFB0cr+Jpj0/yCbW3If0QqNFV5nHJ4W1pn+rSQb5skOmNmy+ 7rvXdBfIL7D8p8fAzvWeCADL9OtIXa1dYhYoIra2m4PYMOVZ2j74uxT4ioWAgKicwx+3 Qa3wBNnBAFCzsGbaDI01GWoPDxX04baaHtmkvtG4Jd+mb2tPeFiCZwBaeGYf7hgVZ7E8 LyKw== X-Gm-Message-State: AEkooutRWx4zySnsiTX5Y4Oy1eXSd4dmFHQkG2sfSbcrFUiSySlMExHBSlSvyVtMI1Yam7MX X-Received: by 10.66.5.72 with SMTP id q8mr17844496paq.38.1471644743514; Fri, 19 Aug 2016 15:12:23 -0700 (PDT) Received: from [172.28.33.5] ([162.246.216.202]) by smtp.gmail.com with ESMTPSA id 81sm8799424pfm.90.2016.08.19.15.12.22 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Aug 2016 15:12:22 -0700 (PDT) From: Michael Koster Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 19 Aug 2016 15:12:20 -0700 To: core Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [core] CoAP Content format encoding for structures syntax and format parameters X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 22:12:26 -0000 Hi, What is the curent thought wrt the CoAP content-format encoding for = structured syntax media identifiers, like link-format+json, senml+cbor?=20= Does each combination need to have its own IANA registered code, or is = there a scheme for structured identifier codes in CoAP? Likewise, what is the preferred way to transmit media type parameters, = for example with "application/senml+json; version=3D2" how do we = transmit the version=3D2 part? Best regards, Michael= From nobody Sun Aug 21 02:27:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9223412B008; Sun, 21 Aug 2016 02:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mML8qQylykbT; Sun, 21 Aug 2016 02:27:12 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3412B126579; Sun, 21 Aug 2016 02:27:11 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u7L9R6Zc013628; Sun, 21 Aug 2016 11:27:06 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id BBA7B1D53C1; Sun, 21 Aug 2016 11:27:05 +0200 (CEST) Received: from 92.11.32.46 by webmail.entel.upc.edu with HTTP; Sun, 21 Aug 2016 11:27:09 +0200 Message-ID: In-Reply-To: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> References: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> Date: Sun, 21 Aug 2016 11:27:09 +0200 From: "Carles Gomez Montenegro" To: =?iso-8859-1?Q?=22Jaime_Jim=C3=A9nez=22?= User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Sun, 21 Aug 2016 11:27:07 +0200 (CEST) Archived-At: Cc: "draft-bormann-core-cocoa@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?iso-8859-1?Q?=F0=9F=94=94_Working_Group_Adoption_of_draft-bormann-core-?=cocoa X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 09:27:14 -0000 Dear WG, This is just a short note to remind interested folks that slides 55-59 from the IETF 96 consolidated slideset [1] summarize the current status of CoCoA and work done on the topic. The summary includes IETF/IRTF presentations given, related I-Ds, related research publications, and running code. Thanks! Carles [1] https://www.ietf.org/proceedings/96/slides/slides-96-core-0.pdf PS: I support adoption of the document, although this is probably obvious as I am one of the document authors... > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been requested > for draft-bormann-core-cocoa. At the IETF meeting the room consensus was > for adoption. Please reply to the list with your comments, including > although not limited to whether or not you support adoption. Non-authors > are especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on > August 26, 2016. > > Thanks, > Jaime and Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Aug 22 00:49:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EAD12B036 for ; Mon, 22 Aug 2016 00:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWFFvaLE6X07 for ; Mon, 22 Aug 2016 00:49:50 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 24D5412B025 for ; Mon, 22 Aug 2016 00:49:50 -0700 (PDT) Received: from localhost ([::1]:49140 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bbjzP-0008MM-Jb; Mon, 22 Aug 2016 00:49:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Mon, 22 Aug 2016 07:49:47 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/406#comment:1 Message-ID: <084.9dff65ddfdcfd235de21f5eed75a4c87@trac.tools.ietf.org> References: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org> X-Trac-Ticket-ID: 406 In-Reply-To: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160822074950.24D5412B025@ietfa.amsl.com> Resent-Date: Mon, 22 Aug 2016 00:49:50 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #406 (resource-directory): Consider URI ranking, Privacy Model, etc. as part of RD X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 07:49:52 -0000 #406: Consider URI ranking, Privacy Model, etc. as part of RD Comment (by consultancy@vanderstok.org): As explained and approved during IETF-96, these additions will not be done in this version of the RD draft. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core- akbar.rahman@interdigital.com | resource-directory@tools.ietf.org Type: protocol enhancement | Status: new Priority: major | Milestone: Component: resource-directory | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Mon Aug 22 00:50:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4176C12B049 for ; Mon, 22 Aug 2016 00:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4F5JuFeNSRB for ; Mon, 22 Aug 2016 00:50:17 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 36B2D12B036 for ; Mon, 22 Aug 2016 00:50:17 -0700 (PDT) Received: from localhost ([::1]:49168 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bbjzs-0008SN-WB; Mon, 22 Aug 2016 00:50:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Mon, 22 Aug 2016 07:50:16 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/406#comment:2 Message-ID: <084.a73b337dffcb8d579f484827dd5c4917@trac.tools.ietf.org> References: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org> X-Trac-Ticket-ID: 406 In-Reply-To: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160822075017.36B2D12B036@ietfa.amsl.com> Resent-Date: Mon, 22 Aug 2016 00:50:17 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #406 (resource-directory): Consider URI ranking, Privacy Model, etc. as part of RD X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 07:50:19 -0000 #406: Consider URI ranking, Privacy Model, etc. as part of RD Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core- akbar.rahman@interdigital.com | resource-directory@tools.ietf.org Type: protocol enhancement | Status: closed Priority: major | Milestone: Component: resource-directory | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Mon Aug 22 00:52:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C48812B025 for ; Mon, 22 Aug 2016 00:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEDiSODxH-9v for ; Mon, 22 Aug 2016 00:52:34 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 B03BC12B05A for ; Mon, 22 Aug 2016 00:52:29 -0700 (PDT) Received: from localhost ([::1]:49216 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bbk20-0000eO-Tn; Mon, 22 Aug 2016 00:52:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Mon, 22 Aug 2016 07:52:28 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/414#comment:1 Message-ID: <076.6e3b3c70ad3cabc3961c5240db50e336@trac.tools.ietf.org> References: <061.1d5cb7c19048f47f4cabf407679e6ab5@trac.tools.ietf.org> X-Trac-Ticket-ID: 414 In-Reply-To: <061.1d5cb7c19048f47f4cabf407679e6ab5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160822075229.B03BC12B05A@ietfa.amsl.com> Resent-Date: Mon, 22 Aug 2016 00:52:29 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #414 (resource-directory): RESTful operation and link parameter changes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 07:52:38 -0000 #414: RESTful operation and link parameter changes Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: As explained and approved during IETF-96, these modifications are outside the scope of the current RD, and will not be taken over. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- lauri.piikivi@arm.com | directory@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: resource- | Resolution: fixed directory | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Mon Aug 22 01:02:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210A912B025 for ; Mon, 22 Aug 2016 01:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXcuyVHCVwBZ for ; Mon, 22 Aug 2016 01:02:12 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 2326612B00B for ; Mon, 22 Aug 2016 01:02:12 -0700 (PDT) Received: from localhost ([::1]:49361 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bbkBP-00023m-VW; Mon, 22 Aug 2016 01:02:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: core Date: Mon, 22 Aug 2016 08:02:11 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/405#comment:1 Message-ID: <067.772cf45573899a6620570b0a69c234b2@trac.tools.ietf.org> References: <052.bbf1ea57631d92052fecf668bfbaa79f@trac.tools.ietf.org> X-Trac-Ticket-ID: 405 In-Reply-To: <052.bbf1ea57631d92052fecf668bfbaa79f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-resource-directory@ietf.org Resent-Message-Id: <20160822080212.2326612B00B@ietfa.amsl.com> Resent-Date: Mon, 22 Aug 2016 01:02:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #405 (resource-directory): A link attribute cannot restrict the link-format syntax X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@durif.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 08:02:13 -0000 #405: A link attribute cannot restrict the link-format syntax Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: changed in version 09 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- cabo@tzi.org | directory@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: minor | Version: Component: resource- | Resolution: fixed directory | Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Mon Aug 22 06:56:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979B712D1E6; Mon, 22 Aug 2016 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.069 X-Spam-Level: X-Spam-Status: No, score=-115.069 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3zDBeuC_dr7; Mon, 22 Aug 2016 06:56:33 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4BB12D51F; Mon, 22 Aug 2016 06:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=958; q=dns/txt; s=iport; t=1471874192; x=1473083792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3LTy4Ir59ztejpblzbjMjpRCAalFL4Esxr+moWOgmbQ=; b=AZo1aP2lbZjM0tDdbeziTZgn4l44Q4pHVew1Fydpt/YaI1gVNwIbN5k7 ynmA17hHUXmM75k6sAxppXs6gUZQUk0EcOvUz6QD7xSgd2FuWn06Pyzgc WESaLzbSCu0NKV2n5u/LfqEvMC7kFLkSoRLz5bzgBdpyH1vMrgwgR8A7K A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAgBmA7tX/4wNJK1dg0RWfAe3cYF9J?= =?us-ascii?q?IV5AoFYOBQCAQEBAQEBAV4nhF4BAQQBAQE4NAsFCwIBCBgeECcLJQIEDgWIKQg?= =?us-ascii?q?OvWYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYgjglWEQIMsgi8BBJlIAYYfiH+Bb?= =?us-ascii?q?YRciQeMP4N3AR42g3pwhXx/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,560,1464652800"; d="scan'208";a="313810702" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2016 13:56:31 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7MDuVQD008690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 13:56:31 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 09:56:31 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 09:56:30 -0400 From: "Cullen Jennings (fluffy)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AQHR/Hz8uU6nvhEdjUynKyRH6PCdkg== Date: Mon, 22 Aug 2016 13:56:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F98B1F7A79ACA49A1E09B1D61F421DC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Internet Area , "its@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [Roll] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 13:56:35 -0000 Seems like the draft needs some more on how the IETF will allocate the subt= ype.=20 > On Jul 18, 2016, at 6:39 AM, Suresh Krishnan wrote: >=20 > Hi all, > I am considering AD sponsoring the following draft >=20 > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 >=20 > to request the allocation of an 802.15.4 information element from the IEE= E=20 > for use in the IETF protocols that may need it. If you have any concerns= =20 > either with the content of the draft or about requesting the IE at all pl= ease=20 > let me know before 2016/07/29. >=20 > Thanks > Suresh >=20 > NOTE: I have CCed: all the groups that I thought could be potentially=20 > interested in this work. If you think I have missed out some WG(s) please= let=20 > me know. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 22 07:41:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FD12D620; Mon, 22 Aug 2016 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfgn2nKqsjiK; Mon, 22 Aug 2016 07:41:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 4A85E12D625; Mon, 22 Aug 2016 07:41:41 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7MEfb6b029182 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Aug 2016 17:41:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7MEfbeI007431; Mon, 22 Aug 2016 17:41:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22459.3873.433750.928934@fireball.acr.fi> Date: Mon, 22 Aug 2016 17:41:37 +0300 From: Tero Kivinen To: "Cullen Jennings \(fluffy\)" In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 7 min Archived-At: Cc: Internet Area , "its@ietf.org" , Routing Over Low power and Lossy networks , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [core] [6tisch] [Roll] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 14:41:44 -0000 Cullen Jennings (fluffy) writes: > Seems like the draft needs some more on how the IETF will allocate > the subtype. If you mean how IETF will get the subtype from the IEEE, then after we have this document approved, we make an request to the IEEE refering to this document, and IEEE 802.15 Assigned Numbers Authority will then follow their own procedures to do the allocation: http://www.ieee802.org/15/ANA.html I think first we just need to specify how we are going to do the subtyping (or at least have belivable plan for it) before we can start the process. What kind of text you think we should add to this document? -- kivinen@iki.fi From nobody Mon Aug 22 14:01:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10E412D58A for ; Mon, 22 Aug 2016 14:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmSyRNLfrMNV for ; Mon, 22 Aug 2016 14:01:35 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0122.outbound.protection.outlook.com [104.47.40.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF34312B051 for ; Mon, 22 Aug 2016 14:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZL2AlFEq0E8YOZMBb8f06qL2M3RN4WIM+ScT4/59J1E=; b=i0BijQSdQ5BxWu+U1A+1NjqXmruis5xv4Kqo/7xMyehsrnG47pOCuuh+zarqJdhPDeZK69eBQf+vBK+8E2Lpx8oGOyxaNzlP/7/0muSb5xe8dtaAY8xwVkMvvq6cP46cQ7R/FlOfQaqU+AY97D7xIjpq84x+TuUeUBpj0OXpwpQ= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2306.namprd06.prod.outlook.com (10.173.19.137) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Mon, 22 Aug 2016 21:01:31 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.027; Mon, 22 Aug 2016 21:01:31 +0000 From: Michel Veillette To: Andy Bierman , Core Thread-Topic: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt Thread-Index: AQHR9+2ERIbSZp0cRUaN3JL58ooChqBVabUA Date: Mon, 22 Aug 2016 21:01:31 +0000 Message-ID: References: <147137218567.23002.16239675741482547105.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 11e05cb0-4e47-4766-8e6f-08d3cacf7e30 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2306; 6:zVUQy07IZv3qW9UAI2qMw1gr30GEI+SisgirUDmuaeLDvVLOJxRaa730dp8V2SOzK74IJYV9sI1F4SVtdsJcGbonaodttpaewDLQRcSVY5pJm0uiCKgSR4Oe5TZZQF2hLu6MnZTJlD+Txw7w9ZQIx/2Vtig7fqtKJYu66GD2tUilqV+9uHehUfar6/BDcndfTZNqStBBjjwCroDgGkbdlLr0zi++UR5tqU5/0MGzi3PEL6hdJb9hWcwL83SGC0OxJIyLh5/6ofWneELqXmqgwPqDZ/BK2fIxJ+S713mRJUY=; 5:GpffX04kUBwtqkSME4Z3h4O2ReZZM05/RSf/s8kzact+HaXpWjFuw6l8W9xY4WMAGs+l+eHoaRNRfj9NWjY0wL0wkKdm4MVTYzg0oXnI/TXXgcM3WaTExA30kA71u2thIEHIcQ4Rwy/6zo4uCANRbQ==; 24:YFnQ4UCGorJJja3yojhB5wUSYQgRTVrVocwAX6k3B2iZz0ggtyzPnGDyF+FBhEfW548fL/xOnwbTz9zlXc6d4b5nPjIovb1mtWONIAUUCpM=; 7:5IUyCE2iK+i82VvL/kuc15HgMo+TIE7zlcdAaXannmNn/t64HSZCkBmO4ixfJumvzf0eD2hbq0vmmMOlJgMPh6rAkf9uKhPTLKhDbKt9kBAhHN8B9WZS6wKX0AGCk3NjU/FG5EtrYAhqzbI6kZMEVvmCvQXUGW7ktDNsF5FH6F9T7MATvr6jnrGLKJ1dbXA57l/sYaccArx9g3PDfh1bOTHIWFw66JocKNy/EvoiUJF0PeznkDP9JsBixAPUccnp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2306; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB2306; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2306; x-forefront-prvs: 00429279BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(377424004)(189002)(22974007)(69234005)(2473001)(199003)(377454003)(66066001)(5002640100001)(586003)(7696003)(81166006)(3660700001)(102836003)(15975445007)(7846002)(86362001)(106356001)(790700001)(16236675004)(81156014)(15650500001)(6116002)(5660300001)(11100500001)(3846002)(2420400007)(76576001)(10710500007)(76176999)(19609705001)(77096005)(54356999)(2906002)(189998001)(2950100001)(2900100001)(92566002)(101416001)(3280700002)(122556002)(50986999)(7906003)(33656002)(97736004)(19617315012)(107886002)(74316002)(7110500001)(5001770100001)(19625215002)(7736002)(99286002)(106116001)(68736007)(10400500002)(9686002)(87936001)(105586002)(19300405004)(14971765001)(19580395003)(8936002)(19580405001)(230783001)(16601075003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2306; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23083DBDC47C13647C385AE4FEE80BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2016 21:01:31.2563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2306 Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:01:38 -0000 --_000_BN6PR06MB23083DBDC47C13647C385AE4FEE80BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpJIHNlZSB0d28gZnVuZGFtZW50YWwgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUg U0lEIGFuZCB0aGUgWUlEIGRyYWZ0cy4NCg0KMSkgVGhlIG5hbWUNCllJRCBpcyBoYXJkZXIgdG8g cHJvbm91bmNlLCBidXQgc2VlbSB0byBiZSB0ZWNobmljYWxseSBiZXR0ZXIuDQpUaGVzZSBJRHMg YXJlIG5vdCByZWFsbHkgc3RydWN0dXJlZCwgdGhleSBhcmUgaW4gZmFjdCBhcmJpdHJhcnkgaWYg d2UgYWxsb2NhdGUgdGhlbSBieSByYW5nZShzKS4NCkJ1dCB3ZSBzaGFsbCB1c2UgdGhlbSBvbmx5 IGZvciBZQU5HIGl0ZW1zIGlmIHdlIHdhbnQgdG8ga2VlcCB0aGVtIGNvbXBhY3QuDQoNCjIpIEFs bG9jYXRpb24gcGVyIHJhbmdlIG9yIHBlciBwcmVmaXgNCkxhc3Qgd2ludGVyLCB3ZSBtb3ZlZCBm cm9tIGFuIGFsbG9jYXRpb24gcGVyIHByZWZpeCAoMjAgYml0cywgMTAgYml0cykgdG8gYW4gYWxs b2NhdGlvbiBwZXIgcmFuZ2UocykuDQoNCldlIGRpZCB0aGlzIGNoYW5nZSBmb3IgdGhlIGZvbGxv d2luZyByZWFzb25zOg0KLSBTdGFydmF0aW9uIG9mIElEcy4NClRoZSBzaXplIG9mIHRoZSByYW5n ZSBjYW4gYmUgYWRqdXN0ZWQgYmFzZWQgb24gdGhlIGVzdGltYXRlZCBudW1iZXIgb2YgaXRlbXMg Zm9yIGVhY2ggcGFydGljdWxhciBZQU5HIG1vZHVsZS4NCkFuZCBleHRyYSByYW5nZShzKSBjYW4g YmUgYWRkZWQgaWYgbmVlZGVkLg0KDQotIEVmZmljaWVuY3kNCkFuIGFsbG9jYXRpb24gYmFzZWQg b24gYSBmaXhlZCBudW1iZXIgb2YgYml0cyBiZWNvbWUgdmVyeSBpbmVmZmljaWVudCwgZXNwZWNp YWxseSBpZiB3YW50IG9yIG1pbmltaXplIHRoZSByaWNrcyBvZiBzdGFydmF0aW9uIGFuZCB0byBz dXBwb3J0IG11bHRpcGxlIHRpZXJzIG9mIHJlZ2lzdHJhdGlvbiAoSUFOQSwgU0RPL3JlZ2lzdHJh cnMsIERldmVsb3BlcnMsIFlBTkcgbW9kdWxlcykuDQoNClRoZXNlIHJlYXNvbnMgYXJlIHN0aWxs IHZhbGlkIGFuZCBJIGhvcGUgeW91IGFwcHJlY2lhdGUgdGhlIGFkdmFudGFnZXMgb2YgdXNpbmcg cmFuZ2VzLg0KDQo9PT09PT09PT09PT09PT09PT0NCg0KSSBhbHNvIHdhbnQgdG8gY2xhcmlmeSBh IGNvdXBsZSBvZiBpdGVtcyBkaXNjdXNzZWQgb24gdGhlIG1hbGxpbmcgbGlzdC4NCg0KMSkgW0kt RC5zb21hcmFqdS1jb3JlLXNpZF0gZG9uJ3QgbWFuZGF0ZSBhbnkgc3BlY2lmaWMgYWxnb3JpdGht IHRvIHBlcmZvcm0gdGhlIGFsbG9jYXRpb24gb2YgSURzIHRvIFlBTkcgaXRlbXMuDQpVc2luZyBh IGhhc2ggdG8gcGVyZm9ybSB0aGlzIGFsbG9jYXRpb24gaXMgcGVyZmVjdGx5IHZhbGlkIGFuZCB0 aGUgdGV4dCBzaG91bGQgYmUgbW9kaWZpZWQgdG8gbWVudGlvbiB0aGUgcG9zc2libGUgdXNlIG9m IGEgaGFzaCBvciBhbnkgb3RoZXIgYWxnb3JpdGhtcy4NCg0KMikgbWFudWFsIC8gc2VxdWVudGlh bCBudW1iZXJpbmcNCltJLUQuYmllcm1hbi1jb3JlLXlpZF0gYXNzb2NpYXRlIHRoZSB0ZXJtICJt YW51YWwiIHRvIHNlcXVlbnRpYWwgbnVtYmVyaW5nLg0KU2luY2UgIFtJLUQuc29tYXJhanUtY29y ZS1zaWRdIHJlY29tbWVuZCB0aGUgdXNlIGFuIGF1dG9tYXRlZCBwcm9jZXNzIHRvIHBlcmZvcm0g U0lEcyBhbGxvY2F0aW9uLCB3ZSBzaG91bGQgYXZvaWQgdGhlIHVzZSBvZiAibWFudWFsIiB0byBx dWFsaWZ5IHNlcXVlbnRpYWwgbnVtYmVyaW5nLg0KDQo9PT09PT09PT09PT09PT09PT0NCg0KQXMg YSBsYXN0IGNvbW1lbnQsIFtJLUQuYmllcm1hbi1jb3JlLXlpZF0gY29udGFpbiBhIGxvdCBvZiB2 ZXJ5IGdvb2QgZGVzY3JpcHRpb24gdGV4dCB3aGljaCBzaG91bGQgYmUgcHJlc2VydmVkIGR1cmlu ZyB0aGUgbWVyZ2luZyBwcm9jZXNzLg0KDQpSZWdhcmRzLA0KTWljaGVsIFZlaWxsZXR0ZQ0KDQpG cm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5k eSBCaWVybWFuDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTYgMjozOSBQTQ0KVG86IENv cmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0DQoNCkZZSSwNCg0KDQpQ ZXRlciBhbmQgSSBoYXZlIHdyaXR0ZW4gYSBuZXcgZHJhZnQgY2FsbGVkICJOdW1lcmljIFlBTkcg SWRlbnRpZmllcnMiDQp3aGljaCByZXBsYWNlcyB0aGUgIllBTkcgSGFzaCIgZHJhZnQuDQoNClRo aXMgZHJhZnQgY29tYmluZXMgaGFzaC1iYXNlZCBhbmQgbWFudWFsIG51bWJlcmluZyBhbmQgZGVm aW5lcw0KYSBzaW1wbGUgcmVnaXN0cnktYmFzZWQgcHJvY2VzcyBmb3IgbWFuYWdlbWVudCBvZiBt b2R1bGUgYW5kIG9iamVjdCBpZGVudGlmaWVycy4NCg0KVGhlIG5lZWQgZm9yIGEgcmVoYXNoIHBy b2NlZHVyZSBhbmQgcmVoYXNoIGVycm9ycyBoYXMgYmVlbiByZW1vdmVkLg0KWUFORyBIYXNoIGlz IG5vdyBzY29wZWQgYnkgdGhlIG1vZHVsZSBpZGVudGlmaWVyIHNvIHRoZXJlIGFyZSBubyBpbnRl ci1tb2R1bGUNCmludGVyYWN0aW9ucy4gIEhhc2ggY29sbGlzaW9ucyB3aXRoaW4gYSBtb2R1bGUg YXJlIG5vdCBhbGxvd2VkLg0KTWFudWFsIGFzc2lnbm1lbnRzIGZvciBjb2xsaWRpbmcgbm9kZXMg YXJlIHVzZWQgdG8gYXZvaWQgdGhlIHJhcmUgb2NjdXJyZW5jZQ0Kb2YgYSBoYXNoIGNvbGxpc2lv biB3aXRoaW4gdGhlIHNhbWUgbW9kdWxlLg0KDQoNCg0KQW5keQ0KDQoNCi0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IFR1ZSwgQXVnIDE2LCAy MDE2IGF0IDExOjI5IEFNDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0DQpUbzogUGV0ZXIgdmFuIGRlciBTdG9rIDxjb25z dWx0YW5jeUB2YW5kZXJzdG9rLm9yZzxtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc+ PiwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmllcm1hbi1jb3JlLXlp ZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQW5keSBCaWVybWFu IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBk cmFmdC1iaWVybWFuLWNvcmUteWlkDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAg ICBOdW1lcmljIFlBTkcgSWRlbnRpZmllcnMNCkRvY3VtZW50IGRhdGU6ICAyMDE2LTA4LTE2DQpH cm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMzMN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLWNvcmUteWlkLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaWVybWFuLWNvcmUteWlkLTAw DQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBlbmNvZGluZyBv ZiBZQU5HIG9iamVjdCBpZGVudGlmaWVycyB1c2luZw0KICAgbnVtZXJpYyB2YWx1ZXMgaW5zdGVh ZCBvZiBzdHJpbmcgdmFsdWVzLiAgSXQgY29tYmluZXMgc2V2ZXJhbA0KICAgdGVjaG5pcXVlcyB0 byBwcm92aWRlIG9wdGltaXplZCBzZXJpYWxpemF0aW9uIGluIHByb3RvY29sIG1lc3NhZ2VzLg0K DQpOb3RlDQoNCiAgIERpc2N1c3Npb24gYW5kIHN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVudCBh cmUgcmVxdWVzdGVkLCBhbmQgc2hvdWxkDQogICBiZSBzZW50IHRvIGNvcmVAaWV0Zi5vcmc8bWFp bHRvOmNvcmVAaWV0Zi5vcmc+Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== --_000_BN6PR06MB23083DBDC47C13647C385AE4FEE80BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SGkgQW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkkgc2VlIHR3byBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBTSUQg YW5kIHRoZSBZSUQgZHJhZnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjEpIFRoZSBuYW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WUlEIGlzIGhhcmRlciB0byBwcm9ub3Vu Y2UsIGJ1dCBzZWVtIHRvIGJlIHRlY2huaWNhbGx5IGJldHRlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aGVzZSBJRHMgYXJlIG5vdCByZWFsbHkgc3RydWN0dXJlZCwgdGhleSBhcmUgaW4gZmFjdCBhcmJp dHJhcnkgaWYgd2UgYWxsb2NhdGUgdGhlbSBieSByYW5nZShzKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5C dXQgd2Ugc2hhbGwgdXNlIHRoZW0gb25seSBmb3IgWUFORyBpdGVtcyBpZiB3ZSB3YW50IHRvIGtl ZXAgdGhlbSBjb21wYWN0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+MikgQWxsb2NhdGlvbiBwZXIgcmFuZ2Ugb3IgcGVyIHByZWZpeDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pkxhc3Qgd2ludGVyLCB3ZSBtb3ZlZCBmcm9tIGFuIGFsbG9jYXRpb24gcGVyIHByZWZpeCAoMjAg Yml0cywgMTAgYml0cykgdG8gYW4gYWxsb2NhdGlvbiBwZXIgcmFuZ2UocykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgZGlkIHRoaXMgY2hhbmdlIGZvciB0aGUg Zm9sbG93aW5nIHJlYXNvbnM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tIFN0YXJ2YXRpb24gb2YgSURz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBzaXplIG9mIHRoZSByYW5nZSBjYW4gYmUgYWRqdXN0ZWQg YmFzZWQgb24gdGhlIGVzdGltYXRlZCBudW1iZXIgb2YgaXRlbXMgZm9yIGVhY2ggcGFydGljdWxh ciBZQU5HIG1vZHVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQgZXh0cmEgcmFuZ2UocykgY2FuIGJl IGFkZGVkIGlmIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4tIEVmZmljaWVuY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbiBhbGxvY2F0aW9uIGJhc2VkIG9uIGEg Zml4ZWQgbnVtYmVyIG9mIGJpdHMgYmVjb21lIHZlcnkgaW5lZmZpY2llbnQsIGVzcGVjaWFsbHkg aWYgd2FudCBvciBtaW5pbWl6ZSB0aGUgcmlja3Mgb2Ygc3RhcnZhdGlvbiBhbmQgdG8gc3VwcG9y dCBtdWx0aXBsZSB0aWVycyBvZg0KIHJlZ2lzdHJhdGlvbiAoSUFOQSwgU0RPL3JlZ2lzdHJhcnMs IERldmVsb3BlcnMsIFlBTkcgbW9kdWxlcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhlc2UgcmVhc29ucyBhcmUgc3RpbGwgdmFsaWQgYW5kIEkgaG9wZSB5b3Ug YXBwcmVjaWF0ZSB0aGUgYWR2YW50YWdlcyBvZiB1c2luZyByYW5nZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBhbHNvIHdhbnQgdG8gY2xhcmlmeSBhIGNv dXBsZSBvZiBpdGVtcyBkaXNjdXNzZWQgb24gdGhlIG1hbGxpbmcgbGlzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xKSBbSS1ELnNvbWFyYWp1LWNvcmUtc2lkXSBk b24ndCBtYW5kYXRlIGFueSBzcGVjaWZpYyBhbGdvcml0aG0gdG8gcGVyZm9ybSB0aGUgYWxsb2Nh dGlvbiBvZiBJRHMgdG8gWUFORyBpdGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Vc2luZyBhIGhhc2gg dG8gcGVyZm9ybSB0aGlzIGFsbG9jYXRpb24gaXMgcGVyZmVjdGx5IHZhbGlkIGFuZCB0aGUgdGV4 dCBzaG91bGQgYmUgbW9kaWZpZWQgdG8gbWVudGlvbiB0aGUgcG9zc2libGUgdXNlIG9mIGEgaGFz aCBvciBhbnkgb3RoZXIgYWxnb3JpdGhtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4yKSBtYW51YWwgLyBzZXF1ZW50aWFsIG51bWJlcmluZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPltJLUQuYmllcm1hbi1jb3JlLXlpZF0gYXNzb2NpYXRlIHRoZSB0ZXJtICZxdW90O21hbnVh bCZxdW90OyB0byBzZXF1ZW50aWFsIG51bWJlcmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TaW5jZSAm bmJzcDtbSS1ELnNvbWFyYWp1LWNvcmUtc2lkXSByZWNvbW1lbmQgdGhlIHVzZSBhbiBhdXRvbWF0 ZWQgcHJvY2VzcyB0byBwZXJmb3JtIFNJRHMgYWxsb2NhdGlvbiwgd2Ugc2hvdWxkIGF2b2lkIHRo ZSB1c2Ugb2YgJnF1b3Q7bWFudWFsJnF1b3Q7IHRvIHF1YWxpZnkgc2VxdWVudGlhbCBudW1iZXJp bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09 PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgYSBsYXN0 IGNvbW1lbnQsIFtJLUQuYmllcm1hbi1jb3JlLXlpZF0gY29udGFpbiBhIGxvdCBvZiB2ZXJ5IGdv b2QgZGVzY3JpcHRpb24gdGV4dCB3aGljaCBzaG91bGQgYmUgcHJlc2VydmVkIGR1cmluZyB0aGUg bWVyZ2luZyBwcm9jZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWljaGVsIFZlaWxsZXR0ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGNvcmUg W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkg Qmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTYgMjozOSBQ TTxicj4NCjxiPlRvOjwvYj4gQ29yZSAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW2NvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1i aWVybWFuLWNvcmUteWlkLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZZSSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGV0ZXIgYW5kIEkgaGF2ZSB3cml0dGVuIGEgbmV3IGRyYWZ0IGNhbGxlZCAmcXVvdDtOdW1lcmlj IFlBTkcgSWRlbnRpZmllcnMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPndoaWNoIHJlcGxhY2VzIHRoZSAmcXVvdDtZQU5HIEhhc2gmcXVv dDsgZHJhZnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgY29tYmluZXMgaGFzaC1iYXNlZCBhbmQgbWFudWFsIG51 bWJlcmluZyBhbmQgZGVmaW5lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YSBzaW1wbGUgcmVnaXN0cnktYmFzZWQgcHJvY2VzcyBmb3IgbWFuYWdl bWVudCBvZiBtb2R1bGUgYW5kIG9iamVjdCBpZGVudGlmaWVycy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5lZWQgZm9yIGEgcmVoYXNo IHByb2NlZHVyZSBhbmQgcmVoYXNoIGVycm9ycyBoYXMgYmVlbiByZW1vdmVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WUFORyBIYXNoIGlzIG5v dyBzY29wZWQgYnkgdGhlIG1vZHVsZSBpZGVudGlmaWVyIHNvIHRoZXJlIGFyZSBubyBpbnRlci1t b2R1bGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmludGVyYWN0aW9ucy4mbmJzcDsgSGFzaCBjb2xsaXNpb25zIHdpdGhpbiBhIG1vZHVsZSBhcmUg bm90IGFsbG93ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NYW51YWwgYXNzaWdubWVudHMgZm9yIGNvbGxpZGluZyBub2RlcyBhcmUgdXNlZCB0 byBhdm9pZCB0aGUgcmFyZSBvY2N1cnJlbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiBhIGhhc2ggY29sbGlzaW9uIHdpdGhpbiB0aGUgc2Ft ZSBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLS0t LS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogVHVlLCBBdWcgMTYsIDIwMTYgYXQgMTE6MjkgQU08YnI+DQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpZXJtYW4tY29yZS15 aWQtMDAudHh0PGJyPg0KVG86IFBldGVyIHZhbiBkZXIgU3RvayAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnIj5jb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzwv YT4mZ3Q7LCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0PGJyPg0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbmR5IEJpZXJtYW4gYW5kIHBvc3RlZCB0 byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWJpZXJtYW4tY29yZS15aWQ8YnI+DQpS ZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRpdGxlOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTnVtZXJpYyBZQU5HIElkZW50aWZpZXJzPGJyPg0K RG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNi0wOC0xNjxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAzMzxicj4NClVSTDombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iaWVy bWFuLWNvcmUteWlkLTAwLnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJpZXJtYW4tY29yZS15aWQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYmllcm1hbi1jb3JlLXlpZC88L2E+PGJyPg0KSHRtbGl6ZWQ6 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMDwvYT48YnI+DQo8 YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYW4gZW5jb2Rpbmcgb2YgWUFORyBvYmplY3QgaWRlbnRpZmllcnMgdXNpbmc8YnI+DQom bmJzcDsgJm5ic3A7bnVtZXJpYyB2YWx1ZXMgaW5zdGVhZCBvZiBzdHJpbmcgdmFsdWVzLiZuYnNw OyBJdCBjb21iaW5lcyBzZXZlcmFsPGJyPg0KJm5ic3A7ICZuYnNwO3RlY2huaXF1ZXMgdG8gcHJv dmlkZSBvcHRpbWl6ZWQgc2VyaWFsaXphdGlvbiBpbiBwcm90b2NvbCBtZXNzYWdlcy48YnI+DQo8 YnI+DQpOb3RlPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0Rpc2N1c3Npb24gYW5kIHN1Z2dlc3Rp b25zIGZvciBpbXByb3ZlbWVudCBhcmUgcmVxdWVzdGVkLCBhbmQgc2hvdWxkPGJyPg0KJm5ic3A7 ICZuYnNwO2JlIHNlbnQgdG8gPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0 Zi5vcmc8L2E+Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9v bHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR06MB23083DBDC47C13647C385AE4FEE80BN6PR06MB2308namp_-- From nobody Mon Aug 22 14:17:33 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F65312D0A5 for ; Mon, 22 Aug 2016 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3K3R7A-O8dT for ; Mon, 22 Aug 2016 14:17:29 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 42F5F127071 for ; Mon, 22 Aug 2016 14:17:29 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 74so212494355uau.0 for ; Mon, 22 Aug 2016 14:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=scmvRVfCLd81FajOdvAtugnXjFDgAP6RWoT2o81Ijbs=; b=tMJqPYQyV52ROpmwzjGpEZcqKCWumixUn5pTpqV1jNMQiz1iBAb7InEjXs5JiqyMWt gjq8IHZCr3D+h1LsbFjw9NA1E9marPYV7ZGddqMNkZ8b5wQLkfhrnTylQiSMSPwoDcKm dX3+ebeVfqwAsOtOB48TFys3l1lVSpNPCL6JEJEgpcFx4DkmGWuKfor1Pgmf9YSpjWBg awnUkTSjaaqmDhohtDcGtdT5KK2bhi599iHm7rhad05ELxeTtLokpU9QRqcEeGdolHP0 a/GoHJFwlVgC/hsiVAF+EEuKTh0PgpPyQxiD7bFem8yMJvLlAsOnG6b/ymRcAuuIMYMT LJWg== 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:from:date :message-id:subject:to:cc; bh=scmvRVfCLd81FajOdvAtugnXjFDgAP6RWoT2o81Ijbs=; b=MM8IGs5nUD6+38mnsmHG1NTdR8QiDqUweKFiXeSDqemLjvhIDWfOi9v+qmf+8XH7Lh C297Or2V1chTeJCn6Wa2wWgUjzNzSq6XWmBwfYkzQFKlVrQnikXBBckdeqvWgydqcbHg DBCsCTrZkSZziD/yQYwer6Lzg9xwmVk5fJF7Xptz1Zv50Wc4abBjJGReq+OljCyV3SBy cst2tYGN3Ia7Ghadh7r2oqtn9rdUNLb3sS/9H4EaCEs6tluJ2+leKpQHAHYDbmA/rPgV lQIUFTEMP9jLfM7zNeIMjlYgc1fTboJeq8oGNpvb+uDZ3u+vhOApzYqy6EfTEi+70ZB1 Og6A== X-Gm-Message-State: AEkoouvnpIGR4jCrCsniQeRJPhwUFqLxJ/evL7eqXamPW9rD+3VE9LMeclVjad65imtf2Q/0CtvIPJk5Jiw6eQ== X-Received: by 10.176.3.72 with SMTP id 66mr12301312uat.105.1471900648359; Mon, 22 Aug 2016 14:17:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Mon, 22 Aug 2016 14:17:27 -0700 (PDT) In-Reply-To: References: <147137218567.23002.16239675741482547105.idtracker@ietfa.amsl.com> From: Andy Bierman Date: Mon, 22 Aug 2016 14:17:27 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=001a113f26944a631d053aaf9389 Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:17:32 -0000 --001a113f26944a631d053aaf9389 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 22, 2016 at 2:01 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > > > I see two fundamental differences between the SID and the YID drafts. > > > > 1) The name > > YID is harder to pronounce, but seem to be technically better. > > These IDs are not really structured, they are in fact arbitrary if we > allocate them by range(s). > > But we shall use them only for YANG items if we want to keep them compact. > > > 2) Allocation per range or per prefix > > Last winter, we moved from an allocation per prefix (20 bits, 10 bits) to > an allocation per range(s). > > > I realize that if I ask for a range of 64K, then why should the registry care if I use it for manual numbering or hashing. I think module-ids are easier to manage though. YID proposes that a module-id be added to the YANG Module Registry and IANA will assign the module-id. This is how it works for the SNMP OID root for a MIB module, which is essentially the same thing. IMO modules should fit into 1 range, if ranges are used. > We did this change for the following reasons: > > - Starvation of IDs. > > The size of the range can be adjusted based on the estimated number of > items for each particular YANG module. > > And extra range(s) can be added if needed. > I think the YID registry can be scaled down as needed. e.g., the server "knows" no module it supports has more than 256 objects so the "local-bits" can be scaled down from 16 bits to 8 bits. > > > - Efficiency > > An allocation based on a fixed number of bits become very inefficient, > especially if want or minimize the ricks of starvation and to support > multiple tiers of registration (IANA, SDO/registrars, Developers, YANG > modules). > > > > These reasons are still valid and I hope you appreciate the advantages of > using ranges. > > > > ================== > > > > I also want to clarify a couple of items discussed on the malling list. > > > > 1) [I-D.somaraju-core-sid] don't mandate any specific algorithm to perform > the allocation of IDs to YANG items. > > Using a hash to perform this allocation is perfectly valid and the text > should be modified to mention the possible use of a hash or any other > algorithms. > > > > 2) manual / sequential numbering > > [I-D.bierman-core-yid] associate the term "manual" to sequential numbering. > > Since [I-D.somaraju-core-sid] recommend the use an automated process to > perform SIDs allocation, we should avoid the use of "manual" to qualify > sequential numbering. > No -- I mean manual. What if I want to leave some gaps in the numbering for future growth? Since the number of CBOR bytes is 1 whether the delta is 1 or 23, I can leave padding in the number space without any penalty in the protocol. Sequential numbering gets very non-sequential (the more so with every new module revision). > > > ================== > > > > As a last comment, [I-D.bierman-core-yid] contain a lot of very good > description text which should be preserved during the merging process. > > > > Regards, > > Michel Veillette > > > Andy > *From:* core [mailto:core-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, August 16, 2016 2:39 PM > *To:* Core > *Subject:* [core] Fwd: New Version Notification for > draft-bierman-core-yid-00.txt > > > > FYI, > > > > > > Peter and I have written a new draft called "Numeric YANG Identifiers" > > which replaces the "YANG Hash" draft. > > > > This draft combines hash-based and manual numbering and defines > > a simple registry-based process for management of module and object > identifiers. > > > > The need for a rehash procedure and rehash errors has been removed. > > YANG Hash is now scoped by the module identifier so there are no > inter-module > > interactions. Hash collisions within a module are not allowed. > > Manual assignments for colliding nodes are used to avoid the rare > occurrence > > of a hash collision within the same module. > > > > > > > > Andy > > > > > > ---------- Forwarded message ---------- > From: > Date: Tue, Aug 16, 2016 at 11:29 AM > Subject: New Version Notification for draft-bierman-core-yid-00.txt > To: Peter van der Stok , Andy Bierman < > andy@yumaworks.com> > > > > A new version of I-D, draft-bierman-core-yid-00.txt > has been successfully submitted by Andy Bierman and posted to the > IETF repository. > > Name: draft-bierman-core-yid > Revision: 00 > Title: Numeric YANG Identifiers > Document date: 2016-08-16 > Group: Individual Submission > Pages: 33 > URL: https://www.ietf.org/internet- > drafts/draft-bierman-core-yid-00.txt > Status: https://datatracker.ietf.org/doc/draft-bierman-core-yid/ > Htmlized: https://tools.ietf.org/html/draft-bierman-core-yid-00 > > > Abstract: > This document describes an encoding of YANG object identifiers using > numeric values instead of string values. It combines several > techniques to provide optimized serialization in protocol messages. > > Note > > Discussion and suggestions for improvement are requested, and should > be sent to core@ietf.org. > > > > > 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 > > > --001a113f26944a631d053aaf9389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 22, 2016 at 2:01 PM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:

Hi Andy

=C2=A0

I see two fundamental differences between the SID = and the YID drafts.

=C2=A0

1) The name

YID is harder to pronounce, but seem to be technic= ally better.

These IDs are not really structured, they are in f= act arbitrary if we allocate them by range(s).

But we shall use them only for YANG items if we wa= nt to keep them compact.

=C2=A0

<= div>


<= /span>

2) Allocation per range or per prefix

Last winter, we moved from an allocation per prefi= x (20 bits, 10 bits) to an allocation per range(s).

=C2=A0

<= div>

I realize that if I ask for a range of 64= K, then why should the registry care
if I use it for manual numbe= ring or hashing. I think module-ids
are easier to manage though.= =C2=A0 YID proposes that a module-id be added
to the YANG Module = Registry and IANA will assign the module-id.
This is how it works= for the SNMP OID root for a MIB module,
which is essentially the= same thing.

IMO modules should fit into 1 range, = if ranges are used.


=C2=A0

We did this change for the following reasons:

- Starvation of IDs.

The size of the range can be adjusted based on the= estimated number of items for each particular YANG module.

And extra range(s) can be added if needed.<= /p>



I think the = YID registry can be scaled down as needed.
e.g., the server "= ;knows" no module it supports has more than 256 objects so
t= he "local-bits" can be scaled down from 16 bits to 8 bits.
<= div>

=C2=A0

=C2=A0

- Efficiency

An allocation based on a fixed number of bits beco= me very inefficient, especially if want or minimize the ricks of starvation= and to support multiple tiers of registration (IANA, SDO/registrars, Developers, YANG modules).

=C2=A0

These reasons are still valid and I hope you appre= ciate the advantages of using ranges.

=C2=A0

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

=C2=A0

I also want to clarify a couple of items discussed= on the malling list.

=C2=A0

1) [I-D.somaraju-core-sid] don't mandate any s= pecific algorithm to perform the allocation of IDs to YANG items.=

Using a hash to perform this allocation is perfect= ly valid and the text should be modified to mention the possible use of a h= ash or any other algorithms.

=C2=A0

2) manual / sequential numbering

[I-D.bierman-core-yid] associate the term "ma= nual" to sequential numbering.

Since =C2=A0[I-D.somaraju-core-sid] recommend the = use an automated process to perform SIDs allocation, we should avoid the us= e of "manual" to qualify sequential numbering.



No -- I mean manual.
What if I want to leave some gaps in the numbering for future growt= h?
Since the number of CBOR bytes is 1 whether the delta is 1 or = 23,
I can leave padding in the number space without any penalty i= n the protocol.
Sequential numbering gets very non-sequential (th= e more so with every new module revision).



=C2=A0

=C2=A0

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

=C2=A0

As a last comment, [I-D.bierman-core-yid] contain = a lot of very good description text which should be preserved during the me= rging process.

=C2=A0

Regards,

Michel Veillette

=C2=A0

<= div>

Andy

=C2=A0
<= p class=3D"MsoNormal">

From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, August 16, 2016 2:39 PM
To: Core <core= @ietf.org>
Subject: [core] Fwd: New Version Notification for draft-bierman-core= -yid-00.txt

=C2=A0

FYI,

=C2=A0

=C2=A0

Peter and I have written a new draft called "Nu= meric YANG Identifiers"

which replaces the "YANG Hash" draft.=C2= =A0

=C2=A0

This draft combines hash-based and manual numbering = and defines

a simple registry-based process for management of mo= dule and object identifiers.

=C2=A0

The need for a rehash procedure and rehash errors ha= s been removed.

YANG Hash is now scoped by the module identifier so = there are no inter-module

interactions.=C2=A0 Hash collisions within a module = are not allowed.

Manual assignments for colliding nodes are used to a= void the rare occurrence

of a hash collision within the same module.

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

---------- Forwarded me= ssage ----------
From: <int= ernet-drafts@ietf.org>
Date: Tue, Aug 16, 2016 at 11:29 AM
Subject: New Version Notification for draft-bierman-core-yid-00.txt
To: Peter van der Stok <consultancy@vanderstok.org>, Andy Bierman <andy@yumaworks.com>= ;



A new version of I-D, draft-bierman-core-yid-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bierman-core-yid
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Numeric YANG Identifiers
Document date:=C2=A0 2016-08-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bierman-core-yid-00.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ie= tf.org/doc/draft-bierman-core-yid/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bierman-core-yid-00


Abstract:
=C2=A0 =C2=A0This document describes an encoding of YANG object identifiers= using
=C2=A0 =C2=A0numeric values instead of string values.=C2=A0 It combines sev= eral
=C2=A0 =C2=A0techniques to provide optimized serialization in protocol mess= ages.

Note

=C2=A0 =C2=A0Discussion and suggestions for improvement are requested, and = should
=C2=A0 =C2=A0be sent to = core@ietf.org.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0


--001a113f26944a631d053aaf9389-- From nobody Mon Aug 22 14:58:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A041812D7C9 for ; Mon, 22 Aug 2016 14:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwQTidRpgEZ4 for ; Mon, 22 Aug 2016 14:58:39 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810A112D144 for ; Mon, 22 Aug 2016 14:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7qDIuVVMvo8LYkOLErUKCwjtdowN4++ClGC22NpnOlg=; b=IvTIVzqyheF7DT0bsKTOgpkU91J51pl+fMJcrgECvZ0tiB/8iC6MB64iIibkwy4vh+FGF+82fjfFl8ow2JmtRWq2MF9KjIFhSz/2H/wMEWoA2A7AXUb1am8WfABjNUdH27GTStDmVYSmPh4+Pi04Z9SXXa8syy9kuTthBw9M81I= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Mon, 22 Aug 2016 21:58:36 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.027; Mon, 22 Aug 2016 21:58:36 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt Thread-Index: AQHR/LqYOh5THJz5skSAEc4Eyhw0IqBVgKLg Date: Mon, 22 Aug 2016 21:58:36 +0000 Message-ID: References: <147137218567.23002.16239675741482547105.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 42dcc5c0-efdf-426a-f111-08d3cad7779a x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 6:2+P5o1AFg+ON/EpTXR6qv4J8iO/a7mYJQxQ7LzmaEpMewxlpRF4ehljAtEKISDP5weTVN9mhe1a7kQN4RkRCZKBPfDuZFtsuJwtba3sRGNhOdPKpL3nBF+Y125cwXew2BWbNx+bi+nRe+qT34eC1tRuYGFdDJ1eNUswVNoruMpVuELP5PjTuG51xnqIhiphLHg9PnG/Q7LMod2wKudT3qTO1xMnMSvk1LzXUkAPBBpXxurVCEveHVTX8Z4FP3qqhxLQa2MPYy6x3oeqv9xiuKcHIcu8A3u9faOHzDD6ocrQ=; 5:4033mrrM246GGLdufpESR2NKrO9dqWaKS5juyw3hmPwyQaDdkF+e16AF5qStBoSoGi8LFkiJz6QbOgT51/QXC+Jaj9K+iR1oC4Tb0dITqmrtVUjJ8mPkOXavpR2nGi5y4uBqkhfZcXCymSVgmYiTug==; 24:W4aep5gAetUAb862sGul1SrdzYjeZwBMbjLXV3YqOypeuVO5baHi2pKBzwsNpR8Apkr/y9L1Z475oCO9TArGouXuR/JkyRH/B53joWzysbM=; 7:D72ecFUBcWXYe/P9WrsL6R6SurcofJ7U57rWCYyYpKm3/SxOaovgg/MYauDQRR4E6C0fwo7jlYx3fjfzSdZO7IWHQgURODo2JhKZdTfqQXpbxJnseRt+IVwYVADOgmh+BIKbkDLB/KjUnUWXyI4F/rvjuqc/Cua5/YKlSGbHiWv74gUfom29Ow2ne0QCRZUBYrtaCYdK/3JQ1tpV7jNUMfm8r5ovckfVO/w8GIFVTiF4UoTBZvWXkPv4a6U+rnsP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2305; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 00429279BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(22974007)(24454002)(69234005)(199003)(189002)(377424004)(2473001)(189998001)(97736004)(5660300001)(7110500001)(76176999)(6116002)(586003)(16236675004)(3660700001)(14971765001)(33656002)(54356999)(790700001)(3846002)(110136002)(2906002)(19625215002)(19609705001)(92566002)(102836003)(4326007)(86362001)(10710500007)(5002640100001)(99286002)(19580405001)(3280700002)(101416001)(19300405004)(11100500001)(19617315012)(122556002)(77096005)(81166006)(8676002)(81156014)(8936002)(106356001)(15975445007)(74316002)(50986999)(7906003)(7736002)(7846002)(7696003)(10400500002)(230783001)(76576001)(2420400007)(16601075003)(2950100001)(15650500001)(66066001)(87936001)(106116001)(19580395003)(9686002)(93886004)(2900100001)(68736007)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308EE903A4BB1D806508535FEE80BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2016 21:58:36.2273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:58:41 -0000 --_000_BN6PR06MB2308EE903A4BB1D806508535FEE80BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudCBbTVZdIGlubGluZQ0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxNiA1OjE3IFBNDQpUbzog TWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPg0KQ2M6 IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIEZ3ZDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dA0KDQoNCg0K T24gTW9uLCBBdWcgMjIsIDIwMTYgYXQgMjowMSBQTSwgTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVs LlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxs aWFudGluYy5jb20+PiB3cm90ZToNCkhpIEFuZHkNCkkgc2VlIHR3byBmdW5kYW1lbnRhbCBkaWZm ZXJlbmNlcyBiZXR3ZWVuIHRoZSBTSUQgYW5kIHRoZSBZSUQgZHJhZnRzLg0KIDEpIFRoZSBuYW1l DQpZSUQgaXMgaGFyZGVyIHRvIHByb25vdW5jZSwgYnV0IHNlZW0gdG8gYmUgdGVjaG5pY2FsbHkg YmV0dGVyLg0KVGhlc2UgSURzIGFyZSBub3QgcmVhbGx5IHN0cnVjdHVyZWQsIHRoZXkgYXJlIGlu IGZhY3QgYXJiaXRyYXJ5IGlmIHdlIGFsbG9jYXRlIHRoZW0gYnkgcmFuZ2UocykuDQpCdXQgd2Ug c2hhbGwgdXNlIHRoZW0gb25seSBmb3IgWUFORyBpdGVtcyBpZiB3ZSB3YW50IHRvIGtlZXAgdGhl bSBjb21wYWN0Lg0KMikgQWxsb2NhdGlvbiBwZXIgcmFuZ2Ugb3IgcGVyIHByZWZpeA0KTGFzdCB3 aW50ZXIsIHdlIG1vdmVkIGZyb20gYW4gYWxsb2NhdGlvbiBwZXIgcHJlZml4ICgyMCBiaXRzLCAx MCBiaXRzKSB0byBhbiBhbGxvY2F0aW9uIHBlciByYW5nZShzKS4NCg0KSSByZWFsaXplIHRoYXQg aWYgSSBhc2sgZm9yIGEgcmFuZ2Ugb2YgNjRLLCB0aGVuIHdoeSBzaG91bGQgdGhlIHJlZ2lzdHJ5 IGNhcmUNCmlmIEkgdXNlIGl0IGZvciBtYW51YWwgbnVtYmVyaW5nIG9yIGhhc2hpbmcuIEkgdGhp bmsgbW9kdWxlLWlkcw0KYXJlIGVhc2llciB0byBtYW5hZ2UgdGhvdWdoLiAgWUlEIHByb3Bvc2Vz IHRoYXQgYSBtb2R1bGUtaWQgYmUgYWRkZWQNCnRvIHRoZSBZQU5HIE1vZHVsZSBSZWdpc3RyeSBh bmQgSUFOQSB3aWxsIGFzc2lnbiB0aGUgbW9kdWxlLWlkLg0KVGhpcyBpcyBob3cgaXQgd29ya3Mg Zm9yIHRoZSBTTk1QIE9JRCByb290IGZvciBhIE1JQiBtb2R1bGUsDQp3aGljaCBpcyBlc3NlbnRp YWxseSB0aGUgc2FtZSB0aGluZy4NCg0KW01WXSBJbiBTTk1QLCBhIHNpbmdsZSBPSUQgaXMgdHlw aWNhbGx5IHJlZ2lzdGVyZWQgZm9yIG11bHRpcGxlIG1vZHVsZXMuDQpbTVZdIERldmVsb3BlcnMg YXNzaWduIGRpZmZlcmVudCBhcmNzIG9mIHRoaXMgcmVnaXN0ZXJlZCBPSUQgdG8gZGlmZmVyZW50 IFNOTVAgb2JqZWN0cy4NCltNVl0gV2UgcHJvcG9zZSB0byBkbyB0aGUgc2FtZSB3aXRoIFNJRCBy YW5nZXMsIGRldmVsb3BlcnMgY2FuIGFsbG9jYXRlIG11bHRpcGxlIHN1YnJhbmdlcyBmcm9tIGl0 cyByZWdpc3RlcmVkIHJhbmdlLg0KDQpJTU8gbW9kdWxlcyBzaG91bGQgZml0IGludG8gMSByYW5n ZSwgaWYgcmFuZ2VzIGFyZSB1c2VkLg0KDQpbTVZdIFRoaXMgd2lsbCBiZSBlZmZlY3RpdmVseSB0 aGUgY2FzZSBpbiBtb3N0IGNhc2VzLg0KW01WXSBIb3dldmVyLCB0aGUgcHJvdG9jb2wgc2hhbGwg bm90IGJyZWFrIGlmIHRoZSBudW1iZXIgb2YgWUFORyBpdGVtcyBleGNlZWQgdGhlIGluaXRpYWwg cmFuZ2UgYWxsb2NhdGVkLg0KV2UgZGlkIHRoaXMgY2hhbmdlIGZvciB0aGUgZm9sbG93aW5nIHJl YXNvbnM6DQotIFN0YXJ2YXRpb24gb2YgSURzLg0KVGhlIHNpemUgb2YgdGhlIHJhbmdlIGNhbiBi ZSBhZGp1c3RlZCBiYXNlZCBvbiB0aGUgZXN0aW1hdGVkIG51bWJlciBvZiBpdGVtcyBmb3IgZWFj aCBwYXJ0aWN1bGFyIFlBTkcgbW9kdWxlLg0KQW5kIGV4dHJhIHJhbmdlKHMpIGNhbiBiZSBhZGRl ZCBpZiBuZWVkZWQuDQpJIHRoaW5rIHRoZSBZSUQgcmVnaXN0cnkgY2FuIGJlIHNjYWxlZCBkb3du IGFzIG5lZWRlZC4NCmUuZy4sIHRoZSBzZXJ2ZXIgImtub3dzIiBubyBtb2R1bGUgaXQgc3VwcG9y dHMgaGFzIG1vcmUgdGhhbiAyNTYgb2JqZWN0cyBzbw0KdGhlICJsb2NhbC1iaXRzIiBjYW4gYmUg c2NhbGVkIGRvd24gZnJvbSAxNiBiaXRzIHRvIDggYml0cy4NCg0KW01WXSBUaGUgIm1vZHVsZS1i aXRzIiBpcyBhIGdsb2JhbCBwcm9wZXJ0eSBvZiB0aGUgcmVnaXN0cnkgYW5kIGNhbid0IGJlIGFk anVzdGVkIHBlciBtb2R1bGUuDQpbTVZdIE9uY2Ugc2V0LCBpdCBjYW4ndCBiZSBpbmNyZWFzZWQg dG8gc3VwcG9ydCBhIFlBTkcgbW9kdWxlIHdpdGggbW9yZSBZQU5HIGl0ZW1zIGFuZA0KW01WXSBj YW4ndCBiZSBkZWNyZWFzZWQgdG8gc3VwcG9ydCBlZmZpY2llbnRseSBhIFlBTkcgbW9kdWxlIHdp dGggdmVyeSBmZXcgWUFORyBpdGVtcy4NCg0KLSBFZmZpY2llbmN5DQpBbiBhbGxvY2F0aW9uIGJh c2VkIG9uIGEgZml4ZWQgbnVtYmVyIG9mIGJpdHMgYmVjb21lIHZlcnkgaW5lZmZpY2llbnQsIGVz cGVjaWFsbHkgaWYgd2FudCBvciBtaW5pbWl6ZSB0aGUgcmlja3Mgb2Ygc3RhcnZhdGlvbiBhbmQg dG8gc3VwcG9ydCBtdWx0aXBsZSB0aWVycyBvZiByZWdpc3RyYXRpb24gKElBTkEsIFNETy9yZWdp c3RyYXJzLCBEZXZlbG9wZXJzLCBZQU5HIG1vZHVsZXMpLg0KDQpUaGVzZSByZWFzb25zIGFyZSBz dGlsbCB2YWxpZCBhbmQgSSBob3BlIHlvdSBhcHByZWNpYXRlIHRoZSBhZHZhbnRhZ2VzIG9mIHVz aW5nIHJhbmdlcy4NCg0KPT09PT09PT09PT09PT09PT09DQoNCkkgYWxzbyB3YW50IHRvIGNsYXJp ZnkgYSBjb3VwbGUgb2YgaXRlbXMgZGlzY3Vzc2VkIG9uIHRoZSBtYWxsaW5nIGxpc3QuDQoNCjEp IFtJLUQuc29tYXJhanUtY29yZS1zaWRdIGRvbid0IG1hbmRhdGUgYW55IHNwZWNpZmljIGFsZ29y aXRobSB0byBwZXJmb3JtIHRoZSBhbGxvY2F0aW9uIG9mIElEcyB0byBZQU5HIGl0ZW1zLg0KVXNp bmcgYSBoYXNoIHRvIHBlcmZvcm0gdGhpcyBhbGxvY2F0aW9uIGlzIHBlcmZlY3RseSB2YWxpZCBh bmQgdGhlIHRleHQgc2hvdWxkIGJlIG1vZGlmaWVkIHRvIG1lbnRpb24gdGhlIHBvc3NpYmxlIHVz ZSBvZiBhIGhhc2ggb3IgYW55IG90aGVyIGFsZ29yaXRobXMuDQoNCjIpIG1hbnVhbCAvIHNlcXVl bnRpYWwgbnVtYmVyaW5nDQpbSS1ELmJpZXJtYW4tY29yZS15aWRdIGFzc29jaWF0ZSB0aGUgdGVy bSAibWFudWFsIiB0byBzZXF1ZW50aWFsIG51bWJlcmluZy4NClNpbmNlICBbSS1ELnNvbWFyYWp1 LWNvcmUtc2lkXSByZWNvbW1lbmQgdGhlIHVzZSBhbiBhdXRvbWF0ZWQgcHJvY2VzcyB0byBwZXJm b3JtIFNJRHMgYWxsb2NhdGlvbiwgd2Ugc2hvdWxkIGF2b2lkIHRoZSB1c2Ugb2YgIm1hbnVhbCIg dG8gcXVhbGlmeSBzZXF1ZW50aWFsIG51bWJlcmluZy4NCg0KTm8gLS0gSSBtZWFuIG1hbnVhbC4N CldoYXQgaWYgSSB3YW50IHRvIGxlYXZlIHNvbWUgZ2FwcyBpbiB0aGUgbnVtYmVyaW5nIGZvciBm dXR1cmUgZ3Jvd3RoPw0KU2luY2UgdGhlIG51bWJlciBvZiBDQk9SIGJ5dGVzIGlzIDEgd2hldGhl ciB0aGUgZGVsdGEgaXMgMSBvciAyMywNCkkgY2FuIGxlYXZlIHBhZGRpbmcgaW4gdGhlIG51bWJl ciBzcGFjZSB3aXRob3V0IGFueSBwZW5hbHR5IGluIHRoZSBwcm90b2NvbC4NClNlcXVlbnRpYWwg bnVtYmVyaW5nIGdldHMgdmVyeSBub24tc2VxdWVudGlhbCAodGhlIG1vcmUgc28gd2l0aCBldmVy eSBuZXcgbW9kdWxlIHJldmlzaW9uKS4NCg0KW01WXSBJZiBzbywgd2Ugc3RpbGwgbmVlZCB0byBz dXBwb3J0IG5vbiBoYXNoIGJhc2VkIElEIGdlbmVyYXRlZCBhdXRvbWF0aWNhbGx5Lg0KW01WXSBX ZSBqdXN0IG5lZWQgdG8gZmluZCBhIHRlcm0gd2hpY2ggY292ZXIgYm90aCBjYXNlcyAobWFudWFs bHkgb3IgYXV0b21hdGljYWxseSBhc3NpZ25lZCBJRCkuDQoNCg0KPT09PT09PT09PT09PT09PT09 DQpBcyBhIGxhc3QgY29tbWVudCwgW0ktRC5iaWVybWFuLWNvcmUteWlkXSBjb250YWluIGEgbG90 IG9mIHZlcnkgZ29vZCBkZXNjcmlwdGlvbiB0ZXh0IHdoaWNoIHNob3VsZCBiZSBwcmVzZXJ2ZWQg ZHVyaW5nIHRoZSBtZXJnaW5nIHByb2Nlc3MuDQpSZWdhcmRzLA0KTWljaGVsIFZlaWxsZXR0ZQ0K DQpBbmR5DQoNCg0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2Vu dDogVHVlc2RheSwgQXVndXN0IDE2LCAyMDE2IDI6MzkgUE0NClRvOiBDb3JlIDxjb3JlQGlldGYu b3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6IFtjb3JlXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQNCg0KRllJ LA0KDQoNClBldGVyIGFuZCBJIGhhdmUgd3JpdHRlbiBhIG5ldyBkcmFmdCBjYWxsZWQgIk51bWVy aWMgWUFORyBJZGVudGlmaWVycyINCndoaWNoIHJlcGxhY2VzIHRoZSAiWUFORyBIYXNoIiBkcmFm dC4NCg0KVGhpcyBkcmFmdCBjb21iaW5lcyBoYXNoLWJhc2VkIGFuZCBtYW51YWwgbnVtYmVyaW5n IGFuZCBkZWZpbmVzDQphIHNpbXBsZSByZWdpc3RyeS1iYXNlZCBwcm9jZXNzIGZvciBtYW5hZ2Vt ZW50IG9mIG1vZHVsZSBhbmQgb2JqZWN0IGlkZW50aWZpZXJzLg0KDQpUaGUgbmVlZCBmb3IgYSBy ZWhhc2ggcHJvY2VkdXJlIGFuZCByZWhhc2ggZXJyb3JzIGhhcyBiZWVuIHJlbW92ZWQuDQpZQU5H IEhhc2ggaXMgbm93IHNjb3BlZCBieSB0aGUgbW9kdWxlIGlkZW50aWZpZXIgc28gdGhlcmUgYXJl IG5vIGludGVyLW1vZHVsZQ0KaW50ZXJhY3Rpb25zLiAgSGFzaCBjb2xsaXNpb25zIHdpdGhpbiBh IG1vZHVsZSBhcmUgbm90IGFsbG93ZWQuDQpNYW51YWwgYXNzaWdubWVudHMgZm9yIGNvbGxpZGlu ZyBub2RlcyBhcmUgdXNlZCB0byBhdm9pZCB0aGUgcmFyZSBvY2N1cnJlbmNlDQpvZiBhIGhhc2gg Y29sbGlzaW9uIHdpdGhpbiB0aGUgc2FtZSBtb2R1bGUuDQoNCg0KDQpBbmR5DQoNCg0KLS0tLS0t LS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlLCBB dWcgMTYsIDIwMTYgYXQgMTE6MjkgQU0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQNClRvOiBQZXRlciB2YW4gZGVyIFN0 b2sgPGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPG1haWx0bzpjb25zdWx0YW5jeUB2YW5kZXJz dG9rLm9yZz4+LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaWVybWFu LWNvcmUteWlkLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbmR5 IEJpZXJtYW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAg ICAgICAgIGRyYWZ0LWJpZXJtYW4tY29yZS15aWQNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6 ICAgICAgICAgIE51bWVyaWMgWUFORyBJZGVudGlmaWVycw0KRG9jdW1lbnQgZGF0ZTogIDIwMTYt MDgtMTYNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAg ICAgICAzMw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQvDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpZXJtYW4tY29y ZS15aWQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGVu Y29kaW5nIG9mIFlBTkcgb2JqZWN0IGlkZW50aWZpZXJzIHVzaW5nDQogICBudW1lcmljIHZhbHVl cyBpbnN0ZWFkIG9mIHN0cmluZyB2YWx1ZXMuICBJdCBjb21iaW5lcyBzZXZlcmFsDQogICB0ZWNo bmlxdWVzIHRvIHByb3ZpZGUgb3B0aW1pemVkIHNlcmlhbGl6YXRpb24gaW4gcHJvdG9jb2wgbWVz c2FnZXMuDQoNCk5vdGUNCg0KICAgRGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMgZm9yIGltcHJv dmVtZW50IGFyZSByZXF1ZXN0ZWQsIGFuZCBzaG91bGQNCiAgIGJlIHNlbnQgdG8gY29yZUBpZXRm Lm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0KDQo= --_000_BN6PR06MB2308EE903A4BB1D806508535FEE80BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q29tbWVudCBbTVZdIGlubGluZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFu ZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxNiA1OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWNoZWwg VmVpbGxldHRlICZsdDtNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2NvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iaWVy bWFuLWNvcmUteWlkLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVn IDIyLCAyMDE2IGF0IDI6MDEgUE0sIE1pY2hlbCBWZWlsbGV0dGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNo ZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQW5keTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBz ZWUgdHdvIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIFNJRCBhbmQgdGhlIFlJ RCBkcmFmdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsxKSBUaGUgbmFtZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+WUlEIGlzIGhhcmRlciB0byBwcm9ub3VuY2UsIGJ1dCBzZWVtIHRvIGJlIHRlY2hu aWNhbGx5IGJldHRlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXNlIElEcyBhcmUgbm90IHJlYWxs eSBzdHJ1Y3R1cmVkLCB0aGV5IGFyZSBpbiBmYWN0IGFyYml0cmFyeSBpZiB3ZSBhbGxvY2F0ZSB0 aGVtIGJ5IHJhbmdlKHMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnV0IHdlIHNoYWxsIHVzZSB0aGVt IG9ubHkgZm9yIFlBTkcgaXRlbXMgaWYgd2Ugd2FudCB0byBrZWVwIHRoZW0gY29tcGFjdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4yKSBBbGxvY2F0aW9uIHBlciByYW5nZSBvciBwZXIgcHJlZml4PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5MYXN0IHdpbnRlciwgd2UgbW92ZWQgZnJvbSBhbiBhbGxvY2F0aW9u IHBlciBwcmVmaXggKDIwIGJpdHMsIDEwIGJpdHMpIHRvIGFuIGFsbG9jYXRpb24gcGVyIHJhbmdl KHMpLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSByZWFsaXplIHRoYXQg aWYgSSBhc2sgZm9yIGEgcmFuZ2Ugb2YgNjRLLCB0aGVuIHdoeSBzaG91bGQgdGhlIHJlZ2lzdHJ5 IGNhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmlmIEkgdXNlIGl0IGZvciBtYW51YWwgbnVtYmVyaW5nIG9yIGhhc2hpbmcuIEkgdGhpbmsgbW9k dWxlLWlkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+YXJlIGVhc2llciB0byBtYW5hZ2UgdGhvdWdoLiZuYnNwOyBZSUQgcHJvcG9zZXMgdGhhdCBh IG1vZHVsZS1pZCBiZSBhZGRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dG8gdGhlIFlBTkcgTW9kdWxlIFJlZ2lzdHJ5IGFuZCBJQU5BIHdpbGwg YXNzaWduIHRoZSBtb2R1bGUtaWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGhvdyBpdCB3b3JrcyBmb3IgdGhlIFNOTVAgT0lEIHJv b3QgZm9yIGEgTUlCIG1vZHVsZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPndoaWNoIGlzIGVzc2VudGlhbGx5IHRoZSBzYW1lIHRoaW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0g SW4gU05NUCwgYSBzaW5nbGUgT0lEIGlzIHR5cGljYWxseSByZWdpc3RlcmVkIGZvciBtdWx0aXBs ZSBtb2R1bGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+W01WXSBEZXZlbG9wZXJzIGFzc2lnbiBkaWZmZXJlbnQgYXJjcyBvZiB0 aGlzIHJlZ2lzdGVyZWQgT0lEIHRvIGRpZmZlcmVudCBTTk1QIG9iamVjdHMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bTVZdIFdl IHByb3Bvc2UgdG8gZG8gdGhlIHNhbWUgd2l0aCBTSUQgcmFuZ2VzLCBkZXZlbG9wZXJzIGNhbiBh bGxvY2F0ZSBtdWx0aXBsZSBzdWJyYW5nZXMgZnJvbSBpdHMgcmVnaXN0ZXJlZCByYW5nZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklNTyBtb2R1bGVzIHNob3VsZCBmaXQgaW50byAxIHJhbmdlLCBpZiByYW5nZXMg YXJlIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W01WXSBUaGlzIHdpbGwgYmUgZWZmZWN0aXZlbHkgdGhl IGNhc2UgaW4gbW9zdCBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gSG93ZXZlciwgdGhlIHByb3RvY29sIHNoYWxs IG5vdCBicmVhayBpZiB0aGUgbnVtYmVyIG9mIFlBTkcgaXRlbXMgZXhjZWVkIHRoZSBpbml0aWFs IHJhbmdlIGFsbG9jYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+V2UgZGlkIHRoaXMgY2hhbmdlIGZvciB0aGUgZm9sbG93aW5nIHJlYXNv bnM6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0gU3RhcnZhdGlvbiBvZiBJRHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgc2l6ZSBvZiB0aGUgcmFuZ2UgY2FuIGJlIGFkanVzdGVkIGJhc2VkIG9uIHRo ZSBlc3RpbWF0ZWQgbnVtYmVyIG9mIGl0ZW1zIGZvciBlYWNoIHBhcnRpY3VsYXIgWUFORw0KIG1v ZHVsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZCBleHRyYSByYW5nZShzKSBjYW4gYmUgYWRkZWQg aWYgbmVlZGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgWUlEIHJlZ2lz dHJ5IGNhbiBiZSBzY2FsZWQgZG93biBhcyBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lLmcuLCB0aGUgc2VydmVyICZxdW90O2tub3dz JnF1b3Q7IG5vIG1vZHVsZSBpdCBzdXBwb3J0cyBoYXMgbW9yZSB0aGFuIDI1NiBvYmplY3RzIHNv PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUg JnF1b3Q7bG9jYWwtYml0cyZxdW90OyBjYW4gYmUgc2NhbGVkIGRvd24gZnJvbSAxNiBiaXRzIHRv IDggYml0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5bTVZdIFRoZSAmcXVvdDttb2R1bGUtYml0cyZxdW90OyBpcyBhIGdsb2JhbCBwcm9w ZXJ0eSBvZiB0aGUgcmVnaXN0cnkgYW5kIGNhbid0IGJlIGFkanVzdGVkIHBlciBtb2R1bGUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5bTVZdIE9uY2Ugc2V0LCBpdCBjYW4ndCBiZSBpbmNyZWFzZWQgdG8gc3VwcG9ydCBhIFlBTkcg bW9kdWxlIHdpdGggbW9yZSBZQU5HIGl0ZW1zIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W01WXSBjYW4ndCBiZSBkZWNyZWFz ZWQgdG8gc3VwcG9ydCBlZmZpY2llbnRseSBhIFlBTkcgbW9kdWxlIHdpdGggdmVyeSBmZXcgWUFO RyBpdGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tIEVmZmljaWVuY3k8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkFuIGFsbG9jYXRpb24gYmFzZWQgb24gYSBmaXhlZCBudW1iZXIgb2YgYml0cyBiZWNv bWUgdmVyeSBpbmVmZmljaWVudCwgZXNwZWNpYWxseSBpZiB3YW50IG9yIG1pbmltaXplDQogdGhl IHJpY2tzIG9mIHN0YXJ2YXRpb24gYW5kIHRvIHN1cHBvcnQgbXVsdGlwbGUgdGllcnMgb2YgcmVn aXN0cmF0aW9uIChJQU5BLCBTRE8vcmVnaXN0cmFycywgRGV2ZWxvcGVycywgWUFORyBtb2R1bGVz KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlc2UgcmVh c29ucyBhcmUgc3RpbGwgdmFsaWQgYW5kIEkgaG9wZSB5b3UgYXBwcmVjaWF0ZSB0aGUgYWR2YW50 YWdlcyBvZiB1c2luZyByYW5nZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JIGFsc28gd2FudCB0byBjbGFyaWZ5IGEgY291cGxlIG9mIGl0ZW1z IGRpc2N1c3NlZCBvbiB0aGUgbWFsbGluZyBsaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4xKSBbSS1ELnNvbWFyYWp1LWNvcmUtc2lkXSBkb24ndCBtYW5k YXRlIGFueSBzcGVjaWZpYyBhbGdvcml0aG0gdG8gcGVyZm9ybSB0aGUgYWxsb2NhdGlvbiBvZiBJ RHMgdG8NCiBZQU5HIGl0ZW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VXNpbmcgYSBoYXNoIHRvIHBl cmZvcm0gdGhpcyBhbGxvY2F0aW9uIGlzIHBlcmZlY3RseSB2YWxpZCBhbmQgdGhlIHRleHQgc2hv dWxkIGJlIG1vZGlmaWVkIHRvIG1lbnRpb24NCiB0aGUgcG9zc2libGUgdXNlIG9mIGEgaGFzaCBv ciBhbnkgb3RoZXIgYWxnb3JpdGhtcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+MikgbWFudWFsIC8gc2VxdWVudGlhbCBudW1iZXJpbmc8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPltJLUQuYmllcm1hbi1jb3JlLXlpZF0gYXNzb2NpYXRlIHRoZSB0ZXJtICZxdW90O21h bnVhbCZxdW90OyB0byBzZXF1ZW50aWFsIG51bWJlcmluZy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNp bmNlICZuYnNwO1tJLUQuc29tYXJhanUtY29yZS1zaWRdIHJlY29tbWVuZCB0aGUgdXNlIGFuIGF1 dG9tYXRlZCBwcm9jZXNzIHRvIHBlcmZvcm0gU0lEcyBhbGxvY2F0aW9uLCB3ZQ0KIHNob3VsZCBh dm9pZCB0aGUgdXNlIG9mICZxdW90O21hbnVhbCZxdW90OyB0byBxdWFsaWZ5IHNlcXVlbnRpYWwg bnVtYmVyaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyAtLSBJIG1lYW4gbWFudWFs LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hh dCBpZiBJIHdhbnQgdG8gbGVhdmUgc29tZSBnYXBzIGluIHRoZSBudW1iZXJpbmcgZm9yIGZ1dHVy ZSBncm93dGg/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TaW5jZSB0aGUgbnVtYmVyIG9mIENCT1IgYnl0ZXMgaXMgMSB3aGV0aGVyIHRoZSBkZWx0 YSBpcyAxIG9yIDIzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBjYW4gbGVhdmUgcGFkZGluZyBpbiB0aGUgbnVtYmVyIHNwYWNlIHdpdGhvdXQg YW55IHBlbmFsdHkgaW4gdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VxdWVudGlhbCBudW1iZXJpbmcgZ2V0cyB2ZXJ5IG5v bi1zZXF1ZW50aWFsICh0aGUgbW9yZSBzbyB3aXRoIGV2ZXJ5IG5ldyBtb2R1bGUgcmV2aXNpb24p LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPltNVl0gSWYgc28sIHdlIHN0aWxsIG5lZWQgdG8gc3VwcG9ydCBub24gaGFzaCBi YXNlZCBJRCBnZW5lcmF0ZWQgYXV0b21hdGljYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gV2UganVzdCBuZWVkIHRv IGZpbmQgYSB0ZXJtIHdoaWNoIGNvdmVyIGJvdGggY2FzZXMgKG1hbnVhbGx5IG9yIGF1dG9tYXRp Y2FsbHkgYXNzaWduZWQgSUQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09 PT09PT09PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BcyBhIGxhc3QgY29tbWVudCwgW0ktRC5iaWVybWFu LWNvcmUteWlkXSBjb250YWluIGEgbG90IG9mIHZlcnkgZ29vZCBkZXNjcmlwdGlvbiB0ZXh0IHdo aWNoIHNob3VsZCBiZQ0KIHByZXNlcnZlZCBkdXJpbmcgdGhlIG1lcmdpbmcgcHJvY2Vzcy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWNoZWwgVmVpbGxl dHRlJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gY29yZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5jb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDE2LCAy MDE2IDI6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IENvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3Jl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+RllJLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5QZXRlciBhbmQgSSBoYXZlIHdyaXR0ZW4gYSBuZXcgZHJhZnQgY2FsbGVk ICZxdW90O051bWVyaWMgWUFORyBJZGVudGlmaWVycyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj53aGljaCByZXBsYWNlcyB0aGUgJnF1 b3Q7WUFORyBIYXNoJnF1b3Q7IGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBkcmFmdCBjb21iaW5lcyBoYXNo LWJhc2VkIGFuZCBtYW51YWwgbnVtYmVyaW5nIGFuZCBkZWZpbmVzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmEgc2ltcGxlIHJlZ2lzdHJ5LWJh c2VkIHByb2Nlc3MgZm9yIG1hbmFnZW1lbnQgb2YgbW9kdWxlIGFuZCBvYmplY3QgaWRlbnRpZmll cnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGUgbmVlZCBmb3IgYSByZWhhc2ggcHJvY2VkdXJlIGFuZCByZWhhc2ggZXJyb3JzIGhh cyBiZWVuIHJlbW92ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPllBTkcgSGFzaCBpcyBub3cgc2NvcGVkIGJ5IHRoZSBtb2R1bGUgaWRlbnRp ZmllciBzbyB0aGVyZSBhcmUgbm8gaW50ZXItbW9kdWxlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmludGVyYWN0aW9ucy4mbmJzcDsgSGFzaCBj b2xsaXNpb25zIHdpdGhpbiBhIG1vZHVsZSBhcmUgbm90IGFsbG93ZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1hbnVhbCBhc3NpZ25tZW50 cyBmb3IgY29sbGlkaW5nIG5vZGVzIGFyZSB1c2VkIHRvIGF2b2lkIHRoZSByYXJlIG9jY3VycmVu Y2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ b2YgYSBoYXNoIGNvbGxpc2lvbiB3aXRoaW4gdGhlIHNhbWUgbW9kdWxlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206 ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBUdWUsIEF1 ZyAxNiwgMjAxNiBhdCAxMToyOSBBTTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQ8YnI+DQpUbzogUGV0ZXIgdmFu IGRlciBTdG9rICZsdDs8YSBocmVmPSJtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmci IHRhcmdldD0iX2JsYW5rIj5jb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzwvYT4mZ3Q7LCBBbmR5 IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0i X2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQW5keSBCaWVybWFuIGFuZCBwb3N0 ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1iaWVybWFuLWNvcmUteWlkPGJy Pg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE51bWVyaWMgWUFORyBJZGVudGlmaWVyczxi cj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTYtMDgtMTY8YnI+DQpHcm91cDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2Vz OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMzM8YnI+DQpVUkw6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0IiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt Ymllcm1hbi1jb3JlLXlpZC0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1iaWVybWFuLWNvcmUteWlkLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQvPC9hPjxicj4NCkh0bWxp emVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDA8L2E+PGJy Pg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGFuIGVuY29kaW5nIG9mIFlBTkcgb2JqZWN0IGlkZW50aWZpZXJzIHVzaW5nPGJy Pg0KJm5ic3A7ICZuYnNwO251bWVyaWMgdmFsdWVzIGluc3RlYWQgb2Ygc3RyaW5nIHZhbHVlcy4m bmJzcDsgSXQgY29tYmluZXMgc2V2ZXJhbDxicj4NCiZuYnNwOyAmbmJzcDt0ZWNobmlxdWVzIHRv IHByb3ZpZGUgb3B0aW1pemVkIHNlcmlhbGl6YXRpb24gaW4gcHJvdG9jb2wgbWVzc2FnZXMuPGJy Pg0KPGJyPg0KTm90ZTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtEaXNjdXNzaW9uIGFuZCBzdWdn ZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQgYXJlIHJlcXVlc3RlZCwgYW5kIHNob3VsZDxicj4NCiZu YnNwOyAmbmJzcDtiZSBzZW50IHRvIDxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYg U2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR06MB2308EE903A4BB1D806508535FEE80BN6PR06MB2308namp_-- From nobody Tue Aug 23 01:37:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9145812D8A0; Tue, 23 Aug 2016 01:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoCpjWYv23LQ; Tue, 23 Aug 2016 01:37:21 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E5812D89F; Tue, 23 Aug 2016 01:37:21 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:dced:8e63:3ef2:ee4f] (unknown [IPv6:2001:660:7301:3728:dced:8e63:3ef2:ee4f]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 166971720B3; Tue, 23 Aug 2016 10:37:18 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D7312D5B-EDF7-477E-85DC-1456F66A28BA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> Date: Tue, 23 Aug 2016 10:37:12 +0200 Message-Id: References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-somaraju-core-sid@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 08:37:25 -0000 --Apple-Mail=_D7312D5B-EDF7-477E-85DC-1456F66A28BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, I want to confirm my support for the adoption of the document = draft-somaraju-core-sid (a.k.a. the SID draft). I do so for the following main reasons: - We need a way to represent YANG identifiers for the = draft-ietf-core-yang-cbor. The SID draft provides just this. We must = adopt the document if we want to move forward with the work on this WG = item. - The SID draft is the result of more than a year and a half of = discussions with people from CoRE, NETMOD, IANA and other SDOs. - It is a straightforward and simple document, which provides the = minimal structure on top of which IDs can be allocated. - It provides for a way of having multiple independent registries, = keeping all interoperable, and relieving IANA from the need to do = overcomplicated, per-device allocations. - Running code. There is a tool and a registry which are already used = for prototyping.=20 The SID draft is aimed at: - Interoperability (having devices with modules from different = registries on a single network).=20 - Future-proof. The authors understand that today there are less than = 2000 YANG modules. Yet, the ranges which will be allocated are FOREVER. = This means, that in 2046, we=E2=80=99ll still be allocating IDs from the = ranges we provide today. Independently of the size of identifiers, = delta-encoding provides for ultra-efficient data transfer. However, once = we move over the 32-bit identifiers, we=E2=80=99ll be taking a 8-byte = penalty hit per request. The SID draft provides for a very = straightforward and simple way of allocating blocks of IDs as necessary = for a module. - Constrained-device and constrained-network oriented (if needed) - = after months of discussions we have confirmed that the most efficient = way of representing the data items is with delta-encoding. When = retrieving more than one item, the IDs take one byte on the wire in most = cases. The allocation of IDs can be manual, automatic, or other - this = is not enforced. What the draft enables is the users to make use of this = ultra-efficient identifier representation - if they need it.=20 - If not needed - an alternative mapping scheme can be used, e.g. = trading interoperability and ultra-efficiency for compatibility with = existing implementations. In conclusion, we need the SID draft to be able to move forward with our = WG item - the YANG-CBOR draft.=20 Best, Alexander Disclaimer: I am one of the authors of the draft. I believe we could = make adjustments after the adoption OR decide to have specific drafts = for specific use-cases, but we should not spend too much time getting = back-and-fourth in changing the WG draft.=20 > Le 15 ao=C3=BBt 2016 =C3=A0 17:06, Jaime Jim=C3=A9nez = a =C3=A9crit : >=20 > Dear CoRE-WG, >=20 > As we discussed at last IETF96, working group adoption has been = requested for draft-somaraju-core-sid. At the IETF meeting the room = consensus was for adoption (3 people), since not too many people had = read the draft we have to take it to the list. Please reply with your = comments, including although not limited to whether or not you support = adoption. Non-authors are especially encouraged to comment. >=20 > Since there are several concurrent WGA calls, we will end the call on = August 26, 2016. >=20 > Thanks, > Jaime and Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_D7312D5B-EDF7-477E-85DC-1456F66A28BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

I= want to confirm my support for the adoption of the document = draft-somaraju-core-sid (a.k.a. the SID draft).

I do so for the following main = reasons:
- We need a way to represent YANG = identifiers for the draft-ietf-core-yang-cbor. The SID draft = provides just this. We must adopt the document if we want to move = forward with the work on this WG item.
- The SID = draft is the result of more than a year and a half of discussions with = people from CoRE, NETMOD, IANA and other SDOs.
- It = is a straightforward and simple document, which provides the minimal = structure on top of which IDs can be allocated.
- = It provides for a way of having multiple independent registries, keeping = all interoperable, and relieving IANA from the need to do = overcomplicated, per-device allocations.
- Running = code. There is a tool and a registry which are already used for = prototyping. 


The SID draft is aimed = at:
- Interoperability (having devices with modules = from different registries on a single network). 

- Future-proof. The = authors understand that today there are less than 2000 YANG modules. = Yet, the ranges which will be allocated are FOREVER. This means, that in = 2046, we=E2=80=99ll still be allocating IDs from the ranges we provide = today. Independently of the size of identifiers, delta-encoding provides = for ultra-efficient data transfer. However, once we move over the 32-bit = identifiers, we=E2=80=99ll be taking a 8-byte penalty hit per request. = The SID draft provides for a very straightforward and simple way of = allocating blocks of IDs as necessary for a module.

- = Constrained-device and constrained-network oriented (if needed) - after = months of discussions we have confirmed that the most efficient way of = representing the data items is with delta-encoding. When retrieving more = than one item, the IDs take one byte on the wire in most cases. The = allocation of IDs can be manual, automatic, or other - this is not = enforced. What the draft enables is the users to make use of this = ultra-efficient identifier representation - if they need = it. 
  - If not needed - an = alternative mapping scheme can be used, e.g. trading interoperability = and ultra-efficiency for compatibility with existing = implementations.


In conclusion, we need = the SID draft to be able to move forward with our WG item - the = YANG-CBOR draft. 

Best,
Alexander

Disclaimer: I am one of the authors of = the draft. I believe we could make adjustments after the adoption OR = decide to have specific drafts for specific use-cases, but we should not = spend too much time getting back-and-fourth in changing the WG = draft. 

Le = 15 ao=C3=BBt 2016 =C3=A0 17:06, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> a =C3=A9crit :

Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been = requested for draft-somaraju-core-sid. At the IETF meeting the room = consensus was for adoption (3 people), since not too many people had = read the draft we have to take it to the list. Please reply with your comments, including although not limited to whether or not = you support adoption. Non-authors are especially encouraged to = comment.

Since there are several concurrent WGA calls, we will end the call on August 26, 2016.

Thanks,
Jaime and Carsten

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

= --Apple-Mail=_D7312D5B-EDF7-477E-85DC-1456F66A28BA-- From nobody Tue Aug 23 08:35:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCDA12D734 for ; Tue, 23 Aug 2016 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC7g_f8GbYD0 for ; Tue, 23 Aug 2016 08:35:46 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0129.outbound.protection.outlook.com [104.47.32.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58D012DA68 for ; Tue, 23 Aug 2016 08:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1huRfBjAJQqxUpR3Hclpz35zQKTSXslHl7hMDZaZSic=; b=hnTK9IAkIYclYPXXiob7r0aQwZ31h1NHJzG2Hg0lRBuOjvRcKR1mH1tlpVHF84bg4gU2mxPltvINI4ywqJMxnNgqu7T4APu6LkFJSVko6Yvc2uPacprQkZ4Otvurtz68B02C9rtIwrdeyNOgc30l7Hlcn2S20C21/9FUmRQdh9o= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 23 Aug 2016 15:24:34 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 15:24:34 +0000 From: Michel Veillette To: Andy Bierman , Core Thread-Topic: [core] New Version Notification for draft-bierman-core-yid-00.txt Thread-Index: AdH9UnGGdbcJKHL+RaiqPFv3qZC4IQ== Date: Tue, 23 Aug 2016 15:24:34 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 57bc0a6e-15a6-4018-ec06-08d3cb699689 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 6:dYQyyQeH05Dp0iRNFE8IHoThOe/78zXWuDuUyg2FATj7dETI0dd5SZJQhb9UdjQlBPzTmLpLLY6S4aVJWZP/oyM2uUwHDg45iswsu/S06efDhdISj6iSbjK9jHSt36n+eLaC2cKITaeTbuT3tdWitSmpdV+vXsIzQjkAgKo0qFX6mtCP8QAKktSM/g2ZFnn8TS0LFwfnmItQWrxYdT9CKT2O88Eh3eneG4PJLKEp2cLpEz+ZdrU/Fh0qqk91sVkhKX7M4itjx4vwBkP13R53yWVYrPNwWhRLnHiNEDx3pLM=; 5:qFS7fBghjcdTUJMjDiefl85ZAciQzOGLz4Yz4YvME+PbWBSoMPxc13tTWJtSS9wNKkj50MXpoY/Xk0lYsuq4fnCXO7P5ip0xNKLP7eHnMyKaQIDv7tl2jgYce/yV7oERuvRPW0hCtdxsfWSCNrqcWA==; 24:7q4bvqbrQ8PU2XdmjdzqZ0SMbkbPL7AJ47Yk/GpP+RjovT9Pj2nAk6Bywt1y/ZDv9OJe+v82egZECzlbjNpxzBBo2njIKR6rg30noNTl65k=; 7:3fHWtkT351Xf5ekJsBPWNNbvQa/imi9LwMZN4dqjUWzOho21XDukd2/eDwTB+VpMlAI2desWr2uqVjO2v/fcd5qR4nZ6Dj1UcXVa9JONSDE4e4ig0YOilK/SLNHM5AHbwKpdg05GalWIuOMm+PsyhkYnRVZ04xsDqH8ucIjjOaVxcvorophudUMdOp+y8Gm9hceNeIFARZ0WeLTeIbI3plM6NP5xeHoMuVFKzpzAQh8eZwHZmeWHXo5MkTP8TKpS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2305; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377424004)(189002)(22974007)(377454003)(69234005)(19300405004)(7846002)(7906003)(7736002)(81166006)(81156014)(8676002)(77096005)(122556002)(74316002)(15975445007)(106356001)(8936002)(19580395003)(66066001)(15650500001)(87936001)(105586002)(68736007)(2900100001)(9686002)(76576001)(230783001)(50986999)(7696003)(10400500002)(2420400007)(16601075003)(6116002)(2906002)(92566002)(19625215002)(19609705001)(107886002)(102836003)(5660300001)(5001770100001)(7110500001)(97736004)(54356999)(33656002)(3846002)(790700001)(14971765001)(16236675004)(586003)(3660700001)(11100500001)(189998001)(101416001)(19617315012)(86362001)(5002640100001)(10710500007)(19580405001)(3280700002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308181338DAF308CBE0CEDCFEEB0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 15:24:34.5706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Subject: Re: [core] New Version Notification for draft-bierman-core-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:35:50 -0000 --_000_BN6PR06MB2308181338DAF308CBE0CEDCFEEB0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwIHByb3Bvc2UgdGhhdCBvbmx5IG1h bnVhbGx5IGFzc2lnbmVkIFlJRHMNCmFyZSBtYWludGFpbmVkIGluIHRoZSByZWdpc3RyeSAobWFw cGluZyBsaXN0IG9yIG1hcHBpbmctdXJsKS4gWUlEcyBhc3NvY2lhdGVkIHRvIGENCmhhc2ggYXJl IGV4Y2x1ZGVkIGZyb20gdGhpcyByZWdpc3RyeS4NCg0KVGhpcyBzb2x1dGlvbiBkb2Vzbid0IHNl ZW0gdG8gd29yayBpZiB0aGUgZm9sbG93aW5nIGRlc2lnbiBvYmplY3RpdmVzIGxpc3RlZCBpbg0K c2VjdGlvbiAxLjIgbmVlZCB0byBiZSByZXNwZWN0ZWQ6DQoNCjEtIFBlcnNpc3RlbnQgSWRlbnRp ZmllcnM6IEl0IGlzIGltcG9ydGFudCB0aGF0IG9uY2UgYW4gaWRlbnRpZmllciBpcw0KYXNzaWdu ZWQsIHRoYXQgaXMgaXQgbmV2ZXIgY2hhbmdlZCBpbiBhbnkgZnV0dXJlIHJldmlzaW9ucyBpbiB0 aGUNCm1vZHVsZS4NCg0KMS0gTW9kdWxlIHVwZGF0ZXMgbmVlZCBiZSBzaW1wbGUsIGFuZCBvbmx5 IHJlcXVpcmUgdGhlIGxhdGVzdCBtb2R1bGUNCmFuZCByZWdpc3RyeSBpbmZvcm1hdGlvbi4NCg0K Rm9yIGV4YW1wbGUsIFlBTkcgbW9kdWxlIFggaXMgY3JlYXRlZCB3aXRoOg0KRGF0YSBub2RlIEEg YXNzb2NpYXRlZCB0byBZSUQgPSBoYXNoIDENCkRhdGEgbm9kZSBCIGFzc29jaWF0ZWQgdG8gWUlE ID0gaGFzaCAyDQpEYXRhIG5vZGUgQyBhc3NvY2lhdGVkIHRvIFlJRCA9IGhhc2ggMw0KDQpUaGFu LCBhIG5ldyByZXZpc2lvbiBpcyBjcmVhdGVkIHdpdGg6DQpEYXRhIG5vZGUgRCBhc3NvY2lhdGVk IHRvIFlJRCA9IGhhc2ggMg0KRGF0YSBub2RlIEUgYXNzb2NpYXRlZCB0byBZSUQgPSBoYXNoIDQN Cg0KSXMgdGhpcyBleGFtcGxlLCB3ZSBoYXZlIGEgaGFzaCBjbGFzaCBiZXR3ZWVuIGRhdGEgbm9k ZSBCIGFuZCBELg0KSG93ZXZlciwgdGhlIFlJRCBhc3NpZ25lZCB0byBkYXRhIG5vZGUgQiBieSB2 ZXJzaW9uIDEgaXMgbm90IGFsbG93ZWQgdG8gY2hhbmdlIChvYmplY3RpdmUgIzEpLg0KT25seSBk YXRhIG5vZGUgRCBjYW4gYmUgcmVoYXNoZWQuDQoNClVzaW5nIG9ubHkgdGhlIGxhdGVzdCBtb2R1 bGUgKG9iamVjdGlvbiAjMikgYW5kIG5vIGVudHJ5IGluIHRoZSByZWdpc3RyeSwgdGhlIHByb3Bl ciByZWhhc2ggY2FuJ3QgYmUgcGVyZm9ybWVkLg0KQSBzaW1wbGUgc29sdXRpb24gdG8gdGhpcyBw cm9ibGVtIGlzIHRvIG1haW50YWluIGFsbCBZSURzIGluIHRoZSByZWdpc3RyeS4NCkEgbmV3IGVu dHJ5IGlzIHJlaGFzaGVkIG9ubHkgaWYgYSBjbGFzaCBpcyBkZXRlY3RlZCB3aXRoIGFuIGVudHJ5 IGFscmVhZHkgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkuDQoNCkluIHN1bW1hcnksIHRoZSBwcm9j ZXNzIGlzIHRoZSBzYW1lIGluZGVwZW5kZW50bHkgb2YgdGhlIGFsZ29yaXRobSBpbiB1c2VkIChz ZXF1ZW50aWFsLCBtdXJtdXIzIGhhc2gsIG1hbnVhbCkuDQpFYWNoIHRpbWUgYW4gWUlEIGlzIGFz c2lnbmVkLCBpdCBtdXN0IGJlIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4NCkFuZCBuZXcgZW50cmll cyBhcmUgbm90IGFsbG93ZWQgdG8gY29sbGlkZSB3aXRoIGVudHJpZXMgYWxyZWFkeSBwcmVzZW50 IGluIHRoZSByZWdpc3RyeS4NCg0KVGhlIHN0YW5kYXJkIG1heSBkZXNjcmliZSB0aGVzZSBkaWZm ZXJlbnQgYWxnb3JpdGhtcyAobXVybXVyMyBoYXNoLCBzZXF1ZW50aWFsLCBtYW51YWwpDQpidXQg ZG9u4oCZdCBuZWVkIHRvIG1hbmRhdGUgb25lLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZyb206 IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJp ZXJtYW4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxNiwgMjAxNiAyOjM5IFBNDQpUbzogQ29yZSA8 Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQNCg0KRllJLA0KDQoNClBldGVy IGFuZCBJIGhhdmUgd3JpdHRlbiBhIG5ldyBkcmFmdCBjYWxsZWQgIk51bWVyaWMgWUFORyBJZGVu dGlmaWVycyINCndoaWNoIHJlcGxhY2VzIHRoZSAiWUFORyBIYXNoIiBkcmFmdC4NCg0KVGhpcyBk cmFmdCBjb21iaW5lcyBoYXNoLWJhc2VkIGFuZCBtYW51YWwgbnVtYmVyaW5nIGFuZCBkZWZpbmVz DQphIHNpbXBsZSByZWdpc3RyeS1iYXNlZCBwcm9jZXNzIGZvciBtYW5hZ2VtZW50IG9mIG1vZHVs ZSBhbmQgb2JqZWN0IGlkZW50aWZpZXJzLg0KDQpUaGUgbmVlZCBmb3IgYSByZWhhc2ggcHJvY2Vk dXJlIGFuZCByZWhhc2ggZXJyb3JzIGhhcyBiZWVuIHJlbW92ZWQuDQpZQU5HIEhhc2ggaXMgbm93 IHNjb3BlZCBieSB0aGUgbW9kdWxlIGlkZW50aWZpZXIgc28gdGhlcmUgYXJlIG5vIGludGVyLW1v ZHVsZQ0KaW50ZXJhY3Rpb25zLiAgSGFzaCBjb2xsaXNpb25zIHdpdGhpbiBhIG1vZHVsZSBhcmUg bm90IGFsbG93ZWQuDQpNYW51YWwgYXNzaWdubWVudHMgZm9yIGNvbGxpZGluZyBub2RlcyBhcmUg dXNlZCB0byBhdm9pZCB0aGUgcmFyZSBvY2N1cnJlbmNlDQpvZiBhIGhhc2ggY29sbGlzaW9uIHdp dGhpbiB0aGUgc2FtZSBtb2R1bGUuDQoNCg0KDQpBbmR5DQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlLCBBdWcgMTYsIDIwMTYg YXQgMTE6MjkgQU0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt Ymllcm1hbi1jb3JlLXlpZC0wMC50eHQNClRvOiBQZXRlciB2YW4gZGVyIFN0b2sgPGNvbnN1bHRh bmN5QHZhbmRlcnN0b2sub3JnPG1haWx0bzpjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZz4+LCBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29t Pj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbmR5IEJpZXJtYW4gYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0 LWJpZXJtYW4tY29yZS15aWQNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIE51 bWVyaWMgWUFORyBJZGVudGlmaWVycw0KRG9jdW1lbnQgZGF0ZTogIDIwMTYtMDgtMTYNCkdyb3Vw OiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAzMw0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1i aWVybWFuLWNvcmUteWlkLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQvDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGVuY29kaW5nIG9mIFlB Tkcgb2JqZWN0IGlkZW50aWZpZXJzIHVzaW5nDQogICBudW1lcmljIHZhbHVlcyBpbnN0ZWFkIG9m IHN0cmluZyB2YWx1ZXMuICBJdCBjb21iaW5lcyBzZXZlcmFsDQogICB0ZWNobmlxdWVzIHRvIHBy b3ZpZGUgb3B0aW1pemVkIHNlcmlhbGl6YXRpb24gaW4gcHJvdG9jb2wgbWVzc2FnZXMuDQoNCk5v dGUNCg0KICAgRGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMgZm9yIGltcHJvdmVtZW50IGFyZSBy ZXF1ZXN0ZWQsIGFuZCBzaG91bGQNCiAgIGJlIHNlbnQgdG8gY29yZUBpZXRmLm9yZzxtYWlsdG86 Y29yZUBpZXRmLm9yZz4uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K --_000_BN6PR06MB2308181338DAF308CBE0CEDCFEEB0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkhpIEFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5kcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwIHByb3Bvc2UgdGhhdCBvbmx5IG1hbnVh bGx5IGFzc2lnbmVkIFlJRHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5hcmUgbWFpbnRhaW5lZCBpbiB0aGUg cmVnaXN0cnkgKG1hcHBpbmcgbGlzdCBvciBtYXBwaW5nLXVybCkuIFlJRHMgYXNzb2NpYXRlZCB0 byBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+aGFzaCBhcmUgZXhjbHVkZWQgZnJvbSB0aGlzIHJlZ2lzdHJ5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgc29sdXRpb24g ZG9lc24ndCBzZWVtIHRvIHdvcmsgaWYgdGhlIGZvbGxvd2luZyBkZXNpZ24gb2JqZWN0aXZlcyBs aXN0ZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zZWN0aW9uIDEuMiBuZWVkIHRvIGJlIHJlc3BlY3Rl ZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLSBQZXJzaXN0ZW50 IElkZW50aWZpZXJzOiBJdCBpcyBpbXBvcnRhbnQgdGhhdCBvbmNlIGFuIGlkZW50aWZpZXIgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5hc3NpZ25lZCwgdGhhdCBpcyBpdCBuZXZlciBjaGFuZ2VkIGluIGFu eSBmdXR1cmUgcmV2aXNpb25zIGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1vZHVsZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLSBNb2R1bGUgdXBkYXRlcyBuZWVk IGJlIHNpbXBsZSwgYW5kIG9ubHkgcmVxdWlyZSB0aGUgbGF0ZXN0IG1vZHVsZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPmFuZCByZWdpc3RyeSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwgWUFORyBtb2R1bGUgWCBpcyBjcmVhdGVkIHdp dGg6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RGF0YSBub2RlIEEgYXNzb2NpYXRlZCB0byBZSUQgPSBoYXNo IDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5EYXRhIG5vZGUgQiBhc3NvY2lhdGVkIHRvIFlJRCA9IGhhc2gg MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkRhdGEgbm9kZSBDIGFzc29jaWF0ZWQgdG8gWUlEID0gaGFzaCAz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbiwgYSBuZXcgcmV2 aXNpb24gaXMgY3JlYXRlZCB3aXRoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhdGEgbm9kZSBEIGFzc29j aWF0ZWQgdG8gWUlEID0gaGFzaCAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGF0YSBub2RlIEUgYXNzb2Np YXRlZCB0byBZSUQgPSBoYXNoIDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JcyB0aGlzIGV4YW1wbGUsIHdlIGhhdmUgYSBoYXNoIGNsYXNoIGJldHdlZW4gZGF0YSBu b2RlIEIgYW5kIEQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SG93ZXZlciwgdGhlIFlJRCBhc3NpZ25lZCB0 byBkYXRhIG5vZGUgQiBieSB2ZXJzaW9uIDEgaXMgbm90IGFsbG93ZWQgdG8gY2hhbmdlIChvYmpl Y3RpdmUgIzEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9ubHkgZGF0YSBub2RlIEQgY2FuIGJlIHJlaGFz aGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlVzaW5nIG9ubHkg dGhlIGxhdGVzdCBtb2R1bGUgKG9iamVjdGlvbiAjMikgYW5kIG5vIGVudHJ5IGluIHRoZSByZWdp c3RyeSwgdGhlIHByb3BlciByZWhhc2ggY2FuJ3QgYmUgcGVyZm9ybWVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkEgc2ltcGxlIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbSBpcyB0byBtYWludGFpbiBhbGwg WUlEcyBpbiB0aGUgcmVnaXN0cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBuZXcgZW50cnkgaXMgcmVo YXNoZWQgb25seSBpZiBhIGNsYXNoIGlzIGRldGVjdGVkIHdpdGggYW4gZW50cnkgYWxyZWFkeSBw cmVzZW50IGluIHRoZSByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JbiBzdW1tYXJ5LCB0aGUgcHJvY2VzcyBpcyB0aGUgc2FtZSBpbmRlcGVuZGVudGx5 IG9mIHRoZSBhbGdvcml0aG0gaW4gdXNlZCAoc2VxdWVudGlhbCwgbXVybXVyMyBoYXNoLCBtYW51 YWwpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVhY2ggdGltZSBhbiBZSUQgaXMgYXNzaWduZWQsIGl0IG11 c3QgYmUgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZCBuZXcgZW50 cmllcyBhcmUgbm90IGFsbG93ZWQgdG8gY29sbGlkZSB3aXRoIGVudHJpZXMgYWxyZWFkeSBwcmVz ZW50IGluIHRoZSByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGUgc3RhbmRhcmQgbWF5IGRlc2NyaWJlIHRoZXNlIGRpZmZlcmVudCBhbGdvcml0aG1z IChtdXJtdXIzIGhhc2gsIHNlcXVlbnRpYWwsIG1hbnVhbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5idXQg ZG9u4oCZdCBuZWVkIHRvIG1hbmRhdGUgb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWljaGVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gY29y ZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5k eSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAxNiwgMjAxNiAyOjM5 IFBNPGJyPg0KPGI+VG86PC9iPiBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWJpZXJtYW4tY29yZS15aWQtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RllJLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXRlciBhbmQgSSBoYXZlIHdyaXR0ZW4gYSBuZXcgZHJhZnQgY2FsbGVkICZxdW90O051bWVy aWMgWUFORyBJZGVudGlmaWVycyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hpY2ggcmVwbGFjZXMgdGhlICZxdW90O1lBTkcgSGFzaCZx dW90OyBkcmFmdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBjb21iaW5lcyBoYXNoLWJhc2VkIGFuZCBtYW51YWwg bnVtYmVyaW5nIGFuZCBkZWZpbmVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hIHNpbXBsZSByZWdpc3RyeS1iYXNlZCBwcm9jZXNzIGZvciBtYW5h Z2VtZW50IG9mIG1vZHVsZSBhbmQgb2JqZWN0IGlkZW50aWZpZXJzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbmVlZCBmb3IgYSByZWhh c2ggcHJvY2VkdXJlIGFuZCByZWhhc2ggZXJyb3JzIGhhcyBiZWVuIHJlbW92ZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZQU5HIEhhc2ggaXMg bm93IHNjb3BlZCBieSB0aGUgbW9kdWxlIGlkZW50aWZpZXIgc28gdGhlcmUgYXJlIG5vIGludGVy LW1vZHVsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+aW50ZXJhY3Rpb25zLiZuYnNwOyBIYXNoIGNvbGxpc2lvbnMgd2l0aGluIGEgbW9kdWxlIGFy ZSBub3QgYWxsb3dlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk1hbnVhbCBhc3NpZ25tZW50cyBmb3IgY29sbGlkaW5nIG5vZGVzIGFyZSB1c2Vk IHRvIGF2b2lkIHRoZSByYXJlIG9jY3VycmVuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9mIGEgaGFzaCBjb2xsaXNpb24gd2l0aGluIHRoZSBz YW1lIG1vZHVsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tLS0t LS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9hPiZndDs8YnI+DQpEYXRlOiBUdWUsIEF1ZyAxNiwgMjAxNiBhdCAxMToyOSBBTTxicj4N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmllcm1hbi1jb3Jl LXlpZC0wMC50eHQ8YnI+DQpUbzogUGV0ZXIgdmFuIGRlciBTdG9rICZsdDs8YSBocmVmPSJtYWls dG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmciPmNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3Jn PC9hPiZndDssIEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQ8YnI+DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFuZHkgQmllcm1hbiBhbmQgcG9zdGVk IHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtYmllcm1hbi1jb3JlLXlpZDxicj4N ClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOdW1lcmljIFlBTkcgSWRlbnRpZmllcnM8YnI+ DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE2LTA4LTE2PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDMzPGJyPg0KVVJMOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJp ZXJtYW4tY29yZS15aWQtMDAudHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYmllcm1hbi1jb3JlLXlpZC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLWNvcmUteWlkLzwvYT48YnI+DQpIdG1saXpl ZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwPC9hPjxicj4N Cjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhbiBlbmNvZGluZyBvZiBZQU5HIG9iamVjdCBpZGVudGlmaWVycyB1c2luZzxicj4N CiZuYnNwOyAmbmJzcDtudW1lcmljIHZhbHVlcyBpbnN0ZWFkIG9mIHN0cmluZyB2YWx1ZXMuJm5i c3A7IEl0IGNvbWJpbmVzIHNldmVyYWw8YnI+DQombmJzcDsgJm5ic3A7dGVjaG5pcXVlcyB0byBw cm92aWRlIG9wdGltaXplZCBzZXJpYWxpemF0aW9uIGluIHByb3RvY29sIG1lc3NhZ2VzLjxicj4N Cjxicj4NCk5vdGU8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7RGlzY3Vzc2lvbiBhbmQgc3VnZ2Vz dGlvbnMgZm9yIGltcHJvdmVtZW50IGFyZSByZXF1ZXN0ZWQsIGFuZCBzaG91bGQ8YnI+DQombmJz cDsgJm5ic3A7YmUgc2VudCB0byA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBp ZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0 b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR06MB2308181338DAF308CBE0CEDCFEEB0BN6PR06MB2308namp_-- From nobody Tue Aug 23 09:03:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA65112D541 for ; Tue, 23 Aug 2016 09:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AColx5SemUXm for ; Tue, 23 Aug 2016 09:03:28 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 68F0612D50D for ; Tue, 23 Aug 2016 09:03:24 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 74so252630930uau.0 for ; Tue, 23 Aug 2016 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C0v+kAJMPX2RIC9a/dJlZMPEu4/dZI789TpZ7AKVjYo=; b=Yw+O2IMZdA4znFJND+VZGfuUktfG2clpNHVdH1liVgG9KMz1lwajeQoRZ9y/8+1z4Y AuqZQR+ipRAcuhnFj511QkC3RktkZzMjCgsPjXIn96bB+O6DW/D4+ktFf90AynXCQz/O PLLeTkjmrEqHelldFYWMcrZ5TdZ1cSveEde2lwOqux2XOPgEBfBe81MYGRvy3LSNdwyH mRIWEwi6zqAMCPtMT7E8eyxIudSWeLMyeRvvvw2EKDwE46NnDVjRDkLAs8+T59nAlu/o sXv0Z5nxawztEDx35VML5XTYVMs63rVHVHDNNWwC3yaK5gH81z1clnKlvzPqLzrdRmag UJ+Q== 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:from:date :message-id:subject:to:cc; bh=C0v+kAJMPX2RIC9a/dJlZMPEu4/dZI789TpZ7AKVjYo=; b=HCu3cU91RfgmSOWdZGce813EiU4yNOuC7xMZfReCpxZvChCNtMHLs9GV+O1magCOl4 bzRFb76QcTzveSIBT6sHwtL48Chm9z6FJEeifsXLiRLEvO6MXDpCb0fix60Dv0MRPXus QIdqwsvkspAg4odKmKTbPIjJRDNvahxQ5r8KQmc5WW/LSB3cgqsJZftI8QiZIBiS40QI 9S2I+PZIQKJdVpgbQ95W0aw0waMPqrhakKJnPYSLXQQjJmfXFhl7WwYrB4rhbBayyJLy F4r6812KDFw8teII/FI1xz+Juqor/qLZ7x2OQjofneWh2gSUKYNNLp9TH2wYDCIlVo3f ZX5A== X-Gm-Message-State: AEkoous2PNY+/DNp3DvBMiHzw7THYGUbbBQetbYL7F2O95FJGXu4mYm/qbSSAeedtZmSzXTrY03tCLrWG5ll1Q== X-Received: by 10.176.80.47 with SMTP id b44mr14664344uaa.135.1471968203467; Tue, 23 Aug 2016 09:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Tue, 23 Aug 2016 09:03:22 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Tue, 23 Aug 2016 09:03:22 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=94eb2c18f30ae3816f053abf4d32 Archived-At: Cc: Core Subject: Re: [core] New Version Notification for draft-bierman-core-yid-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 16:03:31 -0000 --94eb2c18f30ae3816f053abf4d32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2016 at 8:24 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > > > draft-bierman-core-yid-00 propose that only manually assigned YIDs > > are maintained in the registry (mapping list or mapping-url). YIDs > associated to a > > hash are excluded from this registry. > > > > This solution doesn't seem to work if the following design objectives > listed in > > section 1.2 need to be respected: > > > > 1- Persistent Identifiers: It is important that once an identifier is > > assigned, that is it never changed in any future revisions in the > > module. > > > > 1- Module updates need be simple, and only require the latest module > > and registry information. > > > > For example, YANG module X is created with: > > Data node A associated to YID =3D hash 1 > > Data node B associated to YID =3D hash 2 > > Data node C associated to YID =3D hash 3 > > > > Than, a new revision is created with: > > Data node D associated to YID =3D hash 2 > > Data node E associated to YID =3D hash 4 > > > > Is this example, we have a hash clash between data node B and D. > > However, the YID assigned to data node B by version 1 is not allowed to > change (objective #1). > > Only data node D can be rehashed. > So the manual entry will be for D, not B. not a problem. > > > Using only the latest module (objection #2) and no entry in the registry, > the proper rehash can't be performed. > Agreed. You do need the current registry entry to create an update to that entry. > A simple solution to this problem is to maintain all YIDs in the registry= . > > A new entry is rehashed only if a clash is detected with an entry already > present in the registry. > Agreed. This also makes SID registry maintenance simple. (Number only the nodes not already present in version N to produce N+1). No matter how the YANG module can possibly be changed over time, the path identifiers remain the same from version to version, and therefore the hashes remain the same. > > > In summary, the process is the same independently of the algorithm in use= d > (sequential, murmur3 hash, manual). > yes > Each time an YID is assigned, it must be added to the registry. > > And new entries are not allowed to collide with entries already present i= n > the registry. > > > > The standard may describe these different algorithms (murmur3 hash, > sequential, manual) > > but don=E2=80=99t need to mandate one. > > > > Regards, > > Michel > > > Andy > *From:* core [mailto:core-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, August 16, 2016 2:39 PM > *To:* Core > *Subject:* [core] Fwd: New Version Notification for > draft-bierman-core-yid-00.txt > > > > FYI, > > > > > > Peter and I have written a new draft called "Numeric YANG Identifiers" > > which replaces the "YANG Hash" draft. > > > > This draft combines hash-based and manual numbering and defines > > a simple registry-based process for management of module and object > identifiers. > > > > The need for a rehash procedure and rehash errors has been removed. > > YANG Hash is now scoped by the module identifier so there are no > inter-module > > interactions. Hash collisions within a module are not allowed. > > Manual assignments for colliding nodes are used to avoid the rare > occurrence > > of a hash collision within the same module. > > > > > > > > Andy > > > > > > ---------- Forwarded message ---------- > From: > Date: Tue, Aug 16, 2016 at 11:29 AM > Subject: New Version Notification for draft-bierman-core-yid-00.txt > To: Peter van der Stok , Andy Bierman < > andy@yumaworks.com> > > > > A new version of I-D, draft-bierman-core-yid-00.txt > has been successfully submitted by Andy Bierman and posted to the > IETF repository. > > Name: draft-bierman-core-yid > Revision: 00 > Title: Numeric YANG Identifiers > Document date: 2016-08-16 > Group: Individual Submission > Pages: 33 > URL: https://www.ietf.org/internet- > drafts/draft-bierman-core-yid-00.txt > Status: https://datatracker.ietf.org/doc/draft-bierman-core-yid/ > Htmlized: https://tools.ietf.org/html/draft-bierman-core-yid-00 > > > Abstract: > This document describes an encoding of YANG object identifiers using > numeric values instead of string values. It combines several > techniques to provide optimized serialization in protocol messages. > > Note > > Discussion and suggestions for improvement are requested, and should > be sent to core@ietf.org. > > > > > 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 > > > --94eb2c18f30ae3816f053abf4d32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 23, 2016 at 8:24 AM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:

Hi Andy

=C2=A0

draft-bierman-core-yid-00 propose th= at only manually assigned YIDs

are maintained in the registry (mapp= ing list or mapping-url). YIDs associated to a

hash are excluded from this registry= .

=C2=A0

This solution doesn't seem to wo= rk if the following design objectives listed in

section 1.2 need to be respected:=

=C2=A0

1- Persistent Identifiers: It is imp= ortant that once an identifier is

assigned, that is it never changed i= n any future revisions in the

module.

=C2=A0

1- Module updates need be simple, an= d only require the latest module

and registry information.<= /u>

=C2=A0

For example, YANG module X is create= d with:

Data node A associated to YID =3D ha= sh 1

Data node B associated to YID =3D ha= sh 2

Data node C associated to YID =3D ha= sh 3

=C2=A0

Than, a new revision is created with= :

Data node D associated to YID =3D ha= sh 2

Data node E associated to YID =3D ha= sh 4

=C2=A0

Is this example, we have a hash clas= h between data node B and D.

However, the YID assigned to data no= de B by version 1 is not allowed to change (objective #1).

Only data node D can be rehashed.



So the = manual entry will be for D, not B. not a problem.

= =C2=A0

=

=C2=A0

Using only the latest module (object= ion #2) and no entry in the registry, the proper rehash can't be perfor= med.



= Agreed. You do need the current registry entry to create
an updat= e to that entry.


=C2=A0

A simple solution to this problem is= to maintain all YIDs in the registry.

A new entry is rehashed only if a cl= ash is detected with an entry already present in the registry.



Agreed.
This also makes SID registry maintenance simple.
(Number only th= e nodes not already present in version N to produce N+1).

No matter how the YANG module can possibly be changed over time,
the path identifiers remain the same from version to version,
=
and therefore the hashes remain the same.

=C2=A0

=

=C2=A0

In summary, the process is the same = independently of the algorithm in used (sequential, murmur3 hash, manual).<= /span>



yes

=C2=A0

Each time an YID is assigned, it mus= t be added to the registry.

And new entries are not allowed to c= ollide with entries already present in the registry.

=C2=A0

The standard may describe these diff= erent algorithms (murmur3 hash, sequential, manual)

but don=E2=80=99t need to mandate on= e.

=C2=A0

Regards,

Michel

=C2=A0

=

Andy
=C2=A0

From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, August 16, 2016 2:39 PM
To: Core <core= @ietf.org>
Subject: [core] Fwd: New Version Notification for draft-bierman-core= -yid-00.txt

=C2=A0

FYI,

=C2=A0

=C2=A0

Peter and I have written a new draft called "Nu= meric YANG Identifiers"

which replaces the "YANG Hash" draft.=C2= =A0

=C2=A0

This draft combines hash-based and manual numbering = and defines

a simple registry-based process for management of mo= dule and object identifiers.

=C2=A0

The need for a rehash procedure and rehash errors ha= s been removed.

YANG Hash is now scoped by the module identifier so = there are no inter-module

interactions.=C2=A0 Hash collisions within a module = are not allowed.

Manual assignments for colliding nodes are used to a= void the rare occurrence

of a hash collision within the same module.

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Tue, Aug 16, 2016 at 11:29 AM
Subject: New Version Notification for draft-bierman-core-yid-00.txt
To: Peter van der Stok <consultancy@vanderstok.org>, Andy Bierman <andy@yumaworks.com>= ;



A new version of I-D, draft-bierman-core-yid-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bierman-core-yid
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Numeric YANG Identifiers
Document date:=C2=A0 2016-08-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bierman-core-yid-00.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ie= tf.org/doc/draft-bierman-core-yid/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bierman-core-yid-00


Abstract:
=C2=A0 =C2=A0This document describes an encoding of YANG object identifiers= using
=C2=A0 =C2=A0numeric values instead of string values.=C2=A0 It combines sev= eral
=C2=A0 =C2=A0techniques to provide optimized serialization in protocol mess= ages.

Note

=C2=A0 =C2=A0Discussion and suggestions for improvement are requested, and = should
=C2=A0 =C2=A0be sent to = core@ietf.org.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0


--94eb2c18f30ae3816f053abf4d32-- From nobody Tue Aug 23 13:18:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618F212DACE for ; Tue, 23 Aug 2016 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlS8APR03z4F for ; Tue, 23 Aug 2016 13:18:45 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0103.outbound.protection.outlook.com [104.47.33.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAFC12DADB for ; Tue, 23 Aug 2016 13:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LW49Oc7wTSLtKFfibsOB084nhtZjUafPujRXUcIHdd8=; b=ceMY7e/LbUbAHELvBOVUnO0/Uqd4JmuDq2YkYx4U1pPo1foBfzBlk5YeqNSvm7+PyJT6C1cVttOF6cLmAXyRJ3o5pa/aFMQOZydyU+ylkxFgCuNrn8PClJbwzarEXjz7i2ZDtrcQsvzpZNcYX3NBBswVcfdwI669YqDmQS5SIis= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 23 Aug 2016 20:18:23 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 20:18:23 +0000 From: Michel Veillette To: Core Thread-Topic: New Version Notification for draft-veillette-core-cool-library-00.txt Thread-Index: AQHR/XtNV7SN/6lRlUeRSu8z4xelk6BW+8GA Date: Tue, 23 Aug 2016 20:18:23 +0000 Message-ID: References: <147198341778.21934.10336578771769389907.idtracker@ietfa.amsl.com> In-Reply-To: <147198341778.21934.10336578771769389907.idtracker@ietfa.amsl.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: ca26457b-548a-456d-67f9-08d3cb92a21f x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 6:GKPLfEhnNqgvIlaBaBAFnClYvZx14HB9SyJoSFyv1iaG8DnzSgetXUDKBCOFmn7VaKbWIPbVW5BPMn/RkgiBvAEFmx/rsQi4QtMJYd8/WfooNEgY1ncSiB4VYKdTUsZHTILXp9+Bay614Iu2zkWvcV2qHUA8S12ecu/hgpFqiZj+IzUgtmh9vuJan6+0cbSCRLxg+vtWsfXtSdCYe/Bi9j+awM8Iraa3fBQee4V058vir4ewdKT3WrHr9yudrANFLJDbH+VfCUfLZe0r5/cfOQGnsjk8wLRUhqoWXCiuCCg=; 5:wLcvz0DZHm2JT5LIwbgybRhwIQpdpq+PSymMOZC4uC+ZrHc7jkp/LmNROPJyAqiCP13mEqKiIkQSSWn2LyM0SW1YoIS8RjdycTDMrSHBgfbp2u9I1ngYm+H+grd7dAUxBdth7iWe+vU3kXONEDY/2Q==; 24:lw/i6ma3pFj1t/xhZcvdBPI/f/jGjX8G1viNDXSIqJUHYjlK1Wfr07pcIQALFfKnw4yt4D0Sw6B9w010egU5aPSx/wlwHS/+vAlJHCfnkik=; 7:ZIlAIPBQfGbo/Im8yim/6UDFALIZOinYuClxbhof+YHu5q/NSCz0BgVT5RJlE2qBG0c1PKqdRK+l+DB51wSd9GDPN0Lvz7K+H+n7A0dF58wXwuz/6jMvhEla169TDVd1B2LGq/9A9fCz+l0iUR+pJxgkEnnwbvZKsvqocAXitJjDDpUP3wGohQ0/DT7hE+bR3uTADAzFWBQyKQQeHEQal1y0hfan2zdqHb/SrMW6AizL2QlctKa7SuN/u1O9rQkX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(189002)(199003)(450100001)(105586002)(106116001)(68736007)(54356999)(9686002)(50986999)(76176999)(2906002)(10400500002)(106356001)(230783001)(8936002)(99286002)(101416001)(5660300001)(81166006)(92566002)(76576001)(7846002)(305945005)(74316002)(7696003)(81156014)(122556002)(87936001)(7736002)(15975445007)(11100500001)(5002640100001)(66066001)(33656002)(2900100001)(77096005)(8676002)(2950100001)(189998001)(3660700001)(110136002)(102836003)(586003)(6116002)(3846002)(3280700002)(107886002)(19580395003)(86362001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 20:18:23.2941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Subject: [core] FW: New Version Notification for draft-veillette-core-cool-library-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 20:18:47 -0000 QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wtbGlicmFyeS0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGVsIFZlaWxsZXR0 ZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC12ZWls bGV0dGUtY29yZS1jb29sLWxpYnJhcnkNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlDb25zdHJhaW5l ZCBZQU5HIE1vZHVsZSBMaWJyYXJ5DQpEb2N1bWVudCBkYXRlOgkyMDE2LTA4LTIzDQpHcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12ZWlsbGV0dGUtY29yZS1jb29s LWxpYnJhcnktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdmVpbGxldHRlLWNvcmUtY29vbC1saWJyYXJ5Lw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZWlsbGV0dGUtY29yZS1jb29s LWxpYnJhcnktMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg bGlicmFyeSwgd2hpY2ggcHJvdmlkZXMgaW5mb3JtYXRpb24gYWJvdXQNCiAgIGFsbCBZQU5HIG1v ZHVsZXMgaW1wbGVtZW50ZWQgYnkgYSBDb09MIHNlcnZlciBlbmRwb2ludC4gIEEgc2ltcGxlDQog ICBjYWNoaW5nIG1lY2hhbmlzbSBpcyBwcm92aWRlZCB0byBtaW5pbWl6ZSByZXRyaWV2YWwgb2Yg dGhpcw0KICAgaW5mb3JtYXRpb24gYnkgQ29PTCBjbGllbnRzLg0KDQo= From nobody Tue Aug 23 13:35:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62B112DAF3 for ; Tue, 23 Aug 2016 13:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ29xU_hw9M8 for ; Tue, 23 Aug 2016 13:35:27 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0106.outbound.protection.outlook.com [104.47.32.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C621312DAF7 for ; Tue, 23 Aug 2016 13:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L66UVHVUGRDc9mS+jbqnBduHZcvbldgHzhmkOw8Q4q8=; b=lhtCCWwaeaVZuXxeLhR1GmKn/fferZsNjr9c/McX3HdrdVno/znS1kJGuIx8FnjSyS0SsSga3JFEYgp/NPWDAmcuWQWjWx+kItShdisnYEk2jbu+IkngF0us/m6Kuq8npj2vSRH7z+/9ewejL5ESMiber2dlZFm4v2uTqEWrdTs= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2306.namprd06.prod.outlook.com (10.173.19.137) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 23 Aug 2016 20:35:23 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 20:35:23 +0000 From: Michel Veillette To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gY2FsbCBmb3Ig?= =?utf-8?Q?draft-somaraju-core-sid?= Thread-Index: AQHR/RmUGWUF12YwLkiGi0nYbykEOqBW/Yig Date: Tue, 23 Aug 2016 20:35:23 +0000 Message-ID: References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 64767748-6ab7-4d8a-b36c-08d3cb950215 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2306; 6:z4fG6ulfeqoYLxqx6NCoDMkN+/ZXXMC160Vag5dTrLuuMYmuJw3+lZ6CGjdflEGKm5JmbBImXmJOx02CfpuVAWwcdTF8oVcL/GtF0TMIsrtB5H5Yf6noaUC4L3E46DqJ3+fIDoH1MQPRsbOst2de8vabHkB3JhvXQ9bW1zw6XaliZVQfv4THbaQKfq7/fOFmJppTj7GVARiCZlKll4cH9Z8ELfrAWsH+iKTA9jkCsPbu/aVKQ2xqwYDufFbX2B9lahPvyhMZYCbSvdFRiAbyidp/K5D/jG1IFQuqkBtcDJ4=; 5:yfWDJhJrwAq9NuLvyXuHcfXjxXLPn54uc/GpThOKlVmvR7msV5sd+oAGc37gXF0IQPxj8GW7k4EdOw2PhUFqhCOY8g2XBqgw6H4U04ASE3+heWCLXc+TNz5j6KqtnAOJ/w7fmn+IQKSWmYTnoHtzXg==; 24:sWduj4d5m3LlHsznFoFjcYdHJApZW1QBvhtp/0+xYx+V9XkHArBplP5fKZiEt+zr6nSuIpKALk8Bo9fp/e0olQPm26nFSLpx42z6kumiSzs=; 7:VB/KRthg0fATbjgkeq9fXCsbDc/ME9+8w8chzgxbItLxr6w1LY54/KMoqKf6D9MlkF/TcVWr6iAqPvUCE3alkO8Oc02g4vrElIT8y0ohDDFwX4cHF0Kv1Uqq9FwJqx9Au27Yuip+VVe8rp4a4UAN/QKUjNTJHGzt4s/ErZkUieygL7SWLcG9o6Hdrx4LzDQovUBP/RHXSOviONoB5aDJ1ygwTGAO+BvPyVlnW5VDdu9MzifvfMbCQdar141qGNEi x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2306; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB2306; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2306; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(76576001)(33656002)(19617315012)(7906003)(97736004)(74316002)(107886002)(92566002)(19625215002)(2950100001)(189998001)(5001770100001)(2900100001)(50986999)(122556002)(101416001)(3280700002)(229383001)(105586002)(230783001)(87936001)(19300405004)(19580405001)(8936002)(99286002)(9686002)(106116001)(68736007)(10400500002)(19580395003)(102836003)(3660700001)(81166006)(15975445007)(790700001)(7846002)(86362001)(106356001)(66066001)(7736002)(81156014)(5002640100001)(586003)(7696003)(16236675004)(77096005)(19609705001)(2906002)(54356999)(76176999)(3846002)(6116002)(5660300001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2306; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23089B3621DD9CC77AD944A5FEEB0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 20:35:23.2852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2306 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 20:35:30 -0000 --_000_BN6PR06MB23089B3621DD9CC77AD944A5FEEB0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSSBhbHNvIHdhbnQgdG8gY29uZmlybSBteSBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24g b2YgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbWFyYWp1LWNvcmUt c2lkLykgLg0KDQpUaGlzIGRyYWZ0IGlzIGEgZnVuZGFtZW50YWwgYnVpbGRpbmcgYmxvY2sgZm9y IGJyaW5naW5nIFlBTkcgZGF0YSBtb2RlbHMgdG8gQ09SRS4NClRoaXMgZHJhZnQgaXMgYSBwcmVy ZXF1aXNpdGUgZm9yIHRoZSBmb2xsb3dpbmcgd29ya3M6DQoNCi0gQ0JPUiBlbmNvZGluZyBvZiBZ QU5HIGRhdGEgbW9kZWwgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtY29yZS15YW5nLWNib3IvKQ0KLSBDb0FQIG9wZXJhdGlvbi9mdW5jdGlvbiBzZXQgKGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wvKQ0K LSBZQU5HIGRhdGEgbW9kZWwgZGlzY292ZXJ5IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC12ZWlsbGV0dGUtY29yZS1jb29sLWxpYnJhcnkvKQ0KDQpUaGUgYWx0ZXJuYXRl IGFzc2lnbm1lbnQgYWxnb3JpdGhtIG9mIElEcyBiYXNlZCBvbiBtdXJtdXIzIGFuZCBpbXByb3Zl ZCBkZXNjcmlwdGlvbiB0ZXh0cw0KcHJvcG9zZWQgYnkgQW5keSBpbiAoaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmllcm1hbi1jb3JlLXlpZC8pIGRvbid0IGZ1bmRhbWVu dGFsbHkgY2hhbmdlDQp0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVmaW5lZCBieSB0aGUgU0lE IGRyYWZ0LiBUaGVzZSBwcm9wb3NlZCBpbXByb3ZlbWVudHMgY2FuIGJlIGFkZHJlc3NlZCBkdXJp bmcgdGhlIHJldmlldyBwcm9jZXNzLg0KDQpSZWdhcmRzLA0KTWljaGVsIFZlaWxsZXR0ZQ0KDQpG cm9tOiBBbGV4YW5kZXIgUGVsb3YgW21haWx0bzphQGFja2wuaW9dDQpTZW50OiBUdWVzZGF5LCBB dWd1c3QgMjMsIDIwMTYgNDozNyBBTQ0KVG86IEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6 QGVyaWNzc29uLmNvbT4NCkNjOiBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPjsgZHJh ZnQtc29tYXJhanUtY29yZS1zaWRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBX b3JraW5nIEdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkDQoN CkRlYXIgYWxsLA0KDQpJIHdhbnQgdG8gY29uZmlybSBteSBzdXBwb3J0IGZvciB0aGUgYWRvcHRp b24gb2YgdGhlIGRvY3VtZW50IGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkIChhLmsuYS4gdGhlIFNJ RCBkcmFmdCkuDQoNCkkgZG8gc28gZm9yIHRoZSBmb2xsb3dpbmcgbWFpbiByZWFzb25zOg0KLSBX ZSBuZWVkIGEgd2F5IHRvIHJlcHJlc2VudCBZQU5HIGlkZW50aWZpZXJzIGZvciB0aGUgZHJhZnQt aWV0Zi1jb3JlLXlhbmctY2Jvci4gVGhlIFNJRCBkcmFmdCBwcm92aWRlcyBqdXN0IHRoaXMuIFdl IG11c3QgYWRvcHQgdGhlIGRvY3VtZW50IGlmIHdlIHdhbnQgdG8gbW92ZSBmb3J3YXJkIHdpdGgg dGhlIHdvcmsgb24gdGhpcyBXRyBpdGVtLg0KLSBUaGUgU0lEIGRyYWZ0IGlzIHRoZSByZXN1bHQg b2YgbW9yZSB0aGFuIGEgeWVhciBhbmQgYSBoYWxmIG9mIGRpc2N1c3Npb25zIHdpdGggcGVvcGxl IGZyb20gQ29SRSwgTkVUTU9ELCBJQU5BIGFuZCBvdGhlciBTRE9zLg0KLSBJdCBpcyBhIHN0cmFp Z2h0Zm9yd2FyZCBhbmQgc2ltcGxlIGRvY3VtZW50LCB3aGljaCBwcm92aWRlcyB0aGUgbWluaW1h bCBzdHJ1Y3R1cmUgb24gdG9wIG9mIHdoaWNoIElEcyBjYW4gYmUgYWxsb2NhdGVkLg0KLSBJdCBw cm92aWRlcyBmb3IgYSB3YXkgb2YgaGF2aW5nIG11bHRpcGxlIGluZGVwZW5kZW50IHJlZ2lzdHJp ZXMsIGtlZXBpbmcgYWxsIGludGVyb3BlcmFibGUsIGFuZCByZWxpZXZpbmcgSUFOQSBmcm9tIHRo ZSBuZWVkIHRvIGRvIG92ZXJjb21wbGljYXRlZCwgcGVyLWRldmljZSBhbGxvY2F0aW9ucy4NCi0g UnVubmluZyBjb2RlLiBUaGVyZSBpcyBhIHRvb2wgYW5kIGEgcmVnaXN0cnkgd2hpY2ggYXJlIGFs cmVhZHkgdXNlZCBmb3IgcHJvdG90eXBpbmcuDQoNCg0KVGhlIFNJRCBkcmFmdCBpcyBhaW1lZCBh dDoNCi0gSW50ZXJvcGVyYWJpbGl0eSAoaGF2aW5nIGRldmljZXMgd2l0aCBtb2R1bGVzIGZyb20g ZGlmZmVyZW50IHJlZ2lzdHJpZXMgb24gYSBzaW5nbGUgbmV0d29yaykuDQoNCi0gRnV0dXJlLXBy b29mLiBUaGUgYXV0aG9ycyB1bmRlcnN0YW5kIHRoYXQgdG9kYXkgdGhlcmUgYXJlIGxlc3MgdGhh biAyMDAwIFlBTkcgbW9kdWxlcy4gWWV0LCB0aGUgcmFuZ2VzIHdoaWNoIHdpbGwgYmUgYWxsb2Nh dGVkIGFyZSBGT1JFVkVSLiBUaGlzIG1lYW5zLCB0aGF0IGluIDIwNDYsIHdl4oCZbGwgc3RpbGwg YmUgYWxsb2NhdGluZyBJRHMgZnJvbSB0aGUgcmFuZ2VzIHdlIHByb3ZpZGUgdG9kYXkuIEluZGVw ZW5kZW50bHkgb2YgdGhlIHNpemUgb2YgaWRlbnRpZmllcnMsIGRlbHRhLWVuY29kaW5nIHByb3Zp ZGVzIGZvciB1bHRyYS1lZmZpY2llbnQgZGF0YSB0cmFuc2Zlci4gSG93ZXZlciwgb25jZSB3ZSBt b3ZlIG92ZXIgdGhlIDMyLWJpdCBpZGVudGlmaWVycywgd2XigJlsbCBiZSB0YWtpbmcgYSA4LWJ5 dGUgcGVuYWx0eSBoaXQgcGVyIHJlcXVlc3QuIFRoZSBTSUQgZHJhZnQgcHJvdmlkZXMgZm9yIGEg dmVyeSBzdHJhaWdodGZvcndhcmQgYW5kIHNpbXBsZSB3YXkgb2YgYWxsb2NhdGluZyBibG9ja3Mg b2YgSURzIGFzIG5lY2Vzc2FyeSBmb3IgYSBtb2R1bGUuDQoNCi0gQ29uc3RyYWluZWQtZGV2aWNl IGFuZCBjb25zdHJhaW5lZC1uZXR3b3JrIG9yaWVudGVkIChpZiBuZWVkZWQpIC0gYWZ0ZXIgbW9u dGhzIG9mIGRpc2N1c3Npb25zIHdlIGhhdmUgY29uZmlybWVkIHRoYXQgdGhlIG1vc3QgZWZmaWNp ZW50IHdheSBvZiByZXByZXNlbnRpbmcgdGhlIGRhdGEgaXRlbXMgaXMgd2l0aCBkZWx0YS1lbmNv ZGluZy4gV2hlbiByZXRyaWV2aW5nIG1vcmUgdGhhbiBvbmUgaXRlbSwgdGhlIElEcyB0YWtlIG9u ZSBieXRlIG9uIHRoZSB3aXJlIGluIG1vc3QgY2FzZXMuIFRoZSBhbGxvY2F0aW9uIG9mIElEcyBj YW4gYmUgbWFudWFsLCBhdXRvbWF0aWMsIG9yIG90aGVyIC0gdGhpcyBpcyBub3QgZW5mb3JjZWQu IFdoYXQgdGhlIGRyYWZ0IGVuYWJsZXMgaXMgdGhlIHVzZXJzIHRvIG1ha2UgdXNlIG9mIHRoaXMg dWx0cmEtZWZmaWNpZW50IGlkZW50aWZpZXIgcmVwcmVzZW50YXRpb24gLSBpZiB0aGV5IG5lZWQg aXQuDQogIC0gSWYgbm90IG5lZWRlZCAtIGFuIGFsdGVybmF0aXZlIG1hcHBpbmcgc2NoZW1lIGNh biBiZSB1c2VkLCBlLmcuIHRyYWRpbmcgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdWx0cmEtZWZmaWNp ZW5jeSBmb3IgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4NCg0K DQpJbiBjb25jbHVzaW9uLCB3ZSBuZWVkIHRoZSBTSUQgZHJhZnQgdG8gYmUgYWJsZSB0byBtb3Zl IGZvcndhcmQgd2l0aCBvdXIgV0cgaXRlbSAtIHRoZSBZQU5HLUNCT1IgZHJhZnQuDQoNCkJlc3Qs DQpBbGV4YW5kZXINCg0KRGlzY2xhaW1lcjogSSBhbSBvbmUgb2YgdGhlIGF1dGhvcnMgb2YgdGhl IGRyYWZ0LiBJIGJlbGlldmUgd2UgY291bGQgbWFrZSBhZGp1c3RtZW50cyBhZnRlciB0aGUgYWRv cHRpb24gT1IgZGVjaWRlIHRvIGhhdmUgc3BlY2lmaWMgZHJhZnRzIGZvciBzcGVjaWZpYyB1c2Ut Y2FzZXMsIGJ1dCB3ZSBzaG91bGQgbm90IHNwZW5kIHRvbyBtdWNoIHRpbWUgZ2V0dGluZyBiYWNr LWFuZC1mb3VydGggaW4gY2hhbmdpbmcgdGhlIFdHIGRyYWZ0Lg0KDQoNCkxlIDE1IGFvw7t0IDIw MTYgw6AgMTc6MDYsIEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbTxt YWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+PiBhIMOpY3JpdCA6DQoNCkRlYXIgQ29S RS1XRywNCg0KQXMgd2UgZGlzY3Vzc2VkIGF0IGxhc3QgSUVURjk2LCB3b3JraW5nIGdyb3VwIGFk b3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtc29tYXJhanUtY29yZS1zaWQuIEF0 IHRoZSBJRVRGIG1lZXRpbmcgdGhlIHJvb20gY29uc2Vuc3VzIHdhcyBmb3IgYWRvcHRpb24gKDMg cGVvcGxlKSwgc2luY2Ugbm90IHRvbyBtYW55IHBlb3BsZSBoYWQgcmVhZCB0aGUgZHJhZnQgd2Ug aGF2ZSB0byB0YWtlIGl0IHRvIHRoZSBsaXN0LiBQbGVhc2UgcmVwbHkgd2l0aCB5b3VyIGNvbW1l bnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBub3QgeW91 IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQg dG8gY29tbWVudC4NCg0KU2luY2UgdGhlcmUgYXJlIHNldmVyYWwgY29uY3VycmVudCBXR0EgY2Fs bHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3VzdCAyNiwgMjAxNi4NCg0KVGhhbmtzLA0K SmFpbWUgYW5kIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3Jl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoN Cg== --_000_BN6PR06MB23089B3621DD9CC77AD944A5FEEB0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkkgYWxzbyB3YW50IHRvDQo8L3NwYW4+Y29uZmlybSBteSBzdXBwb3J0IGZvciB0aGUgYWRvcHRp b24gb2YgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNv bWFyYWp1LWNvcmUtc2lkLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt c29tYXJhanUtY29yZS1zaWQvPC9hPikgLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRy YWZ0IGlzIGEgZnVuZGFtZW50YWwgYnVpbGRpbmcgYmxvY2sgZm9yIGJyaW5naW5nIFlBTkcgZGF0 YSBtb2RlbHMgdG8gQ09SRS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgZHJhZnQgaXMgYSBwcmVyZXF1aXNpdGUgZm9yIHRoZSBmb2xsb3dpbmcgd29ya3M6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gQ0JPUiBlbmNvZGluZyBvZiBZQU5HIGRhdGEgbW9kZWwgKDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS15 YW5nLWNib3IvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNv cmUteWFuZy1jYm9yLzwvYT4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IENvQVAgb3BlcmF0aW9uL2Z1bmN0aW9uIHNldCAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtdmVpbGxldHRlLWNvcmUtY29vbC8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wvPC9hPik8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gWUFORyBkYXRhIG1vZGVsIGRpc2NvdmVy eSAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmVpbGxl dHRlLWNvcmUtY29vbC1saWJyYXJ5LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdmVpbGxldHRlLWNvcmUtY29vbC1saWJyYXJ5LzwvYT4pPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBhbHRlcm5hdGUgYXNzaWdubWVudCBhbGdvcml0aG0gb2YgSURzIGJhc2VkIG9u IG11cm11cjMgYW5kIGltcHJvdmVkIGRlc2NyaXB0aW9uIHRleHRzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9wb3NlZCBieSBBbmR5IGluICg8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLWNvcmUteWlkLyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmllcm1hbi1jb3JlLXlpZC88L2E+KSBk b24ndCBmdW5kYW1lbnRhbGx5IGNoYW5nZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+dGhlIHJlZ2lzdHJhdGlvbiBwcm9j ZXNzIGRlZmluZWQgYnkgdGhlIFNJRCBkcmFmdC4gVGhlc2UgcHJvcG9zZWQgaW1wcm92ZW1lbnRz IGNhbiBiZSBhZGRyZXNzZWQgZHVyaW5nIHRoZSByZXZpZXcgcHJvY2Vzcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1p Y2hlbCBWZWlsbGV0dGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g QWxleGFuZGVyIFBlbG92IFttYWlsdG86YUBhY2tsLmlvXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEF1Z3VzdCAyMywgMjAxNiA0OjM3IEFNPGJyPg0KPGI+VG86PC9iPiBKYWltZSBKaW3D qW5leiAmbHQ7amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBj b3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGlldGYub3JnJmd0OzsgZHJhZnQtc29tYXJhanUtY29y ZS1zaWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3lt Ym9sJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4Mjc2Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBX b3JraW5nIEdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhbnQgdG8gY29u ZmlybSBteSBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50IGRyYWZ0LXNv bWFyYWp1LWNvcmUtc2lkIChhLmsuYS4gdGhlIFNJRCBkcmFmdCkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gc28gZm9yIHRoZSBmb2xs b3dpbmcgbWFpbiByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBXZSBuZWVkIGEgd2F5IHRvIHJlcHJlc2VudCBZQU5HIGlkZW50aWZp ZXJzIGZvciB0aGUmbmJzcDtkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLiBUaGUgU0lEIGRyYWZ0 IHByb3ZpZGVzIGp1c3QgdGhpcy4gV2UgbXVzdCBhZG9wdCB0aGUgZG9jdW1lbnQgaWYgd2Ugd2Fu dCB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgd29yayBvbiB0aGlzIFdHIGl0ZW0uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRoZSBTSUQgZHJh ZnQgaXMgdGhlIHJlc3VsdCBvZiBtb3JlIHRoYW4gYSB5ZWFyIGFuZCBhIGhhbGYgb2YgZGlzY3Vz c2lvbnMgd2l0aCBwZW9wbGUgZnJvbSBDb1JFLCBORVRNT0QsIElBTkEgYW5kIG90aGVyIFNET3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEl0 IGlzIGEgc3RyYWlnaHRmb3J3YXJkIGFuZCBzaW1wbGUgZG9jdW1lbnQsIHdoaWNoIHByb3ZpZGVz IHRoZSBtaW5pbWFsIHN0cnVjdHVyZSBvbiB0b3Agb2Ygd2hpY2ggSURzIGNhbiBiZSBhbGxvY2F0 ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IEl0IHByb3ZpZGVzIGZvciBhIHdheSBvZiBoYXZpbmcgbXVsdGlwbGUgaW5kZXBlbmRlbnQgcmVn aXN0cmllcywga2VlcGluZyBhbGwgaW50ZXJvcGVyYWJsZSwgYW5kIHJlbGlldmluZyBJQU5BIGZy b20gdGhlIG5lZWQgdG8gZG8gb3ZlcmNvbXBsaWNhdGVkLCBwZXItZGV2aWNlIGFsbG9jYXRpb25z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBS dW5uaW5nIGNvZGUuIFRoZXJlIGlzIGEgdG9vbCBhbmQgYSByZWdpc3RyeSB3aGljaCBhcmUgYWxy ZWFkeSB1c2VkIGZvciBwcm90b3R5cGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU0lEIGRyYWZ0IGlzIGFpbWVkIGF0 OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJ bnRlcm9wZXJhYmlsaXR5IChoYXZpbmcgZGV2aWNlcyB3aXRoIG1vZHVsZXMgZnJvbSBkaWZmZXJl bnQgcmVnaXN0cmllcyBvbiBhIHNpbmdsZSBuZXR3b3JrKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBGdXR1cmUtcHJvb2YuIFRo ZSBhdXRob3JzIHVuZGVyc3RhbmQgdGhhdCB0b2RheSB0aGVyZSBhcmUgbGVzcyB0aGFuIDIwMDAg WUFORyBtb2R1bGVzLiBZZXQsIHRoZSByYW5nZXMgd2hpY2ggd2lsbCBiZSBhbGxvY2F0ZWQgYXJl IEZPUkVWRVIuIFRoaXMgbWVhbnMsIHRoYXQgaW4gMjA0Niwgd2XigJlsbCBzdGlsbCBiZSBhbGxv Y2F0aW5nIElEcyBmcm9tIHRoZSByYW5nZXMgd2UgcHJvdmlkZSB0b2RheS4gSW5kZXBlbmRlbnRs eQ0KIG9mIHRoZSBzaXplIG9mIGlkZW50aWZpZXJzLCBkZWx0YS1lbmNvZGluZyBwcm92aWRlcyBm b3IgdWx0cmEtZWZmaWNpZW50IGRhdGEgdHJhbnNmZXIuIEhvd2V2ZXIsIG9uY2Ugd2UgbW92ZSBv dmVyIHRoZSAzMi1iaXQgaWRlbnRpZmllcnMsIHdl4oCZbGwgYmUgdGFraW5nIGEgOC1ieXRlIHBl bmFsdHkgaGl0IHBlciByZXF1ZXN0LiBUaGUgU0lEIGRyYWZ0IHByb3ZpZGVzIGZvciBhIHZlcnkg c3RyYWlnaHRmb3J3YXJkIGFuZCBzaW1wbGUgd2F5IG9mDQogYWxsb2NhdGluZyBibG9ja3Mgb2Yg SURzIGFzIG5lY2Vzc2FyeSBmb3IgYSBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIENvbnN0cmFpbmVkLWRldmljZSBh bmQgY29uc3RyYWluZWQtbmV0d29yayBvcmllbnRlZCAoaWYgbmVlZGVkKSAtIGFmdGVyIG1vbnRo cyBvZiBkaXNjdXNzaW9ucyB3ZSBoYXZlIGNvbmZpcm1lZCB0aGF0IHRoZSBtb3N0IGVmZmljaWVu dCB3YXkgb2YgcmVwcmVzZW50aW5nIHRoZSBkYXRhIGl0ZW1zIGlzIHdpdGggZGVsdGEtZW5jb2Rp bmcuIFdoZW4gcmV0cmlldmluZyBtb3JlIHRoYW4gb25lIGl0ZW0sIHRoZQ0KIElEcyB0YWtlIG9u ZSBieXRlIG9uIHRoZSB3aXJlIGluIG1vc3QgY2FzZXMuIFRoZSBhbGxvY2F0aW9uIG9mIElEcyBj YW4gYmUgbWFudWFsLCBhdXRvbWF0aWMsIG9yIG90aGVyIC0gdGhpcyBpcyBub3QgZW5mb3JjZWQu IFdoYXQgdGhlIGRyYWZ0IGVuYWJsZXMgaXMgdGhlIHVzZXJzIHRvIG1ha2UgdXNlIG9mIHRoaXMg dWx0cmEtZWZmaWNpZW50IGlkZW50aWZpZXIgcmVwcmVzZW50YXRpb24gLSBpZiB0aGV5IG5lZWQg aXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAtIElmIG5vdCBuZWVkZWQgLSBhbiBhbHRlcm5hdGl2ZSBtYXBw aW5nIHNjaGVtZSBjYW4gYmUgdXNlZCwgZS5nLiB0cmFkaW5nIGludGVyb3BlcmFiaWxpdHkgYW5k IHVsdHJhLWVmZmljaWVuY3kgZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gY29uY2x1c2lvbiwgd2UgbmVlZCB0aGUgU0lEIGRyYWZ0IHRvIGJlIGFibGUg dG8gbW92ZSBmb3J3YXJkIHdpdGggb3VyIFdHIGl0ZW0gLSB0aGUgWUFORy1DQk9SIGRyYWZ0LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxleGFuZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRpc2NsYWltZXI6IEkgYW0gb25lIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBkcmFm dC4gSSBiZWxpZXZlIHdlIGNvdWxkIG1ha2UgYWRqdXN0bWVudHMgYWZ0ZXIgdGhlIGFkb3B0aW9u IE9SIGRlY2lkZSB0byBoYXZlIHNwZWNpZmljIGRyYWZ0cyBmb3Igc3BlY2lmaWMgdXNlLWNhc2Vz LCBidXQgd2Ugc2hvdWxkIG5vdCBzcGVuZCB0b28gbXVjaCB0aW1lIGdldHRpbmcgYmFjay1hbmQt Zm91cnRoIGluIGNoYW5naW5nDQogdGhlIFdHIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAxNSBhb8O7dCAyMDE2 IMOgIDE3OjA2LCBKYWltZSBKaW3DqW5leiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphaW1lLmppbWVu ZXpAZXJpY3Nzb24uY29tIj5qYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IGEgw6lj cml0IDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIg Q29SRS1XRyw8YnI+DQo8YnI+DQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtp bmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1zb21hcmFqdS1j b3JlLXNpZC4gQXQgdGhlIElFVEYgbWVldGluZyB0aGUgcm9vbSBjb25zZW5zdXMgd2FzIGZvciBh ZG9wdGlvbiAoMyBwZW9wbGUpLCBzaW5jZSBub3QgdG9vIG1hbnkgcGVvcGxlIGhhZCByZWFkIHRo ZSBkcmFmdCB3ZSBoYXZlIHRvIHRha2UgaXQgdG8gdGhlIGxpc3QuJm5ic3A7UGxlYXNlIHJlcGx5 DQogd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8g d2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3Bl Y2lhbGx5Jm5ic3A7ZW5jb3VyYWdlZCB0byBjb21tZW50Ljxicj4NCjxicj4NClNpbmNlIHRoZXJl IGFyZSBzZXZlcmFsIGNvbmN1cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0aGUgY2FsbCBv biA8Yj5BdWd1c3QgMjYsIDIwMTY8L2I+Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpKYWltZSBh bmQgQ2Fyc3RlbiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNv cmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BN6PR06MB23089B3621DD9CC77AD944A5FEEB0BN6PR06MB2308namp_-- From nobody Tue Aug 23 14:37:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2A12DB2B for ; Tue, 23 Aug 2016 14:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV-Eroi39Bxq for ; Tue, 23 Aug 2016 14:37:41 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0125.outbound.protection.outlook.com [104.47.2.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6AC12DB06 for ; Tue, 23 Aug 2016 14:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=LandisGyr.onmicrosoft.com; s=selector1-landisgyr-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Dm1OGdk5vsu3B99GlJmK+P+QyfmBfg/dAfY4ntlh1yY=; b=YY/+pohN1zwixvmiVASvEkSaWl6ScFxgaX5qmSY/5R1Q4/ok2h5Pt8KxqW0Uv798kBD7aQKGkZEvMGGSRmonvQ5Pj0gKCMSFWnTC50ZIjv/TMnjRcFpfwoWNAV3UhzG/viBaypyNtcIm4n6TKhfpGDo/N9tqwjLz9CK3kHH99/g= Received: from DB5PR01MB1815.eurprd01.prod.exchangelabs.com (10.166.168.149) by DB5PR01MB1815.eurprd01.prod.exchangelabs.com (10.166.168.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 23 Aug 2016 21:37:35 +0000 Received: from DB5PR01MB1815.eurprd01.prod.exchangelabs.com ([10.166.168.149]) by DB5PR01MB1815.eurprd01.prod.exchangelabs.com ([10.166.168.149]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 21:37:35 +0000 From: "Turner, Randy" To: Michel Veillette Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-somaraju-core-sid?= Thread-Index: AQHR/X3srYFzO0f/UUmzpLs52RaBYaBXEiOA Date: Tue, 23 Aug 2016 21:37:35 +0000 Message-ID: References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:cb:c000:8248:5da5:f:5cfc:1a91] x-ms-office365-filtering-correlation-id: 7158e8ea-7254-4073-3b40-08d3cb9db27c x-microsoft-exchange-diagnostics: 1; DB5PR01MB1815; 6:ObRU3jxe3HjETz0H6I8H27OHwP6UlYPRi7eLIxUXswSzxMvR3GkBRwIFyAcxvKkWgmvnlPf5sTuxnzmlEsmSAboIaUJabLADJWhfv1GrOONxy4xpzY8+cuwRV7QolGEscCGRnDg2Qg/3UuL/iIUgaMvIHA8CE2fMCF6v9keuLL1SSti1qgG7mnGkqVWAXMwKrUAVrzq6Rm0142XpiEMbVeY1vbsippoUuTAUOXHmHBnj8NqjVTRmRUYtNqt8udyVwTtExmiPj3tPAdoy75am0Emc42WHJRgdy3at2E8Gc58UW0j2Zz2STfVDtit1EnIn70GxL9wxYyDDmW7TepXNgQ==; 5:6pJWqiCJILX3fXWx38lbp5bCg2Zsqk17gZRJKx0cpx/1MRUcIq+T4rA4g4OvWtyeQIswiGiRDBxqG0IbNuwM6AKXRGYbe/0xihpaOQ6Kj/GgU1lOgr3EUSueD4s414vBkIGLT/kLilAuVWavxxM2Yg==; 24:PGr+dZxN7j5iyZ2UJUD+oi6m70OLqE5OEYj3MiI/nT3b2QEbHunbpSkrKP5R8ZEhz4HNkSQ/dhvdQjxH45MpfjIMYzRe21ut19Fj9pGuHC8=; 7:n/eAU5hOfwOTmQiUNxbJGHPQcYjXp/U1flD1sB/ksMXWibNqM93yEQCm20II+liKlcybHND9ECobs8/x8LeyWXhv6CsCDqONn+pjB82jVjKzUVJxLha8kNaoImBiFLsXoNt81r5stCYQG6CUVLBUCB5Cj13jkktHhCQqbcLEHLG6+4QT3CZyHSPcudre9Mtaf+SIB+UXY7i9zOnXwgyRUMJd4kt8sdwbwA0PfZ6UI3RrdpSldtG587jZjXjYbYxl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1815; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DB5PR01MB1815; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1815; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(189002)(377454003)(2906002)(19580405001)(19617315012)(122556002)(7736002)(92566002)(7906003)(33656002)(16236675004)(7846002)(3280700002)(101416001)(4326007)(5660300001)(3660700001)(6116002)(230783001)(68736007)(102836003)(19580395003)(110136002)(8936002)(586003)(189998001)(11100500001)(105586002)(106116001)(97736004)(2950100001)(81156014)(83716003)(15975445007)(77096005)(87936001)(81166006)(229383001)(106356001)(10400500002)(76176999)(50986999)(5002640100001)(2900100001)(36756003)(54356999)(86362001)(82746002)(3826002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1815; H:DB5PR01MB1815.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B5A2347E7F744272920A17E99FE572ADlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 21:37:35.2100 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1815 Archived-At: Cc: "core@ietf. org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 21:37:43 -0000 --_000_B5A2347E7F744272920A17E99FE572ADlandisgyrcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KQ29uZmlybWluZyBzdXBwb3J0IGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zb21hcmFqdS1jb3JlLXNpZA0KDQpUaGlzIGRvY3VtZW50IGlzIHJlcXVpcmVk IGNhcGFiaWxpdHkgZm9yIHJlYWxpemluZyBleHRlbnNpYmxlIG1hbmFnZW1lbnQgZnJhbWV3b3Jr cyBhbmQgcHJvdmlkZXMgdGhlIGJhc2lzDQpmb3IgYSBudW1iZXIgb2Ygb3RoZXIgY29uc3RyYWlu ZWQtZnJpZW5kbHkgdGVjaG5vbG9neSwgaW5jbHVkaW5nIENCT1IgZW5jb2Rpbmcgb2YgWUFORyBt b2RlbHMgYW5kIHJldXNlIG9mIENvQVANCnRvIGNhcnJ5IHRoZXNlIHBheWxvYWRzLiBUaGlzIHdv cmsgaGFzIGJlZW4gZXh0ZW5zaXZlbHkgcmV2aWV3ZWQgYW5kIGRpc2N1c3NlZCBvbiB0aGUgbWFp bGluZyBsaXN0KHMpIGFuZCBhdCBtdWx0aXBsZSBwbGVuYXJpZXMNCmFuZCB0aGUgZGlzcG9zaXRp b24gb2YgdGhpcyB3b3JrIGlzIGNvbnNpZGVyZWQgcmVhZHkgZm9yIGFkb3B0aW9uLg0KDQpCUiwN ClJhbmR5DQoNCg0KT24gQXVnIDIzLCAyMDE2LCBhdCA0OjM1IFBNLCBNaWNoZWwgVmVpbGxldHRl IDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hlbC5WZWlsbGV0 dGVAdHJpbGxpYW50aW5jLmNvbT4+IHdyb3RlOg0KDQorMQ0KDQpJIGFsc28gd2FudCB0byBjb25m aXJtIG15IHN1cHBvcnQgZm9yIHRoZSBhZG9wdGlvbiBvZiAoaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtc29tYXJhanUtY29yZS1zaWQvKSAuDQoNClRoaXMgZHJhZnQgaXMg YSBmdW5kYW1lbnRhbCBidWlsZGluZyBibG9jayBmb3IgYnJpbmdpbmcgWUFORyBkYXRhIG1vZGVs cyB0byBDT1JFLg0KVGhpcyBkcmFmdCBpcyBhIHByZXJlcXVpc2l0ZSBmb3IgdGhlIGZvbGxvd2lu ZyB3b3JrczoNCg0KLSBDQk9SIGVuY29kaW5nIG9mIFlBTkcgZGF0YSBtb2RlbCAoaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci8pDQotIENv QVAgb3BlcmF0aW9uL2Z1bmN0aW9uIHNldCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdmVpbGxldHRlLWNvcmUtY29vbC8pDQotIFlBTkcgZGF0YSBtb2RlbCBkaXNjb3Zl cnkgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZlaWxsZXR0ZS1jb3Jl LWNvb2wtbGlicmFyeS8pDQoNClRoZSBhbHRlcm5hdGUgYXNzaWdubWVudCBhbGdvcml0aG0gb2Yg SURzIGJhc2VkIG9uIG11cm11cjMgYW5kIGltcHJvdmVkIGRlc2NyaXB0aW9uIHRleHRzDQpwcm9w b3NlZCBieSBBbmR5IGluIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i aWVybWFuLWNvcmUteWlkLykgZG9uJ3QgZnVuZGFtZW50YWxseSBjaGFuZ2UNCnRoZSByZWdpc3Ry YXRpb24gcHJvY2VzcyBkZWZpbmVkIGJ5IHRoZSBTSUQgZHJhZnQuIFRoZXNlIHByb3Bvc2VkIGlt cHJvdmVtZW50cyBjYW4gYmUgYWRkcmVzc2VkIGR1cmluZyB0aGUgcmV2aWV3IHByb2Nlc3MuDQoN ClJlZ2FyZHMsDQpNaWNoZWwgVmVpbGxldHRlDQoNCkZyb206IEFsZXhhbmRlciBQZWxvdiBbbWFp bHRvOmFAYWNrbC5pb10NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyMywgMjAxNiA0OjM3IEFNDQpU bzogSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWlt ZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4+DQpDYzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBp ZXRmLm9yZz4gV0cgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PjsgZHJhZnQt c29tYXJhanUtY29yZS1zaWRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lk QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRp b24gY2FsbCBmb3IgZHJhZnQtc29tYXJhanUtY29yZS1zaWQNCg0KRGVhciBhbGwsDQoNCkkgd2Fu dCB0byBjb25maXJtIG15IHN1cHBvcnQgZm9yIHRoZSBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQg ZHJhZnQtc29tYXJhanUtY29yZS1zaWQgKGEuay5hLiB0aGUgU0lEIGRyYWZ0KS4NCg0KSSBkbyBz byBmb3IgdGhlIGZvbGxvd2luZyBtYWluIHJlYXNvbnM6DQotIFdlIG5lZWQgYSB3YXkgdG8gcmVw cmVzZW50IFlBTkcgaWRlbnRpZmllcnMgZm9yIHRoZSBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9y LiBUaGUgU0lEIGRyYWZ0IHByb3ZpZGVzIGp1c3QgdGhpcy4gV2UgbXVzdCBhZG9wdCB0aGUgZG9j dW1lbnQgaWYgd2Ugd2FudCB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgd29yayBvbiB0aGlzIFdH IGl0ZW0uDQotIFRoZSBTSUQgZHJhZnQgaXMgdGhlIHJlc3VsdCBvZiBtb3JlIHRoYW4gYSB5ZWFy IGFuZCBhIGhhbGYgb2YgZGlzY3Vzc2lvbnMgd2l0aCBwZW9wbGUgZnJvbSBDb1JFLCBORVRNT0Qs IElBTkEgYW5kIG90aGVyIFNET3MuDQotIEl0IGlzIGEgc3RyYWlnaHRmb3J3YXJkIGFuZCBzaW1w bGUgZG9jdW1lbnQsIHdoaWNoIHByb3ZpZGVzIHRoZSBtaW5pbWFsIHN0cnVjdHVyZSBvbiB0b3Ag b2Ygd2hpY2ggSURzIGNhbiBiZSBhbGxvY2F0ZWQuDQotIEl0IHByb3ZpZGVzIGZvciBhIHdheSBv ZiBoYXZpbmcgbXVsdGlwbGUgaW5kZXBlbmRlbnQgcmVnaXN0cmllcywga2VlcGluZyBhbGwgaW50 ZXJvcGVyYWJsZSwgYW5kIHJlbGlldmluZyBJQU5BIGZyb20gdGhlIG5lZWQgdG8gZG8gb3ZlcmNv bXBsaWNhdGVkLCBwZXItZGV2aWNlIGFsbG9jYXRpb25zLg0KLSBSdW5uaW5nIGNvZGUuIFRoZXJl IGlzIGEgdG9vbCBhbmQgYSByZWdpc3RyeSB3aGljaCBhcmUgYWxyZWFkeSB1c2VkIGZvciBwcm90 b3R5cGluZy4NCg0KDQpUaGUgU0lEIGRyYWZ0IGlzIGFpbWVkIGF0Og0KLSBJbnRlcm9wZXJhYmls aXR5IChoYXZpbmcgZGV2aWNlcyB3aXRoIG1vZHVsZXMgZnJvbSBkaWZmZXJlbnQgcmVnaXN0cmll cyBvbiBhIHNpbmdsZSBuZXR3b3JrKS4NCg0KLSBGdXR1cmUtcHJvb2YuIFRoZSBhdXRob3JzIHVu ZGVyc3RhbmQgdGhhdCB0b2RheSB0aGVyZSBhcmUgbGVzcyB0aGFuIDIwMDAgWUFORyBtb2R1bGVz LiBZZXQsIHRoZSByYW5nZXMgd2hpY2ggd2lsbCBiZSBhbGxvY2F0ZWQgYXJlIEZPUkVWRVIuIFRo aXMgbWVhbnMsIHRoYXQgaW4gMjA0Niwgd2XigJlsbCBzdGlsbCBiZSBhbGxvY2F0aW5nIElEcyBm cm9tIHRoZSByYW5nZXMgd2UgcHJvdmlkZSB0b2RheS4gSW5kZXBlbmRlbnRseSBvZiB0aGUgc2l6 ZSBvZiBpZGVudGlmaWVycywgZGVsdGEtZW5jb2RpbmcgcHJvdmlkZXMgZm9yIHVsdHJhLWVmZmlj aWVudCBkYXRhIHRyYW5zZmVyLiBIb3dldmVyLCBvbmNlIHdlIG1vdmUgb3ZlciB0aGUgMzItYml0 IGlkZW50aWZpZXJzLCB3ZeKAmWxsIGJlIHRha2luZyBhIDgtYnl0ZSBwZW5hbHR5IGhpdCBwZXIg cmVxdWVzdC4gVGhlIFNJRCBkcmFmdCBwcm92aWRlcyBmb3IgYSB2ZXJ5IHN0cmFpZ2h0Zm9yd2Fy ZCBhbmQgc2ltcGxlIHdheSBvZiBhbGxvY2F0aW5nIGJsb2NrcyBvZiBJRHMgYXMgbmVjZXNzYXJ5 IGZvciBhIG1vZHVsZS4NCg0KLSBDb25zdHJhaW5lZC1kZXZpY2UgYW5kIGNvbnN0cmFpbmVkLW5l dHdvcmsgb3JpZW50ZWQgKGlmIG5lZWRlZCkgLSBhZnRlciBtb250aHMgb2YgZGlzY3Vzc2lvbnMg d2UgaGF2ZSBjb25maXJtZWQgdGhhdCB0aGUgbW9zdCBlZmZpY2llbnQgd2F5IG9mIHJlcHJlc2Vu dGluZyB0aGUgZGF0YSBpdGVtcyBpcyB3aXRoIGRlbHRhLWVuY29kaW5nLiBXaGVuIHJldHJpZXZp bmcgbW9yZSB0aGFuIG9uZSBpdGVtLCB0aGUgSURzIHRha2Ugb25lIGJ5dGUgb24gdGhlIHdpcmUg aW4gbW9zdCBjYXNlcy4gVGhlIGFsbG9jYXRpb24gb2YgSURzIGNhbiBiZSBtYW51YWwsIGF1dG9t YXRpYywgb3Igb3RoZXIgLSB0aGlzIGlzIG5vdCBlbmZvcmNlZC4gV2hhdCB0aGUgZHJhZnQgZW5h YmxlcyBpcyB0aGUgdXNlcnMgdG8gbWFrZSB1c2Ugb2YgdGhpcyB1bHRyYS1lZmZpY2llbnQgaWRl bnRpZmllciByZXByZXNlbnRhdGlvbiAtIGlmIHRoZXkgbmVlZCBpdC4NCiAgLSBJZiBub3QgbmVl ZGVkIC0gYW4gYWx0ZXJuYXRpdmUgbWFwcGluZyBzY2hlbWUgY2FuIGJlIHVzZWQsIGUuZy4gdHJh ZGluZyBpbnRlcm9wZXJhYmlsaXR5IGFuZCB1bHRyYS1lZmZpY2llbmN5IGZvciBjb21wYXRpYmls aXR5IHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLg0KDQoNCkluIGNvbmNsdXNpb24sIHdl IG5lZWQgdGhlIFNJRCBkcmFmdCB0byBiZSBhYmxlIHRvIG1vdmUgZm9yd2FyZCB3aXRoIG91ciBX RyBpdGVtIC0gdGhlIFlBTkctQ0JPUiBkcmFmdC4NCg0KQmVzdCwNCkFsZXhhbmRlcg0KDQpEaXNj bGFpbWVyOiBJIGFtIG9uZSBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQuIEkgYmVsaWV2ZSB3 ZSBjb3VsZCBtYWtlIGFkanVzdG1lbnRzIGFmdGVyIHRoZSBhZG9wdGlvbiBPUiBkZWNpZGUgdG8g aGF2ZSBzcGVjaWZpYyBkcmFmdHMgZm9yIHNwZWNpZmljIHVzZS1jYXNlcywgYnV0IHdlIHNob3Vs ZCBub3Qgc3BlbmQgdG9vIG11Y2ggdGltZSBnZXR0aW5nIGJhY2stYW5kLWZvdXJ0aCBpbiBjaGFu Z2luZyB0aGUgV0cgZHJhZnQuDQoNCg0KTGUgMTUgYW/Du3QgMjAxNiDDoCAxNzowNiwgSmFpbWUg Smltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6 QGVyaWNzc29uLmNvbT4+IGEgw6ljcml0IDoNCg0KRGVhciBDb1JFLVdHLA0KDQpBcyB3ZSBkaXNj dXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVx dWVzdGVkIGZvciBkcmFmdC1zb21hcmFqdS1jb3JlLXNpZC4gQXQgdGhlIElFVEYgbWVldGluZyB0 aGUgcm9vbSBjb25zZW5zdXMgd2FzIGZvciBhZG9wdGlvbiAoMyBwZW9wbGUpLCBzaW5jZSBub3Qg dG9vIG1hbnkgcGVvcGxlIGhhZCByZWFkIHRoZSBkcmFmdCB3ZSBoYXZlIHRvIHRha2UgaXQgdG8g dGhlIGxpc3QuIFBsZWFzZSByZXBseSB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRo b3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4g Tm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KDQpTaW5j ZSB0aGVyZSBhcmUgc2V2ZXJhbCBjb25jdXJyZW50IFdHQSBjYWxscywgd2Ugd2lsbCBlbmQgdGhl IGNhbGwgb24gQXVndXN0IDI2LCAyMDE2Lg0KDQpUaGFua3MsDQpKYWltZSBhbmQgQ2Fyc3Rlbg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBt YWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGll dGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlDQoNCg== --_000_B5A2347E7F744272920A17E99FE572ADlandisgyrcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9E1B22FA438D644EB47C13D2EE7646F3@eurprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KJiM0MzsxDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db25maXJtaW5nIHN1cHBvcnQg Zm9yIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbWFy YWp1LWNvcmUtc2lkIiBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBkb2N1bWVudCBpcyByZXF1aXJlZCBj YXBhYmlsaXR5IGZvciByZWFsaXppbmcgZXh0ZW5zaWJsZSBtYW5hZ2VtZW50IGZyYW1ld29ya3Mg YW5kIHByb3ZpZGVzIHRoZSBiYXNpczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5mb3IgYSBudW1iZXIg b2Ygb3RoZXIgY29uc3RyYWluZWQtZnJpZW5kbHkgdGVjaG5vbG9neSwgaW5jbHVkaW5nIENCT1Ig ZW5jb2Rpbmcgb2YgWUFORyBtb2RlbHMgYW5kIHJldXNlIG9mIENvQVA8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+dG8gY2FycnkgdGhlc2UgcGF5bG9hZHMuIFRoaXMgd29yayBoYXMgYmVlbiBleHRlbnNp dmVseSByZXZpZXdlZCBhbmQgZGlzY3Vzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QocykgYW5kIGF0 IG11bHRpcGxlIHBsZW5hcmllczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hbmQgdGhlIGRpc3Bvc2l0 aW9uIG9mIHRoaXMgd29yayBpcyBjb25zaWRlcmVkIHJlYWR5IGZvciBhZG9wdGlvbi48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJSLDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5SYW5keTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBdWcgMjMsIDIwMTYs IGF0IDQ6MzUgUE0sIE1pY2hlbCBWZWlsbGV0dGUgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoZWwu VmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20iIGNsYXNzPSIiPk1pY2hlbC5WZWlsbGV0dGVAdHJp bGxpYW50aW5jLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPiYjNDM7MTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPkkgYWxzbyB3YW50IHRvPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5jb25maXJtIG15IHN1cHBvcnQgZm9yIHRo ZSBhZG9wdGlvbiBvZiAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtc29tYXJhanUtY29yZS1zaWQvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zb21hcmFqdS1jb3JlLXNpZC88L2E+KQ0KIC48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhpcyBkcmFmdCBpcyBhIGZ1bmRhbWVudGFsIGJ1 aWxkaW5nIGJsb2NrIGZvciBicmluZ2luZyBZQU5HIGRhdGEgbW9kZWxzIHRvIENPUkUuPG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQpUaGlzIGRyYWZ0IGlzIGEgcHJlcmVxdWlzaXRlIGZvciB0aGUgZm9sbG93 aW5nIHdvcmtzOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQot IENCT1IgZW5jb2Rpbmcgb2YgWUFORyBkYXRhIG1vZGVsICg8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci88L2E+ KTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KLSBDb0FQIG9wZXJhdGlvbi9mdW5jdGlvbiBzZXQgKDxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZlaWxsZXR0ZS1jb3Jl LWNvb2wvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12ZWlsbGV0 dGUtY29yZS1jb29sLzwvYT4pPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQotIFlBTkcgZGF0YSBtb2RlbCBk aXNjb3ZlcnkgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXZlaWxsZXR0ZS1jb3JlLWNvb2wtbGlicmFyeS8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wtbGlicmFyeS88L2E+KTxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpUaGUgYWx0ZXJuYXRlIGFzc2ln bm1lbnQgYWxnb3JpdGhtIG9mIElEcyBiYXNlZCBvbiBtdXJtdXIzIGFuZCBpbXByb3ZlZCBkZXNj cmlwdGlvbiB0ZXh0czxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KcHJvcG9zZWQgYnkgQW5keSBpbiAoPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmllcm1hbi1jb3Jl LXlpZC8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi IGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4t Y29yZS15aWQvPC9hPikgZG9uJ3QgZnVuZGFtZW50YWxseSBjaGFuZ2U8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPnRoZSByZWdpc3RyYXRpb24gcHJvY2Vz cyBkZWZpbmVkIGJ5IHRoZSBTSUQgZHJhZnQuIFRoZXNlIHByb3Bvc2VkIGltcHJvdmVtZW50cyBj YW4gYmUgYWRkcmVzc2VkIGR1cmluZyB0aGUgcmV2aWV3IHByb2Nlc3MuPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+UmVnYXJkcyw8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5N aWNoZWwgVmVpbGxldHRlPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7 IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsgYm9yZGVyLXRvcC13aWR0aDog MXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFsZXhhbmRlciBQZWxvdiBbPGEgaHJlZj0ibWFp bHRvOmFAYWNrbC5pbyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOmFAYWNrbC5pbzwvYT5dPHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5UdWVzZGF5LCBBdWd1c3QgMjMsIDIwMTYgNDozNyBBTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+SmFpbWUgSmltw6luZXogJmx0OzxhIGhyZWY9Im1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgY2xhc3M9IiI+amFpbWUuamltZW5lekBlcmljc3Nvbi5jb208L2E+Jmd0OzxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNvcmVAaWV0 Zi5vcmc8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PldHICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Y29yZUBpZXRmLm9yZzwv YT4mZ3Q7OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZHJhZnQtc29tYXJhanUtY29yZS1zaWRAaWV0Zi5vcmciIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmRyYWZ0 LXNvbWFyYWp1LWNvcmUtc2lkQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5SZTogW2NvcmVdPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog J1NlZ29lIFVJIFN5bWJvbCcsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj7wn5SUPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPldvcmtpbmcNCiBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1zb21hcmFqdS1jb3Jl LXNpZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCkRlYXIgYWxsLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSSB3 YW50IHRvIGNvbmZpcm0gbXkgc3VwcG9ydCBmb3IgdGhlIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVu dCBkcmFmdC1zb21hcmFqdS1jb3JlLXNpZCAoYS5rLmEuIHRoZSBTSUQgZHJhZnQpLjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpJIGRvIHNvIGZvciB0aGUgZm9sbG93aW5nIG1h aW4gcmVhc29uczo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCi0g V2UgbmVlZCBhIHdheSB0byByZXByZXNlbnQgWUFORyBpZGVudGlmaWVycyBmb3IgdGhlJm5ic3A7 ZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci4gVGhlIFNJRCBkcmFmdCBwcm92aWRlcyBqdXN0IHRo aXMuIFdlIG11c3QgYWRvcHQgdGhlIGRvY3VtZW50IGlmIHdlIHdhbnQgdG8gbW92ZSBmb3J3YXJk IHdpdGggdGhlIHdvcmsgb24gdGhpcyBXRyBpdGVtLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KLSBUaGUgU0lEIGRyYWZ0IGlzIHRoZSByZXN1bHQgb2YgbW9yZSB0 aGFuIGEgeWVhciBhbmQgYSBoYWxmIG9mIGRpc2N1c3Npb25zIHdpdGggcGVvcGxlIGZyb20gQ29S RSwgTkVUTU9ELCBJQU5BIGFuZCBvdGhlciBTRE9zLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KLSBJdCBpcyBhIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgc2ltcGxlIGRv Y3VtZW50LCB3aGljaCBwcm92aWRlcyB0aGUgbWluaW1hbCBzdHJ1Y3R1cmUgb24gdG9wIG9mIHdo aWNoIElEcyBjYW4gYmUgYWxsb2NhdGVkLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KLSBJdCBwcm92aWRlcyBmb3IgYSB3YXkgb2YgaGF2aW5nIG11bHRpcGxlIGlu ZGVwZW5kZW50IHJlZ2lzdHJpZXMsIGtlZXBpbmcgYWxsIGludGVyb3BlcmFibGUsIGFuZCByZWxp ZXZpbmcgSUFOQSBmcm9tIHRoZSBuZWVkIHRvIGRvIG92ZXJjb21wbGljYXRlZCwgcGVyLWRldmlj ZSBhbGxvY2F0aW9ucy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N Ci0gUnVubmluZyBjb2RlLiBUaGVyZSBpcyBhIHRvb2wgYW5kIGEgcmVnaXN0cnkgd2hpY2ggYXJl IGFscmVhZHkgdXNlZCBmb3IgcHJvdG90eXBpbmcuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KVGhlIFNJRCBkcmFmdCBpcyBhaW1lZCBhdDo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCi0gSW50ZXJvcGVyYWJpbGl0eSAoaGF2aW5nIGRldmljZXMg d2l0aCBtb2R1bGVzIGZyb20gZGlmZmVyZW50IHJlZ2lzdHJpZXMgb24gYSBzaW5nbGUgbmV0d29y aykuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCi0gRnV0dXJlLXBy b29mLiBUaGUgYXV0aG9ycyB1bmRlcnN0YW5kIHRoYXQgdG9kYXkgdGhlcmUgYXJlIGxlc3MgdGhh biAyMDAwIFlBTkcgbW9kdWxlcy4gWWV0LCB0aGUgcmFuZ2VzIHdoaWNoIHdpbGwgYmUgYWxsb2Nh dGVkIGFyZSBGT1JFVkVSLiBUaGlzIG1lYW5zLCB0aGF0IGluIDIwNDYsIHdl4oCZbGwgc3RpbGwg YmUgYWxsb2NhdGluZyBJRHMgZnJvbSB0aGUgcmFuZ2VzIHdlIHByb3ZpZGUgdG9kYXkuIEluZGVw ZW5kZW50bHkgb2YgdGhlIHNpemUNCiBvZiBpZGVudGlmaWVycywgZGVsdGEtZW5jb2RpbmcgcHJv dmlkZXMgZm9yIHVsdHJhLWVmZmljaWVudCBkYXRhIHRyYW5zZmVyLiBIb3dldmVyLCBvbmNlIHdl IG1vdmUgb3ZlciB0aGUgMzItYml0IGlkZW50aWZpZXJzLCB3ZeKAmWxsIGJlIHRha2luZyBhIDgt Ynl0ZSBwZW5hbHR5IGhpdCBwZXIgcmVxdWVzdC4gVGhlIFNJRCBkcmFmdCBwcm92aWRlcyBmb3Ig YSB2ZXJ5IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgc2ltcGxlIHdheSBvZiBhbGxvY2F0aW5nIGJsb2Nr cw0KIG9mIElEcyBhcyBuZWNlc3NhcnkgZm9yIGEgbW9kdWxlLjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KLSBDb25zdHJhaW5lZC1kZXZpY2UgYW5k IGNvbnN0cmFpbmVkLW5ldHdvcmsgb3JpZW50ZWQgKGlmIG5lZWRlZCkgLSBhZnRlciBtb250aHMg b2YgZGlzY3Vzc2lvbnMgd2UgaGF2ZSBjb25maXJtZWQgdGhhdCB0aGUgbW9zdCBlZmZpY2llbnQg d2F5IG9mIHJlcHJlc2VudGluZyB0aGUgZGF0YSBpdGVtcyBpcyB3aXRoIGRlbHRhLWVuY29kaW5n LiBXaGVuIHJldHJpZXZpbmcgbW9yZSB0aGFuIG9uZSBpdGVtLCB0aGUgSURzIHRha2Ugb25lIGJ5 dGUgb24NCiB0aGUgd2lyZSBpbiBtb3N0IGNhc2VzLiBUaGUgYWxsb2NhdGlvbiBvZiBJRHMgY2Fu IGJlIG1hbnVhbCwgYXV0b21hdGljLCBvciBvdGhlciAtIHRoaXMgaXMgbm90IGVuZm9yY2VkLiBX aGF0IHRoZSBkcmFmdCBlbmFibGVzIGlzIHRoZSB1c2VycyB0byBtYWtlIHVzZSBvZiB0aGlzIHVs dHJhLWVmZmljaWVudCBpZGVudGlmaWVyIHJlcHJlc2VudGF0aW9uIC0gaWYgdGhleSBuZWVkIGl0 LiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDsgLSBJZiBub3QgbmVlZGVkIC0gYW4gYWx0ZXJuYXRpdmUgbWFwcGluZyBzY2hlbWUg Y2FuIGJlIHVzZWQsIGUuZy4gdHJhZGluZyBpbnRlcm9wZXJhYmlsaXR5IGFuZCB1bHRyYS1lZmZp Y2llbmN5IGZvciBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkluIGNvbmNsdXNpb24sIHdlIG5lZWQgdGhlIFNJ RCBkcmFmdCB0byBiZSBhYmxlIHRvIG1vdmUgZm9yd2FyZCB3aXRoIG91ciBXRyBpdGVtIC0gdGhl IFlBTkctQ0JPUiBkcmFmdC4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KQmVzdCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkFsZXhh bmRlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpEaXNjbGFpbWVyOiBJIGFt IG9uZSBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQuIEkgYmVsaWV2ZSB3ZSBjb3VsZCBtYWtl IGFkanVzdG1lbnRzIGFmdGVyIHRoZSBhZG9wdGlvbiBPUiBkZWNpZGUgdG8gaGF2ZSBzcGVjaWZp YyBkcmFmdHMgZm9yIHNwZWNpZmljIHVzZS1jYXNlcywgYnV0IHdlIHNob3VsZCBub3Qgc3BlbmQg dG9vIG11Y2ggdGltZSBnZXR0aW5nIGJhY2stYW5kLWZvdXJ0aCBpbiBjaGFuZ2luZyB0aGUgV0cg ZHJhZnQuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCkxlIDE1IGFvw7t0IDIwMTYgw6AgMTc6MDYsIEphaW1lIEppbcOpbmV6ICZsdDs8YSBocmVm PSJtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmphaW1lLmppbWVuZXpAZXJp Y3Nzb24uY29tPC9hPiZndDsgYSDDqWNyaXQgOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K RGVhciBDb1JFLVdHLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHdlIGRpc2N1c3Nl ZCBhdCBsYXN0IElFVEY5Niwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0 ZWQgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkLiBBdCB0aGUgSUVURiBtZWV0aW5nIHRoZSBy b29tIGNvbnNlbnN1cyB3YXMgZm9yIGFkb3B0aW9uICgzIHBlb3BsZSksIHNpbmNlIG5vdCB0b28g bWFueSBwZW9wbGUgaGFkIHJlYWQgdGhlIGRyYWZ0IHdlIGhhdmUgdG8gdGFrZSBpdCB0byB0aGUg bGlzdC4mbmJzcDtQbGVhc2UgcmVwbHkNCiB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBh bHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlv bi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkmbmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2luY2UgdGhlcmUgYXJlIHNldmVyYWwgY29u Y3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uPHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPkF1Z3VzdCAyNiwg MjAxNjwvYj4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzLDxiciBjbGFzcz0i Ij4NCkphaW1lIGFuZCBDYXJzdGVuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KY29yZSBtYWlsaW5nIGxpc3Q8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Y29yZUBpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZTwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5j b3JlDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5jb3JlQGlldGYub3JnPC9h PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B5A2347E7F744272920A17E99FE572ADlandisgyrcom_-- From nobody Tue Aug 23 23:39:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6859212D681 for ; Tue, 23 Aug 2016 23:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSXTEeeE2aRW for ; Tue, 23 Aug 2016 23:39:51 -0700 (PDT) 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 D7A8D12D0EC for ; Tue, 23 Aug 2016 23:39:50 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.207]) by smtp-cloud3.xs4all.net with ESMTP id aufn1t00M4U4Moq01ufncw; Wed, 24 Aug 2016 08:39:48 +0200 Received: from 2001:983:a264:1:f8de:e1e1:ad32:4b17 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 24 Aug 2016 08:39:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 24 Aug 2016 08:39:47 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> Message-ID: <086a18a750b073efaf5fc42c47273d37@xs4all.nl> X-Sender: stokcons@xs4all.nl (R7NRUkRYc/LwBzB78ssIbivuMRF01ADX) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 06:39:53 -0000 Some comments based on the arguments below: > This draft is a prerequisite for the following works: > > - CBOR encoding of YANG data model > (https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/) I have argued already for some time that the text about SIDs does not belong in the yang to cbor draft. It reduces its independence from the CoMI work. Given that CBOR is not to be changed, Putting the SID text in a content format draft seems more appropriate. > > The alternate assignment algorithm of IDs based on murmur3 and > improved description texts proposed by Andy in > (https://datatracker.ietf.org/doc/draft-bierman-core-yid/) don't > fundamentally change the registration process defined by the SID draft. I should like to wait till this agreement is visible on this mailing list. Peter From nobody Wed Aug 24 00:57:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A4128E18 for ; Wed, 24 Aug 2016 00:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8qOwapUWIKO for ; Wed, 24 Aug 2016 00:57:14 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825A112B015 for ; Wed, 24 Aug 2016 00:57:14 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:18fb:9ee9:cee6:495e] (unknown [IPv6:2001:660:7301:3728:18fb:9ee9:cee6:495e]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id EA886A80D7; Wed, 24 Aug 2016 09:57:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: <086a18a750b073efaf5fc42c47273d37@xs4all.nl> Date: Wed, 24 Aug 2016 09:57:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <966138C9-ED80-4876-9A60-5C58B0CAFE17@ackl.io> References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> <086a18a750b073efaf5fc42c47273d37@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 07:57:18 -0000 Dear Peter, > Le 24 ao=C3=BBt 2016 =C3=A0 08:39, peter van der Stok = a =C3=A9crit : >=20 > Some comments based on the arguments below: >=20 >> This draft is a prerequisite for the following works: >> - CBOR encoding of YANG data model >> (https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/) > I have argued already for some time that the text about SIDs does not = belong in the yang to cbor draft. > It reduces its independence from the CoMI work. > Given that CBOR is not to be changed, Putting the SID text in a = content format draft seems more appropriate. There are two types of identifiers supported by = draft-ietf-core-yang-cbor - textual (for full compatibility with = RESTConf/NETCONF names) and delta-encoded integers (a.k.a. SIDs). The = former could be used when network constraints are not so stringent, = while the latter is the preferred way of using this encoding in = constrained networks. We should keep it simple. Having several content formats to express the = same thing - especially when this is not necessary - is adding = complexity for no reason.=20 The SID draft allows for having ranges of SIDs be managed by independent = registries and have different rules of assignment. No need to use = different Content Formats necessary to solve overlapping of the integer = values. Moreover, as of the time of this writing, we have 3 different = Content-Formats for the CoOL/CoMI draft. Adding an alternative = Content-Format for the interpretation of the integers would multiply = this by 2, e.g. 6 content formats, where half are doing the same thing. If you have a server with mixed modules (e.g. ones using SID and ones = using a different interpretation of the IDs), the Content-Format will = force you to chose ONE or ANOTHER. There is no possibility in one = request to read or write values from different modules. This effectively = removes all interoperability between the two, making one of the two = redundant.=20 Best, Alexander >> The alternate assignment algorithm of IDs based on murmur3 and >> improved description texts proposed by Andy in >> (https://datatracker.ietf.org/doc/draft-bierman-core-yid/) don't >> fundamentally change the registration process defined by the SID = draft. >=20 > I should like to wait till this agreement is visible on this mailing = list. >=20 > Peter >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 24 03:16:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A14512D8C1 for ; Wed, 24 Aug 2016 03:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JslXWdIV1yar for ; Wed, 24 Aug 2016 03:16:06 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 86C1B12D8BA for ; Wed, 24 Aug 2016 03:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1472033764; d=isode.com; s=june2016; i=@isode.com; bh=VxeXQlzfq2J5Ndm1eOrZH/TAWC8OjZZY5gFEws+AWLI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=C6pok1HOvOrYIqYnVg5gd3MtMHgx/0t8xFXRl9Vd2ci2B7HJ18ASb6A7QdbSYWZ7XrCNEG dARvZyKvOmVgnUWU5MZYsp3qiGQqHsrSNJ5TihpO5AMOrypNqWf97WsYbJO3BT3vgV0EsO b1A6RPf8kl8fH92SmUl3f50+GCNi4Ho=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 24 Aug 2016 11:16:04 +0100 From: Alexey Melnikov To: alexey.melnikov@isode.com, core@ietf.org Message-ID: <85eb8b69-eb5e-c380-18cf-09569272cc92@isode.com> Date: Wed, 24 Aug 2016 11:15:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [core] AD review of draft-ietf-core-etch-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:16:08 -0000 I think the document reads well and I only have a few minor comments. Please address them (or at least discuss them) before the end of IETF Last Call, which I am going to start now: I think response code 4.15 should be mentioned in Section 2 and not just in the IANA Considerations section. I am generally missing Error handling section for the FETCH method, similarly to what you have for PATCH/iPATCH. draft-hartke-core-apps-03 is mentioned several times in the document. It is currently expired. What is the plan with getting it finished? Nit: It looks like RFC 6902 and RFC 7396 should be Normative (IANA Registrations). Obsolete reference: RFC 2616. You also need to update section references you use when referencing RFC 2616 to point to the correct section and RFC from the latest HTTP/1.1 set of RFCs. Best Regards, Alexey From nobody Wed Aug 24 03:34:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8470212DC1F for ; Wed, 24 Aug 2016 03:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeJXNEDXX0sS for ; Wed, 24 Aug 2016 03:34:40 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2AE12DB85 for ; Wed, 24 Aug 2016 03:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1472034879; d=isode.com; s=june2016; i=@isode.com; bh=1chFSzWEA3+zB2mDvmtHJEPZGsZKv9iqCr6jPyL7rqk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=S7d8sdNRtRfPjCmnlM3Mi3JWmLe1jHtj1VZfYvbyOGR6SAIlMdCxsd9fXQetb7LX15flZ5 w7i/JE6zthYTbMwg/UZUch/fZrMDEh+4fJ/n5VXINmTAdgQNILO0CtSNKqFf47XtuXKdci m4USKflCyjKOw45a5tAEdBOc7E1K/jE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 24 Aug 2016 11:34:39 +0100 To: core@ietf.org References: <85eb8b69-eb5e-c380-18cf-09569272cc92@isode.com> From: Alexey Melnikov Message-ID: <10e79457-7da0-f642-9d92-c35a91da10a2@isode.com> Date: Wed, 24 Aug 2016 11:34:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <85eb8b69-eb5e-c380-18cf-09569272cc92@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] AD review of draft-ietf-core-etch-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:34:41 -0000 On 24/08/2016 11:15, Alexey Melnikov wrote: > Obsolete reference: RFC 2616. You also need to update section > references you use when referencing RFC 2616 to point to the correct > section and RFC from the latest HTTP/1.1 set of RFCs. I now saw some text about this in the shepherding write-up, sorry for not checking earlier. I will try to find out if there is a better reference here. From nobody Wed Aug 24 06:13:28 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4312DD1A; Wed, 24 Aug 2016 06:13:26 -0700 (PDT) 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: 6.30.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> Date: Wed, 24 Aug 2016 06:13:26 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 13:13:26 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-09-07. 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 existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-etch/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-etch/ballot/ No IPR declarations have been submitted directly on this I-D. The document has a reference to obsolete RFC 2616, this is intentional. From nobody Wed Aug 24 06:20:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9C12DD3B; Wed, 24 Aug 2016 06:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7qSC-WqjHcG; Wed, 24 Aug 2016 06:20:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0688F12DD2F; Wed, 24 Aug 2016 06:20:22 -0700 (PDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6B7CD476EE; Wed, 24 Aug 2016 09:20:21 -0400 (EDT) From: "Marc Blanchet" To: draft-ietf-core-etch@ietf.org Date: Wed, 24 Aug 2016 09:20:20 -0400 Message-ID: <0FE3CCA5-B148-4F91-8A1E-0E21FB3CCCBB@viagenie.ca> In-Reply-To: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> References: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: core-chairs@ietf.org, core@ietf.org Subject: Re: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 13:20:24 -0000 Hello, found strange the abstract below. On 24 Aug 2016, at 9:13, The IESG wrote: > The IESG has received a request from the Constrained RESTful Environments > WG (core) to consider the following document: > - 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-09-07. 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 existing Constrained Application Protocol (CoAP) methods only > allow access to a complete resource, not to parts of a resource. In > case of resources with larger or complex data, or in situations where > a resource continuity is required, replacing or requesting the whole > resource is undesirable. Several applications using CoAP will need > to perform partial resource accesses. > > Similar to HTTP, the existing Constrained Application Protocol (CoAP) > GET method only allows the specification of a URI and request > parameters in CoAP options, not the transfer of a request payload > detailing the request. This leads to some applications to using POST s/POST/GET/ or do I need more coffee? Marc. > where actually a cacheable, idempotent, safe request is desired. > > Again similar to HTTP, the existing Constrained Application Protocol > (CoAP) PUT method only allows to replace a complete resource. This > also leads applications to use POST where actually a cacheable, > possibly idempotent request is desired. > > This specification adds new CoAP methods, FETCH, to perform the > equivalent of a GET with a request body; and the twin methods PATCH > and iPATCH, to modify parts of a CoAP resource. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-core-etch/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-core-etch/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > The document has a reference to obsolete RFC 2616, this is intentional. From nobody Wed Aug 24 07:41:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AC712D957 for ; Wed, 24 Aug 2016 07:41:13 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1t8NDnQbM5W for ; Wed, 24 Aug 2016 07:41:09 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0105.outbound.protection.outlook.com [104.47.34.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1172312DDD8 for ; Wed, 24 Aug 2016 07:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cA3ngMXKQQRtGCU0U/DY3zTokwDjqmk6aPK1DaRLvM0=; b=g4L5w3WwRbkWe7HyHJt4YmXIUwd6+5idjwuBejdyoxJf+dVPy5qrqdLEszX5DhLiTkGOWoS0N43V8+9Zc3jksruqp6rd6q1gHhH02XXXjO1fRg5icIPyGXBWvh4btlQblAQgXHskNxKSRAGhhkOtceuzetVN+oDIgjY0/mYuzNQ= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 14:38:47 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 14:38:47 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-somaraju-core-sid?= Thread-Index: AQHR/dJRCeCuOrNlc0O8kJrFPtDMi6BYLC+A Date: Wed, 24 Aug 2016 14:38:46 +0000 Message-ID: References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> <086a18a750b073efaf5fc42c47273d37@xs4all.nl> In-Reply-To: <086a18a750b073efaf5fc42c47273d37@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: ef1a859b-5455-4f56-ff1d-08d3cc2c5b70 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 6:cl6TI/syo5pd+ib7PYWV7urf88rZ/oDEJDE078buLwxcrzyiL49g0plCBW+vyjNkgtDpktj6e/QNRJQhhuvj4rqeUyJfwcTsd7HpBp5oaCSTLZE+UtJYmk8BXMi0qAw8oByTlBJj51ad0uuip9RS6N1+nOyI0c40LAeoYuqbUGXgtZE86zYBfkujj91HC94EgQXFqXRV2x+w/Y6iL0lLb5oA64ylu1Q007tftIJapvAV7Ba730wXkiND4u34/6ns/we3kW2MPrUDlkdOBsx4PIfT15td22mnmmO53mHB3CY=; 5:CY2xMkM6Pr2jALi7NN53agEiq7CQ6C3Nngj1ldjm8bI41nSjCjYkfGbL52dfmmbxxzrAwP6KWbAaFdkLSA0Qk17UT312BTs/JrL6ZDHvaGtTrHzUqV4tIWqrorZsR6T7I4F+sAyZK2rXKhIt/1PW/w==; 24:U6brRgJ9OOnR8juK5K3W5jjfZcnD18qwoG2G6JvFnBckL8ttHyC+fDHJ2eFVUqe+NV7Vn7tDy9llY7qadvopWnSz8iT4woq2hCtYH0sWeVo=; 7:tYC3L2EWqn+q/O7157UM8chPWpWstNOwp9Vm7Owu0Uzu/52dowWtUtdxtXMJKCq2TifaVhAS5ibKr/5sv2dRxJj9MClvGZnuesa61GitAKmfnyeJvS3C80IgeqORktRgYO8rvyIWIAuDNFwZMmkhZ1Oru8kXmVNQ/2GhzEkQ1HJ+F68UU/jRdcAgx3d51R7lCmYN8RZSwM8B846LlVBmKg8TIZ1NRNfQItSggiOvzevQ/IKp1LmURqLe9O4ATpSE x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2305; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(13464003)(7736002)(5640700001)(305945005)(7846002)(81156014)(77096005)(1730700003)(122556002)(81166006)(74316002)(15975445007)(106356001)(8936002)(229383001)(2950100001)(87936001)(19580395003)(106116001)(68736007)(105586002)(2900100001)(9686002)(76576001)(50986999)(7696003)(10400500002)(101416001)(2351001)(66066001)(93886004)(6116002)(2906002)(4326007)(2501003)(92566002)(102836003)(110136002)(5660300001)(76176999)(230783001)(97736004)(3660700001)(3846002)(54356999)(586003)(33656002)(11100500001)(189998001)(19580405001)(86362001)(5002640100001)(3280700002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 14:38:46.8716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 14:41:14 -0000 SGkgUGV0ZXINCg0KV2hhdCBkbyB5b3UgbWVhbnMgYnkgImNvbnRlbnQgZm9ybWF0IGRyYWZ0Ij8N CklzIGl0IHNvbWV0aGluZyBkaWZmZXJlbnQgdGhhbiAiZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jv ciI/DQpBbmQgaWYgc28sIGhvdyBkbyB3ZSBtYWtlIHRoZSBzcGxpdD8NCg0KVGhlIGN1cnJlbnQg d29yayBpcyBiYXNlZCBvbiB0aGUgc2FtZSBhcHByb2FjaCB1c2VkIGJ5IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC15YW5nLWpzb24tMTAuDQpJbiBkcmFmdC1p ZXRmLW5ldG1vZC15YW5nLWpzb24sIG5hbWluZyBpcyBmdWxseSBkZWZpbmVkLg0KSWYgdGhpcyBp cyBub3QgZG9uZSwgd2Ugd29u4oCZdCBiZSBhYmxlIHRvIGRlZmluZSB0aGUgbWFwcGluZyBvZiB0 aGUgZm9sbG93aW5nIGluc3RhbmNlcyBhbmQgZGF0YXR5cGVzOiBjb250YWluZXIsIGxpc3QsIGlk ZW50aXR5cmVmICwgaW5zdGFuY2UtaWRlbnRpZmllci4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGV0ZXIgdmFuIGRlciBTdG9rIFttYWls dG86c3Rva2NvbnNAeHM0YWxsLm5sXSANClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI0LCAyMDE2 IDI6NDAgQU0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dGluYy5jb20+DQpDYzogSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29t PjsgY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g 8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUt c2lkDQoNClNvbWUgY29tbWVudHMgYmFzZWQgb24gdGhlIGFyZ3VtZW50cyBiZWxvdzoNCg0KPiBU aGlzIGRyYWZ0IGlzIGEgcHJlcmVxdWlzaXRlIGZvciB0aGUgZm9sbG93aW5nIHdvcmtzOg0KPiAN Cj4gLSBDQk9SIGVuY29kaW5nIG9mIFlBTkcgZGF0YSBtb2RlbA0KPiAoaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci8pDQpJIGhhdmUgYXJn dWVkIGFscmVhZHkgZm9yIHNvbWUgdGltZSB0aGF0IHRoZSB0ZXh0IGFib3V0IFNJRHMgZG9lcyBu b3QgYmVsb25nIGluIHRoZSB5YW5nIHRvIGNib3IgZHJhZnQuDQpJdCByZWR1Y2VzIGl0cyBpbmRl cGVuZGVuY2UgZnJvbSB0aGUgQ29NSSB3b3JrLg0KR2l2ZW4gdGhhdCBDQk9SIGlzIG5vdCB0byBi ZSBjaGFuZ2VkLCBQdXR0aW5nIHRoZSBTSUQgdGV4dCBpbiBhIGNvbnRlbnQgZm9ybWF0IGRyYWZ0 IHNlZW1zIG1vcmUgYXBwcm9wcmlhdGUuDQo+IA0KPiBUaGUgYWx0ZXJuYXRlIGFzc2lnbm1lbnQg YWxnb3JpdGhtIG9mIElEcyBiYXNlZCBvbiBtdXJtdXIzIGFuZCANCj4gaW1wcm92ZWQgZGVzY3Jp cHRpb24gdGV4dHMgIHByb3Bvc2VkIGJ5IEFuZHkgaW4NCj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tY29yZS15aWQvKSBkb24ndCANCj4gZnVuZGFtZW50 YWxseSBjaGFuZ2UgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlZmluZWQgYnkgdGhlIFNJRCBk cmFmdC4NCg0KSSBzaG91bGQgbGlrZSB0byB3YWl0IHRpbGwgdGhpcyBhZ3JlZW1lbnQgaXMgdmlz aWJsZSBvbiB0aGlzIG1haWxpbmcgbGlzdC4NCg0KUGV0ZXINCg== From nobody Wed Aug 24 08:51:11 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2281812D0FF for ; Wed, 24 Aug 2016 08:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZEb9FTJqYlj for ; Wed, 24 Aug 2016 08:51:08 -0700 (PDT) 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 46F8512DE82 for ; Wed, 24 Aug 2016 08:44:59 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud6.xs4all.net with ESMTP id b3kv1t00B4h15BW013kvBV; Wed, 24 Aug 2016 17:44:55 +0200 Received: from 2001:983:a264:1:6846:4325:6a4f:d4bb by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 24 Aug 2016 17:44:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 24 Aug 2016 17:44:55 +0200 From: peter van der Stok To: Marc Blanchet Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0FE3CCA5-B148-4F91-8A1E-0E21FB3CCCBB@viagenie.ca> References: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> <0FE3CCA5-B148-4F91-8A1E-0E21FB3CCCBB@viagenie.ca> Message-ID: X-Sender: stokcons@xs4all.nl (LmaQrICdHIed9uUW4bITwSYUCEEP1V/m) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: Re: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 15:51:09 -0000 >> >> Similar to HTTP, the existing Constrained Application Protocol >> (CoAP) >> GET method only allows the specification of a URI and request >> parameters in CoAP options, not the transfer of a request payload >> detailing the request. This leads to some applications to using >> POST > > s/POST/GET/ or do I need more coffee? > > Marc. > May be something stronger? My apologies, I hope this is a copy/paste confusion coming from a lack of coffee. Peter From nobody Wed Aug 24 09:32:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3A12D104; Wed, 24 Aug 2016 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAgu4LuGxBPE; Wed, 24 Aug 2016 09:32:19 -0700 (PDT) Received: from homiemail-a59.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2E0127735; Wed, 24 Aug 2016 09:32:18 -0700 (PDT) Received: from homiemail-a59.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a59.g.dreamhost.com (Postfix) with ESMTP id 813426002610; Wed, 24 Aug 2016 09:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=EXIav+E/fGtWIHB+1yNL6HSybCQ=; b=Ga4HEu0NJrqblqrwbDI9H9r8nQyj Ms47g91FuqQfBjrq96P1s5hIcmFCMGoDkd3gp3/6CZ/1lt+RZWHr2mstWJPCEcH6 KX9IsHV5xRfPUEE6JBUuuDrwGZinQ6p4ZXlxjNyNng3Mm24zHVmCDnFO9lJF8aey nkz/6CqLbMKqTFY= Received: from [192.168.1.7] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a59.g.dreamhost.com (Postfix) with ESMTPSA id EE99E600260F; Wed, 24 Aug 2016 09:32:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> Date: Wed, 24 Aug 2016 09:32:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0DCA59AF-6DC5-421A-A907-7C1BF173C99B@gbiv.com> References: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-core-etch@ietf.org, core@ietf.org Subject: Re: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 16:32:20 -0000 > On Aug 24, 2016, at 6:13 AM, The IESG wrote: > > > The IESG has received a request from the Constrained RESTful Environments > WG (core) to consider the following document: > - 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-09-07. 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 existing Constrained Application Protocol (CoAP) methods only > allow access to a complete resource, not to parts of a resource. In > case of resources with larger or complex data, or in situations where > a resource continuity is required, replacing or requesting the whole > resource is undesirable. Several applications using CoAP will need > to perform partial resource accesses. > > Similar to HTTP, the existing Constrained Application Protocol (CoAP) > GET method only allows the specification of a URI and request > parameters in CoAP options, not the transfer of a request payload > detailing the request. This leads to some applications to using POST > where actually a cacheable, idempotent, safe request is desired. > > Again similar to HTTP, the existing Constrained Application Protocol > (CoAP) PUT method only allows to replace a complete resource. This > also leads applications to use POST where actually a cacheable, > possibly idempotent request is desired. > > This specification adds new CoAP methods, FETCH, to perform the > equivalent of a GET with a request body; and the twin methods PATCH > and iPATCH, to modify parts of a CoAP resource. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-core-etch/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-core-etch/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > The document has a reference to obsolete RFC 2616, this is intentional. What is that supposed to mean? The reference is intentionally wrong? I looked at the text and it should be referencing section 9 of RFC7231, not section 15 of RFC2616. Just fix the reference or remove it entirely (since RFC7252 already forked HTTP semantics for no reason whatsoever). ....Roy From nobody Wed Aug 24 09:53:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4612D5EB for ; Wed, 24 Aug 2016 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLw_P3S0BJxm for ; Wed, 24 Aug 2016 09:53:45 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA20412D5B7 for ; Wed, 24 Aug 2016 09:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VDm5J53nZ8GlpWINecloItcKqOUKp12+7kEJXIn1XBc=; b=KbI5+j8KZUxlxQKJBuzwqfVa4HKvVYqj/93Beo/Hl4ux5QPKAUSOBKvkGIa/X6sh77abEsRKhecWIt2dTxBD2RftotPIjaUqK7ddc0dp3ubgPic+9vRXnxOUwj8FgfN1rLQAppzni2KK1ffU8/m1hI/MZXSRamBv+ppbP9cUHPE= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 16:53:43 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 16:53:42 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: draft-bierman-core-yid-00 open questions Thread-Index: AdH+KA3Hq1Q3oFkDSaO2q9py8NuksQ== Date: Wed, 24 Aug 2016 16:53:42 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 1adf9dd9-e7be-4d5c-4d24-08d3cc3f34c3 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 6:6YVyBwfXhgOj/C2mTatv15YZnW+WS6FSTLs6+AKrEPvpdZYB9DS1f1hKhHKYYNjuLiPM8EUiD+vmRG+KNCdhB17VI4MF1fU9pj1QWBfQ+jwI8m+YCqsyPIWNDOSjVCizcG4GBAoiUVDtuzzK+3mkXYWeEe1+Vu2lfiBbY3+u0YfG2L6+8Dn6N9KDU1v8zuWOw79/cIQbjOvuZeUpbs0xorbOuwuxXmlgFZaClj2NDebtkI/NK8hYAXIXQ/hH91Wr7QvUltr5D0+pkPxKHAB8Url27THOv0S2/lQ5c2n9H5g=; 5:XnT4Vme9FPOUhEUcagKP2S6Ev4FJlkc3dGAnsZNAgubIWSkw8/N6/X8GG8G3x7T+8tYHuBuTKj7GyyRZs6sT3NR5OAjb1O11cKH5/qpiHbZXQz+YtGfy+WP0GkVbbvqWuzWif1j/kzmP3wSF7O13wg==; 24:YglJC5uxL0LivQzxXWNTt5T1FrFCet253EQ8GwRLtkYE7fuL3+nu4cjPct3xgF8o4OVTUapvQGM9V9/HfQoxnMLtdxO8i4tfYnSX1TX+nxQ=; 7:82a7Vl6HtrFG9mrFym9YEsdhnpiLSoNqwJ/wv6EwqAr8hi9rKwUy/gydNdHm7BGeJtn0Ut9GtSHFvNy/PXGwFlddYsGxmmjZhdJlnhfS8vQCTk454pWksCYSJXJi/bo5wbAdRStl6wFUnBjCcJEjnhN11Fs7ID4yLLNz20hODcAljlT8MWiYplowjM9+Sb0A6Fx7KkvAnGyrno0cefQlB0A1wmN6aZXzk97S643pVYE4+nhZQHRSZDREY9hqxLUq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2305; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(230783001)(97736004)(5660300001)(102836003)(586003)(33656002)(3660700001)(3846002)(54356999)(4326007)(2906002)(92566002)(6116002)(110136002)(5002640100001)(3280700002)(99286002)(189998001)(86362001)(77096005)(81156014)(8676002)(122556002)(106356001)(15975445007)(81166006)(74316002)(7846002)(8936002)(305945005)(7736002)(7696003)(10400500002)(101416001)(76576001)(50986999)(66066001)(19580395003)(87936001)(229853001)(9686002)(2900100001)(68736007)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 16:53:42.7710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Cc: "core@ietf.org WG" Subject: [core] draft-bierman-core-yid-00 open questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 16:53:47 -0000 Hi Andy Following if my answers to the questions listed in draft-bierman-core-yid-0= 0 1) When to assign a module-id Developers should be in control of when this activity is performed based on= the estimated amount of work required to reassign IDs (from temporary assi= gned IDs within the experimental range to the final IDs) and the impacts on= the encoding efficiency of assigning a non stable list of YANG items which= generate non sequential IDs. If the developer already own a range of YID/S= ID, the activity can be perform at any time. It is important to note that the registration of the resulting .sid file(s)= is done independently of the registration of the SID range. When registeri= ng a SID range, the module or list of modules targeted is not provided. Thi= s give the full freedom to developers to assign IDs when needed. 2) How to support private numbering A range called "Experimental" spanning both the 16 and 32 bits unsigned int= eger have been assigned to this purpose. https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-7.1 3) How to combine registries Not needed, all registrars, SDO shall receive a specific range from IANA. 4) Should more YANG statements be numbered Yes rpc, action, notification, module, submodule, feature 5a) How to support anyxml anyxml represents a single data node with an arbitrary content. This data node have a single ID assigned to it the same way as any other da= ta node, nothing special is required. 5b) How to support anydata The anydata define an instance of an unspecified schema node (leaf, leaf-li= st, container, list). All possible schema node supported by an anydata need to be register to one= of the .sid files. It is the responsibility of the developer(s) to add these SIDs to one or mu= ltiple .sid files manually if not already present. A section need to be added to the draft to clearly describe this approach. Regards, Michel Veillette From nobody Wed Aug 24 11:32:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7455012D115 for ; Wed, 24 Aug 2016 11:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zKHvwb-kbiP for ; Wed, 24 Aug 2016 11:31:58 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CBB12D63C for ; Wed, 24 Aug 2016 11:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rzx/CYtpf45k+koNisi9pAhYuxgaOpFVQeWHaONHvB4=; b=eyG54Htq3Y1KJxYahKR9Zod8xpBML6jf+x6f3dMen67TQuQYbX0o5bsMKfF47V3c1L2LoROJsjT9XVX508aOM47fYDYB13AjuZs2fAsIFXL+SenW7vkKbY3Bg53NygrZiHn7FpOelFYW1UxXNEBjPrWV7k1swsC1Kq1afG4WgFE= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 24 Aug 2016 18:31:55 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 18:31:55 +0000 From: Michel Veillette To: Alexander Pelov Thread-Topic: Name support in draft-ietf-core-yang-cbor? Thread-Index: AdH+NcF4cAdohzWGTz2GPBcE0Hu/nw== Date: Wed, 24 Aug 2016 18:31:55 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 16142d4b-850b-46c3-622f-08d3cc4ced3a x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 6:ZwqIAKk+ytsvPTTpPivUMcXNX3/scwhxWrPtbYygkAZRWfY7vE8pw+hHhqldYIkE8+mzLib7xCnJ0H724KIKjZh0KdgUzxKIZb7d3LTdCMeVLXoiT+PXN+9adWlJ48IedcBoskkCpbsNB+1E0in+ZvF9VzuFPE9eg5QzcHBQ6G9bbMrYp+df1rwC8CWIyrEuJSAGrI4toaLxLLdQiTBoiCEw8jKH3DTuhANewwp3KMPkgQh6eJAQfL7fxW8CYxu8J6qaV8drAYTqBY95V/jnDUbLD9Gh/TICdzKEahCcGTc=; 5:aENeLsAsytPre4d7DKTfJTlte6BVcr/r41JyvnrJuivC6LXotthLffvbnMldZPU+0bXvc30VVCaQ6iWDn0uL4FjVLvyW6XKkQtzAvHKuke4aWK7Gy8hHGugzF8xy4Vt7SASpA4Nqm9+b9QUM8T0eyA==; 24:PUFSek1g2vjLWJPxHTrXwBC+aK+Sbxmg97JWO74Ch6dPdRsYMW8BMbA1H+rVqUI/MgcACig84Z3vs+5JhuNAFlTVawDo+MBxhdc97HCEVmo=; 7:aX8no8VVZQFnEzMUQv6SQkcDhnGDyHGdH8YSGre9iy+jCsYsuYdnGj1W5zN5Y+Mz53++5ke3dWtLNoCdFcSlzO86RCvGZ/tz8q/yzopk2qCISe/VTULgJiehLihKhDZDkdFtUXU0T7vXDwEvDSmc6n7fGPi/wEptl5ZSpD7Eplo6lmtoc26jVu4bCzcz4tcPwTcRZvhS79sHms5Fw/dTbXQ7NZ1WiLJii3XTEbWXjWvRxNHYTErl7XxE01ZcgoSf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(13464003)(199003)(9686002)(101416001)(7696003)(3280700002)(92566002)(8936002)(50986999)(54356999)(110136002)(105586002)(4326007)(586003)(305945005)(81156014)(8676002)(2906002)(74316002)(3846002)(77096005)(189998001)(99286002)(76576001)(81166006)(15975445007)(97736004)(7736002)(7846002)(5660300001)(102836003)(6116002)(230783001)(2900100001)(3660700001)(10400500002)(68736007)(66066001)(33656002)(122556002)(106356001)(19580395003)(229853001)(86362001)(19580405001)(11100500001)(5002640100001)(87936001)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 18:31:55.7407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Cc: "core@ietf.org WG" Subject: [core] Name support in draft-ietf-core-yang-cbor? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 18:32:00 -0000 SGkgQWxleGFuZGVyDQoNCkFib3V0ICJUaGVyZSBhcmUgdHdvIHR5cGVzIG9mIGlkZW50aWZpZXJz IHN1cHBvcnRlZCBieSBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yIC0gdGV4dHVhbCAoZm9yIGZ1 bGwgY29tcGF0aWJpbGl0eSB3aXRoIFJFU1RDb25mL05FVENPTkYgbmFtZXMpIGFuZCBkZWx0YS1l bmNvZGVkIGludGVnZXJzIChhLmsuYS4gU0lEcykuIFRoZSBmb3JtZXIgY291bGQgYmUgdXNlZCB3 aGVuIG5ldHdvcmsgY29uc3RyYWludHMgYXJlIG5vdCBzbyBzdHJpbmdlbnQsIHdoaWxlIHRoZSBs YXR0ZXIgaXMgdGhlIHByZWZlcnJlZCB3YXkgb2YgdXNpbmcgdGhpcyBlbmNvZGluZyBpbiBjb25z dHJhaW5lZCBuZXR3b3Jrcy4iDQoNCkRvbid0IHdlIGhhdmUgYW4gYWN0aW9uIGl0ZW0gZnJvbSB0 aGUgbGFzdCBJRVRGIHRvIHJlbW92ZSBuYW1lPw0KVGhlIG1pbnV0ZXMgYXJlIG5vdCBjbGVhciBh Ym91dCB0aGlzIHRvcGljLg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvbWlu dXRlcy9taW51dGVzLTk2LWNvcmUgDQpUaGUgbGFzdCBzZW50ZW5jZSBpcyBmcm9tIEFuZHkgIiBX ZSBkbyBub3QgbmVlZCBtdWx0aXBsZSB3YXlzIHRvIGRvIHRoZSBzYW1lIHRoaW5nLCBlc3BlY2lh bGx5IG9uIGNvbnN0cmFpbmVkIGRldmljZXMuIE5vYm9keSBwcm92aWRlcyBzaG9ydCBtb2R1bGUg bmFtZXMsIHNvIHRoZXkgY2FuIGJlIHZlcnkgbGFyZ2UuIg0KDQpSZWdhcmRzLA0KTWljaGVsDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kZXIgUGVsb3YgW21haWx0 bzphQGFja2wuaW9dIA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMzo1NyBBTQ0K VG86IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnDQpDYzogTWljaGVsIFZlaWxsZXR0ZSA8TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPjsgY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9u IGNhbGwgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkDQoNCkRlYXIgUGV0ZXIsDQoNCj4gTGUg MjQgYW/Du3QgMjAxNiDDoCAwODozOSwgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRh bGwubmw+IGEgw6ljcml0IDoNCj4gDQo+IFNvbWUgY29tbWVudHMgYmFzZWQgb24gdGhlIGFyZ3Vt ZW50cyBiZWxvdzoNCj4gDQo+PiBUaGlzIGRyYWZ0IGlzIGEgcHJlcmVxdWlzaXRlIGZvciB0aGUg Zm9sbG93aW5nIHdvcmtzOg0KPj4gLSBDQk9SIGVuY29kaW5nIG9mIFlBTkcgZGF0YSBtb2RlbA0K Pj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS15YW5n LWNib3IvKQ0KPiBJIGhhdmUgYXJndWVkIGFscmVhZHkgZm9yIHNvbWUgdGltZSB0aGF0IHRoZSB0 ZXh0IGFib3V0IFNJRHMgZG9lcyBub3QgYmVsb25nIGluIHRoZSB5YW5nIHRvIGNib3IgZHJhZnQu DQo+IEl0IHJlZHVjZXMgaXRzIGluZGVwZW5kZW5jZSBmcm9tIHRoZSBDb01JIHdvcmsuDQo+IEdp dmVuIHRoYXQgQ0JPUiBpcyBub3QgdG8gYmUgY2hhbmdlZCwgUHV0dGluZyB0aGUgU0lEIHRleHQg aW4gYSBjb250ZW50IGZvcm1hdCBkcmFmdCBzZWVtcyBtb3JlIGFwcHJvcHJpYXRlLg0KDQpUaGVy ZSBhcmUgdHdvIHR5cGVzIG9mIGlkZW50aWZpZXJzIHN1cHBvcnRlZCBieSBkcmFmdC1pZXRmLWNv cmUteWFuZy1jYm9yIC0gdGV4dHVhbCAoZm9yIGZ1bGwgY29tcGF0aWJpbGl0eSB3aXRoIFJFU1RD b25mL05FVENPTkYgbmFtZXMpIGFuZCBkZWx0YS1lbmNvZGVkIGludGVnZXJzIChhLmsuYS4gU0lE cykuIFRoZSBmb3JtZXIgY291bGQgYmUgdXNlZCB3aGVuIG5ldHdvcmsgY29uc3RyYWludHMgYXJl IG5vdCBzbyBzdHJpbmdlbnQsIHdoaWxlIHRoZSBsYXR0ZXIgaXMgdGhlIHByZWZlcnJlZCB3YXkg b2YgdXNpbmcgdGhpcyBlbmNvZGluZyBpbiBjb25zdHJhaW5lZCBuZXR3b3Jrcy4NCg0KV2Ugc2hv dWxkIGtlZXAgaXQgc2ltcGxlLiBIYXZpbmcgc2V2ZXJhbCBjb250ZW50IGZvcm1hdHMgdG8gZXhw cmVzcyB0aGUgc2FtZSB0aGluZyAtIGVzcGVjaWFsbHkgd2hlbiB0aGlzIGlzIG5vdCBuZWNlc3Nh cnkgLSBpcyBhZGRpbmcgY29tcGxleGl0eSBmb3Igbm8gcmVhc29uLiANCg0KVGhlIFNJRCBkcmFm dCBhbGxvd3MgZm9yIGhhdmluZyByYW5nZXMgb2YgU0lEcyBiZSBtYW5hZ2VkIGJ5IGluZGVwZW5k ZW50IHJlZ2lzdHJpZXMgYW5kIGhhdmUgZGlmZmVyZW50IHJ1bGVzIG9mIGFzc2lnbm1lbnQuIE5v IG5lZWQgdG8gdXNlIGRpZmZlcmVudCBDb250ZW50IEZvcm1hdHMgbmVjZXNzYXJ5IHRvIHNvbHZl IG92ZXJsYXBwaW5nIG9mIHRoZSBpbnRlZ2VyIHZhbHVlcy4gTW9yZW92ZXIsIGFzIG9mIHRoZSB0 aW1lIG9mIHRoaXMgd3JpdGluZywgd2UgaGF2ZSAzIGRpZmZlcmVudCBDb250ZW50LUZvcm1hdHMg Zm9yIHRoZSBDb09ML0NvTUkgZHJhZnQuIEFkZGluZyBhbiBhbHRlcm5hdGl2ZSBDb250ZW50LUZv cm1hdCBmb3IgdGhlIGludGVycHJldGF0aW9uIG9mIHRoZSBpbnRlZ2VycyB3b3VsZCBtdWx0aXBs eSB0aGlzIGJ5IDIsIGUuZy4gNiBjb250ZW50IGZvcm1hdHMsIHdoZXJlIGhhbGYgYXJlIGRvaW5n IHRoZSBzYW1lIHRoaW5nLg0KDQpJZiB5b3UgaGF2ZSBhIHNlcnZlciB3aXRoIG1peGVkIG1vZHVs ZXMgKGUuZy4gb25lcyB1c2luZyBTSUQgYW5kIG9uZXMgdXNpbmcgYSBkaWZmZXJlbnQgaW50ZXJw cmV0YXRpb24gb2YgdGhlIElEcyksIHRoZSBDb250ZW50LUZvcm1hdCB3aWxsIGZvcmNlIHlvdSB0 byBjaG9zZSBPTkUgb3IgQU5PVEhFUi4gVGhlcmUgaXMgbm8gcG9zc2liaWxpdHkgaW4gb25lIHJl cXVlc3QgdG8gcmVhZCBvciB3cml0ZSB2YWx1ZXMgZnJvbSBkaWZmZXJlbnQgbW9kdWxlcy4gVGhp cyBlZmZlY3RpdmVseSByZW1vdmVzIGFsbCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gdGhlIHR3 bywgbWFraW5nIG9uZSBvZiB0aGUgdHdvIHJlZHVuZGFudC4gDQoNCkJlc3QsDQpBbGV4YW5kZXIN Cg0KDQoNCj4+IFRoZSBhbHRlcm5hdGUgYXNzaWdubWVudCBhbGdvcml0aG0gb2YgSURzIGJhc2Vk IG9uIG11cm11cjMgYW5kIA0KPj4gaW1wcm92ZWQgZGVzY3JpcHRpb24gdGV4dHMgIHByb3Bvc2Vk IGJ5IEFuZHkgaW4NCj4+IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i aWVybWFuLWNvcmUteWlkLykgZG9uJ3QgDQo+PiBmdW5kYW1lbnRhbGx5IGNoYW5nZSB0aGUgcmVn aXN0cmF0aW9uIHByb2Nlc3MgZGVmaW5lZCBieSB0aGUgU0lEIGRyYWZ0Lg0KPiANCj4gSSBzaG91 bGQgbGlrZSB0byB3YWl0IHRpbGwgdGhpcyBhZ3JlZW1lbnQgaXMgdmlzaWJsZSBvbiB0aGlzIG1h aWxpbmcgbGlzdC4NCj4gDQo+IFBldGVyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= From nobody Wed Aug 24 13:35:25 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405D412D675 for ; Wed, 24 Aug 2016 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBjtEWMHaLVP for ; Wed, 24 Aug 2016 13:35:23 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A17712D5BE for ; Wed, 24 Aug 2016 13:35:23 -0700 (PDT) Received: from rh7.snmp.com (rh7.snmp.com [192.147.142.222]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA11769 for ; Wed, 24 Aug 2016 16:35:22 -0400 (EDT) Received: from snmp.com (rh7 [IPv6:::1]) by rh7.snmp.com (Postfix) with ESMTP id 3B9B45213C4 for ; Wed, 24 Aug 2016 16:35:26 -0400 (EDT) To: core@ietf.org Date: Wed, 24 Aug 2016 16:35:26 -0400 From: David Reid Message-Id: <20160824203526.3B9B45213C4@rh7.snmp.com> Archived-At: Subject: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 20:35:24 -0000 I read draft-bierman-core-yid-00.txt and have a few questions. Will all IETF standard yang modules be included in the YANG identifier registry or just ones that might be used on constrained devices? In order to assign numbers, is it correct that I need the first revision of the module or else the current revision and the registry assignments for the previous revision? What is the benefit of assigning values using hashing over sequentially assigning values? When there is a hash collision, would it be possible to rehash the value to get a unique number so that we never have to manually assign numbers and thus never need to register the numbers in the registry? Why does module-id need to be added to the YANG module names registry since it is also in the YANG identifier registry? Would it make sense to put the module-id inside the yang module with a yid extension so that I would not have to go lookup that information from a registry? Would it be possible to assign the module-id based on information in the module, for example a hash of the namespace and maybe the revision date. That way, a module-id would not have to be assigned and maintained in a registry. If I want to handle private modules, do I have to create my own registry? It seems important that private modules be supported. Could we re-use the SMI enterprise number assignments for creating module-ids for private modules? Who will assign the local-id numbers? Is that done by the working group that defines the YANG module? -David Reid From nobody Wed Aug 24 13:48:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2012D75C for ; Wed, 24 Aug 2016 13:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHxFt1S_MGR7 for ; Wed, 24 Aug 2016 13:48:18 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 E8C4612D75A for ; Wed, 24 Aug 2016 13:48:17 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 74so50292177uau.0 for ; Wed, 24 Aug 2016 13:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MRA6PUsEZq6DlYZlfDPDT9eKg3NsJLIHN2NKsiJY44g=; b=tg2WpqER0eYDI+X4vhLGQsY96KXtGNlLnFn1TmgwYP+GyB+2+gXU5+7TuSUDCdfhxK o7/X8KKn5W7UHdaP+PJXjioFLZ3Rr3Mzc7uIj+iroyS3cRsDu0bfTp6Jy/4Q6xAyqiBj N9oky0gNTOErpCQ7fyctPsLzVQQajH87PO2JR6pYZF/Pfv4GwdFDdTGb19wakD5qnUs8 Obd007YjGFCdzAZ637VoRmwI3PtH2CacR/EzNEhrZl3CMMbGjDsIWYKa5Ku/Ojcz0tUQ bgYqh3l3GEWqqvl4KtJ1vYywlRhKlqVj2oynLdWuwn9fgMc9/CswL26l2s5p6apNG+2l ytEA== 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:from:date :message-id:subject:to:cc; bh=MRA6PUsEZq6DlYZlfDPDT9eKg3NsJLIHN2NKsiJY44g=; b=dzijnMXjJ9sPs9zLM1urW6rq3SUZNNZN8D7eG8D2Ouf8zzwGJsft4G1osFgQ2KMcNO 7+0rLeFWLr+LUFME2YhzfJfX43a4clWjKy5075QfHoT6S7dcrZNi9u9/aFygY1EVwcpW YSRekTbB5Tp5EnxEKcZqb5pu1aLh+mprI5kfIVRrhycDF/08KHFJgtQ6QaxRbnzjucmz eB6wqpRZNqTi0tEqJ11V05WzTMqYxcXDYjH0izLqL9CD/Gzqs0qpfyyUeo8L/c/b+OWm cNH1J17+fnp4fJKszYMzcP+XJZEFqyFZcG2k1FtUWHkR9wa5lfx2ld8gdOXh5wvNPSSR 3olg== X-Gm-Message-State: AEkoouumg5v/dz7yswjzAzk5Utwotd3fmYQVB2h+cEkVUISNgxBOrDM3dpaZgReRtGECs+5VLaw++ea9XTJsrQ== X-Received: by 10.159.40.167 with SMTP id d36mr2881033uad.55.1472071696938; Wed, 24 Aug 2016 13:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Wed, 24 Aug 2016 13:48:16 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 24 Aug 2016 13:48:16 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=94eb2c123794948c0c053ad76669 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-bierman-core-yid-00 open questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 20:48:20 -0000 --94eb2c123794948c0c053ad76669 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 9:53 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > Following if my answers to the questions listed in > draft-bierman-core-yid-00 > > 1) When to assign a module-id > > Developers should be in control of when this activity is performed based > on the estimated amount of work required to reassign IDs (from temporary > assigned IDs within the experimental range to the final IDs) and the > impacts on the encoding efficiency of assigning a non stable list of YANG > items which generate non sequential IDs. If the developer already own a > range of YID/SID, the activity can be perform at any time. > > It is important to note that the registration of the resulting .sid > file(s) is done independently of the registration of the SID range. When > registering a SID range, the module or list of modules targeted is not > provided. This give the full freedom to developers to assign IDs when > needed. > > I think the registration process issues are the same whether a module-id or a range is allocated. 2) How to support private numbering > > A range called "Experimental" spanning both the 16 and 32 bits unsigned > integer have been assigned to this purpose. > https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-7.1 Yes, it seems trivial to assign a range for temporary numbers. > > > 3) How to combine registries > > Not needed, all registrars, SDO shall receive a specific range from IANA. > OK, so there is a tiered registration process? And there will not be a land-grab for all the numbers? Not clear to me how IANA approves allocation requests. > 4) Should more YANG statements be numbered > > Yes > rpc, action, notification, module, submodule, feature > > Numbering submodule and feature? These are conceptual statements within the schema language and do not affect anything on the wire. > 5a) How to support anyxml > > anyxml represents a single data node with an arbitrary content. > This data node have a single ID assigned to it the same way as any other > data node, nothing special is required. > > anyxml foo; { "foo" : { "bar": 42; "baz" "fred", "a-list" : [ .... ] } } So what numbers do you give to bar,, baz, a-list, etc.? They are all numbered the same as foo? That will be decoded with all nodes named foo, all anyxml. The name, type, value info contained in anyxml and anydata instances have no schema. These nodes cannot be numbered. This is a YANG-to-CBOR issue, not a SID issue. But in real YANG these child nodes sometimes represent real objects from some other module. In this case the server may know the "hidden SID". http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 > 5b) How to support anydata > > The anydata define an instance of an unspecified schema node (leaf, > leaf-list, container, list). > All possible schema node supported by an anydata need to be register to > one of the .sid files. > It is the responsibility of the developer(s) to add these SIDs to one or > multiple .sid files manually if not already present. > A section need to be added to the draft to clearly describe this approach. > > Regards, > Michel Veillette > > Andy --94eb2c123794948c0c053ad76669 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 24, 2016 at 9:53 AM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:
= Hi Andy

Following if my answers to the questions listed in draft-bierman-core-yid-0= 0

1) When to assign a module-id

Developers should be in control of when this activity is performed based on= the estimated amount of work required to reassign IDs (from temporary assi= gned IDs within the experimental range to the final IDs) and the impacts on= the encoding efficiency of assigning a non stable list of YANG items which= generate non sequential IDs. If the developer already own a range of YID/S= ID, the activity can be perform at any time.

It is important to note that the registration of the resulting .sid file(s)= is done independently of the registration of the SID range. When registeri= ng a SID range, the module or list of modules targeted is not provided. Thi= s give the full freedom to developers to assign IDs when needed.


I think the registration process issue= s are the same whether a module-id or a range is allocated.

<= /div>

2) How to support private numbering

A range called "Experimental" spanning both the 16 and 32 bits un= signed integer have been assigned to this purpose.
https://tools.ietf.org/html/d= raft-somaraju-core-sid-01#section-7.1

<= div>
Yes, it seems trivial to assign a range for temporary nu= mbers.

=C2=A0


3) How to combine registries

Not needed, all registrars, SDO shall receive a specific range from IANA.


OK, so there is a tiered = registration process?
And there will not be a land-grab for all t= he numbers?
Not clear to me how IANA approves allocation requests= .



4) Should more YANG statements be numbered

Yes
rpc, action, notification, module, submodule, feature


Numbering submodule and feature?
=
These are conceptual statements within the schema language and
do not affect anything on the wire.

=C2=A0
5a) How to support anyxml

anyxml represents a single data node with an arbitrary content.
This data node have a single ID assigned to it the same way as any other da= ta node, nothing special is required.



=C2=A0 =C2=A0 anyxml fo= o;


=C2=A0 =C2=A0 { "foo" = : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"bar": 42;
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"baz" "fred",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"a-list" : [
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ....
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 = =C2=A0 =C2=A0}


So what numbers do y= ou give to bar,, baz, a-list, etc.?
They are all numbered the sam= e as foo?
That will be decoded with all nodes named foo, all anyx= ml.
The name, type, value info contained in anyxml and anydata
instances have no schema.=C2=A0 These nodes cannot be numbered.
This is a YANG-to-CBOR issue, not a SID issue.

<= div>But in real YANG these child nodes sometimes represent real objects
from some other module.=C2=A0 In this case the server may know the &= quot;hidden SID".




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0
5b) How to support anydata

The anydata define an instance of an unspecified schema node (leaf, leaf-li= st, container, list).
All possible schema node supported by an anydata need to be register to one= of the .sid files.
It is the responsibility of the developer(s) to add these SIDs to one or mu= ltiple .sid files manually if not already present.
A section need to be added to the draft to clearly describe this approach.<= br>
Regards,
Michel Veillette



Andy

--94eb2c123794948c0c053ad76669-- From nobody Wed Aug 24 14:08:40 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E130012D776; Wed, 24 Aug 2016 14:08:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> Date: Wed, 24 Aug 2016 14:08:38 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 21:08:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-04.txt Pages : 42 Date : 2016-08-24 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-04 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 Wed Aug 24 14:09:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE17F12D774 for ; Wed, 24 Aug 2016 14:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxJIJ0Y_fxif for ; Wed, 24 Aug 2016 14:09:24 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0107.outbound.protection.outlook.com [104.47.42.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F61812D76E for ; Wed, 24 Aug 2016 14:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iBY09A3sfh/OmEkoPuGmR2vRnZLjBsoya8UuX2qFgzQ=; b=skNN3nO6OFCWCJnHFLbSCMhkPNxIX8m3HisuBv0nOGFR6nbDGHEMynlw+IkdCBgby0Lx3IyYINoU9CYBEKJKHlHbbe/DZJOoo+lnpozI9v6iWX2oYj+3o1kBlwU3dNFXymecZh9AwBwaBY3QTHG62i9Gu2d2MyLFG+C8x+tQDx0= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 24 Aug 2016 21:09:22 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 21:09:21 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: draft-bierman-core-yid-00 open questions Thread-Index: AdH+KA3Hq1Q3oFkDSaO2q9py8NuksQAIMi0AAAA158A= Date: Wed, 24 Aug 2016 21:09:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: e79d7002-9124-4464-e5b7-08d3cc62eb5c x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:u7PEe5/xC4jWnXUJ2hu+JTEfCZiOS1zBMaSjDol3Za5BD0ZL0gBLY7FV8g7wMKTiHaVuwd1bR2mWPjKyImVFzDwFxHdWKhUfjaAosmtuD2flYXhLfhjuQrmIEqiOKFH0RntHjmE60Pc5XxGDOXD1aYJHmM/oWk+nl+yfY+5iTFfbza0Cd2Dps+RMWwU+wiogr/WmuhM90DIBHciQKfcpFGxg3LF//Q6V8Ju+730RWCJv+scRsAzd94Bl1ftfkopLjx+i4i0mnQWkbSaqWUdvb2gdoZJJKhpmKjnD60/sOvs=; 5:SGHdk6Yql/Edx4tLREYQhWpPGnnd3SAeH3SiFJG5PUEPPuhuPA3NCvuJOfhC0MLvD7F7ibzQCnaxqIpa1Sy7lmxa6yybHr9h00Tq2zG2574lA+QMvkxuUMlp+PqbS42K9hRucWOgxZxPs0qj4IEUSA==; 24:DSQcqGU5ebWZudwU3zxx4S/uLtlm8bRoD/Xp3jiXmTz2d5JJOrjhbEGf1qqUUBxzLTr+3VMQjbHA/PFaoaow8f7m0itDu4xaGbw/0H7kfAA=; 7:G6yvwlyYw+NWu5Y0VKCngSxAh2H/hfn+jKpl68BjNPqJRCtMP026Ukbjwm9kuyFB5MFEoUfxng5Q90O2aEHHNNNjqMvKadTXjmvbziVoRiIukJBK5bXk3gLkqkAZ19ER0le9vyf433w4AgHE7wkuEQAhzz6+pjeqw3uAwHx+ipVJcohU2yu12aWl+ozGXCyAroEUluRb7k6XjPSQUG2w7z+OUNAgPmi/Fk1EbM3ZsuR9cad63VVyXA4uqCWdTdBn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(24454002)(189002)(50986999)(76176999)(110136002)(189998001)(87936001)(97736004)(19580395003)(101416001)(2900100001)(19617315012)(19580405001)(19625215002)(92566002)(2950100001)(33656002)(86362001)(76576001)(68736007)(54356999)(4326007)(105586002)(5660300001)(3660700001)(122556002)(2906002)(77096005)(66066001)(99286002)(10400500002)(8936002)(15975445007)(230783001)(102836003)(19300405004)(7906003)(3846002)(5002640100001)(7736002)(6116002)(8676002)(3280700002)(7846002)(19609705001)(7696003)(586003)(16236675004)(74316002)(9686002)(81166006)(106356001)(81156014)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23087BFAB03E7B392DD25825FEEA0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 21:09:21.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-bierman-core-yid-00 open questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 21:09:27 -0000 --_000_BN6PR06MB23087BFAB03E7B392DD25825FEEA0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpNeSBjb21tZW50cyBpbmxpbmUgW01WXQ0KDQpGcm9tOiBBbmR5IEJpZXJtYW4g W21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwg MjAxNiA0OjQ4IFBNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnRpbmMuY29tPg0KQ2M6IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMCBvcGVuIHF1ZXN0aW9ucw0KDQoNCg0K T24gV2VkLCBBdWcgMjQsIDIwMTYgYXQgOTo1MyBBTSwgTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVs LlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxs aWFudGluYy5jb20+PiB3cm90ZToNCkhpIEFuZHkNCg0KRm9sbG93aW5nIGlmIG15IGFuc3dlcnMg dG8gdGhlIHF1ZXN0aW9ucyBsaXN0ZWQgaW4gZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMA0KDQox KSBXaGVuIHRvIGFzc2lnbiBhIG1vZHVsZS1pZA0KDQpEZXZlbG9wZXJzIHNob3VsZCBiZSBpbiBj b250cm9sIG9mIHdoZW4gdGhpcyBhY3Rpdml0eSBpcyBwZXJmb3JtZWQgYmFzZWQgb24gdGhlIGVz dGltYXRlZCBhbW91bnQgb2Ygd29yayByZXF1aXJlZCB0byByZWFzc2lnbiBJRHMgKGZyb20gdGVt cG9yYXJ5IGFzc2lnbmVkIElEcyB3aXRoaW4gdGhlIGV4cGVyaW1lbnRhbCByYW5nZSB0byB0aGUg ZmluYWwgSURzKSBhbmQgdGhlIGltcGFjdHMgb24gdGhlIGVuY29kaW5nIGVmZmljaWVuY3kgb2Yg YXNzaWduaW5nIGEgbm9uIHN0YWJsZSBsaXN0IG9mIFlBTkcgaXRlbXMgd2hpY2ggZ2VuZXJhdGUg bm9uIHNlcXVlbnRpYWwgSURzLiBJZiB0aGUgZGV2ZWxvcGVyIGFscmVhZHkgb3duIGEgcmFuZ2Ug b2YgWUlEL1NJRCwgdGhlIGFjdGl2aXR5IGNhbiBiZSBwZXJmb3JtIGF0IGFueSB0aW1lLg0KDQpJ dCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIHJlc3Vs dGluZyAuc2lkIGZpbGUocykgaXMgZG9uZSBpbmRlcGVuZGVudGx5IG9mIHRoZSByZWdpc3RyYXRp b24gb2YgdGhlIFNJRCByYW5nZS4gV2hlbiByZWdpc3RlcmluZyBhIFNJRCByYW5nZSwgdGhlIG1v ZHVsZSBvciBsaXN0IG9mIG1vZHVsZXMgdGFyZ2V0ZWQgaXMgbm90IHByb3ZpZGVkLiBUaGlzIGdp dmUgdGhlIGZ1bGwgZnJlZWRvbSB0byBkZXZlbG9wZXJzIHRvIGFzc2lnbiBJRHMgd2hlbiBuZWVk ZWQuDQoNCkkgdGhpbmsgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGlzc3VlcyBhcmUgdGhlIHNh bWUgd2hldGhlciBhIG1vZHVsZS1pZCBvciBhIHJhbmdlIGlzIGFsbG9jYXRlZC4NCg0KW01WXSBO b3QgZXhhY3RseSwgcmVnaXN0ZXJpbmcgYSBtb2R1bGUtaWQgaW1wbHkgdGhhdCB5b3UgbmVlZCB0 byBrbm93IHRoZSBtb2R1bGUgaW5mb3JtYXRpb24gaW4gYWR2YW5jZS4NCltNVl0gSWYgeW91IHJl Z2lzdGVyIGEgcmFuZ2UsIHlvdSBjYW4gYXNzaWduIHRoaXMgcmFuZ2UgYXMgbmVlZGVkIHRvIG9u ZSBvciBtdWx0aXBsZSBtb2R1bGVzLg0KW01WXSBZb3UgZG9u4oCZdCBuZWVkIHRvIGdvIGJhY2sg dG8gdGhlIHJlZ2lzdHJhciBlYWNoIHRpbWUgeW91IGNyZWF0ZSBhIG5ldyBtb2R1bGUuDQoNCjIp IEhvdyB0byBzdXBwb3J0IHByaXZhdGUgbnVtYmVyaW5nDQoNCkEgcmFuZ2UgY2FsbGVkICJFeHBl cmltZW50YWwiIHNwYW5uaW5nIGJvdGggdGhlIDE2IGFuZCAzMiBiaXRzIHVuc2lnbmVkIGludGVn ZXIgaGF2ZSBiZWVuIGFzc2lnbmVkIHRvIHRoaXMgcHVycG9zZS4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zb21hcmFqdS1jb3JlLXNpZC0wMSNzZWN0aW9uLTcuMQ0KDQoNClll cywgaXQgc2VlbXMgdHJpdmlhbCB0byBhc3NpZ24gYSByYW5nZSBmb3IgdGVtcG9yYXJ5IG51bWJl cnMuDQoNCg0KDQoNCjMpIEhvdyB0byBjb21iaW5lIHJlZ2lzdHJpZXMNCg0KTm90IG5lZWRlZCwg YWxsIHJlZ2lzdHJhcnMsIFNETyBzaGFsbCByZWNlaXZlIGEgc3BlY2lmaWMgcmFuZ2UgZnJvbSBJ QU5BLg0KDQoNCk9LLCBzbyB0aGVyZSBpcyBhIHRpZXJlZCByZWdpc3RyYXRpb24gcHJvY2Vzcz8N CkFuZCB0aGVyZSB3aWxsIG5vdCBiZSBhIGxhbmQtZ3JhYiBmb3IgYWxsIHRoZSBudW1iZXJzPw0K Tm90IGNsZWFyIHRvIG1lIGhvdyBJQU5BIGFwcHJvdmVzIGFsbG9jYXRpb24gcmVxdWVzdHMuDQoN Cg0KDQo0KSBTaG91bGQgbW9yZSBZQU5HIHN0YXRlbWVudHMgYmUgbnVtYmVyZWQNCg0KWWVzDQpy cGMsIGFjdGlvbiwgbm90aWZpY2F0aW9uLCBtb2R1bGUsIHN1Ym1vZHVsZSwgZmVhdHVyZQ0KDQpO dW1iZXJpbmcgc3VibW9kdWxlIGFuZCBmZWF0dXJlPw0KVGhlc2UgYXJlIGNvbmNlcHR1YWwgc3Rh dGVtZW50cyB3aXRoaW4gdGhlIHNjaGVtYSBsYW5ndWFnZSBhbmQNCmRvIG5vdCBhZmZlY3QgYW55 dGhpbmcgb24gdGhlIHdpcmUuDQoNCltNVl0gU0lEIGFzc2lnbmVkIHRvIHN1Ym1vZHVsZXMgYW5k IGZlYXR1cmVzIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IGRpc2NvdmVyeQ0KW01WXSBTZWUgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlaWxsZXR0ZS1jb3JlLWNvb2wtbGlicmFy eS0wMCNzZWN0aW9uLTMuMQ0KDQo1YSkgSG93IHRvIHN1cHBvcnQgYW55eG1sDQoNCmFueXhtbCBy ZXByZXNlbnRzIGEgc2luZ2xlIGRhdGEgbm9kZSB3aXRoIGFuIGFyYml0cmFyeSBjb250ZW50Lg0K VGhpcyBkYXRhIG5vZGUgaGF2ZSBhIHNpbmdsZSBJRCBhc3NpZ25lZCB0byBpdCB0aGUgc2FtZSB3 YXkgYXMgYW55IG90aGVyIGRhdGEgbm9kZSwgbm90aGluZyBzcGVjaWFsIGlzIHJlcXVpcmVkLg0K DQoNCiAgICBhbnl4bWwgZm9vOw0KDQoNCiAgICB7ICJmb28iIDogew0KICAgICAgICAgImJhciI6 IDQyOw0KICAgICAgICAgImJheiIgImZyZWQiLA0KICAgICAgICAgImEtbGlzdCIgOiBbDQogICAg ICAgICAgICAuLi4uDQogICAgICAgICBdDQogICAgICAgfQ0KICAgICB9DQoNCg0KU28gd2hhdCBu dW1iZXJzIGRvIHlvdSBnaXZlIHRvIGJhciwsIGJheiwgYS1saXN0LCBldGMuPw0KVGhleSBhcmUg YWxsIG51bWJlcmVkIHRoZSBzYW1lIGFzIGZvbz8NClRoYXQgd2lsbCBiZSBkZWNvZGVkIHdpdGgg YWxsIG5vZGVzIG5hbWVkIGZvbywgYWxsIGFueXhtbC4NClRoZSBuYW1lLCB0eXBlLCB2YWx1ZSBp bmZvIGNvbnRhaW5lZCBpbiBhbnl4bWwgYW5kIGFueWRhdGENCmluc3RhbmNlcyBoYXZlIG5vIHNj aGVtYS4gIFRoZXNlIG5vZGVzIGNhbm5vdCBiZSBudW1iZXJlZC4NClRoaXMgaXMgYSBZQU5HLXRv LUNCT1IgaXNzdWUsIG5vdCBhIFNJRCBpc3N1ZS4NCg0KQnV0IGluIHJlYWwgWUFORyB0aGVzZSBj aGlsZCBub2RlcyBzb21ldGltZXMgcmVwcmVzZW50IHJlYWwgb2JqZWN0cw0KZnJvbSBzb21lIG90 aGVyIG1vZHVsZS4gIEluIHRoaXMgY2FzZSB0aGUgc2VydmVyIG1heSBrbm93IHRoZSAiaGlkZGVu IFNJRCIuDQoNCmh0dHA6Ly93d3cubmV0Y29uZmNlbnRyYWwub3JnL21vZHVsZXMveXVtYS1uY3gv MjAxMy0wOS0yMyNyb290LjU1NA0KDQpbTVZdIElmIHRoZSBpbm5lciBtZW1iZXJzIG9mIHRoaXMg Q0JPUiBtYXAgbmVlZCB0byBhc3NvY2lhdGVkIHRvIFNJRCwgdGhlIGRldmVsb3BlciB3aWxsIG5l ZWQgdG8gYXNzaWduIHRoZXNlIFNJRHMgYXMgZGVzY3JpYmVkIGluIDViLg0KW01WXSBJZiB0aGlz IGlzIHRoZSBjYXNlLCB0aGUgYXV0aG9yIHNob3VsZCBoYXZlIHVzZWQgYW4gYW55ZGF0YS4NCltN Vl0gTm9ybWFsbHksIGFuIGFueXhtbCBjb250YWluIGFuIGFyYml0cmFyeSBDQk9SIGNvbnRlbnQg d2hpY2ggaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggWUFORyBhbmQgU0lEcy4NCltNVl0gVGhpcyBp cyB0aGUgYXBwcm9hY2ggcHJvcG9zZWQgYnkgImRyYWZ0LWlldGYtbmV0bW9kLXlhbmctanNvbiIg YW5kIHJldXNlZCBieSAiZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvciINCg0KDQo1YikgSG93IHRv IHN1cHBvcnQgYW55ZGF0YQ0KDQpUaGUgYW55ZGF0YSBkZWZpbmUgYW4gaW5zdGFuY2Ugb2YgYW4g dW5zcGVjaWZpZWQgc2NoZW1hIG5vZGUgKGxlYWYsIGxlYWYtbGlzdCwgY29udGFpbmVyLCBsaXN0 KS4NCkFsbCBwb3NzaWJsZSBzY2hlbWEgbm9kZSBzdXBwb3J0ZWQgYnkgYW4gYW55ZGF0YSBuZWVk IHRvIGJlIHJlZ2lzdGVyIHRvIG9uZSBvZiB0aGUgLnNpZCBmaWxlcy4NCkl0IGlzIHRoZSByZXNw b25zaWJpbGl0eSBvZiB0aGUgZGV2ZWxvcGVyKHMpIHRvIGFkZCB0aGVzZSBTSURzIHRvIG9uZSBv ciBtdWx0aXBsZSAuc2lkIGZpbGVzIG1hbnVhbGx5IGlmIG5vdCBhbHJlYWR5IHByZXNlbnQuDQpB IHNlY3Rpb24gbmVlZCB0byBiZSBhZGRlZCB0byB0aGUgZHJhZnQgdG8gY2xlYXJseSBkZXNjcmli ZSB0aGlzIGFwcHJvYWNoLg0KDQpSZWdhcmRzLA0KTWljaGVsIFZlaWxsZXR0ZQ0KDQoNCkFuZHkN Cg0K --_000_BN6PR06MB23087BFAB03E7B392DD25825FEEA0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBBbmR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgY29tbWVudHMgaW5saW5lIFtNVl08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgNDo0OCBQTTxicj4NCjxiPlRvOjwvYj4g TWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gY29yZUBpZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAgb3BlbiBx dWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAyNCwgMjAxNiBh dCA5OjUzIEFNLCBNaWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZl aWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGVsLlZlaWxsZXR0 ZUB0cmlsbGlhbnRpbmMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I aSBBbmR5PGJyPg0KPGJyPg0KRm9sbG93aW5nIGlmIG15IGFuc3dlcnMgdG8gdGhlIHF1ZXN0aW9u cyBsaXN0ZWQgaW4gZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMDxicj4NCjxicj4NCjEpIFdoZW4g dG8gYXNzaWduIGEgbW9kdWxlLWlkPGJyPg0KPGJyPg0KRGV2ZWxvcGVycyBzaG91bGQgYmUgaW4g Y29udHJvbCBvZiB3aGVuIHRoaXMgYWN0aXZpdHkgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZSBl c3RpbWF0ZWQgYW1vdW50IG9mIHdvcmsgcmVxdWlyZWQgdG8gcmVhc3NpZ24gSURzIChmcm9tIHRl bXBvcmFyeSBhc3NpZ25lZCBJRHMgd2l0aGluIHRoZSBleHBlcmltZW50YWwgcmFuZ2UgdG8gdGhl IGZpbmFsIElEcykgYW5kIHRoZSBpbXBhY3RzIG9uIHRoZSBlbmNvZGluZyBlZmZpY2llbmN5IG9m IGFzc2lnbmluZw0KIGEgbm9uIHN0YWJsZSBsaXN0IG9mIFlBTkcgaXRlbXMgd2hpY2ggZ2VuZXJh dGUgbm9uIHNlcXVlbnRpYWwgSURzLiBJZiB0aGUgZGV2ZWxvcGVyIGFscmVhZHkgb3duIGEgcmFu Z2Ugb2YgWUlEL1NJRCwgdGhlIGFjdGl2aXR5IGNhbiBiZSBwZXJmb3JtIGF0IGFueSB0aW1lLjxi cj4NCjxicj4NCkl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBv ZiB0aGUgcmVzdWx0aW5nIC5zaWQgZmlsZShzKSBpcyBkb25lIGluZGVwZW5kZW50bHkgb2YgdGhl IHJlZ2lzdHJhdGlvbiBvZiB0aGUgU0lEIHJhbmdlLiBXaGVuIHJlZ2lzdGVyaW5nIGEgU0lEIHJh bmdlLCB0aGUgbW9kdWxlIG9yIGxpc3Qgb2YgbW9kdWxlcyB0YXJnZXRlZCBpcyBub3QgcHJvdmlk ZWQuIFRoaXMgZ2l2ZSB0aGUgZnVsbCBmcmVlZG9tIHRvIGRldmVsb3BlcnMNCiB0byBhc3NpZ24g SURzIHdoZW4gbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgaXNz dWVzIGFyZSB0aGUgc2FtZSB3aGV0aGVyIGEgbW9kdWxlLWlkIG9yIGEgcmFuZ2UgaXMgYWxsb2Nh dGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPltNVl0gTm90IGV4YWN0bHksIHJlZ2lzdGVyaW5nIGEgbW9kdWxlLWlkIGlt cGx5IHRoYXQgeW91IG5lZWQgdG8ga25vdyB0aGUgbW9kdWxlIGluZm9ybWF0aW9uIGluIGFkdmFu Y2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bTVZdIElmIHlvdSByZWdpc3RlciBhIHJhbmdlLCB5b3Ug Y2FuIGFzc2lnbiB0aGlzIHJhbmdlIGFzIG5lZWRlZCB0byBvbmUgb3IgbXVsdGlwbGUgbW9kdWxl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPltNVl0gWW91IGRvbuKAmXQgbmVlZCB0byBnbyBiYWNrIHRvIHRoZSByZWdpc3RyYXIg ZWFjaCB0aW1lIHlvdSBjcmVhdGUgYSBuZXcgbW9kdWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSG93IHRvIHN1 cHBvcnQgcHJpdmF0ZSBudW1iZXJpbmc8YnI+DQo8YnI+DQpBIHJhbmdlIGNhbGxlZCAmcXVvdDtF eHBlcmltZW50YWwmcXVvdDsgc3Bhbm5pbmcgYm90aCB0aGUgMTYgYW5kIDMyIGJpdHMgdW5zaWdu ZWQgaW50ZWdlciBoYXZlIGJlZW4gYXNzaWduZWQgdG8gdGhpcyBwdXJwb3NlLjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zb21hcmFqdS1jb3JlLXNpZC0w MSNzZWN0aW9uLTcuMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zb21hcmFqdS1jb3JlLXNpZC0wMSNzZWN0aW9uLTcuMTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBp dCBzZWVtcyB0cml2aWFsIHRvIGFzc2lnbiBhIHJhbmdlIGZvciB0ZW1wb3JhcnkgbnVtYmVycy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQozKSBIb3cgdG8gY29tYmluZSByZWdpc3RyaWVzPGJyPg0KPGJyPg0K Tm90IG5lZWRlZCwgYWxsIHJlZ2lzdHJhcnMsIFNETyBzaGFsbCByZWNlaXZlIGEgc3BlY2lmaWMg cmFuZ2UgZnJvbSBJQU5BLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgc28gdGhlcmUgaXMgYSB0aWVyZWQgcmVnaXN0cmF0 aW9uIHByb2Nlc3M/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbmQgdGhlcmUgd2lsbCBub3QgYmUgYSBsYW5kLWdyYWIgZm9yIGFsbCB0aGUgbnVt YmVycz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk5vdCBjbGVhciB0byBtZSBob3cgSUFOQSBhcHByb3ZlcyBhbGxvY2F0aW9uIHJlcXVlc3RzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KNCkgU2hvdWxkIG1vcmUgWUFO RyBzdGF0ZW1lbnRzIGJlIG51bWJlcmVkPGJyPg0KPGJyPg0KWWVzPGJyPg0KcnBjLCBhY3Rpb24s IG5vdGlmaWNhdGlvbiwgbW9kdWxlLCBzdWJtb2R1bGUsIGZlYXR1cmU8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk51bWJlcmluZyBz dWJtb2R1bGUgYW5kIGZlYXR1cmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBhcmUgY29uY2VwdHVhbCBzdGF0ZW1lbnRzIHdpdGhpbiB0 aGUgc2NoZW1hIGxhbmd1YWdlIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+ZG8gbm90IGFmZmVjdCBhbnl0aGluZyBvbiB0aGUgd2lyZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bTVZd IFNJRCBhc3NpZ25lZCB0byBzdWJtb2R1bGVzIGFuZCBmZWF0dXJlcyBhcmUgcmVxdWlyZWQgdG8g c3VwcG9ydCBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gU2VlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdmVpbGxldHRlLWNvcmUtY29vbC1saWJyYXJ5LTAwI3NlY3Rpb24t My4xIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZWlsbGV0dGUtY29yZS1j b29sLWxpYnJhcnktMDAjc2VjdGlvbi0zLjE8L2E+IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjVhKSBIb3cgdG8gc3VwcG9ydCBhbnl4bWw8YnI+DQo8YnI+DQphbnl4 bWwgcmVwcmVzZW50cyBhIHNpbmdsZSBkYXRhIG5vZGUgd2l0aCBhbiBhcmJpdHJhcnkgY29udGVu dC48YnI+DQpUaGlzIGRhdGEgbm9kZSBoYXZlIGEgc2luZ2xlIElEIGFzc2lnbmVkIHRvIGl0IHRo ZSBzYW1lIHdheSBhcyBhbnkgb3RoZXIgZGF0YSBub2RlLCBub3RoaW5nIHNwZWNpYWwgaXMgcmVx dWlyZWQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgYW55eG1sIGZvbzs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IHsgJnF1 b3Q7Zm9vJnF1b3Q7IDogezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2JhciZx dW90OzogNDI7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YmF6JnF1b3Q7ICZx dW90O2ZyZWQmcXVvdDssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YS1saXN0 JnF1b3Q7IDogWzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO108bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNvIHdoYXQgbnVtYmVycyBkbyB5b3UgZ2l2ZSB0byBiYXIsLCBiYXosIGEtbGlz dCwgZXRjLj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZXkgYXJlIGFsbCBudW1iZXJlZCB0aGUgc2FtZSBhcyBmb28/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdpbGwgYmUgZGVjb2Rl ZCB3aXRoIGFsbCBub2RlcyBuYW1lZCBmb28sIGFsbCBhbnl4bWwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbmFtZSwgdHlwZSwgdmFsdWUg aW5mbyBjb250YWluZWQgaW4gYW55eG1sIGFuZCBhbnlkYXRhPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnN0YW5jZXMgaGF2ZSBubyBzY2hlbWEu Jm5ic3A7IFRoZXNlIG5vZGVzIGNhbm5vdCBiZSBudW1iZXJlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBZQU5HLXRvLUNCT1Ig aXNzdWUsIG5vdCBhIFNJRCBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGluIHJlYWwgWUFORyB0aGVzZSBjaGlsZCBub2RlcyBz b21ldGltZXMgcmVwcmVzZW50IHJlYWwgb2JqZWN0czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZnJvbSBzb21lIG90aGVyIG1vZHVsZS4mbmJzcDsg SW4gdGhpcyBjYXNlIHRoZSBzZXJ2ZXIgbWF5IGtub3cgdGhlICZxdW90O2hpZGRlbiBTSUQmcXVv dDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHA6Ly93d3cubmV0Y29uZmNlbnRyYWwub3JnL21vZHVsZXMveXVtYS1uY3gv MjAxMy0wOS0yMyNyb290LjU1NCI+aHR0cDovL3d3dy5uZXRjb25mY2VudHJhbC5vcmcvbW9kdWxl cy95dW1hLW5jeC8yMDEzLTA5LTIzI3Jvb3QuNTU0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTVZdIElmIHRoZSBpbm5lciBtZW1iZXJz IG9mIHRoaXMgQ0JPUiBtYXAgbmVlZCB0byBhc3NvY2lhdGVkIHRvIFNJRCwgdGhlIGRldmVsb3Bl ciB3aWxsIG5lZWQgdG8gYXNzaWduIHRoZXNlIFNJRHMgYXMgZGVzY3JpYmVkIGluIDViLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W01WXSBJZiB0aGlzIGlzIHRoZSBjYXNl LCB0aGUgYXV0aG9yIHNob3VsZCBoYXZlIHVzZWQgYW4gYW55ZGF0YS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltNVl0gTm9ybWFsbHksIGFuIGFueXhtbCBjb250YWluIGFu IGFyYml0cmFyeSBDQk9SIGNvbnRlbnQgd2hpY2ggaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggWUFO RyBhbmQgU0lEcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltNVl0gVGhp cyBpcyB0aGUgYXBwcm9hY2ggcHJvcG9zZWQgYnkgJnF1b3Q7ZHJhZnQtaWV0Zi1uZXRtb2QteWFu Zy1qc29uJnF1b3Q7IGFuZCByZXVzZWQgYnkgJnF1b3Q7ZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jv ciZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+NWIpIEhvdyB0byBzdXBwb3J0IGFueWRh dGE8YnI+DQo8YnI+DQpUaGUgYW55ZGF0YSBkZWZpbmUgYW4gaW5zdGFuY2Ugb2YgYW4gdW5zcGVj aWZpZWQgc2NoZW1hIG5vZGUgKGxlYWYsIGxlYWYtbGlzdCwgY29udGFpbmVyLCBsaXN0KS48YnI+ DQpBbGwgcG9zc2libGUgc2NoZW1hIG5vZGUgc3VwcG9ydGVkIGJ5IGFuIGFueWRhdGEgbmVlZCB0 byBiZSByZWdpc3RlciB0byBvbmUgb2YgdGhlIC5zaWQgZmlsZXMuPGJyPg0KSXQgaXMgdGhlIHJl c3BvbnNpYmlsaXR5IG9mIHRoZSBkZXZlbG9wZXIocykgdG8gYWRkIHRoZXNlIFNJRHMgdG8gb25l IG9yIG11bHRpcGxlIC5zaWQgZmlsZXMgbWFudWFsbHkgaWYgbm90IGFscmVhZHkgcHJlc2VudC48 YnI+DQpBIHNlY3Rpb24gbmVlZCB0byBiZSBhZGRlZCB0byB0aGUgZHJhZnQgdG8gY2xlYXJseSBk ZXNjcmliZSB0aGlzIGFwcHJvYWNoLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTWljaGVsIFZl aWxsZXR0ZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR06MB23087BFAB03E7B392DD25825FEEA0BN6PR06MB2308namp_-- From nobody Wed Aug 24 14:22:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC6E12D756 for ; Wed, 24 Aug 2016 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IkOLzepku3U for ; Wed, 24 Aug 2016 14:22:04 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0118.outbound.protection.outlook.com [104.47.34.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C6212D5D7 for ; Wed, 24 Aug 2016 14:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5k+Q14n4Um+/lJ5d6lTX3MtdSBOyeAw1i84cY2U5aH0=; b=aYY2rjhAR4ppCAzO1ko/3Vcgu7nsq8a7tlMf+XpX+o0HrtE+t9jF/vXLRbTeBKduWGuk9C2XZnHM+8ZxcXBiw7R5ovUW9NWtbdPY5ZwmrT+p85jw8+40ZWOHqJ5THkdqGZYUcORPALCQ/esX1Yv8+bppRaM7zSlpltCMZCgPtKo= Received: from BN6PR03MB2724.namprd03.prod.outlook.com (10.173.144.19) by BN6PR03MB2723.namprd03.prod.outlook.com (10.173.144.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 24 Aug 2016 21:22:03 +0000 Received: from BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) by BN6PR03MB2724.namprd03.prod.outlook.com ([10.173.144.19]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 21:22:02 +0000 From: Brian Raymor To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt Thread-Index: AQHR/kux0vvo8uYlLUa/o5fnHPLus6BYnTxw Date: Wed, 24 Aug 2016 21:22:01 +0000 Message-ID: References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> In-Reply-To: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 9d438bf9-5666-41bb-15ea-08d3cc64b0a1 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2723; 6:M0IqLGlyOzUZUl+S8PcFnDhB5OHWOmvGKtlofTXIi2cRpuuIVgTCtX1IxUa4qTxHD7DyRzLyToZG5IKHIk42dZSzcLQlyRLR31s5UThv9wfj2PmpkTNb1CQs9DWI7t3jOOAukhL9Kk1jP+BKQJ0OBDyDl3qENQNGmqo6CHUp7tnPyImivnt4GT/MA3zUwJ4o/lnOYwoQ7L4da9s/apOzsJVkH7Sjd6F/e9snb4Bsawq/m4eCTMyamWbbw0wyG87mHSq4mw8FEy1wT3l2k7R4K+KQdqlnPDpMnRId1cuTquLOEfNk7IqIG43Ac9VThNqMqSPQxulH+admlfCBMzDHtg==; 5:NtYhASi7+HzIpIMu/gcQ3p2/aOz3uiudvCtQPLQTcUAlMAAqIQkiQ6QCKf1EN9w9e4WiCmVzuGG5yG8UNjb2p6FxvwaOFhWx6gocyJQy4eCWgREDoResOHNT+HmN5gnNx+v3n+zOCR+Tve8UsT+pRg==; 24:yb/qRoRKqMaXr+IUONs/ZvWTWEan9YfrJtLNSxRQRC3PUi4n7VcfxDZPS1j9aujkWTLGRbqH65trqQUiDftBOCxURAx0uAnpQtkaEytG8RQ=; 7:GKcbtL9s0vUjsRwxeLjgblsF5hhjt8DeBeySp5lqZL5pK4JBK9XNnfAT+ESXvG4eqjFeleTnNtQvjmEnssoRDXiZ5/0EstYnk49Y9OvdBZLCy5FM1vxOsv6x+sxjClktNIpPvhCiOHqP8m1pPJBZ1/4MeSL7pGVLI4VZec3eWmomcjXFEar3FzXw3Sa3x3KRZKm2dm1D6xIMhvNiZC4ANoP3edYSnIoN7I3KTJarkTIo5723nSfKVFHTya+ZgBKD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2723; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2723; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2723; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(189002)(377424004)(199003)(13464003)(31014005)(377454003)(305945005)(7736002)(7696003)(66066001)(99286002)(8936002)(81166006)(19580405001)(81156014)(1730700003)(74316002)(7846002)(9686002)(87936001)(77096005)(2900100001)(2950100001)(8676002)(105586002)(5002640100001)(106116001)(450100001)(2501003)(106356001)(54356999)(76176999)(50986999)(3660700001)(10090500001)(33656002)(2906002)(10290500002)(5005710100001)(10400500002)(101416001)(3280700002)(110136002)(107886002)(122556002)(5640700001)(189998001)(230783001)(19580395003)(97736004)(92566002)(86612001)(15975445007)(2351001)(76576001)(8990500004)(68736007)(586003)(5660300001)(3846002)(102836003)(86362001)(6116002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2723; H:BN6PR03MB2724.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 21:22:01.8839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2723 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 21:22:07 -0000 -04 addresses all the issues discussed at IETF 96 - with the exception of h= ttps://github.com/core-wg/coap-tcp-tls/issues/5. The authors are discussing= the scope for a section related to RFC7641 (Observing resources ...). In addition, I opened a new issue related to mandatory exchange of CSM - ht= tps://github.com/core-wg/coap-tcp-tls/issues/58 - where feedback would be h= elpful. Both of these issues are targeted for -05. ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Wednesday, August 24, 2016 2:09 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments of the IE= TF. Title : CoAP (Constrained Application Protocol) over TCP,= TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-04.txt Pages : 42 Date : 2016-08-24 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-tcp-tls-04 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 24 14:22:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DE812D756 for ; Wed, 24 Aug 2016 14:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT-f_BoVQmWe for ; Wed, 24 Aug 2016 14:22:50 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 1984312D124 for ; Wed, 24 Aug 2016 14:22:49 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 74so51784085uau.0 for ; Wed, 24 Aug 2016 14:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CxbsYuoJtuyPBqGrJbbW6XtBW88wtKzZFqjdEfY4L7Y=; b=ROYO5X5EN36RwcSRyxT6cMmMOntWS001kHcoJjLOizdUhLLoLdmXzmAWNhyEoEHEje wZFda5MPyn+jo7KZPG9uEr3vLhIqQRQ5OsQZs2XfB93Y6Hc5lWi+bg3tpsCUmsgnPiOX KPTdnjvmxmD9e/L/Lq547MNFrI5G/Fkgf950bScTzS3redFb9ZWoNgJhZyPPHoZkMC26 2ia85a+P8jy+bMSRIWs0nRTZL+I9kOGAExuIkAIQmbT1kid43FHcTRQmlMCg9fsUz266 EqK7wArQTg4U3r40VSZ/RorspN323jBji0UgujMiaxn/yMja2RmuGEcoE23SyoZ6gquY Y02Q== 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:from:date :message-id:subject:to:cc; bh=CxbsYuoJtuyPBqGrJbbW6XtBW88wtKzZFqjdEfY4L7Y=; b=Nc5FPnNctCdY7aaPafQXgig8RA2LG/YvInRG1jjT6Q1bziyeX6oSO1g5Qk5Etuqbf9 jai5+B9BoxNVO4jTH/Plpdvru2O2BvJ2gn3hmglXMV9XS/o/PEMUxjk0hCeQ5S3On0cw g9w+d3MLefrm/3dthWCFJX4YRt4YRakXVLxghipBWmQcB/Rf/b6FVtoswArBDhptP40v iHZm9mxfSrNd6p4YBX3pj2+HjWhmzm155qBFBOl5ePuSzJ7r4/UD6nowbf+C2qMYri5/ TK3L1bBc/EAWP46RSYKttk42C+PkU93M+e0IBoW4Z7tsrGVGX7qRDHwy+OAaW0Ktc9Nz hdZg== X-Gm-Message-State: AEkoouuep4zfieN25YJLaA0309eNKCaLG1wmYiHe3KlBeG7DrnlRHJh3Chwi+tuqUqd3rXqaFTIn0gStdYUvKw== X-Received: by 10.31.139.207 with SMTP id n198mr3001678vkd.121.1472073768185; Wed, 24 Aug 2016 14:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Wed, 24 Aug 2016 14:22:47 -0700 (PDT) In-Reply-To: <20160824203526.3B9B45213C4@rh7.snmp.com> References: <20160824203526.3B9B45213C4@rh7.snmp.com> From: Andy Bierman Date: Wed, 24 Aug 2016 14:22:47 -0700 Message-ID: To: David Reid Content-Type: multipart/alternative; boundary=001a114584d009478b053ad7e218 Archived-At: Cc: Core Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 21:22:53 -0000 --001a114584d009478b053ad7e218 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 1:35 PM, David Reid wrote: > I read draft-bierman-core-yid-00.txt and have a few questions. > > Will all IETF standard yang modules be included in the YANG identifier > registry or just ones that might be used on constrained devices? > I think all modules. We want to support unconstrained devices on constrained networks. > > In order to assign numbers, is it correct that I need the first revision of > the module or else the current revision and the registry assignments for > the > previous revision? > I think in all numbering schemes (as Michel pointed out) you need the current registration entry and the new module revision. > > What is the benefit of assigning values using hashing over sequentially > assigning values? > There is overhead ir reading and processing a giant list of mappings. Automatic assignment is risky because both sides need to agree on the object to number mapping. Detecting these issues is very difficult. The YANG Hash algorithm is designed to use the path string, which is permanent and cannot change no matter how the YANG is refactored. The murmur hash is a stable algorithm. There is not a lot that can go wrong for the 2 peers to disagree on the hashes (except for collisions) > > When there is a hash collision, would it be possible to rehash the value > to get a unique number so that we never have to manually assign numbers and > thus never need to register the numbers in the registry? > yes, this has been suggested. The problem with auto-rehashing before was inter-module clashes. Now those are not possible so automatic rehashing is feasible. > > Why does module-id need to be added to the YANG module names registry since > it is also in the YANG identifier registry? > I guess it is not needed since the module name is in both registries already > > Would it make sense to put the module-id inside the yang module with a yid > extension so that I would not have to go lookup that information from a > registry? > I suppose -- but how to prevent duplicates and cut-and-paste errors? > > Would it be possible to assign the module-id based on information in the > module, for example a hash of the namespace and maybe the revision date. > That way, a module-id would not have to be assigned and maintained in a > registry. > > I think private module-id would be better, using a range reserved for temporary assignments. How do you resolve hash collisions for module-id? > If I want to handle private modules, do I have to create my own registry? > It seems important that private modules be supported. Could we re-use the > SMI enterprise number assignments for creating module-ids for private > modules? > The ietf-yid module has a schema for the entire registry. How to use the registry is a protocol issue that needs to be decided. If the server advertises its own registry vs. a public registry, then it is using a private registry. If all devices in the system agree on which registry to use, then everything works. > Who will assign the local-id numbers? Is that done by the working group > that > defines the YANG module? > I would expect IETF modules to use hashes by default but for some modules that seem useful to constrained devices, then manual numbering could be done instead by the WG. > > -David Reid > Andy > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a114584d009478b053ad7e218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 24, 2016 at 1:35 PM, David Reid <reid@snmp.com> = wrote:
I read draft-bierman-core-yid-00.t= xt and have a few questions.

Will all IETF standard yang modules be included in the YANG identifier
registry or just ones that might be used on constrained devices?


I think all modules.
We = want to support unconstrained devices on constrained networks.

=C2=A0

In order to assign numbers, is it correct that I need the first revision of=
the module or else the current revision and the registry assignments for th= e
previous revision?


I thi= nk in all numbering schemes (as Michel pointed out) you need
the = current registration entry and the new module revision.

=C2=A0

What is the benefit of assigning values using hashing over sequentially
assigning values?

There is overhead ir = reading and processing a giant list of mappings.
Automatic assign= ment is risky because both sides need to agree on
the object to n= umber mapping.=C2=A0 Detecting these issues is very difficult.
The YANG Hash algorithm is designed to use the path string,
which is permanent and cannot change no matter how the
YA= NG is refactored.=C2=A0 The murmur hash is a stable algorithm.
Th= ere is not a lot that can go wrong for the 2 peers to disagree
on= the hashes (except for collisions)
=C2=A0

When there is a hash collision, would it be possible to rehash the value to get a unique number so that we never have to manually assign numbers and=
thus never need to register the numbers in the registry?


yes, this has been suggested.
Th= e problem with auto-rehashing before was inter-module clashes.
No= w those are not possible so automatic rehashing is feasible.
=C2= =A0

Why does module-id need to be added to the YANG module names registry since=
it is also in the YANG identifier registry?
=C2=A0

I guess it is not needed since the module name is in = both registries already

=C2=A0

Would it make sense to put the module-id inside the yang module with a yid<= br> extension so that I would not have to go lookup that information from a
registry?


I suppose -- b= ut how to prevent duplicates and cut-and-paste errors?
=C2=A0

Would it be possible to assign the module-id based on information in the module, for example a hash of the namespace and maybe the revision date. That way, a module-id would not have to be assigned and maintained in a
registry.



I think private module-= id would be better, using a range reserved for temporary
assignme= nts.

How do you resolve hash collisions for module= -id?

=C2=A0
If I want to handle private modules, do I have to create my own registry? It seems important that private modules be supported. Could we re-use the SMI enterprise number assignments for creating module-ids for private modul= es?

The ietf-yid module has a schema fo= r the entire registry.
How to use the registry is a protocol issu= e that needs to be decided.
If the server advertises =C2=A0its ow= n registry vs. a public registry,
then it is using a private = registry.=C2=A0 If all devices in the system agree
on which regis= try to use, then everything works.


Who will assign the local-id numbers? Is that done by the working group tha= t
defines the YANG module?

I would expect= IETF modules to use hashes by default but for
some modules that = seem useful to constrained devices, then
manual numbering could b= e done instead by the WG.
=C2=A0

-David Reid

Andy
=C2=A0
=

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

--001a114584d009478b053ad7e218-- From nobody Wed Aug 24 15:34:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DF812D797 for ; Wed, 24 Aug 2016 15:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWSQfxoRRFAI for ; Wed, 24 Aug 2016 15:34:08 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 9E40112B00E for ; Wed, 24 Aug 2016 15:34:08 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 74so54458515uau.0 for ; Wed, 24 Aug 2016 15:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rXMYm8GYuSHrXq8s1Yxs/TejHoFR1ORlUkV8E5zfkjY=; b=a1D+zdOaD611sKb2EWs3mS4b4XtoqCHWB7rsGphQqrkvYtbb39qUn7CZYRPkrrCTE3 ShDIVBrm3oavCQaqV8BZjMKPdGlTRWYJOVCD1/JlQoAiOg+J6ccnQJwhIdkXKkTMTFCx pHeWLz1WaSaPFlt3foKlJvsTqcytG/GC3Fop148ExCVwge1au/OslHBi6DTmPsYSo038 OyFvWerRzDlwTIB7wNWidL9PdJX3q997SNcZshqhi0hCjUYnFQcHD8QfEQ01hKLfd5hR h8msV9W8CLweJwgVpxz3/lCJseWaCWGdqIzsDz4ktuXftYxwUosW014WrkTmbyEO4U79 kX6A== 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:from:date :message-id:subject:to:cc; bh=rXMYm8GYuSHrXq8s1Yxs/TejHoFR1ORlUkV8E5zfkjY=; b=D+0ReWKHmS2P9E/+9VuWk9krZ0gYrMD/c7FVAlD0yaAeyD8rB1iHw0mAe1lG8b2Ek+ JzJ9SaO1AEL+g4oP8uOncZkPGJzbw2Y9dvHdi/fodr9sNf/gqHIG7lgbaXMzqPaWDehv 5PTRUqL1E/5SNaRCSLjHIzaEdb4z6MXv8WKzv5f42SDb+8Groi8hUAUEEt4iX9ITDkhX 236cKw7E7yqCKn5qR0gimaWoS9DSg8uecTLyGypqV8Nbx1HguE6SXeJDk1DQWFKKqYfZ ec+IWn7VQDYl4ImEWSyuAMO8cePkvLy8ifBz06c3yLXqNaEblTd/bnZMCmPJ5DwLeM32 fOeA== X-Gm-Message-State: AEkooustrnfqq3TLuXCLzfNa+HZowGNMYV5sB91jg5OO48fmxqnR7hVpq0Pss8ME7w5ATwmkd6KNI0+1WUOysA== X-Received: by 10.176.68.166 with SMTP id n35mr3206451uan.47.1472078047737; Wed, 24 Aug 2016 15:34:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Wed, 24 Aug 2016 15:34:07 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 24 Aug 2016 15:34:07 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=94eb2c05c5de1e0efd053ad8e114 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-bierman-core-yid-00 open questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 22:34:11 -0000 --94eb2c05c5de1e0efd053ad8e114 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2016 at 2:09 PM, Michel Veillette wrote: > Hi Andy > > > > My comments inline [MV] > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Wednesday, August 24, 2016 4:48 PM > *To:* Michel Veillette > *Cc:* core@ietf.org WG > *Subject:* Re: draft-bierman-core-yid-00 open questions > > > > > > > > On Wed, Aug 24, 2016 at 9:53 AM, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > Hi Andy > > Following if my answers to the questions listed in > draft-bierman-core-yid-00 > > 1) When to assign a module-id > > Developers should be in control of when this activity is performed based > on the estimated amount of work required to reassign IDs (from temporary > assigned IDs within the experimental range to the final IDs) and the > impacts on the encoding efficiency of assigning a non stable list of YANG > items which generate non sequential IDs. If the developer already own a > range of YID/SID, the activity can be perform at any time. > > It is important to note that the registration of the resulting .sid > file(s) is done independently of the registration of the SID range. When > registering a SID range, the module or list of modules targeted is not > provided. This give the full freedom to developers to assign IDs when > needed. > > > > I think the registration process issues are the same whether a module-id > or a range is allocated. > > > > [MV] Not exactly, registering a module-id imply that you need to know the > module information in advance. > > [MV] If you register a range, you can assign this range as needed to one > or multiple modules. > > [MV] You don=E2=80=99t need to go back to the registrar each time you cre= ate a new > module. > > > But it's not like anybody can use the numbers without knowing how they are assigned. Andy 2) How to support private numbering > > A range called "Experimental" spanning both the 16 and 32 bits unsigned > integer have been assigned to this purpose. > https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-7.1 > > > > > > Yes, it seems trivial to assign a range for temporary numbers. > > > > > > > > 3) How to combine registries > > Not needed, all registrars, SDO shall receive a specific range from IANA. > > > > > > OK, so there is a tiered registration process? > > And there will not be a land-grab for all the numbers? > > Not clear to me how IANA approves allocation requests. > > > > > > > 4) Should more YANG statements be numbered > > Yes > rpc, action, notification, module, submodule, feature > > > > Numbering submodule and feature? > > These are conceptual statements within the schema language and > > do not affect anything on the wire. > > > > [MV] SID assigned to submodules and features are required to support > discovery > > [MV] See https://tools.ietf.org/html/draft-veillette-core-cool-librar > y-00#section-3.1 > > > > 5a) How to support anyxml > > anyxml represents a single data node with an arbitrary content. > This data node have a single ID assigned to it the same way as any other > data node, nothing special is required. > > > > > > anyxml foo; > > > > > > { "foo" : { > > "bar": 42; > > "baz" "fred", > > "a-list" : [ > > .... > > ] > > } > > } > > > > > > So what numbers do you give to bar,, baz, a-list, etc.? > > They are all numbered the same as foo? > > That will be decoded with all nodes named foo, all anyxml. > > The name, type, value info contained in anyxml and anydata > > instances have no schema. These nodes cannot be numbered. > > This is a YANG-to-CBOR issue, not a SID issue. > > > > But in real YANG these child nodes sometimes represent real objects > > from some other module. In this case the server may know the "hidden SID= ". > > > > http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 > > > > [MV] If the inner members of this CBOR map need to associated to SID, the > developer will need to assign these SIDs as described in 5b. > > [MV] If this is the case, the author should have used an anydata. > > [MV] Normally, an anyxml contain an arbitrary CBOR content which have > nothing to do with YANG and SIDs. > > [MV] This is the approach proposed by "draft-ietf-netmod-yang-json" and > reused by "draft-ietf-core-yang-cbor" > > > > > > 5b) How to support anydata > > The anydata define an instance of an unspecified schema node (leaf, > leaf-list, container, list). > All possible schema node supported by an anydata need to be register to > one of the .sid files. > It is the responsibility of the developer(s) to add these SIDs to one or > multiple .sid files manually if not already present. > A section need to be added to the draft to clearly describe this approach= . > > Regards, > Michel Veillette > > > > > > Andy > > > --94eb2c05c5de1e0efd053ad8e114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 24, 2016 at 2:09 PM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:

Hi Andy

=C2=A0

My comments inline [MV]

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Wednesday, August 24, 2016 4:48 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com><= br> Cc: core@ietf.org= WG <core@ietf.or= g>
Subject: Re: draft-bierman-core-yid-00 open questions<= /span>

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 24, 2016 at 9:53 AM, Michel Veillette &l= t;Mi= chel.Veillette@trilliantinc.com> wrote:

Hi Andy

Following if my answers to the questions listed in draft-bierman-core-yid-0= 0

1) When to assign a module-id

Developers should be in control of when this activity is performed based on= the estimated amount of work required to reassign IDs (from temporary assi= gned IDs within the experimental range to the final IDs) and the impacts on= the encoding efficiency of assigning a non stable list of YANG items which generate non sequential IDs. If the = developer already own a range of YID/SID, the activity can be perform at an= y time.

It is important to note that the registration of the resulting .sid file(s)= is done independently of the registration of the SID range. When registeri= ng a SID range, the module or list of modules targeted is not provided. Thi= s give the full freedom to developers to assign IDs when needed.

=C2=A0

I think the registration process issues are the same= whether a module-id or a range is allocated.

=C2=A0

[MV] Not exactly, registering a module-id imply tha= t you need to know the module information in advance.<= /p>

[MV] If you register a range, you can assign this r= ange as needed to one or multiple modules.

[MV] You don=E2=80=99t need to go back to the regis= trar each time you create a new module.

=C2=A0


But it's not like anybody can use the= numbers without knowing how they are assigned.

Andy

2) How to support private numbering

A range called "Experimental" spanning both the 16 and 32 bits un= signed integer have been assigned to this purpose.
https://tools.ietf.org/html/draft-somaraju-core-= sid-01#section-7.1

=C2=A0

=C2=A0

Yes, it seems trivial to assign a range for temporar= y numbers.

=C2=A0

=C2=A0



3) How to combine registries

Not needed, all registrars, SDO shall receive a specific range from IANA.

=C2=A0

=C2=A0

OK, so there is a tiered registration process?

And there will not be a land-grab for all the number= s?

Not clear to me how IANA approves allocation request= s.

=C2=A0

=C2=A0


4) Should more YANG statements be numbered

Yes
rpc, action, notification, module, submodule, feature

=C2=A0

Numbering submodule and feature?

These are conceptual statements within the schema la= nguage and

do not affect anything on the wire.

=C2=A0

[MV] SID assigned to submodules and features are re= quired to support discovery

[MV] See https://tools.ietf.org/html/draft-veillette-core-cool-library-00#= section-3.1

=C2=A0

5a) How to support an= yxml

anyxml represents a single data node with an arbitrary content.
This data node have a single ID assigned to it the same way as any other da= ta node, nothing special is required.

=C2=A0

=C2=A0

=C2=A0 =C2=A0 anyxml foo;

=C2=A0

=C2=A0

=C2=A0 =C2=A0 { "foo" : {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"bar": 4= 2;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"baz" &q= uot;fred",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"a-list"= : [

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ....

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]

=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0}

=C2=A0

=C2=A0

So what numbers do you give to bar,, baz, a-list, et= c.?

They are all numbered the same as foo?=

That will be decoded with all nodes named foo, all a= nyxml.

The name, type, value info contained in anyxml and a= nydata

instances have no schema.=C2=A0 These nodes cannot b= e numbered.

This is a YANG-to-CBOR issue, not a SID issue.

=C2=A0

But in real YANG these child nodes sometimes represe= nt real objects

from some other module.=C2=A0 In this case the serve= r may know the "hidden SID".

=C2=A0

=C2=A0

[MV] If the inner members of this CBOR map need to a= ssociated to SID, the developer will need to assign these SIDs as described= in 5b.

[MV] If this is the case, the author should have use= d an anydata.

[MV] Normally, an anyxml contain an arbitrary CBOR c= ontent which have nothing to do with YANG and SIDs.

[MV] This is the approach proposed by "draft-ie= tf-netmod-yang-json" and reused by "draft-ietf-core-yang-cbor&quo= t;

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0

5b) How to support an= ydata

The anydata define an instance of an unspecified schema node (leaf, leaf-li= st, container, list).
All possible schema node supported by an anydata need to be register to one= of the .sid files.
It is the responsibility of the developer(s) to add these SIDs to one or mu= ltiple .sid files manually if not already present.
A section need to be added to the draft to clearly describe this approach.<= br>
Regards,
Michel Veillette

=C2=A0

=C2=A0

Andy

=C2=A0


--94eb2c05c5de1e0efd053ad8e114-- From nobody Wed Aug 24 16:22:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3C412D1E0 for ; Wed, 24 Aug 2016 16:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfvIilG9QHw6 for ; Wed, 24 Aug 2016 16:22:48 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0103.outbound.protection.outlook.com [104.47.33.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2D712D144 for ; Wed, 24 Aug 2016 16:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nuMQzv3lZkyVJadYjIS0snhvVoDs5hVovqc20QBu7UE=; b=PVEFNj6wk9vpMCKS2yPXet4GGYvVLG4iB3l/j/gkznOC6KILgKj47hkn6uYkAweOrAB3I/pH4ftiUGdF0ucylzoDEc0ZBn8oMVHuor22TUfVtenTr0dPYbT98BkPNA8JcUEe2rbdL+vHKgi4M7ePj+d7ljTkHLn1BDqLOiGKtFg= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 24 Aug 2016 23:22:45 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 23:22:44 +0000 From: Michel Veillette To: Andy Bierman , David Reid Thread-Topic: [core] draft-bierman-core-yid-00.txt questions Thread-Index: AQHR/kcOnsXgBk9RvEWD4CzBgA9zo6BYnsOAgAAdH0A= Date: Wed, 24 Aug 2016 23:22:43 +0000 Message-ID: References: <20160824203526.3B9B45213C4@rh7.snmp.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: 7a4dd038-d989-4a48-027a-08d3cc758d36 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:iJlcpsmeejnXzfvzHk3zUIsu9wfYd6z1AVflrbvNoDVXne4Aj9OViG7TAVTPQutTrH9Z2/BnEhtUtHdHzTqAJCixDrzHEWxGE1P9aDJyTUEfksMpeEXZEypdodgt5ttpnii7LAtkkIuuq+GxEiXNsvjuYeHCL7zZHrzfL8xhYuUixjSWEb3fskaDjHZbvYgr6u+yYjPckeD34QaX+QUsOrubD2bFiYyLjsnNqrEh3DLgA+PgJ9gsCN0uZK64x5P8eoELtdLMKQjuMUv/Y9rZt1cDN6hwsK6G1P//v7i6cCk=; 5:r9/PyMc+O2srTNpEESKJ207Jo2jN65W0dHYN42uKK1opGubQb1xk74XLJm5nE73oYtM0CA0sNTP0RYA7jRjGsWPgGhqQtwoiIJSbAvKD2TLD+AI9PedyweTh+VVXHGDoORRam+ZhGJMllMlPBzCs4w==; 24:486U1jeu4N4ndbHK4ZRvy8h8ApP9BMHCgK9GHsW6cQqhj/G+YT3GTfWNjMMIpkmzntYmvuFObeo76P1eUZX9gTR95Q/KDtU/Fyuc0BL7L+k=; 7:DJcmOggdZXQHzV65Zd+/zU+7FwUMqRR5KXxPKzOq2KCe0zAh0NYryHcWYAQ0EiZE1Zv+pVNFk9DmeC6bM8z/ucjr05k6R7u84wBo5Pp4oH2ZV5ZKahnw6ve8JcVc2h2wGlFT7BYQAWJNQqxz7n4PeigylqpHu0U+VVMg2NztQkbI0+wOOWFjI+UxvEmctZHkjxBFN2D6HEZb2SfPI+nmT6orNpHBcMdxkBn3MNrbc0MSjq8CqGbG66R/xNTtwSCF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(51884002)(377454003)(199003)(68736007)(2906002)(77096005)(106116001)(105586002)(5660300001)(122556002)(3660700001)(3280700002)(7846002)(7696003)(6116002)(586003)(19609705001)(5002640100001)(8676002)(7736002)(790700001)(9686002)(81166006)(74316002)(81156014)(106356001)(8936002)(230783001)(10400500002)(66066001)(99286002)(7906003)(3846002)(19300405004)(102836003)(16236675004)(19580405001)(2900100001)(19617315012)(19625215002)(92566002)(2950100001)(189998001)(76176999)(50986999)(15975445007)(19580395003)(97736004)(101416001)(87936001)(5001770100001)(54356999)(76576001)(4326007)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308A46F6A84378832DBC849FEEA0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 23:22:43.9817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 23:22:51 -0000 --_000_BN6PR06MB2308A46F6A84378832DBC849FEEA0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsIEhpIEFuZHkNCg0KW01WXSBJbmxpbmUNCg0KRnJvbTogY29yZSBbbWFpbHRvOmNv cmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgNToyMyBQTQ0KVG86IERhdmlkIFJlaWQgPHJlaWRAc25t cC5jb20+DQpDYzogQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gZHJh ZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQgcXVlc3Rpb25zDQoNCg0KDQpPbiBXZWQsIEF1ZyAy NCwgMjAxNiBhdCAxOjM1IFBNLCBEYXZpZCBSZWlkIDxyZWlkQHNubXAuY29tPG1haWx0bzpyZWlk QHNubXAuY29tPj4gd3JvdGU6DQpJIHJlYWQgZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQg YW5kIGhhdmUgYSBmZXcgcXVlc3Rpb25zLg0KDQpXaWxsIGFsbCBJRVRGIHN0YW5kYXJkIHlhbmcg bW9kdWxlcyBiZSBpbmNsdWRlZCBpbiB0aGUgWUFORyBpZGVudGlmaWVyDQpyZWdpc3RyeSBvciBq dXN0IG9uZXMgdGhhdCBtaWdodCBiZSB1c2VkIG9uIGNvbnN0cmFpbmVkIGRldmljZXM/DQoNCg0K SSB0aGluayBhbGwgbW9kdWxlcy4NCldlIHdhbnQgdG8gc3VwcG9ydCB1bmNvbnN0cmFpbmVkIGRl dmljZXMgb24gY29uc3RyYWluZWQgbmV0d29ya3MuDQoNCltNVl0gVGhlIHJlcXVlc3Qgd2UgZ290 IHNvIGZhciBpcyBhbGwgWUFORyBtb2R1bGVzIHB1Ymxpc2hlZCBpbiBSRkNzLg0KDQoNCkluIG9y ZGVyIHRvIGFzc2lnbiBudW1iZXJzLCBpcyBpdCBjb3JyZWN0IHRoYXQgSSBuZWVkIHRoZSBmaXJz dCByZXZpc2lvbiBvZg0KdGhlIG1vZHVsZSBvciBlbHNlIHRoZSBjdXJyZW50IHJldmlzaW9uIGFu ZCB0aGUgcmVnaXN0cnkgYXNzaWdubWVudHMgZm9yIHRoZQ0KcHJldmlvdXMgcmV2aXNpb24/DQoN Cg0KSSB0aGluayBpbiBhbGwgbnVtYmVyaW5nIHNjaGVtZXMgKGFzIE1pY2hlbCBwb2ludGVkIG91 dCkgeW91IG5lZWQNCnRoZSBjdXJyZW50IHJlZ2lzdHJhdGlvbiBlbnRyeSBhbmQgdGhlIG5ldyBt b2R1bGUgcmV2aXNpb24uDQoNCg0KDQpXaGF0IGlzIHRoZSBiZW5lZml0IG9mIGFzc2lnbmluZyB2 YWx1ZXMgdXNpbmcgaGFzaGluZyBvdmVyIHNlcXVlbnRpYWxseQ0KYXNzaWduaW5nIHZhbHVlcz8N Cg0KVGhlcmUgaXMgb3ZlcmhlYWQgaXIgcmVhZGluZyBhbmQgcHJvY2Vzc2luZyBhIGdpYW50IGxp c3Qgb2YgbWFwcGluZ3MuDQpBdXRvbWF0aWMgYXNzaWdubWVudCBpcyByaXNreSBiZWNhdXNlIGJv dGggc2lkZXMgbmVlZCB0byBhZ3JlZSBvbg0KdGhlIG9iamVjdCB0byBudW1iZXIgbWFwcGluZy4g IERldGVjdGluZyB0aGVzZSBpc3N1ZXMgaXMgdmVyeSBkaWZmaWN1bHQuDQoNClRoZSBZQU5HIEhh c2ggYWxnb3JpdGhtIGlzIGRlc2lnbmVkIHRvIHVzZSB0aGUgcGF0aCBzdHJpbmcsDQp3aGljaCBp cyBwZXJtYW5lbnQgYW5kIGNhbm5vdCBjaGFuZ2Ugbm8gbWF0dGVyIGhvdyB0aGUNCllBTkcgaXMg cmVmYWN0b3JlZC4gIFRoZSBtdXJtdXIgaGFzaCBpcyBhIHN0YWJsZSBhbGdvcml0aG0uDQpUaGVy ZSBpcyBub3QgYSBsb3QgdGhhdCBjYW4gZ28gd3JvbmcgZm9yIHRoZSAyIHBlZXJzIHRvIGRpc2Fn cmVlDQpvbiB0aGUgaGFzaGVzIChleGNlcHQgZm9yIGNvbGxpc2lvbnMpDQoNCg0KV2hlbiB0aGVy ZSBpcyBhIGhhc2ggY29sbGlzaW9uLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byByZWhhc2ggdGhl IHZhbHVlDQp0byBnZXQgYSB1bmlxdWUgbnVtYmVyIHNvIHRoYXQgd2UgbmV2ZXIgaGF2ZSB0byBt YW51YWxseSBhc3NpZ24gbnVtYmVycyBhbmQNCnRodXMgbmV2ZXIgbmVlZCB0byByZWdpc3RlciB0 aGUgbnVtYmVycyBpbiB0aGUgcmVnaXN0cnk/DQoNCg0KeWVzLCB0aGlzIGhhcyBiZWVuIHN1Z2dl c3RlZC4NClRoZSBwcm9ibGVtIHdpdGggYXV0by1yZWhhc2hpbmcgYmVmb3JlIHdhcyBpbnRlci1t b2R1bGUgY2xhc2hlcy4NCk5vdyB0aG9zZSBhcmUgbm90IHBvc3NpYmxlIHNvIGF1dG9tYXRpYyBy ZWhhc2hpbmcgaXMgZmVhc2libGUuDQoNCltNVl0gSSBkaXNhZ3JlZSwgc2VlIG15IHByZXZpb3Vz IGVtYWlsIHdoaWNoIGV4cGxhaW4gd2h5IGFsbCBZSURzL1NJRHMgbmVlZCB0byBiZSByZWdpc3Rl cmVkIGV2ZW4gaWYgZ2VuZXJhdGVkIHVzaW5nIGEgaGFzaC4NCg0KDQpXaHkgZG9lcyBtb2R1bGUt aWQgbmVlZCB0byBiZSBhZGRlZCB0byB0aGUgWUFORyBtb2R1bGUgbmFtZXMgcmVnaXN0cnkgc2lu Y2UNCml0IGlzIGFsc28gaW4gdGhlIFlBTkcgaWRlbnRpZmllciByZWdpc3RyeT8NCg0KDQpJIGd1 ZXNzIGl0IGlzIG5vdCBuZWVkZWQgc2luY2UgdGhlIG1vZHVsZSBuYW1lIGlzIGluIGJvdGggcmVn aXN0cmllcyBhbHJlYWR5DQoNCg0KDQpXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHB1dCB0aGUgbW9k dWxlLWlkIGluc2lkZSB0aGUgeWFuZyBtb2R1bGUgd2l0aCBhIHlpZA0KZXh0ZW5zaW9uIHNvIHRo YXQgSSB3b3VsZCBub3QgaGF2ZSB0byBnbyBsb29rdXAgdGhhdCBpbmZvcm1hdGlvbiBmcm9tIGEN CnJlZ2lzdHJ5Pw0KDQoNCkkgc3VwcG9zZSAtLSBidXQgaG93IHRvIHByZXZlbnQgZHVwbGljYXRl cyBhbmQgY3V0LWFuZC1wYXN0ZSBlcnJvcnM/DQoNCltNVl0gSnVzdCBhZGRpbmcgdGhlIG1vZHVs ZSBJRCBpbiB0aGUgeWFuZyBmaWxlIGlzIG5vdCBzdWZmaWNpZW50IHRvIHVzZSBhIC55YW5nIGZp bGUsIGFsbCBZSURzL1NJRHMgbmVlZCB0byBiZSBhZGRlZC4NCltNVl0gSGF2aW5nIFlJRHMvU0lE cyBpbiB5YW5nIGZpbGVzIHdpbGwgbWFrZSB0aGVpciBtYWludGVuYW5jZSBtb3JlIGNvbXBsZXgu DQpbTVZdIEJUVywgYSBweWFuZyBwbHVnaW4gYWxyZWFkeSBleGlzdCB0byBhdXRvbWF0aWNhbGx5 IGdlbmVyYXRlIGFuZCB1cGRhdGUgYSAuc2lkIGZpbGUgZnJvbSBhIC55YW5nIGZpbGUNCltNVl0g U2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3lhbmctY2Jvci9ibG9iL21hc3Rlci9zaWQu cHkNCg0KDQpXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhc3NpZ24gdGhlIG1vZHVsZS1pZCBiYXNl ZCBvbiBpbmZvcm1hdGlvbiBpbiB0aGUNCm1vZHVsZSwgZm9yIGV4YW1wbGUgYSBoYXNoIG9mIHRo ZSBuYW1lc3BhY2UgYW5kIG1heWJlIHRoZSByZXZpc2lvbiBkYXRlLg0KVGhhdCB3YXksIGEgbW9k dWxlLWlkIHdvdWxkIG5vdCBoYXZlIHRvIGJlIGFzc2lnbmVkIGFuZCBtYWludGFpbmVkIGluIGEN CnJlZ2lzdHJ5Lg0KDQoNCkkgdGhpbmsgcHJpdmF0ZSBtb2R1bGUtaWQgd291bGQgYmUgYmV0dGVy LCB1c2luZyBhIHJhbmdlIHJlc2VydmVkIGZvciB0ZW1wb3JhcnkNCmFzc2lnbm1lbnRzLg0KDQpI b3cgZG8geW91IHJlc29sdmUgaGFzaCBjb2xsaXNpb25zIGZvciBtb2R1bGUtaWQ/DQoNCg0KSWYg SSB3YW50IHRvIGhhbmRsZSBwcml2YXRlIG1vZHVsZXMsIGRvIEkgaGF2ZSB0byBjcmVhdGUgbXkg b3duIHJlZ2lzdHJ5Pw0KSXQgc2VlbXMgaW1wb3J0YW50IHRoYXQgcHJpdmF0ZSBtb2R1bGVzIGJl IHN1cHBvcnRlZC4gQ291bGQgd2UgcmUtdXNlIHRoZQ0KU01JIGVudGVycHJpc2UgbnVtYmVyIGFz c2lnbm1lbnRzIGZvciBjcmVhdGluZyBtb2R1bGUtaWRzIGZvciBwcml2YXRlIG1vZHVsZXM/DQoN ClRoZSBpZXRmLXlpZCBtb2R1bGUgaGFzIGEgc2NoZW1hIGZvciB0aGUgZW50aXJlIHJlZ2lzdHJ5 Lg0KSG93IHRvIHVzZSB0aGUgcmVnaXN0cnkgaXMgYSBwcm90b2NvbCBpc3N1ZSB0aGF0IG5lZWRz IHRvIGJlIGRlY2lkZWQuDQpJZiB0aGUgc2VydmVyIGFkdmVydGlzZXMgIGl0cyBvd24gcmVnaXN0 cnkgdnMuIGEgcHVibGljIHJlZ2lzdHJ5LA0KdGhlbiBpdCBpcyB1c2luZyBhIHByaXZhdGUgcmVn aXN0cnkuICBJZiBhbGwgZGV2aWNlcyBpbiB0aGUgc3lzdGVtIGFncmVlDQpvbiB3aGljaCByZWdp c3RyeSB0byB1c2UsIHRoZW4gZXZlcnl0aGluZyB3b3Jrcy4NCg0KDQpXaG8gd2lsbCBhc3NpZ24g dGhlIGxvY2FsLWlkIG51bWJlcnM/IElzIHRoYXQgZG9uZSBieSB0aGUgd29ya2luZyBncm91cCB0 aGF0DQpkZWZpbmVzIHRoZSBZQU5HIG1vZHVsZT8NCg0KSSB3b3VsZCBleHBlY3QgSUVURiBtb2R1 bGVzIHRvIHVzZSBoYXNoZXMgYnkgZGVmYXVsdCBidXQgZm9yDQpzb21lIG1vZHVsZXMgdGhhdCBz ZWVtIHVzZWZ1bCB0byBjb25zdHJhaW5lZCBkZXZpY2VzLCB0aGVuDQptYW51YWwgbnVtYmVyaW5n IGNvdWxkIGJlIGRvbmUgaW5zdGVhZCBieSB0aGUgV0cuDQoNCltNVl0gVG8gb2J0YWluIGEgc21h bGxlciBlbmNvZGluZywgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB0aGUgc2VxdWVudGlhbCBu dW1iZXJpbmcgd2lsbCBiZSB1c2VkLg0KW01WXSBXaXRoIHNlcXVlbnRpYWwgbnVtYmVyaW5nLCBh bGwgY3VycmVudCBZQU5HIG1vZHVsZXMgZGVmaW5lZCBpbiBSRkNzIGNhbiBiZSBhc3NpZ25lZCB3 aXRoaW4gdGhlIGZpcnN0IDY1MDAgU0lEcyB3aGljaCB3aWxsIGJlIGVuY29kZWQgYXMgMyBieXRl cyBmb3IgdGhlIGZpcnN0IHJlZmVyZW5jZSBhbmQgdHlwaWNhbGx5IGFzIDEgYnl0ZXMgZm9yIHRo ZSBmb2xsb3dpbmcgb25lcyB1c2luZyBkZWx0YSBlbmNvZGluZy4NCltNVl0gV2l0aCBoYXNoZXMs IG9ubHkgb25lIFlBTkcgbW9kdWxlIGNhbiBiZSBhc3NpZ25lZCB3aXRoaW4gdGhhdCByYW5nZS4N Cg0KDQotRGF2aWQgUmVpZA0KDQpBbmR5DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1h aWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQoNCg== --_000_BN6PR06MB2308A46F6A84378832DBC849FEEA0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBEYXZpZCwgSGkgQW5keTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gSW5saW5lPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g Y29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI0LCAyMDE2 IDU6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIFJlaWQgJmx0O3JlaWRAc25tcC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2NvcmVdIGRyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0IHF1ZXN0aW9u czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDI0LCAyMDE2IGF0IDE6MzUg UE0sIERhdmlkIFJlaWQgJmx0OzxhIGhyZWY9Im1haWx0bzpyZWlkQHNubXAuY29tIiB0YXJnZXQ9 Il9ibGFuayI+cmVpZEBzbm1wLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVhZCBkcmFmdC1iaWVybWFuLWNvcmUt eWlkLTAwLnR4dCBhbmQgaGF2ZSBhIGZldyBxdWVzdGlvbnMuPGJyPg0KPGJyPg0KV2lsbCBhbGwg SUVURiBzdGFuZGFyZCB5YW5nIG1vZHVsZXMgYmUgaW5jbHVkZWQgaW4gdGhlIFlBTkcgaWRlbnRp Zmllcjxicj4NCnJlZ2lzdHJ5IG9yIGp1c3Qgb25lcyB0aGF0IG1pZ2h0IGJlIHVzZWQgb24gY29u c3RyYWluZWQgZGV2aWNlcz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBhbGwgbW9kdWxlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdhbnQgdG8gc3VwcG9y dCB1bmNvbnN0cmFpbmVkIGRldmljZXMgb24gY29uc3RyYWluZWQgbmV0d29ya3MuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W01WXSBUaGUg cmVxdWVzdCB3ZSBnb3Qgc28gZmFyIGlzIGFsbCBZQU5HIG1vZHVsZXMgcHVibGlzaGVkIGluIFJG Q3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpJbiBvcmRlciB0byBhc3NpZ24gbnVtYmVycywgaXMgaXQgY29y cmVjdCB0aGF0IEkgbmVlZCB0aGUgZmlyc3QgcmV2aXNpb24gb2Y8YnI+DQp0aGUgbW9kdWxlIG9y IGVsc2UgdGhlIGN1cnJlbnQgcmV2aXNpb24gYW5kIHRoZSByZWdpc3RyeSBhc3NpZ25tZW50cyBm b3IgdGhlPGJyPg0KcHJldmlvdXMgcmV2aXNpb24/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaW4gYWxsIG51bWJl cmluZyBzY2hlbWVzIChhcyBNaWNoZWwgcG9pbnRlZCBvdXQpIHlvdSBuZWVkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgY3VycmVudCByZWdp c3RyYXRpb24gZW50cnkgYW5kIHRoZSBuZXcgbW9kdWxlIHJldmlzaW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCldo YXQgaXMgdGhlIGJlbmVmaXQgb2YgYXNzaWduaW5nIHZhbHVlcyB1c2luZyBoYXNoaW5nIG92ZXIg c2VxdWVudGlhbGx5PGJyPg0KYXNzaWduaW5nIHZhbHVlcz88bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG92ZXJoZWFk IGlyIHJlYWRpbmcgYW5kIHByb2Nlc3NpbmcgYSBnaWFudCBsaXN0IG9mIG1hcHBpbmdzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0b21hdGlj IGFzc2lnbm1lbnQgaXMgcmlza3kgYmVjYXVzZSBib3RoIHNpZGVzIG5lZWQgdG8gYWdyZWUgb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBv YmplY3QgdG8gbnVtYmVyIG1hcHBpbmcuJm5ic3A7IERldGVjdGluZyB0aGVzZSBpc3N1ZXMgaXMg dmVyeSBkaWZmaWN1bHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBZQU5HIEhhc2ggYWxnb3JpdGhtIGlzIGRlc2lnbmVkIHRvIHVzZSB0 aGUgcGF0aCBzdHJpbmcsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj53aGljaCBpcyBwZXJtYW5lbnQgYW5kIGNhbm5vdCBjaGFuZ2Ugbm8gbWF0dGVy IGhvdyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllBTkcgaXMgcmVmYWN0b3JlZC4mbmJzcDsgVGhlIG11cm11ciBoYXNoIGlzIGEgc3RhYmxl IGFsZ29yaXRobS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZXJlIGlzIG5vdCBhIGxvdCB0aGF0IGNhbiBnbyB3cm9uZyBmb3IgdGhlIDIgcGVl cnMgdG8gZGlzYWdyZWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPm9uIHRoZSBoYXNoZXMgKGV4Y2VwdCBmb3IgY29sbGlzaW9ucyk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K V2hlbiB0aGVyZSBpcyBhIGhhc2ggY29sbGlzaW9uLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBy ZWhhc2ggdGhlIHZhbHVlPGJyPg0KdG8gZ2V0IGEgdW5pcXVlIG51bWJlciBzbyB0aGF0IHdlIG5l dmVyIGhhdmUgdG8gbWFudWFsbHkgYXNzaWduIG51bWJlcnMgYW5kPGJyPg0KdGh1cyBuZXZlciBu ZWVkIHRvIHJlZ2lzdGVyIHRoZSBudW1iZXJzIGluIHRoZSByZWdpc3RyeT88bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+eWVzLCB0 aGlzIGhhcyBiZWVuIHN1Z2dlc3RlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9ibGVtIHdpdGggYXV0by1yZWhhc2hpbmcgYmVmb3Jl IHdhcyBpbnRlci1tb2R1bGUgY2xhc2hlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdyB0aG9zZSBhcmUgbm90IHBvc3NpYmxlIHNvIGF1dG9t YXRpYyByZWhhc2hpbmcgaXMgZmVhc2libGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W01WXSBJIGRpc2FncmVlLCBzZWUg bXkgcHJldmlvdXMgZW1haWwgd2hpY2ggZXhwbGFpbiB3aHkgYWxsIFlJRHMvU0lEcyBuZWVkIHRv IGJlIHJlZ2lzdGVyZWQgZXZlbiBpZiBnZW5lcmF0ZWQgdXNpbmcgYSBoYXNoLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KV2h5IGRvZXMgbW9kdWxlLWlkIG5lZWQgdG8gYmUgYWRkZWQgdG8gdGhlIFlBTkcgbW9k dWxlIG5hbWVzIHJlZ2lzdHJ5IHNpbmNlPGJyPg0KaXQgaXMgYWxzbyBpbiB0aGUgWUFORyBpZGVu dGlmaWVyIHJlZ2lzdHJ5PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIGl0IGlzIG5vdCBuZWVkZWQgc2luY2UgdGhl IG1vZHVsZSBuYW1lIGlzIGluIGJvdGggcmVnaXN0cmllcyBhbHJlYWR5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV291 bGQgaXQgbWFrZSBzZW5zZSB0byBwdXQgdGhlIG1vZHVsZS1pZCBpbnNpZGUgdGhlIHlhbmcgbW9k dWxlIHdpdGggYSB5aWQ8YnI+DQpleHRlbnNpb24gc28gdGhhdCBJIHdvdWxkIG5vdCBoYXZlIHRv IGdvIGxvb2t1cCB0aGF0IGluZm9ybWF0aW9uIGZyb20gYTxicj4NCnJlZ2lzdHJ5PzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHN1cHBvc2UgLS0gYnV0IGhvdyB0byBwcmV2ZW50IGR1cGxpY2F0ZXMgYW5kIGN1dC1hbmQtcGFz dGUgZXJyb3JzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gSnVzdCBhZGRpbmcgdGhlIG1vZHVsZSBJRCBpbiB0aGUg eWFuZyBmaWxlIGlzIG5vdCBzdWZmaWNpZW50IHRvIHVzZSBhIC55YW5nIGZpbGUsIGFsbCBZSURz L1NJRHMgbmVlZCB0byBiZSBhZGRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gSGF2aW5nIFlJRHMvU0lEcyBpbiB5YW5n IGZpbGVzIHdpbGwgbWFrZSB0aGVpciBtYWludGVuYW5jZSBtb3JlIGNvbXBsZXguPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bTVZd IEJUVywgYSBweWFuZyBwbHVnaW4gYWxyZWFkeSBleGlzdCB0byBhdXRvbWF0aWNhbGx5IGdlbmVy YXRlIGFuZCB1cGRhdGUgYSAuc2lkIGZpbGUgZnJvbSBhIC55YW5nIGZpbGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltNVl0gU2Vl DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy95YW5nLWNib3IvYmxvYi9tYXN0 ZXIvc2lkLnB5Ij5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy95YW5nLWNib3IvYmxvYi9tYXN0 ZXIvc2lkLnB5PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+V291bGQgaXQgYmUgcG9zc2libGUgdG8gYXNzaWduIHRoZSBtb2R1bGUtaWQgYmFz ZWQgb24gaW5mb3JtYXRpb24gaW4gdGhlPGJyPg0KbW9kdWxlLCBmb3IgZXhhbXBsZSBhIGhhc2gg b2YgdGhlIG5hbWVzcGFjZSBhbmQgbWF5YmUgdGhlIHJldmlzaW9uIGRhdGUuPGJyPg0KVGhhdCB3 YXksIGEgbW9kdWxlLWlkIHdvdWxkIG5vdCBoYXZlIHRvIGJlIGFzc2lnbmVkIGFuZCBtYWludGFp bmVkIGluIGE8YnI+DQpyZWdpc3RyeS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBwcml2YXRlIG1vZHVsZS1pZCB3 b3VsZCBiZSBiZXR0ZXIsIHVzaW5nIGEgcmFuZ2UgcmVzZXJ2ZWQgZm9yIHRlbXBvcmFyeTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXNzaWdubWVu dHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhvdyBkbyB5b3UgcmVzb2x2ZSBoYXNoIGNvbGxpc2lvbnMgZm9yIG1vZHVsZS1pZD88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J ZiBJIHdhbnQgdG8gaGFuZGxlIHByaXZhdGUgbW9kdWxlcywgZG8gSSBoYXZlIHRvIGNyZWF0ZSBt eSBvd24gcmVnaXN0cnk/PGJyPg0KSXQgc2VlbXMgaW1wb3J0YW50IHRoYXQgcHJpdmF0ZSBtb2R1 bGVzIGJlIHN1cHBvcnRlZC4gQ291bGQgd2UgcmUtdXNlIHRoZTxicj4NClNNSSBlbnRlcnByaXNl IG51bWJlciBhc3NpZ25tZW50cyBmb3IgY3JlYXRpbmcgbW9kdWxlLWlkcyBmb3IgcHJpdmF0ZSBt b2R1bGVzPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGlldGYteWlkIG1vZHVsZSBoYXMgYSBzY2hlbWEgZm9yIHRoZSBlbnRp cmUgcmVnaXN0cnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ib3cgdG8gdXNlIHRoZSByZWdpc3RyeSBpcyBhIHByb3RvY29sIGlzc3VlIHRoYXQg bmVlZHMgdG8gYmUgZGVjaWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcyAmbmJzcDtpdHMgb3duIHJl Z2lzdHJ5IHZzLiBhIHB1YmxpYyByZWdpc3RyeSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZW4gaXQgaXMgdXNpbmcgYSBwcml2YXRlIHJlZ2lz dHJ5LiZuYnNwOyBJZiBhbGwgZGV2aWNlcyBpbiB0aGUgc3lzdGVtIGFncmVlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vbiB3aGljaCByZWdpc3Ry eSB0byB1c2UsIHRoZW4gZXZlcnl0aGluZyB3b3Jrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2hvIHdpbGwgYXNzaWdu IHRoZSBsb2NhbC1pZCBudW1iZXJzPyBJcyB0aGF0IGRvbmUgYnkgdGhlIHdvcmtpbmcgZ3JvdXAg dGhhdDxicj4NCmRlZmluZXMgdGhlIFlBTkcgbW9kdWxlPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBleHBlY3QgSUVU RiBtb2R1bGVzIHRvIHVzZSBoYXNoZXMgYnkgZGVmYXVsdCBidXQgZm9yPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zb21lIG1vZHVsZXMgdGhhdCBz ZWVtIHVzZWZ1bCB0byBjb25zdHJhaW5lZCBkZXZpY2VzLCB0aGVuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYW51YWwgbnVtYmVyaW5nIGNvdWxk IGJlIGRvbmUgaW5zdGVhZCBieSB0aGUgV0cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W01WXSBUbyBvYnRhaW4gYSBzbWFs bGVyIGVuY29kaW5nLCBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IHRoZSBzZXF1ZW50aWFsIG51 bWJlcmluZyB3aWxsIGJlIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bTVZdIFdpdGggc2VxdWVudGlhbCBudW1iZXJpbmcs IGFsbCBjdXJyZW50IFlBTkcgbW9kdWxlcyBkZWZpbmVkIGluIFJGQ3MgY2FuIGJlIGFzc2lnbmVk IHdpdGhpbiB0aGUgZmlyc3QgNjUwMCBTSURzIHdoaWNoIHdpbGwgYmUgZW5jb2RlZCBhcyAzIGJ5 dGVzIGZvciB0aGUgZmlyc3QgcmVmZXJlbmNlDQogYW5kIHR5cGljYWxseSBhcyAxIGJ5dGVzIGZv ciB0aGUgZm9sbG93aW5nIG9uZXMgdXNpbmcgZGVsdGEgZW5jb2RpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bTVZdIFdpdGgg aGFzaGVzLCBvbmx5IG9uZSBZQU5HIG1vZHVsZSBjYW4gYmUgYXNzaWduZWQgd2l0aGluIHRoYXQg cmFuZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQotRGF2aWQgUmVpZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR06MB2308A46F6A84378832DBC849FEEA0BN6PR06MB2308namp_-- From nobody Wed Aug 24 20:24:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942812D127 for ; Wed, 24 Aug 2016 20:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y77R2ckxueQx for ; Wed, 24 Aug 2016 20:24:33 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB812D0EB for ; Wed, 24 Aug 2016 20:24:32 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id XAA25788 for ; Wed, 24 Aug 2016 23:24:30 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id u7P3OTAI005926 for ; Wed, 24 Aug 2016 23:24:30 -0400 (EDT) (envelope-from reid@mainfs.snmp.com) Message-Id: <201608250324.u7P3OTAI005926@mainfs.snmp.com> To: core@ietf.org From: David Reid In-reply-to: Your message of Wed, 24 Aug 2016 23:22:43 -0000. Date: Wed, 24 Aug 2016 23:24:29 -0400 Sender: reid@snmp.com Archived-At: Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Reid List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 03:24:35 -0000 >>> What is the benefit of assigning values using hashing over sequentially >>> assigning values? >> There is overhead ir reading and processing a giant list of mappings. The assignment only happens one-time, so I don't see a problem with a little overhead (which I think would be minimal anyway). >> Automatic assignment is risky because both sides need to agree on >> the object to number mapping. Detecting these issues is very >> difficult. >> The YANG Hash algorithm is designed to use the path string, >> which is permanent and cannot change no matter how the >> YANG is refactored. The murmur hash is a stable algorithm. >> There is not a lot that can go wrong for the 2 peers to disagree >> on the hashes (except for collisions) I would think we could write an algorithm that would guarantee the same number every time. Although I have not thought through all the issues that come up with revisions, maybe this is harder than I think. >>> When there is a hash collision, would it be possible to rehash the value >>> to get a unique number so that we never have to manually assign numbers and >>> thus never need to register the numbers in the registry? >> yes, this has been suggested. >> The problem with auto-rehashing before was inter-module clashes. >> Now those are not possible so automatic rehashing is feasible. > [MV] I disagree, see my previous email which explain why all YIDs/SIDs > need to be registered even if generated using a hash. As long as I have either all revisions of a module or the YIDs from the previous revision, I can generate the numbers for the module. I don't think I need it to be in a central registry. >>> Would it make sense to put the module-id inside the yang module with a yid >>> extension so that I would not have to go lookup that information >>> from a registry? >> I suppose -- but how to prevent duplicates and cut-and-paste errors? We would still need a registry to prevent duplicates. But only the module writer would need to access the registry. The module users would have the information in the yang module and would not have to look at the registry. > [MV] Just adding the module ID in the yang file is not sufficient to > use a .yang file, all YIDs/SIDs need to be added. If YIDs are generated by hashing with auto rehashing on collisions, the YIDs would not have to be explicitly listed in the module. They could be auto-generated and stored in a different file. > [MV] Having YIDs/SIDs in yang files will make their maintenance more > complex. Yes, it makes it more complex for the module writers. But it is easier on the users of the module. > [MV] BTW, a pyang plugin already exist to automatically generate and > update a .sid file from a .yang file > [MV] See [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py >>> Would it be possible to assign the module-id based on information in the >>> module, for example a hash of the namespace and maybe the revision date. >>> That way, a module-id would not have to be assigned and maintained in a >>> registry. >> I think private module-id would be better, using a range reserved for >> temporary assignments. I think you are right. I was just hoping we could avoid requiring module writers to register a module-id by finding a way to auto assign it. >> How do you resolve hash collisions for module-id? I don't have a good solution. I was hoping the probability of collision would be low enough to be acceptable, or we could add the first revision in the number to further reduce collisions. But I don't have a way to resolve collisions. >>> Who will assign the local-id numbers? Is that done by the working >>> group that defines the YANG module? >> I would expect IETF modules to use hashes by default but for >> some modules that seem useful to constrained devices, then >> manual numbering could be done instead by the WG. > [MV] To obtain a smaller encoding, I personally believe that the > sequential numbering will be used. > [MV] With sequential numbering, all current YANG modules defined in > RFCs can be assigned within the first 6500 SIDs which will be encoded > as 3 bytes for the first reference and typically as 1 bytes for the > following ones using delta encoding. > [MV] With hashes, only one YANG module can be assigned within that > range. Is the sequential numbering auto-assigned or manually assigned? -David Reid From nobody Wed Aug 24 20:50:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83B12D10C for ; Wed, 24 Aug 2016 20:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtgyJIxM1SPV for ; Wed, 24 Aug 2016 20:50:50 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 7CD6312B04F for ; Wed, 24 Aug 2016 20:50:50 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id n59so63663043uan.2 for ; Wed, 24 Aug 2016 20:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sXrFg49xZiqQfoDDkIbE+aE8CK6JXNL4W1TXV2gTvDw=; b=dPecCkjLWCLFaMG89fwZhH0bjw+lXQOuJFLv5j4hbMfMHlOhTxJo89UTa6jYTMWA7k OpiSrw7/7f9ni2SsE99+i9ZgQd11EJL8M/b5UQ9vvKIwmv0xgMjiWu9fSPbnNmfT0BKd ieit0t5AKo60cnzipb8UYrX8fPdP5ZfpPV2RlfJ+AJhebVe49Pp6c5YDMJuRFajYXMu5 84MLxUrehp3UJ55Ye4LnXzkFAhfc96KtqlR9hd+FJcxDem0eTeIT+XPR3QXy7Y+YNvNp pXoJBCP+UAj0oiAHAqPx17gVFiggucUf0DfolxOo6QLG7GXs7g/s23RSX7vl9QSIMuCu U/Xw== 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:from:date :message-id:subject:to:cc; bh=sXrFg49xZiqQfoDDkIbE+aE8CK6JXNL4W1TXV2gTvDw=; b=bnCM4C/wHB1rEcs8lWqxsmi0VUDGMZ5vjqV68kHNQ5qJZzPXLLuBAbIGWiecDiD6Pv 8hDcA/ZrpDlMNUSmNCjU1jCrzFxrl05ircyHnGRlg4R6J20XyWVEFxPMFIaIeQVbHokF Nk80awHSWhQJx4zlvdO8pYkV1dLxy6Nip4P6RK7Znfn8cDTvddx6pK0YS5my6pq5BJaD TWn7ckg6oNlCTrUdPYZ4ay6yMpbUD8DKfG/AKVR2/c9kkpFOIETuUEsosPHVSOCBtWR+ fRkxTaEVbjBPthoSHt3c7tg2I2Pr2gTwL3g+71BP28BnsXOOSNMNr6Og8DGmvQ0OV5aa kvCg== X-Gm-Message-State: AEkoousKbPRLZd3iM4SdNCyd4zNd9nPRj9Y7PBdHSqPZrI1+WTI/OKUYhgppXDI0c5B78AgVFL8L9Qmgfcw3NQ== X-Received: by 10.31.136.70 with SMTP id k67mr3688019vkd.13.1472097049613; Wed, 24 Aug 2016 20:50:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Wed, 24 Aug 2016 20:50:48 -0700 (PDT) In-Reply-To: <201608250324.u7P3OTAI005926@mainfs.snmp.com> References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> From: Andy Bierman Date: Wed, 24 Aug 2016 20:50:48 -0700 Message-ID: To: David Reid Content-Type: multipart/alternative; boundary=001a11440bb6b7aa90053add4dfe Archived-At: Cc: Core Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 03:50:53 -0000 --001a11440bb6b7aa90053add4dfe Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 8:24 PM, David Reid wrote: > >>> What is the benefit of assigning values using hashing over sequentially > >>> assigning values? > > >> There is overhead ir reading and processing a giant list of mappings. > > The assignment only happens one-time, so I don't see a problem with a > little overhead (which I think would be minimal anyway). > > >> Automatic assignment is risky because both sides need to agree on > >> the object to number mapping. Detecting these issues is very > >> difficult. > >> The YANG Hash algorithm is designed to use the path string, > >> which is permanent and cannot change no matter how the > >> YANG is refactored. The murmur hash is a stable algorithm. > >> There is not a lot that can go wrong for the 2 peers to disagree > >> on the hashes (except for collisions) > > I would think we could write an algorithm that would guarantee the same > number every time. Although I have not thought through all the issues that > come up with revisions, maybe this is harder than I think. > > So many YANG statements are unordered. There is no order to how imports and includes are processed, which severely affects statement order. Top level statements have no order and can change at any time. Augment statements can change order and be refactored at any time. There is no order to any augmented node (at any level). Only RPC input and output nodes require descendant nodes to stay in the same relative order. Import or include without revision of groupings, etc. is not deterministic, The revision that gets used depends on the implementation. Almost all imports and includes are without revision-date, so this is a significant problem. >>> When there is a hash collision, would it be possible to rehash the value > >>> to get a unique number so that we never have to manually assign > numbers and > >>> thus never need to register the numbers in the registry? > > >> yes, this has been suggested. > >> The problem with auto-rehashing before was inter-module clashes. > >> Now those are not possible so automatic rehashing is feasible. > > > [MV] I disagree, see my previous email which explain why all YIDs/SIDs > > need to be registered even if generated using a hash. > > As long as I have either all revisions of a module or the YIDs from > the previous revision, I can generate the numbers for the module. I don't > think I need it to be in a central registry. > > Any algorithm that relies on statement order to decide which node is rehashed will not work. Maybe it would be possible to rehash all collisions and change the path for each (e.g., prepend '_') , and keep doing it until N new hashes are found. >>> Would it make sense to put the module-id inside the yang module with a > yid > >>> extension so that I would not have to go lookup that information > >>> from a registry? > > >> I suppose -- but how to prevent duplicates and cut-and-paste errors? > > We would still need a registry to prevent duplicates. But only the > module writer would need to access the registry. The module users would > have the information in the yang module and would not have to look at the > registry. > > > [MV] Just adding the module ID in the yang file is not sufficient to > > use a .yang file, all YIDs/SIDs need to be added. > > If YIDs are generated by hashing with auto rehashing on collisions, the > YIDs would not have to be explicitly listed in the module. They could be > auto-generated and stored in a different file. > > > [MV] Having YIDs/SIDs in yang files will make their maintenance more > > complex. > > Yes, it makes it more complex for the module writers. But it is easier on > the users of the module. > I agree that the number of tools that have to know all the complex numbering algorithms should be minimized. The [local-id, path] tuples work no matter how the local-id was assigned. The registry reader tool can be simple. > > > [MV] BTW, a pyang plugin already exist to automatically generate and > > update a .sid file from a .yang file > > [MV] See [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py > > >>> Would it be possible to assign the module-id based on information in > the > >>> module, for example a hash of the namespace and maybe the revision > date. > >>> That way, a module-id would not have to be assigned and maintained in a > >>> registry. > > >> I think private module-id would be better, using a range reserved for > >> temporary assignments. > > I think you are right. I was just hoping we could avoid requiring module > writers to register a module-id by finding a way to auto assign it. > > >> How do you resolve hash collisions for module-id? > > I don't have a good solution. I was hoping the probability of collision > would be low enough to be acceptable, or we could add the first revision > in the number to further reduce collisions. But I don't have a way > to resolve collisions. > > >>> Who will assign the local-id numbers? Is that done by the working > >>> group that defines the YANG module? > > >> I would expect IETF modules to use hashes by default but for > >> some modules that seem useful to constrained devices, then > >> manual numbering could be done instead by the WG. > > > [MV] To obtain a smaller encoding, I personally believe that the > > sequential numbering will be used. > what is sequential about nested lists and choices? Siblings may end up far apart. > > > [MV] With sequential numbering, all current YANG modules defined in > > RFCs can be assigned within the first 6500 SIDs which will be encoded > > as 3 bytes for the first reference and typically as 1 bytes for the > > following ones using delta encoding. > > > [MV] With hashes, only one YANG module can be assigned within that > > range. > > Is the sequential numbering auto-assigned or manually assigned? > > -David Reid > Andy > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11440bb6b7aa90053add4dfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 24, 2016 at 8:24 PM, David Reid <reid@snmp.com> = wrote:
>>> What is the benefit o= f assigning values using hashing over sequentially
>>> assigning values?

>> There is overhead ir reading and processing a giant list of mappin= gs.

The assignment only happens one-time, so I don't see a problem with a little overhead (which I think would be minimal anyway).

>> Automatic assignment is risky because both sides need to agree on<= br> >> the object to number mapping.=C2=A0 Detecting these issues is very=
>> difficult.
>> The YANG Hash algorithm is designed to use the path string,
>> which is permanent and cannot change no matter how the
>> YANG is refactored.=C2=A0 The murmur hash is a stable algorithm. >> There is not a lot that can go wrong for the 2 peers to disagree >> on the hashes (except for collisions)

I would think we could write an algorithm that would guarantee the same
number every time. Although I have not thought through all the issues that<= br> come up with revisions, maybe this is harder than I think.


So many YANG statements are unordered.=
There is no order to how imports and includes are processed,
which severely affects statement order.=C2=A0 Top level statements
have no order and can change at any time.

Augment statements can change order and be refactored at any time.
There is no order to any augmented node (at any level).
Only R= PC input and output nodes require descendant nodes to stay
in the= same relative order.

Import or include without re= vision of groupings, etc. is not deterministic,
The revision that= gets used depends on the implementation.
Almost all imports and = includes are without revision-date, so
this is a significant prob= lem.

>>> When there is a hash collision, would it be possible to rehash= the value
>>> to get a unique number so that we never have to manually assig= n numbers and
>>> thus never need to register the numbers in the registry?

>> yes, this has been suggested.
>> The problem with auto-rehashing before was inter-module clashes. >> Now those are not possible so automatic rehashing is feasible.

> [MV] I disagree, see my previous email which explain why all YIDs/SIDs=
> need to be registered even if generated using a hash.

As long as I have either all revisions of a module or the YIDs from
the previous revision, I can generate the numbers for the module. I don'= ;t
think I need it to be in a central registry.



Any algorithm that reli= es on statement order to decide which node is rehashed
will not w= ork.=C2=A0 Maybe it would be possible to rehash all collisions and
change the path for each (e.g., prepend '_') , and keep doing it = until N
new hashes are found.


>>> Would it make sense to put the module-id inside the yang modul= e with a yid
>>> extension so that I would not have to go lookup that informati= on
>>> from a registry?

>> I suppose -- but how to prevent duplicates and cut-and-paste error= s?

We would still need a registry to prevent duplicates. But only the
module writer would need to access the registry. The module users would
have the information in the yang module and would not have to look at the registry.

> [MV] Just adding the module ID in the yang file is not sufficient to > use a .yang file, all YIDs/SIDs need to be added.

If YIDs are generated by hashing with auto rehashing on collisions, the
YIDs would not have to be explicitly listed in the module. They could be auto-generated and stored in a different file.

> [MV] Having YIDs/SIDs in yang files will make their maintenance more > complex.

Yes, it makes it more complex for the module writers. But it is easier on the users of the module.


I agree that the number of tools that have to know all the
compl= ex numbering algorithms should be minimized.
The [local-id, path]= tuples work no matter how the local-id was assigned.
The registr= y reader tool can be simple.
=C2=A0

> [MV] BTW, a pyang plugin already exist to automatically generate and > update a .sid file from a .yang file
> [MV] See [2]https://github.com/core-wg/<= wbr>yang-cbor/blob/master/sid.py

>>> Would it be possible to assign the module-id based on informat= ion in the
>>> module, for example a hash of the namespace and maybe the revi= sion date.
>>> That way, a module-id would not have to be assigned and mainta= ined in a
>>> registry.

>> I think private module-id would be better, using a range reserved = for
>> temporary assignments.

I think you are right. I was just hoping we could avoid requiring module writers to register a module-id by finding a way to auto assign it.

>> How do you resolve hash collisions for module-id?

I don't have a good solution. I was hoping the probability of collision=
would be low enough to be acceptable, or we could add the first revision in the number to further reduce collisions. But I don't have a way
to resolve collisions.

>>> Who will assign the local-id numbers? Is that done by the work= ing
>>> group that defines the YANG module?

>> I would expect IETF modules to use hashes by default but for
>> some modules that seem useful to constrained devices, then
>> manual numbering could be done instead by the WG.

> [MV] To obtain a smaller encoding, I personally believe that the
> sequential numbering will be used.


what is sequential about nested lists and choices?
Siblings may end up far apart.=C2=A0

=C2=A0

> [MV] With sequential numbering, all current YANG modules defined in > RFCs can be assigned within the first 6500 SIDs which will be encoded<= br> > as 3 bytes for the first reference and typically as 1 bytes for the > following ones using delta encoding.

> [MV] With hashes, only one YANG module can be assigned within that
> range.

Is the sequential numbering auto-assigned or manually assigned?

-David Reid

Andy
=C2=A0
=

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

--001a11440bb6b7aa90053add4dfe-- From nobody Wed Aug 24 22:37:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C59C12B069; Wed, 24 Aug 2016 22:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okEulpOAltsQ; Wed, 24 Aug 2016 22:37:29 -0700 (PDT) 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 6724F12D0A9; Wed, 24 Aug 2016 22:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from alma.local.informatik.uni-bremen.de (fido.informatik.uni-bremen.de [134.102.218.23]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u7P5bJws005102 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Aug 2016 07:37:25 +0200 (CEST) X-Mailer: emacs 24.4.50.1 (via feedmail 11-beta-1 I) From: Carsten Bormann To: peter van der Stok In-Reply-To: (peter van der Stok's message of "Wed, 24 Aug 2016 17:44:55 +0200") References: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> <0FE3CCA5-B148-4F91-8A1E-0E21FB3CCCBB@viagenie.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (darwin) Date: Thu, 25 Aug 2016 07:37:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Marc Blanchet , draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: Re: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 05:37:31 -0000 peter van der Stok writes: >>> >>> Similar to HTTP, the existing Constrained Application Protocol >>> (CoAP) >>> GET method only allows the specification of a URI and request >>> parameters in CoAP options, not the transfer of a request payload >>> detailing the request. This leads to some applications to using >>> POST >> >> s/POST/GET/ or do I need more coffee? Applications are actually using POST for these operations because they can use a request body with POST (allowing to transcend any limitations on the request URI size) and POST is the catch-all operation of HTTP. Gruesse, Carsten From nobody Wed Aug 24 22:55:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847E12D0A9; Wed, 24 Aug 2016 22:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seA5tUsiMCOe; Wed, 24 Aug 2016 22:55:21 -0700 (PDT) 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 1279B12B017; Wed, 24 Aug 2016 22:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from alma.local.informatik.uni-bremen.de (fido.informatik.uni-bremen.de [134.102.218.23]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u7P5t5h4014615 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Aug 2016 07:55:13 +0200 (CEST) X-Mailer: emacs 24.4.50.1 (via feedmail 11-beta-1 I) From: Carsten Bormann To: "Roy T. Fielding" References: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> <0DCA59AF-6DC5-421A-A907-7C1BF173C99B@gbiv.com> Date: Thu, 25 Aug 2016 07:54:46 +0200 In-Reply-To: <0DCA59AF-6DC5-421A-A907-7C1BF173C99B@gbiv.com> (Roy T. Fielding's message of "Wed, 24 Aug 2016 09:32:17 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-core-etch@ietf.org, ietf@ietf.org, core@ietf.org Subject: Re: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 05:55:22 -0000 "Roy T. Fielding" writes: >> The document has a reference to obsolete RFC 2616, this is intentional. > > What is that supposed to mean? The reference is intentionally wrong? RFC 7252 is referencing RFC 2616 for its security considerations, because the RFC 723x series wasn't out yet at the time CoAP was completed. draft-ietf-core-etch references RFC 7252 for its security considerations. This implies a reference to RFC 2616 as well, which we decided to make explicit (it's hard to be explicit enough about security considerations). We could change that to leave it implicit, rendering the downref less visible. > I looked at the text and it should be referencing section 9 of RFC7231, > not section 15 of RFC2616. Just fix the reference or remove it entirely While we could add RFC 7231 to the above reference (which, as I said is already implicitly there), a single security considerations section out of one of the RFC 723x documents does not cover the entire security considerations of RFC 2616 (e.g., section 15.7 does very much apply, some of which seems to have been moved to RFC 7234). Do you see anything specific in RFC 7231 that we should cover that isn't mentioned in RFC 2616? We could use draft-ietf-core-etch more or less randomly as the point where we finally clean up the editorial issues caused by the sharding of RFC 2616. The authors so far did not see a reason to do that exactly in this document, which describes functionality not really touched by that sharding. Should we, anyway? Gruesse, Carsten From nobody Thu Aug 25 02:54:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD03312D1BD for ; Thu, 25 Aug 2016 02:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKuEPJlkvbA7 for ; Thu, 25 Aug 2016 02:54:35 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A5F12D541 for ; Thu, 25 Aug 2016 02:54:35 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.203]) by smtp-cloud2.xs4all.net with ESMTP id bMuY1t00b4NtgTm01MuYkt; Thu, 25 Aug 2016 11:54:32 +0200 Received: from 2001:983:a264:1:f48f:89c1:a738:b506 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 25 Aug 2016 11:54:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 25 Aug 2016 11:54:32 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (TaLJi+EFVMPz1mxuJS1R7sO41YQoZSbe) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Name support in draft-ietf-core-yang-cbor? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 09:54:44 -0000 Hi Alex, and Michel see below Michel Veillette schreef op 2016-08-24 20:31: > Hi Alexander > > About "There are two types of identifiers supported by > draft-ietf-core-yang-cbor - textual (for full compatibility with > RESTConf/NETCONF names) and delta-encoded integers (a.k.a. SIDs). The > former could be used when network constraints are not so stringent, > while the latter is the preferred way of using this encoding in > constrained networks." > > Don't we have an action item from the last IETF to remove name? > The minutes are not clear about this topic. > https://www.ietf.org/proceedings/96/minutes/minutes-96-core > The last sentence is from Andy " We do not need multiple ways to do > the same thing, especially on constrained devices. Nobody provides > short module names, so they can be very large." YANG to CBOR mapping may also be used by RESTCONF/http and I like to maintain the textual representation. > > Regards, > Michel > > -----Original Message----- > From: Alexander Pelov [mailto:a@ackl.io] > Sent: Wednesday, August 24, 2016 3:57 AM > To: consultancy@vanderstok.org > Cc: Michel Veillette ; > core@ietf.org WG > Subject: Re: [core] 🔔 Working Group Adoption call for > draft-somaraju-core-sid > > Dear Peter, > >> Le 24 août 2016 à 08:39, peter van der Stok a >> écrit : >> >> Some comments based on the arguments below: >> >>> This draft is a prerequisite for the following works: >>> - CBOR encoding of YANG data model >>> (https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/) >> I have argued already for some time that the text about SIDs does not >> belong in the yang to cbor draft. >> It reduces its independence from the CoMI work. >> Given that CBOR is not to be changed, Putting the SID text in a >> content format draft seems more appropriate. > > There are two types of identifiers supported by > draft-ietf-core-yang-cbor - textual (for full compatibility with > RESTConf/NETCONF names) and delta-encoded integers (a.k.a. SIDs). The > former could be used when network constraints are not so stringent, > while the latter is the preferred way of using this encoding in > constrained networks. > > We should keep it simple. Having several content formats to express > the same thing - especially when this is not necessary - is adding > complexity for no reason. I agree to keep things simple. Specifying that there are two representations: numeric and textual, keeps the yang to cbor draft simple. IMO the yang to cbor draft is useful beyond CoMI/CoOL applications. Providing one content format for CoMI/CoOL, using yang-to-cbor, that specifies i.a. delta encoding keeps things simple and inter-operable for CoMI/CoOL. May be two content formats to cover the merge-patch case if needed. Other (future) applications can use the CBOR content format and the YANG to CBOR encoding independent of what we invent for CoMI/CoOL. > > The SID draft allows for having ranges of SIDs be managed by > independent registries and have different rules of assignment. No need > to use different Content Formats necessary to solve overlapping of the > integer values. Moreover, as of the time of this writing, we have 3 > different Content-Formats for the CoOL/CoMI draft. Adding an > alternative Content-Format for the interpretation of the integers > would multiply this by 2, e.g. 6 content formats, where half are doing > the same thing. > > If you have a server with mixed modules (e.g. ones using SID and ones > using a different interpretation of the IDs), the Content-Format will > force you to chose ONE or ANOTHER. There is no possibility in one > request to read or write values from different modules. This > effectively removes all interoperability between the two, making one > of the two redundant. > > Best, > Alexander > > > >>> The alternate assignment algorithm of IDs based on murmur3 and >>> improved description texts proposed by Andy in >>> (https://datatracker.ietf.org/doc/draft-bierman-core-yid/) don't >>> fundamentally change the registration process defined by the SID >>> draft. >> >> I should like to wait till this agreement is visible on this mailing >> list. >> >> Peter >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Aug 25 06:40:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9169F12D0B3; Thu, 25 Aug 2016 06:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sandeep.de 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 OsbGNrqOlGut; Thu, 25 Aug 2016 06:40:51 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::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 F020312D13A; Thu, 25 Aug 2016 06:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1472132429; l=3834; s=domk; d=sandeep.de; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=c2ZWM9NLFZ1dLglb+Mkd+3BJT0k3cloALdw1ZK6LWyQ=; b=LNVr8WKWP8t/fbvHEK7VhnTJzr4lFGOAV2d8C2FQ/QONNTRMpSa+fOus0/IE+34jQ+5 30VgGOv9G1blMNWQhWV8MpMJWKTHxmATyU53jatXjrnC5Vm3n4Y3T111ByI4jKGjrQ0JL kMv/1xSbHcIFLbDlCgUOkXq6fKM48OgN+Dw= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQSHYQclW8= X-RZG-CLASS-ID: mo00 Received: from mail-oi0-f48.google.com ([209.85.218.48]) by smtp.strato.de (RZmta 38.13 AUTH) with ESMTPSA id v09a43s7PDeTLmk (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified); Thu, 25 Aug 2016 15:40:29 +0200 (CEST) Received: by mail-oi0-f48.google.com with SMTP id 4so67000085oih.2; Thu, 25 Aug 2016 06:40:29 -0700 (PDT) X-Gm-Message-State: AE9vXwPgqKwJdoZJTNZi3K8e5MuoQJAscTwiLHB3fWKi0C+Veegbq2SZv9edwW8ZI4zVq4KLeP6gPWDkMtoZJg== X-Received: by 10.157.25.165 with SMTP id k34mr6358384otk.169.1472132428599; Thu, 25 Aug 2016 06:40:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.75.81 with HTTP; Thu, 25 Aug 2016 06:40:27 -0700 (PDT) In-Reply-To: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> From: Sandeep Kumar Date: Thu, 25 Aug 2016 15:40:27 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Content-Type: multipart/alternative; boundary=94eb2c09d0b47820d8053ae58a59 Archived-At: Cc: "draft-selander-ace-object-security@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:40:53 -0000 --94eb2c09d0b47820d8053ae58a59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 I support adoption of the draft as it is quite useful to have this additional security mechanism in the toolkit that is useful in many settings. Regards Sandeep Sandeep Kumar Senior Scientist, Philips Lighting Research, The Netherlands On Mon, Aug 15, 2016 at 5:08 PM, Jaime Jim=C3=A9nez wrote: > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been requested > for draft-selander-ace-object-security. At the IETF meeting the > room consensus was strongly supporting adoption (10-12 people). Please > reply to the list with your comments, including although not limited to > whether or not you support adoption. Non-authors are especially encourage= d > to comment. > > Since there are several concurrent WGA calls, we will end the call on *Au= gust > 26, 2016*. > > Thanks, > Jaime and Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --94eb2c09d0b47820d8053ae58a59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1
I support adoption of the= draft as it is quite useful to have this additional security mechanism in = the toolkit that is useful in many settings.

Regards
= Sandeep

Sandeep Kumar

Senior Scientist,

Philips Light= ing Research, The Netherlands


On Mon, Aug 15, 2016 at 5:08 PM, Jaime J= im=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
=
Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been requested f= or draft-selander-ace-object-security. At the IETF meeting the room=C2= =A0consensus was strongly supporting adoption (10-12 people).=C2=A0Please r= eply to the list with your comments, including although not=C2=A0limited to whether or not you support adoption. Non-auth= ors are especially=C2=A0encouraged to comment.

Since there are several concurrent WGA calls, we will end the call on=C2=A0= August 26, 2016.

Thanks,
Jaime and Carsten


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


--94eb2c09d0b47820d8053ae58a59-- From nobody Thu Aug 25 07:16:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1AC12D841 for ; Thu, 25 Aug 2016 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1733Nmo1F934 for ; Thu, 25 Aug 2016 07:15:56 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0115.outbound.protection.outlook.com [104.47.41.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68D012D5AB for ; Thu, 25 Aug 2016 07:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fgi4yVEvNBT0qyemhJKfHhs5zpoxplMPtMey/DLm8DM=; b=pf79ZTLoRRNpl+jABy8dEvwv1TtGk0UTb/wkF9mQjETZsgr/fWrn4OLsfCi4sba3InCSLVy5Zpj803LqnF1tisewCxLSubvlngvE9mts/G6toKTNrVa2c5C0akhGcQxIv4PdO///Da9EuKpQrpVc/EirJ1iAkS/BGLX8XGdYnpk= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Thu, 25 Aug 2016 14:15:52 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Thu, 25 Aug 2016 14:15:52 +0000 From: Michel Veillette To: David Reid , "core@ietf.org" Thread-Topic: [core] draft-bierman-core-yid-00.txt questions Thread-Index: AQHR/oAwnsXgBk9RvEWD4CzBgA9zo6BZtb8w Date: Thu, 25 Aug 2016 14:15:52 +0000 Message-ID: References: Your message of Wed, 24 Aug 2016 23:22:43 -0000. <201608250324.u7P3OTAI005926@mainfs.snmp.com> In-Reply-To: <201608250324.u7P3OTAI005926@mainfs.snmp.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: 8ab7f42b-15f8-4b70-9481-08d3ccf25286 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 6:JuKRIk32mSzTDO2CL2FbFq/YOk1ww9dC1YTO+7ivhicQM6KbYaJvt+CBuTRlxyFWl9fMxawWrTxzutokuzsHRMnSqIhl/ZuuyWHZivv1svLwRkfl/CKVL/ladKpAh89ymOuPgJDNCINC4jASM7xGJpeJVoK3gCl+k7INYmN16ZqWYtt0Sw5SqOs1tSsQvuHAK62UWCmiLlE+vKMjLKEdil8fbf8A48kPX8KgkcabhxMoWOL0T+nV2mpNGwLesv2JC4B1L08PZMfJhyfHunAP17tUpZJc2hdnFsTCgK7W7wU=; 5:JNaVyy+y7Ahv7WW5aDtBoHN+UWVDyj3yhO9q2bUCfAzUwM8KI4zHQ9bpb0s0QajiiHG+dBH3cyGmr2FvkNLUt2elzRcsL35Kt+e2sogJYVUQB4GE7IDTD1w6sd7N4icRzMCAwsb9nGlyeRzdDCFc/Q==; 24:/BSdVrOCP6iL2wsFFDufGqBugsCQqUGjTf2fbafkm8gOCtkK1HnFyN94jUnZhNskB0w/tno27g2AhDoKbulnN3F7sSgvbBnktqW/bFowqmE=; 7:QMsjHByRWvE+SuMGX8dMvI0P7abxIte6dzA2JTT1DLBCzAyKeSqOV52vbDBB/2KrK+e+53OzfOvoFb5quw97trscSq8kRYRfBbe2AmhHmdQb1n5iIeVoAulW3h79DFxRCDAsNwK7bHmtYuDPWiSEwI0oTC3eJMNJ/iQY/fimfCCa7c1jsRc4g/qu7pusK0N5/QId37DaZ2WxslQQBM0DNBirkbOVJVUphIOKJcmDYUFT3KGvVAch3cg1ztfWBh9j x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2305; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(189002)(51884002)(199003)(99936001)(5660300001)(76176999)(97736004)(33656002)(102836003)(5001770100001)(3660700001)(3846002)(54356999)(2906002)(2501003)(92566002)(6116002)(586003)(107886002)(5002640100001)(3280700002)(99286002)(11100500001)(189998001)(86362001)(5890100001)(19580405001)(122556002)(8676002)(77096005)(81156014)(7846002)(74316002)(15975445007)(81166006)(305945005)(7736002)(8936002)(106356001)(7696003)(76576001)(50986999)(10400500002)(101416001)(106116001)(66066001)(230783001)(19580395003)(68736007)(2950100001)(87936001)(105586002)(2900100001)(9686002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_BN6PR06MB2308826651FF40B1BB08F39CFEED0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 14:15:52.5393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 14:15:58 -0000 --_002_BN6PR06MB2308826651FF40B1BB08F39CFEED0BN6PR06MB2308namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David About " Is the sequential numbering auto-assigned or manually assigned? " If you use a tool such the pyang plugin, they will be automatically assigne= d. For example, the command: pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang Generate the file toaster@2009-11-20.sid in attachment. The command: pyang --update-sid-file toaster@2009-11-20.sid toaster@2009-12-28.yang Generate the file toaster@2009-12-28.sid in attachment. It is important to note that sequential numbering doesn't means that two da= ta nodes defined sequentially in .yang file will receive consecutive IDs. As you known, order may change and grouping may be introduced between versi= ons. It means that IDs are assigned sequentially from 1 using some arbitrary ord= er. If a .yang module have 14 YANG items, they will be numbered from 1 to 14. If the next version add 5 YANG items, they will be numbered from 15 to 19. Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of David Reid Sent: Wednesday, August 24, 2016 11:24 PM To: core@ietf.org Subject: Re: [core] draft-bierman-core-yid-00.txt questions >>> What is the benefit of assigning values using hashing over=20 >>> sequentially assigning values? >> There is overhead ir reading and processing a giant list of mappings. The assignment only happens one-time, so I don't see a problem with a littl= e overhead (which I think would be minimal anyway). >> Automatic assignment is risky because both sides need to agree on the=20 >> object to number mapping. Detecting these issues is very difficult. >> The YANG Hash algorithm is designed to use the path string, which is=20 >> permanent and cannot change no matter how the YANG is refactored. =20 >> The murmur hash is a stable algorithm. >> There is not a lot that can go wrong for the 2 peers to disagree on=20 >> the hashes (except for collisions) I would think we could write an algorithm that would guarantee the same num= ber every time. Although I have not thought through all the issues that com= e up with revisions, maybe this is harder than I think. >>> When there is a hash collision, would it be possible to rehash the=20 >>> value to get a unique number so that we never have to manually=20 >>> assign numbers and thus never need to register the numbers in the regis= try? >> yes, this has been suggested. >> The problem with auto-rehashing before was inter-module clashes. >> Now those are not possible so automatic rehashing is feasible. > [MV] I disagree, see my previous email which explain why all YIDs/SIDs=20 > need to be registered even if generated using a hash. As long as I have either all revisions of a module or the YIDs from the pre= vious revision, I can generate the numbers for the module. I don't think I = need it to be in a central registry. >>> Would it make sense to put the module-id inside the yang module with=20 >>> a yid extension so that I would not have to go lookup that=20 >>> information from a registry? >> I suppose -- but how to prevent duplicates and cut-and-paste errors? We would still need a registry to prevent duplicates. But only the module w= riter would need to access the registry. The module users would have the in= formation in the yang module and would not have to look at the registry. > [MV] Just adding the module ID in the yang file is not sufficient to=20 > use a .yang file, all YIDs/SIDs need to be added. If YIDs are generated by hashing with auto rehashing on collisions, the YID= s would not have to be explicitly listed in the module. They could be auto-= generated and stored in a different file. > [MV] Having YIDs/SIDs in yang files will make their maintenance more=20 > complex. Yes, it makes it more complex for the module writers. But it is easier on t= he users of the module. > [MV] BTW, a pyang plugin already exist to automatically generate and=20 > update a .sid file from a .yang file [MV] See=20 > [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py >>> Would it be possible to assign the module-id based on information in=20 >>> the module, for example a hash of the namespace and maybe the revision = date. >>> That way, a module-id would not have to be assigned and maintained=20 >>> in a registry. >> I think private module-id would be better, using a range reserved for=20 >> temporary assignments. I think you are right. I was just hoping we could avoid requiring module wr= iters to register a module-id by finding a way to auto assign it. >> How do you resolve hash collisions for module-id? I don't have a good solution. I was hoping the probability of collision wou= ld be low enough to be acceptable, or we could add the first revision in th= e number to further reduce collisions. But I don't have a way to resolve co= llisions. >>> Who will assign the local-id numbers? Is that done by the working=20 >>> group that defines the YANG module? >> I would expect IETF modules to use hashes by default but for some=20 >> modules that seem useful to constrained devices, then manual=20 >> numbering could be done instead by the WG. > [MV] To obtain a smaller encoding, I personally believe that the=20 > sequential numbering will be used. > [MV] With sequential numbering, all current YANG modules defined in=20 > RFCs can be assigned within the first 6500 SIDs which will be encoded=20 > as 3 bytes for the first reference and typically as 1 bytes for the=20 > following ones using delta encoding. > [MV] With hashes, only one YANG module can be assigned within that=20 > range. Is the sequential numbering auto-assigned or manually assigned? -David Reid _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_002_BN6PR06MB2308826651FF40B1BB08F39CFEED0BN6PR06MB2308namp_ Content-Type: application/octet-stream; name="toaster@2009-12-28.sid" Content-Description: toaster@2009-12-28.sid Content-Disposition: attachment; filename="toaster@2009-12-28.sid"; size=2247; creation-date="Thu, 25 Aug 2016 14:08:06 GMT"; modification-date="Thu, 25 Aug 2016 14:08:06 GMT" Content-Transfer-Encoding: base64 ew0KICAiYXNzaWdubWVudC1yYW5nZXMiOiBbDQogICAgew0KICAgICAgImVudHJ5LXBvaW50Ijog MjAwMDAsDQogICAgICAic2l6ZSI6IDEwMA0KICAgIH0NCiAgXSwNCiAgIm1vZHVsZS1uYW1lIjog InRvYXN0ZXIiLA0KICAibW9kdWxlLXJldmlzaW9uIjogIjIwMDktMTItMjgiLA0KICAiaXRlbXMi OiBbDQogICAgew0KICAgICAgInR5cGUiOiAiTW9kdWxlIiwNCiAgICAgICJsYWJlbCI6ICJ0b2Fz dGVyIiwNCiAgICAgICJzaWQiOiAyMDAwMA0KICAgIH0sDQogICAgew0KICAgICAgInR5cGUiOiAi aWRlbnRpdHkiLA0KICAgICAgImxhYmVsIjogIi90b2FzdC10eXBlIiwNCiAgICAgICJzaWQiOiAy MDAwMQ0KICAgIH0sDQogICAgew0KICAgICAgInR5cGUiOiAiaWRlbnRpdHkiLA0KICAgICAgImxh YmVsIjogIi90b2FzdC10eXBlL2Nyb2lzYW50IiwNCiAgICAgICJzaWQiOiAyMDAxOA0KICAgIH0s DQogICAgew0KICAgICAgInR5cGUiOiAiaWRlbnRpdHkiLA0KICAgICAgImxhYmVsIjogIi90b2Fz dC10eXBlL2Zyb3plbi1iYWdlbCIsDQogICAgICAic2lkIjogMjAwMDINCiAgICB9LA0KICAgIHsN CiAgICAgICJ0eXBlIjogImlkZW50aXR5IiwNCiAgICAgICJsYWJlbCI6ICIvdG9hc3QtdHlwZS9m cm96ZW4td2FmZmxlIiwNCiAgICAgICJzaWQiOiAyMDAwMw0KICAgIH0sDQogICAgew0KICAgICAg InR5cGUiOiAiaWRlbnRpdHkiLA0KICAgICAgImxhYmVsIjogIi90b2FzdC10eXBlL2hhc2gtYnJv d24iLA0KICAgICAgInNpZCI6IDIwMDA0DQogICAgfSwNCiAgICB7DQogICAgICAidHlwZSI6ICJp ZGVudGl0eSIsDQogICAgICAibGFiZWwiOiAiL3RvYXN0LXR5cGUvd2hlYXQtYnJlYWQiLA0KICAg ICAgInNpZCI6IDIwMDA1DQogICAgfSwNCiAgICB7DQogICAgICAidHlwZSI6ICJpZGVudGl0eSIs DQogICAgICAibGFiZWwiOiAiL3RvYXN0LXR5cGUvd2hpdGUtYnJlYWQiLA0KICAgICAgInNpZCI6 IDIwMDA2DQogICAgfSwNCiAgICB7DQogICAgICAidHlwZSI6ICJpZGVudGl0eSIsDQogICAgICAi bGFiZWwiOiAiL3RvYXN0LXR5cGUvd29uZGVyLWJyZWFkIiwNCiAgICAgICJzaWQiOiAyMDAwNw0K ICAgIH0sDQogICAgew0KICAgICAgInR5cGUiOiAibm9kZSIsDQogICAgICAibGFiZWwiOiAiL3Rv YXN0ZXItaW5mbyIsDQogICAgICAic2lkIjogMjAwMDgNCiAgICB9LA0KICAgIHsNCiAgICAgICJ0 eXBlIjogIm5vZGUiLA0KICAgICAgImxhYmVsIjogIi90b2FzdGVyLWluZm8vcG93ZXItc291cmNl L2VsZWN0cmljL3ZvbHRhZ2UiLA0KICAgICAgInNpZCI6IDIwMDE5DQogICAgfSwNCiAgICB7DQog ICAgICAidHlwZSI6ICJub2RlIiwNCiAgICAgICJsYWJlbCI6ICIvdG9hc3Rlci1pbmZvL3RvYXN0 ZXItbWFudWZhY3R1cmVyIiwNCiAgICAgICJzaWQiOiAyMDAwOQ0KICAgIH0sDQogICAgew0KICAg ICAgInR5cGUiOiAibm9kZSIsDQogICAgICAibGFiZWwiOiAiL3RvYXN0ZXItaW5mby90b2FzdGVy LW1vZGVsLW51bWJlciIsDQogICAgICAic2lkIjogMjAwMTANCiAgICB9LA0KICAgIHsNCiAgICAg ICJ0eXBlIjogIm5vZGUiLA0KICAgICAgImxhYmVsIjogIi90b2FzdGVyLWluZm8vdG9hc3Rlci1z dGF0dXMiLA0KICAgICAgInNpZCI6IDIwMDExDQogICAgfSwNCiAgICB7DQogICAgICAidHlwZSI6 ICJub3RpZmljYXRpb24iLA0KICAgICAgImxhYmVsIjogIi90b2FzdC1kb25lIiwNCiAgICAgICJz aWQiOiAyMDAxMg0KICAgIH0sDQogICAgew0KICAgICAgInR5cGUiOiAibm90aWZpY2F0aW9uIiwN CiAgICAgICJsYWJlbCI6ICIvdG9hc3QtZG9uZS90b2FzdC1zdGF0dXMiLA0KICAgICAgInNpZCI6 IDIwMDEzDQogICAgfSwNCiAgICB7DQogICAgICAidHlwZSI6ICJycGMiLA0KICAgICAgImxhYmVs IjogIi9jYW5jZWwtdG9hc3QiLA0KICAgICAgInNpZCI6IDIwMDE0DQogICAgfSwNCiAgICB7DQog ICAgICAidHlwZSI6ICJycGMiLA0KICAgICAgImxhYmVsIjogIi9tYWtlLXRvYXN0IiwNCiAgICAg ICJzaWQiOiAyMDAxNQ0KICAgIH0sDQogICAgew0KICAgICAgInR5cGUiOiAicnBjIiwNCiAgICAg ICJsYWJlbCI6ICIvbWFrZS10b2FzdC9pbnB1dC90b2FzdGVyLWRvbmVuZXNzIiwNCiAgICAgICJz aWQiOiAyMDAxNg0KICAgIH0sDQogICAgew0KICAgICAgInR5cGUiOiAicnBjIiwNCiAgICAgICJs YWJlbCI6ICIvbWFrZS10b2FzdC9pbnB1dC90b2FzdGVyLXRvYXN0LXR5cGUiLA0KICAgICAgInNp ZCI6IDIwMDE3DQogICAgfQ0KICBdDQp9 --_002_BN6PR06MB2308826651FF40B1BB08F39CFEED0BN6PR06MB2308namp_-- From nobody Thu Aug 25 08:34:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1855512D1AC for ; Thu, 25 Aug 2016 08:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYLo7x4htCi9 for ; Thu, 25 Aug 2016 08:33:58 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487A012D0E2 for ; Thu, 25 Aug 2016 08:33:58 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id k90so90088443uak.1 for ; Thu, 25 Aug 2016 08:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uJC9B0I1U3djU+MzaNOwz1EuhdmScoicj31YGh+QEuU=; b=OAMbBf7zvRn4GMEMleuu9erwlXSaTZuAZXNaAodE0kennx/eOcFODeEbzI1rTahNLr ri6NVmIXoxe1FdcHPdoWtz6RP/9s9xfYP2Qyb8gK3b6pDhY+4s/TKI2+gD669j6DSQCO 1uZYz/s3Txrb1PQ/S+6wksDp4YrX0Q0FC19rsgZn6HRLPear3aa26gcXgGkiuNraXGc9 vxA97t1mqV1EG59S9Tfgl1Hh/aremKOW28oaMuwNj3EiqNzL70q/8hhgVwqX4W11zxl+ r9QjV7i4R0GvSGCuqJCqMILQhXvZysVQUTVBs5+5P0VogmqVailSSW5T3g7N4hYJgh2N F25A== 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:from:date :message-id:subject:to:cc; bh=uJC9B0I1U3djU+MzaNOwz1EuhdmScoicj31YGh+QEuU=; b=IWB0zTe0GJu9aBFdNt7YNNW00EEX/LqvjGSQrxC6Yd7y8jWjec1eVl72rWphJ7jbGP ieG0jgrYy5dKS4Tl72K3pvHVsD49KTcmD2SjbQIDXGYjMEhMg2wP35tSnXos7BsGEQAw hcQ3LXdkeO5Fnhfl5S+iI6H08XZdxGHNAgPBfgEwZnomYU8AepB4oxw/CjSbUCHHZ6RH PoBnZw97zOr+C7g453B4W2tdPiUK05DVCPC6jJKNG6JsEXRxdZDEiEE0ECTrdk5n5XF1 FciBng82/e6+KoIQwvWH5O+WeVsI+TD3QYBN1r3oSIwzGQJTQkJ2E9SdvZAUbMW2RVyq qeFw== X-Gm-Message-State: AEkoouscPg+27ei3tUvWXbGbtsu0xJzwrRfOoS9UnHw/rREXLYtoZ8cHGWyWHbDzzjV+nnsNVcoPm3OmsEnHdw== X-Received: by 10.31.136.70 with SMTP id k67mr5105247vkd.13.1472139237208; Thu, 25 Aug 2016 08:33:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Thu, 25 Aug 2016 08:33:56 -0700 (PDT) In-Reply-To: References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> From: Andy Bierman Date: Thu, 25 Aug 2016 08:33:56 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=001a11440bb64b4c10053ae72070 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:34:01 -0000 --001a11440bb64b4c10053ae72070 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi David > > About " Is the sequential numbering auto-assigned or manually assigned? " > > If you use a tool such the pyang plugin, they will be automatically > assigned. > > For example, the command: > pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang > > Generate the file toaster@2009-11-20.sid in attachment. > > The command: > pyang --update-sid-file toaster@2009-11-20.sid toaster@2009-12-28.yang > > Where is the algorithm explained in enough detail that multiple independent implementations will all produce the exact same results? Andy > Generate the file toaster@2009-12-28.sid in attachment. > > It is important to note that sequential numbering doesn't means that two > data nodes defined sequentially in .yang file will receive consecutive IDs. > As you known, order may change and grouping may be introduced between > versions. > It means that IDs are assigned sequentially from 1 using some arbitrary > order. > If a .yang module have 14 YANG items, they will be numbered from 1 to 14. > If the next version add 5 YANG items, they will be numbered from 15 to 19. > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of David Reid > Sent: Wednesday, August 24, 2016 11:24 PM > To: core@ietf.org > Subject: Re: [core] draft-bierman-core-yid-00.txt questions > > >>> What is the benefit of assigning values using hashing over > >>> sequentially assigning values? > > >> There is overhead ir reading and processing a giant list of mappings. > > The assignment only happens one-time, so I don't see a problem with a > little overhead (which I think would be minimal anyway). > > >> Automatic assignment is risky because both sides need to agree on the > >> object to number mapping. Detecting these issues is very difficult. > >> The YANG Hash algorithm is designed to use the path string, which is > >> permanent and cannot change no matter how the YANG is refactored. > >> The murmur hash is a stable algorithm. > >> There is not a lot that can go wrong for the 2 peers to disagree on > >> the hashes (except for collisions) > > I would think we could write an algorithm that would guarantee the same > number every time. Although I have not thought through all the issues that > come up with revisions, maybe this is harder than I think. > > >>> When there is a hash collision, would it be possible to rehash the > >>> value to get a unique number so that we never have to manually > >>> assign numbers and thus never need to register the numbers in the > registry? > > >> yes, this has been suggested. > >> The problem with auto-rehashing before was inter-module clashes. > >> Now those are not possible so automatic rehashing is feasible. > > > [MV] I disagree, see my previous email which explain why all YIDs/SIDs > > need to be registered even if generated using a hash. > > As long as I have either all revisions of a module or the YIDs from the > previous revision, I can generate the numbers for the module. I don't think > I need it to be in a central registry. > > >>> Would it make sense to put the module-id inside the yang module with > >>> a yid extension so that I would not have to go lookup that > >>> information from a registry? > > >> I suppose -- but how to prevent duplicates and cut-and-paste errors? > > We would still need a registry to prevent duplicates. But only the module > writer would need to access the registry. The module users would have the > information in the yang module and would not have to look at the registry. > > > [MV] Just adding the module ID in the yang file is not sufficient to > > use a .yang file, all YIDs/SIDs need to be added. > > If YIDs are generated by hashing with auto rehashing on collisions, the > YIDs would not have to be explicitly listed in the module. They could be > auto-generated and stored in a different file. > > > [MV] Having YIDs/SIDs in yang files will make their maintenance more > > complex. > > Yes, it makes it more complex for the module writers. But it is easier on > the users of the module. > > > [MV] BTW, a pyang plugin already exist to automatically generate and > > update a .sid file from a .yang file [MV] See > > [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py > > >>> Would it be possible to assign the module-id based on information in > >>> the module, for example a hash of the namespace and maybe the revision > date. > >>> That way, a module-id would not have to be assigned and maintained > >>> in a registry. > > >> I think private module-id would be better, using a range reserved for > >> temporary assignments. > > I think you are right. I was just hoping we could avoid requiring module > writers to register a module-id by finding a way to auto assign it. > > >> How do you resolve hash collisions for module-id? > > I don't have a good solution. I was hoping the probability of collision > would be low enough to be acceptable, or we could add the first revision in > the number to further reduce collisions. But I don't have a way to resolve > collisions. > > >>> Who will assign the local-id numbers? Is that done by the working > >>> group that defines the YANG module? > > >> I would expect IETF modules to use hashes by default but for some > >> modules that seem useful to constrained devices, then manual > >> numbering could be done instead by the WG. > > > [MV] To obtain a smaller encoding, I personally believe that the > > sequential numbering will be used. > > > [MV] With sequential numbering, all current YANG modules defined in > > RFCs can be assigned within the first 6500 SIDs which will be encoded > > as 3 bytes for the first reference and typically as 1 bytes for the > > following ones using delta encoding. > > > [MV] With hashes, only one YANG module can be assigned within that > > range. > > Is the sequential numbering auto-assigned or manually assigned? > > -David Reid > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a11440bb64b4c10053ae72070 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:
Hi David

About " Is the sequential numbering auto-assigned or manually assigned= ? "

If you use a tool such the pyang plugin, they will be automatically assigne= d.

For example, the command:
=C2=A0 =C2=A0pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang
Generate the file toaster@2009-11-20.sid in attachment.

The command:
=C2=A0 pyang --update-sid-file toaster@2009-11-20.sid=C2=A0 toaster@2009-12= -28.yang


Where is the algorithm explained in en= ough detail that multiple
independent implementations will all pr= oduce the exact same results?


Andy<= /div>
=C2=A0
Generate the file toaster@2009-12-28.sid in attachment.

It is important to note that sequential numbering doesn't means that tw= o data nodes defined sequentially in .yang file will receive consecutive ID= s.
As you known, order may change and grouping may be introduced between versi= ons.
It means that IDs are assigned sequentially from 1 using some arbitrary ord= er.
If a .yang module have 14 YANG items, they will be numbered from 1 to 14. If the next version add 5 YANG items, they will be numbered from 15 to 19.<= br>
Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of David Reid
Sent: Wednesday, August 24, 2016 11:24 PM
To: core@ietf.org
Subject: Re: [core] draft-bierman-core-yid-00.txt questions

>>> What is the benefit of assigning values using hashing over
>>> sequentially assigning values?

>> There is overhead ir reading and processing a giant list of mappin= gs.

The assignment only happens one-time, so I don't see a problem with a l= ittle overhead (which I think would be minimal anyway).

>> Automatic assignment is risky because both sides need to agree on = the
>> object to number mapping.=C2=A0 Detecting these issues is very dif= ficult.
>> The YANG Hash algorithm is designed to use the path string, which = is
>> permanent and cannot change no matter how the YANG is refactored.<= br> >> The murmur hash is a stable algorithm.
>> There is not a lot that can go wrong for the 2 peers to disagree o= n
>> the hashes (except for collisions)

I would think we could write an algorithm that would guarantee the same num= ber every time. Although I have not thought through all the issues that com= e up with revisions, maybe this is harder than I think.

>>> When there is a hash collision, would it be possible to rehash= the
>>> value to get a unique number so that we never have to manually=
>>> assign numbers and thus never need to register the numbers in = the registry?

>> yes, this has been suggested.
>> The problem with auto-rehashing before was inter-module clashes. >> Now those are not possible so automatic rehashing is feasible.

> [MV] I disagree, see my previous email which explain why all YIDs/SIDs=
> need to be registered even if generated using a hash.

As long as I have either all revisions of a module or the YIDs from the pre= vious revision, I can generate the numbers for the module. I don't thin= k I need it to be in a central registry.

>>> Would it make sense to put the module-id inside the yang modul= e with
>>> a yid extension so that I would not have to go lookup that
>>> information from a registry?

>> I suppose -- but how to prevent duplicates and cut-and-paste error= s?

We would still need a registry to prevent duplicates. But only the module w= riter would need to access the registry. The module users would have the in= formation in the yang module and would not have to look at the registry.
> [MV] Just adding the module ID in the yang file is not sufficient to > use a .yang file, all YIDs/SIDs need to be added.

If YIDs are generated by hashing with auto rehashing on collisions, the YID= s would not have to be explicitly listed in the module. They could be auto-= generated and stored in a different file.

> [MV] Having YIDs/SIDs in yang files will make their maintenance more > complex.

Yes, it makes it more complex for the module writers. But it is easier on t= he users of the module.

> [MV] BTW, a pyang plugin already exist to automatically generate and > update a .sid file from a .yang file [MV] See
> [2]https://github.com/core-wg/yang-= cbor/blob/master/sid.py

>>> Would it be possible to assign the module-id based on informat= ion in
>>> the module, for example a hash of the namespace and maybe the = revision date.
>>> That way, a module-id would not have to be assigned and mainta= ined
>>> in a registry.

>> I think private module-id would be better, using a range reserved = for
>> temporary assignments.

I think you are right. I was just hoping we could avoid requiring module wr= iters to register a module-id by finding a way to auto assign it.

>> How do you resolve hash collisions for module-id?

I don't have a good solution. I was hoping the probability of collision= would be low enough to be acceptable, or we could add the first revision i= n the number to further reduce collisions. But I don't have a way to re= solve collisions.

>>> Who will assign the local-id numbers? Is that done by the work= ing
>>> group that defines the YANG module?

>> I would expect IETF modules to use hashes by default but for some<= br> >> modules that seem useful to constrained devices, then manual
>> numbering could be done instead by the WG.

> [MV] To obtain a smaller encoding, I personally believe that the
> sequential numbering will be used.

> [MV] With sequential numbering, all current YANG modules defined in > RFCs can be assigned within the first 6500 SIDs which will be encoded<= br> > as 3 bytes for the first reference and typically as 1 bytes for the > following ones using delta encoding.

> [MV] With hashes, only one YANG module can be assigned within that
> range.

Is the sequential numbering auto-assigned or manually assigned?

-David Reid

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

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


--001a11440bb64b4c10053ae72070-- From nobody Thu Aug 25 08:55:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8BE12D831 for ; Thu, 25 Aug 2016 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvtRKRjYAG-j for ; Thu, 25 Aug 2016 08:54:57 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0135.outbound.protection.outlook.com [104.47.40.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFEF12D15A for ; Thu, 25 Aug 2016 08:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MJj8Dn9FIAAluEcIKngXeLWQDOVupbLj1X3kRLU6/L0=; b=lasqTHxATigZNw/RHMRfluHWwsp8QmjiqBFQTDKChLyi1R6a3BDUMp/jGlbzCjMA4KSN6WSc0SnxXGTq3byea2ssDaJ/l+f41Rs8HDbL8jiX+nb2FpYYmGfRTUdqgGQpEAEYwCE5xTekiepumgqFfSAb2AfjdoiQs5HPdvO73Bg= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Thu, 25 Aug 2016 15:54:51 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Thu, 25 Aug 2016 15:54:51 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] draft-bierman-core-yid-00.txt questions Thread-Index: AQHR/oAwnsXgBk9RvEWD4CzBgA9zo6BZtb8wgAAZbwCAAAFWcA== Date: Thu, 25 Aug 2016 15:54:51 +0000 Message-ID: References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 84195c57-5498-48f4-07ff-08d3cd002671 x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 6:TMuT9HaPIarAL6F9QcniwZ5aLtgABX5S5Dw/10wzzH48xk/1SuP58akQtm0ge49+6zqrwTptf80cgZnOilFVhLZjYUlnCqIGpKMLeO12kIln93llxkQOI1mQMNzy2YAbIccmW/y8f6dLs9EpGY8rrEmXmu/W7bPjT7TvLaJ1zI0taDGn30fgAsKx0AM3c/qzIIGRvMLRAv3LP0zu5NWlmnnCqNO32LK3K5qw/fc26v/tqYwG8FcLr5bp62I+vOUQEhvk2jsilJ1r7W1cilprV9aGQy80mfKHeLlS9VCra/k=; 5:fXINqBVNqTXFx9yJC8L2iwMM16VLm27LL2zHhPDG/ITPKPyTp5XZyHru1nRqZIZn2Ky8vmIuDaCn1nlPP8UuhhsfAVO5fcZu/aFESVbVzrIOP/O4zZ1nZ56tmtnYcMpH+glsTYs2TJrEe003c8P+Lg==; 24:zVDn6VGjLyIYOs8y9Qe2nVyyCeBDe/Dnv8UgFySGTZL4wbB7tpSaPL8upRF3VP3pwWkBn8HFVR4nDWhkGnE3rPfDc3wpCwzixtfcXPdwZOA=; 7:HuMJbjr34i8aK090K45vuNSCcGtmtYjCoo6nhF3XxFykNxYj7s4kuct9Qk54xImtJ+KPC1y3xzOlKcj3PM/ITyUewHBKEFzSsFweSkfX84Ju3pHBX8Ll0Y40DVB1DDQInXfXctsfxeN+yUkY1t3WCJwSUicASVWraUuB7SBeLZ1V5l3Docz36Mc96JM54ni3x71Jj+bCEt952TFPAw0UmYkMjR5vn0nZZ4J08Jo2RWL7N8xar4/WkpHyKXPB/slM x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(24454002)(13464003)(51884002)(199003)(9686002)(5890100001)(4326007)(101416001)(7696003)(92566002)(76176999)(3280700002)(54356999)(50986999)(110136002)(7906003)(105586002)(106116001)(8936002)(586003)(189998001)(19625215002)(81156014)(8676002)(3846002)(74316002)(2906002)(99286002)(76576001)(77096005)(81166006)(15975445007)(19300405004)(97736004)(7736002)(7846002)(5660300001)(790700001)(6116002)(230783001)(2900100001)(102836003)(2950100001)(3660700001)(10400500002)(66066001)(93886004)(68736007)(19609705001)(33656002)(122556002)(106356001)(19580395003)(19580405001)(86362001)(19617315012)(11100500001)(16236675004)(5002640100001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23081868474C1EBEF6124A07FEED0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 15:54:51.6746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:55:00 -0000 --_000_BN6PR06MB23081868474C1EBEF6124A07FEED0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwgSGkgRGF2aWQNCg0KVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdG8gaGF2ZSBtdWx0 aXBsZSB0b29scyBvciBhbGdvcml0aG1zIHByb2R1Y2luZyB0aGUgc2FtZSByZXN1bHQuDQpUaGUg b25seSByZXF1aXJlbWVudHMgd2UgaGF2ZSBmb3IgWUlEcy9TSURzIGFyZToNCi0gVG8gYmUgdW5p cXVlIChXaXRoaW4gdGhlIGFsbG9jYXRlZCByYW5nZSB3aXRob3V0IGR1cGxpY2F0ZSkNCi0gVG8g YmUgcGVybWFuZW50IChSZWdpc3RlcmVkIHdpdGhpbiBhIHByaXZhdGUgb3IgcHVibGljIHJlZ2lz dHJ5KQ0KDQpBcyBkZW1vbnN0cmF0ZWQgaW4gb25lIG9mIG15IGxhc3QgZW1haWwsIGFsbCBZSURz L1NJRHMgbXVzdCBiZSByZWdpc3RlcmVkIGV2ZW4gaWYgZ2VuZXJhdGVkIGZyb20gYSBoYXNoLg0K VGhlIGFsZ29yaXRobSBkb27igJl0IG5lZWQgdG8gYmUgbWFuZGF0ZWQsIHRoZSByZWdpc3RlcmVk IFlJRHMvU0lEcyBhcmUgdGhlIElEcyB0byB1c2UuDQoNClRoZSBjdXJyZW50bHkgcmVjb21tZW5k ZWQgYWxnb3JpdGhtIGlzIGRlc2NyaWJlZCBpbg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkLTAxI3NlY3Rpb24tMw0KDQogICBvICBBIHRvb2wgZXh0 cmFjdHMgdGhlIGRpZmZlcmVudCBpdGVtcyBkZWZpbmVkIGZvciBhIHNwZWNpZmljIFlBTkcNCiAg ICAgIG1vZHVsZS4NCg0KICAgbyAgVGhlIGxpc3Qgb2YgaXRlbXMgaXMgb3JkZXJlZCBieSB0eXBl IGFuZCBsYWJlbC4NCg0KICAgbyAgU0lEcyBhcmUgYXNzaWduZWQgc2VxdWVudGlhbGx5IGZvciB0 aGUgZW50cnkgcG9pbnQgdXAgdG8gdGhlIHNpemUNCiAgICAgIG9mIHRoZSByZWdpc3RlcmVkIFNJ RCByYW5nZS4gIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQNCiAgICAgIHNlcXVlbnRpYWxs eSBhc3NpZ25pbmcgU0lEcyBvcHRpbWl6ZXMgdGhlIENCT1Igc2VyaWFsaXphdGlvbiBkdWUNCiAg ICAgIHRvIHRoZSB1c2Ugb2YgZGVsdGEgZW5jb2RpbmcuDQoNCiAgIG8gIElmIHRoZSBudW1iZXIg b2YgaXRlbXMgZXhjZWVkcyB0aGUgU0lEIHJhbmdlKHMpIGFsbG9jYXRlZCB0byBhDQogICAgICBZ QU5HIG1vZHVsZSwgYW4gZXh0cmEgcmFuZ2UgaXMgYWRkZWQgZm9yIHN1YnNlcXVlbnQgYXNzaWdu bWVudHMuDQoNCg0KICAgU0lEcyBhcmUgYXNzaWduZWQgcGVybWFuZW50bHksIGl0ZW1zIGludHJv ZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24gb2YNCg0KICAgYSBZQU5HIG1vZHVsZSBhcmUgYWRkZWQg dG8gdGhlIGxpc3Qgb2YgU0lEcyBhbHJlYWR5IGFzc2lnbmVkLiAgVGhpcw0KDQogICBwcm9jZXNz IGNhbiBhbHNvIGJlIGF1dG9tYXRlZCB1c2luZyB0aGUgc2FtZSBtZXRob2QgZGVzY3JpYmVkIGFi b3ZlDQoNCiAgIGV4Y2VwdCB0aGF0IHRoZSBhc3NpZ25tZW50IG5lZWQgdG8gYmUgcmVzdGFydGVk IGZyb20gdGhlIGhpZ2hlc3QgU0lEDQoNCiAgIGFscmVhZHkgYXNzaWduZWQuDQoNClNpbmNlIHRo ZSBmaWxlIGlzIGZ1bGx5IGRlZmluZWQsIG9yZGVyaW5nIHRoZSBsaXN0IHdpdGhpbiB0aGlzIGZp bGUgYW5kIGFzc2lnbmluZyBzZXF1ZW50aWFsbHkgSURzIHRvIHRoZXNlDQplbnRyaWVzIGNhbiBi ZSBwZXJmb3JtZWQgYnkgZGlmZmVyZW50IHRvb2xzIHdpdGggdGhlIHNhbWUgcmVzdWx0Lg0KDQpS ZWdhcmRzLA0KTWljaGVsDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjUsIDIwMTYgMTE6MzQgQU0NClRvOiBN aWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+DQpDYzog RGF2aWQgUmVpZCA8cmVpZEBzbm1wLmNvbT47IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb Y29yZV0gZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQgcXVlc3Rpb25zDQoNCg0KDQpPbiBU aHUsIEF1ZyAyNSwgMjAxNiBhdCA3OjE1IEFNLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVp bGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50 aW5jLmNvbT4+IHdyb3RlOg0KSGkgRGF2aWQNCg0KQWJvdXQgIiBJcyB0aGUgc2VxdWVudGlhbCBu dW1iZXJpbmcgYXV0by1hc3NpZ25lZCBvciBtYW51YWxseSBhc3NpZ25lZD8gIg0KDQpJZiB5b3Ug dXNlIGEgdG9vbCBzdWNoIHRoZSBweWFuZyBwbHVnaW4sIHRoZXkgd2lsbCBiZSBhdXRvbWF0aWNh bGx5IGFzc2lnbmVkLg0KDQpGb3IgZXhhbXBsZSwgdGhlIGNvbW1hbmQ6DQogICBweWFuZyAtLWdl bmVyYXRlLXNpZC1maWxlIDIwMDAwOjEwMCB0b2FzdGVyQDIwMDktMTEtMjAueWFuZzxtYWlsdG86 dG9hc3RlckAyMDA5LTExLTIwLnlhbmc+DQoNCkdlbmVyYXRlIHRoZSBmaWxlIHRvYXN0ZXJAMjAw OS0xMS0yMC5zaWQ8bWFpbHRvOnRvYXN0ZXJAMjAwOS0xMS0yMC5zaWQ+IGluIGF0dGFjaG1lbnQu DQoNClRoZSBjb21tYW5kOg0KICBweWFuZyAtLXVwZGF0ZS1zaWQtZmlsZSB0b2FzdGVyQDIwMDkt MTEtMjAuc2lkPG1haWx0bzp0b2FzdGVyQDIwMDktMTEtMjAuc2lkPiAgdG9hc3RlckAyMDA5LTEy LTI4Lnlhbmc8bWFpbHRvOnRvYXN0ZXJAMjAwOS0xMi0yOC55YW5nPg0KDQpXaGVyZSBpcyB0aGUg YWxnb3JpdGhtIGV4cGxhaW5lZCBpbiBlbm91Z2ggZGV0YWlsIHRoYXQgbXVsdGlwbGUNCmluZGVw ZW5kZW50IGltcGxlbWVudGF0aW9ucyB3aWxsIGFsbCBwcm9kdWNlIHRoZSBleGFjdCBzYW1lIHJl c3VsdHM/DQoNCg0KQW5keQ0KDQpHZW5lcmF0ZSB0aGUgZmlsZSB0b2FzdGVyQDIwMDktMTItMjgu c2lkPG1haWx0bzp0b2FzdGVyQDIwMDktMTItMjguc2lkPiBpbiBhdHRhY2htZW50Lg0KDQpJdCBp cyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHNlcXVlbnRpYWwgbnVtYmVyaW5nIGRvZXNuJ3QgbWVh bnMgdGhhdCB0d28gZGF0YSBub2RlcyBkZWZpbmVkIHNlcXVlbnRpYWxseSBpbiAueWFuZyBmaWxl IHdpbGwgcmVjZWl2ZSBjb25zZWN1dGl2ZSBJRHMuDQpBcyB5b3Uga25vd24sIG9yZGVyIG1heSBj aGFuZ2UgYW5kIGdyb3VwaW5nIG1heSBiZSBpbnRyb2R1Y2VkIGJldHdlZW4gdmVyc2lvbnMuDQpJ dCBtZWFucyB0aGF0IElEcyBhcmUgYXNzaWduZWQgc2VxdWVudGlhbGx5IGZyb20gMSB1c2luZyBz b21lIGFyYml0cmFyeSBvcmRlci4NCklmIGEgLnlhbmcgbW9kdWxlIGhhdmUgMTQgWUFORyBpdGVt cywgdGhleSB3aWxsIGJlIG51bWJlcmVkIGZyb20gMSB0byAxNC4NCklmIHRoZSBuZXh0IHZlcnNp b24gYWRkIDUgWUFORyBpdGVtcywgdGhleSB3aWxsIGJlIG51bWJlcmVkIGZyb20gMTUgdG8gMTku DQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEYXZpZCBSZWlkDQpTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCAyNCwgMjAxNiAxMToyNCBQTQ0KVG86IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIGRyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0IHF1 ZXN0aW9ucw0KDQo+Pj4gV2hhdCBpcyB0aGUgYmVuZWZpdCBvZiBhc3NpZ25pbmcgdmFsdWVzIHVz aW5nIGhhc2hpbmcgb3Zlcg0KPj4+IHNlcXVlbnRpYWxseSBhc3NpZ25pbmcgdmFsdWVzPw0KDQo+ PiBUaGVyZSBpcyBvdmVyaGVhZCBpciByZWFkaW5nIGFuZCBwcm9jZXNzaW5nIGEgZ2lhbnQgbGlz dCBvZiBtYXBwaW5ncy4NCg0KVGhlIGFzc2lnbm1lbnQgb25seSBoYXBwZW5zIG9uZS10aW1lLCBz byBJIGRvbid0IHNlZSBhIHByb2JsZW0gd2l0aCBhIGxpdHRsZSBvdmVyaGVhZCAod2hpY2ggSSB0 aGluayB3b3VsZCBiZSBtaW5pbWFsIGFueXdheSkuDQoNCj4+IEF1dG9tYXRpYyBhc3NpZ25tZW50 IGlzIHJpc2t5IGJlY2F1c2UgYm90aCBzaWRlcyBuZWVkIHRvIGFncmVlIG9uIHRoZQ0KPj4gb2Jq ZWN0IHRvIG51bWJlciBtYXBwaW5nLiAgRGV0ZWN0aW5nIHRoZXNlIGlzc3VlcyBpcyB2ZXJ5IGRp ZmZpY3VsdC4NCj4+IFRoZSBZQU5HIEhhc2ggYWxnb3JpdGhtIGlzIGRlc2lnbmVkIHRvIHVzZSB0 aGUgcGF0aCBzdHJpbmcsIHdoaWNoIGlzDQo+PiBwZXJtYW5lbnQgYW5kIGNhbm5vdCBjaGFuZ2Ug bm8gbWF0dGVyIGhvdyB0aGUgWUFORyBpcyByZWZhY3RvcmVkLg0KPj4gVGhlIG11cm11ciBoYXNo IGlzIGEgc3RhYmxlIGFsZ29yaXRobS4NCj4+IFRoZXJlIGlzIG5vdCBhIGxvdCB0aGF0IGNhbiBn byB3cm9uZyBmb3IgdGhlIDIgcGVlcnMgdG8gZGlzYWdyZWUgb24NCj4+IHRoZSBoYXNoZXMgKGV4 Y2VwdCBmb3IgY29sbGlzaW9ucykNCg0KSSB3b3VsZCB0aGluayB3ZSBjb3VsZCB3cml0ZSBhbiBh bGdvcml0aG0gdGhhdCB3b3VsZCBndWFyYW50ZWUgdGhlIHNhbWUgbnVtYmVyIGV2ZXJ5IHRpbWUu IEFsdGhvdWdoIEkgaGF2ZSBub3QgdGhvdWdodCB0aHJvdWdoIGFsbCB0aGUgaXNzdWVzIHRoYXQg Y29tZSB1cCB3aXRoIHJldmlzaW9ucywgbWF5YmUgdGhpcyBpcyBoYXJkZXIgdGhhbiBJIHRoaW5r Lg0KDQo+Pj4gV2hlbiB0aGVyZSBpcyBhIGhhc2ggY29sbGlzaW9uLCB3b3VsZCBpdCBiZSBwb3Nz aWJsZSB0byByZWhhc2ggdGhlDQo+Pj4gdmFsdWUgdG8gZ2V0IGEgdW5pcXVlIG51bWJlciBzbyB0 aGF0IHdlIG5ldmVyIGhhdmUgdG8gbWFudWFsbHkNCj4+PiBhc3NpZ24gbnVtYmVycyBhbmQgdGh1 cyBuZXZlciBuZWVkIHRvIHJlZ2lzdGVyIHRoZSBudW1iZXJzIGluIHRoZSByZWdpc3RyeT8NCg0K Pj4geWVzLCB0aGlzIGhhcyBiZWVuIHN1Z2dlc3RlZC4NCj4+IFRoZSBwcm9ibGVtIHdpdGggYXV0 by1yZWhhc2hpbmcgYmVmb3JlIHdhcyBpbnRlci1tb2R1bGUgY2xhc2hlcy4NCj4+IE5vdyB0aG9z ZSBhcmUgbm90IHBvc3NpYmxlIHNvIGF1dG9tYXRpYyByZWhhc2hpbmcgaXMgZmVhc2libGUuDQoN Cj4gW01WXSBJIGRpc2FncmVlLCBzZWUgbXkgcHJldmlvdXMgZW1haWwgd2hpY2ggZXhwbGFpbiB3 aHkgYWxsIFlJRHMvU0lEcw0KPiBuZWVkIHRvIGJlIHJlZ2lzdGVyZWQgZXZlbiBpZiBnZW5lcmF0 ZWQgdXNpbmcgYSBoYXNoLg0KDQpBcyBsb25nIGFzIEkgaGF2ZSBlaXRoZXIgYWxsIHJldmlzaW9u cyBvZiBhIG1vZHVsZSBvciB0aGUgWUlEcyBmcm9tIHRoZSBwcmV2aW91cyByZXZpc2lvbiwgSSBj YW4gZ2VuZXJhdGUgdGhlIG51bWJlcnMgZm9yIHRoZSBtb2R1bGUuIEkgZG9uJ3QgdGhpbmsgSSBu ZWVkIGl0IHRvIGJlIGluIGEgY2VudHJhbCByZWdpc3RyeS4NCg0KPj4+IFdvdWxkIGl0IG1ha2Ug c2Vuc2UgdG8gcHV0IHRoZSBtb2R1bGUtaWQgaW5zaWRlIHRoZSB5YW5nIG1vZHVsZSB3aXRoDQo+ Pj4gYSB5aWQgZXh0ZW5zaW9uIHNvIHRoYXQgSSB3b3VsZCBub3QgaGF2ZSB0byBnbyBsb29rdXAg dGhhdA0KPj4+IGluZm9ybWF0aW9uIGZyb20gYSByZWdpc3RyeT8NCg0KPj4gSSBzdXBwb3NlIC0t IGJ1dCBob3cgdG8gcHJldmVudCBkdXBsaWNhdGVzIGFuZCBjdXQtYW5kLXBhc3RlIGVycm9ycz8N Cg0KV2Ugd291bGQgc3RpbGwgbmVlZCBhIHJlZ2lzdHJ5IHRvIHByZXZlbnQgZHVwbGljYXRlcy4g QnV0IG9ubHkgdGhlIG1vZHVsZSB3cml0ZXIgd291bGQgbmVlZCB0byBhY2Nlc3MgdGhlIHJlZ2lz dHJ5LiBUaGUgbW9kdWxlIHVzZXJzIHdvdWxkIGhhdmUgdGhlIGluZm9ybWF0aW9uIGluIHRoZSB5 YW5nIG1vZHVsZSBhbmQgd291bGQgbm90IGhhdmUgdG8gbG9vayBhdCB0aGUgcmVnaXN0cnkuDQoN Cj4gW01WXSBKdXN0IGFkZGluZyB0aGUgbW9kdWxlIElEIGluIHRoZSB5YW5nIGZpbGUgaXMgbm90 IHN1ZmZpY2llbnQgdG8NCj4gdXNlIGEgLnlhbmcgZmlsZSwgYWxsIFlJRHMvU0lEcyBuZWVkIHRv IGJlIGFkZGVkLg0KDQpJZiBZSURzIGFyZSBnZW5lcmF0ZWQgYnkgaGFzaGluZyB3aXRoIGF1dG8g cmVoYXNoaW5nIG9uIGNvbGxpc2lvbnMsIHRoZSBZSURzIHdvdWxkIG5vdCBoYXZlIHRvIGJlIGV4 cGxpY2l0bHkgbGlzdGVkIGluIHRoZSBtb2R1bGUuIFRoZXkgY291bGQgYmUgYXV0by1nZW5lcmF0 ZWQgYW5kIHN0b3JlZCBpbiBhIGRpZmZlcmVudCBmaWxlLg0KDQo+IFtNVl0gSGF2aW5nIFlJRHMv U0lEcyBpbiB5YW5nIGZpbGVzIHdpbGwgbWFrZSB0aGVpciBtYWludGVuYW5jZSBtb3JlDQo+IGNv bXBsZXguDQoNClllcywgaXQgbWFrZXMgaXQgbW9yZSBjb21wbGV4IGZvciB0aGUgbW9kdWxlIHdy aXRlcnMuIEJ1dCBpdCBpcyBlYXNpZXIgb24gdGhlIHVzZXJzIG9mIHRoZSBtb2R1bGUuDQoNCj4g W01WXSBCVFcsIGEgcHlhbmcgcGx1Z2luIGFscmVhZHkgZXhpc3QgdG8gYXV0b21hdGljYWxseSBn ZW5lcmF0ZSBhbmQNCj4gdXBkYXRlIGEgLnNpZCBmaWxlIGZyb20gYSAueWFuZyBmaWxlIFtNVl0g U2VlDQo+IFsyXWh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3lhbmctY2Jvci9ibG9iL21hc3Rl ci9zaWQucHkNCg0KPj4+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGFzc2lnbiB0aGUgbW9kdWxl LWlkIGJhc2VkIG9uIGluZm9ybWF0aW9uIGluDQo+Pj4gdGhlIG1vZHVsZSwgZm9yIGV4YW1wbGUg YSBoYXNoIG9mIHRoZSBuYW1lc3BhY2UgYW5kIG1heWJlIHRoZSByZXZpc2lvbiBkYXRlLg0KPj4+ IFRoYXQgd2F5LCBhIG1vZHVsZS1pZCB3b3VsZCBub3QgaGF2ZSB0byBiZSBhc3NpZ25lZCBhbmQg bWFpbnRhaW5lZA0KPj4+IGluIGEgcmVnaXN0cnkuDQoNCj4+IEkgdGhpbmsgcHJpdmF0ZSBtb2R1 bGUtaWQgd291bGQgYmUgYmV0dGVyLCB1c2luZyBhIHJhbmdlIHJlc2VydmVkIGZvcg0KPj4gdGVt cG9yYXJ5IGFzc2lnbm1lbnRzLg0KDQpJIHRoaW5rIHlvdSBhcmUgcmlnaHQuIEkgd2FzIGp1c3Qg aG9waW5nIHdlIGNvdWxkIGF2b2lkIHJlcXVpcmluZyBtb2R1bGUgd3JpdGVycyB0byByZWdpc3Rl ciBhIG1vZHVsZS1pZCBieSBmaW5kaW5nIGEgd2F5IHRvIGF1dG8gYXNzaWduIGl0Lg0KDQo+PiBI b3cgZG8geW91IHJlc29sdmUgaGFzaCBjb2xsaXNpb25zIGZvciBtb2R1bGUtaWQ/DQoNCkkgZG9u J3QgaGF2ZSBhIGdvb2Qgc29sdXRpb24uIEkgd2FzIGhvcGluZyB0aGUgcHJvYmFiaWxpdHkgb2Yg Y29sbGlzaW9uIHdvdWxkIGJlIGxvdyBlbm91Z2ggdG8gYmUgYWNjZXB0YWJsZSwgb3Igd2UgY291 bGQgYWRkIHRoZSBmaXJzdCByZXZpc2lvbiBpbiB0aGUgbnVtYmVyIHRvIGZ1cnRoZXIgcmVkdWNl IGNvbGxpc2lvbnMuIEJ1dCBJIGRvbid0IGhhdmUgYSB3YXkgdG8gcmVzb2x2ZSBjb2xsaXNpb25z Lg0KDQo+Pj4gV2hvIHdpbGwgYXNzaWduIHRoZSBsb2NhbC1pZCBudW1iZXJzPyBJcyB0aGF0IGRv bmUgYnkgdGhlIHdvcmtpbmcNCj4+PiBncm91cCB0aGF0IGRlZmluZXMgdGhlIFlBTkcgbW9kdWxl Pw0KDQo+PiBJIHdvdWxkIGV4cGVjdCBJRVRGIG1vZHVsZXMgdG8gdXNlIGhhc2hlcyBieSBkZWZh dWx0IGJ1dCBmb3Igc29tZQ0KPj4gbW9kdWxlcyB0aGF0IHNlZW0gdXNlZnVsIHRvIGNvbnN0cmFp bmVkIGRldmljZXMsIHRoZW4gbWFudWFsDQo+PiBudW1iZXJpbmcgY291bGQgYmUgZG9uZSBpbnN0 ZWFkIGJ5IHRoZSBXRy4NCg0KPiBbTVZdIFRvIG9idGFpbiBhIHNtYWxsZXIgZW5jb2RpbmcsIEkg cGVyc29uYWxseSBiZWxpZXZlIHRoYXQgdGhlDQo+IHNlcXVlbnRpYWwgbnVtYmVyaW5nIHdpbGwg YmUgdXNlZC4NCg0KPiBbTVZdIFdpdGggc2VxdWVudGlhbCBudW1iZXJpbmcsIGFsbCBjdXJyZW50 IFlBTkcgbW9kdWxlcyBkZWZpbmVkIGluDQo+IFJGQ3MgY2FuIGJlIGFzc2lnbmVkIHdpdGhpbiB0 aGUgZmlyc3QgNjUwMCBTSURzIHdoaWNoIHdpbGwgYmUgZW5jb2RlZA0KPiBhcyAzIGJ5dGVzIGZv ciB0aGUgZmlyc3QgcmVmZXJlbmNlIGFuZCB0eXBpY2FsbHkgYXMgMSBieXRlcyBmb3IgdGhlDQo+ IGZvbGxvd2luZyBvbmVzIHVzaW5nIGRlbHRhIGVuY29kaW5nLg0KDQo+IFtNVl0gV2l0aCBoYXNo ZXMsIG9ubHkgb25lIFlBTkcgbW9kdWxlIGNhbiBiZSBhc3NpZ25lZCB3aXRoaW4gdGhhdA0KPiBy YW5nZS4NCg0KSXMgdGhlIHNlcXVlbnRpYWwgbnVtYmVyaW5nIGF1dG8tYXNzaWduZWQgb3IgbWFu dWFsbHkgYXNzaWduZWQ/DQoNCi1EYXZpZCBSZWlkDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9y ZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K --_000_BN6PR06MB23081868474C1EBEF6124A07FEED0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQW5keSwgSGkg RGF2aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZSBpcyBu byByZXF1aXJlbWVudCB0byBoYXZlIG11bHRpcGxlIHRvb2xzIG9yIGFsZ29yaXRobXMgcHJvZHVj aW5nIHRoZSBzYW1lIHJlc3VsdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgb25seSByZXF1aXJlbWVu dHMgd2UgaGF2ZSBmb3IgWUlEcy9TSURzIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tIFRvIGJlIHVu aXF1ZSAoV2l0aGluIHRoZSBhbGxvY2F0ZWQgcmFuZ2Ugd2l0aG91dCBkdXBsaWNhdGUpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+LSBUbyBiZSBwZXJtYW5lbnQgKFJlZ2lzdGVyZWQgd2l0aGluIGEgcHJpdmF0 ZSBvciBwdWJsaWMgcmVnaXN0cnkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+QXMgZGVtb25zdHJhdGVkIGluIG9uZSBvZiBteSBsYXN0IGVtYWlsLCBhbGwgWUlEcy9T SURzIG11c3QgYmUgcmVnaXN0ZXJlZCBldmVuIGlmIGdlbmVyYXRlZCBmcm9tIGEgaGFzaC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgYWxnb3JpdGhtIGRvbuKAmXQgbmVlZCB0byBiZSBtYW5kYXRlZCwg dGhlIHJlZ2lzdGVyZWQgWUlEcy9TSURzIGFyZSB0aGUgSURzIHRvIHVzZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY3VycmVudGx5IHJlY29tbWVuZGVkIGFs Z29yaXRobSBpcyBkZXNjcmliZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc29tYXJhanUtY29yZS1zaWQtMDEjc2VjdGlvbi0z Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc29tYXJhanUtY29yZS1zaWQtMDEj c2VjdGlvbi0zPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgbyZuYnNwOyBBIHRvb2wgZXh0cmFjdHMgdGhlIGRpZmZlcmVudCBpdGVtcyBkZWZpbmVkIGZv ciBhIHNwZWNpZmljIFlBTkc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG1vZHVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRo ZSBsaXN0IG9mIGl0ZW1zIGlzIG9yZGVyZWQgYnkgdHlwZSBhbmQgbGFiZWwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBTSURzIGFyZSBhc3NpZ25lZCBzZXF1 ZW50aWFsbHkgZm9yIHRoZSBlbnRyeSBwb2ludCB1cCB0byB0aGUgc2l6ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhlIHJlZ2lzdGVyZWQgU0lEIHJhbmdlLiZu YnNwOyBJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzZXF1ZW50aWFsbHkgYXNzaWduaW5nIFNJRHMgb3B0aW1pemVzIHRo ZSBDQk9SIHNlcmlhbGl6YXRpb24gZHVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0byB0aGUgdXNlIG9mIGRlbHRhIGVuY29kaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgSWYgdGhlIG51bWJlciBvZiBpdGVtcyBleGNlZWRz IHRoZSBTSUQgcmFuZ2UocykgYWxsb2NhdGVkIHRvIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFlBTkcgbW9kdWxlLCBhbiBleHRyYSByYW5nZSBpcyBhZGRlZCBmb3Ig c3Vic2VxdWVudCBhc3NpZ25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU0lEcyBhcmUgYXNz aWduZWQgcGVybWFuZW50bHksIGl0ZW1zIGludHJvZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24gb2Y8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgYSBZQU5HIG1vZHVsZSBhcmUgYWRkZWQgdG8gdGhlIGxpc3Qgb2YgU0lEcyBh bHJlYWR5IGFzc2lnbmVkLiZuYnNwOyBUaGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHByb2Nlc3MgY2FuIGFsc28g YmUgYXV0b21hdGVkIHVzaW5nIHRoZSBzYW1lIG1ldGhvZCBkZXNjcmliZWQgYWJvdmU8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZXhjZXB0IHRoYXQgdGhlIGFzc2lnbm1lbnQgbmVlZCB0byBiZSByZXN0YXJ0ZWQgZnJv bSB0aGUgaGlnaGVzdCBTSUQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWxyZWFkeSBhc3NpZ25lZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNpbmNlIHRoZSBmaWxlIGlzIGZ1bGx5 IGRlZmluZWQsIG9yZGVyaW5nIHRoZSBsaXN0IHdpdGhpbiB0aGlzIGZpbGUgYW5kIGFzc2lnbmlu ZyBzZXF1ZW50aWFsbHkgSURzIHRvIHRoZXNlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5lbnRyaWVzIGNh biBiZSBwZXJmb3JtZWQgYnkgZGlmZmVyZW50IHRvb2xzIHdpdGggdGhlIHNhbWUgcmVzdWx0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+TWljaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29y a3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMjUsIDIwMTYgMTE6 MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hlbCBWZWlsbGV0dGUgJmx0O01pY2hlbC5WZWlsbGV0 dGVAdHJpbGxpYW50aW5jLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERhdmlkIFJlaWQgJmx0O3Jl aWRAc25tcC5jb20mZ3Q7OyBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb Y29yZV0gZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQgcXVlc3Rpb25zPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgMjUsIDIwMTYgYXQgNzoxNSBBTSwgTWljaGVsIFZl aWxsZXR0ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5j LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgRGF2aWQ8YnI+DQo8YnI+DQpB Ym91dCAmcXVvdDsgSXMgdGhlIHNlcXVlbnRpYWwgbnVtYmVyaW5nIGF1dG8tYXNzaWduZWQgb3Ig bWFudWFsbHkgYXNzaWduZWQ/ICZxdW90Ozxicj4NCjxicj4NCklmIHlvdSB1c2UgYSB0b29sIHN1 Y2ggdGhlIHB5YW5nIHBsdWdpbiwgdGhleSB3aWxsIGJlIGF1dG9tYXRpY2FsbHkgYXNzaWduZWQu PGJyPg0KPGJyPg0KRm9yIGV4YW1wbGUsIHRoZSBjb21tYW5kOjxicj4NCiZuYnNwOyAmbmJzcDtw eWFuZyAtLWdlbmVyYXRlLXNpZC1maWxlIDIwMDAwOjEwMCA8YSBocmVmPSJtYWlsdG86dG9hc3Rl ckAyMDA5LTExLTIwLnlhbmciPnRvYXN0ZXJAMjAwOS0xMS0yMC55YW5nPC9hPjxicj4NCjxicj4N CkdlbmVyYXRlIHRoZSBmaWxlIDxhIGhyZWY9Im1haWx0bzp0b2FzdGVyQDIwMDktMTEtMjAuc2lk Ij50b2FzdGVyQDIwMDktMTEtMjAuc2lkPC9hPiBpbiBhdHRhY2htZW50Ljxicj4NCjxicj4NClRo ZSBjb21tYW5kOjxicj4NCiZuYnNwOyBweWFuZyAtLXVwZGF0ZS1zaWQtZmlsZSA8YSBocmVmPSJt YWlsdG86dG9hc3RlckAyMDA5LTExLTIwLnNpZCI+dG9hc3RlckAyMDA5LTExLTIwLnNpZDwvYT4m bmJzcDsNCjxhIGhyZWY9Im1haWx0bzp0b2FzdGVyQDIwMDktMTItMjgueWFuZyI+dG9hc3RlckAy MDA5LTEyLTI4Lnlhbmc8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVyZSBpcyB0aGUgYWxnb3JpdGhtIGV4cGxhaW5lZCBp biBlbm91Z2ggZGV0YWlsIHRoYXQgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucyB3aWxs IGFsbCBwcm9kdWNlIHRoZSBleGFjdCBzYW1lIHJlc3VsdHM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkdlbmVyYXRlIHRoZSBmaWxlIDxhIGhyZWY9Im1haWx0bzp0b2FzdGVy QDIwMDktMTItMjguc2lkIj4NCnRvYXN0ZXJAMjAwOS0xMi0yOC5zaWQ8L2E+IGluIGF0dGFjaG1l bnQuPGJyPg0KPGJyPg0KSXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCBzZXF1ZW50aWFsIG51 bWJlcmluZyBkb2Vzbid0IG1lYW5zIHRoYXQgdHdvIGRhdGEgbm9kZXMgZGVmaW5lZCBzZXF1ZW50 aWFsbHkgaW4gLnlhbmcgZmlsZSB3aWxsIHJlY2VpdmUgY29uc2VjdXRpdmUgSURzLjxicj4NCkFz IHlvdSBrbm93biwgb3JkZXIgbWF5IGNoYW5nZSBhbmQgZ3JvdXBpbmcgbWF5IGJlIGludHJvZHVj ZWQgYmV0d2VlbiB2ZXJzaW9ucy48YnI+DQpJdCBtZWFucyB0aGF0IElEcyBhcmUgYXNzaWduZWQg c2VxdWVudGlhbGx5IGZyb20gMSB1c2luZyBzb21lIGFyYml0cmFyeSBvcmRlci48YnI+DQpJZiBh IC55YW5nIG1vZHVsZSBoYXZlIDE0IFlBTkcgaXRlbXMsIHRoZXkgd2lsbCBiZSBudW1iZXJlZCBm cm9tIDEgdG8gMTQuPGJyPg0KSWYgdGhlIG5leHQgdmVyc2lvbiBhZGQgNSBZQU5HIGl0ZW1zLCB0 aGV5IHdpbGwgYmUgbnVtYmVyZWQgZnJvbSAxNSB0byAxOS48YnI+DQo8YnI+DQpSZWdhcmRzLDxi cj4NCk1pY2hlbDxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogY29yZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPmNv cmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEYXZpZCBSZWlkPGJyPg0KU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMTE6MjQgUE08YnI+DQpUbzogPGEgaHJlZj0i bWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6 IFtjb3JlXSBkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dCBxdWVzdGlvbnM8YnI+DQo8YnI+ DQomZ3Q7Jmd0OyZndDsgV2hhdCBpcyB0aGUgYmVuZWZpdCBvZiBhc3NpZ25pbmcgdmFsdWVzIHVz aW5nIGhhc2hpbmcgb3Zlcjxicj4NCiZndDsmZ3Q7Jmd0OyBzZXF1ZW50aWFsbHkgYXNzaWduaW5n IHZhbHVlcz88YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUaGVyZSBpcyBvdmVyaGVhZCBpciByZWFkaW5n IGFuZCBwcm9jZXNzaW5nIGEgZ2lhbnQgbGlzdCBvZiBtYXBwaW5ncy48YnI+DQo8YnI+DQpUaGUg YXNzaWdubWVudCBvbmx5IGhhcHBlbnMgb25lLXRpbWUsIHNvIEkgZG9uJ3Qgc2VlIGEgcHJvYmxl bSB3aXRoIGEgbGl0dGxlIG92ZXJoZWFkICh3aGljaCBJIHRoaW5rIHdvdWxkIGJlIG1pbmltYWwg YW55d2F5KS48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBBdXRvbWF0aWMgYXNzaWdubWVudCBpcyByaXNr eSBiZWNhdXNlIGJvdGggc2lkZXMgbmVlZCB0byBhZ3JlZSBvbiB0aGU8YnI+DQomZ3Q7Jmd0OyBv YmplY3QgdG8gbnVtYmVyIG1hcHBpbmcuJm5ic3A7IERldGVjdGluZyB0aGVzZSBpc3N1ZXMgaXMg dmVyeSBkaWZmaWN1bHQuPGJyPg0KJmd0OyZndDsgVGhlIFlBTkcgSGFzaCBhbGdvcml0aG0gaXMg ZGVzaWduZWQgdG8gdXNlIHRoZSBwYXRoIHN0cmluZywgd2hpY2ggaXM8YnI+DQomZ3Q7Jmd0OyBw ZXJtYW5lbnQgYW5kIGNhbm5vdCBjaGFuZ2Ugbm8gbWF0dGVyIGhvdyB0aGUgWUFORyBpcyByZWZh Y3RvcmVkLjxicj4NCiZndDsmZ3Q7IFRoZSBtdXJtdXIgaGFzaCBpcyBhIHN0YWJsZSBhbGdvcml0 aG0uPGJyPg0KJmd0OyZndDsgVGhlcmUgaXMgbm90IGEgbG90IHRoYXQgY2FuIGdvIHdyb25nIGZv ciB0aGUgMiBwZWVycyB0byBkaXNhZ3JlZSBvbjxicj4NCiZndDsmZ3Q7IHRoZSBoYXNoZXMgKGV4 Y2VwdCBmb3IgY29sbGlzaW9ucyk8YnI+DQo8YnI+DQpJIHdvdWxkIHRoaW5rIHdlIGNvdWxkIHdy aXRlIGFuIGFsZ29yaXRobSB0aGF0IHdvdWxkIGd1YXJhbnRlZSB0aGUgc2FtZSBudW1iZXIgZXZl cnkgdGltZS4gQWx0aG91Z2ggSSBoYXZlIG5vdCB0aG91Z2h0IHRocm91Z2ggYWxsIHRoZSBpc3N1 ZXMgdGhhdCBjb21lIHVwIHdpdGggcmV2aXNpb25zLCBtYXliZSB0aGlzIGlzIGhhcmRlciB0aGFu IEkgdGhpbmsuPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7IFdoZW4gdGhlcmUgaXMgYSBoYXNoIGNv bGxpc2lvbiwgd291bGQgaXQgYmUgcG9zc2libGUgdG8gcmVoYXNoIHRoZTxicj4NCiZndDsmZ3Q7 Jmd0OyB2YWx1ZSB0byBnZXQgYSB1bmlxdWUgbnVtYmVyIHNvIHRoYXQgd2UgbmV2ZXIgaGF2ZSB0 byBtYW51YWxseTxicj4NCiZndDsmZ3Q7Jmd0OyBhc3NpZ24gbnVtYmVycyBhbmQgdGh1cyBuZXZl ciBuZWVkIHRvIHJlZ2lzdGVyIHRoZSBudW1iZXJzIGluIHRoZSByZWdpc3RyeT88YnI+DQo8YnI+ DQomZ3Q7Jmd0OyB5ZXMsIHRoaXMgaGFzIGJlZW4gc3VnZ2VzdGVkLjxicj4NCiZndDsmZ3Q7IFRo ZSBwcm9ibGVtIHdpdGggYXV0by1yZWhhc2hpbmcgYmVmb3JlIHdhcyBpbnRlci1tb2R1bGUgY2xh c2hlcy48YnI+DQomZ3Q7Jmd0OyBOb3cgdGhvc2UgYXJlIG5vdCBwb3NzaWJsZSBzbyBhdXRvbWF0 aWMgcmVoYXNoaW5nIGlzIGZlYXNpYmxlLjxicj4NCjxicj4NCiZndDsgW01WXSBJIGRpc2FncmVl LCBzZWUgbXkgcHJldmlvdXMgZW1haWwgd2hpY2ggZXhwbGFpbiB3aHkgYWxsIFlJRHMvU0lEczxi cj4NCiZndDsgbmVlZCB0byBiZSByZWdpc3RlcmVkIGV2ZW4gaWYgZ2VuZXJhdGVkIHVzaW5nIGEg aGFzaC48YnI+DQo8YnI+DQpBcyBsb25nIGFzIEkgaGF2ZSBlaXRoZXIgYWxsIHJldmlzaW9ucyBv ZiBhIG1vZHVsZSBvciB0aGUgWUlEcyBmcm9tIHRoZSBwcmV2aW91cyByZXZpc2lvbiwgSSBjYW4g Z2VuZXJhdGUgdGhlIG51bWJlcnMgZm9yIHRoZSBtb2R1bGUuIEkgZG9uJ3QgdGhpbmsgSSBuZWVk IGl0IHRvIGJlIGluIGEgY2VudHJhbCByZWdpc3RyeS48YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsg V291bGQgaXQgbWFrZSBzZW5zZSB0byBwdXQgdGhlIG1vZHVsZS1pZCBpbnNpZGUgdGhlIHlhbmcg bW9kdWxlIHdpdGg8YnI+DQomZ3Q7Jmd0OyZndDsgYSB5aWQgZXh0ZW5zaW9uIHNvIHRoYXQgSSB3 b3VsZCBub3QgaGF2ZSB0byBnbyBsb29rdXAgdGhhdDxicj4NCiZndDsmZ3Q7Jmd0OyBpbmZvcm1h dGlvbiBmcm9tIGEgcmVnaXN0cnk/PGJyPg0KPGJyPg0KJmd0OyZndDsgSSBzdXBwb3NlIC0tIGJ1 dCBob3cgdG8gcHJldmVudCBkdXBsaWNhdGVzIGFuZCBjdXQtYW5kLXBhc3RlIGVycm9ycz88YnI+ DQo8YnI+DQpXZSB3b3VsZCBzdGlsbCBuZWVkIGEgcmVnaXN0cnkgdG8gcHJldmVudCBkdXBsaWNh dGVzLiBCdXQgb25seSB0aGUgbW9kdWxlIHdyaXRlciB3b3VsZCBuZWVkIHRvIGFjY2VzcyB0aGUg cmVnaXN0cnkuIFRoZSBtb2R1bGUgdXNlcnMgd291bGQgaGF2ZSB0aGUgaW5mb3JtYXRpb24gaW4g dGhlIHlhbmcgbW9kdWxlIGFuZCB3b3VsZCBub3QgaGF2ZSB0byBsb29rIGF0IHRoZSByZWdpc3Ry eS48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gSnVzdCBhZGRpbmcgdGhlIG1vZHVsZSBJRCBpbiB0aGUg eWFuZyBmaWxlIGlzIG5vdCBzdWZmaWNpZW50IHRvPGJyPg0KJmd0OyB1c2UgYSAueWFuZyBmaWxl LCBhbGwgWUlEcy9TSURzIG5lZWQgdG8gYmUgYWRkZWQuPGJyPg0KPGJyPg0KSWYgWUlEcyBhcmUg Z2VuZXJhdGVkIGJ5IGhhc2hpbmcgd2l0aCBhdXRvIHJlaGFzaGluZyBvbiBjb2xsaXNpb25zLCB0 aGUgWUlEcyB3b3VsZCBub3QgaGF2ZSB0byBiZSBleHBsaWNpdGx5IGxpc3RlZCBpbiB0aGUgbW9k dWxlLiBUaGV5IGNvdWxkIGJlIGF1dG8tZ2VuZXJhdGVkIGFuZCBzdG9yZWQgaW4gYSBkaWZmZXJl bnQgZmlsZS48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gSGF2aW5nIFlJRHMvU0lEcyBpbiB5YW5nIGZp bGVzIHdpbGwgbWFrZSB0aGVpciBtYWludGVuYW5jZSBtb3JlPGJyPg0KJmd0OyBjb21wbGV4Ljxi cj4NCjxicj4NClllcywgaXQgbWFrZXMgaXQgbW9yZSBjb21wbGV4IGZvciB0aGUgbW9kdWxlIHdy aXRlcnMuIEJ1dCBpdCBpcyBlYXNpZXIgb24gdGhlIHVzZXJzIG9mIHRoZSBtb2R1bGUuPGJyPg0K PGJyPg0KJmd0OyBbTVZdIEJUVywgYSBweWFuZyBwbHVnaW4gYWxyZWFkeSBleGlzdCB0byBhdXRv bWF0aWNhbGx5IGdlbmVyYXRlIGFuZDxicj4NCiZndDsgdXBkYXRlIGEgLnNpZCBmaWxlIGZyb20g YSAueWFuZyBmaWxlIFtNVl0gU2VlPGJyPg0KJmd0OyBbMl08YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy95YW5nLWNib3IvYmxvYi9tYXN0ZXIvc2lkLnB5IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cveWFuZy1jYm9yL2Jsb2IvbWFzdGVyL3NpZC5w eTwvYT48YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsgV291bGQgaXQgYmUgcG9zc2libGUgdG8gYXNz aWduIHRoZSBtb2R1bGUtaWQgYmFzZWQgb24gaW5mb3JtYXRpb24gaW48YnI+DQomZ3Q7Jmd0OyZn dDsgdGhlIG1vZHVsZSwgZm9yIGV4YW1wbGUgYSBoYXNoIG9mIHRoZSBuYW1lc3BhY2UgYW5kIG1h eWJlIHRoZSByZXZpc2lvbiBkYXRlLjxicj4NCiZndDsmZ3Q7Jmd0OyBUaGF0IHdheSwgYSBtb2R1 bGUtaWQgd291bGQgbm90IGhhdmUgdG8gYmUgYXNzaWduZWQgYW5kIG1haW50YWluZWQ8YnI+DQom Z3Q7Jmd0OyZndDsgaW4gYSByZWdpc3RyeS48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIHBy aXZhdGUgbW9kdWxlLWlkIHdvdWxkIGJlIGJldHRlciwgdXNpbmcgYSByYW5nZSByZXNlcnZlZCBm b3I8YnI+DQomZ3Q7Jmd0OyB0ZW1wb3JhcnkgYXNzaWdubWVudHMuPGJyPg0KPGJyPg0KSSB0aGlu ayB5b3UgYXJlIHJpZ2h0LiBJIHdhcyBqdXN0IGhvcGluZyB3ZSBjb3VsZCBhdm9pZCByZXF1aXJp bmcgbW9kdWxlIHdyaXRlcnMgdG8gcmVnaXN0ZXIgYSBtb2R1bGUtaWQgYnkgZmluZGluZyBhIHdh eSB0byBhdXRvIGFzc2lnbiBpdC48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBIb3cgZG8geW91IHJlc29s dmUgaGFzaCBjb2xsaXNpb25zIGZvciBtb2R1bGUtaWQ/PGJyPg0KPGJyPg0KSSBkb24ndCBoYXZl IGEgZ29vZCBzb2x1dGlvbi4gSSB3YXMgaG9waW5nIHRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNp b24gd291bGQgYmUgbG93IGVub3VnaCB0byBiZSBhY2NlcHRhYmxlLCBvciB3ZSBjb3VsZCBhZGQg dGhlIGZpcnN0IHJldmlzaW9uIGluIHRoZSBudW1iZXIgdG8gZnVydGhlciByZWR1Y2UgY29sbGlz aW9ucy4gQnV0IEkgZG9uJ3QgaGF2ZSBhIHdheSB0byByZXNvbHZlIGNvbGxpc2lvbnMuPGJyPg0K PGJyPg0KJmd0OyZndDsmZ3Q7IFdobyB3aWxsIGFzc2lnbiB0aGUgbG9jYWwtaWQgbnVtYmVycz8g SXMgdGhhdCBkb25lIGJ5IHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsmZ3Q7IGdyb3VwIHRoYXQg ZGVmaW5lcyB0aGUgWUFORyBtb2R1bGU/PGJyPg0KPGJyPg0KJmd0OyZndDsgSSB3b3VsZCBleHBl Y3QgSUVURiBtb2R1bGVzIHRvIHVzZSBoYXNoZXMgYnkgZGVmYXVsdCBidXQgZm9yIHNvbWU8YnI+ DQomZ3Q7Jmd0OyBtb2R1bGVzIHRoYXQgc2VlbSB1c2VmdWwgdG8gY29uc3RyYWluZWQgZGV2aWNl cywgdGhlbiBtYW51YWw8YnI+DQomZ3Q7Jmd0OyBudW1iZXJpbmcgY291bGQgYmUgZG9uZSBpbnN0 ZWFkIGJ5IHRoZSBXRy48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gVG8gb2J0YWluIGEgc21hbGxlciBl bmNvZGluZywgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB0aGU8YnI+DQomZ3Q7IHNlcXVlbnRp YWwgbnVtYmVyaW5nIHdpbGwgYmUgdXNlZC48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gV2l0aCBzZXF1 ZW50aWFsIG51bWJlcmluZywgYWxsIGN1cnJlbnQgWUFORyBtb2R1bGVzIGRlZmluZWQgaW48YnI+ DQomZ3Q7IFJGQ3MgY2FuIGJlIGFzc2lnbmVkIHdpdGhpbiB0aGUgZmlyc3QgNjUwMCBTSURzIHdo aWNoIHdpbGwgYmUgZW5jb2RlZDxicj4NCiZndDsgYXMgMyBieXRlcyBmb3IgdGhlIGZpcnN0IHJl ZmVyZW5jZSBhbmQgdHlwaWNhbGx5IGFzIDEgYnl0ZXMgZm9yIHRoZTxicj4NCiZndDsgZm9sbG93 aW5nIG9uZXMgdXNpbmcgZGVsdGEgZW5jb2RpbmcuPGJyPg0KPGJyPg0KJmd0OyBbTVZdIFdpdGgg aGFzaGVzLCBvbmx5IG9uZSBZQU5HIG1vZHVsZSBjYW4gYmUgYXNzaWduZWQgd2l0aGluIHRoYXQ8 YnI+DQomZ3Q7IHJhbmdlLjxicj4NCjxicj4NCklzIHRoZSBzZXF1ZW50aWFsIG51bWJlcmluZyBh dXRvLWFzc2lnbmVkIG9yIG1hbnVhbGx5IGFzc2lnbmVkPzxicj4NCjxicj4NCi1EYXZpZCBSZWlk PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYu b3JnIj5jb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BN6PR06MB23081868474C1EBEF6124A07FEED0BN6PR06MB2308namp_-- From nobody Thu Aug 25 09:01:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5948C12D1DD for ; Thu, 25 Aug 2016 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlIKCJMq4lDB for ; Thu, 25 Aug 2016 09:01:15 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440DD12D135 for ; Thu, 25 Aug 2016 09:01:15 -0700 (PDT) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 73FF4C5A6F; Thu, 25 Aug 2016 18:01:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id jnBS281STzMC; Thu, 25 Aug 2016 18:01:09 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 2C209C5A61; Thu, 25 Aug 2016 18:01:08 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D6556C2-2110-4B44-880A-D93B976D0D41" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Thu, 25 Aug 2016 18:01:09 +0200 Message-Id: <2AC557DE-6F82-4278-83A9-875E25DD01DD@ackl.io> References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 16:01:18 -0000 --Apple-Mail=_0D6556C2-2110-4B44-880A-D93B976D0D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, > Le 25 ao=C3=BBt 2016 =C3=A0 17:33, Andy Bierman a = =C3=A9crit : >=20 >=20 >=20 > On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette = > wrote: > Hi David >=20 > About " Is the sequential numbering auto-assigned or manually = assigned? " >=20 > If you use a tool such the pyang plugin, they will be automatically = assigned. >=20 > For example, the command: > pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang >=20 > Generate the file toaster@2009-11-20.sid in attachment. >=20 > The command: > pyang --update-sid-file toaster@2009-11-20.sid = toaster@2009-12-28.yang >=20 >=20 > Where is the algorithm explained in enough detail that multiple > independent implementations will all produce the exact same results? You don=E2=80=99t need this explicitly. You=E2=80=99ll need the SID file = generated by the tool. There is a description on the way the current = implementation works of course. Of course, you may imagine Registries that choose policies / allocations = that COULD provide for ways of deterministically generating on the fly = your identifiers. But the most common denominator should be the SID = file. Example (which I am inventing on the go, so you can modify it according = to your vision): A Hash-based Registry (HREG) is created and IANA allocates SIDs = 0x00010000-0x000F0000. HREG publishes as its official policy that all modules registered under = it must generate their SID files using the murmur32 hash, and the size = of the hash must be at least 10 bits. (for the sake of the example). The = registry MAY also specify that no hash collisions are allowed, e.g. any = modification of a module must result in different hashes for each = element. If by chance, there is a hash collision, it is up to the author = to change the naming in such a way, as to be collision-free.=20 HREG may provide its own SID-generating tool, which performs the hash = generation, verifies that there are no collisions, and outputs a = standard SID file (where the IDs are generated by hashing). Once this is done, depending on the policy of HREG, it may publish the = SID file for interoperability with the whole world, or potentially keep = it private. The meta-data publishes by the HREG you could have only = thing like: module entry point + range size (10 bits.. or more - could = be flexible per module) + some metadata (e.g. indicating that this is = no_collision_hash_generated). This, however, is in my opinion, out of the scope of this draft. We = should provide the minimal functions which allow these systems to be = built, to coexist and to interoperate.=20 Best, Alexander >=20 >=20 > Andy > =20 > Generate the file toaster@2009-12-28.sid in attachment. >=20 > It is important to note that sequential numbering doesn't means that = two data nodes defined sequentially in .yang file will receive = consecutive IDs. > As you known, order may change and grouping may be introduced between = versions. > It means that IDs are assigned sequentially from 1 using some = arbitrary order. > If a .yang module have 14 YANG items, they will be numbered from 1 to = 14. > If the next version add 5 YANG items, they will be numbered from 15 to = 19. >=20 > Regards, > Michel >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org = ] On Behalf Of David Reid > Sent: Wednesday, August 24, 2016 11:24 PM > To: core@ietf.org > Subject: Re: [core] draft-bierman-core-yid-00.txt questions >=20 > >>> What is the benefit of assigning values using hashing over > >>> sequentially assigning values? >=20 > >> There is overhead ir reading and processing a giant list of = mappings. >=20 > The assignment only happens one-time, so I don't see a problem with a = little overhead (which I think would be minimal anyway). >=20 > >> Automatic assignment is risky because both sides need to agree on = the > >> object to number mapping. Detecting these issues is very = difficult. > >> The YANG Hash algorithm is designed to use the path string, which = is > >> permanent and cannot change no matter how the YANG is refactored. > >> The murmur hash is a stable algorithm. > >> There is not a lot that can go wrong for the 2 peers to disagree on > >> the hashes (except for collisions) >=20 > I would think we could write an algorithm that would guarantee the = same number every time. Although I have not thought through all the = issues that come up with revisions, maybe this is harder than I think. >=20 > >>> When there is a hash collision, would it be possible to rehash the > >>> value to get a unique number so that we never have to manually > >>> assign numbers and thus never need to register the numbers in the = registry? >=20 > >> yes, this has been suggested. > >> The problem with auto-rehashing before was inter-module clashes. > >> Now those are not possible so automatic rehashing is feasible. >=20 > > [MV] I disagree, see my previous email which explain why all = YIDs/SIDs > > need to be registered even if generated using a hash. >=20 > As long as I have either all revisions of a module or the YIDs from = the previous revision, I can generate the numbers for the module. I = don't think I need it to be in a central registry. >=20 > >>> Would it make sense to put the module-id inside the yang module = with > >>> a yid extension so that I would not have to go lookup that > >>> information from a registry? >=20 > >> I suppose -- but how to prevent duplicates and cut-and-paste = errors? >=20 > We would still need a registry to prevent duplicates. But only the = module writer would need to access the registry. The module users would = have the information in the yang module and would not have to look at = the registry. >=20 > > [MV] Just adding the module ID in the yang file is not sufficient to > > use a .yang file, all YIDs/SIDs need to be added. >=20 > If YIDs are generated by hashing with auto rehashing on collisions, = the YIDs would not have to be explicitly listed in the module. They = could be auto-generated and stored in a different file. >=20 > > [MV] Having YIDs/SIDs in yang files will make their maintenance more > > complex. >=20 > Yes, it makes it more complex for the module writers. But it is easier = on the users of the module. >=20 > > [MV] BTW, a pyang plugin already exist to automatically generate and > > update a .sid file from a .yang file [MV] See > > [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py = >=20 > >>> Would it be possible to assign the module-id based on information = in > >>> the module, for example a hash of the namespace and maybe the = revision date. > >>> That way, a module-id would not have to be assigned and maintained > >>> in a registry. >=20 > >> I think private module-id would be better, using a range reserved = for > >> temporary assignments. >=20 > I think you are right. I was just hoping we could avoid requiring = module writers to register a module-id by finding a way to auto assign = it. >=20 > >> How do you resolve hash collisions for module-id? >=20 > I don't have a good solution. I was hoping the probability of = collision would be low enough to be acceptable, or we could add the = first revision in the number to further reduce collisions. But I don't = have a way to resolve collisions. >=20 > >>> Who will assign the local-id numbers? Is that done by the working > >>> group that defines the YANG module? >=20 > >> I would expect IETF modules to use hashes by default but for some > >> modules that seem useful to constrained devices, then manual > >> numbering could be done instead by the WG. >=20 > > [MV] To obtain a smaller encoding, I personally believe that the > > sequential numbering will be used. >=20 > > [MV] With sequential numbering, all current YANG modules defined in > > RFCs can be assigned within the first 6500 SIDs which will be = encoded > > as 3 bytes for the first reference and typically as 1 bytes for the > > following ones using delta encoding. >=20 > > [MV] With hashes, only one YANG module can be assigned within that > > range. >=20 > Is the sequential numbering auto-assigned or manually assigned? >=20 > -David Reid >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_0D6556C2-2110-4B44-880A-D93B976D0D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Andy,

Le 25 ao=C3=BBt 2016 =C3=A0 = 17:33, Andy Bierman <andy@yumaworks.com> a =C3=A9crit :



On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette = <Michel.Veillette@trilliantinc.com> wrote:
Hi David

About " Is the sequential numbering auto-assigned or manually assigned? = "

If you use a tool such the pyang plugin, they will be automatically = assigned.

For example, the command:
   pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang

Generate the file toaster@2009-11-20.sid in attachment.

The command:
  pyang --update-sid-file toaster@2009-11-20.sid  toaster@2009-12-28.yang


Where is the algorithm explained in enough detail that = multiple
independent implementations will all = produce the exact same = results?

You don=E2=80=99t need this explicitly. You=E2=80=99= ll need the SID file generated by the tool. There is a description on = the way the current implementation works of course.

Of course, you may imagine Registries that choose = policies / allocations that COULD provide for ways of deterministically = generating on the fly your identifiers. But the most common denominator = should be the SID file.

Example = (which I am inventing on the go, so you can modify it according to your = vision):
A Hash-based Registry (HREG) is created and IANA = allocates SIDs 0x00010000-0x000F0000.
HREG publishes as its = official policy that all modules registered under it must generate their = SID files using the murmur32 hash, and the size of the hash must be at = least 10 bits. (for the sake of the example). The registry MAY also = specify that no hash collisions are allowed, e.g. any modification of a = module must result in different hashes for each element. If by chance, = there is a hash collision, it is up to the author to change the naming = in such a way, as to be collision-free. 
HREG may provide = its own SID-generating tool, which performs the hash generation, = verifies that there are no collisions, and outputs a standard SID file = (where the IDs are generated by hashing).

Once this is done, depending on the policy of = HREG, it may publish the SID file for interoperability with the whole = world, or potentially keep it private. The meta-data publishes by the = HREG you could have only thing like: module entry point + range size (10 = bits.. or more - could be flexible per module) + some metadata (e.g. = indicating that this is no_collision_hash_generated).

This, however, is in my opinion, out of the scope = of this draft. We should provide the minimal functions which allow these = systems to be built, to coexist and to interoperate. 

Best,
Alexander



Andy
 
Generate the file toaster@2009-12-28.sid in attachment.

It is important to note that sequential numbering doesn't means that two = data nodes defined sequentially in .yang file will receive consecutive = IDs.
As you known, order may change and grouping may be introduced between = versions.
It means that IDs are assigned sequentially from 1 using some arbitrary = order.
If a .yang module have 14 YANG items, they will be numbered from 1 to = 14.
If the next version add 5 YANG items, they will be numbered from 15 to = 19.

Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of David Reid
Sent: Wednesday, August 24, 2016 11:24 PM
To: core@ietf.org
Subject: Re: [core] draft-bierman-core-yid-00.txt questions
=
>>> What is the benefit of assigning values using hashing = over
>>> sequentially assigning values?

>> There is overhead ir reading and processing a giant list of = mappings.

The assignment only happens one-time, so I don't see a problem with a = little overhead (which I think would be minimal anyway).

>> Automatic assignment is risky because both sides need to agree = on the
>> object to number mapping.  Detecting these issues is very = difficult.
>> The YANG Hash algorithm is designed to use the path string, = which is
>> permanent and cannot change no matter how the YANG is = refactored.
>> The murmur hash is a stable algorithm.
>> There is not a lot that can go wrong for the 2 peers to = disagree on
>> the hashes (except for collisions)

I would think we could write an algorithm that would guarantee the same = number every time. Although I have not thought through all the issues = that come up with revisions, maybe this is harder than I think.

>>> When there is a hash collision, would it be possible to = rehash the
>>> value to get a unique number so that we never have to = manually
>>> assign numbers and thus never need to register the numbers = in the registry?

>> yes, this has been suggested.
>> The problem with auto-rehashing before was inter-module = clashes.
>> Now those are not possible so automatic rehashing is = feasible.

> [MV] I disagree, see my previous email which explain why all = YIDs/SIDs
> need to be registered even if generated using a hash.

As long as I have either all revisions of a module or the YIDs from the = previous revision, I can generate the numbers for the module. I don't = think I need it to be in a central registry.

>>> Would it make sense to put the module-id inside the yang = module with
>>> a yid extension so that I would not have to go lookup = that
>>> information from a registry?

>> I suppose -- but how to prevent duplicates and cut-and-paste = errors?

We would still need a registry to prevent duplicates. But only the = module writer would need to access the registry. The module users would = have the information in the yang module and would not have to look at = the registry.

> [MV] Just adding the module ID in the yang file is not sufficient = to
> use a .yang file, all YIDs/SIDs need to be added.

If YIDs are generated by hashing with auto rehashing on collisions, the = YIDs would not have to be explicitly listed in the module. They could be = auto-generated and stored in a different file.

> [MV] Having YIDs/SIDs in yang files will make their maintenance = more
> complex.

Yes, it makes it more complex for the module writers. But it is easier = on the users of the module.

> [MV] BTW, a pyang plugin already exist to automatically generate = and
> update a .sid file from a .yang file [MV] See
> [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py

>>> Would it be possible to assign the module-id based on = information in
>>> the module, for example a hash of the namespace and maybe = the revision date.
>>> That way, a module-id would not have to be assigned and = maintained
>>> in a registry.

>> I think private module-id would be better, using a range = reserved for
>> temporary assignments.

I think you are right. I was just hoping we could avoid requiring module = writers to register a module-id by finding a way to auto assign it.

>> How do you resolve hash collisions for module-id?

I don't have a good solution. I was hoping the probability of collision = would be low enough to be acceptable, or we could add the first revision = in the number to further reduce collisions. But I don't have a way to = resolve collisions.

>>> Who will assign the local-id numbers? Is that done by the = working
>>> group that defines the YANG module?

>> I would expect IETF modules to use hashes by default but for = some
>> modules that seem useful to constrained devices, then manual
>> numbering could be done instead by the WG.

> [MV] To obtain a smaller encoding, I personally believe that the
> sequential numbering will be used.

> [MV] With sequential numbering, all current YANG modules defined = in
> RFCs can be assigned within the first 6500 SIDs which will be = encoded
> as 3 bytes for the first reference and typically as 1 bytes for = the
> following ones using delta encoding.

> [MV] With hashes, only one YANG module can be assigned within = that
> range.

Is the sequential numbering auto-assigned or manually assigned?

-David Reid

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

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


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

= --Apple-Mail=_0D6556C2-2110-4B44-880A-D93B976D0D41-- From nobody Thu Aug 25 09:03:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3903E12D0FF for ; Thu, 25 Aug 2016 09:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgC4FcswEJ13 for ; Thu, 25 Aug 2016 09:03:01 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 BCC1712D847 for ; Thu, 25 Aug 2016 09:03:00 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id l94so28655088ual.0 for ; Thu, 25 Aug 2016 09:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WAATRkEIJvgEnJxrXXwOjW9nhK2DsWxqB1NKOHWtwYc=; b=gCY9RiPlQTUpA536zTEEFy0/7Uywu5bnmS9V6WqM4zj8p0Cmyc7ck1+3rGccw1TS0z Mbp8Vz/9qdSu0BiS6+cc8KMsfAxhbGyUM27gLZUdalQRldKy8ojifvpyWyyA+VB3O4Rg x7ayxniBy151uR0LWddCkImGT3NDoFR1LmvVpuAHJmHZAhSxYzPs2ivZEhw23N5A2gnZ 2ZPedXJlIsRaywztwLl7b90wMZL92bLFLKbL9PHNX1nFakd2BWAE9kMxhCt/q43uMprF acjeTpImqot0BnDbLUQKWWIkcqxl6o1eJPRK5+gz6I094xlfZZlmEUHumiju1bkbURku y3BA== 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:from:date :message-id:subject:to:cc; bh=WAATRkEIJvgEnJxrXXwOjW9nhK2DsWxqB1NKOHWtwYc=; b=TPtw1IVgp7fwft09cmIWd5bsSkIX0YXRjRJ8dpo3hDrtnS63MwHMSzOH5793tqVGMW p5DB6XAlwusApvWQE7oqPa5FJ6Iimhg4fDzqOjMny45325/6C5f4DaBjAsLKkXKo0lph sBr9imzKrSH6RGYc9ylvTiix9Efk9dgPzAswOg6RidpW42cSLCPX1T1ceVjgCyR5P5bv MaHRHxhSzqRhHInPeeQ3H/WUOJ16ULEUei4Gsy5kaVExgdXss1T6HWzB8Rarxoe3ZAzt LZZidwpW67/QzU7aeN4iYUB5O34KJI+RY28d4IoN4rRXF5RJxrLC4osUAclKyk2mfLcH lzJQ== X-Gm-Message-State: AE9vXwOsdKf34R0eorktHW7CVWd5tPzzbusmnaXHftEiyQcTH0/8aWE0tcUw/Shbl7rI8flA6hp5eTNQ7ymlfg== X-Received: by 10.176.82.146 with SMTP id v18mr1946801uav.135.1472140979733; Thu, 25 Aug 2016 09:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Thu, 25 Aug 2016 09:02:58 -0700 (PDT) In-Reply-To: References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> From: Andy Bierman Date: Thu, 25 Aug 2016 09:02:58 -0700 Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=94eb2c18fe32281eac053ae788b4 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 16:03:03 -0000 --94eb2c18fe32281eac053ae788b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 25, 2016 at 8:54 AM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy, Hi David > > > > There is no requirement to have multiple tools or algorithms producing th= e > same result. > Then it isn't auto-numbering. It is just an offline tool to assign numbers to YANG statements. So there is no need to standardize SID at all. There is just a list of [id, path] mappings in a registry entry, which is what the YID draft proposes. (centralized or distributed list of mappings). Andy > The only requirements we have for YIDs/SIDs are: > > - To be unique (Within the allocated range without duplicate) > > - To be permanent (Registered within a private or public registry) > > > > As demonstrated in one of my last email, all YIDs/SIDs must be registered > even if generated from a hash. > > The algorithm don=E2=80=99t need to be mandated, the registered YIDs/SIDs= are the > IDs to use. > > > > The currently recommended algorithm is described in > > https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-3 > > > > o A tool extracts the different items defined for a specific YANG > > module. > > > > o The list of items is ordered by type and label. > > > > o SIDs are assigned sequentially for the entry point up to the size > > of the registered SID range. It is important to note that > > sequentially assigning SIDs optimizes the CBOR serialization due > > to the use of delta encoding. > > > > o If the number of items exceeds the SID range(s) allocated to a > > YANG module, an extra range is added for subsequent assignments. > > > > SIDs are assigned permanently, items introduced by a new revision of > > a YANG module are added to the list of SIDs already assigned. This > > process can also be automated using the same method described above > > except that the assignment need to be restarted from the highest SID > > already assigned. > > > > Since the file is fully defined, ordering the list within this file and > assigning sequentially IDs to these > > entries can be performed by different tools with the same result. > > > > Regards, > > Michel > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 25, 2016 11:34 AM > *To:* Michel Veillette > *Cc:* David Reid ; core@ietf.org > *Subject:* Re: [core] draft-bierman-core-yid-00.txt questions > > > > > > > > On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette trilliantinc.com> wrote: > > Hi David > > About " Is the sequential numbering auto-assigned or manually assigned? " > > If you use a tool such the pyang plugin, they will be automatically > assigned. > > For example, the command: > pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang > > Generate the file toaster@2009-11-20.sid in attachment. > > The command: > pyang --update-sid-file toaster@2009-11-20.sid toaster@2009-12-28.yang > > > > Where is the algorithm explained in enough detail that multiple > > independent implementations will all produce the exact same results? > > > > > > Andy > > > > Generate the file toaster@2009-12-28.sid in attachment. > > It is important to note that sequential numbering doesn't means that two > data nodes defined sequentially in .yang file will receive consecutive ID= s. > As you known, order may change and grouping may be introduced between > versions. > It means that IDs are assigned sequentially from 1 using some arbitrary > order. > If a .yang module have 14 YANG items, they will be numbered from 1 to 14. > If the next version add 5 YANG items, they will be numbered from 15 to 19= . > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of David Reid > Sent: Wednesday, August 24, 2016 11:24 PM > To: core@ietf.org > Subject: Re: [core] draft-bierman-core-yid-00.txt questions > > >>> What is the benefit of assigning values using hashing over > >>> sequentially assigning values? > > >> There is overhead ir reading and processing a giant list of mappings. > > The assignment only happens one-time, so I don't see a problem with a > little overhead (which I think would be minimal anyway). > > >> Automatic assignment is risky because both sides need to agree on the > >> object to number mapping. Detecting these issues is very difficult. > >> The YANG Hash algorithm is designed to use the path string, which is > >> permanent and cannot change no matter how the YANG is refactored. > >> The murmur hash is a stable algorithm. > >> There is not a lot that can go wrong for the 2 peers to disagree on > >> the hashes (except for collisions) > > I would think we could write an algorithm that would guarantee the same > number every time. Although I have not thought through all the issues tha= t > come up with revisions, maybe this is harder than I think. > > >>> When there is a hash collision, would it be possible to rehash the > >>> value to get a unique number so that we never have to manually > >>> assign numbers and thus never need to register the numbers in the > registry? > > >> yes, this has been suggested. > >> The problem with auto-rehashing before was inter-module clashes. > >> Now those are not possible so automatic rehashing is feasible. > > > [MV] I disagree, see my previous email which explain why all YIDs/SIDs > > need to be registered even if generated using a hash. > > As long as I have either all revisions of a module or the YIDs from the > previous revision, I can generate the numbers for the module. I don't thi= nk > I need it to be in a central registry. > > >>> Would it make sense to put the module-id inside the yang module with > >>> a yid extension so that I would not have to go lookup that > >>> information from a registry? > > >> I suppose -- but how to prevent duplicates and cut-and-paste errors? > > We would still need a registry to prevent duplicates. But only the module > writer would need to access the registry. The module users would have the > information in the yang module and would not have to look at the registry= . > > > [MV] Just adding the module ID in the yang file is not sufficient to > > use a .yang file, all YIDs/SIDs need to be added. > > If YIDs are generated by hashing with auto rehashing on collisions, the > YIDs would not have to be explicitly listed in the module. They could be > auto-generated and stored in a different file. > > > [MV] Having YIDs/SIDs in yang files will make their maintenance more > > complex. > > Yes, it makes it more complex for the module writers. But it is easier on > the users of the module. > > > [MV] BTW, a pyang plugin already exist to automatically generate and > > update a .sid file from a .yang file [MV] See > > [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py > > >>> Would it be possible to assign the module-id based on information in > >>> the module, for example a hash of the namespace and maybe the revisio= n > date. > >>> That way, a module-id would not have to be assigned and maintained > >>> in a registry. > > >> I think private module-id would be better, using a range reserved for > >> temporary assignments. > > I think you are right. I was just hoping we could avoid requiring module > writers to register a module-id by finding a way to auto assign it. > > >> How do you resolve hash collisions for module-id? > > I don't have a good solution. I was hoping the probability of collision > would be low enough to be acceptable, or we could add the first revision = in > the number to further reduce collisions. But I don't have a way to resolv= e > collisions. > > >>> Who will assign the local-id numbers? Is that done by the working > >>> group that defines the YANG module? > > >> I would expect IETF modules to use hashes by default but for some > >> modules that seem useful to constrained devices, then manual > >> numbering could be done instead by the WG. > > > [MV] To obtain a smaller encoding, I personally believe that the > > sequential numbering will be used. > > > [MV] With sequential numbering, all current YANG modules defined in > > RFCs can be assigned within the first 6500 SIDs which will be encoded > > as 3 bytes for the first reference and typically as 1 bytes for the > > following ones using delta encoding. > > > [MV] With hashes, only one YANG module can be assigned within that > > range. > > Is the sequential numbering auto-assigned or manually assigned? > > -David Reid > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > --94eb2c18fe32281eac053ae788b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 25, 2016 at 8:54 AM, Michel Veillette <= ;Mic= hel.Veillette@trilliantinc.com> wrote:

Hi Andy, Hi David

=C2=A0

There is no requirement to have mult= iple tools or algorithms producing the same result.

<= /blockquote>



Then it isn&#= 39;t auto-numbering.
It is just an offline tool to assign numbers= to YANG statements.
So there is no need to standardize SID at al= l.
There is just a list of [id, path] mappings in a registry entr= y,
which is what the YID draft proposes. =C2=A0(centralized or di= stributed list of mappings).


Andy


=C2=A0

The only requirements we have for YI= Ds/SIDs are:

- To be unique (Within the allocated= range without duplicate)

- To be permanent (Registered within= a private or public registry)

=C2=A0

As demonstrated in one of my last em= ail, all YIDs/SIDs must be registered even if generated from a hash.=

The algorithm don=E2=80=99t need to = be mandated, the registered YIDs/SIDs are the IDs to use.

=C2=A0

The currently recommended algorithm = is described in

https://tools.ie= tf.org/html/draft-somaraju-core-sid-01#section-3

=C2=A0

=C2=A0=C2=A0 o=C2=A0 A tool extracts the diffe= rent items defined for a specific YANG

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module.<= u>

=C2=A0

=C2=A0=C2=A0 o=C2=A0 The list of items is orde= red by type and label.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 SIDs are assigned sequent= ially for the entry point up to the size

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the register= ed SID range.=C2=A0 It is important to note that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sequentially as= signing SIDs optimizes the CBOR serialization due

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the use of d= elta encoding.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If the number of items ex= ceeds the SID range(s) allocated to a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 YANG module, an= extra range is added for subsequent assignments.

=C2=A0

=C2=A0=C2=A0 SIDs are assigned permanently=
, items introduced by a new revision of
=C2=A0=C2=A0 a YANG module are added to th=
e list of SIDs already assigned.=C2=A0 This
=C2=A0=C2=A0 process can also be automated=
 using the same method described above
=C2=A0=C2=A0 except that the assignment ne=
ed to be restarted from the highest SID
=C2=A0=C2=A0 already assigned.

=C2=A0

Since the file is fully defined, ord= ering the list within this file and assigning sequentially IDs to these

entries can be performed by differen= t tools with the same result.

=C2=A0

Regards,

Michel

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 25, 2016 11:34 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com><= br> Cc: David Reid <reid@snmp.com>; core@ietf.org
Subject: Re: [core] draft-bierman-core-yid-00.txt questions

=C2=A0

=C2=A0

=C2=A0

On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette &l= t;Mi= chel.Veillette@trilliantinc.com> wrote:

Hi David

About " Is the sequential numbering auto-assigned or manually assigned= ? "

If you use a tool such the pyang plugin, they will be automatically assigne= d.

For example, the command:
=C2=A0 =C2=A0pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang

Generate the file toaster@2009-11-20.sid in attachment.

The command:
=C2=A0 pyang --update-sid-file toaster@2009-11-20.sid=C2=A0 toaster@2009-1= 2-28.yang

=C2=A0

Where is the algorithm explained in enough detail th= at multiple

independent implementations will all produce the exa= ct same results?

=C2=A0

=C2=A0

Andy

=C2=A0

Generate the file toaster@2009-12-28.sid in attachment.

It is important to note that sequential numbering doesn't means that tw= o data nodes defined sequentially in .yang file will receive consecutive ID= s.
As you known, order may change and grouping may be introduced between versi= ons.
It means that IDs are assigned sequentially from 1 using some arbitrary ord= er.
If a .yang module have 14 YANG items, they will be numbered from 1 to 14. If the next version add 5 YANG items, they will be numbered from 15 to 19.<= br>
Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of David Reid
Sent: Wednesday, August 24, 2016 11:24 PM
To: core@ietf.org Subject: Re: [core] draft-bierman-core-yid-00.txt questions

>>> What is the benefit of assigning values using hashing over
>>> sequentially assigning values?

>> There is overhead ir reading and processing a giant list of mappin= gs.

The assignment only happens one-time, so I don't see a problem with a l= ittle overhead (which I think would be minimal anyway).

>> Automatic assignment is risky because both sides need to agree on = the
>> object to number mapping.=C2=A0 Detecting these issues is very dif= ficult.
>> The YANG Hash algorithm is designed to use the path string, which = is
>> permanent and cannot change no matter how the YANG is refactored.<= br> >> The murmur hash is a stable algorithm.
>> There is not a lot that can go wrong for the 2 peers to disagree o= n
>> the hashes (except for collisions)

I would think we could write an algorithm that would guarantee the same num= ber every time. Although I have not thought through all the issues that com= e up with revisions, maybe this is harder than I think.

>>> When there is a hash collision, would it be possible to rehash= the
>>> value to get a unique number so that we never have to manually=
>>> assign numbers and thus never need to register the numbers in = the registry?

>> yes, this has been suggested.
>> The problem with auto-rehashing before was inter-module clashes. >> Now those are not possible so automatic rehashing is feasible.

> [MV] I disagree, see my previous email which explain why all YIDs/SIDs=
> need to be registered even if generated using a hash.

As long as I have either all revisions of a module or the YIDs from the pre= vious revision, I can generate the numbers for the module. I don't thin= k I need it to be in a central registry.

>>> Would it make sense to put the module-id inside the yang modul= e with
>>> a yid extension so that I would not have to go lookup that
>>> information from a registry?

>> I suppose -- but how to prevent duplicates and cut-and-paste error= s?

We would still need a registry to prevent duplicates. But only the module w= riter would need to access the registry. The module users would have the in= formation in the yang module and would not have to look at the registry.
> [MV] Just adding the module ID in the yang file is not sufficient to > use a .yang file, all YIDs/SIDs need to be added.

If YIDs are generated by hashing with auto rehashing on collisions, the YID= s would not have to be explicitly listed in the module. They could be auto-= generated and stored in a different file.

> [MV] Having YIDs/SIDs in yang files will make their maintenance more > complex.

Yes, it makes it more complex for the module writers. But it is easier on t= he users of the module.

> [MV] BTW, a pyang plugin already exist to automatically generate and > update a .sid file from a .yang file [MV] See
> [2]https://github.com/core-wg/yang-cbor/blob/master/si= d.py

>>> Would it be possible to assign the module-id based on informat= ion in
>>> the module, for example a hash of the namespace and maybe the = revision date.
>>> That way, a module-id would not have to be assigned and mainta= ined
>>> in a registry.

>> I think private module-id would be better, using a range reserved = for
>> temporary assignments.

I think you are right. I was just hoping we could avoid requiring module wr= iters to register a module-id by finding a way to auto assign it.

>> How do you resolve hash collisions for module-id?

I don't have a good solution. I was hoping the probability of collision= would be low enough to be acceptable, or we could add the first revision i= n the number to further reduce collisions. But I don't have a way to re= solve collisions.

>>> Who will assign the local-id numbers? Is that done by the work= ing
>>> group that defines the YANG module?

>> I would expect IETF modules to use hashes by default but for some<= br> >> modules that seem useful to constrained devices, then manual
>> numbering could be done instead by the WG.

> [MV] To obtain a smaller encoding, I personally believe that the
> sequential numbering will be used.

> [MV] With sequential numbering, all current YANG modules defined in > RFCs can be assigned within the first 6500 SIDs which will be encoded<= br> > as 3 bytes for the first reference and typically as 1 bytes for the > following ones using delta encoding.

> [MV] With hashes, only one YANG module can be assigned within that
> range.

Is the sequential numbering auto-assigned or manually assigned?

-David Reid

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

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

=C2=A0


--94eb2c18fe32281eac053ae788b4-- From nobody Thu Aug 25 09:15:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D005A12D841 for ; Thu, 25 Aug 2016 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjA8bF_yPPLP for ; Thu, 25 Aug 2016 09:14:54 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA9112D847 for ; Thu, 25 Aug 2016 09:14:54 -0700 (PDT) Received: from mfilter45-d.gandi.net (mfilter45-d.gandi.net [217.70.178.176]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 115DD1720D3; Thu, 25 Aug 2016 18:14:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter45-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter45-d.gandi.net (mfilter45-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fO1h4HD_Bm29; Thu, 25 Aug 2016 18:14:49 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1B3141720A1; Thu, 25 Aug 2016 18:14:48 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_48416EFF-8F16-4509-882B-DFA258609912" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Thu, 25 Aug 2016 18:14:48 +0200 Message-Id: <39F2F14C-8D8B-4B0E-B091-AA1EB1DEE255@ackl.io> References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 16:15:06 -0000 --Apple-Mail=_48416EFF-8F16-4509-882B-DFA258609912 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, > Le 25 ao=C3=BBt 2016 =C3=A0 18:02, Andy Bierman a = =C3=A9crit : >=20 >=20 >=20 > On Thu, Aug 25, 2016 at 8:54 AM, Michel Veillette = > wrote: > Hi Andy, Hi David >=20 > =20 >=20 > There is no requirement to have multiple tools or algorithms producing = the same result. >=20 >=20 >=20 >=20 > Then it isn't auto-numbering. > It is just an offline tool to assign numbers to YANG statements. It is a way to assign numbers=E2=80=A6 automatically. Auto-numbering. > So there is no need to standardize SID at all. > There is just a list of [id, path] mappings in a registry entry, > which is what the YID draft proposes. (centralized or distributed = list of mappings). I think we agree here. The YID draft proposes a subset of what can be = achieved by the SID draft. The YID draft proposes a more complex = process, which does not ensure interoperability, and which puts enormous = strain on IANA, with no description of how a more generic system will = work. Everything you can do with YID you can do with SID. Not everything you = can do with SID can be achieved with YID. SID is simpler. SID cares for ID exhaustion. SID has running code. I think that at this point we should continue the work on SID, and see = how on a next stage to specify the things you want to achieve with YID. = I am not sure this needs an additional draft (or maybe - an = informational one). Best, Alexander >=20 >=20 > Andy >=20 >=20 > =20 >=20 > The only requirements we have for YIDs/SIDs are: >=20 > - To be unique (Within the allocated range without duplicate) >=20 > - To be permanent (Registered within a private or public registry) >=20 > =20 >=20 > As demonstrated in one of my last email, all YIDs/SIDs must be = registered even if generated from a hash. >=20 > The algorithm don=E2=80=99t need to be mandated, the registered = YIDs/SIDs are the IDs to use. >=20 > =20 >=20 > The currently recommended algorithm is described in >=20 > https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-3 = > =20 >=20 > o A tool extracts the different items defined for a specific YANG >=20 > module. >=20 > =20 >=20 > o The list of items is ordered by type and label. >=20 > =20 >=20 > o SIDs are assigned sequentially for the entry point up to the = size >=20 > of the registered SID range. It is important to note that >=20 > sequentially assigning SIDs optimizes the CBOR serialization due >=20 > to the use of delta encoding. >=20 > =20 >=20 > o If the number of items exceeds the SID range(s) allocated to a >=20 > YANG module, an extra range is added for subsequent assignments. >=20 > =20 >=20 > SIDs are assigned permanently, items introduced by a new revision = of > a YANG module are added to the list of SIDs already assigned. This > process can also be automated using the same method described above > except that the assignment need to be restarted from the highest = SID > already assigned. > =20 >=20 > Since the file is fully defined, ordering the list within this file = and assigning sequentially IDs to these >=20 > entries can be performed by different tools with the same result. >=20 > =20 >=20 > Regards, >=20 > Michel >=20 > =20 >=20 > From: Andy Bierman [mailto:andy@yumaworks.com = ]=20 > Sent: Thursday, August 25, 2016 11:34 AM > To: Michel Veillette > > Cc: David Reid >; core@ietf.org = > Subject: Re: [core] draft-bierman-core-yid-00.txt questions >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Thu, Aug 25, 2016 at 7:15 AM, Michel Veillette = > wrote: >=20 > Hi David >=20 > About " Is the sequential numbering auto-assigned or manually = assigned? " >=20 > If you use a tool such the pyang plugin, they will be automatically = assigned. >=20 > For example, the command: > pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang = >=20 > Generate the file toaster@2009-11-20.sid = in attachment. >=20 > The command: > pyang --update-sid-file toaster@2009-11-20.sid = toaster@2009-12-28.yang = > =20 >=20 > Where is the algorithm explained in enough detail that multiple >=20 > independent implementations will all produce the exact same results? >=20 > =20 >=20 > =20 >=20 > Andy >=20 > =20 >=20 > Generate the file toaster@2009-12-28.sid = in attachment. >=20 > It is important to note that sequential numbering doesn't means that = two data nodes defined sequentially in .yang file will receive = consecutive IDs. > As you known, order may change and grouping may be introduced between = versions. > It means that IDs are assigned sequentially from 1 using some = arbitrary order. > If a .yang module have 14 YANG items, they will be numbered from 1 to = 14. > If the next version add 5 YANG items, they will be numbered from 15 to = 19. >=20 > Regards, > Michel >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org = ] On Behalf Of David Reid > Sent: Wednesday, August 24, 2016 11:24 PM > To: core@ietf.org > Subject: Re: [core] draft-bierman-core-yid-00.txt questions >=20 > >>> What is the benefit of assigning values using hashing over > >>> sequentially assigning values? >=20 > >> There is overhead ir reading and processing a giant list of = mappings. >=20 > The assignment only happens one-time, so I don't see a problem with a = little overhead (which I think would be minimal anyway). >=20 > >> Automatic assignment is risky because both sides need to agree on = the > >> object to number mapping. Detecting these issues is very = difficult. > >> The YANG Hash algorithm is designed to use the path string, which = is > >> permanent and cannot change no matter how the YANG is refactored. > >> The murmur hash is a stable algorithm. > >> There is not a lot that can go wrong for the 2 peers to disagree on > >> the hashes (except for collisions) >=20 > I would think we could write an algorithm that would guarantee the = same number every time. Although I have not thought through all the = issues that come up with revisions, maybe this is harder than I think. >=20 > >>> When there is a hash collision, would it be possible to rehash the > >>> value to get a unique number so that we never have to manually > >>> assign numbers and thus never need to register the numbers in the = registry? >=20 > >> yes, this has been suggested. > >> The problem with auto-rehashing before was inter-module clashes. > >> Now those are not possible so automatic rehashing is feasible. >=20 > > [MV] I disagree, see my previous email which explain why all = YIDs/SIDs > > need to be registered even if generated using a hash. >=20 > As long as I have either all revisions of a module or the YIDs from = the previous revision, I can generate the numbers for the module. I = don't think I need it to be in a central registry. >=20 > >>> Would it make sense to put the module-id inside the yang module = with > >>> a yid extension so that I would not have to go lookup that > >>> information from a registry? >=20 > >> I suppose -- but how to prevent duplicates and cut-and-paste = errors? >=20 > We would still need a registry to prevent duplicates. But only the = module writer would need to access the registry. The module users would = have the information in the yang module and would not have to look at = the registry. >=20 > > [MV] Just adding the module ID in the yang file is not sufficient to > > use a .yang file, all YIDs/SIDs need to be added. >=20 > If YIDs are generated by hashing with auto rehashing on collisions, = the YIDs would not have to be explicitly listed in the module. They = could be auto-generated and stored in a different file. >=20 > > [MV] Having YIDs/SIDs in yang files will make their maintenance more > > complex. >=20 > Yes, it makes it more complex for the module writers. But it is easier = on the users of the module. >=20 > > [MV] BTW, a pyang plugin already exist to automatically generate and > > update a .sid file from a .yang file [MV] See > > [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py = >=20 > >>> Would it be possible to assign the module-id based on information = in > >>> the module, for example a hash of the namespace and maybe the = revision date. > >>> That way, a module-id would not have to be assigned and maintained > >>> in a registry. >=20 > >> I think private module-id would be better, using a range reserved = for > >> temporary assignments. >=20 > I think you are right. I was just hoping we could avoid requiring = module writers to register a module-id by finding a way to auto assign = it. >=20 > >> How do you resolve hash collisions for module-id? >=20 > I don't have a good solution. I was hoping the probability of = collision would be low enough to be acceptable, or we could add the = first revision in the number to further reduce collisions. But I don't = have a way to resolve collisions. >=20 > >>> Who will assign the local-id numbers? Is that done by the working > >>> group that defines the YANG module? >=20 > >> I would expect IETF modules to use hashes by default but for some > >> modules that seem useful to constrained devices, then manual > >> numbering could be done instead by the WG. >=20 > > [MV] To obtain a smaller encoding, I personally believe that the > > sequential numbering will be used. >=20 > > [MV] With sequential numbering, all current YANG modules defined in > > RFCs can be assigned within the first 6500 SIDs which will be = encoded > > as 3 bytes for the first reference and typically as 1 bytes for the > > following ones using delta encoding. >=20 > > [MV] With hashes, only one YANG module can be assigned within that > > range. >=20 > Is the sequential numbering auto-assigned or manually assigned? >=20 > -David Reid >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = > =20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_48416EFF-8F16-4509-882B-DFA258609912 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Andy,

Le 25 ao=C3=BBt 2016 =C3=A0 = 18:02, Andy Bierman <andy@yumaworks.com> a =C3=A9crit :



On Thu, Aug 25, 2016 at 8:54 AM, Michel Veillette = <Michel.Veillette@trilliantinc.com> wrote:

Hi Andy, Hi David

 

There is no requirement to have multiple tools or algorithms = producing the same result.




Then it isn't = auto-numbering.
It is just an offline tool to = assign numbers to YANG = statements.

It is a way to assign numbers=E2=80=A6 = automatically. Auto-numbering.

So = there is no need to standardize SID at all.
There = is just a list of [id, path] mappings in a registry entry,
which is what the YID draft proposes.  (centralized or = distributed list of = mappings).

I think we agree here. The YID draft proposes a = subset of what can be achieved by the SID draft. The YID draft proposes = a more complex process, which does not ensure interoperability, and = which puts enormous strain on IANA, with no description of how a more = generic system will work.

Everything = you can do with YID you can do with SID. Not everything you can do with = SID can be achieved with YID.
SID is simpler.
SID = cares for ID exhaustion.
SID has running code.

I think that at this point we should continue the = work on SID, and see how on a next stage to specify the things you want = to achieve with YID. I am not sure this needs an additional draft (or = maybe - an informational one).

Best,
Alexander




Andy


 

The only requirements we have for YIDs/SIDs are:

- To be unique (Within the allocated range without = duplicate)

- To be permanent (Registered within a private or public = registry)

 

As demonstrated in one of my last email, all YIDs/SIDs must = be registered even if generated from a hash.

The algorithm don=E2=80=99t need to be mandated, the = registered YIDs/SIDs are the IDs to use.

 

The currently recommended algorithm is described in

https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-3

 

   o  A tool extracts the = different items defined for a specific YANG

      module.

 

   o  The = list of items is ordered by type and label.

 

   o  SIDs = are assigned sequentially for the entry point up to the size

      of the registered SID = range.  It is important to note that

      sequentially assigning SIDs = optimizes the CBOR serialization due

      to the use of delta = encoding.

 

   o  If = the number of items exceeds the SID range(s) allocated to a

      YANG module, an extra range is = added for subsequent assignments.

 

   SIDs are =
assigned permanently, items introduced by a new revision of
   a YANG module =
are added to the list of SIDs already assigned.  This
   process can =
also be automated using the same method described above
   except that the =
assignment need to be restarted from the highest SID
   already =
assigned.

 

Since the file is fully defined, ordering the list within = this file and assigning sequentially IDs to these

entries can be performed by different tools with the same = result.

 

Regards,

Michel

 

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 25, 2016 11:34 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: David Reid <reid@snmp.com>; core@ietf.org
Subject: Re: [core] draft-bierman-core-yid-00.txt = questions

 

 

 

On Thu, Aug 25, 2016 at 7:15 AM, = Michel Veillette <Michel.Veillette@trilliantinc.com> wrote:

Hi = David

About " Is the sequential numbering auto-assigned or manually assigned? = "

If you use a tool such the pyang plugin, they will be automatically = assigned.

For example, the command:
   pyang --generate-sid-file 20000:100 toaster@2009-11-20.yang

Generate the file toaster@2009-11-20.sid in = attachment.

The command:
  pyang --update-sid-file toaster@2009-11-20.sid  toaster@2009-12-28.yang

 

Where is the algorithm explained = in enough detail that multiple

independent implementations will = all produce the exact same results?

 

 

Andy

 

Generate = the file toaster@2009-12-28.sid in attachment.

It is important to note that sequential numbering doesn't means that two = data nodes defined sequentially in .yang file will receive consecutive = IDs.
As you known, order may change and grouping may be introduced between = versions.
It means that IDs are assigned sequentially from 1 using some arbitrary = order.
If a .yang module have 14 YANG items, they will be numbered from 1 to = 14.
If the next version add 5 YANG items, they will be numbered from 15 to = 19.

Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of = David Reid
Sent: Wednesday, August 24, 2016 11:24 PM
To: core@ietf.org
Subject: Re: [core] draft-bierman-core-yid-00.txt questions
=
>>> What is the benefit of assigning values using hashing = over
>>> sequentially assigning values?

>> There is overhead ir reading and processing a giant list of = mappings.

The assignment only happens one-time, so I don't see a problem with a = little overhead (which I think would be minimal anyway).

>> Automatic assignment is risky because both sides need to agree = on the
>> object to number mapping.  Detecting these issues is very = difficult.
>> The YANG Hash algorithm is designed to use the path string, = which is
>> permanent and cannot change no matter how the YANG is = refactored.
>> The murmur hash is a stable algorithm.
>> There is not a lot that can go wrong for the 2 peers to = disagree on
>> the hashes (except for collisions)

I would think we could write an algorithm that would guarantee the same = number every time. Although I have not thought through all the issues = that come up with revisions, maybe this is harder than I think.

>>> When there is a hash collision, would it be possible to = rehash the
>>> value to get a unique number so that we never have to = manually
>>> assign numbers and thus never need to register the numbers = in the registry?

>> yes, this has been suggested.
>> The problem with auto-rehashing before was inter-module = clashes.
>> Now those are not possible so automatic rehashing is = feasible.

> [MV] I disagree, see my previous email which explain why all = YIDs/SIDs
> need to be registered even if generated using a hash.

As long as I have either all revisions of a module or the YIDs from the = previous revision, I can generate the numbers for the module. I don't = think I need it to be in a central registry.

>>> Would it make sense to put the module-id inside the yang = module with
>>> a yid extension so that I would not have to go lookup = that
>>> information from a registry?

>> I suppose -- but how to prevent duplicates and cut-and-paste = errors?

We would still need a registry to prevent duplicates. But only the = module writer would need to access the registry. The module users would = have the information in the yang module and would not have to look at = the registry.

> [MV] Just adding the module ID in the yang file is not sufficient = to
> use a .yang file, all YIDs/SIDs need to be added.

If YIDs are generated by hashing with auto rehashing on collisions, the = YIDs would not have to be explicitly listed in the module. They could be = auto-generated and stored in a different file.

> [MV] Having YIDs/SIDs in yang files will make their maintenance = more
> complex.

Yes, it makes it more complex for the module writers. But it is easier = on the users of the module.

> [MV] BTW, a pyang plugin already exist to automatically generate = and
> update a .sid file from a .yang file [MV] See
> [2]https://github.com/core-wg/yang-cbor/blob/master/sid.py

>>> Would it be possible to assign the module-id based on = information in
>>> the module, for example a hash of the namespace and maybe = the revision date.
>>> That way, a module-id would not have to be assigned and = maintained
>>> in a registry.

>> I think private module-id would be better, using a range = reserved for
>> temporary assignments.

I think you are right. I was just hoping we could avoid requiring module = writers to register a module-id by finding a way to auto assign it.

>> How do you resolve hash collisions for module-id?

I don't have a good solution. I was hoping the probability of collision = would be low enough to be acceptable, or we could add the first revision = in the number to further reduce collisions. But I don't have a way to = resolve collisions.

>>> Who will assign the local-id numbers? Is that done by the = working
>>> group that defines the YANG module?

>> I would expect IETF modules to use hashes by default but for = some
>> modules that seem useful to constrained devices, then manual
>> numbering could be done instead by the WG.

> [MV] To obtain a smaller encoding, I personally believe that the
> sequential numbering will be used.

> [MV] With sequential numbering, all current YANG modules defined = in
> RFCs can be assigned within the first 6500 SIDs which will be = encoded
> as 3 bytes for the first reference and typically as 1 bytes for = the
> following ones using delta encoding.

> [MV] With hashes, only one YANG module can be assigned within = that
> range.

Is the sequential numbering auto-assigned or manually assigned?

-David Reid

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

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

 


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

= --Apple-Mail=_48416EFF-8F16-4509-882B-DFA258609912-- From nobody Thu Aug 25 09:23:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3CC12D841 for ; Thu, 25 Aug 2016 09:23:13 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOLHS10nucKW for ; Thu, 25 Aug 2016 09:23:10 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0090.outbound.protection.outlook.com [104.47.33.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04C612D1D0 for ; Thu, 25 Aug 2016 09:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/D/fFhBLhDFpk/piBTXEcHSxZSsdhBT1iQoemJeiZ1w=; b=xtci7+P/RiUfyL8Fi8OzxD57GK35qc6C7wSlR9266qleVMzENqwajkjFTdIWpT1IoQJn3Ywwvjr2fXQWE+Ele7wwDg06ODiQ/iFu5ag6QX6iZhRq8tdZ9SzXP8k9h6jEJ+L2QpXT4PW806xdmJ35pem2cWGJjluo7Ib33Chrp3w= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Thu, 25 Aug 2016 16:23:06 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Thu, 25 Aug 2016 16:23:06 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] draft-bierman-core-yid-00.txt questions Thread-Index: AQHR/oAwnsXgBk9RvEWD4CzBgA9zo6BZtb8wgAAZbwCAAAFWcIAABscAgAAAmDA= Date: Thu, 25 Aug 2016 16:23:06 +0000 Message-ID: References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: a86660de-8506-4c66-74ba-08d3cd04186e x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 6:yf4YAQ7de3Cd0R2g8t32CBtNwFpk5XgJNt4yjs4lBnym5vAB7EA2scB5d5xAysPJ02IEhz4tHjpMiuTXh+tOxK9TOJTecuiMeEoDeoaG5hGgO4Hvu6oANER69VSs10BTpcp60sgY5EiuRp80SRTrSaEaOhFPumm9lUIbIWNZuv3sHlT68y3v3XoULyXlBh2b0f0Anrjp9uda7sRA+HtL+oO8B9WedmZeyRIvNphys3VyMWBgtNCD/r2vqNz6BB0s0l2ewS3gogpzWDQFJ5NBgs2K8JZ26wqyKY3nMFiOAiA=; 5:WcSKe6gfLNmQO1VMpPClDrtH6jNCYcFHSbQBEm80vCALx8qlqyzxL5e15jlummXPL4htadKn9oKJ/4uZxXa8EslyOmkBx9SMfs1M6q+Dx9sT079ZO84PwJG+1LLJXVrY0sgi5Qqscfai5HrgaWYM6g==; 24:5gMolkoYn3Nyc0fdoaCLMWVhfrZ0UQQhne4bVQ+/xpCPCNC12jYOkSCQqdmUmTgMjtAzdllvq7QIoX5oioi98D66CqsjTqaLPgebJR2gg28=; 7:pqTMTbte/AN9J8Fc4hc+noaPcjrRBpkXuli2YOIpDa24TTJbypcjDmgKWjqNoIzIBmx+RfXurz62sA38eszs0Kqfv8sCkAAtSF2jOFqvAV527Dr5PTFP6spfVjYx47Q085kXUDsE9E8Bp9OSp/4nCjY7W/np8VsOax9l2MOdowDyo2OQCI4zGMZH4v4/65w56vAfgjcL3cwJTOHV+ab7jdOahACW26grj8aG6VnIOY2wfp3fnM3MZkGjz0n79tU2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(13464003)(51884002)(24454002)(199003)(377454003)(189002)(66066001)(68736007)(93886004)(10400500002)(3660700001)(19609705001)(19617315012)(11100500001)(19580395003)(19580405001)(86362001)(16236675004)(87936001)(5002640100001)(106356001)(33656002)(122556002)(106116001)(8936002)(7906003)(105586002)(586003)(4326007)(5890100001)(101416001)(9686002)(54356999)(50986999)(110136002)(76176999)(3280700002)(7696003)(92566002)(7736002)(7846002)(97736004)(6116002)(230783001)(2950100001)(189998001)(2900100001)(102836003)(5660300001)(790700001)(81156014)(19625215002)(8676002)(77096005)(15975445007)(19300405004)(81166006)(74316002)(3846002)(99286002)(76576001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23082C2A4D43FB6519D13669FEED0BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 16:23:06.0605 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 16:23:14 -0000 --_000_BN6PR06MB23082C2A4D43FB6519D13669FEED0BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpTbyBmYXIsIG5vYm9keSBmb3VuZCBhICJhdXRvLW51bWJlcmluZyIgKG9yIGlt cGxpZWQgbnVtYmVyaW5nKSB3aGljaCB3b3JrLg0KRXZlbiBoYXNoZXMgcmVxdWlyZSBzb21lIG1h bnVhbCBpbnRlcnZlbnRpb24gdG8gcmVnaXN0ZXIgdGhlIGFzc2lnbmVkIFlJRC9TSUQgYW5kIHRv IHJlc29sdmUgY2xhc2hlcy4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQpGcm9tOiBBbmR5IEJpZXJt YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI1 LCAyMDE2IDEyOjAzIFBNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0 cmlsbGlhbnRpbmMuY29tPg0KQ2M6IERhdmlkIFJlaWQgPHJlaWRAc25tcC5jb20+OyBjb3JlQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIGRyYWZ0LWJpZXJtYW4tY29yZS15aWQtMDAudHh0 IHF1ZXN0aW9ucw0KDQoNCg0KT24gVGh1LCBBdWcgMjUsIDIwMTYgYXQgODo1NCBBTSwgTWljaGVs IFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNo ZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+PiB3cm90ZToNCkhpIEFuZHksIEhpIERhdmlk DQoNClRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRvIGhhdmUgbXVsdGlwbGUgdG9vbHMgb3IgYWxn b3JpdGhtcyBwcm9kdWNpbmcgdGhlIHNhbWUgcmVzdWx0Lg0KDQoNCg0KVGhlbiBpdCBpc24ndCBh dXRvLW51bWJlcmluZy4NCkl0IGlzIGp1c3QgYW4gb2ZmbGluZSB0b29sIHRvIGFzc2lnbiBudW1i ZXJzIHRvIFlBTkcgc3RhdGVtZW50cy4NClNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3RhbmRhcmRp emUgU0lEIGF0IGFsbC4NClRoZXJlIGlzIGp1c3QgYSBsaXN0IG9mIFtpZCwgcGF0aF0gbWFwcGlu Z3MgaW4gYSByZWdpc3RyeSBlbnRyeSwNCndoaWNoIGlzIHdoYXQgdGhlIFlJRCBkcmFmdCBwcm9w b3Nlcy4gIChjZW50cmFsaXplZCBvciBkaXN0cmlidXRlZCBsaXN0IG9mIG1hcHBpbmdzKS4NCg0K DQpBbmR5DQoNCg0KDQpUaGUgb25seSByZXF1aXJlbWVudHMgd2UgaGF2ZSBmb3IgWUlEcy9TSURz IGFyZToNCi0gVG8gYmUgdW5pcXVlIChXaXRoaW4gdGhlIGFsbG9jYXRlZCByYW5nZSB3aXRob3V0 IGR1cGxpY2F0ZSkNCi0gVG8gYmUgcGVybWFuZW50IChSZWdpc3RlcmVkIHdpdGhpbiBhIHByaXZh dGUgb3IgcHVibGljIHJlZ2lzdHJ5KQ0KDQpBcyBkZW1vbnN0cmF0ZWQgaW4gb25lIG9mIG15IGxh c3QgZW1haWwsIGFsbCBZSURzL1NJRHMgbXVzdCBiZSByZWdpc3RlcmVkIGV2ZW4gaWYgZ2VuZXJh dGVkIGZyb20gYSBoYXNoLg0KVGhlIGFsZ29yaXRobSBkb27igJl0IG5lZWQgdG8gYmUgbWFuZGF0 ZWQsIHRoZSByZWdpc3RlcmVkIFlJRHMvU0lEcyBhcmUgdGhlIElEcyB0byB1c2UuDQoNClRoZSBj dXJyZW50bHkgcmVjb21tZW5kZWQgYWxnb3JpdGhtIGlzIGRlc2NyaWJlZCBpbg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkLTAxI3NlY3Rpb24tMw0K DQogICBvICBBIHRvb2wgZXh0cmFjdHMgdGhlIGRpZmZlcmVudCBpdGVtcyBkZWZpbmVkIGZvciBh IHNwZWNpZmljIFlBTkcNCiAgICAgIG1vZHVsZS4NCg0KICAgbyAgVGhlIGxpc3Qgb2YgaXRlbXMg aXMgb3JkZXJlZCBieSB0eXBlIGFuZCBsYWJlbC4NCg0KICAgbyAgU0lEcyBhcmUgYXNzaWduZWQg c2VxdWVudGlhbGx5IGZvciB0aGUgZW50cnkgcG9pbnQgdXAgdG8gdGhlIHNpemUNCiAgICAgIG9m IHRoZSByZWdpc3RlcmVkIFNJRCByYW5nZS4gIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQN CiAgICAgIHNlcXVlbnRpYWxseSBhc3NpZ25pbmcgU0lEcyBvcHRpbWl6ZXMgdGhlIENCT1Igc2Vy aWFsaXphdGlvbiBkdWUNCiAgICAgIHRvIHRoZSB1c2Ugb2YgZGVsdGEgZW5jb2RpbmcuDQoNCiAg IG8gIElmIHRoZSBudW1iZXIgb2YgaXRlbXMgZXhjZWVkcyB0aGUgU0lEIHJhbmdlKHMpIGFsbG9j YXRlZCB0byBhDQogICAgICBZQU5HIG1vZHVsZSwgYW4gZXh0cmEgcmFuZ2UgaXMgYWRkZWQgZm9y IHN1YnNlcXVlbnQgYXNzaWdubWVudHMuDQoNCg0KICAgU0lEcyBhcmUgYXNzaWduZWQgcGVybWFu ZW50bHksIGl0ZW1zIGludHJvZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24gb2YNCg0KICAgYSBZQU5H IG1vZHVsZSBhcmUgYWRkZWQgdG8gdGhlIGxpc3Qgb2YgU0lEcyBhbHJlYWR5IGFzc2lnbmVkLiAg VGhpcw0KDQogICBwcm9jZXNzIGNhbiBhbHNvIGJlIGF1dG9tYXRlZCB1c2luZyB0aGUgc2FtZSBt ZXRob2QgZGVzY3JpYmVkIGFib3ZlDQoNCiAgIGV4Y2VwdCB0aGF0IHRoZSBhc3NpZ25tZW50IG5l ZWQgdG8gYmUgcmVzdGFydGVkIGZyb20gdGhlIGhpZ2hlc3QgU0lEDQoNCiAgIGFscmVhZHkgYXNz aWduZWQuDQoNClNpbmNlIHRoZSBmaWxlIGlzIGZ1bGx5IGRlZmluZWQsIG9yZGVyaW5nIHRoZSBs aXN0IHdpdGhpbiB0aGlzIGZpbGUgYW5kIGFzc2lnbmluZyBzZXF1ZW50aWFsbHkgSURzIHRvIHRo ZXNlDQplbnRyaWVzIGNhbiBiZSBwZXJmb3JtZWQgYnkgZGlmZmVyZW50IHRvb2xzIHdpdGggdGhl IHNhbWUgcmVzdWx0Lg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZyb206IEFuZHkgQmllcm1hbiBb bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPl0NClNl bnQ6IFRodXJzZGF5LCBBdWd1c3QgMjUsIDIwMTYgMTE6MzQgQU0NClRvOiBNaWNoZWwgVmVpbGxl dHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hlbC5WZWls bGV0dGVAdHJpbGxpYW50aW5jLmNvbT4+DQpDYzogRGF2aWQgUmVpZCA8cmVpZEBzbm1wLmNvbTxt YWlsdG86cmVpZEBzbm1wLmNvbT4+OyBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dCBxdWVz dGlvbnMNCg0KDQoNCk9uIFRodSwgQXVnIDI1LCAyMDE2IGF0IDc6MTUgQU0sIE1pY2hlbCBWZWls bGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTxtYWlsdG86TWljaGVsLlZl aWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPj4gd3JvdGU6DQpIaSBEYXZpZA0KDQpBYm91dCAiIElz IHRoZSBzZXF1ZW50aWFsIG51bWJlcmluZyBhdXRvLWFzc2lnbmVkIG9yIG1hbnVhbGx5IGFzc2ln bmVkPyAiDQoNCklmIHlvdSB1c2UgYSB0b29sIHN1Y2ggdGhlIHB5YW5nIHBsdWdpbiwgdGhleSB3 aWxsIGJlIGF1dG9tYXRpY2FsbHkgYXNzaWduZWQuDQoNCkZvciBleGFtcGxlLCB0aGUgY29tbWFu ZDoNCiAgIHB5YW5nIC0tZ2VuZXJhdGUtc2lkLWZpbGUgMjAwMDA6MTAwIHRvYXN0ZXJAMjAwOS0x MS0yMC55YW5nPG1haWx0bzp0b2FzdGVyQDIwMDktMTEtMjAueWFuZz4NCg0KR2VuZXJhdGUgdGhl IGZpbGUgdG9hc3RlckAyMDA5LTExLTIwLnNpZDxtYWlsdG86dG9hc3RlckAyMDA5LTExLTIwLnNp ZD4gaW4gYXR0YWNobWVudC4NCg0KVGhlIGNvbW1hbmQ6DQogIHB5YW5nIC0tdXBkYXRlLXNpZC1m aWxlIHRvYXN0ZXJAMjAwOS0xMS0yMC5zaWQ8bWFpbHRvOnRvYXN0ZXJAMjAwOS0xMS0yMC5zaWQ+ ICB0b2FzdGVyQDIwMDktMTItMjgueWFuZzxtYWlsdG86dG9hc3RlckAyMDA5LTEyLTI4Lnlhbmc+ DQoNCldoZXJlIGlzIHRoZSBhbGdvcml0aG0gZXhwbGFpbmVkIGluIGVub3VnaCBkZXRhaWwgdGhh dCBtdWx0aXBsZQ0KaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHdpbGwgYWxsIHByb2R1Y2Ug dGhlIGV4YWN0IHNhbWUgcmVzdWx0cz8NCg0KDQpBbmR5DQoNCkdlbmVyYXRlIHRoZSBmaWxlIHRv YXN0ZXJAMjAwOS0xMi0yOC5zaWQ8bWFpbHRvOnRvYXN0ZXJAMjAwOS0xMi0yOC5zaWQ+IGluIGF0 dGFjaG1lbnQuDQoNCkl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgc2VxdWVudGlhbCBudW1i ZXJpbmcgZG9lc24ndCBtZWFucyB0aGF0IHR3byBkYXRhIG5vZGVzIGRlZmluZWQgc2VxdWVudGlh bGx5IGluIC55YW5nIGZpbGUgd2lsbCByZWNlaXZlIGNvbnNlY3V0aXZlIElEcy4NCkFzIHlvdSBr bm93biwgb3JkZXIgbWF5IGNoYW5nZSBhbmQgZ3JvdXBpbmcgbWF5IGJlIGludHJvZHVjZWQgYmV0 d2VlbiB2ZXJzaW9ucy4NCkl0IG1lYW5zIHRoYXQgSURzIGFyZSBhc3NpZ25lZCBzZXF1ZW50aWFs bHkgZnJvbSAxIHVzaW5nIHNvbWUgYXJiaXRyYXJ5IG9yZGVyLg0KSWYgYSAueWFuZyBtb2R1bGUg aGF2ZSAxNCBZQU5HIGl0ZW1zLCB0aGV5IHdpbGwgYmUgbnVtYmVyZWQgZnJvbSAxIHRvIDE0Lg0K SWYgdGhlIG5leHQgdmVyc2lvbiBhZGQgNSBZQU5HIGl0ZW1zLCB0aGV5IHdpbGwgYmUgbnVtYmVy ZWQgZnJvbSAxNSB0byAxOS4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERhdmlkIFJlaWQNClNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDI0LCAyMDE2IDExOjI0IFBNDQpUbzogY29yZUBpZXRmLm9yZzxt YWlsdG86Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gZHJhZnQtYmllcm1hbi1j b3JlLXlpZC0wMC50eHQgcXVlc3Rpb25zDQoNCj4+PiBXaGF0IGlzIHRoZSBiZW5lZml0IG9mIGFz c2lnbmluZyB2YWx1ZXMgdXNpbmcgaGFzaGluZyBvdmVyDQo+Pj4gc2VxdWVudGlhbGx5IGFzc2ln bmluZyB2YWx1ZXM/DQoNCj4+IFRoZXJlIGlzIG92ZXJoZWFkIGlyIHJlYWRpbmcgYW5kIHByb2Nl c3NpbmcgYSBnaWFudCBsaXN0IG9mIG1hcHBpbmdzLg0KDQpUaGUgYXNzaWdubWVudCBvbmx5IGhh cHBlbnMgb25lLXRpbWUsIHNvIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSB3aXRoIGEgbGl0dGxlIG92 ZXJoZWFkICh3aGljaCBJIHRoaW5rIHdvdWxkIGJlIG1pbmltYWwgYW55d2F5KS4NCg0KPj4gQXV0 b21hdGljIGFzc2lnbm1lbnQgaXMgcmlza3kgYmVjYXVzZSBib3RoIHNpZGVzIG5lZWQgdG8gYWdy ZWUgb24gdGhlDQo+PiBvYmplY3QgdG8gbnVtYmVyIG1hcHBpbmcuICBEZXRlY3RpbmcgdGhlc2Ug aXNzdWVzIGlzIHZlcnkgZGlmZmljdWx0Lg0KPj4gVGhlIFlBTkcgSGFzaCBhbGdvcml0aG0gaXMg ZGVzaWduZWQgdG8gdXNlIHRoZSBwYXRoIHN0cmluZywgd2hpY2ggaXMNCj4+IHBlcm1hbmVudCBh bmQgY2Fubm90IGNoYW5nZSBubyBtYXR0ZXIgaG93IHRoZSBZQU5HIGlzIHJlZmFjdG9yZWQuDQo+ PiBUaGUgbXVybXVyIGhhc2ggaXMgYSBzdGFibGUgYWxnb3JpdGhtLg0KPj4gVGhlcmUgaXMgbm90 IGEgbG90IHRoYXQgY2FuIGdvIHdyb25nIGZvciB0aGUgMiBwZWVycyB0byBkaXNhZ3JlZSBvbg0K Pj4gdGhlIGhhc2hlcyAoZXhjZXB0IGZvciBjb2xsaXNpb25zKQ0KDQpJIHdvdWxkIHRoaW5rIHdl IGNvdWxkIHdyaXRlIGFuIGFsZ29yaXRobSB0aGF0IHdvdWxkIGd1YXJhbnRlZSB0aGUgc2FtZSBu dW1iZXIgZXZlcnkgdGltZS4gQWx0aG91Z2ggSSBoYXZlIG5vdCB0aG91Z2h0IHRocm91Z2ggYWxs IHRoZSBpc3N1ZXMgdGhhdCBjb21lIHVwIHdpdGggcmV2aXNpb25zLCBtYXliZSB0aGlzIGlzIGhh cmRlciB0aGFuIEkgdGhpbmsuDQoNCj4+PiBXaGVuIHRoZXJlIGlzIGEgaGFzaCBjb2xsaXNpb24s IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHJlaGFzaCB0aGUNCj4+PiB2YWx1ZSB0byBnZXQgYSB1 bmlxdWUgbnVtYmVyIHNvIHRoYXQgd2UgbmV2ZXIgaGF2ZSB0byBtYW51YWxseQ0KPj4+IGFzc2ln biBudW1iZXJzIGFuZCB0aHVzIG5ldmVyIG5lZWQgdG8gcmVnaXN0ZXIgdGhlIG51bWJlcnMgaW4g dGhlIHJlZ2lzdHJ5Pw0KDQo+PiB5ZXMsIHRoaXMgaGFzIGJlZW4gc3VnZ2VzdGVkLg0KPj4gVGhl IHByb2JsZW0gd2l0aCBhdXRvLXJlaGFzaGluZyBiZWZvcmUgd2FzIGludGVyLW1vZHVsZSBjbGFz aGVzLg0KPj4gTm93IHRob3NlIGFyZSBub3QgcG9zc2libGUgc28gYXV0b21hdGljIHJlaGFzaGlu ZyBpcyBmZWFzaWJsZS4NCg0KPiBbTVZdIEkgZGlzYWdyZWUsIHNlZSBteSBwcmV2aW91cyBlbWFp bCB3aGljaCBleHBsYWluIHdoeSBhbGwgWUlEcy9TSURzDQo+IG5lZWQgdG8gYmUgcmVnaXN0ZXJl ZCBldmVuIGlmIGdlbmVyYXRlZCB1c2luZyBhIGhhc2guDQoNCkFzIGxvbmcgYXMgSSBoYXZlIGVp dGhlciBhbGwgcmV2aXNpb25zIG9mIGEgbW9kdWxlIG9yIHRoZSBZSURzIGZyb20gdGhlIHByZXZp b3VzIHJldmlzaW9uLCBJIGNhbiBnZW5lcmF0ZSB0aGUgbnVtYmVycyBmb3IgdGhlIG1vZHVsZS4g SSBkb24ndCB0aGluayBJIG5lZWQgaXQgdG8gYmUgaW4gYSBjZW50cmFsIHJlZ2lzdHJ5Lg0KDQo+ Pj4gV291bGQgaXQgbWFrZSBzZW5zZSB0byBwdXQgdGhlIG1vZHVsZS1pZCBpbnNpZGUgdGhlIHlh bmcgbW9kdWxlIHdpdGgNCj4+PiBhIHlpZCBleHRlbnNpb24gc28gdGhhdCBJIHdvdWxkIG5vdCBo YXZlIHRvIGdvIGxvb2t1cCB0aGF0DQo+Pj4gaW5mb3JtYXRpb24gZnJvbSBhIHJlZ2lzdHJ5Pw0K DQo+PiBJIHN1cHBvc2UgLS0gYnV0IGhvdyB0byBwcmV2ZW50IGR1cGxpY2F0ZXMgYW5kIGN1dC1h bmQtcGFzdGUgZXJyb3JzPw0KDQpXZSB3b3VsZCBzdGlsbCBuZWVkIGEgcmVnaXN0cnkgdG8gcHJl dmVudCBkdXBsaWNhdGVzLiBCdXQgb25seSB0aGUgbW9kdWxlIHdyaXRlciB3b3VsZCBuZWVkIHRv IGFjY2VzcyB0aGUgcmVnaXN0cnkuIFRoZSBtb2R1bGUgdXNlcnMgd291bGQgaGF2ZSB0aGUgaW5m b3JtYXRpb24gaW4gdGhlIHlhbmcgbW9kdWxlIGFuZCB3b3VsZCBub3QgaGF2ZSB0byBsb29rIGF0 IHRoZSByZWdpc3RyeS4NCg0KPiBbTVZdIEp1c3QgYWRkaW5nIHRoZSBtb2R1bGUgSUQgaW4gdGhl IHlhbmcgZmlsZSBpcyBub3Qgc3VmZmljaWVudCB0bw0KPiB1c2UgYSAueWFuZyBmaWxlLCBhbGwg WUlEcy9TSURzIG5lZWQgdG8gYmUgYWRkZWQuDQoNCklmIFlJRHMgYXJlIGdlbmVyYXRlZCBieSBo YXNoaW5nIHdpdGggYXV0byByZWhhc2hpbmcgb24gY29sbGlzaW9ucywgdGhlIFlJRHMgd291bGQg bm90IGhhdmUgdG8gYmUgZXhwbGljaXRseSBsaXN0ZWQgaW4gdGhlIG1vZHVsZS4gVGhleSBjb3Vs ZCBiZSBhdXRvLWdlbmVyYXRlZCBhbmQgc3RvcmVkIGluIGEgZGlmZmVyZW50IGZpbGUuDQoNCj4g W01WXSBIYXZpbmcgWUlEcy9TSURzIGluIHlhbmcgZmlsZXMgd2lsbCBtYWtlIHRoZWlyIG1haW50 ZW5hbmNlIG1vcmUNCj4gY29tcGxleC4NCg0KWWVzLCBpdCBtYWtlcyBpdCBtb3JlIGNvbXBsZXgg Zm9yIHRoZSBtb2R1bGUgd3JpdGVycy4gQnV0IGl0IGlzIGVhc2llciBvbiB0aGUgdXNlcnMgb2Yg dGhlIG1vZHVsZS4NCg0KPiBbTVZdIEJUVywgYSBweWFuZyBwbHVnaW4gYWxyZWFkeSBleGlzdCB0 byBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlIGFuZA0KPiB1cGRhdGUgYSAuc2lkIGZpbGUgZnJvbSBh IC55YW5nIGZpbGUgW01WXSBTZWUNCj4gWzJdaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cveWFu Zy1jYm9yL2Jsb2IvbWFzdGVyL3NpZC5weQ0KDQo+Pj4gV291bGQgaXQgYmUgcG9zc2libGUgdG8g YXNzaWduIHRoZSBtb2R1bGUtaWQgYmFzZWQgb24gaW5mb3JtYXRpb24gaW4NCj4+PiB0aGUgbW9k dWxlLCBmb3IgZXhhbXBsZSBhIGhhc2ggb2YgdGhlIG5hbWVzcGFjZSBhbmQgbWF5YmUgdGhlIHJl dmlzaW9uIGRhdGUuDQo+Pj4gVGhhdCB3YXksIGEgbW9kdWxlLWlkIHdvdWxkIG5vdCBoYXZlIHRv IGJlIGFzc2lnbmVkIGFuZCBtYWludGFpbmVkDQo+Pj4gaW4gYSByZWdpc3RyeS4NCg0KPj4gSSB0 aGluayBwcml2YXRlIG1vZHVsZS1pZCB3b3VsZCBiZSBiZXR0ZXIsIHVzaW5nIGEgcmFuZ2UgcmVz ZXJ2ZWQgZm9yDQo+PiB0ZW1wb3JhcnkgYXNzaWdubWVudHMuDQoNCkkgdGhpbmsgeW91IGFyZSBy aWdodC4gSSB3YXMganVzdCBob3Bpbmcgd2UgY291bGQgYXZvaWQgcmVxdWlyaW5nIG1vZHVsZSB3 cml0ZXJzIHRvIHJlZ2lzdGVyIGEgbW9kdWxlLWlkIGJ5IGZpbmRpbmcgYSB3YXkgdG8gYXV0byBh c3NpZ24gaXQuDQoNCj4+IEhvdyBkbyB5b3UgcmVzb2x2ZSBoYXNoIGNvbGxpc2lvbnMgZm9yIG1v ZHVsZS1pZD8NCg0KSSBkb24ndCBoYXZlIGEgZ29vZCBzb2x1dGlvbi4gSSB3YXMgaG9waW5nIHRo ZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb24gd291bGQgYmUgbG93IGVub3VnaCB0byBiZSBhY2Nl cHRhYmxlLCBvciB3ZSBjb3VsZCBhZGQgdGhlIGZpcnN0IHJldmlzaW9uIGluIHRoZSBudW1iZXIg dG8gZnVydGhlciByZWR1Y2UgY29sbGlzaW9ucy4gQnV0IEkgZG9uJ3QgaGF2ZSBhIHdheSB0byBy ZXNvbHZlIGNvbGxpc2lvbnMuDQoNCj4+PiBXaG8gd2lsbCBhc3NpZ24gdGhlIGxvY2FsLWlkIG51 bWJlcnM/IElzIHRoYXQgZG9uZSBieSB0aGUgd29ya2luZw0KPj4+IGdyb3VwIHRoYXQgZGVmaW5l cyB0aGUgWUFORyBtb2R1bGU/DQoNCj4+IEkgd291bGQgZXhwZWN0IElFVEYgbW9kdWxlcyB0byB1 c2UgaGFzaGVzIGJ5IGRlZmF1bHQgYnV0IGZvciBzb21lDQo+PiBtb2R1bGVzIHRoYXQgc2VlbSB1 c2VmdWwgdG8gY29uc3RyYWluZWQgZGV2aWNlcywgdGhlbiBtYW51YWwNCj4+IG51bWJlcmluZyBj b3VsZCBiZSBkb25lIGluc3RlYWQgYnkgdGhlIFdHLg0KDQo+IFtNVl0gVG8gb2J0YWluIGEgc21h bGxlciBlbmNvZGluZywgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB0aGUNCj4gc2VxdWVudGlh bCBudW1iZXJpbmcgd2lsbCBiZSB1c2VkLg0KDQo+IFtNVl0gV2l0aCBzZXF1ZW50aWFsIG51bWJl cmluZywgYWxsIGN1cnJlbnQgWUFORyBtb2R1bGVzIGRlZmluZWQgaW4NCj4gUkZDcyBjYW4gYmUg YXNzaWduZWQgd2l0aGluIHRoZSBmaXJzdCA2NTAwIFNJRHMgd2hpY2ggd2lsbCBiZSBlbmNvZGVk DQo+IGFzIDMgYnl0ZXMgZm9yIHRoZSBmaXJzdCByZWZlcmVuY2UgYW5kIHR5cGljYWxseSBhcyAx IGJ5dGVzIGZvciB0aGUNCj4gZm9sbG93aW5nIG9uZXMgdXNpbmcgZGVsdGEgZW5jb2RpbmcuDQoN Cj4gW01WXSBXaXRoIGhhc2hlcywgb25seSBvbmUgWUFORyBtb2R1bGUgY2FuIGJlIGFzc2lnbmVk IHdpdGhpbiB0aGF0DQo+IHJhbmdlLg0KDQpJcyB0aGUgc2VxdWVudGlhbCBudW1iZXJpbmcgYXV0 by1hc3NpZ25lZCBvciBtYW51YWxseSBhc3NpZ25lZD8NCg0KLURhdmlkIFJlaWQNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBs aXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxt YWlsdG86Y29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZQ0KDQoNCg== --_000_BN6PR06MB23082C2A4D43FB6519D13669FEED0BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEFuZHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyBmYXIsIG5vYm9keSBm b3VuZCBhICZxdW90O2F1dG8tbnVtYmVyaW5nJnF1b3Q7IChvciBpbXBsaWVkIG51bWJlcmluZykg d2hpY2ggd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FdmVuIGhhc2hlcyByZXF1aXJlIHNvbWUgbWFu dWFsIGludGVydmVudGlvbiB0byByZWdpc3RlciB0aGUgYXNzaWduZWQgWUlEL1NJRCBhbmQgdG8g cmVzb2x2ZSBjbGFzaGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWljaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuIFtt YWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBB dWd1c3QgMjUsIDIwMTYgMTI6MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hlbCBWZWlsbGV0dGUg Jmx0O01pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IERhdmlkIFJlaWQgJmx0O3JlaWRAc25tcC5jb20mZ3Q7OyBjb3JlQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gZHJhZnQtYmllcm1hbi1jb3JlLXlpZC0wMC50eHQgcXVl c3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgMjUsIDIwMTYgYXQg ODo1NCBBTSwgTWljaGVsIFZlaWxsZXR0ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hlbC5WZWls bGV0dGVAdHJpbGxpYW50aW5jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hlbC5WZWlsbGV0dGVA dHJpbGxpYW50aW5jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQW5k eSwgSGkgRGF2aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdG8gaGF2ZSBtdWx0aXBsZSB0b29scyBvciBhbGdvcml0 aG1zIHByb2R1Y2luZyB0aGUgc2FtZSByZXN1bHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGVuIGl0IGlzbid0IGF1dG8tbnVtYmVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMganVzdCBhbiBvZmZsaW5lIHRvb2wg dG8gYXNzaWduIG51bWJlcnMgdG8gWUFORyBzdGF0ZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdGhlcmUgaXMgbm8gbmVlZCB0byBz dGFuZGFyZGl6ZSBTSUQgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMganVzdCBhIGxpc3Qgb2YgW2lkLCBwYXRoXSBtYXBw aW5ncyBpbiBhIHJlZ2lzdHJ5IGVudHJ5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hpY2ggaXMgd2hhdCB0aGUgWUlEIGRyYWZ0IHByb3Bvc2Vz LiAmbmJzcDsoY2VudHJhbGl6ZWQgb3IgZGlzdHJpYnV0ZWQgbGlzdCBvZiBtYXBwaW5ncykuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5k eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgb25seSByZXF1aXJlbWVudHMg d2UgaGF2ZSBmb3IgWUlEcy9TSURzIGFyZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0gVG8gYmUgdW5p cXVlIChXaXRoaW4gdGhlIGFsbG9jYXRlZCByYW5nZSB3aXRob3V0IGR1cGxpY2F0ZSk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPi0gVG8gYmUgcGVybWFuZW50IChSZWdpc3RlcmVkIHdpdGhpbiBhIHByaXZh dGUgb3IgcHVibGljIHJlZ2lzdHJ5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5BcyBkZW1vbnN0cmF0ZWQgaW4gb25lIG9mIG15IGxhc3QgZW1haWwsIGFsbCBZ SURzL1NJRHMgbXVzdCBiZSByZWdpc3RlcmVkIGV2ZW4gaWYgZ2VuZXJhdGVkIGZyb20gYSBoYXNo Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGFsZ29yaXRobSBkb27igJl0IG5lZWQgdG8gYmUgbWFu ZGF0ZWQsIHRoZSByZWdpc3RlcmVkIFlJRHMvU0lEcyBhcmUgdGhlIElEcyB0byB1c2UuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBjdXJyZW50bHkgcmVj b21tZW5kZWQgYWxnb3JpdGhtIGlzIGRlc2NyaWJlZCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkLTAxI3NlY3Rpb24tMyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zb21hcmFqdS1jb3JlLXNpZC0wMSNzZWN0aW9uLTM8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBIHRvb2wgZXh0cmFj dHMgdGhlIGRpZmZlcmVudCBpdGVtcyBkZWZpbmVkIGZvciBhIHNwZWNpZmljIFlBTkc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9kdWxlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBsaXN0IG9mIGl0ZW1zIGlz IG9yZGVyZWQgYnkgdHlwZSBhbmQgbGFiZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgU0lEcyBhcmUgYXNzaWduZWQgc2VxdWVudGlhbGx5IGZvciB0 aGUgZW50cnkgcG9pbnQgdXAgdG8gdGhlIHNpemU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgb2YgdGhlIHJlZ2lzdGVyZWQgU0lEIHJhbmdlLiZuYnNwOyBJdCBpcyBp bXBvcnRhbnQgdG8gbm90ZSB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNlcXVlbnRpYWxseSBhc3NpZ25pbmcgU0lEcyBvcHRpbWl6ZXMgdGhlIENCT1Igc2Vy aWFsaXphdGlvbiBkdWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dG8gdGhlIHVzZSBvZiBkZWx0YSBlbmNvZGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBJZiB0aGUgbnVtYmVyIG9mIGl0ZW1zIGV4Y2VlZHMgdGhl IFNJRCByYW5nZShzKSBhbGxvY2F0ZWQgdG8gYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBZQU5HIG1vZHVsZSwgYW4gZXh0cmEgcmFuZ2UgaXMgYWRkZWQgZm9yIHN1 YnNlcXVlbnQgYXNzaWdubWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU0lEcyBhcmUgYXNz aWduZWQgcGVybWFuZW50bHksIGl0ZW1zIGludHJvZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24gb2Y8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgYSBZQU5HIG1vZHVsZSBhcmUgYWRkZWQgdG8gdGhlIGxpc3Qgb2YgU0lEcyBh bHJlYWR5IGFzc2lnbmVkLiZuYnNwOyBUaGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHByb2Nlc3MgY2FuIGFsc28g YmUgYXV0b21hdGVkIHVzaW5nIHRoZSBzYW1lIG1ldGhvZCBkZXNjcmliZWQgYWJvdmU8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZXhjZXB0IHRoYXQgdGhlIGFzc2lnbm1lbnQgbmVlZCB0byBiZSByZXN0YXJ0ZWQgZnJv bSB0aGUgaGlnaGVzdCBTSUQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWxyZWFkeSBhc3NpZ25lZC48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TaW5jZSB0aGUgZmlsZSBpcyBm dWxseSBkZWZpbmVkLCBvcmRlcmluZyB0aGUgbGlzdCB3aXRoaW4gdGhpcyBmaWxlIGFuZCBhc3Np Z25pbmcgc2VxdWVudGlhbGx5IElEcyB0bw0KIHRoZXNlIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZW50 cmllcyBjYW4gYmUgcGVyZm9ybWVkIGJ5IGRpZmZlcmVudCB0b29scyB3aXRoIHRoZSBzYW1lIHJl c3VsdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21h aWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YW5keUB5dW1hd29ya3MuY29tPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDI1LCAy MDE2IDExOjM0IEFNPGJyPg0KPGI+VG86PC9iPiBNaWNoZWwgVmVpbGxldHRlICZsdDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMu Y29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IERhdmlk IFJlaWQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmVpZEBzbm1wLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cmVpZEBzbm1wLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5jb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIGRyYWZ0LWJpZXJt YW4tY29yZS15aWQtMDAudHh0IHF1ZXN0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVGh1LCBBdWcgMjUsIDIwMTYgYXQgNzoxNSBBTSwgTWljaGVsIFZlaWxsZXR0ZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIERhdmlkPGJyPg0KPGJyPg0KQWJvdXQg JnF1b3Q7IElzIHRoZSBzZXF1ZW50aWFsIG51bWJlcmluZyBhdXRvLWFzc2lnbmVkIG9yIG1hbnVh bGx5IGFzc2lnbmVkPyAmcXVvdDs8YnI+DQo8YnI+DQpJZiB5b3UgdXNlIGEgdG9vbCBzdWNoIHRo ZSBweWFuZyBwbHVnaW4sIHRoZXkgd2lsbCBiZSBhdXRvbWF0aWNhbGx5IGFzc2lnbmVkLjxicj4N Cjxicj4NCkZvciBleGFtcGxlLCB0aGUgY29tbWFuZDo8YnI+DQombmJzcDsgJm5ic3A7cHlhbmcg LS1nZW5lcmF0ZS1zaWQtZmlsZSAyMDAwMDoxMDAgPGEgaHJlZj0ibWFpbHRvOnRvYXN0ZXJAMjAw OS0xMS0yMC55YW5nIiB0YXJnZXQ9Il9ibGFuayI+DQp0b2FzdGVyQDIwMDktMTEtMjAueWFuZzwv YT48YnI+DQo8YnI+DQpHZW5lcmF0ZSB0aGUgZmlsZSA8YSBocmVmPSJtYWlsdG86dG9hc3RlckAy MDA5LTExLTIwLnNpZCIgdGFyZ2V0PSJfYmxhbmsiPnRvYXN0ZXJAMjAwOS0xMS0yMC5zaWQ8L2E+ IGluIGF0dGFjaG1lbnQuPGJyPg0KPGJyPg0KVGhlIGNvbW1hbmQ6PGJyPg0KJm5ic3A7IHB5YW5n IC0tdXBkYXRlLXNpZC1maWxlIDxhIGhyZWY9Im1haWx0bzp0b2FzdGVyQDIwMDktMTEtMjAuc2lk IiB0YXJnZXQ9Il9ibGFuayI+DQp0b2FzdGVyQDIwMDktMTEtMjAuc2lkPC9hPiZuYnNwOyA8YSBo cmVmPSJtYWlsdG86dG9hc3RlckAyMDA5LTEyLTI4LnlhbmciIHRhcmdldD0iX2JsYW5rIj4NCnRv YXN0ZXJAMjAwOS0xMi0yOC55YW5nPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoZXJlIGlzIHRoZSBhbGdvcml0aG0g ZXhwbGFpbmVkIGluIGVub3VnaCBkZXRhaWwgdGhhdCBtdWx0aXBsZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbmRlcGVuZGVudCBpbXBsZW1l bnRhdGlvbnMgd2lsbCBhbGwgcHJvZHVjZSB0aGUgZXhhY3Qgc2FtZSByZXN1bHRzPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFu ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5HZW5lcmF0ZSB0aGUgZmls ZQ0KPGEgaHJlZj0ibWFpbHRvOnRvYXN0ZXJAMjAwOS0xMi0yOC5zaWQiIHRhcmdldD0iX2JsYW5r Ij50b2FzdGVyQDIwMDktMTItMjguc2lkPC9hPiBpbiBhdHRhY2htZW50Ljxicj4NCjxicj4NCkl0 IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgc2VxdWVudGlhbCBudW1iZXJpbmcgZG9lc24ndCBt ZWFucyB0aGF0IHR3byBkYXRhIG5vZGVzIGRlZmluZWQgc2VxdWVudGlhbGx5IGluIC55YW5nIGZp bGUgd2lsbCByZWNlaXZlIGNvbnNlY3V0aXZlIElEcy48YnI+DQpBcyB5b3Uga25vd24sIG9yZGVy IG1heSBjaGFuZ2UgYW5kIGdyb3VwaW5nIG1heSBiZSBpbnRyb2R1Y2VkIGJldHdlZW4gdmVyc2lv bnMuPGJyPg0KSXQgbWVhbnMgdGhhdCBJRHMgYXJlIGFzc2lnbmVkIHNlcXVlbnRpYWxseSBmcm9t IDEgdXNpbmcgc29tZSBhcmJpdHJhcnkgb3JkZXIuPGJyPg0KSWYgYSAueWFuZyBtb2R1bGUgaGF2 ZSAxNCBZQU5HIGl0ZW1zLCB0aGV5IHdpbGwgYmUgbnVtYmVyZWQgZnJvbSAxIHRvIDE0Ljxicj4N CklmIHRoZSBuZXh0IHZlcnNpb24gYWRkIDUgWUFORyBpdGVtcywgdGhleSB3aWxsIGJlIG51bWJl cmVkIGZyb20gMTUgdG8gMTkuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpNaWNoZWw8YnI+DQo8 YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGNvcmUgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29y ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIERhdmlkIFJlaWQ8YnI+DQpTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAxMToyNCBQTTxicj4NClRvOiA8YSBocmVmPSJt YWlsdG86Y29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5vcmc8L2E+PGJy Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBkcmFmdC1iaWVybWFuLWNvcmUteWlkLTAwLnR4dCBxdWVz dGlvbnM8YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsgV2hhdCBpcyB0aGUgYmVuZWZpdCBvZiBhc3Np Z25pbmcgdmFsdWVzIHVzaW5nIGhhc2hpbmcgb3Zlcjxicj4NCiZndDsmZ3Q7Jmd0OyBzZXF1ZW50 aWFsbHkgYXNzaWduaW5nIHZhbHVlcz88YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUaGVyZSBpcyBvdmVy aGVhZCBpciByZWFkaW5nIGFuZCBwcm9jZXNzaW5nIGEgZ2lhbnQgbGlzdCBvZiBtYXBwaW5ncy48 YnI+DQo8YnI+DQpUaGUgYXNzaWdubWVudCBvbmx5IGhhcHBlbnMgb25lLXRpbWUsIHNvIEkgZG9u J3Qgc2VlIGEgcHJvYmxlbSB3aXRoIGEgbGl0dGxlIG92ZXJoZWFkICh3aGljaCBJIHRoaW5rIHdv dWxkIGJlIG1pbmltYWwgYW55d2F5KS48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBBdXRvbWF0aWMgYXNz aWdubWVudCBpcyByaXNreSBiZWNhdXNlIGJvdGggc2lkZXMgbmVlZCB0byBhZ3JlZSBvbiB0aGU8 YnI+DQomZ3Q7Jmd0OyBvYmplY3QgdG8gbnVtYmVyIG1hcHBpbmcuJm5ic3A7IERldGVjdGluZyB0 aGVzZSBpc3N1ZXMgaXMgdmVyeSBkaWZmaWN1bHQuPGJyPg0KJmd0OyZndDsgVGhlIFlBTkcgSGFz aCBhbGdvcml0aG0gaXMgZGVzaWduZWQgdG8gdXNlIHRoZSBwYXRoIHN0cmluZywgd2hpY2ggaXM8 YnI+DQomZ3Q7Jmd0OyBwZXJtYW5lbnQgYW5kIGNhbm5vdCBjaGFuZ2Ugbm8gbWF0dGVyIGhvdyB0 aGUgWUFORyBpcyByZWZhY3RvcmVkLjxicj4NCiZndDsmZ3Q7IFRoZSBtdXJtdXIgaGFzaCBpcyBh IHN0YWJsZSBhbGdvcml0aG0uPGJyPg0KJmd0OyZndDsgVGhlcmUgaXMgbm90IGEgbG90IHRoYXQg Y2FuIGdvIHdyb25nIGZvciB0aGUgMiBwZWVycyB0byBkaXNhZ3JlZSBvbjxicj4NCiZndDsmZ3Q7 IHRoZSBoYXNoZXMgKGV4Y2VwdCBmb3IgY29sbGlzaW9ucyk8YnI+DQo8YnI+DQpJIHdvdWxkIHRo aW5rIHdlIGNvdWxkIHdyaXRlIGFuIGFsZ29yaXRobSB0aGF0IHdvdWxkIGd1YXJhbnRlZSB0aGUg c2FtZSBudW1iZXIgZXZlcnkgdGltZS4gQWx0aG91Z2ggSSBoYXZlIG5vdCB0aG91Z2h0IHRocm91 Z2ggYWxsIHRoZSBpc3N1ZXMgdGhhdCBjb21lIHVwIHdpdGggcmV2aXNpb25zLCBtYXliZSB0aGlz IGlzIGhhcmRlciB0aGFuIEkgdGhpbmsuPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7IFdoZW4gdGhl cmUgaXMgYSBoYXNoIGNvbGxpc2lvbiwgd291bGQgaXQgYmUgcG9zc2libGUgdG8gcmVoYXNoIHRo ZTxicj4NCiZndDsmZ3Q7Jmd0OyB2YWx1ZSB0byBnZXQgYSB1bmlxdWUgbnVtYmVyIHNvIHRoYXQg d2UgbmV2ZXIgaGF2ZSB0byBtYW51YWxseTxicj4NCiZndDsmZ3Q7Jmd0OyBhc3NpZ24gbnVtYmVy cyBhbmQgdGh1cyBuZXZlciBuZWVkIHRvIHJlZ2lzdGVyIHRoZSBudW1iZXJzIGluIHRoZSByZWdp c3RyeT88YnI+DQo8YnI+DQomZ3Q7Jmd0OyB5ZXMsIHRoaXMgaGFzIGJlZW4gc3VnZ2VzdGVkLjxi cj4NCiZndDsmZ3Q7IFRoZSBwcm9ibGVtIHdpdGggYXV0by1yZWhhc2hpbmcgYmVmb3JlIHdhcyBp bnRlci1tb2R1bGUgY2xhc2hlcy48YnI+DQomZ3Q7Jmd0OyBOb3cgdGhvc2UgYXJlIG5vdCBwb3Nz aWJsZSBzbyBhdXRvbWF0aWMgcmVoYXNoaW5nIGlzIGZlYXNpYmxlLjxicj4NCjxicj4NCiZndDsg W01WXSBJIGRpc2FncmVlLCBzZWUgbXkgcHJldmlvdXMgZW1haWwgd2hpY2ggZXhwbGFpbiB3aHkg YWxsIFlJRHMvU0lEczxicj4NCiZndDsgbmVlZCB0byBiZSByZWdpc3RlcmVkIGV2ZW4gaWYgZ2Vu ZXJhdGVkIHVzaW5nIGEgaGFzaC48YnI+DQo8YnI+DQpBcyBsb25nIGFzIEkgaGF2ZSBlaXRoZXIg YWxsIHJldmlzaW9ucyBvZiBhIG1vZHVsZSBvciB0aGUgWUlEcyBmcm9tIHRoZSBwcmV2aW91cyBy ZXZpc2lvbiwgSSBjYW4gZ2VuZXJhdGUgdGhlIG51bWJlcnMgZm9yIHRoZSBtb2R1bGUuIEkgZG9u J3QgdGhpbmsgSSBuZWVkIGl0IHRvIGJlIGluIGEgY2VudHJhbCByZWdpc3RyeS48YnI+DQo8YnI+ DQomZ3Q7Jmd0OyZndDsgV291bGQgaXQgbWFrZSBzZW5zZSB0byBwdXQgdGhlIG1vZHVsZS1pZCBp bnNpZGUgdGhlIHlhbmcgbW9kdWxlIHdpdGg8YnI+DQomZ3Q7Jmd0OyZndDsgYSB5aWQgZXh0ZW5z aW9uIHNvIHRoYXQgSSB3b3VsZCBub3QgaGF2ZSB0byBnbyBsb29rdXAgdGhhdDxicj4NCiZndDsm Z3Q7Jmd0OyBpbmZvcm1hdGlvbiBmcm9tIGEgcmVnaXN0cnk/PGJyPg0KPGJyPg0KJmd0OyZndDsg SSBzdXBwb3NlIC0tIGJ1dCBob3cgdG8gcHJldmVudCBkdXBsaWNhdGVzIGFuZCBjdXQtYW5kLXBh c3RlIGVycm9ycz88YnI+DQo8YnI+DQpXZSB3b3VsZCBzdGlsbCBuZWVkIGEgcmVnaXN0cnkgdG8g cHJldmVudCBkdXBsaWNhdGVzLiBCdXQgb25seSB0aGUgbW9kdWxlIHdyaXRlciB3b3VsZCBuZWVk IHRvIGFjY2VzcyB0aGUgcmVnaXN0cnkuIFRoZSBtb2R1bGUgdXNlcnMgd291bGQgaGF2ZSB0aGUg aW5mb3JtYXRpb24gaW4gdGhlIHlhbmcgbW9kdWxlIGFuZCB3b3VsZCBub3QgaGF2ZSB0byBsb29r IGF0IHRoZSByZWdpc3RyeS48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gSnVzdCBhZGRpbmcgdGhlIG1v ZHVsZSBJRCBpbiB0aGUgeWFuZyBmaWxlIGlzIG5vdCBzdWZmaWNpZW50IHRvPGJyPg0KJmd0OyB1 c2UgYSAueWFuZyBmaWxlLCBhbGwgWUlEcy9TSURzIG5lZWQgdG8gYmUgYWRkZWQuPGJyPg0KPGJy Pg0KSWYgWUlEcyBhcmUgZ2VuZXJhdGVkIGJ5IGhhc2hpbmcgd2l0aCBhdXRvIHJlaGFzaGluZyBv biBjb2xsaXNpb25zLCB0aGUgWUlEcyB3b3VsZCBub3QgaGF2ZSB0byBiZSBleHBsaWNpdGx5IGxp c3RlZCBpbiB0aGUgbW9kdWxlLiBUaGV5IGNvdWxkIGJlIGF1dG8tZ2VuZXJhdGVkIGFuZCBzdG9y ZWQgaW4gYSBkaWZmZXJlbnQgZmlsZS48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gSGF2aW5nIFlJRHMv U0lEcyBpbiB5YW5nIGZpbGVzIHdpbGwgbWFrZSB0aGVpciBtYWludGVuYW5jZSBtb3JlPGJyPg0K Jmd0OyBjb21wbGV4Ljxicj4NCjxicj4NClllcywgaXQgbWFrZXMgaXQgbW9yZSBjb21wbGV4IGZv ciB0aGUgbW9kdWxlIHdyaXRlcnMuIEJ1dCBpdCBpcyBlYXNpZXIgb24gdGhlIHVzZXJzIG9mIHRo ZSBtb2R1bGUuPGJyPg0KPGJyPg0KJmd0OyBbTVZdIEJUVywgYSBweWFuZyBwbHVnaW4gYWxyZWFk eSBleGlzdCB0byBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlIGFuZDxicj4NCiZndDsgdXBkYXRlIGEg LnNpZCBmaWxlIGZyb20gYSAueWFuZyBmaWxlIFtNVl0gU2VlPGJyPg0KJmd0OyBbMl08YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy95YW5nLWNib3IvYmxvYi9tYXN0ZXIvc2lkLnB5 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cveWFuZy1jYm9yL2Js b2IvbWFzdGVyL3NpZC5weTwvYT48YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsgV291bGQgaXQgYmUg cG9zc2libGUgdG8gYXNzaWduIHRoZSBtb2R1bGUtaWQgYmFzZWQgb24gaW5mb3JtYXRpb24gaW48 YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIG1vZHVsZSwgZm9yIGV4YW1wbGUgYSBoYXNoIG9mIHRoZSBu YW1lc3BhY2UgYW5kIG1heWJlIHRoZSByZXZpc2lvbiBkYXRlLjxicj4NCiZndDsmZ3Q7Jmd0OyBU aGF0IHdheSwgYSBtb2R1bGUtaWQgd291bGQgbm90IGhhdmUgdG8gYmUgYXNzaWduZWQgYW5kIG1h aW50YWluZWQ8YnI+DQomZ3Q7Jmd0OyZndDsgaW4gYSByZWdpc3RyeS48YnI+DQo8YnI+DQomZ3Q7 Jmd0OyBJIHRoaW5rIHByaXZhdGUgbW9kdWxlLWlkIHdvdWxkIGJlIGJldHRlciwgdXNpbmcgYSBy YW5nZSByZXNlcnZlZCBmb3I8YnI+DQomZ3Q7Jmd0OyB0ZW1wb3JhcnkgYXNzaWdubWVudHMuPGJy Pg0KPGJyPg0KSSB0aGluayB5b3UgYXJlIHJpZ2h0LiBJIHdhcyBqdXN0IGhvcGluZyB3ZSBjb3Vs ZCBhdm9pZCByZXF1aXJpbmcgbW9kdWxlIHdyaXRlcnMgdG8gcmVnaXN0ZXIgYSBtb2R1bGUtaWQg YnkgZmluZGluZyBhIHdheSB0byBhdXRvIGFzc2lnbiBpdC48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBI b3cgZG8geW91IHJlc29sdmUgaGFzaCBjb2xsaXNpb25zIGZvciBtb2R1bGUtaWQ/PGJyPg0KPGJy Pg0KSSBkb24ndCBoYXZlIGEgZ29vZCBzb2x1dGlvbi4gSSB3YXMgaG9waW5nIHRoZSBwcm9iYWJp bGl0eSBvZiBjb2xsaXNpb24gd291bGQgYmUgbG93IGVub3VnaCB0byBiZSBhY2NlcHRhYmxlLCBv ciB3ZSBjb3VsZCBhZGQgdGhlIGZpcnN0IHJldmlzaW9uIGluIHRoZSBudW1iZXIgdG8gZnVydGhl ciByZWR1Y2UgY29sbGlzaW9ucy4gQnV0IEkgZG9uJ3QgaGF2ZSBhIHdheSB0byByZXNvbHZlIGNv bGxpc2lvbnMuPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7IFdobyB3aWxsIGFzc2lnbiB0aGUgbG9j YWwtaWQgbnVtYmVycz8gSXMgdGhhdCBkb25lIGJ5IHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsm Z3Q7IGdyb3VwIHRoYXQgZGVmaW5lcyB0aGUgWUFORyBtb2R1bGU/PGJyPg0KPGJyPg0KJmd0OyZn dDsgSSB3b3VsZCBleHBlY3QgSUVURiBtb2R1bGVzIHRvIHVzZSBoYXNoZXMgYnkgZGVmYXVsdCBi dXQgZm9yIHNvbWU8YnI+DQomZ3Q7Jmd0OyBtb2R1bGVzIHRoYXQgc2VlbSB1c2VmdWwgdG8gY29u c3RyYWluZWQgZGV2aWNlcywgdGhlbiBtYW51YWw8YnI+DQomZ3Q7Jmd0OyBudW1iZXJpbmcgY291 bGQgYmUgZG9uZSBpbnN0ZWFkIGJ5IHRoZSBXRy48YnI+DQo8YnI+DQomZ3Q7IFtNVl0gVG8gb2J0 YWluIGEgc21hbGxlciBlbmNvZGluZywgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB0aGU8YnI+ DQomZ3Q7IHNlcXVlbnRpYWwgbnVtYmVyaW5nIHdpbGwgYmUgdXNlZC48YnI+DQo8YnI+DQomZ3Q7 IFtNVl0gV2l0aCBzZXF1ZW50aWFsIG51bWJlcmluZywgYWxsIGN1cnJlbnQgWUFORyBtb2R1bGVz IGRlZmluZWQgaW48YnI+DQomZ3Q7IFJGQ3MgY2FuIGJlIGFzc2lnbmVkIHdpdGhpbiB0aGUgZmly c3QgNjUwMCBTSURzIHdoaWNoIHdpbGwgYmUgZW5jb2RlZDxicj4NCiZndDsgYXMgMyBieXRlcyBm b3IgdGhlIGZpcnN0IHJlZmVyZW5jZSBhbmQgdHlwaWNhbGx5IGFzIDEgYnl0ZXMgZm9yIHRoZTxi cj4NCiZndDsgZm9sbG93aW5nIG9uZXMgdXNpbmcgZGVsdGEgZW5jb2RpbmcuPGJyPg0KPGJyPg0K Jmd0OyBbTVZdIFdpdGggaGFzaGVzLCBvbmx5IG9uZSBZQU5HIG1vZHVsZSBjYW4gYmUgYXNzaWdu ZWQgd2l0aGluIHRoYXQ8YnI+DQomZ3Q7IHJhbmdlLjxicj4NCjxicj4NCklzIHRoZSBzZXF1ZW50 aWFsIG51bWJlcmluZyBhdXRvLWFzc2lnbmVkIG9yIG1hbnVhbGx5IGFzc2lnbmVkPzxicj4NCjxi cj4NCi1EYXZpZCBSZWlkPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8 L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjb3JlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR06MB23082C2A4D43FB6519D13669FEED0BN6PR06MB2308namp_-- From nobody Thu Aug 25 20:53:56 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3971E12D185 for ; Thu, 25 Aug 2016 20:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_N26DSndQVj for ; Thu, 25 Aug 2016 20:53:52 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 352A312D179 for ; Thu, 25 Aug 2016 20:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=llLQsHb3lQGWfpCxbhPtlhNC5eS1I5GrtAcT/ens3qA=; b=FrNOwIRNfCp/9bgkwpRyujviNV 7bp4IPd/qDR0AzFpAKwSA70MjAfWL0+fawkRNQKkvfrOyqQk1mvEJ4DzkUsY52KYEcakNV+4wVq1b 7wZFhtbk3BvfXJbZS3eFARMPThHQRsEWFTYH8SBOaXwb4sAAmrMrbfG1KuHCxZkM+2UrTGw7758W6 /6+85PGymgv85aH3ID1vBx96muaU7k/Lcj1TRpC+VfeUiSimX6ssroT6rXV+0TSsoZ3TkmdysO+67 RBY7x310C3yfGtDRkwcmsZN8Jk93WFSSZrkme6hsdJV9arP4nh5jEpyAbOAY9iqVWHZutTDvJwlKq fDrwIidQ==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:51403 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bd8DE-000TOl-Vw for core@ietf.org; Fri, 26 Aug 2016 13:53:49 +1000 To: core@ietf.org References: From: Christian Groves Message-ID: Date: Fri, 26 Aug 2016 13:53:43 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-kos?= =?utf-8?q?ter-core-coap-pubsub?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 03:53:54 -0000 Hello, I think pub sub functionality is useful for CoAP. Whilst the draft does need some work its appropriate to start a WG item. Regards, Christian On 16/08/2016 1:10 AM, Jaime Jiménez wrote: > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been > requested for draft-koster-core-coap-pubsub. At the IETF meeting the > room consensus was strongly supporting adoption (~10 people). Please > reply to the list with your comments, including although not limited > to whether or not you support adoption. Non-authors are > especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on > *August 26, 2016*. > > Thanks, > Jaime and Carsten > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Aug 25 20:54:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0251F12D1A1 for ; Thu, 25 Aug 2016 20:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSJW1cdgCiPE for ; Thu, 25 Aug 2016 20:54:43 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 DA2D012D19E for ; Thu, 25 Aug 2016 20:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kYRQYxCyhKwajGGa158A+dg/0pdXTj6ld4+ymMRdZBQ=; b=ImATvDo/T59U8OFFuc6aEdTw+z Roy/EnUdV2mKS+TWZnoZWUfQxh6sqpAkJevU6gmoNOQuJJpHoPIEDCg2YIRojsJvjXgc0WLGArJxX vVBw+8W0v1BdMk1ZHRTHy0FLJ+bcgUApUVwZa6rLGa+zBg5rStQT51gU0Nrv2IqmY+wS1L6qKYZkL 9bTgTf4gcMfCFjBQPN8744jIRsusUyxvVuc/AiaGLGRqyTYo5h+2M3s2wb5qYPwUokbIi2uhQL2Yk zlSLz2PFXt7ZcWXpWr8zHSDRHmZhKBOEkpr7s5jDhu1++lbYXxb16lHuVqHjx7xPWIl0tTXdc9LmE YH6p8zqQ==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:51409 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bd8E5-000TS3-7t for core@ietf.org; Fri, 26 Aug 2016 13:54:41 +1000 To: core@ietf.org References: <982B626E107E334DBE601D979F31785C5D053452@blreml501-mbx> From: Christian Groves Message-ID: <4d83d7df-456f-ac61-dc48-5923b27b38d7@nteczone.com> Date: Fri, 26 Aug 2016 13:54:35 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-bor?= =?utf-8?q?mann-core-cocoa?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 03:54:44 -0000 +1 the draft is useful. Christian On 16/08/2016 2:17 PM, Rahul Jadhav wrote: > > I support adoption of this work. The work is of significance in cases > where the RTT is uneven amongst the nodes in LLNs and arriving at an > optimal RTO will significantly save retransmission overhead. Will keep > reviewing and testing the draft in the future. > > Thanks for this work. > > > > > > > From: core [mailto:core-bounces@ietf.org > ] On Behalf Of Jaime Jiménez > > Sent: 15 August 2016 PM 08:39 > > To: core@ietf.org WG > > Cc: draft-bormann-core-cocoa@ietf.org > > > Subject: [core] 🔔 Working Group Adoption of draft-bormann-core-cocoa > > > > > > > > Dear CoRE-WG, > > > > As we discussed at last IETF96, working group adoption has been > requested for draft-bormann-core-cocoa. At the IETF meeting the > room consensus was for adoption. Please reply to the list with your > comments, including although not limited to whether or not you support > adoption. Non-authors are especially encouraged to comment. > > > > Since there are several concurrent WGA calls, we will end the call > on August 26, 2016. > > > > Thanks, > > Jaime and Carsten > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Aug 25 21:21:18 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EBF12D097 for ; Thu, 25 Aug 2016 21:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTHnrKVLJUbM for ; Thu, 25 Aug 2016 21:21:16 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 4466C126579 for ; Thu, 25 Aug 2016 21:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VGYNuuwYyd69Gi0IBJAH8KJSn54FoKmHw57Jjw0giE8=; b=AW9a4KusoiKhHZqLypv5gvMepj hiB96JSsooEvyKj8UQfEhVzThDbjeZ854KzSxm6/nLhMN4mlw6KISO8Y48FfIB/Qt/PIJ5zbWMJU0 +atK92sYieVuLnxBI6yKRB6CFO/ljKSR3434e7YQhk7Xp0RsQGpLWzuKfpsSvEWTC6hkWj21WNRxO Ev8xcEsPxDPW7cAS/gw/Oq8bmC1dRwGnRQpIQzWzrimxsVNUV3CX/usbhkQm6QR5vZRvHyijvizkY gQwuDYVkfHOJUc30tQzLpwQGexNVQ0Y6fN7TukAtcwX7LTR/qklmFtlDGncTEV3FCbcHsOfUN4K8b XSaH8xNw==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:51581 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bd8dm-000Vor-Hr for core@ietf.org; Fri, 26 Aug 2016 14:21:14 +1000 To: core@ietf.org References: <57AE4B71.5090709@tzi.org> <0A49F91D-DC01-48FF-AF01-7D788FD4D803@gmail.com> From: Christian Groves Message-ID: <9de7b080-7987-dad5-4948-78d4c0f8db8e@nteczone.com> Date: Fri, 26 Aug 2016 14:21:09 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0A49F91D-DC01-48FF-AF01-7D788FD4D803@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] rt and if registry question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 04:21:17 -0000 Hello Michael, Its nice to have one central repository for things but I suspect that IANA wouldn't be happy to manage such a large name space. It could be worthwhile to allow the registration of name spaces in the IANA registry (e.g. OIC.* or OCF.*). The registration would include a reference to the doucment(s) defining the RTs. The organisation registering the namespace is then responsible for the management of the "*" part. At least then somebody coming across a particular rt would know where to look for it rather than bodies not registering with IANA because the effort to register individual rts is too large. Regards, Christian On 17/08/2016 10:34 PM, Michael Koster wrote: > Hi, > > Assuming we must register rt and if values used in OCF, is the CoRE > Paramaters Registry an appropriate venue for registration? > > http://www.iana.org/assignments/core-parameters/core-parameters.xhtml > > NB in OCF, rt is used for application semantics and there may be > hundreds to thousands of rt terms registered with more being added > over time. > > Will the CoRE Parameters Registry be appropriate for registration of > such a large volume of terms, or is there another preferred approach? > > Best regards, > > Michael > > >> On Aug 14, 2016, at 3:02 PM, Dave Thaler > > wrote: >> >> Thanks Carsten for the response! This answers one of the two >> questions I asked. I'm still waiting for an >> answer on the other question (in short, it was: can you use values >> other than URIs without >> registering, or only URIs?) The attached email is the one I'm still >> waiting for an answer on. >> >> I believe I know the answer but since there's apparently confusion, >> I'd like confirmation on the list either way. >> >> Dave >> >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: Friday, August 12, 2016 3:19 PM >>> To: Dave Thaler > >>> Cc: core@ietf.org >>> Subject: Re: [core] rt and if registry question >>> >>> Hi Dave, >>> >>> I'm not the foremost expert on this but I'll give it a try. >>> >>> Dave Thaler wrote: >>>> Can a prefix be registered? >>> >>> No. There is nothing in section 7.4 of RFC 6690 that would create >>> such a >>> registry. (The concept of prefix is used in 4.1 for certain kinds >>> of searches, >>> but it is really used in its straight computer science meaning of >>> "the beginning >>> part".) >>> >>> The text about »values starting with the characters "core"« is about >>> swapping out the registration policy, there is no other technical >>> change. >>> >>> Note that the text following (that instructs the designated expert) >>> is about >>> avoiding the typical vagaries of choosing between link.format and >>> linkformat >>> and link-format, so it is a matter of style consistency that is >>> meant to provide >>> more predictability (and this memorability) of the values being >>> registered. It >>> uses "core." as an example, not in a normative way. ("core." >>> doesn't occur in >>> the entire RFC outside examples.) >>> >>> Actually, "coresident-sensors" or "coresident.sensors" have the same >>> special >>> IETF Review policy as "core.foo" -- the policy swap is in effect for >>> »values >>> starting with the characters "core"«. >>> >>> I believe the current text of RFC 6690 is sufficient to say all this >>> and no >>> retroactive analysis of proceedings or mailing lists is required to >>> come to this >>> conclusion. >>> >>> Grüße, Carsten >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Aug 25 21:47:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868C212D0A5 for ; Thu, 25 Aug 2016 21:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Hxmxf3hTCr for ; Thu, 25 Aug 2016 21:47:13 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 D3E9A12D09E for ; Thu, 25 Aug 2016 21:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L0FoKiSI2j3FdavSMGRY6fhhZJG2bDj0Xat9N70yiO8=; b=aGS4SGSCL1H+pPlS70BA/1jzJZ j2HzANLK17iDvzEJ+kjr1PIeSW524buuHv5geywhyq5v0dYUFqMcXzZKkNa416ENluHBBjKQ+MAir PoMRcFhfi3LC+S3rdzIM1YVUja+d+AThjB58yx1l3ZMKVGDgS+7roaz/eK6Aw8GaIo5wPJ5u78Id2 e6UqD6Ri8wMJVW0hOGb2J8/HdxBD6WM4a2idsdQFsXWbzQAMeCvzNhvFNeJxZ9OPNv5vitf6Y0dPU 2atN8j57hbjPO6KbhLYZ9gDD9wEha6JCaz/97RkqrEw9nolBaJzXXSe1aKompEu7L4E7b5j/XQUHK maWCF+Nw==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:51693 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bd92r-000Y0z-Pe for core@ietf.org; Fri, 26 Aug 2016 14:47:09 +1000 To: core@ietf.org References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <7d25c211-197c-775b-ccd3-7675d00936e8@nteczone.com> Date: Fri, 26 Aug 2016 14:47:04 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 04:47:14 -0000 Hello Brian, Thanks for the updates. The TCP port/ALPN changes are OK for me. Regards, Christian On 25/08/2016 7:22 AM, Brian Raymor wrote: > -04 addresses all the issues discussed at IETF 96 - with the exception of https://github.com/core-wg/coap-tcp-tls/issues/5. The authors are discussing the scope for a section related to RFC7641 (Observing resources ...). > > In addition, I opened a new issue related to mandatory exchange of CSM - https://github.com/core-wg/coap-tcp-tls/issues/58 - where feedback would be helpful. > > Both of these issues are targeted for -05. > > ...Brian > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, August 24, 2016 2:09 PM > To: i-d-announce@ietf.org > Cc: core@ietf.org > Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments of the IETF. > > Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets > Authors : Carsten Bormann > Simon Lemay > Hannes Tschofenig > Klaus Hartke > Bilhanan Silverajan > Brian Raymor > Filename : draft-ietf-core-coap-tcp-tls-04.txt > Pages : 42 > Date : 2016-08-24 > > Abstract: > The Constrained Application Protocol (CoAP), although inspired by > HTTP, was designed to use UDP instead of TCP. The message layer of > the CoAP over UDP protocol includes support for reliable delivery, > simple congestion control, and flow control. > > Some environments benefit from the availability of CoAP carried over > reliable transports such as TCP or TLS. This document outlines the > changes required to use CoAP over TCP, TLS, and WebSockets > transports. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-04 > > > 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/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Thu Aug 25 22:07:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127F812B024 for ; Thu, 25 Aug 2016 22:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb9I2tx1VAKy for ; Thu, 25 Aug 2016 22:07:40 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 DBF16128874 for ; Thu, 25 Aug 2016 22:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ihXdtJoGbNHWjuG3tIdchvISC/fp+BEbGkcExTVfBY0=; b=CG1g2p4jMs6XnQCJVeVpd5Tdof YP7W1d7sxkJ8Dq1qZbxZfTnogVqUlVz3RTlwtEbXuB7uxZitgmjYBH4I9wxLc5dJBCXHNuNPZkW0I XJsw+4RUVMPySwsd/Q3szFBPyt6D4K+bXPddv2FzK1YS9zJcfQXU9NC//4Nv5Qyv+DXKNSLGj6tXB kBTwxddsU1VVal2L4Gz2EQtAOfePtI64LKEcs+z6ZSeZH1wtY5zftRyBXDkhCpV8USAncsROcPstG BwyPbfzm/IQ5KODE8grtX5/SrHJ6LvaiFcN16DFmPJ1W8gPLXQCclG5rsEHafmI++V3oU38rR8+3r wMZf88Yg==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:51747 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bd9Mf-000Ztt-Uj for core@ietf.org; Fri, 26 Aug 2016 15:07:38 +1000 To: core@ietf.org References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> From: Christian Groves Message-ID: <6535adf5-7c76-ff1a-e5a3-dcbff49a35ef@nteczone.com> Date: Fri, 26 Aug 2016 15:07:32 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 05:07:41 -0000 +1 Christian On 25/08/2016 11:40 PM, Sandeep Kumar wrote: > +1 > I support adoption of the draft as it is quite useful to have this > additional security mechanism in the toolkit that is useful in many > settings. > > Regards > Sandeep > > Sandeep Kumar > > Senior Scientist, > > Philips Lighting Research,The Netherlands > > > On Mon, Aug 15, 2016 at 5:08 PM, Jaime Jiménez > > wrote: > > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been > requested for draft-selander-ace-object-security. At the IETF > meeting the room consensus was strongly supporting adoption (10-12 > people). Please reply to the list with your comments, including > although not limited to whether or not you support adoption. > Non-authors are especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call > on *August 26, 2016*. > > Thanks, > Jaime and Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Aug 25 23:12:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7412D17E for ; Thu, 25 Aug 2016 23:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPa1pLjT7jDI for ; Thu, 25 Aug 2016 23:12:17 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 669F312D127 for ; Thu, 25 Aug 2016 23:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RFTUIknjPjKKIef1cF2/iJgCiNJXOZTBPnFI/bRILp8=; b=JK7qbt0bXjV2UNX1tSgbyhf8qr pzv5IIlYcyENf71g084I17yfPM2158aBkxZ71OaKlC0n8Iy3wcmhfEKmesvGOKd6wl2i4sOnsUH5O tgUYmcGL1T6BOwBMLnIQxTR5PhecGKw5z8Ic3d/Xsv1W924Rszyn5hQXNZzZojUSPFhGoz8AtKXaM XGzoiOyI8jlz2wrfvs4ns5LVUV0JxjeBuWpmrbAHP89e7agUu8xXZQfn1MNraTK8xJWKhPyGhoc95 pRn+afnCbO4VDjLetp+9/+iHFDA7LOpDWgQiYCECjBLqZGM+rQdDXcM1OeIFpY+sTIrAYeuOfmisN H2TbAzXg==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:52411 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bdANC-000feP-LP for core@ietf.org; Fri, 26 Aug 2016 16:12:14 +1000 To: core@ietf.org References: From: Christian Groves Message-ID: <16edc592-d071-4c45-da84-b570fdd500a7@nteczone.com> Date: Fri, 26 Aug 2016 16:12:09 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] CoAP Content format encoding for structures syntax and format parameters X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 06:12:18 -0000 Hello Michael, The current senml draft requests 6 identifiers for the various senml+(encoding) options. Looking at https://www.iana.org/assignments/media-types/media-types.xhtml registering each structured syntax suffix seems to be the practise. With regards to the parameters wouldn't the parameters first have to be defined by the content-format registration? As senml+json doesn't have parameters "version=2" would not be possible. If you wanted to define parameters I suppose new link attribute would be needed? Regards, Christian On 20/08/2016 8:12 AM, Michael Koster wrote: > Hi, > > What is the curent thought wrt the CoAP content-format encoding for structured syntax media identifiers, like link-format+json, senml+cbor? > > Does each combination need to have its own IANA registered code, or is there a scheme for structured identifier codes in CoAP? > > Likewise, what is the preferred way to transmit media type parameters, for example with "application/senml+json; version=2" how do we transmit the version=2 part? > > Best regards, > > Michael > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Fri Aug 26 00:09:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9078312B017 for ; Fri, 26 Aug 2016 00:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXDp5HxldnCE for ; Fri, 26 Aug 2016 00:09:39 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 910D8128E19 for ; Fri, 26 Aug 2016 00:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5q5qRURgst1BTNN2S/VmSbqmuq0O1FAcNTissEuz+fE=; b=KqiEkWYIlMf/t8q33CrpZdPIqe jfJGaxbFhR2JHWqb6Iu8qh6onYGtg1znDEXQqC4s8cXVs5Jj8BWKUeNqfWJ33/utdUsYeVdzW+zyv ODr7jjmP9DgfEUS5S78fOLDJSoZFZrpp4KA6uxi1SpgmyMNzkYxem1u+xZeq9WMrqT8qvpKRKdscy 0BHF0oRisp3hglO0uLdjmVbcjfiCY5vaMBm2jM9A43nIjXP6s8mp1GCIhnajW7+KQZagOi6HWwRDg DDcw/4FuS6vS/XSyUCfNWjnr26cSFFHsuQn4kPFjIzbRxpIxXEwaf3P82u20EtqC2MbT+cBOvYB5n oTojo+Qg==; Received: from ppp118-209-39-238.lns20.mel4.internode.on.net ([118.209.39.238]:52989 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bdBGj-000jw7-GY for core@ietf.org; Fri, 26 Aug 2016 17:09:37 +1000 To: core@ietf.org References: From: Christian Groves Message-ID: Date: Fri, 26 Aug 2016 17:09:31 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] My Notes about draft-ietf-core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 07:09:45 -0000 Hello Hannes, Please see below. Regards, Christian On 3/08/2016 5:49 PM, Hannes Tschofenig wrote: > Hi all, > > I read through draft-ietf-core-interfaces-05 and I have a few questions. > > I understand the functionality and the desire to standardize interfaces > since the CoRE Link Format only introduces the concepts but leaves the > details (i.e., the value for the if parameter) unspecified. > > 1) Who came up with these terms? [CNG] I'm not sure, various related technologies such as Java and HTML utilise some of the concepts e.g. collection. I'll let one of the original authors answer this. I agree the definitions could use some more "meat" on them. Something that i'll work on. > > Here, for example, is the definition of the 'collection': > > "A Collection is a resource which represents one or more related > resources. Within this document, a collection refers to a collection > with characteristics defined in this document." > > My understanding of the collection function is that of a view in an SQL > database. Is this correct? > > The definition of function set, interface, and other terms also appears > to be somewhat unusual. Isn't there something we could re-use from the > Web context? > > 2) Is this document only applicable to CoAP or also to HTTP? In general, > I get worried when functionality is only defined for use with CoAP and > is not usable with HTTP, and HTTP/2. [CNG] Also to HTTP, as Core-Link format may be used by HTTP. > > 3) Is it possible to include some practical examples? The document > currently includes a number of examples but those are abstract. [CNG] Did you have something in mind? > > 4) I am curious why SenML was selected. I have been trying to understand > the relationship with LWM2M and LWM2M, for example, does not use SenML. > SenML feels like a somewhat heavy format since it includes meta-data > that most applications don't need. [CNG] You mention LWM2M and LWM2M I'm not sure what the 2nd instance is? With regards to LWM2M the specification uses the "interface" concept in a similar manner to what is defined in the draft. I.e. what operations may be performed on resources via the interface is described. The LWM2M specification does reference the core interfaces draft but that's only in the context of a note i.e. "/Note: How to indicate the Attributes in the message payload is specified in [CoRE_Interface]./" I think that needs to be updated to make reference to the dynamic linking draft we have split out. > > 5) For most functionality no use cases are presented. The exception is > the collection where a use case is presented in Section 4.2. I am, > however, not sure that the 'Gradual Reveal' functionality is really > useful as such. [CNG] The draft was accepted back in mid 2013 (before I started following the CORE WG) I would have assumed there were some use cases presented in order for the WG to adopt the work. Perhaps one the original authors has them? > > 6) Who is using the functionality described in this document? The > editor's note talks about alignment with OCF. Since I am not familiar > with the functionality standardized by the OCF I cannot say how much > different this document is from the OCF-defined features. [CNG] The note was simply a place holder for further work that needs to be done. The relationship with OCF is something that needs further description. This is something hopefully Michael will be able to help with. > > 7) The structure of the document is not well-balance. For example, > Section 3 consists of one sentence. The content of Section 5.8 is > meaningless and Section 6.3 "Versioning" is difficult to understand. The > security consideration section as well as the IANA consideration section > is at best incomplete. Appendix A contains no textual description of > what is shown in the tables. [CNG] Yes it needs work. I explained at the meeting this document was a simple split of the existing text. I intend to provide some enhancements for the next version. > 7) Who is the editor of this document? [CNG] I'm now the editor. So thanks for the comments there something to consider for the next revision. > > Ciao > Hannes > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Aug 26 01:26:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959512D185 for ; Fri, 26 Aug 2016 01:26:52 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cSEAG35-R7A for ; Fri, 26 Aug 2016 01:26:50 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FC612D0FA for ; Fri, 26 Aug 2016 01:26:49 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id l89so51616414lfi.1 for ; Fri, 26 Aug 2016 01:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to; bh=laCfM4pqqQlXRsRWedwyN6KgmoMS1/3cTCNb6zJZxBk=; b=iYtOmdeIsGZnla1oJiELgNt9mv22dmt4e4rtOlbkKO2FxwU2GfWrQb7pw0ZEqaK8ry mfqVXH7Yf6yveDstdHjLeQSPCzwbaA5bmqQ9gcnRpCJvHyw7F8Pz0XIEhRsOAOS6n57U vHYtcWmijlKgumul/p8ttwOr8KvRCn+wH327+nnWMFmYFYuVK40QGZ5Th7frcUBBmmsu /fzOvzW+sheOHJghSmFG5N4jTrIkAAR2lEwqG+0WgmvTqLSMyK6b9ie5Q5BV5HHYB8ul GZjsr/PfZPmmIt60RrEwsmBi9UX49S41WodfCr6W8U2vgdrhOw04fV0R+gvemfuZyU2j UeUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to; bh=laCfM4pqqQlXRsRWedwyN6KgmoMS1/3cTCNb6zJZxBk=; b=XbLRZQamF4tZ/xU1q2T1d26zGm6EzG+JCgDwnBAdPjbZIpgX+XqdjFuXt8XXYNC+k/ l1fZHMBjPk1lYEVskKbTbgHCAjuB9Fhb0aWxqYvoEfAL4Bqby7BDwYyVw7VUN6UcjkmL AApSvJ62hKf40pnIcXlTweVKg+/A3djo03mPorEj5C/44GVGGqUd2ID1ShzShLYTmKGL nrwjg1jkPnumN4hK0oZyTK7ZmKZ2NurmTGqnLmyxM5xt7L7g7ArRnlll24qM0xpfJ20S l0NVIVUPTuTzTEZmhFq7/11FTLGrlBOeDf/NA5giUMHRfm3fLtIeCJK9xCUrWCzrf/0j vvIA== X-Gm-Message-State: AE9vXwPBvrIgPvGsadvMNVwQ7JFvEtdxo5AbNQ2m1c8dijHEAft68r2yLHz4DzyMGQ2gAerU X-Received: by 10.25.228.205 with SMTP id x74mr586835lfi.10.1472200007557; Fri, 26 Aug 2016 01:26:47 -0700 (PDT) Received: from ?IPv6:2001:6b0:3a:1:39be:7c:8fd9:aa86? ([2001:6b0:3a:1:39be:7c:8fd9:aa86]) by smtp.googlemail.com with ESMTPSA id g69sm3655681lji.44.2016.08.26.01.26.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Aug 2016 01:26:46 -0700 (PDT) Message-ID: <57BFFD3F.6070608@sics.se> Date: Fri, 26 Aug 2016 10:26:39 +0200 From: Marco Tiloca User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: core@ietf.org References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> <6535adf5-7c76-ff1a-e5a3-dcbff49a35ef@nteczone.com> In-Reply-To: <6535adf5-7c76-ff1a-e5a3-dcbff49a35ef@nteczone.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S9qQ3pcb7HklgsLFwjvAmw8O6DCPdx3IS" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 08:26:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S9qQ3pcb7HklgsLFwjvAmw8O6DCPdx3IS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 I also support the adoption of this draft. It is very useful for many scenarios and settings to have such an application-layer security mechanism available, especially in the presence of proxy units. Best regards, /Marco On 2016-08-26 07:07, Christian Groves wrote: > +1 > > Christian > > > On 25/08/2016 11:40 PM, Sandeep Kumar wrote: >> +1 >> I support adoption of the draft as it is quite useful to have this >> additional security mechanism in the toolkit that is useful in many >> settings. >> >> Regards >> Sandeep >> >> Sandeep Kumar >> >> Senior Scientist, >> >> Philips Lighting Research,The Netherlands >> >> >> On Mon, Aug 15, 2016 at 5:08 PM, Jaime Jim=C3=A9nez >> > wrote= : >> >> Dear CoRE-WG, >> >> As we discussed at last IETF96, working group adoption has been >> requested for draft-selander-ace-object-security. At the IETF >> meeting the room consensus was strongly supporting adoption (10-12= >> people). Please reply to the list with your comments, including >> although not limited to whether or not you support adoption. >> Non-authors are especially encouraged to comment. >> >> Since there are several concurrent WGA calls, we will end the call= >> on *August 26, 2016*. >> >> Thanks, >> Jaime and Carsten >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Marco Tiloca, PhD SICS Swedish ICT AB=20 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ --S9qQ3pcb7HklgsLFwjvAmw8O6DCPdx3IS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXv/1FAAoJEO4mZLQOWNpDuzoH/RQ9Lk7EQmdjBSoHPraOsRu5 zKwkzIE6B3LxNtWOSOK1sjUTl5o9K7/YzgJ3PUHvimkEEAOkSb9ZejaTOT16dQX5 0req7kIvNcSAcWoZ5JNaHpNPJGTEx6NBJYN8pTdZnOoJ1FRDOm15WQylC2nJaKVP 9pNO6OIUCqMemJ/YuqZygjagX/zyX4lxjZ7/kHigGMAk2EPAnht8O8yvTGPph8cX b3yz08/TYKMm8+sB2B5pYr7wHle/flBmhXNz6kLRYf+gm5dy3a+72QmZt2tTqXXV rHfSySENp7HAAMyCrRDjw6JRkwIZXGQ1G/JSD82lXLoiWqGbTTop7W6AxZ1KVBc= =WSQQ -----END PGP SIGNATURE----- --S9qQ3pcb7HklgsLFwjvAmw8O6DCPdx3IS-- From nobody Fri Aug 26 01:29:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C32D12D1C7 for ; Fri, 26 Aug 2016 01:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAE9lyqHs3rg for ; Fri, 26 Aug 2016 01:29:24 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861E612D185 for ; Fri, 26 Aug 2016 01:29:24 -0700 (PDT) Received: from mfilter46-d.gandi.net (mfilter46-d.gandi.net [217.70.178.177]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 3A3CF1720D3; Fri, 26 Aug 2016 10:29:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter46-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter46-d.gandi.net (mfilter46-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id QYHPq-zXq-Vt; Fri, 26 Aug 2016 10:29:21 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 118531720BE; Fri, 26 Aug 2016 10:29:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: <57BFFD3F.6070608@sics.se> Date: Fri, 26 Aug 2016 10:29:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> <6535adf5-7c76-ff1a-e5a3-dcbff49a35ef@nteczone.com> <57BFFD3F.6070608@sics.se> To: Marco Tiloca X-Mailer: Apple Mail (2.3124) Archived-At: Cc: core@ietf.org Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 08:29:26 -0000 +1 In support of the adoption of the draft. Alexander > Le 26 ao=C3=BBt 2016 =C3=A0 10:26, Marco Tiloca a = =C3=A9crit : >=20 > +1 >=20 > I also support the adoption of this draft. >=20 > It is very useful for many scenarios and settings to have such an > application-layer security mechanism available, especially in the > presence of proxy units. >=20 > Best regards, > /Marco >=20 > On 2016-08-26 07:07, Christian Groves wrote: >> +1 >>=20 >> Christian >>=20 >>=20 >> On 25/08/2016 11:40 PM, Sandeep Kumar wrote: >>> +1 >>> I support adoption of the draft as it is quite useful to have this >>> additional security mechanism in the toolkit that is useful in many >>> settings. >>>=20 >>> Regards >>> Sandeep >>>=20 >>> Sandeep Kumar >>>=20 >>> Senior Scientist, >>>=20 >>> Philips Lighting Research,The Netherlands >>>=20 >>>=20 >>> On Mon, Aug 15, 2016 at 5:08 PM, Jaime Jim=C3=A9nez >>> > = wrote: >>>=20 >>> Dear CoRE-WG, >>>=20 >>> As we discussed at last IETF96, working group adoption has been >>> requested for draft-selander-ace-object-security. At the IETF >>> meeting the room consensus was strongly supporting adoption = (10-12 >>> people). Please reply to the list with your comments, including >>> although not limited to whether or not you support adoption. >>> Non-authors are especially encouraged to comment. >>>=20 >>> Since there are several concurrent WGA calls, we will end the = call >>> on *August 26, 2016*. >>>=20 >>> Thanks, >>> Jaime and Carsten >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Marco Tiloca, PhD > SICS Swedish ICT AB=20 > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.sics.se > https://www.sics.se/~marco/ >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Aug 26 02:51:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C4F12D552; Fri, 26 Aug 2016 02:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-bretagne.eu 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 FmPg00l3tEP3; Fri, 26 Aug 2016 02:51:30 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4194812D151; Fri, 26 Aug 2016 02:51:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 611E3232071; Fri, 26 Aug 2016 11:51:29 +0200 (CEST) Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uDvZG3tRWbiZ; Fri, 26 Aug 2016 11:51:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 8ED4D232072; Fri, 26 Aug 2016 11:51:28 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy210.enst-bretagne.fr 8ED4D232072 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-bretagne.eu; s=CFDC2CFA-4654-11E5-AACD-7BCC68B6580D; t=1472205088; bh=EY48aPaf/HkAzg/S4x/sEPhw5MTNeSLEbcTfTqHe6uA=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=cpmGIRlK04qVoy1jCj55CtN868FG+8pV79kuOqpIirLOQLdLbD09CvtV6JIVZA6Q0 2NzJLT2aaKtHDRfxBz490hBV27MHsBvgy+I2WMCUXR0FN/CEoHs/cQ/4WbIomlLMsH th69PVCTOZwmckvTv6FBau4osvihJn+ErrkcMikg= X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kIraSM9rcyFb; Fri, 26 Aug 2016 11:51:28 +0200 (CEST) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 46FC2232069; Fri, 26 Aug 2016 11:51:28 +0200 (CEST) Received: by mail-lf0-f51.google.com with SMTP id f93so53020081lfi.2; Fri, 26 Aug 2016 02:51:28 -0700 (PDT) X-Gm-Message-State: AE9vXwP0AKt1i3Z4VC3Ksn59vyQEZ43bIkicy9DJ8gT5VTg4cqhmxC/UIQolKYhpgocTokHf168N4ZgYnpvSvQ== X-Received: by 10.25.16.212 with SMTP id 81mr603979lfq.174.1472205087248; Fri, 26 Aug 2016 02:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.194.232 with HTTP; Fri, 26 Aug 2016 02:50:46 -0700 (PDT) In-Reply-To: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> From: Laurent Toutain Date: Fri, 26 Aug 2016 11:50:46 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Content-Type: multipart/alternative; boundary=001a11403b76431cd4053af675d2 Archived-At: Cc: "draft-somaraju-core-sid@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 09:51:33 -0000 --001a11403b76431cd4053af675d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I support also the adoption. SID is a very compact notation needed for constraint networks. Laurent On Mon, Aug 15, 2016 at 5:06 PM, Jaime Jim=C3=A9nez wrote: > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been requested > for draft-somaraju-core-sid. At the IETF meeting the room consensus was f= or > adoption (3 people), since not too many people had read the draft we have > to take it to the list. Please reply with your comments, including althou= gh > not limited to whether or not you support adoption. Non-authors are > especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on * > August 26, 2016*. > > Thanks, > Jaime and Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --=20 Laurent Toutain +--- VoIP (recommended) ---+----------- T=C3=A9l=C3=A9com Bretagne --------= ---+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit : | Mob: +33 6 800 75 900 | | | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | +--------------------------+----------------------------------------+ --001a11403b76431cd4053af675d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I support also the adoption. SI= D is a very compact notation needed for constraint networks.

= Laurent

= On Mon, Aug 15, 2016 at 5:06 PM, Jaime Jim=C3=A9nez <<= a href=3D"mailto:jaime.jimenez@ericsson.com" target=3D"_blank">jaime.jimene= z@ericsson.com> wrote:
Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been requested f= or draft-somaraju-core-sid. At the IETF meeting the room consensus was for = adoption (3 people), since not too many people had read the draft we have t= o take it to the list.=C2=A0Please reply with your comments, including although not limited to whether or not you s= upport adoption. Non-authors are especially=C2=A0encouraged to comment.

Since there are several concurrent WGA calls, we will end the call on August 26, 2016.

Thanks,
Jaime and Carsten


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




--
Lau= rent Toutain=C2=A0
+--- VoIP (recommended) ---+-----= ------ T=C3=A9l=C3=A9com Bretagne -----------+
| Tel: +33 2 22 06 8156 = =C2=A0 =C2=A0| Tel: + 33 2 99 12 7026 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | Visit :
| Mob: +33 6 800 75 900 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Fax: +33 2 22 06 8445 =C2=A0 =C2=A0= | Fax: +33 2 99 12 7030 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0ht= tp://class.touta.in
| Laurent@Touta.in =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= Laurent.Toutain@Telecom-Bretagne.eu =C2=A0 =C2=A0|
+-------------------= -------+----------------------------------------+
<= /div>
--001a11403b76431cd4053af675d2-- From nobody Fri Aug 26 04:16:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03A512D892; Fri, 26 Aug 2016 04:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YzBMDD1HIhL; Fri, 26 Aug 2016 04:16:12 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 EB6F112D737; Fri, 26 Aug 2016 04:13:28 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id u7QBDPid017465 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Aug 2016 13:13:25 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u7QBDOvu032499 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 13:13:25 +0200 Received: from DEFTHW99ERAMSX.ww902.siemens.net (139.22.70.72) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 26 Aug 2016 13:13:24 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.119]) by DEFTHW99ERAMSX.ww902.siemens.net ([139.22.70.72]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 13:13:24 +0200 From: "Kovatsch, Matthias" To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2YgZHJhZnQt?= =?utf-8?Q?bormann-core-cocoa?= Thread-Index: AQHR9wcF7XOEF78dYUGLLT8qNc8C1KBbJrgw Date: Fri, 26 Aug 2016 11:13:23 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01868854@DEFTHW99EL4MSX.ww902.siemens.net> References: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> In-Reply-To: <9E8BCA5C-3020-4BFC-9C1D-321A6F53DD7E@ericsson.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.35] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868854DEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Cc: "draft-bormann-core-cocoa@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-bor?= =?utf-8?q?mann-core-cocoa?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 11:16:14 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868854DEFTHW99EL4MSXw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHRoZSBhZG9wdGlvbiBvZiBkcmFmdC1ib3JtYW5uLWNvcmUtY29jb2ENCg0KVGhlIGRy YWZ0IGlzIHVzZWZ1bC4gQmVzaWRlcyBkZWFsaW5nIHdpdGggbG9zc3kgbmV0d29ya3MsIGl0IGhh cyBoaWdoIHBvdGVudGlhbCB0byBpbXByb3ZlIHNjYWxhYmlsaXR5IGlzc3VlcyB3aGVuIGEgbGFy Z2UgbnVtYmVyIG9mIGRldmljZXMgYXJlIGNvbm5lY3RlZCB0byBhIGJhY2tlbmQgc2VydmljZS4g Rm9yIHBsYWluIHRocm91Z2hwdXQgb3B0aW1pemF0aW9uIGZvciB0aG9zZSBwb3dlcmZ1bCBkZXZp Y2VzLCB3ZSBoYXZlIGNvYXAtb3Zlci10Y3DigKYNCg0KQmVzdA0KTWF0dGhpYXMNCg0KDQpWb246 IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEphaW1l IEppbcOpbmV6DQpHZXNlbmRldDogTW9udGFnLCAxNS4gQXVndXN0IDIwMTYgMTc6MDkNCkFuOiBj b3JlQGlldGYub3JnIFdHDQpDYzogZHJhZnQtYm9ybWFubi1jb3JlLWNvY29hQGlldGYub3JnDQpC ZXRyZWZmOiBbY29yZV0g8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIG9mIGRyYWZ0LWJvcm1h bm4tY29yZS1jb2NvYQ0KDQpEZWFyIENvUkUtV0csDQoNCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0 IElFVEY5Niwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRy YWZ0LWJvcm1hbm4tY29yZS1jb2NvYS4gQXQgdGhlIElFVEYgbWVldGluZyB0aGUgcm9vbSBjb25z ZW5zdXMgd2FzIGZvciBhZG9wdGlvbi4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91 ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRoZXIgb3Ig bm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxseSBlbmNv dXJhZ2VkIHRvIGNvbW1lbnQuDQoNClNpbmNlIHRoZXJlIGFyZSBzZXZlcmFsIGNvbmN1cnJlbnQg V0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBBdWd1c3QgMjYsIDIwMTYuDQoNClRo YW5rcywNCkphaW1lIGFuZCBDYXJzdGVuDQoNCg== --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868854DEFTHW99EL4MSXw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mIzQzOzEgZm9yIHRoZSBhZG9wdGlvbiBvZiBkcmFmdC1ib3JtYW5uLWNvcmUtY29j b2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgaXMgdXNlZnVsLiBC ZXNpZGVzIGRlYWxpbmcgd2l0aCBsb3NzeSBuZXR3b3JrcywgaXQgaGFzIGhpZ2ggcG90ZW50aWFs IHRvIGltcHJvdmUgc2NhbGFiaWxpdHkgaXNzdWVzIHdoZW4gYSBsYXJnZSBudW1iZXIgb2YgZGV2 aWNlcyBhcmUNCiBjb25uZWN0ZWQgdG8gYSBiYWNrZW5kIHNlcnZpY2UuIEZvciBwbGFpbiB0aHJv dWdocHV0IG9wdGltaXphdGlvbiBmb3IgdGhvc2UgcG93ZXJmdWwgZGV2aWNlcywgd2UgaGF2ZSBj b2FwLW92ZXItdGNw4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hdHRoaWFzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+SW0gQXVmdHJh ZyB2b24gPC9iPkphaW1lIEppbcOpbmV6PGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBNb250YWcsIDE1 LiBBdWd1c3QgMjAxNiAxNzowOTxicj4NCjxiPkFuOjwvYj4gY29yZUBpZXRmLm9yZyBXRzxicj4N CjxiPkNjOjwvYj4gZHJhZnQtYm9ybWFubi1jb3JlLWNvY29hQGlldGYub3JnPGJyPg0KPGI+QmV0 cmVmZjo8L2I+IFtjb3JlXSDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2YgZHJhZnQtYm9y bWFubi1jb3JlLWNvY29hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RGVhciBDb1JFLVdHLDxicj4NCjxicj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElF VEY5Niwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0 LWJvcm1hbm4tY29yZS1jb2NvYS4gQXQgdGhlIElFVEYgbWVldGluZyB0aGUgcm9vbSZuYnNwO2Nv bnNlbnN1cyB3YXMgZm9yIGFkb3B0aW9uLiZuYnNwO1BsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3 aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QmbmJzcDtsaW1pdGVkIHRv IHdoZXRoZXIgb3Igbm90IHlvdQ0KIHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBl c3BlY2lhbGx5Jm5ic3A7ZW5jb3VyYWdlZCB0byBjb21tZW50Ljxicj4NCjxicj4NClNpbmNlIHRo ZXJlIGFyZSBzZXZlcmFsIGNvbmN1cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0aGUgY2Fs bCBvbiZuYnNwOzxiPkF1Z3VzdCAyNiwgMjAxNjwvYj4uPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4N CkphaW1lIGFuZCBDYXJzdGVuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868854DEFTHW99EL4MSXw_-- From nobody Fri Aug 26 04:24:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A701812D955 for ; Fri, 26 Aug 2016 04:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5sVhBgOJENq for ; Fri, 26 Aug 2016 04:24:35 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 B880B12D885 for ; Fri, 26 Aug 2016 04:20:03 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id u7QBK1dV027016 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Aug 2016 13:20:01 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u7QBK0x8019144 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 13:20:00 +0200 Received: from DEFTHW99ER7MSX.ww902.siemens.net (139.22.70.68) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 26 Aug 2016 13:20:00 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.119]) by DEFTHW99ER7MSX.ww902.siemens.net ([139.22.70.68]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 13:19:59 +0200 From: "Kovatsch, Matthias" To: Michael Koster , "consultancy@vanderstok.org" Thread-Topic: [core] Resource Directory: Use of /rd in path Thread-Index: AQHR8jWdVFusBz/r3kCJoP4E2R18NqBAaRAAgAFk3ICAACPVAIAAQ0uAgAD46ICAB+2+gIABDd4AgA8In9A= Date: Fri, 26 Aug 2016 11:19:59 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C0186889F@DEFTHW99EL4MSX.ww902.siemens.net> References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> <9cf6e5c673abbbbe60e0d6771656f3cc@xs4all.nl> <630F13BF-E488-4334-9EAB-50AF3C2E539F@gmail.com> In-Reply-To: <630F13BF-E488-4334-9EAB-50AF3C2E539F@gmail.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 11:24:38 -0000 SGkNCg0KTXkgc3VnZ2VzdGlvbjogVGhlc2UgYXJlIHRocmVlIGRpZmZlcmVudCBSRVNUZnVsIHNl cnZpY2UgZW50cnkgcG9pbnRzLiBTbyBkZXBlbmRpbmcgb24gd2hhdCBleGFjdGx5IHdlIGFyZSB0 YWxraW5nIGFib3V0LCB3ZSBoYXZlOg0KDQotIGVudHJ5IHBvaW50IFVSSSAoZS5nLiwgY29hcDov cmQuZXhhbXBsZS5jb20vcmQpDQotIGVudHJ5IHBvaW50IHJlc291cmNlIChlLmcuLCAvcmQgb2Yg YSBzcGVjaWZpYyBzZXJ2ZXIpDQoNCkEgbW9yZSBleHBsaWNpdCB2ZXJzaW9uIHdvdWxkIGJlIHRv IGNhbGwgaXQgInNlcnZpY2UgZW50cnkgcG9pbnQgVVJJL3Jlc291cmNlIiBhbGwgdGhlIHRpbWUu DQoNCkNpYW8NCk1hdHRoaWFzDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t LQ0KPiBWb246IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcg dm9uIE1pY2hhZWwgS29zdGVyDQo+IEdlc2VuZGV0OiBNaXR0d29jaCwgMTcuIEF1Z3VzdCAyMDE2 IDAxOjQyDQo+IEFuOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZw0KPiBDYzogY29yZUBpZXRm Lm9yZyBXRw0KPiBCZXRyZWZmOiBSZTogW2NvcmVdIFJlc291cmNlIERpcmVjdG9yeTogVXNlIG9m IC9yZCBpbiBwYXRoDQo+IA0KPiBIaSwNCj4gDQo+IFdlIGRlZmluZSB0aHJlZSAiZnVuY3Rpb24g c2V0cyIgaW4gUkQuIFRoZXkgYXJlIFJlZ2lzdHJhdGlvbiAocnQ9Y29yZS5yZCksIExvb2t1cA0K PiAocnQ9Y29yZS5yZC1sb29rdXApIGFuZCBHcm91cCAocnQ9Y29yZS5yZC1ncm91cCkuIEVhY2gg b2YgdGhlc2UgaGFzIGFuIEFQSSBlbnRyeQ0KPiBVUkkgdGhhdCB3ZSBzdWdnZXN0IGNvbnZlbnRp b25hbCB1c2FnZSBvZiAvcmQsIC9yZC1sb29rdXAsIGFuZCAvcmQtZ3JvdXANCj4gDQo+IFdoYXRl dmVyIHdlIGRvIHRvIGltcHJvdmUgdGhlIHRlcm1pbm9sb2d5IGZyb20gImZ1bmN0aW9uIHNldCIg dG8gIlJFU1QgQVBJDQo+IGVudHJ5IHBvaW50IiBvciB3aGF0ZXZlciB3ZSBjaG9vc2UsIGl0IG5l ZWRzIHRvIGJlIGRvbmUgY29uc2lzdGVudGx5IGluIHRoZQ0KPiBkb2N1bWVudCBmb3IgYWxsIDMg Y2FzZXMuDQo+IA0KPiBJIGRvbid0IHRoaW5rICJjb250YWluZXIgcGF0aCIgaXMgbmVjZXNzYXJp bHkgYSBiZXR0ZXIgY2hvaWNlLg0KPiANCj4gSGFubmVzLCBDYXJzdGVuLCBhbnlvbmUsIGRvIHlv dSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3Igd2hhdCB3ZSBzaG91bGQgY2FsbCB0aGVzZQ0KPiBkaWZm ZXJlbnQgQVBJIGVudHJ5IHBvaW50cz8NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IE1pY2hh ZWwNCj4gDQo+IA0KPiA+IE9uIEF1ZyAxNiwgMjAxNiwgYXQgMTI6MzUgQU0sIHBldGVyIHZhbiBk ZXIgU3RvayA8c3Rva2NvbnNAeHM0YWxsLm5sPiB3cm90ZToNCj4gPg0KPiA+IEhpIEhhbm5lcywg Q2Fyc3RlbiwNCj4gPg0KPiA+IEkgd2lsbCBwcm92aWRlIGEgcGhyYXNlIGluIHRoZSBSRCBkcmFm dCB0aGF0IHRoZSB1c2Ugb2YgdGhlIHBhdGggIi9yZCIgaW4gYWxsDQo+IGV4YW1wbGVzIGlzIHRo ZSBjb252ZW50aW9uIHVzZWQgZm9yIHRoZSBSRCBwYXRoIGluIHRoaXMgZHJhZnQuDQo+ID4NCj4g PiBDb25jZXJuaW5nIHRoZSB0ZW1wbGF0ZSBJIHByb3Bvc2U6DQo+ID4NCj4gPiByZCA6PSAgUkQg RnVuY3Rpb24gU2V0IHBhdGggKG1hbmRhdG9yeSkuICBUaGlzIGlzIHRoZSBwYXRoIG9mIHRoZQ0K PiA+ICAgICAgUkQgRnVuY3Rpb24gU2V0LCBhcyBvYnRhaW5lZCBmcm9tIGRpc2NvdmVyeS4gIFRo ZSB2YWx1ZSAicmQiIGlzDQo+ID4gdXNlZCBhcyBhbiBleGFtcGxlIHZhbHVlIHRocm91Z2hvdXQg dGhpcyBkb2N1bWVudA0KPiA+DQo+ID4gYW5kIGFzIGEgc2lkZToNCj4gPiBSZXBsYWNlIFJEIEZ1 bmN0aW9uIFNldCBwYXRoIGJ5OiBSRCBjb250YWluZXIgcGF0aD8NCj4gPg0KPiA+IEdyZWV0aW5n cywNCj4gPg0KPiA+IFBldGVyDQo+ID4NCj4gPg0KPiA+IEhhbm5lcyBUc2Nob2ZlbmlnIHNjaHJl ZWYgb3AgMjAxNi0wOC0xMSAwODozMToNCj4gPj4gSGkgUGV0ZXIsDQo+ID4+IEkgb25seSB3YW50 IHRvIGhhdmUgY2xhcmlmeSB3aGF0IHVzZSBvZiAvcmQgaXMgdGhlcmUgaW4gdGhlIGV4YW1wbGVz DQo+ID4+IGJlY2F1c2Ugb2YgdGhlIHJlY29tbWVuZGF0aW9uIGFuZCB3aGF0IGhhcyBiZWVuIGNo b3NlbiBmb3IgY29udmVuaWVuY2UuDQo+ID4+IENpYW8NCj4gPj4gSGFubmVzDQo+ID4+IE9uIDA4 LzEwLzIwMTYgMDU6NDAgUE0sIHBldGVyIHZhbiBkZXIgU3RvayB3cm90ZToNCj4gPj4+IEhpIENh cnN0ZW4sDQo+ID4+PiBUaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9ucywgYnV0IHRoZSBjaGFuZ2Vz IGRvIG5vdCBsb29rIHRoYXQNCj4gPj4+IGVzc2VudGlhbCBmb3IgdGhlIGl0ZXJvcGVyYWJpbGl0 eSBhbmQgaW1wbGVtZW50YXRpb24gdG8gbWUuDQo+ID4+PiBJIHdvdWxkIHByZWZlciB0byBnZXQg dGhlIGRyYWZ0IG91dCBhcyBpcy4NCj4gPj4+IEhhbm5lcyB0aGlua3MgZGlmZmVyZW50bHk/DQo+ ID4+PiBQZXRlcg0KPiA+Pj4gQ2Fyc3RlbiBCb3JtYW5uIHNjaHJlZWYgb3AgMjAxNi0wOC0xMCAx MzozOToNCj4gPj4+PiBwZXRlciB2YW4gZGVyIFN0b2sgd3JvdGU6DQo+ID4+Pj4+IEhpIENhcnN0 ZW4sDQo+ID4+Pj4+IERvIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhhdCB5b3UgcmVjb21tZW5k IHRvIGtlZXAgdGhlIGN1cnJlbnQNCj4gPj4+Pj4gdGVtcGxhdGUgd29yZGluZz8NCj4gPj4+Pj4g VVJJIFRlbXBsYXRlOiAgL3srcmR9ez9lcCxkLGV0LGx0LGNvbn0NCj4gPj4+Pj4gICBVUkkgVGVt cGxhdGUgVmFyaWFibGVzOg0KPiA+Pj4+PiAgICAgIHJkIDo9ICBSRCBGdW5jdGlvbiBTZXQgcGF0 aCAobWFuZGF0b3J5KS4gIFRoaXMgaXMgdGhlIHBhdGggb2YgdGhlDQo+ID4+Pj4+ICAgICAgICAg UkQgRnVuY3Rpb24gU2V0LCBhcyBvYnRhaW5lZCBmcm9tIGRpc2NvdmVyeS4gIEFuIFJEIFNIT1VM RCB1c2UNCj4gPj4+Pj4gICAgICAgICB0aGUgdmFsdWUgInJkIiBmb3IgdGhpcyB2YXJpYWJsZSB3 aGVuZXZlciBwb3NzaWJsZS4NCj4gPj4+PiBNYXliZSBhIGJldHRlciB3b3JkaW5nIG9mIHRoZSBs YXN0IHNlbnRlbmNlIHdvdWxkIGJlOg0KPiA+Pj4+IEFzIGEgY29udmVudGlvbiB0aGF0IGFpZHMg aW4gZGVidWdnaW5nLCBhIHNlcnZlciBjYW4gdXNlIHRoZSB2YWx1ZSAicmQiDQo+ID4+Pj4gdW5s ZXNzIGl0IHByZWZlcnMgYSBkaWZmZXJlbnQgdmFsdWUuDQo+ID4+Pj4gR2V0cyByaWQgb2YgdGhl IFNIT1VMRCwgYW5kIG1ha2VzIGl0IGNsZWFyIHRoZSB0aGUgc2VydmVyIGlzIGZyZWUNCj4gPj4+ PiB0byBjaG9vc2UgKGFzIHBlciBSRkMgNzMyMCkuDQo+ID4+Pj4gKEFuZCBtYXliZSB3ZSBjYW4g Z2V0IHJpZCBvZiAiRnVuY3Rpb24gU2V0IiBpbiBhIHNlcGFyYXRlIGVmZm9ydC4pDQo+ID4+Pj4g R3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IGNvcmVAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUg bWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Fri Aug 26 04:28:18 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C461812D925 for ; Fri, 26 Aug 2016 04:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1v4AeU5255x for ; Fri, 26 Aug 2016 04:28:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8614712D764 for ; Fri, 26 Aug 2016 04:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4374; q=dns/txt; s=iport; t=1472210596; x=1473420196; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S83DWfUp7D8OgWYyZAW+Z0SBJyYLruf3ONdBlmTZQAg=; b=F+4np/nelU9BvzBTVW9cOH2Gu37HYr2hyIx4mPLo49poyK6YiSx+rII+ GD3IdApY6CTdCUkeT6P9u/74FjKrnSB8ZQohn1EzkNPhJ3koa6hdo7GvY 9Z25ojQ3gO5vqKwHJpz14wV5iv3vVFKEWdb0i4oA6UfSs5KuL6/7xX/r0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AQCGJcBX/40NJK1dFgMBAQEBAYMjA?= =?us-ascii?q?QEBAQEeVnwHjSmmM4RAggEZC4V5AhyBPzgUAQEBAQEBAQEBAV4nhGEBAQEEAQE?= =?us-ascii?q?BIBE6CwwCAgIBBgIOAwQBAQECAiMDAgICGQwLFAEFAwgCBAENBQiIMA6TCJ0jj?= =?us-ascii?q?0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBQV+hSuETYQcO4JrgloFmUwBjyGBdIR?= =?us-ascii?q?diQiMQ4N4AR42hBxwhB6BL38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,580,1464652800"; d="scan'208";a="144146550" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Aug 2016 11:23:15 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7QBNFnw006508 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 11:23:15 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 Aug 2016 06:23:14 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 26 Aug 2016 06:23:14 -0500 From: "Pascal Thubert (pthubert)" To: Alexander Pelov , Marco Tiloca Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1z?= =?utf-8?Q?elander-ace-object-security?= Thread-Index: AQHR/3OcEAUOj30BBUWIWsuFhXQuzqBbPM2A///aBMA= Date: Fri, 26 Aug 2016 11:22:44 +0000 Deferred-Delivery: Fri, 26 Aug 2016 11:22:28 +0000 Message-ID: References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> <6535adf5-7c76-ff1a-e5a3-dcbff49a35ef@nteczone.com> <57BFFD3F.6070608@sics.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 11:28:17 -0000 KzENCg0KVGhpcyBtYXkgYmVjb21lIGEgY29yZSB0b29sIGZvciBkaXNzZW1pbmF0aW9uIG9mIHRy dXN0ZWQgb2JqZWN0cy4gDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFBlbG92DQo+IFNlbnQ6IHZlbmRyZWRpIDI2IGFvw7t0 IDIwMTYgMTA6MjkNCj4gVG86IE1hcmNvIFRpbG9jYSA8bWFyY29Ac2ljcy5zZT4NCj4gQ2M6IGNv cmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdvcmtpbmcgR3JvdXAgQWRv cHRpb24gb2YgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC0NCj4gc2VjdXJpdHkNCj4gDQo+ICsx DQo+IA0KPiBJbiBzdXBwb3J0IG9mIHRoZSBhZG9wdGlvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBB bGV4YW5kZXINCj4gDQo+IA0KPiA+IExlIDI2IGFvw7t0IDIwMTYgw6AgMTA6MjYsIE1hcmNvIFRp bG9jYSA8bWFyY29Ac2ljcy5zZT4gYSDDqWNyaXQgOg0KPiA+DQo+ID4gKzENCj4gPg0KPiA+IEkg YWxzbyBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPiA+DQo+ID4gSXQgaXMg dmVyeSB1c2VmdWwgZm9yIG1hbnkgc2NlbmFyaW9zIGFuZCBzZXR0aW5ncyB0byBoYXZlIHN1Y2gg YW4NCj4gPiBhcHBsaWNhdGlvbi1sYXllciBzZWN1cml0eSBtZWNoYW5pc20gYXZhaWxhYmxlLCBl c3BlY2lhbGx5IGluIHRoZQ0KPiA+IHByZXNlbmNlIG9mIHByb3h5IHVuaXRzLg0KPiA+DQo+ID4g QmVzdCByZWdhcmRzLA0KPiA+IC9NYXJjbw0KPiA+DQo+ID4gT24gMjAxNi0wOC0yNiAwNzowNywg Q2hyaXN0aWFuIEdyb3ZlcyB3cm90ZToNCj4gPj4gKzENCj4gPj4NCj4gPj4gQ2hyaXN0aWFuDQo+ ID4+DQo+ID4+DQo+ID4+IE9uIDI1LzA4LzIwMTYgMTE6NDAgUE0sIFNhbmRlZXAgS3VtYXIgd3Jv dGU6DQo+ID4+PiArMQ0KPiA+Pj4gSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdCBhcyBp dCBpcyBxdWl0ZSB1c2VmdWwgdG8gaGF2ZSB0aGlzDQo+ID4+PiBhZGRpdGlvbmFsIHNlY3VyaXR5 IG1lY2hhbmlzbSBpbiB0aGUgdG9vbGtpdCB0aGF0IGlzIHVzZWZ1bCBpbiBtYW55DQo+ID4+PiBz ZXR0aW5ncy4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzDQo+ID4+PiBTYW5kZWVwDQo+ID4+Pg0KPiA+ Pj4gU2FuZGVlcCBLdW1hcg0KPiA+Pj4NCj4gPj4+IFNlbmlvciBTY2llbnRpc3QsDQo+ID4+Pg0K PiA+Pj4gUGhpbGlwcyBMaWdodGluZyBSZXNlYXJjaCxUaGUgTmV0aGVybGFuZHMNCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4gT24gTW9uLCBBdWcgMTUsIDIwMTYgYXQgNTowOCBQTSwgSmFpbWUgSmltw6lu ZXoNCj4gPj4+IDxqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbSA8bWFpbHRvOmphaW1lLmppbWVu ZXpAZXJpY3Nzb24uY29tPj4NCj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gICAgRGVhciBDb1JFLVdH LA0KPiA+Pj4NCj4gPj4+ICAgIEFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29ya2lu ZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbg0KPiA+Pj4gICAgcmVxdWVzdGVkIGZvciBkcmFmdC1z ZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LiBBdCB0aGUgSUVURg0KPiA+Pj4gICAgbWVldGlu ZyB0aGUgcm9vbSBjb25zZW5zdXMgd2FzIHN0cm9uZ2x5IHN1cHBvcnRpbmcgYWRvcHRpb24gKDEw LTEyDQo+ID4+PiAgICBwZW9wbGUpLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3Vy IGNvbW1lbnRzLCBpbmNsdWRpbmcNCj4gPj4+ICAgIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdo ZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLg0KPiA+Pj4gICAgTm9uLWF1dGhvcnMg YXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KPiA+Pj4NCj4gPj4+ICAgIFNp bmNlIHRoZXJlIGFyZSBzZXZlcmFsIGNvbmN1cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0 aGUgY2FsbA0KPiA+Pj4gICAgb24gKkF1Z3VzdCAyNiwgMjAxNiouDQo+ID4+Pg0KPiA+Pj4gICAg VGhhbmtzLA0KPiA+Pj4gICAgSmFpbWUgYW5kIENhcnN0ZW4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4g ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ ICAgIGNvcmUgbWFpbGluZyBsaXN0DQo+ID4+PiAgICBjb3JlQGlldGYub3JnIDxtYWlsdG86Y29y ZUBpZXRmLm9yZz4NCj4gPj4+ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZQ0KPiA+Pj4gICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZT4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gY29yZSBtYWlsaW5nIGxpc3QN Cj4gPj4+IGNvcmVAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZQ0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+PiBjb3JlQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiA+ DQo+ID4gLS0NCj4gPiBNYXJjbyBUaWxvY2EsIFBoRA0KPiA+IFNJQ1MgU3dlZGlzaCBJQ1QgQUIN Cj4gPiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiA+IFNFLTE2NCA0MCBL aXN0YSAoU3dlZGVuKQ0KPiA+DQo+ID4gUGhvbmU6ICs0NiAoMCk3MCA2MCA0NiA1MDENCj4gPiBo dHRwczovL3d3dy5zaWNzLnNlDQo+ID4gaHR0cHM6Ly93d3cuc2ljcy5zZS9+bWFyY28vDQo+ID4N Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBjb3JlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBj b3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29y ZQ0K From nobody Fri Aug 26 04:57:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387F412D68B; Fri, 26 Aug 2016 04:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id driA1QLlsxK6; Fri, 26 Aug 2016 04:57:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C0712D6B9; Fri, 26 Aug 2016 04:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12240; q=dns/txt; s=iport; t=1472212577; x=1473422177; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hTnb+5SF+9jSerMrFCC0U6oWj5PY0FAhgUnXkAvGNlk=; b=RM97eoIv7lrkDky2/Uf9AZ8g/Xf/nZW/ChaLU4HFiIKqit0OFuRbXtPL aYkUJglkWFtEl17oR37Jzv60toLOr9I1c8QSOl8kcnSRvmpIGNPyhEdCb NmQrFDq/zPfDzaOZQPJ/NP8teoUDt02JJ8PH7CUQkYvZpyFqWWmOLKNWn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQCvLcBX/5NdJa1dGQEBAQEBgnAzA?= =?us-ascii?q?QEBAQEeVnwHgnqKL6VrSYRAggEZAQqFeQIcgT84FAEBAQEBAQEBAQFeJ4RhAQE?= =?us-ascii?q?BBAEBAQkRBgpBCxACAQYCEQQBASgDAgICJQsUBgMIAgQBDQUIiDAOkn+dI49LA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHIYuhE2EHDsfCIJEgloFiCyRIAGGH4kCgXR?= =?us-ascii?q?OhA+DM4VVjEODeAEPDzaCNByBTHCEHoEvfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,580,1464652800"; d="scan'208,217";a="140163390" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Aug 2016 11:56:16 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u7QBuGNU020752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 11:56:16 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 Aug 2016 06:56:15 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 26 Aug 2016 06:56:15 -0500 From: "Pascal Thubert (pthubert)" To: Laurent Toutain , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-somaraju-core-sid?= Thread-Index: AQHR/39xiVskUABz4k6jMdPYpE9n5KBbIhJg Date: Fri, 26 Aug 2016 11:55:51 +0000 Deferred-Delivery: Fri, 26 Aug 2016 11:55:36 +0000 Message-ID: References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_d56d5c21c14f49dcb6e5f2ff99a2ee88XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-somaraju-core-sid@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 11:57:45 -0000 --_000_d56d5c21c14f49dcb6e5f2ff99a2ee88XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtZSBoZXJlOw0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXNvbWFyYWp1LWNv cmUtc2lkDQoNClBhc2NhbA0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTGF1cmVudCBUb3V0YWluDQpTZW50OiB2ZW5kcmVkaSAyNiBhb8O7 dCAyMDE2IDExOjUxDQpUbzogSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tPg0KQ2M6IGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkQGlldGYub3JnOyBjb3JlQGlldGYub3Jn IFdHIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdvcmtpbmcgR3Jv dXAgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtc29tYXJhanUtY29yZS1zaWQNCg0KSGksDQpJIHN1 cHBvcnQgYWxzbyB0aGUgYWRvcHRpb24uIFNJRCBpcyBhIHZlcnkgY29tcGFjdCBub3RhdGlvbiBu ZWVkZWQgZm9yIGNvbnN0cmFpbnQgbmV0d29ya3MuDQpMYXVyZW50DQoNCk9uIE1vbiwgQXVnIDE1 LCAyMDE2IGF0IDU6MDYgUE0sIEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1lbmV6QGVyaWNzc29u LmNvbTxtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+PiB3cm90ZToNCkRlYXIgQ29S RS1XRywNCg0KQXMgd2UgZGlzY3Vzc2VkIGF0IGxhc3QgSUVURjk2LCB3b3JraW5nIGdyb3VwIGFk b3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtc29tYXJhanUtY29yZS1zaWQuIEF0 IHRoZSBJRVRGIG1lZXRpbmcgdGhlIHJvb20gY29uc2Vuc3VzIHdhcyBmb3IgYWRvcHRpb24gKDMg cGVvcGxlKSwgc2luY2Ugbm90IHRvbyBtYW55IHBlb3BsZSBoYWQgcmVhZCB0aGUgZHJhZnQgd2Ug aGF2ZSB0byB0YWtlIGl0IHRvIHRoZSBsaXN0LiBQbGVhc2UgcmVwbHkgd2l0aCB5b3VyIGNvbW1l bnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBub3QgeW91 IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQg dG8gY29tbWVudC4NCg0KU2luY2UgdGhlcmUgYXJlIHNldmVyYWwgY29uY3VycmVudCBXR0EgY2Fs bHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3VzdCAyNiwgMjAxNi4NCg0KVGhhbmtzLA0K SmFpbWUgYW5kIENhcnN0ZW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNv cmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cg0KDQoNCi0tDQpMYXVyZW50IFRvdXRhaW4NCistLS0gVm9JUCAocmVjb21tZW5kZWQpIC0tLSst LS0tLS0tLS0tLSBUw6lsw6ljb20gQnJldGFnbmUgLS0tLS0tLS0tLS0rDQp8IFRlbDogKzMzIDIg MjIgMDYgODE1NiAgICB8IFRlbDogKyAzMyAyIDk5IDEyIDcwMjYgICAgICAgICAgICAgICAgIHwg VmlzaXQgOg0KfCBNb2I6ICszMyA2IDgwMCA3NSA5MDAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQp8IEZheDogKzMzIDIgMjIgMDYgODQ0NSAgICB8IEZheDog KzMzIDIgOTkgMTIgNzAzMCAgICAgICAgICAgICAgICAgIHwgIGh0dHA6Ly9jbGFzcy50b3V0YS5p bg0KfCBMYXVyZW50QFRvdXRhLmluPG1haWx0bzpMYXVyZW50QFRvdXRhLmluPiAgICAgICAgIHwg TGF1cmVudC5Ub3V0YWluQFRlbGVjb20tQnJldGFnbmUuZXU8bWFpbHRvOkxhdXJlbnQuVG91dGFp bkBUZWxlY29tLUJyZXRhZ25lLmV1PiAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg== --_000_d56d5c21c14f49dcb6e5f2ff99a2ee88XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TYW1lIGhlcmU7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFzY2Fs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+TGF1cmVudCBUb3V0YWluPGJyPg0KPGI+U2VudDo8L2I+IHZlbmRyZWRpIDI2 IGFvw7t0IDIwMTYgMTE6NTE8YnI+DQo8Yj5Ubzo8L2I+IEphaW1lIEppbcOpbmV6ICZsdDtqYWlt ZS5qaW1lbmV6QGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LXNvbWFyYWp1 LWNvcmUtc2lkQGlldGYub3JnOyBjb3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssc2Fu cy1zZXJpZiI+JiMxMjgyNzY7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFdvcmtpbmcgR3JvdXAg QWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtc29tYXJhanUtY29yZS1zaWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgc3VwcG9ydCBh bHNvIHRoZSBhZG9wdGlvbi4gU0lEIGlzIGEgdmVyeSBjb21wYWN0IG5vdGF0aW9uIG5lZWRlZCBm b3IgY29uc3RyYWludCBuZXR3b3Jrcy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5MYXVyZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEF1ZyAxNSwgMjAxNiBhdCA1OjA2IFBNLCBKYWltZSBKaW3DqW5l eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+amFpbWUuamltZW5lekBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBD b1JFLVdHLDxicj4NCjxicj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29ya2lu ZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNvbWFyYWp1LWNv cmUtc2lkLiBBdCB0aGUgSUVURiBtZWV0aW5nIHRoZSByb29tIGNvbnNlbnN1cyB3YXMgZm9yIGFk b3B0aW9uICgzIHBlb3BsZSksIHNpbmNlIG5vdCB0b28gbWFueSBwZW9wbGUgaGFkIHJlYWQgdGhl IGRyYWZ0IHdlIGhhdmUgdG8gdGFrZSBpdCB0byB0aGUgbGlzdC4mbmJzcDtQbGVhc2UgcmVwbHkN CiB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3 aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVj aWFsbHkmbmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuPGJyPg0KPGJyPg0KU2luY2UgdGhlcmUg YXJlIHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9u IDxiPkF1Z3VzdCAyNiwgMjAxNjwvYj4uPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkphaW1lIGFu ZCBDYXJzdGVuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXVyZW50IFRvdXRhaW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0gVm9JUCAocmVjb21tZW5kZWQp IC0tLSYjNDM7LS0tLS0tLS0tLS0gVMOpbMOpY29tIEJyZXRhZ25lIC0tLS0tLS0tLS0tJiM0Mzs8 YnI+DQp8IFRlbDogJiM0MzszMyAyIDIyIDA2IDgxNTYgJm5ic3A7ICZuYnNwO3wgVGVsOiAmIzQz OyAzMyAyIDk5IDEyIDcwMjYgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8IFZpc2l0IDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij58IE1vYjogJiM0MzszMyA2IDgwMCA3NSA5MDAgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPnwgRmF4OiAmIzQzOzMzIDIgMjIgMDYgODQ0NSAmbmJzcDsg Jm5ic3A7fCBGYXg6ICYjNDM7MzMgMiA5OSAxMiA3MDMwICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDs8YSBocmVmPSJo dHRwOi8vY2xhc3MudG91dGEuaW4iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vY2xhc3MudG91dGEu aW48L2E+PGJyPg0KfCA8YSBocmVmPSJtYWlsdG86TGF1cmVudEBUb3V0YS5pbiI+TGF1cmVudEBU b3V0YS5pbjwvYT4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgPGEgaHJlZj0ibWFpbHRv OkxhdXJlbnQuVG91dGFpbkBUZWxlY29tLUJyZXRhZ25lLmV1Ij4NCkxhdXJlbnQuVG91dGFpbkBU ZWxlY29tLUJyZXRhZ25lLmV1PC9hPiAmbmJzcDsgJm5ic3A7fDxicj4NCiYjNDM7LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d56d5c21c14f49dcb6e5f2ff99a2ee88XCHRCD001ciscocom_-- From nobody Fri Aug 26 05:01:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6033A12D13E; Fri, 26 Aug 2016 05:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V97qyMcU8cFW; Fri, 26 Aug 2016 05:01:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D03512B006; Fri, 26 Aug 2016 05:01:08 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-6e-57c02f828084 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 8A.95.02553.28F20C75; Fri, 26 Aug 2016 14:01:07 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.215]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 14:01:05 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBjYWxsIGZvciBk?= =?utf-8?Q?raft-groves-core-dynlink?= Thread-Index: AQHR9wZnahU7ZPN6rEK7KKBHbT/BeqBbE3YA Date: Fri, 26 Aug 2016 12:01:05 +0000 Message-ID: <3A9C9924-D032-4BEE-9B78-DF94680A7C95@ericsson.com> References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> In-Reply-To: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_3A9C9924D0324BEE9B78DF94680A7C95ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2J7iG6z/oFwgztfGS2OTLnLarHv7Xpm i1U/njA6MHssWfKTyWPaoswApigum5TUnMyy1CJ9uwSujLW//jMVLJStOLBrHVsD4yqZLkYO DgkBE4npPaZdjJwcQgLrGSUe7pfsYuQCspcwSkxoW8UOkmATcJb49KwRzBYRUJNonfSKDcRm FsiXWHnoAwuILSxQI/H5+CtWiJpaiad/X0PZRhInzs0Eq2cRUJU4eH4zM4jNK2AvMfNzJzvE YnuJTRMnMYLYnAIOEjOnzQarYRQQk/h+ag0TxC5xiVtP5oPZEgICEkv2nGeGsEUlXj7+xwph K0k0LnnCCvIXs0CyxL97xhCrBCVOznzCMoFRZBaSSbMQqmYhqYIIa0qs36UPUa0oMaX7ITuE rSHROmcuO0SJtcSsvjpkJQsYOVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbbwS2/DXYw vnzueIhRgINRiYdXwWh/uBBrYllxZe4hRgkOZiUR3ljdA+FCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGEPTj7G871Q59Wib+MWrq7Y8nWItvHDy9NT1 Zv1y092+nWvfk6tz7716WLHvjTvrN55dvOh6RoLh6+XP1s87V6Jl8+7cwlT+mJDK9UdkE/6+ 1jm3J8xXptFo9rdvrF94HazPO9dcbn+XHyDh8C8iSE7j3RpTaY/5wr/lIwJcv1ZPTn07dWF3 XroSS3FGoqEWc1FxIgBs1HQTsgIAAA== Archived-At: Cc: "draft-groves-core-dynlink@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-groves-core-dynlink?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 12:01:11 -0000 --_000_3A9C9924D0324BEE9B78DF94680A7C95ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBcyBwZW9wbGUgYXJlIG9uIHZhY2F0aW9uLCBsZXTigJlzIGV4dGVuZCB0aGUg ZGVhZGxpbmUgZmV3IGRheXMgbW9yZSB0byBhbGxvdyBwZW9wbGUgdG8gY29tbWVudC4NCg0KQ2lh byENCi0gLSBKYWltZSBKaW1lbmV6DQoNCk9uIDE1IEF1ZyAyMDE2LCBhdCAxODowNSwgSmFpbWUg Smltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6 QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpEZWFyIENvUkUtV0csDQoNCkFzIHdlIGRpc2N1c3Nl ZCBhdCBsYXN0IElFVEY5Niwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0 ZWQgZm9yIGRyYWZ0LWdyb3Zlcy1jb3JlLWR5bmxpbmsuIFRoaXMgZHJhZnQgaXMgdGhlIHJlc3Vs dCBvZiBhIGRvY3VtZW50IHNwbGl0IGFuZCB0aHVzIHRoZSBpbml0aWFsIHN0YXR1cyBpcyB0aGF0 IG9mIGFkb3B0aW9uLCBuZXZlcnRoZWxlc3MgdGhhdCBoYXMgdG8gYmUgY29uZmlybWVkIG9uIHRo ZSBsaXN0LiBQbGVhc2UgcmVwbHkgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91 Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5v bi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCg0KU2luY2Ug dGhlcmUgYXJlIHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBj YWxsIG9uIEF1Z3VzdCAyNiwgMjAxNi4NCg0KVGhhbmtzLA0KSmFpbWUgYW5kIENhcnN0ZW4NCg0K --_000_3A9C9924D0324BEE9B78DF94680A7C95ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgcGVvcGxlIGFyZSBvbiB2 YWNhdGlvbiwgbGV04oCZcyBleHRlbmQgdGhlIGRlYWRsaW5lIGZldyBkYXlzIG1vcmUgdG8gYWxs b3cgcGVvcGxlIHRvIGNvbW1lbnQuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2lh byE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSAtIEphaW1lIEppbWVuZXogPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPk9uIDE1IEF1ZyAyMDE2LCBhdCAxODowNSwgSmFpbWUgSmltw6luZXogJmx0OzxhIGhy ZWY9Im1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+amFpbWUuamlt ZW5lekBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkRlYXIgQ29SRS1XRyw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdv cmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciZuYnNwO2RyYWZ0LWdy b3Zlcy1jb3JlLWR5bmxpbmsuIFRoaXMgZHJhZnQgaXMgdGhlIHJlc3VsdCBvZiBhIGRvY3VtZW50 IHNwbGl0IGFuZCB0aHVzIHRoZSBpbml0aWFsIHN0YXR1cyBpcyB0aGF0IG9mIGFkb3B0aW9uLCBu ZXZlcnRoZWxlc3MgdGhhdCBoYXMgdG8gYmUgY29uZmlybWVkIG9uIHRoZSBsaXN0LiZuYnNwO1Bs ZWFzZSZuYnNwO3JlcGx5DQogd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2gg bm90Jm5ic3A7bGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4g Tm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkmbmJzcDtlbmNvdXJhZ2VkJm5ic3A7dG8gY29tbWVu dC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTaW5jZSB0aGVyZSBhcmUgc2V2ZXJhbCBj b25jdXJyZW50IFdHQSBjYWxscywgd2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24mbmJzcDs8YiBjbGFz cz0iIj5BdWd1c3QgMjYsIDIwMTY8L2I+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRo YW5rcyw8YnIgY2xhc3M9IiI+DQpKYWltZSBhbmQgQ2Fyc3RlbjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_3A9C9924D0324BEE9B78DF94680A7C95ericssoncom_-- From nobody Fri Aug 26 06:33:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DB012D6AE; Fri, 26 Aug 2016 06:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23OSpf4BILdp; Fri, 26 Aug 2016 06:33:02 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 E52D312D910; Fri, 26 Aug 2016 06:23:04 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id u7QDN11M025473 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Aug 2016 15:23:01 +0200 Received: from DEFTHW99ERJMSX.ww902.siemens.net (defthw99erjmsx.ww902.siemens.net [139.22.70.135]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id u7QDMxRI025721 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 15:23:01 +0200 Received: from DEFTHW99ER8MSX.ww902.siemens.net (139.22.70.73) by DEFTHW99ERJMSX.ww902.siemens.net (139.22.70.135) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 26 Aug 2016 15:22:59 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.119]) by DEFTHW99ER8MSX.ww902.siemens.net ([139.22.70.73]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 15:22:58 +0200 From: "Kovatsch, Matthias" To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gY2FsbCBmb3Ig?= =?utf-8?Q?draft-somaraju-core-sid?= Thread-Index: AQHR9waf6/bJ+bHuyUKUc583312ekaBbSnRQ Date: Fri, 26 Aug 2016 13:22:58 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01868AD5@DEFTHW99EL4MSX.ww902.siemens.net> References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> In-Reply-To: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.35] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868AD5DEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Cc: "draft-somaraju-core-sid@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-somaraju-core-sid?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 13:33:06 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868AD5DEFTHW99EL4MSXw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIGFkb3B0aW9uDQoNCkVuYWJsaW5nIFlBTkcgZm9yIGNvbnN0cmFpbmVkIG5ldHdvcmsg bWFuYWdlbWVudCB0aHJvdWdoIENCT1IgaXMgdXNlZnVsLg0KDQpXaGlsZSByZWFkaW5nIHRoZSBk cmFmdCwgSSBub3RpY2VkIHRoYXQgdGhlIGludHJvZHVjdGlvbiwgaW4gcGFydGljdWxhciB0aGUg dGVjaG5pY2FsIHN1bW1hcnkgaW4gdGhlIGFic3RyYWN0LCBjb3VsZCBiZSBpbXByb3ZlZC4gQmFz ZWQgb24gdGhlIGRvY3VtZW50LCBpdCB0b29rIG1lIGEgd2hpbGUgdG8gdW5kZXJzdGFuZCB3aGF0 IGV4YWN0bHkgaXMgZGVmaW5lZCBmb3IgQ0JPUiBhbmQgdG8gd2hhdCBpdCBjb3JyZXNwb25kcyBp biBZQU5HIGFuZCB0aGUgY2xhc3NpYyBjb25mIHByb3RvY29scy4gSXQgaXMgcmVhbGx5IHNpbXBs ZSwgdGh1cyBJIHdhcyBzdXJwcmlzZWQgd2h5IGl0IHRvb2sgc28gbG9uZyB0byB1bmRlcnN0YW5k IGJhc2VkIG9uIHRoZSB0ZXh0IDopDQoNCkJlc3QgcmVnYXJkcw0KTWF0dGhpYXMNCg0KVm9uOiBj b3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBKYWltZSBK aW3DqW5leg0KR2VzZW5kZXQ6IE1vbnRhZywgMTUuIEF1Z3VzdCAyMDE2IDE3OjA3DQpBbjogY29y ZUBpZXRmLm9yZyBXRw0KQ2M6IGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lkQGlldGYub3JnDQpCZXRy ZWZmOiBbY29yZV0g8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNv bWFyYWp1LWNvcmUtc2lkDQoNCkRlYXIgQ29SRS1XRywNCg0KQXMgd2UgZGlzY3Vzc2VkIGF0IGxh c3QgSUVURjk2LCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3Ig ZHJhZnQtc29tYXJhanUtY29yZS1zaWQuIEF0IHRoZSBJRVRGIG1lZXRpbmcgdGhlIHJvb20gY29u c2Vuc3VzIHdhcyBmb3IgYWRvcHRpb24gKDMgcGVvcGxlKSwgc2luY2Ugbm90IHRvbyBtYW55IHBl b3BsZSBoYWQgcmVhZCB0aGUgZHJhZnQgd2UgaGF2ZSB0byB0YWtlIGl0IHRvIHRoZSBsaXN0LiBQ bGVhc2UgcmVwbHkgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxp bWl0ZWQgdG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3Jz IGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCg0KU2luY2UgdGhlcmUgYXJl IHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1 Z3VzdCAyNiwgMjAxNi4NCg0KVGhhbmtzLA0KSmFpbWUgYW5kIENhcnN0ZW4NCg0K --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868AD5DEFTHW99EL4MSXw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mIzQzOzEgZm9yIGFkb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RW5hYmxpbmcgWUFORyBmb3IgY29uc3RyYWluZWQgbmV0d29yayBtYW5hZ2VtZW50IHRocm91 Z2ggQ0JPUiBpcyB1c2VmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hpbGUg cmVhZGluZyB0aGUgZHJhZnQsIEkgbm90aWNlZCB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24sIGluIHBh cnRpY3VsYXIgdGhlIHRlY2huaWNhbCBzdW1tYXJ5IGluIHRoZSBhYnN0cmFjdCwgY291bGQgYmUg aW1wcm92ZWQuIEJhc2VkIG9uIHRoZSBkb2N1bWVudCwNCiBpdCB0b29rIG1lIGEgd2hpbGUgdG8g dW5kZXJzdGFuZCB3aGF0IGV4YWN0bHkgaXMgZGVmaW5lZCBmb3IgQ0JPUiBhbmQgdG8gd2hhdCBp dCBjb3JyZXNwb25kcyBpbiBZQU5HIGFuZCB0aGUgY2xhc3NpYyBjb25mIHByb3RvY29scy4gSXQg aXMgcmVhbGx5IHNpbXBsZSwgdGh1cyBJIHdhcyBzdXJwcmlzZWQgd2h5IGl0IHRvb2sgc28gbG9u ZyB0byB1bmRlcnN0YW5kIGJhc2VkIG9uIHRoZSB0ZXh0IDopPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TWF0dGhpYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGNvcmUgW21haWx0 bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5JbSBBdWZ0cmFnIHZvbiA8L2I+SmFpbWUgSmlt w6luZXo8YnI+DQo8Yj5HZXNlbmRldDo8L2I+IE1vbnRhZywgMTUuIEF1Z3VzdCAyMDE2IDE3OjA3 PGJyPg0KPGI+QW46PC9iPiBjb3JlQGlldGYub3JnIFdHPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1z b21hcmFqdS1jb3JlLXNpZEBpZXRmLm9yZzxicj4NCjxiPkJldHJlZmY6PC9iPiBbY29yZV0g8J+U lCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUtc2lk PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBDb1JF LVdHLDxicj4NCjxicj4NCkFzIHdlIGRpc2N1c3NlZCBhdCBsYXN0IElFVEY5Niwgd29ya2luZyBn cm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNvbWFyYWp1LWNvcmUt c2lkLiBBdCB0aGUgSUVURiBtZWV0aW5nIHRoZSByb29tIGNvbnNlbnN1cyB3YXMgZm9yIGFkb3B0 aW9uICgzIHBlb3BsZSksIHNpbmNlIG5vdCB0b28gbWFueSBwZW9wbGUgaGFkIHJlYWQgdGhlIGRy YWZ0IHdlIGhhdmUgdG8gdGFrZSBpdCB0byB0aGUgbGlzdC4mbmJzcDtQbGVhc2UgcmVwbHkNCiB3 aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0 aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFs bHkmbmJzcDtlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuPGJyPg0KPGJyPg0KU2luY2UgdGhlcmUgYXJl IHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIDxi PkF1Z3VzdCAyNiwgMjAxNjwvYj4uPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkphaW1lIGFuZCBD YXJzdGVuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01868AD5DEFTHW99EL4MSXw_-- From nobody Fri Aug 26 10:22:25 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979FA12D1BC for ; Fri, 26 Aug 2016 10:22:23 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKblzSLZTxma for ; Fri, 26 Aug 2016 10:22:21 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0098.outbound.protection.outlook.com [104.47.1.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC4912D195 for ; Fri, 26 Aug 2016 10:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0FB0ucwKdoNRwmVJ+wjEDjJP2KlYdp/9T10J8lj86vk=; b=nji/EmERuq2mKfygMWcqR1y3g3vJ58xkkuNjzbnFSeuPJcGTiu///E4rNaUNYRUCTRpCxx443YEEWpWxmRzgms93PIxh7OpfTrLzzJywQjMb0UPDw+2at46ZZW+vSnjT6P0tr+xVDJOHo/dKdfDvEXXYtKpk3b9hrzCO+E7ADYY= Received: from HE1PR0601MB2203.eurprd06.prod.outlook.com (10.168.35.138) by HE1PR0601MB2202.eurprd06.prod.outlook.com (10.168.35.137) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Fri, 26 Aug 2016 17:22:16 +0000 Received: from HE1PR0601MB2203.eurprd06.prod.outlook.com ([10.168.35.138]) by HE1PR0601MB2203.eurprd06.prod.outlook.com ([10.168.35.138]) with mapi id 15.01.0557.030; Fri, 26 Aug 2016 17:22:16 +0000 From: Somaraju Abhinav To: "Pascal Thubert (pthubert)" , Alexander Pelov , Marco Tiloca Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1z?= =?utf-8?Q?elander-ace-object-security?= Thread-Index: AQHR/tZZHcPgFAK9fEWutCDoy36QlKBasdMAgAA3ooCAAADBgIAAMHEAgABkdOs= Date: Fri, 26 Aug 2016 17:22:15 +0000 Message-ID: References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> <6535adf5-7c76-ff1a-e5a3-dcbff49a35ef@nteczone.com> <57BFFD3F.6070608@sics.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=abhinav.somaraju@tridonic.com; x-originating-ip: [89.144.227.21] x-ms-office365-filtering-correlation-id: 2523c20b-423c-4c4a-cab3-08d3cdd586c8 x-microsoft-exchange-diagnostics: 1; HE1PR0601MB2202; 6:M+l62F9zItzM+S7EdFBSK5hy3GSiBLTpA9h2bbXi4P2h/TRSLuZ2MmunvhDaKkLP58tLG773ayiPIDX6lW9SHWuLjWDH/BRBnmZi9W9W1UYtQPafKJGaV1/So4wJSqIEIwJTNXhUBCLFH580l0ND6ydA7K6vUNZlRukHC8x5Cw4wTKlYvSiD078LCeuKgQyi9zlM723ff2+xLcbJNtK9dssm1TyPhPKrfQyHwRjnlga6SCDZTBBkIZTp05mvj+fVsLkDc99tQCXrSpCDElAvpfezJRzgDZxSwPoS3+wjjJhESd6rssLLBELaed70amUN0v5crqLamPlUG/jlrZmGgw==; 5:c1xRHA+oHUrMPJFC/WxK7OLb/7KIvKPXdUbW6JHE3syamwh/yIo7I2Ixq4av0nXCcP8ycxPUOOgNwJf9aw1QODQJwh9IqbPHKRW5qHRCVRzOJpBn4AABL1V7cmgH+q5ck5YMx5rZdW4srmZaFk9Opw==; 24:f2Ghlt9TeRugBL3fWDzivCUWU7LysKdLb9XOyi3uNdauD8agLH8Y+f5eO4tRzfBSkCywOgNeTgspl5e5GbboXH7WtkrJpzugUFak7AF1MW0=; 7:mNY2Ozv3zxYTC5+K2DdQoXCLlgSvoccuxr5qp4UfcP5nLzZrcjd3pV2BocJI3XNUkEdwJ1vHKGGLqfujRt/WrtCvi7+i0CFn8MT2F8WDks+TldDafgwQZR1facqJ4+pU3ba57z0+QMKiVeb2CYnVUV7KucaRm4sO7NPijJtdraWa1UtHhiTObLN4Qwiq6r3PcOOiuC7vJUodSstitG3+bNgHCPyBzvhPVPdwnB1qr+L60QItNRdZ/yvyDD660A09 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0601MB2202; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(192374486261705)(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR0601MB2202; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0601MB2202; x-forefront-prvs: 00462943DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(377424004)(199003)(13464003)(24454002)(189002)(3900700001)(2900100001)(92566002)(77096005)(50986999)(54356999)(106116001)(101416001)(76176999)(19625215002)(230783001)(122556002)(66066001)(7696003)(19580405001)(11100500001)(7846002)(15975445007)(15650500001)(93886004)(9686002)(81156014)(7906003)(81166006)(4326007)(10400500002)(7736002)(8936002)(76576001)(106356001)(2906002)(5002640100001)(97736004)(5890100001)(33656002)(102836003)(2950100001)(189998001)(19580395003)(3846002)(586003)(6116002)(16236675004)(5001770100001)(74316002)(68736007)(87936001)(105586002)(9886003)(3280700002)(19617315012)(5660300001)(86362001)(229383001)(3660700001)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0601MB2202; H:HE1PR0601MB2203.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: tridonic.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0601MB220359D7EDA8F75070BE540FFCEC0HE1PR0601MB2203_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 17:22:15.9984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0601MB2202 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 17:22:23 -0000 --_000_HE1PR0601MB220359D7EDA8F75070BE540FFCEC0HE1PR0601MB2203_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuIFdpbGwgYmVjb21lIGEgY29yZSB0b29sLg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9u ZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFBhc2NhbCBUaHViZXJ0 IChwdGh1YmVydCk8bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4NClNlbnQ6IOKAjjI2L+KAjjA4 L+KAjjIwMTYgMTM6MjgNClRvOiBBbGV4YW5kZXIgUGVsb3Y8bWFpbHRvOmFAYWNrbC5pbz47IE1h cmNvIFRpbG9jYTxtYWlsdG86bWFyY29Ac2ljcy5zZT4NCkNjOiBjb3JlQGlldGYub3JnPG1haWx0 bzpjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdvcmtpbmcgR3JvdXAg QWRvcHRpb24gb2YgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eQ0KDQorMQ0KDQpU aGlzIG1heSBiZWNvbWUgYSBjb3JlIHRvb2wgZm9yIGRpc3NlbWluYXRpb24gb2YgdHJ1c3RlZCBv YmplY3RzLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFsZXhhbmRlciBQZWxvdg0KPiBTZW50OiB2ZW5kcmVkaSAyNiBhb8O7dCAyMDE2IDEw OjI5DQo+IFRvOiBNYXJjbyBUaWxvY2EgPG1hcmNvQHNpY3Muc2U+DQo+IENjOiBjb3JlQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIG9m IGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3QtDQo+IHNlY3VyaXR5DQo+DQo+ICsxDQo+DQo+IElu IHN1cHBvcnQgb2YgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4NCj4NCj4gQWxleGFuZGVyDQo+ DQo+DQo+ID4gTGUgMjYgYW/Du3QgMjAxNiDDoCAxMDoyNiwgTWFyY28gVGlsb2NhIDxtYXJjb0Bz aWNzLnNlPiBhIMOpY3JpdCA6DQo+ID4NCj4gPiArMQ0KPiA+DQo+ID4gSSBhbHNvIHN1cHBvcnQg dGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQo+ID4NCj4gPiBJdCBpcyB2ZXJ5IHVzZWZ1bCBm b3IgbWFueSBzY2VuYXJpb3MgYW5kIHNldHRpbmdzIHRvIGhhdmUgc3VjaCBhbg0KPiA+IGFwcGxp Y2F0aW9uLWxheWVyIHNlY3VyaXR5IG1lY2hhbmlzbSBhdmFpbGFibGUsIGVzcGVjaWFsbHkgaW4g dGhlDQo+ID4gcHJlc2VuY2Ugb2YgcHJveHkgdW5pdHMuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4gL01hcmNvDQo+ID4NCj4gPiBPbiAyMDE2LTA4LTI2IDA3OjA3LCBDaHJpc3RpYW4gR3Jv dmVzIHdyb3RlOg0KPiA+PiArMQ0KPiA+Pg0KPiA+PiBDaHJpc3RpYW4NCj4gPj4NCj4gPj4NCj4g Pj4gT24gMjUvMDgvMjAxNiAxMTo0MCBQTSwgU2FuZGVlcCBLdW1hciB3cm90ZToNCj4gPj4+ICsx DQo+ID4+PiBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRyYWZ0IGFzIGl0IGlzIHF1aXRlIHVz ZWZ1bCB0byBoYXZlIHRoaXMNCj4gPj4+IGFkZGl0aW9uYWwgc2VjdXJpdHkgbWVjaGFuaXNtIGlu IHRoZSB0b29sa2l0IHRoYXQgaXMgdXNlZnVsIGluIG1hbnkNCj4gPj4+IHNldHRpbmdzLg0KPiA+ Pj4NCj4gPj4+IFJlZ2FyZHMNCj4gPj4+IFNhbmRlZXANCj4gPj4+DQo+ID4+PiBTYW5kZWVwIEt1 bWFyDQo+ID4+Pg0KPiA+Pj4gU2VuaW9yIFNjaWVudGlzdCwNCj4gPj4+DQo+ID4+PiBQaGlsaXBz IExpZ2h0aW5nIFJlc2VhcmNoLFRoZSBOZXRoZXJsYW5kcw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBP biBNb24sIEF1ZyAxNSwgMjAxNiBhdCA1OjA4IFBNLCBKYWltZSBKaW3DqW5leg0KPiA+Pj4gPGph aW1lLmppbWVuZXpAZXJpY3Nzb24uY29tIDxtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5j b20+Pg0KPiB3cm90ZToNCj4gPj4+DQo+ID4+PiAgICBEZWFyIENvUkUtV0csDQo+ID4+Pg0KPiA+ Pj4gICAgQXMgd2UgZGlzY3Vzc2VkIGF0IGxhc3QgSUVURjk2LCB3b3JraW5nIGdyb3VwIGFkb3B0 aW9uIGhhcyBiZWVuDQo+ID4+PiAgICByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNlbGFuZGVyLWFjZS1v YmplY3Qtc2VjdXJpdHkuIEF0IHRoZSBJRVRGDQo+ID4+PiAgICBtZWV0aW5nIHRoZSByb29tIGNv bnNlbnN1cyB3YXMgc3Ryb25nbHkgc3VwcG9ydGluZyBhZG9wdGlvbiAoMTAtMTINCj4gPj4+ICAg IHBlb3BsZSkuIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGlu Y2x1ZGluZw0KPiA+Pj4gICAgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBub3Qg eW91IHN1cHBvcnQgYWRvcHRpb24uDQo+ID4+PiAgICBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxs eSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQo+ID4+Pg0KPiA+Pj4gICAgU2luY2UgdGhlcmUgYXJl IHNldmVyYWwgY29uY3VycmVudCBXR0EgY2FsbHMsIHdlIHdpbGwgZW5kIHRoZSBjYWxsDQo+ID4+ PiAgICBvbiAqQXVndXN0IDI2LCAyMDE2Ki4NCj4gPj4+DQo+ID4+PiAgICBUaGFua3MsDQo+ID4+ PiAgICBKYWltZSBhbmQgQ2Fyc3Rlbg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gICAgY29yZSBtYWls aW5nIGxpc3QNCj4gPj4+ICAgIGNvcmVAaWV0Zi5vcmcgPG1haWx0bzpjb3JlQGlldGYub3JnPg0K PiA+Pj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ID4+ PiAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+PiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+Pj4gY29yZUBp ZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IGNvcmUgbWFpbGluZyBsaXN0DQo+ID4+IGNvcmVAaWV0Zi5vcmcNCj4gPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ID4NCj4gPiAtLQ0KPiA+ IE1hcmNvIFRpbG9jYSwgUGhEDQo+ID4gU0lDUyBTd2VkaXNoIElDVCBBQg0KPiA+IElzYWZqb3Jk c2dhdGFuIDIyIC8gS2lzdGFnw6VuZ2VuIDE2DQo+ID4gU0UtMTY0IDQwIEtpc3RhIChTd2VkZW4p DQo+ID4NCj4gPiBQaG9uZTogKzQ2ICgwKTcwIDYwIDQ2IDUwMQ0KPiA+IGh0dHBzOi8vd3d3LnNp Y3Muc2UNCj4gPiBodHRwczovL3d3dy5zaWNzLnNlL35tYXJjby8NCj4gPg0KPiA+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBjb3JlIG1h aWxpbmcgbGlzdA0KPiA+IGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0K Y29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNj bG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIg dGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRo ZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25z aWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eSB0byBzY2Fu IG9yIG90aGVyd2lzZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0K --_000_HE1PR0601MB220359D7EDA8F75070BE540FFCEC0HE1PR0601MB2203_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+JiM0MzsxLiBXaWxsIGJlY29tZSBhIGNv cmUgdG9vbC48YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIj5QYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2Vu dDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTFwdCI+4oCOMjYv4oCOMDgv4oCOMjAxNiAxMzoyODwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsg Zm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzphQGFja2wu aW8iPkFsZXhhbmRlciBQZWxvdjwvYT47DQo8YSBocmVmPSJtYWlsdG86bWFyY29Ac2ljcy5zZSI+ TWFyY28gVGlsb2NhPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9h Pjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+ UmU6IFtjb3JlXSDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2YgZHJhZnQtc2VsYW5kZXIt YWNlLW9iamVjdC1zZWN1cml0eTwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPiYjNDM7MTxicj4NCjxicj4NClRoaXMgbWF5IGJlY29tZSBhIGNvcmUgdG9vbCBm b3IgZGlzc2VtaW5hdGlvbiBvZiB0cnVzdGVkIG9iamVjdHMuIDxicj4NCjxicj4NCkNoZWVycyw8 YnI+DQo8YnI+DQpQYXNjYWw8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBjb3JlIFs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm IE9mIEFsZXhhbmRlciBQZWxvdjxicj4NCiZndDsgU2VudDogdmVuZHJlZGkgMjYgYW/Du3QgMjAx NiAxMDoyOTxicj4NCiZndDsgVG86IE1hcmNvIFRpbG9jYSAmbHQ7bWFyY29Ac2ljcy5zZSZndDs8 YnI+DQomZ3Q7IENjOiBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW2NvcmVd IPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0 LTxicj4NCiZndDsgc2VjdXJpdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsgJiM0MzsxPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEluIHN1cHBvcnQgb2YgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC48YnI+ DQomZ3Q7IDxicj4NCiZndDsgQWxleGFuZGVyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgJmd0OyBMZSAyNiBhb8O7dCAyMDE2IMOgIDEwOjI2LCBNYXJjbyBUaWxvY2EgJmx0O21hcmNv QHNpY3Muc2UmZ3Q7IGEgw6ljcml0IDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJiM0 MzsxPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgYWxzbyBzdXBwb3J0IHRoZSBhZG9w dGlvbiBvZiB0aGlzIGRyYWZ0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJdCBpcyB2 ZXJ5IHVzZWZ1bCBmb3IgbWFueSBzY2VuYXJpb3MgYW5kIHNldHRpbmdzIHRvIGhhdmUgc3VjaCBh bjxicj4NCiZndDsgJmd0OyBhcHBsaWNhdGlvbi1sYXllciBzZWN1cml0eSBtZWNoYW5pc20gYXZh aWxhYmxlLCBlc3BlY2lhbGx5IGluIHRoZTxicj4NCiZndDsgJmd0OyBwcmVzZW5jZSBvZiBwcm94 eSB1bml0cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4N CiZndDsgJmd0OyAvTWFyY288YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gMjAxNi0w OC0yNiAwNzowNywgQ2hyaXN0aWFuIEdyb3ZlcyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7ICYj NDM7MTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IENocmlzdGlhbjxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiAy NS8wOC8yMDE2IDExOjQwIFBNLCBTYW5kZWVwIEt1bWFyIHdyb3RlOjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7ICYjNDM7MTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgc3VwcG9ydCBhZG9wdGlvbiBv ZiB0aGUgZHJhZnQgYXMgaXQgaXMgcXVpdGUgdXNlZnVsIHRvIGhhdmUgdGhpczxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IGFkZGl0aW9uYWwgc2VjdXJpdHkgbWVjaGFuaXNtIGluIHRoZSB0b29sa2l0 IHRoYXQgaXMgdXNlZnVsIGluIG1hbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBzZXR0aW5ncy48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFJlZ2FyZHM8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBTYW5kZWVwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyBTYW5kZWVwIEt1bWFyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBTZW5pb3IgU2NpZW50aXN0LDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgUGhpbGlwcyBMaWdodGluZyBSZXNlYXJjaCxUaGUg TmV0aGVybGFuZHM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgT24gTW9uLCBBdWcgMTUsIDIwMTYgYXQgNTowOCBQTSwg SmFpbWUgSmltw6luZXo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAmbHQ7amFpbWUuamltZW5lekBl cmljc3Nvbi5jb20gJmx0OzxhIGhyZWY9Im1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNv bSI+bWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPiZndDsmZ3Q7PGJyPg0KJmd0 OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IERlYXIgQ29SRS1XRyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIHdlIGRpc2N1c3NlZCBhdCBs YXN0IElFVEY5Niwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3RlZCBmb3IgZHJhZnQtc2VsYW5kZXIt YWNlLW9iamVjdC1zZWN1cml0eS4gQXQgdGhlIElFVEY8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBtZWV0aW5nIHRoZSByb29tIGNvbnNlbnN1cyB3YXMgc3Ryb25nbHkg c3VwcG9ydGluZyBhZG9wdGlvbiAoMTAtMTI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBwZW9wbGUpLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNv bW1lbnRzLCBpbmNsdWRpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9w dGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBOb24tYXV0aG9y cyBhcmUgZXNwZWNpYWxseSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBTaW5jZSB0aGVy ZSBhcmUgc2V2ZXJhbCBjb25jdXJyZW50IFdHQSBjYWxscywgd2Ugd2lsbCBlbmQgdGhlIGNhbGw8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvbiAqQXVndXN0IDI2LCAy MDE2Ki48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBKYWltZSBhbmQgQ2Fyc3Rlbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY29yZUBpZXRmLm9yZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNvcmVAaWV0Zi5vcmciPm1haWx0bzpjb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGNv cmVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgJmd0OyZndDsgY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IGNvcmVAaWV0 Zi5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlPC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0 OyBNYXJjbyBUaWxvY2EsIFBoRDxicj4NCiZndDsgJmd0OyBTSUNTIFN3ZWRpc2ggSUNUIEFCPGJy Pg0KJmd0OyAmZ3Q7IElzYWZqb3Jkc2dhdGFuIDIyIC8gS2lzdGFnw6VuZ2VuIDE2PGJyPg0KJmd0 OyAmZ3Q7IFNFLTE2NCA0MCBLaXN0YSAoU3dlZGVuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBQaG9uZTogJiM0Mzs0NiAoMCk3MCA2MCA0NiA1MDE8YnI+DQomZ3Q7ICZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuc2ljcy5zZSI+aHR0cHM6Ly93d3cuc2ljcy5zZTwvYT48YnI+DQomZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuc2ljcy5zZS9+bWFyY28vIj5odHRwczovL3d3dy5z aWNzLnNlL35tYXJjby88L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyAmZ3Q7IGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IGNvcmVAaWV0Zi5v cmc8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8 L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgY29y ZUBpZXRmLm9yZzxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmU8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCmNvcmVAaWV0Zi5vcmc8YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48YnI+DQo8L2Rpdj4NCjwvc3Bhbj48 L2ZvbnQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3QgYmUg ZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGluIGFueSB3YXkgYnkgYW55b25lIG90 aGVyIHRoYW4gdGhlIGludGVuZGVkDQogcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNl aXZlZCBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0 IG5laXRoZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSBy ZXNwb25zaWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eQ0K IHRvIHNjYW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR0601MB220359D7EDA8F75070BE540FFCEC0HE1PR0601MB2203_-- From nobody Fri Aug 26 11:45:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278D612D7CF; Fri, 26 Aug 2016 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn1Nt5IE2-X6; Fri, 26 Aug 2016 11:44:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE44E12D7C4; Fri, 26 Aug 2016 11:44:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8EF13B80CF2; Fri, 26 Aug 2016 11:44:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160826184448.8EF13B80CF2@rfc-editor.org> Date: Fri, 26 Aug 2016 11:44:48 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, core@ietf.org, rfc-editor@rfc-editor.org Subject: [core] RFC 7959 on Block-Wise Transfers in the Constrained Application Protocol (CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 18:45:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7959 Title: Block-Wise Transfers in the Constrained Application Protocol (CoAP) Author: C. Bormann, Z. Shelby, Ed. Status: Standards Track Stream: IETF Date: August 2016 Mailbox: cabo@tzi.org, zach.shelby@arm.com Pages: 37 Characters: 87515 Updates: RFC 7252 I-D Tag: draft-ietf-core-block-21.txt URL: https://www.rfc-editor.org/info/rfc7959 DOI: http://dx.doi.org/10.17487/RFC7959 The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Aug 26 13:40:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4312D82A; Fri, 26 Aug 2016 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0NpddZ7rm3S; Fri, 26 Aug 2016 13:40:04 -0700 (PDT) Received: from homiemail-a92.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E50F12B02F; Fri, 26 Aug 2016 13:40:04 -0700 (PDT) Received: from homiemail-a92.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a92.g.dreamhost.com (Postfix) with ESMTP id D4F45801B02E; Fri, 26 Aug 2016 13:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=xJz+DniU1Gv/w07tfAEw/7GHDEI=; b=rIuQmAIjUwhSM5x48fUwT47UHi0g GJv7J/bK0S4I2A88XP9TIRY6ZnByk772itt6HWBccOqEGNab/+U2Kkq2WZG/GUKW mbf0J7y9uYf7bJKyVNN/FOifbqkt7Fb0C4BaxYQPpQ1VPTShxWRJ26Um1Q8YwJTx KyxX8LIMK/tM79k= Received: from [10.6.1.26] (69-178-154-242.static-ip.telepacific.net [69.178.154.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a92.g.dreamhost.com (Postfix) with ESMTPSA id A8ABF801B00C; Fri, 26 Aug 2016 13:40:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: Date: Fri, 26 Aug 2016 13:40:03 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <147204440644.13256.15079860829265270933.idtracker@ietfa.amsl.com> <0DCA59AF-6DC5-421A-A907-7C1BF173C99B@gbiv.com> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-core-etch@ietf.org, ietf@ietf.org, core@ietf.org Subject: Re: [core] Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:40:06 -0000 > On Aug 24, 2016, at 10:54 PM, Carsten Bormann wrote: > > "Roy T. Fielding" writes: > >>> The document has a reference to obsolete RFC 2616, this is intentional. >> >> What is that supposed to mean? The reference is intentionally wrong? > > RFC 7252 is referencing RFC 2616 for its security considerations, > because the RFC 723x series wasn't out yet at the time CoAP was > completed. draft-ietf-core-etch references RFC 7252 for its security > considerations. This implies a reference to RFC 2616 as well, which we > decided to make explicit (it's hard to be explicit enough about security > considerations). We could change that to leave it implicit, rendering > the downref less visible. If you think security considerations are important, they should be included in the draft and specific to the additions made by that draft. Specifying them by reference to HTTP would have made sense if you had specified CORE semantics by reference to HTTP (instead, the method definitions were copied, which creates a fork of the protocol). Regardless, this draft does not change the security considerations of RFC7252 (nor 2616, nor 7230). There is no reason to reference considerations that are not applicable to the *changes* introduced by this draft. 7252 is already a normative requirement and its normative dependency on 2616 is not changed by 2616 becoming obsolete -- the text is effectively imported by reference. If there are NEW security considerations introduced by ONLY the addition of these two methods to the semantics of CORE, then that is what should be in the security considerations of this draft. Just that and a generic link to RFC7252's security section. Nothing else. >> I looked at the text and it should be referencing section 9 of RFC7231, >> not section 15 of RFC2616. Just fix the reference or remove it entirely > > While we could add RFC 7231 to the above reference (which, as I said is > already implicitly there), a single security considerations section out > of one of the RFC 723x documents does not cover the entire security > considerations of RFC 2616 (e.g., section 15.7 does very much apply, > some of which seems to have been moved to RFC 7234). Do you see > anything specific in RFC 7231 that we should cover that isn't mentioned > in RFC 2616? It doesn't matter -- they are not relevant to these two methods. If there is something relevant from HTTP caching, then just copy the text and make it specific to these two methods. HTTP semantics could have been used verbatim by CORE, without any changes, so a normative reference to RFC 7231 (HTTP Semantics) would have been appropriate IF the CORE methods and status codes were specified by reference and not forked into your spec. My long-term advice would be to delete 50% of CORE spec and replace that with normative references to HTTP, but I wouldn't bother until after HTTP/1.1 advances to Standard status. > We could use draft-ietf-core-etch more or less randomly as the point > where we finally clean up the editorial issues caused by the sharding of > RFC 2616. The authors so far did not see a reason to do that exactly in > this document, which describes functionality not really touched by that > sharding. Should we, anyway? No, we can't make updates to a proposed standard more or less randomly. They have to be within scope and reviewed by the right folks. Method specs (which define optional features to be deployed at leisure) are not the place to make updates to the underlying protocol. People who are not implementing a given method should feel free to ignore its specification. I would actually go further and say that these two methods should have been specified in two separate documents, but it's far too late for that comment. Cheers, Roy T. Fielding Senior Principal Scientist, Adobe From nobody Sun Aug 28 23:59:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8F8127A91 for ; Sun, 28 Aug 2016 23:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZVfvk-LXW5r for ; Sun, 28 Aug 2016 23:59:03 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFFD127071 for ; Sun, 28 Aug 2016 23:59:01 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud2.xs4all.net with ESMTP id cuyz1t00C4VN29601uyzJv; Mon, 29 Aug 2016 08:59:00 +0200 Received: from 2001:983:a264:1:4101:4012:4a40:4640 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 29 Aug 2016 08:58:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 29 Aug 2016 08:58:59 +0200 From: peter van der Stok To: "Kovatsch, Matthias" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C0186889F@DEFTHW99EL4MSX.ww902.siemens.net> References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> <9cf6e5c673abbbbe60e0d6771656f3cc@xs4all.nl> <630F13BF-E488-4334-9EAB-50AF3C2E539F@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C0186889F@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: X-Sender: stokcons@xs4all.nl (5LLuFjtdmVEQUwbYX8O8vNMLzCUiRONt) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 06:59:06 -0000 Hi Matthias, Understood your suggestion for the individual entry points. But how to call the set of related entry points URI/resource? BTW it is possible to define abbreviations or acronyms in the beginning of the document; so that would be "service ep URI/resource" or even shorter? Peter Kovatsch, Matthias schreef op 2016-08-26 13:19: > Hi > > My suggestion: These are three different RESTful service entry points. > So depending on what exactly we are talking about, we have: > > - entry point URI (e.g., coap:/rd.example.com/rd) > - entry point resource (e.g., /rd of a specific server) > > A more explicit version would be to call it "service entry point > URI/resource" all the time. > > Ciao > Matthias > >> -----Ursprüngliche Nachricht----- >> Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Michael Koster >> Gesendet: Mittwoch, 17. August 2016 01:42 >> An: consultancy@vanderstok.org >> Cc: core@ietf.org WG >> Betreff: Re: [core] Resource Directory: Use of /rd in path >> >> Hi, >> >> We define three "function sets" in RD. They are Registration >> (rt=core.rd), Lookup >> (rt=core.rd-lookup) and Group (rt=core.rd-group). Each of these has an >> API entry >> URI that we suggest conventional usage of /rd, /rd-lookup, and >> /rd-group >> >> Whatever we do to improve the terminology from "function set" to "REST >> API >> entry point" or whatever we choose, it needs to be done consistently >> in the >> document for all 3 cases. >> >> I don't think "container path" is necessarily a better choice. >> >> Hannes, Carsten, anyone, do you have a suggestion for what we should >> call these >> different API entry points? >> >> Best regards, >> >> Michael >> >> >> > On Aug 16, 2016, at 12:35 AM, peter van der Stok wrote: >> > >> > Hi Hannes, Carsten, >> > >> > I will provide a phrase in the RD draft that the use of the path "/rd" in all >> examples is the convention used for the RD path in this draft. >> > >> > Concerning the template I propose: >> > >> > rd := RD Function Set path (mandatory). This is the path of the >> > RD Function Set, as obtained from discovery. The value "rd" is >> > used as an example value throughout this document >> > >> > and as a side: >> > Replace RD Function Set path by: RD container path? >> > >> > Greetings, >> > >> > Peter >> > >> > >> > Hannes Tschofenig schreef op 2016-08-11 08:31: >> >> Hi Peter, >> >> I only want to have clarify what use of /rd is there in the examples >> >> because of the recommendation and what has been chosen for convenience. >> >> Ciao >> >> Hannes >> >> On 08/10/2016 05:40 PM, peter van der Stok wrote: >> >>> Hi Carsten, >> >>> Thanks for the suggestions, but the changes do not look that >> >>> essential for the iteroperability and implementation to me. >> >>> I would prefer to get the draft out as is. >> >>> Hannes thinks differently? >> >>> Peter >> >>> Carsten Bormann schreef op 2016-08-10 13:39: >> >>>> peter van der Stok wrote: >> >>>>> Hi Carsten, >> >>>>> Do I understand correctly that you recommend to keep the current >> >>>>> template wording? >> >>>>> URI Template: /{+rd}{?ep,d,et,lt,con} >> >>>>> URI Template Variables: >> >>>>> rd := RD Function Set path (mandatory). This is the path of the >> >>>>> RD Function Set, as obtained from discovery. An RD SHOULD use >> >>>>> the value "rd" for this variable whenever possible. >> >>>> Maybe a better wording of the last sentence would be: >> >>>> As a convention that aids in debugging, a server can use the value "rd" >> >>>> unless it prefers a different value. >> >>>> Gets rid of the SHOULD, and makes it clear the the server is free >> >>>> to choose (as per RFC 7320). >> >>>> (And maybe we can get rid of "Function Set" in a separate effort.) >> >>>> Grüße, Carsten >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 29 00:02:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92711127071 for ; Mon, 29 Aug 2016 00:02:05 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v58VHirspud5 for ; Mon, 29 Aug 2016 00:02:03 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0117.outbound.protection.outlook.com [104.47.0.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DF612D095 for ; Mon, 29 Aug 2016 00:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YV7hUpfeMdILHVdwL04j+sVHB17x2Grbz7+BXvfaM7I=; b=s5SjzNeWSDVcCKNfTEb7QHxt1l7xiWWNYnhsED3X0Ed6p3Y1zW6nhkWVgr540yDQ5i4sbk+yruV2wQlfeNRzYfOByyOwFxt8ZdVRdkhy9X2bpMBIGKXMnYm0Cv5rywrqpQj5h/0CZG7xBdABqyIqJQu9MEb6Vr6IWL8dIwmZdXg= Received: from HE1PR0401CA0022.eurprd04.prod.outlook.com (10.166.116.160) by AMSPR04MB019.eurprd04.prod.outlook.com (10.242.80.19) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Mon, 29 Aug 2016 07:01:59 +0000 Received: from DB3FFO11FD044.protection.gbl (2a01:111:f400:7e04::116) by HE1PR0401CA0022.outlook.office365.com (2a01:111:e400:c512::32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3 via Frontend Transport; Mon, 29 Aug 2016 07:01:59 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD044.mail.protection.outlook.com (10.47.217.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.587.6 via Frontend Transport; Mon, 29 Aug 2016 07:01:59 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 29 Aug 2016 07:01:57 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0549.029; Mon, 29 Aug 2016 07:01:57 +0000 From: "Dijk, Esko" To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2YgZHJhZnQt?= =?utf-8?Q?selander-ace-object-security?= Thread-Index: AQHR9wbv++lBPHlWOkOzRYWQElHdPaBfl1rw Date: Mon, 29 Aug 2016 07:01:57 +0000 Message-ID: <02584d586d1a47339e0fbee714e5f848@HE1PR9001MB0170.MGDPHG.emi.philips.com> References: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> In-Reply-To: <74A76AFB-A354-4FEC-B5FD-89F180DECF9F@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.200.5.4] X-MS-Office365-Filtering-Correlation-Id: f488dec6-0814-4cab-0e83-08d3cfda5f45 Content-Type: multipart/alternative; boundary="_000_02584d586d1a47339e0fbee714e5f848HE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0170.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(85714005)(189002)(374574003)(199003)(55904004)(16236675004)(66066001)(15650500001)(512874002)(24736003)(5660300001)(2420400007)(19625215002)(102836003)(3846002)(8936002)(68736007)(6116002)(790700001)(81166006)(189998001)(87936001)(7110500001)(97736004)(86362001)(5001770100001)(19580405001)(16796002)(107886002)(586003)(81156014)(92566002)(19300405004)(230783001)(11100500001)(106116001)(69596002)(106466001)(108616004)(229383001)(19580395003)(2950100001)(84326002)(15975445007)(2900100001)(356003)(76176999)(7696003)(105586002)(10710500007)(7736002)(101416001)(7846002)(626004)(10400500002)(33646002)(54356999)(50986999)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR04MB019; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD044; 1:br07aJUgZFAWMxw1Ijz2mp24xlEa8+efR2ceQl3AM0cbJZiYGj2b8gYuFwddvWLXv3U/BLnKKmBRoX+1sBfcf6Zmb71N/HAdfJc8Ssp2UJJoMDSWPbCVh3a4neqkmXpvtjiPA5k2g3I86B2fvzOn6uHqdqFHDJixQzHPY1rmv1NrRFeyE3AH0Ss7L1WpYZXcfhSRSbVNJjtSSAuusNul9jIbRvPrGXYz4Vjk6Ey3MVF9cxPCAbl4NSbf9kqGtaISiVSWKYTc2sSPhGeSc18IF0kqhOoaRGhCn2NsuW0FSG0beWDFLaNv47oFb/yZk4fewyCiitz6Z1SQunoExs7ppL2yp1Optb6yc6rj2l9FbqboUVO+NFUWxHsH23UyMDEU5MlX7gAZlF/cYG76FSNsy94mCd0CBjm/SuUj5yCk9NxZjJlYSgIU/FXhfgPptVFxv5ns9c1ddNNigvFs1DqtH91PLCztR0UHfxeL4Ppoonp2LXXyK241CaZBWmmlMcwf X-CrossPremisesHeadersFiltered: DB3FFO11FD044.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB019; 2:pi+zqqmQk1DQ7+nUOnso9U3Ir2i4O6Nb/2rGEW/Sym8BoVSY3E7W6A9s/RTYYjplKYigCw40ZoeV1DOkAGgu40wqAvG3ACDQk7zwEqaia12CEtQ03SINoDnCjrNZV0nGWR9Y6z2XZ1aMOsuWrhfO18w6wTvYd0GtAIRHW8gMRRc6hpS7NpxP2/QtC7vqq4nx; 3:XYY0Z+6BMgrsG6uf6l/MZcRej0JUYusfYKAxk6lU6hyV3wqAteaNaacBfPRHKd0m4rKyv+s3NXYNYehq9ToFyJE0z46wouNS8Zg75zpF/Gmq7iwa3mGbJKmfmNqeJUJybi8+rFby4E9ChPMeYt3sN/CU5jVz6jRuh7dtMiMg5MYc/jRzCOJM1x489+cslHhV+U5LkEYdyXVbOBuR/wq4VU2zMBmuqI6Wg1JnNReZq7k=; 25:Uid3lAuvPUzEUkWMYQnmUQTQaiWO/hVN1F9SkYuB5fJZVznPStgbdk075CHYA4UDJvDVBhYKWuQ9Xga2r7Muu+Vjs4MjREtnHoWyoYtfZaYCSsDQlE0dkbAA++B6L/EnzpMw+9YZxTaAygvgnerQ26ErZRB8o9j8s67SY9pt7AG9HRcy102oibgzWBXaLwnOFncQxcS0DKkkkUqYfMei6s36bbvy6OCsEYr4ohq/TSZDJVmHssjeUGCQd97136XF7PByDxtKJUl44/0TBVOneFQcC72Wlfs7gAwg+yGpwRm8f47hFQztraCDOrWpZMEoSmNcmO5CaovhKm5d4uWVD7ngDxjbqypTVvZMizrtQ7kMmtQGjc8RrFxXyGDmwDEc9RFe/mBXdiWMzUlR/GA1VA5okAwFjC5JFXRKZJbH6FQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR04MB019; X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB019; 31:6LLhjGVGfzXTamF4fxsxXhBE3JeZlyo2VK2zPWZEXluxK6xoHY2Ivkm5yS5mnRFx5dHNpoaFhDJm7Pb7kqOYkVunJEKFVmoRRL96Ty3GiO6KDxy0TzS0NnYe458J/tQkNNgANocaCVnXJasnRAA9tOPZUBHitMgFN580lT2sEai8cbdGiXtE54ohHbe94k753QpYhzabupFhTGtbvwIc8VLolkEeeNQncNoDNh/Uq/8=; 20:qrTJmEIoe73ERq6nkgDqqJjRF773g5bo9EUyyqLNZ1X7vyJ+vptbQcw6mMSH0okRBvW9+h3wxN7nu2nYCWNwO//EDuHtATDWYrB/7lEOVxCiKgjTm6CjagJD6vHvQlMvW50dVAvYP4t3Ht0K2gXaigID3jr1SKWAHe7C3BMkxrqIZBi9jTwldu2sfDJT6UdcPxnjMKx2XknKOmOvuPvl48kJpxO/wa+TDy1w1MW6AAGy+BnmfXRpZ5b6kfOeVPD272Zd4KhcSCOvOxaVkMx4qoWIwoVrRZzXjIy0vdl8Ym5hnQJ4utNGF0HJIb520DQTDNYDQTxRpCnpSUlLBPD3eY//cCw/98H/40yqFcrp36NYZ0hKFAuoJbtVxHTW2aREeAnxEW4Mw2CG/t9R/5yzVzK5HpJcM4ra5905wRZHRWnvRcWOn73mrHdJ1X+f4nE6QMvPGlw7eRkp6BXgmJZdIcVgT8CkotwhSAx5gJahEdEi/o7x+K3KCylZsmJKlR+4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(100405760836317)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13016025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:AMSPR04MB019; BCL:0; PCL:0; RULEID:; SRVR:AMSPR04MB019; X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB019; 4:yiMp0UAzdvy4qjKGGAExnrAs5uWkKJf0K+8ZHRo3lDJ9aeEIODlxh1CBjgwU3mN7aui8JgHNCAVhwRV87GLXj7kmsGXfaA8gI23dOy6q+Gt3WVdwfsqFT0+3xKIaS26/IjG17xNVbGkXtFSww7mGjpM/6GODsdmc3JyjX6egYok0FgCz7w/t6YCz2GhaKx5LtzbFLu8isiyt2rK8U9PQJLaaj0GfNMRBu4GOwATFHc122HR53g0JvXDuCT7VHQWXG6s38j7XIBWsbqoBUWqjkGzmEw7fd3uecSDfR4762/FXumxzdC214ZwUr/LP4HJYGae+QcPgysWMxcBuGlg9nrt08+XNrO9F+Q+tYuvsf3pVpXLQYsN6J7GmznOtW2m7MT2aDUVguy6c+t1C8n9Gn5q6fEzzONTgqMxQWpkpF+XIUDstoOW4w+QjMoxSCe0lK5iOr91dUC74QfHgC6iQYeHFFJTBOrKiGPEsXAKySl/DLo9qTxilFNMSk+XldupftJ4nsCHPsS+YyqOatermP3GU2r7scrScduM1alDp1qoB8KKF/RJq5MH47cLKpVVN X-Forefront-PRVS: 0049B3F387 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR04MB019; 23:tOb6YAHtWL2E2pR3j8IOvY1T2fPDV93hCpAacarazR?= =?us-ascii?Q?ng8iMo6OcIirg1/li8qFLAmqLrnF07bVhkelqyZU6H0HGdCLrUcwpOLFd+gq?= =?us-ascii?Q?NKaGSFDbH9Vp8MLIVdAA/r8KpPViNQbzh/RCGuzW9rIYSiZKOIYf+Y6Ncp+b?= =?us-ascii?Q?DKseRV9u533nH9N0JFW/kUsJPoHV1JePGNKsTHkq+DrkCPkncvG0v2sS9Q8z?= =?us-ascii?Q?5iaZe7xN8TWBRFKWHPu0BnhQyUXXE1RQWnI1AHjAHopVPkTIaejiDQ+3rCw3?= =?us-ascii?Q?l6skiGNDz1jUHwnmAufsUCy5agpuoXPzrHSngsE5VHA3KTFnwng4fWKcVqVs?= =?us-ascii?Q?c5e3E7DSscGZPfsOacu2ASzmf2jXzMh2r8CG68zAii+pyHlM3Re/V7CZ3r2J?= =?us-ascii?Q?6NN92ZOeUmwKTQHTVIJ1PrXX6jEZlkrQUAcqv/3GVzQ373lv1kpJiuSgAzRj?= =?us-ascii?Q?h9ITBVtTOxG29KF+5pecYlA9JoP6KyLUy9WDLP9xBndnxYWbo8hhmzXRO1L1?= =?us-ascii?Q?SJHsonMHKC/p2ijm94N8MGdgdmUpHBTEvpWSB/nWhY1J+NFXkgXWdo9Xf+y5?= =?us-ascii?Q?03IHGh6DXJir60lID4KLEktPuOn6u51R9QTMrlz8l6DMQfjvRcd9S1EtfRAe?= =?us-ascii?Q?1a+g/n1XfctYbgfman8Qdu6slrtesXV1TIvj0M4jhCPbR+YMEYp7HuWjwwb8?= =?us-ascii?Q?JMx0vKkvxxPanD4dvO3hXaYAxgOmG+BFz2ae62fkWOmQuONGsqMB3pg4EJQV?= =?us-ascii?Q?anLbd/vu1At/XQXOr2BGd2dZ7/0J5POBDxO78QiptgoCQp0MAVlpb0STPMkE?= =?us-ascii?Q?UI6YbSPdXsX3MyavgogPs+IE+4H9Q1HcoIoVgZ+ZAXF3wDYtT+zF80ox4Tkd?= =?us-ascii?Q?njhjVwZpFW317V9YflFHgckibjkNQYKo1IbwUO3ckfjPEMDWOwjM9WAoZRvS?= =?us-ascii?Q?OpGKnuILz67SAO2KTijjgpHrrDclwg4Tv0Jsf3Y+lQm6rP0LCoi0/nYuD5lb?= =?us-ascii?Q?mTz/DFS7T470rXQGPbKb3sNZI3oaVHyg3i9NI8I8xZ81zSGdVNgvQ0cwD2Qa?= =?us-ascii?Q?yFrVe7dQ+8vyrJT31CxvfNoiIsFWtzJ6/F0g+pYTbMeymWrS4udOySl3XvNT?= =?us-ascii?Q?bAUw0URYM86qMz7WZma2ADJHdMV3aTCK427yfndcGdRiaAMqpITZEDStKXTU?= =?us-ascii?Q?Jllart5hgncWqi8TEK+YpUjuY3bYDMD4Q+FQwpaSqhWWIlggkePmWaeDVPmP?= =?us-ascii?Q?FwjrU1jnjVfbbs8sPRmNoFG5XLOEja0XJePuYjjbd97d2zX8mEkjfTn9xnot?= =?us-ascii?Q?jjEVDx7hbmwugxa0Mca1qI9wm72w3U9w3i0FwMoSG6liZOZJT13j7NIcskNu?= =?us-ascii?Q?B0P3BfJagjTUSxfP85ereS7JhgASLEU0H5I3nIQWqdjBlpOCzOUpzidKMLZE?= =?us-ascii?Q?eZ/r+9St5TrFZqHZAWEzRGHlrvU8CK7MNp+qh8gM6mZQb+Dwxly0Uqg6cwAx?= =?us-ascii?Q?X/lkGsAhobOnDJhkAJ9NpGG3DhUwgGJfk3b4B8hayqd6F191BEWZESghRZmR?= =?us-ascii?Q?tkczRZDGZJdPk3Vo2PTFgTrhoLhE7NoD88SFU=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB019; 6:v9ULldY6SGckr/GSyrd28MPS/TsgD3ZoXqKfXwRbZZSYWdNEE4VYxBk0rhC2z95WqiVJxN6Gx/bI5axCJmNPgvpjrEBgnnaS4n5XT9qhdeRF7NWCv4uxqvzwR1l813K9WAgmacH+0oy74pod0RzfymaaCXmgb/IauaMWljq4Tno1uNHUy+2Se+kXZ8wcP02TgrBUFtA5D/XNen63pJUU0HyTaspep2uWju821Zomukw3nqY0M5TrMJJW91Yd1ATmEjw6XvkVlLQDLGjS+2FZppmRETZ8V8Q+hq7TmOIu3xxWT6/QB33G5o68kgluVLYzMPRI6BQNcdkvUNloh2B6Tg==; 5:2yx7c86P8f19bkKFqWrmwekkWdhs/l40IZRcTKahISKSFwueBFJHK7QCrjalAaM8RQLoRAeq5OGZI5oX4W0ji/T8+xURqb55dnC7XINlQ0AkARfxTxm8Knbznksrhq9K22dnLzEj6+tBz+/HMfTuZg==; 24:ftj/RZFV3BsET+aRXysPI1RprWI3PPRTfmKobiovYopTBjMG2jKHc1oR8xSWjxUAOqanQ/sec9Jw13ULJKoRlHLv3muLUJWXfMvgJvTRqNU=; 7:YmfHCiB9Z//l9MqhIhTBa5Sti8fA7LzvhFAQXQAqPLXTpUIufZstZXz9FmOZOsxOdwmBtxTs9zfZGBhOAkPPjbDevg1W5XGxe8Lpy3X12QBbdqMifZGpKcPbGLF9ASjZo1fOM3pNR0uSiIVQdLyl4V8KSC5r9uirPXcddvkSf+RGZucOR6yxofMXsp2IwVRSIVV906WNXAvGkiIbg+kp6DEppeNg/uOgnw/OQ1yxjSwRMbT0sF2cXbc7s3IHme1J SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2016 07:01:59.5993 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR04MB019 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 23.103.247.132 X-MS-Exchange-CrossPremises-AuthSource: DB3FFO11FD044.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: AMSPR04MB019.eurprd04.prod.outlook.com Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-sel?= =?utf-8?q?ander-ace-object-security?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 07:02:05 -0000 --_000_02584d586d1a47339e0fbee714e5f848HE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgICBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYmVjYXVzZSBpdCB3aWxs IGJlIHVzZWZ1bCBhcyBhIGdlbmVyaWMgd2F5IHRvIHByb3ZpZGUgc2VjdXJpdHkgaW4gdmFyaW91 cyBzaXR1YXRpb25zIHdoZXJlIENvQVAgaXMgdXNlZCBidXQgRFRMUyBtYXkgbm90IHdvcmsuIFRo aW5raW5nIG9mIG11bHRpY2FzdCwgcHJveGllZCBDb0FQIGNvbW11bmljYXRpb24sIFB1YlN1YiBh bmQgc2xlZXB5IGRldmljZXMuDQoNCmJlc3QgcmVnYXJkcw0KRXNrbw0KDQpGcm9tOiBjb3JlIFtt YWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFpbWUgSmltw6luZXoN ClNlbnQ6IE1vbmRheSwgQXVndXN0IDE1LCAyMDE2IDE3OjA5DQpUbzogY29yZUBpZXRmLm9yZyBX RyA8Y29yZUBpZXRmLm9yZz4NCkNjOiBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5 QGlldGYub3JnDQpTdWJqZWN0OiBbY29yZV0g8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIG9m IGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkNCg0KRGVhciBDb1JFLVdHLA0KDQpB cyB3ZSBkaXNjdXNzZWQgYXQgbGFzdCBJRVRGOTYsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFz IGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LiBB dCB0aGUgSUVURiBtZWV0aW5nIHRoZSByb29tIGNvbnNlbnN1cyB3YXMgc3Ryb25nbHkgc3VwcG9y dGluZyBhZG9wdGlvbiAoMTAtMTIgcGVvcGxlKS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdp dGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRo ZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxs eSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQoNClNpbmNlIHRoZXJlIGFyZSBzZXZlcmFsIGNvbmN1 cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBBdWd1c3QgMjYsIDIwMTYu DQoNClRoYW5rcywNCkphaW1lIGFuZCBDYXJzdGVuDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1h eSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUg bGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocyku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K --_000_02584d586d1a47339e0fbee714e5f848HE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+JiM0MzsxJm5ic3A7Jm5i c3A7IEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBiZWNhdXNlIGl0IHdpbGwg YmUgdXNlZnVsIGFzIGEgZ2VuZXJpYyB3YXkgdG8gcHJvdmlkZSBzZWN1cml0eSBpbiB2YXJpb3Vz IHNpdHVhdGlvbnMgd2hlcmUgQ29BUCBpcyB1c2VkIGJ1dCBEVExTIG1heSBub3Qgd29yay4gVGhp bmtpbmcNCiBvZiBtdWx0aWNhc3QsIHByb3hpZWQgQ29BUCBjb21tdW5pY2F0aW9uLCBQdWJTdWIg YW5kIHNsZWVweSBkZXZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5iZXN0IHJlZ2FyZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVza288 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYWltZSBKaW3DqW5lejxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIEF1Z3VzdCAxNSwgMjAxNiAxNzowOTxicj4NCjxiPlRvOjwvYj4gY29yZUBp ZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LXNl bGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W2NvcmVdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjgyNzY7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gb2YgZHJhZnQtc2VsYW5kZXIt YWNlLW9iamVjdC1zZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgQ29SRS1XRyw8YnI+DQo8YnI+DQpBcyB3ZSBkaXNjdXNzZWQgYXQgbGFz dCBJRVRGOTYsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBk cmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LiBBdCB0aGUgSUVURiBtZWV0aW5nIHRo ZSByb29tJm5ic3A7Y29uc2Vuc3VzIHdhcyBzdHJvbmdseSBzdXBwb3J0aW5nIGFkb3B0aW9uICgx MC0xMiBwZW9wbGUpLiZuYnNwO1BsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29t bWVudHMsIGluY2x1ZGluZw0KIGFsdGhvdWdoIG5vdCZuYnNwO2xpbWl0ZWQgdG8gd2hldGhlciBv ciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5Jm5i c3A7ZW5jb3VyYWdlZCB0byBjb21tZW50Ljxicj4NCjxicj4NClNpbmNlIHRoZXJlIGFyZSBzZXZl cmFsIGNvbmN1cnJlbnQgV0dBIGNhbGxzLCB3ZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiZuYnNwOzxi PkF1Z3VzdCAyNiwgMjAxNjwvYj4uPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkphaW1lIGFuZCBD YXJzdGVuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9 IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQg dW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCiB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3Nl bWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS48YnI+DQo8L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_02584d586d1a47339e0fbee714e5f848HE1PR9001MB0170MGDPHGem_-- From nobody Mon Aug 29 00:18:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB06112D095 for ; Mon, 29 Aug 2016 00:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5orz2ylzifdy for ; Mon, 29 Aug 2016 00:18:50 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AB1127071 for ; Mon, 29 Aug 2016 00:18:49 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud2.xs4all.net with ESMTP id cvJm1t00L4VN29601vJmvJ; Mon, 29 Aug 2016 09:18:46 +0200 Received: from 2001:983:a264:1:4101:4012:4a40:4640 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 29 Aug 2016 09:18:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 29 Aug 2016 09:18:46 +0200 From: peter van der Stok To: Alexander Pelov Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <39F2F14C-8D8B-4B0E-B091-AA1EB1DEE255@ackl.io> References: <201608250324.u7P3OTAI005926@mainfs.snmp.com> <39F2F14C-8D8B-4B0E-B091-AA1EB1DEE255@ackl.io> Message-ID: <02d7c5805f4090c732c46913c8e53994@xs4all.nl> X-Sender: stokcons@xs4all.nl (avw1ne+WX/W89z+/Ytfa0uLh/WlJpgCW) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] draft-bierman-core-yid-00.txt questions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 07:18:51 -0000 Alexander Pelov schreef op 2016-08-25 18:14: > Hi Andy, > >> Le 25 août 2016 à 18:02, Andy Bierman a >> écrit : >> >> On Thu, Aug 25, 2016 at 8:54 AM, Michel Veillette >> wrote: >> >>> Hi Andy, Hi David >>> >>> There is no requirement to have multiple tools or algorithms >>> producing the same result. >> >> Then it isn't auto-numbering. >> It is just an offline tool to assign numbers to YANG statements. > > It is a way to assign numbers… automatically. Auto-numbering. > >> So there is no need to standardize SID at all. >> There is just a list of [id, path] mappings in a registry entry, >> which is what the YID draft proposes. (centralized or distributed >> list of mappings). > > I think we agree here. I am also convinced there is much overlap in the SID and YID drafts The conclusions by Alexander are a bit fast for me. What happened to the discussion about module number reservation against SID range reservation? I don't think the strains on IANA (enormous or not) are an issue, but the strains on the module writers and what rules they are willing to follow. For me it is the process of establishing identifiers, with a discussion about freedom of choice to companies, and scopes of inter-operability (world-wide, SDO wide,--), that is central here. The YID draft proposes a subset of what can be > achieved by the SID draft. The YID draft proposes a more complex > process, which does not ensure interoperability, and which puts > enormous strain on IANA, with no description of how a more generic > system will work. > > Everything you can do with YID you can do with SID. Not everything you > can do with SID can be achieved with YID. > SID is simpler. > SID cares for ID exhaustion. > SID has running code. > From nobody Mon Aug 29 04:54:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6237412D105 for ; Mon, 29 Aug 2016 04:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqAKXFUEYWw9 for ; Mon, 29 Aug 2016 04:54:36 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 0D20112D686 for ; Mon, 29 Aug 2016 04:54:34 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id u7TBsWbu025778 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 Aug 2016 13:54:32 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u7TBsVUW002851 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Aug 2016 13:54:31 +0200 Received: from DEFTHW99ERFMSX.ww902.siemens.net (139.22.70.67) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 29 Aug 2016 13:54:31 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.119]) by DEFTHW99ERFMSX.ww902.siemens.net ([139.22.70.67]) with mapi id 14.03.0301.000; Mon, 29 Aug 2016 13:54:30 +0200 From: "Kovatsch, Matthias" To: "consultancy@vanderstok.org" Thread-Topic: AW: [core] Resource Directory: Use of /rd in path Thread-Index: AQHR8jWdVFusBz/r3kCJoP4E2R18NqBAaRAAgAFk3ICAACPVAIAAQ0uAgAD46ICAB+2+gIABDd4AgA8In9CABE2AgIAAb6Pg Date: Mon, 29 Aug 2016 11:54:30 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C0186B114@DEFTHW99EL4MSX.ww902.siemens.net> References: <57A9C906.3060704@tzi.org> <009c0ecec6c3624520949baa9cccf554@xs4all.nl> <57AB1270.3060801@tzi.org> <5203ff84277d159fc214d8ccfa91bdf9@xs4all.nl> <9cf6e5c673abbbbe60e0d6771656f3cc@xs4all.nl> <630F13BF-E488-4334-9EAB-50AF3C2E539F@gmail.com> <4EBB3DDD0FBF694CA2A87838DF129B3C0186889F@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Resource Directory: Use of /rd in path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 11:54:38 -0000 RGVhciBQZXRlcg0KDQo+IFVuZGVyc3Rvb2QgeW91ciBzdWdnZXN0aW9uIGZvciB0aGUgaW5kaXZp ZHVhbCBlbnRyeSBwb2ludHMuDQo+IEJ1dCBob3cgdG8gY2FsbCB0aGUgc2V0IG9mIHJlbGF0ZWQg ZW50cnkgcG9pbnRzIFVSSS9yZXNvdXJjZT8NCg0KSSB3b3VsZCBzYXkgd2UgaGF2ZSB0aHJlZSBS RVNUZnVsIHNlcnZpY2VzIHdpdGggbXVsdGlwbGUgcmVzb3VyY2VzIGVhY2g6DQoNCi0gcmVnaXN0 cmF0aW9uIHNlcnZpY2Ugd2l0aCByZWdpc3RyYXRpb24gcmVzb3VyY2VzDQotIGxvb2t1cCBzZXJ2 aWNlIHdpdGggbG9va3VwIHJlc291cmNlcw0KLSBncm91cCBtYW5hZ2VtZW50IHNlcnZpY2Ugd2l0 aCBncm91cCAobWFuYWdlbWVudCkgcmVzb3VyY2VzDQoNCj4gQlRXIGl0IGlzIHBvc3NpYmxlIHRv IGRlZmluZSBhYmJyZXZpYXRpb25zIG9yIGFjcm9ueW1zIGluIHRoZSBiZWdpbm5pbmcgb2YgdGhl DQo+IGRvY3VtZW50OyBzbyB0aGF0IHdvdWxkIGJlICJzZXJ2aWNlIGVwIFVSSS9yZXNvdXJjZSIg b3IgZXZlbiBzaG9ydGVyPw0KDQpXZSBuZWVkIHRvIGJlIGNhcmVmdWwgd2l0aCAiZXAiIHdoaWNo IHByaW1hcmlseSBzdGFuZHMgZm9yIGVuZHBvaW50IGluIENvUkUuDQoNClRoZSB3aG9sZSBuYW1p bmcgd2l0aCAiZnVuY3Rpb24gc2V0cyIgY2FtZSBmcm9tIHRoZSB0aWdodCByZWxhdGlvbiB3aXRo IHRoZSBlYXJseSBkYXlzIG9mIElQU08gT2JqZWN0cyB3aGVuIFphY2ggd2FzIGhpZ2hseSBhY3Rp dmUgaW4gYWxsIG9mIHRoaXMuIFRoZSBsb25nLXRlcm0gZ29hbCBpcyBjb25zdHJhaW5lZCBSRVNU ZnVsIGVudmlyb25tZW50cywgdGh1cyBJIHdvdWxkIHN0aWNrIHdpdGggUkVTVGZ1bCBXZWIgc2Vy dmljZSB0ZXJtaW5vbG9neS4gV2hlbiB3ZSBpbnRyb2R1Y2UgdGhlIFJEIHRvIHByb3ZpZGUgdGhy ZWUgUkVTVGZ1bCBXZWIgc2VydmljZXMgZm9yIHJlZ2lzdHJhdGlvbiwgbG9va3VwLCBhbmQgZ3Jv dXAgbWFuYWdlbWVudCwgdGhlIGV4cGxhbmF0aW9ucyB3aXRoIGVudHJ5IHBvaW50cyBmb3IgZWFj aCBvZiB0aGVzZSBzZXJ2aWNlcywgd2hpY2ggaW4gdHVybiBjb25zaXN0IG9mIGEgbnVtYmVyIG9m IHNlcnZpY2Utc3BlY2lmaWMgcmVzb3VyY2VzLCB3aWxsIGJlY29tZSBjbGVhcmVyIGFuZCBtb3Jl IHNlbGYtZXhwbGFuYXRvcnkuDQoNClRvIG1ha2UgdGhpcyByZWFsbHkgdmlhYmxlIGFuZCBmdXR1 cmUtcHJvb2YsIHdlIG5lZWQgdG8gcHJvdmlkZSBsaW5rcyBhbmQgZm9ybXMgYXQgdGhlIGVudHJ5 IHBvaW50IFVSSXMgaW4gdGhlIGZ1dHVyZSAoaS5lLiwgcmV0dXJuIHRoZW0gd2hlbiBkb2luZyBh IEdFVCBvbiB0aGVzZSByZXNvdXJjZXMpLiBGb3IgdGhpcywgd2Ugc3RhcnRlZCB0aGUgIlJlc291 cmNlIGRpcmVjdG9yeSBldm9sdXRpb24iIHRocmVhZCBhIHdoaWxlIGFnby4NCg0KQ2lhbw0KTWF0 dGhpYXMNCg0KPiANCj4gUGV0ZXINCj4gDQo+IEtvdmF0c2NoLCBNYXR0aGlhcyBzY2hyZWVmIG9w IDIwMTYtMDgtMjYgMTM6MTk6DQo+ID4gSGkNCj4gPg0KPiA+IE15IHN1Z2dlc3Rpb246IFRoZXNl IGFyZSB0aHJlZSBkaWZmZXJlbnQgUkVTVGZ1bCBzZXJ2aWNlIGVudHJ5IHBvaW50cy4NCj4gPiBT byBkZXBlbmRpbmcgb24gd2hhdCBleGFjdGx5IHdlIGFyZSB0YWxraW5nIGFib3V0LCB3ZSBoYXZl Og0KPiA+DQo+ID4gLSBlbnRyeSBwb2ludCBVUkkgKGUuZy4sIGNvYXA6L3JkLmV4YW1wbGUuY29t L3JkKQ0KPiA+IC0gZW50cnkgcG9pbnQgcmVzb3VyY2UgKGUuZy4sIC9yZCBvZiBhIHNwZWNpZmlj IHNlcnZlcikNCj4gPg0KPiA+IEEgbW9yZSBleHBsaWNpdCB2ZXJzaW9uIHdvdWxkIGJlIHRvIGNh bGwgaXQgInNlcnZpY2UgZW50cnkgcG9pbnQNCj4gPiBVUkkvcmVzb3VyY2UiIGFsbCB0aGUgdGlt ZS4NCj4gPg0KPiA+IENpYW8NCj4gPiBNYXR0aGlhcw0KPiA+DQo+ID4+IC0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPj4gVm9uOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2Vz QGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBNaWNoYWVsDQo+ID4+IEtvc3Rlcg0KPiA+PiBHZXNl bmRldDogTWl0dHdvY2gsIDE3LiBBdWd1c3QgMjAxNiAwMTo0Mg0KPiA+PiBBbjogY29uc3VsdGFu Y3lAdmFuZGVyc3Rvay5vcmcNCj4gPj4gQ2M6IGNvcmVAaWV0Zi5vcmcgV0cNCj4gPj4gQmV0cmVm ZjogUmU6IFtjb3JlXSBSZXNvdXJjZSBEaXJlY3Rvcnk6IFVzZSBvZiAvcmQgaW4gcGF0aA0KPiA+ Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gV2UgZGVmaW5lIHRocmVlICJmdW5jdGlvbiBzZXRzIiBp biBSRC4gVGhleSBhcmUgUmVnaXN0cmF0aW9uDQo+ID4+IChydD1jb3JlLnJkKSwgTG9va3VwDQo+ ID4+IChydD1jb3JlLnJkLWxvb2t1cCkgYW5kIEdyb3VwIChydD1jb3JlLnJkLWdyb3VwKS4gRWFj aCBvZiB0aGVzZSBoYXMNCj4gPj4gYW4gQVBJIGVudHJ5IFVSSSB0aGF0IHdlIHN1Z2dlc3QgY29u dmVudGlvbmFsIHVzYWdlIG9mIC9yZCwNCj4gPj4gL3JkLWxvb2t1cCwgYW5kIC9yZC1ncm91cA0K PiA+Pg0KPiA+PiBXaGF0ZXZlciB3ZSBkbyB0byBpbXByb3ZlIHRoZSB0ZXJtaW5vbG9neSBmcm9t ICJmdW5jdGlvbiBzZXQiIHRvDQo+ID4+ICJSRVNUIEFQSSBlbnRyeSBwb2ludCIgb3Igd2hhdGV2 ZXIgd2UgY2hvb3NlLCBpdCBuZWVkcyB0byBiZSBkb25lDQo+ID4+IGNvbnNpc3RlbnRseSBpbiB0 aGUgZG9jdW1lbnQgZm9yIGFsbCAzIGNhc2VzLg0KPiA+Pg0KPiA+PiBJIGRvbid0IHRoaW5rICJj b250YWluZXIgcGF0aCIgaXMgbmVjZXNzYXJpbHkgYSBiZXR0ZXIgY2hvaWNlLg0KPiA+Pg0KPiA+ PiBIYW5uZXMsIENhcnN0ZW4sIGFueW9uZSwgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9uIGZvciB3 aGF0IHdlIHNob3VsZA0KPiA+PiBjYWxsIHRoZXNlIGRpZmZlcmVudCBBUEkgZW50cnkgcG9pbnRz Pw0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+DQo+ID4+IE1pY2hhZWwNCj4gPj4NCj4g Pj4NCj4gPj4gPiBPbiBBdWcgMTYsIDIwMTYsIGF0IDEyOjM1IEFNLCBwZXRlciB2YW4gZGVyIFN0 b2sgPHN0b2tjb25zQHhzNGFsbC5ubD4NCj4gd3JvdGU6DQo+ID4+ID4NCj4gPj4gPiBIaSBIYW5u ZXMsIENhcnN0ZW4sDQo+ID4+ID4NCj4gPj4gPiBJIHdpbGwgcHJvdmlkZSBhIHBocmFzZSBpbiB0 aGUgUkQgZHJhZnQgdGhhdCB0aGUgdXNlIG9mIHRoZSBwYXRoDQo+ID4+ID4gIi9yZCIgaW4gYWxs DQo+ID4+IGV4YW1wbGVzIGlzIHRoZSBjb252ZW50aW9uIHVzZWQgZm9yIHRoZSBSRCBwYXRoIGlu IHRoaXMgZHJhZnQuDQo+ID4+ID4NCj4gPj4gPiBDb25jZXJuaW5nIHRoZSB0ZW1wbGF0ZSBJIHBy b3Bvc2U6DQo+ID4+ID4NCj4gPj4gPiByZCA6PSAgUkQgRnVuY3Rpb24gU2V0IHBhdGggKG1hbmRh dG9yeSkuICBUaGlzIGlzIHRoZSBwYXRoIG9mIHRoZQ0KPiA+PiA+ICAgICAgUkQgRnVuY3Rpb24g U2V0LCBhcyBvYnRhaW5lZCBmcm9tIGRpc2NvdmVyeS4gIFRoZSB2YWx1ZSAicmQiDQo+ID4+ID4g aXMgdXNlZCBhcyBhbiBleGFtcGxlIHZhbHVlIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudA0KPiA+ PiA+DQo+ID4+ID4gYW5kIGFzIGEgc2lkZToNCj4gPj4gPiBSZXBsYWNlIFJEIEZ1bmN0aW9uIFNl dCBwYXRoIGJ5OiBSRCBjb250YWluZXIgcGF0aD8NCj4gPj4gPg0KPiA+PiA+IEdyZWV0aW5ncywN Cj4gPj4gPg0KPiA+PiA+IFBldGVyDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IEhhbm5lcyBUc2No b2ZlbmlnIHNjaHJlZWYgb3AgMjAxNi0wOC0xMSAwODozMToNCj4gPj4gPj4gSGkgUGV0ZXIsDQo+ ID4+ID4+IEkgb25seSB3YW50IHRvIGhhdmUgY2xhcmlmeSB3aGF0IHVzZSBvZiAvcmQgaXMgdGhl cmUgaW4gdGhlDQo+ID4+ID4+IGV4YW1wbGVzIGJlY2F1c2Ugb2YgdGhlIHJlY29tbWVuZGF0aW9u IGFuZCB3aGF0IGhhcyBiZWVuIGNob3NlbiBmb3INCj4gY29udmVuaWVuY2UuDQo+ID4+ID4+IENp YW8NCj4gPj4gPj4gSGFubmVzDQo+ID4+ID4+IE9uIDA4LzEwLzIwMTYgMDU6NDAgUE0sIHBldGVy IHZhbiBkZXIgU3RvayB3cm90ZToNCj4gPj4gPj4+IEhpIENhcnN0ZW4sDQo+ID4+ID4+PiBUaGFu a3MgZm9yIHRoZSBzdWdnZXN0aW9ucywgYnV0IHRoZSBjaGFuZ2VzIGRvIG5vdCBsb29rIHRoYXQN Cj4gPj4gPj4+IGVzc2VudGlhbCBmb3IgdGhlIGl0ZXJvcGVyYWJpbGl0eSBhbmQgaW1wbGVtZW50 YXRpb24gdG8gbWUuDQo+ID4+ID4+PiBJIHdvdWxkIHByZWZlciB0byBnZXQgdGhlIGRyYWZ0IG91 dCBhcyBpcy4NCj4gPj4gPj4+IEhhbm5lcyB0aGlua3MgZGlmZmVyZW50bHk/DQo+ID4+ID4+PiBQ ZXRlcg0KPiA+PiA+Pj4gQ2Fyc3RlbiBCb3JtYW5uIHNjaHJlZWYgb3AgMjAxNi0wOC0xMCAxMzoz OToNCj4gPj4gPj4+PiBwZXRlciB2YW4gZGVyIFN0b2sgd3JvdGU6DQo+ID4+ID4+Pj4+IEhpIENh cnN0ZW4sDQo+ID4+ID4+Pj4+IERvIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhhdCB5b3UgcmVj b21tZW5kIHRvIGtlZXAgdGhlDQo+ID4+ID4+Pj4+IGN1cnJlbnQgdGVtcGxhdGUgd29yZGluZz8N Cj4gPj4gPj4+Pj4gVVJJIFRlbXBsYXRlOiAgL3srcmR9ez9lcCxkLGV0LGx0LGNvbn0NCj4gPj4g Pj4+Pj4gICBVUkkgVGVtcGxhdGUgVmFyaWFibGVzOg0KPiA+PiA+Pj4+PiAgICAgIHJkIDo9ICBS RCBGdW5jdGlvbiBTZXQgcGF0aCAobWFuZGF0b3J5KS4gIFRoaXMgaXMgdGhlIHBhdGggb2YgdGhl DQo+ID4+ID4+Pj4+ICAgICAgICAgUkQgRnVuY3Rpb24gU2V0LCBhcyBvYnRhaW5lZCBmcm9tIGRp c2NvdmVyeS4gIEFuIFJEIFNIT1VMRA0KPiB1c2UNCj4gPj4gPj4+Pj4gICAgICAgICB0aGUgdmFs dWUgInJkIiBmb3IgdGhpcyB2YXJpYWJsZSB3aGVuZXZlciBwb3NzaWJsZS4NCj4gPj4gPj4+PiBN YXliZSBhIGJldHRlciB3b3JkaW5nIG9mIHRoZSBsYXN0IHNlbnRlbmNlIHdvdWxkIGJlOg0KPiA+ PiA+Pj4+IEFzIGEgY29udmVudGlvbiB0aGF0IGFpZHMgaW4gZGVidWdnaW5nLCBhIHNlcnZlciBj YW4gdXNlIHRoZSB2YWx1ZSAicmQiDQo+ID4+ID4+Pj4gdW5sZXNzIGl0IHByZWZlcnMgYSBkaWZm ZXJlbnQgdmFsdWUuDQo+ID4+ID4+Pj4gR2V0cyByaWQgb2YgdGhlIFNIT1VMRCwgYW5kIG1ha2Vz IGl0IGNsZWFyIHRoZSB0aGUgc2VydmVyIGlzDQo+ID4+ID4+Pj4gZnJlZSB0byBjaG9vc2UgKGFz IHBlciBSRkMgNzMyMCkuDQo+ID4+ID4+Pj4gKEFuZCBtYXliZSB3ZSBjYW4gZ2V0IHJpZCBvZiAi RnVuY3Rpb24gU2V0IiBpbiBhIHNlcGFyYXRlDQo+ID4+ID4+Pj4gZWZmb3J0LikgR3LDvMOfZSwg Q2Fyc3Rlbg0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+PiA+IGNvcmVAaWV0 Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gPj4gY29yZUBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Tue Aug 30 03:35:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0FE12D0AD for ; Tue, 30 Aug 2016 03:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_ZtUXVfpP6X for ; Tue, 30 Aug 2016 03:34:59 -0700 (PDT) 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 C129912B071 for ; Tue, 30 Aug 2016 03:34:58 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.213]) by smtp-cloud3.xs4all.net with ESMTP id dNav1t00H4bqPqS01Nav2w; Tue, 30 Aug 2016 12:34:55 +0200 Received: from 2001:983:a264:1:8f4:53cc:1d42:89a9 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 30 Aug 2016 12:34:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 30 Aug 2016 12:34:55 +0200 From: peter van der Stok To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <7a8be541c4221523f0f6606d2b06164f@xs4all.nl> X-Sender: stokcons@xs4all.nl (NWUwRLHssryMuvgh6tkjNO4P3A6YBnzk) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-koster-core-coap-pubsub@ietf.org, "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-kos?= =?utf-8?q?ter-core-coap-pubsub?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 10:35:00 -0000 Hi Michael, I do support the draft, but have some questions after a first reading. section 4 before 4.1; the operations are the functions? In the discover section 4.1 the base location /ps is nowhere returned, only in the example this becomes clear. Is this base /ps compulsory? In the resource directory the base location is returned and the value /rd is recommended. Would it not be better to recommend the value /ps here as well? Does the resource type core.ps need to be declared to IANA? The concept of "link to it's pubsub function set" is a bit complex for me; why not write /.well-known/core and /ps Otherwise I recommend to introduce the "link to the pubsub function set" in section 2. In section 4.2 Create. If I understand correctly, "CREATE" creates a resource at the broker with path name /ps/topic Why not describe it like that? I do have problems with understanding what the value of the created resource is. Is that a list of messages, or is that a set of named values described in the messages. That is important to understand the most recent published value of a topic. The content format of a the messages belonging to a topic is specified, but its contents is free. Suppose a topic uses content formats application/json and application/merge-patch+json Suppose two messages arrive at the broker First message: application/json with {"name" : "topic1", "value" : 10} Second message: application/merge-patch+json with {"name" : "topic2"} The content of the last message to subscribers is clear; but what does the READ return; Should that be {"name" : "topic2", "value" : 10} or {"name" : "topic2"}, or both messages? The answer is important with respect to section 6. My personal preference is that the value of a pubsub resource is a set of messages. Greetings, peter From nobody Tue Aug 30 11:42:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB712D878; Tue, 30 Aug 2016 11:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYf_zEvOysuJ; Tue, 30 Aug 2016 11:42:06 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BA112D7BB; Tue, 30 Aug 2016 11:42:01 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id x131so181920664ite.0; Tue, 30 Aug 2016 11:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EDSQk6w+QHXrV2E7i7TDIEoNYZU1kJrLdi8puFcIIjE=; b=EXwL7ISGXNBqMjHO+MY8rKEWqE2M3796Omx1xWUHWQ5hqOvWw2yYxfpY964dOksvgj CA9scEmUNGPxVAcOIqn4H7kwMrJg7l0q0bXbfIgE3tzIm2hWxy9SpQmymkk94Xs1kuAo FyhkqVBC9CxeRhlWECS6JN3W2EvtxjIzCHMHFrapqWhQp4cZh7dET2Xn8xnam3vvIwUA u04V92ZHpOyLrLMowyfLJB/hX+M/vYGYWp/db+u08B6D5UM1nvrKyW1NBGMn832WCsK/ Ti/QgqV3nWiErb0l4BJOXBCcCixjtVILp4dITz3pPZRJQ+X7W2zYIQNhIMnVkl9L0+VG AJ4g== 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:from:date :message-id:subject:to:cc; bh=EDSQk6w+QHXrV2E7i7TDIEoNYZU1kJrLdi8puFcIIjE=; b=VjFG6ClEbeqO80UbJ8/YJGraMrMgkszahXg3UxsCF47ve1fa/PtYsQe3rYTJBUnOH1 xF3DchL7H2ixRW6vE3qiG4Zs+z2r5jpSufsKvcBVfUxS4p2ZREOQ0nZBzHPff9kQLiuK 3+jBRCUpc5++M6PQTrcip6RCVMADOwvE+9ykbrP/5vGkm0yPSOpMxnO4hICYsmKDGcIt mXr9uhTpN/HNOXIt6Dm7wbXyNd5KvQCWDr7HBF17flcTxuF+qO3xltNH3tOCij2prh3x 3eAViNhSsNgX1jTYqAUgmB2VtvrNN/C5xcxFt2D7GP3E46+1Dbj7GlrYbBgxYDNCv5g5 LCKA== X-Gm-Message-State: AE9vXwNUcrUQTHESVOOyqmu8c9Mq2VRc8uDzW8hZzG/ijp8tXXrcUC2yXZgwwfq7jzZUdmaTsFLgoTYHBmXEEA== X-Received: by 10.36.190.197 with SMTP id i188mr5974550itf.92.1472582514982; Tue, 30 Aug 2016 11:41:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.132.129 with HTTP; Tue, 30 Aug 2016 11:41:54 -0700 (PDT) In-Reply-To: References: From: James Nguyen Date: Tue, 30 Aug 2016 14:41:54 -0400 Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Content-Type: multipart/alternative; boundary=94eb2c0dee30b566fb053b4e55da Archived-At: Cc: "draft-koster-core-coap-pubsub@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-kos?= =?utf-8?q?ter-core-coap-pubsub?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 18:42:08 -0000 --94eb2c0dee30b566fb053b4e55da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I support this I-D as I think it's useful. I have a question. Section 3.5 Brokerless pubsub - I suggest to move this section to section 3.1. - This architecture is more applicable to CoAP Proxy. - I also suggest to add the pubsub capability at CoAP Proxy. James On Mon, Aug 15, 2016 at 11:10 AM, Jaime Jim=C3=A9nez wrote: > Dear CoRE-WG, > > As we discussed at last IETF96, working group adoption has been requested > for draft-koster-core-coap-pubsub. At the IETF meeting the room consensus > was strongly supporting adoption (~10 people). Please reply to the list > with your comments, including although not limited to whether or not you > support adoption. Non-authors are especially encouraged to comment. > > Since there are several concurrent WGA calls, we will end the call on *Au= gust > 26, 2016*. > > Thanks, > Jaime and Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --94eb2c0dee30b566fb053b4e55da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I support this I-D as= I think it's useful.=C2=A0

I have a question.

Section 3.5 Brokerless pubsub

- I suggest to move this sect= ion to section 3.1.
=C2=A0
- This architecture is more appl= icable to CoAP Proxy.=C2=A0

- I also suggest to add the = pubsub capability at CoAP Proxy.

James


On Mon, Aug 15, 2016 at 11:10 AM, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been requested f= or draft-koster-core-coap-pubsub. At the IETF meeting the room=C2=A0consens= us was strongly supporting adoption (~10=C2=A0people).=C2=A0Please reply to= the list with your comments, including although not=C2=A0limited to whether=C2=A0or not you support adoption. Non-authors = are especially=C2=A0encouraged to comment.

Since there are several concurrent WGA calls, we will end the call on=C2=A0= August 26, 2016.

Thanks,
Jaime and Carsten


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




--
James Nguyen
Email: james.huy.nguyen= @gmail.com
--94eb2c0dee30b566fb053b4e55da-- From nobody Tue Aug 30 17:16:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FDC12D854; Tue, 30 Aug 2016 17:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWzV9atjdayE; Tue, 30 Aug 2016 17:16:09 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 17E8B12D849; Tue, 30 Aug 2016 17:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DTGAmoht7EltXwWbwfBIk2SMC0HL/45jH7xwpPCU5cc=; b=HhvLEMWkt16mv2JjThKUIgsojX MgIf0+U95+q8NAuNOS3XYPhhq2m3HpOTvfVyIVM16MVtpPvkgC+C75nATjz8xILbMvwWJieW3I3vD CXdIcBhBJvTWPHR+lTrxg7D5uS0BhBdcNGRk3BHWL1CtEkMuMuovCYrxVeozmzKA/ov1UyHWim+Iv R/pCMC0hkbhZAodrzL9fBVBWpn9yS4jgohvI2CltaFaiuI2gum6khhtBfPhjKLhxGwJhv1TpUfyzS vw0kENGPxUYnlM4wJb71dHAXLZlFYnOiYL1PH7wyvfSJtMsBl/zi1ntWGLgwmjxCwjjHlkW7ngJ49 yMgZKaxA==; Received: from ppp118-209-166-89.lns20.mel8.internode.on.net ([118.209.166.89]:50411 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1betC9-004B0H-2x; Wed, 31 Aug 2016 10:15:57 +1000 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG" References: <790816B5-41F5-487E-B0B8-0BA88F714877@ericsson.com> <3A9C9924-D032-4BEE-9B78-DF94680A7C95@ericsson.com> From: Christian Groves Message-ID: <57879b61-d9fc-2cce-d56a-7bd9c78c2ff7@nteczone.com> Date: Wed, 31 Aug 2016 10:15:53 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3A9C9924-D032-4BEE-9B78-DF94680A7C95@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "draft-groves-core-dynlink@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_call_for_dra?= =?utf-8?q?ft-groves-core-dynlink?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 00:16:11 -0000 No surprise as author I support the draft.. Regards, Christian On 26/08/2016 10:01 PM, Jaime Jiménez wrote: > Hi all, > > As people are on vacation, let’s extend the deadline few days more to > allow people to comment. > > Ciao! > - - Jaime Jimenez > >> On 15 Aug 2016, at 18:05, Jaime Jiménez > > wrote: >> >> Dear CoRE-WG, >> >> As we discussed at last IETF96, working group adoption has been >> requested for draft-groves-core-dynlink. This draft is the result of >> a document split and thus the initial status is that of adoption, >> nevertheless that has to be confirmed on the list. Please reply with >> your comments, including although not limited to whether or not you >> support adoption. Non-authors are especially encouraged to comment. >> >> Since there are several concurrent WGA calls, we will end the call on >> *August 26, 2016*. >> >> Thanks, >> Jaime and Carsten > From nobody Tue Aug 30 17:51:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6D12D858 for ; Tue, 30 Aug 2016 17:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrSzk7h2le7K for ; Tue, 30 Aug 2016 17:51:30 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E2E12B03C for ; Tue, 30 Aug 2016 17:51:29 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 18:04:01 -0700 From: Jim Schaad To: Date: Tue, 30 Aug 2016 17:51:15 -0700 Message-ID: <048901d20321$c8c5dc60$5a519520$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdICNHSaZv2pAHPTRji2hykYHnUiIw== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: core@ietf.org Subject: [core] Comments on draft-selander-ace-objet-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 00:51:32 -0000 Random Thoughts: Introduction: Given the scope of the analysis, I do not believe that you can restrict your solution to just dealing with the forwarding case. Specifically I think you need to deal with the pub/sub cases with or w/o an agent. Introduction: Is the determination of content being present based on the length of the content or on the message type? For example think of a POST or a response with a zero length body. I would tend to create a COSE body in these cases rather than use the option for the body. Section 2 - I am not sure that the SHOULD NOT on caching makes complete sense. It would make sense to cache the response if correlated to the original request for reliability. Caching also makes sense in the pub-sub world Section 2 - how does setting Max-Age interact with pub-sub and w/ caching for reliable transmission? Section 2 - the last sentence seems to be odd - are you really given an example of option length or how different option lengths are encoded? Section 3 - s/common keying material/common shared secret material/ Section 3 - s/of forward secret keying material/of secret material with the property of forward secrecy/ Section 3.1 - You need to add a field for who is being talked to on the client side of the context. There is nothing to say that Cids are unique for the client and therefore it needs to be able to determine which to use when sending a message to the other side. This may also be required for servers when doing unicast in the event that it will spontaneously send messages. Section 3.1 - The idea of flip-flopping the context when the client and server change roles seems to be a very bad idea. If the client sends message and the server never receives it. Then they flip contexts and the old server sends because it swapped server and recipient, then you have a security leak problem. Once the contexts are established they should never be swapped. I think this is what the last paragraph in this section is suggesting. Section 3.2 - there should be a big warning at the top of this section that this procedure is only run once on a set of common secret material. Running it a second time is going to lead to bad things unless there is something added. Section 3.2 - I would prefer to add some additional items to the info structure to make sure that things are going to agree on both sides. These would include the algorithm and the lengths of the item being derived. Look at the prefix derivation problems that can exist otherwise. Section 3.2 - I have a problem with the text " The Context Identifier SHALL be unique for all security contexts used by the party being server." As I am not sure how to test this. A statement that a server will check and reject is testable. I do not think that one can assume that a TTP will be able to ensure this as there may be more than one of them and they may assign the same type of uniqueness indicator (i.e. the addresses of both parties). Please do not assume there is only one authorization server. Section 3.2 - There is a fun thing that needs to be thought about. A client which sends a token along with the request may try and register the same Cid more than once because the response to its request may get lost. This needs to be documented potentially as saying that the same Cid must result in the same context being generated. Section 4 - When doing encryption only, I would remove the I column from figure 4. I would just note that "E includes I" but "I" by itself would be a different proposition. That is 'I' would be ONLY integrity protected or integrity protected in a signed or MAC only message. Section 4 - The second paragraph below table 4 should not be dealing with duplication not integrity protection. That is the items it needs to talk about are 1) encryption or not and 2) duplicate or not and if it is duplicated are they evaluated separately or must the contents be the same - with the addition of new security services then it would also make sense to talk about 3) integrity protect or not. Section 5 - I would suggest making the mandatory algorithm declarations in a single location so that it is easy to find rather than having it in multiple locations. Section 5 - Your maximum sequence number is going to be much smaller than 2^56-1. You need to factor in the reduced sized tag and the limits for GCM into this size. I will need to do some research to figure out what the correct limit is. It is going to be closer to 2^32 w/o adjusting for the abbreviated tag. Section 6.1 - OSCOAP should not be a challenge response protocol so this paragraph is troubling. It needs to be able to support more than just this one situation. I am going to play with some other details so I will probably have more comments following this. Jim From nobody Wed Aug 31 01:25:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CCC12DA08 for ; Wed, 31 Aug 2016 01:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gW6fZmVah_n for ; Wed, 31 Aug 2016 01:25:03 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) (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 3FCEC12DA07 for ; Wed, 31 Aug 2016 01:25:01 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AlWQPuhfwulTJdGrkr5cF+2UvlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxc69ZB7h7PlgxGXEQZ/co6odzbGH6ua8BidZuszJ8ChbNscdD1ld0Y?= =?us-ascii?q?RetjdjKfbNMVf8Iv/uYn5yN+V5f3ghwUuGN1NIEt31fVzYry76xzcTHhLiKVg9?= =?us-ascii?q?fbytScbshsi6n9q/54fUK10RwmHsOPUuc17v9l+Z9pFPx9AzcuBpklqBi0ALUt?= =?us-ascii?q?we/XlvK1OXkkS0zeaL17knzR5tvek8/dVLS6TwcvdwZ7VZCDM7LzJ9v5Wz5lGQ?= =?us-ascii?q?BTeIs3AbSGg+kxdUDU7C9h6pcI32t37TvOp82iCcdef2RKwoUD+i5r16WRag3C?= =?us-ascii?q?4NNz87+WeRgMx5kL5SqxKovQ1uyqbIa5rTP/17KPCONegGTHZMC54CHxdKBZmx?= =?us-ascii?q?OtMC?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DQAQBckcZX/wQXEqxcg00BAQEBAXV8u?= =?us-ascii?q?CeCASaIAxQBAgEBAQEBAQEBgQSCMhiCGQOBGgMGMk0iCAkSiDmtWwEBAZAIMYU?= =?us-ascii?q?HZ4obgX4LWIIvBY8ZijeBZIQ8mGeQQR6EcWgBhmsBAQE?= X-IPAS-Result: =?us-ascii?q?A2DQAQBckcZX/wQXEqxcg00BAQEBAXV8uCeCASaIAxQBAgE?= =?us-ascii?q?BAQEBAQEBgQSCMhiCGQOBGgMGMk0iCAkSiDmtWwEBAZAIMYUHZ4obgX4LWIIvB?= =?us-ascii?q?Y8ZijeBZIQ8mGeQQR6EcWgBhmsBAQE?= X-IronPort-AV: E=Sophos;i="5.30,261,1470681000"; d="scan'208";a="120073052" To: core@ietf.org MIME-Version: 1.0 X-KeepSent: C2D1B5B6:A3F1F073-65258020:002DBA09; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 31 Aug 2016 13:54:51 +0530 X-MIMETrack: Serialize by Router on InKolM02/TCS(Release 9.0.1FP6HF144 | June 24, 2016) at 08/31/2016 13:54:56, Serialize complete at 08/31/2016 13:54:56 Content-Type: multipart/alternative; boundary="=_alternative 002E3A3265258020_=" Archived-At: Subject: [core] No-Response option is now available. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 08:25:05 -0000 This is a multipart message in MIME format. --=_alternative 002E3A3265258020_= Content-Type: text/plain; charset="US-ASCII" Dear list, The No-Response option for CoAP is now available at: https://tools.ietf.org/html/rfc7967 as an Informational RFC. The option is registered by IANA and is available at ( http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers ). Thanks to all the reviewers whose comments and support enriched the work. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 002E3A3265258020_= Content-Type: text/html; charset="US-ASCII" Dear list,
The No-Response option for CoAP is now available at: https://tools.ietf.org/html/rfc7967 as an Informational RFC. The option is registered by IANA and is available at (http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers).
Thanks to all the reviewers whose comments and support enriched the work.
 
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 002E3A3265258020_=-- From nobody Wed Aug 31 01:39:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC09712DA32 for ; Wed, 31 Aug 2016 01:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKfEkie90Q3Z for ; Wed, 31 Aug 2016 01:39:20 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A748B12DA2E for ; Wed, 31 Aug 2016 01:39:20 -0700 (PDT) Received: from mfilter47-d.gandi.net (mfilter47-d.gandi.net [217.70.178.178]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 764EB17213B; Wed, 31 Aug 2016 10:39:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter47-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter47-d.gandi.net (mfilter47-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0E_0I7junumL; Wed, 31 Aug 2016 10:39:17 +0200 (CEST) X-Originating-IP: 192.76.146.51 Received: from nar-4.local (wlan.dagstuhl.de [192.76.146.51]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 3BDDD172106; Wed, 31 Aug 2016 10:39:16 +0200 (CEST) Message-ID: <57C697B3.9050804@tzi.org> Date: Wed, 31 Aug 2016 10:39:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Abhijan Bhattacharyya References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] No-Response option is now available. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 08:39:23 -0000 Congratulations to Abhijan and the other authors, and to all the people who put in their time reviewing and contributing to this work! This is a prominent instance of making the principle work that new CoAP Options can be created by registering them. This model already has worked quite well in getting the requirements of specific areas of application into the CBOR ecosystem; I looking forward to more such activities coming in for CoAP as well. Grüße, Carsten Abhijan Bhattacharyya wrote: > Dear list, > The No-Response option for CoAP is now available at: > https://tools.ietf.org/html/rfc7967as > an Informational RFC. The option is registered by IANA and is available > at > (http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers). > > Thanks to all the reviewers whose comments and support enriched the work. > > Regards > Abhijan Bhattacharyya > Associate Consultant > Scientist, Innovation Lab, Kolkata, India > Tata Consultancy Services > Mailto: abhijan.bhattacharyya@tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 31 03:23:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDEC12DABF; Wed, 31 Aug 2016 03:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX4iOQ9Pc4Bf; Wed, 31 Aug 2016 03:23:46 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C8D12DAA2; Wed, 31 Aug 2016 03:23:46 -0700 (PDT) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D3CF3A80D8; Wed, 31 Aug 2016 12:23:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MilGJicQdd1F; Wed, 31 Aug 2016 12:23:42 +0200 (CEST) X-Originating-IP: 188.130.77.134 Received: from [172.16.0.20] (ppp-134.net-188-130-77.static.magiconline.fr [188.130.77.134]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5FC0BA80DD; Wed, 31 Aug 2016 12:23:40 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E515CA3-E394-4EDF-94B4-F72E5E97169A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Wed, 31 Aug 2016 12:23:44 +0200 Message-Id: <207852EB-C406-4276-AADC-31ED3A626339@ackl.io> References: To: James Nguyen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-koster-core-coap-pubsub@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-kos?= =?utf-8?q?ter-core-coap-pubsub?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 10:23:49 -0000 --Apple-Mail=_3E515CA3-E394-4EDF-94B4-F72E5E97169A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, +1 on the adoption of this draft. For me, the PubSub functionality is = essential and without it we=E2=80=99re leaving a big hole in the CoAP = realm. There are of course things which we should discuss, and most have been = pointed out by the other supporters.=20 A point on which we should be aware is that if we want application level = security, this will imply the use of Asymmetric keys / Certificates. If = we want to keep PSK as a way of authentication, then probably we should = provide some mechanisms for the Broker to be used as a trusted = third-party, which validates the end-devices. Best, Alexander > Le 30 ao=C3=BBt 2016 =C3=A0 20:41, James Nguyen = a =C3=A9crit : >=20 > Hi, >=20 > I support this I-D as I think it's useful. =20 >=20 > I have a question. >=20 > Section 3.5 Brokerless pubsub >=20 > - I suggest to move this section to section 3.1. > =20 > - This architecture is more applicable to CoAP Proxy. =20 >=20 > - I also suggest to add the pubsub capability at CoAP Proxy. >=20 > James >=20 >=20 > On Mon, Aug 15, 2016 at 11:10 AM, Jaime Jim=C3=A9nez = > wrote: > Dear CoRE-WG, >=20 > As we discussed at last IETF96, working group adoption has been = requested for draft-koster-core-coap-pubsub. At the IETF meeting the = room consensus was strongly supporting adoption (~10 people). Please = reply to the list with your comments, including although not limited to = whether or not you support adoption. Non-authors are especially = encouraged to comment. >=20 > Since there are several concurrent WGA calls, we will end the call on = August 26, 2016. >=20 > Thanks, > Jaime and Carsten >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = >=20 >=20 >=20 >=20 > --=20 > James Nguyen > Email: james.huy.nguyen@gmail.com = _______________________________________= ________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_3E515CA3-E394-4EDF-94B4-F72E5E97169A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

+1 on the adoption of this draft. For me, the PubSub = functionality is essential and without it we=E2=80=99re leaving a big = hole in the CoAP realm.

There are of course things which we should discuss, and most = have been pointed out by the other supporters. 

A point on which we = should be aware is that if we want application level security, this will = imply the use of Asymmetric keys / Certificates. If we want to keep PSK = as a way of authentication, then probably we should provide some = mechanisms for the Broker to be used as a trusted third-party, which = validates the end-devices.

Best,
Alexander


Le 30 ao=C3=BBt 2016 =C3=A0 = 20:41, James Nguyen <james.huy.nguyen@gmail.com> a =C3=A9crit :

Hi,

I support this I-D as = I think it's useful. 

I have a = question.

Section 3.5 Brokerless = pubsub

- I suggest to move this = section to section 3.1.
 
- This architecture is more applicable to = CoAP Proxy. 

- = I also suggest to add the pubsub capability at CoAP Proxy.

James


On Mon, Aug 15, 2016 at 11:10 AM, = Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
Dear CoRE-WG,

As we discussed at last IETF96, working group adoption has been = requested for draft-koster-core-coap-pubsub. At the IETF meeting the = room consensus was strongly supporting adoption = (~10 people). Please reply to the list with your comments, = including although not limited to whether or not you support adoption. = Non-authors are especially encouraged to comment.

Since there are several concurrent WGA calls, we will end the call = on August 26, 2016.

Thanks,
Jaime and Carsten


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




--
James Nguyen
Email: james.huy.nguyen@gmail.com
_______________________________________________
core = mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_3E515CA3-E394-4EDF-94B4-F72E5E97169A-- From nobody Wed Aug 31 03:36:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BEC12D099 for ; Wed, 31 Aug 2016 03:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNv1UVlNivaT for ; Wed, 31 Aug 2016 03:36:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF295120727 for ; Wed, 31 Aug 2016 03:36:47 -0700 (PDT) Received: from [192.168.91.132] ([90.127.74.115]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MhhwJ-1bRcUw2Ac7-00MrWe for ; Wed, 31 Aug 2016 12:36:45 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Message-ID: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> Date: Wed, 31 Aug 2016 12:36:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:JwvcJXOKI4avFOXPkZNWdxWUp1R2VrEktdONQq8GeZD1uMRPUwM sT4uDcCXk6o0Bhwnv58PqCohWJzfcwNgVNt1T42cG5d5XumtjOGPEb9UieIrCRaxh9AWqf6 KBJOPpCH1mSnlc9G9pYokSL3RKSTUzVBwEl/T+xlDhTO0WtBM39hf2NF93PT8hYAgE/qQv+ cb8APxUbCNN4nE+i0OwRQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:lCIJnDusagA=:yE+CECNE8PxeD1XsPujniO G5bawXK8Rm+QDQeQ1R3NLioPGVihEg2FuKdKVC21rjUPM2QEUObxmg+4ikfZ7CKMvnE8XquRn uEHguJGAjz9VjwwuJjpynjTxFAWPnwuJQj3rZp2Vucd82IqWm4bBrZ3BXRXNSctN8WXbkReDV kaDa7jX8VpluIAVZWKWa/RY2cQTjq+hfHWdCjB0QDBMU278HWccOyPGMLSoKq2giy4s9Wy+c5 Uow/bFh6AO29ql6eubDkP9tX+oR3C1waf/rLsyhJ4yT6uPl8PdFCWGGRPBfRGoh+PfmvUKW1L 1tmpXIlWAS7wDGTUKdmY5m7WIR56AJXaPlFkgaW2f4HEBxARpzpVhEHkUKZSamPG2QRcXWB5S 4Db4yxeWNRu4kDVpEko5jesXMZlDIwWZ35rRwEGVPnAisCkgG90k/lgRx/jWZxdrsIpGGIVB2 A5xNS+La8lV4314X+swIt0/XgFPAhuNGWzWnjzD+APWJIEO3ew8ApAdmVHnMpj+deOi/9uKxY EOV+h2hiXOPBFEAbG/EsQJglFeH3FlovZN7+MKoo0nf1eo14qhA5w5RsAh3DQsHN0KdFc+6kM h29A4cGjDPouESPv4Gicl974UTffHIN/MOdyV7ZDxy7C7NSPLP4f7+acN6qdk1OcnFfCI/PSI CRa8qOnEQwDOSX2DA6K+OdAlsdLhqjf5AQxqplijKnqLvupR0nsJ2fw/E8AbcUFqI1TAHwuB3 J4JkUoLfTHvrGEW7zpZGGF+ik6C6klU7Ldd0D8PFcnitgZZNZ/VCYuSqUmkTfVO3P4YbpDKgE wreSfPM Archived-At: Subject: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 10:36:50 -0000 Hi all, in the OMA device management group we have been discussing the implications of IP address and/or port number changes of devices (particularly with devices that sleep for an extended period of time). The challenge from a protocol point of view is to use an identifier that does not depend on the IP address and port. Of course, when a IP packet has to be sent to a specific node then IP address and port information has to be used from somewhere but my expectation is that at least the protocol machinery shouldn't break when an IP address changes (or there should be a story for how to recover). In CoAP the 'endpoint' appears to be an important identifier. In an attempt to define what an endpoint is the CoAP specification is a bit confusing: Section 1.2 says: " Endpoint An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association (Section 4.1). " Section 4.1 of RFC 7252 says: " A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode. " The two definitions do not appear to be in sync, particularly when using DTLS to secure CoAP since the DTLS record layer adds nothing with respect to additional multiplexing. I also did not find text that describes what the different endpoint definition is when DTLS is used. In any case, when DTLS is used an IP address / port change at the client will prevent the CoAP server from finding the right security context and a new (hopefully abbreviated) handshake has to be run. Luckily the implications of an IP address/port change are quite minimal for CoAP itself since the only impact (as far as I can tell) is with regards to the use of request/response exchange, as described in Section 5.3.2 "Request/Response Matching Rules". The likelihood that a client changes IP address in the middle of a request/response interaction are IMHO minimal. The story is more interesting when we look at extensions to CoAP, like CoAP Observe. Section 4.1 of https://tools.ietf.org/html/rfc7641 says: " The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. " With Observe a token is used for demultiplexing (in addition to the endpoint info). I assume that the spec uses the same definition of endpoint as in CoAP. While the spec does not say what is actually being updated or replaced one can assume that a client sending a request with a new IP address and port (which corresponds to the endpoint definition in CoAP) gets at least that information updated. The spec is IMHO unclear what should happen in case of an IP address/port change. I suspect that an implementation would send a new register message and the server would update state. Of course, when the IP address / port of the client is not in sync with what is being stored at the server then the notifications sent by the server will not reach the client. The story for RD appears to be different again. First, there appears to be a different definition of endpoint being used (which I prefer more). For multiplexing it does not use IP address & port information. Of course, RD will still have to maintain this information but at least one can be sure that packets are not dropped after the IP address and/or port at the client change. Section 11.1 of draft-ietf-core-resource-directory-08 says: " An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. " It appears that the way how state is indexed is different throughout the specifications developed in the CORE working group and I am curious whether someone else has been looking at the implications of IP address and/or port changes on the protocol operation. I would certainly appreciate your thoughts on this topic. Ciao Hannes From nobody Wed Aug 31 08:49:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E12D12D1DD for ; Wed, 31 Aug 2016 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6MYRqPkyugV for ; Wed, 31 Aug 2016 08:49:10 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72E012D658 for ; Wed, 31 Aug 2016 08:35:10 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id h186so20626407pfg.3 for ; Wed, 31 Aug 2016 08:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5jBXpN1Cxqxy3vp7/ejvZbuECsFhM91ri2uFmy90dq8=; b=ecayOp5FyIwkeIrfV7s3RqmP7h52byiYrjVJmtSrLdJbpLhF8s562OhU5uSWWGvwW6 wSlBI0FT9VRiutgQHjVWHv6+f2z8cvN7floW6XlzZw3IiXI5fg2v2yMNGQFJYiD12stQ hDtfp8wScYvrQacrXHCuppck1V43n6UhKPhYPcJqQ9DSFfVWH2yr1tnhs09ZiU/uTSrb HsyhqiXHuSWaWU0Gjn6pmN+lzBpMCOmdOMkilxqAwrwJXxMQwhlc0OPFYQy8P8WlNEBy H74EJkuJzluWChkAZvWQrVlsoiQFLGPNx63ikU8H8wzwdzLpU01cLFeWYR0AYkMix7lN KrCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5jBXpN1Cxqxy3vp7/ejvZbuECsFhM91ri2uFmy90dq8=; b=EVHjiKcG6UDsZqWr9tpszvr+K9WeyQwXxRJheAlwYuzOW0Wf+fu9/vRESqlJHyrYQd cgLYlXgtaMwH2U4MU1LBuu6n4mCIfwdDZOr4Rg5u/EnguUHhuNcTLfRa9JJ6bXVj+dyC odbyUM1XVhrwe+rlyXddURB4vNKfq3qtq7sOE9UqrL6IKWpdEXDlmNoXbpqeO7fCO7Qq uebI/nT2V2UdfBY7di7ChusWHv0h/6QeUypEwuEevUt/vYL3BxXjgkqiCHdJkjASGdIy 4Ergqko0NnMKCupsfBP1KHcWrJ6xyuqvMU1+ZCGt0bkF5LP61jiJRTfUfzgDq2cmCg6r TeHA== X-Gm-Message-State: AE9vXwPG3X1GfQvPO36zWq37W7z6Ud6lRj3HsRCcmo7cPExztGcUbPpQ6ScOa9uidL23Ag== X-Received: by 10.98.14.72 with SMTP id w69mr17822952pfi.119.1472657710325; Wed, 31 Aug 2016 08:35:10 -0700 (PDT) Received: from [10.0.0.20] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id i137sm588612pfe.64.2016.08.31.08.35.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 08:35:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C2D091A3-008F-42F3-B0E2-A7EF5EF6DABC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Wed, 31 Aug 2016 08:35:07 -0700 Message-Id: <03A5C678-DD44-43BA-A49D-C1EEFAA3C2F9@gmail.com> References: To: Christian Groves , Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] My Notes about draft-ietf-core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:49:14 -0000 --Apple-Mail=_C2D091A3-008F-42F3-B0E2-A7EF5EF6DABC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Hannes, Thanks! Comments below: > On Aug 26, 2016, at 12:09 AM, Christian Groves = wrote: >=20 > Hello Hannes, >=20 > Please see below. >=20 > Regards, Christian >=20 >=20 > On 3/08/2016 5:49 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> I read through draft-ietf-core-interfaces-05 and I have a few = questions. >>=20 >> I understand the functionality and the desire to standardize = interfaces >> since the CoRE Link Format only introduces the concepts but leaves = the >> details (i.e., the value for the if parameter) unspecified. >>=20 >> 1) Who came up with these terms? > [CNG] I'm not sure, various related technologies such as Java and HTML = utilise some of the concepts e.g. collection. I'll let one of the = original authors answer this. I agree the definitions could use some = more "meat" on them. Something that i'll work on. >>=20 >> Here, for example, is the definition of the 'collection': >>=20 >> "A Collection is a resource which represents one or more related >> resources. Within this document, a collection refers to a collection >> with characteristics defined in this document." >>=20 >> My understanding of the collection function is that of a view in an = SQL >> database. Is this correct? >>=20 >> The definition of function set, interface, and other terms also = appears >> to be somewhat unusual. Isn't there something we could re-use from = the >> Web context? >>=20 [MJK] The concept of a collection is very common in web architecture. = Check out RFC6573 https://tools.ietf.org/html/rfc6573 = I think we could add examples to = CoRE Interfaces using the item relation type to illustrate this. [MJK] The concept of "interface" was invented by an earlier author than = me, but has been adopted by OCF in their specification. It fills a gap = between media types and "profiles", which are not well adopted either. [MJK] Function set is not so well adopted and may be changed to a more = colloquial description. Which other terms need further definition? >> 2) Is this document only applicable to CoAP or also to HTTP? In = general, >> I get worried when functionality is only defined for use with CoAP = and >> is not usable with HTTP, and HTTP/2. > [CNG] Also to HTTP, as Core-Link format may be used by HTTP. >>=20 >> 3) Is it possible to include some practical examples? The document >> currently includes a number of examples but those are abstract. > [CNG] Did you have something in mind? >>=20 >> 4) I am curious why SenML was selected. I have been trying to = understand >> the relationship with LWM2M and LWM2M, for example, does not use = SenML. >> SenML feels like a somewhat heavy format since it includes meta-data >> that most applications don't need. > [CNG] You mention LWM2M and LWM2M I'm not sure what the 2nd instance = is? With regards to LWM2M the specification uses the "interface" concept = in a similar manner to what is defined in the draft. I.e. what = operations may be performed on resources via the interface is described. = The LWM2M specification does reference the core interfaces draft but = that's only in the context of a note i.e. "/Note: How to indicate the = Attributes in the message payload is specified in [CoRE_Interface]./" I = think that needs to be updated to make reference to the dynamic linking = draft we have split out. >=20 [MJK] "LWM2M, for example, does not use SenML." (?) I don't understand = this comment. As far as I can tell, LWM2M normatively requires SenML. = =46rom the LWM2M TS, Sec. 6.3.4, JSON: "LWM2M Clients supporting the JSON format MUST use the format defined in = this section for responses with multiple resource values. They MAY use = the format defined in this section for responses with single value. The = format MUST comply to [SENML] JSON representation extended for = supporting LWM2M Object Link data type and MUST support for all = attributes defined in Table 17. According to [SENML] semantics, JSON = data format in LWM2M, is composed of optional attributes (Base Time, = Base Name) and of a mandatory Resource Array having one or more entries. = Each array entry contains several optional or mandatory parameters = (Name, Time...)." >>=20 >> 5) For most functionality no use cases are presented. The exception = is >> the collection where a use case is presented in Section 4.2. I am, >> however, not sure that the 'Gradual Reveal' functionality is really >> useful as such. > [CNG] The draft was accepted back in mid 2013 (before I started = following the CORE WG) I would have assumed there were some use cases = presented in order for the WG to adopt the work. Perhaps one the = original authors has them? >>=20 >> 6) Who is using the functionality described in this document? The >> editor's note talks about alignment with OCF. Since I am not familiar >> with the functionality standardized by the OCF I cannot say how much >> different this document is from the OCF-defined features. > [CNG] The note was simply a place holder for further work that needs = to be done. The relationship with OCF is something that needs further = description. This is something hopefully Michael will be able to help = with. [MJK] OCF uses the "if" link atttriute in much the same way as described = in this draft. It is registered in the IANA CoRE Parameters registry. >>=20 >> 7) The structure of the document is not well-balance. For example, >> Section 3 consists of one sentence. The content of Section 5.8 is >> meaningless and Section 6.3 "Versioning" is difficult to understand. = The >> security consideration section as well as the IANA consideration = section >> is at best incomplete. Appendix A contains no textual description of >> what is shown in the tables. > [CNG] Yes it needs work. I explained at the meeting this document was = a simple split of the existing text. I intend to provide some = enhancements for the next version. >> 7) Who is the editor of this document? > [CNG] I'm now the editor. So thanks for the comments there something = to consider for the next revision. >>=20 >> Ciao >> Hannes >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core = >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_C2D091A3-008F-42F3-B0E2-A7EF5EF6DABC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Hannes,

Thanks!

Comments below:

On Aug 26, 2016, at 12:09 AM, = Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello Hannes,

Please see below.

Regards, Christian


On 3/08/2016 5:49 PM, Hannes Tschofenig = wrote:
Hi all,

I read through = draft-ietf-core-interfaces-05 and I have a few questions.

I understand the functionality and the desire = to standardize interfaces
since the CoRE Link Format only = introduces the concepts but leaves the
details (i.e., the = value for the if parameter) unspecified.

1) = Who came up with these terms?
[CNG] I'm not sure, various related technologies = such as Java and HTML utilise some of the concepts e.g. collection. I'll = let one of the original authors answer this. I agree the definitions = could use some more "meat" on them. Something that i'll work = on.

Here, for example, is the definition of = the 'collection':

"A Collection is a = resource which represents one or more related
resources. = Within this document, a collection refers to a collection
with characteristics defined in this document."

My understanding of the collection function is = that of a view in an SQL
database. Is this correct?

The definition of function set, interface, and = other terms also appears
to be somewhat unusual. Isn't = there something we could re-use from the
Web context?


[MJK] The concept of a collection is very common in web = architecture. Check out RFC6573  https://tools.ietf.org/html/rfc6573  I think we = could add examples to CoRE Interfaces using the item relation type to = illustrate this.

[MJK] The concept = of "interface" was invented by an earlier author than me, but has been = adopted by OCF in their specification. It fills a gap between media = types and "profiles", which are not well adopted either.

[MJK] Function set is not so well adopted and may = be changed to a more colloquial description.

Which other terms need further = definition?


2) Is this document = only applicable to CoAP or also to HTTP? In general,
I get = worried when functionality is only defined for use with CoAP and
is not usable with HTTP, and HTTP/2.
[CNG] Also to HTTP, = as Core-Link format may be used by HTTP.

3) Is it = possible to include some practical examples? The document
currently includes a number of examples but those are = abstract.
[CNG] Did you have something in mind?

4) I am = curious why SenML was selected. I have been trying to understand
the relationship with LWM2M and LWM2M, for example, does not = use SenML.
SenML feels like a somewhat heavy format since = it includes meta-data
that most applications don't = need.
[CNG] You mention = LWM2M and LWM2M I'm not sure what the 2nd instance is? With regards to = LWM2M the specification uses the "interface" concept in a similar manner = to what is defined in the draft. I.e. what operations may be performed = on resources via the interface is described. The LWM2M specification = does reference the core interfaces draft but that's only in the context = of a note i.e. "/Note: How to indicate the Attributes in the message = payload is specified in [CoRE_Interface]./" I think that needs to be = updated to make reference to the dynamic linking draft we have split = out.

[MJK] "LWM2M, for example, does not = use SenML." (?) I don't understand this comment. As far as I can tell, = LWM2M normatively requires SenML. =46rom the LWM2M TS, Sec. 6.3.4, = JSON:

"LWM2M Clients supporting the JSON format MUST use the format defined in this section = for responses with multiple resource values. They MAY use the format defined = in this section for responses with single value. The format MUST comply to [SENML] JSON representation extended for supporting LWM2M Object Link data type and = MUST support for all attributes defined in Table 17. According to [SENML] semantics, JSON data format in LWM2M, is composed of optional attributes (Base Time, Base = Name) and of a mandatory Resource Array having one or more entries. Each array = entry contains several optional or mandatory parameters (Name, Time...)."


5) For most functionality no use cases = are presented. The exception is
the collection where a use = case is presented in Section 4.2. I am,
however, not sure = that the 'Gradual Reveal' functionality is really
useful = as such.
[CNG] The draft was accepted back in mid 2013 = (before I started following the CORE WG) I would have assumed there were = some use cases presented in order for the WG to adopt the work. Perhaps = one the original authors has them?

6) Who = is using the functionality described in this document? The
editor's note talks about alignment with OCF. Since I am not = familiar
with the functionality standardized by the OCF I = cannot say how much
different this document is from the = OCF-defined features.
[CNG] The note was simply a place holder for = further work that needs to be done. The relationship with OCF is = something that needs further description. This is something hopefully = Michael will be able to help with.

[MJK] OCF uses the "if" link atttriute in much the same = way as described in this draft. It is registered in the IANA CoRE = Parameters registry.

7) The = structure of the document is not well-balance. For example,
Section 3 consists of one sentence. The content of Section = 5.8 is
meaningless and Section 6.3 "Versioning" is = difficult to understand. The
security consideration = section as well as the IANA consideration section
is at = best incomplete. Appendix A contains no textual description of
what is shown in the tables.
[CNG] Yes it needs work. I explained at the = meeting this document was a simple split of the existing text. I intend = to provide some enhancements for the next version.
7) Who is the editor of = this document?
[CNG] I'm now the editor. So thanks for the = comments there something to consider for the next revision.

Ciao
Hannes



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

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

= --Apple-Mail=_C2D091A3-008F-42F3-B0E2-A7EF5EF6DABC-- From nobody Wed Aug 31 08:54:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0368E12D5A1 for ; Wed, 31 Aug 2016 08:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfji6AJZuO8e for ; Wed, 31 Aug 2016 08:54:25 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD0212D5DB for ; Wed, 31 Aug 2016 08:45:38 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id h186so20709266pfg.3 for ; Wed, 31 Aug 2016 08:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=S7mfMhu1QyP95LU+Ur832YVo2dg6Q8s6SuuRLOQsW7Q=; b=CR5aRyOIeB7wuus3k/2enahNjlRtRlvEMQjL8ZIz+TE4F/VSO7nOl9nAs8NpXqavJj c6069a72aJ72HqORqPjHgvlkuH/gukaW41zA6OjSSGov6Q8gD8q+D2fKczdHhfYuVeKm 9dJZimxBbIRld0+tUZsTVc2uxDDbXB944Zii6rc3ZmNKGmScvzOvs1W3+0HknnczHiN2 /loBnKjz0A8bj7DSmQl/yA1prOvkNHI8mTO9UjCpyozop7TcJtsUpK1j01pEFqwtDflZ Fqb5QvI3FutYhoav0/2mwF41IvZub0eUqNRCtvZCydwL9hhsnV4FvKdQZEVLJZ5vz1T3 Xq2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=S7mfMhu1QyP95LU+Ur832YVo2dg6Q8s6SuuRLOQsW7Q=; b=nJ6oUFtWzdwsmlFKMFsFczdZNr2ds3SSlmTRgkpitdQKy6BNOR5owuPqnTir8dQ3gz dppMua6u3IiT1fQ3D7UUewg2lI/MFPRPK2ldzxPC0iGkmTlDlontu9BVHoetFt8EIawX sLpbpDGPZGiBNa5qLqLaqzD0sjj8umiIWlV9ahA8HQ2PI86qcWoW4fzBT5bozIMxUZ+C kxvK8W9J/xKgeC+b8su+ghQlBKxiyGf97HClg/Km3ZRDs3UcS7U8aDBl7OpK6/YC0rX5 oDwCLBBKuPSd3cMKbWYIqcaP31kb1jP2341i2GCDVw8rBdvL2DoKhhv/5+f4h+CUKN33 WM7A== X-Gm-Message-State: AE9vXwM/g66XppJWD7KFgQnCV5QcDkBnQzIWg3FCjf3IKPYk07ZwkG8YlA2BEzzRDgHYVg== X-Received: by 10.98.5.133 with SMTP id 127mr18108645pff.40.1472658338433; Wed, 31 Aug 2016 08:45:38 -0700 (PDT) Received: from [10.0.0.20] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id kx13sm707463pab.0.2016.08.31.08.45.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 08:45:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A8213C40-4657-44C9-A522-1CE6545F09FC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Wed, 31 Aug 2016 08:45:36 -0700 Message-Id: <149CE908-A44B-4253-9313-F2F3F4D03937@gmail.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] My Notes about draft-ietf-core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:54:30 -0000 --Apple-Mail=_A8213C40-4657-44C9-A522-1CE6545F09FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Hannes, SenML is used because it is a lightweight data model that can represent = a collection of resources.=20 The "n" attribute in SenML identifies the resource instance and allows = multiple resources to be transmitted in a single representation. The array format has some advantages in processing vs. map formats that = use application semantics as JSON keys. SenML maps to CBOR in a compact way. Most meta data in SenML is optional, and should not need to burden = applications that don't need it. Michael > On Aug 3, 2016, at 12:49 AM, Hannes Tschofenig = wrote: >=20 > 4) I am curious why SenML was selected. I have been trying to = understand > the relationship with LWM2M and LWM2M, for example, does not use = SenML. > SenML feels like a somewhat heavy format since it includes meta-data > that most applications don't need. --Apple-Mail=_A8213C40-4657-44C9-A522-1CE6545F09FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Hannes,

SenML is used because it is a lightweight data model that can = represent a collection of resources. 

The "n" attribute in SenML identifies = the resource instance and allows multiple resources to be transmitted in = a single representation.

The array format has some advantages in processing vs. map = formats that use application semantics as JSON keys.

SenML maps to CBOR in a = compact way.

Most meta data in SenML is optional, and should not need to = burden applications that don't need it.

Michael

On = Aug 3, 2016, at 12:49 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

4) I am curious why SenML was selected. I have = been trying to understand
the relationship with = LWM2M and LWM2M, for example, does not use SenML.
SenML feels like a somewhat heavy format since = it includes meta-data
that most applications = don't need.

= --Apple-Mail=_A8213C40-4657-44C9-A522-1CE6545F09FC--