From nobody Fri Jun 1 00:23:07 2018 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 1AF66129515 for ; Fri, 1 Jun 2018 00:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 zbafVoOFmnDe for ; Fri, 1 Jun 2018 00:22:57 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 432C712D7ED for ; Fri, 1 Jun 2018 00:22:57 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud7.xs4all.net with ESMTPA id OeOkfvWRVxiYrOeOkftZQb; Fri, 01 Jun 2018 09:22:54 +0200 Received: from AMontpellier-654-1-77-167.w90-0.abo.wanadoo.fr ([90.0.172.167]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 01 Jun 2018 09:22:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Jun 2018 09:22:54 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: "Kovatsch, Matthias" , consultancy@vanderstok.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfFYLOsGEnO4BFhv/ZdaD3G7P2/Vd/uKWMtUTPsZItKsdbhVxX99rUrzGjpCl/TkxzUom9T2aOXBm+/hNheWFeKoy9lQ2oH3qOTrwOJshN92IPZQgWK9A OAPdBFHenjBH+y+TrjLkikvp0yODTprOdhN+CyMkQohZogq6aXdLML6yYW4LhaEaE2qx5slNW3WrBYSAY0BN/FT8uXK4Jyp3JirTx1N4qh3cJXrbQQ5ubRKp aSd17IEov/ZozpayS7Msbi9mXMSVm8AgdtSnTo2Fr+k= Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jun 2018 07:23:05 -0000 Hi Hannes, Matthias, Below a proposal for the security considerations section in the RD draft the last paragraph: "Therefore, Endpoints MUST include the Endpoint identifier in the message, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message." to be replaced with: "A client MUST obtain an access token from an authorization server [draft-ietf-ace-oauth-authz]. For most installations the name of the endpoint does not need to be semantically meaningful. For those installations the endpoint name MUST be equated to the security identifier transported in the access token. For installations where the endpoint name must reflect the names of components of the installation, the access token MUST contain the values of the endpoint name and the optional domain name. A companion document SHOULD describe the format of the access tokens, the negotiation between client and Authorization server, and the treatment of the token by the RD server." Will that be sufficient for you; or do you want more detailed text like yours below? Looking forward to your improvements, thanks, peter Hannes Tschofenig schreef op 2018-05-15 10:15: > @Hannes: Could you provide some more detail, how exactly the Endpoint > Client Name is extracted from "security context"? Overall, I like > this, but we should provide concrete text on how people should do it. > > You want to store the security context on the server side and the > Endpoint Client Name points to the identifier part of it. > (Other parts of the security context will be relevant for other > purposes.) > > * For PSK-based credential the Endpoint Client Name becomes the PSK > Identity > * For raw-public keys the Endpoint Client Name becomes the > SubjectPublicKeyInfo structure (or a hash of it). > * For certificates the Endpoint Client Name becomes the leftmost CN > component of subject name or the SubjectAltName of the certificate, > depending on what you use. > > Ciao > Hannes > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. From nobody Fri Jun 1 14:50:04 2018 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 1738D12DA1C; Fri, 1 Jun 2018 14:50:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152788980199.14677.11405847183980275672.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 14:50:01 -0700 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 102 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:50:02 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor httpbis artarea t2trg suit ace lpwan 6lo roll teep Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm emu Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Please also avoid any potentially IoT related BOFs that might come up (atick, amp). Prefer some time between the two meetings (48 h or more). --------------------------------------------------------- From nobody Mon Jun 4 11:16:48 2018 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 4D449129C6B; Mon, 4 Jun 2018 11:16:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152813620626.7880.2794576996256931450@ietfa.amsl.com> Date: Mon, 04 Jun 2018 11:16:46 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 18:16:47 -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 WG of the IETF. Title : YANG Schema Item iDentifier (SID) Authors : Michel Veillette Alexander Pelov Filename : draft-ietf-core-sid-04.txt Pages : 25 Date : 2018-06-04 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 64-bit unsigned numbers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-sid-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-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 Tue Jun 5 07:55:17 2018 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 484181310C6; Tue, 5 Jun 2018 07:55:15 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEBRiNDCTEh0; Tue, 5 Jun 2018 07:55:13 -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 69AF61310C3; Tue, 5 Jun 2018 07:55:13 -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 w55EtA4B005209; Tue, 5 Jun 2018 16:55:10 +0200 (CEST) Received: from client-0081.vpn.uni-bremen.de (client-0081.vpn.uni-bremen.de [134.102.107.81]) (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 410Zbf0c0JzDXBP; Tue, 5 Jun 2018 16:55:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> Date: Tue, 5 Jun 2018 16:55:10 +0200 X-Mao-Original-Outgoing-Id: 549903308.400243-138949a414a5d0be9b20af473de829c9 Content-Transfer-Encoding: quoted-printable Message-Id: <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> References: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> To: core , ace X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] New Version of draft-fossati-core-multipart-ct-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 14:55:16 -0000 In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed = to introduce a media type for efficiently combining multiple = representations, along with the Content-Format numbers of their media = types, into a single representation. I believe we have needed such a media type in other places, so I have = extracted the content of that PR, and revved = draft-fossati-core-multipart-ct (of 2013 vintage) with that. This would = give us a media type multipart/core for general use. (Thanks are due to = Klaus and Thomas for helping me with this little exercise.) CoAP-EST is due to be finished very soon, and extracting this media type = from the CoAP-EST draft should only be done if we can avoid creating a = hazard for CoAP-EST to be delayed by this. I don=E2=80=99t see such a hazard unless we are having fundamental = problems with the approach (but do accept its limited use in the = CoAP-EST space). So it would be useful to get some quick reactions on whether we can go = ahead with this. If you don=E2=80=99t want to read the draft right now, its technical = content is: multipart-core =3D [* multipart-part] multipart-part =3D (type: uint .size 2, part: bytes / null) (Where =E2=80=9Ctype=E2=80=9D is the content-format identifier.) Gr=C3=BC=C3=9Fe, Carsten > Name: draft-fossati-core-multipart-ct > Revision: 04 > Title: Multipart Content-Format for CoAP > Document date: 2018-06-05 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-fossati-core-multipart-ct-04.tx= t > Status: = https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/ > Htmlized: = https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-04 >=20 > Abstract: > This memo defines multipart/core, an application-independent media- > type that can be used to combine (even recursively) several = different > media types into a single CoAP message-body with minimal framing > overhead, along with a CoAP Content-Format identifier. From nobody Tue Jun 5 08:25:51 2018 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 64DB51310F3; Tue, 5 Jun 2018 08:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGQ8rOem7Q7M; Tue, 5 Jun 2018 08:25:42 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE3E1310F2; Tue, 5 Jun 2018 08:25:42 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 705FB181D0286; Tue, 5 Jun 2018 15:25:41 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:2:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1575:1588:1589:1592:1594:1606:1730:1776:1792:2068:2069:2198:2199:2525:2528:2559:2568:2570:2635:2682:2685:2691:2693:2703:2741:2827:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4120:4250:4321:4605:4860:5007:6117:6119:6261:7875:7903:8603:8957:9010:9025:9163:9177:10004:11658:12379:12740:13139:13161:13229, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: wax62_3160f9a61ed45 X-Filterd-Recvd-Size: 9608 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Tue, 5 Jun 2018 15:25:39 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1c965083b32967a55b0041c0a7f18ad2" Date: Tue, 05 Jun 2018 17:25:38 +0200 From: Peter van der Stok To: Carsten Bormann Cc: core , ace Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> References: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.135.186] Archived-At: Subject: Re: [core] New Version of draft-fossati-core-multipart-ct-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 15:25:46 -0000 --=_1c965083b32967a55b0041c0a7f18ad2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Carsten et al. I have looked at the multipart draft, and I am happy to see that the CBOR array is maintained as proposed in est-coaps. So now we have two drafts that both propose an almost identical new media type. The choice will be determined by the delay needed to (pre-)register the new media type. Will anyone start doing that for the multipart draft within a foreseeable delay. If not, I am happy to pre-register the new media type as specified in coaps-est to avoid delaying est-coaps. Looking forward to your reaction, many thanks for your trouble to create an indenpendent draft. peter Carsten Bormann schreef op 2018-06-05 16:55: > In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed to introduce a media type for efficiently combining multiple representations, along with the Content-Format numbers of their media types, into a single representation. > > I believe we have needed such a media type in other places, so I have extracted the content of that PR, and revved draft-fossati-core-multipart-ct (of 2013 vintage) with that. This would give us a media type multipart/core for general use. (Thanks are due to Klaus and Thomas for helping me with this little exercise.) > > CoAP-EST is due to be finished very soon, and extracting this media type from the CoAP-EST draft should only be done if we can avoid creating a hazard for CoAP-EST to be delayed by this. > > I don't see such a hazard unless we are having fundamental problems with the approach (but do accept its limited use in the CoAP-EST space). > So it would be useful to get some quick reactions on whether we can go ahead with this. > > If you don't want to read the draft right now, its technical content is: > multipart-core = [* multipart-part] > multipart-part = (type: uint .size 2, part: bytes / null) > > (Where "type" is the content-format identifier.) > > Grüße, Carsten > >> Name: draft-fossati-core-multipart-ct >> Revision: 04 >> Title: Multipart Content-Format for CoAP >> Document date: 2018-06-05 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/internet-drafts/draft-fossati-core-multipart-ct-04.txt >> Status: https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/ >> Htmlized: https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct >> Diff: https://www.ietf.org/rfcdiff?url2=draft-fossati-core-multipart-ct-04 >> >> Abstract: >> This memo defines multipart/core, an application-independent media- >> type that can be used to combine (even recursively) several different >> media types into a single CoAP message-body with minimal framing >> overhead, along with a CoAP Content-Format identifier. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=_1c965083b32967a55b0041c0a7f18ad2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Carsten et al.

I have looked at the multipart draft, and I am= happy to see that the CBOR array is maintained as proposed in est-coaps.So now we have two drafts that both propose an almost identical new med= ia type.

The choice will be determined by the delay needed to (p= re-)register the new media type.
Will anyone start doing that for the = multipart draft within a foreseeable delay.
If not, I am happy to pre-= register the new media type as specified in coaps-est to avoid delaying est= -coaps.

Looking forward to your reaction,

many thanks= for your trouble to create an indenpendent draft.

peter

Carsten Bormann schreef op 2018-06-05 16:55:

= In https://github.com/SanKumar2015/EST-coaps/pull/5= 0, Klaus has proposed to introduce a media type for efficiently combini= ng multiple representations, along with the Content-Format numbers of their= media types, into a single representation.

I believe we have n= eeded such a media type in other places, so I have extracted the content of= that PR, and revved draft-fossati-core-multipart-ct (of 2013 vintage) with= that.  This would give us a media type multipart/core for general use= =2E  (Thanks are due to Klaus and Thomas for helping me with this litt= le exercise.)

CoAP-EST is due to be finished very soon, and ext= racting this media type from the CoAP-EST draft should only be done if we c= an avoid creating a hazard for CoAP-EST to be delayed by this.

= I don't see such a hazard unless we are having fundamental problems with th= e approach (but do accept its limited use in the CoAP-EST space).
So = it would be useful to get some quick reactions on whether we can go ahead w= ith this.

If you don't want to read the draft right now, its te= chnical content is:
   multipart-core =3D [* multipart= -part]
   multipart-part =3D (type: uint .size 2, part= : bytes / null)

(Where "type" is the content-format identifier= =2E)

Grüße, Carsten


Name:        draft-= fossati-core-multipart-ct
Revision:    04
Title:=        Multipart Content-Format for CoA= P
Document date:    2018-06-05
Group:  &nbs= p;     Individual Submission
Pages:  &n= bsp;     5
URL:     &nbs= p;      https://www.ietf.org/internet-drafts/draft-fossati-core-multip= art-ct-04.txt
Status:        &= nbsp;https://datatracker.ietf.org/d= oc/draft-fossati-core-multipart-ct/
Htmlized:    &= nbsp;  https://tools.ietf.or= g/html/draft-fossati-core-multipart-ct-04
Htmlized:   &= nbsp;   https://= datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct
Dif= f:           https://www.ietf.org/rfcdiff?url2=3Ddraft-= fossati-core-multipart-ct-04

Abstract:
  Th= is memo defines multipart/core, an application-independent media-
&nb= sp; type that can be used to combine (even recursively) several differ= ent
  media types into a single CoAP message-body with mini= mal framing
  overhead, along with a CoAP Content-Format id= entifier.


_______________________________________________
core mai= ling list
core@iet= f.org
https://www.ietf.org/mailman/listinfo/core<= /a>
--=_1c965083b32967a55b0041c0a7f18ad2-- From nobody Tue Jun 5 10:50:14 2018 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 709A0131119 for ; Tue, 5 Jun 2018 10:50:07 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCpSNUjE7T3K for ; Tue, 5 Jun 2018 10:50:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8F913113E for ; Tue, 5 Jun 2018 10:50:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ED81120091 for ; Tue, 5 Jun 2018 14:03:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 831D32F98; Tue, 5 Jun 2018 13:49:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8005A2F86 for ; Tue, 5 Jun 2018 13:49:25 -0400 (EDT) From: Michael Richardson To: core@ietf.org In-Reply-To: References: <20273.1527881373@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 17:50:08 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jaime... Carsten, Thomas and Klaus have just updated: which says very succintly: The collection is encoded as a CBOR [RFC7049] array with an even number of elements. The second, fourth, sixth, etc. element is a byte string containing a representation, or the value "null" if an optional part is indicated as not given. The first, third, fifth, etc. element is an unsigned integer specifying the content format= ID of the representation following it. For example, a collection containing two representations, one with content format ID 42 and one with content format ID 0, looks like this in CBOR diagnostic notation: [42, h'0123456789abcdef', 0, h'3031323334'] EST-COAP (in the ACE WG) needs a multipart reply for the corner case of server generated (private) keys. Servergen is supported in RFC7030, greatly desired by some parties, although some parties deem it a mis-feature. I can't see anything wrong with the draft as it is, and I'd like to see it quickly adopted and WGLC'ed.... =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxbNIoCLcPvd0N1lAQJQmAf+McOr49PTH8YirzUkOePHeGStvRRBY79J oENTPaeX6hTWbHA6dOw2meSJ18ibK/+WEDGHNoBGNVk+iyWEfHZIIa61U/F4Gbks M8ayRJgpW4qBF4Bb1kG+eAdfrNTu9BWgIAqwPim2aRXk0MpyxvL6LJT6pRI+U11u Nfo/OMAXsrxHxI8xp+mmKkk63hBBFJEPZSVmIvrOW6XXEvJL49aicdcotVlGfFzr GztDXj2BFFZelDg2mqu9LAzM8nfNmaWAp0yYfxKBdhhcnHB/GbUjdfm2yUbAVk5r QGeclsiNU2VYXnGlqfDPrjNnFDP6Uc/ryRlHXSDSGvvsndESIw6Kjg== =BioY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 5 11:04:47 2018 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 DD4971292AD; Tue, 5 Jun 2018 11:04:40 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL0fqSoZWiAm; Tue, 5 Jun 2018 11:04:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464CC126F72; Tue, 5 Jun 2018 11:04:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B25020091; Tue, 5 Jun 2018 14:18:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A8D7D2F8F; Tue, 5 Jun 2018 14:04:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A6D1C2F86; Tue, 5 Jun 2018 14:04:03 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: core , ace In-Reply-To: <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> References: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Ace] New Version of draft-fossati-core-multipart-ct-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 18:04:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > I believe we have needed such a media type in other places, so I have > extracted the content of that PR, and revved > draft-fossati-core-multipart-ct (of 2013 vintage) with that. This > would give us a media type multipart/core for general use. (Thanks a= re > due to Klaus and Thomas for helping me with this little exercise.)=20 > CoAP-EST is due to be finished very soon, and extracting this media > type from the CoAP-EST draft should only be done if we can avoid > creating a hazard for CoAP-EST to be delayed by this. > I don=E2=80=99t see such a hazard unless we are having fundamental pr= oblems > with the approach (but do accept its limited use in the CoAP-EST > space). =20=20=20=20 > So it would be useful to get some quick reactions on whether we can go > ahead with this. I'm very happy, as I posted in another message before I sync'ed my inbox and got yours. I also have use of this multipart/core in the constrained extensions to BRSKI contained in 6tisch-dtsecurity-zerotouch. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxbQkYCLcPvd0N1lAQKxsgf/e2Y3iIUXpNtynT+CvjwX1Yd1KWfBeBuS ni93laKgCA4PKoxUqD9/CWpn+iwLWYyPOYucOCxfO4T88MwwGPnMqq0RISNtUtaN 5Cp9Nu7vgxaKh8PfOMjrJQ/l3T2pcsB2BH+t2oER5qh83pGovuRcfZrgs/Xoywjh Zq+820zZXRbv6m4tt9cF0FmTwALnfHVNDQzTh1EN3Yp+P/Gjls0am+PVTKI4kzUk 6phpsJtbsaZanqq6VJlEfNikd69LoEEF4Lie0Q9CWQwKeL9a+wb7NM8RjgpBZYXn nJu5zgiBSdTCgRW14gh+giCDAu1AUmHix7IbzVNCqUBYeNUc6Ew8ww== =NOaa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 6 02:11:01 2018 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 4FF61130F01 for ; Wed, 6 Jun 2018 02:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 wXQ6ZW9FTY5M for ; Wed, 6 Jun 2018 02:10:41 -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 7ABD1130ECC for ; Wed, 6 Jun 2018 02:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528276238; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IUID+4L//FsDiTr2aXqGhrycJ9+jEINPlBFwGIr0I60=; b=Xpckc64iGM+MwxMP0Lh9tTQ7ULXPtkC1Wa8HMvlclcrtgzwZSC/jhgsVGG6iPfxr izXYPGDbXX7t+ftuRMzd6ZbhoKlL3+yH+OCJVhU2idmvmpy4QZ14rqeK4ERUuPGP PqOoQ7s3AugIqmtt/Jaf/pSXo1PyyI+zzkiQTwckXQA=; X-AuditID: c1b4fb25-703639c000003465-4c-5b17a50ec135 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E2.B2.13413.E05A71B5; Wed, 6 Jun 2018 11:10:38 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSHC012.ericsson.se (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 6 Jun 2018 11:10:38 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Jun 2018 11:10:37 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Wed, 6 Jun 2018 11:10:37 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Michael Richardson CC: core , Jim Schaad Thread-Topic: [core] multipart/core Thread-Index: AQHT/PXI0FigUnm0CEeFCM5FAfiJd6RS0QMA Date: Wed, 6 Jun 2018 09:10:37 +0000 Message-ID: <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> References: <20273.1527881373@localhost> <5727.1528220965@localhost> In-Reply-To: <5727.1528220965@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/signed; boundary="Apple-Mail=_12380748-E56B-42F6-A9AF-202B57D8B11C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbHdTJdvqXi0wckOY4t9b9czW6ye/p3N oudQP7sDs8fGOdPZPJYs+cnk0TJnD3MAcxSXTUpqTmZZapG+XQJXxuUba1kL+lMqJl66ytbA +COqi5GTQ0LAROLe75fsXYxcHEICRxgl7m44zwjhbGaUWNXSyQrhfGWU+Ny0gQ3CWcoosfDb DWaQfjYBZ4lPzxrZQWwRAT2J5UeeMYLYzAK2Eu+W32ABsYUFlCTubN0MVaMssXz+eaBeDiDb SKL1mh9ImEVAReLPj69g5bwC9hLHXrVCndTCJLF31n6wXZwCGhKf7i5iBbEZBcQkvp9awwSx S1zi1pP5TBD/iEg8vHiaDcIWlXj5+B8rhK0ksffYdRaQocwCUxglDr25zw6xTVDi5MwnYJuF BNQlvs26zTyBUXwWkrmzkPXMQtIDUZQkMe3HZCYIW1ti2cLXzBC2psT+7uUsmOIaEp3fJrJC 2KYSr49+ZISwrSVm/DrIBmErSkzpfsi+gJF7FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg cji45bfqDsbLbxwPMQpwMCrx8F5fLB4txJpYVlyZe4hRBWjOow2rLzBKseTl56UqifAmXhKL FuJNSaysSi3Kjy8qzUktPsQozcGiJM770HxzlJBAemJJanZqakFqEUyWiYNTqoGx2OTCEZ/1 kfvr+68wZqZu45Vmfu7glcq1sGWfWIHI1Dd7dj/W6Q2YO78/Vu+vfeipYFX90l3CV31/Lnyw k4fxf7PLZovC6HLBf+8WNu9O5DLxeWH0bs2zy9K90VdlGAIWxUdc9PmtdePKjrNM67V+xB7f 583ztEb4UfvzBCe3n1l7khdatUxSYinOSDTUYi4qTgQAOUz39RYDAAA= Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 09:10:58 -0000 --Apple-Mail=_12380748-E56B-42F6-A9AF-202B57D8B11C Content-Type: multipart/alternative; boundary="Apple-Mail=_742793D3-0ACD-4819-A5B1-4BD712EEFD18" --Apple-Mail=_742793D3-0ACD-4819-A5B1-4BD712EEFD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, the draft does indeed pretty straightforward and short, EST-COAP is not = yet in WCLC or similar but if the ACE Chairs have some deadline in mind = please let us know, to give enough time to the group to move this = document forward. Ciao, - - Jaime Jim=C3=A9nez > On 5 Jun 2018, at 20.49, Michael Richardson = wrote: >=20 >=20 > Jaime... >=20 > Carsten, Thomas and Klaus have just updated: > > which says very succintly: >=20 > The collection is encoded as a CBOR [RFC7049] array with an even > number of elements. The second, fourth, sixth, etc. element is a > byte string containing a representation, or the value "null" if an > optional part is indicated as not given. The first, third, > fifth, etc. element is an unsigned integer specifying the content = format ID > of the representation following it. >=20 > For example, a collection containing two representations, one with > content format ID 42 and one with content format ID 0, looks like > this in CBOR diagnostic notation: >=20 > [42, h'0123456789abcdef', 0, h'3031323334'] >=20 >=20 > EST-COAP (in the ACE WG) needs a multipart reply for the corner case = of > server generated (private) keys. Servergen is supported in RFC7030, = greatly > desired by some parties, although some parties deem it a mis-feature. >=20 > I can't see anything wrong with the draft as it is, and I'd like to = see it > quickly adopted and WGLC'ed.... >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_742793D3-0ACD-4819-A5B1-4BD712EEFD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michael,

the draft = does indeed pretty straightforward and short, EST-COAP is not yet in = WCLC or similar but if the ACE Chairs have some deadline in mind please = let us know, to give enough time to the group to move this document = forward.

Ciao,
- - Jaime Jim=C3=A9nez

On 5 Jun 2018, at 20.49, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Jaime...

Carsten, Thomas and = Klaus have just updated:
  <https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04<= /a>>
which says very succintly:

  The collection is encoded as a CBOR [RFC7049] = array with an even
  number of elements. =  The second, fourth, sixth, etc. element is a
=   byte string containing a representation, or the value "null" = if an
  optional part is indicated as not = given.  The first, third,
  fifth, etc. = element is an unsigned integer specifying the content format ID
  of the representation following it.

  For example, a collection = containing two representations, one with
=   content format ID 42 and one with content format ID 0, looks = like
  this in CBOR diagnostic notation:

     [42, = h'0123456789abcdef', 0, h'3031323334']


EST-COAP (in the ACE WG) needs a multipart reply for the = corner case of
server generated (private) keys. Servergen = is supported in RFC7030, greatly
desired by some parties, = although some parties deem it a mis-feature.

I can't see anything wrong with the draft as it is, and I'd = like to see it
quickly adopted and WGLC'ed....

--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh networks [
] =   Michael Richardson, Sandelman Software Works =        | network architect  [ =
]     mcr@sandelman.ca =  http://www.sandelman.ca/ =        |   ruby on rails =    [

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

= --Apple-Mail=_742793D3-0ACD-4819-A5B1-4BD712EEFD18-- --Apple-Mail=_12380748-E56B-42F6-A9AF-202B57D8B11C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDYwNjA5MTAzNlowIwYJKoZIhvcNAQkEMRYEFKRs0Z2AVfzKLRqSHyBlvGCrD/SI MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAHgeoh2ZqY4bIPclBNLSMQGhk0dgzTO0AuxN0JIgkpfnzafO++Ql0Ik/nMnzUxIJk AahHpYn/iErGRIc0XZCO0H7IUtNNcFpw0xS8nfBbR3LZeQauHtMRDu3GIayRwD457D3K9Hk1/3+8 Ewk4H7gebqn9GknRLxGpj34cifuxUXF9/8Wmmw+tgm3++ZlLovpWL2ML2Hiht+cHTD2WJewltAoS zj+6KFl29YeKdQcs+UhrrbqYwMlg5chWnEG0Vse+39DboOh11eXQK3sucNP1G7bXBtJNYX6YTBry TD5TiRG4AfT6PnCwtZQhdKP80QBfdM8H8B4Y+/E6G2jM3PehNwAAAAAAAA== --Apple-Mail=_12380748-E56B-42F6-A9AF-202B57D8B11C-- From nobody Wed Jun 6 02:14:49 2018 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 C527E130ECE for ; Wed, 6 Jun 2018 02:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 qqhaND0NPycF for ; Wed, 6 Jun 2018 02:14:40 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98683130E3F for ; Wed, 6 Jun 2018 02:14:40 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 92B5D182CF673; Wed, 6 Jun 2018 09:14:39 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:72:146:152:355:379:582:599:800:960:962:967:973:983:988:989:1042:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2282:2525:2527:2528:2553:2557:2561:2568:2629:2682:2685:2859:2895:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3586:3622:3769:3770:3865:3866:3867:3868:3870:3871:3872:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4119:4250:4321:4605:4659:4860:5007:6117:6248:6261:6657:6659:6678:7464:7875:7903:8603:9010:9025:9040:9177:9388:10004:10848:11232:11658:11914:12043:12291:12379:12438:12555:12683:12740:12895:12926:12986:13139:13161:13229:13846:14095:14180:14181:14721:21060:21080:21326:21433:21451:21611:21627:21691:21740:30034:30054:30060:30080:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, X-HE-Tag: sheep59_45b66dffd8d2b X-Filterd-Recvd-Size: 8975 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Wed, 6 Jun 2018 09:14:39 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_be1a9e804e0f16543b48ed0e4e08d83c" Date: Wed, 06 Jun 2018 11:14:38 +0200 From: Peter van der Stok To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Cc: Michael Richardson , core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.135.186] Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 09:14:46 -0000 --=_be1a9e804e0f16543b48ed0e4e08d83c Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Jaime, The draft est-coaps is an ACE WG draft The multipart core is a personal draft; not CoRE yet. I would be very much reassured if the WG adoption of multipart core takes place shortly. The WGLC of est-coaps may well be around ietf102. greetings, Peter Jaime Jiménez schreef op 2018-06-06 11:10: > Hi Michael, > > the draft does indeed pretty straightforward and short, EST-COAP is not yet in WCLC or similar but if the ACE Chairs have some deadline in mind please let us know, to give enough time to the group to move this document forward. > > Ciao, > > - - Jaime Jiménez > >> On 5 Jun 2018, at 20.49, Michael Richardson wrote: >> >> Jaime... >> >> Carsten, Thomas and Klaus have just updated: >> >> which says very succintly: >> >> The collection is encoded as a CBOR [RFC7049] array with an even >> number of elements. The second, fourth, sixth, etc. element is a >> byte string containing a representation, or the value "null" if an >> optional part is indicated as not given. The first, third, >> fifth, etc. element is an unsigned integer specifying the content format ID >> of the representation following it. >> >> For example, a collection containing two representations, one with >> content format ID 42 and one with content format ID 0, looks like >> this in CBOR diagnostic notation: >> >> [42, h'0123456789abcdef', 0, h'3031323334'] >> >> EST-COAP (in the ACE WG) needs a multipart reply for the corner case of >> server generated (private) keys. Servergen is supported in RFC7030, greatly >> desired by some parties, although some parties deem it a mis-feature. >> >> I can't see anything wrong with the draft as it is, and I'd like to see it >> quickly adopted and WGLC'ed.... >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | network architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> >> _______________________________________________ >> 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 --=_be1a9e804e0f16543b48ed0e4e08d83c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Jaime,

The draft est-coaps is an ACE WG draft
The multip= art core is a personal draft; not CoRE yet.
I would be very much reass= ured if the WG adoption of multipart core takes place shortly.

T= he WGLC of est-coaps may well be around ietf102.

greetings,

Peter

Jaime Jiménez schreef op 2018-06-06 11:10:

Hi Michael,
 
the draft does indeed pretty straightforward and short, EST-COAP is no= t yet in WCLC or similar but if the ACE Chairs have some deadline in mind p= lease let us know, to give enough time to the group to move this document f= orward.
 
Ciao,
- - Jaime Jiménez

On 5 Jun 2018, at 20.49, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Jaime...

Carsten, Thomas and Klaus have just updated:=
  <https://tools= =2Eietf.org/html/draft-fossati-core-multipart-ct-04>
which says= very succintly:

  The collection is encoded as a CBO= R [RFC7049] array with an even
  number of elements.  = The second, fourth, sixth, etc. element is a
  byte string = containing a representation, or the value "null" if an
  op= tional part is indicated as not given.  The first, third,
 =  fifth, etc. element is an unsigned integer specifying the content for= mat ID
  of the representation following it.

&n= bsp; For example, a collection containing two representations, one wit= h
  content format ID 42 and one with content format ID 0, = looks like
  this in CBOR diagnostic notation:

=      [42, h'0123456789abcdef', 0, h'3031323334']

EST-COAP (in the ACE WG) needs a multipart reply for the co= rner case of
server generated (private) keys. Servergen is supported i= n RFC7030, greatly
desired by some parties, although some parties deem= it a mis-feature.

I can't see anything wrong with the draft as = it is, and I'd like to see it
quickly adopted and WGLC'ed....
--
]           &= nbsp;   Never tell me the odds!     &nbs= p;           | ipv6 = mesh networks [
]   Michael Richardson, Sandelman Software = Works        | network architect  [=
]     mcr@sandelman.ca  http://www.sandelman.ca/  &= nbsp;     |   ruby on rails   =  [
<= /span>
_______________________________________________
core maili= ng list
core@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/core

= _______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--=_be1a9e804e0f16543b48ed0e4e08d83c-- From nobody Wed Jun 6 02:34:35 2018 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 2CBDC130EDB for ; Wed, 6 Jun 2018 02:34:29 -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 buyIiZNvIJ7g for ; Wed, 6 Jun 2018 02:34:25 -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 6864D130EE5 for ; Wed, 6 Jun 2018 02:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w569YI8b025105; Wed, 6 Jun 2018 11:34:18 +0200 (CEST) Received: from client-0196.vpn.uni-bremen.de (client-0196.vpn.uni-bremen.de [134.102.107.196]) (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 4113Qy30vtzDXJw; Wed, 6 Jun 2018 11:34:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 6 Jun 2018 11:34:17 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , Michael Richardson , core X-Mao-Original-Outgoing-Id: 549970455.530872-d6b76e225bd900717b4dafe74f1d4d38 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> To: peter van der Stok X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 09:34:29 -0000 On Jun 6, 2018, at 11:14, Peter van der Stok = wrote: >=20 > Hi Jaime, >=20 > The draft est-coaps is an ACE WG draft > The multipart core is a personal draft; not CoRE yet. > I would be very much reassured if the WG adoption of multipart core = takes place shortly. >=20 > The WGLC of est-coaps may well be around ietf102. Right, and there is little reason to wait finishing multipart/core until = est-coaps is finished. The idea of multipart/core is really well-aged now; I think the only = reason why we haven=E2=80=99t written it down yet was that we didn=E2=80=99= t have a use case. Now we seem to have two, and we should be able to go ahead with = multipart/core very quickly. Gr=C3=BC=C3=9Fe, Carsten >=20 > greetings, >=20 > Peter > Jaime Jim=C3=A9nez schreef op 2018-06-06 11:10: >=20 >> Hi Michael, >> =20 >> the draft does indeed pretty straightforward and short, EST-COAP is = not yet in WCLC or similar but if the ACE Chairs have some deadline in = mind please let us know, to give enough time to the group to move this = document forward. >> =20 >> Ciao, >> - - Jaime Jim=C3=A9nez >>=20 >>> On 5 Jun 2018, at 20.49, Michael Richardson = wrote: >>>=20 >>> Jaime... >>>=20 >>> Carsten, Thomas and Klaus have just updated: >>> >>> which says very succintly: >>>=20 >>> The collection is encoded as a CBOR [RFC7049] array with an even >>> number of elements. The second, fourth, sixth, etc. element is a >>> byte string containing a representation, or the value "null" if an >>> optional part is indicated as not given. The first, third, >>> fifth, etc. element is an unsigned integer specifying the content = format ID >>> of the representation following it. >>>=20 >>> For example, a collection containing two representations, one with >>> content format ID 42 and one with content format ID 0, looks like >>> this in CBOR diagnostic notation: >>>=20 >>> [42, h'0123456789abcdef', 0, h'3031323334'] >>>=20 >>>=20 >>> EST-COAP (in the ACE WG) needs a multipart reply for the corner case = of >>> server generated (private) keys. Servergen is supported in RFC7030, = greatly >>> desired by some parties, although some parties deem it a = mis-feature. >>>=20 >>> I can't see anything wrong with the draft as it is, and I'd like to = see it >>> quickly adopted and WGLC'ed.... >>>=20 >>> --=20 >>> ] Never tell me the odds! | ipv6 mesh = networks [=20 >>> ] Michael Richardson, Sandelman Software Works | network = architect [=20 >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=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 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jun 6 07:06:47 2018 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 0E2DE130F2A for ; Wed, 6 Jun 2018 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gt0fDH3DFBxQ for ; Wed, 6 Jun 2018 07:06:38 -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 544B0130F20 for ; Wed, 6 Jun 2018 07:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528293996; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z0r4IVJjDuOHbM4rUG0gRqK++wAlOA2Fs8cTkELLRHg=; b=aHPPdvb9oGvFvkdBV9+8Ng1SQDfkLtX7+DkuZHfUCvNyYof5SToVaDnk4PtOguOv EPa9Fsec98ilhKzaOxPF424ojbnk7ODkrhLOTfQalenjpgzLDweOYTRSNY1m7esv d4mz9j+o/USfVsYVLh2Q0v93QavqwYBQbOztLbJpuhg=; X-AuditID: c1b4fb25-31dff70000003465-36-5b17ea6cb527 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FF.9A.13413.C6AE71B5; Wed, 6 Jun 2018 16:06:36 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC016.ericsson.se (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 6 Jun 2018 16:06:36 +0200 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Jun 2018 16:06:36 +0200 Received: from ESESBMB505.ericsson.se ([153.88.183.188]) by ESESBMB505.ericsson.se ([153.88.183.188]) with mapi id 15.01.1466.003; Wed, 6 Jun 2018 16:06:35 +0200 From: Mert Ocak To: "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAhG46AAWOgH0D//+5SgIAaqQwAgAh+xAA= Date: Wed, 6 Jun 2018 14:06:35 +0000 Message-ID: <793E8C96-B37F-421C-8712-98BEEF7FC867@ericsson.com> References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> In-Reply-To: <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: <854825EA1CB7BF4AA3CBCD7424546BF7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7k27OK/Fog6lTtCwe7V/FZrHv7Xpm ByaPJUt+MnmcaNjOHsAUxWWTkpqTWZZapG+XwJWx+/w5poIZKhW/ps9naWBcoNzFyMkhIWAi cWrXdJYuRi4OIYEjjBLNp44xQzibGSX+7VjDAlIlJPCVUeL7/gCIxFJGift9rawgCTYBDYld /VeZQGwRAWWJzWdeM4LYzAK2Eju+bGEHsYUFQiTaTkxlhKgJlVj97QwLhO0ncf7kZLA4i4CK xOWJ28Hm8ArYS8xfuIgJYvFjJokPS/xAbE4BS4lPx1azgdiMAmIS30+tYYLYJS5x68l8Joh3 BCSW7DnPDGGLSrx8/A/sTlEBPYmenVfZIOJKElt6twDVcwD1akqs36UPYVpLzD9nBzFRUWJK 90N2iGsEJU7OfAINBmWJp+9XsU5glJqFZPEshEGzEAbNQjJoFpJBCxhZVzGKFqcWJ+WmGxnr pRZlJhcX5+fp5aWWbGIExuzBLb9VdzBefuN4iFGAg1GJh3fSU/FoIdbEsuLK3EOMEhzMSiK8 iZfEooV4UxIrq1KL8uOLSnNSiw8xSnOwKInzPjTfHCUkkJ5YkpqdmlqQWgSTZeLglGpgNDv4 91v0ftE1a/nZdlhPj3IwmPLfdanM7ZQujd0KR/S5Z9qmGAbvnvlbpTQ6q1H1RqzSY6ar99a/ WX6iMELjD8//O/HlETc9Vj20Ur8j8f7RmV3T9d7qdbw7tmbflg/JGS8FD1Uz512VLT7AsUtZ dcFFdoU8PpHaHclstZHihw5cnrn/5OfHO5VYijMSDbWYi4oTAUtZFVvVAgAA Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 14:06:43 -0000 SGksDQoNCkNvbmZpcm1pbmcgdGhlIGVuZHBvaW50IG5hbWUgd2l0aCB0aGUgc2VjdXJpdHkgY29u dGV4dCBzb3VuZHMgcmVhc29uYWJsZSBidXQgaW50cm9kdWNpbmcgYSBNVVNUIGZvciBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciBpcyBxdWl0ZSBhIGJpZyBjaGFuZ2UsIHdoaWNoIEkgdGhpbmsgd2Ug c2hvdWxkIGF2b2lkLiBBQ0UtT2F1dGggY291bGQgYmUgb25lIG9mIHRoZSB3YXlzIHRoZSBSRCBz dXBwb3J0cyBmb3IgZW5kcG9pbnQgYXV0aGVudGljYXRpb24gYnV0IHdlIHNob3VsZCBub3QgaW52 YWxpZGF0ZSBvdGhlciBvcHRpb25zIHRoZSBSRCBpbiBkaWZmZXJlbnQgdXNlIGNhc2VzIGNhbiB1 c2UgZm9yIGF1dGhlbnRpY2F0aW9uLCBzdWNoIGFzIFBTSywgUlBLIG9yIENlcnRpZmljYXRlcyBh cyBIYW5uZXMgbWVudGlvbmVkLg0KDQpDaGVlcnMsDQpNZXJ0DQoNCg0K77u/T24gMDEvMDYvMjAx OCwgMTAuMjMsICJjb3JlIG9uIGJlaGFsZiBvZiBwZXRlciB2YW4gZGVyIFN0b2siIDxjb3JlLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHN0b2tjb25zQHhzNGFsbC5ubD4gd3JvdGU6DQoN CiAgICBIaSBIYW5uZXMsIE1hdHRoaWFzLA0KICAgIA0KICAgIEJlbG93IGEgcHJvcG9zYWwgZm9y IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGluIHRoZSBSRCBkcmFmdA0KICAg IA0KICAgIHRoZSBsYXN0IHBhcmFncmFwaDoNCiAgICAiVGhlcmVmb3JlLCBFbmRwb2ludHMgTVVT VCBpbmNsdWRlIHRoZQ0KICAgIEVuZHBvaW50IGlkZW50aWZpZXIgaW4gdGhlIG1lc3NhZ2UsIGFu ZCB0aGlzIGlkZW50aWZpZXINCiAgICBNVVNUIGJlIGNoZWNrZWQgYnkgYSByZXNvdXJjZSBkaXJl Y3RvcnkgdG8gbWF0Y2ggdGhlIEVuZHBvaW50IGlkZW50aWZpZXINCiAgICBpbmNsdWRlZCBpbiB0 aGUgUmVnaXN0cmF0aW9uIG1lc3NhZ2UuIg0KICAgIA0KICAgIHRvIGJlIHJlcGxhY2VkIHdpdGg6 DQogICAgIkEgY2xpZW50IE1VU1Qgb2J0YWluIGFuIGFjY2VzcyB0b2tlbiBmcm9tIGFuIGF1dGhv cml6YXRpb24gc2VydmVyIA0KICAgIFtkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoel0uIEZvciBt b3N0IGluc3RhbGxhdGlvbnMgdGhlIG5hbWUgb2YgdGhlIA0KICAgIGVuZHBvaW50IGRvZXMgbm90 IG5lZWQgdG8gYmUgc2VtYW50aWNhbGx5IG1lYW5pbmdmdWwuIEZvciB0aG9zZSANCiAgICBpbnN0 YWxsYXRpb25zIHRoZSBlbmRwb2ludCBuYW1lIE1VU1QgYmUgZXF1YXRlZCB0byB0aGUgc2VjdXJp dHkgDQogICAgaWRlbnRpZmllciB0cmFuc3BvcnRlZCBpbiB0aGUgYWNjZXNzIHRva2VuLiBGb3Ig aW5zdGFsbGF0aW9ucyB3aGVyZSB0aGUgDQogICAgZW5kcG9pbnQgbmFtZSBtdXN0IHJlZmxlY3Qg dGhlIG5hbWVzIG9mIGNvbXBvbmVudHMgb2YgdGhlIGluc3RhbGxhdGlvbiwgDQogICAgdGhlIGFj Y2VzcyB0b2tlbiBNVVNUIGNvbnRhaW4gdGhlIHZhbHVlcyBvZiB0aGUgZW5kcG9pbnQgbmFtZSBh bmQgdGhlIA0KICAgIG9wdGlvbmFsIGRvbWFpbiBuYW1lLiBBIGNvbXBhbmlvbiBkb2N1bWVudCBT SE9VTEQgZGVzY3JpYmUgdGhlIGZvcm1hdCBvZiANCiAgICB0aGUgYWNjZXNzIHRva2VucywgdGhl IG5lZ290aWF0aW9uIGJldHdlZW4gY2xpZW50IGFuZCBBdXRob3JpemF0aW9uIA0KICAgIHNlcnZl ciwgYW5kIHRoZSB0cmVhdG1lbnQgb2YgdGhlIHRva2VuIGJ5IHRoZSBSRCBzZXJ2ZXIuIg0KICAg IA0KICAgIFdpbGwgdGhhdCBiZSBzdWZmaWNpZW50IGZvciB5b3U7IG9yIGRvIHlvdSB3YW50IG1v cmUgZGV0YWlsZWQgdGV4dCBsaWtlIA0KICAgIHlvdXJzIGJlbG93Pw0KICAgIExvb2tpbmcgZm9y d2FyZCB0byB5b3VyIGltcHJvdmVtZW50cywNCiAgICANCiAgICB0aGFua3MsDQogICAgDQogICAg cGV0ZXINCiAgICANCiAgICBIYW5uZXMgVHNjaG9mZW5pZyBzY2hyZWVmIG9wIDIwMTgtMDUtMTUg MTA6MTU6DQogICAgPiBASGFubmVzOiBDb3VsZCB5b3UgcHJvdmlkZSBzb21lIG1vcmUgZGV0YWls LCBob3cgZXhhY3RseSB0aGUgRW5kcG9pbnQNCiAgICA+IENsaWVudCBOYW1lIGlzIGV4dHJhY3Rl ZCBmcm9tICJzZWN1cml0eSBjb250ZXh0Ij8gT3ZlcmFsbCwgSSBsaWtlDQogICAgPiB0aGlzLCBi dXQgd2Ugc2hvdWxkIHByb3ZpZGUgY29uY3JldGUgdGV4dCBvbiBob3cgcGVvcGxlIHNob3VsZCBk byBpdC4NCiAgICA+IA0KICAgID4gWW91IHdhbnQgdG8gc3RvcmUgdGhlIHNlY3VyaXR5IGNvbnRl eHQgb24gdGhlIHNlcnZlciBzaWRlIGFuZCB0aGUNCiAgICA+IEVuZHBvaW50IENsaWVudCBOYW1l IHBvaW50cyB0byB0aGUgaWRlbnRpZmllciBwYXJ0IG9mIGl0Lg0KICAgID4gKE90aGVyIHBhcnRz IG9mIHRoZSBzZWN1cml0eSBjb250ZXh0IHdpbGwgYmUgcmVsZXZhbnQgZm9yIG90aGVyIA0KICAg ID4gcHVycG9zZXMuKQ0KICAgID4gDQogICAgPiAgKiBGb3IgUFNLLWJhc2VkIGNyZWRlbnRpYWwg dGhlIEVuZHBvaW50IENsaWVudCBOYW1lIGJlY29tZXMgdGhlIFBTSyANCiAgICA+IElkZW50aXR5 DQogICAgPiAgKiBGb3IgcmF3LXB1YmxpYyBrZXlzIHRoZSBFbmRwb2ludCBDbGllbnQgTmFtZSBi ZWNvbWVzIHRoZQ0KICAgID4gU3ViamVjdFB1YmxpY0tleUluZm8gc3RydWN0dXJlIChvciBhIGhh c2ggb2YgaXQpLg0KICAgID4gICogRm9yIGNlcnRpZmljYXRlcyB0aGUgRW5kcG9pbnQgQ2xpZW50 IE5hbWUgYmVjb21lcyB0aGUgbGVmdG1vc3QgQ04NCiAgICA+IGNvbXBvbmVudCBvZiBzdWJqZWN0 IG5hbWUgb3IgdGhlIFN1YmplY3RBbHROYW1lIG9mIHRoZSBjZXJ0aWZpY2F0ZSwNCiAgICA+IGRl cGVuZGluZyBvbiB3aGF0IHlvdSB1c2UuDQogICAgPiANCiAgICA+IENpYW8NCiAgICA+IEhhbm5l cw0KICAgID4gDQogICAgPiANCiAgICA+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlDQogICAgPiBjb25maWRlbnRpYWwg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0K ICAgID4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRvIG5vdCBkaXNjbG9zZQ0KICAgID4gdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yDQogICAgPiBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBjb3JlIG1haWxpbmcgbGlz dA0KICAgIGNvcmVAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NvcmUNCiAgICANCg0K From nobody Wed Jun 6 07:44:26 2018 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 3C24D130F4D for ; Wed, 6 Jun 2018 07:44:22 -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, 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 4Mri5DjVyxEZ for ; Wed, 6 Jun 2018 07:44:20 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 50474130DCA for ; Wed, 6 Jun 2018 07:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1528296259; d=isode.com; s=june2016; i=@isode.com; bh=lzeW+wapTFRkzVRNH4r/6Avj7fGdxohhrfPX1Oe93dY=; 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=JkmghiUJ9UX+brVj86LiCzxTVx8TtNf0TrSFI+X2mrFy3TgFm45TeqRLiRAUY4GcvvaSjq uINBCHSWucXpVL8fTwX/b/2J4dmJ9MMt37mxxu7DNtGbOZQZsIeNWoRqoNuBbUDCvcUaea yEGsqQHY8C5aRJJriOcXf8ZahM/e9PE=; 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, 6 Jun 2018 15:44:19 +0100 To: Carsten Bormann , peter van der Stok Cc: Michael Richardson , core References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> From: Alexey Melnikov Message-ID: <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> Date: Wed, 6 Jun 2018 15:44:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 14:44:23 -0000 Hi, I would like to quickly insert AD interrupt. I had a quick look at draft-fossati-core-multipart-ct-04 and I think the proposed definition of multipart/core is syntactically incompatible with MIME. Please read sections 5.1 and 5.1.1 of RFC 2046. In particular, all multipart media types have to use syntax specified in RFC 2046, which this proposal violates. To be clear, I am not against registering a media type which uses CBOR syntax for a collection of other media types. However this media type name can't use the "multipart" top level media type. You can either define a new "application" media type (e.g. application/multipart-core) or you can define a new top level media type different from "multipart". The process for definining a new top level media type is slightly more comlicated, so you should evaluate whether you want to do this. Best Regards, Alexey From nobody Wed Jun 6 07:55:16 2018 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 3C109130F4C for ; Wed, 6 Jun 2018 07:55:13 -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 Y8o6szp5EZFJ for ; Wed, 6 Jun 2018 07:55:10 -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 A71B8130DCA for ; Wed, 6 Jun 2018 07:55:09 -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 w56Et1En006853; Wed, 6 Jun 2018 16:55:01 +0200 (CEST) Received: from client-0208.vpn.uni-bremen.de (client-0208.vpn.uni-bremen.de [134.102.107.208]) (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 411BY16DJYzDXNF; Wed, 6 Jun 2018 16:55:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> Date: Wed, 6 Jun 2018 16:54:54 +0200 Cc: peter van der Stok , Michael Richardson , core X-Mao-Original-Outgoing-Id: 549989692.617427-7e63420c2527ce9afa3684303b14b36e Content-Transfer-Encoding: quoted-printable Message-Id: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 14:55:14 -0000 Hi Alexey, On Jun 6, 2018, at 16:44, Alexey Melnikov = wrote: >=20 > Hi, > I would like to quickly insert AD interrupt. getting input from the media type (and core-parameters) experts would = have been next on the list. Thank you for accelerating that input a lot :-) > I had a quick look at draft-fossati-core-multipart-ct-04 and I think = the proposed definition of multipart/core is syntactically incompatible = with MIME. Please read sections 5.1 and 5.1.1 of RFC 2046. In = particular, all multipart media types have to use syntax specified in = RFC 2046, which this proposal violates. >=20 > To be clear, I am not against registering a media type which uses CBOR = syntax for a collection of other media types. However this media type = name can't use the "multipart" top level media type. You can either = define a new "application" media type (e.g. application/multipart-core) = or you can define a new top level media type different from "multipart". = The process for definining a new top level media type is slightly more = comlicated, so you should evaluate whether you want to do this. There is no particular need to use the top-level =E2=80=9Cmultipart=E2=80=9D= (or any other top-level for that matter), so we would go for an = application/ top-level. (The draft from 2013 that this new version continues wasn=E2=80=99t = suggesting a media type name, so the not-so-well-thought-out suggestion = to use multipart/ was new in this version.)=20 Questions to the WG: Anyone have a problem with the name application/multipart-core? (It=E2=80=99s not visible in the CoAP exchanges, we just see the = content-format identifier there. We could discuss whether that should be a single-byte identifier; the = current draft goes for a two-byte one.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 6 09:00:29 2018 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 27E23130F70 for ; Wed, 6 Jun 2018 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 juZ7wKy44_RP for ; Wed, 6 Jun 2018 09:00:20 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3506E130F66 for ; Wed, 6 Jun 2018 09:00:19 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 1104D182CF669; Wed, 6 Jun 2018 16:00:19 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::, RULES_HIT:41:152:355:379:582:599:962:967:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1534:1540:1566:1575:1588:1589:1592:1594:1711:1714:1730:1749:1776:1792:2198:2199:2528:2559:2562:2827:3138:3139:3140:3141:3142:3865:3870:3872:3874:4321:5007:6117:6261:6657:6678:7875:7903:8603:10004:10400:10848:11232:11658:11783:11914:12043:12663:12740:12895:13139:14096:14721:21080:21433:21451:21627:30029:30054, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:47, LUA_SUMMARY:none X-HE-Tag: money27_7716548f6dc61 X-Filterd-Recvd-Size: 3086 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Wed, 6 Jun 2018 16:00:18 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b92383727774928350e3b2657267ef1c" Date: Wed, 06 Jun 2018 18:00:17 +0200 From: Peter van der Stok To: Carsten Bormann Cc: Alexey Melnikov , peter van der Stok , Michael Richardson , core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.135.186] Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 16:00:25 -0000 --=_b92383727774928350e3b2657267ef1c Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I'm fine with application/multipart-core Peter Carsten Bormann schreef op 2018-06-06 16:54: > Anyone have a problem with the name application/multipart-core? > (It's not visible in the CoAP exchanges, we just see the content-format identifier there. > We could discuss whether that should be a single-byte identifier; the current draft goes for a two-byte one.) > > Grüße, Carsten --=_b92383727774928350e3b2657267ef1c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 I'm fine with application/multipart-core

Peter

Carsten Bormann schreef op 2018-06-06 16:54:

=
Anyone have a problem with the name application/multipart-core?
(It's not visible in the CoAP exchanges, we just see the content-format i= dentifier there.
We could discuss whether that should be a single-byt= e identifier; the current draft goes for a two-byte one.)

Gr&uu= ml;ße, Carsten

--=_b92383727774928350e3b2657267ef1c-- From nobody Wed Jun 6 09:12:18 2018 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 CDEC0130F6F for ; Wed, 6 Jun 2018 09:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 FRhSzrIf9RWo for ; Wed, 6 Jun 2018 09:12:10 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0125.outbound.protection.outlook.com [104.47.0.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11C0130F6C for ; Wed, 6 Jun 2018 09:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9h/stUmig+9hxys/QXrqvtfLrPaDcJ3b5UiH4VRm5JU=; b=BYT+90QqXCO3g9Go40cmUgmOBgHBoEF+zmYZPRuQ8iJE401/fx1jSCN34/TPHCPnG1x7jkRz1hER/i9i4xXBs66OjREppyFVOpW9aSqd3pfU05HrsaQTaAncHjGtaYhBbAfd3XiLLYbkpMubS0h+xyI3jphXjTaq6/1k/76eG5I= Received: from VI1PR0701MB2381.eurprd07.prod.outlook.com (10.168.138.135) by VI1PR0701MB2351.eurprd07.prod.outlook.com (10.168.137.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.12; Wed, 6 Jun 2018 16:12:07 +0000 Received: from VI1PR0701MB2381.eurprd07.prod.outlook.com ([fe80::149d:ec19:1d91:6b36]) by VI1PR0701MB2381.eurprd07.prod.outlook.com ([fe80::149d:ec19:1d91:6b36%9]) with mapi id 15.20.0841.006; Wed, 6 Jun 2018 16:12:06 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Carsten Bormann , Alexey Melnikov CC: Michael Richardson , core , "Fossati, Thomas (Nokia - GB/Cambridge)" Thread-Topic: [core] multipart/core Thread-Index: AQHT/PXH8OIx/EiYkkKqob3r3jsMu6RS8ouAgAABHwCAAAV+gIAAVpqAgAAC+gCAACZVAA== Date: Wed, 6 Jun 2018 16:12:06 +0000 Message-ID: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2351; 7:jJI/Ra1OKFpXTgtUXxWD8yK39/SLNyrDsIOIM03an22zHJ0sj8cyTA8gxSMpncIK+VZeXS0TE1UpK5ppu57eGqKvjCwDHjGDaP4Fy081kkxaKYFwJtkeehlQJNwSnEGvJX1UP077ZKMJGlLbNYia47Zsyapbe+EP7TuWBPpNXY+ulAfX8awW5oL3tKmGXEcUiQ0WOzHY/3cFRBYRxArzgNyhKuUH4d0vWKl9BROxwHBvdj5OSDuHh2jE1xNfVubr x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(39380400002)(396003)(189003)(199004)(2616005)(106356001)(316002)(93886005)(6116002)(3846002)(25786009)(4326008)(54906003)(110136005)(53936002)(6246003)(97736004)(58126008)(68736007)(105586002)(305945005)(486006)(8676002)(86362001)(446003)(8936002)(5250100002)(81166006)(82746002)(107886003)(81156014)(7736002)(11346002)(53546011)(229853002)(2900100001)(5660300001)(186003)(3280700002)(6486002)(83716003)(476003)(478600001)(102836004)(99286004)(6506007)(76176011)(36756003)(6512007)(6436002)(3660700001)(14454004)(33656002)(2906002)(26005)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2351; H:VI1PR0701MB2381.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:VI1PR0701MB2351; x-ms-traffictypediagnostic: VI1PR0701MB2351: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2351; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2351; x-forefront-prvs: 06952FC175 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /jPtXQYpta4sNtUmpQ1iuP9ER/RB7xVw5y0oZZmPXEMoD2I7G7Wr4IKe795BWNsbDolUjfbrBdiYg8x7upkQ8CXEhM9NbnqcEYX3nxbARoarmOmDZ+Q9rrBxHNe6lLXphpkltzGLBYYAY1iHq2iA3xQQ+n3fMzuO55EC9rJ29Z2xITTm6SHszBFWBQDcC4M0BJ5igI5a3+SEORscg5JWLjMRN1ky/buUrchJuUERyck= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 60c6ab12-d749-477b-6996-08d5cbc83fcf X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60c6ab12-d749-477b-6996-08d5cbc83fcf X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 16:12:06.6267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2351 Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 16:12:15 -0000 T24gMDYvMDYvMjAxOCwgMTU6NTUsICJjb3JlIG9uIGJlaGFsZiBvZiBDYXJzdGVuIEJvcm1hbm4i IDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNhYm9AdHppLm9yZz4gd3JvdGU6 DQo+IFdlIGNvdWxkIGRpc2N1c3Mgd2hldGhlciB0aGF0IHNob3VsZCBiZSBhIHNpbmdsZS1ieXRl IGlkZW50aWZpZXI7IHRoZSBjdXJyZW50DQo+IGRyYWZ0IGdvZXMgZm9yIGEgdHdvLWJ5dGUgb25l LikNCg0KSSdkIGdvIHdpdGggMSBieXRlLCBidXQgSSBndWVzcyBpbiB0aGlzIGNhc2UgLSBnaXZl biB0aGUgbmVlZCB0byBhbGlnbiB3aXRoIEFDRQ0KRVNUIHRpbWluZyAtIHRoZSBjaG9pY2UgdWx0 aW1hdGVseSBkZXBlbmRzIG9uIHRoZSBFVEEgZm9yIEV4cGVydCB2cyBJRVRGIHJldmlldz8NCg0K From nobody Wed Jun 6 10:48:11 2018 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 40D9C130F89 for ; Wed, 6 Jun 2018 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 FRl-LBsWskEA for ; Wed, 6 Jun 2018 10:48:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336D412777C for ; Wed, 6 Jun 2018 10:48:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BA32720090; Wed, 6 Jun 2018 14:01:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 902A974; Wed, 6 Jun 2018 13:47:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8C0A93F; Wed, 6 Jun 2018 13:47:24 -0400 (EDT) From: Michael Richardson To: core , Carsten Bormann In-Reply-To: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 17:48:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > Anyone have a problem with the name application/multipart-core? I have no objection to the name. The only other name I might imagine is application/multipart-cbor, as slightly more descriptive, but it's a bikeshed question. > (It=E2=80=99s not visible in the CoAP exchanges, we just see the cont= ent-format > identifier there.=20 > We could discuss whether that should be a single-byte identifier; the > current draft goes for a two-byte one.)=20 I don't have a problem with a two-byte ID as the places where it will be us= ed will already be returning ~1k of data. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxgeLICLcPvd0N1lAQIC0gf/YFOgfc3tB8uEPqchDVKJpQrdcEjrVoTx B3San2f9oJn1C7l5GDAvrsa4IdgaVRy/Kh/zEBnjeKMhIFS472Ks8cJ66OaYq9uU gPDOyZBJ5Vf4PkFNpOQzKAeYN/FlWDcA/2Ctx+aQP40suQwTE/7q/WOtuT8yIzS0 UPqvcmvy/WxbXe3IbDODbXL7rMU1cBVyoOU7et2s6VJ+K6NlN43D8zfazW22wwwL yFZzBRyFg2VHU2BJdAzlF4oIxPquln1+NpnaUMn8DT2nEcMfz7FviXNNIqwrCmNY DLr8QIcdvTXQnZksDTvK+Nz3uE98WKJrIik6gB9okqSWRK4LHOWDsw== =Sa7s -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 6 11:36:13 2018 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 81399129619 for ; Wed, 6 Jun 2018 11:36:11 -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 bjT3sU9dZJ6w for ; Wed, 6 Jun 2018 11:36:09 -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 BF7A6128CF3 for ; Wed, 6 Jun 2018 11:36:08 -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 w56Ia3EI025034; Wed, 6 Jun 2018 20:36:04 +0200 (CEST) Received: from [172.18.144.189] (unknown [46.183.103.8]) (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 411HS31RmqzDXPq; Wed, 6 Jun 2018 20:36:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <24375.1528307244@localhost> Date: Wed, 6 Jun 2018 20:35:59 +0200 Cc: core X-Mao-Original-Outgoing-Id: 550002957.188701-250c4a5aafab067888388678fd0a25c0 Content-Transfer-Encoding: quoted-printable Message-Id: <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 18:36:12 -0000 Hi Michael, > On Jun 6, 2018, at 19:47, Michael Richardson = wrote: >=20 > The only other name I might imagine is application/multipart-cbor, as > slightly more descriptive, but it's a bikeshed question. There is not that much CBOR there=E2=80=A6. But the interesting point = about this specific format is not so much the razor-thin CBOR envelope, = but that this is using Content-Format identifiers from the CoRE = Parameters registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the = proposed name. We may want to create similar formats that use = string-based media-type names. (We also could put in string-based = media-types as an alternative to Content-Format Identifiers into this = media type, though, if we want to reduce the number of such formats: multipart-core =3D [* multipart-part] multipart-part =3D (type: uint .size 2 / text, part: bytes / null) Where =E2=80=9Ctext=E2=80=9D is a media type string (possibly including = parameters). Does this have a use case we care about?) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 6 11:52:25 2018 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 8B3F312F1A2 for ; Wed, 6 Jun 2018 11:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md5L4g1rk3bh for ; Wed, 6 Jun 2018 11:52:12 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 95032130FAC for ; Wed, 6 Jun 2018 11:52:12 -0700 (PDT) Received: from mail-io0-f182.google.com ([209.85.223.182]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fQdXV-0006Cd-VC; Wed, 06 Jun 2018 20:52:10 +0200 Received: by mail-io0-f182.google.com with SMTP id u4-v6so8853449iof.2 for ; Wed, 06 Jun 2018 11:52:09 -0700 (PDT) X-Gm-Message-State: APt69E2RAgP0gIV3YFvmmCnymRDfL++AAWRvywhV6peK+aA86/pdfgb5 ocEPjnDPCcj0teA1Vjdb0zgBpRkn2ZjnNTIJRdA= X-Google-Smtp-Source: ADUXVKLQEvOOCqsUqjdIx7VS+Ij/eCnn2yDA0GFX6qEHsTaUbN9+wE3Y49ry4/18VSbjIvyz1TDxJJ3SyQvy7eSvt8U= X-Received: by 2002:a6b:c6c9:: with SMTP id w192-v6mr3975598iof.131.1528311128707; Wed, 06 Jun 2018 11:52:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:1202:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 11:51:27 -0700 (PDT) In-Reply-To: <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> From: Klaus Hartke Date: Wed, 6 Jun 2018 20:51:27 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Michael Richardson , core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1528311132; de78ea0c; X-HE-SMSGID: 1fQdXV-0006Cd-VC Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 18:52:22 -0000 Carsten Bormann wrote: > multipart-core =3D [* multipart-part] > multipart-part =3D (type: uint .size 2 / text, part: bytes / null) > > Where =E2=80=9Ctext=E2=80=9D is a media type string (possibly including p= arameters). Does this have a use case we care about?) For evolvability, we should add rules for processing parts that look invalid at the moment. I can imagine the need for other representation metadata in addition to the content format in the future, so there might be a map in place of the uint. I wouldn't want to bloat the format right now, though. Let's keep it small and focused, and allow for evolving it later should the need arise. Klaus From nobody Wed Jun 6 15:11:35 2018 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 4D1BB130DE8 for ; Wed, 6 Jun 2018 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 vrU9MoKr69K3 for ; Wed, 6 Jun 2018 15:11:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575DD130DF0 for ; Wed, 6 Jun 2018 15:11:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E36C820090; Wed, 6 Jun 2018 18:24:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 92E4C74; Wed, 6 Jun 2018 18:10:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 90A0E3F; Wed, 6 Jun 2018 18:10:50 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: core In-Reply-To: <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 22:11:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> On Jun 6, 2018, at 19:47, Michael Richardson = wrote: >>=20 >> The only other name I might imagine is application/multipart-cbor, as >> slightly more descriptive, but it's a bikeshed question. > There is not that much CBOR there=E2=80=A6. But the interesting poin= t about > this specific format is not so much the razor-thin CBOR envelope, but > that this is using Content-Format identifiers from the CoRE Parameters > registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed n= ame. We may want to That's a reasonable argument for calling it multipart-core. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxhb6oCLcPvd0N1lAQLJxQf/d6afcEclrp0436HokMQfj5tL8BaCoZkf VyS4K/zFsfPjuGV4FO3bs+XurRuj1AgcyNdvV8ooHkGagPFdbm7q7Ip9czmSrv6w mT4t1OAi4tfB+PdERV043lVF/XyK+Ns/ifpe9tXtRv4+VhlzI+74XzYc0l3OGf7Y DkxsJ66k0cxMwxeFKm4lNYjykOEqUrOSuXTa+DGFKPvJBUASYYjg1e2CUUt+VTA0 Xd+0t0hourffUOCq6gXt6LgYeehUWP8z0O27CB+xVTrg0kk1/3WHPUDY2wDOEwXK eC7C1IoMInf/a9NXwloau+GP8u9KvP/crMNyZyAPO6T/rDOv0RLizg== =ZKLJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 00:33:17 2018 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 BDE24130E8F for ; Thu, 7 Jun 2018 00:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 M9R6Ek0Kg7t2 for ; Thu, 7 Jun 2018 00:33:12 -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 4CE2D130E7E for ; Thu, 7 Jun 2018 00:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528356790; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6/kE5dhRLVOFKyz0hGaBxNnDhV7NqYwBzbo7EIIYDXc=; b=KnAfO9LzZqjhrCCdxc4C0in+bp4c74wqzk2WgitrhSzpiMgldvwK4Q2rnRs38Zw7 s4oqgGLi9dW9XOikITYCnEksbvVjs8O9dTCQH7lFP7jFFGMAK2THtehV8/rvwN1j 9TQDP+78CY3mycRA3dJs2V1rMzNA0rjNM9lXPNlStIQ=; X-AuditID: c1b4fb3a-323229c000005fee-93-5b18dfb6a81a Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.D8.24558.6BFD81B5; Thu, 7 Jun 2018 09:33:10 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSHC005.ericsson.se (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 7 Jun 2018 09:33:09 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 7 Jun 2018 09:33:09 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Thu, 7 Jun 2018 09:33:09 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Michael Richardson CC: Carsten Bormann , core Thread-Topic: [core] multipart/core Thread-Index: AQHT/PXI0FigUnm0CEeFCM5FAfiJd6RS0QMAgAABIACAAAV+gIAAVpqAgAAC+gCAADAyAIAADZOAgAA8BwCAAJ0agA== Date: Thu, 7 Jun 2018 07:33:09 +0000 Message-ID: <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> In-Reply-To: <25717.1528323050@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/signed; boundary="Apple-Mail=_0365C780-5AC6-4189-BFD0-3871DDDB75E8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbFdUXfbfYlog+OPlC2OTLnLarHv7Xpm i55D/ewOzB5Llvxk8miZs4fZY9qizADmKC6blNSczLLUIn27BK6MtwfmsRQ8SaqY3PSaqYFx alQXIyeHhICJRN/LfqYuRi4OIYEjjBIX5q5jgXA2M0rcufeFFcL5yiixp/cAI4SzlFFi3YPr jCD9bALOEp+eNbKD2CICehLLjzwDizMLWEhMvvaWBcQWFlCSuLN1M1SNssTy+eeZIewsiQWv voDVswioSDy6MZcNxOYVsJeYf3451E2vWCQurb4NNohTQFPi2PJrrCA2o4CYxPdTa5gglolL 3HoynwniIRGJhxdPs0HYohIvH/9jhbCVJPYeuw72G7PAFEaJrZ1PWSG2CUqcnPkEbIGQgLrE t1m3mScwis9CMncWsp5ZSHogipIk3p+ZyApha0ssW/iaGcLWlNjfvZwFU1xDovMbTL2pxOuj HxkhbGuJGb8OskHYihJTuh+yL2DkXsUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRmBwObvlt tYPx4HPHQ4wCHIxKPLyxtySihVgTy4orcw8xqgDNebRh9QVGKZa8/LxUJRHexEti0UK8KYmV ValF+fFFpTmpxYcYpTlYlMR5ndIsooQE0hNLUrNTUwtSi2CyTBycUg2Mks8rpnpvWy9dKPZ8 xTJPptNRieIaHTOVDKPM+sz3/4n5819bnrGhVvvhnlP63C0z69LXJb5s+WT+R84mIViq/Y/R z+gNRwpllR5xzovO4nvn9LqLrzv2l68p7wHTFhc2teL3/6sYYnlapy4/aJ/zTaz2cQXziT8L lJ0XsGkl29z/aB314rISS3FGoqEWc1FxIgBkuEd7FgMAAA== Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 07:33:15 -0000 --Apple-Mail=_0365C780-5AC6-4189-BFD0-3871DDDB75E8 Content-Type: multipart/alternative; boundary="Apple-Mail=_9787DD90-C0FF-42B2-9AE9-6D6427DB93C5" --Apple-Mail=_9787DD90-C0FF-42B2-9AE9-6D6427DB93C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thank you all for the constructive discussion. To summarise some of the = raised points so far: - Dependency on EST-COAP, which is targeted for WGLC in next IETF. - Multipart/core can't be registered. AD pointed out that it is not = possible to register "multipart" as a top-level media type. Author's = proposal to rename it under application (i.e. - = "application/multipart-core"). - Should the identifier be a single byte or two? - Expert media-type review confirmation needed. If the authors could submit a new version soon, I=E2=80=99ll trigger the = WGA call so that we have consensus on the draft before next IETF. Ciao! - - Jaime Jim=C3=A9nez > On 7 Jun 2018, at 1.10, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >>> On Jun 6, 2018, at 19:47, Michael Richardson = wrote: >>>=20 >>> The only other name I might imagine is application/multipart-cbor, = as >>> slightly more descriptive, but it's a bikeshed question. >=20 >> There is not that much CBOR there=E2=80=A6. But the interesting = point about >> this specific format is not so much the razor-thin CBOR envelope, but >> that this is using Content-Format identifiers from the CoRE = Parameters >> registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed = name. We may want to >=20 > That's a reasonable argument for calling it multipart-core. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_9787DD90-C0FF-42B2-9AE9-6D6427DB93C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Thank = you all for the constructive discussion. To summarise some of the raised = points so far:

- Dependency on EST-COAP, which is = targeted for WGLC in next IETF.
- Multipart/core = can't be registered. AD pointed out that it is not possible to register = "multipart" as a top-level media type. Author's proposal to rename it = under application (i.e. - "application/multipart-core").
- Should the identifier be a single byte or = two?
- Expert media-type review confirmation = needed.

If the = authors could submit a new version soon, I=E2=80=99ll trigger the WGA = call so that we have consensus on the draft before next IETF.

Ciao!
- - Jaime Jim=C3=A9nez

On 7 Jun 2018, at 1.10, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Carsten Bormann <cabo@tzi.org> wrote:
On Jun 6, = 2018, at 19:47, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

The only other name I might imagine is = application/multipart-cbor, as
slightly more descriptive, = but it's a bikeshed question.

There is not that much = CBOR there=E2=80=A6.  But the interesting point about
this specific format is not so much the razor-thin CBOR = envelope, but
that this is using Content-Format = identifiers from the CoRE Parameters
registry =E2=80=94 = hence the =E2=80=9Ccore=E2=80=9D in the proposed name.  We may want = to

That's a reasonable = argument for calling it multipart-core.

-- =
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh networks [
] =   Michael Richardson, Sandelman Software Works =        | network architect  [ =
]     mcr@sandelman.ca =  http://www.sandelman.ca/ =        |   ruby on rails =    [

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

= --Apple-Mail=_9787DD90-C0FF-42B2-9AE9-6D6427DB93C5-- --Apple-Mail=_0365C780-5AC6-4189-BFD0-3871DDDB75E8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDYwNzA3MzMwOFowIwYJKoZIhvcNAQkEMRYEFHISAs2B/vzx3KyUi65f9pU/yRyA MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEARBw/yu5bq7GhXUGvZg7kKxlipm6LLeIg2q0BKFcfi/0SV5QcdWQKb8q1/YQw4khW e0V2c7YfEzKa7+qCZlFmV1W7M7E/TAH15SsQvYNMLXSEIdRNwOeol3PJvr7iNKxsRZJUOpLCkvBO EFDRqMboegkFBxSPd1VUXVkGKuaqTq72v0zy4NoWucrMDKkFHLu0io9RH5+6lBWGu5l9w9kMEpWd fDOwbwKZyuMYk0dYBxzoOaejMgpWODEgtvdrzzj8hEoDQ6/+jN/jtOmIpuVjN61p7uazV9Ekrpnu KF+JxF/eVcZ8/SRgw60WQcB+3bc+jpiHv7ZmDdI/nmjlNrnIyAAAAAAAAA== --Apple-Mail=_0365C780-5AC6-4189-BFD0-3871DDDB75E8-- From nobody Fri Jun 8 06:41:34 2018 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 089D2130EA7 for ; Fri, 8 Jun 2018 06:41:32 -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 QK9SEKNhwk7E for ; Fri, 8 Jun 2018 06:41:28 -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 5B9D5130EA3 for ; Fri, 8 Jun 2018 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w58DfNvx022409; Fri, 8 Jun 2018 15:41:23 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 412Nq74fVZzDXmW; Fri, 8 Jun 2018 15:41:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> Date: Fri, 8 Jun 2018 15:41:23 +0200 Cc: Michael Richardson , core X-Mao-Original-Outgoing-Id: 550158081.150988-692e781b2a80e45c832709c400f289d5 Content-Transfer-Encoding: quoted-printable Message-Id: <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] multipart/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 08 Jun 2018 13:41:32 -0000 I updated the draft based on the input we have so far (thanks to = everyone replying!). (I added alternative text media-type labels as a trial balloon; we can = always remove them in the WG discussion. We can also decide between single-byte and two-byte identifier.) Name: draft-fossati-core-multipart-ct Revision: 05 Title: Multipart Content-Format for CoAP Htmlized: = https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-05 This should be ready for working-group adoption call now. Gr=C3=BC=C3=9Fe, Carsten Please initiate=20 > On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez = wrote: >=20 > Hi, >=20 > Thank you all for the constructive discussion. To summarise some of = the raised points so far: >=20 > - Dependency on EST-COAP, which is targeted for WGLC in next IETF. > - Multipart/core can't be registered. AD pointed out that it is not = possible to register "multipart" as a top-level media type. Author's = proposal to rename it under application (i.e. - = "application/multipart-core"). > - Should the identifier be a single byte or two? > - Expert media-type review confirmation needed. >=20 > If the authors could submit a new version soon, I=E2=80=99ll trigger = the WGA call so that we have consensus on the draft before next IETF. >=20 > Ciao! > - - Jaime Jim=C3=A9nez >=20 >> On 7 Jun 2018, at 1.10, Michael Richardson = wrote: >>=20 >>=20 >> Carsten Bormann wrote: >>>> On Jun 6, 2018, at 19:47, Michael Richardson = wrote: >>>>=20 >>>> The only other name I might imagine is application/multipart-cbor, = as >>>> slightly more descriptive, but it's a bikeshed question. >>=20 >>> There is not that much CBOR there=E2=80=A6. But the interesting = point about >>> this specific format is not so much the razor-thin CBOR envelope, = but >>> that this is using Content-Format identifiers from the CoRE = Parameters >>> registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed = name. We may want to >>=20 >> That's a reasonable argument for calling it multipart-core. >>=20 >> --=20 >> ] Never tell me the odds! | ipv6 mesh = networks [=20 >> ] Michael Richardson, Sandelman Software Works | network = architect [=20 >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 >> =09 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From nobody Fri Jun 8 11:17:30 2018 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 1E416130F6D; Fri, 8 Jun 2018 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 sPQNswXrnmom; Fri, 8 Jun 2018 11:17:24 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0106.outbound.protection.outlook.com [104.47.37.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC0D130F62; Fri, 8 Jun 2018 11:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tIgDjuy6XkwGAttTTpTMYZdVkES2qOXpdAm/Pinv8cc=; b=QUlOfT3nxhCQxWTQhHjc2zvT8Oju+I6Jt/k3+L2L4+7SbQ0Hy+76p15sv7M8vpSl/c0oEtANsNUBTgXF+MEAOUPKLH9jpHHicshzKOrhea4bVTZYu8q00maoIsKhetAT5bBiPXxhPIWcobdrYS2uhAzS2aFbdIVOZdCcB+HETB0= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB3002.namprd06.prod.outlook.com (10.175.109.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.15; Fri, 8 Jun 2018 18:17:19 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::5423:80d3:8d70:efb9]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::5423:80d3:8d70:efb9%9]) with mapi id 15.20.0820.015; Fri, 8 Jun 2018 18:17:19 +0000 From: Michel Veillette To: Peter van der Stok , Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz CC: "yot@ietf.org" , Core Thread-Topic: YANG notification within CoMI Thread-Index: AdP/UVBv6lm2EKsrSzmsBpb94+0wbg== Date: Fri, 8 Jun 2018 18:17:19 +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@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB3002; 7:InqR+dUFxDF0Bph/BdoKN1k2NQhPFlnGw2ZYGOzsVhoFa6olJnEBRfTIOs5z/5o3vq3rlC+HHFqT+40Gl2WXs05Za/1BoEgRCv+wGpZdCxchuuROtpEHYgGqHLkhhjjUQ+63ayQJ+xaFkXaH6PIDdnH3QMas5Jet6DmiBVI3NWWdMx3Xjn8u6eNMnOtrg7jNoXwMsuhgfxWBoW/jVudwg7K8oyhdyuBT6papxx2AcgjAh1/5tRauGuReF1S0T59Q x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB3002; x-ms-traffictypediagnostic: DM5PR06MB3002: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201703011903075)(201702281528075)(20161123555045)(201703061421075)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB3002; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB3002; x-forefront-prvs: 06973FFAD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(39380400002)(396003)(346002)(376002)(39850400004)(366004)(189003)(199004)(7736002)(25786009)(2900100001)(790700001)(5250100002)(6116002)(606006)(7110500001)(186003)(476003)(7696005)(3660700001)(2420400007)(15650500001)(6506007)(8676002)(66066001)(26005)(3480700004)(10710500007)(59450400001)(99286004)(486006)(3846002)(81166006)(3280700002)(102836004)(2906002)(81156014)(68736007)(110136005)(86362001)(5660300001)(316002)(8936002)(33656002)(4326008)(236005)(54896002)(14454004)(508600001)(54906003)(97736004)(6306002)(966005)(55016002)(105586002)(72206003)(9686003)(106356001)(6436002)(53936002)(74316002)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB3002; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: N0PoTpYCK8KW0g6iW6hA3nfhSny3viF45cNvK/YeJikstkly/KHXoLfb87gXJ9JEUmmOFtfIzoSq4PhnVhE1ww/lTClupIzUfWR+W/2Jhvk6Mc+ZfmXKeaBbQwwkGxNeOrR7hVz+jdq7LP96fJu5BzWsJZ/xYMf2KSEmtqJItnzaw84Pl/ykMIOYBkMD/Xx3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR06MB2777CAB016D2789C4F1DD67F9A7B0DM5PR06MB2777namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a5d406d1-c609-451d-bd06-08d5cd6c12ba X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5d406d1-c609-451d-bd06-08d5cd6c12ba X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 18:17:19.5776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3002 Archived-At: Subject: [core] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 08 Jun 2018 18:17:28 -0000 --_000_DM5PR06MB2777CAB016D2789C4F1DD67F9A7B0DM5PR06MB2777namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support the YANG notifications in the current CoMI draft (i.e https://www.i= etf.org/id/draft-ietf-core-comi-03.txt) is based on the observe option as d= efined by RFC7641. This solution has the following issues which make it not practical for the = targeted use case. 1) This approach in incompatible with load balancers, notifications are dir= ectly returned to the specific server within the cluster which have initiat= ed the observe request. 2) Typical CoAP implementation (e.g. Californium) doesn't support the persi= stence of the observe context. These contexts can't be recovered after a se= rver restart and can't be shared between servers. 3) Registrations to event streams are not resilient, they can terminate une= xpectedly upon transmission error or reception of a Reset message. I recommend to delete draft-ietf-core-comi section 5.5 and start a specific= effort on this topic. Alignment with the [I-D.ietf-netconf-yang-push] also need to be considered. Those interested to this topic, please send me a email so I can schedule co= nference calls or a face to face meeting during the next IETF. The following diagram shows a typical deployment scenario. +---------+ +---------+ +---------+ | CoMI | | CoMI | ... | CoMI | | server | | server | | server | +---------+ +---------+ +---------+ | | | | | | +----------+-+-----------------+ | | +---------------------------------+ | CoMI | | | client | | | +----------+ | | | Load | | | | Balancer | | | +----------+ | | | | | +-----+---------+ | | | | | | +---------+ +---------+ | | | Server | ... | Server | | | +---------+ +---------+ | | | | | | +-------+-------+ | | | | | +----------+ | | | Database | | | +----------+ | | | +---------------------------------+ Regards, Michel --_000_DM5PR06MB2777CAB016D2789C4F1DD67F9A7B0DM5PR06MB2777namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support the YANG notificatio= ns in the current CoMI draft (i.e https://www= .ietf.org/id/draft-ietf-core-comi-03.txt) is based on the observe optio= n as defined by RFC7641.

 

This solution has the follow= ing issues which make it not practical for the targeted use case.

 

1) This approach in incompat= ible with load balancers, notifications are directly returned to the specif= ic server within the cluster which have initiated the observe request.=

2) Typical CoAP implementati= on (e.g. Californium) doesn't support the persistence of the observe contex= t. These contexts can't be recovered after a server restart and can't be sh= ared between servers.

3) Registrations to event st= reams are not resilient, they can terminate unexpectedly upon transmission = error or reception of a Reset message.

 

I recommend to delete draft-= ietf-core-comi section 5.5 and start a specific effort on this topic.<= /o:p>

Alignment with the [I-D.ietf= -netconf-yang-push] also need to be considered.

Those interested to this top= ic, please send me a email so I can schedule conference calls or a face to = face meeting during the next IETF.

 

The following diagram shows = a typical deployment scenario.

 

  +---------+  +---------+ = ;      +---------+

  | CoMI    |  | CoMI  = ;  |  ...  | CoMI    |

  | server  |  | server  |  = ;     | server  |

  +---------+  +---------+ = ;      +---------+

       |   &= nbsp;        |    &n= bsp;            |

       |   &= nbsp;        |    &n= bsp;            |

       +----------+= -+-----------------+

         &nb= sp;        |

         &nb= sp;        |

   +---------------------------------+<= o:p>

   | CoMI       &= nbsp; |           &n= bsp;      |

   | client      = |            &= nbsp;     |

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

   |       &= nbsp; | Load     |      &= nbsp;     |

   |       &= nbsp; | Balancer |         &nb= sp;  |

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

   |       &= nbsp;      |      &n= bsp;           |

   |        = +-----+---------+        |

   |        = |            &n= bsp;  |        |<= /p>

   |   +---------+  = ;   +---------+   |

   |   | Server  | ... | Server&= nbsp; |   |

   |   +---------+  = ;   +---------+   |

   |        = |            &n= bsp;  |        |<= /p>

   |        = +-------+-------+        |

   |       &= nbsp;        |    &n= bsp;           |

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

   |       &= nbsp;   | Database |        &n= bsp; |

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

    &nbs= p;   |           = ;            &n= bsp;         |

   +---------------------------------+<= o:p>

 

Regards,

Michel

--_000_DM5PR06MB2777CAB016D2789C4F1DD67F9A7B0DM5PR06MB2777namp_-- From nobody Sat Jun 9 06:21:01 2018 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 5B6D7130DFF; Sat, 9 Jun 2018 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdpJdIBWjtN5; Sat, 9 Jun 2018 06:20:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1512129C6B; Sat, 9 Jun 2018 06:20:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1AFFA20090; Sat, 9 Jun 2018 09:34:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 421953100; Sat, 9 Jun 2018 09:18:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4030F2E8A; Sat, 9 Jun 2018 09:18:03 -0400 (EDT) From: Michael Richardson To: Michel Veillette cc: Peter van der Stok , Andy Bierman , Alexander Pelov , "Eric Voit \(evoit\)" , Henk Birkholz , "yot\@ietf.org" , Core In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Yot] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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: Sat, 09 Jun 2018 13:21:00 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Why would a COMI client be behind a load balancer? (I can't understand why some ports on such a machine might be subject to load balancing, but why the CoMI communications?) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxvThoCLcPvd0N1lAQJergf+J/N2uViihPnO5uXEDoEmCja9Y73UytH7 uV0otyLoEuWkUbfnIn+inBs3n/tIawF2012Rr3RhfoHGXTOuMDZqOtiuCIl4qNMU acnrc6ihMcchJmu0pm/O7oIJ2FhekWNpxfZ9LWzSk7OfjMZ17KxggNlamjXwK7uU D5w0MYlWVCydf5vshs+Ts4bosGUj0kF8w2noHc607SUzPHnx4/GIlRVdKLPm3cVk GQ8GQEXM3IF8Sj4NAY+8VQNDMcG4OqfNVdPckVNTN1qtLzVEh+Kjn9bkL9ptbOcU MP9J8R3N7bSoeLZrbqbToamFLaDZoUu2tyL3iEqEE443rxpv4NG5/w== =ksg9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 10 22:02:27 2018 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 EB3E0130DF5 for ; Sun, 10 Jun 2018 22:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bvryqO57WcJS for ; Sun, 10 Jun 2018 22:02:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3BDFE12F1AC for ; Sun, 10 Jun 2018 22:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528693341; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8Bbpap3xS9xLzksXHDrBMKWEXfiPRBq1h3ztjJzZV0g=; b=dof89ptBY50Kgns04lGEcouz+3IHUAD6c3ALLLvUFzssHjeK4dKGRrIxnlO68LkJ vRq2BkZEzEGfv08mnpue8BQCIgwtbUyf1gofSFz1pW1MN/xXhJiSNUTZ+lglcBKo kMgzHKJmAWZxC4Le0JihLlrmfJ7OG/32Ens6EnkXxAA=; X-AuditID: c1b4fb2d-c79ff700000028db-43-5b1e025d6989 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.75.10459.D520E1B5; Mon, 11 Jun 2018 07:02:21 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSHC005.ericsson.se (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 11 Jun 2018 07:02:20 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 11 Jun 2018 07:02:20 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 11 Jun 2018 07:02:19 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dBIG11bHRpcGFydC9jb3JlIA==?= Thread-Index: AQHUAUFg8swBXyy110eBIT8oThmNyg== Date: Mon, 11 Jun 2018 05:02:19 +0000 Message-ID: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> In-Reply-To: <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/signed; boundary="Apple-Mail=_FB0B4144-14E1-4445-B2D5-C495B74860AA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUyM2K7om4sk1y0wYeHghb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqElH1gLztVWtNw+y97AuKewi5GTQ0LAROLN+QvMXYxcHEIC RxglXjQ3skM4Wxglzuy+wAjhfGOUmDJlOitIi5DAMkaJLY1mIDabgLPEp2cgHZwcIgISEp1f 94PZwgKOEsef3mODiLtJnJvWBGXrSSxomckMYrMIqEocbdgDVs8rYC/xcsUrqGUXWSUetZ0E K+IUsJaYcvIyI4jNKCAm8f3UGiYQm1lAXOLWk/lMED+ISDy8eJoNwhaVePn4HyuErSSx99h1 Foj6KYwSF+/yQiwTlDg58wkLxDPqEt9m3WaewCg2C8nYWUhaZiFpgYgnSTyeMB/K1pZYtvA1 M4StKbG/ezkWcQ2Jzm8TWSFsU4nXRz8yQtjWEjN+HWSDsBUlpnQ/ZF/AyL2KUbQ4tbg4N93I WC+1KDO5uDg/Ty8vtWQTIzCyD275rbuDcfVrx0OMAhyMSjy8EX9lo4VYE8uKK3MPMaoAzXm0 YfUFRimWvPy8VCURXo/n0tFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEefVW7YkSEkhPLEnNTk0t SC2CyTJxcEo1MEa9WXwkwdn04prTMaF7teb+uvGC5wvzKfdIm2e84Rfec3lt/1Li+CuZu/Sj HP+Tua7rCrfOmW1V3D1pZ4Hh77NMfwXeb6jd7JP8Q3DzgzmGzTvE7wv/EYgJidyQH6J5sUrP KUrJU2Amm1OJz4Qpq8UUHpfGrEovF6hew1UusWXmwvAMzlquPCWW4oxEQy3mouJEAPgFmVv0 AgAA Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 05:02:26 -0000 --Apple-Mail=_FB0B4144-14E1-4445-B2D5-C495B74860AA Content-Type: multipart/alternative; boundary="Apple-Mail=_6EE554DD-5A41-4BAD-8C58-F3E441622643" --Apple-Mail=_6EE554DD-5A41-4BAD-8C58-F3E441622643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, based on the ongoing discussion on the Multipart Content-Format for CoAP = and the dependency with ACE, we will issue a 2 week Working group = Adoption call for this draft. Ciao! - - Jaime Jim=C3=A9nez > On 8 Jun 2018, at 16.41, Carsten Bormann wrote: >=20 > I updated the draft based on the input we have so far (thanks to = everyone replying!). > (I added alternative text media-type labels as a trial balloon; we can = always remove them in the WG discussion. > We can also decide between single-byte and two-byte identifier.) >=20 > Name: draft-fossati-core-multipart-ct > Revision: 05 > Title: Multipart Content-Format for CoAP > Htmlized: = https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-05 >=20 > This should be ready for working-group adoption call now. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Please initiate=20 >=20 >> On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez = wrote: >>=20 >> Hi, >>=20 >> Thank you all for the constructive discussion. To summarise some of = the raised points so far: >>=20 >> - Dependency on EST-COAP, which is targeted for WGLC in next IETF. >> - Multipart/core can't be registered. AD pointed out that it is not = possible to register "multipart" as a top-level media type. Author's = proposal to rename it under application (i.e. - = "application/multipart-core"). >> - Should the identifier be a single byte or two? >> - Expert media-type review confirmation needed. >>=20 >> If the authors could submit a new version soon, I=E2=80=99ll trigger = the WGA call so that we have consensus on the draft before next IETF. >>=20 >> Ciao! >> - - Jaime Jim=C3=A9nez >>=20 >>> On 7 Jun 2018, at 1.10, Michael Richardson = wrote: >>>=20 >>>=20 >>> Carsten Bormann wrote: >>>>> On Jun 6, 2018, at 19:47, Michael Richardson = wrote: >>>>>=20 >>>>> The only other name I might imagine is application/multipart-cbor, = as >>>>> slightly more descriptive, but it's a bikeshed question. >>>=20 >>>> There is not that much CBOR there=E2=80=A6. But the interesting = point about >>>> this specific format is not so much the razor-thin CBOR envelope, = but >>>> that this is using Content-Format identifiers from the CoRE = Parameters >>>> registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed = name. We may want to >>>=20 >>> That's a reasonable argument for calling it multipart-core. >>>=20 >>> --=20 >>> ] Never tell me the odds! | ipv6 mesh = networks [=20 >>> ] Michael Richardson, Sandelman Software Works | network = architect [=20 >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 >>> =09 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 --Apple-Mail=_6EE554DD-5A41-4BAD-8C58-F3E441622643 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all,

based on the = ongoing discussion on the Multipart Content-Format for CoAP and the = dependency with ACE, we will issue a 2 week Working group Adoption call = for this draft.

Ciao!
- - Jaime Jim=C3=A9nez

On 8 Jun 2018, at 16.41, Carsten Bormann <cabo@tzi.org> = wrote:

I updated the draft based on the input we have so far (thanks = to everyone replying!).
(I added alternative text = media-type labels as a trial balloon; we can always remove them in the = WG discussion.
We can also decide between single-byte and = two-byte identifier.)

Name: = draft-fossati-core-multipart-ct
Revision: 05
Title:= = Multipart Content-Format for CoAP
Htmlized: =       https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05<= /a>
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipar= t-ct-05

This should be ready for = working-group adoption call now.

Gr=C3=BC=C3=9F= e, Carsten


Please initiate =

On = Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:

Hi,

Thank you all for the = constructive discussion. To summarise some of the raised points so = far:

- Dependency on EST-COAP, which is = targeted for WGLC in next IETF.
- Multipart/core can't be = registered. AD pointed out that it is not possible to register = "multipart" as a top-level media type. Author's proposal to rename it = under application (i.e. - "application/multipart-core").
- = Should the identifier be a single byte or two?
- Expert = media-type review confirmation needed.

If = the authors could submit a new version soon, I=E2=80=99ll trigger the = WGA call so that we have consensus on the draft before next IETF.

Ciao!
- - Jaime Jim=C3=A9nez

On 7 Jun = 2018, at 1.10, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Carsten Bormann <cabo@tzi.org> wrote:
On Jun 6, 2018, at 19:47, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

The only other name I might imagine is = application/multipart-cbor, as
slightly more descriptive, = but it's a bikeshed question.

There is not that much = CBOR there=E2=80=A6.  But the interesting point about
this specific format is not so much the razor-thin CBOR = envelope, but
that this is using Content-Format = identifiers from the CoRE Parameters
registry =E2=80=94 = hence the =E2=80=9Ccore=E2=80=9D in the proposed name.  We may want = to

That's a reasonable = argument for calling it multipart-core.

-- =
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh networks [
] =   Michael Richardson, Sandelman Software Works =        | network architect  [ =
]     mcr@sandelman.ca =  http://www.sandelman.ca/ =        |   ruby on rails =    [

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



= --Apple-Mail=_6EE554DD-5A41-4BAD-8C58-F3E441622643-- --Apple-Mail=_FB0B4144-14E1-4445-B2D5-C495B74860AA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDYxMTA1MDIxOFowIwYJKoZIhvcNAQkEMRYEFDLdiwoti1w7csl4aXOTmqsXwElL MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAiX3WQGmHIIp9VVVtDi3HqdbpHWAhADer1kHRupUsSRHaJ4h9qp4+n3MSI0iB0HwT qXSzXiFxruGtoNgwFdyQXDUqzZjfiPNt4INdjufLfeuHklfW70ArxOX2dKvGXLp5Vz1ajFTJTEw5 df2ga8g7aJJRfatioGI1cqqtV4/943bVOB6Uvkm+lDR91f6agxR6TcHYip7TbREXVFwE30Dfi5Mn EUa/XTULWkAjZ/x6GRAtALhe5le8f8EejgkxuPqAeIG+qRjt3sJ7dx7eKrUJCyggvimjjZjPEJs5 i0PIp+3+qgxMepYSvL9xVP9S3e8pVEsniQ4OiwySdQYaL5KA3AAAAAAAAA== --Apple-Mail=_FB0B4144-14E1-4445-B2D5-C495B74860AA-- From nobody Sun Jun 10 23:04:28 2018 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 710EF130E03 for ; Sun, 10 Jun 2018 23:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=runbox.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 6dSF_NzQ7f6A for ; Sun, 10 Jun 2018 23:04:23 -0700 (PDT) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (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 8250C130E0C for ; Sun, 10 Jun 2018 23:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To; bh=E+Yqx1edIW1OBeNeQeKiVXF85iHAHATW6iFbJUAweEw=; b=h5TH/xznZT9XGn2O4xjbdH2Wci/mfXYe0Mn4YAYsE0fsSMoG5eXO7Y5vFB9ucpLZCy8ec1ilXT 7pBtfo4Ebrsva4Fd8Fxql51n5EjKj9TdJzzDm2WP3Fv7syJYcZbM/ryyM96KAtKjg83JbJVwBJ/wm cpxxgYG1briPw4P/8d3BuDorujig/Mm1Dv04tX3pICEF6Qry86PPEYAeI1NsaCoWg+6bg1hsdyBDH fQTqE+pUqOsYlFa3t2to8KqrBEGDtT5KTF+USBl0oCdYVvLuXD8T7wKE65qK4/Uh124uIbyOB02AU KPBMOcHSzwyzWgsyp9uoaNhCR3WUbm45+CNww==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fSFwB-0000gG-NK for core@ietf.org; Mon, 11 Jun 2018 08:04:19 +0200 Received: from c-73-227-92-48.hsd1.ma.comcast.net ([73.227.92.48] helo=[10.52.33.6]) by mailfront10.runbox.com with esmtpsa (uid:798146 ) (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) id 1fSFw4-0003dS-EQ for core@ietf.org; Mon, 11 Jun 2018 08:04:12 +0200 To: core From: Ken Bannister Message-ID: <1a70f6eb-9957-62df-89a7-fb54d90cecdd@runbox.com> Date: Mon, 11 Jun 2018 02:04:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [core] RFC 7967 absent from docs page X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 06:04:27 -0000 Chairs, Should we we expect to see the informational RFC 7967 (No-Response option) on the documents page [1]? I was surprised that it is absent. Thanks, Ken [1] https://datatracker.ietf.org/wg/core/documents/ From nobody Mon Jun 11 00:02:21 2018 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 3274D130F2D for ; Mon, 11 Jun 2018 00:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZQfEPDg1s1NA for ; Mon, 11 Jun 2018 00:02:17 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4412F130E15 for ; Mon, 11 Jun 2018 00:02:16 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id CB49E182CED5B; Mon, 11 Jun 2018 07:02:15 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -9, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:1:2:41:46:72:150:152:355:379:582:800:960:962:967:968:969:973:982:983:988:989:1042:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2557:2561:2568:2631:2682:2685:2693:2827:2859:2895:2909:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3571:3586:3664:3673:3685:3769:3770:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4184:4250:4321:4425:4605:4659:4860:5007:6117:6261:6657:6659:6678:7875:7903:8526:8603:8660:8985:9010:9025:9040:9163:9177:9388:10004:10848:11232:11657:11658:11783:11914:11984:12043:12050:12114:12291:12379:12438:12555:12683:12740:12895:13139:13148:13230:13846:13972:14095:14096:14799:21060:21080:21433:21451:21611:21627:21691:21740:30018:30029:30041:30054:30060:30070:30090, 0, RBL:error, CacheIP:none, Bayesian:0 X-HE-Tag: crib80_4de72ea084e1a X-Filterd-Recvd-Size: 12228 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf09.hostedemail.com (Postfix) with ESMTPA; Mon, 11 Jun 2018 07:02:15 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2504422df48a6c67d3f7335f4cfb0dd7" Date: Mon, 11 Jun 2018 09:02:14 +0200 From: Peter van der Stok To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Cc: core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> Message-ID: <7567cae936e1ea451de2f688a0530803@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.84.153] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 07:02:20 -0000 --=_2504422df48a6c67d3f7335f4cfb0dd7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I fully support the adoption of this document. It is necessary for the publication of ietf--ace-est-coaps draft in ACE peter Jaime Jiménez schreef op 2018-06-11 07:02: > Dear all, > > based on the ongoing discussion on the Multipart Content-Format for CoAP and the dependency with ACE, we will issue a 2 week Working group Adoption call for this draft. > > Ciao! > > - - Jaime Jiménez > > On 8 Jun 2018, at 16.41, Carsten Bormann wrote: > > I updated the draft based on the input we have so far (thanks to everyone replying!). > (I added alternative text media-type labels as a trial balloon; we can always remove them in the WG discussion. > We can also decide between single-byte and two-byte identifier.) > > Name: draft-fossati-core-multipart-ct > Revision: 05 > Title: Multipart Content-Format for CoAP > Htmlized: https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 > Diff: https://www.ietf.org/rfcdiff?url2=draft-fossati-core-multipart-ct-05 > > This should be ready for working-group adoption call now. > > Grüße, Carsten > > Please initiate > > On Jun 7, 2018, at 09:33, Jaime Jiménez wrote: > > Hi, > > Thank you all for the constructive discussion. To summarise some of the raised points so far: > > - Dependency on EST-COAP, which is targeted for WGLC in next IETF. > - Multipart/core can't be registered. AD pointed out that it is not possible to register "multipart" as a top-level media type. Author's proposal to rename it under application (i.e. - "application/multipart-core"). > - Should the identifier be a single byte or two? > - Expert media-type review confirmation needed. > > If the authors could submit a new version soon, I'll trigger the WGA call so that we have consensus on the draft before next IETF. > > Ciao! > - - Jaime Jiménez > > On 7 Jun 2018, at 1.10, Michael Richardson wrote: > > Carsten Bormann wrote: > On Jun 6, 2018, at 19:47, Michael Richardson wrote: > > The only other name I might imagine is application/multipart-cbor, as > slightly more descriptive, but it's a bikeshed question. > There is not that much CBOR there.... But the interesting point about > this specific format is not so much the razor-thin CBOR envelope, but > that this is using Content-Format identifiers from the CoRE Parameters > registry -- hence the "core" in the proposed name. We may want to That's a reasonable argument for calling it multipart-core. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 --=_2504422df48a6c67d3f7335f4cfb0dd7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 I fully support the adoption of this document.
It is necessary for the= publication of ietf--ace-est-coaps  draft in ACE

peter

Jaime Jiménez schreef op 2018-06-11 07:02:

Dear all,
 
based on the ongoing discussion on the Multipart Content-Format f= or CoAP and the dependency with ACE, we will issue a 2 week Working group A= doption call for this draft.
 
Ciao!
- - Jaime Jiménez

On 8 Jun 2018, at 16.41, Carsten Bormann <cabo@tzi.org> wrote:
I updated the draft based on the input we have so far (thanks to every= one replying!).
(I added alternative text media-type labels as a trial= balloon; we can always remove them in the WG discussion.
We can also = decide between single-byte and two-byte identifier.)

Name: draft-fossati-core-mul= tipart-ct
Revision: 05
Title: Multipart Content-Format for CoAP
Htmlized:   =     https://tools= =2Eietf.org/html/draft-fossati-core-multipart-ct-05
Diff:  &n= bsp;        https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-= core-multipart-ct-05

This should be ready for working-group = adoption call now.

Grüße, Carsten


Pl= ease initiate

On Jun 7, 2018, at 09:33, Jaime Jiménez <jaime.jimenez= @ericsson.com> wrote:

Hi,

Thank you all for th= e constructive discussion. To summarise some of the raised points so far:
- Dependency on EST-COAP, which is targeted for WGLC in next IETF= =2E
- Multipart/core can't be registered. AD pointed out that it is no= t possible to register "multipart" as a top-level media type. Author's prop= osal to rename it under application (i.e. - "application/multipart-core")= =2E
- Should the identifier be a single byte or two?
- Expert med= ia-type review confirmation needed.

If the authors could submit = a new version soon, I'll trigger the WGA call so that we have consensus on = the draft before next IETF.

Ciao!
- - Jaime Jiménez<= br />
On 7 Jun 2018, at 1.10, Michael Richardson <mcr+ietf@sandelman.ca&= gt; wrote:


Carsten Bormann <cabo@tzi.org> wrote:
On Jun 6, 2018, at 19:47, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

The only other name I might imagine is application/= multipart-cbor, as
slightly more descriptive, but it's a bikeshed ques= tion.

There is not that much CBOR there....  But the in= teresting point about
this specific format is not so much the razor-th= in CBOR envelope, but
that this is using Content-Format identifiers fr= om the CoRE Parameters
registry — hence the "core" in the propos= ed name.  We may want to

That's a reasonable argument for calling it multipart-core.

--
]           &n= bsp;   Never tell me the odds!      = ;           | ipv6 m= esh networks [
]   Michael Richardson, Sandelman Software W= orks        | network architect  [ =
]     mcr@sandelman.ca  http://www.sandelman.ca/  &n= bsp;     |   ruby on rails   &= nbsp;[

_______________________________________________
core mailin= g list
core@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/core

= _______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--=_2504422df48a6c67d3f7335f4cfb0dd7-- From nobody Mon Jun 11 00:19:53 2018 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 9218C130E13; Mon, 11 Jun 2018 00:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 fYA2rWGScs_Z; Mon, 11 Jun 2018 00:19:48 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6E5130DFE; Mon, 11 Jun 2018 00:19:48 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 90BA218224D99; Mon, 11 Jun 2018 07:19:47 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::::, RULES_HIT:1:41:69:72:152:355:379:582:599:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1730:1777:1792:1801:2068:2069:2198:2199:2525:2527:2528:2559:2564:2636:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4361:4362:4470:4605:5007:6117:6261:6657:6678:7875:7903:7974:8603:8957:9025:10004:10234:10848:10946:11232:11658:11914:12043:12683:12740:12895:13139:13439:13972:14095:14096:21060:21080:21212:21324:21433:21451:21627:21660:30022:30054:30070:30083, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:1:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: frog86_5566e24c24220 X-Filterd-Recvd-Size: 14930 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf10.hostedemail.com (Postfix) with ESMTPA; Mon, 11 Jun 2018 07:19:46 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2d163e3f187f67022f615d58da684374" Date: Mon, 11 Jun 2018 09:19:46 +0200 From: Peter van der Stok To: Michel Veillette Cc: Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz , yot@ietf.org, Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.84.153] Archived-At: Subject: Re: [core] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 07:19:52 -0000 --=_2d163e3f187f67022f615d58da684374 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Michel, Thanks for the message. I think that load balancers, stable storage for messages, californium implementation restrictions are all separate subjects, and merit a solution independent of CoMI. I recommend to maintain section 5.5, as is, in the comi draft and start looking at the other subjects separately. Peter Michel Veillette schreef op 2018-06-08 20:17: > Support the YANG notifications in the current CoMI draft (i.e https://www.ietf.org/id/draft-ietf-core-comi-03.txt) is based on the observe option as defined by RFC7641. > > This solution has the following issues which make it not practical for the targeted use case. > > 1) This approach in incompatible with load balancers, notifications are directly returned to the specific server within the cluster which have initiated the observe request. > > 2) Typical CoAP implementation (e.g. Californium) doesn't support the persistence of the observe context. These contexts can't be recovered after a server restart and can't be shared between servers. > > 3) Registrations to event streams are not resilient, they can terminate unexpectedly upon transmission error or reception of a Reset message. > > I recommend to delete draft-ietf-core-comi section 5.5 and start a specific effort on this topic. > > Alignment with the [I-D.ietf-netconf-yang-push] also need to be considered. > > Those interested to this topic, please send me a email so I can schedule conference calls or a face to face meeting during the next IETF. > > The following diagram shows a typical deployment scenario. > > +---------+ +---------+ +---------+ > > | CoMI | | CoMI | ... | CoMI | > > | server | | server | | server | > > +---------+ +---------+ +---------+ > > | | | > > | | | > > +----------+-+-----------------+ > > | > > | > > +---------------------------------+ > > | CoMI | | > > | client | | > > | +----------+ | > > | | Load | | > > | | Balancer | | > > | +----------+ | > > | | | > > | +-----+---------+ | > > | | | | > > | +---------+ +---------+ | > > | | Server | ... | Server | | > > | +---------+ +---------+ | > > | | | | > > | +-------+-------+ | > > | | | > > | +----------+ | > > | | Database | | > > | +----------+ | > > | | > > +---------------------------------+ > > Regards, > > Michel --=_2d163e3f187f67022f615d58da684374 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Michel,

Thanks for the message.
I think that load balanc= ers, stable storage for messages, californium implementation restrictions a= re all separate subjects, and merit a solution independent of CoMI.
I recommend to maintain section 5.5, as is, in the comi draft and start= looking at the other subjects separately.

Peter

Michel Veillette schreef op 2018-06-08 20:17:

Support the YANG notifications in the curre= nt CoMI draft (i.e https://www.ietf.org/id/draft-= ietf-core-comi-03.txt) is based on the observe option as defined by RFC= 7641.

 

This solution has the following issues whic= h make it not practical for the targeted use case.=

 

1) This approach in incompatible with load = balancers, notifications are directly returned to the specific server withi= n the cluster which have initiated the observe request.

2) Typical CoAP implementation (e.g. Califo= rnium) doesn't support the persistence of the observe context. These contex= ts can't be recovered after a server restart and can't be shared between se= rvers.

3) Registrations to event streams are not r= esilient, they can terminate unexpectedly upon transmission error or recept= ion of a Reset message.

 

I recommend to delete draft-ietf-core-comi = section 5.5 and start a specific effort on this topic.

Alignment with the [I-D.ietf-netconf-yang-p= ush] also need to be considered.

Those interested to this topic, please send= me a email so I can schedule conference calls or a face to face meeting du= ring the next IETF.

 

The following diagram shows a typical deplo= yment scenario.

 

 = ; +---------+  +---------+       +------= ---+

 = ; | CoMI    |  | CoMI    |  ...&nbs= p; | CoMI    |

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

 = ; +---------+  +---------+       +------= ---+

 = ;      |       =      |        &= nbsp;        |<= /p>

 = ;      |       =      |        &= nbsp;        |<= /p>

 = ;      +----------+-+-----------------+

 = ;            &n= bsp;    |

 = ;            &n= bsp;    |

 = ;  +---------------------------------+

 = ;  | CoMI         |  = ;             &= nbsp;  |

 = ;  | client       |   &nb= sp;            =  |

 = ;  |         +----------+ = ;           |

 = ;  |         | Load  = ;   |          =  |

 = ;  |         | Balancer | = ;           |

 = ;  |         +----------+ = ;           |

 = ;  |           =    |           =        |

 = ;  |        +-----+---------+ =        |

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

 = ;  |   +---------+     +---------+ =  |

 = ;  |   | Server  | ... | Server  |   |

 = ;  |   +---------+     +---------+ =  |

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

 = ;  |        +-------+-------+ =        |

 = ;  |           =      |         =        |

 = ;  |           +----= ------+          |

 = ;  |           | Dat= abase |          |

 = ;  |           +----= ------+          |

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

 = ;  +---------------------------------+

 

Regards,

Michel

--=_2d163e3f187f67022f615d58da684374-- From nobody Mon Jun 11 07:16:25 2018 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 92E74130E2B for ; Mon, 11 Jun 2018 07:16: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 TKcLif2sMY8W for ; Mon, 11 Jun 2018 07:16:20 -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 9E0101294D0 for ; Mon, 11 Jun 2018 07:16:19 -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 w5BEGFUE006435; Mon, 11 Jun 2018 16:16:15 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 414FRz5qX3zDWm4; Mon, 11 Jun 2018 16:16:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <1a70f6eb-9957-62df-89a7-fb54d90cecdd@runbox.com> Date: Mon, 11 Jun 2018 16:16:15 +0200 Cc: core X-Mao-Original-Outgoing-Id: 550419373.639786-8fde59bb3521333c98fad2808a91f2f9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1a70f6eb-9957-62df-89a7-fb54d90cecdd@runbox.com> To: Ken Bannister X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] RFC 7967 absent from docs page X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 14:16:23 -0000 On Jun 11, 2018, at 08:04, Ken Bannister wrote: >=20 > Chairs, >=20 > Should we we expect to see the informational RFC 7967 (No-Response = option) on the documents page [1]? I was surprised that it is absent. That particular document was not completed through the WG process. So it is not listed under the documents created by the WG. I=E2=80=99ll have to update http://coap.technology to include all those = RFCs=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten >=20 > Thanks, > Ken >=20 > [1] https://datatracker.ietf.org/wg/core/documents/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Mon Jun 11 12:42:00 2018 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 84A94130EBF; Mon, 11 Jun 2018 12:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 z1Y8MztfVMMD; Mon, 11 Jun 2018 12:41:55 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0092.outbound.protection.outlook.com [104.47.32.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F15130EBC; Mon, 11 Jun 2018 12:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PgxSOjVC5ugE0gwsHanH+xuvxWXW4kPX8POkKmPLiuk=; b=UAtYkgCM0Jm7EPLyTtZYLsQhS30/uyvJhg/VN0lwwR8Wln4VlzyQsxGLlPMBEiBkV19S0Nw+zyM0GNgKYy+CDjE45zmGF3MmOFYUZ8H6qeeKAcv3dpmurXnyW+PzP89ox8MMUez3Z8Yp8V03z8R81ibIf0sfhk67uLEikDwTVfg= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2443.namprd06.prod.outlook.com (10.168.178.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Mon, 11 Jun 2018 19:41:52 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::f8bd:cd7c:eb9e:b248]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::f8bd:cd7c:eb9e:b248%10]) with mapi id 15.20.0841.019; Mon, 11 Jun 2018 19:41:52 +0000 From: Michel Veillette To: Michael Richardson CC: Peter van der Stok , Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz , "yot@ietf.org" , Core Thread-Topic: [Yot] YANG notification within CoMI Thread-Index: AdP/UVBv6lm2EKsrSzmsBpb94+0wbgAovs2AAHE5hjA= Date: Mon, 11 Jun 2018 19:41:52 +0000 Message-ID: References: <14497.1528550283@localhost> In-Reply-To: <14497.1528550283@localhost> 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@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB2443; 7:RFym443nA2NdJYRiJzfAgrPEtkHQB10oJL8Vj0NOyN0QsW6YcKdla6J+uPUwRZ4sZLRDJGAJlNtHnT3xjRuQwzeI8hCQQ4NnKL2MjMjid94r7DSVCnk96snyJi+w81XIQJ4XzmivfFcJFd1UmBcgo3qjrEz8PC36JAnbubKa76rRDnoIIcNcWwWR5Ugvuk213kticEfankBp8Exz8ebzKz0OOQyutjLxT0dnTGQu7PvhCOsZ9GQPRUQncGT8grmc x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2443; x-ms-traffictypediagnostic: DM5PR06MB2443: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB2443; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2443; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39380400002)(39850400004)(396003)(199004)(189003)(13464003)(7736002)(86362001)(229853002)(3280700002)(2420400007)(74316002)(26005)(54906003)(33656002)(7696005)(55016002)(106356001)(305945005)(316002)(97736004)(4326008)(186003)(7110500001)(5660300001)(105586002)(102836004)(15650500001)(6246003)(5250100002)(486006)(59450400001)(6506007)(53546011)(966005)(76176011)(3846002)(14454004)(66066001)(25786009)(3660700001)(8936002)(446003)(11346002)(72206003)(476003)(10710500007)(53936002)(81166006)(81156014)(8676002)(99286004)(2906002)(6436002)(2900100001)(68736007)(6116002)(6306002)(9686003)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2443; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: g5xzGmYdmCtoUpJwCitvc35VeNkT/nbYs1h7K61qDSJ5jCb6sf5vFzlYx1zG14UsqiaCT8p197bYdF7qnKNwGKy5wRz5rvE0qTbNH9glCEPm22+4bF1pMidZw4vDNwVrbun8EGhGfH81aQPjsTNr+SuDnUMwgK66pYXMbr3db5mZYvs8x4mjfX6Yjw2MZgGK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f8c85790-8431-44b4-bb1f-08d5cfd36182 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8c85790-8431-44b4-bb1f-08d5cfd36182 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2018 19:41:52.3018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2443 Archived-At: Subject: Re: [core] [Yot] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 19:41:59 -0000 Hi Michael About "Why would a COMI client be behind a load balancer?" The main target of the CoMI protocol is network management. We typically de= ploy this protocol between a Network Management System (i.e. CoMI client) a= nd hundreds of thousand or million(s) of constrained network elements (i.e = CoMI server). At that scale, the NMS is implemented using a server cluster.= The load balancer is used to distribute the load of notifications between = the different servers. The load balancer also presents a stable IP address = independent of the currently available servers behind it. This is just a typical NMS configuration, noting special. Regards, Michel -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: Saturday, June 9, 2018 9:18 AM To: Michel Veillette Cc: Peter van der Stok ; Andy Bierman ; Alexander Pelov ; Eric Voit (evoit) ; Hen= k Birkholz ; yot@ietf.org; Core Subject: Re: [Yot] YANG notification within CoMI Why would a COMI client be behind a load balancer? (I can't understand why some ports on such a machine might be subject to lo= ad balancing, but why the CoMI communications?) --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Mon Jun 11 14:13:07 2018 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 4BABC130ED0; Mon, 11 Jun 2018 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 Lt-hjGIH7av5; Mon, 11 Jun 2018 14:12:55 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720115.outbound.protection.outlook.com [40.107.72.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FF6127598; Mon, 11 Jun 2018 14:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m6hKWu5UE0ALrHLysO2QsGpJkm8sGSN17BgXSUl5YWY=; b=xEvBEust3Sv0lkbvKmpFnuHwd0DVtJgafUWTBvIzYV7up7cfcoLIIu1vl4T+yxL60Mb1vFywHi7K3za8YAizsE83IT917l2odExTGrWgQr8yBUjXYtbQJVbKwqnjGf3Ld74J3S1slvAoEe//B3soLnF+8yKrkz6qUz4XblejAkg= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2586.namprd06.prod.outlook.com (10.168.198.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.18; Mon, 11 Jun 2018 21:12:52 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::f8bd:cd7c:eb9e:b248]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::f8bd:cd7c:eb9e:b248%10]) with mapi id 15.20.0841.019; Mon, 11 Jun 2018 21:12:52 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" CC: Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz , "yot@ietf.org" , Core Thread-Topic: YANG notification within CoMI Thread-Index: AdP/UVBv6lm2EKsrSzmsBpb94+0wbgCA0LQAABtlnFA= Date: Mon, 11 Jun 2018 21:12:51 +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@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB2586; 7:c+WgcgAvPjz+Vv63+yYpMflNhYXd4mKiSifvRT9bf2ULYjC2igxmca3edZnX65zoukDqDj0Puj7PmhTQL87qv0ZNIG+Rdu55dmNhW1BvnKyTRsQl6IAJx9Hgfekts0gW4b+7RZqFtzm3RymCoiI8QYIlas3PossMfbaClhXZK/b+3jahvUf5rKp9tnX8o+XaQjmBPCHCNiGbbjhuYYEHXNHF8b8A9+BSlcRdM5MWBMsd5EoOFm0Pb5gGdYNj8OLU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2586; x-ms-traffictypediagnostic: DM5PR06MB2586: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB2586; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2586; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39850400004)(396003)(376002)(346002)(189003)(199004)(51914003)(51444003)(4326008)(25786009)(790700001)(5250100002)(2501003)(5630700001)(68736007)(15650500001)(2420400007)(3660700001)(3280700002)(2906002)(2900100001)(3846002)(6116002)(10710500007)(6246003)(6916009)(54896002)(81166006)(9686003)(236005)(2351001)(53936002)(7736002)(8936002)(3480700004)(8676002)(81156014)(1730700003)(6306002)(5660300001)(74316002)(66066001)(86362001)(59450400001)(97736004)(55016002)(33656002)(105586002)(551934003)(11346002)(6436002)(14454004)(446003)(486006)(476003)(106356001)(76176011)(186003)(7696005)(606006)(19609705001)(26005)(102836004)(54906003)(72206003)(5640700003)(966005)(478600001)(316002)(99286004)(229853002)(7110500001)(6506007)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2586; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Z0zifL6xlbZn5yxUjV6XqOWv8AdwVU6bhwpGpTMdGtlmsq2tDRyXDZIZ5vTiA0m938c6Qy/d5MFFSjBJxL5KOrLCTWXd9Gx9tongK0Oux/M/X6hQVVA6HzxJ09zG0A7wbxDcXwbYhGSIXBw2SDtf6wPorQJ6EwSHgiAiXqlPFZxpWYK6jgMMmo6JudQt6SbS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR06MB2777CD78D86BC74876ED7F059A780DM5PR06MB2777namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9e718c1d-72e1-42e0-b68c-08d5cfe017bb X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e718c1d-72e1-42e0-b68c-08d5cfe017bb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2018 21:12:51.9813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2586 Archived-At: Subject: Re: [core] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 21:12:59 -0000 --_000_DM5PR06MB2777CD78D86BC74876ED7F059A780DM5PR06MB2777namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGV0ZXINCg0KQWJvdXQgIiBJIHJlY29tbWVuZCB0byBtYWludGFpbiBzZWN0aW9uIDUuNSwg YXMgaXMsIGluIHRoZSBDb01JIGRyYWZ0IGFuZCBzdGFydCBsb29raW5nIGF0IHRoZSBvdGhlciBz dWJqZWN0cyBzZXBhcmF0ZWx5LiINCg0KVGhlIGN1cnJlbnQgJ29ic2VydmUnIG1ldGhvZCBtaWdo dCBzdGlsbCBiZSB1c2VmdWwgZm9yIHNvbWUgdXNlIGNhc2VzIHdoaWNoIHJlcXVpcmVzIGEgdGVt cG9yYXJ5IHN1YnNjcmlwdGlvbi4gRm9yIGV4YW1wbGUsIHRoaXMgbWV0aG9kIGNhbiBiZSB1c2Vk IHRvIHRlbXBvcmFyaWx5IHN1YnNjcmliZSB0byB0aGUgc3lzbG9nIGZvciBkZWJ1ZyBwdXJwb3Nl cy4gVGhpcyBtZXRob2QgY2FuIGFsc28gYmUgdXNlZCB0byB3YWl0IGZvciB0aGUgY29tcGxldGlv biBvZiBhIHRyYW5zYWN0aW9uIGluaXRpYXRlZCB1c2luZyB0aGUgbm9ybWFsIENvQVAgbWV0aG9k cy4NCg0KVG8gYWRkcmVzcyB0aGUgbW9yZSBjb21tb24gZXZlbnQgc3RyZWFtIHVzZSBjYXNlcyAo aS5lLiBhIHNvbWV0aGluZyBlcXVpdmFsZW50IHRvIFNOTVAgdHJhcHMpLCBpdCBzZWVtIHdlIG5l ZWQgdG8gaW50cm9kdWNlIGEgbmV3IG1lY2hhbmlzbS4NCg0KQWJvdXQgaG93IHRvIHNvbHV0aW9u IHNob3VsZCBiZSBwYWNrYWdlZCAoaS5lLiBvbmUgb2YgdHdvIGRyYWZ0cyksIHdlIHNob3VsZCBw cm9iYWJseSB3YWl0IGZvciBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkaXJlY3Rpb24g d2Ugd2FudCB0byB0YWtlLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZyb206IFBldGVyIHZhbiBk ZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmxdDQpTZW50OiBNb25kYXksIEp1bmUg MTEsIDIwMTggMzoyMCBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVA dHJpbGxpYW50LmNvbT4NCkNjOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IEFs ZXhhbmRlciBQZWxvdiA8YUBhY2tsLmlvPjsgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2Nv LmNvbT47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+OyB5 b3RAaWV0Zi5vcmc7IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogWUFORyBub3Rp ZmljYXRpb24gd2l0aGluIENvTUkNCg0KSGkgTWljaGVsLA0KDQpUaGFua3MgZm9yIHRoZSBtZXNz YWdlLg0KSSB0aGluayB0aGF0IGxvYWQgYmFsYW5jZXJzLCBzdGFibGUgc3RvcmFnZSBmb3IgbWVz c2FnZXMsIGNhbGlmb3JuaXVtIGltcGxlbWVudGF0aW9uIHJlc3RyaWN0aW9ucyBhcmUgYWxsIHNl cGFyYXRlIHN1YmplY3RzLCBhbmQgbWVyaXQgYSBzb2x1dGlvbiBpbmRlcGVuZGVudCBvZiBDb01J Lg0KDQpJIHJlY29tbWVuZCB0byBtYWludGFpbiBzZWN0aW9uIDUuNSwgYXMgaXMsIGluIHRoZSBj b21pIGRyYWZ0IGFuZCBzdGFydCBsb29raW5nIGF0IHRoZSBvdGhlciBzdWJqZWN0cyBzZXBhcmF0 ZWx5Lg0KDQpQZXRlcg0KDQpNaWNoZWwgVmVpbGxldHRlIHNjaHJlZWYgb3AgMjAxOC0wNi0wOCAy MDoxNzoNCg0KU3VwcG9ydCB0aGUgWUFORyBub3RpZmljYXRpb25zIGluIHRoZSBjdXJyZW50IENv TUkgZHJhZnQgKGkuZSBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWNvcmUtY29t aS0wMy50eHQpIGlzIGJhc2VkIG9uIHRoZSBvYnNlcnZlIG9wdGlvbiBhcyBkZWZpbmVkIGJ5IFJG Qzc2NDEuDQoNCg0KDQpUaGlzIHNvbHV0aW9uIGhhcyB0aGUgZm9sbG93aW5nIGlzc3VlcyB3aGlj aCBtYWtlIGl0IG5vdCBwcmFjdGljYWwgZm9yIHRoZSB0YXJnZXRlZCB1c2UgY2FzZS4NCg0KDQoN CjEpIFRoaXMgYXBwcm9hY2ggaW4gaW5jb21wYXRpYmxlIHdpdGggbG9hZCBiYWxhbmNlcnMsIG5v dGlmaWNhdGlvbnMgYXJlIGRpcmVjdGx5IHJldHVybmVkIHRvIHRoZSBzcGVjaWZpYyBzZXJ2ZXIg d2l0aGluIHRoZSBjbHVzdGVyIHdoaWNoIGhhdmUgaW5pdGlhdGVkIHRoZSBvYnNlcnZlIHJlcXVl c3QuDQoNCjIpIFR5cGljYWwgQ29BUCBpbXBsZW1lbnRhdGlvbiAoZS5nLiBDYWxpZm9ybml1bSkg ZG9lc24ndCBzdXBwb3J0IHRoZSBwZXJzaXN0ZW5jZSBvZiB0aGUgb2JzZXJ2ZSBjb250ZXh0LiBU aGVzZSBjb250ZXh0cyBjYW4ndCBiZSByZWNvdmVyZWQgYWZ0ZXIgYSBzZXJ2ZXIgcmVzdGFydCBh bmQgY2FuJ3QgYmUgc2hhcmVkIGJldHdlZW4gc2VydmVycy4NCg0KMykgUmVnaXN0cmF0aW9ucyB0 byBldmVudCBzdHJlYW1zIGFyZSBub3QgcmVzaWxpZW50LCB0aGV5IGNhbiB0ZXJtaW5hdGUgdW5l eHBlY3RlZGx5IHVwb24gdHJhbnNtaXNzaW9uIGVycm9yIG9yIHJlY2VwdGlvbiBvZiBhIFJlc2V0 IG1lc3NhZ2UuDQoNCg0KDQpJIHJlY29tbWVuZCB0byBkZWxldGUgZHJhZnQtaWV0Zi1jb3JlLWNv bWkgc2VjdGlvbiA1LjUgYW5kIHN0YXJ0IGEgc3BlY2lmaWMgZWZmb3J0IG9uIHRoaXMgdG9waWMu DQoNCkFsaWdubWVudCB3aXRoIHRoZSBbSS1ELmlldGYtbmV0Y29uZi15YW5nLXB1c2hdIGFsc28g bmVlZCB0byBiZSBjb25zaWRlcmVkLg0KDQpUaG9zZSBpbnRlcmVzdGVkIHRvIHRoaXMgdG9waWMs IHBsZWFzZSBzZW5kIG1lIGEgZW1haWwgc28gSSBjYW4gc2NoZWR1bGUgY29uZmVyZW5jZSBjYWxs cyBvciBhIGZhY2UgdG8gZmFjZSBtZWV0aW5nIGR1cmluZyB0aGUgbmV4dCBJRVRGLg0KDQoNCg0K VGhlIGZvbGxvd2luZyBkaWFncmFtIHNob3dzIGEgdHlwaWNhbCBkZXBsb3ltZW50IHNjZW5hcmlv Lg0KDQoNCg0KICArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLSsNCg0K ICB8IENvTUkgICAgfCAgfCBDb01JICAgIHwgIC4uLiAgfCBDb01JICAgIHwNCg0KICB8IHNlcnZl ciAgfCAgfCBzZXJ2ZXIgIHwgICAgICAgfCBzZXJ2ZXIgIHwNCg0KICArLS0tLS0tLS0tKyAgKy0t LS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLSsNCg0KICAgICAgIHwgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICB8DQoNCiAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfA0K DQogICAgICAgKy0tLS0tLS0tLS0rLSstLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAg ICAgICAgfA0KDQogICAgICAgICAgICAgICAgICB8DQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQoNCiAgIHwgQ29NSSAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8 DQoNCiAgIHwgY2xpZW50ICAgICAgIHwgICAgICAgICAgICAgICAgICB8DQoNCiAgIHwgICAgICAg ICArLS0tLS0tLS0tLSsgICAgICAgICAgICB8DQoNCiAgIHwgICAgICAgICB8IExvYWQgICAgIHwg ICAgICAgICAgICB8DQoNCiAgIHwgICAgICAgICB8IEJhbGFuY2VyIHwgICAgICAgICAgICB8DQoN CiAgIHwgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICB8DQoNCiAgIHwgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICB8DQoNCiAgIHwgICAgICAgICstLS0tLSstLS0tLS0tLS0r ICAgICAgICB8DQoNCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICB8DQoNCiAg IHwgICArLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLSsgICB8DQoNCiAgIHwgICB8IFNlcnZlciAg fCAuLi4gfCBTZXJ2ZXIgIHwgICB8DQoNCiAgIHwgICArLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0t LSsgICB8DQoNCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICB8DQoNCiAgIHwg ICAgICAgICstLS0tLS0tKy0tLS0tLS0rICAgICAgICB8DQoNCiAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICB8DQoNCiAgIHwgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAg ICB8DQoNCiAgIHwgICAgICAgICAgIHwgRGF0YWJhc2UgfCAgICAgICAgICB8DQoNCiAgIHwgICAg ICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICB8DQoNCiAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCg0KUmVnYXJkcywNCk1pY2hlbA0K --_000_DM5PR06MB2777CD78D86BC74876ED7F059A780DM5PR06MB2777namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+SGkgUGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkFib3V0ICZxdW90 Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPkkgcmVjb21tZW5kIHRvIG1haW50YWluIHNlY3Rpb24gNS41LCBhcyBpcywgaW4gdGhl DQo8L3NwYW4+Q29NSTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+IGRyYWZ0IGFuZCBzdGFydCBsb29raW5nIGF0 IHRoZSBvdGhlciBzdWJqZWN0cyBzZXBhcmF0ZWx5LiZxdW90Ozxicj4NCjxicj4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5U aGUgY3VycmVudCAnb2JzZXJ2ZScgbWV0aG9kIG1pZ2h0IHN0aWxsIGJlIHVzZWZ1bCBmb3Igc29t ZSB1c2UgY2FzZXMgd2hpY2ggcmVxdWlyZXMgYSB0ZW1wb3Jhcnkgc3Vic2NyaXB0aW9uLiBGb3Ig ZXhhbXBsZSwgdGhpcyBtZXRob2QgY2FuIGJlIHVzZWQgdG8gdGVtcG9yYXJpbHkgc3Vic2NyaWJl IHRvIHRoZSBzeXNsb2cgZm9yIGRlYnVnIHB1cnBvc2VzLiBUaGlzIG1ldGhvZA0KIGNhbiBhbHNv IGJlIHVzZWQgdG8gd2FpdCBmb3IgdGhlIGNvbXBsZXRpb24gb2YgYSB0cmFuc2FjdGlvbiBpbml0 aWF0ZWQgdXNpbmcgdGhlIG5vcm1hbCBDb0FQIG1ldGhvZHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5U byBhZGRyZXNzIHRoZSBtb3JlIGNvbW1vbiBldmVudCBzdHJlYW0gdXNlIGNhc2VzIChpLmUuIGEg c29tZXRoaW5nIGVxdWl2YWxlbnQgdG8gU05NUCB0cmFwcyksIGl0IHNlZW0gd2UgbmVlZCB0byBp bnRyb2R1Y2UgYSBuZXcgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+QWJvdXQgaG93IHRv IHNvbHV0aW9uIHNob3VsZCBiZSBwYWNrYWdlZCAoaS5lLiBvbmUgb2YgdHdvIGRyYWZ0cyksIHdl IHNob3VsZCBwcm9iYWJseSB3YWl0IGZvciBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBk aXJlY3Rpb24gd2Ugd2FudCB0byB0YWtlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSI+TWljaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g UGV0ZXIgdmFuIGRlciBTdG9rIFttYWlsdG86c3Rva2NvbnNAYmJobWFpbC5ubF0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoyMCBBTTxicj4NCjxiPlRvOjwvYj4g TWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7OyBB bGV4YW5kZXIgUGVsb3YgJmx0O2FAYWNrbC5pbyZndDs7IEVyaWMgVm9pdCAoZXZvaXQpICZsdDtl dm9pdEBjaXNjby5jb20mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDtoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlJmd0OzsgeW90QGlldGYub3JnOyBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogWUFORyBub3RpZmljYXRpb24gd2l0aGluIENvTUk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ SGkgTWljaGVsLDxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIG1lc3NhZ2UuPGJyPg0KSSB0aGlu ayB0aGF0IGxvYWQgYmFsYW5jZXJzLCBzdGFibGUgc3RvcmFnZSBmb3IgbWVzc2FnZXMsIGNhbGlm b3JuaXVtIGltcGxlbWVudGF0aW9uIHJlc3RyaWN0aW9ucyBhcmUgYWxsIHNlcGFyYXRlIHN1Ympl Y3RzLCBhbmQgbWVyaXQgYSBzb2x1dGlvbiBpbmRlcGVuZGVudCBvZiBDb01JLjxicj4NCjxicj4N CkkgcmVjb21tZW5kIHRvIG1haW50YWluIHNlY3Rpb24gNS41LCBhcyBpcywgaW4gdGhlIGNvbWkg ZHJhZnQgYW5kIHN0YXJ0IGxvb2tpbmcgYXQgdGhlIG90aGVyIHN1YmplY3RzIHNlcGFyYXRlbHku PGJyPg0KPGJyPg0KUGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWYiPk1pY2hlbCBWZWlsbGV0dGUgc2NocmVlZiBvcCAyMDE4LTA2LTA4IDIwOjE3OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNS4wcHQ7bWFyZ2luLWxl ZnQ6MGluO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlN1 cHBvcnQgdGhlIFlBTkcgbm90aWZpY2F0aW9ucyBpbiB0aGUgY3VycmVudCBDb01JIGRyYWZ0IChp LmUNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWNv cmUtY29taS0wMy50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY29yZS1jb21pLTAzLnR4dDwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj4pDQogaXMgYmFzZWQgb24gdGhlIG9ic2VydmUgb3B0aW9uIGFzIGRlZmlu ZWQgYnkgUkZDNzY0MS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBzb2x1dGlvbiBoYXMgdGhl IGZvbGxvd2luZyBpc3N1ZXMgd2hpY2ggbWFrZSBpdCBub3QgcHJhY3RpY2FsIGZvciB0aGUgdGFy Z2V0ZWQgdXNlIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjEpIFRoaXMgYXBwcm9hY2ggaW4g aW5jb21wYXRpYmxlIHdpdGggbG9hZCBiYWxhbmNlcnMsIG5vdGlmaWNhdGlvbnMgYXJlIGRpcmVj dGx5IHJldHVybmVkIHRvIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgd2l0aGluIHRoZSBjbHVzdGVyIHdo aWNoIGhhdmUgaW5pdGlhdGVkIHRoZSBvYnNlcnZlIHJlcXVlc3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBUeXBpY2Fs IENvQVAgaW1wbGVtZW50YXRpb24gKGUuZy4gQ2FsaWZvcm5pdW0pIGRvZXNuJ3Qgc3VwcG9ydCB0 aGUgcGVyc2lzdGVuY2Ugb2YgdGhlIG9ic2VydmUgY29udGV4dC4gVGhlc2UgY29udGV4dHMgY2Fu J3QgYmUgcmVjb3ZlcmVkIGFmdGVyIGEgc2VydmVyIHJlc3RhcnQgYW5kIGNhbid0DQogYmUgc2hh cmVkIGJldHdlZW4gc2VydmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjMpIFJlZ2lzdHJhdGlvbnMgdG8gZXZlbnQgc3Ry ZWFtcyBhcmUgbm90IHJlc2lsaWVudCwgdGhleSBjYW4gdGVybWluYXRlIHVuZXhwZWN0ZWRseSB1 cG9uIHRyYW5zbWlzc2lvbiBlcnJvciBvciByZWNlcHRpb24gb2YgYSBSZXNldCBtZXNzYWdlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmIj5JIHJlY29tbWVuZCB0byBkZWxldGUgZHJhZnQtaWV0Zi1jb3Jl LWNvbWkgc2VjdGlvbiA1LjUgYW5kIHN0YXJ0IGEgc3BlY2lmaWMgZWZmb3J0IG9uIHRoaXMgdG9w aWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj5BbGlnbm1lbnQgd2l0aCB0aGUgW0ktRC5pZXRmLW5ldGNvbmYteWFuZy1wdXNo XSBhbHNvIG5lZWQgdG8gYmUgY29uc2lkZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRob3NlIGludGVyZXN0ZWQgdG8g dGhpcyB0b3BpYywgcGxlYXNlIHNlbmQgbWUgYSBlbWFpbCBzbyBJIGNhbiBzY2hlZHVsZSBjb25m ZXJlbmNlIGNhbGxzIG9yIGEgZmFjZSB0byBmYWNlIG1lZXRpbmcgZHVyaW5nIHRoZSBuZXh0IElF VEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBmb2xsb3dpbmcgZGlhZ3JhbSBzaG93cyBhIHR5 cGljYWwgZGVwbG95bWVudCBzY2VuYXJpby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJiM0MzstLS0t LS0tLS0mIzQzOyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7IHwgQ29NSSZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwgQ29NSSZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7IC4uLiZuYnNwOyB8IENvTUkmbmJzcDsmbmJzcDsmbmJzcDsgfDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgfCBzZXJ2ZXIgJm5ic3A7fCZuYnNwOyB8IHNl cnZlciAmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgc2VydmVy ICZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0 MzsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7LSYj NDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7fDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7fDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgfCBDb01JICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgfCBjbGllbnQmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBMb2FkJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IEJhbGFuY2VyIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt8PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7LS0t LS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOyZu YnNwOyAmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7IHwgU2VydmVyJm5ic3A7IHwgLi4uIHwgU2VydmVyJm5ic3A7IHwmbmJzcDsgJm5ic3A7 fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQz Oy0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0 MzsmbmJzcDsgJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt8PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRGF0YWJhc2UgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+TWljaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR06MB2777CD78D86BC74876ED7F059A780DM5PR06MB2777namp_-- From nobody Mon Jun 11 18:21:47 2018 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 75F3A130EAC; Mon, 11 Jun 2018 18:21:40 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox3e0g3DL4UO; Mon, 11 Jun 2018 18:21:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D52A130DCF; Mon, 11 Jun 2018 18:21:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B5F1920090; Mon, 11 Jun 2018 21:35:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 59D212F9D; Mon, 11 Jun 2018 21:18:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 57A042F98; Mon, 11 Jun 2018 21:18:40 -0400 (EDT) From: Michael Richardson To: Michel Veillette cc: "Eric Voit \(evoit\)" , Henk Birkholz , Peter van der Stok , Andy Bierman , "yot\@ietf.org" , Alexander Pelov , Core In-Reply-To: References: <14497.1528550283@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Yot] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 01:21:41 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michel Veillette wrote: > The main target of the CoMI protocol is network management. We > typically deploy this protocol between a Network Management System > (i.e. CoMI client) and hundreds of thousand or million(s) of > constrained network elements (i.e CoMI server). At that scale, the NMS > is implemented using a server cluster. The load balancer is used to > distribute the load of notifications between the different servers. T= he > load balancer also presents a stable IP address independent of the > currently available servers behind it. yes, in IPv4 land, this is what you'd be forced to do. In IPv6, it doesn't that much sense to me. It seems that there many possible stateless ways of making what you describe work without resorting to storing a bunch of state in a single-point-of-failure Load balancer, and then having problems with keeping context. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWx8fbYCLcPvd0N1lAQLLowgAmR3IClZH9nt0kXG2HaR//k+FfV65EW/J Ldtaa3f2BME2oU2c+rTDz++zTRYVZ4EhfgKioYDkCBm0ph2D5DZlZCAANfm3M4C/ gHN7X7o5Ej6vhFY4GvvmnfMUAOR34GctxgOYvDuOL9LhZzUoaQbUYryCVOHSz+F3 j6UH6JkPSeZLT8fNcaD/KMtQdXhNxJs5Z1DKS6moYIhh6G3Xg9J6Uy0lE9xvnG86 lQItidkSXZlSE/rRrVTeCB7DjzuXJuzHcv8teJEdTz4tRWKPwv25Iluyrw86R3py L3APnB9iHC5hutYWPCFPJeBZ+23xOgX+46tKd3S2T4uoOER+2BlX6w== =9x88 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 12 02:48:51 2018 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 DD98C131110; Tue, 12 Jun 2018 02:48:48 -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 noQ9RXB2StbH; Tue, 12 Jun 2018 02:48:44 -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 43D3C130E0D; Tue, 12 Jun 2018 02:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5C9mU7g002627; Tue, 12 Jun 2018 11:48:31 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 414lSZ3HwGzDWvj; Tue, 12 Jun 2018 11:48:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 12 Jun 2018 11:48:29 +0200 Cc: Peter van der Stok , Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz , "yot@ietf.org" , Core X-Mao-Original-Outgoing-Id: 550489708.433179-ae471a9967a9c1a21d9bebf25267fd88 Content-Transfer-Encoding: quoted-printable Message-Id: <836A7F59-C26B-4A6C-B9DE-331E9D1CB123@tzi.org> References: To: Michel Veillette X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 09:48:49 -0000 Hi Michel, sorry for being slow to answer; I finally had a nice discussion with = Henk today about your concerns that I want to summarize. Let me propose some terminology first: =E2=80=9Cservers=E2=80=9D are a = CoAP term, so when we talk about =E2=80=9Cheavy boxes with noisy fans = installed into a rack=E2=80=9D, I=E2=80=99ll use =E2=80=9Cmachines=E2=80=9D= (as opposed to =E2=80=9Cdevices=E2=80=9D that are the light bulbs being = managed). Not great terminology, but better than using the term = =E2=80=9Cserver=E2=80=9D for both. You write about the observe-based notifications proposed for COMI: > 1) This approach in incompatible with load balancers, notifications = are directly returned to the specific server within the cluster which = have initiated the observe request. Whether that is true depends a lot on what kind of load balancer you are = thinking about. For UDP CoAP, an anycast mechanism is the obvious choice for a load = balancer. Clearly, for any load balancing mechanism to be useful, the machines = sharing the load need to share state (symbolized by =E2=80=9Cdatabase=E2=80= =9D in your diagram). If they are clients, they need to share communication state as well as = application state (e.g., addresses of servers they talk to, the tokens = they use for outgoing requests). They don=E2=80=99t need to do this for = every single transaction (they don=E2=80=99t if there is no problem in = an occasional loss), but they do have to share observe state. When people talk about load balancers and resilience, they sometimes = mean that the peer with initiative (here: the CoAP server sending = another notification) needs to perform a full rendezvous with the other = side (e.g., in the Big Web, a fresh DNS lookup that might lead to a = completely different machine, potentially a new TLS session). See (3) = below for how we see this, for now let=E2=80=99s just say that we are = trying to achieve generally rendezvous-free notifications. > 2) Typical CoAP implementation (e.g. Californium) doesn't support the = persistence of the observe context. These contexts can=E2=80=99t be = recovered after a server restart and can't be shared between servers. That is indeed a problem. But the real problem is that they are not = ready for sharing their client state at all. Once they are, adding = persistence to that sharing becomes a rather straightforward exercise. So what I=E2=80=99m reading out of your message is that, to employ load = balancing for COMI notifications, CoAP implementations need to grow = support for sharing communication state (preferably with a persistent = mode). That is an important message to implementers, and thank you for = highlighting this. > 3) Registrations to event streams are not resilient, they can = terminate unexpectedly upon transmission error or reception of a Reset = message. Now how does the resilience come in? In the Big Web situation mentioned above, it comes from redoing the = rendezvous each time a notification is needed (potentially with some = caching, both of DNS state [leading to defined periods of blackholing] = and of any connections still open [which will hopefully time out if = there is a problem]. =20 In a rendezvous-free world, we have to do this explicitly. For a CoAP = server that cares about delivering the notifications, it will send (at = least some of) the notifications as confirmable messages [it actually = has to, once every 24 hours, but can do that more often if resilience = calls for it]. So it will notice when the recipient of the = notifications is no longer there. [It will also notice if the recipient = is confused enough to send a Reset, but persistence of communication = state is supposed to make this a non-event.] RFC 7641 tells us that the = CoAP server is to cease delivering notifications when the client machine = goes away. It doesn=E2=80=99t tell us what else the implementation = might want to do in that event. In a COMI call home scenario, I would = expect the device to notice that its relationship to home broke and redo = the rendezvous (call home) =E2=80=94 once, when needed, not for every = transaction (mitigated only by caching). =20 So, in effect, we can have all the advantages of the =E2=80=9Cdo the = rendezvous always, with caching=E2=80=9D world with much less = black-holing and unnecessary message overhead. For the above to be actionable, we do have to have implementations that: =E2=80=94 on the big machines, can share enough communication state so = they can take part in anycast-based load balancing, =E2=80=94 on the small devices, can react to loss of an observation = interest by redoing a call-home transaction. The second one clearly is an implementation quality requirement. = Let=E2=80=99s work on that with the implementers. The first could be thought to call for a protocol for coordinating the = machines. The IETF has not been very successful in establishing = =E2=80=9Creliable server pooling=E2=80=9D. I would actually expect = implementations that want to provide that coordination to come with = their own high-performance mechanisms, involving the usual state sharing = databases such as Redis =E2=80=94 they already have to do this with the = management (application) state shared between the machines. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 12 05:09:58 2018 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 7328B130E27; Tue, 12 Jun 2018 05:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6-iHBIqmbkz; Tue, 12 Jun 2018 05:09:45 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8076B126CC7; Tue, 12 Jun 2018 05:09:45 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 48193100E86C3; Tue, 12 Jun 2018 12:09:44 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::::::, RULES_HIT:41:69:72:152:327:355:379:582:599:800:960:962:967:973:982:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1730:1776:1792:1801:2198:2199:2525:2528:2551:2553:2559:2565:2570:2610:2682:2685:2703:2859:2914:2933:2937:2939:2942:2945:2947:2951:2954:3022:3586:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4361:4470:4605:5007:6117:6119:6261:6298:7576:7875:7903:7974:8583:8603:8957:9025:9080:9545:10004:10182:10183:10234:11658:12740:13139:13161:13229, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:1:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: mind51_37c6de260e03c X-Filterd-Recvd-Size: 24402 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Tue, 12 Jun 2018 12:09:43 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_98f9d46029f96dba3ad828af040a4b67" Date: Tue, 12 Jun 2018 14:09:42 +0200 From: Peter van der Stok To: Michel Veillette Cc: consultancy@vanderstok.org, Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz , yot@ietf.org, Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.84.153] Archived-At: Subject: Re: [core] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 12:09:50 -0000 --=_98f9d46029f96dba3ad828af040a4b67 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII I think Carsten and also Michael have started to discuss an approach to the current implementation short comings and resilience additions. Peter Michel Veillette schreef op 2018-06-11 23:12: > Hi Peter > > About " I recommend to maintain section 5.5, as is, in the CoMI draft and start looking at the other subjects separately." > > The current 'observe' method might still be useful for some use cases which requires a temporary subscription. For example, this method can be used to temporarily subscribe to the syslog for debug purposes. This method can also be used to wait for the completion of a transaction initiated using the normal CoAP methods. > > To address the more common event stream use cases (i.e. a something equivalent to SNMP traps), it seem we need to introduce a new mechanism. > > About how to solution should be packaged (i.e. one of two drafts), we should probably wait for a better understanding of the direction we want to take. > > Regards, > > Michel > > FROM: Peter van der Stok [mailto:stokcons@bbhmail.nl] > SENT: Monday, June 11, 2018 3:20 AM > TO: Michel Veillette > CC: Andy Bierman ; Alexander Pelov ; Eric Voit (evoit) ; Henk Birkholz ; yot@ietf.org; Core > SUBJECT: Re: YANG notification within CoMI > > Hi Michel, > > Thanks for the message. > I think that load balancers, stable storage for messages, californium implementation restrictions are all separate subjects, and merit a solution independent of CoMI. > > I recommend to maintain section 5.5, as is, in the comi draft and start looking at the other subjects separately. > > Peter > > Michel Veillette schreef op 2018-06-08 20:17: > >> Support the YANG notifications in the current CoMI draft (i.e https://www.ietf.org/id/draft-ietf-core-comi-03.txt [1]) is based on the observe option as defined by RFC7641. >> >> This solution has the following issues which make it not practical for the targeted use case. >> >> 1) This approach in incompatible with load balancers, notifications are directly returned to the specific server within the cluster which have initiated the observe request. >> >> 2) Typical CoAP implementation (e.g. Californium) doesn't support the persistence of the observe context. These contexts can't be recovered after a server restart and can't be shared between servers. >> >> 3) Registrations to event streams are not resilient, they can terminate unexpectedly upon transmission error or reception of a Reset message. >> >> I recommend to delete draft-ietf-core-comi section 5.5 and start a specific effort on this topic. >> >> Alignment with the [I-D.ietf-netconf-yang-push] also need to be considered. >> >> Those interested to this topic, please send me a email so I can schedule conference calls or a face to face meeting during the next IETF. >> >> The following diagram shows a typical deployment scenario. >> >> +---------+ +---------+ +---------+ >> >> | CoMI | | CoMI | ... | CoMI | >> >> | server | | server | | server | >> >> +---------+ +---------+ +---------+ >> >> | | | >> >> | | | >> >> +----------+-+-----------------+ >> >> | >> >> | >> >> +---------------------------------+ >> >> | CoMI | | >> >> | client | | >> >> | +----------+ | >> >> | | Load | | >> >> | | Balancer | | >> >> | +----------+ | >> >> | | | >> >> | +-----+---------+ | >> >> | | | | >> >> | +---------+ +---------+ | >> >> | | Server | ... | Server | | >> >> | +---------+ +---------+ | >> >> | | | | >> >> | +-------+-------+ | >> >> | | | >> >> | +----------+ | >> >> | | Database | | >> >> | +----------+ | >> >> | | >> >> +---------------------------------+ >> >> Regards, >> >> Michel Links: ------ [1] https://www.ietf.org/id/draft-ietf-core-comi-03.txt --=_98f9d46029f96dba3ad828af040a4b67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 I think Carsten and also Michael have started to discuss an approach to the= current implementation short comings and resilience additions.

= Peter

Michel Veillette schreef op 2018-06-11 23:12:

Hi Peter

 

About " I recommend to maintain section= 5.5, as is, in the CoMI draft and start looking at the other subjects se= parately."

The current 'observe' method might still be us= eful for some use cases which requires a temporary subscription. For exampl= e, this method can be used to temporarily subscribe to the syslog for debug= purposes. This method can also be used to wait for the completion of a tra= nsaction initiated using the normal CoAP methods.<= /p>

 

To address the more common event stream use ca= ses (i.e. a something equivalent to SNMP traps), it seem we need to introdu= ce a new mechanism.

 

About how to solution should be packaged (i.e= =2E one of two drafts), we should probably wait for a better understanding = of the direction we want to take.

 

Regards,

Michel

 

From: Peter van der Stok [mailto:st= okcons@bbhmail.nl]
Sent: Monday, June 11, 2018 3:20 = AM
To: Michel Veillette <Michel.Veillette@trillian= t.com>
Cc: Andy Bierman <andy@yumaworks.com>= ; Alexander Pelov <a@ackl.io>; Eric Voit (evoit) <evoit@cisco.com&= gt;; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; yot@ietf.org; C= ore <core@ietf.org>
Subject: Re: YANG notificat= ion within CoMI

 

Hi Michel,

Thanks for the message.
I th= ink that load balancers, stable storage for messages, californium implement= ation restrictions are all separate subjects, and merit a solution independ= ent of CoMI.

I recommend to maintain section 5.5, as is, in the= comi draft and start looking at the other subjects separately.

= Peter

Mi= chel Veillette schreef op 2018-06-08 20:17:

Support the YANG notifications in the current CoMI dra= ft (i.e https://www.ietf.org/id/draft-i= etf-core-comi-03.txt) is based on the observe option as defined by RF= C7641.

 

This solution has the following issues which make it n= ot practical for the targeted use case.

 

1) This approach in incompatible with load balancers, = notifications are directly returned to the specific server within the clust= er which have initiated the observe request.

2) Typical CoAP implementation (e.g. Californium) does= n't support the persistence of the observe context. These contexts can't be= recovered after a server restart and can't be shared between servers.

3) Registrations to event streams are not resilient, t= hey can terminate unexpectedly upon transmission error or reception of a Re= set message.

 

I recommend to delete draft-ietf-core-comi section 5= =2E5 and start a specific effort on this topic.

Alignment with the [I-D.ietf-netconf-yang-push] also n= eed to be considered.

Those interested to this topic, please send me a email= so I can schedule conference calls or a face to face meeting during the ne= xt IETF.

 

The following diagram shows a typical deployment scena= rio.

 

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

  | CoMI    |  | CoMI  &nb= sp; |  ...  | CoMI    |=

  | server  |  | server  |  &nb= sp;    | server  |

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

       |    = ;        |     =             |=

       |    = ;        |     =             |=

       +----------+-+----------= -------+

          &= nbsp;       |

          &= nbsp;       |

   +---------------------------------+

   | CoMI        = ; |            =       |

   | client       |&n= bsp;            = ;     |

   |        = ; +----------+           =  |

   |        = ; | Load     |       = ;     |

   |        = ; | Balancer |           =  |

   |        = ; +----------+           =  |

   |        = ;      |       =            |

   |        +---= --+---------+        |

   |   +---------+    = ; +---------+   |

   |   | Server  | ... | Server = ; |   |

   |   +---------+    = ; +---------+   |

   |        |&nb= sp;            =   |        |

   |        +---= ----+-------+        |

   |        = ;   +----------+         =  |

   |        = ;   | Database |         =  |

   |        = ;   +----------+         =  |

        |  &nb= sp;             = ;            &n= bsp;    |

   +---------------------------------+

 

Regards,

Michel

--=_98f9d46029f96dba3ad828af040a4b67-- From nobody Tue Jun 12 07:55:07 2018 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 97DC6130F4F; Tue, 12 Jun 2018 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 LS4M1JptM6pl; Tue, 12 Jun 2018 07:55:00 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CEC130E3D; Tue, 12 Jun 2018 07:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jsqhn8ZYk9GFp2WjPbkLt1668ln16K8YGapDvOygnCc=; b=1wuGdeJnpafjeqo188rHE2QoIa+LDx17w1CtgOtN7Wtq5/nagHLBVLo4/lcENgWqya8OXGSV0TzFyw8i41znAONFX374ofLf4hEsxDDYhPCR/7UOm3PeqmFa7kP5kHpCFj9uE1yQLk/qCDcc5Od0tv0qmz96hIvsfp5Wg04Ht0o= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB3004.namprd06.prod.outlook.com (10.175.109.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Tue, 12 Jun 2018 14:54:58 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::f8bd:cd7c:eb9e:b248]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::f8bd:cd7c:eb9e:b248%10]) with mapi id 15.20.0841.019; Tue, 12 Jun 2018 14:54:58 +0000 From: Michel Veillette To: Carsten Bormann CC: Peter van der Stok , Andy Bierman , Alexander Pelov , "Eric Voit (evoit)" , Henk Birkholz , "yot@ietf.org" , Core Thread-Topic: [core] YANG notification within CoMI Thread-Index: AdP/UVBv6lm2EKsrSzmsBpb94+0wbgC4TPCAAAmcHdA= Date: Tue, 12 Jun 2018 14:54:57 +0000 Message-ID: References: <836A7F59-C26B-4A6C-B9DE-331E9D1CB123@tzi.org> In-Reply-To: <836A7F59-C26B-4A6C-B9DE-331E9D1CB123@tzi.org> 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@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB3004; 7:vZ0PlvBmjbGQHKrEWNlr9gyZVIU5q58VXWwYKlqEEzzD8QaBPUJG4xbMt1XJsrbfA7wlnce9RhXvtFhRVo6+lKw8kXRpELldfc+fap1yooGV/JsmUnkQ9fbwaUFZ0bUdQYZj/V7+9Eq0guIFLnH3Jf4gWDg6cxZvitnJ7GqutNbyvmbtndThPrGOvb2tabWsS3JwKxAKToK9rn9zQe+F/rL7+peNAa/SOUZyRFkjtSeFwEa7AR5Ca/t+Zwd4Ifqn x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB3004; x-ms-traffictypediagnostic: DM5PR06MB3004: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB3004; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB3004; x-forefront-prvs: 07013D7479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(376002)(346002)(39380400002)(366004)(199004)(189003)(31014005)(13464003)(106356001)(5250100002)(229853002)(33656002)(14454004)(446003)(476003)(99286004)(54906003)(486006)(55016002)(345774005)(3846002)(68736007)(6116002)(551934003)(105586002)(316002)(478600001)(7736002)(305945005)(72206003)(6436002)(11346002)(102836004)(4326008)(25786009)(6246003)(6506007)(2906002)(15650500001)(53546011)(3660700001)(3280700002)(8676002)(6916009)(5660300001)(8936002)(81166006)(81156014)(26005)(186003)(76176011)(7696005)(86362001)(66066001)(74316002)(2900100001)(9686003)(97736004)(53936002)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB3004; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dTwzbU/2h9HVyR3P6r85WJwMkxJfVKOoVhkwpN4p2WeclxmXKWDWZmTLAfwN0nmONbCa09VMziXtBFmkn04o3OPz7TrFn/KADnFXY5Gi2l9KjuWkz3UTpnt8n/mce7UUKMG3ITZn8fgRSdumz4qVD5QxeRN3JVN7YrUoaaR1yvAoXXvC65X3ZTZpzqm2Iuxq spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 29aea41d-0f92-46f8-6e42-08d5d0747774 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29aea41d-0f92-46f8-6e42-08d5d0747774 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 14:54:58.0758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3004 Archived-At: Subject: Re: [core] YANG notification within CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 14:55:06 -0000 SGkgQ2Fyc3Rlbg0KDQpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciBwb2ludHMgb2YgdmlldyBvbiB0 aGlzIHN1YmplY3QuDQoNCkknbGwgZmlyc3QgdmFsaWRhdGUgaWYgdGhlIGFueWNhc3QgYWRkcmVz cyBjYW4gZWZmZWN0aXZlbHkgYWRkcmVzcyBteSBmaXJzdCBpc3N1ZS4NCkkgbmVlZCB0byB2ZXJp ZnkgaWYgSSBjYW4gY29uZmlndXJlIHRoZSBpbmZyYXN0cnVjdHVyZSB0byB1c2UgYW4gYW55Y2Fz dCBzb3VyY2UgYWRkcmVzcyBmb3IgbXkgQ29BUCB0cmFmZmljLg0KDQpUaGUgQ29BUCBsaWJyYXJ5 IGFscmVhZHkgc3VwcG9ydCBzaGFyaW5nIG9mIERUTFMgc3RhdGVzLg0KVGhpcyBmZWF0dXJlIGF0 IGxlYXN0IGVuYWJsZSBhIHNvbHV0aW9uIGJhc2VkIG9uIGEgUE9TVCBmb3JtIHRoZSBDb01JIHNl cnZlci4NCkkgYXNzdW1lIHRoYXQgdGhlIHNhbWUgdGVjaG5pcXVlIGlzIHBvc3NpYmxlIGZvciB0 aGUgb2JzZXJ2ZSBzdGF0ZXMsIHNvbWV0aGluZyB0byBiZSB2YWxpZGF0ZWQuDQoNCkkgaG9wZSB0 byBnZXQgdGhlc2UgYW5zd2VycyBwcmlvciB0byB0aGUgbmV4dCBJRVRGIGluIE1vbnRyZWFsLg0K DQpSZWdhcmRzLA0KTWljaGVsDQogDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Q2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXSANClNlbnQ6IFR1ZXNkYXksIEp1 bmUgMTIsIDIwMTggNTo0OCBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0 dGVAdHJpbGxpYW50LmNvbT4NCkNjOiBQZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25zQGJiaG1h aWwubmw+OyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IEFsZXhhbmRlciBQZWxv diA8YUBhY2tsLmlvPjsgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT47IEhlbmsg Qmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+OyB5b3RAaWV0Zi5vcmc7 IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIFlBTkcgbm90aWZpY2F0 aW9uIHdpdGhpbiBDb01JDQoNCkhpIE1pY2hlbCwNCg0Kc29ycnkgZm9yIGJlaW5nIHNsb3cgdG8g YW5zd2VyOyBJIGZpbmFsbHkgaGFkIGEgbmljZSBkaXNjdXNzaW9uIHdpdGggSGVuayB0b2RheSBh Ym91dCB5b3VyIGNvbmNlcm5zIHRoYXQgSSB3YW50IHRvIHN1bW1hcml6ZS4NCg0KTGV0IG1lIHBy b3Bvc2Ugc29tZSB0ZXJtaW5vbG9neSBmaXJzdDogIOKAnHNlcnZlcnPigJ0gYXJlIGEgQ29BUCB0 ZXJtLCBzbyB3aGVuIHdlIHRhbGsgYWJvdXQg4oCcaGVhdnkgYm94ZXMgd2l0aCBub2lzeSBmYW5z IGluc3RhbGxlZCBpbnRvIGEgcmFja+KAnSwgSeKAmWxsIHVzZSDigJxtYWNoaW5lc+KAnSAoYXMg b3Bwb3NlZCB0byDigJxkZXZpY2Vz4oCdIHRoYXQgYXJlIHRoZSBsaWdodCBidWxicyBiZWluZyBt YW5hZ2VkKS4gIE5vdCBncmVhdCB0ZXJtaW5vbG9neSwgYnV0IGJldHRlciB0aGFuIHVzaW5nIHRo ZSB0ZXJtIOKAnHNlcnZlcuKAnSBmb3IgYm90aC4NCg0KWW91IHdyaXRlIGFib3V0IHRoZSBvYnNl cnZlLWJhc2VkIG5vdGlmaWNhdGlvbnMgcHJvcG9zZWQgZm9yIENPTUk6DQoNCj4gMSkgVGhpcyBh cHByb2FjaCBpbiBpbmNvbXBhdGlibGUgd2l0aCBsb2FkIGJhbGFuY2Vycywgbm90aWZpY2F0aW9u cyBhcmUgZGlyZWN0bHkgcmV0dXJuZWQgdG8gdGhlIHNwZWNpZmljIHNlcnZlciB3aXRoaW4gdGhl IGNsdXN0ZXIgd2hpY2ggaGF2ZSBpbml0aWF0ZWQgdGhlIG9ic2VydmUgcmVxdWVzdC4NCg0KV2hl dGhlciB0aGF0IGlzIHRydWUgZGVwZW5kcyBhIGxvdCBvbiB3aGF0IGtpbmQgb2YgbG9hZCBiYWxh bmNlciB5b3UgYXJlIHRoaW5raW5nIGFib3V0Lg0KRm9yIFVEUCBDb0FQLCBhbiBhbnljYXN0IG1l Y2hhbmlzbSBpcyB0aGUgb2J2aW91cyBjaG9pY2UgZm9yIGEgbG9hZCBiYWxhbmNlci4NCg0KQ2xl YXJseSwgZm9yIGFueSBsb2FkIGJhbGFuY2luZyBtZWNoYW5pc20gdG8gYmUgdXNlZnVsLCB0aGUg bWFjaGluZXMgc2hhcmluZyB0aGUgbG9hZCBuZWVkIHRvIHNoYXJlIHN0YXRlIChzeW1ib2xpemVk IGJ5IOKAnGRhdGFiYXNl4oCdIGluIHlvdXIgZGlhZ3JhbSkuDQpJZiB0aGV5IGFyZSBjbGllbnRz LCB0aGV5IG5lZWQgdG8gc2hhcmUgY29tbXVuaWNhdGlvbiBzdGF0ZSBhcyB3ZWxsIGFzIGFwcGxp Y2F0aW9uIHN0YXRlIChlLmcuLCBhZGRyZXNzZXMgb2Ygc2VydmVycyB0aGV5IHRhbGsgdG8sIHRo ZSB0b2tlbnMgdGhleSB1c2UgZm9yIG91dGdvaW5nIHJlcXVlc3RzKS4gIFRoZXkgZG9u4oCZdCBu ZWVkIHRvIGRvIHRoaXMgZm9yIGV2ZXJ5IHNpbmdsZSB0cmFuc2FjdGlvbiAodGhleSBkb27igJl0 IGlmIHRoZXJlIGlzIG5vIHByb2JsZW0gaW4gYW4gb2NjYXNpb25hbCBsb3NzKSwgYnV0IHRoZXkg ZG8gaGF2ZSB0byBzaGFyZSBvYnNlcnZlIHN0YXRlLg0KDQpXaGVuIHBlb3BsZSB0YWxrIGFib3V0 IGxvYWQgYmFsYW5jZXJzIGFuZCByZXNpbGllbmNlLCB0aGV5IHNvbWV0aW1lcyBtZWFuIHRoYXQg dGhlIHBlZXIgd2l0aCBpbml0aWF0aXZlIChoZXJlOiB0aGUgQ29BUCBzZXJ2ZXIgc2VuZGluZyBh bm90aGVyIG5vdGlmaWNhdGlvbikgbmVlZHMgdG8gcGVyZm9ybSBhIGZ1bGwgcmVuZGV6dm91cyB3 aXRoIHRoZSBvdGhlciBzaWRlIChlLmcuLCBpbiB0aGUgQmlnIFdlYiwgYSBmcmVzaCBETlMgbG9v a3VwIHRoYXQgbWlnaHQgbGVhZCB0byBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IG1hY2hpbmUsIHBv dGVudGlhbGx5IGEgbmV3IFRMUyBzZXNzaW9uKS4gIFNlZSAoMykgYmVsb3cgZm9yIGhvdyB3ZSBz ZWUgdGhpcywgZm9yIG5vdyBsZXTigJlzIGp1c3Qgc2F5IHRoYXQgd2UgYXJlIHRyeWluZyB0byBh Y2hpZXZlIGdlbmVyYWxseSByZW5kZXp2b3VzLWZyZWUgbm90aWZpY2F0aW9ucy4NCg0KPiAyKSBU eXBpY2FsIENvQVAgaW1wbGVtZW50YXRpb24gKGUuZy4gQ2FsaWZvcm5pdW0pIGRvZXNuJ3Qgc3Vw cG9ydCB0aGUgcGVyc2lzdGVuY2Ugb2YgdGhlIG9ic2VydmUgY29udGV4dC4gVGhlc2UgY29udGV4 dHMgY2Fu4oCZdCBiZSByZWNvdmVyZWQgYWZ0ZXIgYSBzZXJ2ZXIgcmVzdGFydCBhbmQgY2FuJ3Qg YmUgc2hhcmVkIGJldHdlZW4gc2VydmVycy4NCg0KVGhhdCBpcyBpbmRlZWQgYSBwcm9ibGVtLiAg QnV0IHRoZSByZWFsIHByb2JsZW0gaXMgdGhhdCB0aGV5IGFyZSBub3QgcmVhZHkgZm9yIHNoYXJp bmcgdGhlaXIgY2xpZW50IHN0YXRlIGF0IGFsbC4gIE9uY2UgdGhleSBhcmUsIGFkZGluZyBwZXJz aXN0ZW5jZSB0byB0aGF0IHNoYXJpbmcgYmVjb21lcyBhIHJhdGhlciBzdHJhaWdodGZvcndhcmQg ZXhlcmNpc2UuDQoNClNvIHdoYXQgSeKAmW0gcmVhZGluZyBvdXQgb2YgeW91ciBtZXNzYWdlIGlz IHRoYXQsIHRvIGVtcGxveSBsb2FkIGJhbGFuY2luZyBmb3IgQ09NSSBub3RpZmljYXRpb25zLCBD b0FQIGltcGxlbWVudGF0aW9ucyBuZWVkIHRvIGdyb3cgc3VwcG9ydCBmb3Igc2hhcmluZyBjb21t dW5pY2F0aW9uIHN0YXRlIChwcmVmZXJhYmx5IHdpdGggYSBwZXJzaXN0ZW50IG1vZGUpLiAgVGhh dCBpcyBhbiBpbXBvcnRhbnQgbWVzc2FnZSB0byBpbXBsZW1lbnRlcnMsIGFuZCB0aGFuayB5b3Ug Zm9yIGhpZ2hsaWdodGluZyB0aGlzLg0KDQo+IDMpIFJlZ2lzdHJhdGlvbnMgdG8gZXZlbnQgc3Ry ZWFtcyBhcmUgbm90IHJlc2lsaWVudCwgdGhleSBjYW4gdGVybWluYXRlIHVuZXhwZWN0ZWRseSB1 cG9uIHRyYW5zbWlzc2lvbiBlcnJvciBvciByZWNlcHRpb24gb2YgYSBSZXNldCBtZXNzYWdlLg0K DQpOb3cgaG93IGRvZXMgdGhlIHJlc2lsaWVuY2UgY29tZSBpbj8NCg0KSW4gdGhlIEJpZyBXZWIg c2l0dWF0aW9uIG1lbnRpb25lZCBhYm92ZSwgaXQgY29tZXMgZnJvbSByZWRvaW5nIHRoZSByZW5k ZXp2b3VzIGVhY2ggdGltZSBhIG5vdGlmaWNhdGlvbiBpcyBuZWVkZWQgKHBvdGVudGlhbGx5IHdp dGggc29tZSBjYWNoaW5nLCBib3RoIG9mIEROUyBzdGF0ZSBbbGVhZGluZyB0byBkZWZpbmVkIHBl cmlvZHMgb2YgYmxhY2tob2xpbmddIGFuZCBvZiBhbnkgY29ubmVjdGlvbnMgc3RpbGwgb3BlbiBb d2hpY2ggd2lsbCBob3BlZnVsbHkgdGltZSBvdXQgaWYgdGhlcmUgaXMgYSBwcm9ibGVtXS4gIA0K DQpJbiBhIHJlbmRlenZvdXMtZnJlZSB3b3JsZCwgd2UgaGF2ZSB0byBkbyB0aGlzIGV4cGxpY2l0 bHkuICBGb3IgYSBDb0FQIHNlcnZlciB0aGF0IGNhcmVzIGFib3V0IGRlbGl2ZXJpbmcgdGhlIG5v dGlmaWNhdGlvbnMsIGl0IHdpbGwgc2VuZCAoYXQgbGVhc3Qgc29tZSBvZikgdGhlIG5vdGlmaWNh dGlvbnMgYXMgY29uZmlybWFibGUgbWVzc2FnZXMgW2l0IGFjdHVhbGx5IGhhcyB0bywgb25jZSBl dmVyeSAyNCBob3VycywgYnV0IGNhbiBkbyB0aGF0IG1vcmUgb2Z0ZW4gaWYgcmVzaWxpZW5jZSBj YWxscyBmb3IgaXRdLiAgU28gaXQgd2lsbCBub3RpY2Ugd2hlbiB0aGUgcmVjaXBpZW50IG9mIHRo ZSBub3RpZmljYXRpb25zIGlzIG5vIGxvbmdlciB0aGVyZS4gIFtJdCB3aWxsIGFsc28gbm90aWNl IGlmIHRoZSByZWNpcGllbnQgaXMgY29uZnVzZWQgZW5vdWdoIHRvIHNlbmQgYSBSZXNldCwgYnV0 IHBlcnNpc3RlbmNlIG9mIGNvbW11bmljYXRpb24gc3RhdGUgaXMgc3VwcG9zZWQgdG8gbWFrZSB0 aGlzIGEgbm9uLWV2ZW50Ll0gIFJGQyA3NjQxIHRlbGxzIHVzIHRoYXQgdGhlIENvQVAgc2VydmVy IGlzIHRvIGNlYXNlIGRlbGl2ZXJpbmcgbm90aWZpY2F0aW9ucyB3aGVuIHRoZSBjbGllbnQgbWFj aGluZSBnb2VzIGF3YXkuICBJdCBkb2VzbuKAmXQgdGVsbCB1cyB3aGF0IGVsc2UgdGhlIGltcGxl bWVudGF0aW9uIG1pZ2h0IHdhbnQgdG8gZG8gaW4gdGhhdCBldmVudC4gIEluIGEgQ09NSSBjYWxs IGhvbWUgc2NlbmFyaW8sIEkgd291bGQgZXhwZWN0IHRoZSBkZXZpY2UgdG8gbm90aWNlIHRoYXQg aXRzIHJlbGF0aW9uc2hpcCB0byBob21lIGJyb2tlIGFuZCByZWRvIHRoZSByZW5kZXp2b3VzIChj YWxsIGhvbWUpIOKAlCBvbmNlLCB3aGVuIG5lZWRlZCwgbm90IGZvciBldmVyeSB0cmFuc2FjdGlv biAobWl0aWdhdGVkIG9ubHkgYnkgY2FjaGluZykuICANCg0KU28sIGluIGVmZmVjdCwgd2UgY2Fu IGhhdmUgYWxsIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSDigJxkbyB0aGUgcmVuZGV6dm91cyBhbHdh eXMsIHdpdGggY2FjaGluZ+KAnSB3b3JsZCB3aXRoIG11Y2ggbGVzcyBibGFjay1ob2xpbmcgYW5k IHVubmVjZXNzYXJ5IG1lc3NhZ2Ugb3ZlcmhlYWQuDQoNCkZvciB0aGUgYWJvdmUgdG8gYmUgYWN0 aW9uYWJsZSwgd2UgZG8gaGF2ZSB0byBoYXZlIGltcGxlbWVudGF0aW9ucyB0aGF0Og0K4oCUIG9u IHRoZSBiaWcgbWFjaGluZXMsIGNhbiBzaGFyZSBlbm91Z2ggY29tbXVuaWNhdGlvbiBzdGF0ZSBz byB0aGV5IGNhbiB0YWtlIHBhcnQgaW4gYW55Y2FzdC1iYXNlZCBsb2FkIGJhbGFuY2luZywg4oCU IG9uIHRoZSBzbWFsbCBkZXZpY2VzLCBjYW4gcmVhY3QgdG8gbG9zcyBvZiBhbiBvYnNlcnZhdGlv biBpbnRlcmVzdCBieSByZWRvaW5nIGEgY2FsbC1ob21lIHRyYW5zYWN0aW9uLg0KDQpUaGUgc2Vj b25kIG9uZSBjbGVhcmx5IGlzIGFuIGltcGxlbWVudGF0aW9uIHF1YWxpdHkgcmVxdWlyZW1lbnQu ICBMZXTigJlzIHdvcmsgb24gdGhhdCB3aXRoIHRoZSBpbXBsZW1lbnRlcnMuDQpUaGUgZmlyc3Qg Y291bGQgYmUgdGhvdWdodCB0byBjYWxsIGZvciBhIHByb3RvY29sIGZvciBjb29yZGluYXRpbmcg dGhlIG1hY2hpbmVzLiAgVGhlIElFVEYgaGFzIG5vdCBiZWVuIHZlcnkgc3VjY2Vzc2Z1bCBpbiBl c3RhYmxpc2hpbmcg4oCccmVsaWFibGUgc2VydmVyIHBvb2xpbmfigJ0uICBJIHdvdWxkIGFjdHVh bGx5IGV4cGVjdCBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3YW50IHRvIHByb3ZpZGUgdGhhdCBjb29y ZGluYXRpb24gdG8gY29tZSB3aXRoIHRoZWlyIG93biBoaWdoLXBlcmZvcm1hbmNlIG1lY2hhbmlz bXMsIGludm9sdmluZyB0aGUgdXN1YWwgc3RhdGUgc2hhcmluZyBkYXRhYmFzZXMgc3VjaCBhcyBS ZWRpcyDigJQgdGhleSBhbHJlYWR5IGhhdmUgdG8gZG8gdGhpcyB3aXRoIHRoZSBtYW5hZ2VtZW50 IChhcHBsaWNhdGlvbikgc3RhdGUgc2hhcmVkIGJldHdlZW4gdGhlIG1hY2hpbmVzLg0KDQpHcsO8 w59lLCBDYXJzdGVuDQoNCg== From nobody Thu Jun 14 01:49:55 2018 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 AC2C2130E03 for ; Thu, 14 Jun 2018 01:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieYKNWoKqRAs for ; Thu, 14 Jun 2018 01:49:51 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 533AE12F1A6 for ; Thu, 14 Jun 2018 01:49:51 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id z6-v6so2275855wma.0 for ; Thu, 14 Jun 2018 01:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ImWzzCUOO2bgekSPi7TVOxD6gqx5c0duCc7Wo094ddg=; b=E/Is/Rou4Q8VKYR98W/kquvWim9hzBLjEtKzqg1e67Nw5oxHRsJrXdoBRrh4UbC+oc lyz03SWgNqPmTuWGAb70qz7/98nQC+G93qfYu8Vc6o28PGKABKrLiyLTkuXZPzv9HFzf YzX1w0B5XPNiiLQiYYNc5V+rzuiY5252U0vH/Mzqb2NoLazPj/+tn5uMPLnR9SKOxofs zaOShjJA3/3uQ9ze8LgfGRiBaV81Ja1HWjAC/P837gHlArmI5mHq/7Q97Opf+DB86sSL YPoemuaciDH4atIZGlUJ5+gMYLhiw8DzxzuvTMvu5k1H2Bky15sB4szDR3U/sM7rQxFG BPnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ImWzzCUOO2bgekSPi7TVOxD6gqx5c0duCc7Wo094ddg=; b=VtpAHaG4fyY7LrtmT16L2L30kFrLId4/Kh7KOrKFcyKRNvhFAbQqjH6n7ZkQCNfGTK 1Dvhx1UiDtXsrbeirDh7m0Snv49V1CdYLrK6IaGArrJvYMCRri5POCjSWfsdS+QP5Get LzCRzZ8qxXOU0LZO+IRsjveyKMsEv4ALFdvXWX0ChfefzonxolZGn0uHCYrcUpow79AZ IHjBN7euuADMfVeRaavZJnFcZjxYZKypIERDJndgA+w+pmnrA49C5Qd0iXP1ZVVy57ud Wr04jy1dXd3FXoq36bdZGWHsJ1SxbOXGJ0NGRgN2aHNqCiH5cw75g61pcblL8S8VrEbz C1XQ== X-Gm-Message-State: APt69E2TsHc/AqqErSt8MXx35xeQ4od0wopMljxIaHMWQOf5pO65VO5r DEbK541JGo7eo2qN1aEW0y6YP3B/FvNH7Jnpkv0= X-Google-Smtp-Source: ADUXVKJMzj02BwDipeolxc/XKxOo9hBfP1cwYPEH7ESqwxlSXVmj3779qb5JeCZGtO280gKF5M7zyisLJfhFQXZFZFE= X-Received: by 2002:a50:ada1:: with SMTP id a30-v6mr1854641edd.88.1528966189846; Thu, 14 Jun 2018 01:49:49 -0700 (PDT) MIME-Version: 1.0 References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> In-Reply-To: From: Padmakumar Subramani Date: Thu, 14 Jun 2018 14:19:38 +0530 Message-ID: To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000009e9390056e962eda" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 08:49:54 -0000 --0000000000009e9390056e962eda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Mon, Jun 11, 2018 at 10:32 AM Jaime Jim=C3=A9nez wrote: > Dear all, > > based on the ongoing discussion on the Multipart Content-Format for CoAP > and the dependency with ACE, we will issue a 2 week Working group Adoptio= n > call for this draft. > > Ciao! > - - Jaime Jim=C3=A9nez > > On 8 Jun 2018, at 16.41, Carsten Bormann wrote: > > I updated the draft based on the input we have so far (thanks to everyone > replying!). > (I added alternative text media-type labels as a trial balloon; we can > always remove them in the WG discussion. > We can also decide between single-byte and two-byte identifier.) > > Name: draft-fossati-core-multipart-ct > Revision: 05 > Title: Multipart Content-Format for CoAP > Htmlized: > https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-05 > > This should be ready for working-group adoption call now. > > Gr=C3=BC=C3=9Fe, Carsten > > > Please initiate > > On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez > wrote: > > Hi, > > Thank you all for the constructive discussion. To summarise some of the > raised points so far: > > - Dependency on EST-COAP, which is targeted for WGLC in next IETF. > - Multipart/core can't be registered. AD pointed out that it is not > possible to register "multipart" as a top-level media type. Author's > proposal to rename it under application (i.e. - > "application/multipart-core"). > - Should the identifier be a single byte or two? > - Expert media-type review confirmation needed. > > If the authors could submit a new version soon, I=E2=80=99ll trigger the = WGA call > so that we have consensus on the draft before next IETF. > > Ciao! > - - Jaime Jim=C3=A9nez > > On 7 Jun 2018, at 1.10, Michael Richardson wrote: > > > Carsten Bormann wrote: > > On Jun 6, 2018, at 19:47, Michael Richardson > wrote: > > The only other name I might imagine is application/multipart-cbor, as > slightly more descriptive, but it's a bikeshed question. > > > There is not that much CBOR there=E2=80=A6. But the interesting point ab= out > this specific format is not so much the razor-thin CBOR envelope, but > that this is using Content-Format identifiers from the CoRE Parameters > registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed name.= We may want to > > > That's a reasonable argument for calling it multipart-core. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > _______________________________________________ > 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 > --0000000000009e9390056e962eda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Mon, Jun 11, 2018 at 10:32 AM Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
<= /div>
Dear all,

based on the ongoing= discussion on the=C2=A0Multipart Content-Format for CoAP and the dependenc= y with ACE, we will issue a 2 week Working group Adoption call for this dra= ft.

Ciao!
- - Jaime Jim=C3=A9nez

On 8 Jun 2018, at 16.41, Carsten Bo= rmann <cabo@tzi.org> wrote:

I updated the draft based on the input we have so far (thank= s to everyone replying!).
(I added alternative text media-type labels as= a trial balloon; we can always remove them in the WG discussion.
We can= also decide between single-byte and two-byte identifier.)

Name: draft-fossati-core-multipart-ct
Revision:<= span class=3D"m_-4938192096718792848Apple-tab-span" style=3D"white-space:pr= e-wrap"> 05
Title: Multipart Con= tent-Format for CoAP
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05=
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-= ct-05" target=3D"_blank">https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-= core-multipart-ct-05

This should be ready for working-group adop= tion call now.

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


Please initiate <= br>
On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9n= ez <jaim= e.jimenez@ericsson.com> wrote:

Hi,

Thank you all for t= he constructive discussion. To summarise some of the raised points so far:<= br>
- Dependency on EST-COAP, which is targeted for WGLC in next IETF.- Multipart/core can't be registered. AD pointed out that it is not p= ossible to register "multipart" as a top-level media type. Author= 's proposal to rename it under application (i.e. - "application/mu= ltipart-core").
- Should the identifier be a single byte or two?- Expert media-type review confirmation needed.

If the authors coul= d submit a new version soon, I=E2=80=99ll trigger the WGA call so that we h= ave consensus on the draft before next IETF.

Ciao!
- - Jaime Jim= =C3=A9nez

On 7 Jun 2018, at 1.10, Michael = Richardson <m= cr+ietf@sandelman.ca> wrote:


Carsten Bormann <cabo@tzi.org> wrote:
<= blockquote type=3D"cite">
On Jun 6, 2018, at 19:47= , Michael Richardson <mcr+ietf@sandelman.ca> wrote:

The only other name I = might imagine is application/multipart-cbor, as
slightly more descriptiv= e, but it's a bikeshed question.

There is not that much CBOR there=E2=80=A6.=C2=A0 But = the interesting point about
this specific format is not so much the razo= r-thin CBOR envelope, but
that this is using Content-Format identifiers = from the CoRE Parameters
registry =E2=80=94 hence the =E2=80=9Ccore=E2= =80=9D in the proposed name.=C2=A0 We may want to

That&= #39;s a reasonable argument for calling it multipart-core.

--
] = =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=A0Never tell me the odds! =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| ipv6 mesh networks = [
] =C2=A0=C2=A0Michael Richardson, Sandelman Software Works =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| network architect =C2=A0[
] =C2=A0= =C2=A0=C2=A0=C2=A0mcr= @sandelman.ca =C2=A0http://www.sandelman.ca/ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | =C2=A0=C2=A0ruby on rails =C2=A0=C2=A0=C2=A0[

__= _____________________________________________
core mailing list
core@ietf.org
https://w= ww.ietf.org/mailman/listinfo/core


=

____________________________= ___________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000009e9390056e962eda-- From nobody Sat Jun 16 06:34:52 2018 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 A7DAD130E43; Sat, 16 Jun 2018 06:34:36 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF0dZeYVGIMU; Sat, 16 Jun 2018 06:34:33 -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 5BD5B130E3E; Sat, 16 Jun 2018 06:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5GDYTh3016843; Sat, 16 Jun 2018 15:34:29 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 417JHT4FM3zDXmH; Sat, 16 Jun 2018 15:34:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 550848867.3362-46253f92ae822c5022ffbc08a3f25e61 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 16 Jun 2018 15:34:28 +0200 Message-Id: To: ace , Core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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: Sat, 16 Jun 2018 13:34:37 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a personal problem for me, throwing in TEEP on top is a bit weird, though. 6TISCH vs. SUIT is probably painful for the few individuals who care about security in both. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Viger INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Viger ART *** core Constrained RESTful Environments WG Place du Canada INT intarea Internet Area Working Group WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Duluth ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC secdispatch Security Dispatch WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Van Horne INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** suit Software Updates for Internet of Things = WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Centre Ville OPS v6ops IPv6 Operations WG Viger RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Viger IRTF*** t2trg Thing-to-Thing Duluth OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Duluth IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Mon Jun 18 01:36:23 2018 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 3103A1277D2 for ; Mon, 18 Jun 2018 01:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIlyv8-QVzwo for ; Mon, 18 Jun 2018 01:36:17 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 8465F1277C8 for ; Mon, 18 Jun 2018 01:36:17 -0700 (PDT) Received: from mail-it0-f41.google.com ([209.85.214.41]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fUpe3-0000sf-CS; Mon, 18 Jun 2018 10:36:15 +0200 Received: by mail-it0-f41.google.com with SMTP id 76-v6so10806742itx.4 for ; Mon, 18 Jun 2018 01:36:15 -0700 (PDT) X-Gm-Message-State: APt69E2OGm8USlT2UcQ6huVs+nfu9PktmY2pXzdzuhNpGu4j72GZUROY ipwMZGK2+iAEry4zfXDJluJdjwrW7bKHSs0ZuY4= X-Google-Smtp-Source: ADUXVKK/Vj0eAOQIzxV0SRyclKrGx+1gHXU3LO/CvYI0NaORrujMPMmJ24EHT5gD6SKb6XfpiG1d4Et6KkZqQVemh5g= X-Received: by 2002:a02:1989:: with SMTP id b131-v6mr9373056jab.114.1529310974012; Mon, 18 Jun 2018 01:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:a05:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 01:35:33 -0700 (PDT) In-Reply-To: References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> From: Klaus Hartke Date: Mon, 18 Jun 2018 10:35:33 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Padmakumar Subramani Cc: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG (core@ietf.org)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1529310977; 36dcced1; X-HE-SMSGID: 1fUpe3-0000sf-CS Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 08:36:21 -0000 +1 On 14 June 2018 at 10:49, Padmakumar Subramani wrote: > +1 > > On Mon, Jun 11, 2018 at 10:32 AM Jaime Jim=C3=A9nez > wrote: >> >> Dear all, >> >> based on the ongoing discussion on the Multipart Content-Format for CoAP >> and the dependency with ACE, we will issue a 2 week Working group Adopti= on >> call for this draft. >> >> Ciao! >> - - Jaime Jim=C3=A9nez >> >> On 8 Jun 2018, at 16.41, Carsten Bormann wrote: >> >> I updated the draft based on the input we have so far (thanks to everyon= e >> replying!). >> (I added alternative text media-type labels as a trial balloon; we can >> always remove them in the WG discussion. >> We can also decide between single-byte and two-byte identifier.) >> >> Name: draft-fossati-core-multipart-ct >> Revision: 05 >> Title: Multipart Content-Format for CoAP >> Htmlized: >> https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-05 >> >> This should be ready for working-group adoption call now. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> Please initiate >> >> On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez >> wrote: >> >> Hi, >> >> Thank you all for the constructive discussion. To summarise some of the >> raised points so far: >> >> - Dependency on EST-COAP, which is targeted for WGLC in next IETF. >> - Multipart/core can't be registered. AD pointed out that it is not >> possible to register "multipart" as a top-level media type. Author's >> proposal to rename it under application (i.e. - >> "application/multipart-core"). >> - Should the identifier be a single byte or two? >> - Expert media-type review confirmation needed. >> >> If the authors could submit a new version soon, I=E2=80=99ll trigger the= WGA call >> so that we have consensus on the draft before next IETF. >> >> Ciao! >> - - Jaime Jim=C3=A9nez >> >> On 7 Jun 2018, at 1.10, Michael Richardson wrote= : >> >> >> Carsten Bormann wrote: >> >> On Jun 6, 2018, at 19:47, Michael Richardson >> wrote: >> >> The only other name I might imagine is application/multipart-cbor, as >> slightly more descriptive, but it's a bikeshed question. >> >> >> There is not that much CBOR there=E2=80=A6. But the interesting point a= bout >> this specific format is not so much the razor-thin CBOR envelope, but >> that this is using Content-Format identifiers from the CoRE Parameters >> registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed name= . We may want to >> >> >> That's a reasonable argument for calling it multipart-core. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s >> [ >> >> _______________________________________________ >> 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 > From nobody Mon Jun 18 02:26:36 2018 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 07A86130DC6 for ; Mon, 18 Jun 2018 02:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 ZLvOPD5OCBy2 for ; Mon, 18 Jun 2018 02:26:28 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 664F71277C8 for ; Mon, 18 Jun 2018 02:26:28 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id a12-v6so16045001wro.1 for ; Mon, 18 Jun 2018 02:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pBv1WWlb6syeT+XP2Jw8zAUXweqNuK5OpIeVuUFZfgs=; b=UVY2GnI6WdumVRAc2CkUK1sI+4sk3Q0oW5c7s7yUAuWm/d366E96PbBdFemFjiwrnh 4/Rceu4KPueMreHw355NbT6MEHWg1T/n+alVuF4dQGweJmAZeSdLyFXyqCg0QJA+rCxY 5nOSx2weXFj+jHAdX+eHgBMui5CPUSZjYFVpwqieFraP1AvgVnBQAKbXx+K+Z1tNmrWa cqWSHuBqN94qM/nnec8ZQD9nrJaavQDvdfa+NzNZvcTSuOY7mp5XPcwMuVQ+PfnNvLVK HfM0TUTgnrZnmsWJtmtz+b7ZO2eQO8BRW2OYhJGcC31K25QysjqeU5tk8rlkjDZPrYad Hjlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pBv1WWlb6syeT+XP2Jw8zAUXweqNuK5OpIeVuUFZfgs=; b=PvDk3mtMrD5VvalagYamjRMZFW/dvAi1TdnmgO4NZFugKIrlNOtTz9PdYC8XGaQZyc SQdVzfhW4bSuC1+1267h5ZJzikTxVpIui1lRYghAgNb5Ie0Bv+Pa+5Icu8v7ScIvrtMS 268EicdsKwEsXlZ1/Y9bDhJ/jA3Ns3+kfL90NMC511yHkHUzxpLP0aDRPn+REeWVrdrz yGe/RBEoL9C0AiuCPAvI03k0aPdUFm2RqeAIyyEPrCTMKWhEhs0WMD4V0liIc1r4iw11 +d5EeKxl0S+XFJTS+ccyH8BpCnHSkA8AHPyLTxgj1pshh84f7ppg1wHQmshuANgfUDrU 2OTw== X-Gm-Message-State: APt69E3SV/EGXygGRPkKRjzzsBkbW4PcL1wb1FPDs2vgrZY7+aapzufz U+9IuBh+pejAP+JEDJ4JLxNvYg== X-Google-Smtp-Source: ADUXVKLf8cfFVPtn7W22Prq4a9rkaIKI7V4eh2bX5Xu9Gm2MLFxT338W8wu80RG/ZoYhK8mbDnYw6w== X-Received: by 2002:adf:e987:: with SMTP id h7-v6mr9413411wrm.102.1529313986883; Mon, 18 Jun 2018 02:26:26 -0700 (PDT) Received: from [192.168.1.180] ([185.122.161.249]) by smtp.gmail.com with ESMTPSA id u11-v6sm10313566wmd.7.2018.06.18.02.26.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 02:26:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Alexander Pelov In-Reply-To: Date: Mon, 18 Jun 2018 11:26:24 +0200 Cc: Padmakumar Subramani , "core@ietf.org WG (core@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <32DD9EB8-4264-4CC9-82A8-B7DCA16E74E3@ackl.io> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 09:26:34 -0000 +1 Best, Alexander > Le 18 juin 2018 =C3=A0 10:35, Klaus Hartke a = =C3=A9crit : >=20 > +1 >=20 > On 14 June 2018 at 10:49, Padmakumar Subramani = wrote: >> +1 >>=20 >> On Mon, Jun 11, 2018 at 10:32 AM Jaime Jim=C3=A9nez = >> wrote: >>>=20 >>> Dear all, >>>=20 >>> based on the ongoing discussion on the Multipart Content-Format for = CoAP >>> and the dependency with ACE, we will issue a 2 week Working group = Adoption >>> call for this draft. >>>=20 >>> Ciao! >>> - - Jaime Jim=C3=A9nez >>>=20 >>> On 8 Jun 2018, at 16.41, Carsten Bormann wrote: >>>=20 >>> I updated the draft based on the input we have so far (thanks to = everyone >>> replying!). >>> (I added alternative text media-type labels as a trial balloon; we = can >>> always remove them in the WG discussion. >>> We can also decide between single-byte and two-byte identifier.) >>>=20 >>> Name: draft-fossati-core-multipart-ct >>> Revision: 05 >>> Title: Multipart Content-Format for CoAP >>> Htmlized: >>> https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-05= >>>=20 >>> This should be ready for working-group adoption call now. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>> Please initiate >>>=20 >>> On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez = >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Thank you all for the constructive discussion. To summarise some of = the >>> raised points so far: >>>=20 >>> - Dependency on EST-COAP, which is targeted for WGLC in next IETF. >>> - Multipart/core can't be registered. AD pointed out that it is not >>> possible to register "multipart" as a top-level media type. Author's >>> proposal to rename it under application (i.e. - >>> "application/multipart-core"). >>> - Should the identifier be a single byte or two? >>> - Expert media-type review confirmation needed. >>>=20 >>> If the authors could submit a new version soon, I=E2=80=99ll trigger = the WGA call >>> so that we have consensus on the draft before next IETF. >>>=20 >>> Ciao! >>> - - Jaime Jim=C3=A9nez >>>=20 >>> On 7 Jun 2018, at 1.10, Michael Richardson = wrote: >>>=20 >>>=20 >>> Carsten Bormann wrote: >>>=20 >>> On Jun 6, 2018, at 19:47, Michael Richardson >>> wrote: >>>=20 >>> The only other name I might imagine is application/multipart-cbor, = as >>> slightly more descriptive, but it's a bikeshed question. >>>=20 >>>=20 >>> There is not that much CBOR there=E2=80=A6. But the interesting = point about >>> this specific format is not so much the razor-thin CBOR envelope, = but >>> that this is using Content-Format identifiers from the CoRE = Parameters >>> registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed = name. We may want to >>>=20 >>>=20 >>> That's a reasonable argument for calling it multipart-core. >>>=20 >>> -- >>> ] Never tell me the odds! | ipv6 mesh >>> networks [ >>> ] Michael Richardson, Sandelman Software Works | network >>> architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails >>> [ >>>=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 >>=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 From nobody Mon Jun 18 02:26:58 2018 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 2EC45130EEE for ; Mon, 18 Jun 2018 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 sXbsUFLfFbbA for ; Mon, 18 Jun 2018 02:26:44 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 C70C8130E9E for ; Mon, 18 Jun 2018 02:26:43 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id e18-v6so16043449wrs.5 for ; Mon, 18 Jun 2018 02:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AZw54/6zcJXZx6ZcKb/hbEhrGR4QFUUcKPmNeT6j7wU=; b=jLqDCFzF+7B8lK0uEGNqVfOgniUdFYf8D3i7L9lCgrgaUtbxEIfLMR52f04QMH3PGO IvKn/+ln2NNRe8ssgr6t23l4fHMjkRNdRY/EMSamnwQ/WMYzAtb43ZBqwXlMDX0ApTxl A8KeYx2nqL0cl8q/KH0nBkv7J7wXl9O5DR1r7jlN9U7aMt9Voot46EdYjI6KuF3QP6dR HPte5TKwoS5cjVrEfVL0RJhRuaPJg5pEVMWeYEqM/t1Mb/aeA1NtV0fJh8bFkSyrOOb4 YXcoUdh+zhjTGZKjPtJd9avEZo+p/JaLyf2Zc8zr9ok/9ScHmca7MGyk5pzeRAe5es8L S98Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AZw54/6zcJXZx6ZcKb/hbEhrGR4QFUUcKPmNeT6j7wU=; b=tk+BROiVbuXzs4LzKWj2vfbb2/BphVX9xAK4v+7qf9xF6OqX5Dmp5cLkQDqaUf2Acu 06kUTh50bmfMX2+X4ueFniBtPQrwpc7DXwoAOl8zvY1rpZ7ybIJtkz7ix0bcMPn+bTUs qkhs+lP9gQQBoPWK0Hs7eX2zjY7va+iz52B80EWpfLyll+MSs52opj1PsmIGo0yOt/T0 kX4Q8GIEmFyis31veum/iLB+DVGzrBTvm0+KQUq1DV+Mp2Ws8eRv72MNei+mH0w4cp1C bVWIFbZeqCnP5d5Tev5XoOxZ9eLbNis6vaGs1APUER8Tqyj2G4+JCd6YK+fVix6wvEj8 0kYw== X-Gm-Message-State: APt69E0hW+gRXFEFz/v7DHhi2jv2uNDNjeNrYL/uVeIP+nQXUfWTlO4j 0HhKoX9fUYvCyCg6d2ZkFL033Q== X-Google-Smtp-Source: ADUXVKJLD6b7uA4LwVp2tviJUMJCSO/ctcfsIN5y+o0FAvG+hcpGfDa2gKm//emFRdPExFaMz70RqA== X-Received: by 2002:adf:9d02:: with SMTP id k2-v6mr9395340wre.213.1529314002354; Mon, 18 Jun 2018 02:26:42 -0700 (PDT) Received: from [192.168.1.180] ([185.122.161.249]) by smtp.gmail.com with ESMTPSA id u11-v6sm10313566wmd.7.2018.06.18.02.26.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 02:26:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Alexander Pelov In-Reply-To: Date: Mon, 18 Jun 2018 11:26:40 +0200 Cc: Padmakumar Subramani , "core@ietf.org WG (core@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <333FB83B-0B0B-4A7E-8888-3A902D4B2343@ackl.io> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 09:26:56 -0000 +1 Best, Alexander > Le 18 juin 2018 =C3=A0 10:35, Klaus Hartke a = =C3=A9crit : >=20 > +1 >=20 > On 14 June 2018 at 10:49, Padmakumar Subramani = wrote: >> +1 >>=20 >> On Mon, Jun 11, 2018 at 10:32 AM Jaime Jim=C3=A9nez = >> wrote: >>>=20 >>> Dear all, >>>=20 >>> based on the ongoing discussion on the Multipart Content-Format for = CoAP >>> and the dependency with ACE, we will issue a 2 week Working group = Adoption >>> call for this draft. >>>=20 >>> Ciao! >>> - - Jaime Jim=C3=A9nez >>>=20 >>> On 8 Jun 2018, at 16.41, Carsten Bormann wrote: >>>=20 >>> I updated the draft based on the input we have so far (thanks to = everyone >>> replying!). >>> (I added alternative text media-type labels as a trial balloon; we = can >>> always remove them in the WG discussion. >>> We can also decide between single-byte and two-byte identifier.) >>>=20 >>> Name: draft-fossati-core-multipart-ct >>> Revision: 05 >>> Title: Multipart Content-Format for CoAP >>> Htmlized: >>> https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-05= >>>=20 >>> This should be ready for working-group adoption call now. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>> Please initiate >>>=20 >>> On Jun 7, 2018, at 09:33, Jaime Jim=C3=A9nez = >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Thank you all for the constructive discussion. To summarise some of = the >>> raised points so far: >>>=20 >>> - Dependency on EST-COAP, which is targeted for WGLC in next IETF. >>> - Multipart/core can't be registered. AD pointed out that it is not >>> possible to register "multipart" as a top-level media type. Author's >>> proposal to rename it under application (i.e. - >>> "application/multipart-core"). >>> - Should the identifier be a single byte or two? >>> - Expert media-type review confirmation needed. >>>=20 >>> If the authors could submit a new version soon, I=E2=80=99ll trigger = the WGA call >>> so that we have consensus on the draft before next IETF. >>>=20 >>> Ciao! >>> - - Jaime Jim=C3=A9nez >>>=20 >>> On 7 Jun 2018, at 1.10, Michael Richardson = wrote: >>>=20 >>>=20 >>> Carsten Bormann wrote: >>>=20 >>> On Jun 6, 2018, at 19:47, Michael Richardson >>> wrote: >>>=20 >>> The only other name I might imagine is application/multipart-cbor, = as >>> slightly more descriptive, but it's a bikeshed question. >>>=20 >>>=20 >>> There is not that much CBOR there=E2=80=A6. But the interesting = point about >>> this specific format is not so much the razor-thin CBOR envelope, = but >>> that this is using Content-Format identifiers from the CoRE = Parameters >>> registry =E2=80=94 hence the =E2=80=9Ccore=E2=80=9D in the proposed = name. We may want to >>>=20 >>>=20 >>> That's a reasonable argument for calling it multipart-core. >>>=20 >>> -- >>> ] Never tell me the odds! | ipv6 mesh >>> networks [ >>> ] Michael Richardson, Sandelman Software Works | network >>> architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails >>> [ >>>=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 >>=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 From nobody Mon Jun 18 02:53:12 2018 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 BAFEA130E8D for ; Mon, 18 Jun 2018 02:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795] 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 QQvdpOfOk5Sy for ; Mon, 18 Jun 2018 02:52:39 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E35130E8F for ; Mon, 18 Jun 2018 02:52:36 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id A39D3248A4; Mon, 18 Jun 2018 09:52:35 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:152:355:379:582:599:962:967:973:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1730:1776:1792:2194:2198:2199:2200:2527:2553:2559:2562:2894:2895:2901:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4120:4250:4362:4860:5007:6119:6261:6678:7901:7903:7904:8603:8784:8957:9108:10004:10226:10848:11658:11914:12043:12291:12295:12438:12683:12895:13095:13144:13161:13229:13230:13439:13548:13972:14093:14096:14110:14180:14721:14824:21060:21063:21080:21433:21451:21627:30012:30029:30030:30054:30070:30076:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: coat22_50be50a316b24 X-Filterd-Recvd-Size: 9425 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Mon, 18 Jun 2018 09:52:34 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9c0c098e0b9a46b8d6394f7fa5d6ce2c" Date: Mon, 18 Jun 2018 11:52:34 +0200 From: Peter van der Stok To: consultancy@vanderstok.org Cc: Hannes Tschofenig , "Kovatsch, Matthias" , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> Message-ID: <29a9636a3703e43947fce2f4cb900825@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.129.53] Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 09:52:51 -0000 --=_9c0c098e0b9a46b8d6394f7fa5d6ce2c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI Hannes, Matthias, After some additional discussions, I think it is best to write an extra section into the resource-directory draft. Please have a look at my suggestion below. @Hannes, can you comment on the correctness and sufficiency of the text? thanks, Peter ________________________________________________________ Ietf-core-resource-directory text proposal. Suggestion to add a new section x on Authorization. Section x, use of Authorization Server. When threats may occur as described in section 8.1, an Authorization Server (AS) as specified in ietf-ace-oauth-authz SHOULD be used. A request to the Resource Directory is accompanied by an Access Token that validates the access of the client to the RD. The URI of an authorized request cannot contain the ep= or the d= parameters. When these parameters are present, the request is rejected with CoAP response code 4.00 (bad request). The identifier part of the security context in the Access Token is used to assign a value to the endpoint name of the endpoint to be registered. Three possibilities are supported: * For PSK-based credential, the Endpoint Name becomes the PSK Identity * For raw-public keys, the Endpoint Name becomes the SubjectPublicKeyInfo structure (or a hash of it). * For certificates, the Endpoint Name becomes the leftmost CN component of subject name or the SubjectAltName of the certificate, depending on what is used. An access token MAY include one of the two following new claims: "epn" endpoint name with value the identifier part of one of the 3 possible identifier parts of the security ccontext. "dnm" domain name with value "name of the domain" Three scenarios for registration in the RD MUS be supported. Section x.1 endpoint registers with RD The endpoints sends a Request to the RD accompanied by a CBOR Web Token (CWT). The identifier part of the security context is used to assign the endpoint name. Section x.2 3rd party Commissioning Tool (CT) registers endpoint with RD. The CT sends a Request to the RD accompanied by a CBOR Web Token (CWT). The identifier part of the CWT refers to the security context of the CT. The CWT validates the registration by the CT. The CWT MUST contain the "epn" claim to assign a value to the endpoint that is registered. The CWT MAY contain the "dnm" claim to assign a domain name. Section x.3 Updating multiple links Section 5.4.4 of RD specifies that multiple links can be updated with a media format to be specified. The updating endpoint sends a Request to the RD accompanied by a CBOR Web Token (CWT). The identifier part of the CWT refers to the security context of the updating endpoint. The updating endpoint is authorized to change all links of all existing registrations but MUST NOT delete or add registrations. IANA regsitration. Two new parameters need to be registered in the OAuth Parameter Registration with names ""epn" and "dnm". The last paragraph in section 8.1 is to be replaced: OLD "Therefore, Endpoints MUST include the Endpoint identifier in the message, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message." NEW "Therefore, Endpoints SHOULD follow the guidelines of section x." --=_9c0c098e0b9a46b8d6394f7fa5d6ce2c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Hannes, Matthias,

After some additional discussions, I think = it is best to write an extra section into the resource-directory draft.
Please have a look at my suggestion below.

@Hannes, can you co= mment on the correctness and sufficiency of the text? thanks,

Pe= ter

________________________________________________________

Ietf-core-resource-directory text proposal.

Suggestion to add a new section x on Authorization.

Section x, use of Authorization Server.

When threats may occur as described in section 8.1, an Authorization Ser= ver (AS) as specified in ietf-ace-oauth-authz SHOULD be used. A request to = the Resource Directory is accompanied by an Access Token that validates the= access of the client to the RD. The URI of an authorized request cannot co= ntain the ep=3D or the d=3D parameters. When these parameters are present, = the request is rejected with CoAP response code 4.00 (bad request). The ide= ntifier part of the security context in the Access Token is used to assign = a value to the endpoint name of the endpoint to be registered. Three possib= ilities are supported:

  1. For PSK-based credential, the Endpoint Name becomes the PSK Identity
  2. For raw-public keys, the Endpoint Name becomes=  the SubjectPublicKeyInfo structure (or a hash&nbs= p;of it).
  3. For certificates, the Endpoint Name becomes th= e leftmost CN component of subject name or&nb= sp;the SubjectAltName of the certificate, depending&nbs= p;on what is used.

An access token MAY include one of the two following new claims:

“epn” endpoint name with value the identifier part of one of= the 3 possible identifier parts of the security ccontext.

“dnm” domain name with value “name of the domain&rdquo= ;

Three scenarios for registration in the RD MUS be supported.

Section x.1 endpoint registers with RD

The endpoints sends a Request to the RD accompanied by a CBOR Web Token = (CWT). The identifier part of the security context is used to assign the en= dpoint name.

Section x.2 3rd party Commissioning Tool (CT) registers endpo= int with RD.

The CT sends a Request to the RD accompanied by a CBOR Web Token (= CWT). The identifier part of the CWT refers to the security con= text of the CT. The CWT validates the registration by the CT. The CWT MUST = contain the “epn” claim to assign a value to the endpoint that = is registered. The CWT MAY contain the “dnm” claim to assign a = domain name.

Section x.3 Updating multiple links

Section 5.4.4 of RD specifies that multiple links can be updated with a = media format to be specified. The updating endpoint sends a Request t= o the RD accompanied by a CBOR Web Token (CWT). The ident= ifier part of the CWT refers to the security context of the upda= ting endpoint. The updating endpoint is authorized to ch= ange all links of all existing registrations but MUST NOT delete or add reg= istrations.

IANA regsitration.

Two new parameters need to be registered i= n the OAuth Parameter Registration with names ""epn" and "dnm".

The last paragraph in sectio= n 8.1 is to be replaced:
OLD
"Therefore, Endpoints MUST include theEndpoint identifier in&n= bsp;the message, and this identifier
MUST be checked by a&nbs= p;resource directory to match the Endpoint id= entifier
included in&= nbsp;the Registration message."
NEW
"Therefore, = Endpoints SHOULD follow the guidelines of section x."


--=_9c0c098e0b9a46b8d6394f7fa5d6ce2c-- From nobody Mon Jun 18 05:10:03 2018 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 4B4F8130EB5 for ; Mon, 18 Jun 2018 05:10: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] 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 G1tNgOsdck1Q for ; Mon, 18 Jun 2018 05:09:58 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7F4130EA6 for ; Mon, 18 Jun 2018 05:09:57 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E5DB840033; Mon, 18 Jun 2018 14:09:53 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C3EDAD7; Mon, 18 Jun 2018 14:09:52 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:35b0:fe70:438d:948e]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6EF8610E; Mon, 18 Jun 2018 14:09:52 +0200 (CEST) Received: (nullmailer pid 17188 invoked by uid 1000); Mon, 18 Jun 2018 12:09:51 -0000 Date: Mon, 18 Jun 2018 14:09:50 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jaime =?iso-8859-1?Q?Jim=E9nez?= Cc: core Message-ID: <20180618120948.GA16994@hephaistos.amsuess.com> References: <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 12:10:02 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2018 at 05:02:19AM +0000, Jaime Jim=E9nez wrote: > based on the ongoing discussion on the Multipart Content-Format for > CoAP and the dependency with ACE, we will issue a 2 week Working group > Adoption call for this draft. Sounds like a good idea to me. I would have expected such a media type to be evolved out of SenML or CoRAL (like "two fat self links"), but having a way to do express the simple case with a simple data structure and a timely standardization is probably the better way indeed. Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlsnoQYACgkQOY0REtOk veFk3w//XHVb5DSJ15/HznNUS/AO6EBwGlrsD8FRF1YHi8SkKHCaudWeHK5f31gS Ysd0dpEbWU5RgBHOrevzsyUEiFPf92DXc5PKB2wtAYyRnw0rpt2EJMn9oTB8M7GH oeig6D4n7VHwm/Z+Vwgel1Lfbl0rc4vWB9PkgGbWF8MgZGgEX8WfF315poA0L4Qx 4sjHrIb47beT6IK3Z0FSFQuFAs9WqQ4mtYBnvH5Vx1+rQH0LSw1QMK7MGNvedWdE sNOopd5OPjZcpwTH4C109KZxlCtxpVu/kRtQGLm43+H/cYYdrqGe0xaJgqV+LHig nrBupbJrQzGonM0iY6Xiv9NSub4pJOfFxin6Lz9/MCnnur2NeCQZWXc5KelG3CaK dPIY1syQiGVc/XLGm6irfJhhqOhDdL+2Gxpkrz7mAutmyWBPLvZn+RnUB+/duI4i lY47ts5ThiDQi8VRj+sqhxlpRC3nde2b6zpZlLBFVoapmG52cxqUSjg/c5VghU+j zntRaOsNbZxxlXIrBXg+xsZ7a4aDeILu/85/CxZhQkUfYplLWQQ24Wptrm9MroDh trNI11tAh1lbNO+ocYr9Myq7puCJo7TAmtB+qck+gSuE1Q9QGpxd/aJZ9qJ91Wcy cKVw4CxTQE9YkW2h4X9DlSC8ttpIJ/HXbUZjLWl3TcVdBiwqnGM= =w/fJ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From nobody Mon Jun 18 05:28:26 2018 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 51B57130F04 for ; Mon, 18 Jun 2018 05:28: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 eMboZ_sgeFyy for ; Mon, 18 Jun 2018 05:28:15 -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 84782130F27 for ; Mon, 18 Jun 2018 05:28:14 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 18 Jun 2018 05:25:10 -0700 From: Jim Schaad To: CC: 'Hannes Tschofenig' , References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> <29a9636a3703e43947fce2f4cb900825@bbhmail.nl> In-Reply-To: <29a9636a3703e43947fce2f4cb900825@bbhmail.nl> Date: Mon, 18 Jun 2018 05:28:06 -0700 Message-ID: <00d001d406ff$d1392f80$73ab8e80$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D406C5.24DB41E0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLSQRyK31kKN7geubfCKDOvczH9iQKw5U1yAihxEq4C310y0gFDLGVkAV7n08KiFqXZAA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 12:28:25 -0000 ------=_NextPart_000_00D1_01D406C5.24DB41E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A couple of fast comments below =20 Jim =20 =20 From: core On Behalf Of Peter van der Stok Sent: Monday, June 18, 2018 2:53 AM To: consultancy@vanderstok.org Cc: Hannes Tschofenig ; core@ietf.org Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name = in RD draft =20 HI Hannes, Matthias, After some additional discussions, I think it is best to write an extra = section into the resource-directory draft. Please have a look at my suggestion below. @Hannes, can you comment on the correctness and sufficiency of the text? = thanks, Peter ________________________________________________________ Ietf-core-resource-directory text proposal. Suggestion to add a new section x on Authorization. Section x, use of Authorization Server. When threats may occur as described in section 8.1, an Authorization = Server (AS) as specified in ietf-ace-oauth-authz SHOULD be used. A = request to the Resource Directory is accompanied=20 [JLS] s/as specified/like the one specified/ by an Access Token that validates the access of the client to the RD. = The URI of an authorized request cannot contain the ep=3D or the d=3D = parameters. When these parameters are present, the request is rejected = with CoAP response code 4.00 (bad request). The identifier part of the = security context in the Access Token is used to assign a value to the = endpoint name of the endpoint to be registered. Three possibilities are = supported: 1. For PSK-based credential, the Endpoint Name becomes the PSK Identity [JLS] PSK identities are binary and not text strings so a mapping is = going to be needed here as with RPKs. 2. For raw-public keys, the Endpoint Name becomes the = SubjectPublicKeyInfo structure (or a hash of it). 3. For certificates, the Endpoint Name becomes the leftmost CN component = of subject name or the SubjectAltName of the certificate, depending on = what is used. An access token MAY include one of the two following new claims: =E2=80=9Cepn=E2=80=9D endpoint name with value the identifier part of = one of the 3 possible identifier parts of the security ccontext. [JLS] Why not use the =E2=80=98normal=E2=80=99 subject name? Would you = think that they are the same or different? =E2=80=9Cdnm=E2=80=9D domain name with value =E2=80=9Cname of the = domain=E2=80=9D Three scenarios for registration in the RD MUS be supported. Section x.1 endpoint registers with RD The endpoints sends a Request to the RD accompanied by a CBOR Web Token = (CWT). The identifier part of the security context is used to assign the = endpoint name. Section x.2 3rd party Commissioning Tool (CT) registers endpoint with = RD. The CT sends a Request to the RD accompanied by a CBOR Web Token (CWT). = The identifier part of the CWT refers to the security context of the CT. = The CWT validates the registration by the CT. The CWT MUST contain the = =E2=80=9Cepn=E2=80=9D claim to assign a value to the endpoint that is = registered. The CWT MAY contain the =E2=80=9Cdnm=E2=80=9D claim to = assign a domain name. Section x.3 Updating multiple links Section 5.4.4 of RD specifies that multiple links can be updated with a = media format to be specified. The updating endpoint sends a Request to = the RD accompanied by a CBOR Web Token (CWT). The identifier part of the = CWT refers to the security context of the updating endpoint. The = updating endpoint is authorized to change all links of all existing = registrations but MUST NOT delete or add registrations. IANA regsitration. Two new parameters need to be registered in the OAuth Parameter = Registration with names ""epn" and "dnm". The last paragraph in section 8.1 is to be replaced: OLD "Therefore, Endpoints MUST include the Endpoint identifier in the message, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message." NEW "Therefore, Endpoints SHOULD follow the guidelines of section x."=20 =20 ------=_NextPart_000_00D1_01D406C5.24DB41E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

A couple of fast comments below

 

Jim

 

 

From: core = <core-bounces@ietf.org> On Behalf Of Peter van der = Stok
Sent: Monday, June 18, 2018 2:53 AM
To: = consultancy@vanderstok.org
Cc: Hannes Tschofenig = <Hannes.Tschofenig@arm.com>; core@ietf.org
Subject: Re: = [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD = draft

 

HI Hannes, = Matthias,

After some additional discussions, I think it is best = to write an extra section into the resource-directory draft.
Please = have a look at my suggestion below.

@Hannes, can you comment on = the correctness and sufficiency of the text? = thanks,

Peter

_____________________________________________= ___________

Ietf-core-res= ource-directory text proposal.

Suggestion = to add a new section x on Authorization.

Section x, = use of Authorization Server.

When threats = may occur as described in section 8.1, an Authorization Server (AS) as = specified in ietf-ace-oauth-authz SHOULD be used. A request to the = Resource Directory is accompanied

[JLS] s/as = specified/like the one specified/

by an Access = Token that validates the access of the client to the RD. The URI of an = authorized request cannot contain the ep=3D or the d=3D parameters. When = these parameters are present, the request is rejected with CoAP response = code 4.00 (bad request). The identifier part of the security context in = the Access Token is used to assign a value to the endpoint name of the = endpoint to be registered. Three possibilities are = supported:

  1. For = PSK-based credential, the Endpoint Name becomes the PSK = Identity

[JLS] PSK = identities are binary and not text strings so a mapping is going to be = needed here as with RPKs.

  1. For raw-= public keys, the Endpoint Name becomes the = SubjectPublicKeyInfo structure (or a hash of&nbs= p;it).
  2. For cert= ificates, = the Endpoint Name becomes the leftmost CN = component of subject name or the SubjectAlt= Name of the certificate, depending on what is = used.

An access = token MAY include one of the two following new = claims:

=E2=80=9Cepn=E2= =80=9D endpoint name with value the identifier part of one of the 3 = possible identifier parts of the security = ccontext.

[JLS] Why not use the = =E2=80=98normal=E2=80=99 subject name? Would you think that they are the = same or different?

=E2=80=9Cdnm=E2= =80=9D domain name with value =E2=80=9Cname of the = domain=E2=80=9D

Three = scenarios for registration in the RD MUS be = supported.

Section x.1 = endpoint registers with RD

The = endpoints sends a Request to the RD accompanied by a CBOR Web Token = (CWT). The identifier part of the security context is used to assign the = endpoint name.

Section x.2 = 3rd party Commissioning Tool (CT) registers endpoint with = RD.

The CT sends = a Request to the RD accompanied by a CBOR Web Token (CWT). The = identifier part of the CWT refers to the security context of the CT. The = CWT validates the registration by the CT. The CWT MUST contain the = =E2=80=9Cepn=E2=80=9D claim to assign a value to the endpoint that is = registered. The CWT MAY contain the =E2=80=9Cdnm=E2=80=9D claim to = assign a domain name.

Section x.3 = Updating multiple links

Section = 5.4.4 of RD specifies that multiple links can be updated with a media = format to be specified. The updating endpoint sends a Request to the RD = accompanied by a CBOR Web Token (CWT). The identifier part of the = CWT refers to the security context of the updating = endpoint. The updating endpoint is authorized to change all links = of all existing registrations but MUST NOT delete or add = registrations.

IANA = regsitration.

Two new parameters need to be registered in the = OAuth Parameter Registration with names ""epn" and = "dnm".

The last=  paragraph in section 8.1 is to be = replaced:
OLD
"Therefore, Endpoints MUST includ= e the
Endpoint identifier in the message,&nbs= p;and this identifier
MUST be checked by = ;a resource directory to match the Endpoint=  identifier
included in the Registration mess= age."
NEW
"Therefore, Endpoints SHOULD follow the = guidelines of section x."

 

------=_NextPart_000_00D1_01D406C5.24DB41E0-- From nobody Mon Jun 18 05:28:32 2018 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 4C075130F1F for ; Mon, 18 Jun 2018 05:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 swwQGJpZ2MXy for ; Mon, 18 Jun 2018 05:28:20 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.41]) (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 6FFF8130F40 for ; Mon, 18 Jun 2018 05:28:19 -0700 (PDT) Received: from 1fUtGb-000AJT-T6 by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fUtGb-000AKc-UG; Mon, 18 Jun 2018 05:28:17 -0700 Received: by emcmailer; Mon, 18 Jun 2018 05:28:17 -0700 Received: from [194.218.146.197] (helo=sp-mail-3.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fUtGb-000AJT-T6; Mon, 18 Jun 2018 05:28:17 -0700 Received: from sp-mail-1.sp.se (10.100.0.161) by sp-mail-3.sp.se (10.100.0.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 18 Jun 2018 14:28:16 +0200 Received: from sp-mail-1.sp.se ([fe80::7d78:8db6:13df:8cc7]) by sp-mail-1.sp.se ([fe80::7d78:8db6:13df:8cc7%21]) with mapi id 15.01.1466.008; Mon, 18 Jun 2018 14:28:16 +0200 From: Shahid Raza To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dBIG11bHRpcGFydC9jb3Jl?= Thread-Index: AQHUAUF2AbcJtAYKEUWtSWB+zhL2DqRl1nkAgAAFJYA= Date: Mon, 18 Jun 2018 12:28:16 +0000 Message-ID: <2DA52BAE-7F22-4CDC-A6C3-9857A34DB99B@ri.se> References: <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> <20180618120948.GA16994@hephaistos.amsuess.com> In-Reply-To: <20180618120948.GA16994@hephaistos.amsuess.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) x-originating-ip: [10.100.0.68] Content-Type: text/plain; charset="utf-8" Content-ID: <547C670CA77B1D4281153EE1D5B1189E@sp.se> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-IP: 194.218.146.197 X-Env-From: shahid.raza@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-3.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 12:28:25 -0000 DQorMQ0KDQpBcyBhIGNvLWF1dGhvciBvZiB0aGUgRVNULUNvQVBzIGRyYWZ0LCBJIHN1cHBvcnQg dGhpcyBhcyBpdCBpcyBuZWVkZWQgdG8gZmluYWxpc2Ugb3VyIGRyYWZ0LiANCldlIHdpbGwgaW1w bGVtZW50IHRoaXMsIGFzIGEgcGFydCBvZiBFU1QtQ29BUHMsIGFzIHNvb24gYXMgaXQgYmVjb21l cyBvZmZpY2lhbC4gDQoNCkJlc3QsDQpTaGFoaWQNCg0KDQo+IE9uIDE4IEp1biAyMDE4LCBhdCAx NDowOSwgQ2hyaXN0aWFuIEFtc8O8c3MgPGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4gd3JvdGU6DQo+ IA0KPiBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCAwNTowMjoxOUFNICswMDAwLCBKYWltZSBKaW3D qW5leiB3cm90ZToNCj4+IGJhc2VkIG9uIHRoZSBvbmdvaW5nIGRpc2N1c3Npb24gb24gdGhlIE11 bHRpcGFydCBDb250ZW50LUZvcm1hdCBmb3INCj4+IENvQVAgYW5kIHRoZSBkZXBlbmRlbmN5IHdp dGggQUNFLCB3ZSB3aWxsIGlzc3VlIGEgMiB3ZWVrIFdvcmtpbmcgZ3JvdXANCj4+IEFkb3B0aW9u IGNhbGwgZm9yIHRoaXMgZHJhZnQuDQo+IA0KPiBTb3VuZHMgbGlrZSBhIGdvb2QgaWRlYSB0byBt ZS4NCj4gDQo+IEkgd291bGQgaGF2ZSBleHBlY3RlZCBzdWNoIGEgbWVkaWEgdHlwZSB0byBiZSBl dm9sdmVkIG91dCBvZiBTZW5NTCBvcg0KPiBDb1JBTCAobGlrZSAidHdvIGZhdCBzZWxmIGxpbmtz IiksIGJ1dCBoYXZpbmcgYSB3YXkgdG8gZG8gZXhwcmVzcyB0aGUNCj4gc2ltcGxlIGNhc2Ugd2l0 aCBhIHNpbXBsZSBkYXRhIHN0cnVjdHVyZSBhbmQgYSB0aW1lbHkgc3RhbmRhcmRpemF0aW9uIGlz DQo+IHByb2JhYmx5IHRoZSBiZXR0ZXIgd2F5IGluZGVlZC4NCj4gDQo+IENocmlzdGlhbg0KPiAN Cj4gLS0gDQo+IFRvIHVzZSByYXcgcG93ZXIgaXMgdG8gbWFrZSB5b3Vyc2VsZiBpbmZpbml0ZWx5 IHZ1bG5lcmFibGUgdG8gZ3JlYXRlciBwb3dlcnMuDQo+ICAtLSBCZW5lIEdlc3Nlcml0IGF4aW9t DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNv cmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Tue Jun 19 02:40:24 2018 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 EB8751310DB; Tue, 19 Jun 2018 02:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 AG9lH4dXupFb; Tue, 19 Jun 2018 02:40:19 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0072.outbound.protection.outlook.com [104.47.1.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282BD1310CA; Tue, 19 Jun 2018 02:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3sDlZYXaKT95tL5lrv0nT4IBMYS6P5W8AlZwZjhRSA4=; b=pXvQNZc6b9rsU84ZUaesvcj2G9GwwcpKfd+FIDDxfG78gQrlTS3lMBy7wdGlXbgvNq7AH9LZbmNtj9dkLAjsaMOGN9qaldPSoGAagVGid4Yhc89UNEIaVJEXA5kdGXGs57DQFB4RiO2DJJOoWhGZE2Z8ZT91k5kEZZiG8bgk9lU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1679.eurprd08.prod.outlook.com (10.168.66.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 09:40:16 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 09:40:16 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" , Carsten Bormann CC: core , "ace@ietf.org" Thread-Topic: [core] [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gAB1S+AAAdDwHAALHlyAAAAGtIAAZoVoYAAAOWDAAAAmhQABRCXITA= Date: Tue, 19 Jun 2018 09:40:16 +0000 Message-ID: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@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=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1679; 7:cXHernTLZT2ibvSBHGoaxDGh95O6Pa2Rah1l598s/Oj7OwxNY0fik2u33DTpNqDUjIDEHF92g9cIOtUHqEE8WrRikf6Ab7Zgt0HBlUhXDGGtiolqfdv6B5tMjGcurEynHYU7AN1VryrO2qaXmXja/N9Rz83clnHef1WCjXlS3dKpHv9+puvHlRBhD6/WtmxExxDa1ogyY8mYWXrTeduV0DledVXSuU5J2dTdIV1TEiZciyPfGd6pAAiaMK1KkDb6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e309dd92-d94c-49c2-8012-08d5d5c8a9e4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1679; x-ms-traffictypediagnostic: VI1PR0801MB1679: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1679; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1679; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(366004)(39380400002)(40434004)(13464003)(53754006)(57704003)(189003)(199004)(86362001)(4326008)(229853002)(68736007)(5660300001)(6116002)(3846002)(186003)(25786009)(102836004)(33656002)(26005)(8676002)(2900100001)(6246003)(106356001)(6436002)(53936002)(81166006)(8936002)(81156014)(105586002)(446003)(3280700002)(2906002)(3660700001)(476003)(7736002)(66066001)(9686003)(2501003)(6306002)(11346002)(486006)(74316002)(316002)(14454004)(5250100002)(5890100001)(305945005)(561944003)(97736004)(54906003)(110136005)(55016002)(99286004)(7696005)(53546011)(966005)(478600001)(93886005)(72206003)(59450400001)(76176011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1679; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9dE1k/aPcBmlTSoKBvP7urijZ+qzN3zePoqOBPNiU8PhMAT40yWM2/ckz8XtXXTOsLr/ZdfWDdnE/xcvZ1SJCBy0U0e8nUeWBeJNFDgswte0HoF75JZ6vCtptucIt2vUZhvtN+6pjLDOHIlK8J79hJ9Xc0a1vrN2HRO9/9mMnyPg8ncfdtsQDil1jQN6O6ryMoFlInbXVAMr1KlRdbSEXIVnDQxME4sYXQSItLLKDAutmIOgdrQVAhkm20e6zIMPWJckNVw88iD3T/IH/FLInfE+OvjUKRnsIsDElTHA1xi2MB7WR4zTR0QX0GOO7eJMwd/lJOPiutOICKuXMa0jIQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e309dd92-d94c-49c2-8012-08d5d5c8a9e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 09:40:16.1811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1679 Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 09:40:24 -0000 UGV0ZXIsDQoNCkRpZCB0aGlzIHJlZ2lzdHJhdGlvbiBhdHRlbXB0IGdvdCBjb25jbHVkZWQ/DQoN CkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGV0ZXIg dmFuIGRlciBTdG9rIFttYWlsdG86c3Rva2NvbnNAeHM0YWxsLm5sXQ0KU2VudDogMjQgTWF5IDIw MTggMTU6NTUNClRvOiBDYXJzdGVuIEJvcm1hbm4NCkNjOiBIYW5uZXMgVHNjaG9mZW5pZzsgY29y ZTsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFtBY2VdIEVhcmx5IG1lZGlhLXR5 cGUgcmVnaXN0cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQDQoNCk9rLCBJIHdpbGwgcmFpc2UgdGhl IGV4cGVydHMgdG8tbW9ycm93Lg0KDQpQZXRlcg0KDQpDYXJzdGVuIEJvcm1hbm4gc2NocmVlZiBv cCAyMDE4LTA1LTI0IDE2OjM3Og0KPiBPbiBNYXkgMjQsIDIwMTgsIGF0IDE2OjE1LCBIYW5uZXMg VHNjaG9mZW5pZw0KPiA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQo+Pg0KPj4g SGkgYWxsLA0KPj4NCj4+IFRyeWluZyB0byBmaW5hbGl6ZSB0aGlzIGRpc2N1c3Npb246IENvdWxk IHdlIGRvIGFuIGVhcmx5IHJlZ2lzdHJ5IG9mDQo+PiB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVy cz8NCj4NCj4gWWVzLg0KPg0KPj4gRnJvbSB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIgSSBiZWxpZXZl IHdlIGNvbmNsdWRlZCB0aGF0IHRoZSBjaGFyc2V0IGlzDQo+PiB1dGYtOA0KPg0KPiBXaGF0IGNo YXJzZXQ/ICBJIHRob3VnaHQgd2UgZG9u4oCZdCBoYXZlIHBhcmFtZXRlcnMgKHNlZSBiZWxvdyku DQo+DQo+PiBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gcGFyYW1ldGVycy4gSXMgdGhhdCBjb3JyZWN0 Pw0KPg0KPiBUaGF0IGlzIG15IHVuZGVyc3RhbmRpbmcgc28gZmFyLCBidXQgdGhlIHBvaW50IG9m IG1lIGFza2luZyB0aGUNCj4gcXVlc3Rpb24gd2FzIHRvIGFzayB0aGUgYWN0dWFsIGV4cGVydHMg YWJvdXQgdGhlc2UgbWVkaWEgdHlwZXMuICBEaWQNCj4gd2UgZ2V0IHRoYXQgaW5wdXQ/DQo+DQo+ IE5leHQgc3RlcDogbWFrZSBhIHByb3Bvc2FsIGFuZCByYWlzZSB0aGlzIG9uIGNvcmUtcGFyYW1l dGVyc0BpZXRmLm9yZw0KPiBzbyB3ZSBnZXQgdGhlIG5lZWRlZCBpbnB1dCBmcm9tIHRoZSBkZXNp Z25hdGVkIGV4cGVydC4NCj4NCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPg0KPg0KPj4NCj4+IENpYW8N Cj4+IEhhbm5lcw0KPj4NCj4+IEZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHpp Lm9yZ10NCj4+IFNlbnQ6IDE2IE1heSAyMDE4IDEyOjMwDQo+PiBUbzogSGFubmVzIFRzY2hvZmVu aWcNCj4+IENjOiBhY2VAaWV0Zi5vcmc7IGNvcmUNCj4+IFN1YmplY3Q6IFJlOiBbQWNlXSBFYXJs eSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiBmb3IgRVNUIG92ZXIgQ29BUA0KPj4NCj4+IEZvcmdv dCB0byBhZGQgYW5vdGhlciBleGFtcGxlOiB0aGUgY29udGVudC1mb3JtYXQgbnVtYmVycyBmb3Ig Q09TRQ0KPj4gaGF2ZSBwYXJhbWV0ZXJzLg0KPj4NCj4+IFNlbnQgZnJvbSBtb2JpbGUNCj4+DQo+ PiBPbiAxNi4gTWF5IDIwMTgsIGF0IDEyOjI2LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9y Zz4gd3JvdGU6DQo+Pg0KPj4gSSB3YXMgdGhpbmtpbmcgYWJvdXQgbWVkaWEgdHlwZSBwYXJhbWV0 ZXJzIHN1Y2ggYXMgY2hhcnNldD0idXRmLTgiLg0KPj4gVGhlIFJUIHZhbHVlIG5lZWQgdG8gYmUg cmVnaXN0ZXJlZCBzZXBhcmF0ZWx5LCBidXQgd2UgY2FuIGJlIGEgYml0DQo+PiBsYXp5IGFib3V0 IHRoYXQuDQo+Pg0KPj4gU2VudCBmcm9tIG1vYmlsZQ0KPj4NCj4+IE9uIDE2LiBNYXkgMjAxOCwg YXQgMTI6MTUsIEhhbm5lcyBUc2Nob2ZlbmlnDQo+PiA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT4gd3JvdGU6DQo+Pg0KPj4gSGkgQ2Fyc3RlbiwNCj4+DQo+PiBZZXMsIEkgYW0gdGFsa2luZyBh Ym91dCB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVycyBmb3IgdGhlbS4NCj4+IFdvdWxkIHJ0PSJh Y2UuZXN0IiBiZSB0aGUgcGFyYW1ldGVyIHlvdSBhcmUgdGFsa2luZyBhYm91dD8NCj4+DQo+PiBD aWFvDQo+PiBIYW5uZXMNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0KPj4gU2VudDogMTUgTWF5 IDIwMTggMTE6NDUNCj4+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4gQ2M6IGFjZUBpZXRmLm9y ZzsgY29yZQ0KPj4gU3ViamVjdDogUmU6IFtBY2VdIEVhcmx5IG1lZGlhLXR5cGUgcmVnaXN0cmF0 aW9uIGZvciBFU1Qgb3ZlciBDb0FQDQo+Pg0KPj4gT24gTWF5IDE1LCAyMDE4LCBhdCAxMDo1Niwg SGFubmVzIFRzY2hvZmVuaWcNCj4+IDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToN Cj4+DQo+Pg0KPj4gSSBhbSBjdXJpb3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8g YXNrIGZvciBlYXJseSBtZWRpYS10eXBlDQo+PiByZWdpc3RyYXRpb24gb2YgYXQgbGVhc3QgdGhl c2UgdHdvIHR5cGVzOg0KPj4gLSBhcHBsaWNhdGlvbi9wa2NzNy1taW1lDQo+PiAtIGFwcGxpY2F0 aW9uL3BrY3MxMA0KPj4NCj4+IFRoZXJlIGFscmVhZHkgYXJlIHJlZ2lzdGVyZWQuDQo+Pg0KPj4g SSB0aGluayB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgZ2V0dGluZyBDb250ZW50LUZvcm1hdCBudW1i ZXJzIGZvcg0KPj4gdGhlc2U/DQo+PiBEbyB3ZSBuZWVkIGFueSBwYXJhbWV0ZXJzIG9yIGNvbnRl bnQtY29kaW5ncyB3aXRoIHRoYXQ/DQo+Pg0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4NCj4+IElN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlDQo+PiBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZQ0KPj4gdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9y DQo+PiBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+Pg0K Pj4NCj4+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlDQo+PiBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZQ0KPj4gdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yDQo+PiBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gQWNlIG1haWxpbmcgbGlzdA0KPj4gQWNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Jun 19 05:11:38 2018 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 9F278130E75; Tue, 19 Jun 2018 05:11:36 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwMDp8FdgC_W; Tue, 19 Jun 2018 05:11:33 -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 DF8F8130E6A; Tue, 19 Jun 2018 05:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5JCBREe024611; Tue, 19 Jun 2018 14:11:27 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 4196JH0tt1zDWnx; Tue, 19 Jun 2018 14:11:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 19 Jun 2018 14:11:26 +0200 Cc: peter van der Stok , core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 551103084.705636-fe66a2a218adc989b79b0fcc7348be9d Content-Transfer-Encoding: quoted-printable Message-Id: <7198364E-F831-423F-8709-D96E152FD888@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 12:11:37 -0000 Since the registry that we are registering into does not fulfill the = preconditions of RFC 7120 Section 2 point (a), I think the next step is = to send the registration to IANA using the protocol parameters form [1]. = The application should reference the I-D as well as the message from = the DE [2] =E2=80=94 there will be another interaction between IANA and = DE and then we should be done. To do so without further friction, the = I-D probably should have been updated to align with [2]. [1]: https://www.iana.org/form/protocol-assignment [2]: = https://www.ietf.org/mail-archive/web/core-parameters/current/msg00024.htm= l Gr=C3=BC=C3=9Fe, Carsten > On Jun 19, 2018, at 11:40, Hannes Tschofenig = wrote: >=20 > Peter, >=20 > Did this registration attempt got concluded? >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 24 May 2018 15:55 > To: Carsten Bormann > Cc: Hannes Tschofenig; core; ace@ietf.org > Subject: Re: [core] [Ace] Early media-type registration for EST over = CoAP >=20 > Ok, I will raise the experts to-morrow. >=20 > Peter >=20 > Carsten Bormann schreef op 2018-05-24 16:37: >> On May 24, 2018, at 16:15, Hannes Tschofenig >> wrote: >>>=20 >>> Hi all, >>>=20 >>> Trying to finalize this discussion: Could we do an early registry of >>> the Content-Format numbers? >>=20 >> Yes. >>=20 >>> =46rom the discussion so far I believe we concluded that the charset = is >>> utf-8 >>=20 >> What charset? I thought we don=E2=80=99t have parameters (see = below). >>=20 >>> and that there are no parameters. Is that correct? >>=20 >> That is my understanding so far, but the point of me asking the >> question was to ask the actual experts about these media types. Did >> we get that input? >>=20 >> Next step: make a proposal and raise this on core-parameters@ietf.org >> so we get the needed input from the designated expert. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: 16 May 2018 12:30 >>> To: Hannes Tschofenig >>> Cc: ace@ietf.org; core >>> Subject: Re: [Ace] Early media-type registration for EST over CoAP >>>=20 >>> Forgot to add another example: the content-format numbers for COSE >>> have parameters. >>>=20 >>> Sent from mobile >>>=20 >>> On 16. May 2018, at 12:26, Carsten Bormann wrote: >>>=20 >>> I was thinking about media type parameters such as charset=3D"utf-8". >>> The RT value need to be registered separately, but we can be a bit >>> lazy about that. >>>=20 >>> Sent from mobile >>>=20 >>> On 16. May 2018, at 12:15, Hannes Tschofenig >>> wrote: >>>=20 >>> Hi Carsten, >>>=20 >>> Yes, I am talking about the Content-Format numbers for them. >>> Would rt=3D"ace.est" be the parameter you are talking about? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: 15 May 2018 11:45 >>> To: Hannes Tschofenig >>> Cc: ace@ietf.org; core >>> Subject: Re: [Ace] Early media-type registration for EST over CoAP >>>=20 >>> On May 15, 2018, at 10:56, Hannes Tschofenig >>> wrote: >>>=20 >>>=20 >>> I am curious whether it would be possible to ask for early = media-type >>> registration of at least these two types: >>> - application/pkcs7-mime >>> - application/pkcs10 >>>=20 >>> There already are registered. >>>=20 >>> I think you are talking about getting Content-Format numbers for >>> these? >>> Do we need any parameters or content-codings with that? >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose >>> the contents to any other person, use it for any purpose, or store = or >>> copy the information in any medium. Thank you. >>>=20 >>>=20 >>> IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose >>> the contents to any other person, use it for any purpose, or store = or >>> copy the information in any medium. Thank you. >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jun 19 05:22:54 2018 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 75EBC130EA3; Tue, 19 Jun 2018 05:22:47 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-XqzmORSyZJ; Tue, 19 Jun 2018 05:22:46 -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 C2CF7130E95; Tue, 19 Jun 2018 05:22:45 -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 w5JCMfBQ002853; Tue, 19 Jun 2018 14:22:41 +0200 (CEST) Received: from client-0101.vpn.uni-bremen.de (client-0101.vpn.uni-bremen.de [134.102.107.101]) (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 4196YF31dzzDWp6; Tue, 19 Jun 2018 14:22:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <7198364E-F831-423F-8709-D96E152FD888@tzi.org> Date: Tue, 19 Jun 2018 14:22:40 +0200 Cc: core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 551103759.141158-68dcec812618ae55160340b2631910a4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 12:22:48 -0000 On Jun 19, 2018, at 14:11, Carsten Bormann wrote: >=20 > Since the registry that we are registering into does not fulfill the = preconditions of RFC 7120 Section 2 point (a), (Sorry, wasn=E2=80=99t awake enough. If we go for the 256-9999 space, = of course it does. And we probably do.) So we=E2=80=99ll have to follow the process according to Section 3 of = RFC 7120. Starting with point (1) of Section 3.1: 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 19 07:36:34 2018 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 73EE2131183; Tue, 19 Jun 2018 07:36:21 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpBY3d14PzT1; Tue, 19 Jun 2018 07:36:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07293131172; Tue, 19 Jun 2018 07:36:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F8C220090; Tue, 19 Jun 2018 10:50:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4DCB11A69; Tue, 19 Jun 2018 10:33:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B38B1A68; Tue, 19 Jun 2018 10:33:15 -0400 (EDT) From: Michael Richardson To: core , "ace\@ietf.org" In-Reply-To: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 14:36:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: >> >> Since the registry that we are registering into does not fulfill the >> preconditions of RFC 7120 Section 2 point (a), > (Sorry, wasn=E2=80=99t awake enough. If we go for the 256-9999 space= , of > course it does. And we probably do.) yes, we were perfectly happy with that space. > So we=E2=80=99ll have to follow the process according to Section 3 of= RFC 7120. > Starting with point (1) of Section 3.1: > 1. The authors (editors) of the document submit a request for ear= ly > allocation to the Working Group chairs, specifying which code points > require early allocation and to which document they should be assigne= d. I thought ACE co-chairs already gave consent, but looking in the archives, I see that this isn't actually so. Jim? Roman? DO YOU CONSENT? We have already had some round trips and document changes thanks to Klaus H= artke. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWykUKICLcPvd0N1lAQLeOAgAr+zRrSZVWe2OCzACCr8wv6XjZYAsobZY PMBqtFsuILUN0UHVTQ78EakFvPsJAs41cidXoPJZSYiEgtz5nXi7zsljJnOGT27/ jDLVsMDF2Tkr5QSp4Ui8AeUFHX9dmoGMkbxCkiAoccptRZBlDZhKPfO/3+l94zQ/ +2cNz55t3aIDHYXcLhCBbuZIlgN18VQ53l19zc9nwvqzFUp23OzKZGr2UdN7/ZY0 Smtm0XdjTurqKId2EJqJI8AtYqUirUtMztsUhLrz2WJiWenZA24Xlcvn6VT1ca3f GdEzM/YqYIk5RcoIGbEqNmSUQI/4HQjh1fWL7cYjgtHXKexgV/MN+g== =CTJh -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 08:25:24 2018 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 D09931311A4; Tue, 19 Jun 2018 08:25:21 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksr5mknGhGVO; Tue, 19 Jun 2018 08:25: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 F42391311AF; Tue, 19 Jun 2018 08:25:16 -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 w5JFPDaA022867; Tue, 19 Jun 2018 17:25:13 +0200 (CEST) Received: from client-0114.vpn.uni-bremen.de (client-0114.vpn.uni-bremen.de [134.102.107.114]) (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 419Bbs329zzDWr0; Tue, 19 Jun 2018 17:25:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <26117.1529418795@localhost> Date: Tue, 19 Jun 2018 17:25:12 +0200 Cc: core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 551114711.31085-725aed01c4295c1d73f5acc98da3370b Content-Transfer-Encoding: quoted-printable Message-Id: <5300AE6B-7CA6-4D1E-BAA0-61C64233E1B0@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <26117.1529418795@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 15:25:23 -0000 On Jun 19, 2018, at 16:33, Michael Richardson = wrote: >=20 > We have already had some round trips and document changes thanks to = Klaus Hartke. Yes, but the IANA considerations section currently still has multict in = it =E2=80=94 that might confuse IANA. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 19 09:22:18 2018 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 381EA130F76; Tue, 19 Jun 2018 09:22:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV9UWN_stx3E; Tue, 19 Jun 2018 09:22:06 -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 6F7E9130DE1; Tue, 19 Jun 2018 09:22:06 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Jun 2018 09:19:01 -0700 From: Jim Schaad To: 'Michael Richardson' , 'core' , References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <26117.1529418795@localhost> In-Reply-To: <26117.1529418795@localhost> Date: Tue, 19 Jun 2018 09:21:59 -0700 Message-ID: <01b701d407e9$a78b5dd0$f6a21970$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG/S+RHVkCkQxegzhC32weTrUzzBwIfwDTTAqVFXzMBqqx8WgLhhBh7AciFkcwCU/daGAI1GHuCAgGCadECFFGudgHA077GAiyGetGj1AuXcA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 16:22:10 -0000 > -----Original Message----- > From: Ace On Behalf Of Michael Richardson > Sent: Tuesday, June 19, 2018 7:33 AM > To: core ; ace@ietf.org > Subject: Re: [Ace] [core] Early media-type registration for EST over = CoAP >=20 >=20 > Carsten Bormann wrote: > > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > >> > >> Since the registry that we are registering into does not = fulfill the > >> preconditions of RFC 7120 Section 2 point (a), >=20 > > (Sorry, wasn=E2=80=99t awake enough. If we go for the 256-9999 = space, of > > course it does. And we probably do.) >=20 > yes, we were perfectly happy with that space. >=20 > > So we=E2=80=99ll have to follow the process according to Section = 3 of RFC 7120. >=20 > > Starting with point (1) of Section 3.1: >=20 > > 1. The authors (editors) of the document submit a request = for early > > allocation to the Working Group chairs, specifying which code = points > > require early allocation and to which document they should be = assigned. >=20 > I thought ACE co-chairs already gave consent, but looking in the = archives, I > see that this isn't actually so. >=20 > Jim? Roman? DO YOU CONSENT? I do not believe that I have ever seen a formal request directed at me = for this. Jim >=20 > We have already had some round trips and document changes thanks to > Klaus Hartke. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jun 20 03:07:21 2018 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 9390F131067; Wed, 20 Jun 2018 03:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rYLTm449xqu4; Wed, 20 Jun 2018 03:07:12 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869EF130DD0; Wed, 20 Jun 2018 03:07:12 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 3A0A2182CF66C; Wed, 20 Jun 2018 10:07:11 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2559:2566:2570:2682:2685:2693:2703:2827:2859:2895:2909:2933:2937:2939:2942:2945:2947:2951:2954:3022:3148:3352:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4117:4250:4321:4860:5007:6117:6119:6261:7875:7903:8603:9010:9025:9177:10004:10346:10400:11658:12379:12740:13139:13158:13228:13237, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: bikes38_218d813895d54 X-Filterd-Recvd-Size: 6300 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Wed, 20 Jun 2018 10:07:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b97923618629a809caeae3594b16be85" Date: Wed, 20 Jun 2018 12:07:10 +0200 From: Peter van der Stok To: Carsten Bormann Cc: Hannes Tschofenig , core , ace@ietf.org, Jim Schaad , rdd@cert.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> Message-ID: <91797cd1747cf05db20d64662306e038@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.129.53] Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 10:07:15 -0000 --=_b97923618629a809caeae3594b16be85 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 HI Carsten, Jim Just to get this clear. We will update the the est-coaps draft by referring to draft-fossati-core-multipart-ct-05 [1] for the wanted early registration of the content formats specified in est-coaps. Once done, we direct a request for early registration of the content-format values to the ACE chairs. Although the corresponding media formats have not been allocated yet for multipart-ct draft, the corresponding content-format numbers can be allocated already. Is that the approved plan? Please confirm or specify the conditions on multipart-ct draft. Many thanks for your understanding, Peter Carsten Bormann schreef op 2018-06-19 14:22: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > >> Since the registry that we are registering into does not fulfill the preconditions of RFC 7120 Section 2 point (a), > > (Sorry, wasn't awake enough. If we go for the 256-9999 space, of course it does. And we probably do.) > > So we'll have to follow the process according to Section 3 of RFC 7120. > > Starting with point (1) of Section 3.1: > > 1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code > points require early allocation and to which document they should > be assigned. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Links: ------ [1] https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/ --=_b97923618629a809caeae3594b16be85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Carsten, Jim

Just to get this clear.

We will updat= e the the est-coaps draft by referring to draft-fossati-core-multip= art-ct-05 for the wanted early registration of the content fo= rmats specified in est-coaps.
Once done, we direct a request for early= registration of the content-format values to the ACE chairs.
Although= the corresponding media formats have not been allocated yet for multipart-= ct draft, the corresponding content-format numbers can be allocated already= =2E

Is that the approved plan?

Please confirm or spec= ify the conditions on multipart-ct draft.

Many thanks for your u= nderstanding,

Peter

Carsten Bormann schreef op 2018-06-19 14:22:

= On Jun 19, 2018, at 14:11, Carsten Bormann <cabo@tzi.org> wrote:

Since the registry that we are registering into= does not fulfill the preconditions of RFC 7120 Section 2 point (a),
(Sorry, wasn't awake enough.  If we go for the 256-9999 space, = of course it does.  And we probably do.)

So we'll have to = follow the process according to Section 3 of RFC 7120.

Starting= with point (1) of Section 3.1:

   1.  The = authors (editors) of the document submit a request for early
 &n= bsp;     allocation to the Working Group chairs, s= pecifying which code
       points= require early allocation and to which document they should
 &nb= sp;     be assigned.

Grüße,= Carsten

_______________________________________________
= core mailing list
= core@ietf.org
https://www.ietf.org/mailman/listin= fo/core
--=_b97923618629a809caeae3594b16be85-- From nobody Wed Jun 20 09:13:06 2018 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 04FC8130E19; Wed, 20 Jun 2018 09:13:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TIwqUn-pqi2K; Wed, 20 Jun 2018 09:13:02 -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 261A8126DBF; Wed, 20 Jun 2018 09:13:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Jun 2018 09:09:56 -0700 From: Jim Schaad To: , 'Carsten Bormann' CC: 'Hannes Tschofenig' , 'core' , , References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <91797cd1747cf05db20d64662306e038@bbhmail.nl> In-Reply-To: <91797cd1747cf05db20d64662306e038@bbhmail.nl> Date: Wed, 20 Jun 2018 09:12:52 -0700 Message-ID: <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01D40876.E07564A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG/S+RHVkCkQxegzhC32weTrUzzBwIfwDTTAqVFXzMBqqx8WgLhhBh7AciFkcwCU/daGAI1GHuCAgGCadECFFGudgHA077GAxkWxyKjzjbOUA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 16:13:05 -0000 ------=_NextPart_000_0018_01D40876.E07564A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That sounds like a good plan forward. Are you also going to need an = early registration on the multipart-core draft as well? =20 Jim =20 =20 From: Peter van der Stok =20 Sent: Wednesday, June 20, 2018 3:07 AM To: Carsten Bormann Cc: Hannes Tschofenig ; core ; = ace@ietf.org; Jim Schaad ; rdd@cert.org Subject: Re: [core] [Ace] Early media-type registration for EST over = CoAP =20 HI Carsten, Jim Just to get this clear. We will update the the est-coaps draft by referring to = draft-fossati-core-multipart-ct-05 = for = the wanted early registration of the content formats specified in = est-coaps. Once done, we direct a request for early registration of the = content-format values to the ACE chairs. Although the corresponding media formats have not been allocated yet for = multipart-ct draft, the corresponding content-format numbers can be = allocated already. Is that the approved plan? Please confirm or specify the conditions on multipart-ct draft. Many thanks for your understanding, Peter Carsten Bormann schreef op 2018-06-19 14:22: On Jun 19, 2018, at 14:11, Carsten Bormann > wrote:=20 Since the registry that we are registering into does not fulfill the = preconditions of RFC 7120 Section 2 point (a), (Sorry, wasn't awake enough. If we go for the 256-9999 space, of course = it does. And we probably do.) So we'll have to follow the process according to Section 3 of RFC 7120. Starting with point (1) of Section 3.1: 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0018_01D40876.E07564A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That = sounds like a good plan forward.=C2=A0 Are you also going to need an = early registration on the multipart-core draft as well?

 

Jim

 

 

From: Peter = van der Stok <stokcons@bbhmail.nl>
Sent: Wednesday, = June 20, 2018 3:07 AM
To: Carsten Bormann = <cabo@tzi.org>
Cc: Hannes Tschofenig = <Hannes.Tschofenig@arm.com>; core <core@ietf.org>; = ace@ietf.org; Jim Schaad <ietf@augustcellars.com>; = rdd@cert.org
Subject: Re: [core] [Ace] Early media-type = registration for EST over CoAP

 

HI Carsten, = Jim

Just to get this clear.

We will update the the = est-coaps draft by referring to draft-fossati-core-multipart-ct-05 for the wanted early = registration of the content formats specified in est-coaps.
Once = done, we direct a request for early registration of the content-format = values to the ACE chairs.
Although the corresponding media formats = have not been allocated yet for multipart-ct draft, the corresponding = content-format numbers can be allocated already.

Is that the = approved plan?

Please confirm or specify the conditions on = multipart-ct draft.

Many thanks for your = understanding,

Peter

Carsten = Bormann schreef op 2018-06-19 14:22:

On Jun 19, 2018, at = 14:11, Carsten Bormann <cabo@tzi.org> wrote: =


Since the = registry that we are registering into does not fulfill the preconditions = of RFC 7120 Section 2 point (a),


(Sorry, wasn't awake enough.  If we go for the 256-9999 = space, of course it does.  And we probably do.)

So we'll = have to follow the process according to Section 3 of RFC = 7120.

Starting with point (1) of Section = 3.1:

   1.  The authors (editors) of the = document submit a request for = early
       allocation to the = Working Group chairs, specifying which = code
       points require early = allocation and to which document they = should
       be = assigned.

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

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

------=_NextPart_000_0018_01D40876.E07564A0-- From nobody Wed Jun 20 12:43:03 2018 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 06B4E130E0D; Wed, 20 Jun 2018 12:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 4h5r5hTV5M9d; Wed, 20 Jun 2018 12:42:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE560130EE4; Wed, 20 Jun 2018 12:42:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 566DE20090; Wed, 20 Jun 2018 15:56:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 77CCB120B; Wed, 20 Jun 2018 15:39:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7593B1205; Wed, 20 Jun 2018 15:39:40 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: consultancy@vanderstok.org, "'Carsten Bormann'" , rdd@cert.org, "'Hannes Tschofenig'" , "'core'" , ace@ietf.org In-Reply-To: <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <91797cd1747cf05db20d64662306e038@bbhmail.nl> <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 19:42:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jim Schaad wrote: > That sounds like a good plan forward. Are you also going to need an e= arly > registration on the multipart-core draft as well? yes, it would be nice, ... we think that it's CORE's problem to adopt the draft and ask for that. The multipart response is only need for systems where the private key will = be generated on the EST server: and a number of implementers are keen *not* to do that, so the multipart is not urgent to as many people. > From: Peter van der Stok > Sent: Wednesday, June 20, 2018 3:07 AM > To: Carsten Bormann > Cc: Hannes Tschofenig ; core ; > ace@ietf.org; Jim Schaad ; rdd@cert.org > Subject: Re: [core] [Ace] Early media-type registration for EST over = CoAP > HI Carsten, Jim > Just to get this clear. > We will update the the est-coaps draft by referring to > draft-fossati-core-multipart-ct-05 for the wanted early registration = of the > content formats specified in est-coaps. > Once done, we direct a request for early registration of the content-= format > values to the ACE chairs. > Although the corresponding media formats have not been allocated yet = for > multipart-ct draft, the corresponding content-format numbers can be a= llocated > already. > Is that the approved plan? > Please confirm or specify the conditions on multipart-ct draft. > Many thanks for your understanding, > Peter > Carsten Bormann schreef op 2018-06-19 14:22: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > Since the registry that we are registering into does not fulfill the > preconditions of RFC 7120 Section 2 point (a), > (Sorry, wasn't awake enough. If we go for the 256-9999 space, of cour= se > it does. And we probably do.) > So we'll have to follow the process according to Section 3 of RFC 712= 0. > Starting with point (1) of Section 3.1: > 1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code > points require early allocation and to which document they should > be assigned. > Gr=C3=BC=C3=9Fe, Carsten > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyqteYCLcPvd0N1lAQJDeQf/Wxplvtx7BCgcRrWgQ8Yhq9FdR1Uvqz2z aGuHbD+UnJZrUc2uyetnPiS91m9qS46gXSwRebnW/o1E4DuImSz9Yu/9iIgMI+Hz vyu5R91WeTA9THxS9EQSQA80waappdaSfxguZooGloY2f/RWK/OxFE7346txfrnT dRRu6L+byWKnetAHnoyLJviUH+htKaPgQ4Lw/Atfms5BPoJI3NnQkM8cUDlCQ1FX SYPaKdTfN3Lil2loqNPf2sjEahr/Yb75P3H0yIAvBl9iYJYe+dgeAMINEGlALruG 3PY2cYWWo+d/wrG1xfJMOtwUeh8kwWWeZgVgGYEscBqn+ol+TAJoug== =OoSh -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 20 23:15:22 2018 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 9F3E013102A; Wed, 20 Jun 2018 23:15:15 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh5e_62uBZU5; Wed, 20 Jun 2018 23:15:13 -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 8F3D9130EE8; Wed, 20 Jun 2018 23:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5L6EsZw027079; Thu, 21 Jun 2018 08:14:54 +0200 (CEST) Received: from [192.168.217.102] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (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 41BBHy1TRfzDX9C; Thu, 21 Jun 2018 08:14:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <23428.1529523580@localhost> Date: Thu, 21 Jun 2018 08:14:53 +0200 Cc: Jim Schaad , rdd@cert.org, peter van der Stok , core , ace@ietf.org, Hannes Tschofenig X-Mao-Original-Outgoing-Id: 551254491.905203-3f43be2726a8c93fe69117e9d3863c85 Content-Transfer-Encoding: quoted-printable Message-Id: <48024F1A-13D4-4C45-A708-EA5495374225@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <91797cd1747cf05db20d64662306e038@bbhmail.nl> <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> <23428.1529523580@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 06:15:16 -0000 Hi Michael, On Jun 20, 2018, at 21:39, Michael Richardson = wrote: >=20 > The multipart response is only need for systems where the private key = will be > generated on the EST server: and a number of implementers are keen = *not* to > do that, so the multipart is not urgent to as many people. That is good to know, so we (core) can wait for working-group adoption = (WGA call ends Monday) and go for early allocation then. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 21 04:04:22 2018 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 ED6FD131221 for ; Thu, 21 Jun 2018 04:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kdHv7D7_bSj6 for ; Thu, 21 Jun 2018 04:04:18 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7E131217 for ; Thu, 21 Jun 2018 04:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1529579057; d=isode.com; s=june2016; i=@isode.com; bh=A88FASI5T8KR4s5L5yh75kq6U+yhz40AhbCzLl/cnPc=; 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=bBw/nQo+YZxQprmaDVrk/v1Gmxio8CaIGzakVNb8xP7DgLkenfjJnjlSG/bLQHFNrsDsRc m+WENth3msqc+59IThX5pIcQHxV9ChdcjNeQuniCMRxbxmjHAcP+i8hPbpcrEQmPsMPPwR CLj5nmKiHWMN6Teilv8Q3h6UsWyOkmg=; 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 ; Thu, 21 Jun 2018 12:04:17 +0100 To: "core@ietf.org" From: Alexey Melnikov Message-ID: <377daa74-ce28-75c2-a030-ad790445ddb1@isode.com> Date: Thu, 21 Jun 2018 12:03:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [core] Looking for volunteers to be Designated Expert for "CoAP Signaling Option Numbers" (RFC 8323) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 11:04:20 -0000 Hi, RFC 8323 established a new registry "CoAP Signaling Option Numbers": =C2=A0https://www.iana.org/assignments/core-parameters/core-parameters.xhtm= l#signaling-option-numbers I am soliciting for volunteers to become=C2=A0 Designated Expert(s) for this= =20 registry. Please reply to this email or to me directly. Thank you, Alexey, as AD. From nobody Thu Jun 21 06:11:24 2018 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 E5CE9130E2B; Thu, 21 Jun 2018 06:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckk6Q9KyqzYN; Thu, 21 Jun 2018 06:11:19 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0708F130E2A; Thu, 21 Jun 2018 06:11:18 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id E67E8180A68A9; Thu, 21 Jun 2018 13:11:17 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:2:41:69:72:152:355:379:582:800:962:967:969:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1575:1588:1589:1592:1594:1730:1776:1792:1801:2525:2561:2564:2682:2685:2829:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3586:3740:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4120:4250:4321:4605:4659:5007:6119:6261:6298:6659:6678:6684:7903:8509:8603:9015:9025:9177:9388:10004:10848:10946:11232:11233:11658:11914:12043:12295:12555:12679:12683:12895:12986:13139:13141:13161:13199:13229:13230:13439:13846:13972:14096:14149:21080:21433:21451:21625:21691:30012:30045:30048:30054:30076:30080, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, X-HE-Tag: debt43_62883dc702827 X-Filterd-Recvd-Size: 9967 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA; Thu, 21 Jun 2018 13:11:17 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_05d8c6987358712602dd86a449185f02" Date: Thu, 21 Jun 2018 15:11:16 +0200 From: Peter van der Stok To: rdd@cert.org, ietf@augustcellars.com Cc: Ace , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <6e79add52741ced7b0cade298f5d7404@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.129.53] Archived-At: Subject: [core] early registration of content formats specifid in est-coaps X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 13:11:23 -0000 --=_05d8c6987358712602dd86a449185f02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Dear ACE co-chairs, Given the advanced state of the implementation of est-coaps, it is requested that the content-formats specified in the draft are registered early (before RFC state). That permits to fill in the definite content-format codes in the implementation code. The required content-formats are specified in table 2 of section 9.1 (see below for a specimen) Many thanks to Klaus Hartke for his active contribution and Carsten Bormann for his support. +-------------------------+--------+-----+--------------------------+ | Media type | Encodi | ID | Reference | | | ng | | | +-------------------------+--------+-----+--------------------------+ | application/pkcs7-mime; | - | TBD | [RFC5751] [RFC7030] | | smime-type=server- | | 1 | | | generated-key | | | | | application/pkcs7-mime; | - | TBD | [RFC5751] | | smime-type=certs-only | | 2 | | | application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] | | smime-type=CMC-request | | 3 | | | application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] | | smime-type=CMC-response | | 4 | | | application/pkcs8 | - | TBD | [RFC5751] [RFC5958] | | | | 5 | | | application/csrattrs | - | TBD | [RFC7030] [RFC7231] | | | | 6 | | | application/pkcs10 | - | TBD | [RFC5751] [RFC5967] | | | | 7 | | | application/multict | - | TBD | [I-D.fossati-core-multip | | | | 8 | art-ct] | +-------------------------+--------+-----+--------------------------+ Table 2: New CoAP Content-Formats -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_05d8c6987358712602dd86a449185f02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Dear ACE co-chairs,

Given the advanced state of the implementati= on of est-coaps, it  is requested that the content-formats specified i= n the draft are registered early (before RFC state).
That permits to f= ill in the definite content-format codes in the implementation code.
<= br />The required content-formats are specified in table 2 of section 9.1 (= see below for a specimen)

Many thanks to Klaus Hartke for his ac= tive contribution and Carsten Bormann for his support.

   +-------------------------+--------+-----+-----------------= ---------+
   | Media type     &nb= sp;        | Encodi |  ID | Referen= ce            &= nbsp;   |
   |          =                      = ;| ng      |      |       = ;                     &nb= sp;     |
   +-------------------------+--------+= -----+--------------------------+
   | application/pkcs7-mi= me; | -      | TBD | [RFC5751] [RFC7030] &nbs= p;    |
   | smime-type=3Dserver-  = ;    |        | &nbs= p; 1 |           &nb= sp;            =   |
   | generated-key     &n= bsp;     |        |&= nbsp;    |        &n= bsp;            = ;     |
   | application/pkcs7-mime; | = -      | TBD | [RFC5751]    &n= bsp;           |
&n= bsp;  | smime-type=3Dcerts-only   |    &= nbsp;   |   2 |      &nbs= p;            &= nbsp;      |
   | application/pkcs= 7-mime; | -      | TBD | [RFC5751] [RFC5273] =      |
   | smime-type=3DCMC-request&nb= sp; |        |   3 | &nbs= p;            &= nbsp;           |
&= nbsp;  | application/pkcs7-mime; | -      | T= BD | [RFC5751] [RFC5273]      |
  = | smime-type=3DCMC-response |        |&= nbsp;  4 |          =             &nb= sp;   |
   | application/pkcs8   &= nbsp;   | -      | TBD | [RFC5751] [RFC5= 958]      |
   |   =             &nb= sp;         |   &nbs= p;    |   5 |      &= nbsp;           &nbs= p;       |
   | application/c= srattrs    | -      | TBD | [RFC703= 0] [RFC7231]      |
   | &nbs= p;            &= nbsp;          |  &n= bsp;     |   6 |     = ;            &n= bsp;        |
   | appli= cation/pkcs10      | -    &nbs= p; | TBD | [RFC5751] [RFC5967]      |
 =   |           &= nbsp;           &nbs= p; |        |   7 |  = ;            &n= bsp;           |
&n= bsp;  | application/multict     | -  &nb= sp;   | TBD | [I-D.fossati-core-multip |
   |&nbs= p;            &= nbsp;           | &n= bsp;      |   8 | art-ct]  &nb= sp;            =    |
   +-------------------------+--------+-----= +--------------------------+

     &nb= sp;            =    Table 2: New CoAP Content-Formats

--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org
www: = = www.vanderstok.org
tel NL: +31(0)492474673    &nbs= p;F: +33(0)966015248
--=_05d8c6987358712602dd86a449185f02-- From nobody Thu Jun 21 06:45:20 2018 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 C11F1130DDD; Thu, 21 Jun 2018 06:45:16 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3MmpVk94JOD; Thu, 21 Jun 2018 06:45:13 -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 8DA78130E3B; Thu, 21 Jun 2018 06:45:13 -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 w5LDj0GD007852; Thu, 21 Jun 2018 15:45:00 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (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 41BNHJ1yJZzDXGS; Thu, 21 Jun 2018 15:45:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <6e79add52741ced7b0cade298f5d7404@bbhmail.nl> Date: Thu, 21 Jun 2018 15:44:59 +0200 Cc: rdd@cert.org, ietf@augustcellars.com, Core , Ace X-Mao-Original-Outgoing-Id: 551281496.759093-8e8becb66c73a92015107f73847eb834 Content-Transfer-Encoding: quoted-printable Message-Id: <91AB542A-875D-4357-8779-E3A5639A6EB0@tzi.org> References: <6e79add52741ced7b0cade298f5d7404@bbhmail.nl> To: peter van der Stok X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] early registration of content formats specifid in est-coaps X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 13:45:17 -0000 On Jun 21, 2018, at 15:11, Peter van der Stok = wrote: >=20 > | application/multict | - | TBD | [I-D.fossati-core-multip = | Hi Peter, Didn=E2=80=99t we want to leave that to the draft that is under WG = adoption call now in core? (+1 for the rest; I just think it will be less confusing if the draft is = updated with this.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 21 07:30:32 2018 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 43A34131072; Thu, 21 Jun 2018 07:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XsVMLES4cx9; Thu, 21 Jun 2018 07:30:25 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6202713108C; Thu, 21 Jun 2018 07:30:25 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 691B6837F242; Thu, 21 Jun 2018 14:30:24 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1534:1541:1575:1588:1589:1592:1594:1711:1714:1730:1776:1792:2198:2199:2528:2553:2559:2562:2693:2827:2895:3138:3139:3140:3141:3142:3351:3622:3664:3865:3867:3870:3871:3872:3874:4250:4321:4605:5007:6117:6119:6261:6298:6657:6659:6678:7875:7903:8603:8660:9177:10004:10215:10400:10848:11232:11658:11783:11914:12043:12740:12895:13139:13148:13230:14180:14181:14721:21060:21080:21433:21451:21625:30054:30076:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:1:0, LFtime:24, LUA_SUMMARY:none X-HE-Tag: hat06_3daec74c3c054 X-Filterd-Recvd-Size: 3490 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf10.hostedemail.com (Postfix) with ESMTPA; Thu, 21 Jun 2018 14:30:23 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_16269078d3425a6cea97094b6a972031" Date: Thu, 21 Jun 2018 16:30:23 +0200 From: Peter van der Stok To: Carsten Bormann Cc: peter van der Stok , rdd@cert.org, ietf@augustcellars.com, Core , Ace Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <91AB542A-875D-4357-8779-E3A5639A6EB0@tzi.org> References: <6e79add52741ced7b0cade298f5d7404@bbhmail.nl> <91AB542A-875D-4357-8779-E3A5639A6EB0@tzi.org> Message-ID: <4f2b67fdd3384283ea366c6b1eac7e8f@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.129.53] Archived-At: Subject: Re: [core] early registration of content formats specifid in est-coaps X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 14:30:28 -0000 --=_16269078d3425a6cea97094b6a972031 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Apologies, I did it again: writing something else than I intended. Last line should be : | application/multipart-core | -- |TBD8 | [I-D.fossati-core-mulitpart-ct]| will re-submit draft to-morrow. Peter Carsten Bormann schreef op 2018-06-21 15:44: > On Jun 21, 2018, at 15:11, Peter van der Stok wrote: > >> | application/multict | - | TBD | [I-D.fossati-core-multip | > > Hi Peter, > > Didn't we want to leave that to the draft that is under WG adoption call now in core? > > (+1 for the rest; I just think it will be less confusing if the draft is updated with this.) > > Grüße, Carsten --=_16269078d3425a6cea97094b6a972031 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Apologies, I did it again: writing something else than I intended.
Last line should be :
| application/multipart-core | -- |TBD8 | [I-= D.fossati-core-mulitpart-ct]|

will re-submit draft to-morrow.
Peter

Carsten Bormann schreef op 2018-06-21 15:44:

= On Jun 21, 2018, at 15:11, Peter van der Stok <stokcons@bbhmail.nl> wrote:

   | application/multict  &= nbsp;  | -      | TBD | [I-D.fossati-cor= e-multip |

Hi Peter,

Didn't we want to leave that to the draft that= is under WG adoption call now in core?

(+1 for the rest; I jus= t think it will be less confusing if the draft is updated with this.)
=
Grüße, Carsten

--=_16269078d3425a6cea97094b6a972031-- From nobody Fri Jun 22 03:06:55 2018 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 D21A51274D0 for ; Fri, 22 Jun 2018 03:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oSIun6ADrvCl for ; Fri, 22 Jun 2018 03:06:50 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DE2130E19 for ; Fri, 22 Jun 2018 03:06:50 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 4A0FB1819DE92; Fri, 22 Jun 2018 10:06:49 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:152:355:379:582:599:800:960:962:967:973:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2527:2528:2551:2553:2559:2562:2692:2894:2901:3138:3139:3140:3141:3142:3353:3586:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4118:4250:4321:4362:5007:6117:6119:6261:6298:6657:6659:6678:7576:7809:7875:7901:7903:8583:8603:8957:9010:9080:9545:10004:10848:11232:11657:11658:11914:12043:12050:12295:12438:12663:12740:12895:13139:13436:13439:13846:13972:14181:14721:21080:21433:21451:21625:30029:30054:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: trip05_130550d0f548 X-Filterd-Recvd-Size: 7942 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf08.hostedemail.com (Postfix) with ESMTPA; Fri, 22 Jun 2018 10:06:48 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d88f4dc2612bf4ad5911beb27c86c897" Date: Fri, 22 Jun 2018 12:06:47 +0200 From: Peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, 'Hannes Tschofenig' , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <00d001d406ff$d1392f80$73ab8e80$@augustcellars.com> References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> <29a9636a3703e43947fce2f4cb900825@bbhmail.nl> <00d001d406ff$d1392f80$73ab8e80$@augustcellars.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.250.16] Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 10:06:53 -0000 --=_d88f4dc2612bf4ad5911beb27c86c897 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII H JIm, thanks, see below for fast questions Peter Jim Schaad schreef op 2018-06-18 14:28: > A couple of fast comments below > > Jim > > to assign a value to the endpoint name of the endpoint to be registered. Three possibilities are supported: > > FROM: core ON BEHALF OF Peter van der Stok > SENT: Monday, June 18, 2018 2:53 AM > TO: consultancy@vanderstok.org > CC: Hannes Tschofenig ; core@ietf.org > SUBJECT: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft > > * For PSK-based credential, the Endpoint Name becomes the PSK Identity > > [JLS] PSK identities are binary and not text strings so a mapping is going to be needed here as with RPKs. > > I understand, Is there a standard way to do so? otherwise, a BSD64 representation of the RPK or PSK key is all-right? > > * For raw-public keys, the Endpoint Name becomes the SubjectPublicKeyInfo structure (or a hash of it). > * For certificates, the Endpoint Name becomes the leftmost CN component of subject name or the SubjectAltName of the certificate, depending on what is used. > > An access token MAY include one of the two following new claims: > > "epn" endpoint name with value the identifier part of one of the 3 possible identifier parts of the security ccontext. > > [JLS] Why not use the 'normal' subject name? Would you think that they are the same or different? > > I seem to miss this. the intention is to provide the same three epn identifiers (RPK, PSK, certificate) for the three cases: > - ep registers itself, > - 3rd party registers ep, > - multiple registries , links are changed. > --=_d88f4dc2612bf4ad5911beb27c86c897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 H JIm,

thanks, see below for fast questions

Peter

Jim Schaad schreef op 2018-06-18 14:28:

A couple of fast comments below

 

Jim

 

 

to assign a value to the endpoint name of the endpoint t= o be registered. Three possibilities are supported:

From: core <core-bounces@ietf.org> On Beh= alf Of Peter van der Stok
Sent: Monday, June= 18, 2018 2:53 AM
To: consultancy@vanderstok.org
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; = core@ietf.org
Subject: Re: [core] Conclusion -- Endpo= int Client Name / Endpoint Name in RD draft



  1. For PSK-based credential, the Endpoint N= ame becomes the PSK Identity

[JLS] PSK identities are binary and not text strings so a mapp= ing is going to be needed here as with RPKs.

<pvds> I unde= rstand, Is there a standard way to do so? otherwise, a BSD64 representation= of the RPK or PSK key is all-right? </pvds>
<= /p>

  1. For raw-public keys, the = Endpoint Name becomes the SubjectPublicKeyInfo structur= e (or a hash of it).
  2. For certificates, the Endpoint=  Name becomes the leftmost CN component of&nb= sp;subject name or the SubjectAltName of the&= nbsp;certificate, depending on what is used.

An= access token MAY include one of the two following new claims:

"e= pn" endpoint name with value the identifier part of one of the 3 possible i= dentifier parts of the security ccontext.

[JLS] Why not use the 'normal' subject name? Would you think that they a= re the same or different?

=

<pvds> I seem to miss this. the intention is to provi= de the same  three epn identifiers (RPK, PSK, certificate) for the thr= ee cases:
- ep registers itself,
- 3rd party registers ep,
-= multiple registries , links are changed.
</pvds>

&nb= sp;

--=_d88f4dc2612bf4ad5911beb27c86c897-- From nobody Fri Jun 22 07:56:55 2018 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 A654E130E8E for ; Fri, 22 Jun 2018 07:56:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8fqtEdDsI_Rl for ; Fri, 22 Jun 2018 07:56:50 -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 D4D7C130E8B for ; Fri, 22 Jun 2018 07:56:49 -0700 (PDT) Received: from Jude (104.129.192.86) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Jun 2018 07:53:45 -0700 From: Jim Schaad To: CC: 'Hannes Tschofenig' , References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> <29a9636a3703e43947fce2f4cb900825@bbhmail.nl> <00d001d406ff$d1392f80$73ab8e80$@augustcellars.com> In-Reply-To: Date: Fri, 22 Jun 2018 07:56:42 -0700 Message-ID: <01c001d40a39$3cf415f0$b6dc41d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C1_01D409FE.9098E770" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLSQRyK31kKN7geubfCKDOvczH9iQKw5U1yAihxEq4C310y0gFDLGVkAV7n08IBtcHyTgJwqdY3ofvmYyA= Content-Language: en-us X-Originating-IP: [104.129.192.86] Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 14:56:53 -0000 ------=_NextPart_000_01C1_01D409FE.9098E770 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Given that the =E2=80=98sub=E2=80=99 claim is a binary value (for CWT), = if you don=E2=80=99t need to make a distinction on what the subject name = was derived from then you could just use that rather than defining a new = =E2=80=98epn=E2=80=99 claim. =20 =20 =20 From: Peter van der Stok =20 Sent: Friday, June 22, 2018 3:07 AM To: Jim Schaad Cc: consultancy@vanderstok.org; 'Hannes Tschofenig' = ; core@ietf.org Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name = in RD draft =20 H JIm, thanks, see below for fast questions Peter Jim Schaad schreef op 2018-06-18 14:28: A couple of fast comments below =20 Jim =20 =20 to assign a value to the endpoint name of the endpoint to be registered. = Three possibilities are supported: From: core > On = Behalf Of Peter van der Stok Sent: Monday, June 18, 2018 2:53 AM To: consultancy@vanderstok.org =20 Cc: Hannes Tschofenig >; core@ietf.org = =20 Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name = in RD draft =20 =20 1. For PSK-based credential, the Endpoint Name becomes the PSK Identity [JLS] PSK identities are binary and not text strings so a mapping is = going to be needed here as with RPKs. I understand, Is there a standard way to do so? otherwise, a = BSD64 representation of the RPK or PSK key is all-right? 1. For raw-public keys, the Endpoint Name becomes the = SubjectPublicKeyInfo structure (or a hash of it). 2. For certificates, the Endpoint Name becomes the leftmost CN component = of subject name or the SubjectAltName of the certificate, depending on = what is used. An access token MAY include one of the two following new claims: "epn" endpoint name with value the identifier part of one of the 3 = possible identifier parts of the security ccontext. [JLS] Why not use the 'normal' subject name? Would you think that they = are the same or different? I seem to miss this. the intention is to provide the same three = epn identifiers (RPK, PSK, certificate) for the three cases: - ep registers itself, - 3rd party registers ep, - multiple registries , links are changed. =20 ------=_NextPart_000_01C1_01D409FE.9098E770 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Given that the =E2=80=98sub=E2=80=99 claim is a binary = value (for CWT), if you don=E2=80=99t need to make a distinction on what = the subject name was derived from then you could just use that rather = than defining a new =E2=80=98epn=E2=80=99 claim.

 

 

 

From: Peter = van der Stok <stokcons@bbhmail.nl>
Sent: Friday, June = 22, 2018 3:07 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: consultancy@vanderstok.org; = 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>; = core@ietf.org
Subject: Re: [core] Conclusion -- Endpoint = Client Name / Endpoint Name in RD draft

 

H = JIm,

thanks, see below for fast = questions

Peter

Jim Schaad = schreef op 2018-06-18 14:28:

A couple of = fast comments below

 

Jim

 

 

to assign a = value to the endpoint name of the endpoint to be registered. Three = possibilities are = supported:

From:<= /strong> core <core-bounces@ietf.org> = On Behalf Of = Peter van der Stok
Sent: Monday, = June 18, 2018 2:53 AM
To: consultancy@vanderstok.org=
Cc: Hannes = Tschofenig <Hannes.Tschofenig@arm.com&g= t;; core@ietf.org
Subject: Re: = [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD = draft

 

 

  1. For = PSK-based credential, the Endpoint Name becomes the PSK = Identity

[JLS] PSK = identities are binary and not text strings so a mapping is going to be = needed here as with RPKs.

<pvds> I understand, Is there a = standard way to do so? otherwise, a BSD64 representation of the RPK or = PSK key is all-right? </pvds>

  1. For raw-= public keys, the Endpoint Name becomes the = SubjectPublicKeyInfo structure (or a hash of&nbs= p;it).
  2. For cert= ificates, = the Endpoint Name becomes the leftmost CN = component of subject name or the SubjectAlt= Name of the certificate, depending on what is = used.

An access = token MAY include one of the two following new = claims:

"epn&quo= t; endpoint name with value the identifier part of one of the 3 possible = identifier parts of the security ccontext.

[JLS] Why = not use the 'normal' subject name? Would you think that they are the = same or different?

<pvds> = I seem to miss this. the intention is to provide the same  three = epn identifiers (RPK, PSK, certificate) for the three cases:
- ep = registers itself,
- 3rd party registers ep,
- multiple registries = , links are = changed.
</pvds>

 

=
------=_NextPart_000_01C1_01D409FE.9098E770-- From nobody Fri Jun 22 08:32:38 2018 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 2E2DD130E96 for ; Fri, 22 Jun 2018 08:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 cpHtGDke5fNL for ; Fri, 22 Jun 2018 08:32:34 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 284B0130E9A for ; Fri, 22 Jun 2018 08:32:33 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w5MFVrKN002377 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Jun 2018 17:31:54 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w5MFVqNW001761 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Jun 2018 17:31:53 +0200 Received: from DEFTHW99ER4MSX.ww902.siemens.net (139.22.70.78) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 22 Jun 2018 17:31:52 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.149]) by DEFTHW99ER4MSX.ww902.siemens.net ([139.22.70.78]) with mapi id 14.03.0399.000; Fri, 22 Jun 2018 17:31:52 +0200 From: "Kovatsch, Matthias" To: "consultancy@vanderstok.org" CC: Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "core@ietf.org" Thread-Topic: Definition of the ins target attribute - WAS: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPc2CJmMIAFfi1CQCiQbpKRtnOkzAAVg0oACzrQ9FA= Date: Fri, 22 Jun 2018 15:31:51 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01FBFE71@DEFTHW99EL4MSX.ww902.siemens.net> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 15:32:37 -0000 RGVhciBQZXRlcg0KDQpJIGFtIHNvcnJ5IHRoYXQgSSBjYW5ub3QgYmUgbW9yZSBhY3RpdmUgb24g dGhpcyBpc3N1ZS4gSSB3YW50IHRocmVlIHRoaW5nczoNCg0KLSBBdm9pZCB0ZXJtaW5vbG9neSBj b25mbGljdHMgYmV0d2VlbiB0aGUgdHdvIGVjb3N5c3RlbXMgKGUuZy4sIGRvbWFpbiwgaW5zdGFu Y2UgLS0gbm90IHN1cmUgaWYgdGhlcmUgYXJlIG1vcmUpDQotIE1ha2Ugc3VyZSB3ZSBoYXZlIGNs ZWFyIGRlZmluaXRpb25zIG9mIHRoZSBhdHRyaWJ1dGVzIHdlIHVzZSBmb3IgZGlzY292ZXJ5IGlu IENvUkUNCi0gTWFrZSBzdXJlIHdlIGhhdmUgdGhlIHJpZ2h0IGF0dHJpYnV0ZXMgdG8gY292ZXIg dGhlIGtub3duIHVzZSBjYXNlcw0KDQpGb3IgdGhpcywgSSB0aGluayB3ZSBuZWVkIHRoZSBmb2xs b3dpbmc6DQoNCi0gRGVmaW5lIG5ldyBhdHRyaWJ1dGVzIHdoZXJlIHRoZSBkZWZpbml0aW9uIGRv ZXMgbm90IGZ1bGx5IG1hdGNoIHRoZSBETlMtU0QgZGVmaW5pdGlvbiAoZG9tYWluLCBpbnN0YW5j ZSwgLi4ubW9yZT8pLiBPbmUgb2YgdGhlIGJpZ2dlc3QgcXVlc3Rpb25zIHNlZW1zIHRvIGJlICJ3 aGF0IGlzIGEgZG9tYWluIGluIENvUkU/Ii4NCg0KLSBHZXQgdGhlIGZ1bGwgcGljdHVyZSBvZiB3 aGF0IGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQsIHdoYXQgdGhleSBtZWFuLCBhbmQgaG93IHdlIHNo b3VsZCB1c2UgdGhlbS4gV2l0aG91dCB0aGlzLCBpdCBpcyBoYXJkIHRvIGRpc2N1c3MgYSBnb29k IHdheSBmb3J3YXJkLiBDb3VsZCBzb21lb25lIHByZXBhcmUgYSBmdWxsIGxpc3Qgd2l0aCByZWZl cmVuY2VzIHdoZXJlIHRoZXkgY29tZSBmcm9tIChlLmcuLCBSRkMgNjY5MCBldGMuKT8NCg0KLSBN b2RlbCB0aGUgY3VycmVudGx5IGtub3duIHVzZSBjYXNlcyBzdWNoIGFzICJmaW5kIGFueSByZXNv dXJjZSBvZiB0eXBlICgicnQiKSB4IiAoZS5nLiwgYW4gUkQgcmVnaXN0cmF0aW9uIGludGVyZmFj ZSkgb3IgImZpbmQgYWxsIGRldmljZXMgb3duZWQgYnkgeSIgKGUuZy4sIGFsbCBlbmRwb2ludHMg d2l0aCBzYW1lICJkIikgb3IgImZpbmQgbXkgYW5kIGdvZXMgdG8gImZpbmQgdGhlIG5ldyBVUkkg Zm9yIHRoZSBleGFjdCByZXNvdXJjZSBpbnN0YW5jZSB6IEkgd2FzIGNvbmZpZ3VyZWQgd2l0aCBw cmV2aW91c2x5IiAoZS5nLiwgYW4gb24vb2ZmIHJlc291cmNlIG9mIGEgc3BlY2lmaWMgbGlnaHQg YnVsYikgd2l0aCB0aGUgbGlzdCBvZiBhdmFpbGFibGUgYXR0cmlidXRlcyB0byBpZGVudGlmeSB3 aGl0ZSBzcG90cyBhbmQgdW5jbGVhciBkZWZpbml0aW9ucy4NCg0KU29tZSBxdWVzdGlvbnMsIEkg aGF2ZToNCg0KSSBhbSBub3cgbm90IHN1cmUgd2hhdCB2YWx1ZS9iZW5lZml0ICJpbnMiIHdpdGgg dGhlIEROUy1TRCBtZWFuaW5nIHdvdWxkIGhhdmUgaW4gQ29SRS4gV2hhdCBkb2VzIGl0IG1lYW4g Zm9yIGEgZGV2aWNlIHRvIGJlIGFuIGluc3RhbmNlIHdpdGhpbiBhIEROUyBkb21haW4/IElzIGl0 IGEgbWFudWZhY3R1cmVyLXdpZGUgdW5pcXVlIGlkZW50aWZpZXI/IFdpbGwgYWxsIElvVCBpbnN0 YWxsYXRpb25zIG5lZWQgdGhlaXIgb3duIHRvcC1sZXZlbCBkb21haW4/DQoNCldoYXQgd2F5cyBv ZiBncm91cGluZyByZXNvdXJjZXMgaW4gYW4gUkQgYXJlIGVudmlzaW9uZWQ/IEkgYXNzdW1lZCB3 ZSBncm91cCBlbmRwb2ludHMgYnkgb3duZXIgKD1kIC0tPiBzaG91bGQgaGF2ZSBhIGJldHRlciBm aXR0aW5nIG5hbWUpLCBidXQgbWF5YmUgd2Ugd2FudCB0byBncm91cCB0aGVtIGJ5IHN1Yi1zeXN0 ZW0gb3Igc29tZXRoaW5nLg0KDQpCZXN0IHdpc2hlcywNCk1hdHRoaWFzDQoNCj4gLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IHBldGVyIHZhbiBkZXIgU3RvayBbbWFp bHRvOnN0b2tjb25zQHhzNGFsbC5ubF0NCj4gR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDI2LiBBcHJp bCAyMDE4IDExOjE0DQo+IEFuOiBLb3ZhdHNjaCwgTWF0dGhpYXMgKENUIFJEQSBJT1QgRVdULURF KQ0KPiBDYzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7IEppbSBTY2hhYWQ7ICdDaHJpc3Rp YW4gQW1zw7xzcyc7IGNvcmVAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IERlZmluaXRpb24gb2Yg dGhlIGlucyB0YXJnZXQgYXR0cmlidXRlIC0gV0FTOiBbY29yZV0gRW5kcG9pbnQgQ2xpZW50IE5h bWUgLyBFbmRwb2ludCBOYW1lIGluIFJEIGRyYWZ0DQo+IA0KPiBIaSBNYXR0aGlhcywNCj4gDQo+ IE9uIG9mIHRoZSBjb25mdXNpbmcgYXNwZWN0cyBpcyBpbmRlZWQgdGhlIGRvbWFpbi4NCj4gRG9t YWluIGlzIHVzZWQgaW4gdHdvIHNlbnNlczoNCj4gKyBkPSBhcyBhIGxvY2FsIGRvbWFpbiBkZWZp bml0aW9uIHdpdGhpbiByZCB0byBncm91cCByZXNvdXJjZXMNCj4gKyBkb21haW4gYXMgdXNlZCBp biBETlMNCj4gDQo+IEluIGVhcmxpZXIgUkQgdGV4dHMgYSBtYXBwaW5nIHdhcyBzdWdnZXN0ZWQg YmV0d2VlbiBkPSBhbmQgdGhlIEROUw0KPiBkb21haW4uDQo+IFRoYXQgd2FzIGFiYW5kb25lZCBi ZWNhdXNlIHVudXNhYmxlIGZvciBtb3N0IGJ1aWxkaW5nIGluc3RhbGxhdGlvbnMgYXMNCj4gd2Ug a25vdyB0aGVtLg0KPiANCj4gVGhlIG1hcHBpbmcgbWF5IGJlIHBvc3NpYmxlIGZvciBvdGhlciBp bnN0YWxsYXRpb25zLCBidXQgaXQgY2VydGFpbmx5DQo+IGNhbm5vdCBiZSBhIGdlbmVyYWwgcnVs ZS4NCj4gDQo+IFRoZSBSRC1ETlMtU2QgZHJhZnQgZG9lcyBub3Qgd2FudCB0byBzdWdnZXN0IHRo YXQgeW91IG5lZWQgdG8gbGVhcm4NCj4gRE5TLVNEIHRvIGRvIGNvcmUgZGlzY292ZXJ5LA0KPiBi dXQgeW91IGhhdmUgdG8gbGVhcm4gRE5TLXNkIHRvIGdldCB0aGUgUkQgdG8gRE5TU0QgbWFwcGlu ZyByaWdodC4NCj4gaW5zIGlzIGFuIGltcG9ydGFudCBhdHRyaWJ1dGUgdG8gc2VsZWN0IHRoZSBz ZXJ2aWNlIHR5cGUgaW5zdGFuY2UgbmVlZGVkDQo+IGZvciBkbnNzZC4NCj4gDQo+IEkgYW0gaGFw cHkgdG8gbGVhcm4gaG93IHlvdSB3YW50IHRvIGZpdCBpbnMgdmFsdWVzIGludG8gUkQgZGlzY292 ZXJ5Lg0KPiBQb3NzaWJseSB5b3UgbmVlZCBhIG5ldyBhdHRyaWJ1dGUgaW4gUkQNCj4gZ2l2ZW4g dGhhdCB0aGUgbWFwcGluZyBmcm9tIFJEIHRvIEROU1NEIGlzIG5vdCBhbHdheXMgMS0xLg0KPiAN Cj4gR3JlZXRpbmdzLA0KPiANCj4gUGV0ZXINCj4gDQo+IEtvdmF0c2NoLCBNYXR0aGlhcyBzY2hy ZWVmIG9wIDIwMTgtMDQtMjUgMjM6Mjk6DQo+ID4gRGVhciBhbGwNCj4gPg0KPiA+IE15IG1vdGl2 YXRpb24gZm9yIHJhaXNpbmcgdGhpcyBpc3N1ZSB3YXMgdGhhdCBJIGxlYXJuZWQgdGhhdCAiaW5z IiBpcw0KPiA+IHVzZWQgZGlmZmVyZW50bHkgZnJvbSBpdHMgKG9yaWdpbmFsKSBwdXJwb3NlLiBJ IGFncmVlIHRoYXQgdGhlcmUgaXMgbm8NCj4gPiBzcGVjaWFsIGhhbmRsaW5nIG9mICJpbnMiIGJ5 IFJELiBIYXZpbmcgaXQgaW4gdGhlIEROUy1TRCBkcmFmdCBtaWdodA0KPiA+IHNoaWZ0IGl0cyBt ZWFuaW5nIG9yIGF0IGxlYXN0IHBlcmNlcHRpb24gYW5kIGRlZmluaXRlbHkgdmlzaWJpbGl0eS4N Cj4gPiBXcml0aW5nIGl0cyBvd24gZHJhZnQgZm9yIGp1c3QgImlucyIgaXMgb3ZlcmtpbGwsIHRo b3VnaC4NCj4gPg0KPiA+DQo+ID4gImlucyIgaGFzIGFuIGltcG9ydGFudCByb2xlIHdpdGhpbiBD b1JFIGRpc2NvdmVyeSBhbmQgd2Ugc2hvdWxkIGF2b2lkDQo+ID4gdGhhdCBwZW9wbGUgb3Zlcmxv b2sgaXQsIGJlY2F1c2UgdGhleSB0aGluayB0aGV5IGRvIG5vdCBuZWVkIEROUy1TRA0KPiA+IChh bmQgdGhleSBkbyBub3QgbmVlZCBpdCBmb3IgQ29SRSBkaXNjb3ZlcnkpLiBTbyB3ZSBuZWVkIHRv IG5haWwgZG93bg0KPiA+IGl0cyBkZWZpbml0aW9uIGFuZCBwcm9iYWJseSBtZW50aW9uIGl0IGlu IG11bHRpcGxlIGRyYWZ0cyAod2l0aCBwcm9wZXINCj4gPiByZWZlcmVuY2VzKS4gSSByZWFkIHRo ZSB0ZXh0IGluIGNvcmUtcmQtZG5zLXNkIGFuZCBpdCBpcyByb3VnaGx5IGZpbmUsDQo+ID4gYnV0 IHNvdW5kcyBhIGJpdCBsaWtlIEkgaGF2ZSB0byBsZWFybiBETlMtU0QgdG8gZG8gQ29SRSBkaXNj b3ZlcnkuDQo+ID4gQWxzbyBJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBmb2xsb3dpbmcgc3RhdGVt ZW50cyB3aXRoaW4gdGhlIHNhbWUNCj4gPiBzZWN0aW9uIDIuMToNCj4gPg0KPiA+PiAiU0hPVUxE IGJlIHVuaXF1ZSBhY3Jvc3MgcmVzb3VyY2VzIHdpdGggdGhlIHNhbWUgUmVzb3VyY2UgVHlwZQ0K PiA+PiBhdHRyaWJ1dGUgaW4gdGhlIGRvbWFpbiBpdCBpcyB1c2VkLiINCj4gPg0KPiA+IElzICJk b21haW4iIGNvcnJlc3BvbmRpbmcgdG8gUkQncyAiZCIgcGFyYW1ldGVyIGFuZCBhdHRyaWJ1dGU/ DQo+ID4NCj4gPj4gIlRoaXMgYXR0cmlidXRlIGlzIHVzZWQgYnkgYSBSZXNvdXJjZSBEaXJlY3Rv cnkgdG8gZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KPiA+PiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhl IHNhbWUgcmVzb3VyY2UgdHlwZSB3aXRoaW4gdGhlIGRpcmVjdG9yeSINCj4gPg0KPiA+IEhlcmUg aXQgc291bmRzIGxpa2UgaXQgbmVlZHMgdG8gYmUgdW5pcXVlIGFjcm9zcyBhbGwgcmVzb3VyY2Vz IHdpdGgNCj4gPiB0aGUgc2FtZSBSZXNvdXJjZSBUeXBlIGF0dHJpYnV0ZSBpbiB0aGUgUkQuDQo+ ID4NCj4gPg0KPiA+IExvZ2ljYWxseSBhbmQgaGlzdG9yaWNhbGx5LCBJIHdvdWxkIGhhdmUgZXhw ZWN0ZWQgdGhhdCAiaW5zIiBNVVNUIGJlDQo+ID4gdW5pcXVlIGFjcm9zcyBhbGwgcmVzb3VyY2Vz IHdpdGggdGhlIHNhbWUgUmVzb3VyY2UgVHlwZSBhdHRyaWJ1dGUgaW4NCj4gPiBvbmUgZGV2aWNl ICg9ZXApLiBJIGRvbid0IGtub3cgaWYgdGhlcmUgaXMgYSBjb25mbGljdCB3aXRoIEROUy1TRA0K PiA+IGhlcmUsIHNvIHRoYXQgd2UgY2Fubm90IGRlZmluZSB0aGlzLiBZZXQgYSBkZWZpbml0aW9u IHRvIGJlIHVuaXF1ZQ0KPiA+IHdpdGhpbiAiZCIgc2VlbXMgdG8gYWltIGZvciBhcHBsaWNhdGlv biBzZW1hbnRpY3M6DQo+ID4NCj4gPiBXaGVuIHVuaXF1ZSB3aXRoaW4gImVwIiwgYSBkZXZpY2Ug ZnJvbSB0aGUgZmFjdG9yeSBjb3VsZCBhbHJlYWR5IGhhdmUNCj4gPiAiaW5zIiBhdHRyaWJ1dGVz IGZvciBpdHMgcmVzb3VyY2VzLCBmb3IgaW5zdGFuY2UsIGEgd2VhdGhlciBzdGF0aW9uDQo+ID4g d2l0aCB0d28gdGVtcGVyYXR1cmUgc2Vuc29ycywgb25lIGlucz1pbmRvb3IsIG9uZSBpbnM9b3V0 ZG9vci4NCj4gPg0KPiA+IFdoZW4gdW5pcXVlIHdpdGhpbiAiZCIsIHNvbWVvbmUgaGFkIHRvIHJl d3JpdGUgdGhlICJpbnMiIGF0dHJpYnV0ZXMsDQo+ID4gc28gdGhhdCB0aGV5IG1hdGNoIHRoZSBk ZXBsb3ltZW50IG9yIGFwcGxpY2F0aW9uLCBmb3IgaW5zdGFuY2UsDQo+ID4gaW5zPSJpbmRvb3Ig a2l0Y2hlbiIsIGlucz0iaW5kb29yIGxvYmJ5IiwgaW5zPSJvdXRkb29yIHRlcnJhY2UiLA0KPiA+ IGlucz0ib3V0ZG9vciBnYXJhZ2UiLg0KPiA+DQo+ID4NCj4gPiBEbyB3ZSBhY3R1YWxseSBoYXZl IHJvdWdoIGNvbnNlbnN1cyBvbiB3aGF0ICJpbnMiIGFjdHVhbGx5IG1lYW5zIGFuZA0KPiA+IGhv dyBpdCBzaG91bGQgYmUgdXNlZCBmb3IgZGlzY292ZXJ5IHdpdGhpbiBDb1JFPw0KPiA+IChUaGVy ZSBpcyBhIGhpZ2ggY2hhbmNlIHRoYXQgSSBqdXN0IG1pc3NlZCB0aGF0IGR1ZSB0byBiZWluZyBi dXN5IHdpdGgNCj4gPiBvdGhlciBzdHVmZi4uLikNCj4gPg0KPiA+DQo+ID4gQmVzdCB3aXNoZXMs DQo+ID4gTWF0dGhpYXMNCj4gPg0KPiA+DQo+ID4+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0LS0tLS0NCj4gPj4gVm9uOiBwZXRlciB2YW4gZGVyIFN0b2sgW21haWx0bzpzdG9rY29uc0B4 czRhbGwubmxdDQo+ID4+IEdlc2VuZGV0OiBEaWVuc3RhZywgMjQuIEFwcmlsIDIwMTggMTE6NDAN Cj4gPj4gQW46IEppbSBTY2hhYWQNCj4gPj4gQ2M6IEtvdmF0c2NoLCBNYXR0aGlhcyAoQ1QgUkRB IElPVCBFV1QtREUpOyAnQ2hyaXN0aWFuIEFtc8O8c3MnOw0KPiA+PiBjb25zdWx0YW5jeUB2YW5k ZXJzdG9rLm9yZzsgY29yZUBpZXRmLm9yZw0KPiA+PiBCZXRyZWZmOiBSZTogW2NvcmVdIEVuZHBv aW50IENsaWVudCBOYW1lIC8gRW5kcG9pbnQgTmFtZSBpbiBSRCBkcmFmdA0KPiA+Pg0KPiA+Pg0K PiA+PiA+Pg0KPiA+PiA+PiBSZWxhdGVkIHRvIHRoaXMgaXMgdGhlIHByb3BlciBkZWZpbml0aW9u IG9mICJpbnMiLCB3aGljaA0KPiA+PiA+PiB1bmZvcnR1bmF0ZWx5IHdhcyBtb3ZlZCBvdmVyIHRv IHRoZSBjb3JlLXJkLWRucy1zZCBkcmFmdC4gImlucyIgaXMNCj4gPj4gPj4gdXNlZCB0byBkaXN0 aW5ndWlzaCByZXNvdXJjZXMgd2l0aCB0aGUgc2FtZSAicnQiLiBPcmlnaW5hbGx5LCBpdCB3YXMN Cj4gPj4gPj4gdXNlZCBmb3IgcmVzb3VyY2Ugd2l0aGluIHRoZSBzYW1lIGRldmljZSAoZS5nLiwN Cj4gPj4gPj4gPC90MT47cnQ9dGVtcGVyYXR1cmU7aW5zPWluZG9vciw8L3QyPjtydD10ZW1wZXJh dHVyZTtpbnM9b3V0ZG9vcikuIEJ5DQo+ID4+ID4+IG5vdywgaXQgb2Z0ZW4gaXMgYXNzdW1lZCB0 byByZXF1aXJlIGdsb2JhbCB1bmlxdWVuZXNzLiBJIGNsYWltIHRoYXQNCj4gPj4gPj4gdGhpcyBp cyBub3QgcmVxdWlyZWQgd2hlbiAiZXAiIGlzIHVzZWQgY29ycmVjdGx5LiBVc2luZyBhIGhpZXJh cmNoeQ0KPiA+PiA+PiBvZiAiZCIgLT4gImVwIg0KPiA+PiA+PiAtPiAiaW5zIg0KPiA+PiA+PiBw cm92aWRlcyBtb3JlIGZsZXhpYmlsaXR5IHRoYW4gbWFraW5nICJpbnMiIGdsb2JhbGx5IHVuaXF1 ZS4gImlucyINCj4gPj4gPj4gY2FuIHN0aWxsIGhhdmUgYSBnbG9iYWwgbWVhbmluZyAoY2YuIGlu ZG9vciB2cyBvdXRkb29yKSwgYnV0IGl0DQo+ID4+ID4+IHNob3VsZCBiZSByZS11c2FibGUgZm9y IGFsbCByZXNvdXJjZXMgd2l0aCBzaW1pbGFyIGluc3RhbmNlDQo+ID4+ID4+IHNlbWFudGljcy4g VW5pcXVlbmVzcyBpcyBhY2hpZXZlZCB0aHJvdWdoICJkIiBhbmQgImVwIi4NCj4gPj4gPj4NCj4g Pj4gPj4gSSB0aGluayAiaW5zIiBzaG91bGQgYmVjb21lIHBhcnQgb2YgdGhlIFJEIGRyYWZ0IGFn YWluIHRvIGJlIGRlZmluZWQNCj4gPj4gPj4gdG9nZXRoZXIgd2l0aCAiZCIgYW5kICJlcCIsIGFz IHRoZXkgYXJlIHBhcnQgb2YgYSBsYXJnZXIgZGlzY292ZXJ5DQo+ID4+ID4+IGZyYW1ld29yay4N Cj4gPj4gPg0KPiA+PiA+IElmICJpbnMiIGRvZXMgbm90IG5lZWQgdG8gYmUgaGFuZGxlZCBpbiBh IHNwZWNpYWwgbWFubmVyIGJ5IHRoZSBSRCwNCj4gPj4gPiB0aGVuIEkgd291bGQgc2VlIG5vIHJl YXNvbiBmb3IgaXQgdG8gYmUgcGFydCBvZiB0aGUgUkQgZHJhZnQuICBCb3RoDQo+ID4+ID4gImVw IiBhbmQgImQiIGFyZSB0cmVhdGVkIGluIGEgc3BlY2lhbCBtYW5uZXIgYXMgdGhlIHBhaXIgaXMg cmVxdWlyZWQNCj4gPj4gPiB0byBiZSBnbG9iYWxseSB1bmlxdWUgaW4gdGhlIFJELiAgVGhpcyBp cyBub3QgYSB0cnVlIHN0YXRlbWVudCBmb3IgdGhlDQo+ID4+ID4gImlucyIgYXR0cmlidXRlIGV2 ZW4gaW4gdGhlIGNvcmUtcmQtZG5zLXNkIGRyYWZ0Lg0KPiA+PiA+DQo+ID4+ID4gSmltDQo+ID4+ ID4NCj4gPj4gIklucyIgaXMgdXNlZCB0byBzcGVjaWZ5IHRoZSBpbnN0YW5jZSBuYW1lIGZvciBE TlMgcmVjb3JkcyBuZWNlc3NhcnkNCj4gPj4gZm9yIEROUy1zZCBzZXJ2aWNlIHNwZWNpZmljYXRp b24gdGhlIFJELUROUy1TRCBkcmFmdCBzcGVjaWZpZXMNCj4gPj4gdGhlIHJ1bGVzIHRvIGdlbmVy YXRlIGlucyB2YWx1ZXMgQXMgc3VjaCBpdCBpcyB0b3RhbGx5IHByb3BlciB0aGF0DQo+ID4+ICJp bnMiIHJ1bGVzIGFyZSBzcGVjaWZpZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdCwgYmVjYXVzZSAiaW5z IiB0cmVhdG1lbnQNCj4gPj4gaXMNCj4gPj4gZGlzY29ubmVjdGVkIGZyb20gdGhlIHNwZWNpYWwg dHJlYXRtZW50IHNwZWNpZmllZCBmb3IgImVwIiBhbmQgImQiLg0KPiA+Pg0KPiA+PiBNYXR0aGlh cywgQXJlIHlvdSBleHByZXNzaW5nIHRoYXQgYW4gYWRkaXRpb25hbCBuZWVkIGV4aXN0cyB0bw0K PiA+PiBkaXN0aW5ndWlzaCByZWdpc3RyYXRpb25zPw0KPiA+Pg0KPiA+PiBQZXRlcg0K From nobody Fri Jun 22 09:08:49 2018 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 B8567130EA9 for ; Fri, 22 Jun 2018 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 iuoO2KQ5vvMq for ; Fri, 22 Jun 2018 09:08:46 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 D3622130EA2 for ; Fri, 22 Jun 2018 09:08:45 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w5MG8goI012363 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Jun 2018 18:08:42 +0200 Received: from DEFTHW99ERJMSX.ww902.siemens.net (defthw99erjmsx.ww902.siemens.net [139.22.70.135]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w5MG8c4w024060 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Jun 2018 18:08:42 +0200 Received: from DEFTHW99ERSMSX.ww902.siemens.net (139.22.70.207) by DEFTHW99ERJMSX.ww902.siemens.net (139.22.70.135) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 22 Jun 2018 18:08:38 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.149]) by DEFTHW99ERSMSX.ww902.siemens.net ([139.22.70.207]) with mapi id 14.03.0399.000; Fri, 22 Jun 2018 18:08:37 +0200 From: "Kovatsch, Matthias" To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dBIG11bHRpcGFydC9jb3Jl?= Thread-Index: AQHUAUFuSJfzcFuC9EKZmxelzh2jo6RsfDTg Date: Fri, 22 Jun 2018 16:08:37 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01FBFEB6@DEFTHW99EL4MSX.ww902.siemens.net> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> 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.22] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01FBFEB6DEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 16:08:49 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01FBFEB6DEFTHW99EL4MSXw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KVGhpcyBwcm9wb3NhbCBhbHNvIHNvbHZlcyBhbiBpc3N1ZSB3aXRoIE9ic2VydmUgd2hl biBhIGNoYW5nZSBpbiB0aGUgQ29udGVudCBGb3JtYXQgaXMgbmVlZGVkIChlLmcuLCB0byBzZW5k IGFuIGVycm9yIHJlcHJlc2VudGF0aW9uIGluIHRoZSBmaW5hbCBub3RpZmljYXRpb24pLg0KDQpJ dCBhbHNvIGNvbnRhaW5zIHRoZSBmdW5jdGlvbmFsaXR5IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1ib3JtYW5uLWNvcmUtbWF5YmUtMDAsIHdoaWNoIGlzIGludGVyZXN0aW5nIGZv ciBDb0FQIFB1YlN1Yi4gKFdlcmUgdGhlcmUgb3RoZXIgdXNlIGNhc2VzPykNCg0KSSBhbHNvIHdh bnQgdG8gKzEgYW4gZWFybGllciBjb21tZW50IGJ5IEtsYXVzOg0KDQoNCj4gRm9yIGV2b2x2YWJp bGl0eSwgd2Ugc2hvdWxkIGFkZCBydWxlcyBmb3IgcHJvY2Vzc2luZyBwYXJ0cyB0aGF0IGxvb2sN Cg0KPiBpbnZhbGlkIGF0IHRoZSBtb21lbnQuIEkgY2FuIGltYWdpbmUgdGhlIG5lZWQgZm9yIG90 aGVyIHJlcHJlc2VudGF0aW9uDQoNCj4gbWV0YWRhdGEgaW4gYWRkaXRpb24gdG8gdGhlIGNvbnRl bnQgZm9ybWF0IGluIHRoZSBmdXR1cmUsIHNvIHRoZXJlDQoNCj4gbWlnaHQgYmUgYSBtYXAgaW4g cGxhY2Ugb2YgdGhlIHVpbnQuIEkgd291bGRuJ3Qgd2FudCB0byBibG9hdCB0aGUNCg0KPiBmb3Jt YXQgcmlnaHQgbm93LCB0aG91Z2guIExldCdzIGtlZXAgaXQgc21hbGwgYW5kIGZvY3VzZWQsIGFu ZCBhbGxvdw0KDQo+IGZvciBldm9sdmluZyBpdCBsYXRlciBzaG91bGQgdGhlIG5lZWQgYXJpc2Uu DQoNCg0KT0NGLCBmb3IgaW5zdGFuY2UsIHVzZXMgYSBjdXN0b20gdmVyc2lvbiBvcHRpb24gdGhh dCBtdXN0IGdvIGFsb25nIHdpdGggdGhlIENvbnRlbnQtRm9ybWF0IG9wdGlvbi4gSGVuY2UsIHRo ZSBuZWVkIGZvciBzdXBwb3J0aW5nIGEgbnVtYmVyIG9mIHBheWxvYWQtZGVmaW5pbmcgZWxlbWVu dHMgYXBwZWFycyB2YWxpZC4NCg0KDQoNClRoZSBtZW1vIGN1cnJlbnRseSBtZW50aW9ucyB0aGUg 4oCcZm9ybWF0IGlkZW50aWZ5aW5nIGVsZW1lbnQgYWx0ZXJuYXRpdmVseSBjYW4gYmUgYSB0ZXh0 IHN0cmluZyBnaXZpbmcgdGhlIG1lZGlhIHR5cGUgbmFtZSBwbHVzIHBvdGVudGlhbGx5IHNvbWUg cGFyYW1ldGVyc+KAnS4gVGhpcyBsb29rcyBsaWtlIGEgc2lkZSBmZWF0dXJlL2hhY2sgdG8gYWRk IHN0cmluZyBzdXBwb3J0IGluIENvQVAuIEhvd2V2ZXIsIHRoaXMgb3BlbnMgdXAgYSBjYW4gb2Yg d29ybXMsIGFzIGl0IGludml0ZXMgdG8gdXNlIHVuZGVmaW5lZCBuYW1lcyBhbmQgdGhlIHBhcmFt ZXRlcnMgd291bGQgbGFjayBwcm9wZXIgZGVmaW5pdGlvbi4gUGFyYW1ldGVycyBzaG91bGQgcmF0 aGVyIHVzZSB0aGUgb3B0aW9uIG1lY2hhbmlzbSAocHJvcGVybHkgZGVmaW5lIGFuIG9wdGlvbiBu dW1iZXIpIGFuZCBiZSBwYXNzZWQgdXNpbmcgYSBtYXAgbWVjaGFuaXNtIGFzIHByb3Bvc2VkIGJ5 IEtsYXVzLg0KDQpCZXN0IHdpc2hlcywNCk1hdHRoaWFzDQoNCg0KVm9uOiBjb3JlIFttYWlsdG86 Y29yZS1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBKYWltZSBKaW3DqW5leg0KR2Vz ZW5kZXQ6IE1vbnRhZywgMTEuIEp1bmkgMjAxOCAwNzowMg0KQW46IGNvcmUNCkJldHJlZmY6IFtj b3JlXSDwn5SUIFdHQSBtdWx0aXBhcnQvY29yZQ0KDQpEZWFyIGFsbCwNCg0KYmFzZWQgb24gdGhl IG9uZ29pbmcgZGlzY3Vzc2lvbiBvbiB0aGUgTXVsdGlwYXJ0IENvbnRlbnQtRm9ybWF0IGZvciBD b0FQIGFuZCB0aGUgZGVwZW5kZW5jeSB3aXRoIEFDRSwgd2Ugd2lsbCBpc3N1ZSBhIDIgd2VlayBX b3JraW5nIGdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIHRoaXMgZHJhZnQuDQoNCkNpYW8hDQotIC0g SmFpbWUgSmltw6luZXoNCg0KDQpPbiA4IEp1biAyMDE4LCBhdCAxNi40MSwgQ2Fyc3RlbiBCb3Jt YW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KDQpJIHVwZGF0 ZWQgdGhlIGRyYWZ0IGJhc2VkIG9uIHRoZSBpbnB1dCB3ZSBoYXZlIHNvIGZhciAodGhhbmtzIHRv IGV2ZXJ5b25lIHJlcGx5aW5nISkuDQooSSBhZGRlZCBhbHRlcm5hdGl2ZSB0ZXh0IG1lZGlhLXR5 cGUgbGFiZWxzIGFzIGEgdHJpYWwgYmFsbG9vbjsgd2UgY2FuIGFsd2F5cyByZW1vdmUgdGhlbSBp biB0aGUgV0cgZGlzY3Vzc2lvbi4NCldlIGNhbiBhbHNvIGRlY2lkZSBiZXR3ZWVuIHNpbmdsZS1i eXRlIGFuZCB0d28tYnl0ZSBpZGVudGlmaWVyLikNCg0KTmFtZTogICAgICAgICAgICAgICAgICAg ICAgICBkcmFmdC1mb3NzYXRpLWNvcmUtbXVsdGlwYXJ0LWN0DQpSZXZpc2lvbjogICAgICAgMDUN ClRpdGxlOiAgICAgICAgICAgICBNdWx0aXBhcnQgQ29udGVudC1Gb3JtYXQgZm9yIENvQVANCkh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZm9zc2F0aS1j b3JlLW11bHRpcGFydC1jdC0wNQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1mb3NzYXRpLWNvcmUtbXVsdGlwYXJ0LWN0LTA1DQoNClRoaXMg c2hvdWxkIGJlIHJlYWR5IGZvciB3b3JraW5nLWdyb3VwIGFkb3B0aW9uIGNhbGwgbm93Lg0KDQpH csO8w59lLCBDYXJzdGVuDQoNCg0KUGxlYXNlIGluaXRpYXRlDQoNCg0KT24gSnVuIDcsIDIwMTgs IGF0IDA5OjMzLCBKYWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nvbi5jb208bWFp bHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpUaGFuayB5 b3UgYWxsIGZvciB0aGUgY29uc3RydWN0aXZlIGRpc2N1c3Npb24uIFRvIHN1bW1hcmlzZSBzb21l IG9mIHRoZSByYWlzZWQgcG9pbnRzIHNvIGZhcjoNCg0KLSBEZXBlbmRlbmN5IG9uIEVTVC1DT0FQ LCB3aGljaCBpcyB0YXJnZXRlZCBmb3IgV0dMQyBpbiBuZXh0IElFVEYuDQotIE11bHRpcGFydC9j b3JlIGNhbid0IGJlIHJlZ2lzdGVyZWQuIEFEIHBvaW50ZWQgb3V0IHRoYXQgaXQgaXMgbm90IHBv c3NpYmxlIHRvIHJlZ2lzdGVyICJtdWx0aXBhcnQiIGFzIGEgdG9wLWxldmVsIG1lZGlhIHR5cGUu IEF1dGhvcidzIHByb3Bvc2FsIHRvIHJlbmFtZSBpdCB1bmRlciBhcHBsaWNhdGlvbiAoaS5lLiAt ICJhcHBsaWNhdGlvbi9tdWx0aXBhcnQtY29yZSIpLg0KLSBTaG91bGQgdGhlIGlkZW50aWZpZXIg YmUgYSBzaW5nbGUgYnl0ZSBvciB0d28/DQotIEV4cGVydCBtZWRpYS10eXBlIHJldmlldyBjb25m aXJtYXRpb24gbmVlZGVkLg0KDQpJZiB0aGUgYXV0aG9ycyBjb3VsZCBzdWJtaXQgYSBuZXcgdmVy c2lvbiBzb29uLCBJ4oCZbGwgdHJpZ2dlciB0aGUgV0dBIGNhbGwgc28gdGhhdCB3ZSBoYXZlIGNv bnNlbnN1cyBvbiB0aGUgZHJhZnQgYmVmb3JlIG5leHQgSUVURi4NCg0KQ2lhbyENCi0gLSBKYWlt ZSBKaW3DqW5leg0KDQoNCk9uIDcgSnVuIDIwMTgsIGF0IDEuMTAsIE1pY2hhZWwgUmljaGFyZHNv biA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+PiB3 cm90ZToNCg0KDQpDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emku b3JnPj4gd3JvdGU6DQoNCk9uIEp1biA2LCAyMDE4LCBhdCAxOTo0NywgTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+ IHdyb3RlOg0KDQpUaGUgb25seSBvdGhlciBuYW1lIEkgbWlnaHQgaW1hZ2luZSBpcyBhcHBsaWNh dGlvbi9tdWx0aXBhcnQtY2JvciwgYXMNCnNsaWdodGx5IG1vcmUgZGVzY3JpcHRpdmUsIGJ1dCBp dCdzIGEgYmlrZXNoZWQgcXVlc3Rpb24uDQoNCg0KVGhlcmUgaXMgbm90IHRoYXQgbXVjaCBDQk9S IHRoZXJl4oCmLiAgQnV0IHRoZSBpbnRlcmVzdGluZyBwb2ludCBhYm91dA0KdGhpcyBzcGVjaWZp YyBmb3JtYXQgaXMgbm90IHNvIG11Y2ggdGhlIHJhem9yLXRoaW4gQ0JPUiBlbnZlbG9wZSwgYnV0 DQp0aGF0IHRoaXMgaXMgdXNpbmcgQ29udGVudC1Gb3JtYXQgaWRlbnRpZmllcnMgZnJvbSB0aGUg Q29SRSBQYXJhbWV0ZXJzDQpyZWdpc3RyeSDigJQgaGVuY2UgdGhlIOKAnGNvcmXigJ0gaW4gdGhl IHByb3Bvc2VkIG5hbWUuICBXZSBtYXkgd2FudCB0bw0KDQpUaGF0J3MgYSByZWFzb25hYmxlIGFy Z3VtZW50IGZvciBjYWxsaW5nIGl0IG11bHRpcGFydC1jb3JlLg0KDQotLQ0KXSAgICAgICAgICAg ICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBu ZXR3b3JrcyBbDQpdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29y a3MgICAgICAgIHwgbmV0d29yayBhcmNoaXRlY3QgIFsNCl0gICAgIG1jckBzYW5kZWxtYW4uY2E8 bWFpbHRvOm1jckBzYW5kZWxtYW4uY2E+ICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAg IHwgICBydWJ5IG9uIHJhaWxzICAgIFsNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0 bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3JlDQoNCg0KDQo= --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01FBFEB6DEFTHW99EL4MSXw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnNwc3VwPSJodHRwOi8vbWlj cm9zb2Z0LmNvbS93ZWJzZXJ2aWNlcy9TaGFyZVBvaW50UG9ydGFsU2VydmVyL1VzZXJQcm9maWxl U2VydmljZSIgeG1sbnM6bW1sPSJodHRwOi8vd3d3LnczLm9yZy8xOTk4L01hdGgvTWF0aE1MIiB4 bWxuczpzdD0iJiMxOyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0K PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jv c29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERl ZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIg Mzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6Ik51ciBUZXh0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRh Yi1zcGFuO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5OdXJUZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiTnVyIFRleHQg WmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4 dCI7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MVm9yZm9y bWF0aWVydFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0 aWVydCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl O2xpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgcHJvcG9zYWwgYWxzbyBzb2x2ZXMgYW4gaXNzdWUg d2l0aCBPYnNlcnZlIHdoZW4gYSBjaGFuZ2UgaW4gdGhlIENvbnRlbnQgRm9ybWF0IGlzIG5lZWRl ZCAoZS5nLiwgdG8gc2VuZCBhbiBlcnJvciByZXByZXNlbnRhdGlvbiBpbiB0aGUgZmluYWwgbm90 aWZpY2F0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SXQgYWxzbyBjb250YWlucyB0aGUgZnVuY3Rpb25hbGl0eQ0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1hbm4tY29yZS1tYXli ZS0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1hbm4tY29yZS1tYXli ZS0wMDwvYT4sIHdoaWNoIGlzIGludGVyZXN0aW5nIGZvciBDb0FQIFB1YlN1Yi4gKFdlcmUgdGhl cmUgb3RoZXIgdXNlIGNhc2VzPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIHdhbnQgdG8gJiM0MzsxIGFuIGVhcmxp ZXIgY29tbWVudCBieSBLbGF1czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRm9yIGV2 b2x2YWJpbGl0eSwgd2Ugc2hvdWxkIGFkZCBydWxlcyBmb3IgcHJvY2Vzc2luZyBwYXJ0cyB0aGF0 IGxvb2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaW52YWxp ZCBhdCB0aGUgbW9tZW50LiBJIGNhbiBpbWFnaW5lIHRoZSBuZWVkIGZvciBvdGhlciByZXByZXNl bnRhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBtZXRh ZGF0YSBpbiBhZGRpdGlvbiB0byB0aGUgY29udGVudCBmb3JtYXQgaW4gdGhlIGZ1dHVyZSwgc28g dGhlcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbWlnaHQg YmUgYSBtYXAgaW4gcGxhY2Ugb2YgdGhlIHVpbnQuIEkgd291bGRuJ3Qgd2FudCB0byBibG9hdCB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZm9ybWF0IHJp Z2h0IG5vdywgdGhvdWdoLiBMZXQncyBrZWVwIGl0IHNtYWxsIGFuZCBmb2N1c2VkLCBhbmQgYWxs b3c8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZm9yIGV2b2x2 aW5nIGl0IGxhdGVyIHNob3VsZCB0aGUgbmVlZCBhcmlzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PQ0YsIGZvciBpbnN0YW5jZSwgdXNlcyBhIGN1c3RvbSB2ZXJzaW9uIG9wdGlvbiB0aGF0IG11 c3QgZ28gYWxvbmcgd2l0aCB0aGUgQ29udGVudC1Gb3JtYXQgb3B0aW9uLiBIZW5jZSwgdGhlIG5l ZWQgZm9yIHN1cHBvcnRpbmcgYSBudW1iZXIgb2YgcGF5bG9hZC1kZWZpbmluZyBlbGVtZW50cyBh cHBlYXJzIHZhbGlkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlIG1lbW8gY3VycmVudGx5IG1lbnRpb25zIHRoZSDigJw8L3NwYW4+ Zm9ybWF0IGlkZW50aWZ5aW5nIGVsZW1lbnQgYWx0ZXJuYXRpdmVseSBjYW4gYmUgYSB0ZXh0IHN0 cmluZyBnaXZpbmcgdGhlIG1lZGlhIHR5cGUgbmFtZSBwbHVzIHBvdGVudGlhbGx5IHNvbWUgcGFy YW1ldGVyczxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnS4gVGhpcyBsb29rcyBsaWtlIGEgc2lk ZSBmZWF0dXJlL2hhY2sgdG8gYWRkIHN0cmluZyBzdXBwb3J0IGluIENvQVAuIEhvd2V2ZXIsIHRo aXMgb3BlbnMgdXAgYSBjYW4gb2Ygd29ybXMsIGFzIGl0IGludml0ZXMgdG8gdXNlIHVuZGVmaW5l ZCBuYW1lcyBhbmQgdGhlIHBhcmFtZXRlcnMgd291bGQgbGFjayBwcm9wZXIgZGVmaW5pdGlvbi4g UGFyYW1ldGVycyBzaG91bGQgcmF0aGVyIHVzZSB0aGUgb3B0aW9uIG1lY2hhbmlzbSAocHJvcGVy bHkgZGVmaW5lIGFuIG9wdGlvbiBudW1iZXIpIGFuZCBiZSBwYXNzZWQgdXNpbmcgYSBtYXAgbWVj aGFuaXNtIGFzIHByb3Bvc2VkIGJ5IEtsYXVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3Qgd2lzaGVzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF0dGhpYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlZvbjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGNvcmUgW21haWx0bzpj b3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5JbSBBdWZ0cmFnIHZvbiA8L2I+SmFpbWUgSmltw6lu ZXo8YnI+DQo8Yj5HZXNlbmRldDo8L2I+IE1vbnRhZywgMTEuIEp1bmkgMjAxOCAwNzowMjxicj4N CjxiPkFuOjwvYj4gY29yZTxicj4NCjxiPkJldHJlZmY6PC9iPiBbY29yZV0gPC9zcGFuPjxzcGFu IGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSBTeW1ib2wmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+8J+UlDwvc3Bhbj48c3Bh biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBXR0EgbXVsdGlwYXJ0L2NvcmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJhc2VkIG9uIHRoZSBv bmdvaW5nIGRpc2N1c3Npb24gb24gdGhlJm5ic3A7TXVsdGlwYXJ0IENvbnRlbnQtRm9ybWF0IGZv ciBDb0FQIGFuZCB0aGUgZGVwZW5kZW5jeSB3aXRoIEFDRSwgd2Ugd2lsbCBpc3N1ZSBhIDIgd2Vl ayBXb3JraW5nIGdyb3VwIEFkb3B0aW9uIGNhbGwgZm9yIHRoaXMgZHJhZnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW8hPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPi0gLSBKYWltZSBKaW3DqW5lejxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biA4IEp1biAyMDE4LCBhdCAxNi40MSwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWls dG86Y2Fib0B0emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdXBkYXRlZCB0aGUgZHJhZnQgYmFz ZWQgb24gdGhlIGlucHV0IHdlIGhhdmUgc28gZmFyICh0aGFua3MgdG8gZXZlcnlvbmUgcmVwbHlp bmchKS48YnI+DQooSSBhZGRlZCBhbHRlcm5hdGl2ZSB0ZXh0IG1lZGlhLXR5cGUgbGFiZWxzIGFz IGEgdHJpYWwgYmFsbG9vbjsgd2UgY2FuIGFsd2F5cyByZW1vdmUgdGhlbSBpbiB0aGUgV0cgZGlz Y3Vzc2lvbi48YnI+DQpXZSBjYW4gYWxzbyBkZWNpZGUgYmV0d2VlbiBzaW5nbGUtYnl0ZSBhbmQg dHdvLWJ5dGUgaWRlbnRpZmllci4pPGJyPg0KPGJyPg0KTmFtZTo8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ZHJhZnQtZm9zc2F0aS1j b3JlLW11bHRpcGFydC1jdDxicj4NClJldmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4wNTxicj4NClRp dGxlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5N dWx0aXBhcnQgQ29udGVudC1Gb3JtYXQgZm9yIENvQVA8YnI+DQpIdG1saXplZDogJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWZvc3NhdGktY29yZS1tdWx0aXBhcnQtY3QtMDUiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1mb3NzYXRpLWNvcmUtbXVsdGlwYXJ0LWN0LTA1PC9hPjxicj4N CkRpZmY6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1mb3NzYXRpLWNvcmUtbXVsdGlwYXJ0LWN0LTA1Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtZm9zc2F0aS1jb3JlLW11bHRpcGFydC1jdC0wNTwvYT48YnI+DQo8YnI+ DQpUaGlzIHNob3VsZCBiZSByZWFkeSBmb3Igd29ya2luZy1ncm91cCBhZG9wdGlvbiBjYWxsIG5v dy48YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIGlu aXRpYXRlIDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gSnVuIDcsIDIwMTgsIGF0IDA5OjMzLCBKYWltZSBKaW3DqW5leiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tIj5qYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCkhpLDxicj4NCjxicj4NClRoYW5rIHlv dSBhbGwgZm9yIHRoZSBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbi4gVG8gc3VtbWFyaXNlIHNvbWUg b2YgdGhlIHJhaXNlZCBwb2ludHMgc28gZmFyOjxicj4NCjxicj4NCi0gRGVwZW5kZW5jeSBvbiBF U1QtQ09BUCwgd2hpY2ggaXMgdGFyZ2V0ZWQgZm9yIFdHTEMgaW4gbmV4dCBJRVRGLjxicj4NCi0g TXVsdGlwYXJ0L2NvcmUgY2FuJ3QgYmUgcmVnaXN0ZXJlZC4gQUQgcG9pbnRlZCBvdXQgdGhhdCBp dCBpcyBub3QgcG9zc2libGUgdG8gcmVnaXN0ZXIgJnF1b3Q7bXVsdGlwYXJ0JnF1b3Q7IGFzIGEg dG9wLWxldmVsIG1lZGlhIHR5cGUuIEF1dGhvcidzIHByb3Bvc2FsIHRvIHJlbmFtZSBpdCB1bmRl ciBhcHBsaWNhdGlvbiAoaS5lLiAtICZxdW90O2FwcGxpY2F0aW9uL211bHRpcGFydC1jb3JlJnF1 b3Q7KS48YnI+DQotIFNob3VsZCB0aGUgaWRlbnRpZmllciBiZSBhIHNpbmdsZSBieXRlIG9yIHR3 bz88YnI+DQotIEV4cGVydCBtZWRpYS10eXBlIHJldmlldyBjb25maXJtYXRpb24gbmVlZGVkLjxi cj4NCjxicj4NCklmIHRoZSBhdXRob3JzIGNvdWxkIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIHNvb24s IEnigJlsbCB0cmlnZ2VyIHRoZSBXR0EgY2FsbCBzbyB0aGF0IHdlIGhhdmUgY29uc2Vuc3VzIG9u IHRoZSBkcmFmdCBiZWZvcmUgbmV4dCBJRVRGLjxicj4NCjxicj4NCkNpYW8hPGJyPg0KLSAtIEph aW1lIEppbcOpbmV6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiA3IEp1biAyMDE4LCBhdCAxLjEwLCBNaWNoYWVsIFJpY2hhcmRzb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhIj5tY3ImIzQzO2lldGZA c2FuZGVsbWFuLmNhPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KQ2Fyc3RlbiBCb3Jt YW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gSnVuIDYsIDIwMTgsIGF0IDE5OjQ3LCBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhy ZWY9Im1haWx0bzptY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhIj5tY3ImIzQzO2lldGZAc2FuZGVs bWFuLmNhPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KVGhlIG9ubHkgb3RoZXIgbmFtZSBJIG1p Z2h0IGltYWdpbmUgaXMgYXBwbGljYXRpb24vbXVsdGlwYXJ0LWNib3IsIGFzPGJyPg0Kc2xpZ2h0 bHkgbW9yZSBkZXNjcmlwdGl2ZSwgYnV0IGl0J3MgYSBiaWtlc2hlZCBxdWVzdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgbm90IHRoYXQg bXVjaCBDQk9SIHRoZXJl4oCmLiAmbmJzcDtCdXQgdGhlIGludGVyZXN0aW5nIHBvaW50IGFib3V0 PGJyPg0KdGhpcyBzcGVjaWZpYyBmb3JtYXQgaXMgbm90IHNvIG11Y2ggdGhlIHJhem9yLXRoaW4g Q0JPUiBlbnZlbG9wZSwgYnV0PGJyPg0KdGhhdCB0aGlzIGlzIHVzaW5nIENvbnRlbnQtRm9ybWF0 IGlkZW50aWZpZXJzIGZyb20gdGhlIENvUkUgUGFyYW1ldGVyczxicj4NCnJlZ2lzdHJ5IOKAlCBo ZW5jZSB0aGUg4oCcY29yZeKAnSBpbiB0aGUgcHJvcG9zZWQgbmFtZS4gJm5ic3A7V2UgbWF5IHdh bnQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYXQncyBh IHJlYXNvbmFibGUgYXJndW1lbnQgZm9yIGNhbGxpbmcgaXQgbXVsdGlwYXJ0LWNvcmUuPGJyPg0K PGJyPg0KLS0gPGJyPg0KXSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtOZXZlciB0ZWxsIG1l IHRoZSBvZGRzISAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IGlwdjYg bWVzaCBuZXR3b3JrcyBbIDxicj4NCl0gJm5ic3A7Jm5ic3A7TWljaGFlbCBSaWNoYXJkc29uLCBT YW5kZWxtYW4gU29mdHdhcmUgV29ya3MgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fCBuZXR3b3JrIGFyY2hpdGVjdCAmbmJzcDtbIDxicj4NCl0gJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm1jckBzYW5kZWxtYW4uY2EiPm1jckBzYW5kZWxt YW4uY2E8L2E+ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyI+aHR0cDov L3d3dy5zYW5kZWxtYW4uY2EvPC9hPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8ICZuYnNwOyZuYnNwO3J1Ynkgb24gcmFpbHMgJm5ic3A7Jm5ic3A7Jm5ic3A7Ww0K PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48 YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01FBFEB6DEFTHW99EL4MSXw_-- From nobody Mon Jun 25 03:40:25 2018 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 E31E812D949 for ; Mon, 25 Jun 2018 03:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 R92Rrbaw0bP4 for ; Mon, 25 Jun 2018 03:40:21 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1757126CC7 for ; Mon, 25 Jun 2018 03:40:20 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 70549182251AA; Mon, 25 Jun 2018 10:40:19 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::, RULES_HIT:41:72:152:327:355:379:582:599:800:960:962:967:969:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1616:1712:1730:1776:1792:2108:2194:2198:2199:2200:2528:2553:2559:2562:2638:2693:2741:2894:2900:2901:2907:3138:3139:3140:3141:3142:3165:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4557:5007:6117:6119:6261:6298:6657:6659:6678:7464:7809:7875:7901:7903:7904:7974:8603:9010:9108:9177:10848:11232:11658:11914:12043:12663:12679:12740:12895:13139:13141:13161:13229:13230:13255:13436:13846:13972:14096:14149:21060:21080:21324:21325:21433:21451:21625:21740:21790:30029:30054:30063:30076:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:1:0, LFtime:24, LUA_SUMMARY:none X-HE-Tag: wire21_1fcd317825b21 X-Filterd-Recvd-Size: 24368 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Mon, 25 Jun 2018 10:40:18 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a62ac32136e1dd120ac13aa5ac364679" Date: Mon, 25 Jun 2018 12:40:17 +0200 From: Peter van der Stok To: "Kovatsch, Matthias" Cc: consultancy@vanderstok.org, Jim Schaad , =?UTF-8?Q?=27Christian_Ams=C3=BCss=27?= , core@ietf.org, kerry lynn Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01FBFE71@DEFTHW99EL4MSX.ww902.siemens.net> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01FBFE71@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: <124a1da8773c27f30ec569a4ed2f644b@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.250.16] Archived-At: Subject: Re: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 10:40:25 -0000 --=_a62ac32136e1dd120ac13aa5ac364679 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Matthias, I think much of the confusion comes from the word "domain" that is successfully used for many purposes. In my mind the domain concept in RD (not CoRE specifically) should cater for many purposes. The domain concept in DNS and in RD are fully orthogonal. The domain concept within DNS is motivated by the network topology with its authoritative domain servers. Naming within an installation is done by a network manager. The domain naming within an installation from the point of view of (for example) a building can be done from a functional point of view (e.g. hvac, lighting) or a building structure view (offices, floors) or from tenant point of view (where the domain can be associated with security boundaries). These are a few of the examples I learnt about. The BACnet people warned me to NEVER use the network management domain structure in the RD domain structure as used in the FQDN, because that leads usually to conflicts between organizations. In conclusion: IMO the domain concept in the RD should not be specified to strictly. (you may argue about the term, but domain is a nice word here that covers the purpose). The ins= in RD-DNS-SD is introduced to provide mapping from the RD web service to the DNS services. Be aware the discovery in RD (resources) is more fine grained than in DNS that talks about services that may contain multiple resources. The purpose is that some web services stored in the RD should be visible from Internet with a FQDN, such that you can look at (for example) the temperature in the building without needing access to the RD but by discovering the temperature service with DNS. Please have a look at section 4.1 of RFC6763, where Stuart explains the purpose of the service instance name and how it can be defined. The ins= parameter specifies the instance name that can be used in DNS for a given web service. The idea is that with a definition of ins=DNS-INSTANCE the mapping is complete and the web service, discoverable from RD, is also discoverable from DNS as DNS service. Kerry is still working on getting the mapping complete. I hope this helps a bit, although I am not advocating to get things more strictly defined. Peter Kovatsch, Matthias schreef op 2018-06-22 17:31: > Dear Peter > > I am sorry that I cannot be more active on this issue. I want three things: > > - Avoid terminology conflicts between the two ecosystems (e.g., domain, instance -- not sure if there are more) > - Make sure we have clear definitions of the attributes we use for discovery in CoRE > - Make sure we have the right attributes to cover the known use cases > > For this, I think we need the following: > > - Define new attributes where the definition does not fully match the DNS-SD definition (domain, instance, ...more?). One of the biggest questions seems to be "what is a domain in CoRE?". > > - Get the full picture of what attributes are defined, what they mean, and how we should use them. Without this, it is hard to discuss a good way forward. Could someone prepare a full list with references where they come from (e.g., RFC 6690 etc.)? > > - Model the currently known use cases such as "find any resource of type ("rt") x" (e.g., an RD registration interface) or "find all devices owned by y" (e.g., all endpoints with same "d") or "find my and goes to "find the new URI for the exact resource instance z I was configured with previously" (e.g., an on/off resource of a specific light bulb) with the list of available attributes to identify white spots and unclear definitions. > > Some questions, I have: > > I am now not sure what value/benefit "ins" with the DNS-SD meaning would have in CoRE. What does it mean for a device to be an instance within a DNS domain? Is it a manufacturer-wide unique identifier? Will all IoT installations need their own top-level domain? > > What ways of grouping resources in an RD are envisioned? I assumed we group endpoints by owner (=d --> should have a better fitting name), but maybe we want to group them by sub-system or something. > > Best wishes, > Matthias > > -----Ursprüngliche Nachricht----- > Von: peter van der Stok [mailto:stokcons@xs4all.nl] > Gesendet: Donnerstag, 26. April 2018 11:14 > An: Kovatsch, Matthias (CT RDA IOT EWT-DE) > Cc: consultancy@vanderstok.org; Jim Schaad; 'Christian Amsüss'; core@ietf.org > Betreff: Re: Definition of the ins target attribute - WAS: [core] Endpoint Client Name / Endpoint Name in RD draft > > Hi Matthias, > > On of the confusing aspects is indeed the domain. > Domain is used in two senses: > + d= as a local domain definition within rd to group resources > + domain as used in DNS > > In earlier RD texts a mapping was suggested between d= and the DNS > domain. > That was abandoned because unusable for most building installations as > we know them. > > The mapping may be possible for other installations, but it certainly > cannot be a general rule. > > The RD-DNS-Sd draft does not want to suggest that you need to learn > DNS-SD to do core discovery, > but you have to learn DNS-sd to get the RD to DNSSD mapping right. > ins is an important attribute to select the service type instance needed > for dnssd. > > I am happy to learn how you want to fit ins values into RD discovery. > Possibly you need a new attribute in RD > given that the mapping from RD to DNSSD is not always 1-1. > > Greetings, > > Peter > > Kovatsch, Matthias schreef op 2018-04-25 23:29: Dear all > > My motivation for raising this issue was that I learned that "ins" is > used differently from its (original) purpose. I agree that there is no > special handling of "ins" by RD. Having it in the DNS-SD draft might > shift its meaning or at least perception and definitely visibility. > Writing its own draft for just "ins" is overkill, though. > > "ins" has an important role within CoRE discovery and we should avoid > that people overlook it, because they think they do not need DNS-SD > (and they do not need it for CoRE discovery). So we need to nail down > its definition and probably mention it in multiple drafts (with proper > references). I read the text in core-rd-dns-sd and it is roughly fine, > but sounds a bit like I have to learn DNS-SD to do CoRE discovery. > Also I am not sure about the following statements within the same > section 2.1: > > "SHOULD be unique across resources with the same Resource Type > attribute in the domain it is used." > Is "domain" corresponding to RD's "d" parameter and attribute? > > "This attribute is used by a Resource Directory to distinguish between > multiple instances of the same resource type within the directory" > Here it sounds like it needs to be unique across all resources with > the same Resource Type attribute in the RD. > > Logically and historically, I would have expected that "ins" MUST be > unique across all resources with the same Resource Type attribute in > one device (=ep). I don't know if there is a conflict with DNS-SD > here, so that we cannot define this. Yet a definition to be unique > within "d" seems to aim for application semantics: > > When unique within "ep", a device from the factory could already have > "ins" attributes for its resources, for instance, a weather station > with two temperature sensors, one ins=indoor, one ins=outdoor. > > When unique within "d", someone had to rewrite the "ins" attributes, > so that they match the deployment or application, for instance, > ins="indoor kitchen", ins="indoor lobby", ins="outdoor terrace", > ins="outdoor garage". > > Do we actually have rough consensus on what "ins" actually means and > how it should be used for discovery within CoRE? > (There is a high chance that I just missed that due to being busy with > other stuff...) > > Best wishes, > Matthias > > -----Ursprüngliche Nachricht----- > Von: peter van der Stok [mailto:stokcons@xs4all.nl] > Gesendet: Dienstag, 24. April 2018 11:40 > An: Jim Schaad > Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Christian Amsüss'; > consultancy@vanderstok.org; core@ietf.org > Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft > > Related to this is the proper definition of "ins", which > unfortunately was moved over to the core-rd-dns-sd draft. "ins" is > used to distinguish resources with the same "rt". Originally, it was > used for resource within the same device (e.g., > ;rt=temperature;ins=indoor,;rt=temperature;ins=outdoor). By > now, it often is assumed to require global uniqueness. I claim that > this is not required when "ep" is used correctly. Using a hierarchy > of "d" -> "ep" > -> "ins" > provides more flexibility than making "ins" globally unique. "ins" > can still have a global meaning (cf. indoor vs outdoor), but it > should be re-usable for all resources with similar instance > semantics. Uniqueness is achieved through "d" and "ep". > > I think "ins" should become part of the RD draft again to be defined > together with "d" and "ep", as they are part of a larger discovery > framework. > If "ins" does not need to be handled in a special manner by the RD, > then I would see no reason for it to be part of the RD draft. Both > "ep" and "d" are treated in a special manner as the pair is required > to be globally unique in the RD. This is not a true statement for the > "ins" attribute even in the core-rd-dns-sd draft. > > Jim "Ins" is used to specify the instance name for DNS records necessary for DNS-sd service specification the RD-DNS-SD draft specifies the rules to generate ins values As such it is totally proper that "ins" rules are specified in a separate draft, because "ins" treatment is disconnected from the special treatment specified for "ep" and "d". Matthias, Are you expressing that an additional need exists to distinguish registrations? Peter --=_a62ac32136e1dd120ac13aa5ac364679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Matthias,

I think much of the confusion comes from the word "= domain" that is successfully used for many purposes.
In my mind the do= main concept in RD (not CoRE specifically) should cater for many purposes= =2E
The domain concept in DNS and in RD are fully orthogonal.
The= domain concept within DNS is motivated by the network topology with its au= thoritative domain servers. Naming within an installation is done by a netw= ork manager.
The domain naming within an installation from the point o= f view of (for example) a building can be done from a functional point of v= iew (e.g. hvac, lighting) or a building structure view (offices, floors) or= from  tenant point of view (where the domain can be associated with s= ecurity boundaries). These are a few of the examples I learnt about.
T= he BACnet people warned me to NEVER use the network management domain struc= ture in the RD domain structure as used in the FQDN, because that leads usu= ally to conflicts between organizations.

In conclusion: IMO the = domain concept in the RD should not be specified to strictly. (you may argu= e about the term, but domain is a nice word here that covers the purpose)= =2E

The ins=3D in RD-DNS-SD is introduced to provide mapping fro= m the RD web service to the DNS services.
Be aware the discovery in RD= (resources) is more fine grained than in DNS that talks about services tha= t may contain multiple resources.
The purpose is that some web service= s stored in the RD should be visible from Internet with a FQDN, such that y= ou can look at (for example) the temperature in the building without needin= g access to the RD but by discovering the temperature service with DNS.&nbs= p;

Please have a look at section 4.1 of RFC6763, where Stuart ex= plains the purpose of the service instance name and how it can be defined= =2E
The ins=3D parameter specifies the instance name that can be used = in DNS for a given web service.
The idea is that with a definition of = ins=3DDNS-INSTANCE the mapping is complete and the web service, discoverabl= e from RD, is also discoverable from DNS as DNS service. Kerry is still wor= king on getting the mapping complete.

I hope this helps a bit, a= lthough I am not advocating to get things more strictly defined.

Peter

Kovatsch, Matthias schreef op 2018-06-22 17:31:

= Dear Peter

I am sorry that I cannot be more active on this issu= e. I want three things:

- Avoid terminology conflicts between t= he two ecosystems (e.g., domain, instance -- not sure if there are more) - Make sure we have clear definitions of the attributes we use for disc= overy in CoRE
- Make sure we have the right attributes to cover the k= nown use cases

For this, I think we need the following:
- Define new attributes where the definition does not fully match the = DNS-SD definition (domain, instance, ...more?). One of the biggest question= s seems to be "what is a domain in CoRE?".

- Get the full pictu= re of what attributes are defined, what they mean, and how we should use th= em. Without this, it is hard to discuss a good way forward. Could someone p= repare a full list with references where they come from (e.g., RFC 6690 etc= =2E)?

- Model the currently known use cases such as "find any r= esource of type ("rt") x" (e.g., an RD registration interface) or "find all= devices owned by y" (e.g., all endpoints with same "d") or "find my and go= es to "find the new URI for the exact resource instance z I was configured = with previously" (e.g., an on/off resource of a specific light bulb) with t= he list of available attributes to identify white spots and unclear definit= ions.

Some questions, I have:

I am now not sure wha= t value/benefit "ins" with the DNS-SD meaning would have in CoRE. What does= it mean for a device to be an instance within a DNS domain? Is it a manufa= cturer-wide unique identifier? Will all IoT installations need their own to= p-level domain?

What ways of grouping resources in an RD are en= visioned? I assumed we group endpoints by owner (=3Dd --> should have a = better fitting name), but maybe we want to group them by sub-system or some= thing.

Best wishes,
Matthias

-----Ursprüngliche Nachricht-----
Von: pete= r van der Stok [mailto:stokcons@xs4all.nl]
Gesendet: Donnerstag, 26. April 2018 11:= 14
An: Kovatsch, Matthias (CT RDA IOT EWT-DE)
Cc: consultancy@vanderstok= =2Eorg; Jim Schaad; 'Christian Amsüss'; core@ietf.org
Betreff: Re: Definition o= f the ins target attribute - WAS: [core] Endpoint Client Name / Endpoint Na= me in RD draft

Hi Matthias,

On of the confusing asp= ects is indeed the domain.
Domain is used in two senses:
+ d=3D= as a local domain definition within rd to group resources
+ domain a= s used in DNS

In earlier RD texts a mapping was suggested betwe= en d=3D and the DNS
domain.
That was abandoned because unusable= for most building installations as
we know them.

The map= ping may be possible for other installations, but it certainly
cannot= be a general rule.

The RD-DNS-Sd draft does not want to sugges= t that you need to learn
DNS-SD to do core discovery,
but you h= ave to learn DNS-sd to get the RD to DNSSD mapping right.
ins is an i= mportant attribute to select the service type instance needed
for dns= sd.

I am happy to learn how you want to fit ins values into RD = discovery.
Possibly you need a new attribute in RD
given that t= he mapping from RD to DNSSD is not always 1-1.

Greetings,
=
Peter

Kovatsch, Matthias schreef op 2018-04-25 23:29:
Dear all

My motivation for raising this is= sue was that I learned that "ins" is
used differently from its (origi= nal) purpose. I agree that there is no
special handling of "ins" by R= D. Having it in the DNS-SD draft might
shift its meaning or at least = perception and definitely visibility.
Writing its own draft for just = "ins" is overkill, though.


"ins" has an important role wi= thin CoRE discovery and we should avoid
that people overlook it, beca= use they think they do not need DNS-SD
(and they do not need it for C= oRE discovery). So we need to nail down
its definition and probably m= ention it in multiple drafts (with proper
references). I read the tex= t in core-rd-dns-sd and it is roughly fine,
but sounds a bit like I h= ave to learn DNS-SD to do CoRE discovery.
Also I am not sure about th= e following statements within the same
section 2.1:

"SHOULD be unique across resources with the same Resou= rce Type
attribute in the domain it is used."

Is "domain" corresponding to RD's "d" parameter and attribute?
=
"This attribute is used by a Resource Directory to dis= tinguish between
multiple instances of the same resource type within = the directory"

Here it sounds like it needs to be unique across all resources with<= br /> the same Resource Type attribute in the RD.


Logical= ly and historically, I would have expected that "ins" MUST be
unique = across all resources with the same Resource Type attribute in
one dev= ice (=3Dep). I don't know if there is a conflict with DNS-SD
here, so= that we cannot define this. Yet a definition to be unique
within "d"= seems to aim for application semantics:

When unique within "ep= ", a device from the factory could already have
"ins" attributes for = its resources, for instance, a weather station
with two temperature s= ensors, one ins=3Dindoor, one ins=3Doutdoor.

When unique within= "d", someone had to rewrite the "ins" attributes,
so that they match= the deployment or application, for instance,
ins=3D"indoor kitchen",= ins=3D"indoor lobby", ins=3D"outdoor terrace",
ins=3D"outdoor garage= ".


Do we actually have rough consensus on what "ins" actu= ally means and
how it should be used for discovery within CoRE?
= (There is a high chance that I just missed that due to being busy with
other stuff...)


Best wishes,
Matthias


-----Ursprüngliche Nachricht-----
Von: pete= r van der Stok [mailto:stokcons@xs4all.nl]
Gesendet: Dienstag, 24. April 2018 11:40=
An: Jim Schaad
Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Ch= ristian Amsüss';
consultancy@vanderstok.org; core@ietf.org
Betreff: Re: [core] Endpo= int Client Name / Endpoint Name in RD draft



Related to this is the proper definition of "in= s", which
unfortunately was moved over to the core-rd-dns-sd draft. "= ins" is
used to distinguish resources with the same "rt". Originally,= it was
used for resource within the same device (e.g.,
</t1= >;rt=3Dtemperature;ins=3Dindoor,</t2>;rt=3Dtemperature;ins=3Doutdo= or). By
now, it often is assumed to require global uniqueness. I clai= m that
this is not required when "ep" is used correctly. Using a hier= archy
of "d" -> "ep"
-> "ins"
provides more flexibi= lity than making "ins" globally unique. "ins"
can still have a global= meaning (cf. indoor vs outdoor), but it
should be re-usable for all = resources with similar instance
semantics. Uniqueness is achieved thr= ough "d" and "ep".

I think "ins" should become part of the RD d= raft again to be defined
together with "d" and "ep", as they are part= of a larger discovery
framework.

If "ins" does not need to be handled in a special manner by the RD,<= br /> then I would see no reason for it to be part of the RD draft.  B= oth
"ep" and "d" are treated in a special manner as the pair is requi= red
to be globally unique in the RD.  This is not a true stateme= nt for the
"ins" attribute even in the core-rd-dns-sd draft.
Jim

"Ins" is used to specify the instance name for DNS records necessary
= for DNS-sd service specification the RD-DNS-SD draft specifies
the ru= les to generate ins values As such it is totally proper that
"ins" ru= les are specified in a separate draft, because "ins" treatment
is
disconnected from the special treatment specified for "ep" and "d".

Matthias, Are you expressing that an additional need exists to
distinguish registrations?

Peter
--=_a62ac32136e1dd120ac13aa5ac364679-- From nobody Mon Jun 25 04:44:16 2018 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 1F08F130DD1 for ; Mon, 25 Jun 2018 04:44:14 -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 O6SQ0-1eeFhw for ; Mon, 25 Jun 2018 04:44:12 -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 BF207130DC3 for ; Mon, 25 Jun 2018 04:44:11 -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 w5PBi7Q7005631; Mon, 25 Jun 2018 13:44:07 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (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 41DnPz3q0zzDXvF; Mon, 25 Jun 2018 13:44:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <124a1da8773c27f30ec569a4ed2f644b@bbhmail.nl> Date: Mon, 25 Jun 2018 13:44:06 +0200 Cc: "Kovatsch, Matthias" , =?utf-8?Q?Christian_Ams=C3=BCss?= , core@ietf.org X-Mao-Original-Outgoing-Id: 551619844.963387-c32715e375dcbfc90fea6dec9e11c0b9 Content-Transfer-Encoding: quoted-printable Message-Id: <6E4289F4-6C4A-4A1C-B640-3FE63CF1E47D@tzi.org> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01FBFE71@DEFTHW99EL4MSX.ww902.siemens.net> <124a1da8773c27f30ec569a4ed2f644b@bbhmail.nl> To: peter van der Stok X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 11:44:15 -0000 On Jun 25, 2018, at 12:40, Peter van der Stok = wrote: >=20 > The domain concept in DNS and in RD are fully orthogonal. That is a source of confusion. Since most people who learn networking learn what a =E2=80=9Cdomain=E2=80=9D= is (in the DNS sense), we are probably better off not re-using that = term for something else. Field, sector, sphere, branch, bailiwick, scope, range, area, =E2=80=A6 We can continue to use the letter =E2=80=9Cd=E2=80=9D to refer to that, = if that eases concerns about existing implementations. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 25 04:48:47 2018 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 62799130DD1 for ; Mon, 25 Jun 2018 04:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 JOvHi7r0rybd for ; Mon, 25 Jun 2018 04:48:41 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4307012F1A2 for ; Mon, 25 Jun 2018 04:48:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BED46400E9; Mon, 25 Jun 2018 13:48:37 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A43DB6F; Mon, 25 Jun 2018 13:48:36 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::b44]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 47EAB1F; Mon, 25 Jun 2018 13:48:36 +0200 (CEST) Received: (nullmailer pid 24383 invoked by uid 1000); Mon, 25 Jun 2018 11:48:35 -0000 Date: Mon, 25 Jun 2018 13:48:35 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: peter van der Stok , "Kovatsch, Matthias" , core@ietf.org Message-ID: <20180625114834.GJ8858@hephaistos.amsuess.com> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01FBFE71@DEFTHW99EL4MSX.ww902.siemens.net> <124a1da8773c27f30ec569a4ed2f644b@bbhmail.nl> <6E4289F4-6C4A-4A1C-B640-3FE63CF1E47D@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D6z0c4W1rkZNF4Vu" Content-Disposition: inline In-Reply-To: <6E4289F4-6C4A-4A1C-B640-3FE63CF1E47D@tzi.org> User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 11:48:45 -0000 --D6z0c4W1rkZNF4Vu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 25, 2018 at 01:44:06PM +0200, Carsten Bormann wrote: > Since most people who learn networking learn what a =E2=80=9Cdomain=E2=80= =9D is (in > the DNS sense), we are probably better off not re-using that term for > something else. >=20 > Field, sector, sphere, branch, bailiwick, scope, range, area, =E2=80=A6 >=20 > We can continue to use the letter =E2=80=9Cd=E2=80=9D to refer to that, i= f that eases > concerns about existing implementations. Given this and other naming confusions ([138], current Context definition), would now be the right time to, without modification to any of the mechanisms, pick good names for or backronym all the concepts we now understand? Christian [138]: https://github.com/core-wg/resource-directory/pull/138 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --D6z0c4W1rkZNF4Vu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlsw1o4ACgkQOY0REtOk veEqOQ/+Npjh0pZAdO13fkDh7W6wI/QWjq/SSmuPQPrVGrV7bllOmAEt3wX0S3rU j7qC3lS5wvuxJWhLBWI1GWAcjZWmmYWNQ3hK4pcnHU3QZHH+pAch8a/dADkhqeon DaWqRos4KEWveiX1MSYpYLDEhekwnyThPk4ah0ZEfDBshA7KggNjbm4SCdttfUMc EJ5gi2vG6s2j1lh+3+bS/LmZlFwCA9lmlWgPgGc/ipKDGOxYfOGMplkSdMNdnkOl ACrjkZlgRYwBD4rVGq93g3TCtT7nfj8rt8424tEl/6/Od4yflLy9pMjrfTuSz1Q/ 45UaebkjFan6Z69mwROe8zhlfF7T8X8anNc/nG7Ybw/yamluaVl/ZbcpXZifvFAp xZ8jsMjvcGKKbMNQjZ+GQCPGN+FvlTKWdmrLrf0/fGPSFTwd2mAznPeOz6tZvlhk 6bjl/se3WN03xcZE98ePCIoRhRg3u1gLebIaaFY5EXjN270qEmvWd6ljas92npTJ QoQiQ4C3QpvC4NrWR+bvBeSIU5CPb75sk4iWFExlKDxA3gaFIQZ99rY6uC34fhgX H4WfXVGST9mPCdbRqnY3cl2eWGFPgOHEqr2EN8/EGaGyKAsbKJoR0bqXUkSxqVp2 COP7ovzPh4KRjY4zebIUFL+20FyIu5qQccGhJAlAeJDqRA/JN6k= =wfge -----END PGP SIGNATURE----- --D6z0c4W1rkZNF4Vu-- From nobody Mon Jun 25 05:11:01 2018 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 0CA0B1294D7 for ; Mon, 25 Jun 2018 05:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ZAYe_KNl3YYY for ; Mon, 25 Jun 2018 05:10:57 -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 A037B130DD1 for ; Mon, 25 Jun 2018 05:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529928654; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TjmJi+P09J8yD8IDOXNsFVYm2+trRLthduHmorLVwVo=; b=hcU8fwHHQ0aWXaEdR4TdUqAW7LSGNHt8epCK/8iHUelxET2enc+M+ovna8NgrEsU Z3JE60IEeDXSY7BxD6gdQG4ndqd+XJIYL+BxAgujTbLRNBMkY/5ZqxmdRwH6bp7n w801EgLAfCdLho3v3PbB75X5wzqpIA2IiXvulZM69ng=; X-AuditID: c1b4fb3a-dcb6e9c0000079c1-1f-5b30dbce14df Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 49.B0.31169.ECBD03B5; Mon, 25 Jun 2018 14:10:54 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 25 Jun 2018 14:10:53 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 25 Jun 2018 14:10:53 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dBIG11bHRpcGFydC9jb3JlIA==?= Thread-Index: AQHUAUF5ljDQ/C/RQ0eaRRY4jMiAJKRw1xUA Date: Mon, 25 Jun 2018 12:10:53 +0000 Message-ID: <5EDDEB02-6CDA-4F09-AB4F-60737441921B@ericsson.com> References: <20273.1527881373@localhost> <5727.1528220965@localhost> <4AEB441B-CCE5-49B7-8F42-4D0BC8381BA3@ericsson.com> <1677921f-3c58-9aa4-747f-89b6a4297f52@isode.com> <24375.1528307244@localhost> <2F2ED8C8-DE45-4187-98C9-3DF56F3C2081@tzi.org> <25717.1528323050@localhost> <091EBB63-2719-450F-8403-DCF48DB941D5@ericsson.com> <5B899963-0BB1-4D95-9762-3C6E105C2FDB@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/signed; boundary="Apple-Mail=_926567CB-4B67-4E40-B1E5-A636D1C0D70E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUyM2J7he652wbRBjt2W1rse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGUuX/2EtOGBVMWPWH8YGxg/mXYwcHBICJhKXz5d0MXJxCAkc ZZToWHqUCcL5xijRdH03I4SzjFHixNP1QA4nB5uAs8SnZ43sILaIgIRE59f9YLawgKvEvon9 bBBxN4lz05qgbCOJrm3tYDUsAqoSPWv7WEFsXgF7iZ6Dr1kgFrSzSZxe9wcswSngIPFo8kNm EJtRQEzi+6k1TCA2s4C4xK0n88FsCQERiYcXT7NB2KISLx//Y4WwlST2HrsONpRZYAqjxLUp LVDbBCVOznzCMoFRZBaSWbOQ1c1CUgdRlCTxZcEyKFtbYtnC18wQtqbE/u7lWMQ1JDq/TWSF sE0lXh/9yAhhW0vM+HWQDcJWlJjS/ZB9ASP3KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzA WD245bfVDsaDzx0PMQpwMCrx8KpdMIgWYk0sK67MPcSoAjTn0YbVFxilWPLy81KVRHjt9gOl eVMSK6tSi/Lji0pzUosPMUpzsCiJ8zqlWUQJCaQnlqRmp6YWpBbBZJk4OKUaGGU2ah300Wk3 fTnlaqmiisGbaRey1Pe+zz5nrGd3wPwHz7tTDyqfLJ15o4ErbeJTY3a7Uv7JQZ8MrZQTX77L /Tczzexx0bbX3RWv418s3PPJqmC399qyLE3/6XpXxEqj+8UW6XqnJ116aNr6Lf7FnZUne168 L93LsDj3gtkU7py0z3/+Gbu9tFRiKc5INNRiLipOBABIKzOR3QIAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGA_multipart/core?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 12:10:59 -0000 --Apple-Mail=_926567CB-4B67-4E40-B1E5-A636D1C0D70E Content-Type: multipart/alternative; boundary="Apple-Mail=_ADFEBF03-2FF5-47D5-8194-0A84D9D87763" --Apple-Mail=_ADFEBF03-2FF5-47D5-8194-0A84D9D87763 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, seems that there is consensus to adopt the draft on "Multipart = Content-Format for CoAP" https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 = =20 The authors should submit a new version under draft-ietf.=20 Thank you all! - - Jaime Jim=C3=A9nez --Apple-Mail=_ADFEBF03-2FF5-47D5-8194-0A84D9D87763 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all,

seems that = there is consensus to adopt the draft on "Multipart Content-Format for = CoAP"
https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05<= /a>
 
The authors should = submit a new version under draft-ietf. 

Thank you all!
- - = Jaime Jim=C3=A9nez

= --Apple-Mail=_ADFEBF03-2FF5-47D5-8194-0A84D9D87763-- --Apple-Mail=_926567CB-4B67-4E40-B1E5-A636D1C0D70E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDYyNTEyMTA1M1owIwYJKoZIhvcNAQkEMRYEFArMqbnzdCioLIX5Ni9VVnpoW6KI MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAIHyLWjZEzkFZgOZFOA8RPEFpWz8/8odjxBEHHvzi5VtX3C5DgUFlEbgIoBvJ5SFh hCVSy9fW8V+IZlE+0CcHzL+EEXu2ST6Uk8wob5Kc6bEeGh5yPUtxUkxZO2ZuZ5KzrxlHyF6nVC5+ h/e/hmQtYooHYEYHTqrpvGZeO+5VNT7+Pg3ab4CDjcZZl3P3xaiLT5Ha0xUpRmMJ0ZIYaqoINP/t nkA5ZgjOjZpdTzftAsGuNoRlEvMciGzWbP0UOO7yJDxqiw/6DcDdS/+q8Bbnyg2Vu0ZCw9szXwbt QMiUOSF4k99Lnas6Nd9x0OSuAQ9bL8ya7Yja/FBQySpwCNc+GQAAAAAAAA== --Apple-Mail=_926567CB-4B67-4E40-B1E5-A636D1C0D70E-- From nobody Mon Jun 25 07:18:00 2018 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 ED331130EA7; Mon, 25 Jun 2018 07:17:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152993627791.6344.14623651233108416849@ietfa.amsl.com> Date: Mon, 25 Jun 2018 07:17:57 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-multipart-ct-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 14:17:59 -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 WG of the IETF. Title : Multipart Content-Format for CoAP Authors : Thomas Fossati Klaus Hartke Carsten Bormann Filename : draft-ietf-core-multipart-ct-00.txt Pages : 6 Date : 2018-06-25 Abstract: This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of several different media types into a single CoAP message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-multipart-ct-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-multipart-ct-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 25 10:44:18 2018 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 6284B130E13 for ; Mon, 25 Jun 2018 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 E5FP5Q613mR6 for ; Mon, 25 Jun 2018 10:44:14 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C32130E12 for ; Mon, 25 Jun 2018 10:44:13 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3BB6B400E9 for ; Mon, 25 Jun 2018 19:44:12 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4B3006F for ; Mon, 25 Jun 2018 19:44:10 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::b44]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0E44773 for ; Mon, 25 Jun 2018 19:44:10 +0200 (CEST) Received: (nullmailer pid 6820 invoked by uid 1000); Mon, 25 Jun 2018 17:44:09 -0000 Date: Mon, 25 Jun 2018 19:44:09 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: <20180625174409.GB19915@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: [core] Renaming two Resource Directory parameters X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 17:44:17 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE WG, considering the feedback we got on the last Resource Directory draft, we are about to rename two parameters that have been repeated cause of confusion; while that's a moderate of a stir-up now, it should result in a final document that is easier to understand: * Context ("con") will become called the Base URI of a Registration ("base"). * The Domains ("d") in an RD will be called Sectors, and keep the parameter short name "d". To the best of our knowledge, some of the existing deployments already use "d", but "con" has not been used in a way that can not be changed easily any more. If we are in error about that (or have other comments on that topic), please let us know until Wednesday, so we can publish a -14 version of the draft in due time. Best regards Christian on behalf of the RD authors --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --K8nIJk4ghYZn606h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlsxKeUACgkQOY0REtOk veEB/xAA0kA0v4C4hNs9P18DNupzef6qpS/0NE2UyqkP4tvnBqzVeNoyBCqPJ2Qc nlTXHgTGNucVXgYIax8Gtd57XQtn0+LFmRXZCpKaau2RVpzWjPBO9zy1e0qjawGy B8PuDvn48hQTUPE0Zd7Ow1JVcWnVLGjsuxQev79kO0Lai/lXt9gQkOWR3nWWpvT9 PDRZ5eswskeLyUjjQbQ//NzHZqhp9JBHnLvzCYrttLJa9KvMc+iSR+Xox9FWycjj 2Tq4JlsSwzSADCe/6o0gS/PhvFx9dLmanatuW5MNv7r3C6jsOM19v4ICxNtN7t7e hwkjxWgV8ACQdXtosGpGLlRIzXQF2WEt1hsjRMi2tAT+e21fomqt+JqBPwhE9GA4 fdEzVGk1oU3lSQkqoa7XHoGSiYXZ02KJMoLLpfvSV0oz2I9fPPQOd6KLZxbO9wu1 FxsBdFYxvc5X9OMSk3uvdyZO/ns2y6w/7w3sdUPEtN2nMm68lDKw6ouGpTICB4O6 c8jQFiS09cJv5FUSJHZoMXSnmOJjGRc8zW2AZLl4SEqUfLI6ZNoOrEceobh+g+kr 7LnJoNRa336HjSAyMkItVLk5u9LPJiZyfyyjGpbvwCCDoO/XG8obc5mtZxULDKcc 3he53+3kCXVOCv4gZfZdx7QTe6Nil2yqF6/CGDsmBqbKrfVbHWk= =1kb/ -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From nobody Tue Jun 26 16:50:44 2018 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 2C08F130E6E; Tue, 26 Jun 2018 16:50:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153005703715.18790.5161389875353700660@ietfa.amsl.com> Date: Tue, 26 Jun 2018 16:50:37 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-interfaces-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:50:37 -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 WG of the IETF. Title : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Michael Koster Christian Groves Jintao Zhu Bilhanan Silverajan Filename : draft-ietf-core-interfaces-12.txt Pages : 25 Date : 2018-06-26 Abstract: This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Parameter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines an Interface Description attribute value to describe resources conforming to a particular interface. Editor's notes: o The git repository for the draft is found at https://github.com/ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-12 https://datatracker.ietf.org/doc/html/draft-ietf-core-interfaces-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-12 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 Jun 27 06:16:34 2018 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 5974D1277C8; Wed, 27 Jun 2018 06:16:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153010539031.15390.2733996767687970097@ietfa.amsl.com> Date: Wed, 27 Jun 2018 06:16:30 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 13:16:31 -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 WG of the IETF. Title : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-13.txt Pages : 78 Date : 2018-06-27 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-13 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-13 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 Jun 27 06:21:24 2018 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 88B8412D949 for ; Wed, 27 Jun 2018 06:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z0w0W4uKHZnA for ; Wed, 27 Jun 2018 06:21:20 -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 73D661277C8 for ; Wed, 27 Jun 2018 06:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530105678; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5177mEi7EXT07GjhYp9ibHhnDvzqqNVjP6zpCUUfcVE=; b=UPDS4O2M+8lsHbbXNejviaA/tEjP8z+iNwiYYmXZ03fbSqz9Di3WWc28442lLv8J c5fWUDo9HmL7nm61U4zayWpyGNB+c4/0ulYoFOq6AZ/ndI2vhvYPJ+omYFTmgiLd 5OtT9hGpkNqXNKUISSJrldk1cuR4UVwqfIDRrwN+VUY=; X-AuditID: c1b4fb30-93dff70000000a77-bd-5b338f4ed6d0 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C3.B0.02679.E4F833B5; Wed, 27 Jun 2018 15:21:18 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Jun 2018 15:21:18 +0200 Received: from ESESSMB504.ericsson.se ([153.88.183.192]) by ESESSMB504.ericsson.se ([153.88.183.192]) with mapi id 15.01.1466.003; Wed, 27 Jun 2018 15:21:18 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-object-security-13.txt Thread-Index: AQHUDhkYa6UWoLuxpUK3W5XgBcSvgqR0F0IA Date: Wed, 27 Jun 2018 13:21:18 +0000 Message-ID: References: <153010539031.15390.2733996767687970097@ietfa.amsl.com> In-Reply-To: <153010539031.15390.2733996767687970097@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: <6E7BBB92CA3D294BB80D26542CBB084F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbG9Utev3zjaoG2ZgsW+t+uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWD7PMaCDVoVs/tMGxiXaHYxcnBICJhIvLxf38XIxSEkcJRR YuuFXyxdjJxAzjdGicWT6yDsZYwSjfMyQGw2AReJBw2PmEBsEQFlic1nXjOC2MICbhL77+9h 62JkB4q7SzTUgEwXETCSuH+gDMRkEVCV2PrVCaSWV8BC4v+kr6wQs50l7lw5BjaDE2j2+Vff wPYzCohJfD+1BmwPs4C4xK0n88FsCQEBiSV7zjND2KISLx//A5sjKqAnsbennQ0iriSxpXcL E8haZgFNifW79CHGWEvs+n6SDcJWlJjS/ZAd4hxBiZMzn7BMYBSfhWTbLITuWUi6ZyHpnoWk ewEj6ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwFg6uOW3wQ7Gl88dDzEKcDAq8fD+6TGO FmJNLCuuzD3EKMHBrCTCa5kGFOJNSaysSi3Kjy8qzUktPsQozcGiJM5r4bc5SkggPbEkNTs1 tSC1CCbLxMEp1cC4LjNF5HhmRmZq08xfmy34l81tnvna2NO591238JPMz7KZOb7PL+XPVbVN c/ab/aepNWgvX7eBfmVoGqNzYtTihdpb2c//Ytda3Z+7dEe4TzY394UE4Z0390gESU8olROY /XJ74WWTrDVXAwrMY9f9C/rewW7513veW2uPx2/Ufr3Yt71gV4wSS3FGoqEWc1FxIgBQTjSu oQIAAA== Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-object-security-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 27 Jun 2018 13:21:23 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgT1NDT1JFLiBP bmUgb2YgdGhlIHJldmlldyBjb21tZW50cyBmcm9tDQpJRVNHIHdhcyB0byBwcm92aWRlIG1vcmUg ZGV0YWlscyBvZiB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyB0byBzaW1wbGlmeQ0KdGhlIHJldmll dy4gVGhlIGJhc2ljIGNvbnRlbnQgZm9yIHRoaXMgd2FzIGFscmVhZHkgaW4gdmVyc2lvbiAtMTIs IGJ1dCBpbg0KdGhlIHByb2Nlc3Mgb2YgY29tcGxldGluZyB0aGlzIGV4ZXJjaXNlLCB3ZSB3ZW50 IGJhY2sgdG8gdGhlIGFzc3VtcHRpb25zDQptYWRlIG9uIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSBD b0FQIG9wdGlvbnMgYW5kIG1hZGUgc29tZSByZWFzc2Vzc21lbnRzIGFzDQppcyBkZXNjcmliZWQg YmVsb3cuIFRoaXMgd29yayBpbnZvbHZlZCB0aGUgYXV0aG9ycywgc29tZSBvbGQgYW5kIG5ldw0K aW1wbGVtZW50b3JzLiBNZWFud2hpbGUgd2UgYWxzbyByZWNlaXZlZCBmdXJ0aGVyIHJldmlld3Mg d2hpY2ggd2VyZQ0KaW50ZWdyYXRlZCBpbiB0aGlzIHZlcnNpb24uDQoNClRoZSBmb2xsb3dpbmcg Y2hhbmdlcyB3ZXJlIG1hZGUgdG8gdGhlIG9wdGlvbnM6DQoNCiogT2JzZXJ2ZSBpcyBub3cgYWRk aXRpb25hbGx5IElubmVyLCB3aGljaCBlbmFibGVzIHRoZSBlbmRwb2ludHMgdG8gdmVyaWZ5DQpl YWNoIG90aGVycyBpbnRlbnQgYW5kIHNpbXBsaWZpZXMgdGhlIHByb2Nlc3NpbmcgYXQgdGhlIGNv c3Qgb2YgbWFraW5nDQpzb21lIG9mIHRoZSBwcm94eSBwcm9jZXNzaW5nIG91dCBvZiBzY29wZS4g VGhpcyByZXN1bHRlZCBpbiBhIGNoYW5nZSBvZg0KT2JzZXJ2ZSBwcm9jZXNzaW5nIGFuZCB3ZSB0 aGVuIHRvb2sgdGhlIG9wcG9ydHVuaXR5IHRvIHNwbGl0IG91dA0Kb3B0aW9uLXNwZWNpZmljIHBy b2Nlc3Npbmcgd2hpY2ggc2ltcGxpZmllZCB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KKiBOby1SZXNw b25zZSBpcyBub3cgZXNzZW50aWFsbHkgSW5uZXIsIGkuZS4gcHJvdGVjdGVkIGVuZC10by1lbmQs DQpyZXN1bHRpbmcgZnJvbSBhIHJldmlldyBmcm9tIEppbSBTY2hhYWQuIFRoZSBwcm9jZXNzaW5n IGlzIHJld3JpdHRlbg0KYWNjb3JkaW5nbHkuDQoNCiogVXJpLUhvc3QvUG9ydCBwcm9jZXNzaW5n IGlzIGNsYXJpZmllZCBpbiBhIHNlcGFyYXRlIHN1YnNlY3Rpb24uDQoNCkEgY29ycmVzcG9uZGlu ZyBjaGFuZ2Ugb2YgdGhlIGFuYWx5c2lzIG9mIHVucHJvdGVjdGVkIGhlYWRlciBmaWVsZHMgd2Fz DQptYWRlIGluIGFwcGVuZGl4IEQuDQoNCldlIGFsc28gZGlkIHRoZSBmb2xsb3dpbmcgdXBkYXRl czoNCg0KKiBIVFRQIHByb2Nlc3NpbmcgdXBkYXRlZCBiYXNlZCBvbiBjb21tZW50cyBmcm9tIE1h cnRpbiBUaG9tc29uLg0KDQoqIENvQVAtdG8tQ29BUCBGb3J3YXJkaW5nIFByb3h5IGRlc2NyaXB0 aW9uIGlzIGV4cGFuZGVkLg0KDQoqIElEIENvbnRleHQgYWRkZWQgdG8gdGhlIHNlY3VyaXR5IGNv bnRleHQuIFRoZSBtZXNzYWdlIGZvcm1hdCBhbHJlYWR5DQpjb250YWluZWQgdGhlIENPU0UgaGVh ZGVyIHBhcmFtZXRlciAna2lkIGNvbnRleHQnLCBhbmQgdGhpcyBpcyBub3cNCmRlZGljYXRlZCBm b3IgdHJhbnNwb3J0aW5nIHRoZSBJRCBDb250ZXh0LiBTdWNoIGEgcGFyYW1ldGVyIHdhcyBhbHJl YWR5IGluDQp1c2UgYnkgR3JvdXAgT1NDT1JFIGFuZCA2dGlzY2ggTWluaW1hbCBTZWN1cml0eSBh bmQgdGhleSBjYW4gbm93IGFwcGx5DQp0aGlzIGluIGEgY29tbW9uIHdheS4NCg0KKiBVcGRhdGVk IGRlcGxveW1lbnQgZXhhbXBsZXMgYW5kIHRlc3QgdmVjdG9ycyAoYXBwZW5kaWNlcyBCIGFuZCBD KQ0KDQoqIFVwZGF0ZWQgcmVmZXJlbmNlcw0KDQoNCkJlc3QgcmVnYXJkcywNCkfDtnJhbg0KDQoN Cg0KT24gMjAxOC0wNi0yNywgMTU6MTYsICJjb3JlIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciDQo8Y29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMu DQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uc3RyYWluZWQgUkVTVGZ1bCBF bnZpcm9ubWVudHMgV0cgb2YNCj50aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAg ICA6IE9iamVjdCBTZWN1cml0eSBmb3IgQ29uc3RyYWluZWQgUkVTVGZ1bA0KPkVudmlyb25tZW50 cyAoT1NDT1JFKQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogR8O2cmFuIFNlbGFuZGVyDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIE1hdHRzc29uDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICBGcmFuY2VzY2EgUGFsb21iaW5pDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICBMdWR3aWcgU2VpdHoNCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jb3JlLW9iamVj dC1zZWN1cml0eS0xMy50eHQNCj4JUGFnZXMgICAgICAgICAgIDogNzgNCj4JRGF0ZSAgICAgICAg ICAgIDogMjAxOC0wNi0yNw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0cmFpbmVkIFJFU1RmdWwNCj4gICBFbnZpcm9ubWVu dHMgKE9TQ09SRSksIGEgbWV0aG9kIGZvciBhcHBsaWNhdGlvbi1sYXllciBwcm90ZWN0aW9uIG9m DQo+ICAgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSwgdXNpbmcg Q0JPUiBPYmplY3QNCj4gICBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKS4gIE9TQ09SRSBw cm92aWRlcyBlbmQtdG8tZW5kIHByb3RlY3Rpb24NCj4gICBiZXR3ZWVuIGVuZHBvaW50cyBjb21t dW5pY2F0aW5nIHVzaW5nIENvQVAgb3IgQ29BUC1tYXBwYWJsZSBIVFRQLg0KPiAgIE9TQ09SRSBp cyBkZXNpZ25lZCBmb3IgY29uc3RyYWluZWQgbm9kZXMgYW5kIG5ldHdvcmtzIHN1cHBvcnRpbmcg YQ0KPiAgIHJhbmdlIG9mIHByb3h5IG9wZXJhdGlvbnMsIGluY2x1ZGluZyB0cmFuc2xhdGlvbiBi ZXR3ZWVuIGRpZmZlcmVudA0KPiAgIHRyYW5zcG9ydCBwcm90b2NvbHMuDQo+DQo+DQo+VGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS8N Cj4NCj5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkt MTMNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtY29y ZS1vYmplY3Qtc2VjdXJpdHktMTMNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTMNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1p c3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Y29yZSBtYWlsaW5nIGxpc3QNCj5jb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Thu Jun 28 05:09:41 2018 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 199BD131050; Thu, 28 Jun 2018 05:09:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153018776804.14946.153717582745038555@ietfa.amsl.com> Date: Thu, 28 Jun 2018 05:09:28 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 12:09: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 WG of the IETF. Title : Secure group communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini Jiye Park Filename : draft-ietf-core-oscore-groupcomm-02.txt Pages : 34 Date : 2018-06-28 Abstract: This document describes a mode for protecting group communication over the Constrained Application Protocol (CoAP). The proposed mode relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. In particular, it is defined how OSCORE should be used in a group communication setting, while fulfilling the same security requirements for request messages and related response messages. Source authentication of all messages exchanged within the group is ensured, by means of digital signatures produced through private keys of sender endpoints and embedded in the protected CoAP messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-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 Fri Jun 29 09:19:11 2018 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 CFA61130DDC; Fri, 29 Jun 2018 09:19:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153028914378.30361.16072723610524592348@ietfa.amsl.com> Date: Fri, 29 Jun 2018 09:19:03 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:19:04 -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 WG of the IETF. Title : Echo and Request-Tag Authors : Christian Amsüss John Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-02.txt Pages : 21 Date : 2018-06-29 Abstract: This document specifies several security enhancements to the Constrained Application Protocol (CoAP). Two optional extensions are defined: the Echo option and the Request-Tag option. Each of these options provide additional features to CoAP and protects against certain attacks. The document also updates the processing requirements on the Token of [RFC7252]. The updated Token processing ensures secure binding of responses to requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-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 Fri Jun 29 10:35:03 2018 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 2F739130DEA; Fri, 29 Jun 2018 10:35:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153029370016.30341.4549082261554144546@ietfa.amsl.com> Date: Fri, 29 Jun 2018 10:35:00 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:35:00 -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 WG of the IETF. Title : Too Many Requests Response Code for the Constrained Application Protocol Author : Ari Keranen Filename : draft-ietf-core-too-many-reqs-01.txt Pages : 4 Date : 2018-06-29 Abstract: A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-01 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 Fri Jun 29 10:41:51 2018 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 95B9D130DE9 for ; Fri, 29 Jun 2018 10:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zQurjzR9akVn for ; Fri, 29 Jun 2018 10:41:47 -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 62DCD130DC1 for ; Fri, 29 Jun 2018 10:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530294105; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0ngMMij2QId8kCdiAr3Fij3EFburc32UiOYXq4L2ItE=; b=hjRm7sU2WtZI3lexdEPq6zVJwfqdNwowyd8oGKgLMybJdOWfK9Dhf2qC2mmZgEut UaV5NSLV8T/Ff/Ha87WWxHAJcKDi3O5gSJo5n3qQB599Og39Otarkrj6CPTLEw0U vab0BYPDxBbC6ajKk8wmThm4tWnhpsDuWT6ksmhfmBc=; X-AuditID: c1b4fb30-93dff70000000a77-24-5b366f599d0e Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.60.02679.95F663B5; Fri, 29 Jun 2018 19:41:45 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 29 Jun 2018 19:41:45 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Fri, 29 Jun 2018 19:41:45 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt Thread-Index: AQHUD8+GgeKtCIU/v0i/inkqwsFSM6R3X70A Date: Fri, 29 Jun 2018 17:41:45 +0000 Message-ID: References: <153029370016.30341.4549082261554144546@ietfa.amsl.com> In-Reply-To: <153029370016.30341.4549082261554144546@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <590E7F4D3263324687F41906096B53DD@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbG9WDcy3yza4O5HVYt9b9czOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/Kra8wFP/kr7j1pZmtgvMXTxcjBISFgItEwKbuLkYtDSOAo o8TErQ/ZIJxvjBKrPi6DcpYxSnx99Jili5GTg03AXmLymo+MILaIgIRE59f97CC2sICLxLI1 X5hApooIuEo8nKMPUWIk8W/vYrBWFgFViU/tf8HKeYHG3Dt7nQWkXEjAWWLNQW6QMCfQlG9t q5hAbEYBMYnvp9aA2cwC4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8VwlaS2HvsOgtEvZ7EjalT 2CBsa4mHZ++wQ9jaEssWvmaGOEFQ4uTMJywTGMVmIVkxC0n7LCTts5C0z0LSvoCRdRWjaHFq cVJuupGRXmpRZnJxcX6eXl5qySZGYAQd3PLbYAfjy+eOhxgFOBiVeHgvZZpFC7EmlhVX5h5i lOBgVhLhDQwCCvGmJFZWpRblxxeV5qQWH2KU5mBREue18NscJSSQnliSmp2aWpBaBJNl4uCU amCc/nVmn8rrlPl7JB+oid+4vn3GkUmpSQnRa9yDD2VFmB+MEbUqnBSdMM/58M+yX90+/PUL NH7oNCf7aJq/NX9WHspurcWi+rVd/XjFhUv2LIcmK5tfFrm5cN+qLM5T29PZGm23rImQrph1 NPd4ypkH8SGyM/8XLJ71u2dG0gk3rmLBbY8exhxXYinOSDTUYi4qTgQAq2FZI5wCAAA= Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 17:41:50 -0000 This version adds simply a hint that a server can use action payload with e= rror response to give client guidance how to act (as discussed at the CoRE = meeting in IETF 101). Based on all feedback so far the draft seems to be re= ady to move forward. Cheers, Ari > On 29 Jun 2018, at 20.35, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > Title : Too Many Requests Response Code for the Constrai= ned Application Protocol > Author : Ari Keranen > Filename : draft-ietf-core-too-many-reqs-01.txt > Pages : 4 > Date : 2018-06-29 >=20 > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-01 > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Jun 29 13:25:12 2018 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 3B014130E00 for ; Fri, 29 Jun 2018 13:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 4ceQf66LNtKV for ; Fri, 29 Jun 2018 13:25:05 -0700 (PDT) Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.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 C9766124C04 for ; Fri, 29 Jun 2018 13:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1530303905; x=1561839905; h=mime-version:in-reply-to:references:subject:from:to:cc: message-id:date; bh=tlqE+w5Q2lnnUVIl0Vh+LS/kBUs3mbZn6ES7TTraNak=; b=UtG60MvbcblEXsUutnBbWh7/oeQnEfDOTjr027e/kP1NHXGVXHWjSlaU tZtDGlWHlwi05ADubVhbhMatZ5coiFtfUZBpJPEEKmZUsHRGxK8XGCfaD D9Obvd0Vp5zQ1LJYqSt/Uj+aunTx8gM8H5W0zA3QF5+89K+f8x1m8d1Pl xUoaWU8tdzb6RzaX+TTVSez23fqMA6s6YOTPbHQUorv5y0b4UWsbjUgDw 3pBtpt9J0muOwduVdqajk1D2FR36u9kzKaDBG0ub0OUxHIFd6vSNAZyWD Bf78Up8qSYtLj0u84rr1Fnlg4KRYxcdsRl63nTQk0ak+XIESReyJMkZY/ w==; IronPort-PHdr: =?us-ascii?q?9a23=3AdhHhWxHUGI7L50ANVAHwtZ1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ7ypcWwAkXT6L1XgUPTWs2DsrQY07SQ6/iocFdDyK7JiGoFfp1IWk?= =?us-ascii?q?1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBA?= =?us-ascii?q?j0OxZrKeTpAI7SiNm82/yv95HJbAhEmDuwbaluIBmqsA7cqtQYjYx+J6gr1x?= =?us-ascii?q?DHuGFIe+NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PG?= =?us-ascii?q?Au+MLrrxjDQhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC?= =?us-ascii?q?+85Kl3VhDnlCYHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6jAf90VWH?= =?us-ascii?q?BBU95eWCNCGI2zbYUPAfcBM+hGrIfzqVwAogelCAa2GO/i0CVFhnvq0aEn1e?= =?us-ascii?q?kqDAHI3BYnH9ILqHnZsM76NKcTUeC31qbIyyjIYu5W2Tjn9IjIbgouru2MXb?= =?us-ascii?q?1qa8rQyUkuGBnYhViXs4PqJDOV1uUPs2eB6epsT/mgi249pAFtvjig3Nsjio?= =?us-ascii?q?nTiYIPylHF9T92zZ0pJdKkU053e8KrEJxVtyyDMYZ9X80sQ2ZtuCkgy70Gv4?= =?us-ascii?q?a2fCkUx5Q7yR7TcfuHc5KH4h77SOaePSx4iGh5d7K4gha/91WrxO7kVsSszV?= =?us-ascii?q?pHrDRJnsPRun0OzRDf9MaKRuFy80qnxD2BzRrc6vteLkAxjafbLpkhzaMumZ?= =?us-ascii?q?cLqkTDGzP2mF3xjK+LakUo4uio5PrjYrXhvpKSNJd6hATnPKooh8KyHeI2PA?= =?us-ascii?q?YIUWaB/uqyyqHu8VDhTLVLiP05jLXZvYjHKckZuKK1GRJZ34U55xqhATqqyt?= =?us-ascii?q?sVkWECLF1feRKHi4bpO0vJIPD9FfqwmU+jkDdqx/DEJLLhBI/BIWPDkLj7Yb?= =?us-ascii?q?Z991RTxxYzzd9F/ZJVCrEAL+joV0/tqNPYFQU1PBCzw+biENl9zJ8RWXqTAq?= =?us-ascii?q?+FN6PfqUWH5vguI+WWZ48apiz9JOIj5/Hwi380gkESfbOo3ZQLc3C4BfNmI0?= =?us-ascii?q?ODbXXwhdcBFH8AvhAiQ+zylF2CTTlTam6uUKI7/DE0FpmrDYbdSYCxjryNxi?= =?us-ascii?q?C7HodZZjMONlfZOG3pQKaJQXsKZSTadsZ7k3oHWKKoTYIn/Ry0tQTh0L1haO?= =?us-ascii?q?HT/3tLm4jk0Y1c7e3Slxg0vRZ0BtiB2mqNRntlj2pAEzY83KF9qEo7wFeKzb?= =?us-ascii?q?RxiPxRD81C7ttVWRx8PpnZmb8pQ+vuUx7MK4/aAG2tRc+rVHRoFoo8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CUAADYkzZb/wQXEqxcGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTAYFXD4EYN4tGjkWVIYF6IwEKhEkCg0M0GAECAQECAQECAYE?= =?us-ascii?q?IDII1JAGCXAEBAQECAQEBbAsFCwUGDQQDAQIBJwcnHwkIBgoBCBEKgwUBgXc?= =?us-ascii?q?XrCQBAQGDCIRbg3eBLokOdn6EHoMYAQECAQEWgTA2gw4EgiQCh2SFUYQrh2M?= =?us-ascii?q?HAoFthBeCZIdzQoNHiAiKLokQggpwLyGCaQmFdoUUhUZnjkYHI4IeAQE?= X-IPAS-Result: =?us-ascii?q?A2CUAADYkzZb/wQXEqxcGgEBAQEBAgEBAQEIAQEBAYJTA?= =?us-ascii?q?YFXD4EYN4tGjkWVIYF6IwEKhEkCg0M0GAECAQECAQECAYEIDII1JAGCXAEBA?= =?us-ascii?q?QECAQEBbAsFCwUGDQQDAQIBJwcnHwkIBgoBCBEKgwUBgXcXrCQBAQGDCIRbg?= =?us-ascii?q?3eBLokOdn6EHoMYAQECAQEWgTA2gw4EgiQCh2SFUYQrh2MHAoFthBeCZIdzQ?= =?us-ascii?q?oNHiAiKLokQggpwLyGCaQmFdoUUhUZnjkYHI4IeAQE?= X-IronPort-AV: E=Sophos;i="5.51,287,1526322600"; d="scan'208,217";a="9063903" MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <153029370016.30341.4549082261554144546@ietfa.amsl.com> From: Abhijan Bhattacharyya To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Cc: core Message-ID: Date: Sat, 30 Jun 2018 01:54:56 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP8HF242 May 5, 2017 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 06/30/2018 01:54:56, Serialize complete at 06/30/2018 01:54:56, Itemize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 06/30/2018 01:54:56, Serialize by Router on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 06/30/2018 01:54:57, Serialize complete at 06/30/2018 01:54:57 Content-Type: multipart/alternative; boundary="=_alternative 007025A2652582BB_=" Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 20:25:08 -0000 --=_alternative 007025A2652582BB_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ari, This is indeed an useful addition. = I would like to bring in an aspect which may be highly related to this. Sin= ce I was not actively involved in the earlier discussions related to this d= raft, first hand apologies if it is a repetition. I would like to take clue from https://tools.ietf.org/html/draft-bormann-t2= trg-stp-00 and think of a time-series transaction. There may be cases where= the client is sending a series of information-parts to a resource in the r= emote server such that, the end application collects all the parts and arra= nges them in chronological order to continuously build the information-flow= . In such a situation, every information-part may be transferred as an inde= pendent POST request by the client. Furthermore, to optimize the resource u= sage and satisfy throughput requirements, the client may send a significant= part of these requests as NON with No-Response option (with dis-interest o= nly in the 2.xx responses). However, this open-loop approach has a potentia= l adverse effect in the form of blindly increasing the load on the server a= s well as congesting the network. This response code can be a saviour in su= ch situations. However, Section 4 of the draft says: "If a client receives the 4.29 Resp= onse Code from a CoAP server to a request, it SHOULD NOT send the **same re= quest** to the server before the time indicated in the Max-Age option has p= assed." = The above text covers the case for usual independent sensor updates. But it= exempts the situation narrated earlier. Note that, in that case the client= may not at all be interested to send the same request again. Rather, the = client is sending another independent request (may be quicker than desired = by the server). = So, can the interpretation of this response code be extended a bit so that = scenarios like this may also be covered? (This indicates that probably we n= eed a little more than the HTTP counterpart. HTTP assumes an underlying lay= er of TCP which handles the flow rate, congestion control and is always a c= losed-loop system) . Thank you. = = With Best Regard. Abhijan Bhattacharyya Associate Consultant Scientist, TCS Research Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- 033 66884691 Cell:- +919830468972 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"core" wrote: ----- To: core From: Ari Ker=E4nen = Sent by: "core" = Date: 06/29/2018 11:19PM Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt This version adds simply a hint that a server can use action payload with e= rror response to give client guidance how to act (as discussed at the CoRE = meeting in IETF 101). Based on all feedback so far the draft seems to be re= ady to move forward. Cheers, Ari > On 29 Jun 2018, at 20.35, internet-drafts@ietf.org wrote: > = > = > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. > = > Title : Too Many Requests Response Code for the Constrai= ned Application Protocol > Author : Ari Keranen > Filename : draft-ietf-core-too-many-reqs-01.txt > Pages : 4 > Date : 2018-06-29 > = > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. > = > = > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ > = > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-01 > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-01 > = > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-01 > = > = > Please note that it may take a couple of minutes from the time of submiss= ion > 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 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D 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 007025A2652582BB_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ari,
This is indeed an useful addition. 
I would like to bring in an aspect which may be highly related to thi= s. Since I was not actively involved in the earlier discussions related to = this draft, first hand apologies if it is a repetition.

I would like to take clue from https://tools.ietf.org/= html/draft-bormann-t2trg-stp-00 and think of a time-series transaction.= There may be cases where the client is sending a series of information-par= ts to a resource in the remote server such that, the end application collec= ts all the parts and arranges them in chronological order to continuously b= uild the information-flow. In such a situation, every information-part may = be transferred as an independent POST request by the client. Furthermore, t= o optimize the resource usage and satisfy throughput requirements, the clie= nt may send a significant part of these requests as NON with No-Response op= tion (with dis-interest only in the 2.xx responses). However, this open-loo= p approach has a potential adverse effect in the form of blindly increasing= the load on the server as well as congesting the network. This response co= de can be a saviour in such situations.

However, &= nbsp; Section 4 of the draft says: "I= f a client receives the 4.29 Response Code from a CoAP server to a request, it SHOULD NOT send the *= *same request** to the server before the time indicated in the Max-Age option has passed." 
The above text covers the case for usual independent sensor= updates. But it exempts the situation narrated earlier. Note that, in that= case the client  may not at all be interested to send the same reques= t again. Rather, the client is sending another independent request (may be = quicker than desired by the server). 

=
Thank you. 
 
With Best Regard.
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- 033 66884691
Cell:- +919830468972
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.= tcs.com
____________________________________________
Experience certainty. IT Services
 Business Solutions
 Consulting
____________________________________________


-----"core" <core-bounces@ietf.org> = wrote: -----
To: core <core@i= etf.org>
From: Ari Ker=E4nen
Sent b= y: "core"
Date: 06/29/2018 11:19PM
Subject: R= e: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt

This version adds simpl= y a hint that a server can use action payload with error response to give c= lient guidance how to act (as discussed at the CoRE meeting in IETF 101). B= ased on all feedback so far the draft seems to be ready to move forward.

Cheers,
Ari

> On 29 Jun 2018, at 20.35, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from = the on-line Internet-Drafts directories.
> This draft is a work item = of the Constrained RESTful Environments WG of the IETF.
>
> &n= bsp;      Title           : Too Man= y Requests Response Code for the Constrained Application Protocol
> &= nbsp;      Author          : Ari Ke= ranen
> Filename        : draft-ietf-core-too-ma= ny-reqs-01.txt
> Pages           : 4
>= ; Date            : 2018-06-29
>
&= gt; Abstract:
>   A Constrained Application Protocol (CoAP) serv= er can experience
>   temporary overload because one or more cli= ents are sending requests
>   to the server at a higher rate tha= n the server is capable or willing
>   to handle.  This doc= ument defines a new CoAP Response Code for a
>   server to indic= ate that a client should reduce the rate of requests.
>
>
= > The IETF datatracker status page for this draft is:
> https://d= atatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/
>
>= There are also htmlized versions available at:
> https://tools.ietf.or= g/html/draft-ietf-core-too-many-reqs-01
> https://datatra= cker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-01
>
>= ; A diff from the previous version is available at:
> https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-01
> >
> Please note that it may take a couple of minutes from the ti= me of submission
> until the htmlized version and diff are available = at tools.ietf.org.
>
> Internet-Drafts are also available by a= nonymous FTP at:
> ft= p://ftp.ietf.org/internet-drafts/
>
> ____________________= ___________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/li= stinfo/core

_______________________________________________
c= ore mailing list
core= @ietf.org
htt= ps://www.ietf.org/mailman/listinfo/core

=3D=3D=3D=3D=3D--= ---=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
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 007025A2652582BB_=-- From nobody Sat Jun 30 02:41:20 2018 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 A57D8131053 for ; Sat, 30 Jun 2018 02:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 3Cn8rkrMkXN0 for ; Sat, 30 Jun 2018 02:41:14 -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 8CD5E131051 for ; Sat, 30 Jun 2018 02:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530351672; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Jvsx3i1soLEuPDZ6H+TKyhJ7IsnzRfu7O3D6Fvevc/I=; b=JYwckOIEsmK1ZnZWMwh2XsEmia1K0bHgV3z5sUUWd8EDY2sx7SoUROAyBvy4m8IO Wgr3iA+bHF6Gu/O2CbR2YNXrggUjlJVY7DL+M/7sbBvDFxLfGZC7TL4E4bqx/akm R3gW3wu4GnNRnMj8kNZbdUeTbYv802OIpUhkFQ2qnsk=; X-AuditID: c1b4fb3a-dcb6e9c0000079c1-82-5b375038af9c Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9C.DF.31169.830573B5; Sat, 30 Jun 2018 11:41:12 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 30 Jun 2018 11:40:27 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Sat, 30 Jun 2018 11:40:27 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Abhijan Bhattacharyya , core Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt Thread-Index: AQHUD8+GgeKtCIU/v0i/inkqwsFSM6R3X70AgAAtmQCAAN5EgA== Date: Sat, 30 Jun 2018 09:40:27 +0000 Message-ID: <420CCA7A-5DBB-4BE3-88EA-77EBC8055B3A@ericsson.com> References: <153029370016.30341.4549082261554144546@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: <8D7CC6823FE4084799711ADDA47A9212@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7ma5FgHm0wfmFBhZPZu9ls9j3dj2z A5PHkiU/mTxmvJ/KGsAUxWWTkpqTWZZapG+XwJXx+/QOtoJ7nhVvPk9ha2B8497FyMkhIWAi 8XrRYdYuRi4OIYGjjBI7Z26Dcr4xSqz+uJodwlnGKLHmxHdWkBY2AVuJJ637gGwODhGBQInV r2RBwsICLhLL1nxhggi7Sjycow8SFhFwkjj1fhsbiM0ioCpx4FEDmM0rYC/x+PNtZojx+xkl Jk36DzaSUyBAYveOQpAaRgExie+n1jCB2MwC4hK3nsxngjhaQGLJnvPMELaoxMvH/1ghbCWJ vceus4CMYRbQlFi/Sx+i1Vpix+TZLBC2osSU7ofsECcISpyc+YRlAqPYLCQbZiF0z0LSPQtJ 9ywk3QsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbUwS2/rXYwHnzueIhRgINRiYe3 z9o8Wog1say4MvcQowQHs5IIb2CQWbQQb0piZVVqUX58UWlOavEhRmkOFiVxXqc0iyghgfTE ktTs1NSC1CKYLBMHp1QDI4fLZL43ie+Lmit9dl/N//XmRdA/4bbAj6xX0y53P1q2+diff7/a 1nUmr/L0Z+Fe/9O749zHK5qP2H992VI658bWJRemy9z5s1zpp8nHOwJFDOJJCVv4Oo+aus89 9Tc3efqHuESDrNRpIdKmzY7cDAe9ovKfmNQVCSwVr95eeO3j3Rk+gUesziuxFGckGmoxFxUn AgDfcQpEpQIAAA== Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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: Sat, 30 Jun 2018 09:41:18 -0000 SGkgQWJoaWphbiwgYWxsLA0KDQpJIHRoaW5rIHlvdSBoYXZlIGEgZ29vZCBwb2ludCBhbmQgbWFr aW5nIHRoaXMgYWRkaXRpb24gdG8gdGhlIGRyYWZ0IG1ha2VzIHNlbnNlIHRvIG1lLg0KDQpPbmUg d2F5IHRvIGFkZHJlc3MgdGhpcyB3b3VsZCBiZSB0byByZWRlZmluZSB3aGF0IHdlIG1lYW4gYnkg c2FtZS9zaW1pbGFyIHJlcXVlc3RzIGFuZCBleHBsaWNpdGx5IG1lbnRpb24gdGhlIHNlcmllcyBj YXNlLiBTb21ldGhpbmcgbGlrZSB0aGlzOg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvdG9v LW1hbnktcmVxcy9wdWxsLzEvZmlsZXMNCg0KVGhlIGtleSBjaGFuZ2UgaXMgdGhpcyBuZXcgcGFy YWdyYXBoIGluIGludHJvOg0KPiBXaGlsZSBzZXJ2ZXIgbWF5IG5vdCBiZSBhYmxlIHRvIHJlc3Bv bnNlIHRvIGEgb25lIGtpbmQgb2YgcmVxdWVzdCwgaXQNCj4gbWF5IGJlIGFibGUgdG8gcmVzcG9u ZCB0byBhIGRpZmZlcmVudCByZXF1ZXN0LCBldmVuIGZyb20gdGhlIHNhbWUNCj4gY2xpZW50LiBU aGVyZWZvcmUgdGhlIGJhY2stb2ZmIHBlcmlvZCBhcHBsaWVzIG9ubHkgdG8gc2ltaWxhcg0KPiBy ZXF1ZXN0cy4gRm9yIHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQsIGEgcmVxdWVzdCBpcyBz aW1pbGFyIGlmIGl0DQo+IGhhcyB0aGUgc2FtZSBtZXRob2QsIFJlcXVlc3QtVVJJLCBhbmQgcGF5 bG9hZC4gQWxzbyBpZiBhIGNsaWVudCBpcw0KPiBzZW5kaW5nIGEgc2VxdWVuY2Ugb2YgcmVxdWVz dHMgdGhhdCBhcmUgcGFydCBvZiB0aGUgc2FtZSBzZXJpZXMNCj4gKGUuZy4sIGEgc2V0IG9mIG1l YXN1cmVtZW50cyB0byBiZSBwcm9jZXNzZWQgYnkgdGhlIHNlcnZlcikgdGhleSBhcmUNCj4gY29u c2lkZXJlZCBzaW1pbGFyIGV2ZW4gaWYgcmVxdWVzdCBwYXlsb2FkcyBtYXkgYmUgZGlmZmVyZW50 Lg0KDQoNCkFuZCBpbiBjbGllbnQgYmVoYXZpb3VyIHNheSAic2ltaWxhciByZXF1ZXN0IiBpbnN0 ZWFkIG9mICJ0aGUgc2FtZSByZXF1ZXN0Ii4NCg0KQ29tbWVudHMgd2VsY29tZSEgSWYgc29tZXRo aW5nIGxpa2UgdGhhdCB3b3JrcyBmb3IgZXZlcnlvbmUsIEkgY291bGQgc3VibWl0IGEgbmV3IHZl cnNpb24gd2l0aCB0aGlzIGJlZm9yZSB0aGUgZHJhZnQgREwuDQoNCg0KQ2hlZXJzLA0KQXJpDQoN Cj4gT24gMjkgSnVuIDIwMTgsIGF0IDIzLjI0LCBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFiaGlq YW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPiB3cm90ZToNCj4gDQo+IEhpIEFyaSwNCj4gVGhpcyBp cyBpbmRlZWQgYW4gdXNlZnVsIGFkZGl0aW9uLiANCj4gSSB3b3VsZCBsaWtlIHRvIGJyaW5nIGlu IGFuIGFzcGVjdCB3aGljaCBtYXkgYmUgaGlnaGx5IHJlbGF0ZWQgdG8gdGhpcy4gU2luY2UgSSB3 YXMgbm90IGFjdGl2ZWx5IGludm9sdmVkIGluIHRoZSBlYXJsaWVyIGRpc2N1c3Npb25zIHJlbGF0 ZWQgdG8gdGhpcyBkcmFmdCwgZmlyc3QgaGFuZCBhcG9sb2dpZXMgaWYgaXQgaXMgYSByZXBldGl0 aW9uLg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHRha2UgY2x1ZSBmcm9tIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3JtYW5uLXQydHJnLXN0cC0wMCBhbmQgdGhpbmsgb2YgYSB0 aW1lLXNlcmllcyB0cmFuc2FjdGlvbi4gVGhlcmUgbWF5IGJlIGNhc2VzIHdoZXJlIHRoZSBjbGll bnQgaXMgc2VuZGluZyBhIHNlcmllcyBvZiBpbmZvcm1hdGlvbi1wYXJ0cyB0byBhIHJlc291cmNl IGluIHRoZSByZW1vdGUgc2VydmVyIHN1Y2ggdGhhdCwgdGhlIGVuZCBhcHBsaWNhdGlvbiBjb2xs ZWN0cyBhbGwgdGhlIHBhcnRzIGFuZCBhcnJhbmdlcyB0aGVtIGluIGNocm9ub2xvZ2ljYWwgb3Jk ZXIgdG8gY29udGludW91c2x5IGJ1aWxkIHRoZSBpbmZvcm1hdGlvbi1mbG93LiBJbiBzdWNoIGEg c2l0dWF0aW9uLCBldmVyeSBpbmZvcm1hdGlvbi1wYXJ0IG1heSBiZSB0cmFuc2ZlcnJlZCBhcyBh biBpbmRlcGVuZGVudCBQT1NUIHJlcXVlc3QgYnkgdGhlIGNsaWVudC4gRnVydGhlcm1vcmUsIHRv IG9wdGltaXplIHRoZSByZXNvdXJjZSB1c2FnZSBhbmQgc2F0aXNmeSB0aHJvdWdocHV0IHJlcXVp cmVtZW50cywgdGhlIGNsaWVudCBtYXkgc2VuZCBhIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlc2Ug cmVxdWVzdHMgYXMgTk9OIHdpdGggTm8tUmVzcG9uc2Ugb3B0aW9uICh3aXRoIGRpcy1pbnRlcmVz dCBvbmx5IGluIHRoZSAyLnh4IHJlc3BvbnNlcykuIEhvd2V2ZXIsIHRoaXMgb3Blbi1sb29wIGFw cHJvYWNoIGhhcyBhIHBvdGVudGlhbCBhZHZlcnNlIGVmZmVjdCBpbiB0aGUgZm9ybSBvZiBibGlu ZGx5IGluY3JlYXNpbmcgdGhlIGxvYWQgb24gdGhlIHNlcnZlciBhcyB3ZWxsIGFzIGNvbmdlc3Rp bmcgdGhlIG5ldHdvcmsuIFRoaXMgcmVzcG9uc2UgY29kZSBjYW4gYmUgYSBzYXZpb3VyIGluIHN1 Y2ggc2l0dWF0aW9ucy4NCj4gDQo+IEhvd2V2ZXIsICAgU2VjdGlvbiA0IG9mIHRoZSBkcmFmdCBz YXlzOiAiSWYgYSBjbGllbnQgcmVjZWl2ZXMgdGhlIDQuMjkgUmVzcG9uc2UgQ29kZSBmcm9tIGEg Q29BUCBzZXJ2ZXIgdG8gYSByZXF1ZXN0LCBpdCBTSE9VTEQgTk9UIHNlbmQgdGhlICoqc2FtZSBy ZXF1ZXN0KiogdG8gdGhlIHNlcnZlciBiZWZvcmUgdGhlIHRpbWUgaW5kaWNhdGVkIGluIHRoZSBN YXgtQWdlIG9wdGlvbiBoYXMgcGFzc2VkLiIgDQo+IFRoZSBhYm92ZSB0ZXh0IGNvdmVycyB0aGUg Y2FzZSBmb3IgdXN1YWwgaW5kZXBlbmRlbnQgc2Vuc29yIHVwZGF0ZXMuIEJ1dCBpdCBleGVtcHRz IHRoZSBzaXR1YXRpb24gbmFycmF0ZWQgZWFybGllci4gTm90ZSB0aGF0LCBpbiB0aGF0IGNhc2Ug dGhlIGNsaWVudCAgbWF5IG5vdCBhdCBhbGwgYmUgaW50ZXJlc3RlZCB0byBzZW5kIHRoZSBzYW1l IHJlcXVlc3QgYWdhaW4uIFJhdGhlciwgdGhlIGNsaWVudCBpcyBzZW5kaW5nIGFub3RoZXIgaW5k ZXBlbmRlbnQgcmVxdWVzdCAobWF5IGJlIHF1aWNrZXIgdGhhbiBkZXNpcmVkIGJ5IHRoZSBzZXJ2 ZXIpLiANCj4gDQo+IFNvLCBjYW4gdGhlIGludGVycHJldGF0aW9uIG9mIHRoaXMgcmVzcG9uc2Ug Y29kZSBiZSBleHRlbmRlZCBhIGJpdCBzbyB0aGF0IHNjZW5hcmlvcyBsaWtlIHRoaXMgbWF5IGFs c28gYmUgY292ZXJlZD8gKFRoaXMgaW5kaWNhdGVzIHRoYXQgcHJvYmFibHkgd2UgbmVlZCBhIGxp dHRsZSBtb3JlIHRoYW4gdGhlIEhUVFAgY291bnRlcnBhcnQuIEhUVFAgYXNzdW1lcyBhbiB1bmRl cmx5aW5nIGxheWVyIG9mIFRDUCB3aGljaCBoYW5kbGVzIHRoZSBmbG93IHJhdGUsIGNvbmdlc3Rp b24gY29udHJvbCBhbmQgaXMgYWx3YXlzIGEgY2xvc2VkLWxvb3Agc3lzdGVtKSAuDQo+IA0KPiBU aGFuayB5b3UuIA0KPiAgDQo+IFdpdGggQmVzdCBSZWdhcmQuDQo+IEFiaGlqYW4gQmhhdHRhY2hh cnl5YQ0KPiBBc3NvY2lhdGUgQ29uc3VsdGFudA0KPiBTY2llbnRpc3QsIFRDUyBSZXNlYXJjaA0K PiBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQo+IEJ1aWxkaW5nIDFCLEVjb3NwYWNlDQo+IFBs b3QgLSAgSUlGLzEyICxOZXcgVG93biwgUmFqYXJoYXQsDQo+IEtvbGthdGEgLSA3MDAxNjAsV2Vz dCBCZW5nYWwNCj4gSW5kaWENCj4gUGg6LSAwMzMgNjY4ODQ2OTENCj4gQ2VsbDotICs5MTk4MzA0 Njg5NzINCj4gTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbQ0KPiBXZWJzaXRl OiBodHRwOi8vd3d3LnRjcy5jb20NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gRXhwZXJpZW5jZSBjZXJ0YWludHkuIElUIFNlcnZpY2VzDQo+IEJ1c2lu ZXNzIFNvbHV0aW9ucw0KPiBDb25zdWx0aW5nDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IA0KPiANCj4gLS0tLS0iY29yZSIgPGNvcmUtYm91bmNlc0Bp ZXRmLm9yZz4gd3JvdGU6IC0tLS0tDQo+IFRvOiBjb3JlIDxjb3JlQGlldGYub3JnPg0KPiBGcm9t OiBBcmkgS2Vyw6RuZW4gDQo+IFNlbnQgYnk6ICJjb3JlIiANCj4gRGF0ZTogMDYvMjkvMjAxOCAx MToxOVBNDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jb3Jl LXRvby1tYW55LXJlcXMtMDEudHh0DQo+IA0KPiBUaGlzIHZlcnNpb24gYWRkcyBzaW1wbHkgYSBo aW50IHRoYXQgYSBzZXJ2ZXIgY2FuIHVzZSBhY3Rpb24gcGF5bG9hZCB3aXRoIGVycm9yIHJlc3Bv bnNlIHRvIGdpdmUgY2xpZW50IGd1aWRhbmNlIGhvdyB0byBhY3QgKGFzIGRpc2N1c3NlZCBhdCB0 aGUgQ29SRSBtZWV0aW5nIGluIElFVEYgMTAxKS4gQmFzZWQgb24gYWxsIGZlZWRiYWNrIHNvIGZh ciB0aGUgZHJhZnQgc2VlbXMgdG8gYmUgcmVhZHkgdG8gbW92ZSBmb3J3YXJkLg0KPiANCj4gDQo+ IENoZWVycywNCj4gQXJpDQo+IA0KPiA+IE9uIDI5IEp1biAyMDE4LCBhdCAyMC4zNSwgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+IA0KPiA+IA0KPiA+IEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb25zdHJhaW5l ZCBSRVNUZnVsIEVudmlyb25tZW50cyBXRyBvZiB0aGUgSUVURi4NCj4gPiANCj4gPiAgICAgICAg VGl0bGUgICAgICAgICAgIDogVG9vIE1hbnkgUmVxdWVzdHMgUmVzcG9uc2UgQ29kZSBmb3IgdGhl IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sDQo+ID4gICAgICAgIEF1dGhvciAgICAg ICAgICA6IEFyaSBLZXJhbmVuDQo+ID4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jb3Jl LXRvby1tYW55LXJlcXMtMDEudHh0DQo+ID4gUGFnZXMgICAgICAgICAgIDogNA0KPiA+IERhdGUg ICAgICAgICAgICA6IDIwMTgtMDYtMjkNCj4gPiANCj4gPiBBYnN0cmFjdDoNCj4gPiAgIEEgQ29u c3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIHNlcnZlciBjYW4gZXhwZXJpZW5j ZQ0KPiA+ICAgdGVtcG9yYXJ5IG92ZXJsb2FkIGJlY2F1c2Ugb25lIG9yIG1vcmUgY2xpZW50cyBh cmUgc2VuZGluZyByZXF1ZXN0cw0KPiA+ICAgdG8gdGhlIHNlcnZlciBhdCBhIGhpZ2hlciByYXRl IHRoYW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9yIHdpbGxpbmcNCj4gPiAgIHRvIGhhbmRsZS4g IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBDb0FQIFJlc3BvbnNlIENvZGUgZm9yIGENCj4g PiAgIHNlcnZlciB0byBpbmRpY2F0ZSB0aGF0IGEgY2xpZW50IHNob3VsZCByZWR1Y2UgdGhlIHJh dGUgb2YgcmVxdWVzdHMuDQo+ID4gDQo+ID4gDQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLXRvby1tYW55LXJlcXMvDQo+ID4gDQo+ID4gVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtdG9vLW1hbnktcmVxcy0wMQ0KPiA+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXRvby1t YW55LXJlcXMtMDENCj4gPiANCj4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtY29yZS10b28tbWFueS1yZXFzLTAxDQo+ID4gDQo+ID4gDQo+ID4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KPiA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4gDQo+ID4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IGNvcmVA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ID09PT09LS0tLS09PT09PS0tLS0tPT09PT0NCj4g Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsDQo+IG1lc3Nh Z2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIA0KPiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSANCj4gbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIA0KPiByZXZpZXcsIGRpc3RyaWJ1 dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIA0KPiBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJl IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIA0KPiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIA0KPiBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBv ciB0ZWxlcGhvbmUgYW5kIA0KPiBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBtZXNzYWdlIA0KPiBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UNCj4gDQo+IA0KDQo= From rquattle@google.com Fri Jun 29 13:25:13 2018 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 2AFF6130E00 for ; Fri, 29 Jun 2018 13:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 VlxKrFECKO0A for ; Fri, 29 Jun 2018 13:25:11 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 5B2ED124C04 for ; Fri, 29 Jun 2018 13:25:11 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id v9-v6so3573250pff.9 for ; Fri, 29 Jun 2018 13:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=mr4t83rrPbLxxwvhkzTWzdWos2kZYh9eNRK83w/P2wY=; b=dfSLKyadI64IrkYMBYL/S7v/9FI31/Vn0/c69IoplX04YK6gKbHd8WkOx4yB1/1WRQ KW6J46ReZ7L2EeuzOIKQ/6ALCrtL4N3XVpmYa/Ni38Pn9XXvHYhY4O5/r6CN/DJVvRDT Xe48RXZqqbHnPqakoCEEGXngoP9fsBV6XEkioL5vopnlU8VPQiFi5yF0FT0kLuYE0rBx M9CxMV7kqJAnlSCeN+X4NfFd0hFh2hzFZD6uTQKx5axtqgaMf4/I484SSvHIeKLm8FQv V8a8m8nnZ1ZmY+NHyrRkRUb7ZhceXcV8AdBRLLxkIIJwZQWkZEl5eiEv3U2d2I/Pca6w +J0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=mr4t83rrPbLxxwvhkzTWzdWos2kZYh9eNRK83w/P2wY=; b=dswM6uAHY411+zk5ZpBjUlVXCFtePtlSLMHpZF7kMcYKhfhuysJzVq661+XxIe+s4z Rm6kFTQ3v5BcQ066GprMKUYgSnHBO9CG2MUrRzAEpcIj9CQAPgt8NSbY5s0wP9BgXKMO 56wFH1RqQKofo17PpWDzrUft4zMuqvmWqEAtwfF6AbKwWMnOfoXlPXKg85yL7RLgBYi8 m3w2Tjmu397KiNDA8K1fMAYod+nRMzu18jQT9/wgRlwMk+Ims1BUttfunfg43EhWZ3mp 48QvA8HLzGSbe1UeDuFx0UuE7pPCli3T3WVi5aNa9R3EkV75jQPAQlkuSGu1azR/iYUk T8tQ== X-Gm-Message-State: APt69E3xRtnzNdY76kKA9o8SMLKg9PqR3+MgmoCicncMmHlmqZG7SfvG 8n91oxgoLhpm4jSrrF7ddcgbtZRhF4c= X-Google-Smtp-Source: AAOMgpey/x4pk4bPxxtLvcq6u17MLivkaSKhoBEB5vn3xgEyCk/2NybN+r9e8rjiZGtFyytuxfjumQ== X-Received: by 2002:a65:4b07:: with SMTP id r7-v6mr1595505pgq.150.1530303910263; Fri, 29 Jun 2018 13:25:10 -0700 (PDT) Received: from ?IPv6:2601:646:8d00:1cc3:9582:a955:fe06:34c1? ([2601:646:8d00:1cc3:9582:a955:fe06:34c1]) by smtp.gmail.com with ESMTPSA id 76-v6sm2562202pfx.40.2018.06.29.13.25.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 13:25:09 -0700 (PDT) From: Robert Quattlebaum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 29 Jun 2018 13:25:07 -0700 Message-Id: <403E803C-B547-4645-9C8A-7D1753B651E8@google.com> To: core X-Mailer: Apple Mail (2.3445.8.2) Archived-At: X-Mailman-Approved-At: Sat, 30 Jun 2018 11:04:05 -0700 Subject: [core] oscore-groupcomm: Thoughts on the role of the Group Manager X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 20:26:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, I was reviewing draft-ietf-core-oscore-groupcomm-02 and had some comments, specifically to the role of the group manager. First off, overall the direction looks fantastic. Second, appendix D.1 outlines a process for an endpoint becoming a member of the group. In this process, the endpoint itself petitions the Group Manager to be made a part of the group. This seems obtuse to me: Presumably, an authenticated administrative interaction was required to configure that endpoint to know to request to join that group. Wouldn't it make sense to also configure the rest of the required data to participate in the group in the same administrative action? It also seems at odds with the third responsibility of a Group Manager outlined in section 6: "Driving the join process to add new endpoints as group members". In Appendix D.1, it is the endpoint initiating the join, not the Group Manager. Specifically, what I'm proposing is that endpoints don't ask the Group Manager to join a group: instead, the administrator indicates to the Group Manager that a specific endpoint should be added to the group, and at that point the group manager goes ahead and configures the newly added endpoint accordingly. Strictly speaking, I don't even think an endpoint even needs to know who the Group Manager is. The Group Manager already needs the capability to configure endpoints to reconfigure and eject devices from the group. Eliminating the (apparent) requirement for an endpoint to be able to ask to join a group makes implementations more simple without sacrificing any functionality. It would also simplify the required security interactions. It also allows for the Group Manager to be an offline device that only appears during administrative actions. Thoughts? - -\- RQ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyqyznYdlVWku4iGibiytsfqnyUQFAls2lSIACgkQbiytsfqn yUQx7Af+J2l7KgFGXaJvnCFYE1mYzQ3ralzsAeFOa5V57CWwX4qPg1oVnwXFrQ2q PFEUB09ovAHHEhI0AmHHSt6tJWwJ8LxGs9vkdwdy/5O4nDGml8ix/gksEzKb66MA q1ilk5qns491vCCfpkCzqcNqaE2wT8n/gnF1a5G1lmeARpOkKHhwOzQ+mKObl0ux akCOMdtZcEjVw+npFqWEMxmmtJIcl0JQIXoIxuPO1eSClaxR6KnP19oHrhrhJHuq W61XyucLWEzwD/mQx3LaeI5UGRdoFOFEVjhQd22AeQYWNaUbygQ8ozz+I6vpkplo l/1LbPhyYMDzEQ0FOgx7Kau3O3Su6A== =kvhP -----END PGP SIGNATURE-----