From nobody Mon Apr 1 02:12:13 2019 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 AC2131200CE; Mon, 1 Apr 2019 02:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACmZTvICSqcD; Mon, 1 Apr 2019 02:12:09 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417801200C3; Mon, 1 Apr 2019 02:12:08 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id A6D5D837F27F; Mon, 1 Apr 2019 09:12:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=7v1oHKmUHGutp4fnnQ TdJYu3LbS0cDuc2rPKg4L6uko=; b=cf0BHtcMZDkQ61qih4EF/VxV8JAcXDsogG cxWXv3ErOBIofzsN29xCIs5UrRpaKR7PNz3WYFLrgavXd6XZdkiL6QL8Tedjv6SL Nd2IEG2LJJglEbGv3mWfT/oNVtIirlRYmqfnMvzTMtCvlZkji0NQGejJ0c+zTgE5 v2Zd9XPpc= 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:960:962:967:969:973:983:988:989:1049:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1575:1588:1589:1592:1594:1606:1730:1776:1792:2068:2069:2194:2198:2199:2200:2288:2525:2528:2553:2559:2568:2682:2685:2741:2771:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3165:3353:3421:3622:3865:3866:3867:3868:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4120:4250:4321:4361:4362:4425:4605:4659:4700:4860:5007:6117:6119:6261:6657:6659:6678:7603:7875:7903:8599:8603:9010:9015:9025:9108:9177:10004:10848:11232:11658:11914:12043:12109:12114:12291:12379:12438:12679:12683:12740:12895:12926:13139:13439:13846:13972:14096:14196:21060:21080:21433:21451:21627:21691:21740:21881:30019:30029:30034:30046:30054:30060:30076:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, X-HE-Tag: plant99_86eb82188912d X-Filterd-Recvd-Size: 9484 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf18.hostedemail.com (Postfix) with ESMTPA; Mon, 1 Apr 2019 09:12:07 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_e9f419e5f8e30040d01d4b3e1231b47d" Date: Mon, 01 Apr 2019 02:12:06 -0700 From: Peter van der Stok To: ivaylo petrov Cc: core@ietf.org, i-d-announce@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <155381071244.1414.15110813535407686735@ietfa.amsl.com> Message-ID: <8ca1c4d39dcf1341b55503197519c93b@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-sid-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 09:12:12 -0000 --=_e9f419e5f8e30040d01d4b3e1231b47d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Ivaylo, Thanks for this work. This version looks better than the earler one. Removal of comi draft refrences cleans up nicely. Two suggestions: section 6.2.1 URL entry; make clear what the URL refers to. 6.4.1. YANG Module name Registry, adding a reference to the defining section and the RFC number may be handy. Hope this can be published soon. Peter ivaylo petrov schreef op 2019-03-28 15:07: > Dear all, > > The new version of the sid draft is uploaded to the datatracker. It is the result of a number of discussions with IANA representatives. Please review it and don't hesitate to contact us if you have any questions or comments. > > Best regards, > Ivaylo > > On Thu, Mar 28, 2019 at 11:05 PM 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. >> >> Title : YANG Schema Item iDentifier (SID) >> Authors : Michel Veillette >> Alexander Pelov >> Ivaylo Petrov >> Filename : draft-ietf-core-sid-06.txt >> Pages : 29 >> Date : 2019-03-28 >> >> 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-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-06 >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org [1]. >> >> 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 Links: ------ [1] http://tools.ietf.org --=_e9f419e5f8e30040d01d4b3e1231b47d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Ivaylo,

Thanks for this work.
This version looks better = than the earler one.
Removal of comi draft refrences cleans up nicely= =2E

Two suggestions:
section 6.2.1 URL entry; make clear wh= at the URL refers to.
6.4.1. YANG Module name Registry, adding a refer= ence to the defining section and the RFC number may be handy.

Ho= pe this can be published soon.

Peter

ivaylo petrov schreef op 2019-03-28 15:07:

Dear all,
 
The new version of the sid draft is uploaded to the datatracke= r. It is the result of a number of discussions with IANA representatives. P= lease review it and don't hesitate to contact us if you have any questions = or comments.
 
Best regards,
Ivaylo

On Thu, Mar 28, 2019 at 11:05 PM <= 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.

        Title        &nbs= p;  : YANG Schema Item iDentifier (SID)
      &nb= sp; Authors         : Michel Veillette
 = ;                     &nb= sp;   Alexander Pelov
            =               Ivaylo Petrov
 =       Filename        : draft-ietf-core= -sid-06.txt
        Pages      &nb= sp;    : 29
        Date    &= nbsp;       : 2019-03-28

Abstract:
 =  YANG Schema Item iDentifiers (SID) are globally unique 64-bit
=    unsigned numbers used to identify YANG items.  This docum= ent defines
   the semantics, the registration, and assignm= ent processes of SIDs.
   To enable the implementation of t= hese processes, this document also
   defines a file format= used to persist and publish assigned SIDs.


The IETF da= tatracker status page for this draft is:
= https://datatracker.ietf.org/doc/draft-ietf-core-sid/

Ther= e are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-sid-06
https://datatracker.ietf.org/doc/html/draft-ietf-co= re-sid-06

A diff from the previous version is available at= :
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-core-sid-06


Please note that it may t= ake a couple of minutes from the time of submission
until the htmlize= d version and diff are available at tools.ietf.org.

Internet-D= rafts are also available by anonymous FTP at:
ftp://ftp.iet= f.org/internet-drafts/

___________________________________= ____________
core mailing list
core@ietf.org
https://www.ie= tf.org/mailman/listinfo/core

= _______________________________________________
core mailing list
core@ietf.org https://www.ietf.org/mailman/listinfo/core
--=_e9f419e5f8e30040d01d4b3e1231b47d-- From nobody Mon Apr 1 09:12:50 2019 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 8C0F01202C6; Mon, 1 Apr 2019 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, URIBL_BLOCKED=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 httZOCVJpB4g; Mon, 1 Apr 2019 09:12:46 -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 6D0591202BB; Mon, 1 Apr 2019 09:12:45 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D630740614; Mon, 1 Apr 2019 18:12:43 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5E23036; Mon, 1 Apr 2019 18:12:40 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:d1d3:1131:a7fd:9672]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2BE096A; Mon, 1 Apr 2019 18:12:40 +0200 (CEST) Received: (nullmailer pid 29556 invoked by uid 1000); Mon, 01 Apr 2019 16:12:39 -0000 Date: Mon, 1 Apr 2019 18:12:39 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: draft-ietf-core-coap-pubsub@ietf.org Cc: core@ietf.org Message-ID: <20190401161239.GC28400@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] pubsub short-review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 16:12:48 -0000 --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello pubsub authors, I've gone through the current pubsub version on github, and while this is not a full review (although in retrospect it has become quite a wall of text -- if I had the time I'd write a shorter mail), there's some questions I'd like to raise: * message passing vs. eventual consistency: I'm getting mixed messages when reading the document here. On one side, pub/sub in general is described as a messaging paradigm, CoAP pub/sub is not differentiated in that property, and a "Broker MUST make a best-effort attempt to notify all clients [...] each time it receives a publish". That indicates that every single state change matters (though the best-effort wording foreshadows the trouble). On the other side, the subscribe operation is built on CoAP observation, which is an inherently eventually consistent thing. Even if the broker and client libraries can be configured to not swallow notifications that arrive too fast in sequence, there can always be intermediaries that execute their liberties under RFC7641 to poll instead or (being a server) "MAY choose to skip sending a notification if it knows that it will send another notification soon". The ways I see out of this are either to go with a full a messaging concept (and implement a reliable message queue), or embrace the eventually consistent style, losen up on best-effort on state changes and make it clear in the introduction that representations of state, not messages, are kept in the topics. I have a preference for the latter. * Failure 4.04 "Not Found": The difference between an empty list (empty payload in link-format) and the failure to find a list (4.04 response) has been pointed out in the resource directory, and applies to the discovery interface just as well. (As a side effect, observing lists of topics becomes possible). I wouldn't quite classify that case as a failure -- both an empty-list result and no response on multicast are very successful results. (Following parallel discussion in RD, it might be worth reconsidering whether listing error codes for each operation really has value, given the list can not be exhaustive anyway, and regular CoAP processing needs to be applied). * If I understand correctly, a topic can have sub-topics iff it is created with a link-format media type. On such topics the discover operation can be executed, while non-linkformat topics can be read. Does this allow the publication of general information in link format? How will this behave when there are other media types that express link-format-ish information? (There was the idea around after the presentation in Prague that suggests separating the topic metadata from its data -- or is that what is hinted at with the distinction between "/ps/parent-topic" and "/ps/parent-topic/"? If so, it could be more explicit). * The create-on-publish operation is executed using PUT, which MUST be idempotent according to RFC7252 Section 5.1. Returning 2.01 Created on first put and 2.04 Changed on the second put is not exactly idempotent. A client behind an optimized intermediary or library may receive a 2.04 even on creation if one of the components forgoes message deduplication as given license to do in RFC7252 Section 4.5. * The subscribe operation uses a whole lot of words to say that "CoAP observation as defined in RFC7641 can be used on topics". I have no issue with having examples for that or using more than 80 characters to describe it, but this is phrasing requirements from other places into normative languages and IMO overspecifying. * RFC6690 pet peeve: in the context of /ps/parent-topic/ does not mean what it appears to be, it resolves to /subtopic rather than /ps/parent-topic/subtopic according to the resoluton rules as I understand them. * Brokerless pub-sub: What is the difference between a brokerless node with preconfigured topics that are subscribed to by other nodes, and a CoAP server? (Should I advertise rt=3Dcore.ps on every of my servers so I can become a brokerless pubsub server? What information does a client gain from discovering a given resource as being part of a pubsub server[1] vs. discovering it on a CoAP server[2]?) Best regards Christian [1]: executing figures 3 and 4 of the current git version [2]: same with s/?rt=3Dcore.ps/?ct=3D40/ which implements regular gradual reveal --=20 There's always a bigger fish. -- Qui-Gon Jinn --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyiOHQACgkQOY0REtOk veGAHhAAwQJ7wDySyjHRXULtvanRAnsJCgMLxn8WqGh5Wg06+QtIaxzisEy7MZ6T YXYufrQaT0ol2oEIBRKvCipDxXTjydkZdIHFxBAORik0Aa2YVxhY+mlTfeN3EHrj z9CQLfzIPJf81iVGKO0k4ZwWd4LAaaKZN97+HCJ96CT2lXKadCr9CQpfBtegMiQH kOdDQk6dgT394G1YNJOP4R3/KY6A3Z5znB7fKkzswUj/p7WbqcCiDEQMigYj2tJN gNPE679cKutAtOTs0RnHGZJKG4i1Gr67pimGJBnZmMFqK5cqrtZByzrEq/EaPYDk CHhgN2tETeGEC+HZhor7ypU5muTELCb2MA7b0jCOBLRF0v7uE3LWp6zP/FbULPu4 sOMBpz+kWPA+wnsWuTb6XVxwtg+BjtgsCiV4/HMCgZDOy2B2XBk/KsyEXrR5lHrH ++ZJZBdHzXyNEoXc3wjKoNDCX2d774rOon8M1mm2yXJ1zR2v3b9HoBCG+AlKSZQt nDSwTskrvo+Q5/MoL+Sku5wsFzKmR7LaQAcFd3pKu27xKHl4IQPcdBSHvXF2kJhy qYQYJnNsKzq3BFD8f8B2SkaxSdapbVQj8TLGzbWvp/TjehyC+c9iBiJY5T5HlY6H XILTRcbBnT1Cesp3PRq41DkEiUiGvfeunUG/xuEFSmeJv+zgsVs= =yNZV -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- From nobody Mon Apr 1 10:30:05 2019 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 F2CE11204CB; Mon, 1 Apr 2019 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 bxnnDBCu0Ih2; Mon, 1 Apr 2019 10:29:56 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 678031204C6; Mon, 1 Apr 2019 10:29:56 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id d18so6910574lfn.3; Mon, 01 Apr 2019 10:29:56 -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; bh=mTWBcU7MyGGtDMi5xFLQknDotm6kaVRUcmWoknbfDdQ=; b=AkIygQbQrcM7zAmflT9K1VA2lOc3/jtRydnzNgCm56o2LPpHtTKXzO+GjiifVsjkyg CgpBj+vIq42BkWqLgteedmFubJHzrKcT7QQEfuF+388fL2CGC9GJFGg5c7XT2iMjUV7U 7DFTOG7lcj2c9hcrv6/LNQ0FpgfR1KcSkvJn7M215XUSaSE2UMHwKvaQi29FsBJR8ig9 aD7H7Pfc4dEFODAxLbxydiQK8/SNfBxIBmVk/ACR9i6ojI9BnKPbnRfNsu5kMgQ6pxl0 JcnLGgrnRDaokSehP6rANjiyieKmbvmbfbWmOS08zh6Er28fOC8D6bkPayCOQFiq4Ih2 +4Ng== 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; bh=mTWBcU7MyGGtDMi5xFLQknDotm6kaVRUcmWoknbfDdQ=; b=BOJ+lBL5gJcqMx2ThWPVzKLX98p1n3Qs3UAd7ErVipwE+3RhTlkz04lVtDYelApTVI XVpeti+gFEb1Qes3ArhWniPihXXlGa4wzool0CLyT+iwETeeXtqu9B8/CezRWLef2boA ckam9JyB/dCE3Q9vu2co0ZAfwn1tkXdlJuCZYEeVmCpbW1x/3WK4Zsgg5z/Kuu2JfWtO k5kTYO3TmEiG/81a/Z5Bv+Xq+GDSX53vwFotI1YaeOsfzf875gg/fqiPbAueZ6Z/tjiP KRpuGuOv82sYFEQeLpI5TLlyKcHkbSGJzkgAX6p9LdGqnfBKVfKMfIBy6YDw0jXoqY4R wXqw== X-Gm-Message-State: APjAAAV34OWXgGqK2NXXeNyPUAGNs+da4OaIFWRnWsFMOT9keknjuq4B 7YaCE0CEildY01yzDHZ7aTLzp2rsJfvsdNglhZCoKsaS X-Google-Smtp-Source: APXvYqwCQFanNi5E3CkhZ16KutHJ5VT7ms/s1u1OOX+Rn55w8KvwmYjWxIhjYVXoSUmy0OIQoahobk1UBqe3AoSN1M4= X-Received: by 2002:a19:a40b:: with SMTP id q11mr33432746lfc.33.1554139794426; Mon, 01 Apr 2019 10:29:54 -0700 (PDT) MIME-Version: 1.0 References: <155413839109.17114.2318273093661309081.idtracker@ietfa.amsl.com> In-Reply-To: <155413839109.17114.2318273093661309081.idtracker@ietfa.amsl.com> From: Badis Djamaa Date: Mon, 1 Apr 2019 19:29:21 +0200 Message-ID: To: core@ietf.org, core-chairs@ietf.org, ali yachir Content-Type: multipart/alternative; boundary="00000000000060cd9605857b5e59" Archived-At: Subject: [core] Fwd: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 17:29:59 -0000 --00000000000060cd9605857b5e59 Content-Type: text/plain; charset="UTF-8" Dear core chairs, members, A new Internet-draft has been uploaded to IETF repository. The draft proposes an announce-based mechanism that builds upon CoAP Group Communication (GroupComm) to discover CoRE Resource Directories (RDs). Looking forward to your comments and suggestions Best, Badis ---------- Forwarded message --------- From: Date: Mon, 1 Apr 2019 at 19:06 Subject: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt To: Badis Djamaa , Ali Yachir A new version of I-D, draft-djamaa-core-proactive-rd-discovery-00.txt has been successfully submitted by Badis Djamaa and posted to the IETF repository. Name: draft-djamaa-core-proactive-rd-discovery Revision: 00 Title: Proactive Discovery of CoRE Resource Directories Document date: 2019-03-31 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-djamaa-core-proactive-rd-discovery-00.txt Status: https://datatracker.ietf.org/doc/draft-djamaa-core-proactive-rd-discovery/ Htmlized: https://tools.ietf.org/html/draft-djamaa-core-proactive-rd-discovery-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-djamaa-core-proactive-rd-discovery Abstract: The CoRE working group has proposed a Resource Directory (RD) solution to facilitate the discovery of the resources provided by constrained sensor and actuator networks. For such a mechanism to be effectively deployable, endpoints must first discover the existence of an RD in the network before being able to exploit its functionalities. This document presents Proactive RD Discovery (PRD); a scalable and effective mechanism to discover RDs. To achieve such qualities, PRD follows an announce-based model that builds upon CoAP Group Communication. PRD aims to provide important performance in terms of energy consumption, generated traffic, expressivity, and RD discovery time. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000060cd9605857b5e59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear core chairs, members,

A= new Internet-draft has been uploaded to=20 IETF repository. The draft proposes an announce-based mechanism that builds= upon CoAP Group Communication (GroupComm) to discover CoRE Resource Direct= ories (RDs).

Looking forward to your comments and = suggestions

Best, Badis

---------- For= warded message ---------
From: <internet-drafts@ietf.org>
Date: M= on, 1 Apr 2019 at 19:06
Subject: New Version Notification for draft-djam= aa-core-proactive-rd-discovery-00.txt
To: Badis Djamaa <badis.djamaa@gmail.com>, Ali Yachir <= ;a_yachir@yahoo.fr>


A new version of I-D, draft-djamaa-core-proactive-rd-discovery-00.txt
has been successfully submitted by Badis Djamaa and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-djamaa-core-proactive-r= d-discovery
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Proactive Discovery of CoRE Resour= ce Directories
Document date:=C2=A0 2019-03-31
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-dj= amaa-core-proactive-rd-discovery-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-djamaa-core-proactive= -rd-discovery/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-djamaa-core-proactive-rd-discovery= -00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-djamaa-core-proac= tive-rd-discovery


Abstract:
=C2=A0 =C2=A0The CoRE working group has proposed a Resource Directory (RD)<= br> =C2=A0 =C2=A0solution to facilitate the discovery of the resources provided= by
=C2=A0 =C2=A0constrained sensor and actuator networks. For such a mechanism= to be
=C2=A0 =C2=A0effectively deployable, endpoints must first discover the exis= tence
=C2=A0 =C2=A0of an RD in the network before being able to exploit its
=C2=A0 =C2=A0functionalities. This document presents Proactive RD Discovery=
=C2=A0 =C2=A0(PRD); a scalable and effective mechanism to discover RDs. To<= br> =C2=A0 =C2=A0achieve such qualities, PRD follows an announce-based model th= at
=C2=A0 =C2=A0builds upon CoAP Group Communication. PRD aims to provide impo= rtant
=C2=A0 =C2=A0performance in terms of energy consumption, generated traffic,=
=C2=A0 =C2=A0expressivity, and RD discovery time.




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

The IETF Secretariat

--00000000000060cd9605857b5e59-- From nobody Mon Apr 1 11:31:12 2019 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 EDD8412054E; Mon, 1 Apr 2019 11:31:08 -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 DTKar3t0NO2k; Mon, 1 Apr 2019 11:31:06 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CE71204FE; Mon, 1 Apr 2019 11:31:05 -0700 (PDT) Received: from [192.168.217.120] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Y1BG6rbHz101J; Mon, 1 Apr 2019 20:31:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190401161239.GC28400@hephaistos.amsuess.com> Date: Mon, 1 Apr 2019 20:31:02 +0200 Cc: draft-ietf-core-coap-pubsub@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 575836260.457303-2028de0c9ce0eaf2c096c54b37c96d48 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190401161239.GC28400@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] pubsub short-review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 18:31:11 -0000 Hi Christian, Thank you for this review. The below comments focus on architectural = and editorial issues in specifying CoAP applications like this; I might = have a separate response on the pubsub application itself later. > (Following parallel discussion in RD, it might be worth reconsidering > whether listing error codes for each operation really has value, = given > the list can not be exhaustive anyway, and regular CoAP processing > needs to be applied). Indeed. However, if it is the normal result of an application state = that results in an error response, it probably is worth to point that = out in the definition of the application. > * The create-on-publish operation is executed using PUT, which MUST be > idempotent according to RFC7252 Section 5.1. Returning 2.01 Created = on > first put and 2.04 Changed on the second put is not exactly > idempotent. Idempotency in a REST context is with respect to the state on the = server, not with respect to the response code. Trivially, doing a = DELETE will get you a 2.02 only on the first request and a 4.04 on all = following ones. > A client behind an optimized intermediary or library may > receive a 2.04 even on creation if one of the components forgoes > message deduplication as given license to do in RFC7252 Section 4.5. This is indeed an idiosyncrasy of CoAP over UDP, but note that something = related happens with HTTP if the TCP connection breaks and you just = don=E2=80=99t know whether the first request in an idempotent series was = actually executed. > [don=E2=80=99t do] phrasing requirements from > other places into normative languages and IMO overspecifying. +1 It is not always wrong to remind the reader of a requirement already = posed by a standard that is being used as a dependency, but this always = MUST be clearly identified as a reminder and as following from the other = standard. Re-specifying bears the danger of creating something different, which = forks the original standard. (Compare the way ABNF was used in RFC 5988 = and is used in RFC 8288 for an example of avoiding the problem.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 1 22:40:29 2019 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 42E3512004A for ; Mon, 1 Apr 2019 22:40:28 -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, 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 Z5RrsCUijJuF for ; Mon, 1 Apr 2019 22:40:24 -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 7362C120049 for ; Mon, 1 Apr 2019 22:40:24 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7349F40614; Tue, 2 Apr 2019 07:40:21 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7522436; Tue, 2 Apr 2019 07:40:20 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [213.208.157.36]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 72ACB74; Tue, 2 Apr 2019 07:40:18 +0200 (CEST) Received: (nullmailer pid 26795 invoked by uid 1000); Tue, 02 Apr 2019 05:40:17 -0000 Date: Tue, 2 Apr 2019 07:40:17 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Badis Djamaa Cc: core@ietf.org, ali yachir Message-ID: <20190402054015.GA22410@hephaistos.amsuess.com> References: <155413839109.17114.2318273093661309081.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 05:40:28 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Badis, On Mon, Apr 01, 2019 at 07:29:21PM +0200, Badis Djamaa wrote: > A new Internet-draft has been uploaded to IETF repository. The draft > proposes an announce-based mechanism that builds upon CoAP Group > Communication (GroupComm) to discover CoRE Resource Directories (RDs). thanks for sending this document; it describes a strategy I have not considered before. On first reading, some questions and remarks came up: * Ad Approach 6: This approach does not necessarily mean that the RD is deployed on the 6LBR, just that it can be discovered from it (eg. the 6LBR may announce `;rt=3Dcore.rd`. Same goes for approach 7. * Ad 4.1.1: Where would the rd template value come from? * The DA generation process looks like every device is supposed to be a simple RD (that may be only capable of accepting a single registration, which is that of the actual ID), that is then replicated. Maintaining such replication seems to me to be quite a task for small nodes, especially if they're supposed to use the registration update interface and thus remember locations for each sub-PRD they registered to (though I'm not sure what is intended here, "SHOULD only contain the content and parameters that have been changed" seems to imply registration update, while 4.1.1 describes the registration interface which can't rely on previous registrations). The document may benefit from exploring alternatives here (even if only to confirm the conclusion that the approach taken is the right one), like using the Simple Registration interface (would answer the question ad 4.1.1) or setting the announcements up as nontraditional responses[1] (eg. notifications about an unspoken request to GET /.well-known/core?rt=3Dcore.rd. I can't tell whether that'd even be a good idea, that's yet to be seen). * I like to keep the resource directory as little a special-case as possible (see RD Section 3.1). In later stages of this document, it may be worth looking into whether there is anything in particular about RD announcements in it as compared to general link announcments. (Sure, there comes a point when not all resources can be announced proactively, and it makes sense to announce an RD as that provides all the other lookups, but maybe a single service is queried so often by each and every joining node that it makes sense to announce an RD *and* another link or two?) Best regards Christian [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ibTvN161/egqYuK8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyi9bwACgkQOY0REtOk veGLOw/9EoO/fOVixPdS64XRSWKauR4HXpmrR5WSHzs+KqPfB6iSNTnZ2fdoqjF0 NF3wVtngx9nL8vjZSwD3SdkuNJTUFl6XgxwMbjdeb7YN4xHyYZRVsqIhYDs4AP9t kVTvmpNON+Wu+l+wgcdszo4xz7JNYzl84jKTAh5O4edCc/L5OyqAumCyseb+ermG WP9q7scsP0MlDs96Ldx3U/7KEDCWqD/RHsNKee5eoYA9VY5xrt67rP4bJ4G/C79z MHKYTQO14mhsLVDfde1Z+GcQkuYOL3FtmQdcarc672nTkedyu7v7ZPJeWK2TGRyB XtBqP1q1ae7GFmXUr/uILcYqlxm1Jm77sRnB2k/c1cSFYz5N06k+lVfO58XeAJZ7 axIJjpV5p2gRNWwPQ/sAMUsepVX8kWoLOZjeeGqdzvFxIWGCRfJZLlSLe+qsvC/Q OMKtFd6i9W4hOI1N3uCkq2I3jbdwbxMkJ5g9MI0muZ2hzbngTivUNuAdymozHQ8T qpMVNgdDWxOrMa1ChjQResVrSUPOMXyA0MQxvYn1J+eJfmLT9ZIlgGrXbLyGWVgm i3/5NiyRdgTwTU10epo2Q/z1QJ7Ik7SOsiIi/NDfYKhIOY5yzBUk73daqyF9iWKe hqUF/uOuIykLYoJfgIn3N163cdlVe4aGg0bBSq3vh0K62Q0/EOg= =mf7l -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From nobody Tue Apr 2 02:19:12 2019 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 EC2A21200A2; Tue, 2 Apr 2019 02:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 phKEADAtLYmA; Tue, 2 Apr 2019 02:19:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 869E412009A; Tue, 2 Apr 2019 02:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F072E660260; Tue, 2 Apr 2019 12:18:59 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFxdeGPmZdHt; Tue, 2 Apr 2019 12:18:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id CF15666012B; Tue, 2 Apr 2019 12:18:57 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> Date: Tue, 2 Apr 2019 12:18:58 +0300 Cc: "secdispatch@ietf.org" , core Content-Transfer-Encoding: quoted-printable Message-Id: <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> To: Carsten Bormann , Roman Danyliw X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Secdispatch] EDHOC Summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 09:19:04 -0000 FWIW, I had not had time to look at this during the IETF week, nor did I = have an opportunity to be at the CORE WG during the IETF. But I support = Roman's conclusion below: >> -----[ Conclusion >>=20 >> There appears to be an understood and scoped problem that is feasible = to engineer. Among the available starting points to address the problem = defined in question #1, EDHOC presents a viable choice. =20 >>=20 >> Chartering a narrowly scoped, short-lived WG in this space with EDHOC = as a starting point seems to be an attractive path forward, but we would = like to receive community feedback on the degree of support for this = approach. Jari From nobody Tue Apr 2 06:37:03 2019 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 BBA741200DB; Tue, 2 Apr 2019 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kkfnFz7S; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dfCA2Ns8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNg3-a6ikOkB; Tue, 2 Apr 2019 06:36:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F091200A1; Tue, 2 Apr 2019 06:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1208; q=dns/txt; s=iport; t=1554212211; x=1555421811; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4L9IPmVK2rtMbxkf3IejMVzYObwcHPOTZQL0ET3MXh4=; b=kkfnFz7SBoZtbGO3nkLQQ2yzKnEFKmItXCp7mNhKiRM86zo4WZVe23il wBx8Tk7aAz69qXewkiPwPqqGheMo5t0JwsNwEGhyQRlwH2O2ekpgvlBQF jG6uLEm9qLBlA10U0l5qMpd0L56vXPPyrIYhwBLqZBBa6xqPjJFh5IG6e U=; IronPort-PHdr: =?us-ascii?q?9a23=3A24H4IxBpKaD9EagN8PpVUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAB0ZKNc/4kNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgT1QA2h0BAsnh1UDjzWCV36WE4EugSQ?= =?us-ascii?q?DVA4BARgLCYRAAoU8IjYHDQEBAwEBCQEDAm0cDIVKAQEBAQMBATgGAQEsCwE?= =?us-ascii?q?LBAIBCBEEAQEfECcLHQgCBAENBQgMgw+BXQMVAQIMolwCihSCIIJ5AQEFhRE?= =?us-ascii?q?YggwDBYEvAYsyF4FAP4ERRoIXNT6CYQEBgWODOYImpVcJApQAlDiLRpNcAgQ?= =?us-ascii?q?CBAUCDgEBBYFUATCBVnAVO4JsggoMF4NLhRSFP3KBKI8xAQE?= X-IronPort-AV: E=Sophos;i="5.60,300,1549929600"; d="scan'208";a="253974075" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 13:36:50 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x32DaoV3031188 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 13:36:50 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 08:36:49 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 08:36:49 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 09:36:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wVeAxfFbXIJnjvnjY44Zq5o3/9eQcdM1QXLsNkkiIGA=; b=dfCA2Ns84cwDkMpbSI4GDfyfCh2be9tdFgTIy3BF7xbcP+gT2KV2oHahlGoVS9e/BRJ1nzpkHUh6f9qf/uWHffdNnE0OmKHQZ5nYjjZXYYlP/EIKB64BJgO5eNdNRJTpAsKeWV3hCWjGgJOnlRtl3dKCCX5F1BEWbcIbah8EsJk= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3886.namprd11.prod.outlook.com (20.179.150.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Tue, 2 Apr 2019 13:36:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 13:36:47 +0000 From: "Pascal Thubert (pthubert)" To: Jari Arkko , Carsten Bormann , "Roman Danyliw" CC: "secdispatch@ietf.org" , core Thread-Topic: [core] [Secdispatch] EDHOC Summary Thread-Index: AQHU5hFZ2mc9hpxHAE2la3IM1m7wUqYonhEAgABHTHA= Date: Tue, 2 Apr 2019 13:36:37 +0000 Deferred-Delivery: Tue, 2 Apr 2019 13:36:05 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> In-Reply-To: <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4713b8a4-e963-4a8a-0b34-08d6b77040fa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3886; x-ms-traffictypediagnostic: MN2PR11MB3886: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(136003)(396003)(189003)(13464003)(199004)(7696005)(110136005)(6506007)(53546011)(54906003)(9686003)(6246003)(6306002)(68736007)(53936002)(229853002)(102836004)(71190400001)(186003)(8936002)(316002)(6436002)(76176011)(71200400001)(2906002)(97736004)(55016002)(8676002)(81156014)(81166006)(99286004)(14454004)(6116002)(6666004)(46003)(305945005)(486006)(52536014)(7736002)(478600001)(25786009)(11346002)(476003)(966005)(446003)(33656002)(4326008)(86362001)(5660300002)(106356001)(105586002)(256004)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3886; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7ETSJbSkI2I2REwxL2LViQw84SBqnd78bZbvt4awhVZTSewelX4cHJKvdtN/noIcV32eGg/vBTNXzAtgP25ih4HCRQ9OY+tmsl2a+tBsq/fvfVF3M86vcZ9EfOWorHvL8o249htLdkCGX/b3pWRWdL/36R43sLBGOZTNkA2gV0Cn9eN2tzbV/aJz9yNkf6oZ8NEEHawkDw2BJyStT5x0PNvCSBzHoCwONaRvGH9H+z0kxiq5tKlU9h7jxonnSXQ+Gyuf3y5tIOEfF+Y3QhuvqatCV0SRtJRF16yXPFJRSWA1k9zFf9rxNtrVka+VdBBSCCCiTmpzhjllW3AJ0K/230a916Q0GX/drG/r4LVVzvj7NbrEpLKS8WHHMoaP7xDpQsWfTepTtOObGb5OzfdFVjAV5UImBBuGnr4ct5rjYYo= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4713b8a4-e963-4a8a-0b34-08d6b77040fa X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 13:36:47.2031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3886 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [core] [Secdispatch] EDHOC Summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:36:54 -0000 Unsurprisingly I'm on the same page; All the best, Pascal > -----Original Message----- > From: core On Behalf Of Jari Arkko > Sent: mardi 2 avril 2019 11:19 > To: Carsten Bormann ; Roman Danyliw > Cc: secdispatch@ietf.org; core > Subject: Re: [core] [Secdispatch] EDHOC Summary >=20 > FWIW, I had not had time to look at this during the IETF week, nor did I = have > an opportunity to be at the CORE WG during the IETF. But I support Roman'= s > conclusion below: >=20 > >> -----[ Conclusion > >> > >> There appears to be an understood and scoped problem that is feasible = to > engineer. Among the available starting points to address the problem def= ined > in question #1, EDHOC presents a viable choice. > >> > >> Chartering a narrowly scoped, short-lived WG in this space with EDHOC = as a > starting point seems to be an attractive path forward, but we would like = to > receive community feedback on the degree of support for this approach. >=20 > Jari >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 2 07:43:38 2019 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 0FA71120124; Tue, 2 Apr 2019 07:43:36 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155421621598.6254.5836620520696023721@ietfa.amsl.com> Date: Tue, 02 Apr 2019 07:43:36 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 14:43:36 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Filename : draft-ietf-core-yang-cbor-09.txt Pages : 41 Date : 2019-04-02 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-09 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-09 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 Apr 2 11:43:00 2019 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 25AF7120170 for ; Tue, 2 Apr 2019 11:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 1_7d1_C6pDKZ for ; Tue, 2 Apr 2019 11:42:55 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 6C2EC120192 for ; Tue, 2 Apr 2019 11:42:54 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id h16so12504344ljg.11 for ; Tue, 02 Apr 2019 11:42:54 -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=oZGPXJtwNJjT47iO0uZ2p5yW/nxf6iEQUk2JApmcZoQ=; b=kBMP2JmgYs/K5tjdpRuxubQjjDPgeGgTKxZD3ciN46OHV+blhk3HofQzdBGvcW2+cs KfzpgIsD32Mi61GTyngH6qjBujzdiYIfZriqdLsPMibR2upbqJHxVuKRsE9jlVdTgDR/ FK5vqPY303C5s6imWqxndWFtcsH3Zp99et8xvLOHL9f7VO46/LYsoC4JwcGp0PKRbniZ 70G67ntlNKQ+/6eYjMXYLvOE+lXM7znNZt7BHhU29X65A+tl2kaMoUoN1Ik5I7S7vs+f D+LAHRpnB9f6ZsJikRl3IrLENyR1n9eIhJVWTe/aNfJI+FGrPswb8nI+TT2HzrPK8b+D X05Q== 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=oZGPXJtwNJjT47iO0uZ2p5yW/nxf6iEQUk2JApmcZoQ=; b=hjZ3ansgy0a30n/eJwP0JywG+6zDMyfVCRGPm/KYeCPCVtp43jyyCwFvJMGP5gwZBt Wy/iThjUqYftbI9QUN+oZaF5GuDn8KbNnPzFSaNjF741gsjB/ERp/DH0FEO3bRaxNZuA jcwRw0kK56ddW0xrQJjj1Xu8VKB2zhtjU5M0LFl1X1mkmJSj7b2g/5pK49eqLu/3Koti qqx4Jq/wpHXsMx6/ZkZ1O/YPIFjnpxgnjEL0IO0GCJ+Geb4ZXwAVYEZ28zxcicM17grs wEMeVvBYfVGnTZctqBJZSmgcliYDE19rgn8oAMgtN8M8QZtWEzZCv9+cHIgIioVPquRh arTw== X-Gm-Message-State: APjAAAUZGcC+AuvNUYRRnljU5OLlYn+bFnP4I2piBTw0NlcyISjWBQPx FlZYmLiJgOLvO1XeLRHC4+2RpJsO/jdAA1nEfQT7ePMnnvY= X-Google-Smtp-Source: APXvYqzwW8JgDssfC7rgmlMOQs48uPJxR8S1nayzB3c8C5ZVid+bgHHTB+n7BXalDYyDf+MZCnePia5eS4yiLgDYQVk= X-Received: by 2002:a2e:b01a:: with SMTP id y26mr21647873ljk.38.1554230572661; Tue, 02 Apr 2019 11:42:52 -0700 (PDT) MIME-Version: 1.0 References: <155413839109.17114.2318273093661309081.idtracker@ietfa.amsl.com> <20190402054015.GA22410@hephaistos.amsuess.com> In-Reply-To: <20190402054015.GA22410@hephaistos.amsuess.com> From: Badis Djamaa Date: Tue, 2 Apr 2019 20:42:19 +0200 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: core@ietf.org, ali yachir Content-Type: multipart/alternative; boundary="0000000000002ec48e0585908155" Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 18:42:58 -0000 --0000000000002ec48e0585908155 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Christian for your quick and thorough review, please find replies inline On Tue, 2 Apr 2019 at 07:40, Christian Ams=C3=BCss = wrote: > Hello Badis, > > On Mon, Apr 01, 2019 at 07:29:21PM +0200, Badis Djamaa wrote: > > A new Internet-draft has been uploaded to IETF repository. The draft > > proposes an announce-based mechanism that builds upon CoAP Group > > Communication (GroupComm) to discover CoRE Resource Directories (RDs). > > thanks for sending this document; it describes a strategy I have not > considered before. > > On first reading, some questions and remarks came up: > > * Ad Approach 6: This approach does not necessarily mean that the RD is > deployed on the 6LBR, just that it can be discovered from it (eg. the > 6LBR may announce `;rt=3Dcore.rd`. Same goe= s > for approach 7. > The text in the RD draft seems to indicate that the "(6LBR) can act as a resource directory". Thus, the 6LBR address can be announced in the ABRO and confirmation of RD function can be done by unicasting "coap://[6LBR]/.well-known/core?rt=3Dcore.rd*". Otherwise, how would the RD be announced to the 6LBR (not mentioned in the RD draft )? > > * Ad 4.1.1: Where would the rd template value come from? > > In the current version, the rd template value may be assumed a default location, for instance, "core-rd". The Location-URI Template would be then /core-rd/ep where ep comes from the RD's "ep" attribute contained in the registration request, which is unique per RD. Another possibility is to locate the posted RD resource under well-known/core/ep at each device. What is your take on this? * The DA generation process looks like every device is supposed to be a > simple RD (that may be only capable of accepting a single > registration, which is that of the actual ID), that is then > replicated. > > Maintaining such replication seems to me to be quite a task for small > nodes, especially if they're supposed to use the registration update > interface and thus remember locations for each sub-PRD they registered > to (though I'm not sure what is intended here, "SHOULD only contain > the content and parameters that have been changed" seems to imply > registration update, while 4.1.1 describes the registration interface > which can't rely on previous registrations). > > True, but DA is only generated by the RD and forwarded using CoAP Group Communication. Devices do no replication tasks. Also, very constrained devices (section 5.2 of RD), may simply ignore the received DA (see section 3) Also, the current version of PRD does not use a separate resource update interface. Both the first registration (which doesn't rely on previous registrations) and periodic updates sent by RDs (relying on previous registrations) use the registration interface. The difference is that in the latter, the optional unchanged parameters and payload are not POSTed. Processing of the received DA, for both cases, is specified in section 4.1.2. The document may benefit from exploring alternatives here (even if > only to confirm the conclusion that the approach taken is the right > one), like using the Simple Registration interface (would answer the > question ad 4.1.1) or setting the announcements up as nontraditional > responses[1] (eg. notifications about an unspoken request to GET > /.well-known/core?rt=3Dcore.rd. I can't tell whether that'd even be a > good idea, that's yet to be seen). > > The Simple Registration (SR) interface and Nontraditional Responses (NR) need the devices to be aware of the RD location. Announcing RD's location and functionalities, in the first place, is a part of the draft objectives. For the following announcements, I can see a use of SR and NR, however, I do not see how they can be used for the first announcement ? * I like to keep the resource directory as little a special-case as > possible (see RD Section 3.1). In later stages of this document, it > may be worth looking into whether there is anything in particular > about RD announcements in it as compared to general link announcments. > (Sure, there comes a point when not all resources can be announced > proactively, and it makes sense to announce an RD as that provides all > the other lookups, but maybe a single service is queried so often by > each and every joining node that it makes sense to announce an RD > *and* another link or two?) > Thank you for this suggestion, we will consider it in future versions. Can you please indicate some key services that need to be announced. > Best regards > Christian > > [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00 > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom > All the best, Badis --0000000000002ec48e0585908155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Thank you Christian for your quick = and thorough review, please find replies inline

<= /div>
On Tu= e, 2 Apr 2019 at 07:40, Christian Ams=C3=BCss <christian@amsuess.com> wrote:
Hello Badis,

On Mon, Apr 01, 2019 at 07:29:21PM +0200, Badis Djamaa wrote:
> A new Internet-draft has been uploaded to IETF repository. The draft > proposes an announce-based mechanism that builds upon CoAP Group
> Communication (GroupComm) to discover CoRE Resource Directories (RDs).=

thanks for sending this document; it describes a strategy I have not
considered before.

On first reading, some questions and remarks came up:

* Ad Approach 6: This approach does not necessarily mean that the RD is
=C2=A0 deployed on the 6LBR, just that it can be discovered from it (eg. th= e
=C2=A0 6LBR may announce `<coap://some.example.com/rd>;rt=3Dcore= .rd`. Same goes
=C2=A0 for approach 7.

=C2=A0The text i= n the RD draft seems to indicate that the "(6LBR) can act as a resourc= e
=C2=A0 directory". Thus, the 6LBR address can be announced in th= e ABRO and
=C2=A0 confirmation of RD function can be done by unicasting=
=C2=A0 "coap://[6LBR]/.well-known/core?rt=3Dcore.rd*".
=
=C2=A0 Otherwise, how would the RD be announced to the 6LBR (not menti= oned in=20 the RD draft=20 )?=C2=A0

* Ad 4.1.1: Where would the rd template value come from?

=C2=A0 In the current version, the rd template value = may be assumed a default location,
=C2=A0 for instance, "core-rd&q= uot;. The Location-URI Template would be then /core-rd/ep where
=C2=A0 = ep comes from the RD's "ep" attribute contained in the regist= ration request,
=C2=A0 which is unique per RD. Another possibility is t= o locate the posted RD resource
=C2=A0 under well-known/core/ep at each= device.
=C2=A0 What is your take on this?=C2=A0=C2=A0=C2=A0
<= br>
* The DA generation process looks like every device is supposed to be a
=C2=A0 simple RD (that may be only capable of accepting a single
=C2=A0 registration, which is that of the actual ID), that is then
=C2=A0 replicated.

=C2=A0 Maintaining such replication seems to me to be quite a task for smal= l
=C2=A0 nodes, especially if they're supposed to use the registration up= date
=C2=A0 interface and thus remember locations for each sub-PRD they register= ed
=C2=A0 to (though I'm not sure what is intended here, "SHOULD only= contain
=C2=A0 the content and parameters that have been changed" seems to imp= ly
=C2=A0 registration update, while 4.1.1 describes the registration interfac= e
=C2=A0 which can't rely on previous registrations).

=C2=A0True, but DA is only generated by the RD and fo= rwarded using CoAP Group
=C2=A0 Communication. Devices do no= replication tasks. Also, very constrained devices
=C2=A0 (section 5.2 = of RD), may simply ignore the received DA (see section 3)

=C2= =A0 Also, the current version of PRD does not use a separate resource updat= e
=C2=A0 interface. Both the first registration (which doesn= 't rely on previous registrations)
=C2=A0 and periodic updates sent= by RDs (relying on previous registrations)
=C2=A0 use the registration= interface. The difference is that in the latter,
=C2=A0 the optional u= nchanged parameters and payload are not POSTed. Processing of
=C2=A0 the= received DA, for both cases, is specified in section 4.1.2.

=C2=A0 The document may benefit from exploring alternatives here (even if =C2=A0 only to confirm the conclusion that the approach taken is the right<= br> =C2=A0 one), like using the Simple Registration interface (would answer the=
=C2=A0 question ad 4.1.1) or setting the announcements up as nontraditional=
=C2=A0 responses[1] (eg. notifications about an unspoken request to GET
=C2=A0 /.well-known/core?rt=3Dcore.rd. I can't tell whether that'd = even be a
=C2=A0 good idea, that's yet to be seen).

=C2=A0The Simple Registration (SR) interface and Nont= raditional
=C2=A0 Responses (NR) need the devices to be aware of the RD =
=C2=A0 location. Announcing RD's location and functionalities, in t= he first place,
=C2=A0 is a part of the draft objectives. For the follo= wing announcements,
=C2=A0 I can see a use of SR and NR, however, I do = not see how they can be used
=C2=A0 for the first announcement ?

* I like to keep the resource directory as little a special-case as
=C2=A0 possible (see RD Section 3.1). In later stages of this document, it<= br> =C2=A0 may be worth looking into whether there is anything in particular =C2=A0 about RD announcements in it as compared to general link announcment= s.
=C2=A0 (Sure, there comes a point when not all resources can be announced =C2=A0 proactively, and it makes sense to announce an RD as that provides a= ll
=C2=A0 the other lookups, but maybe a single service is queried so often by=
=C2=A0 each and every joining node that it makes sense to announce an RD =C2=A0 *and* another link or two?)
=C2=A0
=C2=A0Thank you for this suggestion, we will consider it in future versi= ons. Can you
=C2=A0 please indicate some key services that n= eed to be announced.
=C2=A0
Best regards
Christian

[1]: https://tools.ietf.org/html/draft-bo= rmann-core-responses-00

--
To use raw power is to make yourself infinitely vulnerable to greater power= s.
=C2=A0 -- Bene Gesserit axiom

All the b= est,
Badis
--0000000000002ec48e0585908155-- From nobody Wed Apr 3 06:35:17 2019 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 4101612013C; Wed, 3 Apr 2019 06:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, 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=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 aqI9pupa0PcG; Wed, 3 Apr 2019 06:35:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60060.outbound.protection.outlook.com [40.107.6.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5979D1200B5; Wed, 3 Apr 2019 06:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=91CCTFF1vHJE5HXiWZqmIBSPXbkQKTBvGbP8wXxndDU=; b=IepdIvdDXl/yHMyMcPr5nA1f9oMiA03NN7uQlYRviOq43m8AG+f0GQJOJ0uu3UfFCS3Aow53jkXCxloqnOlCnqWOfA6t6oeI7SCrAaQwPr1YhCDXP+kDsbjc/EaKxog3UynQuklX14joPEB0tw+aUL5BJLyeTslUQQchiF7qacU= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2684.eurprd07.prod.outlook.com (10.168.183.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Wed, 3 Apr 2019 13:35:06 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1771.011; Wed, 3 Apr 2019 13:35:06 +0000 From: Francesca Palombini To: Ace Wg , "core@ietf.org" Thread-Topic: New Version Notification for draft-palombini-ace-coap-pubsub-profile-04.txt Thread-Index: AQHU6iFUWr25cwLiJEGz6zrjLxGdy6YqkVyA Date: Wed, 3 Apr 2019 13:35:06 +0000 Message-ID: <6F661F7B-8159-4253-B526-BA0BF4FF1ECF@ericsson.com> References: <155429817346.5295.16132999392792189014.idtracker@ietfa.amsl.com> In-Reply-To: <155429817346.5295.16132999392792189014.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: badcb3b4-6000-41dc-5ecc-08d6b8392f49 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2684; x-ms-traffictypediagnostic: HE1PR0701MB2684: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(366004)(136003)(39860400002)(199004)(189003)(53754006)(25786009)(8676002)(6246003)(81156014)(36756003)(2501003)(7736002)(305945005)(8936002)(81166006)(6486002)(15650500001)(6116002)(3846002)(86362001)(11346002)(486006)(14454004)(478600001)(2616005)(14444005)(446003)(82746002)(476003)(186003)(2906002)(66066001)(316002)(105586002)(450100002)(6506007)(97736004)(229853002)(102836004)(966005)(256004)(33656002)(76176011)(6436002)(106356001)(110136005)(99286004)(44832011)(71200400001)(83716004)(71190400001)(5660300002)(6306002)(53936002)(6512007)(68736007)(26005)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2684; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: b25Ig95HGLegdS5wVKjgAlUaINTH0nlVyBCzoY3Jvs3r4ICPyFfm88Zu/x0NiJFfFMij2LEBaGlybrc2q+EqwEbyACR1NOkWztq/9LQUY4n2jUoSKekMDgPYkJQ/FPCkPJWzSModf/3fQzqep0T8vFDTtkcrQbWBOwnsUdSEOKpp6QCssD8VfLvUgsRWbQMWmIL9zSe3mwqrybRiyi/K1wIHNFnL0rRui68cyoQmDJWBEpQHT502rFMl0DstgnM0ga+2rgSvciK+A/pazuFMNHG0V28PFjTw4/8nczcwJXvnZRNfmbuawCEjXebnNTVvicx0f51M/O04n5rC0FmjS/e/PNVP/7Vdor3VbJeHdYa0vMyvAZwwP+AG3fYc5jFA6nDamgcWIuzdj0bztDsFGPRU/fk2GOBY4JV6DjQ7eeY= Content-Type: text/plain; charset="utf-8" Content-ID: <1FA35918DEFEB449B7430668BE073E56@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: badcb3b4-6000-41dc-5ecc-08d6b8392f49 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 13:35:06.4176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2684 Archived-At: Subject: Re: [core] New Version Notification for draft-palombini-ace-coap-pubsub-profile-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 13:35:12 -0000 SGkgYWxsLA0KDQpBcyBJIG9ic2VydmVkIGludGVyZXN0IGFib3V0IHNlY3VyaXR5IGZvciBwdWJz dWIgaW4gYm90aCBBY2UgYW5kIENvUkUgZHVyaW5nIGxhc3QgbWVldGluZywgSSB0aG91Z2h0IG5v dyB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byBzdWJtaXQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgY29h cC1wdWJzdWIgcHJvZmlsZSBvZiBBQ0UuDQoNClRoaXMgdXBkYXRlIGFsaWducyB0aGUgZG9jdW1l bnQgdG8gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtYWNlLWtleS1ncm91cGNvbW0g YW5kIGZpeGVzIG1pbm9yIGVkaXRvcmlhbHMuDQoNCkZlZWRiYWNrIGlzIHdlbGNvbWUhDQoNClRo YW5rcywNCkZyYW5jZXNjYQ0KDQrvu79PbiAwMy8wNC8yMDE5LCAxNToyOSwgImludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICAN CiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1 Yi1wcm9maWxlLTA0LnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg RnJhbmNlc2NhIFBhbG9tYmluaSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3NpdG9y eS4NCiAgICANCiAgICBOYW1lOgkJZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9m aWxlDQogICAgUmV2aXNpb246CTA0DQogICAgVGl0bGU6CQlDb0FQIFB1Yi1TdWIgUHJvZmlsZSBm b3IgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmly b25tZW50cyAoQUNFKQ0KICAgIERvY3VtZW50IGRhdGU6CTIwMTktMDQtMDMNCiAgICBHcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOgkJMTYNCiAgICBVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBhbG9tYmluaS1h Y2UtY29hcC1wdWJzdWItcHJvZmlsZS0wNC50eHQNCiAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1 Yi1wcm9maWxlLw0KICAgIEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9maWxlLTA0DQogICAgSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcGFs b21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9maWxlDQogICAgRGlmZjogICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVi c3ViLXByb2ZpbGUtMDQNCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIHNwZWNpZmlj YXRpb24gZGVmaW5lcyBhIHByb2ZpbGUgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZA0KICAgICAgIGF1 dGhvcml6YXRpb24gZm9yIHB1Ymxpc2hlcnMgYW5kIHN1YnNjcmliZXJzIGluIGEgcHViLXN1YiBz ZXR0aW5nDQogICAgICAgc2NlbmFyaW8gaW4gYSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCwgdXNp bmcgdGhlIEFDRSBmcmFtZXdvcmsuICBUaGlzDQogICAgICAgcHJvZmlsZSByZWxpZXMgb24gdHJh bnNwb3J0IGxheWVyIG9yIGFwcGxpY2F0aW9uIGxheWVyIHNlY3VyaXR5IHRvDQogICAgICAgYXV0 aG9yaXplIHRoZSBwdWJsaXNoZXIgdG8gdGhlIGJyb2tlci4gIE1vcmVvdmVyLCBpdCByZWxpZXMg b24NCiAgICAgICBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBmb3IgcHVibGlzaGVyLWJyb2tl ciBhbmQgc3Vic2NyaWJlci1icm9rZXINCiAgICAgICBjb21tdW5pY2F0aW9uLg0KICAgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0K ICAgIA0KICAgIA0KDQo= From nobody Wed Apr 3 18:42:44 2019 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 14F1C120071; Wed, 3 Apr 2019 18:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lWit8lPSaXZT; Wed, 3 Apr 2019 18:42:41 -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 C868C120003; Wed, 3 Apr 2019 18:42:40 -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.1395.4; Wed, 3 Apr 2019 18:42:34 -0700 From: Jim Schaad To: CC: Date: Wed, 3 Apr 2019 18:42:31 -0700 Message-ID: <003201d4ea87$acb73780$0625a680$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdTqhNNyNWeMmgN+Rsq71GPkqAXXZA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Mail regarding draft-ietf-ace-key-groupcomm X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 01:42:43 -0000 Some additional things that need to be thought about. 1. Someplace as part of the re-key discussions there ought to be some commentary on the wisdom of rate limiting the frequency of doing re-keying operations. 2. I think that there should be an optional parameter that says "If this much time has elapsed since the last time you checked, see if the group id has changed." This would be combined with a polling client to ensure that they check for an updated key context before doing some operation. 3. What happens in the following situations: a) The key context is changed between a request being sent and the server receiving the request. This could just be because the sender did not get the notification of the key context changing. b) The response takes "a while" to generate and the key context is changed after the request is received, but before the response is sent. c) The key context is changed in the middle of a block-wise transfer. Jim From nobody Sat Apr 6 02:26:49 2019 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 1EEA7120316; Sat, 6 Apr 2019 02:26:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: draft-ietf-core-multipart-ct.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <155454280808.21871.333722671657907840@ietfa.amsl.com> Date: Sat, 06 Apr 2019 02:26:48 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-multipart-ct-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 09:26:48 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-multipart-ct-03 Reviewer: Stewart Bryant Review Date: 2019-04-06 IETF LC End Date: 2019-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Apart from one figure that was difficult to understand and some trivial nits this is well written and is ready for publication. Major issues: None Minor issues: __________ __________ __________ | | | | | | ---->| 2.05 |---->| 2.05 / |---->| 4.xx / | | Pending | | 2.03 | | 5.xx | |__________| |__________| |__________| ^ \ \ ^ \ ^ \__/ \ \___/ / \_______________________/ Figure 2: Sequence of Notifications: SB> Not my specialty, but I don't see what message gets sent SB> to who in the above and RFC7641 has no similar diagram. Nits/editorial comments: accompanying it. In such a case, the sequence in which these occur may not be relevant to the application. This specification allows to SB> typo - word missing indicate that an optional part is not present by substituting a null value for the representation of the part. ========== The collection is encoded as a CBOR [RFC7049] array with an even SB> CBOR needs expanding on first use (it is not on the well known list) number of elements. ========== Person & email address to contact for further information: iesg&ietf.org SB> Shouldn't that be iesg@ietf.org? ========== From nobody Sat Apr 6 17:12:29 2019 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 9CB04120091; Sat, 6 Apr 2019 17:12:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Scott Bradner via Datatracker To: Cc: draft-ietf-core-multipart-ct.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Scott Bradner Message-ID: <155459594857.21805.15546489930064339722@ietfa.amsl.com> Date: Sat, 06 Apr 2019 17:12:28 -0700 Archived-At: Subject: [core] Opsdir last call review of draft-ietf-core-multipart-ct-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 00:12:29 -0000 Reviewer: Scott Bradner Review result: Ready This is an OPS-DIR review of Multipart Content-Format for CoAP . This ID defines application/multipart-core, an application-independent media-type that can be used to combine representations of zero or more different media types into a single message providing a more efficient encoding. As such, the ID does not have any direct operational impacts. The ID is well written and provides a clear description of the media-type. From nobody Mon Apr 8 08:40:45 2019 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 D6FB91201C0; Mon, 8 Apr 2019 08:40:43 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155473804380.14547.8653825885414663414@ietfa.amsl.com> Date: Mon, 08 Apr 2019 08:40:43 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 15:40:44 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Filename : draft-ietf-core-yang-cbor-10.txt Pages : 42 Date : 2019-04-08 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-10 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 Apr 8 14:30:43 2019 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 C3073120346 for ; Mon, 8 Apr 2019 14:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kqzbUJ8EFC4X for ; Mon, 8 Apr 2019 14:30:39 -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 C24AD120089 for ; Mon, 8 Apr 2019 14:30:38 -0700 (PDT) Received: from Jude (73.109.61.140) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Apr 2019 14:29:54 -0700 From: Jim Schaad To: Date: Mon, 8 Apr 2019 14:29:51 -0700 Message-ID: <007e01d4ee52$34d796a0$9e86c3e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdTuTrtyLsvZFxlwS3u5xL0Gj0pgRg== Content-Language: en-us X-Originating-IP: [73.109.61.140] Archived-At: Subject: [core] Security Model and other issues for group messaging X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 21:30:41 -0000 I have been going through the design process for getting software running for Montreal and I have come across the following issues that I think need some discussion. Some of these may just need clarification in documents but other are more substantive. It took me a while to determine that one of the strange issues I was having is that when looking just at the multicast case my mental model of who was making the decisions on if access was allowed did not seem to make a good match to what was being documented. I rather expected that all of the ACL decisions were going to be made on the AS and none on the KDC. This meant that the inclusion of scope in all of the messages was redundant if sending messages to a per group resource. Part of the questions involved here are who does the configuration for what key groups are associated with what application groups. I was always thinking of a single key group which was identified by the AS and sent to the KDC without the KDC needing to know the details of multiple resources for that key group. This of course does not match the model in the document. Some text on what model is being laid out is probably worthwhile. There was discussions for the ACE OAuth document about how to handle multiple access tokens for a single entity that need to be looked at in the context of a KDC. The current rule is that a resource server needs only to keep one token for any single supplicant. This was mostly discussed in the context of adding and subtracting privileges for the supplicant. It may be that this also needs to be viewed in the context of having completely disjoint resources on a single RS which are going to have different AS tokens issued. Thus for example, if there is a KDC which is servicing two different key groups. The supplicant gets a token for group1, gets the keys from the KDC. It then asks for a token for group2. Given that the lifetimes of these different tokens could be radically different does it really make sense to require that the two AS tokens be merged together (assuming they are from the same source) or would it make more sense to relax the RS only needs to keep one token rule. An easy way out of this might be to say one token per resource, but for constrained devices it could be one token per RS. Jim From nobody Mon Apr 8 17:02:43 2019 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 7D0C612000F for ; Mon, 8 Apr 2019 17:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tIvq4xCkMOti for ; Mon, 8 Apr 2019 17:02:38 -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 78EE21200B2 for ; Mon, 8 Apr 2019 17:02:38 -0700 (PDT) Received: from Jude (50.248.212.131) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Apr 2019 17:02:31 -0700 From: Jim Schaad To: Date: Mon, 8 Apr 2019 17:02:28 -0700 Message-ID: <007f01d4ee67$86dcda90$94968fb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdTuTrtyLsvZFxlwS3u5xL0Gj0pgRg== Content-Language: en-us X-Originating-IP: [50.248.212.131] Archived-At: Subject: [core] Security Model and other issues for group messaging X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 00:02:42 -0000 I have been going through the design process for getting software running for Montreal and I have come across the following issues that I think need some discussion. Some of these may just need clarification in documents but other are more substantive. It took me a while to determine that one of the strange issues I was having is that when looking just at the multicast case my mental model of who was making the decisions on if access was allowed did not seem to make a good match to what was being documented. I rather expected that all of the ACL decisions were going to be made on the AS and none on the KDC. This meant that the inclusion of scope in all of the messages was redundant if sending messages to a per group resource. Part of the questions involved here are who does the configuration for what key groups are associated with what application groups. I was always thinking of a single key group which was identified by the AS and sent to the KDC without the KDC needing to know the details of multiple resources for that key group. This of course does not match the model in the document. Some text on what model is being laid out is probably worthwhile. There was discussions for the ACE OAuth document about how to handle multiple access tokens for a single entity that need to be looked at in the context of a KDC. The current rule is that a resource server needs only to keep one token for any single supplicant. This was mostly discussed in the context of adding and subtracting privileges for the supplicant. It may be that this also needs to be viewed in the context of having completely disjoint resources on a single RS which are going to have different AS tokens issued. Thus for example, if there is a KDC which is servicing two different key groups. The supplicant gets a token for group1, gets the keys from the KDC. It then asks for a token for group2. Given that the lifetimes of these different tokens could be radically different does it really make sense to require that the two AS tokens be merged together (assuming they are from the same source) or would it make more sense to relax the RS only needs to keep one token rule. An easy way out of this might be to say one token per resource, but for constrained devices it could be one token per RS. Jim From nobody Tue Apr 9 02:41:29 2019 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 0AF8C1203CD for ; Tue, 9 Apr 2019 02:41:28 -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, 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 JELvod5LN9kw for ; Tue, 9 Apr 2019 02:41:25 -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 49B031202DB for ; Tue, 9 Apr 2019 02:41:25 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 40C1743819; Tue, 9 Apr 2019 11:41:23 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1BA0026; Tue, 9 Apr 2019 11:41:22 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8877:7422:b795:852a]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AF55874; Tue, 9 Apr 2019 11:41:21 +0200 (CEST) Received: (nullmailer pid 349 invoked by uid 1000); Tue, 09 Apr 2019 09:41:13 -0000 Date: Tue, 9 Apr 2019 11:41:13 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Badis Djamaa Cc: ali yachir , core@ietf.org Message-ID: <20190409094112.GA15632@hephaistos.amsuess.com> References: <155413839109.17114.2318273093661309081.idtracker@ietfa.amsl.com> <20190402054015.GA22410@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 09:41:28 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Badis, some replies inline: On Tue, Apr 02, 2019 at 08:42:19PM +0200, Badis Djamaa wrote: > The text in the RD draft seems to indicate that the "(6LBR) can act > as a resource directory". Thus, the 6LBR address can be announced in > the ABRO and confirmation of RD function can be done by unicasting > "coap://[6LBR]/.well-known/core?rt=3Dcore.rd*". That is exactly how contacting an RD via the 6LBR works; however, the 6LBR may only host the .well-known part of the RD but not the registration and lookup resources. (This comment's main purpose was to highlight alternatives to the "inconvenien[ce] of imposing that the RD be physically integrated" with the 6LBR.) > Otherwise, how would the RD be announced to the 6LBR (not mentioned in > the RD draft )? That is out of scope for the RD document, but I'd assume it would happen about the same way the 6LBR is configured to send ND options, or how a DHCP server is configured to send a particular option. > In the current version, the rd template value may be assumed a > default location, for instance, "core-rd". The Location-URI > Template would be then /core-rd/ep where ep comes from the RD's > "ep" attribute contained in the registration request, which is > unique per RD. Another possibility is to locate the posted RD > resource under well-known/core/ep at each device. > What is your take on this? Anything outside /.well-known/ should not be fixed by specifications according to RFC7320. I don't have any concrete suggestions yet as to where those updates should ideally go to. > * The DA generation process looks like every device is supposed to be a > > simple RD (that may be only capable of accepting a single > > registration, which is that of the actual ID), that is then > > replicated. > > > > Maintaining such replication seems to me to be quite a task for small > > nodes, especially if they're supposed to use the registration update > > interface and thus remember locations for each sub-PRD they registered > > to (though I'm not sure what is intended here, "SHOULD only contain > > the content and parameters that have been changed" seems to imply > > registration update, while 4.1.1 describes the registration interface > > which can't rely on previous registrations). > > True, but DA is only generated by the RD and forwarded using CoAP Group > Communication. Devices do no replication tasks. Also, very > constrained devices (section 5.2 of RD), may simply ignore the > received DA (see section 3) OK, that was not fully clear to me before, especially with the open question about the registration location. > Also, the current version of PRD does not use a separate resource > update interface. Both the first registration (which doesn't rely on > previous registrations) and periodic updates sent by RDs (relying on > previous registrations) use the registration interface. The > difference is that in the latter, the optional unchanged parameters > and payload are not POSTed. Processing of the received DA, for both > cases, is specified in section 4.1.2. As this is all intended for multicast and nodes joining the network, how can there be a difference between a first registration and periodic updates, which may arrive at devices that haev not seen the first registration? > > The document may benefit from exploring alternatives here (even if > > only to confirm the conclusion that the approach taken is the right > > one), like using the Simple Registration interface (would answer the > > question ad 4.1.1) or setting the announcements up as nontraditional > > responses[1] (eg. notifications about an unspoken request to GET > > /.well-known/core?rt=3Dcore.rd. I can't tell whether that'd even be a > > good idea, that's yet to be seen). > > [...] Nontraditional Responses (NR) need the devices to be aware of the= RD > location. Not necessarily; the NR could contain all the necessary request details as in [1]. [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00#section-2 > > * [...] whether there is anything in particular about RD announcements > > in it as compared to general link announcments. >=20 > Thank you for this suggestion, we will consider it in future versions. Ca= n you > please indicate some key services that need to be announced. That very much depends on the particular use case, but if there is anything that most devices joining the network would query right after having discovered the RD, that would be it. For example, in a setup that uses tiloca-core-oscore-discovery[2], it might make sense to not only send the RD's data but also the links to the most frequently joined join resources. (Not that the frequency of group members joining would be likely to warrant this, but if it were frequent enough that proactive-rd made sense, sending those links to join resources proactively would just make as much sense.) [2]: https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-02 Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlysaLQACgkQOY0REtOk veEkKA//VlnOnKqq+6dHLxkj+1Yh9PQ7OPInluV8Mli8h59hQ/UtoeiIupyQIl5v 3ZDzEEQBi58dYM8AJ31PsW6ze8s8lenKtKK+J5ZmuGkwf80sP5jPB1yQUm3bZI54 90wf7NlZ5/CHLBujeI7JtVJtV83wsIlad4rU/D0VFnCi2MzJ9/89Kzf5eUCatypg uTOcmBR5LIRAUdcYCyCWEtlNZUJ1xuSaIxC4KWamIxK4b3tJnpfBF8bNEbAfgnCU iKjR/G4xqEu9XcNQAsaK4796erBOMDYkEQJmFkhOKGh08wcKN1t1m1236LI0L6uy 8kwrC8JuAkC4SfG0/IAmmqirIPcUJycr5jbrKJ4yvierM9njHX0c/PraxeAkM/rZ ELVOHjf7HPCUjWmH0IxuVx5w1S670fDkJQI8/KibzPoLbyhmL7qqLFOfVLiYsBbX rAAJYXAv5e7k2Tf0z3cWpME0hOj0L/V4u/heBx9zKlidxNgLkrEKaGDJelXM8T5S /c9dBPBIwwOZ3J7ho5FXiujJOGFJORLakHLEF2Pn8R7qs1uV0UTebwv8m1POmXgR H/hwGV8n5fiDb5pGYcdqfTDkuD2sw31KtpIEZtEfiDZCfZSJgJoNHAes7mo7F5kU q76cr1iL+3LHhIo6yf35MDDB7VrVOASv8WcQrE2ZB9/mC9LLh3g= =IiAj -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From nobody Tue Apr 9 02:45:56 2019 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 72F2D1202DB; Tue, 9 Apr 2019 02:45:54 -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 Ed62-3GimJ-O; Tue, 9 Apr 2019 02:45:52 -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 42C0F120099; Tue, 9 Apr 2019 02:45:52 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 98A8B43819; Tue, 9 Apr 2019 11:45:50 +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 8A6D326; Tue, 9 Apr 2019 11:45:49 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8877:7422:b795:852a]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 117CC74; Tue, 9 Apr 2019 11:45:49 +0200 (CEST) Received: (nullmailer pid 804 invoked by uid 1000); Tue, 09 Apr 2019 09:45:40 -0000 Date: Tue, 9 Apr 2019 11:45:40 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: draft-ietf-core-coap-pubsub@ietf.org, core@ietf.org Message-ID: <20190409094539.GB15632@hephaistos.amsuess.com> References: <20190401161239.GC28400@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] pubsub short-review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 09:45:55 -0000 --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten and pubsub authors, > Indeed. However, if it is the normal result of an application state > that results in an error response, it probably is worth to point that > out in the definition of the application. >=20 > > * The create-on-publish operation is executed using PUT, which MUST be > > idempotent according to RFC7252 Section 5.1. Returning 2.01 Created on > > first put and 2.04 Changed on the second put is not exactly > > idempotent. >=20 > Idempotency in a REST context is with respect to the state on the > server, not with respect to the response code. Trivially, doing a > DELETE will get you a 2.02 only on the first request and a 4.04 on all > following ones. You're right, I missed that =E2=80=93 implementors might still appreciate a= note that they could receive a 2.04 even if they just created the topic. In the same vein, the 4.04 one could get on a DELETE is one of the protocol error codes that would be worth pointing out. Best regards Christian --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlysacMACgkQOY0REtOk veHI2RAAonp0FgyARyCUOUm98zzLUu2CfQiNw8icB9Q+5oK/GQnXE0y7TBs+CXJf MFU+0CbUpSJQe/4J9DgVnBQsM9/LC+pMX9XhyiQn1cVJxx1H77gppvwNAiZJt3vj dbC45yZKaqAeu7CDPBtqn8Ppw8IDQqoU5l7EyzLHHny1QdoH/FWa1NRcSKvRD6Uq Zg8pLye3BGI9kIi19jn99Psu3J/w0WmCE+HTdPVsmUM++3piCA0Fv0gPBk8uXGUc xWtjuav4BDM1jLKGAI5vwK2cYLHiO37NxiuKnh5+/eMYbEXWzmGelkXTf4DAxr3g RgqPsPmZplw4Qh2e3VumKL+jDEiHQpECvhPoBkwj1VIj1uMv+EryPC+RApe0kMbQ 0q1GCRQ83Xg7TEufF8wvPKemjLEcwGJw/uTw69reqkfv+hAC0lHMHQpt/r35lnxW PpcLfV/Ugis9rEL9ruI5kR86TSGpxPleJwVAOulQ1NTjdDPdZ7cd+c/v6s9D2hAl cXt3gynMWL/4mEg8bcfe+mz04TGQslRpyfdOtrFnlDUwQ5N3a10dMTht7Rdwy0Zk Sqv9go439ljyLfA06Z/Vaz06fFVxeGlJbgvFMQwLFqa3fcQIA9my8SJxKqJb/eGq gAD4yMAZd8ugJ78Mfwj6NtcxI8h3406bvMUDSZcfAgmzga67ZHY= =FvRk -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- From nobody Tue Apr 9 04:18:07 2019 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 551D612077B for ; Tue, 9 Apr 2019 04:18: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] 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 pAzYNupBZaMp for ; Tue, 9 Apr 2019 04:18:01 -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 284D1120778 for ; Tue, 9 Apr 2019 04:18:01 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5C2E343819; Tue, 9 Apr 2019 13:17:58 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A854E26; Tue, 9 Apr 2019 13:17:56 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8877:7422:b795:852a]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5174574; Tue, 9 Apr 2019 13:17:56 +0200 (CEST) Received: (nullmailer pid 11512 invoked by uid 1000); Tue, 09 Apr 2019 11:17:48 -0000 Date: Tue, 9 Apr 2019 13:17:48 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Cc: Bill Silverajan , "jintao.zhu@huawei.com" , core@ietf.org Message-ID: <20190409111747.GC15632@hephaistos.amsuess.com> References: <20180926163552.GA18946@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Dynlink observation attributes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 11:18:05 -0000 --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael, On Tue, Nov 06, 2018 at 12:05:57AM -0800, Michael Koster wrote: > I am convinced that we need to support observe attributes as query > parameters to an observe request, and include them in the request > caching. This makes sense as an application pattern and as a > sub-pattern for dynlinks (below). Glad you agree. > The modified URI may be thought of as a newly defined resource that > exposes a coarser grained dynamic representation of the same variable > indicated by the other URI parameters. I haven't fully thought through > the caching issue with etags and lifetimes, but it seems like there > will be ony one set of parameters feeding any given cached resource. > The notifications should be cacheable. Maybe even a bit better: I think that a proxy that has learned (eg. by having seen interface type information earlier) that a resource supports query attributes[1] could, when receiving a second observation on the same "resource" with different filters, pick a more generic one and serve the more specific ones after applying its own filtering. [1]: I think it'd make sense to define an interface type for that, for otherwise no client can be sure that /t?pmin=3D5 is actually a view on /t and not something completely different. > On that, I believe that the use of target attributes in a dynlink is > quite reasonable if we consider that the target of the link is always > the source of the transfer when rel=3Dboundto, and that we always use > the observe mechanism as an architectural model =3D> they are always > observe attributes, and they apply to the target of the link which is > hte source of the transfer. It also makes it very hard to move those links over to the semantic web world for reasoning, as those target attributes are per-link and not per-target. If there's a statement like ;rel=3Dboundto;anchor=3D"/monitor" then that can be processed on easily in RDF or any other information model that does not carry information per-link in the way we had sketched for JSON-LD enrichted links-json during IETF96 in Berlin. If the statement is ;rel=3Dboundto;st=3D2;anchor=3D"/monitor" then all semantic-web style processing needs to be aware of all those attributes, and can't wrap the information in a set of statements that includes `/monitor is boundto coap://sensor/temp` as the step information can't hook onto that statement. (Also, having the parameters in the target makes the binding site easier to implement, as it won't have to do URI fiddling but just takes a URI and observes it). > The "native" case is simply an optimization and not an architecture > permutation. A practical implementation may re-use the observe > mechanism for local transers.=20 > > Note also that the "bind" attribute is not strictly needed if we apply > these other constraints, as you point out. We may always assume > observe as an architectural model. This can be generalized to allow > the link to be stored anywhere that a client function can be > implemented, especially useful if we don't want to modify existing > servers.=20 I'm not saying it is very special, I'm more saying that GET/observe and PUT are not. > Not sure if we need polling but if we do, it's probably not the same > relation as "boundto". The transfer would likely be from source to > target like rel=3Dpolls, as in "target polls context". Only one > attribute of poll interval could be supported, and of course the > others could be modeled on observers of the target resource after the > polling, using the algorithm.=20 The binding site may not have control over whether what actually happens is polling or observation (and thus the distinction is of limited use); per RFC7641 Section 5, intermediaries could make the same observation polling-based over one hop and actually observing on the next one. > In the draft we can describe the observe attribute first, then > describe the use in dynlinks, then describe a link table example > implementation. I think a lot of the confusion can be alleviated this > way, and we can focus on preferred patterns. That's certainly a structure that will help, even now that both components stay in the same document. > Note that using a dynlink makes the observe parameters visible and > gives the observe relationship an affordance. >=20 > Does this all make sense? The affordance part does not, possibly because I've heard the term only in the context of high-level usefullness. As I understand the term, he affordance would be informing a heating valve of a room temperature, and that affordance can be implemented in the CoRE ecosystem by placing a dynlink. > Does this make sense? I could write up a rough strawman draft with the > changes. I'd be happy to read that. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlysf1kACgkQOY0REtOk veE6/xAAnpqIJu8gQr6K3vsGut1nHwlJ9BbcxAQATDgH5dU2/ac56qStIuZ9TQCI 8bh9m3sQfzhlSsUgYW7e580PZNQIDgtCUW8u+w6yXAXmiW2F2uBJHk7ZBRBoGjF9 Qg1INccQDowXn6+zvg5LOIk6gpui0NSrAVoDrylemq7yVwLXDURp6r+ytYgZBrgT 0xg7btGkiqfl1NDPrec8QIXl6hbZGaRPr4P1DhEPPfrQZriADLOPoEbmGpFut7VM T5fGNJJqM6RnuKurt6ongcHHBnenV3xt5qnRFxmCJd3ceo5X/Ucdn+xSCMQJ7bQG NxUERwpL6rCAvTqNGJRvalCuH7YTx4hdItLWccLOwHQnRGYaPQ9ksMsSX56Ua2nX e1NLqAx2SQ3dfvTag6awqIhrxj664PzpZsecGdTxLMpd2Tzj+AmEfPPvmMFXV/bF nkGs3K83rd8M9gQwAmYUwY+Eii1mfVrvKbwFtdARdq/zKGROUkgypMUSuEdnrwjx su1TyWvG2K4t5FrvTJYdJ3ji5q0DqUgnfYZogXrUA2OwH6VwncC/DIDqGIfkISp3 LcDa4mO4eXKFbFLIpox7NbZhD4y0ZTwRhRlqAAGt0EfH7ikHa6G3jnkmbVatPU+M liapjayNUmmTSEILxmXna7PNm7/0X7Xq4T2lK6uUX5lncPLfqUc= =5pkE -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/-- From nobody Sat Apr 13 07:46:44 2019 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 2F51D1201CF; Sat, 13 Apr 2019 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DrFc88bBgp8m; Sat, 13 Apr 2019 07:46:34 -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 CD7C11201B8; Sat, 13 Apr 2019 07:46:30 -0700 (PDT) Received: from mail-qt1-f178.google.com ([209.85.160.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hFJvG-0007sV-10; Sat, 13 Apr 2019 16:46:26 +0200 Received: by mail-qt1-f178.google.com with SMTP id k2so14595505qtm.1; Sat, 13 Apr 2019 07:46:25 -0700 (PDT) X-Gm-Message-State: APjAAAUDlUxpbMNyCBwVOaCFYwH/vu5s23jFXDvXcPpkYs+hXz5C/GY5 POYVyeG0Qv/0dxCW2OCAuQ0MMJlA+1Xerg5NPaI= X-Google-Smtp-Source: APXvYqxMUQ6S1XdElMSNLcKnMBrCyFyndiaMqrEiVVvuzDqs1JxeyXZdtBTZ0f7h8ipnl0H5mj49heAjoRUIxghOEaI= X-Received: by 2002:ac8:2a54:: with SMTP id l20mr52037829qtl.193.1555166784978; Sat, 13 Apr 2019 07:46:24 -0700 (PDT) MIME-Version: 1.0 From: Klaus Hartke Date: Sat, 13 Apr 2019 16:45:49 +0200 X-Gmail-Original-Message-ID: Message-ID: To: cose@ietf.org, "core@ietf.org WG" , cbor@ietf.org, Ace@ietf.org Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1555166793; 96846234; X-HE-SMSGID: 1hFJvG-0007sV-10 Archived-At: Subject: [core] Doodle poll for virtual interims X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Apr 2019 14:46:36 -0000 We are looking for a new time slot for the CoRE/CBOR/COSE virtual interims until IETF 105. Proposed options: 7am PDT / 10am EDT / 4pm CEST / 11pm JST 8am PDT / 11am EDT / 5pm CEST / 12midn JST 9am PDT / 12noon EDT / 6pm CEST / 1am JST 10am PDT / 1pm EDT / 7pm CEST / 2am JST The interims are scheduled to be weekly, alternating between CoRE and CBOR/COSE (and a dash of ACE). Please use this doodle poll to indicate your preference: https://doodle.com/poll/ve7rnyareri2kqer Klaus From nobody Mon Apr 15 06:11:56 2019 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 643A81200C4; Mon, 15 Apr 2019 06:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 xSIh3QXzrd1z; Mon, 15 Apr 2019 06:11:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23B912017E; Mon, 15 Apr 2019 06:11:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8E2BD2607E; Mon, 15 Apr 2019 09:11:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 15 Apr 2019 09:11:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=QkLTb3vm9f/MuBCBd737E5Y3lu66N bo2Jni8bqyb9/A=; b=LZK/ucQtFebESLKG0vcq4h2IphLwJqi9FoldvXbEUmpa9 e9V9XqM4j/cWZQ53XP8O4PJ2FhvERLfkwBlXIakTnbp2IBBvrwTS+AH0jXtN+3bM pA6U97H9rVfRT2XZou7Ae0rgOd9aNFh0REhwui4NqROP/q/UJa53eLg4yc5VhEeY q4L1B9oGNUe3GVrU4IHaTnIclgzAJfp7BLPXQL1trd+DNBr4V4EUhVnK1BgwanId KcTdZXFBDoZcrTFHO5nCcARulQQ4JGwBcSA8EzdbHh/DIqutvE0g0e42k0bAdn7Y S57M5QOQmrc0VY2n4qyF6TPNcknqxA+91UTovvlLg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdelgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtggguffkfffvofesrgdtmherhhdtjeenucfhrhhomheplfgrihhmvggplfhi mhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuffhomhgrihhnpehivghtfhdroh hrghdpohhpvghnmhhosghilhgvrghllhhirghntggvrdhorhhgnecukfhppeduledvrddu jeeirddurdektdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfh hinecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [100.94.49.156] (sessfw99-sesbfw99-80.ericsson.net [192.176.1.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 026B8E4448; Mon, 15 Apr 2019 09:11:48 -0400 (EDT) From: =?utf-8?Q?Jaime_Jim=C3=A9nez?= Content-Type: multipart/alternative; boundary="Apple-Mail=_11FA2E83-2876-44B7-9ECA-4CDB2DE48CB2" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <4E61C319-0FF0-44BC-B4DD-39451BC52F68@iki.fi> Date: Mon, 15 Apr 2019 16:11:47 +0300 Cc: Carsten Bormann , Jari Arkko , draft-ietf-core-dev-urn@ietf.org To: core X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [core] Chair's review of draft-ietf-core-dev-urn-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 13:11:54 -0000 --Apple-Mail=_11FA2E83-2876-44B7-9ECA-4CDB2DE48CB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear authors of draft-ietf-core-dev-urn, Below is the chair=E2=80=99s review of the draft. I could not find a reference on the draft to the OMA LwM2M specification = Section 7.3.1. It is probably relevant as it is mentioned few times. = 7.3.1 is where Endpoint Client Names are defined and URNs are used. = http://www.openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/H= TML-Version/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.html#7-3-1-0-731-En= dpoint-Client-Name This statement is a bit self-evident: "These URNs may be used in any = relevant networks that benefit from the ability to refer to these = identifiers in the form of URNs" The ABNF does not have errors but there are some nits - according to = https://tools.ietf.org/tools/bap/abnf.cgi - for example in "Component" = which should be: component =3D [ DIGIT / ALPHA ] Although DIGIT and ALPHA are not repeated in this draft's ABNF it = wouldn't hurt to repeat them for completion as they are just two short = lines. I am not sure what the right policy is regarding that. Reference to [IEEE.EUI64] returns 404. There are also few outdated = references that you have to check on the nits. Clarification question, since ow urns are defined as "owbody =3D "ow:" = hexstring" , is it OK to use urn:dev:ow:264437f5000000ed_humidity as an = example? Wouldn't it be better to define it as "owbody =3D "ow:" = identifier=E2=80=9D Ciao! -- Jaime Jim=C3=A9nez --Apple-Mail=_11FA2E83-2876-44B7-9ECA-4CDB2DE48CB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear authors of draft-ietf-core-dev-urn,

Below is the chair=E2=80=99s review of = the draft.

I = could not find a reference on the draft to the OMA LwM2M specification = Section 7.3.1. It is probably relevant as it is mentioned few times. = 7.3.1 is where Endpoint Client Names are defined and URNs are used. http://www.openmobilealliance.org/release/LightweightM2M/V1_1-2= 0180710-A/HTML-Version/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.html#7-3= -1-0-731-Endpoint-Client-Name

This statement is a bit self-evident: = "These URNs may be used in any relevant networks that benefit from the = ability to refer to these identifiers in the form of URNs"

The ABNF does not have errors = but there are some nits - according to https://tools.ietf.org/tools/bap/abnf.cgi - for example = in "Component" which should be:
component =3D [ DIGIT / ALPHA ]

Although DIGIT and ALPHA are not repeated = in this draft's ABNF it wouldn't hurt to repeat them for completion as = they are just two short lines. I am not sure what the right policy is = regarding that.

Reference to [IEEE.EUI64] returns 404. There are also few = outdated references that you have to check on the nits.

Clarification question, since = ow urns are defined as "owbody =3D "ow:" hexstring" , is it OK to use = urn:dev:ow:264437f5000000ed_humidity as an example? Wouldn't it be = better to define it as "owbody =3D "ow:" identifier=E2=80=9D


Ciao!
-- Jaime Jim=C3=A9nez

= --Apple-Mail=_11FA2E83-2876-44B7-9ECA-4CDB2DE48CB2-- From nobody Mon Apr 15 06:54:37 2019 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 986331202F3; Mon, 15 Apr 2019 06:54:35 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 s_nWBnTwgU6p; Mon, 15 Apr 2019 06:54:34 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3651202CE; Mon, 15 Apr 2019 06:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1555336473; d=isode.com; s=june2016; i=@isode.com; bh=lJ5FaZq4/NUVJRTLLFcvUtXv6LgSk+BCEVciWOMz7aY=; 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=N/ecisD0H99o33eE2608PwLJTHTItalhKGLEukxUBxtgPsHErrIF2c21Iqd6Gz4aq71V4m w9RR+fsmhFpIp+0m1CFz5i9M6OXTfbmnAii69H1tkMUJn+Q2Ne4O5Py0/HULQ7eX4pGIjg tD03qHiH9nRecEIKefbgsOGePQWu87E=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 15 Apr 2019 14:54:33 +0100 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , core Cc: draft-ietf-core-dev-urn@ietf.org References: <4E61C319-0FF0-44BC-B4DD-39451BC52F68@iki.fi> From: Alexey Melnikov Message-ID: <90ef750f-8db8-4001-ab0d-92092bdcbea1@isode.com> Date: Mon, 15 Apr 2019 14:54:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <4E61C319-0FF0-44BC-B4DD-39451BC52F68@iki.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1598464ADB0A2D2AA1A25C4F" Content-Language: en-GB Archived-At: Subject: Re: [core] Chair's review of draft-ietf-core-dev-urn-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 13:54:36 -0000 --------------1598464ADB0A2D2AA1A25C4F Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Jaime, On 15/04/2019 14:11, Jaime Jim=C3=A9nez wrote: > > Although DIGIT and ALPHA are not repeated in this draft's ABNF it=20 > wouldn't hurt to repeat them for completion as they are just two short=20 > lines. I am not sure what the right policy is regarding that. The best way is to add the following 2 rules: DIGIT =3D ALPHA =3D Best Regards, Alexey --------------1598464ADB0A2D2AA1A25C4F Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Jaime,

On 15/04/2019 14:11, Jaime Jim=C3=A9nez wrote:

Although DIGIT and ALPHA are not repeated in this draft's ABNF it wouldn't hurt to repeat them for completion as they are just two short lines. I am not sure what the right policy is regarding that.

The best way is to add the following 2 rules:

DIGIT =3D <Defined in RFC5234>

ALPHA =3D <Defined in RFC5234>


Best Regards,

Alexey

--------------1598464ADB0A2D2AA1A25C4F-- From nobody Mon Apr 15 06:57:35 2019 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 362DD1202CE; Mon, 15 Apr 2019 06:57:34 -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] 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 IOtoDrXK2hiw; Mon, 15 Apr 2019 06:57:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id B900C12036B; Mon, 15 Apr 2019 06:57:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B050466020B; Mon, 15 Apr 2019 16:57:30 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbYPYV2DBM5Y; Mon, 15 Apr 2019 16:57:28 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 834D86600AE; Mon, 15 Apr 2019 16:57:28 +0300 (EEST) From: Jari Arkko Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_93FB8734-BFC8-4097-A2F2-E6C8F4A47152" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 15 Apr 2019 16:57:27 +0300 In-Reply-To: <90ef750f-8db8-4001-ab0d-92092bdcbea1@isode.com> Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core , draft-ietf-core-dev-urn@ietf.org To: Alexey Melnikov References: <4E61C319-0FF0-44BC-B4DD-39451BC52F68@iki.fi> <90ef750f-8db8-4001-ab0d-92092bdcbea1@isode.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Chair's review of draft-ietf-core-dev-urn-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 13:57:34 -0000 --Apple-Mail=_93FB8734-BFC8-4097-A2F2-E6C8F4A47152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii First, thanks for your review, Jaime. And Alexey: >> Although DIGIT and ALPHA are not repeated in this draft's ABNF it = wouldn't hurt to repeat them for completion as they are just two short = lines. I am not sure what the right policy is regarding that. > The best way is to add the following 2 rules: >=20 > DIGIT =3D >=20 > ALPHA =3D >=20 Thanks. Will use this. Jari --Apple-Mail=_93FB8734-BFC8-4097-A2F2-E6C8F4A47152 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii First, thanks for your review, Jaime. And Alexey:

Although DIGIT and ALPHA are not repeated in this draft's ABNF it wouldn't hurt to repeat them for completion as they are just two short lines. I am not sure what the right policy is regarding that.

The best way is to add the following 2 rules:

DIGIT = <Defined in RFC5234>

ALPHA = <Defined in RFC5234>


Thanks. Will use this.

Jari

--Apple-Mail=_93FB8734-BFC8-4097-A2F2-E6C8F4A47152-- From nobody Mon Apr 15 08:44:23 2019 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 DF4D8120382; Mon, 15 Apr 2019 08:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 f-KUr6A-iG4c; Mon, 15 Apr 2019 08:44:18 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40072.outbound.protection.outlook.com [40.107.4.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 F13D912001B; Mon, 15 Apr 2019 08:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5dK1KGM6ccgp1ccVmzgQVP2jCMTUmZCcbB3n2MKu81Y=; b=Jf/o4uryFz29y+5le8OzhYGfwMgtZf1zccV+fOkddGUXOrv3jDLWajx7+xxh2FO8A5rDJvgQSIbQhq+VTKbWLJ4eNGVs1exkeCSW3lFlPoJyyMDPtNaOo2pu+8Wo1VxN7ba4My8U6iDZNdcT7YV83GZSpIrSiubOBb8IbsaAs3o= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2874.eurprd07.prod.outlook.com (10.168.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 15:44:14 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 15:44:14 +0000 From: Francesca Palombini To: "cose@ietf.org" , "core@ietf.org WG" , "cbor@ietf.org" , "Ace@ietf.org" Thread-Topic: [Ace] Doodle poll for virtual interims Thread-Index: AQHU8gfB1xzeYR7XSk63xG16DiVzHaY9YBcv Date: Mon, 15 Apr 2019 15:44:14 +0000 Message-ID: <0A9FF18D-5A9F-483A-B6CB-871CD25626F5@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5268253e-9e9b-402f-c4fa-08d6c1b93689 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2874; x-ms-traffictypediagnostic: HE1PR0701MB2874: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(136003)(346002)(396003)(199004)(189003)(5660300002)(26005)(76176011)(97736004)(186003)(25786009)(8676002)(305945005)(102836004)(6246003)(53546011)(6506007)(110136005)(236005)(316002)(6306002)(450100002)(106356001)(6512007)(14454004)(53936002)(33656002)(105586002)(54896002)(2906002)(7736002)(66066001)(229853002)(6486002)(82746002)(2501003)(256004)(86362001)(606006)(966005)(81156014)(476003)(81166006)(11346002)(446003)(2616005)(68736007)(486006)(2201001)(44832011)(8936002)(36756003)(71190400001)(71200400001)(83716004)(478600001)(99286004)(6436002)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2874; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 07xdM3ITsqNHly274pKCFl3HtDlc0PRK4vMImEiQmDkABrcz5Hmc2dFyIRhSD6YZIUTR8t6WrX2Kr8Y7C/H1VMx2NbhURMwSKeMoF9rVB6Vu+Ao+CZ/3idUFGvu8uCmGmEuHs+B8e7qCa1CBJchdlhwqlMNLReXiXgt4qL//8sMHn1koEa4+VujjoGEtO9vl36o+KFM29wcZrpwqu6DOvGYlbEzYhRVurFQAjVPR2sqrCgG7KJ//Q2fAqZe7vCM5iQ+cMWpUNj4z5PIQcrwcBXRNuC/1RDzTEV3f1gCsF3jvNYcqx17WcJm71oRty6SDxo/RW9+IZVDJKYvno5j5CB7NrhFL1aKgW0PzAY5LLgJOMZQSVzPYee1X/1nHKAw7qWUcNSqh/g+ijAIBLDLKWMVFmGaEwIDDhBnVRouvNvk= Content-Type: multipart/alternative; boundary="_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5268253e-9e9b-402f-c4fa-08d6c1b93689 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 15:44:14.5491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2874 Archived-At: Subject: Re: [core] [Ace] Doodle poll for virtual interims X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:44:21 -0000 --_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClBsZWFzZSBlbnRlciB5b3VyIGF2YWlsYWJpbGl0eSBieSB0aGlzIEZyaWRheSwgQXBy aWwgMTl0aDogaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvdmU3cm55YXJlcmkya3Flcg0KDQpBcyBL bGF1cyBzYWlkLCB0aGUgdGltZSBzbG90cyBhcmUgdG8gY2hvc2UgZm9yIHdlZWtseSBtZWV0aW5n cywgc28gZGlzcmVnYXJkIHRoZSBleGFjdCBkYXRlcyBpbiB0aGUgZG9vZGxlIHBvbGwsIGJ1dCBv bmx5IGNvbnNpZGVyIHRoZSBkYXkgb2YgdGhlIHdlZWsuDQoNClRoZSBnb2FsIGlzIHRvIHJlc3Rh cnQgdGhlIG1lZXRpbmdzIGJ5IHRoZSAybmQgd2VlayBvZiBNYXksIGFuZCB3ZSBuZWVkIGEgY291 cGxlIG9mIHdlZWtzIHRvIHNldCBpdCB1cCB3aXRoIHRoZSBTZWNyZXRhcmlhdC4NCg0KQWxzbyBu b3RlIHRoYXQgdGhlIHRpbWVzbG90cyBhcmUgOTAgbWludXRlcyBsb25nLCB0byBhbGxvdyBmb3Ig bG9uZ2VyIGludGVyaW0gdGltZSBpZiBuZWVkZWQuDQoNCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoN Cg0KT24gMTMgQXByaWwgMjAxOSBhdCAxNjo0NzowMiBDRVNULCBLbGF1cyBIYXJ0a2UgPGhhcnRr ZUBwcm9qZWN0Y29vbC5kZT4gd3JvdGU6DQpXZSBhcmUgbG9va2luZyBmb3IgYSBuZXcgdGltZSBz bG90IGZvciB0aGUgQ29SRS9DQk9SL0NPU0UgdmlydHVhbA0KaW50ZXJpbXMgdW50aWwgSUVURiAx MDUuDQoNClByb3Bvc2VkIG9wdGlvbnM6DQoNCjdhbSBQRFQgLyAxMGFtIEVEVCAvIDRwbSBDRVNU IC8gMTFwbSBKU1QNCjhhbSBQRFQgLyAxMWFtIEVEVCAvIDVwbSBDRVNUIC8gMTJtaWRuIEpTVA0K OWFtIFBEVCAvIDEybm9vbiBFRFQgLyA2cG0gQ0VTVCAvIDFhbSBKU1QNCjEwYW0gUERUIC8gMXBt IEVEVCAvIDdwbSBDRVNUIC8gMmFtIEpTVA0KDQpUaGUgaW50ZXJpbXMgYXJlIHNjaGVkdWxlZCB0 byBiZSB3ZWVrbHksIGFsdGVybmF0aW5nIGJldHdlZW4gQ29SRSBhbmQNCkNCT1IvQ09TRSAoYW5k IGEgZGFzaCBvZiBBQ0UpLg0KDQpQbGVhc2UgdXNlIHRoaXMgZG9vZGxlIHBvbGwgdG8gaW5kaWNh dGUgeW91ciBwcmVmZXJlbmNlOg0KaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvdmU3cm55YXJlcmky a3Flcg0KDQpLbGF1cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K --_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+SGksDQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlBsZWFz ZSBlbnRlciB5b3VyIGF2YWlsYWJpbGl0eSBieSB0aGlzIEZyaWRheSwgQXByaWwgMTl0aDombmJz cDs8c3Bhbj5odHRwczovL2Rvb2RsZS5jb20vcG9sbC92ZTdybnlhcmVyaTJrcWVyJm5ic3A7PC9z cGFuPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5B cyBLbGF1cyBzYWlkLCB0aGUgdGltZSBzbG90cyBhcmUgdG8gY2hvc2UgZm9yIHdlZWtseSBtZWV0 aW5ncywgc28gZGlzcmVnYXJkIHRoZSBleGFjdCBkYXRlcyBpbiB0aGUgZG9vZGxlIHBvbGwsIGJ1 dCBvbmx5IGNvbnNpZGVyIHRoZSBkYXkgb2YgdGhlIHdlZWsuPC9kaXY+DQo8ZGl2IGRpcj0ibHRy Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlRoZSBnb2FsIGlzIHRvIHJlc3RhcnQgdGhl IG1lZXRpbmdzIGJ5IHRoZSAybmQgd2VlayBvZiBNYXksIGFuZCB3ZSBuZWVkIGEgY291cGxlIG9m IHdlZWtzIHRvIHNldCBpdCB1cCB3aXRoIHRoZSBTZWNyZXRhcmlhdC48YnI+DQo8L2Rpdj4NCjxk aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+QWxzbyBub3RlIHRoYXQg dGhlIHRpbWVzbG90cyBhcmUgOTAgbWludXRlcyBsb25nLCB0byBhbGxvdyBmb3IgbG9uZ2VyIGlu dGVyaW0gdGltZSBpZiBuZWVkZWQuPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJkcmFmdC1icmVh ayI+PC9zcGFuPjxicj4NCjxicj4NClRoYW5rcywNCjxkaXYgZGlyPSJsdHIiPkZyYW5jZXNjYTwv ZGl2Pg0KPHNwYW4gaWQ9ImRyYWZ0LWJyZWFrIj48L3NwYW4+PGJyPg0KPGJyPg0KPGRpdj4NCjxk aXYgY2xhc3M9Im51bGwiIGRpcj0iYXV0byI+T24gMTMgQXByaWwgMjAxOSBhdCAxNjo0NzowMiBD RVNULCBLbGF1cyBIYXJ0a2UgJmx0O2hhcnRrZUBwcm9qZWN0Y29vbC5kZSZndDsgd3JvdGU6PGJy IGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImJv cmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci13aWR0aDoxcHg7bWFyZ2luLWxlZnQ6MHB4O3Bh ZGRpbmctbGVmdDoxMHB4OyIgY2xhc3M9Im51bGwiPg0KPGRpdiBjbGFzcz0ibnVsbCIgZGlyPSJh dXRvIj4NCjxkaXYgY2xhc3M9Im51bGwiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgRXhjaGFuZ2UgU2VydmVyIiBjbGFzcz0ibnVsbCI+DQo8IS0tIGNvbnZlcnRl ZCBmcm9tIHRleHQgLS0+DQo8ZGl2IGNsYXNzPSJudWxsIj48Zm9udCBzaXplPSIyIiBjbGFzcz0i bnVsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyIgY2xhc3M9Im51bGwiPg0KPGRpdiBu b3A9IlBsYWluVGV4dCIgY2xhc3M9Im51bGwiPldlIGFyZSBsb29raW5nIGZvciBhIG5ldyB0aW1l IHNsb3QgZm9yIHRoZSBDb1JFL0NCT1IvQ09TRSB2aXJ0dWFsPGJyIGNsYXNzPSJudWxsIj4NCmlu dGVyaW1zIHVudGlsIElFVEYgMTA1LjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwi Pg0KUHJvcG9zZWQgb3B0aW9uczo8YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4N CjdhbSBQRFQgLyAxMGFtIEVEVCAvIDRwbSBDRVNUIC8gMTFwbSBKU1Q8YnIgY2xhc3M9Im51bGwi Pg0KOGFtIFBEVCAvIDExYW0gRURUIC8gNXBtIENFU1QgLyAxMm1pZG4gSlNUPGJyIGNsYXNzPSJu dWxsIj4NCjlhbSBQRFQgLyAxMm5vb24gRURUIC8gNnBtIENFU1QgLyAxYW0gSlNUPGJyIGNsYXNz PSJudWxsIj4NCjEwYW0gUERUIC8gMXBtIEVEVCAvIDdwbSBDRVNUIC8gMmFtIEpTVDxiciBjbGFz cz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KVGhlIGludGVyaW1zIGFyZSBzY2hlZHVsZWQg dG8gYmUgd2Vla2x5LCBhbHRlcm5hdGluZyBiZXR3ZWVuIENvUkUgYW5kPGJyIGNsYXNzPSJudWxs Ij4NCkNCT1IvQ09TRSAoYW5kIGEgZGFzaCBvZiBBQ0UpLjxiciBjbGFzcz0ibnVsbCI+DQo8YnIg Y2xhc3M9Im51bGwiPg0KUGxlYXNlIHVzZSB0aGlzIGRvb2RsZSBwb2xsIHRvIGluZGljYXRlIHlv dXIgcHJlZmVyZW5jZTo8YnIgY2xhc3M9Im51bGwiPg0KPGEgaHJlZj0iaHR0cHM6Ly9kb29kbGUu Y29tL3BvbGwvdmU3cm55YXJlcmkya3FlciIgdGFyZ2V0PSJfQkxBTksiIGNsYXNzPSJudWxsIj5o dHRwczovL2Rvb2RsZS5jb20vcG9sbC92ZTdybnlhcmVyaTJrcWVyPC9hPjxiciBjbGFzcz0ibnVs bCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KS2xhdXM8YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNz PSJudWxsIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSJudWxsIj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9Im51bGwiPg0KQWNl QGlldGYub3JnPGJyIGNsYXNzPSJudWxsIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9CTEFOSyIgY2xhc3M9Im51bGwiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxiciBjbGFzcz0ibnVsbCI+ DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0A9FF18D5A9F483AB6CB871CD25626F5ericssoncom_-- From nobody Tue Apr 16 01:01:47 2019 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 6B289120330 for ; Tue, 16 Apr 2019 01:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 OwQXkgi9BhQq for ; Tue, 16 Apr 2019 01:01:44 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140073.outbound.protection.outlook.com [40.107.14.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB077120345 for ; Tue, 16 Apr 2019 01:01:42 -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=pty0P3sONZNuUkcMOWy+BnTTTOsIAC1DSHiu7yH4igc=; b=qY74zyOeeulRN7TzuZKubONQOmVI19PVAMA/briafjz46k8tgRDta/jOwO1ZLShOELrFE0CxG1xU70QWaj7FBxtqSZWxcKrAO373iGYXsfJI4Ch44bobddBq804V+wmd8YKdOelK4Se8XTK+D4RssbIqELn1YO2AJkgM8QMzkKk= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB5111.eurprd08.prod.outlook.com (10.255.122.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Tue, 16 Apr 2019 08:01:40 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 08:01:40 +0000 From: Hannes Tschofenig To: "'core@ietf.org WG'" Thread-Topic: draft-ietf-core-dynlink-08: pmin/pmax Thread-Index: AdT0KnqSYDRi4KSbTpqGdVqQZybMmw== Date: Tue, 16 Apr 2019 08:01:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffb1a397-d7ac-4e72-479f-08d6c241c1f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB5111; x-ms-traffictypediagnostic: AM6PR08MB5111: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(376002)(346002)(136003)(40434004)(189003)(199004)(7696005)(413944005)(14454004)(72206003)(966005)(105586002)(71200400001)(7736002)(106356001)(6116002)(71190400001)(97736004)(478600001)(102836004)(5660300002)(81156014)(3846002)(52536014)(5024004)(6506007)(256004)(14444005)(8676002)(606006)(74316002)(8936002)(790700001)(6306002)(316002)(33656002)(99286004)(6436002)(66066001)(81166006)(486006)(186003)(26005)(9686003)(55016002)(54896002)(236005)(68736007)(2906002)(53936002)(4744005)(86362001)(6916009)(25786009)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB5111; H:AM6PR08MB3686.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8QhkoCsfSs7JpJ50lvuSUi1TQu51NwGdOyx4kFk51sF1iu6ESmw1PLqgibfMwELgeEaAzOA710p7eJxTPkA+yQX3om4v04ytzJaoo2GALHK9xi9n1s6SehsgmWE9ZScUM4C+35qdO8TP43+3Tizm6s44y9/D4duH62qZ3q2mYsqcCAJq0sgygUsrxjFbBZLJHId9a7NfenjLxM1kwMLNTbgwO7O9sga1I37t5+JXoGyw5x91gUVep2ozJa3a/anZ8+Q8pZG4wsTKofpi/d8xNmp9uHl0AsyGrjnoxJ2xDnNA0YQhie8I2cmGGE+0PILWe8og+8lXnbk4l8pPYmJP/IBdszsVt+zvH00b3TQmZU/zXkmxI3eD3ftRbMXvLPGFDp1HETnRaGS+0LOsViOqvktx4bfJJGPFKe5vAUw3QYY= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3686CA26455B9EFDDA995EEEFA240AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffb1a397-d7ac-4e72-479f-08d6c241c1f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 08:01:40.1431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5111 Archived-At: Subject: [core] draft-ietf-core-dynlink-08: pmin/pmax X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 08:01:46 -0000 --_000_AM6PR08MB3686CA26455B9EFDDA995EEEFA240AM6PR08MB3686eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear dynlink authors, We got a question regarding pmin/pmax regarding the dynlink draft at our pu= blic LwM2M Github issue tracker: https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/461 Maybe this is useful input for your draft. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM6PR08MB3686CA26455B9EFDDA995EEEFA240AM6PR08MB3686eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear dynlink authors,

 

We got a question regarding pmin/pmax regarding the = dynlink draft at our public LwM2M Github issue tracker:

https://github.com/OpenMobileAlliance/OMA= _LwM2M_for_Developers/issues/461

 

Maybe this is useful input for your draft.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM6PR08MB3686CA26455B9EFDDA995EEEFA240AM6PR08MB3686eurp_-- From nobody Tue Apr 16 08:56:53 2019 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 7A76812076A for ; Tue, 16 Apr 2019 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 5LaLHAjUBYdU for ; Tue, 16 Apr 2019 08:56:48 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80082.outbound.protection.outlook.com [40.107.8.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4B4120823 for ; Tue, 16 Apr 2019 07:56:15 -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=yX/BmMabnWnc+vPdK9tXyCuIM06PUkvuK5LaJyMOKm0=; b=PngmPkHCuKgc4TfYO4fF7r7fyyOMwmKeH0PhYJ9ukp1++Nss5pQauGlk45Y7aAs3hz9tItIaR93YJto3Tz091ZfdtWsEI8bceckdFE+UTNn8xBkOJlXpq/qsEJzH2gCkf+cWL1xD08+f9pI10/aA0eWEl1VbSgFJ/EOTjSF5zmQ= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3992.eurprd08.prod.outlook.com (20.179.0.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Tue, 16 Apr 2019 14:56:10 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 14:56:10 +0000 From: Hannes Tschofenig To: "'core@ietf.org WG'" Thread-Topic: Dynlink examples Thread-Index: AdT0ZHk3yT3Cky7CRA+qz3MXhDPTGg== Date: Tue, 16 Apr 2019 14:56:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28eff87a-32b6-49e3-527f-08d6c27ba9c0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3992; x-ms-traffictypediagnostic: AM6PR08MB3992: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(346002)(376002)(136003)(40434004)(199004)(189003)(102836004)(486006)(6506007)(476003)(186003)(26005)(316002)(4326008)(53936002)(105586002)(106356001)(99286004)(7696005)(68736007)(3846002)(5660300002)(52536014)(81166006)(71190400001)(71200400001)(25786009)(2906002)(72206003)(8936002)(81156014)(478600001)(7736002)(7116003)(4744005)(6116002)(3480700005)(966005)(256004)(9686003)(97736004)(55016002)(66066001)(6306002)(14444005)(5024004)(33656002)(6436002)(6916009)(305945005)(74316002)(86362001)(8676002)(221733001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3992; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: omHIG67lg888JvduNa+86lmb6HAd0nhsCjOgaVZg8io02d+B1j9NxYEhTSEJaCCRmz/DGpL64pk1/FG4267YPEJHBXhmw6CFCeiXusIOEpaDYw4/VhhNt4bOg30DVlqVw+eHhKom2ojiMCLMb0rj9WyrWklvnR8F0U/Ec+WufFHqdpQUEhcQA21Sgy5NLYzMge+yUs6WsoVW7a2YUjHgajp8PawOcSDYghcWIlJ8woKCkoRzBcU/gPGLwnvsZTt+ABZkhxu0hfEo5xygyF/q/iYj0pkNiVcn/01CK/mKrM9q60GQhLAbr7ni7AloVTJObjXNdwIoPgGMuUtoQW8Iq5m3D3GOAoDv03COCx1rXCaM8lEe8IB+76BT+kPaf/wyHh1erhjjPWRqQGWcaK7M2nk5rU+og28lJLczoqvwmsU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28eff87a-32b6-49e3-527f-08d6c27ba9c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 14:56:10.3102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3992 Archived-At: Subject: [core] Dynlink examples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 15:56:52 -0000 Hi Dynlink authors, during our OMA DM conference call this week Mert noticed that the examples = in https://tools.ietf.org/html/draft-ietf-core-dynlink-08 are incorrect. For example, Figure 2 says > pmin=3D"10";pmax=3D"60" Since pmin and pmax are integer values they would be represented without qu= otes. The correct writing in this case would be > pmin=3D10;pmax=3D60 Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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 Wed Apr 17 06:38:59 2019 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 03A88120364 for ; Wed, 17 Apr 2019 06:38:58 -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 ClFVEfn6gcmU for ; Wed, 17 Apr 2019 06:38:56 -0700 (PDT) Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.69]) (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 E351312008D for ; Wed, 17 Apr 2019 06:38:55 -0700 (PDT) Received: from smtp25.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0989A20139; Wed, 17 Apr 2019 09:38:55 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp25.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B81892010B; Wed, 17 Apr 2019 09:38:54 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 17 Apr 2019 09:38:55 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Cullen Jennings In-Reply-To: Date: Wed, 17 Apr 2019 07:38:54 -0600 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: <2D65CEA4-7C9E-46F5-96BD-99F6C1E83C9A@iii.ca> References: To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [core] New units for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:38:58 -0000 I think our goal should be to have units that are pragmatically useful = but try not to have too many confusing duplicates. The units here seem = inline with that so I support this.=20 I wonder if VAa for Volt Amps apparent and VAr for Volt Amps reactive = might be clearer names. It might be worth mentioning that W is real = power.=20 > On Mar 1, 2019, at 12:33 AM, Carsten Bormann wrote: >=20 > SenML (RFC 8428) has been a bit of a success story for this WG, at = least (but not only) with respect to pickup by other SDO. While we are = filling gaps in the specification itself (fetch/(i)patch, data-ct), = another item receives attention: SenML=E2=80=99s unit registry, which = can be useful for other SDOs even beyond the direct use of the SenML = data format. >=20 > In this context, a few units popped up that are somewhat in style with = the Celsius exception that RFC 8428 provides. Instead of just having = them registered silently, maybe it is good to have some attention for = them here in the WG. To that end, based on input from OMA (but all = mistakes are mine), I have written a draft: >=20 > Name: draft-bormann-senml-more-units > Revision: 00 > Title: Additional Units for SenML > Document date: 2019-02-27 > Group: Individual Submission > Pages: 4 > Status: = https://datatracker.ietf.org/doc/draft-bormann-senml-more-units/ > Htmlized: = https://tools.ietf.org/html/draft-bormann-senml-more-units-00 >=20 > Abstract: > The Sensor Measurement Lists (SenML) media type supports the > indication of units for a quantity represented. This short document > registers a number of additional unit names in the IANA registry for > Units in SenML. >=20 > Discussing physical quantities and their units may be not be the CoRE = WG=E2=80=99s center of gravity, but if you care about the integrity of = SenML, please have a look into this short draft. The IANA policies = allow us to go ahead with registration before this is an RFC (even = before any working group adoption!), which would fit well with OMA = timelines, so some feedback from the WG now would help getting that = right. >=20 > Sorry for forgetting the WG name in the draft name and going directly = to the name senml =E2=80=94 news of a new SenML WG are greatly = exaggerated :-) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Apr 17 10:03:39 2019 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 7642512033C for ; Wed, 17 Apr 2019 10:03:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=tuni.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 6P12KN_A3KgS for ; Wed, 17 Apr 2019 10:03:34 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80130.outbound.protection.outlook.com [40.107.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324361203D2 for ; Wed, 17 Apr 2019 10:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuni.onmicrosoft.com; s=selector1-tuni-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jBQDFRSGiygHZspXuUJEJmoOX/Gc0RiG1zA9viS+rWQ=; b=ScjyrNke5gedDYR5pMsA+qY93quIbea89pjXv9EekUw9ZP7J6361rdEu2FufFYTKmoPlBxSfSJ1XeyzRJbhXJPaGS0zok6Ox+NZFKtPwwvwyIgeW5PHpP/9RgmZ5wjBtM9Vm/miy/t2V1IYg49/HfAWL+GOlxlwA0IzisdtVX7Y= Received: from VI1PR08MB3086.eurprd08.prod.outlook.com (52.133.15.15) by VI1PR08MB3806.eurprd08.prod.outlook.com (20.178.14.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Wed, 17 Apr 2019 17:03:31 +0000 Received: from VI1PR08MB3086.eurprd08.prod.outlook.com ([fe80::90ee:2961:d2b7:62e2]) by VI1PR08MB3086.eurprd08.prod.outlook.com ([fe80::90ee:2961:d2b7:62e2%5]) with mapi id 15.20.1813.011; Wed, 17 Apr 2019 17:03:31 +0000 From: "Bilhanan Silverajan (TAU)" To: Hannes Tschofenig , "'core@ietf.org WG'" , Mert Ocak Thread-Topic: Dynlink examples Thread-Index: AdT0ZHk3yT3Cky7CRA+qz3MXhDPTGgA2ud6C Date: Wed, 17 Apr 2019 17:03:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tuni.fi; x-originating-ip: [88.217.199.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86a36f1d-55a4-4e58-1c37-08d6c3569e7d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR08MB3806; x-ms-traffictypediagnostic: VI1PR08MB3806: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(376002)(396003)(136003)(366004)(39860400002)(40434004)(189003)(199004)(486006)(110136005)(55016002)(53936002)(236005)(106356001)(316002)(1015004)(256004)(81156014)(81166006)(5024004)(14444005)(786003)(8676002)(9686003)(66066001)(25786009)(6246003)(6606003)(33656002)(6306002)(54896002)(19627405001)(221733001)(105586002)(229853002)(2906002)(478600001)(6436002)(3480700005)(8936002)(97736004)(14454004)(966005)(606006)(7116003)(53546011)(6506007)(26005)(52536014)(6116002)(446003)(11346002)(3846002)(102836004)(74482002)(5660300002)(71200400001)(71190400001)(186003)(99286004)(68736007)(74316002)(7696005)(7736002)(476003)(76176011)(86362001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR08MB3806; H:VI1PR08MB3086.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: tuni.fi does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 48cQTIIIKxHCpkYD/1e+m4e7Rnaloc2TidVKGHwWZmvEtEEJ91Mhx3SB0eS8hrkG1l/8QW5Zr/FwdT+2gHC/mBVH8dcg8hUbV6d1s6LghiAcfADTNFdmft4ycCYhY7KLoBGHiPSMW0fPbOokPzei28q8k+FyH9nCfSqWVglzxbkDJSf7js7qMBDxCU/GEwEqwKGJR52Fuykq44qvnNQXm4bvvUS2Tg9oDsU5yy/Q9IdwFB3ANXcYvzIj6MpUyr/FHgLOoE1N2nET02rb/VUAWz8UAveKUa8N0FaeiUQq/AKhK0BhTez2fPaDB+njRPK73pHq09A6LtkoECTbC+1xTK+pm9ujAT12Wys8u8QQbmQRUadPNmzuGVfUt0FfS5soj6pi/gHkpaoD41uXMY1rhSU2g65e5KgLJYZxoecii0Q= Content-Type: multipart/alternative; boundary="_000_VI1PR08MB3086C1A351BD34D0EB537D7CEF250VI1PR08MB3086eurp_" MIME-Version: 1.0 X-OriginatorOrg: tuni.fi X-MS-Exchange-CrossTenant-Network-Message-Id: 86a36f1d-55a4-4e58-1c37-08d6c3569e7d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 17:03:31.1225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa6944af-cc7c-4cd8-9154-c01132798910 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3806 Archived-At: Subject: Re: [core] Dynlink examples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 17:03:37 -0000 --_000_VI1PR08MB3086C1A351BD34D0EB537D7CEF250VI1PR08MB3086eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hannes, Mert, Thanks for pointing out the inconsistencies. I've fixed them in the latest = version of the draft. Best regards, Bill ________________________________ From: core on behalf of Hannes Tschofenig Sent: Tuesday 16 April 2019 17:56 To: 'core@ietf.org WG' Subject: [core] Dynlink examples Hi Dynlink authors, during our OMA DM conference call this week Mert noticed that the examples = in https://tools.ietf.org/html/draft-ietf-core-dynlink-08 are incorrect. For example, Figure 2 says > pmin=3D"10";pmax=3D"60" Since pmin and pmax are integer values they would be represented without qu= otes. The correct writing in this case would be > pmin=3D10;pmax=3D60 Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_VI1PR08MB3086C1A351BD34D0EB537D7CEF250VI1PR08MB3086eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi Hannes, Mert,

Thanks for pointing out the inconsistencies. I've fixed them in the la= test version of the draft.

Best regards,
Bill

From: core <core-bounces= @ietf.org> on behalf of Hannes Tschofenig <Hannes.Tschofenig@arm.com&= gt;
Sent: Tuesday 16 April 2019 17:56
To: 'core@ietf.org WG'
Subject: [core] Dynlink examples
 
Hi Dynlink authors,

during our OMA DM conference call this week Mert noticed that the examples = in https://tools.ietf.org/html/draft-ietf-core-dynlink-08 are incorrect.
For example, Figure 2 says

 > pmin=3D"10";pmax=3D"60"

Since pmin and pmax are integer values they would be represented without qu= otes.
The correct writing in this case would be

> pmin=3D10;pmax=3D60

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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.

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/l= istinfo/core
--_000_VI1PR08MB3086C1A351BD34D0EB537D7CEF250VI1PR08MB3086eurp_-- From nobody Wed Apr 24 06:47:21 2019 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 5B045120020; Wed, 24 Apr 2019 06:47:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155611363836.32100.4518601876204888053.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2019 06:47:18 -0700 Archived-At: Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-multipart-ct-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 13:47:19 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-multipart-ct-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few minor nits/points: (1) Section 1. Grammar Nit. s/This specification allows to indicate that/ This specification allows one to indication that/ (2) Section 1. Per “A third situation that is common only ever has a single representation in the sequence, which is one of a set of formats possible”, it isn’t clear to me what the dependent clause, “which is one of the a set of formats”, is suggesting. If there is only a single representation, how is there a “union of formats” as suggested by the follow-on sentence? (3) Section 2. The provided example of two representations is helpful. It would be useful to carry this example through and use it again in Implementation Hints section. (4) Section 2. Per “(This generally means the representation is not processes at all except if some stream processing has already happened.)”, the target of this observation isn’t clear to me – perhaps the third clause from the previous sentence about left over data? (5) Section 4. Nits. Make the section title case, like the other sections. s/Implementation hints/Implementation Hints/ From nobody Wed Apr 24 12:07:29 2019 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 B12B3120226; Wed, 24 Apr 2019 12:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dET-2-NB-pDa; Wed, 24 Apr 2019 12:07:17 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E351D120229; Wed, 24 Apr 2019 12:07:16 -0700 (PDT) Received: from [192.168.217.106] (p54A6CA34.dip0.t-ipconnect.de [84.166.202.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44q8vQ3kshzyhR; Wed, 24 Apr 2019 21:07:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155611363836.32100.4518601876204888053.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2019 21:07:13 +0200 Cc: The IESG , draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 577825632.393086-89e4187a9534fe933f4adcdb13851985 Content-Transfer-Encoding: quoted-printable Message-Id: References: <155611363836.32100.4518601876204888053.idtracker@ietfa.amsl.com> To: Roman Danyliw X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-multipart-ct-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 19:07:21 -0000 Hi Roman, thank you for your comments. We are working on addressing the IETF LC comments in the branch = ietf-lc-fixes on https://github.com/core-wg/multipart-ct, the current = state of which can we viewed at: = https://core-wg.github.io/multipart-ct/ietf-lc-fixes/draft-ietf-core-multi= part-ct.html and = https://tools.ietf.org/rfcdiff?url1=3Dhttps://core-wg.github.io/multipart-= ct/draft-ietf-core-multipart-ct.txt&url2=3Dhttps://core-wg.github.io/multi= part-ct/ietf-lc-fixes/draft-ietf-core-multipart-ct.txt Detailed responses below. Gr=C3=BC=C3=9Fe, Carsten > On Apr 24, 2019, at 15:47, Roman Danyliw via Datatracker = wrote: >=20 > Roman Danyliw has entered the following ballot position for > draft-ietf-core-multipart-ct-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A few minor nits/points: >=20 > (1) Section 1. Grammar Nit. >=20 > s/This specification allows to indicate that/ > This specification allows one to indication that/ Barry Leiba already proposed a fix for this that we like, see branch = linked above. > (2) Section 1. Per =E2=80=9CA third situation that is common only = ever has a single > representation in the sequence, which is one of a set of formats = possible=E2=80=9D, it > isn=E2=80=99t clear to me what the dependent clause, =E2=80=9Cwhich is = one of the a set of > formats=E2=80=9D, is suggesting. If there is only a single = representation, how is > there a =E2=80=9Cunion of formats=E2=80=9D as suggested by the = follow-on sentence? New text that is maybe more clear: A third situation that is common only ever has a single representation in the sequence, which selects one of a set of formats possible for this situation. This kind [=E2=80=A6] > (3) Section 2. The provided example of two representations is = helpful. It > would be useful to carry this example through and use it again in > Implementation Hints section. I append some text showing the encoding of the example at the end of = section 4 now. > (4) Section 2. Per =E2=80=9C(This generally means the representation = is not processes > at all except if some stream processing has already happened.)=E2=80=9D,= the target of > this observation isn=E2=80=99t clear to me =E2=80=93 perhaps the third = clause from the previous > sentence about left over data? It is trying to say that the result of the MUST is that most = implementations will detect the wellformedness error (or data left after = a well-formed representation) before making use of the data; streaming = implementations being the exception that we don=E2=80=99t want to rule = out here completely. How could we clarify this? > (5) Section 4. Nits. Make the section title case, like the other = sections. >=20 > s/Implementation hints/Implementation Hints/ Also fixed now in the above branch. From nobody Mon Apr 29 06:45:02 2019 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 EB05012031A; Mon, 29 Apr 2019 06:44:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 06:44:53 -0700 Archived-At: Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-multipart-ct-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:44:54 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-core-multipart-ct-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One minor question: I don't fully understand why the new content format is called "application/multipart-core". Does "core" stand for the core working group? Shouldn't it rather be "application/multipart-coap"? Also why "multipart" and not e.g. "multicontent"? I guess it doesn't matter that much but was mainly wondering where the naming came from... From nobody Mon Apr 29 07:21:43 2019 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 7E0D712004E; Mon, 29 Apr 2019 07:21:42 -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 A1KjUBbttab2; Mon, 29 Apr 2019 07:21:40 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC95120333; Mon, 29 Apr 2019 07:21:40 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44t6KZ6GQ1zym8; Mon, 29 Apr 2019 16:21:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 16:21:38 +0200 Cc: The IESG , core-chairs@ietf.org, Jaime Jimenez , draft-ietf-core-multipart-ct@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 578240496.080669-f9a39b5a5c2d19b836f74f75066f893a Content-Transfer-Encoding: quoted-printable Message-Id: <1FF60F4A-CD4D-47D1-B26E-9F321F04947C@tzi.org> References: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-multipart-ct-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 14:21:43 -0000 Hi Mirja, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > One minor question: I don't fully understand why the new content = format is > called "application/multipart-core". Does "core" stand for the core = working > group? Shouldn't it rather be "application/multipart-coap"? Also why > "multipart" and not e.g. "multicontent"? I guess it doesn't matter = that much > but was mainly wondering where the naming came from=E2=80=A6 Originally, I had proposed to call it =E2=80=9Cmultipart/core=E2=80=9D = and then Alexey pointed out that a multipart media type has to fulfill = certain formal requirements that we didn=E2=80=99t need. So it became = =E2=80=9Capplication/multipart-core=E2=80=9D. Now why core? We have been using CoRE, =E2=80=9CConstrained RESTful = Environments=E2=80=9D(*) as an abbreviation for using the = representational state transfer (REST) architectural style in the = constrained environments that multipart-core is designed for. An early = example is the title of RFC 6690: CoRE Link Format. The media type will = not only be used with CoAP, but in other contexts that employ media = types as well. For shortcuts for the embedded media types, it does = employ the Content-Format registry that is part of the =E2=80=9CCoRE = parameters=E2=80=9D IANA registry (CoRE, again) for CoAP and other = applications. ((*) That probably should have been REST-style, or REST-based, as = RESTful is one of these =E2=80=9Cessentially contested concepts=E2=80=9D = [1].) Gr=C3=BC=C3=9Fe, Carsten [1]: https://en.wikipedia.org/wiki/Essentially_contested_concept From nobody Mon Apr 29 07:22:20 2019 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 83088120333; Mon, 29 Apr 2019 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 axzg-akgWXxC; Mon, 29 Apr 2019 07:22:16 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0626.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::626]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D399F12004E; Mon, 29 Apr 2019 07:22:15 -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=G8ifRDG/UT7OFrEvFHvGg9EOL9RoOiS0sIF8Mx7RlaY=; b=YEEHlapwizIZJdCUIJNg5FzHKEMNPSClLX0YGopzXa2EruFucecusagpp3T/aEeyYDUAcwtgI7krCbhMCWIYCYmtJya4/MaQ4f+hxy82x18wfp4UwUjpHOofMXbfaNL2Vr0x+OcvX4BZ5WxHZH4nl5aAzN+D4l9DZ7OhclNBaGs= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.4.202) by AM6PR08MB4817.eurprd08.prod.outlook.com (10.255.98.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.15; Mon, 29 Apr 2019 14:22:13 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5482:1855:4483:98f1]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5482:1855:4483:98f1%5]) with mapi id 15.20.1835.018; Mon, 29 Apr 2019 14:22:13 +0000 From: Thomas Fossati To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-core-multipart-ct@ietf.org" , Jaime Jimenez , "core-chairs@ietf.org" , "core@ietf.org" , Thomas Fossati Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-core-multipart-ct-03:_(with_COMMENT)?= Thread-Index: AQHU/pG7HPt9w6m7/UGhaJY7wOSPoKZTQX8A Date: Mon, 29 Apr 2019 14:22:12 +0000 Message-ID: References: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> In-Reply-To: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [217.140.106.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6a2b6d4-8373-4689-fa9f-08d6ccae12cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4817; x-ms-traffictypediagnostic: AM6PR08MB4817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(396003)(346002)(366004)(51914003)(189003)(199004)(40434004)(66946007)(99286004)(66556008)(91956017)(224303003)(14454004)(76116006)(82746002)(66476007)(66446008)(64756008)(53546011)(102836004)(486006)(476003)(446003)(26005)(186003)(71190400001)(76176011)(71200400001)(11346002)(6506007)(2616005)(14444005)(5660300002)(36756003)(5024004)(256004)(83716004)(6116002)(2906002)(3846002)(86362001)(73956011)(66574012)(229853002)(478600001)(6436002)(72206003)(6486002)(7736002)(6512007)(81156014)(53936002)(305945005)(66066001)(6246003)(97736004)(54906003)(316002)(8936002)(33656002)(4326008)(110136005)(25786009)(68736007)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4817; H:AM6PR08MB4231.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sMj1azX649si4/7qpcr3tb4D6XB6M4La1DhSe0JQL7MhW5+oNPwUDKbqupsC5Ua3T475225i5yDns327G1VFiyLzxZuzfHVD444pLhddR0BcNwqXdRnLcfNd9k6vzMUIiLeuKcEYyb36LQvDqv7zrg+UB7eJBkdqGuEYKJRkGdkO8Z3tpfnDhCcnEbKm+b/JNExLVZz3/PpQ6/UzMWMQuHXslBiPSvmE+T1X6mdvU8UEpCFhU7m3LBTcM97KnAp3U3mQN36xoIod1rbA2zsq+cX2NhmzBOMPlkYl8rmKumMUot0OrqtOp4g2SKAKyjYd/ZPbNVNCqF7nNtrDrUIhwuRBxxiBB7+Ou7xpCjIkBjsPxFfwUDRg3jcIULMlNTtDrmQLHpfYsuq8hITXLdi2SKg2HUkbpE64fMd8csK8m74= Content-Type: text/plain; charset="utf-8" Content-ID: <08088789BCCD4B48B78445BADCDCF4A9@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6a2b6d4-8373-4689-fa9f-08d6ccae12cc X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 14:22:13.0002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4817 Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-multipart-ct-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 14:22:18 -0000 SGkgTWlyamEsIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIQ0KDQpPbiAyOS8wNC8yMDE5LCAxNDo0 NCwgIk1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4g d3JvdGU6DQo+IEkgZG9uJ3QgZnVsbHkgdW5kZXJzdGFuZCB3aHkgdGhlIG5ldyBjb250ZW50IGZv cm1hdCBpcyBjYWxsZWQgImFwcGxpY2F0aW9uL211bHRpcGFydC1jb3JlIi4gRG9lcyAiY29yZSIg c3RhbmQgZm9yIHRoZSBjb3JlIHdvcmtpbmcgZ3JvdXA/DQoNClllcy4NCg0KPiBTaG91bGRuJ3Qg aXQgcmF0aGVyIGJlICJhcHBsaWNhdGlvbi9tdWx0aXBhcnQtY29hcCI/DQoNCnMvY29yZS9jb2Fw LyB3b3VsZCBiZSBzbGlnaHRseSBtb3JlIHByZWNpc2Ugc2luY2UgdGhlIHRoaW5ncyB3ZSBhcmUg bWl4aW5nIGhlcmUgYXJlIENvQVAgQ29udGVudC1Gb3JtYXRzLCBzbyB5ZXMgeW91J3JlIHByb2Jh Ymx5IHJpZ2h0LiAgQXQgdGhlIHNhbWUgdGltZSB0aGlzIGlzIGxheWVyIDYgb2JqZWN0IHdoaWNo IGlzIG5vdCBsaW1pdGVkIHRvIHRoZSBDb0FQIHRyYW5zcG9ydCwgc28gbWF5YmUgdXNpbmcgYSBu YW1lIGlkZW50aWZ5aW5nIGEgd2lkZXIgc2NvcGUgaXMgbm90IGEgdGVycmlibGUgaWRlYS4NCg0K PiBBbHNvIHdoeSAibXVsdGlwYXJ0IiBhbmQgbm90IGUuZy4gIm11bHRpY29udGVudCI/DQoNCk1h eWJlIG11bHRpZm9ybWF0PyA6LSkuICBKb2tlcyBhc2lkZSwgIm11bHRpcGFydCIgaXMgYSBub2Qg dG8gdGhlIGhvbm91cmFibGUgTUlNRSBtdWx0aXBhcnQgY29udGVudCB0eXBlLCB3aGljaCBwcm92 aWRlZCB0aGUgaW5zcGlyYXRpb24gZm9yIHRoaXMuDQoNCkkgZ3Vlc3MgaWYgd2UgY291bGQgZ28g YmFjayBpbiB0aW1lIGl0J2QgYmUgd29ydGggc3BlbmRpbmcgYSBmZXcgbW9yZSBjeWNsZXMgdHJ5 aW5nIHRvIHBpY2sgYSBiZXR0ZXIgbmFtZSwgYnV0IGF0IHRoaXMgc3RhZ2UgaXQgc2VlbXMgdG8g bWUgdGhhdCB0aGlzIGlzIHRoZSBoYW5kbGUgdGhhdCBmb2xrcyBpbiBDb1JFIGFuZCBBTklNQSBo YXZlIGdvdCB1c2VkIHRvIGFuZCBjaGFuZ2luZyBpdCB3b3VsZCBjcmVhdGUgYSBiaXQgb2YgdW5u ZWNlc3NhcnkgY29uZnVzaW9uPw0KDQpDaGVlcnMsIHRoYW5rcw0KdA0KDQoNCklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Mon Apr 29 07:51:58 2019 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 CAA9412033E; Mon, 29 Apr 2019 07:51:49 -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, 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 fYhyyFpN2FWw; Mon, 29 Apr 2019 07:51:47 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 64CFF12031C; Mon, 29 Apr 2019 07:51:47 -0700 (PDT) Received: from 200116b82ccdbd001157d185e6caa96e.dip.versatel-1u1.de ([2001:16b8:2ccd:bd00:1157:d185:e6ca:a96e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hL7dB-00085s-BU; Mon, 29 Apr 2019 16:51:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 29 Apr 2019 16:51:44 +0200 Cc: The IESG , "core-chairs@ietf.org" , Jaime Jimenez , "draft-ietf-core-multipart-ct@ietf.org" , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3C303AC3-1483-49D9-8CBB-A45AA5F6F9B2@kuehlewind.net> References: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> To: Thomas Fossati X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1556549507;192970bf; X-HE-SMSGID: 1hL7dB-00085s-BU Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-multipart-ct-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 14:51:50 -0000 Hi Thomas, See below. > On 29. Apr 2019, at 16:22, Thomas Fossati = wrote: >=20 > Hi Mirja, thanks for the comments! >=20 > On 29/04/2019, 14:44, "Mirja K=C3=BChlewind via Datatracker" = wrote: >> I don't fully understand why the new content format is called = "application/multipart-core". Does "core" stand for the core working = group? >=20 > Yes. >=20 >> Shouldn't it rather be "application/multipart-coap"? >=20 > s/core/coap/ would be slightly more precise since the things we are = mixing here are CoAP Content-Formats, so yes you're probably right. At = the same time this is layer 6 object which is not limited to the CoAP = transport, so maybe using a name identifying a wider scope is not a = terrible idea. >=20 >> Also why "multipart" and not e.g. "multicontent"? >=20 > Maybe multiformat? :-). Jokes aside, "multipart" is a nod to the = honourable MIME multipart content type, which provided the inspiration = for this. >=20 > I guess if we could go back in time it'd be worth spending a few more = cycles trying to pick a better name, but at this stage it seems to me = that this is the handle that folks in CoRE and ANIMA have got used to = and changing it would create a bit of unnecessary confusion? Yes, if that=E2=80=99s already in use and implemented, it probably = doesn=E2=80=99t make sense to change it. I was just wondering=E2=80=A6 Mirja >=20 > Cheers, thanks > t >=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. From nobody Mon Apr 29 07:52:58 2019 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 249F612033E; Mon, 29 Apr 2019 07:52:56 -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, 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 v6ol8zJqgWrF; Mon, 29 Apr 2019 07:52:54 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 4B01812031C; Mon, 29 Apr 2019 07:52:54 -0700 (PDT) Received: from 200116b82ccdbd001157d185e6caa96e.dip.versatel-1u1.de ([2001:16b8:2ccd:bd00:1157:d185:e6ca:a96e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hL7eG-00005t-Sb; Mon, 29 Apr 2019 16:52:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: <1FF60F4A-CD4D-47D1-B26E-9F321F04947C@tzi.org> Date: Mon, 29 Apr 2019 16:52:52 +0200 Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, The IESG , core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04777153-CA04-40EB-85F7-67E7E315ABBE@kuehlewind.net> References: <155654549395.15746.4472278849644812167.idtracker@ietfa.amsl.com> <1FF60F4A-CD4D-47D1-B26E-9F321F04947C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1556549574;318c7cdb; X-HE-SMSGID: 1hL7eG-00005t-Sb Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-multipart-ct-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 14:52:56 -0000 Hi Carsten, Thanks for the explanation. I was just wondering. So I guess the naming = is fine. Mirja > On 29. Apr 2019, at 16:21, Carsten Bormann wrote: >=20 > Hi Mirja, >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> One minor question: I don't fully understand why the new content = format is >> called "application/multipart-core". Does "core" stand for the core = working >> group? Shouldn't it rather be "application/multipart-coap"? Also why >> "multipart" and not e.g. "multicontent"? I guess it doesn't matter = that much >> but was mainly wondering where the naming came from=E2=80=A6 >=20 > Originally, I had proposed to call it =E2=80=9Cmultipart/core=E2=80=9D = and then Alexey pointed out that a multipart media type has to fulfill = certain formal requirements that we didn=E2=80=99t need. So it became = =E2=80=9Capplication/multipart-core=E2=80=9D. >=20 > Now why core? We have been using CoRE, =E2=80=9CConstrained RESTful = Environments=E2=80=9D(*) as an abbreviation for using the = representational state transfer (REST) architectural style in the = constrained environments that multipart-core is designed for. An early = example is the title of RFC 6690: CoRE Link Format. The media type will = not only be used with CoAP, but in other contexts that employ media = types as well. For shortcuts for the embedded media types, it does = employ the Content-Format registry that is part of the =E2=80=9CCoRE = parameters=E2=80=9D IANA registry (CoRE, again) for CoAP and other = applications. >=20 > ((*) That probably should have been REST-style, or REST-based, as = RESTful is one of these =E2=80=9Cessentially contested concepts=E2=80=9D = [1].) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > [1]: https://en.wikipedia.org/wiki/Essentially_contested_concept >=20 >=20 From nobody Mon Apr 29 23:31:26 2019 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 7B4BC1200E3; Mon, 29 Apr 2019 23:31:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155660587850.12863.3531895290991565789.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 23:31:18 -0700 Archived-At: Subject: [core] Adam Roach's No Objection on draft-ietf-core-multipart-ct-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 06:31:19 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-multipart-ct-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone put in on this document. The "Usage Examples" section seems a bit odd, since it only describes the use of this new content type for sending a response prior to the response body becoming available. The introduction does not give the impression that this is the primary use case -- it implies that this new format is primarily intended to be used in a similar fashion as the traditional multipart/* media types. Perhaps there should be some additional examples in section 3 that outline these more common cases? Alternately, if I have misunderstood the primary use case for this mechanism, then I would humbly offer that the introduction needs substantial revision. From nobody Tue Apr 30 06:20:17 2019 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 0FF3212007A for ; Tue, 30 Apr 2019 06:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 9d-Fg8_VknPB for ; Tue, 30 Apr 2019 06:20:09 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 5AEDC120006 for ; Tue, 30 Apr 2019 06:20:09 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 4so3790702wmf.1 for ; Tue, 30 Apr 2019 06:20:09 -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=Gp4CrAoL3X4SJ/pp4skcC8U/IlTPmKi8lE0cwYl2yAg=; b=KJrPZ7WUgfsnCmKvxf+2AppMshSi3OgkaceCdjOpQ0/BLnpFrAWW5wXzaynNDbyUwc d4sKR3EJiW1Jt+OuHTEUfUJgUUo0RTCKrrGVBFnqoeAQp+Bom5mxxW4e43+HK/xBcBCj HwfveG+5fqwhvCWOfXvKMIwrvFC4NSq3VCD0v/vkOh+PcETqgeJZyLR6nO4f9rEurM9g WLq/IWvoxHSCV/3KP2bV9+EPMvIZLS0DWXqpbn/MDZiTQ0WPfKAYyHtRk0zaVjkw9w2D kJpgJypfGufyxJnIDJMvVYvk63z6giIoIKWt9iihRFc/b/kUK/n68xuhwMrIY08Oqusf NLAA== 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=Gp4CrAoL3X4SJ/pp4skcC8U/IlTPmKi8lE0cwYl2yAg=; b=jvwG+hOFzil2vmGqKDlfn8i/SbOxu2Gxj/9e5Ny9axUpp9wWins7DxeqUH17cbulZr Vc6nw02t30qYhvupIWyB6D03VrVadq7muLtkRaO/o9Dtams415TLhU4jLDcnijD7swaC m9AFSr7itJ8UjvLAv5UloxGsIL8VRg47w1cW/36hT+gyEhkxGh5f28xLoHJlmf2ZTp/A FCid2KMr/T9iOIE+SoZKjEtwGssaQdvbik1pHauWsEV+whQr1pUGOwa3MpgKUZlNfs8y XNG4P7cIMTTdOBZ5UlZlgDYItOasIxoeQg0ORWPPRgsCmxI5VGZFVkx46Faa/Da+ympx 2z5A== X-Gm-Message-State: APjAAAW0OnTJnXef6pnfBOVE1sS8PhGwiBvhKR8ePGnznEsGborFkzoK aDOzEd7CKlJtek2weBkhC97zJrLgENV+smzaLkU= X-Google-Smtp-Source: APXvYqw9GLS/XSW5rfYmCYT+2FwTrTpeSyWn5WT8kJNfbKKB2Pxa7/sAVxfCDvzpbchWVf4Miy15TapO/QnVRfTZOFs= X-Received: by 2002:a1c:7d92:: with SMTP id y140mr3064628wmc.54.1556630407801; Tue, 30 Apr 2019 06:20:07 -0700 (PDT) MIME-Version: 1.0 References: <155413839109.17114.2318273093661309081.idtracker@ietfa.amsl.com> <20190402054015.GA22410@hephaistos.amsuess.com> <20190409094112.GA15632@hephaistos.amsuess.com> In-Reply-To: <20190409094112.GA15632@hephaistos.amsuess.com> From: Badis Djamaa Date: Tue, 30 Apr 2019 15:19:29 +0200 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: ali yachir , core@ietf.org Content-Type: multipart/alternative; boundary="0000000000008101bb0587bf4279" Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 13:20:15 -0000 --0000000000008101bb0587bf4279 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Christian, Thank you for your feedback,please see my comments inline On Tue, 9 Apr 2019 at 11:41, Christian Ams=C3=BCss = wrote: > Hello Badis, > > some replies inline: > > On Tue, Apr 02, 2019 at 08:42:19PM +0200, Badis Djamaa wrote: > > The text in the RD draft seems to indicate that the "(6LBR) can act > > as a resource directory". Thus, the 6LBR address can be announced in > > the ABRO and confirmation of RD function can be done by unicasting > > "coap://[6LBR]/.well-known/core?rt=3Dcore.rd*". > > That is exactly how contacting an RD via the 6LBR works; however, the > 6LBR may only host the .well-known part of the RD but not the > registration and lookup resources. (This comment's main purpose was to > highlight alternatives to the "inconvenien[ce] of imposing that the RD > be physically integrated" with the 6LBR.) > > > Otherwise, how would the RD be announced to the 6LBR (not mentioned i= n > > the RD draft )? > > That is out of scope for the RD document, but I'd assume it would happen > about the same way the 6LBR is configured to send ND options, or how a > DHCP server is configured to send a particular option. > I can think of a way here. Let an RD announces its address(es) in the RDAO ND option. When RDAO arrives to the 6LBR, it knows that it contains an RD address. The 6LBR can then construct a resource with rt=3Dcore.rd and base=3DRD address. Doing so the endpoint can GET the RD address from the 6LBR, which allows it to contact the RD directly for URI discovery as in section 4.3 of the CoRE-RD draft. > > > In the current version, the rd template value may be assumed a > > default location, for instance, "core-rd". The Location-URI > > Template would be then /core-rd/ep where ep comes from the RD's > > "ep" attribute contained in the registration request, which is > > unique per RD. Another possibility is to locate the posted RD > > resource under well-known/core/ep at each device. > > What is your take on this? > > Anything outside /.well-known/ should not be fixed by specifications > according to RFC7320. > > I don't have any concrete suggestions yet as to where those updates > should ideally go to. > > OK, thank you for outlining RFC7320, below are some thoughts concerning this issue: 1- To stay compatible with RFC7320 recommendations, one basic option is to simply POST the registration to well-known/core. However, and since the replies are suppressed, the RD won't know the registration location. This does not affect the periodic updates, but it can affect the explicit registration removal interface. One intuition to deal with this, is not to provide an explicit removal interface. Indeed, RD registrations will be removed at the expiry of their lifetime. The inconvenient arising from this (i.e. an RD no longer available, but endpoints still have active registrations) can be mitigated. For instance, an endpoint not getting a response from an RD after some tentative may delete the RD registration. 2- I thought also not to suppress the responses, but such a solution increases traffic, adds burden on an RD to manage all locations, and makes explicit registration removal more complex. For instance, the RD should unicast each endpoint to delete its registration. 3- Also, the nontraditional response way you mentioned will have difficulty to manage explicit registration removal. Indeed, while announcements can be realized as a response with embedded request, I cannot see how a delete will be carried out? I prefer proposition 1 to propositions 2 and 3. All, however, find difficulties to manage explicit registration removal. The main issue for that is the use of DELETE within multicast. It might be useful to discuss such use? (in other words, is it possible to relax RFC 2370 recommendations for the case of multicast). Alternatively, and inspired by the simple registration interface of CoRE-RD, an RD might send a POST request with an empty body in order to emulate a DELETE. Such a request triggers the removal of the RD registration from endpoints. With this alternative, the issue with RD template can be mitigated ? > > > * The DA generation process looks like every device is supposed to be a > > > simple RD (that may be only capable of accepting a single > > > registration, which is that of the actual ID), that is then > > > replicated. > > > > > > Maintaining such replication seems to me to be quite a task for sma= ll > > > nodes, especially if they're supposed to use the registration updat= e > > > interface and thus remember locations for each sub-PRD they > registered > > > to (though I'm not sure what is intended here, "SHOULD only contain > > > the content and parameters that have been changed" seems to imply > > > registration update, while 4.1.1 describes the registration interfa= ce > > > which can't rely on previous registrations). > > > > True, but DA is only generated by the RD and forwarded using CoAP Gro= up > > Communication. Devices do no replication tasks. Also, very > > constrained devices (section 5.2 of RD), may simply ignore the > > received DA (see section 3) > > OK, that was not fully clear to me before, especially with the open > question about the registration location. > > > Also, the current version of PRD does not use a separate resource > > update interface. Both the first registration (which doesn't rely on > > previous registrations) and periodic updates sent by RDs (relying on > > previous registrations) use the registration interface. The > > difference is that in the latter, the optional unchanged parameters > > and payload are not POSTed. Processing of the received DA, for both > > cases, is specified in section 4.1.2. > > As this is all intended for multicast and nodes joining the network, how > can there be a difference between a first registration and periodic > updates, which may arrive at devices that haev not seen the first > registration? > Thank you for raising this important issue. As a remedy, I can think of three solutions: 1- Send all the information either in the first and the update. Cons: waste of resource although this might be acceptable, knowing the infrequency of RD updates and the limited size of the registration resource. Pros: it solves all issues. 2- The new joining nodes SHOULD use DS to ask for the information from neighbors upon joining The network. If this is not already done before getting the RD update for the first time, the node SHOULD issue a DS to make sure that it has all the information. In this case, only already-aware updated neighbors reply. Cons: It might not be available any already-aware neighbor in the vicinity. In addition, this imposes for nodes to send DS even for the first received registration. To avoid this latter, the RD might specify in the POSTed resource in a TBD attribute whether it is a registration or an update. 3- In the third option, the node receiving an update, might directly unicast the RD, to get the information. This has the same drawbacks as in 2. In addition, it might creates a burden on the RD if the number of simultaneous joiners is important. I would prefer the first option. What do you think? > > > > The document may benefit from exploring alternatives here (even if > > > only to confirm the conclusion that the approach taken is the right > > > one), like using the Simple Registration interface (would answer th= e > > > question ad 4.1.1) or setting the announcements up as nontraditiona= l > > > responses[1] (eg. notifications about an unspoken request to GET > > > /.well-known/core?rt=3Dcore.rd. I can't tell whether that'd even be= a > > > good idea, that's yet to be seen). > > > > [...] Nontraditional Responses (NR) need the devices to be aware of > the RD > > location. > > Not necessarily; the NR could contain all the necessary request details > as in [1]. > > [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00#section-= 2 > > Agree > > * [...] whether there is anything in particular about RD announcements > > > in it as compared to general link announcments. > > > > Thank you for this suggestion, we will consider it in future versions. > Can you > > please indicate some key services that need to be announced. > > That very much depends on the particular use case, but if there is > anything that most devices joining the network would query right after > having discovered the RD, that would be it. > > For example, in a setup that uses tiloca-core-oscore-discovery[2], it > might make sense to not only send the RD's data but also the links to > the most frequently joined join resources. (Not that the frequency of > group members joining would be likely to warrant this, but if it were > frequent enough that proactive-rd made sense, sending those links to > join resources proactively would just make as much sense.) > > [2]: https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-02 > > Thank you for mentioning this draft, we are working to consider such services and similar (e.g., Announce Available Groups for nodes to join) for he next version of the draft Best regards > Christian > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom > All the best, Badis --0000000000008101bb0587bf4279 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Christian,
Thank you for your feedback,please see my comments inline
<= br>
On Tue,= 9 Apr 2019 at 11:41, Christian Ams=C3=BCss <christian@amsuess.com> wrote:
Hello Badis,

some replies inline:

On Tue, Apr 02, 2019 at 08:42:19PM +0200, Badis Djamaa wrote:
>=C2=A0 The text in the RD draft seems to indicate that the "(6LBR)= can act
>=C2=A0 as a resource directory". Thus, the 6LBR address can be ann= ounced in
>=C2=A0 the ABRO and confirmation of RD function can be done by unicasti= ng
>=C2=A0 "coap://[6LBR]/.well-known/core?rt=3Dcore.rd*".

That is exactly how contacting an RD via the 6LBR works; however, the
6LBR may only host the .well-known part of the RD but not the
registration and lookup resources. (This comment's main purpose was to<= br> highlight alternatives to the "inconvenien[ce] of imposing that the RD=
be physically integrated" with the 6LBR.)

>=C2=A0 =C2=A0Otherwise, how would the RD be announced to the 6LBR (not = mentioned in
>=C2=A0 =C2=A0the RD draft )?

That is out of scope for the RD document, but I'd assume it would happe= n
about the same way the 6LBR is configured to send ND options, or how a
DHCP server is configured to send a particular option.

I can think of a way here. Let an RD announces its address(= es) in the RDAO ND option.
When RDAO arrives to the 6LBR, it knows that = it contains an RD address. The
6LBR can then construct a resource with = rt=3Dcore.rd and base=3DRD address. Doing so
the endpoint can GET the RD= address from the 6LBR, which allows it to contact the RD directly
for = URI discovery as in section 4.3 of the CoRE-RD draft.
=C2=A0<= /div>

>=C2=A0 =C2=A0 In the current version, the rd template value may be assu= med a
>=C2=A0 =C2=A0 default location, for instance, "core-rd". The = Location-URI
>=C2=A0 =C2=A0 Template would be then /core-rd/ep where ep comes from th= e RD's
>=C2=A0 =C2=A0 "ep" attribute contained in the registration re= quest, which is
>=C2=A0 =C2=A0 unique per RD. Another possibility is to locate the poste= d RD
>=C2=A0 =C2=A0 resource under well-known/core/ep at each device.
>=C2=A0 =C2=A0What is your take on this?

Anything outside /.well-known/ should not be fixed by specifications
according to RFC7320.

I don't have any concrete suggestions yet as to where those updates
should ideally go to.

=C2=A0OK, thank you for outlining RFC7320, below are = some thoughts concerning this issue:

=C2=A0=C2=A0= =C2=A0=C2=A0 1- To stay compatible with RFC7320 recommendations, one basic = option is to simply POST the registration
=C2=A0=C2=A0=C2=A0 =C2=A0to w= ell-known/core. However, and since the replies are suppressed, the RD won&#= 39;t know the registration location.
=C2=A0=C2=A0=C2=A0=C2=A0 This does = not affect the periodic updates, but it can affect the explicit registratio= n removal interface.
=C2=A0=C2=A0=C2=A0=C2=A0 One intuition = to deal with this, is not to provide an explicit removal interface. Indeed,= RD registrations will be removed
=C2=A0=C2=A0=C2=A0=C2=A0 a= t the expiry of their lifetime. The inconvenient arising from this (i.e. an= RD no longer available, but endpoints
=C2=A0=C2=A0=C2=A0 =C2=A0still h= ave active registrations) can be mitigated. For instance, an endpoint not g= etting a response from an RD after some
=C2=A0=C2=A0=C2=A0= =C2=A0 tentative may delete the RD registration.
=C2=A0=C2=A0=C2=A0 =C2= =A0
=C2=A0=C2=A0=C2=A0 =C2=A02- I thought also not to suppress the respo= nses, but such a solution increases traffic, adds
=C2=A0=C2=A0=C2=A0 =C2= =A0burden on an RD to manage all locations, and makes explicit registration= removal more complex.
=C2=A0=C2=A0=C2=A0=C2=A0 For instance, the RD sho= uld unicast each endpoint to delete its registration.
=C2=A0=C2=A0=C2=A0= =C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A03- Also, the nontraditional response wa= y you mentioned will have difficulty to manage explicit registration remova= l.
=C2=A0=C2=A0=C2=A0 =C2=A0Indeed, while announcements can be realized = as a response with embedded request, I cannot see how a delete will
=C2= =A0=C2=A0=C2=A0 =C2=A0be carried out?
=C2=A0=C2=A0=C2=A0 =C2=A0
=C2= =A0=C2=A0=C2=A0=C2=A0 I prefer proposition 1 to propositions 2 and 3. All, = however, find difficulties to manage explicit registration removal.
=C2=A0=C2=A0=C2=A0=C2=A0 The main issue for that is the use of DELE= TE within multicast. It might be useful to discuss such use?=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 (in other words, is it possible to relax RF= C 2370 recommendations for the case of multicast).

=C2=A0=C2=A0=C2=A0=C2=A0 Alternatively, and inspired by the simple registr= ation interface of CoRE-RD, an RD might send a POST request with an
=C2=A0=C2=A0=C2=A0=C2=A0 empty body in order to emulate a DELETE. S= uch a request triggers the removal of the RD registration from endpoints.
=C2=A0=C2=A0=C2=A0=C2=A0 With this alternative, the issue with RD = template can be mitigated ?

> * The DA generation process looks like every device is supposed to be = a
> >=C2=A0 =C2=A0simple RD (that may be only capable of accepting a si= ngle
> >=C2=A0 =C2=A0registration, which is that of the actual ID), that i= s then
> >=C2=A0 =C2=A0replicated.
> >
> >=C2=A0 =C2=A0Maintaining such replication seems to me to be quite = a task for small
> >=C2=A0 =C2=A0nodes, especially if they're supposed to use the = registration update
> >=C2=A0 =C2=A0interface and thus remember locations for each sub-PR= D they registered
> >=C2=A0 =C2=A0to (though I'm not sure what is intended here, &q= uot;SHOULD only contain
> >=C2=A0 =C2=A0the content and parameters that have been changed&quo= t; seems to imply
> >=C2=A0 =C2=A0registration update, while 4.1.1 describes the regist= ration interface
> >=C2=A0 =C2=A0which can't rely on previous registrations).
>
>=C2=A0 =C2=A0True, but DA is only generated by the RD and forwarded usi= ng CoAP Group
>=C2=A0 =C2=A0Communication. Devices do no replication tasks. Also, very=
>=C2=A0 =C2=A0constrained devices (section 5.2 of RD), may simply ignore= the
>=C2=A0 =C2=A0received DA (see section 3)

OK, that was not fully clear to me before, especially with the open
question about the registration location.

>=C2=A0 =C2=A0Also, the current version of PRD does not use a separate r= esource
>=C2=A0 =C2=A0update interface. Both the first registration (which doesn= 't rely on
>=C2=A0 =C2=A0previous registrations) and periodic updates sent by RDs (= relying on
>=C2=A0 =C2=A0previous registrations) use the registration interface. Th= e
>=C2=A0 =C2=A0difference is that in the latter, the optional unchanged p= arameters
>=C2=A0 =C2=A0and payload are not POSTed. Processing of the received DA,= for both
>=C2=A0 =C2=A0cases, is specified in section 4.1.2.

As this is all intended for multicast and nodes joining the network, how can there be a difference between a first registration and periodic
updates, which may arrive at devices that haev not seen the first
registration?

Thank you for raising thi= s important issue. As a remedy, I can think of three solutions:
<= br>1- Send all the information either in the first and the update.
=C2= =A0=C2=A0 Cons: waste of resource although this might be acceptable, knowin= g the infrequency of RD updates
=C2=A0=C2=A0 and the limited size of th= e registration resource.
=C2=A0=C2=A0 Pros: it solves all issues.
=C2= =A0=C2=A0
2- The new joining nodes SHOULD use DS to ask for the informa= tion from neighbors upon joining
=C2=A0=C2=A0 The network. If this is no= t already done before getting the RD update for the first time, the node SH= OULD
=C2=A0=C2=A0 issue a DS to make sure that it has all the informatio= n. In this case, only already-aware
=C2=A0=C2=A0 updated neighbors reply= .
=C2=A0=C2=A0 Cons: It might not be available any already-aware neighb= or in the vicinity. In addition,
=C2=A0=C2=A0 this imposes for nodes to= send DS even for the first received registration. To avoid this latter, th= e RD
=C2=A0=C2=A0 might specify in the POSTed resource in a TBD attribut= e whether it is a registration or an update.=C2=A0
=C2=A0=C2=A0
3- = In the third option, the node receiving an update, might directly unicast t= he RD, to get the information.
=C2=A0=C2=A0 This has the same drawbacks = as in 2. In addition, it might creates
=C2=A0=C2=A0 a burden on the RD i= f the number of simultaneous joiners is important.=C2=A0=C2=A0=C2=A0
<= div>
I would prefer the first option. What do you think?

> >=C2=A0 =C2=A0The document may benefit from exploring alternatives = here (even if
> >=C2=A0 =C2=A0only to confirm the conclusion that the approach take= n is the right
> >=C2=A0 =C2=A0one), like using the Simple Registration interface (w= ould answer the
> >=C2=A0 =C2=A0question ad 4.1.1) or setting the announcements up as= nontraditional
> >=C2=A0 =C2=A0responses[1] (eg. notifications about an unspoken req= uest to GET
> >=C2=A0 =C2=A0/.well-known/core?rt=3Dcore.rd. I can't tell whet= her that'd even be a
> >=C2=A0 =C2=A0good idea, that's yet to be seen).
>
>=C2=A0 =C2=A0[...] Nontraditional Responses (NR) need the devices to be= aware of the RD
>=C2=A0 =C2=A0location.

Not necessarily; the NR could contain all the necessary request details
as in [1].

[1]: https://tools.ietf.org/htm= l/draft-bormann-core-responses-00#section-2

Agree

> > * [...] whether there is anything in particular about RD announce= ments
> > in it as compared to general link announcments.
>
> Thank you for this suggestion, we will consider it in future versions.= Can you
>=C2=A0 please indicate some key services that need to be announced.

That very much depends on the particular use case, but if there is
anything that most devices joining the network would query right after
having discovered the RD, that would be it.

For example, in a setup that uses tiloca-core-oscore-discovery[2], it
might make sense to not only send the RD's data but also the links to the most frequently joined join resources. (Not that the frequency of
group members joining would be likely to warrant this, but if it were
frequent enough that proactive-rd made sense, sending those links to
join resources proactively would just make as much sense.)

[2]: https://tools.ietf.org/html/dr= aft-tiloca-core-oscore-discovery-02

=C2=A0Thank you for mentioning this draft, we are wor= king to consider such services and similar (e.g., Announce
=C2=A0=C2=A0= =C2=A0 Available Groups for nodes to join)=C2=A0 for he next version of the= draft

, Jaime Jimenez , "core-chairs@ietf.org" , "core@ietf.org" , Thomas Fossati Thread-Topic: Adam Roach's No Objection on draft-ietf-core-multipart-ct-03: (with COMMENT) Thread-Index: AQHU/x5UK9iu9ntrn0+xDYvvzKRD6KZUy8oA Date: Tue, 30 Apr 2019 13:57:23 +0000 Message-ID: <0E505663-91A8-4811-9D06-A1DA2774FD23@arm.com> References: <155660587850.12863.3531895290991565789.idtracker@ietfa.amsl.com> In-Reply-To: <155660587850.12863.3531895290991565789.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [5.148.85.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88afca38-e572-491d-9268-08d6cd73c526 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4358; x-ms-traffictypediagnostic: AM6PR08MB4358: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(396003)(376002)(136003)(51914003)(199004)(189003)(40434004)(8936002)(68736007)(86362001)(99286004)(97736004)(71446004)(71200400001)(82746002)(8676002)(110136005)(83716004)(6512007)(7736002)(76116006)(91956017)(76176011)(71190400001)(66556008)(64756008)(66446008)(2906002)(54906003)(36756003)(316002)(66946007)(305945005)(73956011)(81156014)(81166006)(476003)(2616005)(486006)(6436002)(53936002)(186003)(256004)(6116002)(33656002)(66476007)(446003)(5024004)(5660300002)(14444005)(11346002)(3846002)(6486002)(478600001)(229853002)(14454004)(25786009)(6506007)(72206003)(4326008)(66066001)(102836004)(26005)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4358; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: s5OO4yvEWBOXEKkIfgQySu6l3yvPtcGsRTeExGU5SrUHgiHW99qRvDyZmCxcSjkcOY6szFjHJT6qevLgxIocDmdt2f+9Z3grNZz1qlowlhg+5lNk+inhB+XuSJIy7H0RrLo9iuS/OguoDyM3t92Iil4DZbd7jQzeKrRAschecEpdMZMLyZp7lBsR6XsY14hx69Mtwsj7t7IwKUIGSFCiHHpY2jwA+EnQ3I1JQifg/dvmorqWlGPzZdBoVMGazUUstZUrHEVnNsPNY7NBaNHaLwoeRHCVJ8341iASgWRkFbfryqCXNEeefRFi5gSTGS3T8JQXD1vZ+/K/p7Jsfj/78zNP386x8YVHGLbSwsWZ6bdWeDpRfb4Abhm/Y2r58qXkKRiPp8c/W8xnADxzrrRKrLxSkNuuOm+74MWO1OANqss= Content-Type: text/plain; charset="utf-8" Content-ID: <683F50646A77644480D8BF4856C8DBDF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88afca38-e572-491d-9268-08d6cd73c526 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 13:57:23.1235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4358 Archived-At: Subject: Re: [core] Adam Roach's No Objection on draft-ietf-core-multipart-ct-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 13:57:29 -0000 SGkgQWRhbSwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQoNCu+7v09uIDMwLzA0LzIwMTksIDA3 OjMxLCAiQWRhbSBSb2FjaCB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3JnPiB3cm90 ZToNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CiAgICBUaGFua3MgZm9yIHRoZSB3b3JrIGV2ZXJ5b25lIHB1dCBpbiBvbiB0aGlzIGRvY3VtZW50 Lg0KDQogICAgVGhlICJVc2FnZSBFeGFtcGxlcyIgc2VjdGlvbiBzZWVtcyBhIGJpdCBvZGQsIHNp bmNlIGl0IG9ubHkgZGVzY3JpYmVzIHRoZSB1c2Ugb2YNCiAgICB0aGlzIG5ldyBjb250ZW50IHR5 cGUgZm9yIHNlbmRpbmcgYSByZXNwb25zZSBwcmlvciB0byB0aGUgcmVzcG9uc2UgYm9keSBiZWNv bWluZw0KICAgIGF2YWlsYWJsZS4gVGhlIGludHJvZHVjdGlvbiBkb2VzIG5vdCBnaXZlIHRoZSBp bXByZXNzaW9uIHRoYXQgdGhpcyBpcyB0aGUNCiAgICBwcmltYXJ5IHVzZSBjYXNlIC0tIGl0IGlt cGxpZXMgdGhhdCB0aGlzIG5ldyBmb3JtYXQgaXMgcHJpbWFyaWx5IGludGVuZGVkIHRvDQogICAg YmUgdXNlZCBpbiBhIHNpbWlsYXIgZmFzaGlvbiBhcyB0aGUgdHJhZGl0aW9uYWwgbXVsdGlwYXJ0 LyogbWVkaWEgdHlwZXMuDQogICAgUGVyaGFwcyB0aGVyZSBzaG91bGQgYmUgc29tZSBhZGRpdGlv bmFsIGV4YW1wbGVzIGluIHNlY3Rpb24gMyB0aGF0IG91dGxpbmUgdGhlc2UNCiAgICBtb3JlIGNv bW1vbiBjYXNlcz8NCg0KWWVzLCBpdCBpcyBjb3JyZWN0IHRvIHNheSB0aGF0IHRoaXMgaXMgbm90 IHRoZSBwcmltYXJ5IHVzZSBjYXNlLCBhbmQgeWVzLCBzZWN0aW9uIDMuMSBsb29rcyBhIGJpdCBs b25lc29tZS4uLg0KDQpJIHRoaW5rIHdlIGVuZGVkIHVwIGxpa2UgdGhhdCBhcyB3ZSBmZWx0IGxp a2UgdGhpcyB3YXMgdGhlIG9ubHkgdXNlIGNhc2UgdGhhdCBuZWVkZWQgc29tZSBraW5kIG9mICJ2 aXN1YWwiIC0tIGFsbCB0aGUgb3RoZXJzIGJlaW5nIHByZXR0eSBzdHJhaWdodGZvcndhcmQgdG8g Z3Jhc3Agd2l0aG91dCBhbnkgcGFydGljdWxhciBhaWQuDQoNCkhvdyBhYm91dCB3ZSBhZGQgYSBi aXQgb2YgdGV4dCBhdCB0aGUgdG9wIG9mIHNlYyAzIHRoYXQgYXJ0aWN1bGF0ZXMgdGhlIGFib3Zl IHJhdGlvbmFsZT8NCg0KQ2hlZXJzIQ0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCg== From nobody Tue Apr 30 10:12:49 2019 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 B7DF11202CE; Tue, 30 Apr 2019 10:12:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155664436774.7505.12604389698979572964.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 10:12:47 -0700 Archived-At: Subject: [core] Alissa Cooper's No Objection on draft-ietf-core-multipart-ct-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:12:48 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-core-multipart-ct-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. = Section 2 = "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." I think it would be more precise to refer to the "even-numbered elements" and the "odd-numbered elements" rather than enumerating the elements and saying "etc." From nobody Tue Apr 30 10:13:51 2019 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 5751012029C; Tue, 30 Apr 2019 10:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cooperw.in header.b=RlDOeVaZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NkaN+3nL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7N2rko4Itm9; Tue, 30 Apr 2019 10:13:47 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615221202F9; Tue, 30 Apr 2019 10:13:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 58FEA23489; Tue, 30 Apr 2019 13:13:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 30 Apr 2019 13:13:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=S L09bhhgt9mSqHG6ci7Ol9syNLsqjHYgcmE0eyeYr7c=; b=RlDOeVaZ1TuL/D4iG uGYwtZ8IYA0a8WjKVeUw84rRkIIjnMpCze/cJIPzL8+TY3RLx0cdxbWSHnQvPd1Q pk861fVfG0ND7Inc2tjXvfpXAsLjjYIpleKyEDPjIaI4C2yJz4+kYDl77vJzcchK y+6S4Uor814rtnivd43A21P6tKo9f7w8kG9lJlDepZNXy+rFQVeeLNkOYYLBjRJr qpIAUZDJetrp7XsKWlQkFiuhyHq5L124tQGhx73svxivpMnMHZlmlyT86xmyHBIY Ld59QgRv6vKG72rLSrHSZa+Lb1uFh7kHuROm6DO7xLgjxr18AweT9fEryoLYEfqJ ApBcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=SL09bhhgt9mSqHG6ci7Ol9syNLsqjHYgcmE0eyeYr 7c=; b=NkaN+3nLrBuKdhQBkhk0f4US7G5JMeE1AGe9bpyk4+IB+4YJOfkyzHub7 Tf9OhIRB3O+5KMA012ZYuVzpTRuSsAhcXi2bakQ8r/cXzjGEHJ1O3KtumTSWqIvu Fy2B8ErEDKZQ11kMYx/w0dhArnhz6rpUbeoRhho05DzcTodC6ROeKTC/G/PDIa53 BJVj57XiaSYs3aS8Z7yQC4hvbu765ztR1OyDspaYkGrrLI/alDsxZeXxzhwa2Ye3 3RvnsAp93VihcpbnipKct+Pv/Nu8uauWGXjSufZmA0Etuzw7h1Fb03Es+L/Y0H3g ou1eWaTbvHA0Hf4dQWz3QYSdMX57Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieehgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejheenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 36FDDE454A; Tue, 30 Apr 2019 13:13:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155454280808.21871.333722671657907840@ietfa.amsl.com> Date: Tue, 30 Apr 2019 13:13:35 -0400 Cc: gen-art@ietf.org, draft-ietf-core-multipart-ct.all@ietf.org, ietf@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D782283-D1F6-42EA-87CD-3A6EF31926ED@cooperw.in> References: <155454280808.21871.333722671657907840@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-multipart-ct-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:13:50 -0000 Thanks Stewart. I entered a No Objection ballot and referred to your = review. Alissa > On Apr 6, 2019, at 5:26 AM, Stewart Bryant via Datatracker = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-multipart-ct-03 > Reviewer: Stewart Bryant > Review Date: 2019-04-06 > IETF LC End Date: 2019-04-08 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > Apart from one figure that was difficult to understand and some = trivial nits > this is well written and is ready for publication. >=20 > Major issues: None >=20 > Minor issues: >=20 > __________ __________ __________ > | | | | | | > ---->| 2.05 |---->| 2.05 / |---->| 4.xx / | > | Pending | | 2.03 | | 5.xx | > |__________| |__________| |__________| > ^ \ \ ^ \ ^ > \__/ \ \___/ / > \_______________________/ >=20 > Figure 2: Sequence of Notifications: > SB> Not my specialty, but I don't see what message gets sent > SB> to who in the above and RFC7641 has no similar diagram. >=20 > Nits/editorial comments: > accompanying it. In such a case, the sequence in which these occur > may not be relevant to the application. This specification allows = to > SB> typo - word missing > indicate that an optional part is not present by substituting a null > value for the representation of the part. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The collection is encoded as a CBOR [RFC7049] array with an even > SB> CBOR needs expanding on first use (it is not on the well known = list) > number of elements. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Person & email address to contact for further information: > iesg&ietf.org > SB> Shouldn't that be iesg@ietf.org? >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art