From nobody Sat Apr 1 08:51:01 2017 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 EB81E1295EA for ; Sat, 1 Apr 2017 08:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 vleiQV9GiRU5 for ; Sat, 1 Apr 2017 08:50:56 -0700 (PDT) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (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 8FE7E12954B for ; Sat, 1 Apr 2017 08:50:56 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 93BDA53DE; Sat, 1 Apr 2017 11:50:50 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F23805357; Sat, 1 Apr 2017 11:50:49 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn4-1944.cisco.com ([UNAVAILABLE]. [173.38.117.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sat, 01 Apr 2017 11:50:50 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_5A9B19BF-2F08-41BF-A108-6416B9D6EB66" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20170324113150.hrxznr44n5zdivud@hephaistos.amsuess.com> Date: Fri, 31 Mar 2017 19:16:46 -0500 Cc: core Message-Id: <5FFD07F7-0D8A-49A8-AD5F-47DFCD0182FE@iii.ca> References: <20170324113150.hrxznr44n5zdivud@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 15:51:00 -0000 --Apple-Mail=_5A9B19BF-2F08-41BF-A108-6416B9D6EB66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Might be good to have a short phone call about this. I don't think I = understand what problem we are trying to solve. Most the sensors I am dealing with do not have long term stable DNS = names. In fact often IP addressed only and in a non unique address = space.=20 So the HTTP URL one might be doing a HTTP GET on might look like=20 http://192.168.0.2/s/temperature And might return=20 [ {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} ] Note that one of the key principals of SenML is that the name "must = result in a globally unique identifier for the resource." This is a key = property and critical to applications that process SenML for analytics , = ML etc.=20 The above is what I mostly what I was thinking about but I can easily = imagine that there might be some cases where the device has a long term = stable DNS address. So perhaps we have a light bulb that has the long = term stable DNS name light22.building3.example.com = and has a light and temperature = resources=20 I can imagine that an HTTP GET on=20 http://light22.building3.example.com/s = / returning=20 [ { "bn":"light22.building3.example.com-s = -" } {"n": "light", "v": 123, "u": "lx"}, {"n:" "temp", "v": 27.2, "u": "degC"} ] I do not think we should support turning a SenML document where you can = only figure out the unique name of the sensor is by looking at = information outside the SenML document.=20 So with that context ... I thought we had fleshed out a way for the URI = approach to work and it was the "bn" indicated effectively the HTTP ref.=20= I do not think that=20 [{"n": "/s/light", "v": 123, "u": "lx"}]=20 is a valid SenML in because the name is not globally unique. If we = added an bh (or h) attribute that looked like=20 [{ "h": "http://light22.building3.example.com/s/ = " "n": "light", "v": 123, "u": "lx"}]=20 Where the h is the same as the URL in the GET, I can see how we could = get that transform to something that might work but is seem more or or = less the same as using "n" or "bn".=20 So with all that said .... I don't think I am clearly understanding what = the problems is we are trying to solve.=20 Thanks, Cullen > On Mar 24, 2017, at 6:31 AM, Christian Ams=C3=BCss = > = wrote: >=20 > Hello SenML authors, and hello CoRE Interfaces authors, >=20 > I'd like to follow up on the IETF96 (Berlin) discussion on using URIs > with SenML after reviewing the mails on the topic and the discussion > footage. The point of the URI concatenation discussion back then was = to > allow CoRE Interfaces to do what they are currently doing, being >=20 > GET /l/ > [{"n": "/s/light", "v": 123, "u": "lx"}, > {"n:" "/s/temp", "v": 27.2, "u": "degC"}] >=20 > which is supposed to mean the /s/light and /s/temp resources on the > origin server, and not /l//s/light etc. as it will by the SenML spec. >=20 >=20 > In the Berlin discussion, there was a rough agreement on taking a = route > where URI users could use a different attribute to denote their > anchor/href; this would avoid the pitfalls of doing URI concatenation > wrong for people who don't use URIs there anyway. >=20 > This has not been fleshed out or at least explored since then AFAICT, > and I'd like to at least see that there is a route of extensions CoRE > interfaces can use if we publish SenML as it is now. >=20 > Two questions need answering IMO: >=20 > * Do we want to be able to share documents between "URI users" and > "non-URI users"? In many cases this will be possible; for example, > batches (as opposed to linked batches as above) would just work with > the current name building, and thus be usable by non-URI-aware = clients > as well. >=20 > * If we want to keep them apart, how would we deal with the = requirement > of having mandatory uniquely identifying names? A linked batch would > certainly not want to repeat names once in "n" and once in "h" > notation. >=20 >=20 > For a strawman proposal, I'd assume the answers are "we want to allow > mixed usership", and "the unique name requirement stays". Then we = could > construct an extension like this: >=20 > Resolved records have, in addition to their name, a URI name ("href"), > which is optional to use but can be mandated to use in certain > applications (eg. CoRE interfaces). The URI name is formed by doing > RFC3986 relative URI resolution of the "h" property relative to the = "bh" > base attribute relative to the requested URI. If the "h" property is > absent on a record, its "n" property provides a default value. If the > "bh" property is absent on the first record, the "bn" property = provides > a default value. >=20 > This scheme has the properties that >=20 > + Batches (or generally, collections that worked so far) work equally > well for non-URI and URI users. > + Representations stay as compact as they are. > + The CoRE interfaces can refer to the records' URI names and thus be > sure that users must take the necessary steps to resolve relativities > correctly, while simpler SenML users arrive at resolved names by > concatenating. > ~ Evaluating the name of, say, linked batch resources still gives a > unique name. It might or might not be a valid URI, and might or might > not be dereferncable, but since it's agreed on that a name is not > necessarily a URI, that's OK. For example, the linked batch of the > first example would give resolved "n":"coap://host/l//s/light = " (or > even, for other examples, "n":"coap://host/l/http://remote/resource = "), > but that would still be a unique name. > - It doesn't survive representation as Resolved Records. (But are they > intended to be serialized again at all? How do other extensions cope > with Resolved Records?) > - It defines properties that would, in actual use, barely (if at all) > show up. In particular, the CoRE Interfaces examples could stay as > they are and never use "h"/"bh". If we just dropped the arguments and > only defined a URI property, we're even worse again in the next = point: > - This has a smell of applications defining how to interpret the name, > which is what Cullen has already argued against in the July thread. >=20 > If we can live with the above downsides or those of another form of = URI > extension (which might have fewer or others), then I think we can > procede with SenML as it is, otherwise we should either come up with a > better URI story, or need SenML to accomodate such uses. >=20 > What do you think? >=20 > Best regards > Christian >=20 > --=20 > Christian Ams=C3=BCss | Energy Harvesting = Solutions GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at = | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > | ATU68476614 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_5A9B19BF-2F08-41BF-A108-6416B9D6EB66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Might be good to have a = short phone call about this. I don't think I understand what problem we = are trying to solve.

Most the sensors I am dealing with do not have long term = stable DNS names. In fact often IP addressed only and in a non unique = address space. 

So the HTTP URL one might be doing a HTTP GET on might look = like 

http://192.168.0.2/s/temperature

And might return 

[
    =  {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
]

Note that one of the key principals of SenML is that the name = "must result in a globally unique identifier for the resource." This is = a key property and critical to applications that process SenML for = analytics , ML etc. 

The above is what I mostly what I was thinking about but I = can easily imagine that there might be some cases where the device has a = long term stable DNS address. So perhaps we have a light bulb that has = the long term stable DNS name light22.building3.example.com and has a light and = temperature resources 

I can imagine that an HTTP GET on 

http://light22.building3.example.com/s/

returning 

[
{ "bn":"light22.building3.example.com-s-" }
{"n": "light", "v": 123, "u": "lx"},
{"n:"= "temp", "v": 27.2, "u": "degC"}
]

I do not think we should = support turning a SenML document where you can only figure out the = unique name of the sensor is by looking at information outside the SenML = document. 

So with that context ... I thought we had fleshed out a way = for the URI approach to work and it was the "bn" indicated effectively = the HTTP ref. 

I do not think that 

[{"n": "/s/light", "v": 123, "u": = "lx"}] 

is = a valid SenML in because the name is not globally unique.  If we = added an bh (or h) attribute that looked like 

 [{     = "h": "http://light22.building3.example.com/s/"
= "n": "light", "v": 123, "u": "lx"}] 

Where the h is the same as the URL in = the GET, I can see how we could get that transform to something that = might work but is seem more or or less the same as using "n" or = "bn". 

So = with all that said .... I don't think I am clearly understanding what = the problems is we are trying to solve. 

Thanks, Cullen





On Mar 24, 2017, at 6:31 AM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:

Hello = SenML authors, and hello CoRE Interfaces authors,

I'd like to follow up on the IETF96 (Berlin) discussion on = using URIs
with SenML after reviewing the mails on the = topic and the discussion
footage. The point of the URI = concatenation discussion back then was to
allow CoRE = Interfaces to do what they are currently doing, being

GET /l/
[{"n": "/s/light", "v": 123, "u": = "lx"},
{"n:" "/s/temp", "v": 27.2, "u": "degC"}]

which is supposed to mean the /s/light and = /s/temp resources on the
origin server, and not = /l//s/light etc. as it will by the SenML spec.


In the Berlin discussion, there was a rough = agreement on taking a route
where URI users could use a = different attribute to denote their
anchor/href; this = would avoid the pitfalls of doing URI concatenation
wrong = for people who don't use URIs there anyway.

This has not been fleshed out or at least explored since then = AFAICT,
and I'd like to at least see that there is a route = of extensions CoRE
interfaces can use if we publish SenML = as it is now.

Two questions need answering = IMO:

* Do we want to be able to share = documents between "URI users" and
 "non-URI users"? = In many cases this will be possible; for example,
=  batches (as opposed to linked batches as above) would just work = with
 the current name building, and thus be usable = by non-URI-aware clients
 as well.

* If we want to keep them apart, how would we deal with the = requirement
 of having mandatory uniquely = identifying names? A linked batch would
 certainly = not want to repeat names once in "n" and once in "h"
=  notation.


For a = strawman proposal, I'd assume the answers are "we want to allow
mixed usership", and "the unique name requirement stays". = Then we could
construct an extension like this:

Resolved records have, in addition to their = name, a URI name ("href"),
which is optional to use but = can be mandated to use in certain
applications (eg. CoRE = interfaces). The URI name is formed by doing
RFC3986 = relative URI resolution of the "h" property relative to the "bh"
base attribute relative to the requested URI. If the "h" = property is
absent on a record, its "n" property provides = a default value. If the
"bh" property is absent on the = first record, the "bn" property provides
a default = value.

This scheme has the properties = that

+ Batches (or generally, collections = that worked so far) work equally
 well for non-URI = and URI users.
+ Representations stay as compact as they = are.
+ The CoRE interfaces can refer to the records' URI = names and thus be
 sure that users must take the = necessary steps to resolve relativities
 correctly, = while simpler SenML users arrive at resolved names by
=  concatenating.
~ Evaluating the name of, say, linked = batch resources still gives a
 unique name. It might = or might not be a valid URI, and might or might
 not = be dereferncable, but since it's agreed on that a name is not
 necessarily a URI, that's OK. For example, the linked = batch of the
 first example would give resolved = "n":"coap://host/l//s/light" (or
 even, = for other examples, "n":"coap://host/l/http://remote/resource"),
=  but that would still be a unique name.
- It doesn't = survive representation as Resolved Records. (But are they
=  intended to be serialized again at all? How do other extensions = cope
 with Resolved Records?)
- It = defines properties that would, in actual use, barely (if at all)
 show up. In particular, the CoRE Interfaces examples = could stay as
 they are and never use "h"/"bh". If = we just dropped the arguments and
 only defined a = URI property, we're even worse again in the next point:
- = This has a smell of applications defining how to interpret the name,
 which is what Cullen has already argued against in the = July thread.

If we can live with the above = downsides or those of another form of URI
extension (which = might have fewer or others), then I think we can
procede = with SenML as it is, otherwise we should either come up with a
better URI story, or need SenML to accomodate such uses.

What do you think?

Best regards
Christian

--
Christian Ams=C3=BCss =             &n= bsp;        | Energy Harvesting = Solutions GmbH
founder, system architect =             | = headquarter:
mailto:c.amsuess@energyharvesting.at  | = Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =             &n= bsp;  | http://www.energyharvesting.at/
=             &n= bsp;           &nbs= p;            = | ATU68476614
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_5A9B19BF-2F08-41BF-A108-6416B9D6EB66-- From nobody Sat Apr 1 08:51:09 2017 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 E9F7612954B for ; Sat, 1 Apr 2017 08:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 a9wREMSlLuQo for ; Sat, 1 Apr 2017 08:50:59 -0700 (PDT) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (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 89E051295DF for ; Sat, 1 Apr 2017 08:50:59 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E3C7953AB; Sat, 1 Apr 2017 11:50:48 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 2D9F65357; Sat, 1 Apr 2017 11:50:47 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn4-1944.cisco.com ([UNAVAILABLE]. [173.38.117.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sat, 01 Apr 2017 11:50:48 -0400 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/html; charset=utf-8 X-Apple-Base-Url: x-msg://14/ X-Apple-Mail-Remote-Attachments: YES From: Cullen Jennings In-Reply-To: <20170324113150.hrxznr44n5zdivud@hephaistos.amsuess.com> X-Apple-Windows-Friendly: 1 Date: Fri, 31 Mar 2017 19:16:02 -0500 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170324113150.hrxznr44n5zdivud@hephaistos.amsuess.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 15:51:02 -0000

Might be good to have = a short phone call about this. I don't think I understand what problem = we are trying to solve.

Most the sensors I am dealing with do not have long term = stable DNS names. In fact often IP addressed only and in a non unique = address space. 

So the HTTP URL one might be doing a HTTP GET on might look = like 

http://192.168.0.2/s/temperature

And might return 

[
    =  {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
]

Note that one of the key principals of SenML is that the name = "must result in a globally unique identifier for the resource." This is = a key property and critical to applications that process SenML for = analytics , ML etc. 

The above is what I mostly what I was thinking about but I = can easily imagine that there might be some cases where the device has a = long term stable DNS address. So perhaps we have a light bulb that has = the long term stable DNS name light22.building3.example.com and has a light and = temperature resources 

I can imagine that an HTTP GET on 

http://light22.building3.example.com/s/

returning 

[
{ "bn":"light22.building3.example.com-s-" }
{"n": "light", "v": 123, "u": "lx"},
{"n:"= "temp", "v": 27.2, "u": "degC"}
]

I do not think we should = support turning a SenML document where you can only figure out the = unique name of the sensor is by looking at information outside the SenML = document. 

So with that context ... I thought we had fleshed out a way = for the URI approach to work and it was the "bn" indicated effectively = the HTTP ref. 

I do not think that 

[{"n": "/s/light", "v": 123, "u": = "lx"}] 

is = a valid SenML in because the name is not globally unique.  If we = added an bh (or h) attribute that looked like 

 [{     = "h": "http://light22.building3.example.com/s/"
= "n": "light", "v": 123, "u": "lx"}] 

Where the h is the same as the URL in = the GET, I can see how we could get that transform to something that = might work but is seem more or or less the same as using "n" or = "bn". 

So = with all that said .... I don't think I am clearly understanding what = the problems is we are trying to solve. 

Thanks, Cullen





On Mar 24, 2017, at 6:31 AM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:

Hello = SenML authors, and hello CoRE Interfaces authors,

I'd like to follow up on the IETF96 (Berlin) discussion on = using URIs
with SenML after reviewing the mails on the = topic and the discussion
footage. The point of the URI = concatenation discussion back then was to
allow CoRE = Interfaces to do what they are currently doing, being

GET /l/
[{"n": "/s/light", "v": 123, "u": = "lx"},
{"n:" "/s/temp", "v": 27.2, "u": "degC"}]

which is supposed to mean the /s/light and = /s/temp resources on the
origin server, and not = /l//s/light etc. as it will by the SenML spec.


In the Berlin discussion, there was a rough = agreement on taking a route
where URI users could use a = different attribute to denote their
anchor/href; this = would avoid the pitfalls of doing URI concatenation
wrong = for people who don't use URIs there anyway.

This has not been fleshed out or at least explored since then = AFAICT,
and I'd like to at least see that there is a route = of extensions CoRE
interfaces can use if we publish SenML = as it is now.

Two questions need answering = IMO:

* Do we want to be able to share = documents between "URI users" and
 "non-URI users"? = In many cases this will be possible; for example,
=  batches (as opposed to linked batches as above) would just work = with
 the current name building, and thus be usable = by non-URI-aware clients
 as well.

* If we want to keep them apart, how would we deal with the = requirement
 of having mandatory uniquely = identifying names? A linked batch would
 certainly = not want to repeat names once in "n" and once in "h"
=  notation.


For a = strawman proposal, I'd assume the answers are "we want to allow
mixed usership", and "the unique name requirement stays". = Then we could
construct an extension like this:

Resolved records have, in addition to their = name, a URI name ("href"),
which is optional to use but = can be mandated to use in certain
applications (eg. CoRE = interfaces). The URI name is formed by doing
RFC3986 = relative URI resolution of the "h" property relative to the "bh"
base attribute relative to the requested URI. If the "h" = property is
absent on a record, its "n" property provides = a default value. If the
"bh" property is absent on the = first record, the "bn" property provides
a default = value.

This scheme has the properties = that

+ Batches (or generally, collections = that worked so far) work equally
 well for non-URI = and URI users.
+ Representations stay as compact as they = are.
+ The CoRE interfaces can refer to the records' URI = names and thus be
 sure that users must take the = necessary steps to resolve relativities
 correctly, = while simpler SenML users arrive at resolved names by
=  concatenating.
~ Evaluating the name of, say, linked = batch resources still gives a
 unique name. It might = or might not be a valid URI, and might or might
 not = be dereferncable, but since it's agreed on that a name is not
 necessarily a URI, that's OK. For example, the linked = batch of the
 first example would give resolved = "n":"coap://host/l//s/light" (or
 even, = for other examples, "n":"coap://host/l/http://remote/resource"),
=  but that would still be a unique name.
- It doesn't = survive representation as Resolved Records. (But are they
=  intended to be serialized again at all? How do other extensions = cope
 with Resolved Records?)
- It = defines properties that would, in actual use, barely (if at all)
 show up. In particular, the CoRE Interfaces examples = could stay as
 they are and never use "h"/"bh". If = we just dropped the arguments and
 only defined a = URI property, we're even worse again in the next point:
- = This has a smell of applications defining how to interpret the name,
 which is what Cullen has already argued against in the = July thread.

If we can live with the above = downsides or those of another form of URI
extension (which = might have fewer or others), then I think we can
procede = with SenML as it is, otherwise we should either come up with a
better URI story, or need SenML to accomodate such uses.

What do you think?

Best regards
Christian

--
Christian Ams=C3=BCss =             &n= bsp;        | Energy Harvesting = Solutions GmbH
founder, system architect =             | = headquarter:
mailto:c.amsuess@energyharvesting.at  | = Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =             &n= bsp;  | http://www.energyharvesting.at/
=             &n= bsp;           &nbs= p;            = | ATU68476614
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= From nobody Sun Apr 2 04:52:06 2017 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 2B40D1286CA for ; Sun, 2 Apr 2017 04:52:04 -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 kMlY4TChSxC7 for ; Sun, 2 Apr 2017 04:52:02 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37165127876 for ; Sun, 2 Apr 2017 04:52: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 F3E91469E8; Sun, 2 Apr 2017 13:51:59 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 293E878; Sun, 2 Apr 2017 13:51:49 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D197A3E1; Sun, 2 Apr 2017 13:51:47 +0200 (CEST) Received: (nullmailer pid 22296 invoked by uid 1000); Sun, 02 Apr 2017 11:51:46 -0000 Date: Sun, 2 Apr 2017 13:51:46 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Cullen Jennings Cc: core Message-ID: <20170402115146.l7pigbgnf7m2tiwm@hephaistos.amsuess.com> References: <20170324113150.hrxznr44n5zdivud@hephaistos.amsuess.com> <5FFD07F7-0D8A-49A8-AD5F-47DFCD0182FE@iii.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u7laqmzfj2qtge7z" Content-Disposition: inline In-Reply-To: <5FFD07F7-0D8A-49A8-AD5F-47DFCD0182FE@iii.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 11:52:04 -0000 --u7laqmzfj2qtge7z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Cullen, hello core-interfaces authors, On Fri, Mar 31, 2017 at 07:16:46PM -0500, Cullen Jennings wrote: > Might be good to have a short phone call about this. I don't think I > understand what problem we are trying to solve. sure; let's do this. I'm sending you contact details off-list in parallel. Nevertheless, ahead-of-time and for the record: The examples you've been giving of proper SenML use make it get across better; and I see the utility of having a format with always unique and fully given names[1]. The problem I'm trying to solve is that the users of SenML (not in terms of implementations but in terms of Internet Drafts referencing SenML; don't know about SDOs) do not follow that line of thought. The two documents[2] that describe applications on it (core-interfaces, t2trg-hsml) do so in a way that is not aligned with SenML as you describe it. What I've been trying to do with my proposal is to find a way to enable both use cases (yours of transporting uniquely named sensors' data, and core-interface's of transporting different resource's values; reading the latest t2trg-hsml, something similar is already attempted there). It may well be (and I think more so since your last mail) that those goals can not be reconciled, and that core-interfaces & co would be well-advised to stop using SenML (if it's not the right tool for the job) and specify something else (maybe something different, maybe something generalized like SenML w/o "n" and unique-name requirements that's clear about not being SenML compatible). The situation as I see it now is that SenML is (rightfully) pushing for a WGLC, but its users are sitting quietly in the WG with different ideas about it, and I have no clue about why. Christian [1] My applications never had a need for strong uniqueness as they must consider both name and time anyways, but that's not the issue here. [2] Of the 7 references to the SenML draft[2], 2 are about extending SenML (with no further issues), 3 merely mention it as a possible content-format; in detail: * draft-groves-core-senml-bto-00 (ext) * draft-groves-core-senml-options-00 (ext) * draft-ietf-lwig-crypto-sensors-02 (mention) * draft-groves-core-obsattr-00 (mention) * draft-keranen-t2trg-rest-iot-04 (mention) * draft-ietf-core-interfaces-09 (problem: linked batch) * draft-koster-t2trg-hsml (problem: all examples uri-like) --=20 To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom --u7laqmzfj2qtge7z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljg5c8ACgkQOY0REtOk veGBsA//dEVj2aqAwdg09HjOwvKaTZLZga3ftOH0l5J4xj6kjVpDTnQL2T7eVz3r ZjBikY/+lBT9Iu0Xf7N0nyeiNiIlt9JY/scIIvfFkE0fNx1fTx2lawLEXsr5aNwM /2FTXvPy2+wEhWbSBLbJLRe49oD+JwJjNvndN00fi9TPjjzBiBdQ0nlr6ITlAhSB G/FaKbsPgz+BHrrQJ0AeeAXSbcl1bVav5TIeaRJiBczTjQu1pzAuatPGYHR2zSuM +Cq26Kj3KPuONo6rfj0o7AGYYq5oyg8rAKmIcfE9Qh98VeLibNDKkXi3Zso0NRsK GaEJ6HPEC4n+ZJUN4XIrEbYHycq6CS5wlljL6m29Kd4zigMeR+OK3/a/NK7BEHLm r1zJw4geojt5EC+tZJLd/GpM8OTpnlzyu2dlPOIyhcH95PJabZDYjacmz73a/VR9 rvQ6Ebk3kdTSWIZ/ux5Sovbw0JqxFigVTXoY7QVo7fHuFtMtnyNreGKnU/qwRInV UnPXCZr11XMUU3LJH9nt55HYC37CpHRTnyAtuorQVX4iIz9z6eOyfo6V95AI9Bl4 +LCoAkJSV0oeG0c877K7t7XDmypE/2AAyG2JkNTTk/H07B/aNwKDsAtkD4RcdsX2 MUTxKyoTWmCQI6FqLFszG/lIZ4vlzN3JAWpFkUfMBRzcpcyGviw= =Io10 -----END PGP SIGNATURE----- --u7laqmzfj2qtge7z-- From nobody Mon Apr 3 01:00:00 2017 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 35105127275 for ; Mon, 3 Apr 2017 00:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR-OA33iWjYC for ; Mon, 3 Apr 2017 00:59:57 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C678126BFD for ; Mon, 3 Apr 2017 00:59:57 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud3.xs4all.net with ESMTP id 3jzv1v00526ABXz01jzvf5; Mon, 03 Apr 2017 09:59:55 +0200 Received: from 2001:983:a264:1:bc6b:ed02:1137:16f5 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 03 Apr 2017 09:59:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 03 Apr 2017 09:59:55 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <077d4a2654a4958e2c403a6d96ed4be4@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [core] response code 2.06 versus 5.03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 07:59:59 -0000 Hi Core, I had the pleasure to present the "pending" draft at the start of the Friday session. The draft proposes a new coap response code 2.06. Carsten remarked that response code 5.03 also exists. Our 2.06 draft allows to specify the location of the result, allowing interleaved requests. Additionally, the 2.06 draft will allow multiple requests. My intention is to not only specify a minimum retry interval but also a maximum interval (not specified for 5.03) Consequently, I think that there are enough reasons to continue the 2.06 proposal. Alternatively, the 5.03 can be extended with the current 2.06 specification. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Mon Apr 3 15:08:39 2017 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 40714129461; Mon, 3 Apr 2017 15:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 oKCfrvsuJist; Mon, 3 Apr 2017 15:08:35 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 16A5912948F; Mon, 3 Apr 2017 15:08:35 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 81so32608129pgh.3; Mon, 03 Apr 2017 15:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HUbyeyIhqiWay8/TsBDmX2LZ9l04M4IftE7r9M9tPvI=; b=EG0l1wdrqrD+d6mbX6vf5Oh7BOus+9eyGLgEbwUmwR4IO+EH5MkLwE36JdOyrvHXob FmcZqbecVbE5ROjo+HcxVYfeaoEeVE+g2om9vgiB/9YFAQ0IM03RsVHrAAp45BRyKrCA D3fT0WvtPdzA4y6fPtz9P7bCRBNJkg6ctbiu3ctr8B3QWzo/seCCt5fezHXC0oQ4THtE v7JKqZn8ZMoZafS6vzXVo50SWj4jizf53Ba0MY5h0hi4ma88Zay9Gr/Mi2vqyF1W1ic8 GT+/to5lnZMU7dTdCTRutr7VPASwxI9y7lxzBk7tVueZxGQEyIh6kenfYobZorDHFYQh cCKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HUbyeyIhqiWay8/TsBDmX2LZ9l04M4IftE7r9M9tPvI=; b=cD6HjjTWHhc48aLfHTRPdmuXTYgl3atn04i6sINLW8z8lqySi3J/4sw5dvj+qDTSYy l9CzavlPrTEU4Uj32yu6dgUj/ZE1eW3PYG1VdfwxY6QP3zfEXwUEJNRE7T8nwzkESeIp kwYMg/6UAzPy8ApoBsHDQR+yS4bIijA1Wn3WhdY8ISlFQzeK24zZNDsOMZn5tSDk/w0u CRY6j7ilxdHxzCnI/DKH3cyOfJ3XMZ/z6qM5L4Vp/HtC+g3/Xf3pJCvZm35nOZUflN2H PKgQLmvd7FSNpnP3vQnB+HxbccrXVOPSXutys+PLGi+DffWyp+fV6Pa16VVo5Kp1VF+c wB7A== X-Gm-Message-State: AFeK/H2QH4g32BcelfQOHVuDI5UqZCl/1PYURuwwUtijcIIwXCEcbo89xFO4093kpDlnPQ== X-Received: by 10.99.164.26 with SMTP id c26mr20474969pgf.89.1491257314655; Mon, 03 Apr 2017 15:08:34 -0700 (PDT) Received: from ?IPv6:2620::1000:1409:c9a8:eb31:281c:7881? ([2620:0:1000:1409:c9a8:eb31:281c:7881]) by smtp.gmail.com with ESMTPSA id q64sm27635550pga.0.2017.04.03.15.08.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 15:08:33 -0700 (PDT) From: Robert Quattlebaum X-Google-Original-From: Robert Quattlebaum Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) In-Reply-To: Date: Mon, 3 Apr 2017 15:08:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> To: Carsten Bormann , "draft-ietf-core-coap-tcp-tls@ietf.org" , core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:08:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Everyone, I had an observation about the implications to observation that the current text of draft-ietf-core-coap-tcp-tls appendix A seems to have. I fully realize that I am way too late in this observation, as WGLC has already come and gone, but I figure it can't hurt to bring it up and see what others think. I've got several smart light switches in my house. They all speak CoAP and can be configured to observe the state of each other. This allows for a "two-way" switch (called "three-way" in the US) to be implemented without changing wiring, which I've found to be rather convenient. A slightly different scenario I have implemented is where I have one switch (Switch-A) that, when turned on or off, will turn on (or off) several other lights (Switch-B) which are all on dimmers. I can then walk over to those lights and control them individually (perhaps turning them off, or by adjusting the dimmer) to suit my needs at the time. When leaving the room I can turn them all off by controlling the light switch at the entrance to the room. To implement this, I have Switch-B observe the value of Switch-A. However, to allow local changes, Switch-B keeps track of the observe counter to determine if the value has been updated or not. Now, you might say that I should use ETags for this. But Etags only tell me if the value is the same as the last time I retrieved (or observed) a resource, it doesn't necessarily tell me if the resource had changed in the mean time. A resource could have changed to a different value and then changed back. Also, ETags are optional. If you are observing a resource, Observe counters are (or at least were) required. My own (ab)use of the Observe counter aside, the current language in section A.1 of draft-ietf-core-coap-tcp-tls also makes the life of a CoAP non-caching proxy/bridge more difficult by requiring additional state to keep track of. Imagine a CoAP UDP-only node (Node-A) which is observing a resource on another device (Node-B, TLS-only) via a CoAP proxy. If the proxy connects to Node-B using TLS or WebSockets, then Node-B may opt to leave the value on the Observe option empty. That means the CoAP proxy must now keep track of what observations are occurring, regenerating an index and populating the observe header before sending the observe packet to Node-A. Even if Node-B did include an Observe count, the current language says the proxy MUST ignore it. Section A.3 also seems to have similar problems in the proxy case. If Node-B is trying to observe a resource on Node-A and it follows the guidance in section A.3, it is going to be checking for the health of the connection to the proxy rather than sending individual GET requests. This means that the proxy is going to have to send its own GET requests to Node-A to ensure liveliness. Again, I fully realize that I missed the boat when it comes to this sort of feedback, but nonetheless I wanted to go ahead and put this out there to see what others thought. - -\- RQ -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY4seZAAoJEE6OLsxF2Ko6s+QH/jhkaA19Mp9Ub02yfyUzkKa3 xaWtEIhAUxHFe0TXv9sbwJUi8V4q4Qb+VZRYWJqZB/u6SdLayTledcKKXYHId6ZB EqcKyFb29k3oFZs1hvtZxBtowekAlpV7efLxLNB+DFkioOl8AYEhibmAeQunJTZP KTpPhZiImsrZVScOSGT12wZ5/ogzjYTHOv9kM6DN4B/hrqt2ylxW/FS/7oxfr/My 7iRYof+dJvoD1Yz1xtJoNphQk1wja4eDyNuwAYkFlhdCPxpokG1BekLYmjGIQxHc h0k8buaj4uXdFE9RiAIDNCUx5zu+1Ur1Q2my37zbHzznPC8NgwCRSw7oMxt/ukY= =G/G9 -----END PGP SIGNATURE----- From martinscheffler@gmail.com Tue Apr 4 04:24:42 2017 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 E3A76129622 for ; Tue, 4 Apr 2017 04:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHKghcrIMjdY for ; Tue, 4 Apr 2017 04:24:41 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B60127843 for ; Tue, 4 Apr 2017 04:24:36 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id h125so90580924lfe.0 for ; Tue, 04 Apr 2017 04:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/V/9j9EZbZbvejTgZIGhFzejXjLvyhmj4/mjlCCc6qs=; b=lBlmZkvYCnVYi+0GidrB0hVlvtPhNH8aTpv902L1YEHB4zLCBRdATSNPj5gGEda8zs 8Eo7m2c64Nz/5+2y/X7KmAKNSJhPyHrb2360yovLSOCqGcTO2JvNe2sOpcbsiFqUFUYM CE15pp9ROEQ9/SeQnJmiBQ3EQZnTX8lfxMwTXHk4lmuzcs7wX3hIdkRwIIvAfn71uDet 2TAqJKFdy93hmLcp4zgRtaWt5WRGtxt+AYY85X4Rc8w9r7tpKuDynvnm4sUKLI12TFgF JLcsuNnRNxVnelJm+recsJ6ezcH4fy+08QKW27Qgm4sRuN03IJVtLyh1l/428yBsthcb 6t7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/V/9j9EZbZbvejTgZIGhFzejXjLvyhmj4/mjlCCc6qs=; b=NQEUppqZqQahFGKxAUNpr2Y2ST4fez1JtU/bnegNFpWeZog2S9jSk92uT7BSvzJBOD jyccl1MUDErpFNtwKhiiwTsCo2eCwSRmAM+IgZCnWY5i0ZMl/qWP0CmnrwcNEV27dg07 76lLXAGdn23dK+SlqAw2oiUb1N3qfeAk0uJWlNUOud1gTwat2KCH1DFPy+u1xBwzEEYY Ec+afrF4rutymjizc0NXuMB/TC/q6j49GcjtKa354F0kpfi5JIutRGKJ4qrBAduFEK5d 8NGpDf5X/zzoqkZAkgCXjZaZtCrSZZ4J24gA5ntApKH7GfvSDtCjuhElNknwNNwdfs8L IWiA== X-Gm-Message-State: AFeK/H2a8uhRN1vHtOAcrzv2G7s5yZ+QJs8KlnG0adw+TbfR9qLGqohJGijMx0f5LG/NC8Ck2t8y/JxC1J+cTg== X-Received: by 10.25.192.5 with SMTP id q5mr7435132lff.38.1491305074327; Tue, 04 Apr 2017 04:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.18 with HTTP; Tue, 4 Apr 2017 04:24:33 -0700 (PDT) From: Martin Scheffler Date: Tue, 4 Apr 2017 13:24:33 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary=f403045e3bb0350688054c5585f8 Archived-At: X-Mailman-Approved-At: Tue, 04 Apr 2017 04:39:31 -0700 Subject: [core] CoAP over TCP and observing values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 11:25:23 -0000 --f403045e3bb0350688054c5585f8 Content-Type: text/plain; charset=UTF-8 Hi CORE, while researching the different capabilities of CoAP I think I stumbled onto an issue: the CoAP over TCP transmission does not have ACK or RESET messages because TCP is already reliable. But the observation mechanism from RFC 7641 uses RESET messages to unsubscribe from observed values. AFAIK there is no other way to unsubscribe from observations, so unsubscribing is not possible when using TCP. Is this true or is there something I don't get? Is this a problem of the TCP RFC or of the observation RFC? Cheers, Martin --f403045e3bb0350688054c5585f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi CORE,

while researching the differen= t capabilities of CoAP I think I stumbled onto an issue:
the CoAP o= ver TCP transmission does not have ACK or RESET messages because TCP is alr= eady reliable.=C2=A0
But the observation mechanism from RFC 7641 = uses RESET messages to unsubscribe from observed values. AFAIK there is no = other way to unsubscribe from observations, so unsubscribing is not possibl= e when using TCP.
Is this true or is there something I don't get? I= s this a problem of the TCP RFC or of the observation RFC?
=
Cheers,
Martin
--f403045e3bb0350688054c5585f8-- From nobody Tue Apr 4 04:46:54 2017 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 D5A44126B72 for ; Tue, 4 Apr 2017 04:46:52 -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 ZonUasop7AR5 for ; Tue, 4 Apr 2017 04:46:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D997712951F for ; Tue, 4 Apr 2017 04:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34Bkg1G012494; Tue, 4 Apr 2017 13:46:42 +0200 (CEST) Received: from client-0199.vpn.uni-bremen.de (client-0199.vpn.uni-bremen.de [134.102.107.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vy6dG2KN7zDHB9; Tue, 4 Apr 2017 13:46:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 4 Apr 2017 13:46:40 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 512999200.480169-a4518fb5d6ea9855f619894ef562e24f Content-Transfer-Encoding: quoted-printable Message-Id: <0FAC8AB8-3BD0-4001-B6D4-897E238CF211@tzi.org> References: To: Martin Scheffler X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] CoAP over TCP and observing values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 11:46:53 -0000 > On 4. Apr 2017, at 13:24, Martin Scheffler = wrote: >=20 > Hi CORE, >=20 > while researching the different capabilities of CoAP I think I = stumbled onto an issue: > the CoAP over TCP transmission does not have ACK or RESET messages = because TCP is already reliable.=20 > But the observation mechanism from RFC 7641 uses RESET messages to = unsubscribe from observed values. AFAIK there is no other way to = unsubscribe from observations, so unsubscribing is not possible when = using TCP.=20 Actually, there is; see deregister in Section 2. Reset messages are used in UDP CoAP as a reply to messages that do not = make sense for the recipient. The case addressed for observe is that a = client crashes and loses all knowledge about an observation request it = placed; when it receives the next notification, it can answer with a = Reset message to indicate that it is lacking the context to process it. With TCP CoAP, a crashing and restarting client would reset the TCP = connection upon receiving any further TCP packet on that connection it = no longer knows about. That causes the TCP connection to go away, and = with it all the observation interests established over that connection. (The assumption is here that there is fate sharing between the TCP = connection state and the application layer observation interest state. = If the latter can be forgotten without forgetting the former, there = would be a need for a further mechanism.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 4 04:54:16 2017 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 8634D1277BB for ; Tue, 4 Apr 2017 04:54: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 ZNjuBgCRw9-z for ; Tue, 4 Apr 2017 04:54:13 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5EA127B73 for ; Tue, 4 Apr 2017 04:54:13 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 21so150454477pgg.1 for ; Tue, 04 Apr 2017 04:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KegngD9YSUIYwKZiBKMFSGJprpapXYZYKtqkcPMt9N0=; b=n3qsBr/AqZEqBzr7lKSr1QdTgmpqSeQUVkDu5O3lkg17f4cus9/t3wquhBGTJgDXQz pdnE3UcjC8VV4jwr83QGpJKySJrII5J79EVcF0R7smWI7Z8cxeeNcOM08p04LP/YtZs+ AXEwm1T/Oy5e9lAU+s6SLDkdwRyC/+eKBXdMoxZv9HxVZlMKDl22X34I/EmwfOkp6tPr 4OOUgyHSBtITSd5+C/8a7F8Z2kiK/Y36cND9xmFPKBNeDX+rcTXG5H0QzUcxeKlKHAnD WIWg+KZWZnwg/hF1/4lFCr/aYFjCxatzv6ZdCpmLF6k1E/hhzNZcJRGpBy9Veu7nEkr2 PIhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KegngD9YSUIYwKZiBKMFSGJprpapXYZYKtqkcPMt9N0=; b=GGikMLsSm9CmfWeULnvITQPpkMYQ9ae9oBU7xGR/77Yo7lLXx0jKAzJn0vq4KjvfBg iBrqxCpaV+cRV1u/jrfMW5egNFXe2bjp5INRjElVbMCT+NSOL8m2f+S3Ax92HNL8PKF1 0y/4l6XXnR+uQcJ7He7+dzPvdTRrY8+YMuYRcZeme4CYdE1369LS0kyhO7HFNNheH9bk hjMzJZ1Xh7RVZNOjshCg6m9m7mpbHjby7tkMT5bdwHbczbv+/h6VZ7h+JXcfpa7jqfz4 ea0hraV0JzpPe4yGSkNy3f/Ga1ZoQ+3zeRmh/HSyUvPlDvErrRxcgD9f3br8L2yNEp4y RVbQ== X-Gm-Message-State: AFeK/H1i/bV/8o6ORBbRIaLYDbZtk0OyOl0t27Wop+GjH6jcLgNT0QREX99Lo/35d53WCw== X-Received: by 10.98.87.216 with SMTP id i85mr23159195pfj.151.1491306852930; Tue, 04 Apr 2017 04:54:12 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id d130sm31603107pga.17.2017.04.04.04.54.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 04:54:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3C856A71-B4B3-4ED2-922A-E7031C44C483" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 4 Apr 2017 04:54:10 -0700 Cc: core@ietf.org Message-Id: <60545A5A-D79F-4DC6-AD76-9FBF36358781@gmail.com> References: To: Martin Scheffler X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] CoAP over TCP and observing values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 11:54:15 -0000 --Apple-Mail=_3C856A71-B4B3-4ED2-922A-E7031C44C483 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, There is an application layer mechanism defined to cancel observe, by = the client sending a value of observe=3D1 in the coap option header. When included in a GET request, the Observe Option extends the GET method so it does not only retrieve a current representation of the target resource, but also requests the server to add or remove an entry in the list of observers of the resource depending on the option value. The list entry consists of the client endpoint and the token specified by the client in the request. Possible values are: 0 (register) adds the entry to the list, if not present; 1 (deregister) removes the entry from the list, if present. This is the preferred method for a client to indicate it no longer = wishes to receive notifications. Best regards, Michael > On Apr 4, 2017, at 4:24 AM, Martin Scheffler = wrote: >=20 > Hi CORE, >=20 > while researching the different capabilities of CoAP I think I = stumbled onto an issue: > the CoAP over TCP transmission does not have ACK or RESET messages = because TCP is already reliable.=20 > But the observation mechanism from RFC 7641 uses RESET messages to = unsubscribe from observed values. AFAIK there is no other way to = unsubscribe from observations, so unsubscribing is not possible when = using TCP.=20 > Is this true or is there something I don't get? Is this a problem of = the TCP RFC or of the observation RFC? >=20 > Cheers, > Martin > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_3C856A71-B4B3-4ED2-922A-E7031C44C483 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Martin,

There is an application layer mechanism defined to cancel = observe, by the client sending a value of observe=3D1 in the coap option = header.

When =
included in a GET request, the Observe Option extends the GET
   method so it does not only retrieve a current representation of the
   target resource, but also requests the server to add or remove an
   entry in the list of observers of the resource depending on the
   option value.  The list entry consists of the client endpoint and the
   token specified by the client in the request.  Possible values are:

      0 (register) adds the entry to the list, if not present;

      1 (deregister) removes the entry from the list, if =
present.

This is the preferred method for a client to indicate it no = longer wishes to receive notifications.

Best regards,

Michael

On = Apr 4, 2017, at 4:24 AM, Martin Scheffler <martinscheffler@gmail.com> wrote:

Hi CORE,

while researching the different capabilities of CoAP I think = I stumbled onto an issue:
the CoAP over = TCP transmission does not have ACK or RESET messages because TCP is = already reliable. 
But the observation = mechanism from RFC 7641 uses RESET messages to unsubscribe from observed = values. AFAIK there is no other way to unsubscribe from observations, so = unsubscribing is not possible when using TCP.
Is this = true or is there something I don't get? Is this a problem of the TCP RFC = or of the observation RFC?

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

= --Apple-Mail=_3C856A71-B4B3-4ED2-922A-E7031C44C483-- From nobody Tue Apr 4 07:05:46 2017 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 1C53C129634; Tue, 4 Apr 2017 07:05:44 -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 WwCwQjTq0lAa; Tue, 4 Apr 2017 07:05:41 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84497129579; Tue, 4 Apr 2017 07:05:41 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id g2so151502126pge.3; Tue, 04 Apr 2017 07:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=hoFFNxswZ2FYZ1lGVN59ILekgY5U6om2yqKpqFqTfB4=; b=TBZbuVkpaslTj9IoF3PrwMQnonYbiZDyHmyp9K0r+dusF5Bk5oyOk3HNSUTHHSjkVL KNsCBwZCTcSsCpYg6kOuCKhHSn2/I2pUk8SHHA91t2aoiL73LS7CInQBh3gOK5J2nnw1 GVXCbvzFUPIf/l20W3IIrAclytl3LZYjZZmo/eJ7ZLth3jgaBxVv1ashog3AYLz5zbX5 schFGK6RcCQh/etdaqIV0OuBlt84NZACTXCwZbj4PBYTj5yhcGoU+9JoymaaL/mGWYXb +dBeVxfXxuIybAW4sFHXSKBXT4s35zUf84q76yrAcfYwPnbOJyxxFAA3FRh7S2//isGy 07gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hoFFNxswZ2FYZ1lGVN59ILekgY5U6om2yqKpqFqTfB4=; b=SW1FY3pdq4GZ89C8Gi9ibh9k3/xmy2GqcEf/0Q0r80ZsJpwUSC2iT+V4kRcyKhLPzd CuGGoAb461SNwz031LdvhlF1T6WLzYQUy5RyqkMKu1ckAVqGSvXKWemoJkosoe1AQX7d EbJ1dpz8HSRMBn4HR9PtVFneXHWGZps3l8vlMFFcCn4JyAyHRv1J0isdFXE4DxvSKNoH ExpkKYDSjngkFYImLHpHfyk5mH3ncfcKJ11mRGvI4fQhu2qbIUsSEn5N1/2mKwMm4jYg UCSSE5lc2K65yg6hufGSdCCctf0waLAtEKJFbAX14Ke+qo6swnL59C7v7wlzhpBfFIZD EimA== X-Gm-Message-State: AFeK/H07JoDCZ8PwtCc+yR0l944jUzmZzBuSNFcK3vL0FJq4xacsIhXNKRv0PXyvnDhT/w== X-Received: by 10.99.100.129 with SMTP id y123mr24365740pgb.101.1491314741105; Tue, 04 Apr 2017 07:05:41 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id s14sm1858032pgs.0.2017.04.04.07.05.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 07:05:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C009C25-7080-4A10-92BA-A9D6E57A4A31" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 4 Apr 2017 07:05:38 -0700 Cc: Carsten Bormann , "draft-ietf-core-coap-tcp-tls@ietf.org" , core Message-Id: <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> To: Robert Quattlebaum X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:05:44 -0000 --Apple-Mail=_6C009C25-7080-4A10-92BA-A9D6E57A4A31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, It seems that we have inadvertently removed some signaling functionality = that is not solely related to the persistence of the TLS connection. The observe option is more than simply a sequence number. It also a = signal used by the server to indicate to the client that it is unwilling = to send or to continue to send notifications. Making it optional and = requiring it to be ignored removes the ability for the server to = gracefully end or limit observe/notify operations. When included in a response, the Observe Option identifies the message as a notification. This implies that a matching entry exists in the list of observers and that the server will notify the client of changes to the resource state.=20 A server that is unable or unwilling to add a new entry to the list of observers of a resource MAY silently ignore the registration request and process the GET request as usual. The resulting response MUST NOT include an Observe Option, the absence of which signals to the client that it will not be notified of changes to the resource and, e.g., needs to poll the resource for its state instead. Best regards, Michael > On Apr 3, 2017, at 3:08 PM, Robert Quattlebaum = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hello Everyone, >=20 > I had an observation about the implications to observation that the > current text of draft-ietf-core-coap-tcp-tls appendix A seems to have. > I fully realize that I am way too late in this observation, as WGLC > has already come and gone, but I figure it can't hurt to bring it up > and see what others think. >=20 > I've got several smart light switches in my house. They all speak CoAP > and can be configured to observe the state of each other. This allows > for a "two-way" switch (called "three-way" in the US) to be > implemented without changing wiring, which I've found to be rather > convenient. >=20 > A slightly different scenario I have implemented is where I have one > switch (Switch-A) that, when turned on or off, will turn on (or off) > several other lights (Switch-B) which are all on dimmers. I can then > walk over to those lights and control them individually (perhaps > turning them off, or by adjusting the dimmer) to suit my needs at the > time. When leaving the room I can turn them all off by controlling the > light switch at the entrance to the room. >=20 > To implement this, I have Switch-B observe the value of Switch-A. > However, to allow local changes, Switch-B keeps track of the observe > counter to determine if the value has been updated or not. >=20 > Now, you might say that I should use ETags for this. But Etags only > tell me if the value is the same as the last time I retrieved (or > observed) a resource, it doesn't necessarily tell me if the resource > had changed in the mean time. A resource could have changed to a > different value and then changed back. Also, ETags are optional. If > you are observing a resource, Observe counters are (or at least were) > required. >=20 > My own (ab)use of the Observe counter aside, the current language in > section A.1 of draft-ietf-core-coap-tcp-tls also makes the life of a > CoAP non-caching proxy/bridge more difficult by requiring additional > state to keep track of. Imagine a CoAP UDP-only node (Node-A) which is > observing a resource on another device (Node-B, TLS-only) via a CoAP > proxy. If the proxy connects to Node-B using TLS or WebSockets, then > Node-B may opt to leave the value on the Observe option empty. That > means the CoAP proxy must now keep track of what observations are > occurring, regenerating an index and populating the observe header > before sending the observe packet to Node-A. Even if Node-B did > include an Observe count, the current language says the proxy MUST > ignore it. >=20 > Section A.3 also seems to have similar problems in the proxy case. If > Node-B is trying to observe a resource on Node-A and it follows the > guidance in section A.3, it is going to be checking for the health of > the connection to the proxy rather than sending individual GET > requests. This means that the proxy is going to have to send its own > GET requests to Node-A to ensure liveliness. >=20 > Again, I fully realize that I missed the boat when it comes to this > sort of feedback, but nonetheless I wanted to go ahead and put this > out there to see what others thought. >=20 > - -\- RQ > -----BEGIN PGP SIGNATURE----- >=20 > iQEcBAEBCAAGBQJY4seZAAoJEE6OLsxF2Ko6s+QH/jhkaA19Mp9Ub02yfyUzkKa3 > xaWtEIhAUxHFe0TXv9sbwJUi8V4q4Qb+VZRYWJqZB/u6SdLayTledcKKXYHId6ZB > EqcKyFb29k3oFZs1hvtZxBtowekAlpV7efLxLNB+DFkioOl8AYEhibmAeQunJTZP > KTpPhZiImsrZVScOSGT12wZ5/ogzjYTHOv9kM6DN4B/hrqt2ylxW/FS/7oxfr/My > 7iRYof+dJvoD1Yz1xtJoNphQk1wja4eDyNuwAYkFlhdCPxpokG1BekLYmjGIQxHc > h0k8buaj4uXdFE9RiAIDNCUx5zu+1Ur1Q2my37zbHzznPC8NgwCRSw7oMxt/ukY=3D > =3DG/G9 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_6C009C25-7080-4A10-92BA-A9D6E57A4A31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

It seems that we have inadvertently = removed some signaling functionality that is not solely related to the = persistence of the TLS connection.

The observe option is more than simply = a sequence number. It also a signal used by the server to indicate to = the client that it is unwilling to send or to continue to send = notifications. Making it optional and requiring it to be ignored removes = the ability for the server to gracefully end or limit observe/notify = operations.


   When included in a response, the Observe =
Option identifies the
   message as a notification.  This implies that a matching entry exists
   in the list of observers and that the server will notify the client
   of changes to the resource state. 


   A server =
that is unable or unwilling to add a new entry to the list
   of observers of a resource MAY silently ignore the registration
   request and process the GET request as usual.  The resulting response
   MUST NOT include an Observe Option, the absence of which signals to
   the client that it will not be notified of changes to the resource
   and, e.g., needs to poll the resource for its state instead.


Best regards,

Michael


On Apr 3, 2017, at 3:08 PM, Robert = Quattlebaum <darconeous@gmail.com> wrote:

-----BEGIN PGP = SIGNED MESSAGE-----
Hash: SHA256

Hello Everyone,

I had an = observation about the implications to observation that the
current text of draft-ietf-core-coap-tcp-tls appendix A seems = to have.
I fully realize that I am way too late in this = observation, as WGLC
has already come and gone, but I = figure it can't hurt to bring it up
and see what others = think.

I've got several smart light = switches in my house. They all speak CoAP
and can be = configured to observe the state of each other. This allows
for a "two-way" switch (called "three-way" in the US) to = be
implemented without changing wiring, which I've found = to be rather
convenient.

A = slightly different scenario I have implemented is where I have one
switch (Switch-A) that, when turned on or off, will turn on = (or off)
several other lights (Switch-B) which are all on = dimmers. I can then
walk over to those lights and control = them individually (perhaps
turning them off, or by = adjusting the dimmer) to suit my needs at the
time. When = leaving the room I can turn them all off by controlling the
light switch at the entrance to the room.

To implement this, I have Switch-B observe the value of = Switch-A.
However, to allow local changes, Switch-B keeps = track of the observe
counter to determine if the value has = been updated or not.

Now, you might say = that I should use ETags for this. But Etags only
tell me = if the value is the same as the last time I retrieved (or
observed) a resource, it doesn't necessarily tell me if the = resource
had changed in the mean time. A resource could = have changed to a
different value and then changed back. = Also, ETags are optional. If
you are observing a resource, = Observe counters are (or at least were)
required.

My own (ab)use of the Observe counter aside, = the current language in
section A.1 of = draft-ietf-core-coap-tcp-tls also makes the life of a
CoAP = non-caching proxy/bridge more difficult by requiring additional
state to keep track of. Imagine a CoAP UDP-only node (Node-A) = which is
observing a resource on another device (Node-B, = TLS-only) via a CoAP
proxy. If the proxy connects to = Node-B using TLS or WebSockets, then
Node-B may opt to = leave the value on the Observe option empty. That
means = the CoAP proxy must now keep track of what observations are
occurring, regenerating an index and populating the observe = header
before sending the observe packet to Node-A. Even = if Node-B did
include an Observe count, the current = language says the proxy MUST
ignore it.

Section A.3 also seems to have similar problems in the proxy = case. If
Node-B is trying to observe a resource on Node-A = and it follows the
guidance in section A.3, it is going to = be checking for the health of
the connection to the proxy = rather than sending individual GET
requests. This means = that the proxy is going to have to send its own
GET = requests to Node-A to ensure liveliness.

Again, I fully realize that I missed the boat when it comes = to this
sort of feedback, but nonetheless I wanted to go = ahead and put this
out there to see what others = thought.

- -\- RQ
-----BEGIN = PGP SIGNATURE-----

iQEcBAEBCAAGBQJY4seZAAoJEE6OLsxF2Ko6s+QH/jhkaA19Mp9Ub02yfyUzkKa= 3
xaWtEIhAUxHFe0TXv9sbwJUi8V4q4Qb+VZRYWJqZB/u6SdLayTledcKKXYHId6Z= B
EqcKyFb29k3oFZs1hvtZxBtowekAlpV7efLxLNB+DFkioOl8AYEhibmAeQunJTZ= P
KTpPhZiImsrZVScOSGT12wZ5/ogzjYTHOv9kM6DN4B/hrqt2ylxW/FS/7oxfr/M= y
7iRYof+dJvoD1Yz1xtJoNphQk1wja4eDyNuwAYkFlhdCPxpokG1BekLYmjGIQxH= c
h0k8buaj4uXdFE9RiAIDNCUx5zu+1Ur1Q2my37zbHzznPC8NgwCRSw7oMxt/ukY= =3D
=3DG/G9
-----END PGP SIGNATURE-----

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

= --Apple-Mail=_6C009C25-7080-4A10-92BA-A9D6E57A4A31-- From nobody Tue Apr 4 07:12:05 2017 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 C78A4127071; Tue, 4 Apr 2017 07:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwvOailrt2Mu; Tue, 4 Apr 2017 07:12:02 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5332129579; Tue, 4 Apr 2017 07:11:54 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id z13so96267624iof.2; Tue, 04 Apr 2017 07:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=loNNCiPj3xC6lTxa5hU4I8rb7AbNivIsmsxoqlNDDRQ=; b=O+WmEtuRVl+67tvrLZLGwOsJFUmwFxU7TULCJGoDYprxhadUDgdnxTZ0k8hMRoG5Fg ZFPpCyOq3uflS1J1VIPcla3KHqYwhFZRRx618A6I6xjXYqKEkmegSOvWdtA+Ql+TTBxP AjQzU6r0vf+PRwlsQ71hClOHIzwL+VoRg3KsV4CTkpOZD+7YoVjK1+vEPHAwrQzlO9Sp d4yX9ko4fBlDdt+jGcUDWb6Q3KqJNuL75O6zj63tv4dZaCevWPV0knejlPhJM46nM+8H Gwp23XiAf8/WPS9YX/Rn4XzjVULc6i1Y/B9tGNxJe4ejZpTKsrwTFx6Sp93Uc0Tv823c WddQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=loNNCiPj3xC6lTxa5hU4I8rb7AbNivIsmsxoqlNDDRQ=; b=pfugz7P7MAWe1BBvqkx0i1IkXqMeAPgdgA2KBITCMGSibJMfu/TSrB7wE9JCm7E4XH hNY7eGM2efperEIXGjyRinB7gF08w3M75yxS/vveIQgA7HaI9BLWlnafn8wVT2kMLOXb 2NlCh4iQPtN65E3zZXMWrsfBOAclIhkosp603JsPF4lw79PrkqblFBuv2SNJlhgZniEj fH81AMkVzXBUrNmZRAYRstiSGlUVBJo3ULeWjavK0/1+GoqiNuLtGHvQR5RlJ4IZ9Z0M yVrJQe9D1vzslK1Qjxw/KTfkTusm5jlNVMZKO40pUgj2+eesaW9uaI6NWI8UG6776hvL Wo6w== X-Gm-Message-State: AFeK/H1mK8LermcYnXomGmnbf+OjqwplX7fMjkbd9Nab89Jn6xgxsdLXzndZ7nH/rS2mzg== X-Received: by 10.107.59.74 with SMTP id i71mr24534683ioa.151.1491315114055; Tue, 04 Apr 2017 07:11:54 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id v187sm8721248ith.18.2017.04.04.07.11.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 07:11:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_58B3D807-0B68-4153-A60E-BDE8D2C7C007" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 4 Apr 2017 07:11:51 -0700 Cc: Carsten Bormann , "draft-ietf-core-coap-tcp-tls@ietf.org" , core Message-Id: <2054FD98-6CEA-416D-8E1F-A78C4BF70D02@gmail.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> To: Robert Quattlebaum X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:12:04 -0000 --Apple-Mail=_58B3D807-0B68-4153-A60E-BDE8D2C7C007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, My reading of how Etags work in both HTTP and CoAP implies that the Etag = changes value every time a resource state update occurs. In a practical = sense, if a resource changes value and then back to some previously held = value, the Etag should change to a new unique value. I don't imagine an = implementation trying to re-use an Etag when the resource value matches = some previous value. But I could be missing something. Is this a reasonable interpretation? Best regards, Michael > On Apr 3, 2017, at 3:08 PM, Robert Quattlebaum = wrote: >=20 > Now, you might say that I should use ETags for this. But Etags only > tell me if the value is the same as the last time I retrieved (or > observed) a resource, it doesn't necessarily tell me if the resource > had changed in the mean time. A resource could have changed to a > different value and then changed back. Also, ETags are optional. If > you are observing a resource, Observe counters are (or at least were) > required. --Apple-Mail=_58B3D807-0B68-4153-A60E-BDE8D2C7C007 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

My = reading of how Etags work in both HTTP and CoAP implies that the Etag = changes value every time a resource state update occurs. In a practical = sense, if a resource changes value and then back to some previously held = value, the Etag should change to a new unique value. I don't imagine an = implementation trying to re-use an Etag when the resource value matches = some previous value. But I could be missing something.

Is this a reasonable = interpretation?

Best regards,

Michael


On Apr 3, 2017, at 3:08 PM, = Robert Quattlebaum <darconeous@gmail.com> wrote:

Now, you might say that I should use ETags for = this. But Etags only
tell me if the value is = the same as the last time I retrieved (or
observed) a resource, it doesn't necessarily = tell me if the resource
had changed in the mean = time. A resource could have changed to a
different value and then changed back. Also, = ETags are optional. If
you are observing a = resource, Observe counters are (or at least were)
required.

= --Apple-Mail=_58B3D807-0B68-4153-A60E-BDE8D2C7C007-- From nobody Tue Apr 4 07:21:27 2017 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 34AD6129512 for ; Tue, 4 Apr 2017 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjYudevShdTm for ; Tue, 4 Apr 2017 07:21:25 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C53A129579 for ; Tue, 4 Apr 2017 07:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34ELJvC015644 for ; Tue, 4 Apr 2017 16:21:19 +0200 (CEST) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vyB3f5Cr4zDHGH for ; Tue, 4 Apr 2017 16:21:18 +0200 (CEST) Received: by mail-io0-f177.google.com with SMTP id z13so96483250iof.2 for ; Tue, 04 Apr 2017 07:21:18 -0700 (PDT) X-Gm-Message-State: AFeK/H0UxihYbBzCt9jJGDbpbMO1qiXLbHEdPACBvPEzL4XKaWVpt2Zb9RT0OF3PHiBPRvPujM5jyPYIYWf/Jg== X-Received: by 10.107.146.198 with SMTP id u189mr24047470iod.173.1491315677530; Tue, 04 Apr 2017 07:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.6 with HTTP; Tue, 4 Apr 2017 07:20:37 -0700 (PDT) In-Reply-To: <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> From: Klaus Hartke Date: Tue, 4 Apr 2017 16:20:37 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Michael Koster Cc: core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:21:26 -0000 Michael Koster wrote: > The observe option is more than simply a sequence number. It also a signal > used by the server to indicate to the client that it is unwilling to send or > to continue to send notifications. Making it optional and requiring it to be > ignored removes the ability for the server to gracefully end or limit > observe/notify operations. draft-ietf-core-coap-tcp-tls doesn't make the Observe option optional. The presence of the option still signals if the client is in the list of observers or not. But since TCP already deals with reordering, the sequence number inside the Observe in notifications is not needed any more. Klaus From nobody Tue Apr 4 07:24:24 2017 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 D511712894A for ; Tue, 4 Apr 2017 07:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIm9n_KzaUqG for ; Tue, 4 Apr 2017 07:24:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF8C129512 for ; Tue, 4 Apr 2017 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34EODdG017652 for ; Tue, 4 Apr 2017 16:24:13 +0200 (CEST) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vyB7135w4zDHGQ for ; Tue, 4 Apr 2017 16:24:13 +0200 (CEST) Received: by mail-io0-f182.google.com with SMTP id l7so96132117ioe.3 for ; Tue, 04 Apr 2017 07:24:13 -0700 (PDT) X-Gm-Message-State: AFeK/H1aMyygFnCGNcSdYLlU78Z2z/5xULowj53DZXXOZRbKqlHlRE8+Rkj1Tdox310yY6wtpDlyp5hqQv2J9A== X-Received: by 10.107.146.198 with SMTP id u189mr24063264iod.173.1491315852252; Tue, 04 Apr 2017 07:24:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.6 with HTTP; Tue, 4 Apr 2017 07:23:31 -0700 (PDT) In-Reply-To: <2054FD98-6CEA-416D-8E1F-A78C4BF70D02@gmail.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <2054FD98-6CEA-416D-8E1F-A78C4BF70D02@gmail.com> From: Klaus Hartke Date: Tue, 4 Apr 2017 16:23:31 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Michael Koster Cc: core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:24:23 -0000 Michael Koster wrote: > My reading of how Etags work in both HTTP and CoAP implies that the Etag > changes value every time a resource state update occurs. In a practical > sense, if a resource changes value and then back to some previously held > value, the Etag should change to a new unique value. I don't imagine an > implementation trying to re-use an Etag when the resource value matches some > previous value. But I could be missing something. The point of caches is to reuse earlier responses as often as possible. So, if a resource changes back to some earlier state, it would be beneficial if the response describing that state could be reused. Using a different Etag for the same response would be counterproductive. Klaus From nobody Tue Apr 4 07:28:21 2017 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 6C4411296C7; Tue, 4 Apr 2017 07:28:19 -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 38E-fO6PGa6s; Tue, 4 Apr 2017 07:28:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F1B12894A; Tue, 4 Apr 2017 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34ESD4D020622; Tue, 4 Apr 2017 16:28:13 +0200 (CEST) Received: from client-0153.vpn.uni-bremen.de (client-0153.vpn.uni-bremen.de [134.102.107.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vyBCd1S1ZzDHGV; Tue, 4 Apr 2017 16:28:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <2054FD98-6CEA-416D-8E1F-A78C4BF70D02@gmail.com> Date: Tue, 4 Apr 2017 16:28:12 +0200 Cc: Robert Quattlebaum , "draft-ietf-core-coap-tcp-tls@ietf.org" , core X-Mao-Original-Outgoing-Id: 513008892.32886-95b2ba8c6970ba5c6f509df40bc8df78 Content-Transfer-Encoding: quoted-printable Message-Id: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <2054FD98-6CEA-416D-8E1F-A78C4BF70D02@gmail.com> To: Michael Koster X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:28:19 -0000 On 4. Apr 2017, at 16:11, Michael Koster = wrote: >=20 > I don't imagine an implementation trying to re-use an Etag when the = resource value matches some previous value.=20 In many implementations the ETag is simply a hash over the = representation. (There is a lot of discussion about ETags on the Web; e.g., see = https://www.mnot.net/blog/2007/08/07/etags .) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 4 07:30:41 2017 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 B1A681295EE for ; Tue, 4 Apr 2017 07:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 tBUAofztcv6a for ; Tue, 4 Apr 2017 07:30:38 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9E512950C for ; Tue, 4 Apr 2017 07:30:38 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id g2so152149412pge.3 for ; Tue, 04 Apr 2017 07:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XrRerSy2TfdojX10P1UsNQOyzIpTJYlqRfmH7Ti9jqs=; b=F6J6KRWSepbAH9JfBuRP6lmeZCn6mkcsO6ezRl6Hq9XLNVShlEc44fFQKJRPXRreq3 32DuxkE3gaWC2FDUdsosme0DeyU9ii9ZOTjKLCAOY8hgs1r9eiBjx24ke/U465Vg0cXV qhzonwWzqZ4F98T/g2iUQdEeYbx4ojBsi2gl0IwhkgvNpdYf8kRozOKShb89hzWH/uU9 8APcqxWQ5rExmqN7UMiLe5zx8pBs4/h5105qyF6SV5lBJxmUs117P0XZbP/kv9Q1Ki3H LePr2HNtzKcU4ag7rYOSh6NvXTKKYS1GEBHRsDIlz8hGuLXxPACVOEScjyjYFDG1ELdX HtJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XrRerSy2TfdojX10P1UsNQOyzIpTJYlqRfmH7Ti9jqs=; b=IgCbfsGwwRzN9fH6Uk+C8wOV45mjPbFSBQeX5/Fvavp/jKSFJvnZY1uhcbirksYq8D 19MXL3WBLtFuLv9eUdGqphn3OFbSudDQRGMhgu78mka70f9TO/JO41bgS3U57sCo6k6f TUvI4Fq831RX61I8NuflBMfZ52vkfcK8mLqiIfBJWMuCZSLvmBvh/6FDtl7lj0DVHWVB iIIqfJhXZMn05pfjr4GNGABVcIHy3MNK5dMcvvxhWaovJmTTYWHJAEM63HkDaXDXZHnM BGYN3bvwFLAQB+LYlmU9/GFJ+Fj8QQjkT449+brrIqkznEK2Z2y8Tgp8dzK6fLx3zdw+ ukKA== X-Gm-Message-State: AFeK/H1svbcdwP7PpQayzk/JdVXRJmbegOLaXUMtK8soXIifNQs+2812R29okw6LNa+CJg== X-Received: by 10.99.67.6 with SMTP id q6mr24082259pga.156.1491316237742; Tue, 04 Apr 2017 07:30:37 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id p68sm19723319pfp.104.2017.04.04.07.30.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 07:30:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 4 Apr 2017 07:30:35 -0700 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> To: Klaus Hartke X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:30:40 -0000 I see it now; the observe option must be included but may be empty. The = value must be ignored. Thanks! Michael > On Apr 4, 2017, at 7:20 AM, Klaus Hartke wrote: >=20 > Michael Koster wrote: >> The observe option is more than simply a sequence number. It also a = signal >> used by the server to indicate to the client that it is unwilling to = send or >> to continue to send notifications. Making it optional and requiring = it to be >> ignored removes the ability for the server to gracefully end or limit >> observe/notify operations. >=20 > draft-ietf-core-coap-tcp-tls doesn't make the Observe option optional. > The presence of the option still signals if the client is in the list > of observers or not. But since TCP already deals with reordering, the > sequence number inside the Observe in notifications is not needed any > more. >=20 > Klaus From nobody Tue Apr 4 07:32:05 2017 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 A8F7E12950C; Tue, 4 Apr 2017 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 vavqJPj7mY9a; Tue, 4 Apr 2017 07:31:55 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F9A1296D2; Tue, 4 Apr 2017 07:31:54 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 21so154334963pgg.1; Tue, 04 Apr 2017 07:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1iFnKcQxoX1zpBpsfcr4SUTcLBEWxa2D4tdWV/bzvw8=; b=pXLkLk6m0cgc/s+g3OuWBUd0RYh5YWp65VmUPH1Dibq0dxsxq4k9O/n3bJh/UZEk1f Z9pkiFJTotoKaBLzuXmkHFniHbF3jL5k7XfdhqITs/v0c4/y909bDzXbPV2C2utGl56V EX8C/HedqbnTZQVD8NIaXUlHnZlQ1OVmHLNwgekZz72NoMvD+pjsClJiezYnJE3Au/Hv ApjIFXAoF2RKDk3n4z5Kqe03n3mp4s0hm/YfNQh5GcLl7y/HAI84OrYym+1HX73StZCn qDcsXgO9WPIU+3F3rt6utKiUlf4/14yNq+PIC/xdnnCvlnYDRfj/1bMerhQ6IUYAIocm kwHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1iFnKcQxoX1zpBpsfcr4SUTcLBEWxa2D4tdWV/bzvw8=; b=l8QyKPjVGxw4KRXfYvOtx/fBHHkndc2IeRk7TFsgcjOVYTigm5fkrJfccdFZtxRfvc BjctoDGWQYpc7OImqREtFOJV9qO0mp+W6GFFUjiVzRZbfaP83ucfhjJddn+Dyj96+Vxm MXJiaNAwtFSLWAchLocapcgR7X1ftuVJL3PhnK9vBof92mbQS88z5Tga58u15uFR4ZjZ OQyAQV5ipflEh8rn6yLwTV4V2EYqIxjXc45D9WG0JQMHTglFVKDN2HD9iLyFL6tJNq7f r063oCCnStf/My1uSYubmKAOBN+BOkTNP55BVE9Q1KYKBCbeuFbzbwCpsIByTgrRbrjO lbHQ== X-Gm-Message-State: AFeK/H29Y7hYC9Vv7B34EOwz4hR2r8J3IhlYdnUdX9PInG99sNZLACwi3WPR+fwFwTHV6g== X-Received: by 10.99.238.69 with SMTP id n5mr24467741pgk.38.1491316314587; Tue, 04 Apr 2017 07:31:54 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id n85sm32259681pfi.101.2017.04.04.07.31.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 07:31:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 4 Apr 2017 07:31:52 -0700 Cc: Robert Quattlebaum , "draft-ietf-core-coap-tcp-tls@ietf.org" , core Content-Transfer-Encoding: quoted-printable Message-Id: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <2054FD98-6CEA-416D-8E1F-A78C4BF70D02@gmail.com> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:31:58 -0000 OK, thanks for the clarifications. That makes sense, especially for = enumerations. Michael > On Apr 4, 2017, at 7:28 AM, Carsten Bormann wrote: >=20 > On 4. Apr 2017, at 16:11, Michael Koster = wrote: >>=20 >> I don't imagine an implementation trying to re-use an Etag when the = resource value matches some previous value.=20 >=20 > In many implementations the ETag is simply a hash over the = representation. >=20 > (There is a lot of discussion about ETags on the Web; e.g., see = https://www.mnot.net/blog/2007/08/07/etags .) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Tue Apr 4 07:35:13 2017 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 D4D13129512 for ; Tue, 4 Apr 2017 07:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v1x4bL5mVZJ for ; Tue, 4 Apr 2017 07:35:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B33D129691 for ; Tue, 4 Apr 2017 07:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34EZ6E7028550; Tue, 4 Apr 2017 16:35:06 +0200 (CEST) Received: from client-0153.vpn.uni-bremen.de (client-0153.vpn.uni-bremen.de [134.102.107.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vyBMZ17trzDHGf; Tue, 4 Apr 2017 16:35:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 4 Apr 2017 16:35:05 +0200 Cc: Klaus Hartke , core X-Mao-Original-Outgoing-Id: 513009305.459768-538ef7c8776a2fe114cca5bdc0b27b92 Content-Transfer-Encoding: quoted-printable Message-Id: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> To: Michael Koster X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:35:12 -0000 On 4. Apr 2017, at 16:30, Michael Koster = wrote: >=20 > I see it now; the observe option must be included but may be empty. = The value must be ignored. Add =E2=80=9Cin a 2.xx response that indicates an ongoing observation = interest=E2=80=9D, and you are almost right (for an option of uint = format, being =E2=80=9Cempty=E2=80=9D just means the number is 0; maybe = we should have said that in A.1). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 4 07:38:32 2017 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 5B973129634 for ; Tue, 4 Apr 2017 07:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 d_4QeOQv1hSk for ; Tue, 4 Apr 2017 07:38:28 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373F5129512 for ; Tue, 4 Apr 2017 07:38:28 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id g2so152354302pge.3 for ; Tue, 04 Apr 2017 07:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NwrQYNwtLdyRUfldRWQmfMSEduITdz3Vv9k1Kl/djlM=; b=OVJXPl1cxL8KnANsX4XqH/5AqobienEnDerCZpFtGLi6MfOg3h+FPhSVwkjjQBMojk WvUVOczOSgo0Dyu8Yy9kaH5oYVzqwLCTft1CoDUvoDtvCzog2JkB5gPWvtKdbqZ3+xK8 yRE6goEAnil+RSYkNtX/T/pbXQaeaeHC+gcEtsHJj49gaKQl9kaiA7YZjiupKojQxEQq 2UhYumQ9uMgqHxay2B6yA/D6C2orGejxDJTF5F7lI1A+xWhDQpwELq9Z8zXbZR47Uma3 bpmp1KGhN2PojONT5yCiKZpjUeLsMxByi4KLCgFIw7pYVgYj5SDUazThWom7yS3r7vF0 svBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NwrQYNwtLdyRUfldRWQmfMSEduITdz3Vv9k1Kl/djlM=; b=pAYxETbOSnXAfVTyQyBHSUWMhBDN8DpGGV92WElqoSRbGQTysjpHfVcPDAgNB71nKC PRcFhNxqs5Uah/NQas5vn+iV+FwpmZSrWZX88+vc259rkir5x8pVNq1He2S2sfBBWyv+ EYDIxfiiqUVdnVfFyee2NYR1hOZvlw4paxBJ9IdEhbTUyraW5jbNnD7Q64avBSQ+7E10 KjZ7XGph5mmoEuqqam/FJTD0d5YM4fbyb8Tyi96Ni1HGgFzb2PmTREz06acpBULiGerL kCbNSFwfZch9A0P7f22haKZTl/s/ds5ZNqz7j5ozifN+NPeifuXk4xMlVH584/Xrx/Y7 L+bg== X-Gm-Message-State: AFeK/H3oq4t+fj7j1igVRCqiDX6hy/oFTDaC0rc5RbmcdlpiYsDku7Il5Qd6afMQW7KInA== X-Received: by 10.98.106.134 with SMTP id f128mr24444114pfc.142.1491316707870; Tue, 04 Apr 2017 07:38:27 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id n4sm32325211pfg.73.2017.04.04.07.38.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 07:38:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 4 Apr 2017 07:38:25 -0700 Cc: Klaus Hartke , core Content-Transfer-Encoding: quoted-printable Message-Id: <0CF80AFF-1701-41DC-9EF6-E74BE05038AE@gmail.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:38:30 -0000 Ah, of course, the value will still be relevant when it indicates = cancellation. I think a little more text or a little more thought would have helped = me. Best regards, Michael > On Apr 4, 2017, at 7:35 AM, Carsten Bormann wrote: >=20 > On 4. Apr 2017, at 16:30, Michael Koster = wrote: >>=20 >> I see it now; the observe option must be included but may be empty. = The value must be ignored. >=20 > Add =E2=80=9Cin a 2.xx response that indicates an ongoing observation = interest=E2=80=9D, and you are almost right (for an option of uint = format, being =E2=80=9Cempty=E2=80=9D just means the number is 0; maybe = we should have said that in A.1). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Tue Apr 4 09:06:52 2017 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 9C76A127775 for ; Tue, 4 Apr 2017 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=augustcellars.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 BaLE95AuKjhf for ; Tue, 4 Apr 2017 09:06:49 -0700 (PDT) Received: from mail4.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 4AF4A1292F5 for ; Tue, 4 Apr 2017 09:06:49 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491322001; h=from:subject:to:date:message-id; bh=rWCd9l2tqx7Ct48O90FJzsXbg42xfqTFkM99DKBU6GM=; b=PvdozrgmddvTKed608S++p4lH6MUVyQnKDcEylrOH8adiWQNBOE7VZpo7BsKC4bPfftw3MBOAzS ipWIIQx1HBDw1/HU04SiWnKQEBweZtwQBl+FDk4KmYhBLx5y8wcFYse1OLn6UW9sSaLf/06RLnK4R O6MH6jAiM4m3BuZKiUVIm8NXbgW6dNiq7YRYEJgaE1lfCSWuElol8gODJkRAvdiJR7ny5DbLS/k25 8UJiwpoRKyYVe2WpV0hojYucp+EIthFSzhePHbo2gGAvDnNfqdvf9RqNvlDbUUGIuFFGb2264rSt/ uNfRoqmYUHI4RNJlDRLhkwDM1LDcWGwUVLlA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Apr 2017 09:06:41 -0700 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Apr 2017 09:06:36 -0700 From: Jim Schaad To: 'Klaus Hartke' , 'Michael Koster' CC: 'core' References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> In-Reply-To: Date: Tue, 4 Apr 2017 09:06:33 -0700 Message-ID: <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxTUTDBoSefxL81keLoFmyvfInogHZFuWWAeLl1r8CIknjdQMueM/WAnp+2lUB4xgVzQINtmCfoHxfO2A= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:06:51 -0000 This would indicate to me that there needs to be some text in the = document about dealing with transitions from TCP->UDP and the other = direction. If the value is "unneeded" and "ignored" then you might end = up with problems if a proxy going between these two different transports = does not do the right thing in terms of putting in "good" values for the = observe option. Are there other places where the fact that TCP has reliable deliver that = are going to cause problems for proxies? For example, should a UDP->TCP = proxy always ack a request since it is going from unreliable to reliable = delivery? Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Klaus Hartke > Sent: Tuesday, April 4, 2017 7:21 AM > To: Michael Koster > Cc: core > Subject: Re: [core] =F0=9F=94=94 WGLC draft-ietf-core-coap-tcp-tls >=20 > Michael Koster wrote: > > The observe option is more than simply a sequence number. It also a > > signal used by the server to indicate to the client that it is > > unwilling to send or to continue to send notifications. Making it > > optional and requiring it to be ignored removes the ability for the > > server to gracefully end or limit observe/notify operations. >=20 > draft-ietf-core-coap-tcp-tls doesn't make the Observe option optional. > The presence of the option still signals if the client is in the list = of observers or > not. But since TCP already deals with reordering, the sequence number = inside > the Observe in notifications is not needed any more. >=20 > Klaus >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 4 09:30:26 2017 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 A4EC8126B6E for ; Tue, 4 Apr 2017 09:30:25 -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 bJ7ZdajssKPl for ; Tue, 4 Apr 2017 09:30:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069921293E9 for ; Tue, 4 Apr 2017 09:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34GUDNW022921; Tue, 4 Apr 2017 18:30:13 +0200 (CEST) Received: from client-0153.vpn.uni-bremen.de (client-0153.vpn.uni-bremen.de [134.102.107.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vyDwP5WpnzDHK1; Tue, 4 Apr 2017 18:30:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> Date: Tue, 4 Apr 2017 18:30:13 +0200 Cc: Klaus Hartke , Michael Koster , core X-Mao-Original-Outgoing-Id: 513016212.918757-6f74d62cfd891a5e3db1e3725a2265d5 Content-Transfer-Encoding: quoted-printable Message-Id: <83CB73A5-C912-4040-880D-7D1CC5310B9E@tzi.org> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:30:26 -0000 > On Apr 4, 2017, at 18:06, Jim Schaad wrote: >=20 > This would indicate to me that there needs to be some text in the = document about dealing with transitions from TCP->UDP and the other = direction. If the value is "unneeded" and "ignored" then you might end = up with problems if a proxy going between these two different transports = does not do the right thing in terms of putting in "good" values for the = observe option. The Observe value in a response is not meant to be end-to-end (it cannot = be, as observations are hop-by-hop). RFC 7641 may be slightly opaque here, but Section 5 does say: Each hop MUST generate its own values for the Observe Option in notifications See also Figure 8 in RFC 7641 for an example of how that looks like. > Are there other places where the fact that TCP has reliable deliver = that are going to cause problems for proxies? For example, should a = UDP->TCP proxy always ack a request since it is going from unreliable to = reliable delivery? Any UDP CoAP in a proxy will send ACKs right away (maybe with a little = piggyback timeout), independent of whether the request then goes out via = TCP or UDP. So this is not a new thing. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 4 09:32:05 2017 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 97C901296E0 for ; Tue, 4 Apr 2017 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 Ba-qJ95QQfMj for ; Tue, 4 Apr 2017 09:31:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B031292D0 for ; Tue, 4 Apr 2017 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v34GVpE9024057 for ; Tue, 4 Apr 2017 18:31:51 +0200 (CEST) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vyDyG6l56zDHK3 for ; Tue, 4 Apr 2017 18:31:50 +0200 (CEST) Received: by mail-it0-f45.google.com with SMTP id y18so67870167itc.0 for ; Tue, 04 Apr 2017 09:31:50 -0700 (PDT) X-Gm-Message-State: AFeK/H29kc+cfm5UHeAWDuGxHFXpGS/G2HlT32zGfskhWZFCpHBRkbistEyHuqsSak5/p05Pksbw8zwiTl6Lxg== X-Received: by 10.36.40.9 with SMTP id h9mr16849729ith.13.1491323509599; Tue, 04 Apr 2017 09:31:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.6 with HTTP; Tue, 4 Apr 2017 09:31:09 -0700 (PDT) In-Reply-To: <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> From: Klaus Hartke Date: Tue, 4 Apr 2017 18:31:09 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: core Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:31:59 -0000 Jim Schaad wrote: > This would indicate to me that there needs to be some text in the documen= t about dealing with transitions from TCP->UDP and the other direction. If= the value is "unneeded" and "ignored" then you might end up with problems = if a proxy going between these two different transports does not do the rig= ht thing in terms of putting in "good" values for the observe option. Section 5 of RFC 7641 [1] contains some text that explains how intermediaries work in the context of resource observation. In short, resource observation is a hop-by-hop feature: In a client--proxy--server chain, the Proxy generates the notifications and sequence numbers for the client; and the server generates the notifications and sequence numbers for the proxy. A TCP<->UDP transition does not change that. > Are there other places where the fact that TCP has reliable deliver that = are going to cause problems for proxies? For example, should a UDP->TCP pr= oxy always ack a request since it is going from unreliable to reliable deli= very? Acknowledgements in CoAP-over-UDP are a hop-by-hop feature as well: In a client--proxy--server chain, the proxy acknowledges the confirmable messages from the client; and the server acknowledges the confirmable messages from the proxy. An acknowledgement in CoAP has no meaning other than "I have received your confirmable message; you can stop retransmitting it now." Over TCP, TCP does the retransmission and acknowledgement, so the messaging layer of CoAP-over-UDP is not needed. I can see some problems if someone tries to implement a CoAP proxy by rewriting UDP datagrams into TCP segments. But that's not how CoAP proxies are intended to work. Klaus [1] https://tools.ietf.org/html/rfc7641#section-5 From nobody Tue Apr 4 10:49:20 2017 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 B2E9E126DD9 for ; Tue, 4 Apr 2017 10:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 Cpnqt_QHR-RO for ; Tue, 4 Apr 2017 10:49:16 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E46D127B5A for ; Tue, 4 Apr 2017 10:49:16 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id 81so159408008pgh.2 for ; Tue, 04 Apr 2017 10:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m0XGcArGa9MMV4qkdgOEp8o7mUqNwEarnvlFB0wsoqM=; b=YHDQqt9TlgSoXBtr/RIYVtUKSqK/i2nEO2JI0n8cZrmNCHo7AiblvzMW0PgxXH8hEV P4ok0SSWljfVr0flLX7ZdEaVedmxYT47uhOMd+4uiyoj61eYct4JVyitxJuY6Y+Ajw9a uAqVmJ9k4kjZ3dZll64ccuYxVIqB4Vty8B43rOJ5FbGvFJDKvNjEb10AjOnJB044f/tC IKlOuWX4xSRvWBXXzHvhccjtlud3+8/9lnSdvhfbcoRAmf7gaoN1hbH2DT1K/8HTujC1 HJExWxd3ZopGrCkPrppxs//w03bq2HM7ea3tcPHiPWSzo4zOvXuL/FemTt5AyqOIZAER 5Mzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m0XGcArGa9MMV4qkdgOEp8o7mUqNwEarnvlFB0wsoqM=; b=FK3mlqN7oq8pHl8h+lpn4C4Rt5leu6alHaBwpLkhkLs8DAzhYOYajKUzuaVYXVuOr3 SUBR3zPGQKfq8JZwJsfof30SAHRuW2vcYQ+lMQnBzqmNDCrx3cw9aDwxQ5pzRohKuVt9 6aFeIOX85Jt80/mvfMz8IckWIblEgHOfqCDV9A8cAU9jioQLMUSwnvaIspgzAXpZbwlH xENUK7XKzfPPQSZGV+l6h/e1wtnBp+ikwK57VRV4EEDysvQRtWxbNZf3ehX8BZCeVvZt XkYo+3eMKEP9lvmSiSo1sZC2PWUu+kIuckSA3nQtQGoI2op9Ray/yipQrJArDEghVu3u VUhA== X-Gm-Message-State: AFeK/H1bEsYFZx+AyJyvedJS4unFg6hzKIRlhmXd2YgT5c6G2FQSW7nxdPGChnLeB9ki2w== X-Received: by 10.84.229.79 with SMTP id d15mr30835673pln.49.1491328155871; Tue, 04 Apr 2017 10:49:15 -0700 (PDT) Received: from dhcp-100-99-227-205.pao.corp.google.com ([100.99.227.205]) by smtp.gmail.com with ESMTPSA id m69sm32974486pfc.33.2017.04.04.10.49.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 10:49:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Robert Quattlebaum In-Reply-To: Date: Tue, 4 Apr 2017 10:49:13 -0700 Cc: Jim Schaad , core Content-Transfer-Encoding: quoted-printable Message-Id: <9D5033DA-96D2-4489-8586-F64B9124C63D@gmail.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> To: Klaus Hartke , Carsten Bormann X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 17:49:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 That ACKs are hop-by-hop makes total intuitive sense to me. That CoAP observations are hop-by-hop makes considerably less intuitive sense to me. That being said, it's hard to argue with the text from RFC7641 that Carsten pointed out: > Each hop MUST generate its own values for the Observe Option in > notifications This seems baffling to me, as it requires each "hop" to be aware of observations when it wouldn't necessarily otherwise be required for the feature to work=C2=B9. Even when the proxy is aggregating = observations (as it ideally should be), reusing the same numbers from the origin seems like it would have been a good idea, were it not for this text. But RFC7641 is cooked, so it is what it is. This text from RFC7641 does appear to make section A.1 from draft-ietf-core-coap-tcp-tls more consistent. An unfortunate consequence of this design is that it implies momentary changes in the value of an observed resource cannot be reliably detected across a "hop", but in the grand scheme of things I suppose it isn't that big of a deal. - -\- RQ =C2=B9 I realize that this is technically incorrect, because for that to work resets would need to be propagated across "hops", too. I think it is rather unfortunate that resets are not propagated across hops, since it would have allowed for relatively dumb proxies. But seeing that apparently well-established consensus is that resets are not intended to propagate across hops I won't press the issue further. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY49ulAAoJEE6OLsxF2Ko6dBUH+QEga+qDxbg0jgXZOx/bE8Uo WJtatgpXZIXKmmyePG2hNf+DZWBWnoo4n4N/NumLM3GD+vHSdDuWjNaWmCFSLnxx keKfuMpuppyV8k3ZIAeCJVsJw6+irysOzUb1t/izRwmvu+AZdmtH4VbnKy1WgOPf kTl55I74FEG/duy0jzL7rpOSJiUKrgazWHM4xTSgRZvQqj4/yOtOvx2AZAhNdXbn ENy4yVYZUsvJgDMfHXWHx9comRUTMaff202MjBompFiWyiyfB73kyjTsStLjYlDb D/6P0lWXh35lA2VIsANptr8Dl4f29bo9SwSrPwhcrMRn4VquRizFd6wnl8nVynY=3D =3DT675 -----END PGP SIGNATURE----- > On Apr 4, 2017, at 9:31 AM, Klaus Hartke wrote: >=20 > Jim Schaad wrote: >> This would indicate to me that there needs to be some text in the = document about dealing with transitions from TCP->UDP and the other = direction. If the value is "unneeded" and "ignored" then you might end = up with problems if a proxy going between these two different transports = does not do the right thing in terms of putting in "good" values for the = observe option. >=20 > Section 5 of RFC 7641 [1] contains some text that explains how > intermediaries work in the context of resource observation. In short, > resource observation is a hop-by-hop feature: In a > client--proxy--server chain, the Proxy generates the notifications and > sequence numbers for the client; and the server generates the > notifications and sequence numbers for the proxy. A TCP<->UDP > transition does not change that. >=20 >> Are there other places where the fact that TCP has reliable deliver = that are going to cause problems for proxies? For example, should a = UDP->TCP proxy always ack a request since it is going from unreliable to = reliable delivery? >=20 > Acknowledgements in CoAP-over-UDP are a hop-by-hop feature as well: In > a client--proxy--server chain, the proxy acknowledges the confirmable > messages from the client; and the server acknowledges the confirmable > messages from the proxy. An acknowledgement in CoAP has no meaning > other than "I have received your confirmable message; you can stop > retransmitting it now." Over TCP, TCP does the retransmission and > acknowledgement, so the messaging layer of CoAP-over-UDP is not > needed. >=20 > I can see some problems if someone tries to implement a CoAP proxy by > rewriting UDP datagrams into TCP segments. But that's not how CoAP > proxies are intended to work. >=20 > Klaus >=20 > [1] https://tools.ietf.org/html/rfc7641#section-5 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 4 11:06:15 2017 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 DCFA712706D for ; Tue, 4 Apr 2017 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=augustcellars.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 xA8WshMS7Ios for ; Tue, 4 Apr 2017 11:06:11 -0700 (PDT) Received: from mail4.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 01F13128954 for ; Tue, 4 Apr 2017 11:06:11 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491329168; h=from:subject:to:date:message-id; bh=Qg0RJAZNiSYrkZzu4AmRHvuk2GRxYyM4/7kbfDVMiiU=; b=Q4bxpItsPoXDrGmXf/KGq9pS8Q+J/jKkuZ4QvSbrMR251n0ViOnOaPPPZt9B4JZUEVdV7Q1KJyf 4P9mdp6aKoy+Hlet3af4mq5oqDFVSAmg6e36QhSg6WC47SZo3XQ4Ah7FDzGQiMvh1q4RgHbxeTmu3 bCFA8ZT701ueziby3YcltRg2OzleBht7+oc/9U0L1hKvwSnuvnCSrw7MPjYHtc1+a1SOboowHa7mQ NS4Ued7Aig3uJu8m7ZezyVodEC3A8GIRy+XYRgDxyUS0jLyr49ZpqmAjB/5kcJZYRHSJpq73UPic8 SC+tkHusW6WFZ9IJ41elDJ2VfSKJvh2P1ybw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Apr 2017 11:06:07 -0700 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Apr 2017 11:05:42 -0700 From: Jim Schaad To: 'Robert Quattlebaum' , 'Klaus Hartke' , 'Carsten Bormann' CC: 'core' References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> <297FC3B0-E312-423D-939F-080D880F0BDE@gmail.com> <008701d2ad5d$6ffbea70$4ff3bf50$@augustcellars.com> <9D5033DA-96D2-4489-8586-F64B9124C63D@gmail.com> In-Reply-To: <9D5033DA-96D2-4489-8586-F64B9124C63D@gmail.com> Date: Tue, 4 Apr 2017 11:05:40 -0700 Message-ID: <009301d2ad6e$14131b50$3c3951f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxTUTDBoSefxL81keLoFmyvfInogHZFuWWAeLl1r8CIknjdQMueM/WAnp+2lUB4xgVzQINtmCfAoxtAZ8CRJ8OFwLikxtDoD7iwwA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:06:14 -0000 That ACKs are hop-by-hop does not make total intuitive sense to me, = because the proxies that I have dealt with are much more stateless and = therefore are far more likely to let the retransmission be largely = invisible to them. This is the model that I am far more used to from = protocols such as RADIUS where we are trying to deal with the questions = of how re-tries are done when moving from UDP to TCP and back. If you = ACK back from the proxy, then the client may never know that the server = is down or is not going to respond. Does a proxy know that it needs to = fail some way if it later times out? Really lightweight proxies are not = going to do this. Jim > -----Original Message----- > From: Robert Quattlebaum [mailto:darconeous@gmail.com] > Sent: Tuesday, April 4, 2017 10:49 AM > To: Klaus Hartke ; Carsten Bormann > Cc: Jim Schaad ; core > Subject: Re: [core] =F0=9F=94=94 WGLC draft-ietf-core-coap-tcp-tls >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > That ACKs are hop-by-hop makes total intuitive sense to me. That CoAP > observations are hop-by-hop makes considerably less intuitive sense to = me. > That being said, it's hard to argue with the text from RFC7641 that = Carsten > pointed out: >=20 > > Each hop MUST generate its own values for the Observe Option in > > notifications >=20 > This seems baffling to me, as it requires each "hop" to be aware of > observations when it wouldn't necessarily otherwise be required for = the > feature to work=C2=B9. Even when the proxy is aggregating observations = (as it ideally > should be), reusing the same numbers from the origin seems like it = would > have been a good idea, were it not for this text. > But RFC7641 is cooked, so it is what it is. This text from RFC7641 = does appear > to make section A.1 from draft-ietf-core-coap-tcp-tls more consistent. >=20 > An unfortunate consequence of this design is that it implies momentary > changes in the value of an observed resource cannot be reliably = detected > across a "hop", but in the grand scheme of things I suppose it isn't = that big of a > deal. >=20 > - -\- RQ >=20 > =C2=B9 I realize that this is technically incorrect, because for that = to > work resets would need to be propagated across "hops", too. I think > it is rather unfortunate that resets are not propagated across > hops, since it would have allowed for relatively dumb proxies. But > seeing that apparently well-established consensus is that resets > are not intended to propagate across hops I won't press the issue > further. >=20 >=20 > -----BEGIN PGP SIGNATURE----- >=20 > iQEcBAEBCAAGBQJY49ulAAoJEE6OLsxF2Ko6dBUH+QEga+qDxbg0jgXZOx/bE8U > o > WJtatgpXZIXKmmyePG2hNf+DZWBWnoo4n4N/NumLM3GD+vHSdDuWjNaWm > CFSLnxx > keKfuMpuppyV8k3ZIAeCJVsJw6+irysOzUb1t/izRwmvu+AZdmtH4VbnKy1WgOP > f > kTl55I74FEG/duy0jzL7rpOSJiUKrgazWHM4xTSgRZvQqj4/yOtOvx2AZAhNdXbn > ENy4yVYZUsvJgDMfHXWHx9comRUTMaff202MjBompFiWyiyfB73kyjTsStLjYlDb > D/6P0lWXh35lA2VIsANptr8Dl4f29bo9SwSrPwhcrMRn4VquRizFd6wnl8nVynY=3D > =3DT675 > -----END PGP SIGNATURE----- >=20 > > On Apr 4, 2017, at 9:31 AM, Klaus Hartke wrote: > > > > Jim Schaad wrote: > >> This would indicate to me that there needs to be some text in the > document about dealing with transitions from TCP->UDP and the other > direction. If the value is "unneeded" and "ignored" then you might = end up > with problems if a proxy going between these two different transports = does > not do the right thing in terms of putting in "good" values for the = observe > option. > > > > Section 5 of RFC 7641 [1] contains some text that explains how > > intermediaries work in the context of resource observation. In = short, > > resource observation is a hop-by-hop feature: In a > > client--proxy--server chain, the Proxy generates the notifications = and > > sequence numbers for the client; and the server generates the > > notifications and sequence numbers for the proxy. A TCP<->UDP > > transition does not change that. > > > >> Are there other places where the fact that TCP has reliable deliver = that are > going to cause problems for proxies? For example, should a UDP->TCP = proxy > always ack a request since it is going from unreliable to reliable = delivery? > > > > Acknowledgements in CoAP-over-UDP are a hop-by-hop feature as well: = In > > a client--proxy--server chain, the proxy acknowledges the = confirmable > > messages from the client; and the server acknowledges the = confirmable > > messages from the proxy. An acknowledgement in CoAP has no meaning > > other than "I have received your confirmable message; you can stop > > retransmitting it now." Over TCP, TCP does the retransmission and > > acknowledgement, so the messaging layer of CoAP-over-UDP is not > > needed. > > > > I can see some problems if someone tries to implement a CoAP proxy = by > > rewriting UDP datagrams into TCP segments. But that's not how CoAP > > proxies are intended to work. > > > > Klaus > > > > [1] https://tools.ietf.org/html/rfc7641#section-5 > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Wed Apr 5 18:59:08 2017 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 F2211126B6E; Wed, 5 Apr 2017 18:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 wYhfRlWDoGoX; Wed, 5 Apr 2017 18:59:04 -0700 (PDT) Received: from mail4.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 5DCD1127077; Wed, 5 Apr 2017 18:59:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491443943; h=from:subject:to:date:message-id; bh=0FTQKskPzu72vKqmEsj9Oo773nS6tR22Mb8+1OQCmSA=; b=Rrzadb+haUgBpLE6KUQ6VAnQoh+6bvyzP+4UWomJ+wYwrmuvJVLhsoGk7xZdpjsihzzyQETo+Ab Q2HTokn23BwsUgl9ISOcQPC6XQ007Md0w0Q04PqFndg0DAiBnj02pFIHEB61Zc9y3PNEG7xKjEDMH Z/+Tgvv1yU8FlguLZznFb7wG6GdHQm/wQHkaoxZsajDdBrgc07Y9xCYDm2aRvJRmwp2dQx/anFBck AVamAYyRzMrp2pPFoovF7pwUu8DeIzFdPDP4dsWWUKX1ucP4n+Kn/V07ug1vHW/pVydoetbvpEu2U DalSjOh7KOWrU2XDQ6L2mdkL5BUPBVWXNybw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Apr 2017 18:59:02 -0700 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Apr 2017 18:58:57 -0700 From: Jim Schaad To: CC: 'core' Date: Wed, 5 Apr 2017 18:58:54 -0700 Message-ID: <017401d2ae79$5a6378f0$0f2a6ad0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKuTspS7D95VPiCTf6PMOteBsYMvA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Review on draft-tiloca-core-multicast-oscoap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 01:59:06 -0000 Here are a few comments on this draft. Section 1 - "Keying Material" - it is a bit confusing to say "key, key pairs". I suggest that this become more detailed on the types of keys - and perhaps purpose - or maybe just reduce to one item. Section 1 - "GM" - The sentence starting "A GMC can" should be split into two as the concepts are different. Section 1 - "GM" - I think that the word 'may' should not be in these sentences. This is what it is responsible for, a group may not use the services. That is a different statement. Section 1 - "GM" - I do not understand what this sentence is trying to say "Any message exchange with the GM MUST be secured and based on different secure channels for different endpoints." Section 1 - "Listener" - Are there cases where a listener may reply to a multicast message w/ a multicast rather than a unicast message? Section 1 - "Group response" - Is this a normal term? Group is implying multicast to my uneducated mind. Section 1 - "Source authentication" - suggest the last sentence ends "not tampered with either by a different group member or by a non-group member". Section 2 - "Multicast communication technology" - The first for instance is a problem, thisis really an M-to-N situation if you are talking about "switches". You should probably change this to "a single switch" so that it is really 1 not M. Section 2 - You should probably add a requirement on ordering of messages. Specifically - there is a requirement that it is possible to determine ordering of messages coming from a single sender, but it is not a requirement to be able to determine the correct ordering of messages between two different senders. If this is a requirement then it needs to be incorporated into the data portion of the protocol. Section 3- para 3 - the last sentence needs to be cleaned up a bit. It could be read as saying that two endpoint ids that are in different groups is precluded. Section 3 - Note that endpoint ids only need to be assigned to multicasters, a pure listener that never responds w/ unicast does not need to have an endpoint id. This would be protocol specific. Section 4 - You would have zero or one sender context - depending on if you would ever respond unicast to a message - protocol dependent. Section 4 - You would have R recipient contexts. One for every possible sender of a message to this endpoint. This would be M-1 or N-1 for a multicaster (depending if unicast responses are needed) or M for a listener. Section 4 - Creation of recipient contexts on demand is an optional item. The current text reads as mandatory. Section 4 - Need to update the last paragraph of this section to deal with the changes in OSCOAP - I assume that Cid is converted into a Group Identifier. The question then becomes if this is transmitted as a separate item or if it is part of the kid when transmitted. Additionally, how it is put into the AAD needs to be modified. Section 5 - Yes - need to be sure to highlight the difference between this and unicast as re-use of serial numbers might occur without the change of using the sender context partial IV always. Section 6.2 - The order of verifying the signature and doing the decryption does not matter and thus should not be mandated. It may be that it is cheaper to do the decryption first as long as the memory constraint is not so large that decryption in place is needed. This would allow the cheaper operation occur first. Section 6.4 - the mapping rules are not necessarily the same in the final paragraph of this section. This is because of the updates to OSCOAP. Section 7.3 - You need to have a bit of a discussion here about the difference between a late joining endpoint and a new endpoint that is joining an existing group. The in latter case there would not be an issue w/ serial numbers because a new context is going to be created. RANT - Please review all 2119 language. If it does not refer to a byte on the wire or to a specific step that one of the parities is going to perform, then it is not appropriate. Example the MAY in the first paragraph of section 3. How would I even think about doing a compliance test for this? Jim From nobody Thu Apr 6 16:30:06 2017 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 D92DD129498; Thu, 6 Apr 2017 16:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Ozd2Gvx7Jaju; Thu, 6 Apr 2017 16:29:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BC8127978; Thu, 6 Apr 2017 16:29:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 48DF6B80DD6; Thu, 6 Apr 2017 16:29:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org Message-Id: <20170406232938.48DF6B80DD6@rfc-editor.org> Date: Thu, 6 Apr 2017 16:29:38 -0700 (PDT) Archived-At: Subject: [core] RFC 8132 on PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 23:29:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8132 Title: PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) Author: P. van der Stok, C. Bormann, A. Sehgal Status: Standards Track Stream: IETF Date: April 2017 Mailbox: consultancy@vanderstok.org, cabo@tzi.org, anuj.sehgal@navomi.com Pages: 21 Characters: 42359 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-core-etch-04.txt URL: https://www.rfc-editor.org/info/rfc8132 DOI: 10.17487/RFC8132 The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Apr 7 08:03:44 2017 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 1A695129449 for ; Fri, 7 Apr 2017 08:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smartthings-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ihad2OS_vUX for ; Fri, 7 Apr 2017 08:03:38 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400D51294D1 for ; Fri, 7 Apr 2017 08:03:31 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id g2so68166122pge.3 for ; Fri, 07 Apr 2017 08:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=from:subject:date:message-id:cc:to:mime-version; bh=yYBoeh7pL4uLQN7gkPMGwtrWn+SJeCOIgQjCeiDYOVY=; b=HPwRCn986WDVV+/3CXCz2CETBvz/EYn6NqWYnXHfwSK+tYv5v4Aun2/4GQmCfQ8DEP LUeIIHGNOfjbKarcT/GajW6d7jlLh0Y1d/TlhxyMJ8oAFBOaaPrP+lYQ5xLb6Hi8PpOO 9h8o71x+qgPEy6WbZC0xwnCiftV197+JcGxfAsSF2lW2bHLG5IagyEWtwYurApHd1aX1 +d5pZU8Q2SM94yUEKB9H55OMnveoOhjuO0tD/3B0H7kPrIkRGZsS3XjHBJIWBkwFFOmp Vz6BOcyJF/eBonwhKP5McjT8ttDHTUBfNaCioAm3fR3uoBKMIbrb3aDN37uOUD4Fg+ie fz+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=yYBoeh7pL4uLQN7gkPMGwtrWn+SJeCOIgQjCeiDYOVY=; b=AqemlHFlXkuhYhaQQRpj+c2VwQROf5sxyTm3BSmMen2QXl4z5dNDfufSl9Uh0ujw3J IxIku2yGbMNNy5SPTk1/0N468L44pYvtYmu2IxwlNHRY5H/jH4G1OqmlupUvnm+pIO9A pyWPWlXWxTpm5zO4v1x7ndlanE5WN2grtp+9vAmO7wKyRMKaKJqWVHAS+AvZ+vWTdywW m3YPoIdrR12WfuOK1QH7znY8XMDNwWi4HDDDO3+Y28KXorqLL6Cpuvsv1fe4TW9GgPOV jvUc7mPOiOzHuk3ETlAR3tXggYUmQHHCE8alXfm5tyDHanP7qGJ8kRPIe+4qU9+B1vm3 XTGQ== X-Gm-Message-State: AFeK/H2qBTgp3p+R2CwW6rcBSOPvaGppvEwLFr8SjMIR+ydC8lmAuyRyCx9zW//X4jHochl/ X-Received: by 10.99.95.73 with SMTP id t70mr41003002pgb.84.1491577410526; Fri, 07 Apr 2017 08:03:30 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id j73sm10260532pfj.70.2017.04.07.08.03.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 08:03:29 -0700 (PDT) From: Michael Koster Content-Type: multipart/alternative; boundary="Apple-Mail=_A8823359-FCC4-4B13-84E5-F9FF3EE732DA" Date: Fri, 7 Apr 2017 08:03:27 -0700 Message-Id: <2B5F5BA0-875A-4941-BB27-7764DB19A942@smartthings.com> Cc: core , "draft-ietf-core-resource-directory@ietf.org" To: Kerry Lynn , peter van der Stok , Carsten Bormann , Zach Shelby , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Christian_Ams=C3=BCss?= Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [core] Continuing the Resource Directory and DNS-SD discussion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:03:41 -0000 --Apple-Mail=_A8823359-FCC4-4B13-84E5-F9FF3EE732DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, The last discussion as I recall from the CoRE meeting was around 3 = points: 1. Using DNS-SD to find a resource directory 2. Providing "ins" and "exp" link attributes=20 3. Specifying DNS-SD mapping to links in the RD document We have already decided for points 1 and 2 within the scope of the RD = document. We are discussing whether the DNS-SD mapping should be = published in the RD document. At IETF 98 we had two discussions.. First, should DNS-SD mapping be included in the RD draft? This question can be informed by the requirements for the mapping itself = and the expected use case of the mapping. Based on the discussion below, there is a case to be made for publishing = the mapping or RD links to DNS-SD records as a separate document. - DNS-SD is not required to use RD. It would not be helpful to couple RD = and DNS-SD unnecessarily by creating intra-document dependencies. - A good use scenario and introductory explanation is needed, describing = the relationship of RD to DNS-SD, which may be better served in its own = document. - Additional constraints on the use of RD are needed to facilitate the = mapping, such as limiting the length of identifiers, requiring the = presense of the "rt" attribute, requiring the use of "ins" and "exp". = What is mandatory in RD? - The rd-dns-sd draft can refer to RD normatively and publish in the = same time frame, since the 2 documents will both be working group = adopted and have good support. The RD document will not need to refer to = the RD-DNS-SD document normatively. There is a github repository with this work in progress and issues = tracking: RD document: https://github.com/core-wg/resource-directory = RD to DNS-SD mapping document: https://github.com/core-wg/rd-dns-sd = The second question was to clarify the mapping itself, and its use case. = We had several enlightening discussions, which I will try to summarize = here. What is DNS-SD mapping and how does it work? What are the use cases and = what assumptions do they drive? The big bit seems to be service discovery vs. resource discovery The use case for DNS-SD is service discovery across broad network scope, = including mesh and bridged/routed networks.=20 The use case for RD is fine grain resource discovery using hyperlinks, = as part of a REST client-server state machine. Clearly these are mostly = complementary use cases, and it is easy to build service discovery on = top of REST. Resource Directories are themselves REST servers and can = respond to multicast discovery queries, but have no well defined = discovery proxy for routed and bridged networks. Once the RD address is = known, it can participate in REST interactions through unicast = transactions.=20 The use case for RD to DNS-SD mapping is in making DNS-SD services = discoverable as RD registered endpoints and links, and to make RD = registered endpoints and links discoverable as DNS-SD services. Based on this, a system could bootstrap resource discovery by = advertizing the resource directory location(s) usind DNS-SD and the link = mapping to RD services; e.g. links with = "rt=3Dcore.rd;rt=3Dcore.rd-lookup-res;core.rd-lookup-ep" etc. would be = registered in an RD and exported to DNS-SD. Other RD services in the = network would expose links to the RD services that were discovered over = DNS-SD. In this way, all of the RD services that are only reachable = using unicast could be discovered in "local" RD services. DNS-SD would = be used to keep all of the RD service locations discoverable through RD = on local network scope. A number of assumptions and requirements for the mapping: Links registered in RD for export to DNS-SD use the "rt" link attribute = for translation to DNS service type name and transmitted as a SRV = record. Link context, consisting of scheme+authority+port, will be translated to = a DNS service location and transmitted as a PTR record. The remaining information in the link, or perhaps the entire link, will = be transmitted in DNS-SD as a TXT record. Based on these discussion, I am recommending that the DNS-SD mapping to = RD links be taken up in a separate document, to normatively refer to the = RD document, and be published in the same time frame in order to enable = systems to use both RD and DNS-SD together. --Apple-Mail=_A8823359-FCC4-4B13-84E5-F9FF3EE732DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

The = last discussion as I recall from the CoRE meeting was around 3 = points:

1. = Using DNS-SD to find a resource directory

2. Providing "ins" and "exp" link = attributes 

3. Specifying DNS-SD mapping to links in the RD = document

We = have already decided for points 1 and 2 within the scope of the RD = document. We are discussing whether the DNS-SD mapping should be = published in the RD document.

At IETF 98 we had two = discussions..

First, should DNS-SD mapping be included in the RD = draft?

This = question can be informed by the requirements for the mapping itself and = the expected use case of the mapping.

Based on the discussion below, there is = a case to be made for publishing the mapping or RD links to DNS-SD = records as a separate document.

- DNS-SD is not required to use RD. It = would not be helpful to couple RD and DNS-SD unnecessarily by creating = intra-document dependencies.
- A good use scenario = and introductory explanation is needed, describing the relationship of = RD to DNS-SD, which may be better served in its own document.
- Additional constraints on the use of RD are needed to = facilitate the mapping, such as limiting the length of identifiers, = requiring the presense of the "rt" attribute, requiring the use of "ins" = and "exp". What is mandatory in RD?
- The rd-dns-sd = draft can refer to RD normatively and publish in the same time frame, = since the 2 documents will both be working group adopted and have good = support. The RD document will not need to refer to the RD-DNS-SD = document normatively.

There is a github repository with this work in progress and = issues tracking:
RD document: https://github.com/core-wg/resource-directory
RD to DNS-SD mapping document: https://github.com/core-wg/rd-dns-sd

The second question was = to clarify the mapping itself, and its use case. We had several = enlightening discussions, which I will try to summarize here.

What is DNS-SD mapping = and how does it work? What are the use cases and what assumptions do = they drive?

The = big bit seems to be service discovery vs. resource discovery

The use = case for DNS-SD is service discovery across broad network scope, = including mesh and bridged/routed networks. 

The use case for RD is = fine grain resource discovery using hyperlinks, as part of a REST = client-server state machine. Clearly these are mostly complementary use = cases, and it is easy to build service discovery on top of REST. = Resource Directories are themselves REST servers and can respond to = multicast discovery queries, but have no well defined discovery proxy = for routed and bridged networks. Once the RD address is known, it can = participate in REST interactions through unicast = transactions. 

The use case for RD to DNS-SD = mapping is in making DNS-SD services discoverable as RD registered = endpoints and links, and to make RD registered endpoints and links = discoverable as DNS-SD services.

Based on this, a system could bootstrap = resource discovery by advertizing the resource directory location(s) = usind DNS-SD and the link mapping to RD services; e.g. links with = "rt=3Dcore.rd;rt=3Dcore.rd-lookup-res;core.rd-lookup-ep" etc. would be = registered in an RD and exported to DNS-SD. Other RD services in the = network would expose links to the RD services that were discovered over = DNS-SD. In this way, all of the RD services that are only reachable = using unicast could be discovered in "local" RD services. DNS-SD would = be used to keep all of the RD service locations discoverable through RD = on local network scope.

A number of assumptions and requirements for the = mapping:

Links = registered in RD for export to DNS-SD use the "rt" link attribute for = translation to DNS service type name and transmitted as a SRV = record.

Link = context, consisting of scheme+authority+port, will be translated to a = DNS service location and transmitted as a PTR record.

The remaining = information in the link, or perhaps the entire link, will be transmitted = in DNS-SD as a TXT record.

Based on these discussion, I am recommending that the DNS-SD = mapping to RD links be taken up in a separate document, to normatively = refer to the RD document, and be published in the same time frame in = order to enable systems to use both RD and DNS-SD together.




= --Apple-Mail=_A8823359-FCC4-4B13-84E5-F9FF3EE732DA-- From nobody Fri Apr 7 09:59:52 2017 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 5E90B12942F for ; Fri, 7 Apr 2017 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.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 8li64bu-gEhi for ; Fri, 7 Apr 2017 09:59:50 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D7AFE129481 for ; Fri, 7 Apr 2017 09:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491584389; d=isode.com; s=june2016; i=@isode.com; bh=X8WEVW86Ho8bNdsGl/bVRPUSyNlTVj8WWJXdgwDqN3o=; 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=A2+Xx4ik4WaqKe4V94ZBwt58LS+s4RBgJtA8zuJLS7dWysEIa0nht23H3fO6pfjeVHgen8 dAN+tVbiR/yfUQC5ElDF1dysvcsOYVv+38vjlJew0pQU6myZlZnZVc39HsWXjdWZ2CzrWh CLrMVYEIIpoCxEoKKyTsth0uhIvTYbU=; 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 ; Fri, 7 Apr 2017 17:59:48 +0100 To: "core@ietf.org" From: Alexey Melnikov Message-ID: <132ab7aa-7ba7-6ea4-1ef3-6a0fe76f7b92@isode.com> Date: Fri, 7 Apr 2017 17:59:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [core] AD review of draft-ietf-core-links-json-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:59:51 -0000 Hi, I have requested an extra review to check that use of Link relations is correct. I also found a small cut & paste error: In 3.2: +------------------------------+-------+ | Media type | ID | +------------------------------+-------+ | application/link-format+cbor | TBD64 | | application/link-format+cbor | TBD54 | +------------------------------+-------+ I think one of these should be +json. As I have no other comments, I've initiated IETF LC for this document. Thank you, Alexey From nobody Fri Apr 7 10:05:11 2017 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 D6AC81294F3; Fri, 7 Apr 2017 10:05:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, Jaime Jimenez , draft-ietf-core-links-json@ietf.org, core@ietf.org, alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149158470280.11163.1811202987047421967.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 10:05:02 -0700 Archived-At: Subject: [core] Last Call: (Representing CoRE Formats in JSON and CBOR) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:05:03 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Representing CoRE Formats in JSON and CBOR' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 7 12:02:19 2017 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 0D44D12958B for ; Fri, 7 Apr 2017 12:02:17 -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 XnlVArqLOYcU for ; Fri, 7 Apr 2017 12:02:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BC01296DC for ; Fri, 7 Apr 2017 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v37J1i7L010237; Fri, 7 Apr 2017 21:01:44 +0200 (CEST) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w087r2n47zDHG0; Fri, 7 Apr 2017 21:01:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <132ab7aa-7ba7-6ea4-1ef3-6a0fe76f7b92@isode.com> Date: Fri, 7 Apr 2017 21:01:43 +0200 Cc: "core@ietf.org" X-Mao-Original-Outgoing-Id: 513284503.308049-2f05ab256c3aaa51f5c73423bdd5d322 Content-Transfer-Encoding: quoted-printable Message-Id: <3E3013DD-E574-4B56-8F2E-92288F01E19C@tzi.org> References: <132ab7aa-7ba7-6ea4-1ef3-6a0fe76f7b92@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] AD review of draft-ietf-core-links-json-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:02:17 -0000 On Apr 7, 2017, at 18:59, Alexey Melnikov = wrote: >=20 > | application/link-format+cbor | TBD64 | > | application/link-format+cbor | TBD54 | Indeed, this registration should be | application/link-format+cbor | TBD64 | | application/link-format+json | TBD54 | (Listed in alphabetical, not the suggested numerical order. Note that 60 is application/cbor and 50 is application/json, and then 40 = is application/link-format, so there is some mnemonic value to using 64 = and 54 as suggested numbers =E2=80=94 at least to my twisted mind :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 7 12:47:04 2017 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 DB97D126BFD for ; Fri, 7 Apr 2017 12:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 p47kWIcVK8kX for ; Fri, 7 Apr 2017 12:47:01 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AF5126C7A for ; Fri, 7 Apr 2017 12:47:00 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id g2so74237086pge.3 for ; Fri, 07 Apr 2017 12:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e32KhlVUFBCsjPmRQl+sqqZmRrdn5Nr2LTmyziejcKw=; b=Jeua8OFPPWZBe54CSynPJKamJwqpL5Gm6bnEUGFIMIQe4SXyHT8XeM4LJNDpO5o6Lc GUKaJ5IJZo142Arw0kYvlqrVtAebhDvOkn/ZoMpnR2/mLIdz/rVXhXGugoBMxWssI0eX 4AFlojoUVYlqftx8NdFPV05SKLAEaXNL5qvf2QFw1gEjKphLQFPEBLORwZU6rbFbWTeD wN4F8hRRAXKJcOzLSKH8gh2fz27TXXA7mxsAsp9SipCkp7SgNnP6Phhv58DtB9SVUzaI eO22BA1KwGE4SLkrgD5Iudr8O/q1rBu13ZZ+8O5Fr0tFMikvbY4h30lCph3iTrjTedfW gVBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e32KhlVUFBCsjPmRQl+sqqZmRrdn5Nr2LTmyziejcKw=; b=AwQUrkqSwVomBvU4p9DUFGOKmZojOOlmf1LUxhGkqU71O/iMpYd1GFRvslyDYDlvRQ xNift8Givy0TuVHiWTGE6nFhYhu58nDvdDF6SW5VBdD1GlWDoldkx3rJyAaPEE8b/SVn SeKRly0Y8NH3Vvp7+oq4TmKf3Y6TpInVbDznUQu6iT7LoUJ4ggnm+Roth7S0P5KPSjwI 0GyqU3sBXnAwUXfyNmJuWtbdcNskgguqTRnqyFE6YHNLfYgnQmf/ZUOp+LH5xQpcb9jL oO7I669UQP91oPjwfD/sDMb1ur1AOBNvFnMG1ftMVDBGD6eyrwpaIvPlZ6NPuS8Td5Mh TnJA== X-Gm-Message-State: AFeK/H0ZE0ueC+xD7UJMEiPoQEFz6gJO+Vtcow90nFlfDHZIRjQ7lwXT2uAAHvI9HPfc/g== X-Received: by 10.98.196.221 with SMTP id h90mr41328913pfk.149.1491594420510; Fri, 07 Apr 2017 12:47:00 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id s13sm11091520pfd.46.2017.04.07.12.46.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 12:46:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <3E3013DD-E574-4B56-8F2E-92288F01E19C@tzi.org> Date: Fri, 7 Apr 2017 12:46:58 -0700 Cc: Alexey Melnikov , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <390BC795-CBE5-421A-9118-40E980EB608F@gmail.com> References: <132ab7aa-7ba7-6ea4-1ef3-6a0fe76f7b92@isode.com> <3E3013DD-E574-4B56-8F2E-92288F01E19C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] AD review of draft-ietf-core-links-json-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:47:03 -0000 60 is application/cbor and=20 50 is application/json, and then=20 40 is application/link-format=20 therefore: | application/link-format+cbor | TBD100 | | application/link-format+json | TBD90 | ;-) > On Apr 7, 2017, at 12:01 PM, Carsten Bormann wrote: >=20 > On Apr 7, 2017, at 18:59, Alexey Melnikov = wrote: >>=20 >> | application/link-format+cbor | TBD64 | >> | application/link-format+cbor | TBD54 | >=20 > Indeed, this registration should be >=20 > | application/link-format+cbor | TBD64 | > | application/link-format+json | TBD54 | >=20 > (Listed in alphabetical, not the suggested numerical order. > Note that 60 is application/cbor and 50 is application/json, and then = 40 is application/link-format, so there is some mnemonic value to using = 64 and 54 as suggested numbers =E2=80=94 at least to my twisted mind :-) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Apr 8 20:53:26 2017 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 E798B128DE7; Sat, 8 Apr 2017 20:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 xcxBljahfKUU; Sat, 8 Apr 2017 20:53:16 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E112B126E3A; Sat, 8 Apr 2017 20:53:15 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2A03A29C9DC; Sun, 9 Apr 2017 12:53:13 +0900 (JST) Received: by mail-oi0-f43.google.com with SMTP id l63so12047633oig.2; Sat, 08 Apr 2017 20:53:13 -0700 (PDT) X-Gm-Message-State: AFeK/H2OnXmfqg2iRi8GkVofIn8CGqBPchEFjaGPCVLn+FBG2EFFtIbxtdm04TXPDmgJtSRRehr7j+cKhXazPw== X-Received: by 10.202.97.6 with SMTP id v6mr11468290oib.214.1491709991791; Sat, 08 Apr 2017 20:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Sat, 8 Apr 2017 20:53:11 -0700 (PDT) From: Yoshifumi Nishida Date: Sat, 8 Apr 2017 20:53:11 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tsv-art@ietf.org Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=001a113d4fee2b36e8054cb3ccb5 Archived-At: Subject: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 03:53:18 -0000 --001a113d4fee2b36e8054cb3ccb5 Content-Type: text/plain; charset=UTF-8 Document: draft-ietf-core-coap-tcp-tls-07 Reviewer: Yoshifumi Nishida I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Summary: This document is well-written. It is almost ready to be published as a PS draft once the following points are addressed. 1: It is not clear how the protocol reacts the errors from transport layers (e.g. connection failure). The protocol will just inform apps of the events and the app will decide what to do or the protocol itself will do something? 2: There will be situations where the app layer is freezing while the transport layer is still working. Since transport layers cannot detect this type of failures, there should be some mechanisms for it somewhere in the protocol or in the app layer. The doc needs to address this point. For example, what will happen when a PONG message is not returned for a certain amount of time? 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc. -- Yoshi --001a113d4fee2b36e8054cb3ccb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Document: draft-ietf-core-coap-tcp-tls-07
Reviewer: Yoshifumi Nishid= a
<= br>
I've reviewed= this document as part of TSV-ART's ongoing effort to review key IETF d= ocuments. These comments were written primarily for the transport area dire= ctors, but are copied to the document's authors for their information a= nd to allow them to address any issues raised.When done at the time of IETF= Last Call, the authors should consider this review together with any other= last-call comments they receive. Please always CC=C2=A0tsv-art@ietf.org=C2=A0if you reply t= o or forward this review.

Summary:=C2=A0This document is well-written. It is almost ready= to be published as a PS draft once=C2=A0the following points are addressed= .

1: It is not cl= ear how the protocol reacts the errors from transport layers (e.g. connecti= on failure).
= =C2=A0 =C2=A0The protocol will just inform apps of the events and the app w= ill decide what to do or the protocol itself will do something?

2: There will be situations where = the app layer is freezing while the transport layer is still working. Since= transport layers cannot detect this type of failures, there should be some= mechanisms for it somewhere in the protocol or in the app layer.=C2=A0 The= doc needs to address this point. For example, what will happen when a PONG= message is not returned for a certain amount of time?
=C2=A0
3: Since this draft defines new SZX value= , I think the doc needs to update RFC7959. This point should be clarified m= ore in the doc.
--
Yoshi
=
--001a113d4fee2b36e8054cb3ccb5-- From nobody Sun Apr 9 00:25:44 2017 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 CD89A129456; Sun, 9 Apr 2017 00:25:27 -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 Or48n5sLs9Ea; Sun, 9 Apr 2017 00:25:26 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D3B129329; Sun, 9 Apr 2017 00:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v397PMHT000531; Sun, 9 Apr 2017 09:25:22 +0200 (CEST) Received: from client-0060.vpn.uni-bremen.de (client-0060.vpn.uni-bremen.de [134.102.107.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w14bQ1yhBzDHdT; Sun, 9 Apr 2017 09:25:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sun, 9 Apr 2017 09:25:21 +0200 Cc: tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org X-Mao-Original-Outgoing-Id: 513415521.674309-e6e2b439554923e512814b6ee2040d7e Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 07:25:28 -0000 Hi Yoshi, thank you very much for your thoughtful review. For now, let me pick one of your comments: > 3: Since this draft defines new SZX value, I think the doc needs to = update RFC7959. This point should be clarified more in the doc. The spec does indeed define a new SZX value, for use with the = environments this document is used in (reliable transports). It does = not change or add anything to the way RFC 7959 is used with the existing = unreliable transports; as such it does not really update RFC 7959 as = much as it does extend it for its own purposes. (However, the same argument could be made for RFC 7641, which we do say = we update.) Maybe we are not making the point forcefully enough that SZX=3D7 is = meant for use within this spec? (Again, however: any other future COAP transports that have larger = messages might pick up SZX=3D7 as well.) I don=E2=80=99t have a strong opinion on how to populate the = =E2=80=9Cupdates=E2=80=9D graph of RFCs in these boundary cases; it = might help to get some more guidance here. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Apr 9 07:13:00 2017 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 518CA128C81 for ; Sun, 9 Apr 2017 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcGa62DopK0Y for ; Sun, 9 Apr 2017 07:12:56 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF40312785F for ; Sun, 9 Apr 2017 07:12:55 -0700 (PDT) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 80458172095 for ; Sun, 9 Apr 2017 16:12:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 5SQy60nDCP-q for ; Sun, 9 Apr 2017 16:12:51 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.10] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A15201720A3 for ; Sun, 9 Apr 2017 16:12:50 +0200 (CEST) From: Alexander Pelov Content-Type: multipart/alternative; boundary="Apple-Mail=_92E8FA76-2F4E-4BB6-B8B4-141BCEDC2658" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Sun, 9 Apr 2017 16:12:49 +0200 To: Core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 14:12:58 -0000 --Apple-Mail=_92E8FA76-2F4E-4BB6-B8B4-141BCEDC2658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, IANA has received a request from Michael Koster to register two new CoAP = options: - Accept-Content-Format-Version - Content-Format-Version The registration happens after an expert review and after a couple of = mail exchanges and meeting Michael in person in Chicago, we (the experts = and Michael) decided that the discussion should be brought to the = mailing list, before getting the final approval.=20 One of the major questions that needs to be discussed is the following: What are the reasons *NOT* to allocate a new Content-Format number (RFC = 7252) for each new version? (in the HTTP world, "version" is a simple = parameter to the Content-Type, so why not treat it as such?) The question is not trivial, as it touches upon content format = negotiation, e.g. how should the Server use the = Accept-Content-Format-Version in order to indicate that it is willing to = accept both application/vnd.ocf+cbor AND = application/application/vnd.ocf+cbor;version=3D2.0, with a preference = for the latter? In the semantics of the version parameter, the two = should be considered completely independent/incompatible types.=20 The current way of doing this would be to allocate separate = Content-Format numbers to "application/application/vnd.ocf+cbor" (10000 = as it stands now) and "application/application/vnd.ocf+cbor;version=3D2.0"= (e.g. 10001).. and then use some form of content negotiation.=20 This however can have its disadvantages, .. and the way industry does = use versioning in some cases (e.g. people DO use the version parameter = to version their RESTful APIs.. which means, that NOT having such = mechanism in CoAP could theoretically drive them to re-register blocks = of Content-Format numbers, just to differentiate between their APIs). In any case, we need to have this discussion documented on the mailing = list (as previously discussed with Michael), so here we go.. Best, Alexander --Apple-Mail=_92E8FA76-2F4E-4BB6-B8B4-141BCEDC2658 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear all,

IANA has received a request from = Michael Koster to register two new CoAP options:
- = Accept-Content-Format-Version
- = Content-Format-Version

The registration happens after an expert review and after a = couple of mail exchanges and meeting Michael in person in Chicago, we = (the experts and Michael) decided that the discussion should be brought = to the mailing list, before getting the final approval. 

One of the major = questions that needs to be discussed is the following:
What are the reasons *NOT* to allocate a new = Content-Format number (RFC 7252) for each new version? (in the HTTP = world, "version" is a simple parameter to the Content-Type, so why not = treat it as such?)

The question is not trivial, as it touches upon content = format negotiation, e.g. how  should the Server use the = Accept-Content-Format-Version in order to indicate that it is willing to = accept both application/vnd.ocf+cbor AND application/application/vnd.ocf+cbor;version=3D2.0, with = a preference for the latter? In the semantics of the version parameter, = the two should be considered completely independent/incompatible = types. 

The= current way of doing this would be to allocate separate Content-Format = numbers to "application/application/vnd.ocf+cbor" (10000 as it stands = now) and "application/application/vnd.ocf+cbor;version=3D2.0" (e.g. = 10001).. and then use some form of content negotiation. 

This however can have = its disadvantages, .. and the way industry does use versioning in some = cases (e.g. people DO use the version parameter to version their RESTful = APIs.. which means, that NOT having such mechanism in CoAP could = theoretically drive them to re-register blocks of Content-Format = numbers, just to differentiate between their APIs).

In any case, we need to = have this discussion documented on the mailing list (as previously = discussed with Michael), so here we go..

Best,
Alexander

= --Apple-Mail=_92E8FA76-2F4E-4BB6-B8B4-141BCEDC2658-- From nobody Sun Apr 9 07:55:27 2017 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 D4DE412785F for ; Sun, 9 Apr 2017 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXpdm76Cv8Gm for ; Sun, 9 Apr 2017 07:55:24 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0110126C83 for ; Sun, 9 Apr 2017 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v39EtLDt006962 for ; Sun, 9 Apr 2017 16:55:21 +0200 (CEST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w1GZc5rVQzDHhj for ; Sun, 9 Apr 2017 16:55:20 +0200 (CEST) Received: by mail-io0-f174.google.com with SMTP id r16so17270390ioi.2 for ; Sun, 09 Apr 2017 07:55:20 -0700 (PDT) X-Gm-Message-State: AFeK/H1E7W2afVFaW/ylkNXEni4XeeTE+eErf0tVsrI2R8v5twxO+0BLochE5yPEqP9zYJlWZF9jAbVgYdDUBA== X-Received: by 10.107.146.198 with SMTP id u189mr51402875iod.173.1491749719655; Sun, 09 Apr 2017 07:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.65 with HTTP; Sun, 9 Apr 2017 07:54:39 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Sun, 9 Apr 2017 16:54:39 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 14:55:26 -0000 Alexander Pelov wrote: > IANA has received a request from Michael Koster to register two new CoAP > options: > - Accept-Content-Format-Version > - Content-Format-Version Spec? > One of the major questions that needs to be discussed is the following: What are the other questions? > What are the reasons *NOT* to allocate a new Content-Format number (RFC > 7252) for each new version? (in the HTTP world, "version" is a simple > parameter to the Content-Type, so why not treat it as such?) None? > The question is not trivial, as it touches upon content format negotiation, > e.g. how should the Server use the Accept-Content-Format-Version in order > to indicate that it is willing to accept both application/vnd.ocf+cbor AND > application/application/vnd.ocf+cbor;version=2.0, with a preference for the > latter? In the semantics of the version parameter, the two should be > considered completely independent/incompatible types. CoAP currently has no features for content format negotiation, only for the selection of an available content format. If a server wishes to indicate available content formats, it needs to do so in the (hypermedia) representation. (The CoAP Accept option can only be used in requests, not in responses.) Are the two options a proposal to change that? Need spec. > The current way of doing this would be to allocate separate Content-Format > numbers to "application/application/vnd.ocf+cbor" (10000 as it stands now) > and "application/application/vnd.ocf+cbor;version=2.0" (e.g. 10001).. and > then use some form of content negotiation. Yes. > This however can have its disadvantages, .. and the way industry does use > versioning in some cases (e.g. people DO use the version parameter to > version their RESTful APIs.. which means, that NOT having such mechanism in > CoAP could theoretically drive them to re-register blocks of Content-Format > numbers, just to differentiate between their APIs). Working as intended. > In any case, we need to have this discussion documented on the mailing list > (as previously discussed with Michael), so here we go.. I'm sure Michael has analyzed the problem, evaluated different options to solve the problem, and contacted the experts with the best solution he could find. However, since the identifier spaces in CoAP are so small and the unrestricted addition of new CoAP features can lead to fragmentation, every addition must be carefully considered. For that, it is really helpful to establish an understanding of the problem before pushing a particular solution. Klaus From nobody Sun Apr 9 13:00:56 2017 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 7EFC6127B52 for ; Sun, 9 Apr 2017 13:00:54 -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 ToTN8e0qZo1K for ; Sun, 9 Apr 2017 13:00:51 -0700 (PDT) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:c:538::200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0FD127BA3 for ; Sun, 9 Apr 2017 13:00:50 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by relay7-d.mail.gandi.net (Postfix) with ESMTPS id 39A4C1326; Sun, 9 Apr 2017 22:00:48 +0200 (CEST) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D1B96A80BE; Sun, 9 Apr 2017 22:00:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id a_9iXg88bn0J; Sun, 9 Apr 2017 22:00:46 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.10] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 6EA20A80C2; Sun, 9 Apr 2017 22:00:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Alexander Pelov In-Reply-To: Date: Sun, 9 Apr 2017 22:00:44 +0200 Cc: Core Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 20:00:54 -0000 Hi Klaus, > Le 9 avr. 2017 =C3=A0 16:54, Klaus Hartke a =C3=A9crit = : >=20 > Alexander Pelov wrote: >> IANA has received a request from Michael Koster to register two new = CoAP >> options: >> - Accept-Content-Format-Version >> - Content-Format-Version >=20 > Spec? >=20 >> One of the major questions that needs to be discussed is the = following: >=20 > What are the other questions? The other questions are mostly details that we can (easily) figure out = once the major one is answered. For example, should the = Accept-Content-Format-Version be Repeatable or Not? (I don=E2=80=99t = want to get to more details on this for the moment - and they will = surely come up if necessary). >=20 >> What are the reasons *NOT* to allocate a new Content-Format number = (RFC >> 7252) for each new version? (in the HTTP world, "version" is a simple >> parameter to the Content-Type, so why not treat it as such?) >=20 > None? >=20 >> The question is not trivial, as it touches upon content format = negotiation, >> e.g. how should the Server use the Accept-Content-Format-Version in = order >> to indicate that it is willing to accept both = application/vnd.ocf+cbor AND >> application/application/vnd.ocf+cbor;version=3D2.0, with a preference = for the >> latter? In the semantics of the version parameter, the two should be >> considered completely independent/incompatible types. >=20 > CoAP currently has no features for content format negotiation, only > for the selection of an available content format. If a server wishes > to indicate available content formats, it needs to do so in the > (hypermedia) representation. (The CoAP Accept option can only be used > in requests, not in responses.) >=20 > Are the two options a proposal to change that? >=20 > Need spec. Yes, you are right indeed. The *Client* indicates in its CoAP Accept = option the Content-Format it is willing to accept. Now, if you have the = same Content-Format, but with different versions, then you could imagine = having something like:=20 Accept: 10000 (which maps to application/application/vnd.ocf+cbor) Accept-Content-Format-Version: 2.0 Instead of: Accept: 10001 (application/application/vnd.ocf+cbor;version=3D2.0 which = would need to be registered to 10001 for example) The intent here is to always indicate "10000" in your hypermedia links, = and without changing them to be able to upgrade/downgrade the version of = the content-format (e.g. I like to think of this as changing APIs - you = upgrade a Client, and then it is on ver2 - but still using the original = Content-Format, but this may not be the only reason Michael proposes = these options).=20 >=20 >> The current way of doing this would be to allocate separate = Content-Format >> numbers to "application/application/vnd.ocf+cbor" (10000 as it stands = now) >> and "application/application/vnd.ocf+cbor;version=3D2.0" (e.g. = 10001).. and >> then use some form of content negotiation. >=20 > Yes. >=20 >> This however can have its disadvantages, .. and the way industry does = use >> versioning in some cases (e.g. people DO use the version parameter to >> version their RESTful APIs.. which means, that NOT having such = mechanism in >> CoAP could theoretically drive them to re-register blocks of = Content-Format >> numbers, just to differentiate between their APIs). >=20 > Working as intended. >=20 >> In any case, we need to have this discussion documented on the = mailing list >> (as previously discussed with Michael), so here we go.. >=20 > I'm sure Michael has analyzed the problem, evaluated different options > to solve the problem, and contacted the experts with the best solution > he could find. However, since the identifier spaces in CoAP are so > small and the unrestricted addition of new CoAP features can lead to > fragmentation, every addition must be carefully considered. For that, > it is really helpful to establish an understanding of the problem > before pushing a particular solution. I agree with you on this. Having this understanding - and documented on = the mailing list - is the intent of this discussion.=20 Alexander >=20 > Klaus >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Apr 9 14:24:26 2017 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 C501C1293FC; Sun, 9 Apr 2017 14:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 sJZ-ZfgyzHgm; Sun, 9 Apr 2017 14:24:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD04127A97; Sun, 9 Apr 2017 14:24:14 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 05AB129CC3C; Mon, 10 Apr 2017 06:24:12 +0900 (JST) Received: by mail-oi0-f47.google.com with SMTP id g204so56639005oib.1; Sun, 09 Apr 2017 14:24:11 -0700 (PDT) X-Gm-Message-State: AFeK/H2dD9jOkdWNRDjqiQIGTRG25G6qIOjQXAtG7c5+hoiOhdx4xfQlhLGz863SX3wjjH/k+OcdUQPSzgAjZw== X-Received: by 10.157.45.163 with SMTP id g32mr29278825otb.274.1491773050374; Sun, 09 Apr 2017 14:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Sun, 9 Apr 2017 14:24:09 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Sun, 9 Apr 2017 14:24:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Yoshifumi Nishida , tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=94eb2c04fb4ac0d40c054cc27a04 Archived-At: Subject: Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 21:24:17 -0000 --94eb2c04fb4ac0d40c054cc27a04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On Sun, Apr 9, 2017 at 12:25 AM, Carsten Bormann wrote: > Hi Yoshi, > > thank you very much for your thoughtful review. > > For now, let me pick one of your comments: > > > 3: Since this draft defines new SZX value, I think the doc needs to > update RFC7959. This point should be clarified more in the doc. > > The spec does indeed define a new SZX value, for use with the environment= s > this document is used in (reliable transports). It does not change or ad= d > anything to the way RFC 7959 is used with the existing unreliable > transports; as such it does not really update RFC 7959 as much as it does > extend it for its own purposes. > (However, the same argument could be made for RFC 7641, which we do say w= e > update.) > > Maybe we are not making the point forcefully enough that SZX=3D7 is meant > for use within this spec? > (Again, however: any other future COAP transports that have larger > messages might pick up SZX=3D7 as well.) > > I don=E2=80=99t have a strong opinion on how to populate the =E2=80=9Cupd= ates=E2=80=9D graph of > RFCs in these boundary cases; it might help to get some more guidance her= e. > Ok, I see the point. I don't have a strong opinion here either as I am not a COAP expert. It could be enough if the draft has more texts to articulate that it won't cause conflict with unreliable transport COAP. -- Yoshi --94eb2c04fb4ac0d40c054cc27a04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

On Sun, Apr 9, 2017 at 12:25 AM, Carsten Bormann <cabo@tzi.org= > wrote:
Hi Yoshi,

thank you very much for your thoughtful review.

For now, let me pick one of your comments:

> 3: Since this draft defines new SZX value, I think the doc needs to up= date RFC7959. This point should be clarified more in the doc.

The spec does indeed define a new SZX value, for use with the enviro= nments this document is used in (reliable transports).=C2=A0 It does not ch= ange or add anything to the way RFC 7959 is used with the existing unreliab= le transports; as such it does not really update RFC 7959 as much as it doe= s extend it for its own purposes.
(However, the same argument could be made for RFC 7641, which we do say we = update.)

Maybe we are not making the point forcefully enough that SZX=3D7 is meant f= or use within this spec?
(Again, however: any other future COAP transports that have larger messages= might pick up SZX=3D7 as well.)

I don=E2=80=99t have a strong opinion on how to populate the =E2=80=9Cupdat= es=E2=80=9D graph of RFCs in these boundary cases; it might help to get som= e more guidance here.

Ok, I see the poi= nt. I don't have a strong opinion here either as I am not a COAP expert= .=C2=A0
It could be enough if the draft has more texts to art= iculate that it won't cause conflict with unreliable transport COAP.=C2= =A0
--
Yoshi
--94eb2c04fb4ac0d40c054cc27a04-- From nobody Sun Apr 9 21:07:20 2017 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 8905A129415; Sun, 9 Apr 2017 21:07:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mark Nottingham To: Cc: draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Sun, 09 Apr 2017 21:07:04 -0700 Archived-At: Subject: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 04:07:05 -0000 Reviewer: Mark Nottingham Review result: Not Ready First, a general comment. I have been concerned about the duplication of effort that COAP represents for some time, and that concern grows significantly upon reading this draft. COAP is now specifying multiple "bindings" to underlying application and transport protocols, re-inventing message framing, congestion control in UDP, etc. The introduction justifies this development over the reuse of HTTP/2 (and presumably QUIC, once available) based upon the relative availability of implementations for constrained devices. Whether that remains true will only be judged by the market -- unfortunately after all of the cost of development and standardisation is sunk. The introduction motivates the layering of COAP over WebSockets to allow it to be used in a network that only allows external access through a HTTP proxy. In fact, it is not necessary to use WebSockets to do so; HTTP CONNECT provides a tunnel in this scenario. WebSockets is a specialised protocol that allows bidirectional, stream-based transport from a Web browser -- it is effectively TCP wrapped into the Web browser's security model, to make doing so safe. Using it for other purposes (i.e., non-browser use cases) isn't really appropriate. I'd suggest either removing the WebSockets binding, or changing its motivation in the Introduction. Section 7 defines a number of new URI schemes for COAP protocols. Syntactically, they use "+" to separate "coap" from the underlying transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This syntax is allowed by RFC3986, but is unprecedented, and implies a sub-syntax convention similar to those used in media types, etc. Is there an expectation that other URI schemes starting with "coap+" are reserved? Defining URI schemes that switch transport protocol based upon their name deserves wider review as well; this has been a contentious topic in the past, and it would be good to understand what tradeoffs are being made by doing so. Locking identifiers into a specific transport protocol sacrifices much of the power of URLs. Furthermore, creating "coap+ws" to denote a specific protocol over WebSockets (which has its own URI scheme) is questionable; taken to its natural conclusion, we'll have a proliferation of URI schemes for things over WebSockets. Will COAP take the same approach for HTTP? I would suggest a wider discussion of these issues on art@ / uri@. Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use. I'm not sure how to address this, other than removing the WebSockets binding. Section 8.1 makes it Mandatory to Implement the protocol without any security ("NoSec"). This seems counter to best practice in the IETF, but I'll defer to the Security Area review. From nobody Mon Apr 10 00:50:06 2017 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 7F2AF12945D for ; Mon, 10 Apr 2017 00:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HrUw9F8sF6o for ; Mon, 10 Apr 2017 00:50:00 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFB3129353 for ; Mon, 10 Apr 2017 00:49:59 -0700 (PDT) Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.52]) by imta23.fe.bosch.de (Postfix) with ESMTP id 33505158012E for ; Mon, 10 Apr 2017 09:49:57 +0200 (CEST) Received: from FE-MBX1028.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta12.fe.internet.bosch.com (Postfix) with ESMTP id D284B1B8049E for ; Mon, 10 Apr 2017 09:49:56 +0200 (CEST) Received: from FE-MBX1027.de.bosch.com (10.3.230.85) by FE-MBX1028.de.bosch.com (10.3.230.86) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 10 Apr 2017 09:49:56 +0200 Received: from FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af]) by FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af%16]) with mapi id 15.00.1236.000; Mon, 10 Apr 2017 09:49:56 +0200 From: "Kraus Achim (INST/ECS4)" To: "core@ietf.org" Thread-Topic: Details for CON notifies RFC7641/RFC7252 Thread-Index: AdKxyu2PPBnJhI45TSmVdI55Cbj5vg== Date: Mon, 10 Apr 2017 07:49:55 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.22.82.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22994.006 X-TMASE-MatchedRID: RVl0Uc7zi4ONE6O6CFKP4i1Hx9UxMGjdKVrLOZD1BXR5UICQcvBF40EI eI6apA+16DB7yJ7eUTPuO2g+BKOgYtnu+sxzz8XLLcLAlVGnzPohotH7bEpEMqXJ9vMysD/CrRG iaFY8lpCc9hMDYAMsrGeoPp4GT4bhLFyTPNlMtibidvCqqY53aQMDwjfX+DzgEFURwtwehWBf43 3d66LVIrmC22BNIiyiop1WCihmjjQe1C8SQ7ENMuliYDhFnxTfELbqrOgWzye6uRwP4AnzlCGnP icd8JCREVtxaPoSt7CMpYGkRSWMBrIYWtjSEqxqydRP56yRRA9LaooQW4IyHsUdvmUXV4MLo8WM kQWv6iUig6xaCvyzXY6HM5rqDwqt3UJEOpZLRdGuPaN32tCeIymbVsTZVpSNxXUZ4dzkmVj/NoC +wf7Miw== Archived-At: Subject: [core] Details for CON notifies RFC7641/RFC7252 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 07:50:05 -0000 Hello CORE, I have some questions according the intended message flow for an observe (R= FC7641) which uses CON notifies and the resource is changing while retransm= itting the notify and waiting for the ACK. I got aware that (at least one) = implementation just modifies the payload in that case leaving the MID an re= transmission time from the already pending notify. Sequence: CoAP client = CoAP server ---------- GET R, CON, MID 1, TOKEN ABCD, Observe 0 ---------= ---> <-------- 2.05, ACK, MID 1, TOKEN ABCD, Observe 10, "state 1" -----------= -- ... <-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------= (R changed from "state 1" to "state 2") <-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------= (retransmission, because ACK missing) ... <-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 14, "state 3" ------------= (R changed from "state 2" to "state 3") =20 ---------- ACK, MID 65 = ------------> So: Is it intended to (re-)use a MID with a modified message? (I personally wou= ld say, this is a NO GO!). Should the retransmission timing/counter from the first notify be continued= ? Should this continuing also prevent the second change to be send delayed wi= th the next retransmission?=20 Or should the second change simply wait until the first timeout all retrans= mission? There may be even different answers/intended usage, depending on the usage = of the CON notify: If it's used the test the liveliness of the observe or If it's used to ensure (in my opinion a pseudo) safe state transfer =20 =20 My personal favorite would be, just cancel the first CON notify and start a= new one with the updated payload immediately (new MID, new retransmission setup with reset counter and timeo= ut). Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus Bosch Software Innovations GmbH Communications (INST/ECS4) Stuttgarter Stra=DFe 130 71332 Waiblingen GERMANY www.bosch-si.de www.blog.bosch-si.com=20 Tel. +49 711 811-58139 achim.kraus@bosch-si.com Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB = 148411 B Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn From nobody Mon Apr 10 01:11:18 2017 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 1E9D6129423; Mon, 10 Apr 2017 01:11:17 -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 mrYMsqmB3TfA; Mon, 10 Apr 2017 01:11:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD643129447; Mon, 10 Apr 2017 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3A8BBhh005546; Mon, 10 Apr 2017 10:11:11 +0200 (CEST) Received: from client-0078.vpn.uni-bremen.de (client-0078.vpn.uni-bremen.de [134.102.107.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w1jYq2TbYzDHwP; Mon, 10 Apr 2017 10:11:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 10 Apr 2017 10:11:10 +0200 Cc: "core@ietf.org" , draft-ietf-lwig-coap@ietf.org X-Mao-Original-Outgoing-Id: 513504670.602463-eced4140d125161610907c2559e4b889 Content-Transfer-Encoding: quoted-printable Message-Id: <8FF83D7A-703E-4881-84F6-FFA7D3F7E360@tzi.org> References: To: "Kraus Achim (INST/ECS4)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Details for CON notifies RFC7641/RFC7252 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:11:17 -0000 Hi Achim, these questions are very good material for draft-ietf-lwig-coap, the = authors of which I CC. The main reference here is Section 4.5.2 of RFC 7641, especially the = guidance under "supersede an outstanding transmission=E2=80=9D. > Is it intended to (re-)use a MID with a modified message? (I = personally would say, this is a NO GO!). If the client already acknowledged the notification, but that ack got = lost, the notification with a changed payload might simply be ACKed by = the client in the deduplication mechanism. Also, we need a new MID to = be sure that the changed payload actually is being ACKed. RFC 7641 does not leave this open to speculation: 4. The new notification is transmitted with a new Message ID [=E2=80=A6= ] > Should the retransmission timing/counter from the first notify be = continued? It MAY be, but there is no SHOULD. > Should this continuing also prevent the second change to be send = delayed with the next retransmission?=20 > Or should the second change simply wait until the first timeout all = retransmission? If all retransmissions time out, the server does not know whether the = client is still there. Depending on how robust interest entries are = maintained, the server may give up completely on this interest (i.e., = cancel the observation, see 4.5), or it may retry a few times later = (robustness features are not specified in RFC 7641). > My personal favorite would be, just cancel the first CON notify and = start a new one with the updated payload > immediately (new MID, new retransmission setup with reset counter and = timeout). The problem with this is that this circumvents congestion control: Imagine a server that has a new value every 0.1 s. If the old = transmission is canceled each time there is a new value, the server now = sends packets at 10 Hz without any congestion control. Not good. So = the server has to slow down on lack of ACKs: Either by completing the = old transfer (with stale data), or by using the =E2=80=9Csuperseding=E2=80= =9D mechanism of Section 4.5.2. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 10 02:46:59 2017 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 760E412946D; Mon, 10 Apr 2017 02:46:50 -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 laIirY-Qwsht; Mon, 10 Apr 2017 02:46:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6762B129469; Mon, 10 Apr 2017 02:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3A9kf6R029982; Mon, 10 Apr 2017 11:46:41 +0200 (CEST) Received: from client-0078.vpn.uni-bremen.de (client-0078.vpn.uni-bremen.de [134.102.107.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w1lh10PjCzDJ1N; Mon, 10 Apr 2017 11:46:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Mon, 10 Apr 2017 11:46:40 +0200 Cc: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 513510400.415103-770b8e04c4ebcf4e77d1fedbfcf44f5f Content-Transfer-Encoding: quoted-printable Message-Id: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:46:50 -0000 Hi Mark, thank you for this thoughtful review. This message will focus on a few technical points; I=E2=80=99ll leave = aside the philosophical issues about whether the IETF should have a = constrained node stack. > WebSockets > is a specialised protocol that allows bidirectional, stream-based > transport from a Web browser -- it is effectively TCP wrapped into the > Web browser's security model, to make doing so safe. Indeed, that is the use case that was motivating this part. > Using it for > other purposes (i.e., non-browser use cases) isn't really appropriate. > I'd suggest either removing the WebSockets binding, or changing its > motivation in the Introduction. I agree that the introduction should focus on the Browser use case and = keep out of the firewall traversal jungle. > Section 7 defines a number of new URI schemes for COAP protocols. > Syntactically, they use "+" to separate "coap" from the underlying > transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This > syntax is allowed by RFC3986, but is unprecedented, and implies a > sub-syntax convention similar to those used in media types, etc. Is > there an expectation that other URI schemes starting with "coap+" are > reserved?=20 There is no such expectation. We did have the discussion about reserved URI scheme prefixes in the = IETF, and as I recall, the result was that there are none. While it = would be a bit weird to register a URI scheme starting with coap+ or = coaps+ that is unrelated to CoAP, only the slightly boggled response = from an expert review is in the way of that happening. Would the scheme names be more palatable with a dash instead of a plus? Careful choice of the scheme name mostly benefits the implementer, so it = can be changed in the spec (at the cost of changing existing = implementations). > Defining URI schemes that switch transport protocol based upon their > name deserves wider review as well; this has been a contentious topic > in the past, and it would be good to understand what tradeoffs are > being made by doing so. Locking identifiers into a specific transport > protocol sacrifices much of the power of URLs. The =E2=80=9Csiloing=E2=80=9D of URIs along schemes is indeed a problem, = which started for CoAP with the separation of the coap:/coaps: name = spaces. The CoRE WG did not see it as its task to address this = shortcoming. So, for now, we=E2=80=99ll have to live with it; = approaches such as draft-silverajan-core-coap-protocol-negotiation are = trying to address its practicalities. > Furthermore, creating > "coap+ws" to denote a specific protocol over WebSockets (which has its > own URI scheme) is questionable; taken to its natural conclusion, > we'll have a proliferation of URI schemes for things over WebSockets. I=E2=80=99m not sure that a proliferation will happen =E2=80=94 = WebSockets is mostly used for tightly bound proprietary protocols = between a JavaScript mobile code client and a server that provides this = mobile code client. On the other hand, deciding to never use URIs to = refer to resources available over a WebSockets protocol strikes me as an = unnecessary restriction. > Will COAP take the same approach for HTTP? Not sure what this question is leading into. (We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075. But maybe this is about something different.) > I would suggest a wider discussion of these issues on art@ / uri@. Indeed, a wider discussion of these longstanding issues would be useful. I=E2=80=99m not sure that waiting for their resolution is blocking this = spec. > Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" > URI, using a well-known URI in the "wss" scheme. However, "wss" is not > defined to use well-known URIs, so this is an invalid use.=20 This incorrect use of RFC 5785 is indeed embarrassing. More about that = later. > Section 8.1 makes it Mandatory to Implement the protocol without any > security ("NoSec"). This seems counter to best practice in the IETF, > but I'll defer to the Security Area review. Since it is the implementers who will decide whether they implement = this, this co-author could live with making implementing NoSec = completely optional. (It will be anyway, in practice, at the level of = what is actually configured.) The important point(*) from the WG = perspective here is that TLS is mandatory to implement, with the = specifics depending on the security mode needed (cf. RFC 7925). (Note = also that there are other ways to provide security with CoAP.) Gr=C3=BC=C3=9Fe, Carsten (*) = https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e935424= 2012afb28dc60 From nobody Mon Apr 10 02:53:19 2017 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 18F8712946B for ; Mon, 10 Apr 2017 02:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwzl2-hA2YYI for ; Mon, 10 Apr 2017 02:53:16 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052C412441E for ; Mon, 10 Apr 2017 02:53:15 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud2.xs4all.net with ESMTP id 6ZtC1v00b1ThUbc01ZtCMc; Mon, 10 Apr 2017 11:53:14 +0200 Received: from 2001:983:a264:1:c533:52bc:b92:e25f by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 10 Apr 2017 11:53:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 10 Apr 2017 11:53:12 +0200 From: peter van der Stok To: Michael Koster Cc: Kerry Lynn , peter van der Stok , Carsten Bormann , Zach Shelby , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , =?UTF-8?Q?Christian_Ams=C3=BCss?= , core , draft-ietf-core-resource-directory@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <2B5F5BA0-875A-4941-BB27-7764DB19A942@smartthings.com> References: <2B5F5BA0-875A-4941-BB27-7764DB19A942@smartthings.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Continuing the Resource Directory and DNS-SD discussion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:53:18 -0000 Thanks Michael, Given the minutes of DNS RD Friday telco, I do have some concrete questions (and opinions). Your discussion below is an excellent fulcrum. Michael Koster schreef op 2017-04-07 17:03: > The last discussion as I recall from the CoRE meeting was around 3 > points: > > 1. Using DNS-SD to find a resource directory > > 2. Providing "ins" and "exp" link attributes > > 3. Specifying DNS-SD mapping to links in the RD document > > We have already decided for points 1 and 2 within the scope of the RD > document. We are discussing whether the DNS-SD mapping should be > published in the RD document. Are adding points 1 and 2 to RD confirmed? What is the outcome on point 3? > > At IETF 98 we had two discussions.. > > - DNS-SD is not required to use RD. It would not be helpful to couple > RD and DNS-SD unnecessarily by creating intra-document dependencies. I don't understand; You will need a reference from RD to DNS and DNS-SD anyway A link from DNS-SD to RD may be profitable, if Stuart sees a place for RD in the context of its future Thread developments. > - A good use scenario and introductory explanation is needed, > describing the relationship of RD to DNS-SD, which may be better > served in its own document. That also applies to RD in its present state; why does RD exist, given we have DNS. > - Additional constraints on the use of RD are needed to facilitate the > mapping, such as limiting the length of identifiers, requiring the > presense of the "rt" attribute, requiring the use of "ins" and "exp". > What is mandatory in RD? If ins and exp are added to RD, then these constraints belong there IMO. > - The rd-dns-sd draft can refer to RD normatively and publish in the > same time frame, since the 2 documents will both be working group > adopted and have good support. The RD document will not need to refer > to the RD-DNS-SD document normatively. I agree, what did the friday discussion conclude? > > What is DNS-SD mapping and how does it work? What are the use cases > and what assumptions do they drive? > > The big bit seems to be service discovery vs. resource discovery I prefer fine grained versus coarse grained. > > The use case for DNS-SD is service discovery across broad network > scope, including mesh and bridged/routed networks. > > The use case for RD is fine grain resource discovery using hyperlinks, > as part of a REST client-server state machine. Clearly these are > mostly complementary use cases, and it is easy to build service > discovery on top of REST. Resource Directories are themselves REST > servers and can respond to multicast discovery queries, but have no > well defined discovery proxy for routed and bridged networks. Once the > RD address is known, it can participate in REST interactions through > unicast transactions. I don't understand the paragraph above. That's all a bit too fast for me. What I took back with me from this discussion: We need to explain that RD transports less data than DNSSD for the same information content, and we need to explain that filtering in RD takes little code space and processor time. > > The use case for RD to DNS-SD mapping is in making DNS-SD services > discoverable as RD registered endpoints and links, and to make RD > registered endpoints and links discoverable as DNS-SD services. I understand the second but not the first. > > Based on this, a system could bootstrap resource discovery by > advertizing the resource directory location(s) usind DNS-SD and the > link mapping to RD services; e.g. links with > "rt=core.rd;rt=core.rd-lookup-res;core.rd-lookup-ep" etc. would be > registered in an RD and exported to DNS-SD. So far, so good. Other RD services in the > network would expose links to the RD services that were discovered > over DNS-SD. In this way, all of the RD services that are only > reachable using unicast could be discovered in "local" RD services. > DNS-SD would be used to keep all of the RD service locations > discoverable through RD on local network scope. And here I am lost. > > A number of assumptions and requirements for the mapping: > > Links registered in RD for export to DNS-SD use the "rt" link > attribute for translation to DNS service type name and transmitted as > a SRV record. Is that so? > > Link context, consisting of scheme+authority+port, will be translated > to a DNS service location and transmitted as a PTR record. Sounds correct and doable in an automatic fashion > > The remaining information in the link, or perhaps the entire link, > will be transmitted in DNS-SD as a TXT record. needs some discussion, but doable. > > Based on these discussion, I am recommending that the DNS-SD mapping > to RD links be taken up in a separate document, to normatively refer > to the RD document, and be published in the same time frame in order > to enable systems to use both RD and DNS-SD together. What did you conclude on Friday? I am glad this discussion gets the attention it deserves. I hope there is enough energy to bring it to a conclusion (RFC) Cheerio, Peter From nobody Mon Apr 10 04:05:40 2017 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 57410126DCA; Mon, 10 Apr 2017 04:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tjt87QDvDpM; Mon, 10 Apr 2017 04:05:35 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC04F129478; Mon, 10 Apr 2017 04:05:34 -0700 (PDT) Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta23.fe.bosch.de (Postfix) with ESMTP id BEE7815800F1; Mon, 10 Apr 2017 13:05:32 +0200 (CEST) Received: from SI-MBX1027.de.bosch.com (vsgw22.fe.internet.bosch.com [10.4.98.11]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id 966702E4021A; Mon, 10 Apr 2017 13:05:32 +0200 (CEST) Received: from FE-MBX1027.de.bosch.com (10.3.230.85) by SI-MBX1027.de.bosch.com (10.3.230.41) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 10 Apr 2017 13:05:32 +0200 Received: from FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af]) by FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af%16]) with mapi id 15.00.1236.000; Mon, 10 Apr 2017 13:05:32 +0200 From: "Kraus Achim (INST/ECS4)" To: Carsten Bormann CC: "core@ietf.org" , "draft-ietf-lwig-coap@ietf.org" Thread-Topic: [core] Details for CON notifies RFC7641/RFC7252 Thread-Index: AdKxyu2PPBnJhI45TSmVdI55Cbj5vv//7KMA//+wZYA= Date: Mon, 10 Apr 2017 11:05:32 +0000 Message-ID: References: <8FF83D7A-703E-4881-84F6-FFA7D3F7E360@tzi.org> In-Reply-To: <8FF83D7A-703E-4881-84F6-FFA7D3F7E360@tzi.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.22.82.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22994.006 X-TMASE-MatchedRID: 9haqLjVvoMiI0KPyMNrNUjOb4QjG+dWPC3HuWcgyQCaQcp7izK6RGP1j R8qIf+9CFp1/6tEDSIA9u+0E5F6z2dyZCHE3tkuL1poecQqOJjApxoenBUOrIWPK/53RnQ7Fy7C 7zqfGkIrK3wrMWIVJeXJhwFAvdW79YmchNlDsuBzJ1E/nrJFED0tqihBbgjIemPWRVCa5M9Lo44 LYGf+D39TXuaaTLXeJq+YMnSQhfwQqEGY+7PF6K0NdLGoEdvhB0BciT9B07b6dI/DikZ1UPIsaZ 7etKDBkT/dBt9e2zw9QLYg6E04dN+4dcT3ZaTocGQlUVP2iPcz64i5lgawyBBKCZ+Q6yB8qUU5i dY48HIfcMih1MgHl6R0iQRuoRS0LqzpKVAbKqd9IRA38P/dwbiGi0ftsSkQypcn28zKwP8IkO11 kEvGSAK/IDUO7Iw0dkXSJzFJzhLx8xqXGIUw3Stjko+KiQPUGK7VOL9908cEYvUUv9u3VjdT77d Ysv2ne95WRO22VEx8y2ii2lrm+D0L9tcyTZdAsgxsfzkNRlfLdB/CxWTRRu25FeHtsUoHut3L7S fxKTvaiNTHw4vB0WmZtw+WyGnitR3TPFtGvHg4+kK598Yf3Mg== Archived-At: Subject: Re: [core] Details for CON notifies RFC7641/RFC7252 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:05:38 -0000 SGkgQ2Fyc3RlbiwNCg0KVGhhbmtzIGZvciB5b3VyIGZhc3QgYW5zd2VyIQ0KDQpZb3VyIHBlcmZl Y3RseSByaWdodCwgdGhhdCBSRkM3NjQxLCA0LjUuMiBzcGVjaWZpZXMgdGhlIGJlaGF2aW9yIGZv ciB0aGUgc2NlbmFyaW8uICANCg0KQW5kIGdvb2QgdG8ga25vdywgdGhhdCBkcmFmdC1pZXRmLWx3 aWctY29hcCBpcyBhbGl2ZSwgYmVjYXVzZSB3aGVuIEkgbG9va2VkIGF0IGl0DQpvbiBKYW51YXJ5 IGl0IHNlZW1zIHRvIG1lIHRvIGJlIG5vIGxvbmdlciBhbGl2ZS4NCg0KTWl0IGZyZXVuZGxpY2hl biBHcsO8w59lbiAvIEJlc3QgcmVnYXJkcw0KDQpBY2hpbSBLcmF1cw0KDQpCb3NjaCBTb2Z0d2Fy ZSBJbm5vdmF0aW9ucyBHbWJIDQpDb21tdW5pY2F0aW9ucyAoSU5TVC9FQ1M0KQ0KU3R1dHRnYXJ0 ZXIgU3RyYcOfZSAxMzANCjcxMzMyIFdhaWJsaW5nZW4NCkdFUk1BTlkNCnd3dy5ib3NjaC1zaS5k ZQ0Kd3d3LmJsb2cuYm9zY2gtc2kuY29tIA0KDQpSZWdpc3RlcmVkIG9mZmljZTogQmVybGluLCBS ZWdpc3RlciBjb3VydDogQW10c2dlcmljaHQgQ2hhcmxvdHRlbmJ1cmcsIEhSQiAxNDg0MTEgQg0K RXhlY3V0aXZlczogRHIuLUluZy4gUmFpbmVyIEthbGxlbmJhY2g7IE1pY2hhZWwgSGFobg0KDQoN Cg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBDYXJzdGVuIEJvcm1h bm4gW21haWx0bzpjYWJvQHR6aS5vcmddIA0KR2VzZW5kZXQ6IE1vbnRhZywgMTAuIEFwcmlsIDIw MTcgMTA6MTENCkFuOiBLcmF1cyBBY2hpbSAoSU5TVC9FQ1M0KSA8QWNoaW0uS3JhdXNAYm9zY2gt c2kuY29tPg0KQ2M6IGNvcmVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbHdpZy1jb2FwQGlldGYub3Jn DQpCZXRyZWZmOiBSZTogW2NvcmVdIERldGFpbHMgZm9yIENPTiBub3RpZmllcyBSRkM3NjQxL1JG QzcyNTINCg0KSGkgQWNoaW0sDQoNCnRoZXNlIHF1ZXN0aW9ucyBhcmUgdmVyeSBnb29kIG1hdGVy aWFsIGZvciBkcmFmdC1pZXRmLWx3aWctY29hcCwgdGhlIGF1dGhvcnMgb2Ygd2hpY2ggSSBDQy4N Cg0KVGhlIG1haW4gcmVmZXJlbmNlIGhlcmUgaXMgU2VjdGlvbiA0LjUuMiBvZiBSRkMgNzY0MSwg ZXNwZWNpYWxseSB0aGUgZ3VpZGFuY2UgdW5kZXIgInN1cGVyc2VkZSBhbiBvdXRzdGFuZGluZyB0 cmFuc21pc3Npb27igJ0uDQoNCj4gSXMgaXQgaW50ZW5kZWQgdG8gKHJlLSl1c2UgYSBNSUQgd2l0 aCBhIG1vZGlmaWVkIG1lc3NhZ2U/IChJIHBlcnNvbmFsbHkgd291bGQgc2F5LCB0aGlzIGlzIGEg Tk8gR08hKS4NCg0KSWYgdGhlIGNsaWVudCBhbHJlYWR5IGFja25vd2xlZGdlZCB0aGUgbm90aWZp Y2F0aW9uLCBidXQgdGhhdCBhY2sgZ290IGxvc3QsIHRoZSBub3RpZmljYXRpb24gd2l0aCBhIGNo YW5nZWQgcGF5bG9hZCBtaWdodCBzaW1wbHkgYmUgQUNLZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUg ZGVkdXBsaWNhdGlvbiBtZWNoYW5pc20uICBBbHNvLCB3ZSBuZWVkIGEgbmV3IE1JRCB0byBiZSBz dXJlIHRoYXQgdGhlIGNoYW5nZWQgcGF5bG9hZCBhY3R1YWxseSBpcyBiZWluZyBBQ0tlZC4NCg0K UkZDIDc2NDEgZG9lcyBub3QgbGVhdmUgdGhpcyBvcGVuIHRvIHNwZWN1bGF0aW9uOg0KDQogICA0 LiAgVGhlIG5ldyBub3RpZmljYXRpb24gaXMgdHJhbnNtaXR0ZWQgd2l0aCBhIG5ldyBNZXNzYWdl IElEIFvigKZdDQoNCj4gU2hvdWxkIHRoZSByZXRyYW5zbWlzc2lvbiB0aW1pbmcvY291bnRlciBm cm9tIHRoZSBmaXJzdCBub3RpZnkgYmUgY29udGludWVkPw0KDQpJdCBNQVkgYmUsIGJ1dCB0aGVy ZSBpcyBubyBTSE9VTEQuDQoNCj4gU2hvdWxkIHRoaXMgY29udGludWluZyBhbHNvIHByZXZlbnQg dGhlIHNlY29uZCBjaGFuZ2UgdG8gYmUgc2VuZCBkZWxheWVkIHdpdGggdGhlIG5leHQgcmV0cmFu c21pc3Npb24/IA0KPiBPciBzaG91bGQgdGhlIHNlY29uZCBjaGFuZ2Ugc2ltcGx5IHdhaXQgdW50 aWwgdGhlIGZpcnN0IHRpbWVvdXQgYWxsIHJldHJhbnNtaXNzaW9uPw0KDQpJZiBhbGwgcmV0cmFu c21pc3Npb25zIHRpbWUgb3V0LCB0aGUgc2VydmVyIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGUg Y2xpZW50IGlzIHN0aWxsIHRoZXJlLiAgRGVwZW5kaW5nIG9uIGhvdyByb2J1c3QgaW50ZXJlc3Qg ZW50cmllcyBhcmUgbWFpbnRhaW5lZCwgdGhlIHNlcnZlciBtYXkgZ2l2ZSB1cCBjb21wbGV0ZWx5 IG9uIHRoaXMgaW50ZXJlc3QgKGkuZS4sIGNhbmNlbCB0aGUgb2JzZXJ2YXRpb24sIHNlZSA0LjUp LCBvciBpdCBtYXkgcmV0cnkgYSBmZXcgdGltZXMgbGF0ZXIgKHJvYnVzdG5lc3MgZmVhdHVyZXMg YXJlIG5vdCBzcGVjaWZpZWQgaW4gUkZDIDc2NDEpLg0KDQo+IE15IHBlcnNvbmFsIGZhdm9yaXRl IHdvdWxkIGJlLCBqdXN0IGNhbmNlbCB0aGUgZmlyc3QgQ09OIG5vdGlmeSBhbmQgDQo+IHN0YXJ0 IGEgbmV3IG9uZSB3aXRoIHRoZSB1cGRhdGVkIHBheWxvYWQgaW1tZWRpYXRlbHkgKG5ldyBNSUQs IG5ldyByZXRyYW5zbWlzc2lvbiBzZXR1cCB3aXRoIHJlc2V0IGNvdW50ZXIgYW5kIHRpbWVvdXQp Lg0KDQpUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCB0aGlzIGNpcmN1bXZlbnRzIGNvbmdl c3Rpb24gY29udHJvbDoNCg0KSW1hZ2luZSBhIHNlcnZlciB0aGF0IGhhcyBhIG5ldyB2YWx1ZSBl dmVyeSAwLjEgcy4gIElmIHRoZSBvbGQgdHJhbnNtaXNzaW9uIGlzIGNhbmNlbGVkIGVhY2ggdGlt ZSB0aGVyZSBpcyBhIG5ldyB2YWx1ZSwgdGhlIHNlcnZlciBub3cgc2VuZHMgcGFja2V0cyBhdCAx MCBIeiB3aXRob3V0IGFueSBjb25nZXN0aW9uIGNvbnRyb2wuICBOb3QgZ29vZC4gIFNvIHRoZSBz ZXJ2ZXIgaGFzIHRvIHNsb3cgZG93biBvbiBsYWNrIG9mIEFDS3M6IEVpdGhlciBieSBjb21wbGV0 aW5nIHRoZSBvbGQgdHJhbnNmZXIgKHdpdGggc3RhbGUgZGF0YSksIG9yIGJ5IHVzaW5nIHRoZSDi gJxzdXBlcnNlZGluZ+KAnSBtZWNoYW5pc20gb2YgU2VjdGlvbiA0LjUuMi4NCg0KR3LDvMOfZSwg Q2Fyc3Rlbg0KDQo= From nobody Mon Apr 10 04:51:39 2017 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 97A14129497; Mon, 10 Apr 2017 04:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApScIIDLYzfA; Mon, 10 Apr 2017 04:51:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2691294A3; Mon, 10 Apr 2017 04:51:24 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-82-58eb71b9f7c2 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 6C.80.27378.9B17BE85; Mon, 10 Apr 2017 13:51:22 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.339.0; Mon, 10 Apr 2017 13:51:21 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id E637D4EB0B; Mon, 10 Apr 2017 14:53:52 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 8606D4E94F; Mon, 10 Apr 2017 14:53:52 +0300 (EEST) To: Core , <6tisch@ietf.org> From: Mohit Sethi Message-ID: Date: Mon, 10 Apr 2017 14:51:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------491536ABE7E172A49B56C33C" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2J7uO6uwtcRBifuqFssu9vHbLHv7Xpm ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlLGpdzFIwXaziTeda9gbGPYJdjBwcEgImEvv3h3Ux cnEICaxnlFiy9DYjhLODUeLiqVPMEM4mRomD57+xQjgLGSXefVjG1sXIySEioC1xb+ZJRhCb TUBPovPccWYQW1hAV2LL3152EJtXwF7ix75/TCA2i4CqxOpNW8HiogIREg87d0HVCEqcnPmE BcRmFgiTWLPmP9gcCQE1iavnNoHZQgLqEls7DjBOYOSfhaRlFpIWCNtCYub884wQtrbEsoWv oeIaEq1z5rJD2PISzVtnMy9gZFvFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERjAB7f8Vt3B ePmN4yFGAQ5GJR7eB+teRQixJpYVV+YeYpTgYFYS4e1aARTiTUmsrEotyo8vKs1JLT7EKM3B oiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBMZvzpkqZhsQBppKPEawLD+y+YsDllqzd8GXv rklzzD4EJ30uXtTCUfo5/XR6714W5mPrNwSdfZ3XFs985NhmPqle3sOBLUtnTEpkadZLqjZe /sTJ7q75lFP6x5M3cj86xLCuZYvqru7mqS/nzy+Nb9MSmxT5KP6Vi7MFp29F4L8mtyIGr0fP lFiKMxINtZiLihMBbkJd91wCAAA= Archived-At: Subject: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:51:32 -0000 --------------491536ABE7E172A49B56C33C Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi OSCoAP authors I was trying to read the OSCoAP and 6tisch minimal security drafts. I=20 have a question about the AEAD nonce uniqueness. RFC 5116 says that: When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices So my obvious question is how is the AEAD nonce uniqueness ensured. The=20 PSK is known to at least two parties (more in case of some uses such as=20 multicast OSCoAP=20 https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)?? The draft currently says that AEAD Nonce uniqueness is ensured with=20 sequence numbers and sender context which is essentially the sender ID.=20 But how do you ensure that the two parties have different sender ID.=20 Especially since sender ID is not fixed length. I guess there will be=20 other problems in case of sender ID collisions? --Mohit --------------491536ABE7E172A49B56C33C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi OSCoAP authors

I was trying to read the OSCoAP and 6tisch minimal security drafts. I have a question about the AEAD nonce uniqueness. RFC 5116 says that:

   When there are multiple devices performing encryption using a single
   key, those devices must coordinate to ensure that the nonces are
   unique.  A simple way to do this is to use a nonce format that
   contains a field that is distinct for each one of the devices

So my obvious question is how is the AEAD nonce uniqueness ensured. The PSK is known to at least two parties (more in case of some uses such as multicast OSCoAP https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)??

The draft currently says that AEAD Nonce uniqueness is ensured with sequence numbers and sender context which is essentially the sender ID. But how do you ensure that the two parties have different sender ID. Especially since sender ID is not fixed length. I guess there will be other problems in case of sender ID collisions?

--Mohit


--------------491536ABE7E172A49B56C33C-- From nobody Mon Apr 10 05:07:40 2017 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 BD09B1294A0; Mon, 10 Apr 2017 05:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pPnS9ENshmpd; Mon, 10 Apr 2017 05:07:30 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B456A129488; Mon, 10 Apr 2017 05:07: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 2CBDE46B38; Mon, 10 Apr 2017 14:07:23 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 32D5F2A; Mon, 10 Apr 2017 14:07:22 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 01C033BE; Mon, 10 Apr 2017 14:07:21 +0200 (CEST) Received: (nullmailer pid 28884 invoked by uid 1000); Mon, 10 Apr 2017 12:07:21 -0000 Date: Mon, 10 Apr 2017 14:07:21 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Mohit Sethi Cc: Core , 6tisch@ietf.org Message-ID: <20170410120721.tbtkylim7ledbuo2@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5fd6mhalikpysxqq" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 12:07:33 -0000 --5fd6mhalikpysxqq Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Mohit, On Mon, Apr 10, 2017 at 02:51:20PM +0300, Mohit Sethi wrote: > The draft currently says that AEAD Nonce uniqueness is ensured with seque= nce > numbers and sender context which is essentially the sender ID. But how do > you ensure that the two parties have different sender ID. as Sender IDs are currently used, they are mutually agreed-upon like the rest of the security context (key, algorithm etc); in other words, they are explicitly given to a device by the mechanism that also distributes the key. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --5fd6mhalikpysxqq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljrdXUACgkQOY0REtOk veF8Fw/9FdWmetqeN3EsQma8zM+RHUbKdRP8u4hCTcJ4InoeHeOjrYm9L3haf7ut uuyx9eWmsBmPziNe1HXL4vgdMEmU6IjxWGUkH06OChu85EmtHZN4pcWC0ETxnvR0 Q6IiSODFxmuVDyoiCzQubhrFAmOQlgJf0b45Z1sPY/1ABgo0iOeLx2kA7HwkzxQ8 +KWejbOmcx+xYlLZ8kZmbp0FsPOGJBYmjhKLz0Gp7vsfSxkfDlF/7aQG1E3dp73q tIntUYxmFDyciWAJwHhTLYybe4YBMxUtclGlPvtUH5c4kU5W+D7tIW2UIhzlYmPo fM2aerME/GSxmiinhUl6EVSgvIkZt1I2eSovMS4znWH4g5Eu5cCYpcxMBOWv3tpF D9wSwN3OMWQd5RxH3opSQ6i75bkrneyzUQBIphZ714pDeX4HN8VV+pJLsRTtlVwI KlbzK910jw4tuk4j2gq47RaZhDr8cLCwAXjaFidTA2jC8bA+THpJIYN70p0qgX2/ O09UFaq6qsim+Z6apfuagCw2su8g1I+OL2DwP1qEcPIDTlpN0668udgGaq6cHHwb IwOuSxdBEwxxlpaEpFLeVTPadDpbtJeQGm8auDtlTqEj5NMqZXO/EPnoM0GnkBsn rR9hT3lmC5jsexAG9q3VulCEEu60Y9bDnmIZqr6+1o3h1BQHJOg= =nfPB -----END PGP SIGNATURE----- --5fd6mhalikpysxqq-- From nobody Mon Apr 10 10:09:54 2017 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 A3570129510; Mon, 10 Apr 2017 10:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 KyEdJjv0rDoC; Mon, 10 Apr 2017 10:09:50 -0700 (PDT) Received: from mail4.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 7C595127A91; Mon, 10 Apr 2017 10:09:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01D2B1E2.93977E70" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491844186; h=from:subject:to:date:message-id; bh=ztgYpHueWVjMio4h07v+ASNpQ7P6fhWnN9/tPjp0kqs=; b=C56nusbOyKXpbP8piJTaiHYanE0jJKFCvq4at8OjWxLsz8Gv9wIN3eG/9AWUHBXZjSKr6Fn0nJC 58Ep9rm7wk+6D8LDHKoUS9Buq7bbipKmGGWqqoo8uKSziyAnCjxGU9IsonnTyb65LJKpDG/4JzNJv c+jcfJPIHFp9KiLn2QjuvDLc5S+268N9Osjcdk8kBWqpF3GdMvFWENOysxL3S9wxyPLlVGDCAt7cn 1pHVl/NNyVxFBvD2LtxCyGKPy6/IZ8BDFvReHnRz2SSe5KFq8nv1BGbo1s+VnKUaqkAnYLLxgcuBY lAgX7LwfZRwEtNiQawnMwRjkRxYGFHvgGa/w== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 10:09:45 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 10:09:43 -0700 From: Jim Schaad To: 'Mohit Sethi' , 'Core' , <6tisch@ietf.org> References: In-Reply-To: Date: Mon, 10 Apr 2017 10:09:41 -0700 Message-ID: <002101d2b21d$3ff5ba30$bfe12e90$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJv4xR+uLYuNuXVlU8kA8osT/0S9aCEc6vw X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:09:52 -0000 ------=_NextPart_000_0022_01D2B1E2.93977E70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is not a problem with dealing with nonce uniqueness in this draft = because each entity is going to be assigned to a unique key for = transmissions. The transport key is derived from the PSK and the sender = ID. Sender IDs will be unique based on the enrollment protocol in the = group as each entity will have a unique identifier. =20 Jim =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Mohit Sethi Sent: Monday, April 10, 2017 4:51 AM To: Core ; 6tisch@ietf.org Subject: [core] Question about AEAD nonce uniqueness =20 Hi OSCoAP authors I was trying to read the OSCoAP and 6tisch minimal security drafts. I = have a question about the AEAD nonce uniqueness. RFC 5116 says that: When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices So my obvious question is how is the AEAD nonce uniqueness ensured. The = PSK is known to at least two parties (more in case of some uses such as = multicast OSCoAP = https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)??=20 The draft currently says that AEAD Nonce uniqueness is ensured with = sequence numbers and sender context which is essentially the sender ID. = But how do you ensure that the two parties have different sender ID. = Especially since sender ID is not fixed length. I guess there will be = other problems in case of sender ID collisions?=20 --Mohit =20 ------=_NextPart_000_0022_01D2B1E2.93977E70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There is not a problem with dealing with nonce uniqueness in this = draft because each entity is going to be assigned to a unique key for = transmissions.=C2=A0 The transport key is derived from the PSK and the = sender ID.=C2=A0 Sender IDs will be unique based on the enrollment = protocol in the group as each entity will have a unique = identifier.

 

Jim

 

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Mohit = Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core = <core@ietf.org>; 6tisch@ietf.org
Subject: [core] = Question about AEAD nonce uniqueness

 

Hi OSCoAP = authors

I was trying to read the OSCoAP and 6tisch = minimal security drafts. I have a question about the AEAD nonce = uniqueness. RFC 5116 says that:

=C2=A0=C2=A0 When =
there are multiple devices performing encryption using a =
single
=C2=A0=C2=A0 key, those devices must =
coordinate to ensure that the nonces =
are
=C2=A0=C2=A0 unique.=C2=A0 A simple way to do =
this is to use a nonce format that
=C2=A0=C2=A0 =
contains a field that is distinct for each one of the =
devices

So my obvious question is how is the AEAD = nonce uniqueness ensured. The PSK is known to at least two parties (more = in case of some uses such as multicast OSCoAP https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)?= ?

The draft currently says that AEAD Nonce uniqueness = is ensured with sequence numbers and sender context which is essentially = the sender ID. But how do you ensure that the two parties have different = sender ID. Especially since sender ID is not fixed length. I guess there = will be other problems in case of sender ID collisions? =

--Mohit

 

------=_NextPart_000_0022_01D2B1E2.93977E70-- From nobody Mon Apr 10 17:39:34 2017 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 37EC91293F8; Mon, 10 Apr 2017 17:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 u01rQ2Qe3umb; Mon, 10 Apr 2017 17:39:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 0CB501294C4; Mon, 10 Apr 2017 17:39:24 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2753B22E253; Mon, 10 Apr 2017 20:39:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> Date: Tue, 11 Apr 2017 10:39:18 +1000 Cc: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 00:39:27 -0000 Hi Carsten, Couple of quic responses below. On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: > I agree that the introduction should focus on the Browser use case and = keep out of the firewall traversal jungle. OK. Just curious -- is there a strong motivation here? It seems very odd = to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over = WebSockets over HTTP again, rather than just using HTTP (which AIUI you = already have a mapping to). >> Section 7 defines a number of new URI schemes for COAP protocols. >> Syntactically, they use "+" to separate "coap" from the underlying >> transport(-ish) protocol that they're bound to; e.g., "coap+tcp". = This >> syntax is allowed by RFC3986, but is unprecedented, and implies a >> sub-syntax convention similar to those used in media types, etc. Is >> there an expectation that other URI schemes starting with "coap+" are >> reserved?=20 >=20 > There is no such expectation. >=20 > We did have the discussion about reserved URI scheme prefixes in the = IETF, and as I recall, the result was that there are none. While it = would be a bit weird to register a URI scheme starting with coap+ or = coaps+ that is unrelated to CoAP, only the slightly boggled response = from an expert review is in the way of that happening. >=20 > Would the scheme names be more palatable with a dash instead of a = plus? > Careful choice of the scheme name mostly benefits the implementer, so = it can be changed in the spec (at the cost of changing existing = implementations). OK. I'm mostly noting this in case other folks feel that this is a bad = precedent for URI schemes; I think the bigger concern is the one below. >> Defining URI schemes that switch transport protocol based upon their >> name deserves wider review as well; this has been a contentious topic >> in the past, and it would be good to understand what tradeoffs are >> being made by doing so. Locking identifiers into a specific transport >> protocol sacrifices much of the power of URLs. >=20 > The =E2=80=9Csiloing=E2=80=9D of URIs along schemes is indeed a = problem, which started for CoAP with the separation of the coap:/coaps: = name spaces. The CoRE WG did not see it as its task to address this = shortcoming. So, for now, we=E2=80=99ll have to live with it; = approaches such as draft-silverajan-core-coap-protocol-negotiation are = trying to address its practicalities. By defining multiple URI schemes for different transports of the same = protocol, the WG has taken a position as to what the solution is. I'm = finding it difficult to square this with the continuing characterisation = of CORE as "RESTful". >> Furthermore, creating >> "coap+ws" to denote a specific protocol over WebSockets (which has = its >> own URI scheme) is questionable; taken to its natural conclusion, >> we'll have a proliferation of URI schemes for things over WebSockets. >=20 > I=E2=80=99m not sure that a proliferation will happen =E2=80=94 = WebSockets is mostly used for tightly bound proprietary protocols = between a JavaScript mobile code client and a server that provides this = mobile code client. On the other hand, deciding to never use URIs to = refer to resources available over a WebSockets protocol strikes me as an = unnecessary restriction. >=20 >> Will COAP take the same approach for HTTP? >=20 > Not sure what this question is leading into. > (We do have a defined relationship with HTTP, in RFC 7252 and RFC = 8075. > But maybe this is about something different.) I mean to ask whether there will be a need for a "coap+http" URI scheme; = it seems like a logical conclusion of the approach taken here.=20 >> I would suggest a wider discussion of these issues on art@ / uri@. >=20 > Indeed, a wider discussion of these longstanding issues would be = useful. > I=E2=80=99m not sure that waiting for their resolution is blocking = this spec. >=20 >> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >> URI, using a well-known URI in the "wss" scheme. However, "wss" is = not >> defined to use well-known URIs, so this is an invalid use.=20 >=20 > This incorrect use of RFC 5785 is indeed embarrassing. More about = that later. OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, = but I think that would take a separate RFC that updates their scheme = registrations. Not sure whether there would be any pushback in that = community (but I can't see any immediate reason why there would be). >> Section 8.1 makes it Mandatory to Implement the protocol without any >> security ("NoSec"). This seems counter to best practice in the IETF, >> but I'll defer to the Security Area review. >=20 > Since it is the implementers who will decide whether they implement = this, this co-author could live with making implementing NoSec = completely optional. (It will be anyway, in practice, at the level of = what is actually configured.) The important point(*) from the WG = perspective here is that TLS is mandatory to implement, with the = specifics depending on the security mode needed (cf. RFC 7925). (Note = also that there are other ways to provide security with CoAP.) Ack. Again, this was mostly a note to bring it to others' attention; the = use of the phrase "Mandatory to Implement" when applied to "no security" = just seems odd. Cheers, >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) = https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e935424= 2012afb28dc60 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Apr 10 20:49:48 2017 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 ADADC129A9F; Mon, 10 Apr 2017 20:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mark Nottingham To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149188258769.15738.17473942496982365590@ietfa.amsl.com> Date: Mon, 10 Apr 2017 20:49:47 -0700 Archived-At: Subject: [core] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 03:49:47 -0000 Reviewer: Mark Nottingham Review result: Ready with Issues This specification is a relatively straightforward mapping of the format described in RFC6690 (itself a serialisation of RFC5988bis links) into JSON and CBOR. I don't have deep knowledge of CBOR, but given the editorship of the document, I trust it's seen adequate review in that regard. The only potential issue is how this is achieved. Rather than defining two new serialisations of RFC5988bis links (into JSON and CBOR), it describes how to re-serialise RFC6690 documents into JSON and CBOR. This means that any constraints upon RFC6690 documents are also mirrored into these formats; e.g., the target IRI is constrained to be a URI in 6690, and therefore can also only be a URI in JSON and CBOR, despite these formats' ability to easily convey non-ASCII content. In other words, the specification currently defines these link formats in terms of the Link header (as defined in section 5 of RFC5988) -- along with all of the foibles of HTTP header syntax -- rather than their abstract model (defined in Section 3). Whether or not this is a problem depends on what's desired; if 6690 is seen as effectively a profile of 5988, then it makes sense to express it in those terms. If the full range of links capable of being expressed in 5988 is desired, creating new serialisations of 5988 links (without a hop through 6690) is preferable. If the current approach is kept, it'd be nice to clarify this situation a bit in the Introduction. From nobody Mon Apr 10 22:44:07 2017 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 4933012871F; Mon, 10 Apr 2017 22:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDjgHXztpiSj; Mon, 10 Apr 2017 22:44:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1B81205F0; Mon, 10 Apr 2017 22:44:02 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-08-58ec6d1e796d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 20.B0.27378.E1D6CE85; Tue, 11 Apr 2017 07:44:00 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Tue, 11 Apr 2017 07:43:58 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Mohit Sethi M , 'Core' , "6tisch@ietf.org" <6tisch@ietf.org> CC: Jim Schaad , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] Question about AEAD nonce uniqueness Thread-Index: AQHSsh1IHF3Oh9Y+Y0KzCXtT1ygnt6G/qPyA Date: Tue, 11 Apr 2017 05:43:57 +0000 Message-ID: References: <002101d2b21d$3ff5ba30$bfe12e90$@augustcellars.com> In-Reply-To: <002101d2b21d$3ff5ba30$bfe12e90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_D512297C7B59Dgoranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7pa5C7psIg0lTVCyW3e1jtlh+4TmL xb6365ktVk//zubA4rFxznQ2j6377zJ5LFnykymAOYrLJiU1J7MstUjfLoErY+Hp86wFz6cz Vmy52cfawHhnMmMXIyeHhICJxK8v3cxdjFwcQgLrGSX2bFzCCuEsYZTon3CYDaSKTcBF4kHD IyYQW0QgV+L89HfMIDazQL7EhvYlYHFhAQuJO3sOsEPUWEo83HcPyjaSWHXwEpDNwcEioCpx eGc6SJgXqPzMqxusILaQQKnEys5bYAdxCjhIrFm6lQXEZhQQk/h+ag0TxCpxiVtP5jNBHC0g sWTPeWYIW1Ti5eN/YHNEBfQk9v37ygYRV5JoXPKEFaI3VuLJrDZmiL2CEidnPmGZwCg6C8nY WUjKZiEpmwV0NbOApsT6XfoQJYoSU7ofskPYGhKtc+ayQ5RYSxz+b4GsZAEjxypG0eLU4qTc dCNjvdSizOTi4vw8vbzUkk2MwCg9uOW36g7Gy28cDzEKcDAq8fA+6H8dIcSaWFZcmXuIUYKD WUmE92oHUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWpRTBZJg5OqQZG G58AlplvQtV4Sjmvz76i9uxencjHNyJnJxv3Wn8J9r51abPnuQ2eO3/8fK8r/ejyh2RFBq2f 4Ubr3gltuLzrY+1rk19JjckS2TyLzQqvSNsq57ssTNotuntrhKvsruWVIaplCksMtQ7K3JIL qowIOM33dNbHA6feCal9MTRp2bbhd8X+9hXaSizFGYmGWsxFxYkAG0CZ284CAAA= Archived-At: Subject: Re: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 05:44:05 -0000 --_000_D512297C7B59Dgoranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTW9oaXQsDQoNCkNocmlzdGlhbiBhbmQgSmltIGFscmVhZHkgcHJvdmlkZWQgYW5zd2Vy cywgbGV0IG1lIGp1c3QgcHJvdmlkZSBwb2ludGVycyB0byB0aGUgcmVsZXZhbnQgc2VjdGlvbnMu DQoNCk9TQ09BUDoNCuKAlA0KVGhlIHJlcXVpcmVtZW50cyBvbiB0aGUgc2VjdXJpdHkgY29udGV4 dCBwYXJhbWV0ZXJzIGFyZSBoZXJlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDIjc2VjdGlvbi0zLjMNClR3byBtZXRob2RzIGZv ciBlc3RhYmxpc2hpbmcgdW5pcXVlIHNlbmRlciBJRHMgYXJlIHByZXNlbnRlZDogMSkgdXNlIEVE SE9DIG9yIDIpIGdlbmVyYXRlIGxhcmdlIHJhbmRvbSBpZGVudGlmaWVycy4NClRoZSBmb3JtZXIg YWxsb3dzIGZvciB0aGUgdXNlIG9mIHNob3J0IHNlbmRlciBJRHMuDQoNCg0KTXVsdGljYXN0IE9T Q09BUDoNCuKAlA0KSW4gTXVsdGljYXN0IE9TQ09BUCAoU2VjdXJlIGdyb3VwIGNvbW11bmljYXRp b24gZm9yIENvQVApIHRoZSByZXF1aXJlbWVudHMgb24gdGhlIHNlY3VyaXR5IGNvbnRleHQgcGFy YW1ldGVycyBhcmUgaGVyZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxv Y2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAxI3NlY3Rpb24tMg0KSXQgaXMgdGhlIHJlc3BvbnNp YmlsaXR5IG9mIHRoZSBHcm91cCBNYW5hZ2VyIHRvIGVzdGFibGlzaCBhbmQgbWFuYWdlIHRoZSBz ZWN1cml0eSBjb250ZXh0LCB3aGljaCBpbmNsdWRlcyB0aGUgc2VuZGVyIElEcywgYnV0IGhvdyB0 aGUgYXNzaWdubWVudCBpcyBkb25lIGlzIG91dCBvZiBzY29wZS4gVGhlIHVuaXF1ZW5lc3Mgb2Yg c2VuZGVyIElEcyBpbiB0aGlzIGRyYWZ0IGZvbGxvd3MgZnJvbSBPU0NPQVAsIGJ1dCBzaW5jZSB5 b3UgYXNrZWQgSSB0aGluayB3ZSBzaG91bGQgYWRkIGEgc2VudGVuY2UgdG8gdGhpcyBkcmFmdCBz dHJlc3NpbmcgdGhhdC4NCg0KDQpHw7ZyYW4NCg0KDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKaW0g U2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMu Y29tPj4NCkRhdGU6IE1vbmRheSAxMCBBcHJpbCAyMDE3IGF0IDE5OjA5DQpUbzogTW9oaXQgU2V0 aGkgPG1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPG1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNz c29uLmNvbT4+LCAnQ29yZScgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Piwg IjZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPiIgPDZ0aXNjaEBpZXRmLm9y ZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbY29yZV0gUXVlc3Rpb24g YWJvdXQgQUVBRCBub25jZSB1bmlxdWVuZXNzDQoNClRoZXJlIGlzIG5vdCBhIHByb2JsZW0gd2l0 aCBkZWFsaW5nIHdpdGggbm9uY2UgdW5pcXVlbmVzcyBpbiB0aGlzIGRyYWZ0IGJlY2F1c2UgZWFj aCBlbnRpdHkgaXMgZ29pbmcgdG8gYmUgYXNzaWduZWQgdG8gYSB1bmlxdWUga2V5IGZvciB0cmFu c21pc3Npb25zLiAgVGhlIHRyYW5zcG9ydCBrZXkgaXMgZGVyaXZlZCBmcm9tIHRoZSBQU0sgYW5k IHRoZSBzZW5kZXIgSUQuICBTZW5kZXIgSURzIHdpbGwgYmUgdW5pcXVlIGJhc2VkIG9uIHRoZSBl bnJvbGxtZW50IHByb3RvY29sIGluIHRoZSBncm91cCBhcyBlYWNoIGVudGl0eSB3aWxsIGhhdmUg YSB1bmlxdWUgaWRlbnRpZmllci4NCg0KSmltDQoNCg0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vaGl0IFNldGhpDQpTZW50OiBNb25kYXks IEFwcmlsIDEwLCAyMDE3IDQ6NTEgQU0NClRvOiBDb3JlIDxjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPj47IDZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0K U3ViamVjdDogW2NvcmVdIFF1ZXN0aW9uIGFib3V0IEFFQUQgbm9uY2UgdW5pcXVlbmVzcw0KDQoN CkhpIE9TQ29BUCBhdXRob3JzDQoNCkkgd2FzIHRyeWluZyB0byByZWFkIHRoZSBPU0NvQVAgYW5k IDZ0aXNjaCBtaW5pbWFsIHNlY3VyaXR5IGRyYWZ0cy4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQg dGhlIEFFQUQgbm9uY2UgdW5pcXVlbmVzcy4gUkZDIDUxMTYgc2F5cyB0aGF0Og0KDQogICBXaGVu IHRoZXJlIGFyZSBtdWx0aXBsZSBkZXZpY2VzIHBlcmZvcm1pbmcgZW5jcnlwdGlvbiB1c2luZyBh IHNpbmdsZQ0KDQogICBrZXksIHRob3NlIGRldmljZXMgbXVzdCBjb29yZGluYXRlIHRvIGVuc3Vy ZSB0aGF0IHRoZSBub25jZXMgYXJlDQoNCiAgIHVuaXF1ZS4gIEEgc2ltcGxlIHdheSB0byBkbyB0 aGlzIGlzIHRvIHVzZSBhIG5vbmNlIGZvcm1hdCB0aGF0DQoNCiAgIGNvbnRhaW5zIGEgZmllbGQg dGhhdCBpcyBkaXN0aW5jdCBmb3IgZWFjaCBvbmUgb2YgdGhlIGRldmljZXMNCg0KU28gbXkgb2J2 aW91cyBxdWVzdGlvbiBpcyBob3cgaXMgdGhlIEFFQUQgbm9uY2UgdW5pcXVlbmVzcyBlbnN1cmVk LiBUaGUgUFNLIGlzIGtub3duIHRvIGF0IGxlYXN0IHR3byBwYXJ0aWVzIChtb3JlIGluIGNhc2Ug b2Ygc29tZSB1c2VzIHN1Y2ggYXMgbXVsdGljYXN0IE9TQ29BUCBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMSk/Pw0KDQpUaGUg ZHJhZnQgY3VycmVudGx5IHNheXMgdGhhdCBBRUFEIE5vbmNlIHVuaXF1ZW5lc3MgaXMgZW5zdXJl ZCB3aXRoIHNlcXVlbmNlIG51bWJlcnMgYW5kIHNlbmRlciBjb250ZXh0IHdoaWNoIGlzIGVzc2Vu dGlhbGx5IHRoZSBzZW5kZXIgSUQuIEJ1dCBob3cgZG8geW91IGVuc3VyZSB0aGF0IHRoZSB0d28g cGFydGllcyBoYXZlIGRpZmZlcmVudCBzZW5kZXIgSUQuIEVzcGVjaWFsbHkgc2luY2Ugc2VuZGVy IElEIGlzIG5vdCBmaXhlZCBsZW5ndGguIEkgZ3Vlc3MgdGhlcmUgd2lsbCBiZSBvdGhlciBwcm9i bGVtcyBpbiBjYXNlIG9mIHNlbmRlciBJRCBjb2xsaXNpb25zPw0KDQphcyBTZW5kZXIgSURzIGFy ZSBjdXJyZW50bHkgdXNlZCwgdGhleSBhcmUgbXV0dWFsbHkgYWdyZWVkLXVwb24gbGlrZSB0aGUN CnJlc3Qgb2YgdGhlIHNlY3VyaXR5IGNvbnRleHQgKGtleSwgYWxnb3JpdGhtIGV0Yyk7IGluIG90 aGVyIHdvcmRzLCB0aGV5DQphcmUgZXhwbGljaXRseSBnaXZlbiB0byBhIGRldmljZSBieSB0aGUg bWVjaGFuaXNtIHRoYXQgYWxzbyBkaXN0cmlidXRlcw0KdGhlIGtleS4NCg0KQmVzdCByZWdhcmRz DQpDaHJpc3RpYW4NCg0KLS0NCkNocmlzdGlhbiBBbXPDvHNzICAgICAgICAgICAgICAgICAgICAg IHwgRW5lcmd5IEhhcnZlc3RpbmcgU29sdXRpb25zIEdtYkgNCmZvdW5kZXIsIHN5c3RlbSBhcmNo aXRlY3QgICAgICAgICAgICAgfCBoZWFkcXVhcnRlcjoNCm1haWx0bzpjLmFtc3Vlc3NAZW5lcmd5 aGFydmVzdGluZy5hdCAgfCBBcmJlaXRlcmdhc3NlIDE1LCBBLTQ0MDAgU3RleXINCnRlbDorNDMt NjY0LTk3LTkwLTYtMzkgICAgICAgICAgICAgICAgfCBodHRwOi8vd3d3LmVuZXJneWhhcnZlc3Rp bmcuYXQvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQVRVNjg0NzY2 MTQNCg0KDQo= --_000_D512297C7B59Dgoranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <566A8C32CE2F97488EE5AF9132D7734C@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IZWxsbyBNb2hp dCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNocmlzdGlhbiBhbmQgSmltIGFscmVh ZHkgcHJvdmlkZWQgYW5zd2VycywgbGV0IG1lIGp1c3QgcHJvdmlkZSBwb2ludGVycyB0byB0aGUg cmVsZXZhbnQgc2VjdGlvbnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PU0NPQVA6 PC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj5UaGUgcmVxdWlyZW1lbnRzIG9uIHRoZSBzZWN1 cml0eSBjb250ZXh0IHBhcmFtZXRlcnMgYXJlIGhlcmU6PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5 LTAyI3NlY3Rpb24tMy4zIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLW9iamVjdC1zZWN1cml0eS0wMiNzZWN0aW9uLTMuMzwvYT48L2Rpdj4NCjxkaXY+VHdvIG1l dGhvZHMgZm9yIGVzdGFibGlzaGluZyB1bmlxdWUgc2VuZGVyIElEcyBhcmUgcHJlc2VudGVkOiAx KSB1c2UgRURIT0Mgb3IgMikgZ2VuZXJhdGUgbGFyZ2UgcmFuZG9tIGlkZW50aWZpZXJzLiZuYnNw OzwvZGl2Pg0KPGRpdj5UaGUgZm9ybWVyIGFsbG93cyBmb3IgdGhlIHVzZSBvZiBzaG9ydCBzZW5k ZXIgSURzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pk11bHRpY2FzdCBPU0NPQVA6PC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj5JbiBNdWx0aWNh c3QgT1NDT0FQIChTZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUCkgdGhlIHJlcXVp cmVtZW50cyBvbiB0aGUgc2VjdXJpdHkgY29udGV4dCBwYXJhbWV0ZXJzIGFyZSBoZXJlOjwvZGl2 Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGlsb2Nh LWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMSNzZWN0aW9uLTIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAxI3NlY3Rpb24tMjwv YT48L2Rpdj4NCjxkaXY+SXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBHcm91cCBNYW5h Z2VyIHRvIGVzdGFibGlzaCBhbmQgbWFuYWdlIHRoZSBzZWN1cml0eSBjb250ZXh0LCB3aGljaCBp bmNsdWRlcyB0aGUgc2VuZGVyIElEcywgYnV0IGhvdyB0aGUgYXNzaWdubWVudCBpcyBkb25lIGlz IG91dCBvZiBzY29wZS4gVGhlIHVuaXF1ZW5lc3Mgb2Ygc2VuZGVyIElEcyBpbiB0aGlzIGRyYWZ0 IGZvbGxvd3MgZnJvbSBPU0NPQVAsIGJ1dCBzaW5jZSB5b3UgYXNrZWQNCiBJIHRoaW5rIHdlIHNo b3VsZCBhZGQgYSBzZW50ZW5jZSB0byB0aGlzIGRyYWZ0IHN0cmVzc2luZyB0aGF0LjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkfDtnJhbjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXpl OjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1 bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBB RERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYg MXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Y29yZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyI+Y29yZS1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgb24gYmVoYWxmIG9mIEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRm QGF1Z3VzdGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSAxMCBBcHJp bCAyMDE3IGF0IDE5OjA5PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8 L3NwYW4+TW9oaXQgU2V0aGkgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNz c29uLmNvbSI+bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb208L2E+Jmd0OywgJ0NvcmUnICZsdDs8 YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIj42dGlzY2hAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIj42dGlzY2hAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+UmU6IFtjb3JlXSBRdWVzdGlvbiBhYm91dCBBRUFEIG5vbmNlIHVuaXF1ZW5lc3M8YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAw NC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0 YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBt ZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGVyZSBp cyBub3QgYSBwcm9ibGVtIHdpdGggZGVhbGluZyB3aXRoIG5vbmNlIHVuaXF1ZW5lc3MgaW4gdGhp cyBkcmFmdCBiZWNhdXNlIGVhY2ggZW50aXR5IGlzIGdvaW5nIHRvIGJlIGFzc2lnbmVkIHRvIGEg dW5pcXVlIGtleSBmb3IgdHJhbnNtaXNzaW9ucy4mbmJzcDsgVGhlDQogdHJhbnNwb3J0IGtleSBp cyBkZXJpdmVkIGZyb20gdGhlIFBTSyBhbmQgdGhlIHNlbmRlciBJRC4mbmJzcDsgU2VuZGVyIElE cyB3aWxsIGJlIHVuaXF1ZSBiYXNlZCBvbiB0aGUgZW5yb2xsbWVudCBwcm90b2NvbCBpbiB0aGUg Z3JvdXAgYXMgZWFjaCBlbnRpdHkgd2lsbCBoYXZlIGEgdW5pcXVlIGlkZW50aWZpZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5KaW08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+IGNvcmUgWzxhIGhyZWY9Im1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Nb2hp dCBTZXRoaTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDEwLCAyMDE3IDQ6NTEgQU08 YnI+DQo8Yj5Ubzo8L2I+IENvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5j b3JlQGlldGYub3JnPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciPg0K NnRpc2NoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbY29yZV0gUXVlc3Rpb24g YWJvdXQgQUVBRCBub25jZSB1bmlxdWVuZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+ SGkgT1NDb0FQIGF1dGhvcnM8bzpwPjwvbzpwPjwvcD4NCjxwPkkgd2FzIHRyeWluZyB0byByZWFk IHRoZSBPU0NvQVAgYW5kIDZ0aXNjaCBtaW5pbWFsIHNlY3VyaXR5IGRyYWZ0cy4gSSBoYXZlIGEg cXVlc3Rpb24gYWJvdXQgdGhlIEFFQUQgbm9uY2UgdW5pcXVlbmVzcy4gUkZDIDUxMTYgc2F5cyB0 aGF0OjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgV2hlbiB0aGVyZSBhcmUgbXVs dGlwbGUgZGV2aWNlcyBwZXJmb3JtaW5nIGVuY3J5cHRpb24gdXNpbmcgYSBzaW5nbGU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsga2V5LCB0aG9zZSBkZXZpY2VzIG11c3QgY29v cmRpbmF0ZSB0byBlbnN1cmUgdGhhdCB0aGUgbm9uY2VzIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyB1bmlxdWUuJm5ic3A7IEEgc2ltcGxlIHdheSB0byBkbyB0aGlzIGlz IHRvIHVzZSBhIG5vbmNlIGZvcm1hdCB0aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IGNvbnRhaW5zIGEgZmllbGQgdGhhdCBpcyBkaXN0aW5jdCBmb3IgZWFjaCBvbmUgb2Yg dGhlIGRldmljZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHA+U28gbXkgb2J2aW91cyBxdWVzdGlvbiBp cyBob3cgaXMgdGhlIEFFQUQgbm9uY2UgdW5pcXVlbmVzcyBlbnN1cmVkLiBUaGUgUFNLIGlzIGtu b3duIHRvIGF0IGxlYXN0IHR3byBwYXJ0aWVzIChtb3JlIGluIGNhc2Ugb2Ygc29tZSB1c2VzIHN1 Y2ggYXMgbXVsdGljYXN0IE9TQ29BUA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDEiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAxPC9hPik/ Pw0KPG86cD48L286cD48L3A+DQo8cD5UaGUgZHJhZnQgY3VycmVudGx5IHNheXMgdGhhdCBBRUFE IE5vbmNlIHVuaXF1ZW5lc3MgaXMgZW5zdXJlZCB3aXRoIHNlcXVlbmNlIG51bWJlcnMgYW5kIHNl bmRlciBjb250ZXh0IHdoaWNoIGlzIGVzc2VudGlhbGx5IHRoZSBzZW5kZXIgSUQuIEJ1dCBob3cg ZG8geW91IGVuc3VyZSB0aGF0IHRoZSB0d28gcGFydGllcyBoYXZlIGRpZmZlcmVudCBzZW5kZXIg SUQuIEVzcGVjaWFsbHkgc2luY2Ugc2VuZGVyIElEIGlzIG5vdCBmaXhlZCBsZW5ndGguDQogSSBn dWVzcyB0aGVyZSB3aWxsIGJlIG90aGVyIHByb2JsZW1zIGluIGNhc2Ugb2Ygc2VuZGVyIElEIGNv bGxpc2lvbnM/PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3Rh bmRhcmQ7Ij5hcyBTZW5kZXIgSURzIGFyZSBjdXJyZW50bHkgdXNlZCwgdGhleSBhcmUgbXV0dWFs bHkgYWdyZWVkLXVwb24gbGlrZSB0aGU8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAt d2Via2l0LXN0YW5kYXJkOyI+cmVzdCBvZiB0aGUgc2VjdXJpdHkgY29udGV4dCAoa2V5LCBhbGdv cml0aG0gZXRjKTsgaW4gb3RoZXIgd29yZHMsIHRoZXk8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+YXJlIGV4cGxpY2l0bHkgZ2l2ZW4gdG8gYSBkZXZp Y2UgYnkgdGhlIG1lY2hhbmlzbSB0aGF0IGFsc28gZGlzdHJpYnV0ZXM8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+dGhlIGtleS48L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkJlc3QgcmVnYXJkczwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5DaHJpc3RpYW48 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPi0tJm5i c3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkNo cmlzdGlhbiBBbXPDvHNzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBFbmVyZ3kgSGFydmVzdGluZyBTb2x1 dGlvbnMgR21iSDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij5mb3VuZGVyLCBzeXN0ZW0gYXJjaGl0ZWN0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgaGVhZHF1YXJ0 ZXI6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxh IGhyZWY9Im1haWx0bzpjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdCI+bWFpbHRvOmMuYW1z dWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0PC9hPiZuYnNwOyZuYnNwO3wgQXJiZWl0ZXJnYXNzZSAx NSwgQS00NDAwIFN0ZXlyPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z dGFuZGFyZDsiPnRlbDomIzQzOzQzLTY2NC05Ny05MC02LTM5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuZW5lcmd5aGFydmVz dGluZy5hdC8iPmh0dHA6Ly93d3cuZW5lcmd5aGFydmVzdGluZy5hdC88L2E+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgQVRVNjg0NzY2MTQ8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_D512297C7B59Dgoranselanderericssoncom_-- From nobody Tue Apr 11 00:34:05 2017 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 5B9E1128954; Tue, 11 Apr 2017 00:33:55 -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 Em0Bphy2FgcI; Tue, 11 Apr 2017 00:33:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D55F1272E1; Tue, 11 Apr 2017 00:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3B7XiVi016689; Tue, 11 Apr 2017 09:33:44 +0200 (CEST) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w2Jh80fd0zDGv9; Tue, 11 Apr 2017 09:33:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149188258769.15738.17473942496982365590@ietfa.amsl.com> Date: Tue, 11 Apr 2017 09:33:43 +0200 Cc: art@ietf.org, ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 513588823.52644-849855f363bc0cd0868f57315eaebce9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 07:33:55 -0000 Hi Mark, thank you a lot for another thoughtful review. I don=E2=80=99t have an opinion yet on what we should do here, so I=E2=80=99= ll supply some more background first. The present spec is first and foremost intended to round-trip with RFC = 6690, which is indeed stuck a bit on HTTP Link header field syntax. = However, the way this is used in practice is not meant to inherit the = complexities of HTTP header field coding. E.g., for CoRE Resource = Directory and its DNS-SD compatibility, we want to represent a DNS-SD = instance identifier (which is UTF-8) as a link attribute. This is not a = problem in JSON or CBOR, but also not in the way RFC 6690 is being used, = i.e. as a UTF-8 based format. I haven=E2=80=99t checked yet what 5988bis brings to the table and how = to track this in 6690 or possibly a 6690bis. There is no point in Big = Web and Thing Web diverging here, so we should follow the lead. But = maybe that would touch both 6690 and the present document once 5988bis = is done. More importantly, we haven=E2=80=99t really put a lot of thinking into = IRI support. The CoAP data type =E2=80=9Cstring=E2=80=9D which is used = for URI components such as Uri-Path is UTF-8, so we could embrace them = by extending the rules in section 6 of RFC 7252 to cover IRIs. I=E2=80=99= m sure that, in practice, CoAP implementations already do this =E2=80=94 = it is not distinguishable in the CoAP packet whether the (decomposed) = CoAP Uri components have been derived from URIs or IRIs. But the = metadata formats (6690 and its JSON/CBOR representations; various other = JSON and CBOR based formats, e.g. from OCF) are still based on RFC 3986 = URIs, except where they also use the CoAP decomposed form (e.g., CORAL). While this is outside the scope of the CoRE WG, I personally would like = to explore how link-format+cbor/+json could be useful for the Big Web. = If embracing IRIs there is all we need to make this happen, maybe that = can be added with a warning that IRIs have to be converted back to URIs = for 6690 link-format. Gr=C3=BC=C3=9Fe, Carsten > On Apr 11, 2017, at 05:49, Mark Nottingham wrote: >=20 > Reviewer: Mark Nottingham > Review result: Ready with Issues >=20 > This specification is a relatively straightforward mapping of the > format described in RFC6690 (itself a serialisation of RFC5988bis > links) into JSON and CBOR. I don't have deep knowledge of CBOR, but > given the editorship of the document, I trust it's seen adequate > review in that regard. >=20 > The only potential issue is how this is achieved. Rather than defining > two new serialisations of RFC5988bis links (into JSON and CBOR), it > describes how to re-serialise RFC6690 documents into JSON and CBOR. > This means that any constraints upon RFC6690 documents are also > mirrored into these formats; e.g., the target IRI is constrained to be > a URI in 6690, and therefore can also only be a URI in JSON and CBOR, > despite these formats' ability to easily convey non-ASCII content. >=20 > In other words, the specification currently defines these link formats > in terms of the Link header (as defined in section 5 of RFC5988) -- > along with all of the foibles of HTTP header syntax -- rather than > their abstract model (defined in Section 3). >=20 > Whether or not this is a problem depends on what's desired; if 6690 is > seen as effectively a profile of 5988, then it makes sense to express > it in those terms. If the full range of links capable of being > expressed in 5988 is desired, creating new serialisations of 5988 > links (without a hop through 6690) is preferable. >=20 > If the current approach is kept, it'd be nice to clarify this > situation a bit in the Introduction. >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art >=20 From nobody Tue Apr 11 04:06:24 2017 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 A7D06128C83 for ; Tue, 11 Apr 2017 04:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU_k1RRlMRe3 for ; Tue, 11 Apr 2017 04:06:22 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 BE7CB126C2F for ; Tue, 11 Apr 2017 04:06:21 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id v3BB6J5L002064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 11 Apr 2017 13:06:19 +0200 Received: from DEFTHW99ERKMSX.ww902.siemens.net (defthw99erkmsx.ww902.siemens.net [139.22.70.147]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v3BB6IwW000962 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Apr 2017 13:06:19 +0200 Received: from DEFTHW99ER3MSX.ww902.siemens.net (139.22.70.74) by DEFTHW99ERKMSX.ww902.siemens.net (139.22.70.147) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 11 Apr 2017 13:06:18 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.68]) by DEFTHW99ER3MSX.ww902.siemens.net ([139.22.70.74]) with mapi id 14.03.0339.000; Tue, 11 Apr 2017 13:06:18 +0200 From: "Kovatsch, Matthias" To: "core@ietf.org" Thread-Topic: Resource Directory vs RFC 6690 Thread-Index: AdKys6Slnkh1vPiYReSfMVxW3VUVvQ== Date: Tue, 11 Apr 2017 11:06:17 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.33] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64DEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Subject: [core] Resource Directory vs RFC 6690 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:06:23 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64DEFTHW99EL4MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear list, dear Michael While talking with people from an industry alliance building their standard= on CoAP, it came up that RD lookups need to support multiple query paramet= ers with an AND conjunction. draft-ietf-core-resource-directory-10, Section= 7 supports this: "Multiple query parameters MAY be included in a lookup" It might be clearer to also mention the logical AND conjunction here. The confusion for this requirement mainly arose from the Link Format RFC 66= 90, Section 4: "/.well-known/core{?search*} where the variable "search" is a 1-element list that has a single = name/value pair" The lookup on /.well-known/core only allows a single query parameter. This = was decided to not demand too much query processing from constrained device= s. The query feature is overall a MAY, that is, it might not be implemented= at all. That means, also links that do not match the query could be return= ed. This is in conflict with draft-ietf-core-resource-directory-10, Section 7, = where it says further: "all included parameters MUST match for a resource to be returned." I say conflict because we should have the principle of the least surprise. = RD res-lookup and /.well-known/core are very similar. The latter could also= offer the same filtering as RD based on the server's resource(=3Dlink) att= ributes. Furthermore, I think the "MUST match" is inappropriate. It must be up to th= e client to select the correct link. Just compare it to Google, where besid= es irrelevant results also ads are included in the results and it is up to = the user to decide which links to click on. While I fully understand that t= here is usually no user involved, it would make a more robust system, when = the client has the responsibility to select the appropriate link and not bl= indly the first one because it trusts the MUST in a specification. What do you think? Should we file errata for RFC 6690 and fix this? Did I miss updates from RFC 7252? Ciao Matthias --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64DEFTHW99EL4MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear list,
dear Michael
 
While talking with people from an industry alliance building their sta= ndard on CoAP, it came up that RD lookups need to support multiple query pa= rameters with an AND conjunction. draft-ietf-core-resource-directory-10, Se= ction 7 supports this:
 
=         “Multiple query parameters= MAY be included in a lookup”
=  
It might be clearer to also mention the logical AND conjunction here.<= /div>
The confusion for this requirement mainly arose from the Link Format R= FC 6690, Section 4:
 
        “/.well-known/co= re{?search*}
=         where the variable "search= " is a 1-element list that has a single name/value pair”<= /font>
 
The lookup on /.well-known/core only allows a single query parameter. = This was decided to not demand too much query processing from constrained d= evices. The query feature is overall a MAY, that is, it might not be implem= ented at all. That means, also links that do not match the query could be returned.
 
This is in conflict with draft-ietf-core-resource-directory-10, Sectio= n 7, where it says further:
 
=         “all included parameters M= UST match for a resource to be returned.”
 
I say conflict because we should have the principle of the least surpr= ise. RD res-lookup and /.well-known/core are very similar. The latter could= also offer the same filtering as RD based on the server’s resource(= =3Dlink) attributes.
 
Furthermore, I think the “MUST match” is inappropriate. It= must be up to the client to select the correct link. Just compare it to Go= ogle, where besides irrelevant results also ads are included in the results= and it is up to the user to decide which links to click on. While I fully understand that there is usually no user involve= d, it would make a more robust system, when the client has the responsibili= ty to select the appropriate link and not blindly the first one because it = trusts the MUST in a specification.
 
What do you think?
Should we file errata for RFC 6690 and fix this?
Did I miss updates from RFC 7252?
 
Ciao
Matthias
 
 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01B22B64DEFTHW99EL4MSXw_-- From nobody Tue Apr 11 19:38:03 2017 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 BCF76128D44 for ; Tue, 11 Apr 2017 19:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 oPpb73YDtkwd for ; Tue, 11 Apr 2017 19:38:00 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3AA128BB7 for ; Tue, 11 Apr 2017 19:37:58 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9CE6A19F380; Wed, 12 Apr 2017 10:37:56 +0800 (HKT) Message-ID: <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> From: "weigengyu" To: "Mark Nottingham" , "Carsten Bormann" Cc: , , , References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> In-Reply-To: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> Date: Wed, 12 Apr 2017 10:38:12 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:38:03 -0000 Hi Mark, > OK. Just curious -- is there a strong motivation here? > It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol > (COAP) over WebSockets over HTTP again, > rather than just using HTTP (which AIUI you already have a mapping to). It is meaningful and interesting. CoAP/UDP/IPv6 protocl stack can run well within CoRE environments. But if CoAP/UDP is tried in the Internet, it will be blocked due to NAT/firewall etcs based on tests done here a few years ago. CoAP/TCP or CoAP/WSS could help CoAP messages and applications available around Internet. We have done some works about this topics. The following are two abstracts of my master course students' theses, in which may be interested. THE RESEARCH AND DEVELOPMENT OF CoAP over TCP ABSTRACT The CoAP protocol is a restricted resource application protocol. In the CoAP protocol research and application, the default CoAP protocol stack use UDP as the transport layer。In the Ethernet environment, data transmission will be affected because of the existence of the firewall . For the reason that CoAP can be better applied to the current Internet environment and cloud environment, IETF working group proposed CoAP over TCP, CoAP protocol stack use TCP as the transport layer .In this context, CoAP over TCP is studied and CoAP over TCP is implemented based on the open source framework Californium. The CoAP over TCP is implemented as a client in the real Internet environment and the function of the implementation is evaluated. CoAP over TCP is the Internet of Things cloud platform services, so AWS environment is used to achieve CoAP over TLS/TCP and the default protocol stack performance comparison. In this paper, the significance of CoAP over TCP is expatiated, and CoAP over TCP is studied. After that, the overall architecture of Californium framework is deeply analyzed, and the design scheme of CoAP over TCP is proposed. The transport layer is extended on the basis of the original frame structure. Based on the design scheme, the modules are designed and designed in detail. On the core of the class through the class diagram describes the expansion of the relationship between the various modules. The network layer, protocol layer and application layer implementation process are analyzed in detail. Afterwards, we study the proxy between CoAP over TCP and default protocol stack, and propose the message type conversion problem and solution of CoAPToCoAP proxy. The paper concludes the relevant work, and puts forward the research direction of the next step. KEY WORDS: CoAP over TCP Proxy Californium Frame THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET ABSTRACT The concept of Internet of Things (IoT) was originally proposed almost twenty years ago. Over the past many years, IoT has gone through huge and rapid development, and the field of Wireless Sensor Network (WSN) has witnessed remarkable advancement in particular. Compared to the progress of WSN, the practical service and application of IoT still has a very long way to go. Although current industry standards can meet those equipments like smart phones, they are not quite suitable for constrained nodes which are often battery supported and has relatively lower processing ability. Driven by such demands, the IETF set up CoRE working group to design a RESTful application protocol which can perform better among constrained nodes in constrained environments. The protocol was named Constrained Application Protocol (CoAP) and it was later standardized as RFC 7252. This paper analizes the features and defect of the HTTP/CoAP proxy proposed in RFC 7252, and explains the CoAP over WebSocket proxy as well as its advantages over the HTTP/CoAP proxy. Then a design and implementation of CoAP over WebSocket based on Californium open-source framework is given. Performance tests and experiments have shown that the CoAP over WebSocket approach has some significant advantages over HTTP/CoAP proxy in term of response time and high concurrency requests processing ability. KEY WORDS: computer network, iot, coap, network proxy, websocket Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Mark Nottingham Sent: Tuesday, April 11, 2017 8:39 AM To: Carsten Bormann Cc: art@ietf.org ; draft-ietf-core-coap-tcp-tls.all@ietf.org ; ietf@ietf.org ; core@ietf.org Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Hi Carsten, Couple of quic responses below. On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: > I agree that the introduction should focus on the Browser use case and > keep out of the firewall traversal jungle. OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over HTTP again, rather than just using HTTP (which AIUI you already have a mapping to). >> Section 7 defines a number of new URI schemes for COAP protocols. >> Syntactically, they use "+" to separate "coap" from the underlying >> transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This >> syntax is allowed by RFC3986, but is unprecedented, and implies a >> sub-syntax convention similar to those used in media types, etc. Is >> there an expectation that other URI schemes starting with "coap+" are >> reserved? > > There is no such expectation. > > We did have the discussion about reserved URI scheme prefixes in the IETF, > and as I recall, the result was that there are none. While it would be a > bit weird to register a URI scheme starting with coap+ or coaps+ that is > unrelated to CoAP, only the slightly boggled response from an expert > review is in the way of that happening. > > Would the scheme names be more palatable with a dash instead of a plus? > Careful choice of the scheme name mostly benefits the implementer, so it > can be changed in the spec (at the cost of changing existing > implementations). OK. I'm mostly noting this in case other folks feel that this is a bad precedent for URI schemes; I think the bigger concern is the one below. >> Defining URI schemes that switch transport protocol based upon their >> name deserves wider review as well; this has been a contentious topic >> in the past, and it would be good to understand what tradeoffs are >> being made by doing so. Locking identifiers into a specific transport >> protocol sacrifices much of the power of URLs. > > The “siloing†of URIs along schemes is indeed a problem, which started > for CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG > did not see it as its task to address this shortcoming. So, for now, we’ll > have to live with it; approaches such as > draft-silverajan-core-coap-protocol-negotiation are trying to address its > practicalities. By defining multiple URI schemes for different transports of the same protocol, the WG has taken a position as to what the solution is. I'm finding it difficult to square this with the continuing characterisation of CORE as "RESTful". >> Furthermore, creating >> "coap+ws" to denote a specific protocol over WebSockets (which has its >> own URI scheme) is questionable; taken to its natural conclusion, >> we'll have a proliferation of URI schemes for things over WebSockets. > > I’m not sure that a proliferation will happen — WebSockets is mostly > used for tightly bound proprietary protocols between a JavaScript mobile > code client and a server that provides this mobile code client. On the > other hand, deciding to never use URIs to refer to resources available > over a WebSockets protocol strikes me as an unnecessary restriction. > >> Will COAP take the same approach for HTTP? > > Not sure what this question is leading into. > (We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075. > But maybe this is about something different.) I mean to ask whether there will be a need for a "coap+http" URI scheme; it seems like a logical conclusion of the approach taken here. >> I would suggest a wider discussion of these issues on art@ / uri@. > > Indeed, a wider discussion of these longstanding issues would be useful. > I’m not sure that waiting for their resolution is blocking this spec. > >> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >> URI, using a well-known URI in the "wss" scheme. However, "wss" is not >> defined to use well-known URIs, so this is an invalid use. > > This incorrect use of RFC 5785 is indeed embarrassing. More about that > later. OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I think that would take a separate RFC that updates their scheme registrations. Not sure whether there would be any pushback in that community (but I can't see any immediate reason why there would be). >> Section 8.1 makes it Mandatory to Implement the protocol without any >> security ("NoSec"). This seems counter to best practice in the IETF, >> but I'll defer to the Security Area review. > > Since it is the implementers who will decide whether they implement this, > this co-author could live with making implementing NoSec completely > optional. (It will be anyway, in practice, at the level of what is > actually configured.) The important point(*) from the WG perspective here > is that TLS is mandatory to implement, with the specifics depending on the > security mode needed (cf. RFC 7925). (Note also that there are other ways > to provide security with CoAP.) Ack. Again, this was mostly a note to bring it to others' attention; the use of the phrase "Mandatory to Implement" when applied to "no security" just seems odd. Cheers, > > Grüße, Carsten > > (*) > https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60 > -- Mark Nottingham https://www.mnot.net/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 11 19:42:33 2017 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 903D5126CD8; Tue, 11 Apr 2017 19:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcrNX87zLUnb; Tue, 11 Apr 2017 19:42:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 401621242F5; Tue, 11 Apr 2017 19:42:29 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CFC6822E253; Tue, 11 Apr 2017 22:42:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham X-Priority: 3 In-Reply-To: <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> Date: Wed, 12 Apr 2017 12:42:16 +1000 Cc: Carsten Bormann , art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> To: weigengyu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:42:32 -0000 So, is COAP using WebSockets for browser access, or for firewall = traversal? The paper below seems to indicate the latter, and so the = original question remains. Also, the assertions about firewalls are interesting; we're hearing very = different assertions in the discussions of QUIC (e.g,. 90%+ success = rates for UDP protocols). Cheers, > On 12 Apr 2017, at 12:38 pm, weigengyu wrote: >=20 > Hi Mark, >=20 >> OK. Just curious -- is there a strong motivation here? >> It seems very odd to tunnel HTTP-like semantics over a custom UDP = protocol (COAP) over WebSockets over HTTP again, >> rather than just using HTTP (which AIUI you already have a mapping = to). >=20 > It is meaningful and interesting. > CoAP/UDP/IPv6 protocl stack can run well within CoRE environments. > But if CoAP/UDP is tried in the Internet, it will be blocked due to = NAT/firewall etcs based on tests done here a few years ago. > CoAP/TCP or CoAP/WSS could help CoAP messages and applications = available around Internet. >=20 > We have done some works about this topics. > The following are two abstracts of my master course students' theses, = in which may be interested. >=20 > THE RESEARCH AND DEVELOPMENT OF CoAP over TCP > ABSTRACT > The CoAP protocol is a restricted resource application protocol. In = the CoAP protocol research and application, the default CoAP protocol > stack use UDP as the transport layer=E3=80=82In the Ethernet = environment, data transmission will be affected because of the existence = of the firewall . > For the reason that CoAP can be better applied to the current Internet = environment and cloud environment, IETF working group proposed CoAP over = TCP, > CoAP protocol stack use TCP as the transport layer .In this context, = CoAP over TCP is studied and CoAP over TCP is implemented based on the > open source framework Californium. The CoAP over TCP is implemented as = a client in the real Internet environment and the function of the > implementation is evaluated. CoAP over TCP is the Internet of Things = cloud platform services, so AWS environment is used to achieve CoAP over = TLS/TCP > and the default protocol stack performance comparison. > In this paper, the significance of CoAP over TCP is expatiated, and = CoAP over TCP is studied. After that, the overall architecture of = Californium framework > is deeply analyzed, and the design scheme of CoAP over TCP is = proposed. The transport layer is extended on the basis of the original = frame structure. > Based on the design scheme, the modules are designed and designed in = detail. On the core of the class through the class diagram describes the = expansion > of the relationship between the various modules. The network layer, = protocol layer and application layer implementation process are analyzed = in detail. > Afterwards, we study the proxy between CoAP over TCP and default = protocol stack, and propose the message type conversion problem and = solution of CoAPToCoAP proxy. > The paper concludes the relevant work, and puts forward the research = direction of the next step. > KEY WORDS: CoAP over TCP Proxy Californium Frame >=20 > THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET > ABSTRACT > The concept of Internet of Things (IoT) was originally proposed almost = twenty years ago. Over the past many years, IoT has gone through huge = and rapid development, > and the field of Wireless Sensor Network (WSN) has witnessed = remarkable advancement in particular. Compared to the progress of WSN, = the practical service > and application of IoT still has a very long way to go. Although = current industry standards can meet those equipments like smart phones, = they are not quite suitable > for constrained nodes which are often battery supported and has = relatively lower processing ability. Driven by such demands, the IETF = set up CoRE working group > to design a RESTful application protocol which can perform better = among constrained nodes in constrained environments. > The protocol was named Constrained Application Protocol (CoAP) and it = was later standardized as RFC 7252. > This paper analizes the features and defect of the HTTP/CoAP proxy = proposed in RFC 7252, and explains the CoAP over WebSocket proxy as well = as its advantages over > the HTTP/CoAP proxy. Then a design and implementation of CoAP over = WebSocket based on Californium open-source framework is given. = Performance tests and > experiments have shown that the CoAP over WebSocket approach has some = significant advantages over HTTP/CoAP proxy in term of response time and = high concurrency > requests processing ability. > KEY WORDS: computer network, iot, coap, network proxy, websocket >=20 >=20 > Regards, >=20 > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Mark Nottingham > Sent: Tuesday, April 11, 2017 8:39 AM > To: Carsten Bormann > Cc: art@ietf.org ; draft-ietf-core-coap-tcp-tls.all@ietf.org ; = ietf@ietf.org ; core@ietf.org > Subject: Re: [core] Artart last call review of = draft-ietf-core-coap-tcp-tls-07 >=20 > Hi Carsten, >=20 > Couple of quic responses below. >=20 > On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: >=20 >> I agree that the introduction should focus on the Browser use case = and keep out of the firewall traversal jungle. >=20 > OK. Just curious -- is there a strong motivation here? It seems very = odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over = WebSockets over HTTP again, rather than just using HTTP (which AIUI you = already have a mapping to). >=20 >=20 >>> Section 7 defines a number of new URI schemes for COAP protocols. >>> Syntactically, they use "+" to separate "coap" from the underlying >>> transport(-ish) protocol that they're bound to; e.g., "coap+tcp". = This >>> syntax is allowed by RFC3986, but is unprecedented, and implies a >>> sub-syntax convention similar to those used in media types, etc. Is >>> there an expectation that other URI schemes starting with "coap+" = are >>> reserved? >>=20 >> There is no such expectation. >>=20 >> We did have the discussion about reserved URI scheme prefixes in the = IETF, and as I recall, the result was that there are none. While it = would be a bit weird to register a URI scheme starting with coap+ or = coaps+ that is unrelated to CoAP, only the slightly boggled response = from an expert review is in the way of that happening. >>=20 >> Would the scheme names be more palatable with a dash instead of a = plus? >> Careful choice of the scheme name mostly benefits the implementer, so = it can be changed in the spec (at the cost of changing existing = implementations). >=20 > OK. I'm mostly noting this in case other folks feel that this is a bad = precedent for URI schemes; I think the bigger concern is the one below. >=20 >=20 >>> Defining URI schemes that switch transport protocol based upon their >>> name deserves wider review as well; this has been a contentious = topic >>> in the past, and it would be good to understand what tradeoffs are >>> being made by doing so. Locking identifiers into a specific = transport >>> protocol sacrifices much of the power of URLs. >>=20 >> The =E2=80=9Csiloing=E2=80=9D of URIs along schemes is indeed a = problem, which started for CoAP with the separation of the coap:/coaps: = name spaces. The CoRE WG did not see it as its task to address this = shortcoming. So, for now, we=E2=80=99ll have to live with it; = approaches such as draft-silverajan-core-coap-protocol-negotiation are = trying to address its practicalities. >=20 > By defining multiple URI schemes for different transports of the same = protocol, the WG has taken a position as to what the solution is. I'm = finding it difficult to square this with the continuing characterisation = of CORE as "RESTful". >=20 >=20 >>> Furthermore, creating >>> "coap+ws" to denote a specific protocol over WebSockets (which has = its >>> own URI scheme) is questionable; taken to its natural conclusion, >>> we'll have a proliferation of URI schemes for things over = WebSockets. >>=20 >> I=E2=80=99m not sure that a proliferation will happen =E2=80=94 = WebSockets is mostly used for tightly bound proprietary protocols = between a JavaScript mobile code client and a server that provides this = mobile code client. On the other hand, deciding to never use URIs to = refer to resources available over a WebSockets protocol strikes me as an = unnecessary restriction. >>=20 >>> Will COAP take the same approach for HTTP? >>=20 >> Not sure what this question is leading into. >> (We do have a defined relationship with HTTP, in RFC 7252 and RFC = 8075. >> But maybe this is about something different.) >=20 > I mean to ask whether there will be a need for a "coap+http" URI = scheme; it seems like a logical conclusion of the approach taken here. >=20 >=20 >>> I would suggest a wider discussion of these issues on art@ / uri@. >>=20 >> Indeed, a wider discussion of these longstanding issues would be = useful. >> I=E2=80=99m not sure that waiting for their resolution is blocking = this spec. >>=20 >>> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >>> URI, using a well-known URI in the "wss" scheme. However, "wss" is = not >>> defined to use well-known URIs, so this is an invalid use. >>=20 >> This incorrect use of RFC 5785 is indeed embarrassing. More about = that later. >=20 > OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, = but I think that would take a separate RFC that updates their scheme = registrations. Not sure whether there would be any pushback in that = community (but I can't see any immediate reason why there would be). >=20 >=20 >>> Section 8.1 makes it Mandatory to Implement the protocol without any >>> security ("NoSec"). This seems counter to best practice in the IETF, >>> but I'll defer to the Security Area review. >>=20 >> Since it is the implementers who will decide whether they implement = this, this co-author could live with making implementing NoSec = completely optional. (It will be anyway, in practice, at the level of = what is actually configured.) The important point(*) from the WG = perspective here is that TLS is mandatory to implement, with the = specifics depending on the security mode needed (cf. RFC 7925). (Note = also that there are other ways to provide security with CoAP.) >=20 > Ack. Again, this was mostly a note to bring it to others' attention; = the use of the phrase "Mandatory to Implement" when applied to "no = security" just seems odd. >=20 > Cheers, >=20 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> (*) = https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e935424= 2012afb28dc60 >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 11 20:30:38 2017 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 4B0FD12947A for ; Tue, 11 Apr 2017 20:30: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iv_n78kLFT3 for ; Tue, 11 Apr 2017 20:30:33 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 31B48128B88 for ; Tue, 11 Apr 2017 20:30:33 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0896719F36F; Wed, 12 Apr 2017 11:30:28 +0800 (HKT) Message-ID: <964BD3C751A640E48A10E4FFC42E2B2F@WeiGengyuPC> From: "weigengyu" To: "Michael Koster" , "Kerry Lynn" , "peter van der Stok" , "Carsten Bormann" , "Zach Shelby" , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: , "core" References: <2B5F5BA0-875A-4941-BB27-7764DB19A942@smartthings.com> In-Reply-To: <2B5F5BA0-875A-4941-BB27-7764DB19A942@smartthings.com> Date: Wed, 12 Apr 2017 11:30:42 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01D2B380.385DC1A0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] Continuing the Resource Directory and DNS-SD discussion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 03:30:36 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0049_01D2B380.385DC1A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael,=20 We are also intersted in this topic. =20 > 1. Using DNS-SD to find a resource directory If to find/resolve a RD server in the internet, DNS is also required = when DNS-SD is not avalable. > 2. Providing "ins" and "exp" link attributes=20 Yes. > 3. Specifying DNS-SD mapping to links in the RD document It seems clear that to resolve a RD server, CoAP, HTTP, DNS-SD are = available.=20 If to resolve a resourece registered in a RD server, CoAP is available = already. Dose it try to have DNS-SD available too?=20 > First, should DNS-SD mapping be included in the RD draft? > This question can be informed by the requirements for the mapping = itself and the expected use case of the mapping. First of all, what the objective is by adoptng DNS-SD?=20 To resovle a CoAP node/resources, or to resolve a RD server? =20 > Based on the discussion below, there is a case to be made for = publishing the mapping or RD links to DNS-SD records as a separate = document. > - DNS-SD is not required to use RD. It would not be helpful to couple = RD and DNS-SD unnecessarily by creating intra-document dependencies. Yes. But DNS or DNS-SD have the data of the =E2=80=9Cregistered=E2=80=9D = RD server(s), and knows which RD to have. =20 > - A good use scenario and introductory explanation is needed, = describing the relationship of RD to DNS-SD, which may be better served = in its own document. Yes > - Additional constraints on the use of RD are needed to facilitate the = mapping, such as limiting the length of identifiers, requiring the = presense of the "rt" attribute,=20 > requiring the use of "ins" and "exp". What is mandatory in RD? Yes. Considering the current length limites of DNS/DNS-RD, it may be = realistic to use DNS or DNS-SD to resolve a RD server instead of CoAP = server or resources. =20 > - The rd-dns-sd draft can refer to RD normatively and publish in the = same time frame, since the 2 documents will both be working group = adopted and have good support.=20 > The RD document will not need to refer to the RD-DNS-SD document = normatively. If DNS-SD is tried to resolve a CoAP server or resources, a separate = document is better.=20 > The second question was to clarify the mapping itself, and its use = case. We had several enlightening discussions, which I will try to = summarize here. > What is DNS-SD mapping and how does it work? What are the use cases = and what assumptions do they drive? > The big bit seems to be service discovery vs. resource discovery > The use case for DNS-SD is service discovery across broad network = scope, including mesh and bridged/routed networks.=20 > The use case for RD is fine grain resource discovery using hyperlinks, = as part of a REST client-server state machine. Clearly these are mostly = complementary use cases,=20 > and it is easy to build service discovery on top of REST. Resource = Directories are themselves REST servers and can respond to multicast = discovery queries,=20 > but have no well defined discovery proxy for routed and bridged = networks. Once the RD address is known, it can participate in REST = interactions through unicast transactions.=20 > The use case for RD to DNS-SD mapping is in making DNS-SD services = discoverable as RD registered endpoints and links, and to make RD = registered endpoints and links discoverable=20 > as DNS-SD services. I do not agree that =E2=80=9Cmaking DNS-SD services discoverable as RD = registered endpoints and links, and to make RD registered endpoints and = links discoverable as DNS-SD services.=E2=80=9D My suggestion is just to make a RD server discoverable as DNS-SD = service.=20 >Based on this, a system could bootstrap resource discovery by = advertizing the resource directory location(s) usind DNS-SD and the link = mapping to RD services; e.g. links > with "rt=3Dcore.rd;rt=3Dcore.rd-lookup-res;core.rd-lookup-ep" etc. = would be registered in an RD and exported to DNS-SD. Other RD services = in the network would expose links=20 > to the RD services that were discovered over DNS-SD. In this way, all = of the RD services that are only reachable using unicast could be = discovered in "local" RD services.=20 > DNS-SD would be used to keep all of the RD service locations = discoverable through RD on local network scope. > A number of assumptions and requirements for the mapping: > Links registered in RD for export to DNS-SD use the "rt" link = attribute for translation to DNS service type name and transmitted as a = SRV record. > Link context, consisting of scheme+authority+port, will be translated = to a DNS service location and transmitted as a PTR record. > The remaining information in the link, or perhaps the entire link, = will be transmitted in DNS-SD as a TXT record. > Based on these discussion, I am recommending that the DNS-SD mapping = to RD links be taken up in a separate document, to normatively refer to = the RD document,=20 > and be published in the same time frame in order to enable systems to = use both RD and DNS-SD together. After all, making a RD server discoverable as DNS/DNS-SD service does = not bread the existing rules or add anything new to the existing = Internet nodes. =20 For the a RD server as a node fuctioning for resolution, it is tied to = DNS/DNS-SD, but it works only for CoAP node or resource resolution.=20 Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Michael Koster=20 Sent: Friday, April 07, 2017 11:03 PM To: Kerry Lynn ; peter van der Stok ; Carsten Bormann ; Zach Shelby ; = Jaime Jim=C3=A9nez ; Christian Ams=C3=BCss=20 Cc: draft-ietf-core-resource-directory@ietf.org ; core=20 Subject: [core] Continuing the Resource Directory and DNS-SD discussion Hi,=20 The last discussion as I recall from the CoRE meeting was around 3 = points: 1. Using DNS-SD to find a resource directory 2. Providing "ins" and "exp" link attributes=20 3. Specifying DNS-SD mapping to links in the RD document We have already decided for points 1 and 2 within the scope of the RD = document. We are discussing whether the DNS-SD mapping should be = published in the RD document. At IETF 98 we had two discussions.. First, should DNS-SD mapping be included in the RD draft? This question can be informed by the requirements for the mapping itself = and the expected use case of the mapping. Based on the discussion below, there is a case to be made for publishing = the mapping or RD links to DNS-SD records as a separate document. - DNS-SD is not required to use RD. It would not be helpful to couple RD = and DNS-SD unnecessarily by creating intra-document dependencies. - A good use scenario and introductory explanation is needed, describing = the relationship of RD to DNS-SD, which may be better served in its own = document. - Additional constraints on the use of RD are needed to facilitate the = mapping, such as limiting the length of identifiers, requiring the = presense of the "rt" attribute, requiring the use of "ins" and "exp". = What is mandatory in RD? - The rd-dns-sd draft can refer to RD normatively and publish in the = same time frame, since the 2 documents will both be working group = adopted and have good support. The RD document will not need to refer to = the RD-DNS-SD document normatively. There is a github repository with this work in progress and issues = tracking: RD document: https://github.com/core-wg/resource-directory RD to DNS-SD mapping document: https://github.com/core-wg/rd-dns-sd The second question was to clarify the mapping itself, and its use case. = We had several enlightening discussions, which I will try to summarize = here. What is DNS-SD mapping and how does it work? What are the use cases and = what assumptions do they drive? The big bit seems to be service discovery vs. resource discovery The use case for DNS-SD is service discovery across broad network scope, = including mesh and bridged/routed networks.=20 The use case for RD is fine grain resource discovery using hyperlinks, = as part of a REST client-server state machine. Clearly these are mostly = complementary use cases, and it is easy to build service discovery on = top of REST. Resource Directories are themselves REST servers and can = respond to multicast discovery queries, but have no well defined = discovery proxy for routed and bridged networks. Once the RD address is = known, it can participate in REST interactions through unicast = transactions.=20 The use case for RD to DNS-SD mapping is in making DNS-SD services = discoverable as RD registered endpoints and links, and to make RD = registered endpoints and links discoverable as DNS-SD services. Based on this, a system could bootstrap resource discovery by = advertizing the resource directory location(s) usind DNS-SD and the link = mapping to RD services; e.g. links with = "rt=3Dcore.rd;rt=3Dcore.rd-lookup-res;core.rd-lookup-ep" etc. would be = registered in an RD and exported to DNS-SD. Other RD services in the = network would expose links to the RD services that were discovered over = DNS-SD. In this way, all of the RD services that are only reachable = using unicast could be discovered in "local" RD services. DNS-SD would = be used to keep all of the RD service locations discoverable through RD = on local network scope. A number of assumptions and requirements for the mapping: Links registered in RD for export to DNS-SD use the "rt" link attribute = for translation to DNS service type name and transmitted as a SRV = record. Link context, consisting of scheme+authority+port, will be translated to = a DNS service location and transmitted as a PTR record. The remaining information in the link, or perhaps the entire link, will = be transmitted in DNS-SD as a TXT record. Based on these discussion, I am recommending that the DNS-SD mapping to = RD links be taken up in a separate document, to normatively refer to the = RD document, and be published in the same time frame in order to enable = systems to use both RD and DNS-SD together. -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0049_01D2B380.385DC1A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,
 
We are also intersted in this topic. 
 
> 1. Using DNS-SD to find a resource directory
If to find/resolve a RD server in the internet, DNS is also = required when=20 DNS-SD is not avalable.
 
> 2. Providing "ins" and "exp" link attributes
Yes.
 
> 3. Specifying DNS-SD mapping to links in the RD document
It seems clear that to resolve a RD server, CoAP, HTTP, DNS-SD are=20 available.
If to resolve a resourece registered in a RD server, CoAP is = available=20 already.  Dose it try to have DNS-SD available too?
 
> First, should DNS-SD mapping be included in the RD = draft?
> This question can be informed by the requirements for the = mapping=20 itself and the expected use case of the mapping.
 
First of all, what the objective is by adoptng DNS-SD?
To resovle a CoAP node/resources, or to resolve a RD server?  =
 
> Based on the discussion below, there is a case to be made for=20 publishing the mapping or RD links to DNS-SD records as a separate=20 document.
> - DNS-SD is not required to use RD. It would not be helpful to = couple=20 RD and DNS-SD unnecessarily by creating intra-document = dependencies.
Yes. But DNS or DNS-SD have the data of the = =E2=80=9Cregistered=E2=80=9D RD server(s), and=20 knows which RD to have. 
 
> - A good use scenario and introductory explanation is needed,=20 describing the relationship of RD to DNS-SD, which may be better served = in its=20 own document.
Yes
 
> - Additional constraints on the use of RD are needed to = facilitate the=20 mapping, such as limiting the length of identifiers, requiring the = presense of=20 the "rt" attribute,
>    requiring the use of "ins" and "exp". What = is=20 mandatory in RD?
Yes. Considering the current length limites of DNS/DNS-RD, it may = be=20 realistic to use DNS or DNS-SD to resolve a RD server instead of CoAP = server or=20 resources. 
 
> - The rd-dns-sd draft can refer to RD normatively and publish = in the=20 same time frame, since the 2 documents will both be working group = adopted and=20 have good support.
>    The RD document will not need to refer to = the=20 RD-DNS-SD document normatively.
If DNS-SD is tried to resolve a CoAP server or resources, a = separate=20 document is better.
 
 
> The second question was to clarify the mapping itself, and its = use=20 case. We had several enlightening discussions, which I will try to = summarize=20 here.
> What is DNS-SD mapping and how does it work? What are the use = cases=20 and what assumptions do they drive?
 
> The big bit seems to be service discovery vs. resource = discovery
> The use case for DNS-SD is service discovery across broad = network=20 scope, including mesh and bridged/routed networks.
> The use case for RD is fine grain resource discovery using = hyperlinks,=20 as part of a REST client-server state machine. Clearly these are mostly=20 complementary use cases,
> and it is easy to build service discovery on top of REST. = Resource=20 Directories are themselves REST servers and can respond to multicast = discovery=20 queries,
> but have no well defined discovery proxy for routed and = bridged=20 networks. Once the RD address is known, it can participate in REST = interactions=20 through unicast transactions.
 
> The use case for RD to DNS-SD mapping is in making DNS-SD = services=20 discoverable as RD registered endpoints and links, and to make RD = registered=20 endpoints and links discoverable
> as DNS-SD services.
I do not agree that  =E2=80=9Cmaking DNS-SD services = discoverable as RD=20 registered endpoints and links, and to make RD registered endpoints and = links=20 discoverable as DNS-SD services.=E2=80=9D
 
My suggestion is just to make a RD server discoverable as DNS-SD = service.=20
 
>Based on this, a system could bootstrap resource discovery by=20 advertizing the resource directory location(s) usind DNS-SD and the link = mapping=20 to RD services; e.g. links
> with "rt=3Dcore.rd;rt=3Dcore.rd-lookup-res;core.rd-lookup-ep" = etc. would=20 be registered in an RD and exported to DNS-SD. Other RD services in the = network=20 would expose links
> to the RD services that were discovered over DNS-SD. In this = way, all=20 of the RD services that are only reachable using unicast could be = discovered in=20 "local" RD services.
> DNS-SD would be used to keep all of the RD service locations=20 discoverable through RD on local network scope.
 
> A number of assumptions and requirements for the = mapping:
> Links registered in RD for export to DNS-SD use the "rt" link=20 attribute for translation to DNS service type name and transmitted as a = SRV=20 record.
> Link context, consisting of scheme+authority+port, will be = translated=20 to a DNS service location and transmitted as a PTR record.
> The remaining information in the link, or perhaps the entire = link,=20 will be transmitted in DNS-SD as a TXT record.
 
> Based on these discussion, I am recommending that the DNS-SD = mapping=20 to RD links be taken up in a separate document, to normatively refer to = the RD=20 document,
> and be published in the same time frame in order to enable = systems to=20 use both RD and DNS-SD together.
 
After all, making a RD server discoverable as DNS/DNS-SD service = does not=20 bread the existing rules or add anything new to the existing Internet=20 nodes. 
For the a RD server as a node fuctioning for resolution, it is tied = to=20 DNS/DNS-SD, but it works only for CoAP node or resource resolution. =
 
Regards,
 
Gengyu WEI
Network Technology Center
School of Computer =
Beijing=20 University of Posts and Telecommunications
 
From: Michael Koster
Sent: Friday, April 07, 2017 11:03 PM
To: Kerry=20 Lynn ; peter van der Stok ; Carsten Bormann ; = Zach = Shelby ; Jaime=20 Jim=C3=A9nez ; Christian Ams=C3=BCss =
Subject: [core] Continuing the Resource Directory and DNS-SD = discussion
 
Hi,=20
 
The last discussion as I recall from the CoRE meeting was around 3=20 points:
 
1. Using DNS-SD to find a resource directory
 
2. Providing "ins" and "exp" link attributes
 
3. Specifying DNS-SD mapping to links in the RD document
 
We have already decided for points 1 and 2 within the scope of the = RD=20 document. We are discussing whether the DNS-SD mapping should be = published in=20 the RD document.
 
At IETF 98 we had two discussions..
 
First, should DNS-SD mapping be included in the RD draft?
 
This question can be informed by the requirements for the mapping = itself=20 and the expected use case of the mapping.
 
Based on the discussion below, there is a case to be made for = publishing=20 the mapping or RD links to DNS-SD records as a separate document.
 
- DNS-SD is not required to use RD. It would not be helpful to = couple RD=20 and DNS-SD unnecessarily by creating intra-document dependencies.
- A good use scenario and introductory explanation is needed, = describing=20 the relationship of RD to DNS-SD, which may be better served in its own=20 document.
- Additional constraints on the use of RD are needed to facilitate = the=20 mapping, such as limiting the length of identifiers, requiring the = presense of=20 the "rt" attribute, requiring the use of "ins" and "exp". What is = mandatory in=20 RD?
- The rd-dns-sd draft can refer to RD normatively and publish in = the same=20 time frame, since the 2 documents will both be working group adopted and = have=20 good support. The RD document will not need to refer to the RD-DNS-SD = document=20 normatively.
 
There is a github repository with this work in progress and issues=20 tracking:
RD document: https://github.com= /core-wg/resource-directory
RD to DNS-SD mapping document: https://github.com/core-wg/= rd-dns-sd
 
The second question was to clarify the mapping itself, and its use = case. We=20 had several enlightening discussions, which I will try to summarize = here.
 
What is DNS-SD mapping and how does it work? What are the use cases = and=20 what assumptions do they drive?
 
The big bit seems to be service discovery vs. resource = discovery
 
The use case for DNS-SD is service discovery across broad network = scope,=20 including mesh and bridged/routed networks.
 
The use case for RD is fine grain resource discovery using = hyperlinks, as=20 part of a REST client-server state machine. Clearly these are mostly=20 complementary use cases, and it is easy to build service discovery on = top of=20 REST. Resource Directories are themselves REST servers and can respond = to=20 multicast discovery queries, but have no well defined discovery proxy = for routed=20 and bridged networks. Once the RD address is known, it can participate = in REST=20 interactions through unicast transactions.
 
The use case for RD to DNS-SD mapping is in making DNS-SD services=20 discoverable as RD registered endpoints and links, and to make RD = registered=20 endpoints and links discoverable as DNS-SD services.
 
Based on this, a system could bootstrap resource discovery by = advertizing=20 the resource directory location(s) usind DNS-SD and the link mapping to = RD=20 services; e.g. links with = "rt=3Dcore.rd;rt=3Dcore.rd-lookup-res;core.rd-lookup-ep"=20 etc. would be registered in an RD and exported to DNS-SD. Other RD = services in=20 the network would expose links to the RD services that were discovered = over=20 DNS-SD. In this way, all of the RD services that are only reachable = using=20 unicast could be discovered in "local" RD services. DNS-SD would be used = to keep=20 all of the RD service locations discoverable through RD on local network = scope.
 
A number of assumptions and requirements for the mapping:
 
Links registered in RD for export to DNS-SD use the "rt" link = attribute for=20 translation to DNS service type name and transmitted as a SRV = record.
 
Link context, consisting of scheme+authority+port, will be = translated to a=20 DNS service location and transmitted as a PTR record.
 
The remaining information in the link, or perhaps the entire link, = will be=20 transmitted in DNS-SD as a TXT record.
 
Based on these discussion, I am recommending that the DNS-SD = mapping to RD=20 links be taken up in a separate document, to normatively refer to the RD = document, and be published in the same time frame in order to enable = systems to=20 use both RD and DNS-SD together.
 
 
 
 

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0049_01D2B380.385DC1A0-- From nobody Tue Apr 11 21:04:54 2017 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 C8563126B71; Tue, 11 Apr 2017 21:04:45 -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 OyZA3icPqMiG; Tue, 11 Apr 2017 21:04:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFD012009C; Tue, 11 Apr 2017 21:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3C44YFs013672; Wed, 12 Apr 2017 06:04:34 +0200 (CEST) Received: from client-0052.vpn.uni-bremen.de (client-0052.vpn.uni-bremen.de [134.102.107.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w2r0L04mjzDHMj; Wed, 12 Apr 2017 06:04:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> Date: Wed, 12 Apr 2017 06:04:33 +0200 Cc: weigengyu , art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 513662673.384077-8d9577bc6a7635a03537385cb9593471 Content-Transfer-Encoding: quoted-printable Message-Id: <9302A268-50CF-4688-A79D-8343E5B9B7CE@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 04:04:46 -0000 On Apr 12, 2017, at 04:42, Mark Nottingham wrote: >=20 > So, is COAP using WebSockets for browser access, or for firewall = traversal? The paper below seems to indicate the latter, and so the = original question remains. Can=E2=80=99t answer that for Gengyu, but the term =E2=80=9Cfirewall=E2=80= =9D occurs in the CoAP over TCP abstract, not in the CoAP over = WebSockets one. I continue to maintain that for CoAP over WebSockets the access to CoAP = proxies from browsers is the motivating case. (Yes, these could also be = HTTP to CoAP cross-protocol proxies, but there are impedance mismatches = here; e.g., for a browser application that wants to observe a CoAP = resource.) > Also, the assertions about firewalls are interesting; we're hearing = very different assertions in the discussions of QUIC (e.g,. 90%+ success = rates for UDP protocols). Apart from the backend motivation, the main motivation for CoAP over TCP = was easier NAT traversal (UDP bindings are timed out much faster in most = NATs). This may extend to other middleboxes, including firewalls that = build (and then time out) UDP-based state. I=E2=80=99m not sure the QUIC numbers transfer to this use case very = well, as QUIC is mostly used for web page access from browsers, so short = NAT binding timeouts don=E2=80=99t matter that much. For a sensor that = needs to be accessed every 30 minutes, these are much more of an issue. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 12 01:24:40 2017 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 35359129AD4 for ; Wed, 12 Apr 2017 01:24:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149198547921.15657.11746802776905651225.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 01:24:39 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:24:39 -0000 Changed milestone "Representing CoRE Link Collections in JSON submitted to IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/core/about/ From nobody Wed Apr 12 02:52:00 2017 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 BF77A131511; Wed, 12 Apr 2017 02:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 2AV3p0dfm7GK; Wed, 12 Apr 2017 02:51:42 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C3131526; Wed, 12 Apr 2017 02:51:41 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 12 Apr 2017 11:51:35 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 11:51:39 +0200 From: "Kovatsch Matthias" To: Mark Nottingham , Carsten Bormann CC: "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsbAL4XGhCj4NBUOslxkUkswmRKG+Oc0AgAD5ZgCAAkm54A== Date: Wed, 12 Apr 2017 09:51:38 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> In-Reply-To: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.195.112.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:51:45 -0000 RGVhciBNYXJrDQoNCj4gT0suIEp1c3QgY3VyaW91cyAtLSBpcyB0aGVyZSBhIHN0cm9uZyBtb3Rp dmF0aW9uIGhlcmU/IEl0IHNlZW1zIHZlcnkgb2RkIHRvIHR1bm5lbA0KPiBIVFRQLWxpa2Ugc2Vt YW50aWNzIG92ZXIgYSBjdXN0b20gVURQIHByb3RvY29sIChDT0FQKSBvdmVyIFdlYlNvY2tldHMg b3Zlcg0KPiBIVFRQIGFnYWluLCByYXRoZXIgdGhhbiBqdXN0IHVzaW5nIEhUVFAgKHdoaWNoIEFJ VUkgeW91IGFscmVhZHkgaGF2ZSBhIG1hcHBpbmcNCj4gdG8pLg0KDQpUaGUgbW90aXZhdGlvbiBp cyB0byBjb25uZWN0IHRoZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCB0byB0aGUgV2ViIGJyb3dz ZXIuIElkZWFsbHksIG9uZSB3b3VsZCB1c2UgSFRUUCBmcm9tIHRoZSBicm93c2VyIHRvIHRhbGsg dG8gYSBIVFRQLUNvQVAgY3Jvc3MtcHJveHksIHdoaWNoIGluIHR1cm4gdGFsa3MgdG8gdGhlIGNv bnN0cmFpbmVkIGRldmljZS4gVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IEhUVFAgbmV2ZXIgcHJv cGVybHkgYW5kIHVuaXF1ZWx5IHNvbHZlZCBzZXJ2ZXIgcHVzaCwgd2hpY2ggaXMgcXVpdGUgY3J1 Y2lhbCBmb3IgcmVzb3VyY2UtY29uc3RyYWluZWQgZGV2aWNlcyBhbmQgSW9UIHVzZSBjYXNlcy4g VGh1cy0tLWV2ZW4gYmV5b25kIHRoZSBDb1JFIHVzZSBjYXNlLS0tcGVvcGxlIHJlc29ydCB0byBX ZWJTb2NrZXRzLiBTaW5jZSBXZWJTb2NrZXRzIGFyZSBqdXN0IGEgYnJvd3NlciB2ZXJzaW9uIG9m IFRDUCwgcGVvcGxlIGFsc28gaGF2ZSB0byBpbnZlbnQgdGhlaXIgb3duIHByb3RvY29sIGV2ZXJ5 IHRpbWUuLi4gVGhpcyBpcyB3aGVyZSBDb0FQLW92ZXItV2ViU29ja2V0cyBoZWxwcywgb2YgY291 cnNlIHdpdGggdGhlIHByaW1hcnkgZm9jdXMgdG8gc2VhbWxlc3NseSBjb25uZWN0IHRvIGNvbnN0 cmFpbmVkIGRldmljZXMuDQoNCkkgYW0gbm90IHN1cmUgd2hhdCBpcyB0aGUgcHJlZmVycmVkIHdh eSB0byBzb2x2ZSB0aGUgYXN5bmMgY29tbXVuaWNhdGlvbiBpc3N1ZSBvZiBIVFRQLiBTZXJ2ZXIg U2VudCBFdmVudHMsIGZvciBpbnN0YW5jZSwgYXJlIGFscmVhZHkgcHJldHR5IGNsb3NlIHRvIHRo ZSBPYnNlcnZlIG1lY2hhbmlzbS4gTWF5YmUgd2UgY291bGQgcHJvcGVybHkgZml4IHRoZSBwdXNo IHN1cHBvcnQgb2YgSFRUUCB0byBjb3VudGVyIHRoZSBlbmRsZXNzIHN0YWNraW5nIG9mIHByb3Rv Y29scyBhIGJpdD8NCg0KQmVzdCByZWdhcmRzDQpNYXR0aGlhcw0K From nobody Wed Apr 12 03:06:28 2017 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 DB6F7131559; Wed, 12 Apr 2017 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.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 aUfiBIwyP8fX; Wed, 12 Apr 2017 03:06:25 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFBD131546; Wed, 12 Apr 2017 03:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491991584; d=isode.com; s=june2016; i=@isode.com; bh=+GpEPL5/0zpcK40iiymiYtDj5GeLhe4qhSu0Wkc4aac=; 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=ohEPv9wp6nyWJwNXZ0bjUkzYIdlpY0CaIisF+xe4aG23DPHpU1NwXByoSReA1oGYUUAwyp UxyimK903SkKTHpS4d6p7E7aclHKu8HAp8mBxg8aHupooA9IEH6M/6XxhS8AY4lCZHr8/x 2QeFD/SRfeOCviPvkZJ2jDHhYTerdfk=; Received: from [172.20.1.215] ((unknown) [62.232.206.186]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 12 Apr 2017 11:06:24 +0100 X-SMTP-Protocol-Errors: NORDNS To: Kovatsch Matthias , Mark Nottingham , Carsten Bormann References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> Cc: "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" From: Alexey Melnikov Message-ID: Date: Wed, 12 Apr 2017 11:06:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:06:27 -0000 Hi Matthias, On 12/04/2017 10:51, Kovatsch Matthias wrote: > Dear Mark > >> OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel >> HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over >> HTTP again, rather than just using HTTP (which AIUI you already have a mapping >> to). > The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices. > > I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit? We have a WG for this: https://datatracker.ietf.org/wg/webpush/about/ From nobody Wed Apr 12 03:09:41 2017 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 AFE47131546; Wed, 12 Apr 2017 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWnK_MNT7dyb; Wed, 12 Apr 2017 03:09:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 D6304131574; Wed, 12 Apr 2017 03:09:37 -0700 (PDT) Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AD4B22E261; Wed, 12 Apr 2017 06:09:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Wed, 12 Apr 2017 20:09:21 +1000 Cc: Kovatsch Matthias , Carsten Bormann , "art@ietf.org" , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:09:41 -0000 [ cutting down the CC a bit ] > On 12 Apr 2017, at 8:06 pm, Alexey Melnikov = wrote: >=20 > Hi Matthias, >=20 >=20 > On 12/04/2017 10:51, Kovatsch Matthias wrote: >> Dear Mark >>=20 >>> OK. Just curious -- is there a strong motivation here? It seems very = odd to tunnel >>> HTTP-like semantics over a custom UDP protocol (COAP) over = WebSockets over >>> HTTP again, rather than just using HTTP (which AIUI you already have = a mapping >>> to). >> The motivation is to connect the constrained environment to the Web = browser. Ideally, one would use HTTP from the browser to talk to a = HTTP-CoAP cross-proxy, which in turn talks to the constrained device. = The problem here is that HTTP never properly and uniquely solved server = push, which is quite crucial for resource-constrained devices and IoT = use cases. Thus---even beyond the CoRE use case---people resort to = WebSockets. Since WebSockets are just a browser version of TCP, people = also have to invent their own protocol every time... This is where = CoAP-over-WebSockets helps, of course with the primary focus to = seamlessly connect to constrained devices. >>=20 >> I am not sure what is the preferred way to solve the async = communication issue of HTTP. Server Sent Events, for instance, are = already pretty close to the Observe mechanism. Maybe we could properly = fix the push support of HTTP to counter the endless stacking of = protocols a bit? > We have a WG for this: > https://datatracker.ietf.org/wg/webpush/about/ Well, yes and no. My understanding is that web push is designed for a = very specific use case / deployment scenario, and it is likely not = appropriate for other uses. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 12 03:17:12 2017 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 15D7C13156F; Wed, 12 Apr 2017 03:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 1wIti_YFikCH; Wed, 12 Apr 2017 03:17:02 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D410128AB0; Wed, 12 Apr 2017 03:16:59 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 12 Apr 2017 12:16:53 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 12:16:57 +0200 From: "Kovatsch Matthias" To: Mark Nottingham , Alexey Melnikov CC: Carsten Bormann , "art@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSs3TkWi82eiIOykGDazObnipNOqHBg/mw Date: Wed, 12 Apr 2017 10:16:56 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B558B2B97A@MBX210.d.ethz.ch> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.195.112.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:17:04 -0000 > >> I am not sure what is the preferred way to solve the async communicati= on > issue of HTTP. Server Sent Events, for instance, are already pretty close= to the > Observe mechanism. Maybe we could properly fix the push support of HTTP t= o > counter the endless stacking of protocols a bit? > > We have a WG for this: > > https://datatracker.ietf.org/wg/webpush/about/ >=20 > Well, yes and no. My understanding is that web push is designed for a ver= y > specific use case / deployment scenario, and it is likely not appropriate= for other > uses. This is also my conclusion about this variant of HTTP push. Best wishes Matthias From nobody Wed Apr 12 03:53:38 2017 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 5D2EA1315FD; Wed, 12 Apr 2017 03:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tutfi.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 suNNgl9JGG52; Wed, 12 Apr 2017 03:53:17 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0106.outbound.protection.outlook.com [104.47.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C33131601; Wed, 12 Apr 2017 03:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r95wy0QdwwLsVIXJegmBBR+rVOAzHNUNSAeIy09VDLM=; b=fE/g04rNgjUrtN7mP+0OUgm92UmPfBUeFBYUDIrD4wQ8j5qkyl6rtk2lnK5SgUlB/o5+cvxsR6jhN7xP1bAVGppOuj9uiSjdF36KtzR+07EkbCKe7AqEfNIdRivLHyoz1niuXU+nak3x8Ue7Ie80c7Rlsf/wOLIT9konyjKdumg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tut.fi; Received: from Bilhanans-MacBook-Pro.local (88.114.43.235) by AM3PR02MB1074.eurprd02.prod.outlook.com (2a01:111:e400:c405::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Wed, 12 Apr 2017 10:53:08 +0000 To: Carsten Bormann , Mark Nottingham References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> <9302A268-50CF-4688-A79D-8343E5B9B7CE@tzi.org> CC: weigengyu , , , , From: Bill Silverajan Message-ID: Date: Wed, 12 Apr 2017 13:53:05 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9302A268-50CF-4688-A79D-8343E5B9B7CE@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [88.114.43.235] X-ClientProxiedBy: VI1PR0802CA0004.eurprd08.prod.outlook.com (2603:10a6:800:aa::14) To AM3PR02MB1074.eurprd02.prod.outlook.com (2a01:111:e400:c405::16) X-MS-Office365-Filtering-Correlation-Id: edff1787-f36b-456c-3983-08d481921b7c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM3PR02MB1074; X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 3:8YiXnG6Au1lTLkEQLBHF2M+cZXcy9DR5jI2SPVqvhMrZ4Xp2MPT1yxTywzAZWBY1yYCz6vJdOa50AcPboFBbA6pbh4M2ofAW7vzUulttbdCKHRAMQlsliErc9HGHfza0olvTiq++AdVlcOUweY58g3/EFD5dHqm8WVbb0XxNMOlTqwiYKmE89lJ4fgmLnTRZ48EA+P5ZYpC2BaNVpkzd7iQuDYXYeQ/RpjTTT5ahDAuqZRm/eCMsnmbtquOWrBMJ73HkqI7ODc2qh+TnwEuMfnashWVUHQcQIgqy6w1RQ3npH/4YBdP1uQc2VZi4K4Y600tRMhucXBCQZgamVS5KPQ==; 25:qZUsMtca7ILoKCKS/oO1AU1LuiKfNixAJnt48bfZR3yABqg4qXDwTz3mMZBfNxdLq/qQK8/1JhBXjcIWzsNMD2lTxvlfzZoFALf6zgGLgQPukYN+3iX42tqByTDVjuSwbQv1IMsID3CXQYQL+URvS6YP2bKJVW/+nrQi0PG+I9wNYreGyakCo08as8kQKcpvY3o17nqCfHpAnj+ep6d8+Q7ojBWQ/q6+UXgT5iXP6QsTRFcjEzv1RwGuUgk/PfuyV3cI3chGYD+8U3yDW415WIvoNIE5UqLsSNL14FkV062cJkFRFnmJnTk+828AncGl+lkQaRnvp78eIz8nhobaoX2PBrAn5PkazVcorSMmu6x8+Zlmlrswm90jDZjfCGwDchOHIHx2TqyQ358ceEBXnDNEh9KEeNAhnAxPWf1hUyze+vNemTrRDzR3N+h2c+c4HvVkuGB9GRi2nJkQpBLAoA== X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 31:iBJN8djrE6b4Sxq2D1rC52XvAe9fpeaHsQpUB/VWLmXY4Gh8hDjPHtPkMBkZ+J6svGURSdHBZ9RmHI7so9mRsOZlS01102f9KCNohSfhwpbYAtfFPyDGrDns2aeRZbV/+MaZnV1sfs41cT73fLEAL4fKa6XP276FQbJArOj+7iQplGEYR+ieSiWunWbrrtBh1UN1385EIS/P3O+fWoQlrPcC8FnjptF+FUtune5LCZuANUQqX/TwbX/k5cbj9WF7; 20:H1QAz0S7U6ARvGBK6IguwHiDOHtWzFjPVK9wQAm0lslKXQCJXCq1GGRlR6cZqj96xh4KMmcQ95XlBQVDUaV2j9beFdYI7nMfPw83bOyXoksDJCfnyKlBkeJV4AqeDr6v9ORjNje9TO4+Wt8jzH89LFT+bUOr1cx/ihaYOd2vTzmOEPI9uVXWxYTyWQEDpvCsHFXiBJCbnC09FYme22K3B6wwrRnq1rLhZ4CTERUJLt2MtkYrvQVkIJGb9jjqkt5z X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR02MB1074; BCL:0; PCL:0; RULEID:; SRVR:AM3PR02MB1074; X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 4:P4EvM01zvSlXwAn4K2bwO33lfK4rF0+RWgaXZZerGSzrkdpt4678Qfncwdmvu7g3hIcoPtzIIUPPyXlsWv3GTbf2SQXDi7/kafgEr2wkKO73fEq5EyABGJTTsfa8xJR00+opISC84T8fjNmqanz0exai14wswUNDYsSGN30u12NgjqFSV45J4/xatIk/Js52SXSvFuw15mF4IjEgp+AUfOdDRMdUCyuiIeQEFMNbNzxGUKr8C05+Z4x5ZTX282HTpIYzVvkaASEM3jaCqJPWtnpdFdtf/b4DbO7sGPb5PTfb53+1GCehaetSaZsO27lDVQ64AMXBwPwrreEJmdW5gsaI1Ecb0IsPwQjlkIAoCzk5hLDTA5uDlcbD/WNYOg3IZQEmcbw34Q45DrCwms9LxXjG04Pl19NAPQ6NB0v2ng0QeISG6vWOOTS1b5Ct3NbNAmC0V+VpDapfSjQKb87OAJjyEm6xcDi/OibXFqcS8BQwVvBTTZYkgzjbdNPuuYWdmRkoDXeNxZ+kaDk8WINYapMB8sUJ6ELmNuCEhTms1wg3CdxbxLGGPm1ifJFY9ExrPcCjiEW86vYhh5NElxydVcUjKD5kbpgJuiAgpPK8pm1W0MhgFYK4MONOb0xL8CU5CCUd8HJ2aOTk5YKB+22nuA0zun8eBqdOzu0cS2v4JO2engROFuCJ73eWf6WXt/OFQk0LBsQA1fMq+nYclGWSKKq3nN1fZwOIcxhw6qz0qmz/bIkuac4nfrELjw/2ZzrKvyIcbY7yZgmcAIRhHfT50ntUzQQWjaIT0AokF9ErZYka2L3jQKgEKNBJxw3TT7FFw/h3AO/cE1IfEppE5nyj2g== X-Forefront-PRVS: 027578BB13 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(24454002)(4326008)(230783001)(50466002)(6506006)(38730400002)(50986999)(7736002)(31696002)(81166006)(54356999)(76176999)(86362001)(8676002)(74482002)(305945005)(31686004)(6246003)(42186005)(6116002)(3846002)(5660300001)(53936002)(6486002)(6512007)(54906002)(229853002)(6666003)(2950100002)(33646002)(4001350100001)(66066001)(2906002)(53546009)(2870700001)(25786009)(189998001)(36756003)(47776003)(23676002)(83506001)(65806001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR02MB1074; H:Bilhanans-MacBook-Pro.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQUjAyTUIxMDc0OzIzOkJMYjBZeWhrU0F6dmt3WjVGM1c5bGxTUmYz?= =?utf-8?B?b1Ird0FJY1F6ZFR0VzhVYXQ0TENyM2VBeTFlNmhMOENKSnNhYmdiYUhUQU9U?= =?utf-8?B?L25YYm1aVlo4MmxTTldqU0lyS0M1aElhQkQrb0NUYkF3Y3NyVzVPUkRRNFVY?= =?utf-8?B?YmM2V2RIOVIxdXBhTEc0QUxvTjV5VzF2Yi9keUI4VmdsS2xySjlBcXp6RkhR?= =?utf-8?B?Mjk4T0FoWXpRMlBaNlNKZ2F6SEd2eFp3Wlk1VzVSZzJITFg1WTIxTHR5NEdl?= =?utf-8?B?N21Iam1kZzhGdUxJSit1NXhEWVYwa3VVTElVYUUyRWpDUmJ6bFpia2x4RXlF?= =?utf-8?B?Z1Q0LzhmQUR1UTF2ZUJ3RDkrNm9CbS9QREh4NGJuTkloU0VIQngwcEVZcVhQ?= =?utf-8?B?Z0ZyVUI3ZXd1dWRuVE1XZm56a2VrdzNmb0t6c0xwMWxpYzlYQThHZE4ydzBK?= =?utf-8?B?QlNDWTQyNVJPOTU4RFA0aHNicnlPSGpqVmJtWTJUMzY1MVF6OTkwRG5McFlF?= =?utf-8?B?SWlTRXZEYU5sck9lYTN6RmpFeDJxQTBuWG8vS2hFR3k5eTZNckYzdFNCa2xy?= =?utf-8?B?UDZwMDI1S1VjOEZMM1MwRHlDVGduVjhOY3NpUFBjQUxPaVppa3k2RC9aRE4z?= =?utf-8?B?UzNOVmdqMXBqUlBOV2FKeXRpYWxndEhPTm0yajNiN1pQVkdYaHgzYjJrM1o3?= =?utf-8?B?bUVlOGNrb3J4UnV0NTRybW5tdGNVaUkvakMzRlJxcmV5M0Q0SW04K3B1dm5R?= =?utf-8?B?d1VtcDhwaVpacHhpV0Z4MC9OaW1VVno2Nm9PeFdtaW9hUjQ3Y2tUazNaRHdx?= =?utf-8?B?bVRJV0FUaldJa0xJZWt0MVhlNTBMZko2OUxLRHgrN3M2ZXZvekNiTjJ4d3Nl?= =?utf-8?B?L3FaalVXTXJrdEUxRzJNNHpxZUZWV1BpSFhPN2h6SzdsR2YzdTdJa1lxN2tI?= =?utf-8?B?Mzhwd3FmSzZXNHhsMHAwWkZmaWxRTnRObG1SdkVhQ2VlN3pxT1pkZW5aNklT?= =?utf-8?B?VHA0NitjaWRpV1c1SUZEQ1o0MGdtWnBsTENDUUcyUU56UW82a2ZhZCtGQk1W?= =?utf-8?B?dnhBMHlRQmgwL2lYOUppNlZIQWJRWGNJM2dpTElEYmR1UkxLTnUzL0xNcUx0?= =?utf-8?B?THVOMHlMd2NvTDhqUVJCNDhnb1FsZCswTldNSDJoalBOMmo4aWRCNlFwank1?= =?utf-8?B?TnZpOUJ1akp5Z1QxZ3g2ZngrNTJzd2pwZUp0MlkvTDNscFJXZGdwUE5aeWYy?= =?utf-8?B?Ui9VVS8xdW9ETjdYcThXcXo1SjhVcFFwcEJqKzNIODMwbjBVY1ZxcG5vS3RK?= =?utf-8?B?VEFkZEtQbENtY2REcGdpNGdqVWpTSkVranhSS3h5Y1JyQURVZWE0eVdueGZV?= =?utf-8?B?YktCZGEzak5wbGtsZktmNnhIeFFyNlJkTjBZRHlqK082RlFqSm5sN1QrclJJ?= =?utf-8?B?TnUwSWRJWkNFUnBFWnVhdnpqa0NhU1l4aG85Qms5cDFWZW1FSktiQjR1Nkls?= =?utf-8?B?MjR0Y3grcGRPdTEwalp4NlEvTnpROHZlSG16RGlPUGI5NFB2M2VSRVY3eTVV?= =?utf-8?Q?zsSXRm2Ev2RQulgagqf+xGZ1rwv/r6vlVc7MBn7Fxn/M=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 6:TRVc5W4Ukguue5/CDr9bG1N5RyqL2cBy4m2Xxkqm9KAmut0+FV9h3IsoH52DDf54TtQN3Tb/lIVfwWJMzg792fuZxjvmsEVAA7YWXm0a2KjgOqUwmJFElKUDcttcPNSt7tT7AIXkraKrCHRRniCysN6BeGm5Fla14AxhpVCbK1FQHfTB6IIrMQPMCGqJg9ZVYYeQbQ7CkyQuCovQMmPd8Q24ClYX3fub9JRhJrHOisK26XaNIylBmaaWyxm00AIeQnfdMJeW+1t/RX3c0iqbx5XOHlYk5UOpQzArtJtg38j1coCDS/2vVo4sTG1GTA1mLH64Nyam4vqRCqRvjRtygUjie8CWwDNPjkrgzHNbN/EhReQmZ+cUhDVaq3U19SXEZdL7j7YC8dy/PAKZSWdZQ7dE8AkBZJ7Pkj+mcTPerxmuNKhxU6oALnVtzJf4KaHsuEV+GRU6wDP0h2rNMtxWRQ==; 5:f+DyIRWpqnCA0KOOt68qNU6mhFAlc3VS/wrWObmIq3+a+tZ2+3X8N3FjYWiFJJlTN5UJic3geI/vPKttITzjoxDJ3Qf8D7XR3TbwDdn9Sb785KFAEfds5QmVsxU1qutWitpOQ/24UkI2QkwD1ywtTg==; 24:Ho1j5gdevsUmkWKEP5Z5eYOrJSizLiL+lBzsSy43FMoNi4TjkJrZqrnw0q6OWXpYwLiERnAZJpYQBpy7Xi0G2r0zZtNNyfaxq1nRDAA58H4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 7:BMWymjTfhiQi18T7YTRc8Yd0bLZFD/MF/mjEnFR8QKqZUdUkaRp1n7Y+MLJYmh+TTJRyBOh5sbJDyPlgRQnjPdYm5zCLBMerylL/q/PEPoH953B3q9bmzyeFVJfSBnoAp752gC3UbEXO5KkzPuT1VOyoAHXWO51f7eJXFy/EWr2IbwmVPz8jfudCAaSjSaT+eyttdKMCvjBXOdpVD2m1idTvD0+D75Sacy2VnzQRNN6YQaqQG14PEPKIvEjwOQwwo8VF+SNft5axw9Z2v8utUlROTzty0fjja45klACcjZtpM/lHn38ybQde9hGUzVuFn8x3plvemCouiBa1IhNG1A== X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2017 10:53:08.5800 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR02MB1074 Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:53:19 -0000 Hello, On 12/04/17 07:04, Carsten Bormann wrote: > On Apr 12, 2017, at 04:42, Mark Nottingham wrote: >> So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains. > Can’t answer that for Gengyu, but the term “firewall†occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one. > > I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case. (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.) > Carsten's right. The primary use case which motivated us to undertake the work were for browser access, and for sandboxed web applications that want to use CoAP-based communication to a end-point, but are restricted from using system-level APIs such as TCP or UDP socket libraries. Matthias (in a forked version of this message thread) also mentioned where we saw benefits in allowing CoAP over Websockets to reach constrained devices. While the work was progressing however, we did become aware of minor use cases where using CoAP over Websockets can provide an advantage: Reaching constrained nodes residing in domains where end users may lack the authority to configure middleboxes to allow new services over TCP/UDP. This is commonplace in particularly restrictive and firewalled networks that otherwise allow traditional messaging, email and web-based services. However, I need to emphasise this is a minor use case. Best regards, Bill From nobody Wed Apr 12 05:35:09 2017 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 CB8B11316AA; Wed, 12 Apr 2017 05:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCO3EDOtX0nf; Wed, 12 Apr 2017 05:35:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAEC1316B0; Wed, 12 Apr 2017 05:35:04 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-d6-58ee1ef6a816 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 2B.2A.27378.6FE1EE85; Wed, 12 Apr 2017 14:35:02 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Wed, 12 Apr 2017 14:35:02 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: "iccrg@ietf.org" , "tcpm@ietf.org" , "michawe@ifi.uio.no" Thread-Topic: Heads up on the upcoming WGLC for COCOA Thread-Index: AQHSs4k0mnjKYz30k0+Zp7QNidIepA== Date: Wed, 12 Apr 2017 12:35:01 +0000 Message-ID: <23333C37-60FB-41FD-B43B-EDC75F7BBFDB@ericsson.com> Reply-To: "core@ietf.org WG" Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7pe43uXcRBo8m61nse7ue2eLzx8Ws Fj/O7mS12HZyPpMDi8eSJT+ZPFavfsgcwBTFZZOSmpNZllqkb5fAlbF6zy22gqkaFZu6lrE2 MP5S62Lk5JAQMJGYf3MrUxcjF4eQwHpGiVeHt7JAOEsYJe68a2IBqWITcJb49KyRHcQWEVCT aJ30iq2LkYODWaBY4mtrFEhYWMBA4vDeKUwQJaYSSxtPskLYehLTT51gA7FZBFQltt9bygxi 8wrYS0y/PxVsjJCAjsSFdhGQMKOAmMT3U2vAxjALiEvcejKfCeJOAYkle84zQ9iiEi8f/2OF sJUk1h7ezgJRnyzx9mcf1HhBiZMzn7BMYBSehWTULCRls5CUzQJ7RlNi/S59iBJFiSndD9kh bA2J1jlzoWxriZfPrrEjq1nAyLGKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzDODm75rbqD 8fIbx0OMAhyMSjy8CQ/fRAixJpYVV+YeYpTgYFYS4VW/DBTiTUmsrEotyo8vKs1JLT7EKM3B oiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBUWDx/JX3WKcye3K5uvyJNb9Qbqti4V5n/smN Q6BI63Wlnkr4vmxj7onX8vd94+F69c3UU82uJWCvctfqpOKPEz7NSGL8Kqi+QudeyRl+tYtS bivTJZQnLFjx1cRZJ5Mpwu3PFq2eiWyyHaqp9X7xM8Q3hp73yrgq1Litq/awQHaxjF7PzYlK LMUZiYZazEXFiQBqIepirwIAAA== Archived-At: Subject: [core] Heads up on the upcoming WGLC for COCOA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:35:07 -0000 --_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ29SRSBXRywNCg0KdGhpcyBpcyBqdXN0IGEgaGVhZHMgdXAgZm9yIHRoZSB1cGNvbWluZyBX R0xDIGZvciAiQ29BUCBTaW1wbGUgQ29uZ2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2NvYS0wMQ0KDQpOb3Rl IHRoYXQgdGhlcmUgaXMgc3RpbGwgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgdG8ga2Vl cCB0aGUgYXBwZW5kaXhlcyBvciBub3QsIGFuZCB0aGF0IHRoZXJlIGlzIHRpbWUgdG8gZ2V0IG90 aGVyIGNvbW1lbnRzIGJlZm9yZSBXR0xDLg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50 ZWQgbXVsdGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29u LCBpdOKAmWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuDQoNClRvIElDQ1JHLCBhcyB5 b3Ugbm93IGFscmVhZHksIHRoaXMgd2FzIHByZXNlbnRlZCBxdWl0ZSBzb21lIHRpbWUgYWdvLCBi ZWxvdyBpcyB0aGUgbGlua3MgdG8gdGhlIHNlc3Npb24gYW5kIHRoZSBzbGlkZXMuDQoNClNlc3Np b246IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL2ljY3JnLmh0bWwNClByZXNl bnRhdGlvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRl cy05Mi1pY2NyZy0yLnBkZg0KDQpCZXR3ZWVuIHRoZSB0d28gc2Vzc2lvbnMgdGhlIG1haW4gZGlm ZmVyZW5jZSBpcyB0aGUgYWRkaXRpb24gb2YgdGhlIGFwcGVuZGl4ZXM6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29jb2EtMDEudHh0DQoNCkNp YW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg0K --_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQ29SRSBXRywNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnRoaXMgaXMganVzdCBh IGhlYWRzIHVwIGZvciB0aGUgdXBjb21pbmcgV0dMQyBmb3IgJnF1b3Q7Q29BUCBTaW1wbGUgQ29u Z2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvY29h LTAxIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvY29hLTAxPC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIHNvbWUgZGlzY3Vz c2lvbiBhYm91dCB3aGV0aGVyIHRvIGtlZXAgdGhlIGFwcGVuZGl4ZXMgb3Igbm90LCBhbmQgdGhh dCB0aGVyZSBpcyB0aW1lIHRvIGdldCBvdGhlciBjb21tZW50cyBiZWZvcmUgV0dMQy4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50ZWQgbXVs dGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29uLCBpdOKA mWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UbyBJQ0NSRywgYXMgeW91 IG5vdyBhbHJlYWR5LCB0aGlzIHdhcyBwcmVzZW50ZWQgcXVpdGUgc29tZSB0aW1lIGFnbywgYmVs b3cgaXMgdGhlIGxpbmtzIHRvIHRoZSBzZXNzaW9uIGFuZCB0aGUgc2xpZGVzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2Vzc2lvbjom bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QcmVzZW50YXRpb246Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1pY2Ny Zy0yLnBkZiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xp ZGVzL3NsaWRlcy05Mi1pY2NyZy0yLnBkZjwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJldHdlZW4gdGhlIHR3byBzZXNz aW9ucyB0aGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoZSBhZGRpdGlvbiBvZiB0aGUgYXBwZW5kaXhl czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4dCIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4 dDwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkNpYW8hPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQot IC0gSmFpbWUgSmltw6luZXo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_-- From nobody Wed Apr 12 05:38:33 2017 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 1FDE1129AB8; Wed, 12 Apr 2017 05:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdyZgMZYDdiI; Wed, 12 Apr 2017 05:38:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00E71316B7; Wed, 12 Apr 2017 05:38:17 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-ed-58ee1fb8faa4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 6C.C0.21650.8BF1EE85; Wed, 12 Apr 2017 14:38:16 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Wed, 12 Apr 2017 14:38:01 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: "iccrg@irtf.org" , "tcpm@ietf.org" , "michawe@ifi.uio.no" Thread-Topic: Heads up on the upcoming WGLC for COCOA Thread-Index: AQHSs4mfQjrNXAdDOU6pskdy1cCI4w== Date: Wed, 12 Apr 2017 12:38:01 +0000 Message-ID: <623D63BA-FCEA-411C-B0C0-03EF4978FA47@ericsson.com> Reply-To: "core@ietf.org WG" Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7qO4O+XcRBqf+Clrse7ue2eLAgp3s Fj/O7mS12HZyPpMDi8eSJT+ZPFavfsjsMXnjYbYA5igum5TUnMyy1CJ9uwSujJ7dF9gKzipX vNu9kqmB8ZBSFyMnh4SAicTO+y/Yuxi5OIQE1jNK7Jt7kBXCWcIo8XHCdRaQKjYBZ4lPzxrZ QWwRATWJ1kmv2EBsZoFiiSn/vzGC2MIChhL/ftxmgagxk1i1Yg0jhK0nsX5jM5jNIqAqcb9x MpDNwcErYC9xb1UciCkkoCNxoV0EpIJRQEzi+6k1TBDTxSVuPZnPBHGngMSSPeeZIWxRiZeP /7FC2EoSK7ZfYoSoT5b4uWcDWD2vgKDEyZlPWCYwCs9CMmoWkrJZSMpmAV3BLKApsX6XPkSJ osSU7ofsELaGROucuVC2tcSHp9uZkNUsYORYxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREY cQe3/LbawXjwueMhRgEORiUe3oSHbyKEWBPLiitzDzFKcDArifCqXwYK8aYkVlalFuXHF5Xm pBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwNjM8KA1t+/ywaOaBwoF/yxf0dWm +1vCqX3fugXHI+J11IQivKvWvzngs/u/xL2FBhd049028M57xbZE1mzuS6U9bKxntBjuTOs/ FxD5RVmp+qlIp4WlcdPpZK/vGgfWd6nEzzz4fuLG/nA9rW+TcvNe3WdY9oHr2yeOHdo39dQT Wd70Hpm/ZbMSS3FGoqEWc1FxIgCztiY0tAIAAA== Archived-At: Subject: [core] Heads up on the upcoming WGLC for COCOA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:38:20 -0000 --_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ29SRSBXRywNCg0KdGhpcyBpcyBqdXN0IGEgaGVhZHMgdXAgZm9yIHRoZSB1cGNvbWluZyBX R0xDIGZvciAiQ29BUCBTaW1wbGUgQ29uZ2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2NvYS0wMQ0KDQpOb3Rl IHRoYXQgdGhlcmUgaXMgc3RpbGwgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgdG8ga2Vl cCB0aGUgYXBwZW5kaXhlcyBvciBub3QsIGFuZCB0aGF0IHRoZXJlIGlzIHRpbWUgdG8gZ2V0IG90 aGVyIGNvbW1lbnRzIGJlZm9yZSBXR0xDLg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50 ZWQgbXVsdGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29u LCBpdOKAmWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuDQoNClRvIElDQ1JHLCBhcyB5 b3Ugbm93IGFscmVhZHksIHRoaXMgd2FzIHByZXNlbnRlZCBxdWl0ZSBzb21lIHRpbWUgYWdvLCBi ZWxvdyBpcyB0aGUgbGlua3MgdG8gdGhlIHNlc3Npb24gYW5kIHRoZSBzbGlkZXMuDQoNClNlc3Np b246IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL2ljY3JnLmh0bWwNClByZXNl bnRhdGlvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRl cy05Mi1pY2NyZy0yLnBkZg0KDQpCZXR3ZWVuIHRoZSB0d28gc2Vzc2lvbnMgdGhlIG1haW4gZGlm ZmVyZW5jZSBpcyB0aGUgYWRkaXRpb24gb2YgdGhlIGFwcGVuZGl4ZXM6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29jb2EtMDEudHh0DQoNCkNp YW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg== --_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQ29SRSBXRywNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnRoaXMgaXMganVzdCBh IGhlYWRzIHVwIGZvciB0aGUgdXBjb21pbmcgV0dMQyBmb3IgJnF1b3Q7Q29BUCBTaW1wbGUgQ29u Z2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvY29h LTAxIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvY29hLTAxPC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIHNvbWUgZGlzY3Vz c2lvbiBhYm91dCB3aGV0aGVyIHRvIGtlZXAgdGhlIGFwcGVuZGl4ZXMgb3Igbm90LCBhbmQgdGhh dCB0aGVyZSBpcyB0aW1lIHRvIGdldCBvdGhlciBjb21tZW50cyBiZWZvcmUgV0dMQy4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50ZWQgbXVs dGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29uLCBpdOKA mWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UbyBJQ0NSRywgYXMgeW91 IG5vdyBhbHJlYWR5LCB0aGlzIHdhcyBwcmVzZW50ZWQgcXVpdGUgc29tZSB0aW1lIGFnbywgYmVs b3cgaXMgdGhlIGxpbmtzIHRvIHRoZSBzZXNzaW9uIGFuZCB0aGUgc2xpZGVzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2Vzc2lvbjom bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QcmVzZW50YXRpb246Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1pY2Ny Zy0yLnBkZiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xp ZGVzL3NsaWRlcy05Mi1pY2NyZy0yLnBkZjwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJldHdlZW4gdGhlIHR3byBzZXNz aW9ucyB0aGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoZSBhZGRpdGlvbiBvZiB0aGUgYXBwZW5kaXhl czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4dCIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4 dDwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkNpYW8hPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNz PSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KLSAtIEphaW1lIEpp bcOpbmV6PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_-- From nobody Thu Apr 13 02:46:03 2017 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 6E70E13147E; Thu, 13 Apr 2017 02:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndiHdTVuNzLL; Thu, 13 Apr 2017 02:45:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089D0131473; Thu, 13 Apr 2017 02:45:51 -0700 (PDT) X-AuditID: c1b4fb2d-c616898000004c5d-73-58ef48ce6d4e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 53.67.19549.EC84FE85; Thu, 13 Apr 2017 11:45:50 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.339.0; Thu, 13 Apr 2017 11:45:49 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id B053C4EB0B; Thu, 13 Apr 2017 12:48:24 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 1E6B84E94F; Thu, 13 Apr 2017 12:48:24 +0300 (EEST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , 'Core' , "6tisch@ietf.org" <6tisch@ietf.org> References: <002101d2b21d$3ff5ba30$bfe12e90$@augustcellars.com> CC: Jim Schaad , =?UTF-8?Q?Christian_Ams=c3=bcss?= From: Mohit Sethi Message-ID: <1bc3ed76-245a-f8fe-ae72-a424102ba682@ericsson.com> Date: Thu, 13 Apr 2017 12:45:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3688C8F35B5769A69DBEFCB9" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdTPecx/sIgxVTpCyW3e1jtlh+4TmL xb6365ktVk//zubA4rFxznQ2j6377zJ5LFnykymAOYrLJiU1J7MstUjfLoEro2f3BbaC1mmM Fc2rZzI2MF4v6GLk4JAQMJH49jm3i5GLQ0hgPaNE461tjBDODkaJJS03oZxNjBKfXy1jhXAW Mkr0Xz4E5HByCAtYSNzZc4AdxBYRaGCU2HcbatYSRokZV3rYQBLMAjkSz1feAStiE9CT6Dx3 nBnE5hWwl5hwsIkJxGYRUJXYcWoNC4gtKhAh8bBzFztEjaDEyZlPwOKcApYSnbPvM0LMDJOY uvElWFxCQE3i6rlNYDOFBNQltnYcYJzAKDQLSfssJC0QtoXEzPnnGSFsbYllC18zQ9gaEq1z 5rJD2PISzVtnMy9gZFvFKFqcWlycm25krJdalJlcXJyfp5eXWrKJERg1B7f81t3BuPq14yFG AQ5GJR7eB0bvIoRYE8uKK3MPMUpwMCuJ8F7QAgrxpiRWVqUW5ccXleakFh9ilOZgURLnddh3 IUJIID2xJDU7NbUgtQgmy8TBKdXAuOJp4XQvk+C/0i6ZddfKLvz8F2by63XxZq0lp7/dVlrt /oVhZ8nn9j3NF9q51vkcnDfl3JK+Fad6K6vVfymHfDvy+aqCE9OBPxMUBc7d3+i5jnf2lIaS wIW5S+zm7FLhWKudb7v/YAdHVHJlmu8Fo7IfO+vcvl84znRA59ORICfV76F+M8T5fZRYijMS DbWYi4oTAV0bcC2WAgAA Archived-At: Subject: Re: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:45:56 -0000 --------------3688C8F35B5769A69DBEFCB9 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi G=C3=B6ran, Jim and Christian Thanks for responding to my question. @G=C3=B6ran: both 1) use EDHOC or 2= )=20 generate large random identifiers, are the same thing. How are they any=20 different? I went through EDHOC draft and it says that sender id is S_V=20 which is variable length session identifier (=3D generate large random=20 identifier). I am afraid simply waving off the problem as out of scope may lead to=20 some (many) inter interoperability issues. If the Sender ID is variable=20 length, different manufacturers may implement it very differently and=20 could cause collision with just 2-3 devices. If they are generated in=20 software at run time, you can still do something about it, but if it is=20 burnt into the device, then there is no way to recover from . At the=20 very least there could be better guidance. I also think it would make=20 sense to have a minimum length specified and some=20 recommendations/guidelines on how it is generated. I would also like to know what are the concrete affects of a collision? --Mohit On 04/11/2017 08:43 AM, G=C3=B6ran Selander wrote: > Hello Mohit, > > Christian and Jim already provided answers, let me just provide=20 > pointers to the relevant sections. > > OSCOAP: > =E2=80=94 > The requirements on the security context parameters are here: > https://tools.ietf.org/html/draft-ietf-core-object-security-02#section-= 3.3 > Two methods for establishing unique sender IDs are presented: 1) use=20 > EDHOC or 2) generate large random identifiers. > The former allows for the use of short sender IDs. > > > Multicast OSCOAP: > =E2=80=94 > In Multicast OSCOAP (Secure group communication for CoAP) the=20 > requirements on the security context parameters are here: > https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01#secti= on-2 > It is the responsibility of the Group Manager to establish and manage=20 > the security context, which includes the sender IDs, but how the=20 > assignment is done is out of scope. The uniqueness of sender IDs in=20 > this draft follows from OSCOAP, but since you asked I think we should=20 > add a sentence to this draft stressing that. > > > G=C3=B6ran > > > From: core > on=20 > behalf of Jim Schaad > > Date: Monday 10 April 2017 at 19:09 > To: Mohit Sethi >, 'Core' >, "6tisch@ietf.org "=20 > <6tisch@ietf.org > > Subject: Re: [core] Question about AEAD nonce uniqueness > > There is not a problem with dealing with nonce uniqueness in this > draft because each entity is going to be assigned to a unique key > for transmissions. The transport key is derived from the PSK and > the sender ID. Sender IDs will be unique based on the enrollment > protocol in the group as each entity will have a unique identifier.= > > Jim > > *From:*core [mailto:core-bounces@ietf.org] *On Behalf Of *Mohit Set= hi > *Sent:* Monday, April 10, 2017 4:51 AM > *To:* Core >; 6tisch@ietf.org > > *Subject:* [core] Question about AEAD nonce uniqueness > > Hi OSCoAP authors > > I was trying to read the OSCoAP and 6tisch minimal security > drafts. I have a question about the AEAD nonce uniqueness. RFC > 5116 says that: > > When there are multiple devices performing encryption using a s= ingle > > key, those devices must coordinate to ensure that the nonces ar= e > > unique. A simple way to do this is to use a nonce format that > > contains a field that is distinct for each one of the devices > > So my obvious question is how is the AEAD nonce uniqueness > ensured. The PSK is known to at least two parties (more in case of > some uses such as multicast OSCoAP > https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)?= ? > > The draft currently says that AEAD Nonce uniqueness is ensured > with sequence numbers and sender context which is essentially the > sender ID. But how do you ensure that the two parties have > different sender ID. Especially since sender ID is not fixed > length. I guess there will be other problems in case of sender ID > collisions? > > as Sender IDs are currently used, they are mutually agreed-upon like th= e > rest of the security context (key, algorithm etc); in other words, they= > are explicitly given to a device by the mechanism that also distributes= > the key. > > Best regards > Christian > > --=20 > Christian Ams=C3=BCss | Energy Harvesting Solution= s GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/= > | ATU68476614 > > --------------3688C8F35B5769A69DBEFCB9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Göran, Jim and Christian

Thanks for responding to my question. @Göran: both 1) use EDHOC or 2) generate large random identifiers, are the same thing. How are they any different? I went through EDHOC draft and it says that sender id is S_V which is variable length session identifier (= generate large random identifier).

I am afraid simply waving off the problem as out of scope may lead to some (many) inter interoperability issues. If the Sender ID is variable length, different manufacturers may implement it very differently and could cause collision with just 2-3 devices. If they are generated in software at run time, you can still do something about it, but if it is burnt into the device, then there is no way to recover from . At the very least there could be better guidance. I also think it would make sense to have a minimum length specified and some recommendations/guidelines on how it is generated.

I would also like to know what are the concrete affects of a collision?

--Mohit


On 04/11/2017 08:43 AM, Göran Selander wrote:
Hello Mohit,

Christian and Jim already provided answers, let me just provide pointers to the relevant sections.

OSCOAP:
—
The requirements on the security context parameters are here:
Two methods for establishing unique sender IDs are presented: 1) use EDHOC or 2) generate large random identifiers. 
The former allows for the use of short sender IDs.


Multicast OSCOAP:
—
In Multicast OSCOAP (Secure group communication for CoAP) the requirements on the security context parameters are here:
It is the responsibility of the Group Manager to establish and manage the security context, which includes the sender IDs, but how the assignment is done is out of scope. The uniqueness of sender IDs in this draft follows from OSCOAP, but since you asked I think we should add a sentence to this draft stressing that.


Göran


From: core <core-bounces@ietf.org> on behalf of Jim Schaad <ietf@augustcellars.com>
Date: Monday 10 April 2017 at 19:09
To: Mohit Sethi <mohit.m.sethi@ericsson.com>, 'Core' <core@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [core] Question about AEAD nonce uniqueness

There is not a problem with dealing with nonce uniqueness in this draft because each entity is going to be assigned to a unique key for transmissions.  The transport key is derived from the PSK and the sender ID.  Sender IDs will be unique based on the enrollment protocol in the group as each entity will have a unique identifier.

 

Jim

 

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core <core@ietf.org>; 6tisch@ietf.org
Subject: [core] Question about AEAD nonce uniqueness

 

Hi OSCoAP authors

I was trying to read the OSCoAP and 6tisch minimal security drafts. I have a question about the AEAD nonce uniqueness. RFC 5116 says that:

   When there are multiple devices performing encryption using a single
   key, those devices must coordinate to ensure that the nonces are
   unique.  A simple way to do this is to use a nonce format that
   contains a field that is distinct for each one of the devices

So my obvious question is how is the AEAD nonce uniqueness ensured. The PSK is known to at least two parties (more in case of some uses such as multicast OSCoAP https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)??

The draft currently says that AEAD Nonce uniqueness is ensured with sequence numbers and sender context which is essentially the sender ID. But how do you ensure that the two parties have different sender ID. Especially since sender ID is not fixed length. I guess there will be other problems in case of sender ID collisions?
as Sender IDs are currently used, they are mutually agreed-upon like the
rest of the security context (key, algorithm etc); in other words, they
are explicitly given to a device by the mechanism that also distributes
the key.

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614



--------------3688C8F35B5769A69DBEFCB9-- From nobody Thu Apr 13 07:47:07 2017 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 5F6CD129481; Thu, 13 Apr 2017 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 ucrBtVSv0t8N; Thu, 13 Apr 2017 07:47:05 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56624129409; Thu, 13 Apr 2017 07:47:04 -0700 (PDT) X-AuditID: c1b4fb30-abffb70000006667-8c-58ef8f65d397 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 66.C0.26215.56F8FE85; Thu, 13 Apr 2017 16:47:02 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Thu, 13 Apr 2017 16:47:00 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Mark Nottingham CC: weigengyu , Carsten Bormann , "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsa/qwMrkOzw42UWHLUrHT1G7O6G+Oc0AgAD5ZwCAAbONAIAAASMAgAJc0QA= Date: Thu, 13 Apr 2017 14:47:00 +0000 Message-ID: <180A6A3D-2242-4D71-AAC7-4180284398E4@ericsson.com> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> In-Reply-To: <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_180A6A3D22424D71AAC74180284398E4ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2K7rm5a//sIgxWL5SxW3PWwODLlLqvF vrfrmS32vXnHYvFs43wWi/WfHjNaTJn5id2B3aPx1F42jyVLfjJ5bFz8ndVj2qLMAJYoLpuU 1JzMstQifbsErowNq46wFbyWqFjxOL6BsUmii5GTQ0LARGLj2U+sXYxcHEIC6xklfl79ygbh LGGU6Gn9xQRSxSbgLPHpWSM7iC0ioCzxff4SFpAiZoFWJomWrdPBEsICARJL224ANXAAFQVK bDmkD1HvJ7Hk6TRmEJtFQFVi0Zw2sHJeAXuJyc/mQ21uZ5KY+X4P2DJOARuJWy+eMILYjAJi Et9PrQGLMwuIS9x6Mp8J4mwBiSV7zjND2KISLx//Y4WwlSQalzxhhahPlvh+9TUjxDJBiZMz n7BMYBSZhWTULCRls5CUzQJ6gVlAU2L9Ln2IEkWJKd0P2SFsDYnWOXOhbGuJpkWnWJDVLGDk WMUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGLEHt/w22MH48rnjIUYBDkYlHt6ElvcRQqyJ ZcWVuYcYJTiYlUR4p7UBhXhTEiurUovy44tKc1KLDzFKc7AoifM67rsQISSQnliSmp2aWpBa BJNl4uCUamDUMZ5vWszzU/z/sdVyZfF3FpboXLkjE+A982v6Mv8NO0smbN+z59RC3z///z7d l1Y2e2f2kvPtfzt6chZIbaxT1awLK2V7IPdm0fKnh2wmZk5+k1H/+X30lfLyiOP1RywtDtyd +1DveJbAOvOqSymnNxy871L/WzpNu+zvN3HJ7x2R3krOSka/lFiKMxINtZiLihMBtD8nhNQC AAA= Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 14:47:06 -0000 --_000_180A6A3D22424D71AAC74180284398E4ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCmNvdWxkIHlvdSBzaGFyZSBkYXRhIHNvdXJjZSBvbiB0aGF0IHBscz8gSXTigJlkIGNv bWUgaW4gaGFuZHkuDQoNCkNpYW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg0KT24gMTIgQXByIDIw MTcsIGF0IDUuNDIsIE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBt bm90Lm5ldD4+IHdyb3RlOg0KDQooZS5nLC4gOTAlKyBzdWNjZXNzIHJhdGVzIGZvciBVRFAgcHJv dG9jb2xzKS4NCg0K --_000_180A6A3D22424D71AAC74180284398E4ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4FBEA9501C975747B32AB3369FEF09FA@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5jb3VsZCB5b3Ugc2hhcmUgZGF0YSBz b3VyY2Ugb24gdGhhdCBwbHM/IEl04oCZZCBjb21lIGluIGhhbmR5LjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2lhbyE8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCi0gLSBKYWltZSBKaW3DqW5lejwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTIgQXByIDIwMTcsIGF0IDUuNDIsIE1hcmsg Tm90dGluZ2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5uZXQiIGNsYXNzPSIiPm1u b3RAbW5vdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj4oZS5nLC4NCiA5MCUmIzQzOyBzdWNjZXNzIHJhdGVzIGZvciBVRFAg cHJvdG9jb2xzKS48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_180A6A3D22424D71AAC74180284398E4ericssoncom_-- From nobody Thu Apr 13 07:50:08 2017 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 60F82129494; Thu, 13 Apr 2017 07:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 ffsugUZA0opS; Thu, 13 Apr 2017 07:49:57 -0700 (PDT) Received: from mail4.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 B34121294A2; Thu, 13 Apr 2017 07:49:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01D2B429.1CCA1430" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1492094991; h=from:subject:to:date:message-id; bh=tGA52XXAJuoj/pTrVB6Z0SAqxZeW3+EwtZ7XnLqlkR8=; b=NS73xZo/rBzf2a93xFswFC9VQEw+ZqnmBLsJON24VL0kyXm8Y2SfeZv6GfWa12A/AvfKPWBTuaX bv/0L5phkd+IYMFSMKUZyJqeRzyUH+e5aZfkw19CxOICdcWdyvjLbVU/0u4fl9/NL1ZRbILP94oWR o1SLvfADVCteiezKD3Us4OAzBJGpmRDBp1OBI+2XeiBtmlVKrvjBm2TxGmO2G2l/vpyzHDILz7nXU mvmSo/7d7VDhBeF2v/Zh1udVOAYjUcFwM9GQXHqr/l1WBpZrr9g9ypV5xJCequRWznwMy3F74nZ9t RdkBWRMvtiuis52/pLQ9kDj5KgKDF4HOFH7A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Apr 2017 07:49:50 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Apr 2017 07:49:44 -0700 From: Jim Schaad To: 'Mohit Sethi' , =?utf-8?Q?'G=C3=B6ran_Selander'?= , 'Core' , <6tisch@ietf.org> CC: =?utf-8?Q?'Christian_Ams=C3=BCss'?= References: <002101d2b21d$3ff5ba30$bfe12e90$@augustcellars.com> <1bc3ed76-245a-f8fe-ae72-a424102ba682@ericsson.com> In-Reply-To: <1bc3ed76-245a-f8fe-ae72-a424102ba682@ericsson.com> Date: Thu, 13 Apr 2017 07:39:38 -0700 Message-ID: <007001d2b463$c9243140$5b6c93c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJv4xR+uLYuNuXVlU8kA8osT/0S9QKF7EItAvmXia8CDahmyqBMlrgQ X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 14:50:00 -0000 ------=_NextPart_000_0071_01D2B429.1CCA1430 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The selection of S_X is done by party X. This means that all they need = to do is to generate =E2=80=93 either randomly or deterministically = =E2=80=93 some identifier which is currently unique for them. =20 The easiest way to do this is to have an array of N security contexts. = Choose the first slot in the array which is empty and use that index as = your identifier. If the array is full, then either grow the array or = scavenge a security context which has not been used in a while and use = that slot. This allows for identifiers that are unique to the party and = still very small. =20 The only time that one would need large random identifiers is when the = keying material is generated by a third party such as the PSK version of = EDHOC where the common PSK needs to be identified for both parties. =20 I also do not have the same problems with collisions that G=C3=B6ran and = others have. I am willing to try multiple keys in the event of a = collision and only the correct one will work. This is not unusual in = some cases already in other environments. =20 Jim =20 =20 From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]=20 Sent: Thursday, April 13, 2017 2:46 AM To: G=C3=B6ran Selander ; 'Core' = ; 6tisch@ietf.org Cc: Jim Schaad ; Christian Ams=C3=BCss = Subject: Re: [core] Question about AEAD nonce uniqueness =20 Hi G=C3=B6ran, Jim and Christian Thanks for responding to my question. @G=C3=B6ran: both 1) use EDHOC or = 2) generate large random identifiers, are the same thing. How are they = any different? I went through EDHOC draft and it says that sender id is = S_V which is variable length session identifier (=3D generate large = random identifier). I am afraid simply waving off the problem as out of scope may lead to = some (many) inter interoperability issues. If the Sender ID is variable = length, different manufacturers may implement it very differently and = could cause collision with just 2-3 devices. If they are generated in = software at run time, you can still do something about it, but if it is = burnt into the device, then there is no way to recover from . At the = very least there could be better guidance. I also think it would make = sense to have a minimum length specified and some = recommendations/guidelines on how it is generated. I would also like to know what are the concrete affects of a collision? --Mohit =20 On 04/11/2017 08:43 AM, G=C3=B6ran Selander wrote: Hello Mohit, =20 Christian and Jim already provided answers, let me just provide pointers = to the relevant sections. =20 OSCOAP: =E2=80=94 The requirements on the security context parameters are here: https://tools.ietf.org/html/draft-ietf-core-object-security-02#section-3.= 3 Two methods for establishing unique sender IDs are presented: 1) use = EDHOC or 2) generate large random identifiers.=20 The former allows for the use of short sender IDs. =20 =20 Multicast OSCOAP: =E2=80=94 In Multicast OSCOAP (Secure group communication for CoAP) the = requirements on the security context parameters are here: https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01#section= -2 It is the responsibility of the Group Manager to establish and manage = the security context, which includes the sender IDs, but how the = assignment is done is out of scope. The uniqueness of sender IDs in this = draft follows from OSCOAP, but since you asked I think we should add a = sentence to this draft stressing that. =20 =20 G=C3=B6ran =20 =20 From: core > on = behalf of Jim Schaad > Date: Monday 10 April 2017 at 19:09 To: Mohit Sethi >, 'Core' >, "6tisch@ietf.org" <6tisch@ietf.org = > Subject: Re: [core] Question about AEAD nonce uniqueness =20 There is not a problem with dealing with nonce uniqueness in this draft = because each entity is going to be assigned to a unique key for = transmissions. The transport key is derived from the PSK and the sender = ID. Sender IDs will be unique based on the enrollment protocol in the = group as each entity will have a unique identifier. =20 Jim =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Mohit Sethi Sent: Monday, April 10, 2017 4:51 AM To: Core >; 6tisch@ietf.org = =20 Subject: [core] Question about AEAD nonce uniqueness =20 Hi OSCoAP authors I was trying to read the OSCoAP and 6tisch minimal security drafts. I = have a question about the AEAD nonce uniqueness. RFC 5116 says that: When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices So my obvious question is how is the AEAD nonce uniqueness ensured. The = PSK is known to at least two parties (more in case of some uses such as = multicast OSCoAP = https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)??=20 The draft currently says that AEAD Nonce uniqueness is ensured with = sequence numbers and sender context which is essentially the sender ID. = But how do you ensure that the two parties have different sender ID. = Especially since sender ID is not fixed length. I guess there will be = other problems in case of sender ID collisions? as Sender IDs are currently used, they are mutually agreed-upon like the rest of the security context (key, algorithm etc); in other words, they are explicitly given to a device by the mechanism that also distributes the key. =20 Best regards Christian =20 --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions = GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 =20 =20 =20 ------=_NextPart_000_0071_01D2B429.1CCA1430 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The selection of S_X is done by party X.=C2=A0 This means that all = they need to do is to generate =E2=80=93 either randomly or = deterministically =E2=80=93 some identifier which is currently unique = for them.

 

The easiest way to do this is to have an array of N security = contexts.=C2=A0 Choose the first slot in the array which is empty and = use that index as your identifier.=C2=A0 If the array is full, then = either grow the array or scavenge a security context which has not been = used in a while and use that slot.=C2=A0 This allows for identifiers = that are unique to the party and still very = small.

 

The only time that one would need large random identifiers is when = the keying material is generated by a third party such as the PSK = version of EDHOC where the common PSK needs to be identified for both = parties.

 

I also do not have the same problems with collisions that = G=C3=B6ran and others have.=C2=A0 I am willing to try multiple = keys in the event of a collision and only the correct one will = work.=C2=A0 This is not unusual in some cases already in other = environments.

 

Jim

 

 

From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
Sent: = Thursday, April 13, 2017 2:46 AM
To: G=C3=B6ran Selander = <goran.selander@ericsson.com>; 'Core' <core@ietf.org>; = 6tisch@ietf.org
Cc: Jim Schaad <ietf@augustcellars.com>; = Christian Ams=C3=BCss = <c.amsuess@energyharvesting.at>
Subject: Re: [core] = Question about AEAD nonce uniqueness

 

Hi G=C3=B6ran, Jim and = Christian

Thanks for responding to my question. = @G=C3=B6ran: both 1) use EDHOC or 2) generate large random identifiers, = are the same thing. How are they any different? I went through EDHOC = draft and it says that sender id is S_V which is variable length session = identifier (=3D generate large random identifier).

I am = afraid simply waving off the problem as out of scope may lead to some = (many) inter interoperability issues. If the Sender ID is variable = length, different manufacturers may implement it very differently and = could cause collision with just 2-3 devices. If they are generated in = software at run time, you can still do something about it, but if it is = burnt into the device, then there is no way to recover from . At the = very least there could be better guidance. I also think it would make = sense to have a minimum length specified and some = recommendations/guidelines on how it is generated.

I = would also like to know what are the concrete affects of a = collision?

--Mohit

 

On = 04/11/2017 08:43 AM, G=C3=B6ran Selander = wrote:

Hello Mohit,

 

Christian and Jim already provided answers, let me = just provide pointers to the relevant = sections.

 

OSCOAP:

=E2=80=94

The requirements on the security context parameters = are here:

Two = methods for establishing unique sender IDs are presented: 1) use EDHOC = or 2) generate large random = identifiers. 

The = former allows for the use of short sender = IDs.

 

 

Multicast OSCOAP:

=E2=80=94

In Multicast OSCOAP (Secure group communication for = CoAP) the requirements on the security context parameters are = here:

It is = the responsibility of the Group Manager to establish and manage the = security context, which includes the sender IDs, but how the assignment = is done is out of scope. The uniqueness of sender IDs in this draft = follows from OSCOAP, but since you asked I think we should add a = sentence to this draft stressing that.

 

 

G=C3=B6ran

 

 

From: = core <core-bounces@ietf.org> on = behalf of Jim Schaad <ietf@augustcellars.com>
= Date: Monday 10 April 2017 at 19:09
To: Mohit Sethi = <mohit.m.sethi@ericsson.com= >, 'Core' <core@ietf.org>, = "6tisch@ietf.org" = <6tisch@ietf.org>
Subject: = Re: [core] Question about AEAD nonce = uniqueness

 

There is not a problem with dealing with nonce uniqueness in this = draft because each entity is going to be assigned to a unique key for = transmissions.  The transport key is derived from the PSK and the = sender ID.  Sender IDs will be unique based on the enrollment = protocol in the group as each entity will have a unique = identifier.

 

Jim

 

 

From: core [mailto:core-bounces@ietf.org] = On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 = 4:51 AM
To: Core <core@ietf.org>; 6tisch@ietf.org
Subject: = [core] Question about AEAD nonce = uniqueness

 

Hi OSCoAP = authors

I was trying to read the OSCoAP and 6tisch = minimal security drafts. I have a question about the AEAD nonce = uniqueness. RFC 5116 says that:

   When =
there are multiple devices performing encryption using a =
single
   key, those devices must =
coordinate to ensure that the nonces =
are
   unique.  A simple way to do =
this is to use a nonce format that
   =
contains a field that is distinct for each one of the =
devices

So my obvious question is how is the AEAD = nonce uniqueness ensured. The PSK is known to at least two parties (more = in case of some uses such as multicast OSCoAP https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)?= ?

The draft currently says that AEAD Nonce uniqueness = is ensured with sequence numbers and sender context which is essentially = the sender ID. But how do you ensure that the two parties have different = sender ID. Especially since sender ID is not fixed length. I guess there = will be other problems in case of sender ID = collisions?

as Sender IDs are = currently used, they are mutually agreed-upon like = the

rest of the security = context (key, algorithm etc); in other words, = they

are explicitly given to a = device by the mechanism that also = distributes

the = key.

 

Best = regards

Christian

 

-- =

Christian = Ams=C3=BCss          &n= bsp;           | = Energy Harvesting Solutions GmbH

founder, system = architect          &nbs= p;  | headquarter:

mailto:c.amsuess@energyharv= esting.at  | Arbeitergasse 15, A-4400 = Steyr

tel:+43-664-97-90-6-39  &nb= sp;           &nbs= p; | http://www.energyharvesting.at/<= /a>

 

------=_NextPart_000_0071_01D2B429.1CCA1430-- From nobody Thu Apr 13 07:52:56 2017 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 3B483129544 for ; Thu, 13 Apr 2017 07:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIlAOqDMIBsW for ; Thu, 13 Apr 2017 07:52:44 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3995E1294C5 for ; Thu, 13 Apr 2017 07:52:43 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 13 Apr 2017 16:52:40 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 16:52:41 +0200 From: "Kovatsch Matthias" To: Alexander Pelov , Klaus Hartke CC: Core , "t2trg@irtf.org" Thread-Topic: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version Thread-Index: AQHSsTtrL6aNZ+doiUmoAcAVC3mrcaG8/m6AgABVhQCABhJz0A== Date: Thu, 13 Apr 2017 14:52:40 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B558B2C574@MBX210.d.ethz.ch> References: In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.195.112.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 14:52:47 -0000 SGkgYWxsDQoNCkkgd2FudCB0byBwb2ludCBvdXQgdGhhdCB0aGlzIGlzIHJlbGF0ZWQgdG8gdGhl IHBhcmFtZXRlciBvcHRpb24gZGlzY3Vzc2lvbiB3ZSBoYWQgZm9yIGEgbG9uZyB0aW1lOiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9pLWNvcmUtcGFyYW1ldGVyLW9wdGlvbi0w Mw0KVGhlIHdvcmsgd2FzIGRyb3BwZWQgYmVjYXVzZSB0aGVyZSB3YXMgdG9vIG11Y2ggcmVzaXN0 YW5jZSB0byBpbmNsdWRlIHRoaXMgZmVhdHVyZSAoaXQgbGVhc3QgaW4gbXkgdW5kZXJzdGFuZGlu ZykuDQoNCkNvbWluZyBmcm9tIHRoZSBkZXNpZ24gZ3VpZGVsaW5lcyBkaXNjdXNzZWQgaW4gVDJU UkcsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdmVyc2lvbmluZyBpcyBoYW5kbGVkIHdpdGhpbiB0aGUg cmVwcmVzZW50YXRpb24gZm9ybWF0ICh3aGlsZSBhIGdvb2QgZGVzaWduIGFsc28gZW5zdXJlcyBi YWNrd2FyZCBhbmQgZm9yd2FyZCBjb21wYXRpYmlsaXR5KS4gSWYgYSByZXByZXNlbnRhdGlvbiBm b3JtYXQgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBwcmV2aW91cyB2ZXJzaW9ucywgaXQgaXMgYSBk aWZmZXJlbnQgZm9ybWF0IHRoYXQgbmVlZHMgYSBuZXcgbWVkaWEgdHlwZSwgYW5kIGhlbmNlIENv QVAgaWRlbnRpZmllci4NCihOb3RlIHRoYXQgdGhlc2UgZ3VpZGVsaW5lcyBoYXZlIG5vdCByZWFj aGVkIGNvbnNlbnN1cywgYW5kIGhlbmNlIGNhbm5vdCBiZSByZWZlcmVuY2VkLiBQbGVhc2UgYWRk IG90aGVyIHZpZXdzOyBpdCBtaWdodCBiZSBhIHZhbHVhYmxlIFQyVFJHIGRpc2N1c3Npb24uKQ0K DQpDaWFvDQpNYXR0aGlhcw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5k ZXIgUGVsb3YNCj4gU2VudDogU3VuZGF5LCA5IEFwcmlsIDIwMTcgMjI6MDENCj4gVG86IEtsYXVz IEhhcnRrZSA8aGFydGtlQHR6aS5vcmc+DQo+IENjOiBDb3JlIDxjb3JlQGlldGYub3JnPg0KPiBT dWJqZWN0OiBSZTogW2NvcmVdIE5ldyBDb0FQIE9wdGlvbnMgb24gdGhlIGhvcml6b24gLSBBY2Nl cHQtQ29udGVudC1Gb3JtYXQtDQo+IFZlcnNpb24gYW5kIENvbnRlbnQtRm9ybWF0LVZlcnNpb24N Cj4gDQo+IEhpIEtsYXVzLA0KPiANCj4gDQo+ID4gTGUgOSBhdnIuIDIwMTcgw6AgMTY6NTQsIEts YXVzIEhhcnRrZSA8aGFydGtlQHR6aS5vcmc+IGEgw6ljcml0IDoNCj4gPg0KPiA+IEFsZXhhbmRl ciBQZWxvdiB3cm90ZToNCj4gPj4gSUFOQSBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gTWlj aGFlbCBLb3N0ZXIgdG8gcmVnaXN0ZXIgdHdvIG5ldw0KPiA+PiBDb0FQDQo+ID4+IG9wdGlvbnM6 DQo+ID4+IC0gQWNjZXB0LUNvbnRlbnQtRm9ybWF0LVZlcnNpb24NCj4gPj4gLSBDb250ZW50LUZv cm1hdC1WZXJzaW9uDQo+ID4NCj4gPiBTcGVjPw0KPiA+DQo+ID4+IE9uZSBvZiB0aGUgbWFqb3Ig cXVlc3Rpb25zIHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGlzIHRoZSBmb2xsb3dpbmc6DQo+ ID4NCj4gPiBXaGF0IGFyZSB0aGUgb3RoZXIgcXVlc3Rpb25zPw0KPiANCj4gVGhlIG90aGVyIHF1 ZXN0aW9ucyBhcmUgbW9zdGx5IGRldGFpbHMgdGhhdCB3ZSBjYW4gKGVhc2lseSkgZmlndXJlIG91 dCBvbmNlIHRoZQ0KPiBtYWpvciBvbmUgaXMgYW5zd2VyZWQuIEZvciBleGFtcGxlLCBzaG91bGQg dGhlIEFjY2VwdC1Db250ZW50LUZvcm1hdC1WZXJzaW9uDQo+IGJlIFJlcGVhdGFibGUgb3IgTm90 PyAoSSBkb27igJl0IHdhbnQgdG8gZ2V0IHRvIG1vcmUgZGV0YWlscyBvbiB0aGlzIGZvciB0aGUN Cj4gbW9tZW50IC0gYW5kIHRoZXkgd2lsbCBzdXJlbHkgY29tZSB1cCBpZiBuZWNlc3NhcnkpLg0K PiANCj4gPg0KPiA+PiBXaGF0IGFyZSB0aGUgcmVhc29ucyAqTk9UKiB0byBhbGxvY2F0ZSBhIG5l dyBDb250ZW50LUZvcm1hdCBudW1iZXINCj4gPj4gKFJGQw0KPiA+PiA3MjUyKSBmb3IgZWFjaCBu ZXcgdmVyc2lvbj8gKGluIHRoZSBIVFRQIHdvcmxkLCAidmVyc2lvbiIgaXMgYSBzaW1wbGUNCj4g Pj4gcGFyYW1ldGVyIHRvIHRoZSBDb250ZW50LVR5cGUsIHNvIHdoeSBub3QgdHJlYXQgaXQgYXMg c3VjaD8pDQo+ID4NCj4gPiBOb25lPw0KPiA+DQo+ID4+IFRoZSBxdWVzdGlvbiBpcyBub3QgdHJp dmlhbCwgYXMgaXQgdG91Y2hlcyB1cG9uIGNvbnRlbnQgZm9ybWF0DQo+ID4+IG5lZ290aWF0aW9u LCBlLmcuIGhvdyAgc2hvdWxkIHRoZSBTZXJ2ZXIgdXNlIHRoZQ0KPiA+PiBBY2NlcHQtQ29udGVu dC1Gb3JtYXQtVmVyc2lvbiBpbiBvcmRlciB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIHdpbGxpbmcN Cj4gPj4gdG8gYWNjZXB0IGJvdGggYXBwbGljYXRpb24vdm5kLm9jZitjYm9yIEFORA0KPiA+PiBh cHBsaWNhdGlvbi9hcHBsaWNhdGlvbi92bmQub2NmK2Nib3I7dmVyc2lvbj0yLjAsIHdpdGggYSBw cmVmZXJlbmNlDQo+ID4+IGZvciB0aGUgbGF0dGVyPyBJbiB0aGUgc2VtYW50aWNzIG9mIHRoZSB2 ZXJzaW9uIHBhcmFtZXRlciwgdGhlIHR3byBzaG91bGQgYmUNCj4gY29uc2lkZXJlZCBjb21wbGV0 ZWx5IGluZGVwZW5kZW50L2luY29tcGF0aWJsZSB0eXBlcy4NCj4gPg0KPiA+IENvQVAgY3VycmVu dGx5IGhhcyBubyBmZWF0dXJlcyBmb3IgY29udGVudCBmb3JtYXQgbmVnb3RpYXRpb24sIG9ubHkN Cj4gPiBmb3IgdGhlIHNlbGVjdGlvbiBvZiBhbiBhdmFpbGFibGUgY29udGVudCBmb3JtYXQuIElm IGEgc2VydmVyIHdpc2hlcw0KPiA+IHRvIGluZGljYXRlIGF2YWlsYWJsZSBjb250ZW50IGZvcm1h dHMsIGl0IG5lZWRzIHRvIGRvIHNvIGluIHRoZQ0KPiA+IChoeXBlcm1lZGlhKSByZXByZXNlbnRh dGlvbi4gKFRoZSBDb0FQIEFjY2VwdCBvcHRpb24gY2FuIG9ubHkgYmUgdXNlZA0KPiA+IGluIHJl cXVlc3RzLCBub3QgaW4gcmVzcG9uc2VzLikNCj4gPg0KPiA+IEFyZSB0aGUgdHdvIG9wdGlvbnMg YSBwcm9wb3NhbCB0byBjaGFuZ2UgdGhhdD8NCj4gPg0KPiA+IE5lZWQgc3BlYy4NCj4gDQo+IFll cywgeW91IGFyZSByaWdodCBpbmRlZWQuIFRoZSAqQ2xpZW50KiBpbmRpY2F0ZXMgaW4gaXRzIENv QVAgQWNjZXB0IG9wdGlvbiB0aGUNCj4gQ29udGVudC1Gb3JtYXQgaXQgaXMgd2lsbGluZyB0byBh Y2NlcHQuIE5vdywgaWYgeW91IGhhdmUgdGhlIHNhbWUgQ29udGVudC0NCj4gRm9ybWF0LCBidXQg d2l0aCBkaWZmZXJlbnQgdmVyc2lvbnMsIHRoZW4geW91IGNvdWxkIGltYWdpbmUgaGF2aW5nIHNv bWV0aGluZw0KPiBsaWtlOg0KPiBBY2NlcHQ6IDEwMDAwICh3aGljaCBtYXBzIHRvIGFwcGxpY2F0 aW9uL2FwcGxpY2F0aW9uL3ZuZC5vY2YrY2JvcikNCj4gQWNjZXB0LUNvbnRlbnQtRm9ybWF0LVZl cnNpb246IDIuMA0KPiANCj4gSW5zdGVhZCBvZjoNCj4gQWNjZXB0OiAxMDAwMSAoYXBwbGljYXRp b24vYXBwbGljYXRpb24vdm5kLm9jZitjYm9yO3ZlcnNpb249Mi4wIHdoaWNoIHdvdWxkDQo+IG5l ZWQgdG8gYmUgcmVnaXN0ZXJlZCB0byAxMDAwMSBmb3IgZXhhbXBsZSkNCj4gDQo+IFRoZSBpbnRl bnQgaGVyZSBpcyB0byBhbHdheXMgaW5kaWNhdGUgIjEwMDAwIiBpbiB5b3VyIGh5cGVybWVkaWEg bGlua3MsIGFuZA0KPiB3aXRob3V0IGNoYW5naW5nIHRoZW0gdG8gYmUgYWJsZSB0byB1cGdyYWRl L2Rvd25ncmFkZSB0aGUgdmVyc2lvbiBvZiB0aGUNCj4gY29udGVudC1mb3JtYXQgKGUuZy4gSSBs aWtlIHRvIHRoaW5rIG9mIHRoaXMgYXMgY2hhbmdpbmcgQVBJcyAtIHlvdSB1cGdyYWRlIGEgQ2xp ZW50LA0KPiBhbmQgdGhlbiBpdCBpcyBvbiB2ZXIyIC0gYnV0IHN0aWxsIHVzaW5nIHRoZSBvcmln aW5hbCBDb250ZW50LUZvcm1hdCwgYnV0IHRoaXMgbWF5DQo+IG5vdCBiZSB0aGUgb25seSByZWFz b24gTWljaGFlbCBwcm9wb3NlcyB0aGVzZSBvcHRpb25zKS4NCj4gDQo+ID4NCj4gPj4gVGhlIGN1 cnJlbnQgd2F5IG9mIGRvaW5nIHRoaXMgd291bGQgYmUgdG8gYWxsb2NhdGUgc2VwYXJhdGUNCj4g Pj4gQ29udGVudC1Gb3JtYXQgbnVtYmVycyB0byAiYXBwbGljYXRpb24vYXBwbGljYXRpb24vdm5k Lm9jZitjYm9yIg0KPiA+PiAoMTAwMDAgYXMgaXQgc3RhbmRzIG5vdykgYW5kDQo+ID4+ICJhcHBs aWNhdGlvbi9hcHBsaWNhdGlvbi92bmQub2NmK2Nib3I7dmVyc2lvbj0yLjAiIChlLmcuIDEwMDAx KS4uIGFuZCB0aGVuDQo+IHVzZSBzb21lIGZvcm0gb2YgY29udGVudCBuZWdvdGlhdGlvbi4NCj4g Pg0KPiA+IFllcy4NCj4gPg0KPiA+PiBUaGlzIGhvd2V2ZXIgY2FuIGhhdmUgaXRzIGRpc2FkdmFu dGFnZXMsIC4uIGFuZCB0aGUgd2F5IGluZHVzdHJ5IGRvZXMNCj4gPj4gdXNlIHZlcnNpb25pbmcg aW4gc29tZSBjYXNlcyAoZS5nLiBwZW9wbGUgRE8gdXNlIHRoZSB2ZXJzaW9uDQo+ID4+IHBhcmFt ZXRlciB0byB2ZXJzaW9uIHRoZWlyIFJFU1RmdWwgQVBJcy4uIHdoaWNoIG1lYW5zLCB0aGF0IE5P VA0KPiA+PiBoYXZpbmcgc3VjaCBtZWNoYW5pc20gaW4gQ29BUCBjb3VsZCB0aGVvcmV0aWNhbGx5 IGRyaXZlIHRoZW0gdG8NCj4gPj4gcmUtcmVnaXN0ZXIgYmxvY2tzIG9mIENvbnRlbnQtRm9ybWF0 IG51bWJlcnMsIGp1c3QgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuDQo+IHRoZWlyIEFQSXMpLg0K PiA+DQo+ID4gV29ya2luZyBhcyBpbnRlbmRlZC4NCj4gPg0KPiA+PiBJbiBhbnkgY2FzZSwgd2Ug bmVlZCB0byBoYXZlIHRoaXMgZGlzY3Vzc2lvbiBkb2N1bWVudGVkIG9uIHRoZQ0KPiA+PiBtYWls aW5nIGxpc3QgKGFzIHByZXZpb3VzbHkgZGlzY3Vzc2VkIHdpdGggTWljaGFlbCksIHNvIGhlcmUg d2UgZ28uLg0KPiA+DQo+ID4gSSdtIHN1cmUgTWljaGFlbCBoYXMgYW5hbHl6ZWQgdGhlIHByb2Js ZW0sIGV2YWx1YXRlZCBkaWZmZXJlbnQgb3B0aW9ucw0KPiA+IHRvIHNvbHZlIHRoZSBwcm9ibGVt LCBhbmQgY29udGFjdGVkIHRoZSBleHBlcnRzIHdpdGggdGhlIGJlc3Qgc29sdXRpb24NCj4gPiBo ZSBjb3VsZCBmaW5kLiBIb3dldmVyLCBzaW5jZSB0aGUgaWRlbnRpZmllciBzcGFjZXMgaW4gQ29B UCBhcmUgc28NCj4gPiBzbWFsbCBhbmQgdGhlIHVucmVzdHJpY3RlZCBhZGRpdGlvbiBvZiBuZXcg Q29BUCBmZWF0dXJlcyBjYW4gbGVhZCB0bw0KPiA+IGZyYWdtZW50YXRpb24sIGV2ZXJ5IGFkZGl0 aW9uIG11c3QgYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQuIEZvciB0aGF0LA0KPiA+IGl0IGlzIHJl YWxseSBoZWxwZnVsIHRvIGVzdGFibGlzaCBhbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBwcm9ibGVt DQo+ID4gYmVmb3JlIHB1c2hpbmcgYSBwYXJ0aWN1bGFyIHNvbHV0aW9uLg0KPiANCj4gSSBhZ3Jl ZSB3aXRoIHlvdSBvbiB0aGlzLiBIYXZpbmcgdGhpcyB1bmRlcnN0YW5kaW5nIC0gYW5kIGRvY3Vt ZW50ZWQgb24gdGhlDQo+IG1haWxpbmcgbGlzdCAtIGlzIHRoZSBpbnRlbnQgb2YgdGhpcyBkaXNj dXNzaW9uLg0KPiANCj4gQWxleGFuZGVyDQo+IA0KPiANCj4gPg0KPiA+IEtsYXVzDQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNv cmUgbWFpbGluZyBsaXN0DQo+ID4gY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Thu Apr 13 09:48:37 2017 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 E5D05129AFA for ; Thu, 13 Apr 2017 09:48:34 -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 0r6E08O9fTEh for ; Thu, 13 Apr 2017 09:48:32 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C933C12951D for ; Thu, 13 Apr 2017 09:48:32 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 72so24615669pge.2 for ; Thu, 13 Apr 2017 09:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pZxNk9lLtgqwq0p+k1RBhXxuOvr/rv4QB3YANRyf83c=; b=jBqzM20g+7XMJI5hu7Q98mfxugZ0/CiyanGzEoAQa4DKrAorpCV1yaGGc4qYzrDYdV Ld+/SzLm09XCD/rfChVlvjX2SKamLF84U2rJD6PK7cHhdJbb3f7uiPfPjv38hBcHuY9x kxwoJeelwRx9LiEcviQhzXRNJaX7XfOQJ+xJJ34vKDs0EFZJcGWRpUFamR86or3bFcvL nj4Twe5ipockFA6pOumtF9F9GPvv8TIU2U0MkX/lBvt0PHdK8njgLaHn3BODjPH0DVSl /yfXEH/m37G+3WLfrq9kUCEVvqfaeo0uGe884i3rHzSnQSkNgKjGbA1ZuSUOFk+CP22c E/Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pZxNk9lLtgqwq0p+k1RBhXxuOvr/rv4QB3YANRyf83c=; b=KZGIaFPfRLEv0TOMcOYLFMlvsP4e1/USz2x91RaLDO70fj+50BXkpepPQ6IOhx6DaS /4zoldey8/tz9lWw3naDx8cz9qak4fg/ofO+X33rBcnq6nal60R10XwCKRyeLueW7FmE gxgXp6PNbtGWF7pI5EM53c1TO/9UKPAja+pLWxRajZEfBapm+ca9W7gCxL5HLJj5vNE0 lVax7NK8WPR4Z2Ro5UD8p7lyE87RhG7rv7N1m/Fq4B9qkKnVqVXx+yaeZaEqzpFixepb XGBGlTo0SP74Q60au5bnt4VAp8bWnSpH75UQhu+3MdcCO9S/x4cBMLrulxzGl/SzEr/K 80zQ== X-Gm-Message-State: AN3rC/57alvgfhiduq/5R5QoITrPXixgjsaOgOrKSCqJvcTNubnD6jX7 DVtAIyp8j9VpG1d2MQU= X-Received: by 10.84.212.130 with SMTP id e2mr5221632pli.140.1492102112459; Thu, 13 Apr 2017 09:48:32 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id u29sm43478920pfa.123.2017.04.13.09.48.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Apr 2017 09:48:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B143EC84-E02D-4466-B7BD-6229F6D7213D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Thu, 13 Apr 2017 09:48:31 -0700 Cc: Klaus Hartke , Core Message-Id: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> References: To: Alexander Pelov X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 16:48:35 -0000 --Apple-Mail=_B143EC84-E02D-4466-B7BD-6229F6D7213D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, This gets to the core of the problem as I see it. It is important to be able to construct a request header from the = information in a hypermedia control. For links to CoAP resources, we = have the content-format number. Even if we have content-format = negotiation in CoAP, there is still application awareness of content = formats. The purpose of the content format *version* is to indicate changes in = the serialization that don't impact the application compatibility, which = the system can handle transparently if it has the correct serializer.=20 One use case is to align the representations in OCF with standard IETF = content-formats over time, as we are doing with CoRE link-format = (RFC6690). Doing this may require a linear update to the OCF content = format, which already has a compatible data model, in addition to the = implicit support of a standard content format. If there is a move to = SenML serialization, for example (hypothetical), but uisng the same OCF = data model, then we will need to have an updated OCF content-format = version to track OCF versions, even though by then the server may also = be able to returnin link-format+cbor (TBD) and senml+cbor (TBD) content = format numbers, because of existing OCF applications that are aware of = the content-format number. Thus it is desireable to keep the link attribute value consistent to = avoid having to change application layer logic, which is aware of = content format numbers and may query a collection using content-format = numbers, etc. Does this make sense? Best regards, Michael > On Apr 9, 2017, at 1:00 PM, Alexander Pelov wrote: >=20 > Yes, you are right indeed. The *Client* indicates in its CoAP Accept = option the Content-Format it is willing to accept. Now, if you have the = same Content-Format, but with different versions, then you could imagine = having something like:=20 > Accept: 10000 (which maps to application/application/vnd.ocf+cbor) > Accept-Content-Format-Version: 2.0 >=20 > Instead of: > Accept: 10001 (application/application/vnd.ocf+cbor;version=3D2.0 = which would need to be registered to 10001 for example) >=20 > The intent here is to always indicate "10000" in your hypermedia = links, and without changing them to be able to upgrade/downgrade the = version of the content-format (e.g. I like to think of this as changing = APIs - you upgrade a Client, and then it is on ver2 - but still using = the original Content-Format, but this may not be the only reason Michael = proposes these options).=20 >=20 >>=20 >>> The current way of doing this would be to allocate separate = Content-Format >>> numbers to "application/application/vnd.ocf+cbor" (10000 as it = stands now) >>> and "application/application/vnd.ocf+cbor;version=3D2.0" (e.g. = 10001).. and >>> then use some form of content negotiation. >>=20 >> Yes. >>=20 >>> This however can have its disadvantages, .. and the way industry = does use >>> versioning in some cases (e.g. people DO use the version parameter = to >>> version their RESTful APIs.. which means, that NOT having such = mechanism in >>> CoAP could theoretically drive them to re-register blocks of = Content-Format >>> numbers, just to differentiate between their APIs). >>=20 >> Working as intended. >>=20 >>> In any case, we need to have this discussion documented on the = mailing list >>> (as previously discussed with Michael), so here we go.. >>=20 >> I'm sure Michael has analyzed the problem, evaluated different = options >> to solve the problem, and contacted the experts with the best = solution >> he could find. However, since the identifier spaces in CoAP are so >> small and the unrestricted addition of new CoAP features can lead to >> fragmentation, every addition must be carefully considered. For that, >> it is really helpful to establish an understanding of the problem >> before pushing a particular solution. >=20 --Apple-Mail=_B143EC84-E02D-4466-B7BD-6229F6D7213D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

This = gets to the core of the problem as I see it.

It is important to be able to construct = a request header from the information in a hypermedia control. For links = to CoAP resources, we have the content-format number. Even if we have = content-format negotiation in CoAP, there is still application awareness = of content formats.

The purpose of the content format *version* is to indicate = changes in the serialization that don't impact the application = compatibility, which the system can handle transparently if it has the = correct serializer. 

One use case is to align the representations in OCF with = standard IETF content-formats over time, as we are doing with CoRE = link-format (RFC6690). Doing this may require a linear update to the OCF = content format, which already has a compatible data model, in addition = to the implicit support of a standard content format. If there is a move = to SenML serialization, for example (hypothetical), but uisng the same = OCF data model, then we will need to have an updated OCF content-format = version to track OCF versions, even though by then the server may also = be able to returnin link-format+cbor (TBD) and senml+cbor (TBD) content = format numbers, because of existing OCF applications that are aware of = the content-format number.

Thus it is desireable to keep the link attribute value = consistent to avoid having to change application layer logic, which is = aware of content format numbers and may query a collection using = content-format numbers, etc.

Does this make sense?

Best regards,

Michael


On = Apr 9, 2017, at 1:00 PM, Alexander Pelov <alexander@ackl.io> = wrote:

Yes, you are right indeed. The *Client* = indicates in its CoAP Accept option the Content-Format it is willing to = accept. Now, if you have the same Content-Format, but with different = versions, then you could imagine having something like: 
Accept: 10000 (which maps to = application/application/vnd.ocf+cbor)
Accept-Content-Format-Version: 2.0

Instead of:
Accept: 10001 = (application/application/vnd.ocf+cbor;version=3D2.0 which would need to = be registered to 10001 for example)

The intent here is to always indicate "10000" in = your hypermedia links, and without changing them to be able to = upgrade/downgrade the version of the content-format (e.g. I like to = think of this as changing APIs - you upgrade a Client, and then it is on = ver2 - but still using the original Content-Format, but this may not be = the only reason Michael proposes these options). 


The current way of doing = this would be to allocate separate Content-Format
numbers = to "application/application/vnd.ocf+cbor" (10000 as it stands now)
and "application/application/vnd.ocf+cbor;version=3D2.0" = (e.g. 10001).. and
then use some form of content = negotiation.

Yes.

This = however can have its disadvantages, .. and the way industry does use
versioning in some cases (e.g. people DO use the version = parameter to
version their RESTful APIs.. which means, = that NOT having such mechanism in
CoAP could theoretically = drive them to re-register blocks of Content-Format
numbers, = just to differentiate between their APIs).

Working as intended.

In any case, we need to have this discussion = documented on the mailing list
(as previously discussed = with Michael), so here we go..

I'm sure Michael has analyzed the problem, evaluated = different options
to solve the problem, and contacted the = experts with the best solution
he could find. However, = since the identifier spaces in CoAP are so
small and the = unrestricted addition of new CoAP features can lead to
fragmentation, every addition must be carefully considered. = For that,
it is really helpful to establish an = understanding of the problem
before pushing a particular = solution.


= --Apple-Mail=_B143EC84-E02D-4466-B7BD-6229F6D7213D-- From nobody Thu Apr 13 10:58:31 2017 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 BA76A12EB09 for ; Thu, 13 Apr 2017 10:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTTEW6Zwl1e8 for ; Thu, 13 Apr 2017 10:58:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7589612EADC for ; Thu, 13 Apr 2017 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3DHwKna019994; Thu, 13 Apr 2017 19:58:20 +0200 (CEST) Received: from [100.69.171.177] (ip-109-40-0-49.web.vodafone.de [109.40.0.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w3pRw54mlzDJJV; Thu, 13 Apr 2017 19:58:20 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-9D7F3D59-C4DD-4AA2-ACF9-26E1F90166AA Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (14E304) In-Reply-To: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> Date: Thu, 13 Apr 2017 19:58:19 +0200 Cc: Alexander Pelov , Core , Klaus Hartke Content-Transfer-Encoding: 7bit Message-Id: <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> To: Michael Koster Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 17:58:31 -0000 --Apple-Mail-9D7F3D59-C4DD-4AA2-ACF9-26E1F90166AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think that this is indicative of a more general problem. Media types have v= arious conventions for indicating subclass relationships: the two-part notat= ion, structured syntax suffixes, but no general way to indicate that a repre= sentation is both within a larger and a more specific type. Content-format m= akes this slightly worse by hiding both the special-case mechanisms cited ab= ove and media type parameters, which are another subclassing mechanism. A f= ix might be too be able to indicate multiple content-formats. But this requi= res a bit more thinking.=20 Sent from mobile > On 13. Apr 2017, at 18:48, Michael Koster wr= ote: >=20 > Does this make sense? --Apple-Mail-9D7F3D59-C4DD-4AA2-ACF9-26E1F90166AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I think that this is indicative of a more general problem. Media types have various conventions for indicating subclass relationships: the two-part notation, structured syntax suffixes, but no general way to indicate that a representation is both within a larger and a more specific type. Content-format makes this slightly worse by hiding both the special-case mechanisms cited above and media type parameters, which are another subclassing mechanism.  A fix might be too be able to indicate multiple content-formats. But this requires a bit more thinking. 

Sent from mobile

On 13. Apr 2017, at 18:48, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Does this make sense?
--Apple-Mail-9D7F3D59-C4DD-4AA2-ACF9-26E1F90166AA-- From nobody Thu Apr 13 13:22:58 2017 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 1F326127076 for ; Thu, 13 Apr 2017 13:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 YIzbKJjixQvf for ; Thu, 13 Apr 2017 13:22:55 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EDA12773A for ; Thu, 13 Apr 2017 13:22:55 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id o126so33086753pfb.3 for ; Thu, 13 Apr 2017 13:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=OwUWh+/s4UrBm+ZsusNG6tG7XgZEyTHryoYQi6rczlw=; b=Xx8h1PcoMeTpMCMvozldNx+yOr9lE2rYlMKKBNiZgTz/eBxKDS6EpUhKHNN3wSmPk5 ONqsXdfHHvcgs2K0YVGf+/nKHUUc3/g65IHBIsTmd5WS5A1cm2VJXRn4OxkVTLyjVNGD ir5LLiWl0j1wU3oFm4IXNb9wvKA0hOOIrrGOkLHeGG/nbBf2Qo+jURlGP5nYjDtEBjAM mHfT+DpdpPbS0yPaJcmFJpUclwggKlwe9Geh9iJ487n0k4hFSU1V1wqcZckY6mVMyNWh 1YeqnPkw80Naf3GYzDOIBHuFwgtYetfdp1dCXTV25XUtEvBSSq5FoJEOJvj567IfGkqe f02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=OwUWh+/s4UrBm+ZsusNG6tG7XgZEyTHryoYQi6rczlw=; b=syMYcBIR1MoITb7s/UMZxUU40RbMA9+8SxvyeY4g0XcXqqpZcxMlbd4BdwJML/dW2U jeeX6GBpcXc3DZq/ErYaFU8CekPDVPERgi0l3hEapjDa/SZDC3FbtGw4Q5Er7kh6RTj2 t3TGi1NhZnfKMxJeu/5qTyk8j0TLofO1e2f8dUMJvPQu6Y9Y3a9KUlzyTRqb9203DvaB 0H6kLX8v5/hW+ejHa63/m0K9oFtt6PSCdlOA6W+2rPBl9hwI4Kv39Iu5tfYTmcxZT/2B e3A+VFBEc+NJmB7CNjTPXgs4+1RQnESKMSmLku5qWWbGjq7lzFnNoYP3BPWyA4t8l3c/ 2JUg== X-Gm-Message-State: AN3rC/5HkyaHJyPFdIg4uR74/3xfwIpX6ero5hv09Us4MO+SPciO4rEo HLOd4VfO5aTmUA== X-Received: by 10.99.2.5 with SMTP id 5mr4269915pgc.205.1492114975040; Thu, 13 Apr 2017 13:22:55 -0700 (PDT) Received: from ?IPv6:2601:646:8a01:e6b3:397f:db65:272f:a219? ([2601:646:8a01:e6b3:397f:db65:272f:a219]) by smtp.gmail.com with ESMTPSA id 21sm43960928pfl.129.2017.04.13.13.22.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Apr 2017 13:22:54 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_E011AC7A-F5FD-469F-92FB-5BDF06AE40A4" From: Robert Quattlebaum In-Reply-To: <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> Date: Thu, 13 Apr 2017 13:22:53 -0700 Cc: Michael Koster , core , Alexander Pelov , Klaus Hartke Message-Id: References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:22:57 -0000 --Apple-Mail=_E011AC7A-F5FD-469F-92FB-5BDF06AE40A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is a bit of a long shot, but may be worth bringing up... Apple came up with a hierarchical content-type mechanism they called the = "Universal Type Identifier": = https://developer.apple.com/library/content/documentation/FileManagement/C= onceptual/understanding_utis/understand_utis_conc/understand_utis_conc.htm= l = This itself doesn't solve the problem, but if there was a hierarchical = registry for assigning numeric identifiers at each node (OID style), = then the file type could be specified as a sequence of numbers. = Applications would then only need to verify that the file type has the = appropriate prefix (if well designed, this could just be an opaque = string of bytes) and ignore anything they don't understand after. For example, let's assume the registry has some classes like this: public.data 0: public.text 0: public.html 1: public.plain-text 0: net.daringfireball.markdown 2: public.json 0: com.example.iot-foo 1: public.image 0: public.jpeg 1: public.tiff So, for the content type com.example.iot-foo, the type would be encoded = as "0.2.0". A TIFF image would be "1.1". If a browser has a nice JSON pretty-printer but has no idea what = com.example.iot-foo is, then it would just check for the "0.2" type = prefix, ignoring anything after. The problem is that the UTI concept never seemed to quite make it to the = IETF, or any other standards body (even though it was seemingly designed = in such a way as to make standardization somewhat easy). Nonetheless, = the concept above might be useful to consider if we are actually = thinking about digging up this can of worms. If we go this route, perhaps some sort of CBOR encoding would be = appropriate. Realistically, this is a big change, if taken as described. I wonder if = there is a way to build this concept on top of what we already have? -- RQ > On Apr 13, 2017, at 10:58 AM, Carsten Bormann wrote: >=20 > I think that this is indicative of a more general problem. Media types = have various conventions for indicating subclass relationships: the = two-part notation, structured syntax suffixes, but no general way to = indicate that a representation is both within a larger and a more = specific type. Content-format makes this slightly worse by hiding both = the special-case mechanisms cited above and media type parameters, which = are another subclassing mechanism. A fix might be too be able to = indicate multiple content-formats. But this requires a bit more = thinking.=20 >=20 > Sent from mobile >=20 > On 13. Apr 2017, at 18:48, Michael Koster > wrote: >=20 >> Does this make sense? > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_E011AC7A-F5FD-469F-92FB-5BDF06AE40A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It is a bit of a long shot, but may be worth bringing = up...

Apple came up = with a hierarchical content-type mechanism they called the = "Universal Type Identifier":

https://developer.apple.com/library/content/documentation/FileM= anagement/Conceptual/understanding_utis/understand_utis_conc/understand_ut= is_conc.html

This itself doesn't solve the problem, but if there was a = hierarchical registry for assigning numeric identifiers at each node = (OID style), then the file type could be specified as a sequence of = numbers. Applications would then only need to verify that the file type = has the appropriate prefix (if well designed, this could just be an = opaque string of bytes) and ignore anything they don't understand = after.

For = example, let's assume the registry has some classes like this:

  • public.data
    • 0: public.text
        • 0: public.html
      • 1: = public.plain-text
        • 0: = net.daringfireball.markdown
      • 2: = public.json
        • 0: = com.example.iot-foo
    • 1: public.image
      • 0: = public.jpeg
      • 1: public.tiff

So, for the = content type com.example.iot-foo, the type would be encoded as "0.2.0". = A TIFF image would be "1.1".

If a browser has a nice JSON = pretty-printer but has no idea what com.example.iot-foo is, then it = would just check for the "0.2" type prefix, ignoring anything = after.

The = problem is that the UTI concept never seemed to quite make it to the = IETF, or any other standards body (even though it was seemingly designed = in such a way as to make standardization somewhat easy). Nonetheless, = the concept above might be useful to consider if we are actually = thinking about digging up this can of worms.

If we go this route, perhaps some sort = of CBOR encoding would be appropriate.

Realistically, this is a big change, if = taken as described. I wonder if there is a way to build this concept on = top of what we already have?

-- RQ

On = Apr 13, 2017, at 10:58 AM, Carsten Bormann <cabo@tzi.org> = wrote:

I think that = this is indicative of a more general problem. Media types have various = conventions for indicating subclass relationships: the two-part = notation, structured syntax suffixes, but no general way to indicate = that a representation is both within a larger and a more specific type. = Content-format makes this slightly worse by hiding both the special-case = mechanisms cited above and media type parameters, which are another = subclassing mechanism.  A fix might be too be able to indicate = multiple content-formats. But this requires a bit more = thinking. 

Sent from mobile

On 13. Apr 2017, at 18:48, Michael Koster = <michaeljohnkoster@gmail.com> wrote:

Does= this make = sense?
___________________________________________= ____
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_E011AC7A-F5FD-469F-92FB-5BDF06AE40A4-- From nobody Fri Apr 14 03:34:42 2017 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 D6CEE1286CA; Fri, 14 Apr 2017 03:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScwJgasBWIHw; Fri, 14 Apr 2017 03:34:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F16E12708C; Fri, 14 Apr 2017 03:34:23 -0700 (PDT) X-AuditID: c1b4fb2d-89fff70000004c5d-01-58f0a5ab8478 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 39.92.19549.BA5A0F85; Fri, 14 Apr 2017 12:34:21 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Fri, 14 Apr 2017 12:34:55 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Mohit Sethi M , 'Core' , "6tisch@ietf.org" <6tisch@ietf.org>, "ace@ietf.org" CC: Jim Schaad , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] Question about AEAD nonce uniqueness Thread-Index: AQHSsh1IHF3Oh9Y+Y0KzCXtT1ygnt6G/qPyAgANGtwCAAcFmgA== Date: Fri, 14 Apr 2017 10:34:19 +0000 Message-ID: References: <002101d2b21d$3ff5ba30$bfe12e90$@augustcellars.com> <1bc3ed76-245a-f8fe-ae72-a424102ba682@ericsson.com> In-Reply-To: <1bc3ed76-245a-f8fe-ae72-a424102ba682@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_D5161FCE7BAA8goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7q+7apR8iDE6/ZLRYdreP2eL7tx5m i+UXnrNY7Hu7ntli9fTvbA6sHhvnTGfz2Lr/LpPHkiU/mQKYo7hsUlJzMstSi/TtErgy7t09 yV4wcyFrxc5Z05gbGB/0s3YxcnJICJhIvJg8j7mLkYtDSGA9o0Tz23MsEM4SRoklsxczg1Sx CbhIPGh4xASSEBHoYZS4OOc2C0iCWSBfYkP7EiYQW1jAQuLOngPsILaIgKXEw333oGwniYXH 3jKC2CwCqhKHG/eDreYFqp//cxcbiC0kcItR4ubmKhCbU8BB4ufllWBxRgExie+n1jBB7BKX uPVkPhPE2QISS/acZ4awRSVePv4HNlNUQE9ib087G0RcSWLF9kuMEL2xEm933GWC2CsocXLm E5YJjKKzkIydhaRsFpKyWYwcQHFNifW79CFKFCWmdD9kh7A1JFrnzGWHKLGWWHOmHFnJAkaO VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBMXtwy2/dHYyrXzseYhTgYFTi4U1oeR8hxJpY VlyZe4hRgoNZSYT3eSNQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/DvgsRQgLpiSWp2ampBalF MFkmDk6pBsZ5sjeefT24ZUXpz1U9+/2bWWu3J4oEOmXKPKxIC1vCJcnz9+3ftOrDK7dNXMXc 4/Eg+KhngUQMs1D38f1s5TIXdFmmyB33TFucs2rqdBmJI3EOVw2uMj+fdeLOpdI1ksIS1W3L Cl5Ymb1jVrXdvEZnN+ff9pQ9nVYqblwvV13dxXRouUquiJoSS3FGoqEWc1FxIgClbgRh1QIA AA== Archived-At: Subject: Re: [core] Question about AEAD nonce uniqueness X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 10:34:28 -0000 --_000_D5161FCE7BAA8goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTW9oaXQsDQoNCihBbHNvIGluY2x1ZGluZyBBQ0Ugc2luY2UgRURIT0MgYmVsb25ncyB0aGVy ZS4pDQoNClRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIGFuZCByZXZpZXdpbmcgT1NDT0FQIGFu ZCBFREhPQy4NCg0KQWdhaW4sIEppbSB3YXMgcXVpY2tlciB0byBhbnN3ZXIsIGFuZCBpbiBmYWN0 IHRoaXMgaXMgb25lIG9mIHRoZSBmZWF0dXJlcyBvZiBFREhPQyB0aGF0IHdhcyBwcm9wb3NlZCBi eSBoaW0uIExldCBtZSBnaXZlIGEgYmFja2dyb3VuZCwgbWF5YmUgdGhhdCBoZWxwcy4NCg0KT25l IG9mIHRoZSBtYWluIGRlc2lnbiBjcml0ZXJpYSBmb3IgT1NDT0FQIGFuZCBFREhPQyBpcyB0byBt YWtlIHRoZSBwcm90b2NvbCBtZXNzYWdlcyBzbWFsbCwgc2luY2UgbWFueSBwZXJmb3JtYW5jZSBh c3BlY3RzIGFyZSByZWxhdGVkIHRvIG1lc3NhZ2Ugc2l6ZXMuDQoNCldoZXJlYXMgRURIT0MgaXMg b25seSBleHBlY3RlZCB0byBiZSBydW4gb25jZSBpbiBhIHdoaWxlIChtYXliZSBqdXN0IG9uY2Up LCBPU0NPQVAgbWF5IHBvdGVudGlhbGx5IGJlIHVzZWQgd2l0aCBpbiBldmVyeSBDb0FQIG1lc3Nh Z2UsIHNvIGluIHBhcnRpY3VsYXIgZm9yIE9TQ09BUCB3ZSBoYXZlIHRyaWVkIHRvIHR1cm4gb3Zl ciBldmVyeSBieXRlLiBUaGUgY3VycmVudCBvdmVyaGVhZCBvZiBPU0NPQVAgZm9yIGEgdHlwaWNh bCBDb0FQIG1lc3NhZ2UgZXhjaGFuZ2UgaXMgMTMgYnl0ZXMgaW4gdGhlIHJlcXVlc3QgYW5kIDkg Ynl0ZXMgaW4gdGhlIHJlc3BvbnNlIGFuZCB0aGF0IGluY2x1ZGVzIHRoZSA4IGJ5dGVzIG9mIE1B QyBpbiBlYWNoIG1lc3NhZ2UuIFRoaXMgbWVzc2FnZSBzaXplIGNhbGN1bGF0aW9uIGluY2x1ZGVz IGEgU2VuZGVyIElEIG9mIDEgYnl0ZS4gSGVuY2UgdG8gZ2V0IGxvdyBvdmVyaGVhZCBpbiBwYXJ0 aWN1bGFyIHJlcXVpcmVzIGEgc2hvcnQgU2VuZGVyIElELiBTZWUgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLWNvcmUtc2VjdXJpdHktb3ZlcmhlYWQtMDAjc2VjdGlv bi0yLjExDQoNCk5vdGUgdGhhdCB0aGUgU2VuZGVyIElEIGlzIG9ubHkgc2lnbmlmaWNhbnQgZm9y IGEgcGFydGljdWxhciBtYXN0ZXIgc2VjcmV0IGFuZCB0aGUgdXNlIG9mIHNob3J0IGlkZW50aWZp ZXJzIChhZGRyZXNzaW5nIHlvdXIgY29tbWVudCBvbiAibWluaW11bSBsZW5ndGgiKSBpcyBkZXNj cmliZWQgaW4gdGhlIE9TQ09BUCBzZWN0aW9uIEkgcmVmZXJlbmNlZCBiZWxvdy4NCg0KSWYgdGhl IFNlbmRlciBJRCBjb2luY2lkZXMgd2l0aCBhIFNlbmRlciBJRCB1c2VkIHdpdGggYW5vdGhlciBz ZWN1cml0eSBjb250ZXh0IHRoYXQgaXMgbm90IGEgc2VjdXJpdHkgaXNzdWUsIGJ1dCBhIGRldmlj ZSByZWNlaXZpbmcgYSBtZXNzYWdlIGZvciB3aGljaCBpdCBoYXMgbXVsdGlwbGUgc2VjdXJpdHkg Y29udGV4dHMgd2l0aCB0aGUgc2FtZSBTZW5kZXIgSUQgd291bGQgaGF2ZSB0byB0cnkgbW9yZSB0 aGFuIG9uY2UgYmVmb3JlIGZpbmRpbmcgdGhlIHJpZ2h0IChhZGRyZXNzaW5nIHlvdXIgY29tbWVu dCBvbiAiY29uY3JldGUgZWZmZWN0c+KAnSkuICBKaW0gZG9lc27igJl0IGhhdmUgYSBwcm9ibGVt IHdpdGggdGhhdCwgd2Ugd2FudGVkIHRvIHRyeSB0byBhdm9pZCBpdC4gQnV0LCBqdXN0IGluIGNh c2UsIHdlIHNob3VsZCBkZXNjcmliZSB0aGUgcHJvY2Vzc2luZyBoYW5kbGluZyB0aGlzLCBJIG5v dGUgdGhhdCBhcyBhbiBpc3N1ZS4NCg0KRm9yIHR3byBwZWVycyBhdXRvbm9tb3VzbHkgZXN0YWJs aXNoaW5nIGEgc2VjdXJpdHkgY29udGV4dCwgbmVpdGhlciBvZiB0aGUgbm9kZXMgaGF2ZSBrbm93 bGVkZ2UgYWJvdXQgdGhlIGlkZW50aWZpZXJzIHVzZWQgYnkgdGhlIHBlZXIgaW4gaXRzIHZhcmlv dXMgT1NDT0FQIGNvbnRleHRzIHdpdGggb3RoZXIgcGFydGllcy4gVGhlcmVmb3JlLCBpbiBFREhP QywgYXMgZGVzY3JpYmVkIGJ5IEppbSwgZWFjaCBwYXJ0eSBjYW4gc2VsZWN0IGl0cyBvd24gbG9j YWxseSB1bmlxdWUgc2hvcnQgc2Vzc2lvbiBpZGVudGlmaWVyLCBhbmQgd2hlbiBFREhPQyBpcyB1 c2VkIHdpdGggT1NDT0FQIHRoaXMgc2Vzc2lvbiBpZGVudGlmaWVyIGJlY29tZXMgdGhlIFNlbmRl ciBJRCwgc2VlDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNl LWNvc2UtZWNkaGUtMDUjYXBwZW5kaXgtQi4yDQooYWRkcmVzc2luZyB5b3VyIGNvbW1lbnQgb24g ImhvdyBpdCBpcyBnZW5lcmF0ZWQiKQ0KDQpIYXZpbmcgc2hvcnQgc2Vzc2lvbiBpZGVudGlmaWVy cyBhbHNvIG9wdGltaXNlcyB0aGUgRURIT0MgbWVzc2FnZXMsIHNpbmNlIHRoZXkgc2hvcnQgKG9m IGNvdXJzZSkgYnV0IGFsc28gc2luY2UgdGhlIG5vbmNlcyBOX1UsIE5fViAod2hpY2ggYXJlIGxv bmdlcikgb25seSBuZWVkIHRvIGJlIHNlbnQgb25jZSwgaW4gY29tcGFyaXNvbiB3aXRoIGEgcHJv dG9jb2wgY29tYmluaW5nIHRoZSBmdW5jdGlvbiBvZiBub25jZSBhbmQgc2Vzc2lvbiBpZGVudGlm aWVyLg0KDQpJZiB0aGVyZSBpcyBhIHRydXN0ZWQgdGhpcmQgcGFydHkgc3VjaCBhcyB0aGUgR3Jv dXAgTWFuYWdlciBpbiBhIG11bHRpY2FzdCBzZXR0aW5nIChhcyByZWZlcmVuY2VkIGJlbG93KSB0 aGVuIHRoZSBhc3NpZ25tZW50IG9mIGlkZW50aWZpZXJzIGluIHRoZSBzZXQgb2YgZGV2aWNlcyBz aGFyaW5nIGEgY29tbW9uIGNvbnRleHQgY2FuIGJlIHVuaWxhdGVyYWxseSBkZWNpZGVkIGJ5IHRo ZSBHTSBhbmQgdGhlIHNpemUgb2YgaWRlbnRpZmllcnMgb3B0aW1pc2VkIChhZGRyZXNzaW5nIHlv dXIgY29tbWVudCBvbiAib3V0IG9mIHNjb3BlIiAtIHdoaWNoIGluIG15IG1haWwgb25seSByZWZl cnJlZCB0byB0aGlzIGNhc2UpLiBOb3RlIHRoYXQgdGhlcmUgaXMgbm8gYWRkaXRpb25hbCBjb21w bGljYXRpb24gaW4gbWFraW5nIHRoaXMgYXNzaWdubWVudCBzaW5jZSBpdCBqdXN0IGhhcyB0byBi ZSBsb2NhbGx5IHVuaXF1ZSBmb3IgdGhhdCBncm91cC4NCg0KRGlkIHRoYXQgbWFrZSB0aGluZ3Mg bW9yZSBjbGVhcj8gRG8geW91IHRoaW5rIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMgYXJlIG5lZWRl ZCBpbiB0aGUgZHJhZnRzPw0KDQoNClRoYW5rcw0KR8O2cmFuDQoNCg0KDQoNCkZyb206IDZ0aXNj aCA8NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaC1ib3VuY2VzQGlldGYub3Jn Pj4gb24gYmVoYWxmIG9mIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRv OmlldGZAYXVndXN0Y2VsbGFycy5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTMgQXByaWwgMjAxNyBh dCAxNjozOQ0KVG86IE1vaGl0IFNldGhpIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTxtYWls dG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+PiwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5z ZWxhbmRlckBlcmljc3Nvbi5jb208bWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4+ LCAnQ29yZScgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PiwgIjZ0aXNjaEBp ZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPiIgPDZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86 NnRpc2NoQGlldGYub3JnPj4NCkNjOiAnQ2hyaXN0aWFuIEFtc8O8c3MnIDxjLmFtc3Vlc3NAZW5l cmd5aGFydmVzdGluZy5hdDxtYWlsdG86Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQ+Pg0K U3ViamVjdDogUmU6IFs2dGlzY2hdIFtjb3JlXSBRdWVzdGlvbiBhYm91dCBBRUFEIG5vbmNlIHVu aXF1ZW5lc3MNCg0KVGhlIHNlbGVjdGlvbiBvZiBTX1ggaXMgZG9uZSBieSBwYXJ0eSBYLiAgVGhp cyBtZWFucyB0aGF0IGFsbCB0aGV5IG5lZWQgdG8gZG8gaXMgdG8gZ2VuZXJhdGUg4oCTIGVpdGhl ciByYW5kb21seSBvciBkZXRlcm1pbmlzdGljYWxseSDigJMgc29tZSBpZGVudGlmaWVyIHdoaWNo IGlzIGN1cnJlbnRseSB1bmlxdWUgZm9yIHRoZW0uDQoNClRoZSBlYXNpZXN0IHdheSB0byBkbyB0 aGlzIGlzIHRvIGhhdmUgYW4gYXJyYXkgb2YgTiBzZWN1cml0eSBjb250ZXh0cy4gIENob29zZSB0 aGUgZmlyc3Qgc2xvdCBpbiB0aGUgYXJyYXkgd2hpY2ggaXMgZW1wdHkgYW5kIHVzZSB0aGF0IGlu ZGV4IGFzIHlvdXIgaWRlbnRpZmllci4gIElmIHRoZSBhcnJheSBpcyBmdWxsLCB0aGVuIGVpdGhl ciBncm93IHRoZSBhcnJheSBvciBzY2F2ZW5nZSBhIHNlY3VyaXR5IGNvbnRleHQgd2hpY2ggaGFz IG5vdCBiZWVuIHVzZWQgaW4gYSB3aGlsZSBhbmQgdXNlIHRoYXQgc2xvdC4gIFRoaXMgYWxsb3dz IGZvciBpZGVudGlmaWVycyB0aGF0IGFyZSB1bmlxdWUgdG8gdGhlIHBhcnR5IGFuZCBzdGlsbCB2 ZXJ5IHNtYWxsLg0KDQpUaGUgb25seSB0aW1lIHRoYXQgb25lIHdvdWxkIG5lZWQgbGFyZ2UgcmFu ZG9tIGlkZW50aWZpZXJzIGlzIHdoZW4gdGhlIGtleWluZyBtYXRlcmlhbCBpcyBnZW5lcmF0ZWQg YnkgYSB0aGlyZCBwYXJ0eSBzdWNoIGFzIHRoZSBQU0sgdmVyc2lvbiBvZiBFREhPQyB3aGVyZSB0 aGUgY29tbW9uIFBTSyBuZWVkcyB0byBiZSBpZGVudGlmaWVkIGZvciBib3RoIHBhcnRpZXMuDQoN CkkgYWxzbyBkbyBub3QgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtcyB3aXRoIGNvbGxpc2lvbnMgdGhh dCBHw7ZyYW4gYW5kIG90aGVycyBoYXZlLiAgSSBhbSB3aWxsaW5nIHRvIHRyeSBtdWx0aXBsZSBr ZXlzIGluIHRoZSBldmVudCBvZiBhIGNvbGxpc2lvbiBhbmQgb25seSB0aGUgY29ycmVjdCBvbmUg d2lsbCB3b3JrLiAgVGhpcyBpcyBub3QgdW51c3VhbCBpbiBzb21lIGNhc2VzIGFscmVhZHkgaW4g b3RoZXIgZW52aXJvbm1lbnRzLg0KDQpKaW0NCg0KDQpGcm9tOiBNb2hpdCBTZXRoaSBbbWFpbHRv Om1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDEzLCAy MDE3IDI6NDYgQU0NClRvOiBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj47ICdDb3JlJyA8Y29yZUBp ZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+OyA2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0 aXNjaEBpZXRmLm9yZz4NCkNjOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1h aWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj47IENocmlzdGlhbiBBbXPDvHNzIDxjLmFtc3Vl c3NAZW5lcmd5aGFydmVzdGluZy5hdDxtYWlsdG86Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3Rpbmcu YXQ+Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBRdWVzdGlvbiBhYm91dCBBRUFEIG5vbmNlIHVuaXF1 ZW5lc3MNCg0KDQpIaSBHw7ZyYW4sIEppbSBhbmQgQ2hyaXN0aWFuDQoNClRoYW5rcyBmb3IgcmVz cG9uZGluZyB0byBteSBxdWVzdGlvbi4gQEfDtnJhbjogYm90aCAxKSB1c2UgRURIT0Mgb3IgMikg Z2VuZXJhdGUgbGFyZ2UgcmFuZG9tIGlkZW50aWZpZXJzLCBhcmUgdGhlIHNhbWUgdGhpbmcuIEhv dyBhcmUgdGhleSBhbnkgZGlmZmVyZW50PyBJIHdlbnQgdGhyb3VnaCBFREhPQyBkcmFmdCBhbmQg aXQgc2F5cyB0aGF0IHNlbmRlciBpZCBpcyBTX1Ygd2hpY2ggaXMgdmFyaWFibGUgbGVuZ3RoIHNl c3Npb24gaWRlbnRpZmllciAoPSBnZW5lcmF0ZSBsYXJnZSByYW5kb20gaWRlbnRpZmllcikuDQoN CkkgYW0gYWZyYWlkIHNpbXBseSB3YXZpbmcgb2ZmIHRoZSBwcm9ibGVtIGFzIG91dCBvZiBzY29w ZSBtYXkgbGVhZCB0byBzb21lIChtYW55KSBpbnRlciBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4g SWYgdGhlIFNlbmRlciBJRCBpcyB2YXJpYWJsZSBsZW5ndGgsIGRpZmZlcmVudCBtYW51ZmFjdHVy ZXJzIG1heSBpbXBsZW1lbnQgaXQgdmVyeSBkaWZmZXJlbnRseSBhbmQgY291bGQgY2F1c2UgY29s bGlzaW9uIHdpdGgganVzdCAyLTMgZGV2aWNlcy4gSWYgdGhleSBhcmUgZ2VuZXJhdGVkIGluIHNv ZnR3YXJlIGF0IHJ1biB0aW1lLCB5b3UgY2FuIHN0aWxsIGRvIHNvbWV0aGluZyBhYm91dCBpdCwg YnV0IGlmIGl0IGlzIGJ1cm50IGludG8gdGhlIGRldmljZSwgdGhlbiB0aGVyZSBpcyBubyB3YXkg dG8gcmVjb3ZlciBmcm9tIC4gQXQgdGhlIHZlcnkgbGVhc3QgdGhlcmUgY291bGQgYmUgYmV0dGVy IGd1aWRhbmNlLiBJIGFsc28gdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0byBoYXZlIGEgbWlu aW11bSBsZW5ndGggc3BlY2lmaWVkIGFuZCBzb21lIHJlY29tbWVuZGF0aW9ucy9ndWlkZWxpbmVz IG9uIGhvdyBpdCBpcyBnZW5lcmF0ZWQuDQoNCkkgd291bGQgYWxzbyBsaWtlIHRvIGtub3cgd2hh dCBhcmUgdGhlIGNvbmNyZXRlIGFmZmVjdHMgb2YgYSBjb2xsaXNpb24/DQoNCi0tTW9oaXQNCg0K T24gMDQvMTEvMjAxNyAwODo0MyBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KSGVsbG8gTW9o aXQsDQoNCkNocmlzdGlhbiBhbmQgSmltIGFscmVhZHkgcHJvdmlkZWQgYW5zd2VycywgbGV0IG1l IGp1c3QgcHJvdmlkZSBwb2ludGVycyB0byB0aGUgcmVsZXZhbnQgc2VjdGlvbnMuDQoNCk9TQ09B UDoNCuKAlA0KVGhlIHJlcXVpcmVtZW50cyBvbiB0aGUgc2VjdXJpdHkgY29udGV4dCBwYXJhbWV0 ZXJzIGFyZSBoZXJlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29y ZS1vYmplY3Qtc2VjdXJpdHktMDIjc2VjdGlvbi0zLjMNClR3byBtZXRob2RzIGZvciBlc3RhYmxp c2hpbmcgdW5pcXVlIHNlbmRlciBJRHMgYXJlIHByZXNlbnRlZDogMSkgdXNlIEVESE9DIG9yIDIp IGdlbmVyYXRlIGxhcmdlIHJhbmRvbSBpZGVudGlmaWVycy4NClRoZSBmb3JtZXIgYWxsb3dzIGZv ciB0aGUgdXNlIG9mIHNob3J0IHNlbmRlciBJRHMuDQoNCg0KTXVsdGljYXN0IE9TQ09BUDoNCuKA lA0KSW4gTXVsdGljYXN0IE9TQ09BUCAoU2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIENv QVApIHRoZSByZXF1aXJlbWVudHMgb24gdGhlIHNlY3VyaXR5IGNvbnRleHQgcGFyYW1ldGVycyBh cmUgaGVyZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1t dWx0aWNhc3Qtb3Njb2FwLTAxI3NlY3Rpb24tMg0KSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9m IHRoZSBHcm91cCBNYW5hZ2VyIHRvIGVzdGFibGlzaCBhbmQgbWFuYWdlIHRoZSBzZWN1cml0eSBj b250ZXh0LCB3aGljaCBpbmNsdWRlcyB0aGUgc2VuZGVyIElEcywgYnV0IGhvdyB0aGUgYXNzaWdu bWVudCBpcyBkb25lIGlzIG91dCBvZiBzY29wZS4gVGhlIHVuaXF1ZW5lc3Mgb2Ygc2VuZGVyIElE cyBpbiB0aGlzIGRyYWZ0IGZvbGxvd3MgZnJvbSBPU0NPQVAsIGJ1dCBzaW5jZSB5b3UgYXNrZWQg SSB0aGluayB3ZSBzaG91bGQgYWRkIGEgc2VudGVuY2UgdG8gdGhpcyBkcmFmdCBzdHJlc3Npbmcg dGhhdC4NCg0KDQpHw7ZyYW4NCg0KDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKaW0gU2NoYWFkIDxp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4NCkRh dGU6IE1vbmRheSAxMCBBcHJpbCAyMDE3IGF0IDE5OjA5DQpUbzogTW9oaXQgU2V0aGkgPG1vaGl0 Lm0uc2V0aGlAZXJpY3Nzb24uY29tPG1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT4+ LCAnQ29yZScgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+PiwgIjZ0aXNjaEBp ZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPiIgPDZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86 NnRpc2NoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbY29yZV0gUXVlc3Rpb24gYWJvdXQgQUVB RCBub25jZSB1bmlxdWVuZXNzDQoNClRoZXJlIGlzIG5vdCBhIHByb2JsZW0gd2l0aCBkZWFsaW5n IHdpdGggbm9uY2UgdW5pcXVlbmVzcyBpbiB0aGlzIGRyYWZ0IGJlY2F1c2UgZWFjaCBlbnRpdHkg aXMgZ29pbmcgdG8gYmUgYXNzaWduZWQgdG8gYSB1bmlxdWUga2V5IGZvciB0cmFuc21pc3Npb25z LiAgVGhlIHRyYW5zcG9ydCBrZXkgaXMgZGVyaXZlZCBmcm9tIHRoZSBQU0sgYW5kIHRoZSBzZW5k ZXIgSUQuICBTZW5kZXIgSURzIHdpbGwgYmUgdW5pcXVlIGJhc2VkIG9uIHRoZSBlbnJvbGxtZW50 IHByb3RvY29sIGluIHRoZSBncm91cCBhcyBlYWNoIGVudGl0eSB3aWxsIGhhdmUgYSB1bmlxdWUg aWRlbnRpZmllci4NCg0KSmltDQoNCg0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vaGl0IFNldGhpDQpTZW50OiBNb25kYXksIEFwcmlsIDEw LCAyMDE3IDQ6NTEgQU0NClRvOiBDb3JlIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYu b3JnPj47IDZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0KU3ViamVjdDog W2NvcmVdIFF1ZXN0aW9uIGFib3V0IEFFQUQgbm9uY2UgdW5pcXVlbmVzcw0KDQoNCkhpIE9TQ29B UCBhdXRob3JzDQoNCkkgd2FzIHRyeWluZyB0byByZWFkIHRoZSBPU0NvQVAgYW5kIDZ0aXNjaCBt aW5pbWFsIHNlY3VyaXR5IGRyYWZ0cy4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIEFFQUQg bm9uY2UgdW5pcXVlbmVzcy4gUkZDIDUxMTYgc2F5cyB0aGF0Og0KDQogICBXaGVuIHRoZXJlIGFy ZSBtdWx0aXBsZSBkZXZpY2VzIHBlcmZvcm1pbmcgZW5jcnlwdGlvbiB1c2luZyBhIHNpbmdsZQ0K DQogICBrZXksIHRob3NlIGRldmljZXMgbXVzdCBjb29yZGluYXRlIHRvIGVuc3VyZSB0aGF0IHRo ZSBub25jZXMgYXJlDQoNCiAgIHVuaXF1ZS4gIEEgc2ltcGxlIHdheSB0byBkbyB0aGlzIGlzIHRv IHVzZSBhIG5vbmNlIGZvcm1hdCB0aGF0DQoNCiAgIGNvbnRhaW5zIGEgZmllbGQgdGhhdCBpcyBk aXN0aW5jdCBmb3IgZWFjaCBvbmUgb2YgdGhlIGRldmljZXMNCg0KU28gbXkgb2J2aW91cyBxdWVz dGlvbiBpcyBob3cgaXMgdGhlIEFFQUQgbm9uY2UgdW5pcXVlbmVzcyBlbnN1cmVkLiBUaGUgUFNL IGlzIGtub3duIHRvIGF0IGxlYXN0IHR3byBwYXJ0aWVzIChtb3JlIGluIGNhc2Ugb2Ygc29tZSB1 c2VzIHN1Y2ggYXMgbXVsdGljYXN0IE9TQ29BUCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMSk/Pw0KDQpUaGUgZHJhZnQgY3Vy cmVudGx5IHNheXMgdGhhdCBBRUFEIE5vbmNlIHVuaXF1ZW5lc3MgaXMgZW5zdXJlZCB3aXRoIHNl cXVlbmNlIG51bWJlcnMgYW5kIHNlbmRlciBjb250ZXh0IHdoaWNoIGlzIGVzc2VudGlhbGx5IHRo ZSBzZW5kZXIgSUQuIEJ1dCBob3cgZG8geW91IGVuc3VyZSB0aGF0IHRoZSB0d28gcGFydGllcyBo YXZlIGRpZmZlcmVudCBzZW5kZXIgSUQuIEVzcGVjaWFsbHkgc2luY2Ugc2VuZGVyIElEIGlzIG5v dCBmaXhlZCBsZW5ndGguIEkgZ3Vlc3MgdGhlcmUgd2lsbCBiZSBvdGhlciBwcm9ibGVtcyBpbiBj YXNlIG9mIHNlbmRlciBJRCBjb2xsaXNpb25zPw0KYXMgU2VuZGVyIElEcyBhcmUgY3VycmVudGx5 IHVzZWQsIHRoZXkgYXJlIG11dHVhbGx5IGFncmVlZC11cG9uIGxpa2UgdGhlDQpyZXN0IG9mIHRo ZSBzZWN1cml0eSBjb250ZXh0IChrZXksIGFsZ29yaXRobSBldGMpOyBpbiBvdGhlciB3b3Jkcywg dGhleQ0KYXJlIGV4cGxpY2l0bHkgZ2l2ZW4gdG8gYSBkZXZpY2UgYnkgdGhlIG1lY2hhbmlzbSB0 aGF0IGFsc28gZGlzdHJpYnV0ZXMNCnRoZSBrZXkuDQoNCkJlc3QgcmVnYXJkcw0KQ2hyaXN0aWFu DQoNCi0tDQpDaHJpc3RpYW4gQW1zw7xzcyAgICAgICAgICAgICAgICAgICAgICB8IEVuZXJneSBI YXJ2ZXN0aW5nIFNvbHV0aW9ucyBHbWJIDQpmb3VuZGVyLCBzeXN0ZW0gYXJjaGl0ZWN0ICAgICAg ICAgICAgIHwgaGVhZHF1YXJ0ZXI6DQptYWlsdG86Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3Rpbmcu YXQgIHwgQXJiZWl0ZXJnYXNzZSAxNSwgQS00NDAwIFN0ZXlyDQp0ZWw6KzQzLTY2NC05Ny05MC02 LTM5ICAgICAgICAgICAgICAgIHwgaHR0cDovL3d3dy5lbmVyZ3loYXJ2ZXN0aW5nLmF0Lw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFUVTY4NDc2NjE0DQoNCg0KDQoN CkZyb206IE1vaGl0IFNldGhpIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTxtYWlsdG86bW9o aXQubS5zZXRoaUBlcmljc3Nvbi5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTMgQXByaWwgMjAxNyBh dCAxMTo0NQ0KVG86IEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29t PG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PiwgJ0NvcmUnIDxjb3JlQGlldGYu b3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4sICI2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNj aEBpZXRmLm9yZz4iIDw2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4+DQpD YzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbT4+LCBDaHJpc3RpYW4gQW1zw7xzcyA8Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3Rp bmcuYXQ8bWFpbHRvOmMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0Pj4NClN1YmplY3Q6IFJl OiBbY29yZV0gUXVlc3Rpb24gYWJvdXQgQUVBRCBub25jZSB1bmlxdWVuZXNzDQoNCg0KSGkgR8O2 cmFuLCBKaW0gYW5kIENocmlzdGlhbg0KDQpUaGFua3MgZm9yIHJlc3BvbmRpbmcgdG8gbXkgcXVl c3Rpb24uIEBHw7ZyYW46IGJvdGggMSkgdXNlIEVESE9DIG9yIDIpIGdlbmVyYXRlIGxhcmdlIHJh bmRvbSBpZGVudGlmaWVycywgYXJlIHRoZSBzYW1lIHRoaW5nLiBIb3cgYXJlIHRoZXkgYW55IGRp ZmZlcmVudD8gSSB3ZW50IHRocm91Z2ggRURIT0MgZHJhZnQgYW5kIGl0IHNheXMgdGhhdCBzZW5k ZXIgaWQgaXMgU19WIHdoaWNoIGlzIHZhcmlhYmxlIGxlbmd0aCBzZXNzaW9uIGlkZW50aWZpZXIg KD0gZ2VuZXJhdGUgbGFyZ2UgcmFuZG9tIGlkZW50aWZpZXIpLg0KDQpJIGFtIGFmcmFpZCBzaW1w bHkgd2F2aW5nIG9mZiB0aGUgcHJvYmxlbSBhcyBvdXQgb2Ygc2NvcGUgbWF5IGxlYWQgdG8gc29t ZSAobWFueSkgaW50ZXIgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMuIElmIHRoZSBTZW5kZXIgSUQg aXMgdmFyaWFibGUgbGVuZ3RoLCBkaWZmZXJlbnQgbWFudWZhY3R1cmVycyBtYXkgaW1wbGVtZW50 IGl0IHZlcnkgZGlmZmVyZW50bHkgYW5kIGNvdWxkIGNhdXNlIGNvbGxpc2lvbiB3aXRoIGp1c3Qg Mi0zIGRldmljZXMuIElmIHRoZXkgYXJlIGdlbmVyYXRlZCBpbiBzb2Z0d2FyZSBhdCBydW4gdGlt ZSwgeW91IGNhbiBzdGlsbCBkbyBzb21ldGhpbmcgYWJvdXQgaXQsIGJ1dCBpZiBpdCBpcyBidXJu dCBpbnRvIHRoZSBkZXZpY2UsIHRoZW4gdGhlcmUgaXMgbm8gd2F5IHRvIHJlY292ZXIgZnJvbSAu IEF0IHRoZSB2ZXJ5IGxlYXN0IHRoZXJlIGNvdWxkIGJlIGJldHRlciBndWlkYW5jZS4gSSBhbHNv IHRoaW5rIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIG1pbmltdW0gbGVuZ3RoIHNwZWNp ZmllZCBhbmQgc29tZSByZWNvbW1lbmRhdGlvbnMvZ3VpZGVsaW5lcyBvbiBob3cgaXQgaXMgZ2Vu ZXJhdGVkLg0KDQpJIHdvdWxkIGFsc28gbGlrZSB0byBrbm93IHdoYXQgYXJlIHRoZSBjb25jcmV0 ZSBhZmZlY3RzIG9mIGEgY29sbGlzaW9uPw0KDQotLU1vaGl0DQoNCk9uIDA0LzExLzIwMTcgMDg6 NDMgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCkhlbGxvIE1vaGl0LA0KDQpDaHJpc3RpYW4g YW5kIEppbSBhbHJlYWR5IHByb3ZpZGVkIGFuc3dlcnMsIGxldCBtZSBqdXN0IHByb3ZpZGUgcG9p bnRlcnMgdG8gdGhlIHJlbGV2YW50IHNlY3Rpb25zLg0KDQpPU0NPQVA6DQrigJQNClRoZSByZXF1 aXJlbWVudHMgb24gdGhlIHNlY3VyaXR5IGNvbnRleHQgcGFyYW1ldGVycyBhcmUgaGVyZToNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5 LTAyI3NlY3Rpb24tMy4zDQpUd28gbWV0aG9kcyBmb3IgZXN0YWJsaXNoaW5nIHVuaXF1ZSBzZW5k ZXIgSURzIGFyZSBwcmVzZW50ZWQ6IDEpIHVzZSBFREhPQyBvciAyKSBnZW5lcmF0ZSBsYXJnZSBy YW5kb20gaWRlbnRpZmllcnMuDQpUaGUgZm9ybWVyIGFsbG93cyBmb3IgdGhlIHVzZSBvZiBzaG9y dCBzZW5kZXIgSURzLg0KDQoNCk11bHRpY2FzdCBPU0NPQVA6DQrigJQNCkluIE11bHRpY2FzdCBP U0NPQVAgKFNlY3VyZSBncm91cCBjb21tdW5pY2F0aW9uIGZvciBDb0FQKSB0aGUgcmVxdWlyZW1l bnRzIG9uIHRoZSBzZWN1cml0eSBjb250ZXh0IHBhcmFtZXRlcnMgYXJlIGhlcmU6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0w MSNzZWN0aW9uLTINCkl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgR3JvdXAgTWFuYWdl ciB0byBlc3RhYmxpc2ggYW5kIG1hbmFnZSB0aGUgc2VjdXJpdHkgY29udGV4dCwgd2hpY2ggaW5j bHVkZXMgdGhlIHNlbmRlciBJRHMsIGJ1dCBob3cgdGhlIGFzc2lnbm1lbnQgaXMgZG9uZSBpcyBv dXQgb2Ygc2NvcGUuIFRoZSB1bmlxdWVuZXNzIG9mIHNlbmRlciBJRHMgaW4gdGhpcyBkcmFmdCBm b2xsb3dzIGZyb20gT1NDT0FQLCBidXQgc2luY2UgeW91IGFza2VkIEkgdGhpbmsgd2Ugc2hvdWxk IGFkZCBhIHNlbnRlbmNlIHRvIHRoaXMgZHJhZnQgc3RyZXNzaW5nIHRoYXQuDQoNCg0KR8O2cmFu DQoNCg0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3JlLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+DQpEYXRlOiBNb25kYXkgMTAgQXBy aWwgMjAxNyBhdCAxOTowOQ0KVG86IE1vaGl0IFNldGhpIDxtb2hpdC5tLnNldGhpQGVyaWNzc29u LmNvbTxtYWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+PiwgJ0NvcmUnIDxjb3JlQGll dGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4sICI2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0 aXNjaEBpZXRmLm9yZz4iIDw2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW2NvcmVdIFF1ZXN0aW9uIGFib3V0IEFFQUQgbm9uY2UgdW5pcXVlbmVz cw0KDQpUaGVyZSBpcyBub3QgYSBwcm9ibGVtIHdpdGggZGVhbGluZyB3aXRoIG5vbmNlIHVuaXF1 ZW5lc3MgaW4gdGhpcyBkcmFmdCBiZWNhdXNlIGVhY2ggZW50aXR5IGlzIGdvaW5nIHRvIGJlIGFz c2lnbmVkIHRvIGEgdW5pcXVlIGtleSBmb3IgdHJhbnNtaXNzaW9ucy4gIFRoZSB0cmFuc3BvcnQg a2V5IGlzIGRlcml2ZWQgZnJvbSB0aGUgUFNLIGFuZCB0aGUgc2VuZGVyIElELiAgU2VuZGVyIElE cyB3aWxsIGJlIHVuaXF1ZSBiYXNlZCBvbiB0aGUgZW5yb2xsbWVudCBwcm90b2NvbCBpbiB0aGUg Z3JvdXAgYXMgZWFjaCBlbnRpdHkgd2lsbCBoYXZlIGEgdW5pcXVlIGlkZW50aWZpZXIuDQoNCkpp bQ0KDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBNb2hpdCBTZXRoaQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMCwgMjAxNyA0OjUxIEFNDQpU bzogQ29yZSA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+OyA2dGlzY2hAaWV0 Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFtjb3JlXSBRdWVzdGlvbiBh Ym91dCBBRUFEIG5vbmNlIHVuaXF1ZW5lc3MNCg0KDQpIaSBPU0NvQVAgYXV0aG9ycw0KDQpJIHdh cyB0cnlpbmcgdG8gcmVhZCB0aGUgT1NDb0FQIGFuZCA2dGlzY2ggbWluaW1hbCBzZWN1cml0eSBk cmFmdHMuIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZSBBRUFEIG5vbmNlIHVuaXF1ZW5lc3Mu IFJGQyA1MTE2IHNheXMgdGhhdDoNCg0KICAgV2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgZGV2aWNl cyBwZXJmb3JtaW5nIGVuY3J5cHRpb24gdXNpbmcgYSBzaW5nbGUNCg0KICAga2V5LCB0aG9zZSBk ZXZpY2VzIG11c3QgY29vcmRpbmF0ZSB0byBlbnN1cmUgdGhhdCB0aGUgbm9uY2VzIGFyZQ0KDQog ICB1bmlxdWUuICBBIHNpbXBsZSB3YXkgdG8gZG8gdGhpcyBpcyB0byB1c2UgYSBub25jZSBmb3Jt YXQgdGhhdA0KDQogICBjb250YWlucyBhIGZpZWxkIHRoYXQgaXMgZGlzdGluY3QgZm9yIGVhY2gg b25lIG9mIHRoZSBkZXZpY2VzDQoNClNvIG15IG9idmlvdXMgcXVlc3Rpb24gaXMgaG93IGlzIHRo ZSBBRUFEIG5vbmNlIHVuaXF1ZW5lc3MgZW5zdXJlZC4gVGhlIFBTSyBpcyBrbm93biB0byBhdCBs ZWFzdCB0d28gcGFydGllcyAobW9yZSBpbiBjYXNlIG9mIHNvbWUgdXNlcyBzdWNoIGFzIG11bHRp Y2FzdCBPU0NvQVAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3Jl LW11bHRpY2FzdC1vc2NvYXAtMDEpPz8NCg0KVGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzIHRoYXQg QUVBRCBOb25jZSB1bmlxdWVuZXNzIGlzIGVuc3VyZWQgd2l0aCBzZXF1ZW5jZSBudW1iZXJzIGFu ZCBzZW5kZXIgY29udGV4dCB3aGljaCBpcyBlc3NlbnRpYWxseSB0aGUgc2VuZGVyIElELiBCdXQg aG93IGRvIHlvdSBlbnN1cmUgdGhhdCB0aGUgdHdvIHBhcnRpZXMgaGF2ZSBkaWZmZXJlbnQgc2Vu ZGVyIElELiBFc3BlY2lhbGx5IHNpbmNlIHNlbmRlciBJRCBpcyBub3QgZml4ZWQgbGVuZ3RoLiBJ IGd1ZXNzIHRoZXJlIHdpbGwgYmUgb3RoZXIgcHJvYmxlbXMgaW4gY2FzZSBvZiBzZW5kZXIgSUQg Y29sbGlzaW9ucz8NCg0KYXMgU2VuZGVyIElEcyBhcmUgY3VycmVudGx5IHVzZWQsIHRoZXkgYXJl IG11dHVhbGx5IGFncmVlZC11cG9uIGxpa2UgdGhlDQpyZXN0IG9mIHRoZSBzZWN1cml0eSBjb250 ZXh0IChrZXksIGFsZ29yaXRobSBldGMpOyBpbiBvdGhlciB3b3JkcywgdGhleQ0KYXJlIGV4cGxp Y2l0bHkgZ2l2ZW4gdG8gYSBkZXZpY2UgYnkgdGhlIG1lY2hhbmlzbSB0aGF0IGFsc28gZGlzdHJp YnV0ZXMNCnRoZSBrZXkuDQoNCkJlc3QgcmVnYXJkcw0KQ2hyaXN0aWFuDQoNCi0tDQpDaHJpc3Rp YW4gQW1zw7xzcyAgICAgICAgICAgICAgICAgICAgICB8IEVuZXJneSBIYXJ2ZXN0aW5nIFNvbHV0 aW9ucyBHbWJIDQpmb3VuZGVyLCBzeXN0ZW0gYXJjaGl0ZWN0ICAgICAgICAgICAgIHwgaGVhZHF1 YXJ0ZXI6DQptYWlsdG86Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQgIHwgQXJiZWl0ZXJn YXNzZSAxNSwgQS00NDAwIFN0ZXlyDQp0ZWw6KzQzLTY2NC05Ny05MC02LTM5ICAgICAgICAgICAg ICAgIHwgaHR0cDovL3d3dy5lbmVyZ3loYXJ2ZXN0aW5nLmF0Lw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IEFUVTY4NDc2NjE0DQoNCg0KDQo= --_000_D5161FCE7BAA8goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj5IaSBN b2hpdCw8L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPjxicj4NCjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0i Q2FsaWJyaSIgc2l6ZT0iMyI+KEFsc28mbmJzcDtpbmNsdWRpbmcgQUNFIHNpbmNlIEVESE9DIGJl bG9uZ3MgdGhlcmUuKTwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+PGJyPg0KPC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9u dCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj5UaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSBhbmQg cmV2aWV3aW5nIE9TQ09BUCBhbmQgRURIT0MuPC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIz Ij48YnI+DQo8L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCjxmb250IHNpemU9IjMiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ QWdhaW4sIEppbSB3YXMgcXVpY2tlciB0byBhbnN3ZXIsIGFuZCBpbiBmYWN0IHRoaXMgaXMgb25l IG9mIHRoZSBmZWF0dXJlcyBvZiBFREhPQyB0aGF0IHdhcyBwcm9wb3NlZCBieSBoaW0uIExldCBt ZSBnaXZlIGEmbmJzcDtiYWNrZ3JvdW5kLCBtYXliZSB0aGF0IGhlbHBzLjwvZm9udD48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiPjxmb250Pjxmb250IGZh Y2U9IkNhbGlicmkiPk9uZSBvZiB0aGUgbWFpbiBkZXNpZ24gY3JpdGVyaWEgZm9yIE9TQ09BUCBh bmQgRURIT0MgaXMgdG8gbWFrZSB0aGUgcHJvdG9jb2wgbWVzc2FnZXMgc21hbGwsIHNpbmNlIG1h bnkmbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogbWVkaXVtOyI+cGVyZm9ybWFuY2UNCiBhc3Bl Y3RzIGFyZSByZWxhdGVkIHRvIG1lc3NhZ2Ugc2l6ZXMuJm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBzaXplPSIzIj48 YnI+DQo8L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxmb250IHNpemU9IjMiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+V2hl cmVhcyBFREhPQyBpcyBvbmx5IGV4cGVjdGVkIHRvIGJlIHJ1biBvbmNlIGluIGEgd2hpbGUgKG1h eWJlIGp1c3Qgb25jZSksIE9TQ09BUCBtYXkgcG90ZW50aWFsbHkgYmUgdXNlZCB3aXRoIGluIGV2 ZXJ5IENvQVAgbWVzc2FnZSwgc28gaW4gcGFydGljdWxhciBmb3IgT1NDT0FQIHdlIGhhdmUgdHJp ZWQgdG8gdHVybiBvdmVyIGV2ZXJ5IGJ5dGUuPC9mb250Pjxmb250IGZhY2U9IkNhbGlicmkiIHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJz cDtUPC9mb250PmhlPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDtjdXJyZW50 DQogb3ZlcmhlYWQgb2YgT1NDT0FQIGZvciBhIHR5cGljYWwgQ29BUCBtZXNzYWdlIGV4Y2hhbmdl IGlzIDEzIGJ5dGVzIGluIHRoZSByZXF1ZXN0IGFuZDwvZm9udD48L2ZvbnQ+PC9mb250Pjxmb250 IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+Jm5ic3A7OSBi eXRlcyBpbiB0aGUgcmVzcG9uc2UgYW5kIHRoYXQgaW5jbHVkZXMNCiB0aGUgOCBieXRlcyBvZiBN QUMgaW4gZWFjaCBtZXNzYWdlLiBUaGlzIG1lc3NhZ2Ugc2l6ZSBjYWxjdWxhdGlvbiBpbmNsdWRl cyBhIFNlbmRlciBJRCBvZiAxIGJ5dGUuIEhlbmNlIHRvIGdldCBsb3cgb3ZlcmhlYWQgaW4gcGFy dGljdWxhciByZXF1aXJlcyBhIHNob3J0IFNlbmRlciBJRC4gU2VlJm5ic3A7PC9mb250PjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLXNlY3Vy aXR5LW92ZXJoZWFkLTAwI3NlY3Rpb24tMi4xMSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZC0wMCNzZWN0aW9uLTIuMTE8 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxi cj4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8 Zm9udCBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPk5vdGUgdGhhdCZuYnNwOzwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIz Ij50aGUgU2VuZGVyIElEIGlzIG9ubHkgc2lnbmlmaWNhbnQgZm9yIGEgcGFydGljdWxhciBtYXN0 ZXIgc2VjcmV0PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZuYnNwOzwvZm9u dD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPmFuZA0KIHRoZSB1c2Ugb2Ygc2hvcnQg aWRlbnRpZmllcnMgKGFkZHJlc3NpbmcgeW91ciBjb21tZW50IG9uICZxdW90O21pbmltdW0gbGVu Z3RoJnF1b3Q7KTwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwO2lz IGRlc2NyaWJlZCBpbiB0aGUgT1NDT0FQIHNlY3Rpb24gSSByZWZlcmVuY2VkIGJlbG93LjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij48YnI+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIiBzaXplPSIzIj5JZiB0aGUgU2VuZGVyIElEIGNvaW5jaWRlcyB3 aXRoIGEgU2VuZGVyIElEIHVzZWQgd2l0aCBhbm90aGVyIHNlY3VyaXR5IGNvbnRleHQgdGhhdCBp cyBub3QgYSBzZWN1cml0eSBpc3N1ZSwgYnV0IGEgZGV2aWNlIHJlY2VpdmluZyBhIG1lc3NhZ2Ug Zm9yIHdoaWNoIGl0IGhhcyBtdWx0aXBsZSBzZWN1cml0eSBjb250ZXh0cyB3aXRoIHRoZQ0KIHNh bWUgU2VuZGVyIElEIHdvdWxkIGhhdmUgdG8gdHJ5IG1vcmUgdGhhbiBvbmNlIGJlZm9yZSBmaW5k aW5nIHRoZSByaWdodCAoYWRkcmVzc2luZyB5b3VyIGNvbW1lbnQgb24gJnF1b3Q7Y29uY3JldGUg ZWZmZWN0c+KAnSkuICZuYnNwO0ppbSBkb2VzbuKAmXQgaGF2ZSBhIHByb2JsZW0gd2l0aCB0aGF0 LCB3ZSB3YW50ZWQgdG8gdHJ5IHRvJm5ic3A7PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5hdm9pZDwvZm9udD48Zm9udCBmYWNlPSJD YWxpYnJpIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+Jm5ic3A7aXQuDQogQnV0LCBqdXN0IGluIGNhc2UsIHdlIHNob3VsZCBkZXNjcmliZSB0 aGUgcHJvY2Vzc2luZzwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHNpemU9 IjMiPiZuYnNwO2hhbmRsaW5nIHRoaXMsIEkgbm90ZSB0aGF0IGFzIGFuIGlzc3VlLjwvZm9udD48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxicj4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj5Gb3IgdHdvIHBlZXJzIGF1dG9ub21vdXNs eSBlc3RhYmxpc2hpbmcgYSBzZWN1cml0eSZuYnNwO2NvbnRleHQsIG5laXRoZXIgb2YgdGhlJm5i c3A7bm9kZXMgaGF2ZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGlkZW50aWZpZXJzIHVzZWQgYnkgdGhl IHBlZXIgaW4gaXRzIHZhcmlvdXMgT1NDT0FQIGNvbnRleHRzIHdpdGggb3RoZXIgcGFydGllcy4g VGhlcmVmb3JlLCBpbiBFREhPQywgYXMgZGVzY3JpYmVkIGJ5IEppbSwNCiBlYWNoIHBhcnR5IGNh biBzZWxlY3QgaXRzIG93biBsb2NhbGx5IHVuaXF1ZSBzaG9ydCBzZXNzaW9uIGlkZW50aWZpZXIs IGFuZCB3aGVuIEVESE9DIGlzIHVzZWQgd2l0aCBPU0NPQVAgdGhpcyBzZXNzaW9uIGlkZW50aWZp ZXIgYmVjb21lcyB0aGUgU2VuZGVyIElELCBzZWU8L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS0wNSNhcHBlbmRpeC1CLjIi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2Ro ZS0wNSNhcHBlbmRpeC1CLjI8L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij4NCihhZGRyZXNzaW5nIHlvdXIgY29tbWVudCBvbiAmcXVvdDtob3cgaXQg aXMgZ2VuZXJhdGVkJnF1b3Q7KSZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+SGF2aW5n IHNob3J0IHNlc3Npb24gaWRlbnRpZmllcnMgYWxzbyBvcHRpbWlzZXMgdGhlIEVESE9DIG1lc3Nh Z2VzLCBzaW5jZSB0aGV5IHNob3J0IChvZiBjb3Vyc2UpIGJ1dCBhbHNvIHNpbmNlIHRoZSBub25j ZXMgTl9VLCBOX1YgKHdoaWNoIGFyZSBsb25nZXIpIG9ubHkgbmVlZCB0byBiZSBzZW50IG9uY2Us IGluIGNvbXBhcmlzb24gd2l0aCBhIHByb3RvY29sIGNvbWJpbmluZyB0aGUgZnVuY3Rpb24NCiBv ZiBub25jZSBhbmQgc2Vzc2lvbiZuYnNwO2lkZW50aWZpZXIuPC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj4NCjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIz IiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPklmIHRoZXJlIGlzIGEgdHJ1c3RlZCB0aGlyZCBwYXJ0 eSZuYnNwO3N1Y2ggYXMgdGhlIEdyb3VwIE1hbmFnZXIgaW4gYSBtdWx0aWNhc3Qgc2V0dGluZyAo YXMgcmVmZXJlbmNlZCBiZWxvdykgdGhlbiB0aGUgYXNzaWdubWVudCBvZg0KIGlkZW50aWZpZXJz IGluIHRoZSBzZXQgb2YgZGV2aWNlcyBzaGFyaW5nIGEgY29tbW9uIGNvbnRleHQgY2FuIGJlIHVu aWxhdGVyYWxseSBkZWNpZGVkIGJ5IHRoZSBHTSBhbmQgdGhlIHNpemUgb2YgaWRlbnRpZmllcnMg b3B0aW1pc2VkIChhZGRyZXNzaW5nIHlvdXIgY29tbWVudCBvbiAmcXVvdDtvdXQgb2Ygc2NvcGUm cXVvdDsgLSB3aGljaCBpbiBteSBtYWlsIG9ubHkgcmVmZXJyZWQgdG8gdGhpcyBjYXNlKS4gTjwv Zm9udD48Zm9udCBzaXplPSIzIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHN0eWxl PSJmb250LWZhbWlseTogQ2FsaWJyaTsiPm90ZQ0KIHRoYXQgdGhlcmUgaXMgbm8gYWRkaXRpb25h bCBjb21wbGljYXRpb24gaW4gbWFraW5nIHRoaXMmbmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ2Fs aWJyaSI+YXNzaWdubWVudDwvZm9udD48Zm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPiZuYnNwO3NpbmNlIGl0IGp1c3QgaGFzIHRvIGJlIGxvY2FsbHkgdW5pcXVlIGZvciB0aGF0 IGdyb3VwLjwvZm9udD48L2ZvbnQ+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9 IjMiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+RGlkIHRoYXQgbWFrZSB0aGluZ3Mg bW9yZSBjbGVhcj8gRG8geW91IHRoaW5rIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMgYXJlIG5lZWRl ZCBpbiB0aGUgZHJhZnRzPC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Pzwv Zm9udD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxicj4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+VGhhbmtzPC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogbWVkaXVtOyI+R8O2cmFuPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGJyPg0K PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj48YnI+DQo8L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvcD4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9u dD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGJvcmRlci13aWR0aDogMXB0IG1l ZGl1bSBtZWRpdW07IGJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBwYWRkaW5nOiAzcHQg MGluIDBpbjsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyI+DQo8Zm9udCBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5Gcm9tOiZuYnNw Ozwvc3Bhbj42dGlzY2ggJmx0OzxhIGhyZWY9Im1haWx0bzo2dGlzY2gtYm91bmNlc0BpZXRmLm9y ZyI+NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSmltIFNjaGFh ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0 Y2VsbGFycy5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsi PkRhdGU6Jm5ic3A7PC9zcGFuPlRodXJzZGF5IDEzIEFwcmlsIDIwMTcgYXQgMTY6Mzk8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5UbzombmJzcDs8L3NwYW4+TW9oaXQgU2V0 aGkgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSI+bW9oaXQu bS5zZXRoaUBlcmljc3Nvbi5jb208L2E+Jmd0OywgR8O2cmFuIFNlbGFuZGVyICZsdDs8YSBocmVm PSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIj5nb3Jhbi5zZWxhbmRlckBlcmlj c3Nvbi5jb208L2E+Jmd0OywgJ0NvcmUnICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzo2dGlzY2hA aWV0Zi5vcmciPjZ0aXNjaEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzo2 dGlzY2hAaWV0Zi5vcmciPjZ0aXNjaEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OiBib2xkOyI+Q2M6Jm5ic3A7PC9zcGFuPidDaHJpc3RpYW4gQW1zw7xzcycg Jmx0OzxhIGhyZWY9Im1haWx0bzpjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdCI+Yy5hbXN1 ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDogYm9sZDsiPlN1YmplY3Q6Jm5ic3A7PC9zcGFuPlJlOiBbNnRpc2NoXSBbY29yZV0gUXVl c3Rpb24gYWJvdXQgQUVBRCBub25jZSB1bmlxdWVuZXNzPGJyPg0KPC9mb250PjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9m b250PjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+PC9zcGFuPjwvZm9udD48L3A+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGJvcmRlci1sZWZ0LWNv bG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1sZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1s ZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBweCAwcHggNXB4OyBtYXJnaW46IDBweCAw cHggMHB4IDVweDsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZt bCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxu czp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRw Oi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgY29sb3I6IGJsYWNrOyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiB3aW5kb3d0ZXh0OyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+VGhl IHNlbGVjdGlvbiBvZiBTX1ggaXMgZG9uZSBieSBwYXJ0eSBYLiZuYnNwOyBUaGlzIG1lYW5zIHRo YXQgYWxsIHRoZXkgbmVlZCB0byBkbyBpcyB0byBnZW5lcmF0ZSDigJMgZWl0aGVyIHJhbmRvbWx5 IG9yIGRldGVybWluaXN0aWNhbGx5DQog4oCTIHNvbWUgaWRlbnRpZmllciB3aGljaCBpcyBjdXJy ZW50bHkgdW5pcXVlIGZvciB0aGVtLjxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBjb2xvcjog YmxhY2s7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHdpbmRvd3RleHQ7Ij48bzpwPjxmb250IGZhY2U9 IkNhbGlicmkiIHNpemU9IjMiPiZuYnNwOzwvZm9udD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgY29sb3I6IGJs YWNrOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiB3aW5kb3d0ZXh0OyI+PGZvbnQgZmFjZT0iQ2FsaWJy aSIgc2l6ZT0iMyI+VGhlIGVhc2llc3Qgd2F5IHRvIGRvIHRoaXMgaXMgdG8gaGF2ZSBhbiBhcnJh eSBvZiBOIHNlY3VyaXR5IGNvbnRleHRzLiZuYnNwOyBDaG9vc2UgdGhlIGZpcnN0IHNsb3QgaW4g dGhlIGFycmF5IHdoaWNoIGlzIGVtcHR5IGFuZA0KIHVzZSB0aGF0IGluZGV4IGFzIHlvdXIgaWRl bnRpZmllci4mbmJzcDsgSWYgdGhlIGFycmF5IGlzIGZ1bGwsIHRoZW4gZWl0aGVyIGdyb3cgdGhl IGFycmF5IG9yIHNjYXZlbmdlIGEgc2VjdXJpdHkgY29udGV4dCB3aGljaCBoYXMgbm90IGJlZW4g dXNlZCBpbiBhIHdoaWxlIGFuZCB1c2UgdGhhdCBzbG90LiZuYnNwOyBUaGlzIGFsbG93cyBmb3Ig aWRlbnRpZmllcnMgdGhhdCBhcmUgdW5pcXVlIHRvIHRoZSBwYXJ0eSBhbmQgc3RpbGwgdmVyeSBz bWFsbC48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgY29sb3I6IGJsYWNrOyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiB3aW5kb3d0ZXh0OyI+PG86cD48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIz Ij4mbmJzcDs8L2ZvbnQ+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGNvbG9yOiBibGFjazsiPjxzcGFuIHN0eWxl PSJjb2xvcjogd2luZG93dGV4dDsiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPlRoZSBv bmx5IHRpbWUgdGhhdCBvbmUgd291bGQgbmVlZCBsYXJnZSByYW5kb20gaWRlbnRpZmllcnMgaXMg d2hlbiB0aGUga2V5aW5nIG1hdGVyaWFsIGlzIGdlbmVyYXRlZCBieSBhIHRoaXJkIHBhcnR5IHN1 Y2ggYXMNCiB0aGUgUFNLIHZlcnNpb24gb2YgRURIT0Mgd2hlcmUgdGhlIGNvbW1vbiBQU0sgbmVl ZHMgdG8gYmUgaWRlbnRpZmllZCBmb3IgYm90aCBwYXJ0aWVzLjxvOnA+PC9vOnA+PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBjb2xvcjogYmxhY2s7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHdpbmRvd3RleHQ7Ij48 bzpwPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZuYnNwOzwvZm9udD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgY29sb3I6IGJsYWNrOyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+PHNwYW4g c3R5bGU9ImNvbG9yOiB3aW5kb3d0ZXh0OyI+SSBhbHNvIGRvIG5vdCBoYXZlIHRoZSBzYW1lIHBy b2JsZW1zIHdpdGggY29sbGlzaW9ucyB0aGF0Jm5ic3A7PC9zcGFuPkfDtnJhbiBhbmQgb3RoZXJz IGhhdmUuJm5ic3A7IEkgYW0gd2lsbGluZyB0byB0cnkgbXVsdGlwbGUga2V5cyBpbg0KIHRoZSBl dmVudCBvZiBhIGNvbGxpc2lvbiBhbmQgb25seSB0aGUgY29ycmVjdCBvbmUgd2lsbCB3b3JrLiZu YnNwOyBUaGlzIGlzIG5vdCB1bnVzdWFsIGluIHNvbWUgY2FzZXMgYWxyZWFkeSBpbiBvdGhlciBl bnZpcm9ubWVudHMuPG86cD48L286cD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgY29sb3I6IGJsYWNrOyI+PG86cD48Zm9u dCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgY29sb3I6IGJs YWNrOyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+SmltPG86cD48L286cD48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgY29sb3I6IGJsYWNrOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiB3aW5kb3d0ZXh0OyI+PG86cD48 Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg Y29sb3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHdpbmRvd3RleHQ7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlk IG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXIt dG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiB3aW5kb3d0ZXh0OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog d2luZG93dGV4dDsiPiZuYnNwO01vaGl0IFNldGhpIFs8YSBocmVmPSJtYWlsdG86bW9oaXQubS5z ZXRoaUBlcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiPm1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTwvYT5dJm5ic3A7 PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7VGh1cnNkYXksIEFwcmlsIDEzLCAyMDE3IDI6NDYgQU08 YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7R8O2cmFuIFNlbGFuZGVyICZsdDs8YSBocmVmPSJtYWlsdG86 Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5nb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+Jmd0 OzsgJ0NvcmUnICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+Y29yZUBpZXRmLm9yZzwvYT4m Z3Q7OyZuYnNwOzxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPjZ0aXNjaEBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7SmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZA YXVndXN0Y2VsbGFycy5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OzsgQ2hyaXN0aWFuIEFt c8O8c3MgJmx0OzxhIGhyZWY9Im1haWx0bzpjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdCIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+Yy5hbXN1 ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNw O1JlOiBbY29yZV0gUXVlc3Rpb24gYWJvdXQgQUVBRCBub25jZSB1bmlxdWVuZXNzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgY29sb3I6IGJsYWNrOyI+DQo8bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+SGkgR8O2cmFuLCBKaW0gYW5kIENocmlzdGlhbjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij5UaGFua3MgZm9yIHJlc3BvbmRpbmcgdG8gbXkgcXVlc3Rpb24uIEBHw7ZyYW46IGJv dGggMSkgdXNlIEVESE9DIG9yIDIpIGdlbmVyYXRlIGxhcmdlIHJhbmRvbSBpZGVudGlmaWVycywg YXJlIHRoZSBzYW1lIHRoaW5nLiBIb3cgYXJlIHRoZXkgYW55IGRpZmZlcmVudD8gSSB3ZW50IHRo cm91Z2ggRURIT0MgZHJhZnQgYW5kIGl0IHNheXMgdGhhdA0KIHNlbmRlciBpZCBpcyBTX1Ygd2hp Y2ggaXMgdmFyaWFibGUgbGVuZ3RoIHNlc3Npb24gaWRlbnRpZmllciAoPSBnZW5lcmF0ZSBsYXJn ZSByYW5kb20gaWRlbnRpZmllcikuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iZm9udC1zaXpl OiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPkkgYW0gYWZyYWlkIHNp bXBseSB3YXZpbmcgb2ZmIHRoZSBwcm9ibGVtIGFzIG91dCBvZiBzY29wZSBtYXkgbGVhZCB0byBz b21lIChtYW55KSBpbnRlciBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4gSWYgdGhlIFNlbmRlciBJ RCBpcyB2YXJpYWJsZSBsZW5ndGgsIGRpZmZlcmVudCBtYW51ZmFjdHVyZXJzIG1heSBpbXBsZW1l bnQgaXQgdmVyeQ0KIGRpZmZlcmVudGx5IGFuZCBjb3VsZCBjYXVzZSBjb2xsaXNpb24gd2l0aCBq dXN0IDItMyBkZXZpY2VzLiBJZiB0aGV5IGFyZSBnZW5lcmF0ZWQgaW4gc29mdHdhcmUgYXQgcnVu IHRpbWUsIHlvdSBjYW4gc3RpbGwgZG8gc29tZXRoaW5nIGFib3V0IGl0LCBidXQgaWYgaXQgaXMg YnVybnQgaW50byB0aGUgZGV2aWNlLCB0aGVuIHRoZXJlIGlzIG5vIHdheSB0byByZWNvdmVyIGZy b20gLiBBdCB0aGUgdmVyeSBsZWFzdCB0aGVyZSBjb3VsZCBiZSBiZXR0ZXINCiBndWlkYW5jZS4g SSBhbHNvIHRoaW5rIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIG1pbmltdW0gbGVuZ3Ro IHNwZWNpZmllZCBhbmQgc29tZSByZWNvbW1lbmRhdGlvbnMvZ3VpZGVsaW5lcyBvbiBob3cgaXQg aXMgZ2VuZXJhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5JIHdvdWxkIGFsc28gbGlrZSB0byBr bm93IHdoYXQgYXJlIHRoZSBjb25jcmV0ZSBhZmZlY3RzIG9mIGEgY29sbGlzaW9uPzxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij4tLU1vaGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGNvbG9yOiBibGFjazsiPg0KPG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KT24gMDQvMTEvMjAxNyAwODo0 MyBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgbWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9y OiBibGFjazsiPg0KSGVsbG8gTW9oaXQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9y OiBibGFjazsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFj azsiPg0KQ2hyaXN0aWFuIGFuZCBKaW0gYWxyZWFkeSBwcm92aWRlZCBhbnN3ZXJzLCBsZXQgbWUg anVzdCBwcm92aWRlIHBvaW50ZXJzIHRvIHRoZSByZWxldmFudCBzZWN0aW9ucy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+DQpPU0NPQVA6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IGNvbG9yOiBibGFjazsiPg0K4oCUPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNv bG9yOiBibGFjazsiPg0KVGhlIHJlcXVpcmVtZW50cyBvbiB0aGUgc2VjdXJpdHkgY29udGV4dCBw YXJhbWV0ZXJzIGFyZSBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxh Y2s7Ij4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNv cmUtb2JqZWN0LXNlY3VyaXR5LTAyI3NlY3Rpb24tMy4zIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0wMiNzZWN0aW9uLTMuMzwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+DQpUd28gbWV0aG9kcyBmb3IgZXN0 YWJsaXNoaW5nIHVuaXF1ZSBzZW5kZXIgSURzIGFyZSBwcmVzZW50ZWQ6IDEpIHVzZSBFREhPQyBv ciAyKSBnZW5lcmF0ZSBsYXJnZSByYW5kb20gaWRlbnRpZmllcnMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KVGhlIGZvcm1lciBhbGxvd3MgZm9yIHRo ZSB1c2Ugb2Ygc2hvcnQgc2VuZGVyIElEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29s b3I6IGJsYWNrOyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJs YWNrOyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+ DQpNdWx0aWNhc3QgT1NDT0FQOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxh Y2s7Ij4NCuKAlDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4NCklu IE11bHRpY2FzdCBPU0NPQVAgKFNlY3VyZSBncm91cCBjb21tdW5pY2F0aW9uIGZvciBDb0FQKSB0 aGUgcmVxdWlyZW1lbnRzIG9uIHRoZSBzZWN1cml0eSBjb250ZXh0IHBhcmFtZXRlcnMgYXJlIGhl cmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1v c2NvYXAtMDEjc2VjdGlvbi0yIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGlsb2NhLWNv cmUtbXVsdGljYXN0LW9zY29hcC0wMSNzZWN0aW9uLTI8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IGNvbG9yOiBibGFjazsiPg0KSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBH cm91cCBNYW5hZ2VyIHRvIGVzdGFibGlzaCBhbmQgbWFuYWdlIHRoZSBzZWN1cml0eSBjb250ZXh0 LCB3aGljaCBpbmNsdWRlcyB0aGUgc2VuZGVyIElEcywgYnV0IGhvdyB0aGUgYXNzaWdubWVudCBp cyBkb25lIGlzIG91dCBvZiBzY29wZS4gVGhlIHVuaXF1ZW5lc3Mgb2Ygc2VuZGVyIElEcyBpbiB0 aGlzIGRyYWZ0IGZvbGxvd3MgZnJvbSBPU0NPQVAsIGJ1dCBzaW5jZSB5b3UgYXNrZWQgSQ0KIHRo aW5rIHdlIHNob3VsZCBhZGQgYSBzZW50ZW5jZSB0byB0aGlzIGRyYWZ0IHN0cmVzc2luZyB0aGF0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4NCjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4NCkfDtnJhbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBjb2xvcjogYmxhY2s7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjog cmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAw aW4gMGluOyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IGNvbG9yOiBibGFjazsiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Gcm9tOiZuYnNwOzwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij5jb3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5jb3JlLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBKaW0gU2NoYWFkICZsdDs8YSBo cmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+TW9uZGF5IDEwIEFwcmlsIDIwMTcgYXQgMTk6MDk8 YnI+DQo8Yj5UbzombmJzcDs8L2I+TW9oaXQgU2V0aGkgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hp dC5tLnNldGhpQGVyaWNzc29uLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyI+bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb208L2E+Jmd0OywgJ0Nv cmUnICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7LA0K ICZxdW90OzxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVy cGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPjZ0aXNjaEBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVy cGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPjZ0aXNjaEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+UmU6IFtjb3JlXSBRdWVzdGlvbiBhYm91dCBBRUFE IG5vbmNlIHVuaXF1ZW5lc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9y OiBibGFjazsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iYm9yZGVyLXN0eWxl OiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5Niwg MjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDQuNXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7 IG1hcmdpbi1sZWZ0OiAzLjc1cHQ7IG1hcmdpbi1yaWdodDogMGluOyI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29s b3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHdpbmRvd3RleHQ7Ij5UaGVyZSBpcyBub3QgYSBw cm9ibGVtIHdpdGggZGVhbGluZyB3aXRoIG5vbmNlIHVuaXF1ZW5lc3MgaW4gdGhpcyBkcmFmdCBi ZWNhdXNlIGVhY2ggZW50aXR5IGlzIGdvaW5nIHRvIGJlIGFzc2lnbmVkIHRvIGEgdW5pcXVlIGtl eSBmb3IgdHJhbnNtaXNzaW9ucy4mbmJzcDsgVGhlIHRyYW5zcG9ydCBrZXkgaXMNCiBkZXJpdmVk IGZyb20gdGhlIFBTSyBhbmQgdGhlIHNlbmRlciBJRC4mbmJzcDsgU2VuZGVyIElEcyB3aWxsIGJl IHVuaXF1ZSBiYXNlZCBvbiB0aGUgZW5yb2xsbWVudCBwcm90b2NvbCBpbiB0aGUgZ3JvdXAgYXMg ZWFjaCBlbnRpdHkgd2lsbCBoYXZlIGEgdW5pcXVlIGlkZW50aWZpZXIuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBjb2xvcjogYmxhY2s7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogd2luZG93dGV4dDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHdpbmRvd3Rl eHQ7Ij5KaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiB3aW5kb3d0ZXh0OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogd2luZG93dGV4dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1s ZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IHBhZGRpbmc6IDBpbiAw aW4gMGluIDRwdDsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9u ZSBub25lOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3At d2lkdGg6IDFwdDsgcGFkZGluZzogM3B0IDBpbiAwaW47Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHdpbmRvd3RleHQ7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiB3aW5k b3d0ZXh0OyI+Jm5ic3A7Y29yZSBbPGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y ZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+bWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dJm5ic3A7PGI+T24NCiBCZWhhbGYgT2YmbmJz cDs8L2I+TW9oaXQgU2V0aGk8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDtNb25kYXksIEFwcmlsIDEw LCAyMDE3IDQ6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7Q29yZSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNvcmVAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0OzsmbmJzcDs8YSBocmVmPSJtYWlsdG86 NnRpc2NoQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7Ij42dGlzY2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7 W2NvcmVdIFF1ZXN0aW9uIGFib3V0IEFFQUQgbm9uY2UgdW5pcXVlbmVzczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8cD5IaSBPU0NvQVAgYXV0aG9yczxvOnA+PC9vOnA+PC9wPg0KPHA+SSB3YXMgdHJ5aW5n IHRvIHJlYWQgdGhlIE9TQ29BUCBhbmQgNnRpc2NoIG1pbmltYWwgc2VjdXJpdHkgZHJhZnRzLiBJ IGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgQUVBRCBub25jZSB1bmlxdWVuZXNzLiBSRkMgNTEx NiBzYXlzIHRoYXQ6PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNv bG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyBXaGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBkZXZpY2Vz IHBlcmZvcm1pbmcgZW5jcnlwdGlvbiB1c2luZyBhIHNpbmdsZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyBrZXks IHRob3NlIGRldmljZXMgbXVzdCBjb29yZGluYXRlIHRvIGVuc3VyZSB0aGF0IHRoZSBub25jZXMg YXJlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgY29sb3I6IGJs YWNrOyI+Jm5ic3A7Jm5ic3A7IHVuaXF1ZS4mbmJzcDsgQSBzaW1wbGUgd2F5IHRvIGRvIHRoaXMg aXMgdG8gdXNlIGEgbm9uY2UgZm9ybWF0IHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgY29udGFpbnMgYSBm aWVsZCB0aGF0IGlzIGRpc3RpbmN0IGZvciBlYWNoIG9uZSBvZiB0aGUgZGV2aWNlczxvOnA+PC9v OnA+PC9wcmU+DQo8cD5TbyBteSBvYnZpb3VzIHF1ZXN0aW9uIGlzIGhvdyBpcyB0aGUgQUVBRCBu b25jZSB1bmlxdWVuZXNzIGVuc3VyZWQuIFRoZSBQU0sgaXMga25vd24gdG8gYXQgbGVhc3QgdHdv IHBhcnRpZXMgKG1vcmUgaW4gY2FzZSBvZiBzb21lIHVzZXMgc3VjaCBhcyBtdWx0aWNhc3QgT1ND b0FQJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9j YS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAxPC9hPik/PzxvOnA+PC9vOnA+PC9wPg0KPHA+ VGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzIHRoYXQgQUVBRCBOb25jZSB1bmlxdWVuZXNzIGlzIGVu c3VyZWQgd2l0aCBzZXF1ZW5jZSBudW1iZXJzIGFuZCBzZW5kZXIgY29udGV4dCB3aGljaCBpcyBl c3NlbnRpYWxseSB0aGUgc2VuZGVyIElELiBCdXQgaG93IGRvIHlvdSBlbnN1cmUgdGhhdCB0aGUg dHdvIHBhcnRpZXMgaGF2ZSBkaWZmZXJlbnQgc2VuZGVyIElELiBFc3BlY2lhbGx5IHNpbmNlIHNl bmRlciBJRCBpcyBub3QgZml4ZWQgbGVuZ3RoLg0KIEkgZ3Vlc3MgdGhlcmUgd2lsbCBiZSBvdGhl ciBwcm9ibGVtcyBpbiBjYXNlIG9mIHNlbmRlciBJRCBjb2xsaXNpb25zPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9y OiBibGFjazsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkLCBz ZXJpZjsiPmFzIFNlbmRlciBJRHMgYXJlIGN1cnJlbnRseSB1c2VkLCB0aGV5IGFyZSBtdXR1YWxs eSBhZ3JlZWQtdXBvbiBsaWtlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg Y29sb3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQsIHNlcmlmOyI+cmVzdCBvZiB0aGUgc2VjdXJpdHkgY29udGV4dCAoa2V5LCBhbGdvcml0aG0g ZXRjKTsgaW4gb3RoZXIgd29yZHMsIHRoZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IGNvbG9yOiBibGFjazsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0 YW5kYXJkLCBzZXJpZjsiPmFyZSBleHBsaWNpdGx5IGdpdmVuIHRvIGEgZGV2aWNlIGJ5IHRoZSBt ZWNoYW5pc20gdGhhdCBhbHNvIGRpc3RyaWJ1dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtp dC1zdGFuZGFyZCwgc2VyaWY7Ij50aGUga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsgY29sb3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQsIHNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBjb2xvcjogYmxhY2s7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFu ZGFyZCwgc2VyaWY7Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IGNvbG9yOiBibGFjazsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0 YW5kYXJkLCBzZXJpZjsiPkNocmlzdGlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgY29sb3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3Rh bmRhcmQsIHNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBj b2xvcjogYmxhY2s7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZCwgc2VyaWY7Ij4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29s b3I6IGJsYWNrOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQs IHNlcmlmOyI+Q2hyaXN0aWFuIEFtc8O8c3MmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IEVuZXJneSBIYXJ2 ZXN0aW5nIFNvbHV0aW9ucyBHbWJIPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBj b2xvcjogYmxhY2s7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZCwgc2VyaWY7Ij5mb3VuZGVyLCBzeXN0ZW0gYXJjaGl0ZWN0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgaGVh ZHF1YXJ0ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7 Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZCwgc2VyaWY7Ij48 YSBocmVmPSJtYWlsdG86Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQiIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPm1haWx0bzpjLmFtc3Vlc3NA ZW5lcmd5aGFydmVzdGluZy5hdDwvYT4mbmJzcDsmbmJzcDt8IEFyYmVpdGVyZ2Fzc2UgMTUsIEEt NDQwMCBTdGV5cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNr OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQsIHNlcmlmOyI+ PGEgaHJlZj0idGVsOiYjNDM7NDMtNjY0LTk3LTkwLTYtMzkiIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPnRlbDomIzQzOzQzLTY2NC05Ny05MC02LTM5 PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDs8YSBocmVm PSJodHRwOi8vd3d3LmVuZXJneWhhcnZlc3RpbmcuYXQvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5odHRwOi8vd3d3LmVuZXJneWhhcnZlc3Rpbmcu YXQvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQsIHNlcmlmOyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBB VFU2ODQ3NjYxNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xv cjogYmxhY2s7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxh Y2s7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGNvbG9yOiBi bGFjazsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7 IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkct TEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNv bGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+TW9oaXQgU2V0aGkgJmx0Ozxh IGhyZWY9Im1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSI+bW9oaXQubS5zZXRoaUBl cmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E YXRlOiA8L3NwYW4+VGh1cnNkYXkgMTMgQXByaWwgMjAxNyBhdCAxMTo0NTxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkfDtnJhbiBTZWxhbmRlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbSI+Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPC9hPiZndDssICdDb3JlJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0 Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOjZ0aXNj aEBpZXRmLm9yZyI+NnRpc2NoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OjZ0aXNjaEBpZXRmLm9yZyI+NnRpc2NoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5KaW0gU2NoYWFkICZsdDs8YSBocmVmPSJt YWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4m Z3Q7LCBDaHJpc3RpYW4gQW1zw7xzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmMuYW1zdWVzc0BlbmVy Z3loYXJ2ZXN0aW5nLmF0Ij5jLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdDwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW2Nv cmVdIFF1ZXN0aW9uIGFib3V0IEFFQUQgbm9uY2UgdW5pcXVlbmVzczxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdj b2xvcj0iI0ZGRkZGRiI+DQo8cD5IaSBHw7ZyYW4sIEppbSBhbmQgQ2hyaXN0aWFuPC9wPg0KPHA+ VGhhbmtzIGZvciByZXNwb25kaW5nIHRvIG15IHF1ZXN0aW9uLiBAR8O2cmFuOiBib3RoIDEpIHVz ZSBFREhPQyBvciAyKSBnZW5lcmF0ZSBsYXJnZSByYW5kb20gaWRlbnRpZmllcnMsIGFyZSB0aGUg c2FtZSB0aGluZy4gSG93IGFyZSB0aGV5IGFueSBkaWZmZXJlbnQ/IEkgd2VudCB0aHJvdWdoIEVE SE9DIGRyYWZ0IGFuZCBpdCBzYXlzIHRoYXQgc2VuZGVyIGlkIGlzIFNfViB3aGljaCBpcyB2YXJp YWJsZSBsZW5ndGggc2Vzc2lvbiBpZGVudGlmaWVyDQogKD0gZ2VuZXJhdGUgbGFyZ2UgcmFuZG9t IGlkZW50aWZpZXIpLjxicj4NCjwvcD4NCjxwPkkgYW0gYWZyYWlkIHNpbXBseSB3YXZpbmcgb2Zm IHRoZSBwcm9ibGVtIGFzIG91dCBvZiBzY29wZSBtYXkgbGVhZCB0byBzb21lIChtYW55KSBpbnRl ciBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4gSWYgdGhlIFNlbmRlciBJRCBpcyB2YXJpYWJsZSBs ZW5ndGgsIGRpZmZlcmVudCBtYW51ZmFjdHVyZXJzIG1heSBpbXBsZW1lbnQgaXQgdmVyeSBkaWZm ZXJlbnRseSBhbmQgY291bGQgY2F1c2UgY29sbGlzaW9uIHdpdGgganVzdCAyLTMgZGV2aWNlcy4N CiBJZiB0aGV5IGFyZSBnZW5lcmF0ZWQgaW4gc29mdHdhcmUgYXQgcnVuIHRpbWUsIHlvdSBjYW4g c3RpbGwgZG8gc29tZXRoaW5nIGFib3V0IGl0LCBidXQgaWYgaXQgaXMgYnVybnQgaW50byB0aGUg ZGV2aWNlLCB0aGVuIHRoZXJlIGlzIG5vIHdheSB0byByZWNvdmVyIGZyb20gLiBBdCB0aGUgdmVy eSBsZWFzdCB0aGVyZSBjb3VsZCBiZSBiZXR0ZXIgZ3VpZGFuY2UuIEkgYWxzbyB0aGluayBpdCB3 b3VsZCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBtaW5pbXVtDQogbGVuZ3RoIHNwZWNpZmllZCBhbmQg c29tZSByZWNvbW1lbmRhdGlvbnMvZ3VpZGVsaW5lcyBvbiBob3cgaXQgaXMgZ2VuZXJhdGVkLjxi cj4NCjwvcD4NCjxwPkkgd291bGQgYWxzbyBsaWtlIHRvIGtub3cgd2hhdCBhcmUgdGhlIGNvbmNy ZXRlIGFmZmVjdHMgb2YgYSBjb2xsaXNpb24/PC9wPg0KPHA+LS1Nb2hpdDxicj4NCjwvcD4NCjxi cj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMDQvMTEvMjAxNyAwODo0MyBBTSwg R8O2cmFuIFNlbGFuZGVyIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlk OkQ1MTIyOTdDLjdCNTlEJTI1Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIiB0eXBlPSJjaXRl Ij4NCjxkaXY+SGVsbG8gTW9oaXQsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaHJp c3RpYW4gYW5kIEppbSBhbHJlYWR5IHByb3ZpZGVkIGFuc3dlcnMsIGxldCBtZSBqdXN0IHByb3Zp ZGUgcG9pbnRlcnMgdG8gdGhlIHJlbGV2YW50IHNlY3Rpb25zLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+T1NDT0FQOjwvZGl2Pg0KPGRpdj7igJQ8L2Rpdj4NCjxkaXY+VGhlIHJlcXVp cmVtZW50cyBvbiB0aGUgc2VjdXJpdHkgY29udGV4dCBwYXJhbWV0ZXJzIGFyZSBoZXJlOjwvZGl2 Pg0KPGRpdj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTAyI3NlY3Rpb24tMy4z Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1 cml0eS0wMiNzZWN0aW9uLTMuMzwvYT48L2Rpdj4NCjxkaXY+VHdvIG1ldGhvZHMgZm9yIGVzdGFi bGlzaGluZyB1bmlxdWUgc2VuZGVyIElEcyBhcmUgcHJlc2VudGVkOiAxKSB1c2UgRURIT0Mgb3Ig MikgZ2VuZXJhdGUgbGFyZ2UgcmFuZG9tIGlkZW50aWZpZXJzLiZuYnNwOzwvZGl2Pg0KPGRpdj5U aGUgZm9ybWVyIGFsbG93cyBmb3IgdGhlIHVzZSBvZiBzaG9ydCBzZW5kZXIgSURzLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk11bHRpY2FzdCBPU0NP QVA6PC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj5JbiBNdWx0aWNhc3QgT1NDT0FQIChTZWN1 cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUCkgdGhlIHJlcXVpcmVtZW50cyBvbiB0aGUg c2VjdXJpdHkgY29udGV4dCBwYXJhbWV0ZXJzIGFyZSBoZXJlOjwvZGl2Pg0KPGRpdj48YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAxI3NlY3Rpb24tMiI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDEjc2Vj dGlvbi0yPC9hPjwvZGl2Pg0KPGRpdj5JdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIEdy b3VwIE1hbmFnZXIgdG8gZXN0YWJsaXNoIGFuZCBtYW5hZ2UgdGhlIHNlY3VyaXR5IGNvbnRleHQs IHdoaWNoIGluY2x1ZGVzIHRoZSBzZW5kZXIgSURzLCBidXQgaG93IHRoZSBhc3NpZ25tZW50IGlz IGRvbmUgaXMgb3V0IG9mIHNjb3BlLiBUaGUgdW5pcXVlbmVzcyBvZiBzZW5kZXIgSURzIGluIHRo aXMgZHJhZnQgZm9sbG93cyBmcm9tIE9TQ09BUCwgYnV0IHNpbmNlIHlvdSBhc2tlZA0KIEkgdGhp bmsgd2Ugc2hvdWxkIGFkZCBhIHNlbnRlbmNlIHRvIHRoaXMgZHJhZnQgc3RyZXNzaW5nIHRoYXQu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R8O2cmFu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJP TEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBm b250LXNpemU6MTFwdDsNCiAgICAgICAgICB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBC T1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsNCiAgICAgICAgICBCT1JERVItTEVGVDogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDoNCiAgICAgICAgICAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7DQogICAg ICAgICAgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPmNvcmUgJmx0OzxhIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyI+Y29y ZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEppbSBTY2hhYWQgJmx0Ozxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5j b20iPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5IDEwIEFwcmlsIDIwMTcgYXQgMTk6MDk8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Nb2hpdCBTZXRo aSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRo aUBlcmljc3Nvbi5jb20iPm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPC9hPiZndDssICdDb3Jl JyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUi IGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciPjZ0aXNjaEBpZXRmLm9yZzwvYT4mcXVvdDsN CiAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYu b3JnIj42dGlzY2hAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtjb3JlXSBRdWVzdGlvbiBhYm91dCBBRUFEIG5v bmNlIHVuaXF1ZW5lc3M8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1M RUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjANCiAgICAgICAg ICAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIg eG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8v d3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkDQogICAgICAgICAgICAgIG1lZGl1bSkiPg0K PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8ZGl2IGJnY29sb3I9IndoaXRlIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBs YW5nPSJFTi1VUyI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlRoZXJlIGlzIG5vdCBhIHBy b2JsZW0gd2l0aCBkZWFsaW5nIHdpdGggbm9uY2UgdW5pcXVlbmVzcyBpbiB0aGlzIGRyYWZ0IGJl Y2F1c2UgZWFjaCBlbnRpdHkgaXMgZ29pbmcgdG8gYmUgYXNzaWduZWQgdG8gYSB1bmlxdWUga2V5 IGZvciB0cmFuc21pc3Npb25zLiZuYnNwOyBUaGUNCiB0cmFuc3BvcnQga2V5IGlzIGRlcml2ZWQg ZnJvbSB0aGUgUFNLIGFuZCB0aGUgc2VuZGVyIElELiZuYnNwOyBTZW5kZXIgSURzIHdpbGwgYmUg dW5pcXVlIGJhc2VkIG9uIHRoZSBlbnJvbGxtZW50IHByb3RvY29sIGluIHRoZSBncm91cCBhcyBl YWNoIGVudGl0eSB3aWxsIGhhdmUgYSB1bmlxdWUgaWRlbnRpZmllci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkppbTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0KICAgICAg ICAgICAgICAgICAgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxDQogICAgICAgICAg ICAgICAgICAgICAgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gY29yZSBbPGEgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TW9oaXQg U2V0aGk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxMCwgMjAxNyA0OjUxIEFNPGJy Pg0KPGI+VG86PC9iPiBDb3JlICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1h aWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDs7DQo8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciPjZ0aXNjaEBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIFF1ZXN0aW9uIGFib3V0IEFFQUQgbm9u Y2UgdW5pcXVlbmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhpIE9TQ29BUCBhdXRo b3JzPG86cD48L286cD48L3A+DQo8cD5JIHdhcyB0cnlpbmcgdG8gcmVhZCB0aGUgT1NDb0FQIGFu ZCA2dGlzY2ggbWluaW1hbCBzZWN1cml0eSBkcmFmdHMuIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0 IHRoZSBBRUFEIG5vbmNlIHVuaXF1ZW5lc3MuIFJGQyA1MTE2IHNheXMgdGhhdDo8bzpwPjwvbzpw PjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGRldmljZXMg cGVyZm9ybWluZyBlbmNyeXB0aW9uIHVzaW5nIGEgc2luZ2xlPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IGtleSwgdGhvc2UgZGV2aWNlcyBtdXN0IGNvb3JkaW5hdGUgdG8gZW5z dXJlIHRoYXQgdGhlIG5vbmNlcyBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgdW5pcXVlLiZuYnNwOyBBIHNpbXBsZSB3YXkgdG8gZG8gdGhpcyBpcyB0byB1c2UgYSBub25j ZSBmb3JtYXQgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb250YWlu cyBhIGZpZWxkIHRoYXQgaXMgZGlzdGluY3QgZm9yIGVhY2ggb25lIG9mIHRoZSBkZXZpY2VzPG86 cD48L286cD48L3ByZT4NCjxwPlNvIG15IG9idmlvdXMgcXVlc3Rpb24gaXMgaG93IGlzIHRoZSBB RUFEIG5vbmNlIHVuaXF1ZW5lc3MgZW5zdXJlZC4gVGhlIFBTSyBpcyBrbm93biB0byBhdCBsZWFz dCB0d28gcGFydGllcyAobW9yZSBpbiBjYXNlIG9mIHNvbWUgdXNlcyBzdWNoIGFzIG11bHRpY2Fz dCBPU0NvQVANCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDEiPg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2Nv YXAtMDE8L2E+KT8/IDxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlz IHRoYXQgQUVBRCBOb25jZSB1bmlxdWVuZXNzIGlzIGVuc3VyZWQgd2l0aCBzZXF1ZW5jZSBudW1i ZXJzIGFuZCBzZW5kZXIgY29udGV4dCB3aGljaCBpcyBlc3NlbnRpYWxseSB0aGUgc2VuZGVyIElE LiBCdXQgaG93IGRvIHlvdSBlbnN1cmUgdGhhdCB0aGUgdHdvIHBhcnRpZXMgaGF2ZSBkaWZmZXJl bnQgc2VuZGVyIElELiBFc3BlY2lhbGx5IHNpbmNlIHNlbmRlciBJRCBpcyBub3QgZml4ZWQgbGVu Z3RoLg0KIEkgZ3Vlc3MgdGhlcmUgd2lsbCBiZSBvdGhlciBwcm9ibGVtcyBpbiBjYXNlIG9mIHNl bmRlciBJRCBjb2xsaXNpb25zPzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAt d2Via2l0LXN0YW5kYXJkOyI+YXMgU2VuZGVyIElEcyBhcmUgY3VycmVudGx5IHVzZWQsIHRoZXkg YXJlIG11dHVhbGx5IGFncmVlZC11cG9uIGxpa2UgdGhlPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPnJlc3Qgb2YgdGhlIHNlY3VyaXR5IGNvbnRleHQg KGtleSwgYWxnb3JpdGhtIGV0Yyk7IGluIG90aGVyIHdvcmRzLCB0aGV5PC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPmFyZSBleHBsaWNpdGx5IGdpdmVu IHRvIGEgZGV2aWNlIGJ5IHRoZSBtZWNoYW5pc20gdGhhdCBhbHNvIGRpc3RyaWJ1dGVzPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPnRoZSBrZXkuPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5CZXN0IHJl Z2FyZHM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+ Q2hyaXN0aWFuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij4tLSZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3Rh bmRhcmQ7Ij5DaHJpc3RpYW4gQW1zw7xzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgRW5lcmd5IEhhcnZl c3RpbmcgU29sdXRpb25zIEdtYkg8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN0YW5kYXJkOyI+Zm91bmRlciwgc3lzdGVtIGFyY2hpdGVjdCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IGhlYWRxdWFydGVyOjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3Rh bmRhcmQ7Ij48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjLmFtc3Vlc3NA ZW5lcmd5aGFydmVzdGluZy5hdCI+bWFpbHRvOmMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0 PC9hPiZuYnNwOyZuYnNwO3wgQXJiZWl0ZXJnYXNzZSAxNSwgQS00NDAwIFN0ZXlyPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPnRlbDomIzQzOzQzLTY2 NC05Ny05MC02LTM5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNw OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL3d3dy5lbmVyZ3loYXJ2ZXN0 aW5nLmF0LyI+aHR0cDovL3d3dy5lbmVyZ3loYXJ2ZXN0aW5nLmF0LzwvYT48L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBBVFU2ODQ3NjYxNDwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_D5161FCE7BAA8goranselanderericssoncom_-- From nobody Tue Apr 18 05:47:33 2017 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 D45B312EB88; Tue, 18 Apr 2017 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 JkQQnjBunmpA; Tue, 18 Apr 2017 05:47:29 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FDF12420B; Tue, 18 Apr 2017 05:47:29 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id c45so123688668qtb.1; Tue, 18 Apr 2017 05:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lsAj+8l6lI8C4/5VmvmY1YQ0PuxbxkFimPzx4OG+Ucg=; b=kVFBzdI8Y3UxFPQ4GjXLSxNulNR1YSu2SfzzFqQNUhqE6gA1vAjRd5o01rOHd0nkr2 13M6SH4iucDzFh3qSIDYffOIOM/e5km9lAiltLu4uz3ijwfT9z0MIct5SWEwYGl0bHr4 bu5O4HSpP8I1o56sjGLjt22+UPd5tBIE6T4iXDk7pgW6vRuDQUhzkiOU+MXENw7edYS9 dR5OmkiWAdRnEIl58XcnOQPo9cXegxGL5+9Jx68df/DTjTurJDZMimh4jEbR6vz6sDbC 16qiXV0BcAr9HPSBztgmj9RRpYxtnw+3wyckMM4PKkzDfIgHuVF4V/wFuJYMk58NevpH +org== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lsAj+8l6lI8C4/5VmvmY1YQ0PuxbxkFimPzx4OG+Ucg=; b=KoyG2fW14GBjX661JMEBcreXt1stXg6fDfqnpouh+zj87evLXqdPeerOAjTVafXkHW +jn8ing+XbMO3mYSQ3C0e91YfsQYlAYvg+kw8lL90IFNbgtb3XG5sb75EhcHsR+aq5vy Q3w9jEAEafYIeDot1BAOqxAgNMzwbg8ReC9rSQpBR/8cW3ttcADMIFW/BRNrMMHpqXYW 0bX1rJKu0pZclpU7Ydbk3jhBiK8aXy1MAGjCX/9F3v2SzGnQXYb0Lk/zXL/1Q4jqOzsz Wu/rmT0va25mNOVydGNyGW0EIDA7HwpgBnVfzduDJGsW5KZ3AbSE2Bc3CMR7rQjgVMpk uJwQ== X-Gm-Message-State: AN3rC/40XV7Wzb/BZU4TZ/6sGhyJfb0y61pZHSDWiVUTYHgpgeq/1Vzo 6ck9kpbqab704nMg6Qhy6A9yJg7AGg== X-Received: by 10.200.36.240 with SMTP id t45mr12970125qtt.230.1492519648189; Tue, 18 Apr 2017 05:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.45.162 with HTTP; Tue, 18 Apr 2017 05:47:27 -0700 (PDT) In-Reply-To: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> From: Herbert Van de Sompel Date: Tue, 18 Apr 2017 14:47:27 +0200 Message-ID: To: Carsten Bormann Cc: Mark Nottingham , art@ietf.org, ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org, Herbert Van de Sompel Content-Type: multipart/alternative; boundary=001a1140eede73628d054d704f68 Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:47:32 -0000 --001a1140eede73628d054d704f68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi Mark, Carsten, Sorry to be a bit late to the game. Two things: 1. I would be very interested in documents serialized according to application/link-format+json as described in the I-D, especially in the context of an I-D Erik Wilde and I are authoring regarding Link Sets, see https://datatracker.ietf.org/doc/draft-wilde-linkset-link-rel/ 2. Regarding Mark's comment "This means that any constraints upon RFC6690 documents are also mirrored into these formats": Mark mentions IRIs as a concern. I am also concerned about the rules for interpretation of (the Context IRI of) links as described in Section 2.1 of 6690 ( https://tools.ietf.org/html/rfc6690#section-2.1). It seems to me that these also introduce constraints that go beyond 5988. I may be mistaken with that regard because I have never fully understood that section of 6690 (i.e. the use of "base URI", "origin", "Context URI"). But, when compared to 5988, the section comes across as imposing constraints that are intended to allow the straightforward use of relative URIs in constrained environments as a means to decrease the payload. If my interpretation is correct, then I would very much favor spec-ing the json link format in terms of 5988 rather than 6690. Cheers Herbert Van de Sompel On Tue, Apr 11, 2017 at 9:33 AM, Carsten Bormann wrote: > Hi Mark, > > thank you a lot for another thoughtful review. > > I don=E2=80=99t have an opinion yet on what we should do here, so I=E2=80= =99ll supply some > more background first. > > The present spec is first and foremost intended to round-trip with RFC > 6690, which is indeed stuck a bit on HTTP Link header field syntax. > However, the way this is used in practice is not meant to inherit the > complexities of HTTP header field coding. E.g., for CoRE Resource > Directory and its DNS-SD compatibility, we want to represent a DNS-SD > instance identifier (which is UTF-8) as a link attribute. This is not a > problem in JSON or CBOR, but also not in the way RFC 6690 is being used, > i.e. as a UTF-8 based format. > > I haven=E2=80=99t checked yet what 5988bis brings to the table and how to= track > this in 6690 or possibly a 6690bis. There is no point in Big Web and Thi= ng > Web diverging here, so we should follow the lead. But maybe that would > touch both 6690 and the present document once 5988bis is done. > > More importantly, we haven=E2=80=99t really put a lot of thinking into IR= I > support. The CoAP data type =E2=80=9Cstring=E2=80=9D which is used for U= RI components such > as Uri-Path is UTF-8, so we could embrace them by extending the rules in > section 6 of RFC 7252 to cover IRIs. I=E2=80=99m sure that, in practice,= CoAP > implementations already do this =E2=80=94 it is not distinguishable in th= e CoAP > packet whether the (decomposed) CoAP Uri components have been derived fro= m > URIs or IRIs. But the metadata formats (6690 and its JSON/CBOR > representations; various other JSON and CBOR based formats, e.g. from OCF= ) > are still based on RFC 3986 URIs, except where they also use the CoAP > decomposed form (e.g., CORAL). > > While this is outside the scope of the CoRE WG, I personally would like t= o > explore how link-format+cbor/+json could be useful for the Big Web. If > embracing IRIs there is all we need to make this happen, maybe that can b= e > added with a warning that IRIs have to be converted back to URIs for 6690 > link-format. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Apr 11, 2017, at 05:49, Mark Nottingham wrote: > > > > Reviewer: Mark Nottingham > > Review result: Ready with Issues > > > > This specification is a relatively straightforward mapping of the > > format described in RFC6690 (itself a serialisation of RFC5988bis > > links) into JSON and CBOR. I don't have deep knowledge of CBOR, but > > given the editorship of the document, I trust it's seen adequate > > review in that regard. > > > > The only potential issue is how this is achieved. Rather than defining > > two new serialisations of RFC5988bis links (into JSON and CBOR), it > > describes how to re-serialise RFC6690 documents into JSON and CBOR. > > This means that any constraints upon RFC6690 documents are also > > mirrored into these formats; e.g., the target IRI is constrained to be > > a URI in 6690, and therefore can also only be a URI in JSON and CBOR, > > despite these formats' ability to easily convey non-ASCII content. > > > > In other words, the specification currently defines these link formats > > in terms of the Link header (as defined in section 5 of RFC5988) -- > > along with all of the foibles of HTTP header syntax -- rather than > > their abstract model (defined in Section 3). > > > > Whether or not this is a problem depends on what's desired; if 6690 is > > seen as effectively a profile of 5988, then it makes sense to express > > it in those terms. If the full range of links capable of being > > expressed in 5988 is desired, creating new serialisations of 5988 > > links (without a hop through 6690) is preferable. > > > > If the current approach is kept, it'd be nice to clarify this > > situation a bit in the Introduction. > > > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --=20 Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126 =3D=3D --001a1140eede73628d054d704f68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hi Mark, Carsten,

Sorry to be a bit lat= e to the game.

Two things:

1. I would be very interested in documents serialized according to applic= ation/link-format+json as described in the I-D, especially in the context o= f an I-D Erik Wilde and I are authoring regarding Link Sets, see https://da= tatracker.ietf.org/doc/draft-wilde-linkset-link-rel/

2. Regarding Mark's comment "This means that any constraints upon RFC6690 documents are alsomirrored into these formats": Mar= k mentions IRIs as a concern. I am also concerned about the rules for inter= pretation of (the Context IRI of) links as described in Section 2.1 of 6690= (https://tools= .ietf.org/html/rfc6690#section-2.1). It seems to me that these also int= roduce constraints that go beyond 5988. I may be mistaken with that regard = because I have never fully understood that section of 6690 (i.e. the use of= "base URI", "origin", "Context URI"). But, w= hen compared to 5988, the section comes across as imposing constraints that= are intended to allow the straightforward use of relative URIs in constrai= ned environments=C2=A0as a means to decrease the payload. If my interpretat= ion is correct, then I would very much favor spec-ing the json link format = in terms of 5988 rather than 6690.

Cheers

Herbert Van de Sompel

=C2= =A0

On Tue, Apr 11, 2017 at 9:33 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:
Hi Mark,

thank you a lot for another thoughtful review.

I don=E2=80=99t have an opinion yet on what we should do here, so I=E2=80= =99ll supply some more background first.

The present spec is first and foremost intended to round-trip with RFC 6690= , which is indeed stuck a bit on HTTP Link header field syntax.=C2=A0 Howev= er, the way this is used in practice is not meant to inherit the complexiti= es of HTTP header field coding.=C2=A0 E.g., for CoRE Resource Directory and= its DNS-SD compatibility, we want to represent a DNS-SD instance identifie= r (which is UTF-8) as a link attribute.=C2=A0 This is not a problem in JSON= or CBOR, but also not in the way RFC 6690 is being used, i.e. as a UTF-8 b= ased format.

I haven=E2=80=99t checked yet what 5988bis brings to the table and how to t= rack this in 6690 or possibly a 6690bis.=C2=A0 There is no point in Big Web= and Thing Web diverging here, so we should follow the lead.=C2=A0 But mayb= e that would touch both 6690 and the present document once 5988bis is done.=

More importantly, we haven=E2=80=99t really put a lot of thinking into IRI = support.=C2=A0 The CoAP data type =E2=80=9Cstring=E2=80=9D which is used fo= r URI components such as Uri-Path is UTF-8, so we could embrace them by ext= ending the rules in section 6 of RFC 7252 to cover IRIs.=C2=A0 I=E2=80=99m = sure that, in practice, CoAP implementations already do this =E2=80=94 it i= s not distinguishable in the CoAP packet whether the (decomposed) CoAP Uri = components have been derived from URIs or IRIs.=C2=A0 But the metadata form= ats (6690 and its JSON/CBOR representations; various other JSON and CBOR ba= sed formats, e.g. from OCF) are still based on RFC 3986 URIs, except where = they also use the CoAP decomposed form (e.g., CORAL).

While this is outside the scope of the CoRE WG, I personally would like to = explore how link-format+cbor/+json could be useful for the Big Web.=C2=A0 I= f embracing IRIs there is all we need to make this happen, maybe that can b= e added with a warning that IRIs have to be converted back to URIs for 6690= link-format.

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


> On Apr 11, 2017, at 05:49, Mark Nottingham <mnot@mnot.net> wrote:
>
> Reviewer: Mark Nottingham
> Review result: Ready with Issues
>
> This specification is a relatively straightforward mapping of the
> format described in RFC6690 (itself a serialisation of RFC5988bis
> links) into JSON and CBOR. I don't have deep knowledge of CBOR, bu= t
> given the editorship of the document, I trust it's seen adequate > review in that regard.
>
> The only potential issue is how this is achieved. Rather than defining=
> two new serialisations of RFC5988bis links (into JSON and CBOR), it > describes how to re-serialise RFC6690 documents into JSON and CBOR. > This means that any constraints upon RFC6690 documents are also
> mirrored into these formats; e.g., the target IRI is constrained to be=
> a URI in 6690, and therefore can also only be a URI in JSON and CBOR,<= br> > despite these formats' ability to easily convey non-ASCII content.=
>
> In other words, the specification currently defines these link formats=
> in terms of the Link header (as defined in section 5 of RFC5988) -- > along with all of the foibles of HTTP header syntax -- rather than
> their abstract model (defined in Section 3).
>
> Whether or not this is a problem depends on what's desired; if 669= 0 is
> seen as effectively a profile of 5988, then it makes sense to express<= br> > it in those terms. If the full range of links capable of being
> expressed in 5988 is desired, creating new serialisations of 5988
> links (without a hop through 6690) is preferable.
>
> If the current approach is kept, it'd be nice to clarify this
> situation a bit in the Introduction.
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>

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



--
=
Herbert V= an de Sompel
Digital Library Research & Prototyping
Los Alamos Na= tional Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.or= g/0000-0002-0715-6126

=3D=3D
--001a1140eede73628d054d704f68-- From nobody Tue Apr 18 17:48:24 2017 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 467AF129416; Tue, 18 Apr 2017 17:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP7w0aeHxg73; Tue, 18 Apr 2017 17:48:20 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E401250B8; Tue, 18 Apr 2017 17:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4B6KXpPBLm61WrTUxH+Ze62Fe+lw3X7Gf/vxddMmao0=; b=aHcF6szGa2jS3Lyzip3UYvE97jcxmmK+5zMScehsSmv0Lmq/SZNQ6YKEdChkc7zQ8D3qUceDwn8dUuQnh1TOcXd5C74xOWlbuiPCP7LYSZic4c6eg8ko593p8dMVeBEc4DcWYhjHxjgzuozctVtl1SilyoeUXcEimwHm6FzsXFM= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0081.namprd21.prod.outlook.com (10.162.78.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Wed, 19 Apr 2017 00:48:18 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Wed, 19 Apr 2017 00:48:18 +0000 From: Brian Raymor To: Carsten Bormann , Mark Nottingham CC: "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsa/ruYJAPgRh/k2Aqaxin65fHKG+W1UAgA2IyeA= Date: Wed, 19 Apr 2017 00:48:17 +0000 Message-ID: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> In-Reply-To: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0081; 7:ET2ae8tLyud9HDCn+EOfPnA7KzUPQB31CkIKKmjVaSda6ksrE39XnDmSmLVaKO3WMBCHz/WvrxmDhClNuAuECYCK78HhfbT3AZMqUzTve0ai0FpsOtyPPnW87iRCoMbwqEFHNv6Ig82cJ7RGvkuwBjxiB9UrKo7Yq/6fINVX/xNn5RtUH2YUKDHJhENoyNFaRCtxrn8ZInMdWrGCoyMqViJc8l34NMSJNkbVJPot0ErHWiAtcAedlF4wze6caOH0gFRLcn/v9jrz3cvPTYSo4yGNpCauTSA7kiqUbi2opaKffIvg0z3Fl8hVwYrxaiH87WSssSEmj1/ULSxMcHGWHgVDkZKNAZYGolXBv/eIQ7I= x-ms-office365-filtering-correlation-id: 38543b9b-667b-4555-10dc-08d486bdc529 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR21MB0081; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406088)(20161123558035)(20161123560025)(6072148); SRVR:BY2PR21MB0081; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0081; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39860400002)(39400400002)(52314003)(24454002)(38730400002)(6506006)(54906002)(55016002)(4326008)(66066001)(99286003)(6436002)(9686003)(77096006)(74316002)(76176999)(3846002)(25786009)(6306002)(53936002)(6246003)(54356999)(8936002)(8676002)(102836003)(50986999)(2900100001)(6116002)(7696004)(81166006)(2950100002)(305945005)(7736002)(5660300001)(10290500002)(10090500001)(3660700001)(33656002)(5005710100001)(86612001)(2906002)(3280700002)(189998001)(86362001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0081; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 00:48:17.8034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0081 Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:48:22 -0000 VGhhbmtzIGZvciB5b3VyIHRob3VnaHRmdWwgZmVlZGJhY2ssIE1hcmsuDQoNCk1hcmsgd3JvdGU6 DQo+PiBTZWN0aW9uIDguMSBtYWtlcyBpdCBNYW5kYXRvcnkgdG8gSW1wbGVtZW50IHRoZSBwcm90 b2NvbCB3aXRob3V0IGFueSANCj4+IHNlY3VyaXR5ICgiTm9TZWMiKS4gVGhpcyBzZWVtcyBjb3Vu dGVyIHRvIGJlc3QgcHJhY3RpY2UgaW4gdGhlIElFVEYsIA0KPj4gYnV0IEknbGwgZGVmZXIgdG8g dGhlIFNlY3VyaXR5IEFyZWEgcmV2aWV3Lg0KDQpDYXJzdGVuIHJlc3BvbmRlZDoNCj4gU2luY2Ug aXQgaXMgdGhlIGltcGxlbWVudGVycyB3aG8gd2lsbCBkZWNpZGUgd2hldGhlciB0aGV5IGltcGxl bWVudCB0aGlzLCB0aGlzIGNvLWF1dGhvciBjb3VsZCBsaXZlIHdpdGggbWFraW5nIGltcGxlbWVu dGluZyBOb1NlYw0KPiBjb21wbGV0ZWx5IG9wdGlvbmFsLiAgKEl0IHdpbGwgYmUgYW55d2F5LCBp biBwcmFjdGljZSwgYXQgdGhlIGxldmVsIG9mIHdoYXQgaXMgYWN0dWFsbHkgY29uZmlndXJlZC4p ICBUaGUgaW1wb3J0YW50IHBvaW50KCopIGZyb20gdGhlIFdHDQo+IHBlcnNwZWN0aXZlIGhlcmUg aXMgdGhhdCBUTFMgaXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwgd2l0aCB0aGUgc3BlY2lmaWNz IGRlcGVuZGluZyBvbiB0aGUgc2VjdXJpdHkgbW9kZSBuZWVkZWQgKGNmLiBSRkMgNzkyNSkuIA0K PiAoTm90ZSBhbHNvIHRoYXQgdGhlcmUgYXJlIG90aGVyIHdheXMgdG8gcHJvdmlkZSBzZWN1cml0 eSB3aXRoIENvQVAuKQ0KDQo+ICgqKSBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRj cC10bHMvY29tbWl0L2ZlMzQ4ZjU0M2ZjNDVlOTgxZTM4ZTkzNTQyNDIwMTJhZmIyOGRjNjANCg0K U29tZSBjb250ZXh0IC0gZHVyaW5nIHRoZSBzZWN1cml0eSBkaXNjdXNzaW9ucyBpbiB0aGUgV0cs IHRoZXJlIHdhcyBhIHJlY29tbWVuZGF0aW9uIHRvICJtaXJyb3IiIHRoZSBzaW1pbGFyIHNlY3Rp b24gaW4gUkZDNzI1Mi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2Vj dGlvbi05IHN0YXRlczoNCg0KICBUaGUgTm9TZWMgYW5kIFJhd1B1YmxpY0tleSBtb2RlcyBhcmUg bWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQp3aGljaCBp cyB3aHkgTm9TZWMgaXMgTVRJLiANCg0KSSBhZ3JlZSB3aXRoIENhcnN0ZW4uIEknZCBiZSBoYXBw eSB0byBtYWtlIHRoaXMgY29tcGxldGVseSBvcHRpb25hbCBpZiBpdCByZXN1bHRzIGluIGxlc3Mg ZGlzc29uYW5jZSBmb3IgcmV2aWV3ZXJzIGFuZCB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyBpbiB0 aGUgV0cuDQoNCg== From nobody Wed Apr 19 06:39:58 2017 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 DF57E129537 for ; Wed, 19 Apr 2017 06:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI9MS-Y7HDKc for ; Wed, 19 Apr 2017 06:39:54 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543E21293F4 for ; Wed, 19 Apr 2017 06:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JDdoDN029655 for ; Wed, 19 Apr 2017 15:39:50 +0200 (CEST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7NQt4FVzzDGwN for ; Wed, 19 Apr 2017 15:39:50 +0200 (CEST) Received: by mail-io0-f181.google.com with SMTP id k87so21786103ioi.0 for ; Wed, 19 Apr 2017 06:39:50 -0700 (PDT) X-Gm-Message-State: AN3rC/76LzlLj6Ug0fJC3M+oXpeCCsEck+BV6JK4pyluogcpLoHV+4WM 9lM1hXHLSv0DCh0GbMHbIlr4MtZH/g== X-Received: by 10.107.141.84 with SMTP id p81mr3046512iod.61.1492609189436; Wed, 19 Apr 2017 06:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.65 with HTTP; Wed, 19 Apr 2017 06:39:08 -0700 (PDT) In-Reply-To: References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> From: Klaus Hartke Date: Wed, 19 Apr 2017 15:39:08 +0200 X-Gmail-Original-Message-ID: Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:39:57 -0000 So something like this? +-- | +-- A. content coding 'identity' | | | +-- A.0. text/plain; charset=utf-8 | | | +-- A.40. application/link-format | | | +-- A.41. application/xml | | | | | +-- A.41.65001. application/senml+xml | | +-- A.41.65002. application/sensml+xml | | | +-- A.42. application/octet-stream | | | +-- A.47. application/exi | | | | | +-- A.47.65003. application/senml+exi | | +-- A.47.65004. application/sensml+exi | | | +-- A.50. application/json | | | | | +-- A.50.51. application/json-patch+json | | +-- A.50.52. application/merge-patch+json | | +-- A.50.256. application/coap-group+json | | +-- A.50.11543. application/vnd.oma.lwm2m+json | | +-- A.50.65005. application/senml+json | | +-- A.50.65006. application/sensml+json | | | +-- A.60. application/cbor | | | | | +-- A.60.16. application/cose; cose-type="cose-encrypt0" | | +-- A.60.17. application/cose; cose-type="cose-mac0" | | +-- A.60.18. application/cose; cose-type="cose-sign1" | | +-- A.60.96. application/cose; cose-type="cose-encrypt" | | +-- A.60.97. application/cose; cose-type="cose-mac" | | +-- A.60.98. application/cose; cose-type="cose-sign" | | +-- A.60.101. application/cose-key | | +-- A.60.102. application/cose-key-set | | +-- A.60.10000. application/vnd.ocf+cbor | | +-- A.60.65007. application/senml+cbor | | +-- A.60.65008. application/sensml+cbor | | | +-- A.11542. application/vnd.oma.lwm2m+tlv | +-- B. content coding 'deflate' | | | (same structure as 'identity') | +-- C. content coding 'gzip' | | | (same structure as 'identity') | +-- D. content coding 'aes128gcm' | | | (same structure as 'identity') | +-- E. content coding 'exi' | +-- E.65003. application/senml+exi +-- E.65004. application/sensml+exi Michael: Does your use case fit in there? Klaus From nobody Wed Apr 19 07:25:45 2017 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 028A9129AAC for ; Wed, 19 Apr 2017 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKWxg4QfAZgD for ; Wed, 19 Apr 2017 07:25:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08851293E0 for ; Wed, 19 Apr 2017 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JEPeK1008733 for ; Wed, 19 Apr 2017 16:25:40 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7PRm15r8zDGxQ; Wed, 19 Apr 2017 16:25:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Apr 2017 16:25:39 +0200 Cc: core X-Mao-Original-Outgoing-Id: 514304739.516499-9cb9ef5719c9cf4b2f936b3157efe5d4 Content-Transfer-Encoding: quoted-printable Message-Id: <15D8CAC1-537A-44F4-8F73-E28FE439C1B5@tzi.org> References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:25:44 -0000 Now, is this a hierarchy? > | | +-- A.41.65001. application/senml+xml > | | +-- A.47.65003. application/senml+exi > | | +-- A.50.65005. application/senml+json > | | +-- A.60.65007. application/senml+cbor > +-- E.65003. application/senml+exi The =E2=80=9Csenml=E2=80=9D-ness could be another node in the tree, with = leaves for the cases listed here. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 07:51:17 2017 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 1B22A129AAD for ; Wed, 19 Apr 2017 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY4aZn8d81_f for ; Wed, 19 Apr 2017 07:51:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6E6129513 for ; Wed, 19 Apr 2017 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JEpAS7001276 for ; Wed, 19 Apr 2017 16:51:10 +0200 (CEST) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7Q1B391MzDGy9 for ; Wed, 19 Apr 2017 16:51:10 +0200 (CEST) Received: by mail-it0-f48.google.com with SMTP id 193so6146832itm.1 for ; Wed, 19 Apr 2017 07:51:10 -0700 (PDT) X-Gm-Message-State: AN3rC/5U2yEUsOOkyie32CyGiDQhTVkaSMaUBWH+C3DuNH8n9frcGq2B MALHmuSRhacdxGdUqfF4qCTbhEPNvQ== X-Received: by 10.36.124.139 with SMTP id a133mr3768874itd.84.1492613469255; Wed, 19 Apr 2017 07:51:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.65 with HTTP; Wed, 19 Apr 2017 07:50:28 -0700 (PDT) In-Reply-To: <15D8CAC1-537A-44F4-8F73-E28FE439C1B5@tzi.org> References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> <15D8CAC1-537A-44F4-8F73-E28FE439C1B5@tzi.org> From: Klaus Hartke Date: Wed, 19 Apr 2017 16:50:28 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:51:16 -0000 > Now, is this a hierarchy? If you want it to be a hierarchy, then there are two options: +-- | +-- data model X | | | +-- cbor | +-- exi | +-- json | +-- xml | +-- data model Y | +-- cbor +-- exi +-- json +-- xml +-- | +-- cbor | | | +-- data model X | +-- data model Y | +-- exi | | | +-- data model X | +-- data model Y | +-- json | | | +-- data model X | +-- data model Y | +-- xml | +-- data model X +-- data model Y The second allows a processor to fall back to generic cbor/exi/json/xml if it does not understand data model X/Y. Does the first have a similar property? Klaus From nobody Wed Apr 19 07:54:37 2017 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 C3ED1129ADE for ; Wed, 19 Apr 2017 07:54:24 -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 fUa8HFUWC8DO for ; Wed, 19 Apr 2017 07:54:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C954129ADC for ; Wed, 19 Apr 2017 07:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JEsH26003185 for ; Wed, 19 Apr 2017 16:54:17 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7Q4n3LvTzDGyJ; Wed, 19 Apr 2017 16:54:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Apr 2017 16:54:17 +0200 Cc: core X-Mao-Original-Outgoing-Id: 514306456.926201-995ca3087f8175ce0f7f201b2b18d3ab Content-Transfer-Encoding: quoted-printable Message-Id: References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> <15D8CAC1-537A-44F4-8F73-E28FE439C1B5@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:54:25 -0000 On Apr 19, 2017, at 16:50, Klaus Hartke wrote: >=20 > The second allows a processor to fall back to generic > cbor/exi/json/xml if it does not understand data model X/Y. Does the > first have a similar property? If you are about senml, but don=E2=80=99t care about a specific = serialization, the other hierarchy would make more sense. (I=E2=80=99m not sure that this is usefully a hierarchy =E2=80=94 I just = saw the depictions as a tree and the question was my knee jerk reaction = to seeing a tree.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 08:06:21 2017 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 DFDB9129AD7 for ; Wed, 19 Apr 2017 08:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 MFXErUXhJUkV for ; Wed, 19 Apr 2017 08:06:18 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C33129AD8 for ; Wed, 19 Apr 2017 08:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JF6FMG012855 for ; Wed, 19 Apr 2017 17:06:15 +0200 (CEST) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7QLZ6RK5zDGyf for ; Wed, 19 Apr 2017 17:06:14 +0200 (CEST) Received: by mail-io0-f182.google.com with SMTP id a103so24789778ioj.1 for ; Wed, 19 Apr 2017 08:06:14 -0700 (PDT) X-Gm-Message-State: AN3rC/7beT4qBcWHC7cnh7txkvUZqaHAUqdHcVCthN5wVCvJ1u3yZPge QfCZNohgqrhRoi5RiugWAwyCdhCk4g== X-Received: by 10.107.20.199 with SMTP id 190mr3682307iou.81.1492614373143; Wed, 19 Apr 2017 08:06:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.136.65 with HTTP; Wed, 19 Apr 2017 08:05:32 -0700 (PDT) In-Reply-To: References: <70BD1F42-5B10-473A-B199-2D3142FDFFB4@gmail.com> <472BC7AE-8708-410C-B42B-F73A8BB62B74@tzi.org> <15D8CAC1-537A-44F4-8F73-E28FE439C1B5@tzi.org> From: Klaus Hartke Date: Wed, 19 Apr 2017 17:05:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: core Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] New CoAP Options on the horizon - Accept-Content-Format-Version and Content-Format-Version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:06:20 -0000 +---------------+---------------+---------------+ /| /| /| /| / | / | / | / | data / | / | / | / | model Y +---------------+---------------+---------------+ | | | | | | | | | | | | | | | | | | +-----------|---+-----------|---+-----------|---+ deflate | / | / | / | / | / | / | / | / data |/ |/ |/ |/ model X +---------------+---------------+---------------+ identity cbor exi json xml Better? Klaus On 19 April 2017 at 16:54, Carsten Bormann wrote: > On Apr 19, 2017, at 16:50, Klaus Hartke wrote: >> >> The second allows a processor to fall back to generic >> cbor/exi/json/xml if it does not understand data model X/Y. Does the >> first have a similar property? > > If you are about senml, but don=E2=80=99t care about a specific serializa= tion, the other hierarchy would make more sense. > > (I=E2=80=99m not sure that this is usefully a hierarchy =E2=80=94 I just = saw the depictions as a tree and the question was my knee jerk reaction to = seeing a tree.) > > Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 10:59:09 2017 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 1BD70129BA3; Wed, 19 Apr 2017 10:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmiREgHErwgw; Wed, 19 Apr 2017 10:58:59 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23AF129B9E; Wed, 19 Apr 2017 10:58:58 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v3JHwtgX008143 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Apr 2017 19:58:56 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id v3JHwtvD001745 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Apr 2017 19:58:55 +0200 Received: from DENBGAT9ER2MSX.ww902.siemens.net (139.22.70.79) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 19 Apr 2017 19:58:55 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.107]) by DENBGAT9ER2MSX.ww902.siemens.net ([139.22.70.79]) with mapi id 14.03.0352.000; Wed, 19 Apr 2017 19:58:54 +0200 From: "Kovatsch, Matthias" To: Mark Nottingham , "cabo@tzi.org" CC: "art@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsbAJgy90j5EPhU2Dw058Pbi54KG+Oc0AgAD5ZgCAAiynAIAABAsAgAAA6ICACvX8kA== Date: Wed, 19 Apr 2017 17:58:53 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:59:00 -0000 Hi there I am picking up this discussion again, as I was made aware of another use c= ase for CoAP-over-WebSockets related to firewalls or shielded networks: wit= hout having looked into the details, HTTP CONNECT apparently does not allow= for OAuth, while upgrading to WebSockets can make use of OAuth to establis= h a secure channel between two edge CoAP proxies that, for instance, forwar= d requests from devices behind one firewall to devices behind another firew= all. Best wishes Matthias From nobody Wed Apr 19 12:10:40 2017 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 B6AAB129BC4; Wed, 19 Apr 2017 12:10:38 -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 1AmXuEFl5DLF; Wed, 19 Apr 2017 12:10:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BCF12952E; Wed, 19 Apr 2017 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJAVM0007708; Wed, 19 Apr 2017 21:10:31 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7WmR5NVwzDH3K; Wed, 19 Apr 2017 21:10:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net> Date: Wed, 19 Apr 2017 21:10:31 +0200 Cc: Mark Nottingham , "art@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 514321831.09875-3422f4d2a22ee59edda267964266b43e Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net> To: "Kovatsch, Matthias" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:10:39 -0000 Hi Matthias, while I can imagine uses cases like that, I don=E2=80=99t believe that a = specification has to be exhaustive in listing its use cases. The CoAP = over WebSockets work was motivated by getting full CoAP functionality = into a browser by providing a way for JavaScript code to use a proxy, = and maybe it is enough to point this out in the specification. I = don=E2=80=99t think it is expedient to add use cases that tend to press = unrelated buttons in people =E2=80=94 even if they are made possible by = the generality of the specification. Implementers will find out = anyway... Gr=C3=BC=C3=9Fe, Carsten > On Apr 19, 2017, at 19:58, Kovatsch, Matthias = wrote: >=20 > Hi there >=20 > I am picking up this discussion again, as I was made aware of another = use case for CoAP-over-WebSockets related to firewalls or shielded = networks: without having looked into the details, HTTP CONNECT = apparently does not allow for OAuth, while upgrading to WebSockets can = make use of OAuth to establish a secure channel between two edge CoAP = proxies that, for instance, forward requests from devices behind one = firewall to devices behind another firewall. >=20 > Best wishes > Matthias >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art >=20 From nobody Wed Apr 19 12:22:12 2017 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 591A4129C1A; Wed, 19 Apr 2017 12:22:11 -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 IFzqeXD2KAZL; Wed, 19 Apr 2017 12:22:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB24D129557; Wed, 19 Apr 2017 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJM6VE017168; Wed, 19 Apr 2017 21:22:06 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7X1p4yfgzDH3W; Wed, 19 Apr 2017 21:22:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Wed, 19 Apr 2017 21:22:05 +0200 X-Mao-Original-Outgoing-Id: 514322525.709632-e6c608bc5c2ecfb6a3a2b1b6084beadb Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, IETF , core , hybi@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:22:11 -0000 On Apr 10, 2017, at 06:07, Mark Nottingham wrote: >=20 > Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" > URI, using a well-known URI in the "wss" scheme. However, "wss" is not > defined to use well-known URIs, so this is an invalid use. Clearly, this is a bug in draft-ietf-core-coap-tcp-tls-07. I have argued that underlying this is an omission in RFC 6455: ws:/wss: URIs are translated into http:/https: URIs, and the well-known = space is already reserved in the latter, so it would be nonsensical to = try to use RFC 5785 /.well-known for something else in the ws:/wss: URI = schemes. Maybe there wasn=E2=80=99t a use case for well-known URIs in WebSockets = before, but there is one now, and we would like to remedy this omission = in the procedurally simplest possibly way. So I am proposing to add RFC 5785=E2=80=99s well-known URI mechanism to = these URI schemes in the document that needs it, = draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455. Are there any objections to this procedure? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 12:32:58 2017 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 D9170129B0D; Wed, 19 Apr 2017 12:32:43 -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 L2t_a9dboMM0; Wed, 19 Apr 2017 12:32:42 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DCE128C83; Wed, 19 Apr 2017 12:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJWb0V025914; Wed, 19 Apr 2017 21:32:38 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7XFx5FkyzDH3d; Wed, 19 Apr 2017 21:32:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Apr 2017 21:32:37 +0200 X-Mao-Original-Outgoing-Id: 514323157.104291-7d2be15871210d08ee22cfcf0d7a07e1 Content-Transfer-Encoding: quoted-printable Message-Id: <289231B4-3335-4CC1-A285-68E1F301360C@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, IETF , core , hybi@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:32:44 -0000 On Apr 19, 2017, at 21:22, Carsten Bormann wrote: >=20 > So I am proposing to add RFC 5785=E2=80=99s well-known URI mechanism = to these URI schemes in the document that needs it, = draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455. Forgot to add the pointer to the simple fix text: https://github.com/core-wg/coap-tcp-tls/pull/128/files Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 20 01:46:13 2017 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 3D99012EB8C for ; Thu, 20 Apr 2017 01:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG8GsMreDo10 for ; Thu, 20 Apr 2017 01:46:10 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9269F12EB7B for ; Thu, 20 Apr 2017 01:46:10 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud3.xs4all.net with ESMTP id AYm81v00F5W6tKc01Ym8AM; Thu, 20 Apr 2017 10:46:08 +0200 Received: from 2001:983:a264:1:dc7e:9a28:c63a:a3ad by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Apr 2017 10:46:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Apr 2017 10:46:08 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 08:46:12 -0000 Hi Core, Following the discussion on CoMI content-formats during ietf98, I want to propose the following; Draft-ietf-core-yang-cbor deines the content-format application/yang+cbor which defines CBOR documents which contain the results of the mapping of a YANG document to CBOR as specified in the draft. Draft-ietf-core-comi defines two additional content-formats: 1) application/yang-fetch+cbor that specifies the contents and semantics of a FETCH CoMI request payload 2) application/yang-patch+cbor that specifies the contents and semantics of a PATCH CoMI request payload Looking forward to alternative proposals or noises of approval. Greetings, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Thu Apr 20 01:55:25 2017 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 41A7312EB8C for ; Thu, 20 Apr 2017 01:55:24 -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 yhLGWcR1PXlS for ; Thu, 20 Apr 2017 01:55:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0FA12EB8F for ; Thu, 20 Apr 2017 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3K8tIWt018756; Thu, 20 Apr 2017 10:55:18 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7t465DG5zDHFZ; Thu, 20 Apr 2017 10:55:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Apr 2017 10:55:18 +0200 Cc: Core X-Mao-Original-Outgoing-Id: 514371318.168876-b67ec7622c319d01cc0b59589dc62c8f Content-Transfer-Encoding: quoted-printable Message-Id: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> References: To: peter van der Stok X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 08:55:24 -0000 > On Apr 20, 2017, at 10:46, peter van der Stok = wrote: >=20 > Hi Core, >=20 > Following the discussion on CoMI content-formats during ietf98, I want = to propose the following; >=20 > Draft-ietf-core-yang-cbor deines the content-format = application/yang+cbor which defines CBOR documents which contain the = results of the mapping of a YANG document to CBOR as specified in the = draft. >=20 > Draft-ietf-core-comi defines two additional content-formats: > 1) application/yang-fetch+cbor that specifies the contents and = semantics of a FETCH CoMI request payload > 2) application/yang-patch+cbor that specifies the contents and = semantics of a PATCH CoMI request payload >=20 > Looking forward to alternative proposals or noises of approval. Sounds very good to me. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 20 02:34:21 2017 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 6AD6C12EBDD for ; Thu, 20 Apr 2017 02:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c2HoDTgEtSJ for ; Thu, 20 Apr 2017 02:34:18 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8F212EBCF for ; Thu, 20 Apr 2017 02:34:18 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud3.xs4all.net with ESMTP id AZaG1v00R5W6tKc01ZaGsY; Thu, 20 Apr 2017 11:34:16 +0200 Received: from 2001:983:a264:1:dc7e:9a28:c63a:a3ad by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Apr 2017 11:34:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Apr 2017 11:34:16 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <5ae3648a22ab499f646bfab85b193755@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [core] CoMI error codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:34:20 -0000 Hi Core, Michel makes the remark that the production of comi specific error messages needs a better specification. I thought that this warranted a discussion on the ML. Michel's proposal is: to create a typical CoMI method parsing pseudo code. This pseudo code is useful to identify which CoAP error codes are generated by the underline CoAP library and which are generated by the CoMI specific application logic. For those errors generated by the CoAP library, we should not require any payload since such requirement will force implementers to make changes to the underline CoAP library. In some cases, such changes are not even possible, no access to source code or not allowed by the software license. For CoAP errors generated at the CoMI application logic level, my recommendation is still to avoid the definition of specific error codes. Such error code are really useful only if a client can automatically fix the situation by re-issuing an updated request taking into account the initial error. However, I don't see such use cases for these errors. One example of such approach is error code 4.13 (Request Entity Too Large) which allow a client to switch to block transfer. If the target for this extra information is debugging, a simple text message will do the job. This text message can identify for example the exact leaf and specific error condition (e.g. "ip-address, pattern mismatch"). ______________________________________________ My alternative proposal is: using the RESTCONF approach, where errors are returned within a YANG module instance as specified in section 8 of RFC8040 (RESTCONF). The returned content format would then be /application/yang+cbor as proposed in an earlier message to this list. Looking forward to some discussion, Peter From nobody Thu Apr 20 06:40:57 2017 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 7983613145E for ; Thu, 20 Apr 2017 06:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMNXByEICyL3 for ; Thu, 20 Apr 2017 06:40:42 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952E9129AF7 for ; Thu, 20 Apr 2017 06:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1EZr/k9bwA7kr3cl85PcsT3dW5iusdfvW8ecAM/9xik=; b=tsyQTU4WFcw1Eg723qMyGFojQMHEVXrv1yMjICP3E8GAA+XSiKfK+S8/xS0GL9Hcv2RZEA/soW80BLbRDWgFQXUK64rYDslsqNQVcaaskSoMH/+X8oCqtIeOLhll/UlABJE48UxfY1kbAXbJoYSME81SJWkoJpr8NCT5VhirlKI= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 13:40:40 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1034.018; Thu, 20 Apr 2017 13:40:40 +0000 From: Michel Veillette To: Carsten Bormann , peter van der Stok CC: Core Thread-Topic: [core] content-formats for cbor YANG Thread-Index: AQHSubKXN7UA6+6dAE+n0rfEL3aqF6HN9EUAgABIYfA= Date: Thu, 20 Apr 2017 13:40:40 +0000 Message-ID: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> In-Reply-To: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:jkUKH6/PpP+HMTX5XkQSMsleA1ZqBgGJuElFJoTfw7Jc0NUKeLsrkRBhaW9D5G0Xjo+DU8r2JdK1r948WA8JsuRwui9JSfCqlX1KnyYswfZDx7dcv8GzhHtM9ZPr6hlZhpAbDsLCKRnUFBRFR15EBlZye+hLm4sKra0Wm+GWSD0Y0tPQ0xfk2kyhk8Q4H9lfddiJ8thLyamd4qKBqPpvwr/5jlCJjMw6OhMhCHAzCQ/puzRJx/ypk8s1bYLTA0oo9jQFTccczhJHhDxtq4cDTNYT/nCdt5l/h2QcsJIBW9AcqSDx+yHheVS4vHKxht8WlxTBcRLkwOh8bxCOHHY9Kg== x-ms-office365-filtering-correlation-id: 75bc6695-1295-40a8-52d5-08d487f2d5e9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(24454002)(377454003)(6246003)(3846002)(6116002)(53936002)(102836003)(9686003)(229853002)(50986999)(3660700001)(76176999)(5660300001)(74316002)(33656002)(66066001)(55016002)(86362001)(7696004)(6306002)(2900100001)(3280700002)(99286003)(122556002)(6436002)(8676002)(38730400002)(305945005)(7736002)(81166006)(77096006)(8936002)(189998001)(6506006)(54356999)(2906002)(25786009)(4326008)(53546009)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 13:40:40.4564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:40:45 -0000 SGkgUGV0ZXIsIEhpIENhcnN0ZW4NCg0KVGhlIGZvbGxvd2luZyB0YWJsZSBzdW1tYXJpemVzIHRo ZSBkaWZmZXJlbnQgcGF5bG9hZCB1c2VzIGJ5IENvTUkuDQondmFsdWUnIGlzIGRlZmluZWQgaW4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS15YW5nLWNib3ItMDQj c2VjdGlvbi00DQonaW5zdGFuY2UtaWRlbnRpZmllcicgaXMgZGVmaW5lZCBpbiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci0wNCNzZWN0aW9uLTUu MTMuMQ0KDQpVc2UgQ2FzZQkgICAgICAgICAgICAgICAgICB8IFJlcXVlc3QgcGF5bG9hZCAgICAg ICAgICAgICAgICAgICAgICAgICB8IFJlc3BvbnNlIHBheWxvYWQNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KR0VUIC9jL2luc3Rh bmNlLWlkZW50aWZpZXIgICAgICAgIHwgbmEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgdmFsdWUNClBVVCAvYy9pbnN0YW5jZS1pZGVudGlmaWVyICAgICAgICB8IHZhbHVl ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IG5hDQpQT1NUIC9jL2luc3RhbmNl LWlkZW50aWZpZXIgICAgICAgfCB2YWx1ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCBuYQ0KREVMRVRFIC9jL2luc3RhbmNlLWlkZW50aWZpZXIgICAgIHwgbmEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgbmENCkdFVCAvYyAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IG5hICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENC T1IgYXJyYXkgKGluc3RhbmNlLWlkZW50aWZpZXIsIHZhbHVlKQ0KUFVUIC9jCSAgICAgICAgICAg ICAgICAgICAgICAgICAgfCBDQk9SIGFycmF5IChpbnN0YW5jZS1pZGVudGlmaWVyLCB2YWx1ZSkg fCBuYQ0KUE9TVCAvYwkgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ0JPUiBhcnJheSAoaW5z dGFuY2UtaWRlbnRpZmllciwgdmFsdWUpIHwgbmENCkZFVENIIC9jICAgICAgICAgICAgICAgICAg ICAgICAgICB8IENCT1IgYXJyYXkgKGluc3RhbmNlLWlkZW50aWZpZXIpICAgICAgICB8IENCT1Ig YXJyYXkgKHZhbHVlKQ0KaVBBVENIL2MgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ0JPUiBh cnJheSAoaW5zdGFuY2UtaWRlbnRpZmllciwgdmFsdWUpIHwgbmENClBPU1QgL2MvaW5zdGFuY2Ut aWRlbnRpZmllciAoUlBDKSB8IHZhbHVlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IHZhbHVlDQpHRVQgL3MgKE5vdGlmaWNhdGlvbikgICAgICAgICAgICAgfCB2YWx1ZSBvciBD Qk9SIGFycmF5ICh2YWx1ZSkgICAgICAgICAgICAgfCBuYQ0KDQpBcyB5b3UgY2FuIHNlZSwgdGhl IHBheWxvYWQgb2YgYSBpUEFUQ0ggL2MgcmVxdWVzdCBoYXZlIHRoZSBzYW1lIGZvcm1hdCBhIFBV VCAvYyByZXF1ZXN0LCBQT1NUIC9jIHJlcXVlc3QgYW5kIEdFVCAvYyByZXNwb25zZS4NCldoYXQg d2lsbCBiZSB0aGUgcmF0aW9uYWwgdG8gdXNlIGEgZGlmZmVyZW50IENvbnRlbnQtRm9ybWF0IGZv ciB0aGUgaVBBVENIPw0KQ2FuIHdlIHNpbXBseSB1c2UgKENvbnRlbnQtRm9ybWF0OiBhcHBsaWNh dGlvbi9jYm9yKSBpbiBhbGwgY2FzZXM/DQoNClF1aWNrIG5vdGUsIGRyYWZ0LWlldGYtY29yZS15 YW5nLWNib3IgZG9uJ3QgcHJvcG9zZSBhbnkgQ29udGVudC1Gb3JtYXQsIHRoaXMgaXMgbGVmdCB0 byAgZHJhZnQtaWV0Zi1jb3JlLWNvbWkuDQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAy MCwgMjAxNyA0OjU1IEFNDQpUbzogcGV0ZXIgdmFuIGRlciBTdG9rIDxjb25zdWx0YW5jeUB2YW5k ZXJzdG9rLm9yZz4NCkNjOiBDb3JlIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3Jl XSBjb250ZW50LWZvcm1hdHMgZm9yIGNib3IgWUFORw0KDQoNCj4gT24gQXByIDIwLCAyMDE3LCBh dCAxMDo0NiwgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw+IHdyb3RlOg0K PiANCj4gSGkgQ29yZSwNCj4gDQo+IEZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBvbiBDb01JIGNv bnRlbnQtZm9ybWF0cyBkdXJpbmcgaWV0Zjk4LCBJIHdhbnQgdG8gcHJvcG9zZSB0aGUgZm9sbG93 aW5nOw0KPiANCj4gRHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvciBkZWluZXMgdGhlIGNvbnRlbnQt Zm9ybWF0IGFwcGxpY2F0aW9uL3lhbmcrY2JvciB3aGljaCBkZWZpbmVzIENCT1IgZG9jdW1lbnRz IHdoaWNoIGNvbnRhaW4gdGhlIHJlc3VsdHMgb2YgdGhlIG1hcHBpbmcgb2YgYSBZQU5HIGRvY3Vt ZW50IHRvIENCT1IgYXMgc3BlY2lmaWVkIGluIHRoZSBkcmFmdC4NCj4gDQo+IERyYWZ0LWlldGYt Y29yZS1jb21pIGRlZmluZXMgdHdvIGFkZGl0aW9uYWwgY29udGVudC1mb3JtYXRzOg0KPiAxKSBh cHBsaWNhdGlvbi95YW5nLWZldGNoK2Nib3IgdGhhdCBzcGVjaWZpZXMgdGhlIGNvbnRlbnRzIGFu ZCBzZW1hbnRpY3Mgb2YgYSBGRVRDSCBDb01JIHJlcXVlc3QgcGF5bG9hZA0KPiAyKSBhcHBsaWNh dGlvbi95YW5nLXBhdGNoK2Nib3IgdGhhdCBzcGVjaWZpZXMgdGhlIGNvbnRlbnRzIGFuZCBzZW1h bnRpY3Mgb2YgYSBQQVRDSCBDb01JIHJlcXVlc3QgcGF5bG9hZA0KPiANCj4gTG9va2luZyBmb3J3 YXJkIHRvIGFsdGVybmF0aXZlIHByb3Bvc2FscyBvciBub2lzZXMgb2YgYXBwcm92YWwuDQoNClNv dW5kcyB2ZXJ5IGdvb2QgdG8gbWUuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cg== From nobody Thu Apr 20 07:36:55 2017 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 85A9F131486 for ; Thu, 20 Apr 2017 07:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFSjFswZ0Cmh for ; Thu, 20 Apr 2017 07:36:52 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B086B13147F for ; Thu, 20 Apr 2017 07:36:51 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud2.xs4all.net with ESMTP id Aeco1v00Q4CWAV301ecoUH; Thu, 20 Apr 2017 16:36:49 +0200 Received: from 2001:983:a264:1:2149:777c:6426:3c87 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Apr 2017 16:36:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Apr 2017 16:36:48 +0200 From: peter van der Stok To: Michel Veillette Cc: Carsten Bormann , peter van der Stok , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> Message-ID: <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:36:55 -0000 Hi Michel, The semantics of the PUT and GET specify that the payload replaces (represents) the whole payload. Applying PUT semantics to a PATCH payload has as consequence that you loose unintentionally large parts of the resource. A different content-format signals this semantics difference. The FETCH payload may contain only an array of YANG-CBOR identifiers and each identifier represents GET semantics Not all CBOR documents represent YANG to CBOR mappings, that's why the content format application/yang-data+cbor is proposed equivalent to application/yang-data+json. Does that help? Peter Michel Veillette schreef op 2017-04-20 15:40: > Hi Peter, Hi Carsten > > The following table summarizes the different payload uses by CoMI. > 'value' is defined in > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-4 > 'instance-identifier' is defined in > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-5.13.1 > > Use Case | Request payload | > Response payload > ----------------------------------+-----------------------------------------+---------------------------------------- > GET /c/instance-identifier | na > | value > PUT /c/instance-identifier | value > | na > POST /c/instance-identifier | value > | na > DELETE /c/instance-identifier | na > | na > GET /c | na > | CBOR array (instance-identifier, value) > PUT /c | CBOR array (instance-identifier, > value) | na > POST /c | CBOR array (instance-identifier, > value) | na > FETCH /c | CBOR array (instance-identifier) > | CBOR array (value) > iPATCH/c | CBOR array (instance-identifier, > value) | na > POST /c/instance-identifier (RPC) | value > | value > GET /s (Notification) | value or CBOR array (value) > | na > > As you can see, the payload of a iPATCH /c request have the same > format a PUT /c request, POST /c request and GET /c response. > What will be the rational to use a different Content-Format for the > iPATCH? > Can we simply use (Content-Format: application/cbor) in all cases? > > Quick note, draft-ietf-core-yang-cbor don't propose any > Content-Format, this is left to draft-ietf-core-comi. > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Thursday, April 20, 2017 4:55 AM > To: peter van der Stok > Cc: Core > Subject: Re: [core] content-formats for cbor YANG > > >> On Apr 20, 2017, at 10:46, peter van der Stok >> wrote: >> >> Hi Core, >> >> Following the discussion on CoMI content-formats during ietf98, I want >> to propose the following; >> >> Draft-ietf-core-yang-cbor deines the content-format >> application/yang+cbor which defines CBOR documents which contain the >> results of the mapping of a YANG document to CBOR as specified in the >> draft. >> >> Draft-ietf-core-comi defines two additional content-formats: >> 1) application/yang-fetch+cbor that specifies the contents and >> semantics of a FETCH CoMI request payload >> 2) application/yang-patch+cbor that specifies the contents and >> semantics of a PATCH CoMI request payload >> >> Looking forward to alternative proposals or noises of approval. > > Sounds very good to me. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Apr 20 07:39:38 2017 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 990D8127B60 for ; Thu, 20 Apr 2017 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMyWUSZ8p_Rp for ; Thu, 20 Apr 2017 07:39:34 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9A4129543 for ; Thu, 20 Apr 2017 07:39:34 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud2.xs4all.net with ESMTP id AefY1v00M4CWAV301efYuR; Thu, 20 Apr 2017 16:39:32 +0200 Received: from 2001:983:a264:1:2149:777c:6426:3c87 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Apr 2017 16:39:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Apr 2017 16:39:32 +0200 From: peter van der Stok To: Michel Veillette Cc: Carsten Bormann , peter van der Stok , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:39:37 -0000 peter van der Stok schreef op 2017-04-20 16:36: > Hi Michel, > > The semantics of the PUT and GET specify that the payload replaces > (represents) the whole payload. resource (oversight, apologies) > Applying PUT semantics to a PATCH payload has as consequence that you > loose unintentionally large parts of the resource. > A different content-format signals this semantics difference. > The FETCH payload may contain only an array of YANG-CBOR identifiers > and each identifier represents GET semantics > > Not all CBOR documents represent YANG to CBOR mappings, that's why the > content format > application/yang-data+cbor is proposed equivalent to > application/yang-data+json. > > Does that help? > > Peter > > Michel Veillette schreef op 2017-04-20 15:40: >> Hi Peter, Hi Carsten >> >> The following table summarizes the different payload uses by CoMI. >> 'value' is defined in >> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-4 >> 'instance-identifier' is defined in >> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-5.13.1 >> >> Use Case | Request payload | >> Response payload >> ----------------------------------+-----------------------------------------+---------------------------------------- >> GET /c/instance-identifier | na >> | value >> PUT /c/instance-identifier | value >> | na >> POST /c/instance-identifier | value >> | na >> DELETE /c/instance-identifier | na >> | na >> GET /c | na >> | CBOR array (instance-identifier, value) >> PUT /c | CBOR array (instance-identifier, >> value) | na >> POST /c | CBOR array (instance-identifier, >> value) | na >> FETCH /c | CBOR array (instance-identifier) >> | CBOR array (value) >> iPATCH/c | CBOR array (instance-identifier, >> value) | na >> POST /c/instance-identifier (RPC) | value >> | value >> GET /s (Notification) | value or CBOR array (value) >> | na >> >> As you can see, the payload of a iPATCH /c request have the same >> format a PUT /c request, POST /c request and GET /c response. >> What will be the rational to use a different Content-Format for the >> iPATCH? >> Can we simply use (Content-Format: application/cbor) in all cases? >> >> Quick note, draft-ietf-core-yang-cbor don't propose any >> Content-Format, this is left to draft-ietf-core-comi. >> >> Regards, >> Michel >> >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: Thursday, April 20, 2017 4:55 AM >> To: peter van der Stok >> Cc: Core >> Subject: Re: [core] content-formats for cbor YANG >> >> >>> On Apr 20, 2017, at 10:46, peter van der Stok >>> wrote: >>> >>> Hi Core, >>> >>> Following the discussion on CoMI content-formats during ietf98, I >>> want to propose the following; >>> >>> Draft-ietf-core-yang-cbor deines the content-format >>> application/yang+cbor which defines CBOR documents which contain the >>> results of the mapping of a YANG document to CBOR as specified in the >>> draft. >>> >>> Draft-ietf-core-comi defines two additional content-formats: >>> 1) application/yang-fetch+cbor that specifies the contents and >>> semantics of a FETCH CoMI request payload >>> 2) application/yang-patch+cbor that specifies the contents and >>> semantics of a PATCH CoMI request payload >>> >>> Looking forward to alternative proposals or noises of approval. >> >> Sounds very good to me. >> >> Grüße, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Thu Apr 20 09:21:45 2017 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 D1E4A128D3E for ; Thu, 20 Apr 2017 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPM0XVBFx7k5 for ; Thu, 20 Apr 2017 09:21:42 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0133.outbound.protection.outlook.com [104.47.33.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BEF1287A3 for ; Thu, 20 Apr 2017 09:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C2PVnZrmsIo2iBZsuA+6DD8x5md0prcTxt+IGmVeafc=; b=QGcTsUpUc7tOmcCPB5qC6Et4cA5C0KN0u3L+DBW5mwQQTrdYDl7eED1ADFCGWyO5AAQ9mBOh/VtrfMr8u0/ZTkBpqDG2FSQm9kEi5aqVJOCzCmC/dqjW+f3N8xbC4v9UQzZT0jTNgPFRVvdp1cfUEbzILz5ouSOhsCvwinJsXtg= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 16:21:40 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1034.018; Thu, 20 Apr 2017 16:21:40 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" CC: Carsten Bormann , Core Thread-Topic: [core] content-formats for cbor YANG Thread-Index: AQHSubKXN7UA6+6dAE+n0rfEL3aqF6HN9EUAgABIYfCAABcJAIAAGQHg Date: Thu, 20 Apr 2017 16:21:40 +0000 Message-ID: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> In-Reply-To: <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:lz2vvNJoqs6hjauXG++Mhgb9hQVfYRgMVPkZz22e4qCJ031T1/6q/UMeFoO/EbW3KkXaNXSmcJHfQwHPeEDJHdx9L5VYHJ6R5wwJ5pJSrDVbgiJ2l+f6fXJu4aT5Cm0BIR3GrNiuSJdS2sC9NY/21ay2g4R574ap5ZLqzHp2YUVgxBy08aHkIGF7fRvhYN6SamnSC4JQ6kntkxem8ePrLa3oG5RFRcRZlf4P2tAQEP6aFPEPV64aopCA+hKY1HAP8ysTtKHAJ7KsLsfDND6fCbcGmzTAU2JN5H/fWqitPRyunyXkrTrVTfjSJz0spzpIdSkRY2zpmWLMi55tw/iStQ== x-ms-office365-filtering-correlation-id: 3fb08d73-a9fc-46ba-704e-08d488095390 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(377454003)(377424004)(13464003)(24454002)(189998001)(8936002)(77096006)(6506006)(110136004)(81166006)(7736002)(8676002)(305945005)(1730700003)(38730400002)(25786009)(53546009)(6916009)(2950100002)(4326008)(54356999)(2351001)(2906002)(3846002)(102836003)(93886004)(53936002)(6116002)(6246003)(3280700002)(86362001)(6306002)(2900100001)(7696004)(2501003)(122556002)(99286003)(5640700003)(66066001)(3660700001)(50986999)(9686003)(229853002)(74316002)(33656002)(55016002)(54906002)(5660300001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 16:21:40.3239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:21:45 -0000 SGkgUGV0ZXINCg0KSXQgc3RpbGwgdW5jbGVhciB0byBtZSB3aGF0IGlzIHRoZSByb2xlIG9mIHRo ZSBDb0FQIG1ldGhvZCB2cy4gdGhlIHJvbGUgb2YgdGhlIENvbnRlbnQtRm9ybWF0Lg0KVGhlIFBV VCwgUE9TVCBhbmQgaVBBVENIIG1ldGhvZHMgYWxsIHNoYXJlIHRoZSBzYW1lIHBheWxvYWQgKGku ZS4gQ0JPUiBhcnJheSAoaW5zdGFuY2UtaWRlbnRpZmllciwgdmFsdWUpKS4NCg0KLSBJbiB0aGUg Y2FzZSBvZiB0aGUgUFVULCB0aGUgZXhpc3RpbmcgZGF0YXN0b3JlIGlzIGRlbGV0ZWQgYW5kIHJl cGxhY2VkIGJ5IHRoZSBwcm92aWRlZCBwYXlsb2FkLg0KLSBJbiB0aGUgY2FzZSBvZiB0aGUgUE9T VCwgYSBuZXcgZGF0YXN0b3JlIGlzIGNyZWF0ZWQgd2l0aCB0aGUgcHJvdmlkZWQgcGF5bG9hZC4N Ci0gSW4gdGhlIGNhc2Ugb2YgdGhlIGlQQVRDSCwgdGhlIGV4aXN0aW5nIGRhdGFzdG9yZSBpcyB1 cGRhdGVkIGJhc2VkIG9uIHRoZSBwcm92aWRlZCBwYXlsb2FkLg0KDQpGb3IgdGhlc2UgdGhyZWUg dXNlIGNhc2VzLCB0aGUgbWV0aG9kIGRlZmluZXMgd2hhdCB0byBkbyB3aXRoIHRoZSBwYXlsb2Fk LCBub3QgdGhlIENvbnRlbnQtRm9ybWF0Lg0KTXkgcXVlc3Rpb24gaXMgd2h5IGlQQVRDSCByZXF1 aXJlZCBhIGRpZmZlcmVudCBDb250ZW50LUZvcm1hdCB3aGVuIFBVVCBhbmQgUE9TVCB1c2UgdGhl IHNhbWU/DQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0gDQpT ZW50OiBUaHVyc2RheSwgQXByaWwgMjAsIDIwMTcgMTA6MzcgQU0NClRvOiBNaWNoZWwgVmVpbGxl dHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+DQpDYzogQ2Fyc3RlbiBCb3Jt YW5uIDxjYWJvQHR6aS5vcmc+OyBwZXRlciB2YW4gZGVyIFN0b2sgPGNvbnN1bHRhbmN5QHZhbmRl cnN0b2sub3JnPjsgQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gY29u dGVudC1mb3JtYXRzIGZvciBjYm9yIFlBTkcNCg0KSGkgTWljaGVsLA0KDQpUaGUgc2VtYW50aWNz IG9mIHRoZSBQVVQgYW5kIEdFVCBzcGVjaWZ5IHRoYXQgdGhlIHBheWxvYWQgcmVwbGFjZXMNCihy ZXByZXNlbnRzKSB0aGUgd2hvbGUgcGF5bG9hZC4NCkFwcGx5aW5nIFBVVCBzZW1hbnRpY3MgdG8g YSBQQVRDSCBwYXlsb2FkIGhhcyBhcyBjb25zZXF1ZW5jZSB0aGF0IHlvdSBsb29zZSB1bmludGVu dGlvbmFsbHkgbGFyZ2UgcGFydHMgb2YgdGhlIHJlc291cmNlLg0KQSBkaWZmZXJlbnQgY29udGVu dC1mb3JtYXQgc2lnbmFscyB0aGlzIHNlbWFudGljcyBkaWZmZXJlbmNlLg0KVGhlIEZFVENIIHBh eWxvYWQgbWF5IGNvbnRhaW4gb25seSBhbiBhcnJheSBvZiBZQU5HLUNCT1IgaWRlbnRpZmllcnMg YW5kIGVhY2ggaWRlbnRpZmllciByZXByZXNlbnRzIEdFVCBzZW1hbnRpY3MNCg0KTm90IGFsbCBD Qk9SIGRvY3VtZW50cyByZXByZXNlbnQgWUFORyB0byBDQk9SIG1hcHBpbmdzLCB0aGF0J3Mgd2h5 IHRoZSBjb250ZW50IGZvcm1hdCBhcHBsaWNhdGlvbi95YW5nLWRhdGErY2JvciBpcyBwcm9wb3Nl ZCBlcXVpdmFsZW50IHRvIGFwcGxpY2F0aW9uL3lhbmctZGF0YStqc29uLg0KDQpEb2VzIHRoYXQg aGVscD8NCg0KUGV0ZXINCg0KTWljaGVsIFZlaWxsZXR0ZSBzY2hyZWVmIG9wIDIwMTctMDQtMjAg MTU6NDA6DQo+IEhpIFBldGVyLCBIaSBDYXJzdGVuDQo+IA0KPiBUaGUgZm9sbG93aW5nIHRhYmxl IHN1bW1hcml6ZXMgdGhlIGRpZmZlcmVudCBwYXlsb2FkIHVzZXMgYnkgQ29NSS4NCj4gJ3ZhbHVl JyBpcyBkZWZpbmVkIGluDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWNvcmUteWFuZy1jYm9yLTA0I3NlY3Rpb24tNA0KPiAnaW5zdGFuY2UtaWRlbnRpZmllcicgaXMg ZGVmaW5lZCBpbg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LXlhbmctY2Jvci0wNCNzZWN0aW9uLTUuMTMuDQo+IDENCj4gDQo+IFVzZSBDYXNlCSAgICAgICAg ICAgICAgICAgIHwgUmVxdWVzdCBwYXlsb2FkICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g UmVzcG9uc2UgcGF5bG9hZA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gR0VUIC9jL2luc3RhbmNlLWlkZW50aWZpZXIgICAg ICAgIHwgbmENCj4gICAgICB8IHZhbHVlDQo+IFBVVCAvYy9pbnN0YW5jZS1pZGVudGlmaWVyICAg ICAgICB8IHZhbHVlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiAgICAgfCBuYQ0K PiBQT1NUIC9jL2luc3RhbmNlLWlkZW50aWZpZXIgICAgICAgfCB2YWx1ZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCj4gICAgIHwgbmENCj4gREVMRVRFIC9jL2luc3RhbmNlLWlkZW50 aWZpZXIgICAgIHwgbmEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ICAgICB8 IG5hDQo+IEdFVCAvYyAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IG5hDQo+ICAgICAgfCBD Qk9SIGFycmF5IChpbnN0YW5jZS1pZGVudGlmaWVyLCB2YWx1ZSkNCj4gUFVUIC9jCSAgICAgICAg ICAgICAgICAgICAgICAgICAgfCBDQk9SIGFycmF5IChpbnN0YW5jZS1pZGVudGlmaWVyLCANCj4g dmFsdWUpIHwgbmENCj4gUE9TVCAvYwkgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ0JPUiBh cnJheSAoaW5zdGFuY2UtaWRlbnRpZmllciwgDQo+IHZhbHVlKSB8IG5hDQo+IEZFVENIIC9jICAg ICAgICAgICAgICAgICAgICAgICAgICB8IENCT1IgYXJyYXkgKGluc3RhbmNlLWlkZW50aWZpZXIp DQo+ICAgICAgfCBDQk9SIGFycmF5ICh2YWx1ZSkNCj4gaVBBVENIL2MgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgQ0JPUiBhcnJheSAoaW5zdGFuY2UtaWRlbnRpZmllciwgDQo+IHZhbHVlKSB8 IG5hDQo+IFBPU1QgL2MvaW5zdGFuY2UtaWRlbnRpZmllciAoUlBDKSB8IHZhbHVlDQo+ICAgICAg fCB2YWx1ZQ0KPiBHRVQgL3MgKE5vdGlmaWNhdGlvbikgICAgICAgICAgICAgfCB2YWx1ZSBvciBD Qk9SIGFycmF5ICh2YWx1ZSkgICAgICAgICANCj4gICAgIHwgbmENCj4gDQo+IEFzIHlvdSBjYW4g c2VlLCB0aGUgcGF5bG9hZCBvZiBhIGlQQVRDSCAvYyByZXF1ZXN0IGhhdmUgdGhlIHNhbWUgDQo+ IGZvcm1hdCBhIFBVVCAvYyByZXF1ZXN0LCBQT1NUIC9jIHJlcXVlc3QgYW5kIEdFVCAvYyByZXNw b25zZS4NCj4gV2hhdCB3aWxsIGJlIHRoZSByYXRpb25hbCB0byB1c2UgYSBkaWZmZXJlbnQgQ29u dGVudC1Gb3JtYXQgZm9yIHRoZSANCj4gaVBBVENIPw0KPiBDYW4gd2Ugc2ltcGx5IHVzZSAoQ29u dGVudC1Gb3JtYXQ6IGFwcGxpY2F0aW9uL2Nib3IpIGluIGFsbCBjYXNlcz8NCj4gDQo+IFF1aWNr IG5vdGUsIGRyYWZ0LWlldGYtY29yZS15YW5nLWNib3IgZG9uJ3QgcHJvcG9zZSBhbnkgDQo+IENv bnRlbnQtRm9ybWF0LCB0aGlzIGlzIGxlZnQgdG8gIGRyYWZ0LWlldGYtY29yZS1jb21pLg0KPiAN Cj4gUmVnYXJkcywNCj4gTWljaGVsDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg Q2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyMCwgMjAxNyA0OjU1IEFN DQo+IFRvOiBwZXRlciB2YW4gZGVyIFN0b2sgPGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPg0K PiBDYzogQ29yZSA8Y29yZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBjb250ZW50 LWZvcm1hdHMgZm9yIGNib3IgWUFORw0KPiANCj4gDQo+PiBPbiBBcHIgMjAsIDIwMTcsIGF0IDEw OjQ2LCBwZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25zQHhzNGFsbC5ubD4NCj4+IHdyb3RlOg0K Pj4gDQo+PiBIaSBDb3JlLA0KPj4gDQo+PiBGb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gb24gQ29N SSBjb250ZW50LWZvcm1hdHMgZHVyaW5nIGlldGY5OCwgSSANCj4+IHdhbnQgdG8gcHJvcG9zZSB0 aGUgZm9sbG93aW5nOw0KPj4gDQo+PiBEcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yIGRlaW5lcyB0 aGUgY29udGVudC1mb3JtYXQgDQo+PiBhcHBsaWNhdGlvbi95YW5nK2Nib3Igd2hpY2ggZGVmaW5l cyBDQk9SIGRvY3VtZW50cyB3aGljaCBjb250YWluIHRoZSANCj4+IHJlc3VsdHMgb2YgdGhlIG1h cHBpbmcgb2YgYSBZQU5HIGRvY3VtZW50IHRvIENCT1IgYXMgc3BlY2lmaWVkIGluIHRoZSANCj4+ IGRyYWZ0Lg0KPj4gDQo+PiBEcmFmdC1pZXRmLWNvcmUtY29taSBkZWZpbmVzIHR3byBhZGRpdGlv bmFsIGNvbnRlbnQtZm9ybWF0czoNCj4+IDEpIGFwcGxpY2F0aW9uL3lhbmctZmV0Y2grY2JvciB0 aGF0IHNwZWNpZmllcyB0aGUgY29udGVudHMgYW5kIA0KPj4gc2VtYW50aWNzIG9mIGEgRkVUQ0gg Q29NSSByZXF1ZXN0IHBheWxvYWQNCj4+IDIpIGFwcGxpY2F0aW9uL3lhbmctcGF0Y2grY2JvciB0 aGF0IHNwZWNpZmllcyB0aGUgY29udGVudHMgYW5kIA0KPj4gc2VtYW50aWNzIG9mIGEgUEFUQ0gg Q29NSSByZXF1ZXN0IHBheWxvYWQNCj4+IA0KPj4gTG9va2luZyBmb3J3YXJkIHRvIGFsdGVybmF0 aXZlIHByb3Bvc2FscyBvciBub2lzZXMgb2YgYXBwcm92YWwuDQo+IA0KPiBTb3VuZHMgdmVyeSBn b29kIHRvIG1lLg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4g Y29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUNCg== From nobody Thu Apr 20 09:30:52 2017 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 687F6129ADC for ; Thu, 20 Apr 2017 09:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooSHx4YWBSsA for ; Thu, 20 Apr 2017 09:30:48 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF15A129AF4 for ; Thu, 20 Apr 2017 09:30:42 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w64so108411089wma.0 for ; Thu, 20 Apr 2017 09:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=amfh4S92sQvBnqBJDDK6CmMddKHX2Op7Kloj1hoRweQ=; b=oTHcnSv5nExQbuJeFFrAnLST6ykXvn8eNLIvufIFCs45LSyExYrpcYvCQTh62KANir 57PNuJgudkPwtTeUwl2czywx7MHeci29OJKvTiIONj6RqFF+82WnOwmrEK1xlMFOtBNB nvL4Lo+SdBAkqJ29zQPDg61e+BVJHGKwNmKEQEf9S5t0UlkfbWD7d94ouw7A2iw1Ghkh tzuynQD7CDrZVr1syQapcnmpysXYKfi+qiL5q5DSyodeT/x6ROXSSx2gwLNRjFNe1QEV LhD4S+nwqdhOiZ4tWhxg8+5XR14oUDdVNNcEKhw4R5QnKFoNUFj1wyq257vEdWMwL8qK Xs9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=amfh4S92sQvBnqBJDDK6CmMddKHX2Op7Kloj1hoRweQ=; b=W1G21kwMv8lwPJPCsofm2afO27GOdXN79Ci0SYczZQcYBps4EacQYVYzrj/tvRW7Oi WM2q6CA4BjVnPfn2uLRNWE8sO2YZIZqT7UCetYIxaAo13WKJI0oDBOy1LqaJivxHnWAz umu0BDL+fVAFZUIwm9uSVm5grs4U5TiVGG+Wec5fcXGgpqBUB0RrYxOGiNTEOYSpsxye GQ9Nmr0kAEsRBnZ+NaNwF2R/4ZYGuCJ795KrkpYcIQC9DsIDx1PAaIIgNd8ZMCkNsIYC ufh6heFQBb8/ypTFgGl2Zi1ErvVYK7Gi0I3n+CKj7DHYmLeR5yu6hBLYwtdLH/0eKgVK iXSA== X-Gm-Message-State: AN3rC/6DuOpkG8fqo5xqnXo+hpWV54InM9u77VBzbtXZhqCHWfeZ/Pf1 zymo9t+dIvH5iBCJvfg/9sTrWaEHtw== X-Received: by 10.28.143.135 with SMTP id r129mr3888577wmd.54.1492705841352; Thu, 20 Apr 2017 09:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Thu, 20 Apr 2017 09:30:40 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Thu, 20 Apr 2017 09:30:40 -0700 Message-ID: To: "consultancy@vanderstok.org" Cc: Core Content-Type: multipart/alternative; boundary=001a1145b59e6da89f054d9ba9ab Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:30:50 -0000 --001a1145b59e6da89f054d9ba9ab Content-Type: text/plain; charset=UTF-8 Hi, On Thu, Apr 20, 2017 at 1:46 AM, peter van der Stok wrote: > Hi Core, > > Following the discussion on CoMI content-formats during ietf98, I want to > propose the following; > > Draft-ietf-core-yang-cbor deines the content-format application/yang+cbor > which defines CBOR documents which contain the results of the mapping of a > YANG document to CBOR as specified in the draft. > > Draft-ietf-core-comi defines two additional content-formats: > 1) application/yang-fetch+cbor that specifies the contents and semantics > of a FETCH CoMI request payload > 2) application/yang-patch+cbor that specifies the contents and semantics > of a PATCH CoMI request payload > > I think the name application/yang-patch+cbor is very confusing, because application/yang-patch+xml and application/yang-patch+json are already defined in RFC 8072, and they work completely differently than the media types in CoMI. I suggest application/coap-patch+cbor. The reason this media-type is needed in RESTCONF is to distinguish a "plain patch" from a "structured patch". The payload for an RFC 5789 PATCH method is a representation of the target resource. A structured patch cannot use the same media-types because the payload is a predefined data structure. The resource content for the patch is embedded inside. Seems like the new media-types are needed instead of overloading application/cbor. Looking forward to alternative proposals or noises of approval. > > Greetings, > > Peter Andy > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a1145b59e6da89f054d9ba9ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


On Thu, Apr 20, 2017 at 1:46 AM, peter van der Stok <stokco= ns@xs4all.nl> wrote:
Hi Cor= e,

Following the discussion on CoMI content-formats during ietf98, I want to p= ropose the following;

Draft-ietf-core-yang-cbor deines the content-format application/yang+cbor w= hich defines CBOR documents which contain the results of the mapping of a Y= ANG document to CBOR as specified in the draft.

Draft-ietf-core-comi defines two additional content-formats:
1) application/yang-fetch+cbor that specifies the contents and semantics of= a FETCH CoMI request payload
2) application/yang-patch+cbor that specifies the contents and semantics of= a PATCH CoMI request payload


I think the name application/yang-patc= h+cbor is very confusing, because application/yang-patch+xml and
= application/yang-patch+json are already defined in RFC 8072, and they work = completely differently
than the media types in CoMI.
I suggest application/coap-patch+cbor.

The reason this media-type is needed in RESTCONF is to distinguish a &quo= t;plain patch"
from a "structured patch". The payl= oad for an RFC 5789 PATCH method is a representation
of the targe= t resource. A structured patch cannot use the same media-types because the = payload
is a predefined data structure. The resource content for = the patch is embedded inside.

Seems like the new m= edia-types are needed instead of overloading application/cbor.

Looking forward to alternative proposals or noises of approval.

Greetings,

Peter

Andy
=C2=A0


--
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248

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

--001a1145b59e6da89f054d9ba9ab-- From nobody Thu Apr 20 09:39:05 2017 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 C90D7129B1A for ; Thu, 20 Apr 2017 09:39:02 -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 pLai-H4c8uT1 for ; Thu, 20 Apr 2017 09:39:01 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4443D129B00 for ; Thu, 20 Apr 2017 09:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3KGcwps006934; Thu, 20 Apr 2017 18:38:58 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w84M61D1NzDHTw; Thu, 20 Apr 2017 18:38:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Apr 2017 18:38:57 +0200 Cc: peter van der Stok , Core X-Mao-Original-Outgoing-Id: 514399137.549681-721ac9b128c7c734322ce7703627903a Content-Transfer-Encoding: quoted-printable Message-Id: <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> To: Michel Veillette X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:39:03 -0000 > On Apr 20, 2017, at 18:21, Michel Veillette = wrote: >=20 > Hi Peter >=20 > It still unclear to me what is the role of the CoAP method vs. the = role of the Content-Format. > The PUT, POST and iPATCH methods all share the same payload (i.e. CBOR = array (instance-identifier, value)). >=20 > - In the case of the PUT, the existing datastore is deleted and = replaced by the provided payload. > - In the case of the POST, a new datastore is created with the = provided payload. > - In the case of the iPATCH, the existing datastore is updated based = on the provided payload. >=20 > For these three use cases, the method defines what to do with the = payload, not the Content-Format. > My question is why iPATCH required a different Content-Format when PUT = and POST use the same? That is a good question. We definitely need a different format for the FETCH request body, which = is a list of IDs, not a set of ID-value pairs. (We used to have this = argument whether the response should be just a list of values or that = set; I think we are now at the set selected, which is strictly speaking = a bit different from the representation of the whole resource.) The body of an (i)PATCH is different in meaning, not in structure, from = the representation bearing formats. It is a bit of a taste thing = whether we attach media types to semantics or to structural = interoperability. I didn=E2=80=99t have a problem with Peter=E2=80=99s original proposal: > Draft-ietf-core-yang-cbor deines the content-format = application/yang+cbor which defines CBOR documents which contain the = results of the mapping of a YANG document to CBOR as specified in the = draft. >=20 > Draft-ietf-core-comi defines two additional content-formats: > 1) application/yang-fetch+cbor that specifies the contents and = semantics of a FETCH CoMI request payload > 2) application/yang-patch+cbor that specifies the contents and = semantics of a PATCH CoMI request payload Just calling the thing application/cbor just tells us the serialization = format, by the way; this is a bit like sending text/html as text/plain = because any text also is structurally compatible with the latter. Andy=E2=80=99s argument that yang-patch is taken for the different = yang-patch format used with XML/JSON is a good one. Note that there is = no coap in the comi patch format either, so I don=E2=80=99t like = application/coap-patch+cbor. Right now I=E2=80=99m favoring = application/yang-set+cbor. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 20 09:46:26 2017 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 2F75C129B08 for ; Thu, 20 Apr 2017 09:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8bGHctqpKE7 for ; Thu, 20 Apr 2017 09:46:23 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C5E129436 for ; Thu, 20 Apr 2017 09:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YRzwI8EaOIk1qGMky3FAAb4osEycxBkLw4Hx3inL/3k=; b=COqEJEypT31hqXWfq+jrPYwLrkhEn7ixPwHizFugzKsY3rXQc0tS337JT1ob+YELwrJJU1jCIkf+mnXTAS30y461KEWsDDaI0uAdTcKyJXMuOgBX+pYDK0bKVjf5Z3TighPcEovDcyKiHMGL7SzxtxeFdekYvDpJSdEqXtf1Gug= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 16:46:20 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1034.018; Thu, 20 Apr 2017 16:46:20 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] CoMI error codes Thread-Index: AQHSublPEn8rpZLORkeihgQq3Il3U6HOcn4g Date: Thu, 20 Apr 2017 16:46:20 +0000 Message-ID: References: <5ae3648a22ab499f646bfab85b193755@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:3RxmPcvY9pldUkQDmzm6vm3Cr0Fpu3X4tFGI3ZnVjffk6qWr7WzcCo0mf0pRDsIwfonk7q94iqs5zpuIdWO3uTUjau5H47CQuQ2UdvpI1gtwb2kkJhhbEIiDn/TiMG+ihiC8aCAVx0M04t46HOCMjvN50Uo6IwBv4MBO8ze5ajQPNgDALSWLleN4ZsBBFAekvhs340hcdvLz95mPaUFKYDgBMqvl+Jbgo7HkOKN7cliDVnl6mwcZ91AAr95PzTpEn7OQgW8V464xZsNx0Wmqv9gL8pAze9ElrKKPbdq7ZhyZAO7w1Q5bIjTC5IRJvcwWyX5oZjffaNPSoLCW8X4AlA== x-ms-office365-filtering-correlation-id: ac144048-b7a5-4082-8b86-08d4880cc58f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(13464003)(377454003)(6246003)(9686003)(86362001)(77096006)(6506006)(6306002)(55016002)(99286003)(561944003)(53936002)(74316002)(76176999)(38730400002)(305945005)(54356999)(50986999)(53546009)(25786009)(2900100001)(33656002)(189998001)(5660300001)(7736002)(122556002)(7696004)(2950100002)(66066001)(3280700002)(2906002)(81166006)(229853002)(8676002)(8936002)(2501003)(3846002)(3660700001)(102836003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 16:46:20.0815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Subject: Re: [core] CoMI error codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:46:25 -0000 Hi Peter and thanks bringing this subject to the mailing list. To help moving forward with this discussion, I'm proposing the following in= puts: 1) The different validations a YANG server is expected to performe are list= ed in YANG 1.1 section 8. https://tools.ietf.org/html/rfc7950#section-8.3.1 Each validation correspond to a possible error message. 2) The format of a RESTCONF error message is described in RFC8040 section 7= .1. https://tools.ietf.org/html/rfc8040#section-7.1=20 3) The pseudo code mentioned by Peter is provided below. This pseudo code certainly requires improvements, but should be a good star= ting point. CoAP method(){ if CoAP resource don't exist return error 4.04 (Not Found) =20 if not authorized to access this resource return error 4.01 (Unauthorized) if CoAP method code unsupported for the target resource return error 4.05 (Method Not Allowed) =20 if CoAP request payload too large return 4.13 (Request Entity Too Large) if method GET { return resource() =20 if method PUT { YANG schema validation on payload() YANG schema validation on updated datastore() replace resource() } if method POST { if rpc or action resource { YANG schema validation on payload() execute rpc or action() } else { YANG schema validation on payload() YANG schema validation on updated datastore() create resource() } if method DELETE { YANG schema validation on updated datastore() remove resource() } } // YANG schema validation are defined in RFC7950 section 8 YANG schema validation on payload() { if 'Content-Format' is not 'application/cbor' return error 4.15 (Unsupported Content-Format) if CBOR deserialization fail=20 return error 4.00 (Bad Request) with optional error message =20 if a datanode is unknown return error 4.00 (Bad Request) with optional error message if non config leaf return error 4.00 (Bad Request) with optional error message if a leaf with invalid type return error 4.00 (Bad Request) with optional error message =20 if a leaf with invalid 'range' or 'length' or 'pattern' return error 4.00 (Bad Request) with optional error message } } } YANG schema validation on updated datastore() { if a 'mandatory' leaf or choice is absent unless one of its ancestors has= a 'when' condition or 'if-feature' evaluates to false. return error 4.00 (Bad Request) with optional error message =20 if datanodes for more than one 'choice' return error 4.00 (Bad Request) with optional error message if datanodes of a 'if-feature' not implemented return error 4.00 (Bad Request) with optional error message =20 if 'must' contains fail to evaluate return error 4.00 (Bad Request) with optional error message =20 if 'path' referential integrity fail=20 return error 4.00 (Bad Request) with optional error message if 'array' or 'array-list' with invalid 'min-elements' of 'max-elements' return error 4.00 (Bad Request) with optional error message =20 if one of the 'keys' in a YANG 'list' is missing return error 4.00 (Bad Request) with optional error message =20 if the 'unique' constraint of a YANG 'list' fail return error 4.00 (Bad Request) with optional error message } } Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Thursday, April 20, 2017 5:34 AM To: Core Subject: [core] CoMI error codes Hi Core, Michel makes the remark that the production of comi specific error messages= needs a better specification. I thought that this warranted a discussion on the ML. Michel's proposal is: to create a typical CoMI method parsing pseudo code. This pseudo code is us= eful to identify which CoAP error codes are generated by the underline CoAP= library and which are generated by the CoMI specific application logic. For those errors generated by the CoAP library, we should not require any p= ayload since such requirement will force implementers to make changes to th= e underline CoAP library. In some cases, such changes are not even possible= , no access to source code or not allowed by the software license. For CoAP errors generated at the CoMI application logic level, my recommend= ation is still to avoid the definition of specific error codes.=20 Such error code are really useful only if a client can automatically fix th= e situation by re-issuing an updated request taking into account the initia= l error. However, I don't see such use cases for these errors. One example = of such approach is error code 4.13 (Request Entity Too Large) which allow = a client to switch to block transfer. If the target for this extra information is debugging, a simple text messag= e will do the job. This text message can identify for example the exact lea= f and specific error condition (e.g. "ip-address, pattern mismatch"). ______________________________________________ My alternative proposal is: using the RESTCONF approach, where errors are returned within a YANG module= instance as specified in section 8 of RFC8040 (RESTCONF). The returned con= tent format would then be /application/yang+cbor as proposed in an earlier = message to this list. Looking forward to some discussion, Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Apr 20 09:58:29 2017 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 0F696127078 for ; Thu, 20 Apr 2017 09:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oldcvEc0Kqg for ; Thu, 20 Apr 2017 09:58:25 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0133.outbound.protection.outlook.com [104.47.34.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E072128DE5 for ; Thu, 20 Apr 2017 09:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2PtIDX0bWM+WFGtTyd/a6wcoiBPUZUnts6Zwls7zL8I=; b=uY2/DiICXWdgRx55p5/Tqmnqs3dxP8BXDN2cdNzePrvFm1aKQMKO63vX25HB7/ph82FF+mKiUe+zElmMRHIT79BSTaHqGAkk+7DKa9WSCbSinh9SbkPqLBXUfS+6LID92uIIG2qp9TDbtbHAnco5COOzJ/RIUqw06yqEWUFFrJA= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 16:58:24 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1034.018; Thu, 20 Apr 2017 16:58:24 +0000 From: Michel Veillette To: Carsten Bormann CC: peter van der Stok , Core Thread-Topic: [core] content-formats for cbor YANG Thread-Index: AQHSubKXN7UA6+6dAE+n0rfEL3aqF6HN9EUAgABIYfCAABcJAIAAGQHggAAJIICAAAMmQA== Date: Thu, 20 Apr 2017 16:58:24 +0000 Message-ID: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> In-Reply-To: <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:7hqs+dD7DwHn0xtIfBQx4xWvl8OBpAM1K4k1cK8RVMv8Kr59Vxau6aJD1sWYukQfVnYNW3lJTo0tUyH/HjbEs/RRE8N26WaSw+r9F41O0MahS2nuaCeaHF6lKDqKS96qDp1OBgX0sGp+FSknFEYUiWC9PuC32mnEUcNQaAWPraQJj2uc7y0oJ8nS5ASGQF5PRqQuEylCYRjEO3862rDJe0pbWj/FJGp4qQAJOCfRL3xkhK44aJuVM3IWABgZFTsR2HCgG3EebWDcXK5Iew/MmfIoDwAgG8GhMC3yJAbY05q3plLYlgPRDH7TpyUgb6uw45wShQj3zu4AOWqLXv4gMw== x-ms-office365-filtering-correlation-id: b2bbf719-c9ed-498c-1fbd-08d4880e7521 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39410400002)(39400400002)(377454003)(57704003)(13464003)(24454002)(189998001)(8936002)(77096006)(6506006)(110136004)(7736002)(81166006)(8676002)(305945005)(38730400002)(25786009)(53546009)(6916009)(2950100002)(5890100001)(4326008)(54356999)(2906002)(3846002)(102836003)(53936002)(6116002)(93886004)(561944003)(6246003)(3280700002)(86362001)(2900100001)(7696004)(99286003)(122556002)(66066001)(3660700001)(50986999)(9686003)(229853002)(33656002)(74316002)(55016002)(54906002)(5660300001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 16:58:24.0225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:58:27 -0000 SGkgQ2Fyc3RlbiBhbmQgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpBYm91dCAoYXBwbGlj YXRpb24veWFuZy1zZXQrY2JvcikNCkRvIHlvdSBwcm9wb3NlIHRvIHVzZSBpdCBvbmx5IGZvciBp UEFUQ0ggL2MgcmVxdWVzdCA/DQpPciBhbHNvIGZvciBHRVQgL2MgcmVzcG9uc2UsIFBVVCAvYyBy ZXF1ZXN0IGFuZCBQT1NUIC9jIHJlcXVlc3QgPw0KDQpJZiB3ZSBtb3ZlIGluIHRoYXQgZGlyZWN0 aW9uIChzdHJ1Y3R1cmFsIGludGVyb3BlcmFiaWxpdHkpLCBkbyB3ZSBuZWVkIHRvIGRlZmluZSBh IGRpZmZlcmVudCBDb250ZW50LUZvcm1hdCBmb3IgZWFjaCBvbmUgdXNlZCBieSBDb01JPw0KLSB2 YWx1ZQ0KLSBDQk9SIGFycmF5IChpbnN0YW5jZS1pZGVudGlmaWVyKQ0KLSBDQk9SIGFycmF5ICh2 YWx1ZSkNCi0gQ0JPUiBhcnJheSAoaW5zdGFuY2UtaWRlbnRpZmllciwgdmFsdWUpDQoNClJlZ2Fy ZHMsDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4g Qm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjAs IDIwMTcgMTI6MzkgUE0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRy aWxsaWFudGluYy5jb20+DQpDYzogcGV0ZXIgdmFuIGRlciBTdG9rIDxjb25zdWx0YW5jeUB2YW5k ZXJzdG9rLm9yZz47IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIGNv bnRlbnQtZm9ybWF0cyBmb3IgY2JvciBZQU5HDQoNCg0KPiBPbiBBcHIgMjAsIDIwMTcsIGF0IDE4 OjIxLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+ IHdyb3RlOg0KPiANCj4gSGkgUGV0ZXINCj4gDQo+IEl0IHN0aWxsIHVuY2xlYXIgdG8gbWUgd2hh dCBpcyB0aGUgcm9sZSBvZiB0aGUgQ29BUCBtZXRob2QgdnMuIHRoZSByb2xlIG9mIHRoZSBDb250 ZW50LUZvcm1hdC4NCj4gVGhlIFBVVCwgUE9TVCBhbmQgaVBBVENIIG1ldGhvZHMgYWxsIHNoYXJl IHRoZSBzYW1lIHBheWxvYWQgKGkuZS4gQ0JPUiBhcnJheSAoaW5zdGFuY2UtaWRlbnRpZmllciwg dmFsdWUpKS4NCj4gDQo+IC0gSW4gdGhlIGNhc2Ugb2YgdGhlIFBVVCwgdGhlIGV4aXN0aW5nIGRh dGFzdG9yZSBpcyBkZWxldGVkIGFuZCByZXBsYWNlZCBieSB0aGUgcHJvdmlkZWQgcGF5bG9hZC4N Cj4gLSBJbiB0aGUgY2FzZSBvZiB0aGUgUE9TVCwgYSBuZXcgZGF0YXN0b3JlIGlzIGNyZWF0ZWQg d2l0aCB0aGUgcHJvdmlkZWQgcGF5bG9hZC4NCj4gLSBJbiB0aGUgY2FzZSBvZiB0aGUgaVBBVENI LCB0aGUgZXhpc3RpbmcgZGF0YXN0b3JlIGlzIHVwZGF0ZWQgYmFzZWQgb24gdGhlIHByb3ZpZGVk IHBheWxvYWQuDQo+IA0KPiBGb3IgdGhlc2UgdGhyZWUgdXNlIGNhc2VzLCB0aGUgbWV0aG9kIGRl ZmluZXMgd2hhdCB0byBkbyB3aXRoIHRoZSBwYXlsb2FkLCBub3QgdGhlIENvbnRlbnQtRm9ybWF0 Lg0KPiBNeSBxdWVzdGlvbiBpcyB3aHkgaVBBVENIIHJlcXVpcmVkIGEgZGlmZmVyZW50IENvbnRl bnQtRm9ybWF0IHdoZW4gUFVUIGFuZCBQT1NUIHVzZSB0aGUgc2FtZT8NCg0KVGhhdCBpcyBhIGdv b2QgcXVlc3Rpb24uDQoNCldlIGRlZmluaXRlbHkgbmVlZCBhIGRpZmZlcmVudCBmb3JtYXQgZm9y IHRoZSBGRVRDSCByZXF1ZXN0IGJvZHksIHdoaWNoIGlzIGEgbGlzdCBvZiBJRHMsIG5vdCBhIHNl dCBvZiBJRC12YWx1ZSBwYWlycy4gIChXZSB1c2VkIHRvIGhhdmUgdGhpcyBhcmd1bWVudCB3aGV0 aGVyIHRoZSByZXNwb25zZSBzaG91bGQgYmUganVzdCBhIGxpc3Qgb2YgdmFsdWVzIG9yIHRoYXQg c2V0OyBJIHRoaW5rIHdlIGFyZSBub3cgYXQgdGhlIHNldCBzZWxlY3RlZCwgd2hpY2ggaXMgc3Ry aWN0bHkgc3BlYWtpbmcgYSBiaXQgZGlmZmVyZW50IGZyb20gdGhlIHJlcHJlc2VudGF0aW9uIG9m IHRoZSB3aG9sZSByZXNvdXJjZS4pDQoNClRoZSBib2R5IG9mIGFuIChpKVBBVENIIGlzIGRpZmZl cmVudCBpbiBtZWFuaW5nLCBub3QgaW4gc3RydWN0dXJlLCBmcm9tIHRoZSByZXByZXNlbnRhdGlv biBiZWFyaW5nIGZvcm1hdHMuICBJdCBpcyBhIGJpdCBvZiBhIHRhc3RlIHRoaW5nIHdoZXRoZXIg d2UgYXR0YWNoIG1lZGlhIHR5cGVzIHRvIHNlbWFudGljcyBvciB0byBzdHJ1Y3R1cmFsIGludGVy b3BlcmFiaWxpdHkuDQoNCkkgZGlkbuKAmXQgaGF2ZSBhIHByb2JsZW0gd2l0aCBQZXRlcuKAmXMg b3JpZ2luYWwgcHJvcG9zYWw6DQoNCj4gRHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvciBkZWluZXMg dGhlIGNvbnRlbnQtZm9ybWF0IGFwcGxpY2F0aW9uL3lhbmcrY2JvciB3aGljaCBkZWZpbmVzIENC T1IgZG9jdW1lbnRzIHdoaWNoIGNvbnRhaW4gdGhlIHJlc3VsdHMgb2YgdGhlIG1hcHBpbmcgb2Yg YSBZQU5HIGRvY3VtZW50IHRvIENCT1IgYXMgc3BlY2lmaWVkIGluIHRoZSBkcmFmdC4NCj4gDQo+ IERyYWZ0LWlldGYtY29yZS1jb21pIGRlZmluZXMgdHdvIGFkZGl0aW9uYWwgY29udGVudC1mb3Jt YXRzOg0KPiAxKSBhcHBsaWNhdGlvbi95YW5nLWZldGNoK2Nib3IgdGhhdCBzcGVjaWZpZXMgdGhl IGNvbnRlbnRzIGFuZCBzZW1hbnRpY3Mgb2YgYSBGRVRDSCBDb01JIHJlcXVlc3QgcGF5bG9hZA0K PiAyKSBhcHBsaWNhdGlvbi95YW5nLXBhdGNoK2Nib3IgdGhhdCBzcGVjaWZpZXMgdGhlIGNvbnRl bnRzIGFuZCBzZW1hbnRpY3Mgb2YgYSBQQVRDSCBDb01JIHJlcXVlc3QgcGF5bG9hZA0KDQpKdXN0 IGNhbGxpbmcgdGhlIHRoaW5nIGFwcGxpY2F0aW9uL2Nib3IganVzdCB0ZWxscyB1cyB0aGUgc2Vy aWFsaXphdGlvbiBmb3JtYXQsIGJ5IHRoZSB3YXk7IHRoaXMgaXMgYSBiaXQgbGlrZSBzZW5kaW5n IHRleHQvaHRtbCBhcyB0ZXh0L3BsYWluIGJlY2F1c2UgYW55IHRleHQgYWxzbyBpcyBzdHJ1Y3R1 cmFsbHkgY29tcGF0aWJsZSB3aXRoIHRoZSBsYXR0ZXIuDQoNCkFuZHnigJlzIGFyZ3VtZW50IHRo YXQgeWFuZy1wYXRjaCBpcyB0YWtlbiBmb3IgdGhlIGRpZmZlcmVudCB5YW5nLXBhdGNoIGZvcm1h dCB1c2VkIHdpdGggWE1ML0pTT04gaXMgYSBnb29kIG9uZS4gIE5vdGUgdGhhdCB0aGVyZSBpcyBu byBjb2FwIGluIHRoZSBjb21pIHBhdGNoIGZvcm1hdCBlaXRoZXIsIHNvIEkgZG9u4oCZdCBsaWtl IGFwcGxpY2F0aW9uL2NvYXAtcGF0Y2grY2Jvci4gIFJpZ2h0IG5vdyBJ4oCZbSBmYXZvcmluZyBh cHBsaWNhdGlvbi95YW5nLXNldCtjYm9yLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Thu Apr 20 11:08:27 2017 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 A8DFA129B51 for ; Thu, 20 Apr 2017 11:08:25 -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 sq-YjIWeMMhQ for ; Thu, 20 Apr 2017 11:08:24 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C564F12957C for ; Thu, 20 Apr 2017 11:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3KI8Kbs018937; Thu, 20 Apr 2017 20:08:20 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w86LD5bLGzDHW6; Thu, 20 Apr 2017 20:08:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Apr 2017 20:08:18 +0200 Cc: peter van der Stok , Core X-Mao-Original-Outgoing-Id: 514404498.662665-e26cfa3546a2badf5cf7d41100893047 Content-Transfer-Encoding: quoted-printable Message-Id: <091EF847-AD5E-40D8-B04C-CDBDA47023F1@tzi.org> References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> To: Michel Veillette X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 18:08:26 -0000 On Apr 20, 2017, at 18:58, Michel Veillette = wrote: >=20 > Hi Carsten and thanks for your comments. >=20 > About (application/yang-set+cbor) > Do you propose to use it only for iPATCH /c request ? That was my intention. > Or also for GET /c response, PUT /c request and POST /c request ? We could stick with application/yang+cbor for that, but that would meant = that they all use the same structure. I see that your table doesn=E2=80=99= t. (Or we could go for structural interoperability only.) > If we move in that direction (structural interoperability), do we need = to define a different Content-Format for each one used by CoMI? > - value > - CBOR array (instance-identifier) > - CBOR array (value) > - CBOR array (instance-identifier, value) Oh, right, I wasn=E2=80=99t aware that we use all of them. So this would be (all in application/___+cbor): yang-value yang-ids yang-values yang-set (or just yang) This could be four media types, or one media type with four different = values for a parameter. Since, in both cases, we will have four = different content-formats in the end, I=E2=80=99d go with four media = types so we can minimize confusion. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 20 11:15:31 2017 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 8C8B5126C25 for ; Thu, 20 Apr 2017 11:15:28 -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 HoydfgXt9zcZ for ; Thu, 20 Apr 2017 11:15:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E051314BE for ; Thu, 20 Apr 2017 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3KIFMBv025284 for ; Thu, 20 Apr 2017 20:15:22 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w86VK6Z5SzDHWB; Thu, 20 Apr 2017 20:15:21 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 514404919.721039-75d63dafb4a8128b4df4b1a35f24c7ea Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 20:15:19 +0200 Message-Id: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> To: Core X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 18:15:28 -0000 In the current resource directory, multiple domains are pretty much ships in the night to each other; domains "compartmentalize" the RD. After we had a discussion of RD domains between the authors, I'm no longer sure we actually need all this mechanism. Instead, each such compartment/domain could be modeled as a separate resource directory of its own. Multiple domains could be offered as multiple resource directories, e.g. under /rd/{domain} (This does not mean that there need to be multiple copies of RD software running etc., it just means a resource directory implementation could offer multiple of the entry points called "resource directories" under different URIs.) The remaining questions are -- how does a client find the resource directory for the domain it wants to register under. -- how does a client list the resource directories and find the "domain" for each. Listing the resource directories could simply be done by offering a collection interface to them. The domain property could be converted into a URI and listed in the resource directory. Construction of an RD URI could be via a template as shown above. Before we further flesh out this design, I'd like to know who has implemented domains (which are optional in the current RD) and how much they would be impacted by such a simplification. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 20 12:31:45 2017 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 B6D4E1315BF; Thu, 20 Apr 2017 12:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfttccClCqb1; Thu, 20 Apr 2017 12:31:41 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EF21315FD; Thu, 20 Apr 2017 12:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gZQXEn5AMfW0SBRFJEmxpLjuTJxdKqTjytB5LVLRDiE=; b=SD6+8mXBtOaz/KX0yX0mbAUC9HcBxzUb79V7N2m707E74qAOVlsuq7DBrL1jOL8I9REXm2RL6FEOK54Zf8HrooN6eU5JPr5FrcdX8dokihbG9dxGXYBC/YRn9OsGvTTSFCOtmb19HV1a27pZnX+DOXMkzWT5yF1s1uTZR9GojiU= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0083.namprd21.prod.outlook.com (10.162.78.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Thu, 20 Apr 2017 19:31:38 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Thu, 20 Apr 2017 19:31:38 +0000 From: Brian Raymor To: Yoshifumi Nishida , "tsv-art@ietf.org" CC: "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Thread-Topic: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsOTWicthTbHq+0Cl6wEpb6SnVKHOtjQA Date: Thu, 20 Apr 2017 19:31:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sfc.wide.ad.jp; dkim=none (message not signed) header.d=none;sfc.wide.ad.jp; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0083; 7:rWzV/MddUNs53nBT3v6eGgbIIJPr5ZooUjY/MeGMkEDdnhAHkAeKvWBaM3vIv0cezKcqstjTqSUfN0du9Mtvhk3B7rx2cl0LMo3CuYX9Dh8odSWtHv72Ve0ATl7skOsq+VHXhvN+SyASxUOHRTTVizyjjPirFFmU+3K3yItnGeIGYgfy4cJ9KhFxNpHvrwj54fQrUwzGEhwoA98fjMp8DPeMx7lv+9xyr3ORNkWWW40gojujKt4mBaIMMMOVdvcg9S9TA4kbXt3Im1issFqb3scQlYbhcfL9X6LzqMwQsyCzf0qwZ2WmvGeZMNtKCvlqSgmNdJSZhv0ooxyns9/GFn5J4mNizUL6gaS0Zpzy9oo= x-ms-office365-filtering-correlation-id: de05cb43-ed75-4b8d-6352-08d48823dd64 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR21MB0083; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123558043)(201703131423075)(201702281528075)(201703061421075)(201703061406096)(20161123564025)(20161123560025)(6072148); SRVR:BY2PR21MB0083; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0083; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39860400002)(39450400003)(39400400002)(39840400002)(6436002)(6116002)(50986999)(55016002)(54906002)(74316002)(99286003)(38730400002)(6506006)(66066001)(4326008)(6246003)(2900100001)(53936002)(76176999)(9686003)(8676002)(6306002)(8936002)(81166006)(54356999)(3846002)(7736002)(7696004)(5660300001)(305945005)(25786009)(102836003)(2950100002)(77096006)(10090500001)(5005710100001)(33656002)(86362001)(3660700001)(2906002)(3280700002)(2501003)(122556002)(189998001)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0083; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 19:31:38.2636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0083 Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 19:31:44 -0000 DQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suDQoNCj4gMTogSXQgaXMgbm90IGNsZWFyIGhvdyB0 aGUgcHJvdG9jb2wgcmVhY3RzIHRoZSBlcnJvcnMgZnJvbSB0cmFuc3BvcnQgbGF5ZXJzIChlLmcu IGNvbm5lY3Rpb24gZmFpbHVyZSkuDQo+ICAgIFRoZSBwcm90b2NvbCB3aWxsIGp1c3QgaW5mb3Jt IGFwcHMgb2YgdGhlIGV2ZW50cyBhbmQgdGhlIGFwcCB3aWxsIGRlY2lkZSB3aGF0IHRvIGRvIG9y IHRoZSBwcm90b2NvbCBpdHNlbGYgd2lsbCBkbyBzb21ldGhpbmc/DQoNClRoZSBXZWJTb2NrZXRz IGNhc2UgaXMgYWRkcmVzc2VkIGJ5IFJGQzY0NTU6DQoNCiAgIFdoZW4gdGhlIHVuZGVybHlpbmcg VENQIGNvbm5lY3Rpb24gaXMgY2xvc2VkLCBpdCBpcyBzYWlkIHRoYXQgX1RoZQ0KICAgV2ViU29j a2V0IENvbm5lY3Rpb24gaXMgQ2xvc2VkXyBhbmQgdGhhdCB0aGUgV2ViU29ja2V0IGNvbm5lY3Rp b24gaXMNCiAgIGluIHRoZSBDTE9TRUQgc3RhdGUuICBJZiB0aGUgVENQIGNvbm5lY3Rpb24gd2Fz IGNsb3NlZCBhZnRlciB0aGUNCiAgIFdlYlNvY2tldCBjbG9zaW5nIGhhbmRzaGFrZSB3YXMgY29t cGxldGVkLCB0aGUgV2ViU29ja2V0IGNvbm5lY3Rpb24NCiAgIGlzIHNhaWQgdG8gaGF2ZSBiZWVu IGNsb3NlZCBfY2xlYW5seV8uDQoNCi1hbmQtDQoNCiAgIElmIGF0IGFueSBwb2ludCB0aGUgdW5k ZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgY29ubmVjdGlvbiBpcw0KICAgdW5leHBlY3RlZGx5IGxv c3QsIHRoZSBjbGllbnQgTVVTVCBfRmFpbCB0aGUgV2ViU29ja2V0IENvbm5lY3Rpb25fLg0KDQpJ dCdzIHBvc3NpYmxlIHRvIGFkZCBsYW5ndWFnZSBzaW1pbGFyIHRvIHRoZSBhYm9ydCBjYXNlLCBh bG9uZyB0aGUgbGluZXMgb2YgIldoZW4gdGhlIHVuZGVybHlpbmcgVENQIGNvbm5lY3Rpb24gaXMg Y2xvc2VkIG9yIHJlc2V0LCB0aGUgQ29BUCBjb25uZWN0aW9uIGlzIGNsb3NlZCBhbmQgaW4gZmxp Z2h0IG1lc3NhZ2VzIG1heSBiZSBsb3N0Ii4NCg0KPiAyOiBUaGVyZSB3aWxsIGJlIHNpdHVhdGlv bnMgd2hlcmUgdGhlIGFwcCBsYXllciBpcyBmcmVlemluZyB3aGlsZSB0aGUgDQo+IHRyYW5zcG9y dCBsYXllciBpcyBzdGlsbCB3b3JraW5nLiBTaW5jZSB0cmFuc3BvcnQgbGF5ZXJzIGNhbm5vdCBk ZXRlY3QgDQo+IHRoaXMgdHlwZSBvZiBmYWlsdXJlcywgdGhlcmUgc2hvdWxkIGJlIHNvbWUgbWVj aGFuaXNtcyBmb3IgaXQgc29tZXdoZXJlIGluIHRoZSBwcm90b2NvbCBvciBpbiB0aGUgYXBwIGxh eWVyLiAgVGhlIGRvYyBuZWVkcyB0byBhZGRyZXNzDQo+IHRoaXMgcG9pbnQuIEZvciBleGFtcGxl LCB3aGF0IHdpbGwgaGFwcGVuIHdoZW4gYSBQT05HIG1lc3NhZ2UgaXMgbm90IHJldHVybmVkIGZv ciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWU/DQoNClBPTkcgaXMgbW9kZWxlZCBvbiBzaW1pbGFy IG1lY2hhbmlzbXMgaW4gUkZDNjQ1NSBhbmQgUkZDNzU0MC4gTmVpdGhlciBwcm92aWRlcyBhbnkg Z3VpZGFuY2UgZm9yIHRoaXMgY2FzZS4gSXQncyBleHBlY3RlZCB0aGF0IGFuIGFwcGxpY2F0aW9u IGZyYW1ld29yayB3b3VsZCBkZWZpbmUgYW5kIGVuZm9yY2UgdGhlIGFwcHJvcHJpYXRlIHBvbGlj eSBmb3IgdGltZW91dHMgb3IgcmV0cmllcy4NCiANCj4gMzogU2luY2UgdGhpcyBkcmFmdCBkZWZp bmVzIG5ldyBTWlggdmFsdWUsIEkgdGhpbmsgdGhlIGRvYyBuZWVkcyB0byB1cGRhdGUgUkZDNzk1 OS4gVGhpcyBwb2ludCBzaG91bGQgYmUgY2xhcmlmaWVkIG1vcmUgaW4gdGhlIGRvYy4NCg0KQ2Fy c3RlbiByZXNwb25kZWQgdG8gdGhpcyBpc3N1ZSBhbmQgdGhlIGZpbmFsIGV4Y2hhbmdlIGlzIGhl cmUgLSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9t c2cwODU2Mi5odG1sIA0KDQpNeSBzZW5zZSBpcyB0aGF0IHdlIHNob3VsZCB0cmVhdCB0aGlzIGFz IGFuIHVwZGF0ZSB0byBSRkM3OTU5IGJhc2VkIG9uIHRoZSBvcmlnaW5hbCBsYW5ndWFnZToNCg0K ICAgICBUaGUgdmFsdWUgNyBmb3IgU1pYICh3aGljaCB3b3VsZA0KICAgICAgaW5kaWNhdGUgYSBi bG9jayBzaXplIG9mIDIwNDgpIGlzIHJlc2VydmVkLCBpLmUuLCBNVVNUIE5PVCBiZSBzZW50DQog ICAgICBhbmQgTVVTVCBsZWFkIHRvIGEgNC4wMCBCYWQgUmVxdWVzdCByZXNwb25zZSBjb2RlIHVw b24gcmVjZXB0aW9uDQogICAgICBpbiBhIHJlcXVlc3QuDQoNCmFuZCB0aGUgdXNlIG9mICJleHRl bnNpb24iIGluIGNvYXAtdGNwLXRsczoNCg0KICAgIFRoZSDigJlCbG9jay13aXNlIEV4dGVuc2lv biBmb3IgUmVsaWFibGUgVHJhbnNwb3J0IChCRVJUKeKAmSBleHRlbmRzIHRoZSBCbG9jayBwcm90 b2NvbA0KICAgIHRvIGVuYWJsZSB0aGUgdXNlIG9mIGxhcmdlciBtZXNzYWdlcyBvdmVyIGEgcmVs aWFibGUgdHJhbnNwb3J0Lg0KDQpUaGUgZXhpc3RpbmcgSUFOQSBlbnRyaWVzIGZvciBCbG9jazEg YW5kIEJsb2NrMiB3aWxsIGFsc28gbmVlZCB0byByZWZlcmVuY2UgY29hcC10Y3AtdGxzIGluIGFk ZGl0aW9uIHRvIFJGQzc5NTkuDQoNClRyYWNraW5nIGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTI5DQoNCg0K From nobody Thu Apr 20 22:18:33 2017 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 6A4F212940F for ; Thu, 20 Apr 2017 22:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 BBfkDONn5z_Q for ; Thu, 20 Apr 2017 22:18:26 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0085612945C for ; Thu, 20 Apr 2017 22:18:25 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 37D7919F36D; Fri, 21 Apr 2017 13:08:43 +0800 (HKT) Message-ID: From: "weigengyu" To: "Brian Raymor" , "Yoshifumi Nishida" , Cc: , , References: In-Reply-To: Date: Fri, 21 Apr 2017 13:08:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 05:18:27 -0000 Hi， > It's possible to add language similar to the abort case, along the lines > of "When the underlying TCP connection is closed or reset, > the CoAP connection is closed and in flight messages may be lost". It is not necessary when CoAP over WEBSocket is concerned, I think. By the API or the interface, CoAP only interacts with WEB socket, does not need to touch issues of TCP. CoAP would react to the events of WebSokcet. But, issues on TCP should be concerned if it is CoAP over TCP. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Brian Raymor Sent: Friday, April 21, 2017 3:31 AM To: Yoshifumi Nishida ; tsv-art@ietf.org Cc: draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf.org ; ietf@ietf.org Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thanks for your feedback. > 1: It is not clear how the protocol reacts the errors from transport > layers (e.g. connection failure). > The protocol will just inform apps of the events and the app will > decide what to do or the protocol itself will do something? The WebSockets case is addressed by RFC6455: When the underlying TCP connection is closed, it is said that _The WebSocket Connection is Closed_ and that the WebSocket connection is in the CLOSED state. If the TCP connection was closed after the WebSocket closing handshake was completed, the WebSocket connection is said to have been closed _cleanly_. -and- If at any point the underlying transport layer connection is unexpectedly lost, the client MUST _Fail the WebSocket Connection_. It's possible to add language similar to the abort case, along the lines of "When the underlying TCP connection is closed or reset, the CoAP connection is closed and in flight messages may be lost". > 2: There will be situations where the app layer is freezing while the > transport layer is still working. Since transport layers cannot detect > this type of failures, there should be some mechanisms for it somewhere in > the protocol or in the app layer. The doc needs to address > this point. For example, what will happen when a PONG message is not > returned for a certain amount of time? PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither provides any guidance for this case. It's expected that an application framework would define and enforce the appropriate policy for timeouts or retries. > 3: Since this draft defines new SZX value, I think the doc needs to update > RFC7959. This point should be clarified more in the doc. Carsten responded to this issue and the final exchange is here - https://www.ietf.org/mail-archive/web/core/current/msg08562.html My sense is that we should treat this as an update to RFC7959 based on the original language: The value 7 for SZX (which would indicate a block size of 2048) is reserved, i.e., MUST NOT be sent and MUST lead to a 4.00 Bad Request response code upon reception in a request. and the use of "extension" in coap-tcp-tls: The ’Block-wise Extension for Reliable Transport (BERT)’ extends the Block protocol to enable the use of larger messages over a reliable transport. The existing IANA entries for Block1 and Block2 will also need to reference coap-tcp-tls in addition to RFC7959. Tracking in https://github.com/core-wg/coap-tcp-tls/issues/129 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Apr 21 00:04:35 2017 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 79D1212946A for ; Fri, 21 Apr 2017 00:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kgXqYx9M4aNF for ; Fri, 21 Apr 2017 00:04:31 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245EF12946B for ; Fri, 21 Apr 2017 00:04:30 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud6.xs4all.net with ESMTP id Av4U1v00F4R9iYA01v4UZS; Fri, 21 Apr 2017 09:04:29 +0200 Received: from 2001:983:a264:1:207c:e978:69c3:9319 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 21 Apr 2017 09:04:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 21 Apr 2017 09:04:28 +0200 From: peter van der Stok To: Carsten Bormann Cc: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> Message-ID: <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 07:04:33 -0000 Hi Carsten, my hip gun shot reaction. The alternative seems more complex to handle than the original from application point of view. In my opinion, the application ease of use takes precedence here. Peter Carsten Bormann schreef op 2017-04-20 20:15: > In the current resource directory, multiple domains are pretty much > ships in the night to each other; domains "compartmentalize" the RD. > After we had a discussion of RD domains between the authors, I'm no > longer sure we actually need all this mechanism. > Instead, each such compartment/domain could be modeled as a separate > resource directory of its own. > Multiple domains could be offered as multiple resource directories, > e.g. under > > /rd/{domain} > > (This does not mean that there need to be multiple copies of RD > software running etc., it just means a resource directory > implementation could offer multiple of the entry points called > "resource directories" under different URIs.) > > The remaining questions are > > -- how does a client find the resource directory for the domain it > wants to register under. > -- how does a client list the resource directories and find the > "domain" for each. > > Listing the resource directories could simply be done by offering a > collection interface to them. The domain property could be converted > into a URI and listed in the resource directory. Construction of an > RD URI could be via a template as shown above. > > Before we further flesh out this design, I'd like to know who has > implemented domains (which are optional in the current RD) and how > much they would be impacted by such a simplification. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Apr 21 00:18:59 2017 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 BAAEF129482 for ; Fri, 21 Apr 2017 00:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uNxzdDgVCZo for ; Fri, 21 Apr 2017 00:18:56 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1469212946A for ; Fri, 21 Apr 2017 00:18:55 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud6.xs4all.net with ESMTP id AvJt1v00F4R9iYA01vJuGu; Fri, 21 Apr 2017 09:18:54 +0200 Received: from 2001:983:a264:1:207c:e978:69c3:9319 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 21 Apr 2017 09:18:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 21 Apr 2017 09:18:53 +0200 From: peter van der Stok To: Carsten Bormann Cc: Michel Veillette , peter van der Stok , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <091EF847-AD5E-40D8-B04C-CDBDA47023F1@tzi.org> References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> <091EF847-AD5E-40D8-B04C-CDBDA47023F1@tzi.org> Message-ID: <8ff54501447ab9e681ecfbee04652fb3@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 07:18:58 -0000 >> If we move in that direction (structural interoperability), do we need >> to define a different Content-Format for each one used by CoMI? >> - value >> - CBOR array (instance-identifier) >> - CBOR array (value) >> - CBOR array (instance-identifier, value) > > Oh, right, I wasn’t aware that we use all of them. > > So this would be (all in application/___+cbor): > > yang-value > yang-ids > yang-values > yang-set (or just yang) > > This could be four media types, or one media type with four different > values for a parameter. Since, in both cases, we will have four > different content-formats in the end, I’d go with four media types so > we can minimize confusion. Because the CoMI text now says that the payload of an array of one item can be optimized to just one item, I like to suppress the yang-value+cbor and only retain the yang-values+cbor Cheerio, Peter > > Grüße, Carsten From nobody Fri Apr 21 01:25:49 2017 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 1EBB71288B8; Fri, 21 Apr 2017 01:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 8gs9nIIjJ9cq; Fri, 21 Apr 2017 01:25:46 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDF4126CC7; Fri, 21 Apr 2017 01:25:45 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A4B8A279C66; Fri, 21 Apr 2017 17:25:43 +0900 (JST) Received: by mail-oi0-f49.google.com with SMTP id y11so52400910oie.0; Fri, 21 Apr 2017 01:25:43 -0700 (PDT) X-Gm-Message-State: AN3rC/6396mJRhNyNXJaX0mk76s/nsdo1daScsz1xO/XHW7B959kPIE/ 4EtjqIYIFCOwOKqN5eujEl5/h8Txbw== X-Received: by 10.202.97.85 with SMTP id v82mr7096714oib.214.1492763139122; Fri, 21 Apr 2017 01:25:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Fri, 21 Apr 2017 01:25:38 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 21 Apr 2017 01:25:38 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a113d45f4a42cd6054da900d7 Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 08:25:48 -0000 --001a113d45f4a42cd6054da900d7 Content-Type: text/plain; charset=UTF-8 Hi Brian, On Thu, Apr 20, 2017 at 12:31 PM, Brian Raymor wrote: > > Thanks for your feedback. > > > 1: It is not clear how the protocol reacts the errors from transport > layers (e.g. connection failure). > > The protocol will just inform apps of the events and the app will > decide what to do or the protocol itself will do something? > > The WebSockets case is addressed by RFC6455: > > When the underlying TCP connection is closed, it is said that _The > WebSocket Connection is Closed_ and that the WebSocket connection is > in the CLOSED state. If the TCP connection was closed after the > WebSocket closing handshake was completed, the WebSocket connection > is said to have been closed _cleanly_. > > -and- > > If at any point the underlying transport layer connection is > unexpectedly lost, the client MUST _Fail the WebSocket Connection_. > > It's possible to add language similar to the abort case, along the lines > of "When the underlying TCP connection is closed or reset, the CoAP > connection is closed and in flight messages may be lost". > OK. I also think we should state that the protocol should notify the failure events to applications. Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not be enough. > > > 2: There will be situations where the app layer is freezing while the > > transport layer is still working. Since transport layers cannot detect > > this type of failures, there should be some mechanisms for it somewhere > in the protocol or in the app layer. The doc needs to address > > this point. For example, what will happen when a PONG message is not > returned for a certain amount of time? > > PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither > provides any guidance for this case. It's expected that an application > framework would define and enforce the appropriate policy for timeouts or > retries. > The figure 1 in the draft indicates that this draft and RFC7252 are in the same level. So, I am looking at this draft and 7252. When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol provides such things. However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that there need to be some guidance here. BTW, PONG is one example. > > 3: Since this draft defines new SZX value, I think the doc needs to > update RFC7959. This point should be clarified more in the doc. > > Carsten responded to this issue and the final exchange is here - > https://www.ietf.org/mail-archive/web/core/current/msg08562.html > > My sense is that we should treat this as an update to RFC7959 based on the > original language: > > I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people. Thanks, -- Yoshi --001a113d45f4a42cd6054da900d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Thu, Apr 20, 2017 at 12:31 PM, Brian Raymor <Bri= an.Raymor@microsoft.com> wrote:

Thanks for your feedback.

> 1: It is not clear how the protocol reacts the errors from transport l= ayers (e.g. connection failure).
>=C2=A0 =C2=A0 The protocol will just inform apps of the events and the = app will decide what to do or the protocol itself will do something?

The WebSockets case is addressed by RFC6455:

=C2=A0 =C2=A0When the underlying TCP connection is closed, it is said that = _The
=C2=A0 =C2=A0WebSocket Connection is Closed_ and that the WebSocket connect= ion is
=C2=A0 =C2=A0in the CLOSED state.=C2=A0 If the TCP connection was closed af= ter the
=C2=A0 =C2=A0WebSocket closing handshake was completed, the WebSocket conne= ction
=C2=A0 =C2=A0is said to have been closed _cleanly_.

-and-

=C2=A0 =C2=A0If at any point the underlying transport layer connection is =C2=A0 =C2=A0unexpectedly lost, the client MUST _Fail the WebSocket Connect= ion_.

It's possible to add language similar to the abort case, along the line= s of "When the underlying TCP connection is closed or reset, the CoAP = connection is closed and in flight messages may be lost".

OK. I also think we should state that the protocol = should notify the failure events to applications.=C2=A0
Since err= ors can happen not only in TCP, but also TLS and websocket level, mentionin= g only TCP close or reset might not be enough.
=C2=A0

> 2: There will be situations where the app layer is freezing while the<= br> > transport layer is still working. Since transport layers cannot detect=
> this type of failures, there should be some mechanisms for it somewher= e in the protocol or in the app layer.=C2=A0 The doc needs to address
> this point. For example, what will happen when a PONG message is not r= eturned for a certain amount of time?

PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neithe= r provides any guidance for this case. It's expected that an applicatio= n framework would define and enforce the appropriate policy for timeouts or= retries.

The figure 1 in the draft ind= icates that this draft and RFC7252 are in the same level.
So, I a= m looking at this draft and 7252.=C2=A0
When we use 7252, I think= applications basically don't need to implement timeouts or retry mecha= nisms as the protocol provides such things.=C2=A0
However, when w= e use this one, it seems applications will need to have such mechanisms. Is= n't it a bit confusing? I am thinking that there need to be some guidan= ce here.
BTW, PONG is one example.=C2=A0


> 3: Since this draft defines new SZX value, I think the doc needs to up= date RFC7959. This point should be clarified more in the doc.

Carsten responded to this issue and the final exchange is here - https://www.ietf.org/mail-archive/= web/core/current/msg08562.html

My sense is that we should treat this as an update to RFC7959 based on the = original language:

I don't have a strong opini= on here. Updating 7959 is fine for me if it's clearer to CoAP people.

Thanks,
--
Yoshi=C2=A0


--001a113d45f4a42cd6054da900d7-- From nobody Fri Apr 21 02:00:47 2017 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 D1E17129B4C for ; Fri, 21 Apr 2017 02:00:46 -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 glWPzoSMAaF0 for ; Fri, 21 Apr 2017 02:00:45 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB010129B1A for ; Fri, 21 Apr 2017 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3L90fRl024358; Fri, 21 Apr 2017 11:00:41 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w8V7s2BLfzDHmD; Fri, 21 Apr 2017 11:00:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <8ff54501447ab9e681ecfbee04652fb3@xs4all.nl> Date: Fri, 21 Apr 2017 11:00:40 +0200 Cc: Michel Veillette , Core X-Mao-Original-Outgoing-Id: 514458040.705316-795a7d3a54f8339e3c562bd66d924dfa Content-Transfer-Encoding: quoted-printable Message-Id: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> <091EF847-AD5E-40D8-B04C-CDBDA47023F1@tzi.org> <8ff54501447ab9e681ecfbee04652fb3@xs4all.nl> To: peter van der Stok X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 09:00:47 -0000 On Apr 21, 2017, at 09:18, peter van der Stok = wrote: >=20 > Because the CoMI text now says that the payload of an array of one = item can be optimized to just one item, > I like to suppress the yang-value+cbor and only retain the = yang-values+cbor That would create an ambiguity if a value can ever be an array. What is so bad about the media type being very specific about what the = payload is? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 21 07:49:01 2017 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 D278E12951E for ; Fri, 21 Apr 2017 07:48:59 -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 SdIAifrEPpI3 for ; Fri, 21 Apr 2017 07:48:58 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04471294FA for ; Fri, 21 Apr 2017 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3LEms97007930 for ; Fri, 21 Apr 2017 16:48:54 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w8dsd6htvzDHwq; Fri, 21 Apr 2017 16:48:53 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 514478933.221998-6b0506d48c4569839ae039b869a29d72 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 16:48:53 +0200 Message-Id: <7575EA43-5B2E-4949-BC33-2B5F44D8D703@tzi.org> To: Core X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Draft CoRE Minutes for IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 14:49:00 -0000 I have uploaded draft minutes for the two sessions CoRE had at IETF98. As usual, this starts with a summary that is then followed by raw = detailed minutes. https://www.ietf.org/proceedings/98/minutes/minutes-98-core-00.html We have until 2017-05-15 to fix these, but the earlier your fixes come = in, the earlier we can act on those fixes. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 21 08:49:26 2017 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 97826129528 for ; Fri, 21 Apr 2017 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0lhePP9CMlo for ; Fri, 21 Apr 2017 08:49:22 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0125.outbound.protection.outlook.com [104.47.38.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA0C12954D for ; Fri, 21 Apr 2017 08:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8VqL2P8SLGtI0Df+LaAovmr6wb6f1pZmXUuiO0Y30Og=; b=TKzitbppC/UifmJvfUpfyNyq778zWGvXEdUhORg4PW7DswqncTtCDoJxUhqD/TvdwClC845yplAEh/Xd9BOps+GgRmFUzArdTFMOlKK6dCUg8z5+IIthyHXelMEQNnLXL4TKvYE4Vl+i7x3HiQlxqDAy1BVJYtMgXMYq0zGQs8Y= Received: from MWHPR06MB2317.namprd06.prod.outlook.com (10.168.246.147) by MWHPR06MB2317.namprd06.prod.outlook.com (10.168.246.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 21 Apr 2017 15:49:18 +0000 Received: from MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) by MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) with mapi id 15.01.1034.018; Fri, 21 Apr 2017 15:49:18 +0000 From: Michel Veillette To: Carsten Bormann , peter van der Stok CC: Core Thread-Topic: [core] content-formats for cbor YANG Thread-Index: AQHSubKXN7UA6+6dAE+n0rfEL3aqF6HN9EUAgABIYfCAABcJAIAAGQHggAAJIICAAAMmQIAAFdEAgADc44CAABxwAIAAUvHA Date: Fri, 21 Apr 2017 15:49:18 +0000 Message-ID: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> <091EF847-AD5E-40D8-B04C-CDBDA47023F1@tzi.org> <8ff54501447ab9e681ecfbee04652fb3@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB2317; 7:W4gnlKlFS1RVwcdrGy5lKqlw+FJ30+DxwYbNvGK9c+WwmKeofATeBR19BuPT2eusQmh01K3ikpzooOQX7V4hi4V2EBJxKo30aMKmQzO69LG0+NSrHxbUsrtnpS2nwC6foApB3w+KpjhAxWv9uNAPIMhG33RXQKy37TIUpnVi4WRCwKPHk//mp+xZJxD+eulNc+1oPWxR1mOcWaKCOqW6IKV9FmMm2hHls8MQYjJi8/bJNGOYjXB5D+yotykfGbp2cp9V69erghB8R3F60U2XC4mf8IjbkM1lH05xeOATGRwxlcNZLQJV41XeKjwjHpCbx2hYw2SHp88vc8GG49WjvA== x-ms-office365-filtering-correlation-id: 66d77ccf-afaa-4bbf-4dab-08d488cdf89c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR06MB2317; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:MWHPR06MB2317; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB2317; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39400400002)(39840400002)(24454002)(13464003)(377454003)(7696004)(74316002)(7736002)(6506006)(99286003)(305945005)(86362001)(8936002)(6436002)(55016002)(229853002)(77096006)(8676002)(33656002)(5660300001)(122556002)(6246003)(81166006)(2950100002)(53936002)(50986999)(66066001)(2900100001)(54356999)(9686003)(76176999)(38730400002)(4326008)(6116002)(102836003)(3846002)(3280700002)(3660700001)(189998001)(93886004)(25786009)(53546009)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR06MB2317; H:MWHPR06MB2317.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 15:49:18.4536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2317 Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:49:25 -0000 SGkgUGV0ZXINCg0KQWJvdXQgInBheWxvYWQgb2YgYW4gYXJyYXkgb2Ygb25lIGl0ZW0gY2FuIGJl IG9wdGltaXplZCB0byBqdXN0IG9uZSBpdGVtIg0KDQpJIGFncmVlIHdpdGggQ2Fyc3RlbiwgSSBt b3N0IGNhc2VzLCB0aGlzIHJ1bGUgaGF2ZSB0aGUgcG90ZW50aWFsIHRvIGNyZWF0ZSBhbWJpZ3Vp dGllcy4NCkluIHRoZSBzcGVjaWZpYyBjYXNlIG9mIGEgbm90aWZpY2F0aW9uLCB0aGUgcGF5bG9h ZCBjYW4gYmUgZWl0aGVyIGEgQ0JPUiBtYXAgKHNpbmdsZSBub3RpZmljYXRpb24pIG9yIGEgQ0JP UiBhcnJheSAobXVsdGlwbGUgbm90aWZpY2F0aW9ucykuDQpBIHNpbmdsZSBDb250ZW50LUZvcm1h dCAoZS5nLiB5YW5nLXZhbHVlK2Nib3IpIHdpbGwgd29yayBidXQgYSBzb2x1dGlvbiB3aXRoIHR3 byBDb250ZW50LUZvcm1hdCBzZWVtIHRvIGJlIGNsZWFuZXIuDQoNClJlZ2FyZHMsDQpNaWNoZWwN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFp bHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBGcmlkYXksIEFwcmlsIDIxLCAyMDE3IDU6MDEgQU0N ClRvOiBwZXRlciB2YW4gZGVyIFN0b2sgPGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPg0KQ2M6 IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT47IENv cmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIGNvbnRlbnQtZm9ybWF0cyBm b3IgY2JvciBZQU5HDQoNCk9uIEFwciAyMSwgMjAxNywgYXQgMDk6MTgsIHBldGVyIHZhbiBkZXIg U3RvayA8c3Rva2NvbnNAeHM0YWxsLm5sPiB3cm90ZToNCj4gDQo+IEJlY2F1c2UgdGhlIENvTUkg dGV4dCBub3cgc2F5cyB0aGF0IHRoZSBwYXlsb2FkIG9mIGFuIGFycmF5IG9mIG9uZSANCj4gaXRl bSBjYW4gYmUgb3B0aW1pemVkIHRvIGp1c3Qgb25lIGl0ZW0sIEkgbGlrZSB0byBzdXBwcmVzcyB0 aGUgDQo+IHlhbmctdmFsdWUrY2JvciBhbmQgb25seSByZXRhaW4gdGhlIHlhbmctdmFsdWVzK2Ni b3INCg0KVGhhdCB3b3VsZCBjcmVhdGUgYW4gYW1iaWd1aXR5IGlmIGEgdmFsdWUgY2FuIGV2ZXIg YmUgYW4gYXJyYXkuDQoNCldoYXQgaXMgc28gYmFkIGFib3V0IHRoZSBtZWRpYSB0eXBlIGJlaW5n IHZlcnkgc3BlY2lmaWMgYWJvdXQgd2hhdCB0aGUgcGF5bG9hZCBpcz8NCg0KR3LDvMOfZSwgQ2Fy c3Rlbg0KDQo= From nobody Fri Apr 21 11:15:53 2017 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 5FB1512EAAF; Fri, 21 Apr 2017 11:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVp5ZPV_J0TA; Fri, 21 Apr 2017 11:15:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A386B129B31; Fri, 21 Apr 2017 11:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/VZ5UsaK7vLD4NN+KKgNG84lH2X7MR+V4XHDq6pQ1Z8=; b=dqtqqR4Vy/z2qdG9Thi8Dy2l+mCZxv5hnL/it86gAxt74iuS/iMlmAcO3bpPVkzMQY2ivOOtHafnacfeU0q1udO6fSOlA3IM3wjhnYeXL4jLB16WmZ7W6/zFbGa7SJN/axuy+R1S4cphDFcqmLy0SwH+QyKmMCEBUqrJYoj71qo= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0081.namprd21.prod.outlook.com (10.162.78.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Fri, 21 Apr 2017 18:15:41 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Fri, 21 Apr 2017 18:15:41 +0000 From: Brian Raymor To: Yoshifumi Nishida CC: "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Thread-Topic: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsOTWicthTbHq+0Cl6wEpb6SnVKHOtjQAgADZuACAAKJUUA== Date: Fri, 21 Apr 2017 18:15:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sfc.wide.ad.jp; dkim=none (message not signed) header.d=none;sfc.wide.ad.jp; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0081; 7:qfCLDnaB8/U9ttbrq86XBAMJRHA+UXepMmUysJRHVSqaxY9gk7mTbF8siP2YSAMCgyUr8Fba8vb9ATo4JDGeqamPlbQZjBCPGeK0l5bhoBx+gPeW3YzLYVfzwgq6e2oHbNNaJFUiX8csdV4IRo5vvmgoAMzNFSXtoTsw6c/+2xhP1DqfVhHmuQPV3GcUR4LJVNKt/tQZtU7TRgoybyRE2daHmpn4GcnPC/Br857L++1KRFez+7/n5YZfUFuzAbe1FY06W9sacWAGeLze29gcEMMfuQLKs59numfvJTM2NM2h7s0fRqXQNvOwlhBd51cgMLIFKJ78pH4qCZKyvIS2A1BV1l5yilEb3SDVs9SItPI= x-ms-office365-filtering-correlation-id: eaef3a27-4556-4407-68e1-08d488e26bb7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR21MB0081; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558055)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406108)(20161123555025)(20161123560025)(6072148); SRVR:BY2PR21MB0081; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0081; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(39400400002)(43784003)(86362001)(2950100002)(102836003)(6916009)(6246003)(4326008)(7696004)(74316002)(38730400002)(110136004)(7906003)(230783001)(229853002)(33656002)(7736002)(122556002)(54356999)(5660300001)(790700001)(6116002)(76176999)(3846002)(189998001)(50986999)(9686003)(10090500001)(55016002)(66066001)(6306002)(54896002)(99286003)(54906002)(53936002)(2906002)(3280700002)(25786009)(236005)(606005)(8936002)(8676002)(81166006)(9326002)(3660700001)(6506006)(77096006)(6436002)(10290500002)(5005710100001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0081; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 18:15:41.3988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0081 Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 18:15:46 -0000 --_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNCg0KDQo+IE9LLiBJIGFsc28gdGhpbmsgd2Ugc2hvdWxkIHN0YXRlIHRoYXQg dGhlIHByb3RvY29sIHNob3VsZCBub3RpZnkgdGhlIGZhaWx1cmUgZXZlbnRzIHRvIGFwcGxpY2F0 aW9ucy4NCg0KPiBTaW5jZSBlcnJvcnMgY2FuIGhhcHBlbiBub3Qgb25seSBpbiBUQ1AsIGJ1dCBh bHNvIFRMUyBhbmQgd2Vic29ja2V0IGxldmVsLCBtZW50aW9uaW5nIG9ubHkgVENQIGNsb3NlIG9y IHJlc2V0IG1pZ2h0IG5vdA0KDQo+IGJlIGVub3VnaC4NCg0KDQoNCkFmdGVyIHJldmlld2luZyB3 aXRoIHRoZSBhdXRob3JzLCBhbiBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24gd2FzIGFwcGVuZGVk IHRvIDMuNCBDb25uZWN0aW9uIEhlYWx0aCAtIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2Nv YXAtdGNwLXRscy9wdWxsLzE0MC9maWxlcw0KDQoNCg0KVGhlIG9waW5pb24gb2YgdGhlIGF1dGhv cnMgKGFuZCBHZW5neXUgV0VJ4oCZcyByZWNlbnQgcmVzcG9uc2UgLSBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sKSBpcyB0aGF0 IFJGQzY0NTUgY292ZXJzIHRoZSBXZWJTb2NrZXQgY2FzZSBhbmQgZG9lcyBub3QgbmVlZCB0byBi ZSByZXBlYXRlZCBoZXJlLg0KDQoNCg0KPiBXaGVuIHdlIHVzZSA3MjUyLCBJIHRoaW5rIGFwcGxp Y2F0aW9ucyBiYXNpY2FsbHkgZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgdGltZW91dHMgb3IgcmV0 cnkgbWVjaGFuaXNtcyBhcyB0aGUgcHJvdG9jb2wNCg0KPiBwcm92aWRlcyBzdWNoIHRoaW5ncy4N Cg0KDQoNClJGQzcyNTIgcHJvdmlkZXMgdGltZW91dHMgYW5kIHJldHJpZXMgYmVjYXVzZSBpdCdz IGltcGxlbWVudGluZyBhIFRDUC1saWtlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbSBvdmVyIFVEUCAt IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMi4xDQoNCg0KDQo+ IEhvd2V2ZXIsIHdoZW4gd2UgdXNlIHRoaXMgb25lLCBpdCBzZWVtcyBhcHBsaWNhdGlvbnMgd2ls bCBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5pc21zLiBJc24ndCBpdCBhIGJpdCBjb25mdXNpbmc/ IEkgYW0gdGhpbmtpbmcgdGhhdA0KDQo+IHRoZXJlIG5lZWQgdG8gYmUgc29tZSBndWlkYW5jZSBo ZXJlLg0KDQo+IEJUVywgUE9ORyBpcyBvbmUgZXhhbXBsZS4NCg0KDQoNCkZvciBjb2FwLXRjcC10 bHMsIHRoZXJlIGFyZSBtdWx0aXBsZSBlYXJseSBpbXBsZW1lbnRhdGlvbnMuIFRoaXMgaGFzIG5l dmVyIGJlZW4gcmVwb3J0ZWQgYXMgYSBzb3VyY2Ugb2YgY29uZnVzaW9uLg0KDQoNCg0KPj4gTXkg c2Vuc2UgaXMgdGhhdCB3ZSBzaG91bGQgdHJlYXQgdGhpcyBhcyBhbiB1cGRhdGUgdG8gUkZDNzk1 OSBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2U6DQoNCj4gSSBkb24ndCBoYXZlIGEgc3Ry b25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5lIGZvciBtZSBpZiBpdCdzIGNs ZWFyZXIgdG8gQ29BUCBwZW9wbGUuDQoNCg0KDQpJJ3ZlIG1lcmdlZCB0aGUgY2hhbmdlIC0gaHR0 cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTM4L2ZpbGVzDQoNCg0K VGhhbmtzIGFnYWluIGZvciBoZWxwaW5nIHVzIHRvIGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgdGhl IGRyYWZ0LA0KDQrigKZCcmlhbg0K --_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkgWW9zaGksPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT0suIEkgYWxzbyB0aGluayB3ZSBzaG91bGQgc3Rh dGUgdGhhdCB0aGUgcHJvdG9jb2wgc2hvdWxkIG5vdGlmeSB0aGUgZmFpbHVyZSBldmVudHMgdG8g YXBwbGljYXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBTaW5jZSBlcnJvcnMgY2FuIGhhcHBlbiBub3Qgb25seSBpbiBUQ1AsIGJ1dCBhbHNv IFRMUyBhbmQgd2Vic29ja2V0IGxldmVsLCBtZW50aW9uaW5nIG9ubHkgVENQIGNsb3NlIG9yIHJl c2V0IG1pZ2h0IG5vdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGJlIGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWZ0ZXIgcmV2aWV3 aW5nIHdpdGggdGhlIGF1dGhvcnMsIGFuIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbiB3YXMgYXBw ZW5kZWQgdG8gMy40IENvbm5lY3Rpb24gSGVhbHRoIC0NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9wdWxsLzE0MC9maWxlcyI+aHR0cHM6Ly9naXRodWIu Y29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTQwL2ZpbGVzPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGUgb3BpbmlvbiBvZiB0aGUgYXV0aG9ycyAoYW5kIEdlbmd5dSBX RUnigJlzIHJlY2VudCByZXNwb25zZSAtDQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sPC9hPikg aXMgdGhhdCBSRkM2NDU1IGNvdmVycyB0aGUgV2ViU29ja2V0IGNhc2UgYW5kIGRvZXMgbm90IG5l ZWQgdG8gYmUgcmVwZWF0ZWQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBXaGVuIHdlIHVzZSA3MjUyLCBJIHRoaW5rIGFwcGxpY2F0aW9ucyBiYXNpY2FsbHkgZG9uJ3Qg bmVlZCB0byBpbXBsZW1lbnQgdGltZW91dHMgb3IgcmV0cnkgbWVjaGFuaXNtcyBhcyB0aGUgcHJv dG9jb2w8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcHJvdmlk ZXMgc3VjaCB0aGluZ3MuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SRkM3MjUyIHBy b3ZpZGVzIHRpbWVvdXRzIGFuZCByZXRyaWVzIGJlY2F1c2UgaXQncyBpbXBsZW1lbnRpbmcgYSBU Q1AtbGlrZSByZWxpYWJpbGl0eSBtZWNoYW5pc20gb3ZlciBVRFAgLQ0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2VjdGlvbi0yLjEiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEhvd2V2ZXIsIHdoZW4gd2UgdXNlIHRoaXMgb25lLCBpdCBzZWVtcyBh cHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5pc21zLiBJc24ndCBpdCBh IGJpdCBjb25mdXNpbmc/IEkgYW0gdGhpbmtpbmcgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGVyZSBuZWVkIHRvIGJlIHNvbWUgZ3VpZGFuY2UgaGVy ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQlRXLCBQT05H IGlzIG9uZSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Gb3IgY29hcC10 Y3AtdGxzLCB0aGVyZSBhcmUgbXVsdGlwbGUgZWFybHkgaW1wbGVtZW50YXRpb25zLiBUaGlzIGhh cyBuZXZlciBiZWVuIHJlcG9ydGVkIGFzIGEgc291cmNlIG9mIGNvbmZ1c2lvbi4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBNeSBzZW5zZSBpcyB0aGF0IHdlIHNob3Vs ZCB0cmVhdCB0aGlzIGFzIGFuIHVwZGF0ZSB0byBSRkM3OTU5IGJhc2VkIG9uIHRoZSBvcmlnaW5h bCBsYW5ndWFnZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg SSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5l IGZvciBtZSBpZiBpdCdzIGNsZWFyZXIgdG8gQ29BUCBwZW9wbGUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkndmUgbWVyZ2VkIHRoZSBjaGFuZ2UgLSA8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvcHVsbC8xMzgvZmlsZXMiPg0KaHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTM4L2ZpbGVzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBhZ2FpbiBmb3IgaGVs cGluZyB1cyB0byBpbXByb3ZlIHRoZSBxdWFsaXR5IG9mIHRoZSBkcmFmdCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+4oCmQnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_-- From nobody Fri Apr 21 14:08:07 2017 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 DD6F1129479; Fri, 21 Apr 2017 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ahQJJ6NZu6_S; Fri, 21 Apr 2017 14:07:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C25128B44; Fri, 21 Apr 2017 14:07:56 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 30195279D8E; Sat, 22 Apr 2017 06:07:54 +0900 (JST) Received: by mail-oi0-f48.google.com with SMTP id x184so112867488oia.1; Fri, 21 Apr 2017 14:07:54 -0700 (PDT) X-Gm-Message-State: AN3rC/6vOngQAXDkGNCJhPiowtR0CAmuNZcCGZ/dXd6RBnVt/7rUy+YN DHiFeUG4clDLVb8RwnaykgToU2grPw== X-Received: by 10.157.40.87 with SMTP id h23mr9949234otd.274.1492808872850; Fri, 21 Apr 2017 14:07:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Fri, 21 Apr 2017 14:07:52 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 21 Apr 2017 14:07:52 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a11396afc957e3a054db3a6cc Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 21:07:59 -0000 --001a11396afc957e3a054db3a6cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Just in case, Reliable transports only provide reliability at transport level. It doesn't provide reliability in application protocol level. RFC7252 has reliability mechanisms in it since it uses UDP. This means it has abilities to check both transport and app level reliability. This draft only provides transport level reliability and apps will need to detect app protocol failure by themselves. This means 7252 and this draft are not totally equivalent from the viewpoint of applications. I am not saying this is wrong or bad, but I believe app developer should aware this point. -- Yoshi On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor wrote: > Hi Yoshi, > > > > > OK. I also think we should state that the protocol should notify the > failure events to applications. > > > Since errors can happen not only in TCP, but also TLS and websocket > level, mentioning only TCP close or reset might not > > > be enough. > > > > After reviewing with the authors, an additional clarification was appende= d > to 3.4 Connection Health - https://github.com/core-wg/ > coap-tcp-tls/pull/140/files > > > > The opinion of the authors (and Gengyu WEI=E2=80=99s recent response - > https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that > RFC6455 covers the WebSocket case and does not need to be repeated here. > > > > > When we use 7252, I think applications basically don't need to implemen= t > timeouts or retry mechanisms as the protocol > > > provides such things. > > > > RFC7252 provides timeouts and retries because it's implementing a TCP-lik= e > reliability mechanism over UDP - https://tools.ietf.org/html/ > rfc7252#section-2.1 > > > > > However, when we use this one, it seems applications will need to have > such mechanisms. Isn't it a bit confusing? I am thinking that > > > there need to be some guidance here. > > > BTW, PONG is one example. > > > > For coap-tcp-tls, there are multiple early implementations. This has neve= r > been reported as a source of confusion. > > > > >> My sense is that we should treat this as an update to RFC7959 based on > the original language: > > > I don't have a strong opinion here. Updating 7959 is fine for me if it'= s > clearer to CoAP people. > > > > I've merged the change - https://github.com/core-wg/ > coap-tcp-tls/pull/138/files > > > > Thanks again for helping us to improve the quality of the draft, > > > > =E2=80=A6Brian > --001a11396afc957e3a054db3a6cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Just in case,
Relia= ble transports only provide reliability at transport level. It doesn't = provide reliability in application protocol level.=C2=A0

RFC7252 has reliability mechanisms in it since it uses UDP. This mea= ns it has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will ne= ed to detect app protocol failure by themselves.=C2=A0
This means= 7252 and this draft are not totally equivalent from the viewpoint of appli= cations.=C2=A0

I am not saying this is wrong or ba= d, but I believe app developer should aware this point.
--
Yoshi

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <= ;Brian.Raym= or@microsoft.com> wrote:

Hi Yoshi,

=C2=A0<= /p>

> OK. I also think= we should state that the protocol should notify the failure events to appl= ications.=C2=A0

> Since errors can= happen not only in TCP, but also TLS and websocket level, mentioning only = TCP close or reset might not

> be enough.

=C2=A0<= /p>

After reviewin= g with the authors, an additional clarification was appended to 3.4 Connect= ion Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files=

=C2=A0<= /p>

The opinion of the au= thors (and Gengyu WEI=E2=80=99s recent response - https://www.ietf.org/mail-archive/web/core/current= /msg08622.html) is that RFC6455 covers the WebSocket case and does= not need to be repeated here.

=C2=A0<= /p>

> When we use 7252= , I think applications basically don't need to implement timeouts or re= try mechanisms as the protocol

> provides such th= ings.

=C2=A0<= /p>

RFC7252 provid= es timeouts and retries because it's implementing a TCP-like reliabilit= y mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

=C2=A0<= /p>

> However, when we= use this one, it seems applications will need to have such mechanisms. Isn= 't it a bit confusing? I am thinking that

> there need to be= some guidance here.

> BTW, PONG is one= example.

=C2=A0<= /p>

For coap-tcp-t= ls, there are multiple early implementations. This has never been reported = as a source of confusion.

=C2=A0<= /p>

>> My sense is = that we should treat this as an update to RFC7959 based on the original lan= guage:

> I don't have= a strong opinion here. Updating 7959 is fine for me if it's clearer to= CoAP people.

=C2=A0<= /p>

I've merge= d the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

=C2=A0<= /p>

Thanks again for helping us to improve the quality of the draft,<= span class=3D"gmail-HOEnZb">

=C2=A0

=E2=80=A6Brian


--001a11396afc957e3a054db3a6cc-- From nobody Fri Apr 21 14:58:45 2017 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 C3AC0128896; Fri, 21 Apr 2017 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8M7J2GgLu_N; Fri, 21 Apr 2017 14:58:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0137.outbound.protection.outlook.com [104.47.38.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786AC127419; Fri, 21 Apr 2017 14:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RCNcGBcpFMFACwUzgRWino9j/YiAC0OIqEzpt7Mk0q8=; b=QlBZJCF597JET/z8/JXFo4r92pAerWliExHW561i1rm6G+hOZCSJeB/ltKB8tpykewXM1KZUiwJjh+oiv273hnehCpsQUPnfPAPzFR3sPW+7Acr7fKqyXwh40MOBm3HiCuxU6OPWyTmVrPXk5C/a0mP0ZZvL01xwApOvKnkv/CA= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0083.namprd21.prod.outlook.com (10.162.78.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Fri, 21 Apr 2017 21:57:39 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Fri, 21 Apr 2017 21:57:39 +0000 From: Brian Raymor To: Yoshifumi Nishida CC: "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Thread-Topic: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsOTWicthTbHq+0Cl6wEpb6SnVKHOtjQAgADZuACAAKJUUIAAMqMAgAADmmA= Date: Fri, 21 Apr 2017 21:57:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0083; 7:SUyyCBTp6tIPDmMkBxW3jAig8ww5pYu2G79NPVVNK1yBkyOowbioy+N+Xf618XodNeWh5DuwyqEAztWNW+TqU+98EWQvilEXXUskZdQych/mntocKRsqi/3jbXi/mYQAYub6rUWyAtmwS2i2vwle8KVWu9rdph0gGWD1tfYyqYTYtggO4NtncBGx5YX0YQECDeeSNIuKHg8zQ0Q/uMvZBjF+uKg6/kDbWzM4I02co41tq9pgyVRf+pDoKw672+xVXFf2MyGqpnpcEP+EXTYeR2LYZTJQEKwMM1EWsj+hCgw1dIF2+pSoIpjGy+zraJSF/FPaho6wFZ+uO4NgyDdmmCFAg4Cts9m1WFVqqi8tUUs= x-ms-office365-filtering-correlation-id: 76a0f5b2-64ee-453c-8300-08d489016d76 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR21MB0083; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(43784003)(51444003)(377454003)(199003)(189002)(24454002)(3660700001)(230783001)(10290500002)(6436002)(189998001)(86612001)(5005710100001)(7696004)(105586002)(6506006)(6246003)(77096006)(4326008)(74316002)(86362001)(3280700002)(5660300001)(110136004)(7736002)(76176999)(54356999)(236005)(50986999)(101416001)(33656002)(7906003)(8990500004)(2900100001)(9686003)(97736004)(229853002)(606005)(55016002)(19609705001)(54906002)(99286003)(8676002)(6916009)(25786009)(68736007)(93886004)(790700001)(10090500001)(6116002)(102836003)(3846002)(81156014)(8936002)(54896002)(6306002)(2950100002)(66066001)(53546009)(122556002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0083; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 21:57:38.8246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0083 Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 21:58:27 -0000 --_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IEkgdW5kZXJzdGFuZCB5b3VyIHBlcmNlcHRpb25zIGJldHRlci4gUHJpb3Ig dG8gYWRvcHRpb24gb2YgY29hcC10Y3AtdGxzIGFuZCBiZWZvcmUgSSB3YXMgYWN0aXZlIGluIHRo ZSBXRywgSSByZWNhbGwgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byB0aGUgY29uZnVzaW9uIG92ZXIg YXBwbGljYXRpb24gdnMgdHJhbnNwb3J0IHJlbGlhYmlsaXR5IGluIENvQVAgZXNwZWNpYWxseSBh cyByZWxhdGVkIHRvIENPTiBhbmQgTk9OLiBXaGF0IHdhcyBpbnRlbmRlZD8NCg0KVGltIENhcmV5 IG91dGxpbmVkIHNvbWUgY29uY2VybnMgaW46DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2FyZXktY29yZS1zdGQtbXNnLXZzLXRyYW5zLWFkYXB0LTAwI3NlY3Rpb24tMg0KDQpU aGlzIHRvcGljIHdhcyBwcmVzZW50ZWQgaW4gZGV0YWlsIGF0IElFVEYgOTMgLSBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLWNvcmUtMC5wZGYgLSBz dGFydGluZyBvbiBzbGlkZSAyMy4NCg0KQW5kIGluIGEgcmVsYXRlZCB0aHJlYWQgb24gdGhlIG1h aWxpbmcgbGlzdCBiYWNrIGluIDIwMTUgLSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2NvcmUvY3VycmVudC9tc2cwNjI4MC5odG1sIC0gQ2Fyc3RlbiByZXNwb25kZWQ6DQoN Cj4gSW4gYW55IGNhc2UsIENPTiBhbmQgTk9OIGFyZSBhYm91dCBtZXNzYWdlIGxheWVyIHNlbWFu dGljcywgbm90IGFib3V0IGFwcGxpY2F0aW9uIHNlbWFudGljcw0KPiAtLSB5b3UgZ2F2ZSB0aGVt IGEgbWVhbmluZyB0aGV5IGRvbid0IGhhdmUuDQoNCkJ5IElFVEYgOTQsIHRoZSBhdXRob3JzIHdl cmUgcmVwb3J0aW5nIOKAkyDigJxNb3N0IG9mIHRoZSBDb25mdXNpb24gYXJvdW5kICAgICAgICAg ICAgICBDT04vTk9OIHdhcyByZXNvbHZlZOKAnS4NCg0KV2hlcmUgcmVsZXZhbnQsIEnigJl2ZSBh ZGRlZCBjbGFyaWZpY2F0aW9ucyAtIHN1Y2ggYXMgdGhlIEFwcGVuZGl4IHJlbGF0ZWQgdG8gZGlm ZmVyZW5jZXMgaW4gT2JzZXJ2ZSBmb3IgcmVsaWFibGUgdHJhbnNwb3J0cy4NCg0KQm90aCBDYXJz dGVuIGFuZCBIYW5uZXMgY291bGQgcHJvYmFibHkgb2ZmZXIgbW9yZSBjb250ZXh0IGlmIG5lZWRl ZC4NCg0KRnJvbTogWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53aWRlLmFk LmpwXQ0KU2VudDogRnJpZGF5LCBBcHJpbCAyMSwgMjAxNyAyOjA4IFBNDQpUbzogQnJpYW4gUmF5 bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NCkNjOiBZb3NoaWZ1bWkgTmlzaGlkYSA8 bmlzaGlkYUBzZmMud2lkZS5hZC5qcD47IHRzdi1hcnRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29y ZS1jb2FwLXRjcC10bHNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBUU1YtQVJUIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz LTA3DQoNCkhpIEJyaWFuLA0KDQpKdXN0IGluIGNhc2UsDQpSZWxpYWJsZSB0cmFuc3BvcnRzIG9u bHkgcHJvdmlkZSByZWxpYWJpbGl0eSBhdCB0cmFuc3BvcnQgbGV2ZWwuIEl0IGRvZXNuJ3QgcHJv dmlkZSByZWxpYWJpbGl0eSBpbiBhcHBsaWNhdGlvbiBwcm90b2NvbCBsZXZlbC4NCg0KUkZDNzI1 MiBoYXMgcmVsaWFiaWxpdHkgbWVjaGFuaXNtcyBpbiBpdCBzaW5jZSBpdCB1c2VzIFVEUC4gVGhp cyBtZWFucyBpdCBoYXMgYWJpbGl0aWVzIHRvIGNoZWNrIGJvdGggdHJhbnNwb3J0IGFuZCBhcHAg bGV2ZWwgcmVsaWFiaWxpdHkuDQpUaGlzIGRyYWZ0IG9ubHkgcHJvdmlkZXMgdHJhbnNwb3J0IGxl dmVsIHJlbGlhYmlsaXR5IGFuZCBhcHBzIHdpbGwgbmVlZCB0byBkZXRlY3QgYXBwIHByb3RvY29s IGZhaWx1cmUgYnkgdGhlbXNlbHZlcy4NClRoaXMgbWVhbnMgNzI1MiBhbmQgdGhpcyBkcmFmdCBh cmUgbm90IHRvdGFsbHkgZXF1aXZhbGVudCBmcm9tIHRoZSB2aWV3cG9pbnQgb2YgYXBwbGljYXRp b25zLg0KDQpJIGFtIG5vdCBzYXlpbmcgdGhpcyBpcyB3cm9uZyBvciBiYWQsIGJ1dCBJIGJlbGll dmUgYXBwIGRldmVsb3BlciBzaG91bGQgYXdhcmUgdGhpcyBwb2ludC4NCi0tDQpZb3NoaQ0KDQpP biBGcmksIEFwciAyMSwgMjAxNyBhdCAxMToxNSBBTSwgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXlt b3JAbWljcm9zb2Z0LmNvbTxtYWlsdG86QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KSGkgWW9zaGksDQoNCg0KDQo+IE9LLiBJIGFsc28gdGhpbmsgd2Ugc2hvdWxkIHN0YXRl IHRoYXQgdGhlIHByb3RvY29sIHNob3VsZCBub3RpZnkgdGhlIGZhaWx1cmUgZXZlbnRzIHRvIGFw cGxpY2F0aW9ucy4NCg0KPiBTaW5jZSBlcnJvcnMgY2FuIGhhcHBlbiBub3Qgb25seSBpbiBUQ1As IGJ1dCBhbHNvIFRMUyBhbmQgd2Vic29ja2V0IGxldmVsLCBtZW50aW9uaW5nIG9ubHkgVENQIGNs b3NlIG9yIHJlc2V0IG1pZ2h0IG5vdA0KDQo+IGJlIGVub3VnaC4NCg0KDQoNCkFmdGVyIHJldmll d2luZyB3aXRoIHRoZSBhdXRob3JzLCBhbiBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24gd2FzIGFw cGVuZGVkIHRvIDMuNCBDb25uZWN0aW9uIEhlYWx0aCAtIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL2NvYXAtdGNwLXRscy9wdWxsLzE0MC9maWxlcw0KDQoNCg0KVGhlIG9waW5pb24gb2YgdGhl IGF1dGhvcnMgKGFuZCBHZW5neXUgV0VJ4oCZcyByZWNlbnQgcmVzcG9uc2UgLSBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sKSBp cyB0aGF0IFJGQzY0NTUgY292ZXJzIHRoZSBXZWJTb2NrZXQgY2FzZSBhbmQgZG9lcyBub3QgbmVl ZCB0byBiZSByZXBlYXRlZCBoZXJlLg0KDQoNCg0KPiBXaGVuIHdlIHVzZSA3MjUyLCBJIHRoaW5r IGFwcGxpY2F0aW9ucyBiYXNpY2FsbHkgZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgdGltZW91dHMg b3IgcmV0cnkgbWVjaGFuaXNtcyBhcyB0aGUgcHJvdG9jb2wNCg0KPiBwcm92aWRlcyBzdWNoIHRo aW5ncy4NCg0KDQoNClJGQzcyNTIgcHJvdmlkZXMgdGltZW91dHMgYW5kIHJldHJpZXMgYmVjYXVz ZSBpdCdzIGltcGxlbWVudGluZyBhIFRDUC1saWtlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbSBvdmVy IFVEUCAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMi4xDQoN Cg0KDQo+IEhvd2V2ZXIsIHdoZW4gd2UgdXNlIHRoaXMgb25lLCBpdCBzZWVtcyBhcHBsaWNhdGlv bnMgd2lsbCBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5pc21zLiBJc24ndCBpdCBhIGJpdCBjb25m dXNpbmc/IEkgYW0gdGhpbmtpbmcgdGhhdA0KDQo+IHRoZXJlIG5lZWQgdG8gYmUgc29tZSBndWlk YW5jZSBoZXJlLg0KDQo+IEJUVywgUE9ORyBpcyBvbmUgZXhhbXBsZS4NCg0KDQoNCkZvciBjb2Fw LXRjcC10bHMsIHRoZXJlIGFyZSBtdWx0aXBsZSBlYXJseSBpbXBsZW1lbnRhdGlvbnMuIFRoaXMg aGFzIG5ldmVyIGJlZW4gcmVwb3J0ZWQgYXMgYSBzb3VyY2Ugb2YgY29uZnVzaW9uLg0KDQoNCg0K Pj4gTXkgc2Vuc2UgaXMgdGhhdCB3ZSBzaG91bGQgdHJlYXQgdGhpcyBhcyBhbiB1cGRhdGUgdG8g UkZDNzk1OSBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2U6DQoNCj4gSSBkb24ndCBoYXZl IGEgc3Ryb25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5lIGZvciBtZSBpZiBp dCdzIGNsZWFyZXIgdG8gQ29BUCBwZW9wbGUuDQoNCg0KDQpJJ3ZlIG1lcmdlZCB0aGUgY2hhbmdl IC0gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTM4L2ZpbGVz DQoNCg0KVGhhbmtzIGFnYWluIGZvciBoZWxwaW5nIHVzIHRvIGltcHJvdmUgdGhlIHF1YWxpdHkg b2YgdGhlIGRyYWZ0LA0KDQrigKZCcmlhbg0KDQo= --_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbS0zMDU4NDQ4 ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0LCBsaS5nbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdt c29wbGFpbnRleHQsIGRpdi5nbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQN Cgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4 dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwt DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXttc28tc3R5 bGUtbmFtZTpnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IEkgdW5kZXJzdGFuZCB5b3Vy IHBlcmNlcHRpb25zIGJldHRlci4gUHJpb3IgdG8gYWRvcHRpb24gb2YgY29hcC10Y3AtdGxzIGFu ZCBiZWZvcmUgSSB3YXMgYWN0aXZlIGluIHRoZSBXRywgSSByZWNhbGwgZGlzY3Vzc2lvbnMgcmVs YXRlZCB0byB0aGUgY29uZnVzaW9uIG92ZXIgYXBwbGljYXRpb24NCiB2cyB0cmFuc3BvcnQgcmVs aWFiaWxpdHkgaW4gQ29BUCBlc3BlY2lhbGx5IGFzIHJlbGF0ZWQgdG8gQ09OIGFuZCBOT04uIFdo YXQgd2FzIGludGVuZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaW0gQ2FyZXkgb3V0bGluZWQgc29tZSBj b25jZXJucyBpbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jYXJleS1jb3JlLXN0ZC1tc2ctdnMtdHJhbnMtYWRhcHQtMDAjc2VjdGlvbi0yIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FyZXktY29yZS1zdGQtbXNnLXZzLXRyYW5zLWFk YXB0LTAwI3NlY3Rpb24tMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyB0b3BpYyB3YXMgcHJlc2Vu dGVkIGluIGRldGFpbCBhdCBJRVRGIDkzIC0NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzkzL3NsaWRlcy9zbGlkZXMtOTMtY29yZS0wLnBkZiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1jb3JlLTAucGRmPC9hPiAt IHN0YXJ0aW5nIG9uIHNsaWRlIDIzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQgaW4gYSByZWxhdGVkIHRo cmVhZCBvbiB0aGUgbWFpbGluZyBsaXN0IGJhY2sgaW4gMjAxNSAtDQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwNjI4MC5odG1s Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cw NjI4MC5odG1sPC9hPiAtIENhcnN0ZW4gcmVzcG9uZGVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IElu IGFueSBjYXNlLCBDT04gYW5kIE5PTiBhcmUgYWJvdXQgbWVzc2FnZSBsYXllciBzZW1hbnRpY3Ms IG5vdCBhYm91dCBhcHBsaWNhdGlvbiBzZW1hbnRpY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgLS0geW91IGdhdmUgdGhl bSBhIG1lYW5pbmcgdGhleSBkb24ndCBoYXZlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJ5IElFVEYgOTQs IHRoZSBhdXRob3JzIHdlcmUgcmVwb3J0aW5nIOKAkyDigJxNb3N0IG9mIHRoZSBDb25mdXNpb24g YXJvdW5kJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENPTi9OT04gd2FzIHJlc29sdmVk4oCdLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPldoZXJlIHJlbGV2YW50LCBJ4oCZdmUgYWRkZWQgY2xhcmlmaWNhdGlvbnMg LSBzdWNoIGFzIHRoZSBBcHBlbmRpeCByZWxhdGVkIHRvIGRpZmZlcmVuY2VzIGluIE9ic2VydmUg Zm9yIHJlbGlhYmxlIHRyYW5zcG9ydHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJvdGggQ2Fyc3RlbiBhbmQg SGFubmVzIGNvdWxkIHByb2JhYmx5IG9mZmVyIG1vcmUgY29udGV4dCBpZiBuZWVkZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53aWRl LmFkLmpwXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMjEsIDIwMTcgMjowOCBQ TTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gUmF5bW9yICZsdDtCcmlhbi5SYXltb3JAbWljcm9zb2Z0 LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFlvc2hpZnVtaSBOaXNoaWRhICZsdDtuaXNoaWRhQHNm Yy53aWRlLmFkLmpwJmd0OzsgdHN2LWFydEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLWNvYXAt dGNwLXRsc0BpZXRmLm9yZzsgY29yZUBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogVFNWLUFSVCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNw LXRscy0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpYW4sPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGluIGNhc2UsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWxpYWJsZSB0 cmFuc3BvcnRzIG9ubHkgcHJvdmlkZSByZWxpYWJpbGl0eSBhdCB0cmFuc3BvcnQgbGV2ZWwuIEl0 IGRvZXNuJ3QgcHJvdmlkZSByZWxpYWJpbGl0eSBpbiBhcHBsaWNhdGlvbiBwcm90b2NvbCBsZXZl bC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UkZDNzI1MiBoYXMgcmVsaWFiaWxpdHkgbWVjaGFuaXNtcyBpbiBpdCBzaW5jZSBpdCB1 c2VzIFVEUC4gVGhpcyBtZWFucyBpdCBoYXMgYWJpbGl0aWVzIHRvIGNoZWNrIGJvdGggdHJhbnNw b3J0IGFuZCBhcHAgbGV2ZWwgcmVsaWFiaWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IG9ubHkgcHJvdmlkZXMgdHJhbnNw b3J0IGxldmVsIHJlbGlhYmlsaXR5IGFuZCBhcHBzIHdpbGwgbmVlZCB0byBkZXRlY3QgYXBwIHBy b3RvY29sIGZhaWx1cmUgYnkgdGhlbXNlbHZlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVhbnMgNzI1MiBhbmQgdGhpcyBk cmFmdCBhcmUgbm90IHRvdGFsbHkgZXF1aXZhbGVudCBmcm9tIHRoZSB2aWV3cG9pbnQgb2YgYXBw bGljYXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzYXlpbmcgdGhpcyBpcyB3cm9uZyBvciBiYWQsIGJ1dCBJ IGJlbGlldmUgYXBwIGRldmVsb3BlciBzaG91bGQgYXdhcmUgdGhpcyBwb2ludC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3NoaTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEFwciAyMSwgMjAxNyBhdCAxMTox NSBBTSwgQnJpYW4gUmF5bW9yICZsdDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUmF5bW9yQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5Ccmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50 ZXh0Ij5IaSBZb3NoaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4 MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jmd0OyBPSy4gSSBhbHNv IHRoaW5rIHdlIHNob3VsZCBzdGF0ZSB0aGF0IHRoZSBwcm90b2NvbCBzaG91bGQgbm90aWZ5IHRo ZSBmYWlsdXJlIGV2ZW50cyB0byBhcHBsaWNhdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7IFNp bmNlIGVycm9ycyBjYW4gaGFwcGVuIG5vdCBvbmx5IGluIFRDUCwgYnV0IGFsc28gVExTIGFuZCB3 ZWJzb2NrZXQgbGV2ZWwsIG1lbnRpb25pbmcgb25seSBUQ1AgY2xvc2Ugb3IgcmVzZXQgbWlnaHQg bm90DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2 NDdtc29wbGFpbnRleHQiPiZndDsgYmUgZW5vdWdoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0 Ij5BZnRlciByZXZpZXdpbmcgd2l0aCB0aGUgYXV0aG9ycywgYW4gYWRkaXRpb25hbCBjbGFyaWZp Y2F0aW9uIHdhcyBhcHBlbmRlZCB0byAzLjQgQ29ubmVjdGlvbiBIZWFsdGggLQ0KPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTQwL2ZpbGVzIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMv cHVsbC8xNDAvZmlsZXM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4 NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPlRoZSBvcGluaW9u IG9mIHRoZSBhdXRob3JzIChhbmQgR2VuZ3l1IFdFSeKAmXMgcmVjZW50IHJlc3BvbnNlIC0NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY29yZS9jdXJyZW50 L21zZzA4NjIyLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvY29yZS9jdXJyZW50L21zZzA4NjIyLmh0bWw8L2E+KSBpcyB0aGF0IFJG QzY0NTUgY292ZXJzIHRoZSBXZWJTb2NrZXQgY2FzZSBhbmQgZG9lcyBub3QgbmVlZCB0byBiZSBy ZXBlYXRlZCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgx NTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7IFdoZW4gd2UgdXNl IDcyNTIsIEkgdGhpbmsgYXBwbGljYXRpb25zIGJhc2ljYWxseSBkb24ndCBuZWVkIHRvIGltcGxl bWVudCB0aW1lb3V0cyBvciByZXRyeSBtZWNoYW5pc21zIGFzIHRoZSBwcm90b2NvbDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4 dCI+Jmd0OyBwcm92aWRlcyBzdWNoIHRoaW5ncy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQi PlJGQzcyNTIgcHJvdmlkZXMgdGltZW91dHMgYW5kIHJldHJpZXMgYmVjYXVzZSBpdCdzIGltcGxl bWVudGluZyBhIFRDUC1saWtlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbSBvdmVyIFVEUCAtDQo8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTIuMSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24t Mi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3 NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwt bS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7IEhvd2V2ZXIsIHdoZW4gd2Ug dXNlIHRoaXMgb25lLCBpdCBzZWVtcyBhcHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGhhdmUgc3Vj aCBtZWNoYW5pc21zLiBJc24ndCBpdCBhIGJpdCBjb25mdXNpbmc/IEkgYW0gdGhpbmtpbmcgdGhh dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21z b3BsYWludGV4dCI+Jmd0OyB0aGVyZSBuZWVkIHRvIGJlIHNvbWUgZ3VpZGFuY2UgaGVyZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFp bnRleHQiPiZndDsgQlRXLCBQT05HIGlzIG9uZSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxh aW50ZXh0Ij5Gb3IgY29hcC10Y3AtdGxzLCB0aGVyZSBhcmUgbXVsdGlwbGUgZWFybHkgaW1wbGVt ZW50YXRpb25zLiBUaGlzIGhhcyBuZXZlciBiZWVuIHJlcG9ydGVkIGFzIGEgc291cmNlIG9mIGNv bmZ1c2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYz NzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21h aWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7Jmd0OyBNeSBzZW5zZSBp cyB0aGF0IHdlIHNob3VsZCB0cmVhdCB0aGlzIGFzIGFuIHVwZGF0ZSB0byBSRkM3OTU5IGJhc2Vk IG9uIHRoZSBvcmlnaW5hbCBsYW5ndWFnZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPiZndDsgSSBkb24ndCBoYXZlIGEg c3Ryb25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5lIGZvciBtZSBpZiBpdCdz IGNsZWFyZXIgdG8gQ29BUCBwZW9wbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwt bS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPkkndmUg bWVyZ2VkIHRoZSBjaGFuZ2UgLSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9j b2FwLXRjcC10bHMvcHVsbC8xMzgvZmlsZXMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0 aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9wdWxsLzEzOC9maWxlczwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rcyBhZ2FpbiBmb3IgaGVscGluZyB1cyB0byBpbXByb3ZlIHRoZSBxdWFsaXR5 IG9mIHRoZSBkcmFmdCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPuKApkJyaWFuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_-- From nobody Fri Apr 21 16:11:47 2017 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 02E311242F5; Fri, 21 Apr 2017 16:11:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-links-json@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> Date: Fri, 21 Apr 2017 16:11:46 -0700 Archived-At: Subject: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:11:46 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-links-json-07: Discuss 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-links-json/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. Ambiguity 1: Section 1.1 describes "round-tripping" between 6690 format and JSON/CBOR; however, the document describes the transform in one direction, leaving the other implicit. The non-normative code in Appendix A shows a conversion into link relation format, but it makes certain assumptions about the syntax of link relation parameters that, while possibly true today, are not guaranteed to hold true in the future. As defined in this document, the transform requires parameter-specific syntax knowledge of each link relation parameter that it will transform. The problem this causes is probably best demonstrated with an example. Let's say some future document defined a link relation ("smellslike") that included a parameter with ABNF syntax like: "smellsys" "=" quoted-string Now, if we were to apply the transform in this document to the following link relation: ;smellsys="h9341";rel="smellslike" We get: [{"href":"/smellr2", "smellsys":"h9341","rel":"smellslike"}] Applying the logic that is implicit in the document and explicit (if non-normative) in Appendix A, converting this back into a link relation yields: ;smellsys=h9341;rel=smellslike Note the stripping of double quotes from the parameter values. This is fine for "rel", whose ABNF syntax allows for the presence or absence of quotes -- but the emitted syntax for "smellsys" is actually in violation of its defined ABNF. This needs to be addressed by either indicating that conversion into link relations requires that the conversion routine has explicit knowledge of the syntax for each parameter it converts (and must fail to convert parameters it does not understand), *or* the JSON and CBOR representations need some additional indication that preserves knowledge of whether the indicated value is required to be quoted when converted to a link relation. If the first path is taken, the associated Ruby code needs to be updated accordingly. Ambiguity 2: The document requires that the thirteen defined values MUST be encoded as integers. The document does not define what implementations are to do if they receive a CBOR object that does not conform to this encoding: is the parameter ignored? Is the entire link relation ignored? Do you reject the entire collection of link relations? Or do you just go ahead and parse it anyway, since the intended meaning is ambiguous (even if out of spec)? - The draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively. This document appears to use CDDL to define the formal schema for both the JSON and CBOR representations of its data format, although the CDDL document itself is cited only informatively. Additionally , figure 1 shows an application of CDDL to define schema for JSON. It's not clear from a skim through the CDDL document that it can be used for JSON; it would appear that using it in this fashion would require additional text in this document to talk about how to apply CDDL to JSON, or waiting for some other document to do so. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In section 2.2, the phrase "outer collection" is a bit difficult to understand at first (on first reading, the sense of the word "outer" is unclear); recommend a more descriptive phrase like "The collection of link relations is represented as a JSON or CBOR array of links" The first paragraph on page 5 is using normal English prose to describe normative behavior, which is fine; however it plainly says that the encoding is normal JSON name/value pairs, and that "the value is a string," full stop, no exceptions. Further down, this section says the value can be a boolean, which effectively contradicts the earlier statement. Even further down, it says the value can be an array of strings. It would be much easier to understand if the initial statement said "the value can be a string, a boolean, or an array of strings, as described below," and then have each of the three situations described independently. Both of the CDDL schemata seem to omit support for array values (i.e., if a name appears twice in a link relation, as shown in Figure 4). Section 2.3 opens with "The above specification could be used as is..." -- there is a risk that implementors might read this as permission rather than hypothetical musing. Suggest rephrasing like "...might have been able to be used as-is..." Table 1 reads is introduced with the phrase "The substitution is summarized below," which had me looking for the actual definition elsewhere in the document. Not finding one, I conclude this table defines, rather than summarizes, the substitution. (Replace "summarized" with "defined"). One would presume the paragraph below table 1 should be removed. The example in Figure 6 would benefit greatly by showing both the array encoding and "foo" encoding used in Figure 4 (including, in particular, the string -- rather than integer -- encoding of the "foo=3" parameter). From nobody Fri Apr 21 16:16:30 2017 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 401D21242F5; Fri, 21 Apr 2017 16:16:29 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281658922.25848.5921781397085157648@ietfa.amsl.com> Date: Fri, 21 Apr 2017 16:16:29 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:16:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-08.txt Pages : 49 Date : 2017-04-21 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports, RFC 7959 to enable the use of larger messages over a reliable transport, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-tcp-tls-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 21 16:55:26 2017 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 14C2E129564; Fri, 21 Apr 2017 16:55:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281891905.25803.486183286884921759@ietfa.amsl.com> Date: Fri, 21 Apr 2017 16:55:19 -0700 Archived-At: Subject: [core] Secdir last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:55:19 -0000 Reviewer: Paul Wouters Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format of JSON optimized for IoT. This document describes the JSON and CBOR formats of the CoRE link format of RFC-6690. The document's security section refers to the security sections of the respective formats' RFCs, [RFC6690], [RFC7049] and [RFC7159]. These describe the various issues well. This document introduces no new issues that require further security considerations. From nobody Sat Apr 22 01:04:08 2017 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 A3A54120724; Sat, 22 Apr 2017 01:03:58 -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 eO1usm23bMVU; Sat, 22 Apr 2017 01:03:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ECA126DED; Sat, 22 Apr 2017 01:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3M83mMb004777; Sat, 22 Apr 2017 10:03:49 +0200 (CEST) Received: from client-0059.vpn.uni-bremen.de (client-0059.vpn.uni-bremen.de [134.102.107.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w94qm51KFzDJCN; Sat, 22 Apr 2017 10:03:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> Date: Sat, 22 Apr 2017 10:03:47 +0200 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-links-json@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 514541027.595496-7201b6f1741a27fa4c1ecfd26e8eae54 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 08:03:59 -0000 Hi Adam, thank you very much for this deep review. This will allow us to improve the document a lot. Let me pick one issue here that I think goes beyond the details of = links-json. > Let's say some future document defined a link relation ("smellslike") > that included a parameter with ABNF syntax like: >=20 > "smellsys" "=3D" quoted-string My knee-jerk reaction is =E2=80=9Cthen don=E2=80=99t do that=E2=80=9D. But the more fundamental problem is that RFC 5988 actually defines a = data model and its serialization without ever saying so. Any reasonably = defined link parameter will either have a syntax that is limited to = ptoken or allow both ptoken and quoted-string serialization. The fact that we then use ABNF to define the link parameter syntax = obscures that property and allows the above deviation. We already made = the mistake for [anchor, title, rt, if] (see MUSTBEQUOTED in the = reference implementation). There is no need to make it again, but the = use of ABNF for what should be a data model definition does make it too = easy to shoot ourselves in the foot. Note that the above issue hits any implementation that wants to generate = RFC 5988 syntax, not just one that converts links-json into RFC 5988 = syntax. So my takeaway summary is that links-json only works for reasonably = defined link parameters (after grandfathering in anchor, title, rt, if) = and probably should say so much more explicitly. But I don=E2=80=99t = know how to fix RFC 5988 about this issue. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Apr 22 01:33:03 2017 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 6BE6A129C27; Sat, 22 Apr 2017 01:32:54 -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 4sunpppcdK9w; Sat, 22 Apr 2017 01:32:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F513129C25; Sat, 22 Apr 2017 01:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3M8WmxQ027021; Sat, 22 Apr 2017 10:32:48 +0200 (CEST) Received: from client-0059.vpn.uni-bremen.de (client-0059.vpn.uni-bremen.de [134.102.107.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w95TD35qNzDJCj; Sat, 22 Apr 2017 10:32:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sat, 22 Apr 2017 10:32:47 +0200 Cc: draft-ietf-core-links-json@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org X-Mao-Original-Outgoing-Id: 514542767.419119-27ef02a8f7520883c018f2fc860b13ed Content-Transfer-Encoding: quoted-printable Message-Id: References: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 08:32:54 -0000 Interesting. Julian Reschke reminds me that this is repaired in = draft-nottingham-rfc5988bis-05.txt: 3. Link Serialisation in HTTP Headers The Link header field provides a means for serialising one or more links into HTTP headers. The ABNF for the field value is: Link =3D #link-value link-value =3D "<" URI-Reference ">" *( OWS ";" OWS link-param ) link-param =3D token BWS "=3D" BWS ( token / quoted-string ) Note that any "link-param" can be generated with values using either the "token" or the "quoted-string" syntax, and therefore recipients MUST be able to parse both forms. Individual "link-param"s specify their syntax in terms of the value after any necessary unquoting (as per [RFC7230], Section 3.2.6). Unfortunately, this doesn=E2=80=99t retroactively fix RFC 6690, which = still has restrictive ABNF for rt, if, title, anchor. Hmm. Gr=C3=BC=C3=9Fe, Carsten > On Apr 22, 2017, at 10:03, Carsten Bormann wrote: >=20 > Hi Adam, >=20 > thank you very much for this deep review. > This will allow us to improve the document a lot. >=20 > Let me pick one issue here that I think goes beyond the details of = links-json. >=20 >> Let's say some future document defined a link relation ("smellslike") >> that included a parameter with ABNF syntax like: >>=20 >> "smellsys" "=3D" quoted-string >=20 > My knee-jerk reaction is =E2=80=9Cthen don=E2=80=99t do that=E2=80=9D. >=20 > But the more fundamental problem is that RFC 5988 actually defines a = data model and its serialization without ever saying so. Any reasonably = defined link parameter will either have a syntax that is limited to = ptoken or allow both ptoken and quoted-string serialization. > The fact that we then use ABNF to define the link parameter syntax = obscures that property and allows the above deviation. We already made = the mistake for [anchor, title, rt, if] (see MUSTBEQUOTED in the = reference implementation). There is no need to make it again, but the = use of ABNF for what should be a data model definition does make it too = easy to shoot ourselves in the foot. >=20 > Note that the above issue hits any implementation that wants to = generate RFC 5988 syntax, not just one that converts links-json into RFC = 5988 syntax. >=20 > So my takeaway summary is that links-json only works for reasonably = defined link parameters (after grandfathering in anchor, title, rt, if) = and probably should say so much more explicitly. But I don=E2=80=99t = know how to fix RFC 5988 about this issue. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 From nobody Sat Apr 22 10:03:01 2017 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 C0AF312946D for ; Sat, 22 Apr 2017 10:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLvmqJkrHV-n for ; Sat, 22 Apr 2017 10:02:58 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0129.outbound.protection.outlook.com [104.47.37.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8C812944F for ; Sat, 22 Apr 2017 10:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9VHu1OHKKSgULcvDR5Ahub/qSNjD5WIEKxYmE+JIK3Q=; b=Dn0o2L/ORbAmNIByg6AQevWLBcVwmeqcPpq1FEQS5rR4V6pSc/kqMzZ/QDatRBXCjMMlrj/S867IJ6LES3GVqFv5GySRtNBO109+bDXCQyF5q5l5DpUm1ZvO0Q6YMCDlX8W5ahhyPyhQcNLg2T0+oIQlC8+JWAQPRHO0oBu6EZE= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Sat, 22 Apr 2017 17:02:57 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Sat, 22 Apr 2017 17:02:57 +0000 From: Brian Raymor To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-08.txt Thread-Index: AQHSuvVUsZS+ERB4MEeBo6upG981YqHRmpCQ Date: Sat, 22 Apr 2017 17:02:56 +0000 Message-ID: References: <149281658922.25848.5921781397085157648@ietfa.amsl.com> In-Reply-To: <149281658922.25848.5921781397085157648@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0084; 7:fFnQ+sWr7B0qnVfxbhmYoFxpZw58K+1TTU5vQTB61Q6Pwwx585haV/TRAkvF5Hs3Nw+eb+Si+YuQYT9hhL+T3ygK4DsXW1vQVMCIvPfb7UxkP9gi6F3E5N+kKK3oT3ppS2hcMqqzgUMzB1OumcRXyaMDZcImO0U5IjAxEfl3czGiqVSqbqfa/uTJkZDDEOAQG77p/DAuu34cumTCLvkbDqDKF1AdpotoAbtCJb1p+xYhAs6EjwFfVsXAiDFwaWbrnpjfaXbIOEs7OauTG3kl9kJlhtCXxAMizZo+e/88xzBzVq+h7uKqKI0CZO+36ijXGyICgO5K5GmzWi82MfBZ4vUI0orQ0ST+sL0vKZEYXds= x-ms-office365-filtering-correlation-id: 166178e5-86ee-4ff3-29ad-08d489a16c9c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR21MB0084; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406124)(20161123558071)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:BY2PR21MB0084; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0084; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(39400400002)(377454003)(13464003)(377424004)(2906002)(5005710100001)(99286003)(55016002)(10290500002)(8990500004)(230783001)(3280700002)(2900100001)(25786009)(6916009)(5640700003)(3660700001)(53546009)(8676002)(8936002)(6506006)(7696004)(6436002)(10090500001)(81166006)(1730700003)(53936002)(66066001)(77096006)(6306002)(3846002)(33656002)(110136004)(2351001)(7736002)(6116002)(102836003)(74316002)(6246003)(86362001)(229853002)(38730400002)(305945005)(5660300001)(2501003)(9686003)(2950100002)(189998001)(50986999)(76176999)(54356999)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0084; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 17:02:56.8153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0084 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 17:03:01 -0000 coap-tcp-tls-08 addresses the following issues - https://github.com/core-wg= /coap-tcp-tls/issues?utf8=3D%E2%9C%93&q=3D%20is%3Aissue%20milestone%3Acoap-= tcp-tls-08%20 I especially want to call attention to the "NoSec" change from mandatory-to= -implement to optional-to-implement - https://github.com/core-wg/coap-tcp-t= ls/issues/130 + https://github.com/core-wg/coap-tcp-tls/pull/137/files ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, April 21, 2017 4:16 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments of the IE= TF. Title : CoAP (Constrained Application Protocol) over TCP,= TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-08.txt Pages : 49 Date : 2017-04-21 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports, RFC 7959 to enable the use of larger messages over a reliable transport, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-tcp-tls-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-tcp-tls-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sat Apr 22 10:45:32 2017 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 5F45A1294B9; Sat, 22 Apr 2017 10:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TcRpLWJFges; Sat, 22 Apr 2017 10:45:21 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30112.outbound.protection.outlook.com [40.107.3.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6C8128B8F; Sat, 22 Apr 2017 10:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=f0tVLJ/PxTCazr7eKnliBWkLbD4p+Z3iyU+1cnX6iiI=; b=pL8mvLxTHWGT307cF5h4EGGj2Qbhpw3fiCTs8ETs1KSF58eK73zLG9/IKu5/TnwAllxXwCSV7C1jdSgMxrXKTjSfKdxvKTW6ySzQMfexDqR9DgRA4XFhnL9Jt7fDn2t6E7s4SBrVYf+tFCfaHAxeIM0sv310eJetd0J8GpvA6E8= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sat, 22 Apr 2017 17:45:18 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1047.018; Sat, 22 Apr 2017 17:45:18 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "core@ietf.org WG" CC: "tcpm@ietf.org" , "iccrg@ietf.org" , "michawe@ifi.uio.no" Thread-Topic: Heads up on the upcoming WGLC for COCOA Thread-Index: AQHSs4k0mnjKYz30k0+Zp7QNidIepKHRhciX Date: Sat, 22 Apr 2017 17:45:18 +0000 Message-ID: References: <23333C37-60FB-41FD-B43B-EDC75F7BBFDB@ericsson.com> In-Reply-To: <23333C37-60FB-41FD-B43B-EDC75F7BBFDB@ericsson.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [25.163.180.4] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 7:TmsjZpbQYd5hTSFMOpyo/8h5hykDiw7eUR6AW4+LdE1mOTSQ1HCPqjA96HRoVwfgGtwD+jJupP1d7OPFW7hvv7TFQx96t9ACtvvL2Ge4WC4LHKOGoiQ16TEMsa/jnrgxn0zLhrMbZyB4wcTl2k4O7LOvKcZ9F8sK1hMlzkXrCEXoUzKB/dQTUjxW4XTHHVEjAuhTuSWyLR1PAm/NhBbrkCIm4ShvyplFkVIz0XZeFmnZ67pw0NXBKTZ/eal6KayiFFtLVQxFBM1S6v3a6I8Wg6Tewpm/FxKRaKedb/ixr/eumDiCsZa1BzWf1V3JRHhnDzFiN1lgoy+gQvk+Wm1/sg== x-ms-office365-filtering-correlation-id: eed05b5c-7b4c-43b2-1d1a-08d489a75796 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM5PR0701MB2547; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2547; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39840400002)(39410400002)(39400400002)(39450400003)(54094003)(53754006)(6436002)(53936002)(9686003)(6306002)(102836003)(3846002)(6116002)(99286003)(54906002)(50986999)(54356999)(76176999)(55016002)(3660700001)(3280700002)(77096006)(6506006)(81166006)(2900100001)(110136004)(6246003)(38730400002)(8676002)(33656002)(66066001)(8936002)(2906002)(53546009)(189998001)(25786009)(6916009)(7696004)(229853002)(4326008)(5660300001)(7736002)(305945005)(2950100002)(74316002)(122556002)(86362001)(557034004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 17:45:18.6440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: Re: [core] Heads up on the upcoming WGLC for COCOA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 17:45:24 -0000 Hi all, I have read draft-ietf-core-cocoa-01 as a contributor to TCPM, in particula= r since TCP documents are mentioned therein. Please find below my comments.= Note that I have not followed discussions on this document and I also do n= ot monitor the CoRE mailing list, i.e., I may lack some context. If topics = have been discussed already, I apologize for that. I wonder if this document is already ready for WGLC. There is missing text,= and to me the alorithm is not very well motivated. A formal issue is the e= xplicit violation of the BCP RFC 8085 but this is more something for the IE= SG to care about. If the document should continue to use an algorithm contradicting RFC 8085,= I think Appendix B should be in the document. I have not read Appendix A. An algorithm like the one mentioned in Appendix= A IMHO requires comprehensive simulation and empirical evaluation to ensur= e it is robust in all possible corner cases. This may be a topic e.g. for I= CCRG. In my option, either evidence should be included or referenced in the= document, or the Appendix A should be removed. It seems to me that Appendi= x A could be moved to another draft without impacting the rest of this docu= ment. Major issues: - Abstract: The abstract does not explain well the actual content of the do= cument. For instance, it does not mention that an RTO algorithm is describe= d in the document. - Abstract: The abstract should mention that the document is informational. - Section 3: I think the area of applicability should be better explained. = As far as I can see, the document focuses on low-bandwidth and high-latency= links. This is probably a relevant application scenario for CoAP. However,= I wonder if the mechanism would be equally well applicable to other transp= orts built for constrained network, see e.g. the "IoT" work in 4G/5G. I am = not sure if they have the same delay characteristics. Also, the document se= ems to assume later "naturally lossy networks"; this is not generally true = in the Internet. All in all, it really would make sense to explicitly spell= out for what environments the algorithms have been designed. - Section 4: Somewhat related, I think at the beginning of Section 4 a bett= er description is needed for the design rationale of the algorithms, e.g., = on underlying assumptions on the absolute values of delays. The current dra= ft basically presents an algorithm without much discussion on the design ch= oices, and whether alternatives would exist. For instance, I believe that t= he document implicitly assumes that delays/RTT can be larger than 1s. Such = assumptions should be spelt out.=20 - Section 4, Section 4.2, and Section 4.2.2: Indeed, BCP RFC 8085 defines "= Latency samples MUST NOT be derived from ambiguous transactions." As far as= I understand, this document explicitly violates the IETF concensus on RFC = 8085. Whether this is acceptable from a process perspective probably needs = IESG discussion. From a formal perspective, at minimum, I would expect this= deviation to be mentioned very explicitly in the introduction and at the b= eginning of Section 4. I'll comment below on some technical aspects. - Section 4.2 and in particular 4.2.1: This document should use a terminolg= y like "differences to the algorithm in RFC 6298". Using the term "modifica= tion" is confusing. This (informational) document does not *modify* RFC 629= 8 or the algorithms therein. Minor issues: - I find the title "CoAP Simple Congestion Control/Advanced" confusing. To= me the terms "simple" and "adanced" don't fit together very well. If the o= bjective is to use the acronym "CoCoA", this could be better explained, e.g= ., in the abstract. - Section 1: I think "(See Abstract.)" should be replaced by actual text. A= s mentioned separately, IMHO the abstract does not well describe the docume= nt neither. - Section 1 and 2: I would avoid that a long-lasting document refers to "mi= nutes of the IEFT 84 CoRE WG meetings". I think a document should be reason= ably self-contained, in particular in the introduction. I also think that s= ome content of Section 2 would well fit into the introduction. But this may= be a personal preference of me. - Section 3: As already mentioned, if "aggregate congestion control (Append= ix A) is not yet supported by research", I wonder why not to move this to a= separate document and publish that other document once there is research. = In any case, the term "cloud side" in that paragraph is not well defined an= d the use case assumed here is not clear to me. - Section 4: "This is based on the usual algorithms for RTO estimation [RFC= 6298]". RFC 6298 describes the standardized TCP algorithm; I think "usual" = is not a precise characterization as some TCP stacks may not exactly follow= RFC 6298. - Section 4: "One important consideration not relevant for TCP is the fact = that a CoAP round-trip may include application processing time". If the doc= ument wants to compare to TCP, it may be worthwile here to discuss the TCP = delayed acks. - Section 4.2 (and follow-up): I don't think the use of the weak estimator = is well motivated. The document does not give a good explanation why using = ambiguous samples is really useful, except for the observation that there h= ave been some (small?) benefits in some studies, without looking into root = causes. For instance, the weak estimator can be significantly larger than t= he actual network delay. Why does it make sense to increase the RTO way bey= ond the actual network delay in that case? Wouldn't this impact the deliver= y delay if a follow-up packet gets lost, and thus degrade the application p= erformance more than needed? In what network scenarios does using ambiguous= samples really help? And why does it even make sense to calculate the vari= ance of a sample that is ambiguous? Unfortunately, there is no single set o= f delay and loss characteristics in the Internet that a performance study c= ould use. Therefore, arguments on functional properties of an algorithm (e.= g., in simple example scenarios) would be quite helpful. - Section 4.2 (and follow-ups): I don't think the document addresses well h= ow close or far away the estimates of the strong and weak estimator can be = to each other. For instance, in a network without much congestion, would th= e weak estimator get updated if the latency in the network changes? How doe= s the Aging according to Section 4.3 tie in in that case? Based on the docu= ment it is difficult to understand how the various different algorithms wit= h conditional statements finally react altogether, and whether they are saf= e in all corner cases. It may be simpler to present the complete algorithms= as a sequence of processing steps. Alternatively or in addition, some exam= ples for simple scenarios could help to better understand what the algorith= ms would converge to (e.g., one example with rather low RTT samples and one= with rather large ones). Such examples may not be mandatory in an RFC, but= this would really be nice-to-have, IMHO. - Section 4.2: If we assume that the weak estimator is used (see my other c= omments), it seems that a sender would *either* use (1) or (2), right? If s= o, this could be better spelt out. - Section 4.2.1: "For RTO estimations below 1 s, the RTO for a retransmiss= ion is multiplied by 3, while for estimations above 3 s, the RTO is multip= lied only by 1.5 (this updated choice of numbers to be verified by more si= mulations)". Will the document be updated with results from more simulation= s prior to WGLC? - Section 4.2.2 "In contrast to [RFC6298], this algorithm attempts to make = use of ambiguous information from retransmissions. This is motivated by th= e high non-congestion loss rates expected in constrained node networks, an= d the need to update the RTO estimators even in the presence of loss." I be= lieve this assumption does not generally apply to all network technologies.= Several technologies have ARQ or FEC mechanisms below IP to make the rate = of non-congestion loss extremely small. I think this should be discussed. I= t would be worthwile to expand on what benefits (if any) the weak estimator= might have in networks without non-congestion loss. - Section 4.2.2: "However, those samples are not simply combined into the s= trong estimator, but are used to correct the limited knowledge that can be = gained from the strong RTT measurements by employing an additional weak est= imator." If there is benefit, it would be useful to add an example that exp= lains that "limited knowledge" and why such a correction could be useful. - Section 7: Security considerations seem to be missing. I wonder about the= scenario that an attacker only has temporary access to the network path. B= y causing some packets to be dropped, can he increase the RTOs in a large n= umber of senders for a relatively long time, thus degrading the performance= significantly? Thanks Michael ________________________________________ From: tcpm on behalf of Jaime Jim=E9nez Sent: Wednesday, April 12, 2017 14:35 To: core@ietf.org WG Cc: tcpm@ietf.org; iccrg@ietf.org; michawe@ifi.uio.no Subject: [tcpm] Heads up on the upcoming WGLC for COCOA Hi CoRE WG, this is just a heads up for the upcoming WGLC for "CoAP Simple Congestion C= ontrol/Advanced=94. https://tools.ietf.org/html/draft-ietf-core-cocoa-01 Note that there is still some discussion about whether to keep the appendix= es or not, and that there is time to get other comments before WGLC. This document has been presented multiple times and I=92d like to progress = with it soon, it=92d be great to have it by Prague. To ICCRG, as you now already, this was presented quite some time ago, below= is the links to the session and the slides. Session: https://www.ietf.org/proceedings/92/iccrg.html Presentation: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-2.= pdf Between the two sessions the main difference is the addition of the appendi= xes: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-01.txt Ciao! - - Jaime Jim=E9nez From nobody Mon Apr 24 00:15:24 2017 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 79747128BBB for ; Mon, 24 Apr 2017 00:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4rkF_JxT7oI for ; Mon, 24 Apr 2017 00:15:21 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8589128990 for ; Mon, 24 Apr 2017 00:15:20 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud2.xs4all.net with ESMTP id C7FJ1v0091ThUbc017FJF5; Mon, 24 Apr 2017 09:15:19 +0200 Received: from 2001:983:a264:1:dd30:5122:7cc7:ee67 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 24 Apr 2017 09:15:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 24 Apr 2017 09:15:18 +0200 From: peter van der Stok To: Michel Veillette Cc: Carsten Bormann , peter van der Stok , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org> <091EF847-AD5E-40D8-B04C-CDBDA47023F1@tzi.org> <8ff54501447ab9e681ecfbee04652fb3@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] content-formats for cbor YANG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 07:15:23 -0000 Michel, See your point. Will change the text accordingly. I hope that yang-cbor content-format will be defined in yang-cbor draft. Peter Michel Veillette schreef op 2017-04-21 17:49: > Hi Peter > > About "payload of an array of one item can be optimized to just one > item" > > I agree with Carsten, I most cases, this rule have the potential to > create ambiguities. > In the specific case of a notification, the payload can be either a > CBOR map (single notification) or a CBOR array (multiple > notifications). > A single Content-Format (e.g. yang-value+cbor) will work but a > solution with two Content-Format seem to be cleaner. > > Regards, > Michel > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Friday, April 21, 2017 5:01 AM > To: peter van der Stok > Cc: Michel Veillette ; Core > > Subject: Re: [core] content-formats for cbor YANG > > On Apr 21, 2017, at 09:18, peter van der Stok > wrote: >> >> Because the CoMI text now says that the payload of an array of one >> item can be optimized to just one item, I like to suppress the >> yang-value+cbor and only retain the yang-values+cbor > > That would create an ambiguity if a value can ever be an array. > > What is so bad about the media type being very specific about what the > payload is? > > Grüße, Carsten From nobody Mon Apr 24 01:39:03 2017 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 A6F6A129B98; Mon, 24 Apr 2017 01:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=gKwe+m5j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EVYMpd44 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU6Sesu-c-Pe; Mon, 24 Apr 2017 01:39:00 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FA1129B9D; Mon, 24 Apr 2017 01:38:55 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 98A1F20D60; Mon, 24 Apr 2017 04:38:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Mon, 24 Apr 2017 04:38:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=tGeaXlYWF146o9HqpV qqSevO3bVvvAWOBVj/U1JffAY=; b=gKwe+m5jY3K3mLUKmVHYGeqoxKMD92cN3x x3QyLRb/YOCGuL2bCiNSyNajPnJ4TmPikHj1l+M9As3AJdVANRONTOzB6sg54uLF sCQafMduiKU0M48TzVtwf8XoGbEJcvHSKo/+n3LnAaoZDN3Ip0hZJ9kkgaowxZ00 d90cLhR7NkMbI+fKdIgt9TkYxfIgL+DQ+fhSFpem3/wTZzcrT2dEogL/m/q2FyQs 9ArTu0x35VS3Kv+KDGukjFv4dkd8X2P9jze7+UvPkvZ9yOATEHgZdkco3Vj5D81B SqvZF4KUAAN8d+Gr67mqIk9pMb107h3UKOVmTvxQWpyaJfDPBlBg== 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=tGeaXlYWF146o9HqpVqqSevO3bVvvAWOBVj/U1JffAY=; b=EVYMpd44 EYzzLcp15WU1yiMbZJPzI1tWouqoVdHD6kvsF6XNbQeqavq7ta6aWVi/lJEyIoyI kssPJT+LU8MNyH4i2erMJjTXuSbFzMbb2MKF+CyiUNkgMYPqyevgWVv92EX3ojcK wlJ4XPiLKGTP/jGuX/o7uLwUrqJe4j5ZUes4+ghue3AaRh6v85CdGgw6NGBORDQU q/MsVdbnT3gnuHsIqN3jeY4D5W+T5OO73Hzz37Oa+k13XG3VwTK0OC7LY78LBP9i gCv3wqyW7cvgnffSkDKlZK637ynMV5CDauziHYracS/USvtGTnByw4CYnaDgDg9T Qn4LtHf3+CbTUA== X-ME-Sender: X-Sasl-enc: wbOeArWVfCgAtPot8Vyzhmydq1aGQRrfEGlISEk0K+C2 1493023134 Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 53D31246CA; Mon, 24 Apr 2017 04:38:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Mon, 24 Apr 2017 10:00:12 +0100 Cc: core-chairs@ietf.org, draft-ietf-core-links-json@ietf.org, The IESG , core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C6A2BAA-F0FB-4E4B-BB33-95F69615B62D@fastmail.fm> References: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> To: Carsten Bormann , Adam Roach Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 08:39:02 -0000 Carsten and Adam, > On 22 Apr 2017, at 09:32, Carsten Bormann wrote: >=20 > Interesting. > Julian Reschke reminds me that this is repaired in draft-nottingham-rfc598= 8bis-05.txt: >=20 > 3. Link Serialisation in HTTP Headers >=20 > The Link header field provides a means for serialising one or more > links into HTTP headers. >=20 > The ABNF for the field value is: >=20 > Link =3D #link-value > link-value =3D "<" URI-Reference ">" *( OWS ";" OWS link-param ) > link-param =3D token BWS "=3D" BWS ( token / quoted-string ) >=20 > Note that any "link-param" can be generated with values using either > the "token" or the "quoted-string" syntax, and therefore recipients > MUST be able to parse both forms. Individual "link-param"s specify > their syntax in terms of the value after any necessary unquoting (as > per [RFC7230], Section 3.2.6). I think this document should recognize this change and just reference draft-= nottingham-rfc5988bis normatively. (I will be AD sponsoring it shortly anywa= y.) Adam, will this address this concern > Unfortunately, this doesn=E2=80=99t retroactively fix RFC 6690, which stil= l has restrictive ABNF for rt, if, title, anchor. Hmm. Well, we just have to special case them. The list of special attributes is f= ixed. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Apr 22, 2017, at 10:03, Carsten Bormann wrote: >>=20 >> Hi Adam, >>=20 >> thank you very much for this deep review. >> This will allow us to improve the document a lot. >>=20 >> Let me pick one issue here that I think goes beyond the details of links-= json. >>=20 >>> Let's say some future document defined a link relation ("smellslike") >>> that included a parameter with ABNF syntax like: >>>=20 >>> "smellsys" "=3D" quoted-string >>=20 >> My knee-jerk reaction is =E2=80=9Cthen don=E2=80=99t do that=E2=80=9D. >>=20 >> But the more fundamental problem is that RFC 5988 actually defines a data= model and its serialization without ever saying so. Any reasonably defined= link parameter will either have a syntax that is limited to ptoken or allow= both ptoken and quoted-string serialization. >> The fact that we then use ABNF to define the link parameter syntax obscur= es that property and allows the above deviation. We already made the mistak= e for [anchor, title, rt, if] (see MUSTBEQUOTED in the reference implementat= ion). There is no need to make it again, but the use of ABNF for what shou= ld be a data model definition does make it too easy to shoot ourselves in th= e foot. >>=20 >> Note that the above issue hits any implementation that wants to generate R= FC 5988 syntax, not just one that converts links-json into RFC 5988 syntax. >>=20 >> So my takeaway summary is that links-json only works for reasonably defin= ed link parameters (after grandfathering in anchor, title, rt, if) and proba= bly should say so much more explicitly. But I don=E2=80=99t know how to fix= RFC 5988 about this issue. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >=20 From nobody Mon Apr 24 01:42:38 2017 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 47AA7129BCB; Mon, 24 Apr 2017 01:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 vafp8gVv2v0K; Mon, 24 Apr 2017 01:42:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F06129BC5; Mon, 24 Apr 2017 01:42:33 -0700 (PDT) X-AuditID: c1b4fb3a-9397998000006079-f5-58fdba78d43d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id FC.44.24697.87ABDF85; Mon, 24 Apr 2017 10:42:32 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 24 Apr 2017 10:40:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CvRx+AAn7lIpqb0LCu37abF+dIALtjI91mz8spDg7Fw=; b=byU+Qdqb8OXRkmFWbzE6e49DuC8APjcOjtV+EsSTmhDYEZ3AA9H4CpAyGE70BfdvWgJIMxW3HFXkxQYaVNbDsnCSo2D68OskU30sVs3IKF89UDl1uPZfd82dZnPtg8Fz8nmYSCqHfend69ftrtLO29wZI7nHANrgaMVM7F4QJcE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 24 Apr 2017 08:40:02 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0%15]) with mapi id 15.01.1061.005; Mon, 24 Apr 2017 08:40:01 +0000 From: Ingemar Johansson S To: "draft-ietf-core-cocoa@ietf.org" CC: "core@ietf.org" Thread-Topic: Comments on draft-ietf-core-cocoa-01 Thread-Index: AdK8z3LR0c5hIrgsQH2Pq7HrYTEu8Q== Date: Mon, 24 Apr 2017 08:40:00 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.95] x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:/FWeEfmSWnz898L6NXHo6T9ksqVjmpntCks8in3MnBRbN1Co34dFJVicYRcXFbdo/FS1bCDxEHy2AsI42cbX6jGvqvmYJLqhSIHR/779UZ7Raq5kUHT+txGmFw/whdx82jVokc0DJhxjMcfcW6/ERt3luucn7W+iIUZ0xDlQfSkl5kdBVnzj/figZK3IagRTvr58Tgs6XebPFDlNSmgwOR5B35tmAF5J7xWZLMTp5oImnnnj830G1Vih9fRkmvJJej8JnFO4F2rCFikLAEkrgBJlu4OytPlbjU6KuPbEeWvN4gs/ZYUhp59NFLYUH7FaQsaekRR5S5Vkld5F1sLvOQ== x-ms-office365-filtering-correlation-id: 516b52b9-93ba-4e93-7b86-08d48aed7f5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB347; x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39400400002)(39410400002)(39450400003)(39840400002)(51884002)(450100002)(606005)(66066001)(4326008)(6436002)(5640700003)(6506006)(110136004)(50986999)(6916009)(38730400002)(33656002)(2900100001)(230783001)(19609705001)(53936002)(5660300001)(54356999)(25786009)(7736002)(102836003)(189998001)(3846002)(86362001)(790700001)(236005)(3280700002)(55016002)(7906003)(8936002)(9686003)(99286003)(5250100002)(6116002)(9326002)(81166006)(2351001)(54896002)(5630700001)(7696004)(6306002)(74316002)(2906002)(3660700001)(8676002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348621F25BDE07FCCFB53ADC21F0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 08:40:00.3432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2K7qG7Frr8RBk9OiVrse7ue2WLm3kWM DkweS5b8ZApgjOKySUnNySxLLdK3S+DKuNjpXPCrjbFiyp9vbA2MT0q7GDk5JARMJO6efcHW xcjFISSwnlHi4cRORpCEkMAJRokn271AEiwCvcwSN/fOYIKomsYk8W/1NnYI5yGjxONbPawg LWwCNhIrD30HaxcRcJWYd+0MWJxZQFni+OzDQDYHh7CArsSlmVkQJUYSl1s/skHYehJ9/7vA WlkEVCU2LJsK1sorECXxp+U5O4jNKCArcf/7PRaIkeISt57MZ4J4QUBiyZ7zzBC2qMTLx/9Y QW5jFOhmlPgw7xpUkYJE54E3YB9ICHQzSzTdfgKV8JXYf3wtC8hxEgK1Ek3LbCHCmRJrP22D KomWmHKsiw2i9zyTxJ+911khEjISMy+0M0LY11klHh0QBbGFBaQk7l6BhKMwUM2LO3uhAZEv MeX2EhaIzwQlTs58wjKBUW0WkodmISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUX MLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAhMOge3/LbawXjwueMhRgEORiUe3gfKfyOE WBPLiitzDzFKcDArifB2rwAK8aYkVlalFuXHF5XmpBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1 ILUIJsvEwSnVwBi5fm7gch/uP2z7/wQ57tr4he/xtIPTGPT2RObsYbv4hXeDjvS7zSpx8lM3 566VOeaiwpmhaf1BJ91AIsx2ppB8yJGKZ9oPElv5j85+4P3D4rhLiNvUUD5WEa1irjmFDKIz 9lz7oHLQTvdV98vwT7MlGmKFymK3t7pfDvugHDAnKeH2Pg+jEiWW4oxEQy3mouJEAIl94Uo2 AwAA Archived-At: Subject: [core] Comments on draft-ietf-core-cocoa-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 08:42:36 -0000 --_000_DB4PR07MB348621F25BDE07FCCFB53ADC21F0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I read through draft-ietf-core-cocoa-01, and unfortunately I am not convinc= ed that the draft its yet ready for WGLC. In general it could be good if you can get the help from a native English s= peaking person to work on the text. The end result would be a more crisp te= xt, in some cases you should even be able to remove large amounts of text, = in other cases more text will likely be added. That said.. I am definitely not worthy of throwing the first stone here, I = have my own problems with the English language. A few more detailed comments, please see them as a suggested way to improve= the document, writing RFCs that describe algorithms is a pain.. Section 1 refers to two other drafts that are expired since a few years bac= k. Isn't it better to make this draft more self- contained ?. It would of c= ourse mean that the draft becomes bigger. Section 2 looks to me that something that belongs to section 1. There is so= me terminology like for instance "non-confirmable", I assume that the expla= nation is given in RFC7252 or one of the other CORE RFCs (sorry don't follo= w CORE) Section 3 "Aggregate Congestion Control (Appendix A) is not yet supported b= y research as well as the other algorithms in this specification". Ambiguo= us text. Section 4 "Note that such a mechanism must, during idle periods, decay RTO estimates that are shorter or longer than the basic RTO estimate back to the basic RTO estimate, until fresh measurements become available again, as proposed in Section 4.3." Unclear to me what this means. I don't know how the discussion has been ear= lier but one question that comes to my mind is.. Would it be possible to ad= d pseudo code here and then explain the pseudo code ?. "to avoid expending all of its retransmissions" : Is this limitation defin= ed?, in which draft/RFC ? Section 4.2 Difficult to follow. Some pseudo code would help here, I believe. For examp= le, the 1st para is very compressed. "RTO :=3D 0.25 * E_weak_ + 0.75 * RTO (1)" The equation numbers should be moved further to the right to avoid confusio= n. In addition, I am here left wondering if these two equations are run in = sequence, reading the text I get the impression that it is not the case ?. Section 4.2.1 "If an RTO estimation is lower than 1 s or higher than 3 s, instead of applying a binary backoff factor in both cases, a variable backoff factor is used. For RTO estimations below 1 s, the RTO for a retransmission is multiplied by 3, while for estimations above 3 s, the RTO is multiplied only by 1.5 (this updated choice of numbers to be verified by more simulations). This helps to avoid that exchanges with small initial RTOs use up all retransmissions in a short interval of time and exchanges with large initial RTOs may not be able to carry out all retransmissions within MAX_TRANSMIT_WAIT (93 s)" I would believe that it is better to describe the problem first and then th= e fix. Section 4.3 "very strongly RECOMMENDED". Not sure that this will pass the IESG last cal= l. Sounds like a "SHOULD" or "MUST" "RTO :=3D 1 s + (0.5 * RTO)" the 's' confuses the reader. It should be s= ufficient to state that the unit of the RTO estimate is [s] Section 5 "The confirmable messages must be sent under an RTO estimator, as specified in Section 4." I am not sure I understand what this means. Section 5.1 "This is relatively conservative. " Missing text ?. Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348621F25BDE07FCCFB53ADC21F0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I read through draft-ietf-core-cocoa-01, and unfortu= nately I am not convinced that the draft its yet ready for WGLC.

 

In general it could be good if you can get the help = from a native English speaking person to work on the text. The end result w= ould be a more crisp text, in some cases you should even be able to remove = large amounts of text, in other cases more text will likely be added.

That said.. I am definitely not worthy of throwing t= he first stone here, I have my own problems with the English language.

 

A few more detailed comments, please see them as a s= uggested way to improve the document, writing RFCs that describe algorithms= is a pain..

 

Section 1 refers to two other drafts that are expire= d since a few years back. Isn’t it better to make this draft more sel= f- contained ?. It would of course mean that the draft becomes bigger.=

Section 2 looks to me that something that belongs to= section 1. There is some terminology like for instance “non-confirma= ble”, I assume that the explanation is given in RFC7252 or one of the= other CORE RFCs (sorry don’t follow CORE)

Section 3 “Aggregate Congestion Control (Appen= dix A) is not yet supported by  research as well as the other algorith= ms in this specification”. Ambiguous text.

 

Section 4

“Note that such a

   mechanism must, during idle periods, de= cay RTO estimates that are

   shorter or longer than the basic RTO es= timate back to the basic RTO

   estimate, until fresh measurements beco= me available again, as

   proposed in Section 4.3.”

Unclear to me what this means. I don’t know ho= w the discussion has been earlier but one question that comes to my mind is= .. Would it be possible to add pseudo code here and then explain the pseudo= code ?.

“to avoid expending all of  its retransmi= ssions” : Is this limitation defined?, in which draft/RFC ?

 

Section 4.2

Difficult to follow. Some pseudo code would help her= e, I believe. For example, the 1st para is very compressed.=

“RTO :=3D 0.25 * E= _weak_ + 0.75 * RTO (1)”

The equation numbers should be moved further to the = right to avoid confusion. In addition, I am here left wondering if these tw= o equations are run in sequence, reading the text I get the impression that= it is not the case ?.

 

Section 4.2.1

“If an RTO estimation is lower than 1 s or hig= her than 3 s, instead of

   applying a binary backoff factor in bot= h cases, a variable backoff

   factor is used.  For RTO estimatio= ns below 1 s, the RTO for a

   retransmission is multiplied by 3, whil= e for estimations above 3 s,

   the RTO is multiplied only by 1.5 (this= updated choice of numbers to

   be verified by more simulations). = This helps to avoid that exchanges

   with small initial RTOs use up all retr= ansmissions in a short

   interval of time and exchanges with lar= ge initial RTOs may not be

   able to carry out all retransmissions w= ithin MAX_TRANSMIT_WAIT

   (93 s)”

I would believe that it is better to describe the pr= oblem first and then the fix.

 

Section 4.3

“very strongly RECOMMENDED&#=
8221;. Not sure that this will pass the IESG last call. Sounds like a ̶=
0;SHOULD” or “MUST”
“RTO :=3D 1 s + (0.5 * RTO)”    the ‘s’ confuses the reader. It sh=
ould be sufficient to state that the unit of the RTO estimate is [s]
 
Section 5
“The confirmable messages must be s=
ent under an RTO estimator, as
       specified in Section=
 4.”
I am not sure I understand what this means.
Section 5.1
“This is relatively conservative. <=
/span>” Missing text ?.=

 
 

Regards

Ingemar

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

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348621F25BDE07FCCFB53ADC21F0DB4PR07MB348eurprd_-- From nobody Mon Apr 24 03:06:10 2017 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 B899B12EC13; Mon, 24 Apr 2017 03:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dho2VUhYH-8b; Mon, 24 Apr 2017 03:06:07 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (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 2863612EBCF; Mon, 24 Apr 2017 02:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mGRZQ2Pk6IP6/9wtfPWMjnHXt+PJWC1dFb1mTGStjFk=; b=Ra+sR9NwwL+hjijG0dKrBk683O tNqK1vd/2imcrl0ojS7kbmSqjNjVMK1k3RIdDvFw7o76V1/MMAqLII9SrUP5UxLV9Ny5R9NhYzN+q Gi2+3nXRbPhARqNkVCBB9Rb80bri1CrGm2xVzN6VWFo4MMvjv1syfckrldjPPZt1VQd0r0M4Tfmci caQ7AKpBkS+SrKg+Mn1fEni2WFdtCMA9raNB+shgtzMLdJ77L4lrj6saBjG+TlY8gVO6qICW4HISv pWOoPFK8OImqdF6Mm6RjSK8n6cV1iG35XrKtZDqpAmJmP8gNIZ9d1BXNmQA737Vf/uykUJP7UJOJt 08k3+wRg==; Received: from 201.116.77.83.dynamic.wline.res.cust.swisscom.ch ([83.77.116.201]:55969 helo=dretbook.home) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2amA-0000GX-9t; Mon, 24 Apr 2017 05:59:22 -0400 To: Herbert Van de Sompel , Carsten Bormann References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> Cc: ietf@ietf.org, art@ietf.org, draft-ietf-core-links-json.all@ietf.org, Mark Nottingham , "core@ietf.org WG" From: Erik Wilde Message-ID: Date: Mon, 24 Apr 2017 10:49:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:06:09 -0000 hello. just adding my voice here and since i am collaborating with herbert on this, my position is relatively clear. On 2017-04-18 14:47, Herbert Van de Sompel wrote: > 2. Regarding Mark's comment "This means that any constraints upon > RFC6690 documents are also > mirrored into these formats": Mark mentions IRIs as a concern. I am also > concerned about the rules for interpretation of (the Context IRI of) > links as described in Section 2.1 of 6690 > (https://tools.ietf.org/html/rfc6690#section-2.1). It seems to me that > these also introduce constraints that go beyond 5988. I may be mistaken > with that regard because I have never fully understood that section of > 6690 (i.e. the use of "base URI", "origin", "Context URI"). But, when > compared to 5988, the section comes across as imposing constraints that > are intended to allow the straightforward use of relative URIs in > constrained environments as a means to decrease the payload. If my > interpretation is correct, then I would very much favor spec-ing the > json link format in terms of 5988 rather than 6690. very much agreed, it would be great to have a generic way of serializing links as standalone resources (ideally in a way that is able to preserve their context, so that relative URIs are well-defined). my concern is that RFC 6690 was not intended to do this (it adds constraints to RFC 5988), and thus draft-ietf-core-links-json has the same limitations. to be fair, the draft does not intend to define a general-purpose web link serialization, it is simply intended as a serialization of the specialized model defined in RFC 6690. i am not sure what the best way forward is. the representations defined in this draft are tantalizingly close to general-purpose serializations of RFC 5988. but the draft is clearly intended to be (one more) building block in the "CoRE-only" universe. two suggestions: - add language that makes it clear that because of the limitations of RFC 6690, the media types in this draft should not be considered as general-purpose serializations of web links. - consider adding a serialization of web links to RFC 5988bis. this would address the problem of how to serialize web links outside of the HTTP link header field. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Apr 24 04:53:22 2017 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 9EFF612EBC7; Mon, 24 Apr 2017 04:53:09 -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 3-_A0SSi7VOd; Mon, 24 Apr 2017 04:53:08 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D70E127B73; Mon, 24 Apr 2017 04:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OBqHMr003090; Mon, 24 Apr 2017 13:52:17 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBPpS6GrhzDHJ4; Mon, 24 Apr 2017 13:52:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 24 Apr 2017 13:52:15 +0200 Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514727535.684329-be5ad1644b45dde245ba178c864264fa Content-Transfer-Encoding: quoted-printable Message-Id: <027F2C41-E498-4801-86E2-047771E10545@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> To: Erik Wilde X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 11:53:10 -0000 On Apr 24, 2017, at 10:49, Erik Wilde wrote: >=20 > - consider adding a serialization of web links to RFC 5988bis. this = would address the problem of how to serialize web links outside of the = HTTP link header field. Sounds good to me. What needs to be done to make sure links-json is a proper subset of = this? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 24 05:48:44 2017 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 891BA13150F; Mon, 24 Apr 2017 05:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-LpXFH2X_aM; Mon, 24 Apr 2017 05:48:28 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (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 A7C1D131504; Mon, 24 Apr 2017 05:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UC9sWWxKH1eqF2oU21h1VeiNoG4Wqp4yaF7IlyCwuds=; b=ammD7eky36yaO3MZBCm/PYIoXe OXvTk/bIAizfuJX+U9fje4wwZ44IkbN6T4GLktDoq+XQLCk056oBlpMWzM44h1CXp0UANOkcx8D+f 5Drcwi9xvJTaPEdkZNR47vsyJUi7YUw3LtdcqNYeXlRuJqQJnQKnmW32RWhomkrK1NTNYJGlNdwnO aC/iWAlYpxUJTTWAmtJoh8wT88NJofaaoFgQ0KtdKeos2JDJmaGfoBKagUCXzvfAuGHJeD2LF7gSr tTCD8okTDxQtLaHGzAqctuwh3MpI8v1menCmadCB7qXXaB0ag8wd2MqnOEj9D9cz2G92H/NjawinG 0Fm4Np4w==; Received: from 201.116.77.83.dynamic.wline.res.cust.swisscom.ch ([83.77.116.201]:55922 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2dPn-0003r7-Np; Mon, 24 Apr 2017 08:48:27 -0400 To: Carsten Bormann References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org From: Erik Wilde Message-ID: <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> Date: Mon, 24 Apr 2017 14:48:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <027F2C41-E498-4801-86E2-047771E10545@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 12:48:30 -0000 On 2017-04-24 13:52, Carsten Bormann wrote: > On Apr 24, 2017, at 10:49, Erik Wilde wrote: >> - consider adding a serialization of web links to RFC 5988bis. this would address the problem of how to serialize web links outside of the HTTP link header field. > Sounds good to me. > What needs to be done to make sure links-json is a proper subset of this? hard to tell as "this" is just speculation at this point. generally speaking, i don't think it's such a great idea to piggyback on standards and then reduce their expressiveness. imho that's one of the well-known anti-patterns of interop: (extended) subsets. but if you're shooting for a subset i think that's where you are right now. it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Apr 24 05:57:00 2017 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 DF137128959; Mon, 24 Apr 2017 05:56:50 -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 7vQKb_6jzFps; Mon, 24 Apr 2017 05:56:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B40E131448; Mon, 24 Apr 2017 05:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OCtv8U024072; Mon, 24 Apr 2017 14:55:57 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBRCx27SHzDHKw; Mon, 24 Apr 2017 14:55:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> Date: Mon, 24 Apr 2017 14:55:56 +0200 Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514731356.639242-36f7ee4bca0d5a83208bda5fa5f40929 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> To: Erik Wilde X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 12:56:51 -0000 On Apr 24, 2017, at 14:48, Erik Wilde wrote: >=20 > On 2017-04-24 13:52, Carsten Bormann wrote: >> On Apr 24, 2017, at 10:49, Erik Wilde wrote: >>> - consider adding a serialization of web links to RFC 5988bis. this = would address the problem of how to serialize web links outside of the = HTTP link header field. >> Sounds good to me. >> What needs to be done to make sure links-json is a proper subset of = this? >=20 > hard to tell as "this" is just speculation at this point. generally = speaking, i don't think it's such a great idea to piggyback on standards = and then reduce their expressiveness. imho that's one of the well-known = anti-patterns of interop: (extended) subsets. >=20 > but if you're shooting for a subset i think that's where you are right = now. >=20 > it would be better to make sure that serializations of web links = actually can represent web links and not just some of the information = that they convey. that train may have left the station with RFC 6690, = but maybe for the JSON and CBOR serializations that can be changed. Right. Can you be more specific what you would want to see here? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 24 09:02:15 2017 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 96B1313179E; Mon, 24 Apr 2017 09:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up57oHRjcV50; Mon, 24 Apr 2017 09:02:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 056141317A4; Mon, 24 Apr 2017 09:01:56 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3OG1r3m036065 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Apr 2017 11:01:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Alexey Melnikov , Carsten Bormann Cc: core-chairs@ietf.org, draft-ietf-core-links-json@ietf.org, The IESG , core@ietf.org References: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> <4C6A2BAA-F0FB-4E4B-BB33-95F69615B62D@fastmail.fm> From: Adam Roach Message-ID: Date: Mon, 24 Apr 2017 11:01:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <4C6A2BAA-F0FB-4E4B-BB33-95F69615B62D@fastmail.fm> Content-Type: multipart/alternative; boundary="------------AFA9ED5F45542E07A46EE7EA" Content-Language: en-US Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:02:14 -0000 This is a multi-part message in MIME format. --------------AFA9ED5F45542E07A46EE7EA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/24/17 04:00, Alexey Melnikov wrote: > I think this document should recognize this change and just reference draft-nottingham-rfc5988bis normatively. (I will be AD sponsoring it shortly anyway.) Adam, will this address this concern I think citing 5988bis is definitely called for, but not sufficient to solve this issue. The thing that actually prevents the situation I describe from occurring is that 5988bis will prevent new link relation parameters of type quoted-string (only) from being defined, and my read of 6690 is that the syntax of CoAP link relations will mirror those of 5988bis link relations, so I'm far less concerned about the future-proofness of this protocol. In terms of the issue at hand, I think this document really needs to have English prose that captures the logic in the Ruby script (since the script is non-normative). My reading is that these rules are: * Always include quotes for the known special cases (anchor, title, rt, and if). * For other parameters, omit quotes if the value is composed entirely of token characters * Include quotes otherwise This necessarily requires some description of how to take the JSON/CBOR format and convert it to HTTP/CoAP format, but that's something I think the document really needs anyway. /a --------------AFA9ED5F45542E07A46EE7EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 4/24/17 04:00, Alexey Melnikov wrote:
I think this document should recognize this change and just reference draft-nottingham-rfc5988bis normatively. (I will be AD sponsoring it shortly anyway.) Adam, will this address this concern


I think citing 5988bis is definitely called for, but not sufficient to solve this issue. The thing that actually prevents the situation I describe from occurring is that 5988bis will prevent new link relation parameters of type quoted-string (only) from being defined, and my read of 6690 is that the syntax of CoAP link relations will mirror those of 5988bis link relations, so I'm far less concerned about the future-proofness of this protocol.

In terms of the issue at hand, I think this document really needs to have English prose that captures the logic in the Ruby script (since the script is non-normative).

My reading is that these rules are:

  • Always include quotes for the known special cases (anchor, title, rt, and if).
  • For other parameters, omit quotes if the value is composed entirely of token characters
  • Include quotes otherwise

This necessarily requires some description of how to take the JSON/CBOR format and convert it to HTTP/CoAP format, but that's something I think the document really needs anyway.

/a

--------------AFA9ED5F45542E07A46EE7EA-- From nobody Mon Apr 24 09:18:04 2017 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 455111317CC; Mon, 24 Apr 2017 09:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=nHnE7gs2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SYN16YZD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms2izRytG4ge; Mon, 24 Apr 2017 09:17:58 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F409E1294F9; Mon, 24 Apr 2017 09:17:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6D73420BFB; Mon, 24 Apr 2017 12:17:57 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 24 Apr 2017 12:17:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=kbCI0qzS2wfpGQkQ9HkxVriDfWc2f pemHE3+/2RO3vo=; b=nHnE7gs2HddN3ssktfoATdvS9vgPt1wtUDHBNBCO+wdDh RaJrJRHDzsYYvaEkkIiPPZyDZp24QsNhUFXRuxWKWh8p79rnuwus5TdmbC7zkF2k c/mTvFq6A0IIFt3V7TNG+sM3vnVKwkH1vAX8+mIZDq9BzG86Fu/qvp/DAH9oq7QZ egbwVi5iDH5YYQBoTfJwvyCPXyDTgRNhCOpCVR/Uk+a7IjybhcZw2DWhHtqn19kd N0KMJGq9NDAQZ1hi0W/NN6VvtjE1ASouGjzd0xcavlTyFtg0fLXUKKvaBWsuKozF oBr1OohprM0N8+3I4dxqF79HbCKBB2Xgw1+OZKlog== 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kbCI0q zS2wfpGQkQ9HkxVriDfWc2fpemHE3+/2RO3vo=; b=SYN16YZD7pl6jFkZ208U/x GxUWNI2Etu5QiI8ZtxNsOVv7+O++3s9ySmgfWu/yDh62OiSmJOeCvPq/sh0MI+Yx w2vmbU8cj/1O6WZzycIskL02oFe8wNpzcLZyfFh4eQveHJE/QBGphcvkj60OMqqI Cj2/9mMtUaV1aSE4nCMGUue/6f9BO1YSaK9+UimJUZBQobEVXvonj4r0yWKxM/Fc gAcFcODcYEDLLQmisd26TYjeBHApGKjuFJN7sTf0NmzsxIWDXt67/QHccsulFpOB WrPngEMUvZ1Rn+pWXAS9GT7iVZWfHjPvZ9XaUkOdpPucTBNj+dDnwL/TJDKaF1Qw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 480719E215; Mon, 24 Apr 2017 12:17:57 -0400 (EDT) Message-Id: <1493050677.1359056.954507592.7A70FF7C@webmail.messagingengine.com> From: Alexey Melnikov To: Adam Roach , Carsten Bormann Cc: core-chairs@ietf.org, draft-ietf-core-links-json@ietf.org, The IESG , core@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149305067713590560" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29d47332 References: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> <4C6A2BAA-F0FB-4E4B-BB33-95F69615B62D@fastmail.fm> Date: Mon, 24 Apr 2017 17:17:57 +0100 In-Reply-To: Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:18:00 -0000 This is a multi-part message in MIME format. --_----------=_149305067713590560 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Adam, On Mon, Apr 24, 2017, at 05:01 PM, Adam Roach wrote: > On 4/24/17 04:00, Alexey Melnikov wrote: >> I think this document should recognize this change and just reference >> draft-nottingham-rfc5988bis normatively. (I will be AD sponsoring it >> shortly anyway.) Adam, will this address this concern> I think citing 5988bis is definitely called for, Let's at least do this. > but not sufficient to solve this issue. The thing that actually > prevents the situation I describe from occurring is that 5988bis will > prevent new link relation parameters of type quoted-string (only) from > being defined, and my read of 6690 is that the syntax of CoAP link > relations will mirror those of 5988bis link relations, so I'm far less > concerned about the future-proofness of this protocol.So other than the currently defined parameters (in rfc5988bis or RFC 6690), this situation will not occur, right? > In terms of the issue at hand, I think this document really needs to > have English prose that captures the logic in the Ruby script (since > the script is non-normative).Ok. > My reading is that these rules are: > * Always include quotes for the known special cases (anchor, title, > rt, and if). > * For other parameters, omit quotes if the value is composed entirely > of token characters > * Include quotes otherwiseSeems sensible. > This necessarily requires some description of how to take the > JSON/CBOR format and convert it to HTTP/CoAP format, but that's > something I think the document really needs anyway.Agreed. --_----------=_149305067713590560 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Adam,

On Mon, Apr 24, 2017, at 05:01 PM, Adam Roach wrote:
On 4/24/17 04:00, Alexey Melnikov wrote:
I think this document should recognize this change and just reference draft-nottingham-rfc5988bis normatively. (I will be AD sponsoring it shortly anyway.) Adam, will this address this concern

I think citing 5988bis is definitely called for,

Let's at least do this.

but not sufficient to solve this issue. The thing that actually prevents the situation I describe from occurring is that 5988bis will prevent new link relation parameters of type quoted-string (only) from being defined, and my read of 6690 is that the syntax of CoAP link relations will mirror those of 5988bis link relations, so I'm far less concerned about the future-proofness of this protocol.
So other than the currently defined parameters (in rfc5988bis or RFC 6690), this situation will not occur, right?

In terms of the issue at hand, I think this document really needs to have English prose that captures the logic in the Ruby script (since the script is non-normative).

Ok.

My reading is that these rules are:

  • Always include quotes for the known special cases (anchor, title, rt, and if).
  • For other parameters, omit quotes if the value is composed entirely of token characters
  • Include quotes otherwise
Seems sensible.

This necessarily requires some description of how to take the JSON/CBOR format and convert it to HTTP/CoAP format, but that's something I think the document really needs anyway.

Agreed.

--_----------=_149305067713590560-- From nobody Mon Apr 24 09:20:10 2017 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 73F481317DB; Mon, 24 Apr 2017 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKucH45d2QEl; Mon, 24 Apr 2017 09:20:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 937631317DC; Mon, 24 Apr 2017 09:20:05 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3OGK1er037610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Apr 2017 11:20:02 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Alexey Melnikov , Carsten Bormann Cc: core-chairs@ietf.org, draft-ietf-core-links-json@ietf.org, The IESG , core@ietf.org References: <149281630600.25862.8449227995136793167.idtracker@ietfa.amsl.com> <4C6A2BAA-F0FB-4E4B-BB33-95F69615B62D@fastmail.fm> <1493050677.1359056.954507592.7A70FF7C@webmail.messagingengine.com> From: Adam Roach Message-ID: <2872189b-61dc-9a08-e453-18bc4f5c800e@nostrum.com> Date: Mon, 24 Apr 2017 11:19:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <1493050677.1359056.954507592.7A70FF7C@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:20:08 -0000 On 4/24/17 11:17, Alexey Melnikov wrote: > Hi Adam, > > On Mon, Apr 24, 2017, at 05:01 PM, Adam Roach wrote: >> On 4/24/17 04:00, Alexey Melnikov wrote: >>> I think this document should recognize this change and just reference draft-nottingham-rfc5988bis normatively. (I will be AD sponsoring it shortly anyway.) Adam, will this address this concern >> >> I think citing 5988bis is definitely called for, >> > Let's at least do this. > >> but not sufficient to solve this issue. The thing that actually >> prevents the situation I describe from occurring is that 5988bis will >> prevent new link relation parameters of type quoted-string (only) >> from being defined, and my read of 6690 is that the syntax of CoAP >> link relations will mirror those of 5988bis link relations, so I'm >> far less concerned about the future-proofness of this protocol. > So other than the currently defined parameters (in rfc5988bis or RFC > 6690), this situation will not occur, right? As far as I can tell, that is true. /a From nobody Mon Apr 24 09:29:50 2017 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 C0579131817 for ; Mon, 24 Apr 2017 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 DBsj3TmXgkjX for ; Mon, 24 Apr 2017 09:29:47 -0700 (PDT) Received: from mail4.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 0274D131806 for ; Mon, 24 Apr 2017 09:29:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493051385; h=from:subject:to:date:message-id; bh=KgibsSomxFHbMCZq9P/1whZcGfT0JSubUdXe/7zny0A=; b=KwwJSJAb4T4xFaDlHnlJw06TUAlbrg+gWJSMYP6KgrM1Zc6AyHceHoTFm9wf8Br856bPG3XxzG2 iLxo8lWDvHgf1rt0/2VtHVW2s2LT+8vcFbs6WdIqJdb2+Q6bmoYq/GLqSnRaJxc+PghIoXVvqvE6D e2v4oHmYPCWAMHrx0Wdpjmrf+xEdq18WStADjEPgxuFhx2FN0/mrkt03fi3vbageu5oA7Ihfmslc3 FB0RQQwi7Z9DbP/mNAwcbQK3RKprxRdu7TqhiLTfLqr68dzMukKkxzNjB3zczrYZC0DK9G26s3MWq fTp9ylaSEvPKeWXBPFU5jBQVMc6MmQt4ka5g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 09:29:44 -0700 Received: from Hebrews (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 09:29:35 -0700 From: Jim Schaad To: 'Core' Date: Mon, 24 Apr 2017 09:19:17 -0700 Message-ID: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdK9FTTNQqIDQxwSSBijDQvXYALUWA== X-Originating-IP: [192.168.1.157] Archived-At: Subject: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:29:49 -0000 I have been sketching out what my TCP/UDP and UDP/TCP proxy code would look like and I am having a problem deciding what should be done for the observe option. If you have the case of Client->UDP->Proxy->UDP->Server, then dealing with out of order observations can be dealt with in the following ways: 1. Pass them through unchanged or subtract a constant from the observer value. This pushes the problem of out of order observes onto the client. The proxy would save the high water content. 2. Filter on observe value so that out of order transmissions are suppressed. 3. Keep out of order items around for a while and see if the out of order items show up and transmit them back as in order. I missing items do not show up until the time out, then suppress the out of order items. 4. Reorder the numbers so that things are seen in the wrong order by the client. (Obviously a wrong answer.) I assumed that 1 was the correct answer and deal with things that way. Now I come to the question of Client->TCP->Proxy->UDP->Server. Since the observe value is now to be ignored or removed, the first option above will no longer work and I am not sure which the remaining options is the correct one to do. Does a reliable transmission protocol mean that we should suppress items? Jim From nobody Mon Apr 24 09:51:09 2017 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 32127128792 for ; Mon, 24 Apr 2017 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 VqrjIr8fEEKp for ; Mon, 24 Apr 2017 09:51:06 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA4513180D for ; Mon, 24 Apr 2017 09:45:39 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 194so14914291pfv.3 for ; Mon, 24 Apr 2017 09:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hhK+X/OBr/pdnu+oqWud7ZXfOpt7NMxfSgdbiEjTz70=; b=j+6pc/E1260MTp2xIp5cKVnfDom7jpLnLdOaqgrde5JN4WDwls4uqatQG/b8oc8bOI D6BPSQIXrZ4gCD2kxVk943ioMKDYoGkCbU4gIPjenbcZmb+ekNDOULiG67J+puUzfSmX 1TwCjCbKX3yrG6stZI7mRHOgng6iHCSQkYkVfeZyUSGei73yEShsRcRv/N8HbxHHqG+K uIEEkskNMeKVAvV9w0ebAVXs7qomao3KLd28iQ7YY6VM6ot56qFkP+bDBe/5GLKC5Yvt /OlfU17JHvOOpMHecJjmKwzPxDZl25xCM9WH7/GmP69am2E7njaoiYhEDiS2oskXbJ4F ++zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hhK+X/OBr/pdnu+oqWud7ZXfOpt7NMxfSgdbiEjTz70=; b=smNmPdfG7BmjrtMW5IKitKt0EwN+qC8vfx6D7lSJVpJCoHTvwGXRzQIkaqUZQiynfK Ulrk5R72ssNRblMhjiijF4sZnryKfHgHvBVVAHxkzk9ZTflhvu3xKua7RZHTZXD9zeUX 0VlySDIjFqIFnixap/QjLhn4+XEDqhTvaupVI3oiLAvd1vlmdCz7JEjJqeFd1zMOWpKd R0QjiJrJ2UE5BUE1pt1lDJRie00pzRbGigQtRclqHQDoDT3KHtJx/T3CbjNAjkyZPLJc ysf9FOiCCY8BqLvqiJtYtMA/DY0Y39wfi/prBRfWPy4gNk7qOF/uVS6l+S4Ds7Iy5K1I 0REw== X-Gm-Message-State: AN3rC/6jaDmp+u0Ua5OhslQZIfTJeI1oWb6ei/uwghWAh2TMLdKQAn2d G6DeG5ZyqL2YJg== X-Received: by 10.99.113.10 with SMTP id m10mr5050001pgc.49.1493052339230; Mon, 24 Apr 2017 09:45:39 -0700 (PDT) Received: from ?IPv6:2620::1000:1512:7874:3c:6eb5:4d8c? ([2620:0:1000:1512:7874:3c:6eb5:4d8c]) by smtp.gmail.com with ESMTPSA id x68sm31857731pgx.57.2017.04.24.09.45.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 09:45:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Robert Quattlebaum In-Reply-To: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> Date: Mon, 24 Apr 2017 09:45:37 -0700 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:51:08 -0000 > On Apr 24, 2017, at 9:19 AM, Jim Schaad = wrote: > Now I come to the question of Client->TCP->Proxy->UDP->Server. Since = the > observe value is now to be ignored or removed, the first option above = will > no longer work and I am not sure which the remaining options is the = correct > one to do. Does a reliable transmission protocol mean that we should > suppress items? According to the data model that observe is based on, out-of-order = observe response packets are considered to be out-of-date and thus = should be ignored. Proxies must be aware of outstanding observations and = keep track of the observe counters to make sure that out-of-order = packets are dropped. I'm not super happy about the mechanism, but that = seems to be what the standard has settled on. Passing everything through = and letting the client sort it out is explicitly not allowed. -- RQ > On Apr 24, 2017, at 9:19 AM, Jim Schaad = wrote: >=20 > I have been sketching out what my TCP/UDP and UDP/TCP proxy code would = look > like and I am having a problem deciding what should be done for the = observe > option. >=20 > If you have the case of Client->UDP->Proxy->UDP->Server, then dealing = with > out of order observations can be dealt with in the following ways: >=20 > 1. Pass them through unchanged or subtract a constant from the = observer > value. This pushes the problem of out of order observes onto the = client. > The proxy would save the high water content. > 2. Filter on observe value so that out of order transmissions are > suppressed. > 3. Keep out of order items around for a while and see if the out of = order > items show up and transmit them back as in order. I missing items do = not > show up until the time out, then suppress the out of order items. > 4. Reorder the numbers so that things are seen in the wrong order by = the > client. (Obviously a wrong answer.) >=20 > I assumed that 1 was the correct answer and deal with things that way. >=20 > Now I come to the question of Client->TCP->Proxy->UDP->Server. Since = the > observe value is now to be ignored or removed, the first option above = will > no longer work and I am not sure which the remaining options is the = correct > one to do. Does a reliable transmission protocol mean that we should > suppress items? >=20 > Jim >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Apr 24 09:54:34 2017 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 3CEE2131868 for ; Mon, 24 Apr 2017 09:54:33 -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 ST_dTYhgBykb for ; Mon, 24 Apr 2017 09:54:31 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3797A131860 for ; Mon, 24 Apr 2017 09:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OGsKiF005400; Mon, 24 Apr 2017 18:54:20 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBXW05pYxzDHRX; Mon, 24 Apr 2017 18:54:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 24 Apr 2017 18:54:20 +0200 Cc: Jim Schaad , core X-Mao-Original-Outgoing-Id: 514745660.239078-fea13864eab63e548809f95a4af9885e Content-Transfer-Encoding: quoted-printable Message-Id: <98FA9C4F-0E41-4BC0-B297-19A2DC9C888C@tzi.org> References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> To: Robert Quattlebaum X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:54:33 -0000 On Apr 24, 2017, at 18:45, Robert Quattlebaum = wrote: >=20 > According to the data model that observe is based on, out-of-order = observe response packets are considered to be out-of-date and thus = should be ignored. Right, Observe gives you eventual consistency, where data that is not = fresh is not of interest. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 24 10:01:18 2017 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 A45CF131881 for ; Mon, 24 Apr 2017 10:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTxwn-hTrx01 for ; Mon, 24 Apr 2017 10:01:16 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370E1131880 for ; Mon, 24 Apr 2017 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OH1DIP011531 for ; Mon, 24 Apr 2017 19:01:13 +0200 (CEST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBXfw65YmzDHRh for ; Mon, 24 Apr 2017 19:01:12 +0200 (CEST) Received: by mail-io0-f174.google.com with SMTP id k87so199849831ioi.0 for ; Mon, 24 Apr 2017 10:01:12 -0700 (PDT) X-Gm-Message-State: AN3rC/7pHDkeAqxSIRbv2N72qhSNn8/g4jbjx8zfbTng7SPARVJno/xR oWEabO/HyAzQiZyku+BL0jRpd72Qrg== X-Received: by 10.107.20.199 with SMTP id 190mr8192392iou.81.1493053271608; Mon, 24 Apr 2017 10:01:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.163.87 with HTTP; Mon, 24 Apr 2017 10:00:31 -0700 (PDT) In-Reply-To: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> From: Klaus Hartke Date: Mon, 24 Apr 2017 19:00:31 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: Core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:01:18 -0000 Jim Schaad wrote: > 1. Pass them through unchanged or subtract a constant from the observer > value. This pushes the problem of out of order observes onto the client. > The proxy would save the high water content. The sequence numbers in notifications are not end-to-end; they are only meaningful between each pair of hops; each hop has to generate its own sequence numbers [1]. It might be possible for a hop to generate sequence numbers based on the values it receives, but my head hurts when thinking about temporal sequence numbers, so I wouldn't recommend it. > 2. Filter on observe value so that out of order transmissions are > suppressed. > 3. Keep out of order items around for a while and see if the out of order > items show up and transmit them back as in order. I missing items do not > show up until the time out, then suppress the out of order items. >From Section 1.3 [2]: o It follows a best-effort approach for sending the current representation to the client after a state change: clients should see the new state after a state change as soon as possible, and they should see as many states as possible. So, depending on whether you optimize for "as soon as possible" or "as many as possible", you should do 2 or 3. I would recommend 2. This applies equally to reliable and unreliable transports. Klaus [1] https://tools.ietf.org/html/rfc7641#section-5 [2] https://tools.ietf.org/html/rfc7641#section-1.3 From nobody Mon Apr 24 10:36:56 2017 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 CFF6F128616 for ; Mon, 24 Apr 2017 10:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 5gGPqMFwe-vY for ; Mon, 24 Apr 2017 10:36:51 -0700 (PDT) Received: from mail4.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 EB4FD1318E2 for ; Mon, 24 Apr 2017 10:36:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493055409; h=from:subject:to:date:message-id; bh=AXP5Ic1n1BQVqrcmzhXLsFcsqE4262P3Var3Db+k3VA=; b=Bv/rge19YSWeDXe0hl06DyiyB6diREbEm27UKdqAMl4UR3fn143LiMboCtQhVq9Ltb5ik/H1XR4 4E4Rb1hh4jmTg6qKVqV8qnk1jF2nlAbkMHPKmBMqGayhfOKP3xxX66mlTOn0QvwE2/x55qlRD01q6 xMPeCySp3PWAAsgdiaPGti/EQK/LKEfTX99eGZmTuZZrzX8FHoQ8Jg/iZXikkXNTJzQ3g6WpHCUXN C8a6MUCg+FpF8fFjC9v0OkaorItAbbix/uQZCGwh6j0oR6Yez4AsD74JvgevMQfeJ4IliLExusdJx 7Ba6tjKnDpG+Q7+NbtnRnOi2vX4stP2ISiMw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 10:36:48 -0700 Received: from Hebrews (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 10:36:39 -0700 From: Jim Schaad To: 'Robert Quattlebaum' CC: 'core' References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> In-Reply-To: Date: Mon, 24 Apr 2017 10:26:22 -0700 Message-ID: <000201d2bd1f$e5eac590$b1c050b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJeukh32Gal94+LtNk1k0eLwH8yRgId6sjxoKvbFeA= X-Originating-IP: [192.168.1.157] Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:36:55 -0000 -----Original Message----- From: Robert Quattlebaum [mailto:darconeous@gmail.com] Sent: Monday, April 24, 2017 9:46 AM To: Jim Schaad Cc: core Subject: Re: [core] TCP, UDP, Proxy and Observe > On Apr 24, 2017, at 9:19 AM, Jim Schaad wrote: > Now I come to the question of Client->TCP->Proxy->UDP->Server. Since > the observe value is now to be ignored or removed, the first option > above will no longer work and I am not sure which the remaining > options is the correct one to do. Does a reliable transmission > protocol mean that we should suppress items? According to the data model that observe is based on, out-of-order observe response packets are considered to be out-of-date and thus should be ignored. Proxies must be aware of outstanding observations and keep track of the observe counters to make sure that out-of-order packets are dropped. I'm not super happy about the mechanism, but that seems to be what the standard has settled on. Passing everything through and letting the client sort it out is explicitly not allowed. [JLS] I cannot quite see that as being a true statement. It is true that the most reason transmission must be considered the freshest, however a client may want a more complete history of values than just the most recent one and can deal with a non-freshest value. For example, if it is a controller and is doing projections based on the current set of values, having the "stale" value is still useful information even if it is not the freshest. I do not see anything in RFC 7641 that says that out of order packets are dropped by an intermediary. Are you saying this just based on the fact that it is not freshest? Jim -- RQ > On Apr 24, 2017, at 9:19 AM, Jim Schaad wrote: > > I have been sketching out what my TCP/UDP and UDP/TCP proxy code would > look like and I am having a problem deciding what should be done for > the observe option. > > If you have the case of Client->UDP->Proxy->UDP->Server, then dealing > with out of order observations can be dealt with in the following ways: > > 1. Pass them through unchanged or subtract a constant from the > observer value. This pushes the problem of out of order observes onto the client. > The proxy would save the high water content. > 2. Filter on observe value so that out of order transmissions are > suppressed. > 3. Keep out of order items around for a while and see if the out of > order items show up and transmit them back as in order. I missing > items do not show up until the time out, then suppress the out of order items. > 4. Reorder the numbers so that things are seen in the wrong order by > the client. (Obviously a wrong answer.) > > I assumed that 1 was the correct answer and deal with things that way. > > Now I come to the question of Client->TCP->Proxy->UDP->Server. Since > the observe value is now to be ignored or removed, the first option > above will no longer work and I am not sure which the remaining > options is the correct one to do. Does a reliable transmission > protocol mean that we should suppress items? > > Jim > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Apr 24 10:39:58 2017 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 5D28C1318ED for ; Mon, 24 Apr 2017 10:39:56 -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 1CmBBBurJ__6 for ; Mon, 24 Apr 2017 10:39:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238191318F4 for ; Mon, 24 Apr 2017 10:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OHdiCs009852; Mon, 24 Apr 2017 19:39:44 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBYWM689DzDHRv; Mon, 24 Apr 2017 19:39:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <000201d2bd1f$e5eac590$b1c050b0$@augustcellars.com> Date: Mon, 24 Apr 2017 19:39:42 +0200 Cc: Robert Quattlebaum , core X-Mao-Original-Outgoing-Id: 514748382.326747-b641ea4e6533fbd861ff69b2cfd638d3 Content-Transfer-Encoding: quoted-printable Message-Id: <44EEBD22-51EB-40A0-AFE4-443C8E06FBDE@tzi.org> References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> <000201d2bd1f$e5eac590$b1c050b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:39:56 -0000 On Apr 24, 2017, at 19:26, Jim Schaad wrote: >=20 > I do not see anything in RFC 7641 that says that out of order > packets are dropped by an intermediary. Are you saying this just = based on > the fact that it is not freshest? While there may be many kinds of proxy, the standard caching proxy will = only put fresh data into the cache, and only those would lead to = notifications. Observing a resource may not be the best model if you want to keep an = uninterrupted time series of the value of the resource. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 24 10:54:22 2017 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 8FCED131523 for ; Mon, 24 Apr 2017 10:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zyXtIGlaA5N4 for ; Mon, 24 Apr 2017 10:54:10 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80C01318FE for ; Mon, 24 Apr 2017 10:54:09 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 72so16593620pge.2 for ; Mon, 24 Apr 2017 10:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9hLzqk2x1a33JKbTG+l45x97FV8LzkH5IpUx7+hWWFw=; b=sYNaNfjZgm5f8ENnvmgM0ExZ9l73sgz9qStYHcLKbz+MbZI1Tjf5FUMIKj0aHO3SmY 5xfHp9x5mqTo4PE6VwjbpC4L93tbqbH+hafkdW9y8g+ApAdiOpWO0RSY1aXGuN5Ss9Ae ZRDdGVwgS5TtPCHo9l+3tDeeiZtsEz1Ln3sDs1kouOd07pekzgYroFHx5S6h9On57HCd y5jbaOO01xj1LKcmEOgkc1b48csZt/BpOVLGBoBKEoAbNrd7iZMNi+VmVbXHvWb8l2O/ Xe+wTddxJthrlVktBtZ1fa8zXup8uGLEE5DdjreWuHxuh+2TquDUlRgS8gfiAdGg/jA9 flrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9hLzqk2x1a33JKbTG+l45x97FV8LzkH5IpUx7+hWWFw=; b=G6jhrqZX5Tcns8xVH0BrjtBMMG38MDKx+1KcFUYIaIkSZV3AJypFMhyd9TuPqmKLWE YViOt2cO1DBU6uq8vxpz7MpnrodC+Azd51GnnFdQB8AhTlcs54GxsD2ylKFSkdNcYddT Gs0gXNQCGQCIvvp3c+f2+dLp/DONfh5sSYliXPtAS/SKFPTdMc6iWIBL9+GNvx6BBnOL RgUiOc+uoRrsurR4jBsM3SFLSu6GaatchRCPP7KXExyxU8IKmcbrqRGtMNsIjKS+MzuW Om9kOYXBOlbAmm8pYSC/MGOk0gMfS4DAhfhSG4V/rH+3IlhLNzTG/UGvDaUTrmfqZVHb xEvg== X-Gm-Message-State: AN3rC/66i+ASAnSiAET6VFv7sIs69vEW8i4yMLGOG7UN+Jws2bq+NHah epwtHTAJUFU0Kw== X-Received: by 10.84.143.129 with SMTP id 1mr6712947plz.105.1493056449458; Mon, 24 Apr 2017 10:54:09 -0700 (PDT) Received: from ?IPv6:2620::1000:1512:7874:3c:6eb5:4d8c? ([2620:0:1000:1512:7874:3c:6eb5:4d8c]) by smtp.gmail.com with ESMTPSA id v128sm32105104pgb.20.2017.04.24.10.54.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 10:54:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Robert Quattlebaum In-Reply-To: <000201d2bd1f$e5eac590$b1c050b0$@augustcellars.com> Date: Mon, 24 Apr 2017 10:54:07 -0700 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: <09D621A0-FAA5-4124-97CF-F82D23E86E4B@gmail.com> References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> <000201d2bd1f$e5eac590$b1c050b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:54:21 -0000 Hello Jim, Comments inline below: >> According to the data model that observe is based on, out-of-order = observe >> response packets are considered to be out-of-date and thus should be >> ignored. Proxies must be aware of outstanding observations and keep = track of >> the observe counters to make sure that out-of-order packets are = dropped. I'm >> not super happy about the mechanism, but that seems to be what the = standard >> has settled on. Passing everything through and letting the client = sort it >> out is explicitly not allowed. >>=20 > [JLS] I cannot quite see that as being a true statement. It is true = that > the most reason transmission must be considered the freshest, however = a > client may want a more complete history of values than just the most = recent > one and can deal with a non-freshest value. For example, if it is a > controller and is doing projections based on the current set of = values, > having the "stale" value is still useful information even if it is not = the > freshest. I do not see anything in RFC 7641 that says that out of = order > packets are dropped by an intermediary. Are you saying this just = based on > the fact that it is not freshest? The dropping behavior is implied by two things: * RFC7641 Section 5 says that proxies must track and renumber observe = sessions * draft-ietf-core-coap-tcp-tls-07 requires the observing endpoint to = ignore the numeric value of the Observe header (because it is assumed to = always be increasing). I think the most reasonable way to reconcile these requirements is that = an intermediary proxy MUST drop out-of-order observations. You could = argue that such logic only applies when proxying to TLS/TCP/WebSockets, = but I think the intent is for this behavior to be required independent = of the raw transport. I'm not saying that I like it or that I think that this is how it should = have be, I'm just saying what the current documentation appears to = require and what will likely be standardized. -- RQ >=20 > Jim >=20 >=20 > -- RQ >=20 >> On Apr 24, 2017, at 9:19 AM, Jim Schaad = wrote: >>=20 >> I have been sketching out what my TCP/UDP and UDP/TCP proxy code = would=20 >> look like and I am having a problem deciding what should be done for=20= >> the observe option. >>=20 >> If you have the case of Client->UDP->Proxy->UDP->Server, then dealing=20= >> with out of order observations can be dealt with in the following = ways: >>=20 >> 1. Pass them through unchanged or subtract a constant from the=20 >> observer value. This pushes the problem of out of order observes = onto the > client. >> The proxy would save the high water content. >> 2. Filter on observe value so that out of order transmissions are=20 >> suppressed. >> 3. Keep out of order items around for a while and see if the out of=20= >> order items show up and transmit them back as in order. I missing=20 >> items do not show up until the time out, then suppress the out of = order > items. >> 4. Reorder the numbers so that things are seen in the wrong order by=20= >> the client. (Obviously a wrong answer.) >>=20 >> I assumed that 1 was the correct answer and deal with things that = way. >>=20 >> Now I come to the question of Client->TCP->Proxy->UDP->Server. Since=20= >> the observe value is now to be ignored or removed, the first option=20= >> above will no longer work and I am not sure which the remaining=20 >> options is the correct one to do. Does a reliable transmission=20 >> protocol mean that we should suppress items? >>=20 >> Jim >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 >=20 From nobody Mon Apr 24 10:57:36 2017 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 CE84C1293F4 for ; Mon, 24 Apr 2017 10:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 r2eudDCf3Val for ; Mon, 24 Apr 2017 10:57:34 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBB6127978 for ; Mon, 24 Apr 2017 10:57:34 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id 63so5982301pgh.0 for ; Mon, 24 Apr 2017 10:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=wxlaTpwrwbQqN5LBLZrgo7UaJ1F3xfOuESm+bgsaY1Q=; b=BA/CJymv4ayyvX46jQpmzep91GJZIR3CA9yDvcFyne/cgltI0Aud7gPOl/N63dMYA3 H3NjiXCXHBu00gIkHWuJhvCqTrZsD1JCJA6sTDb7OIQmY64Zsyf48UbKqrW55+UEiX5w ET3NiIuPYRt2AWOfDuv95+OJ9loE9q/qJHIbAm5Ws1VRgsDl9XaZ3AD9eyxMbsfXBcwf IJBT9RwrP8wiygulO9imkt9Y77agxBjS/APoQuNp11r8bc+Gd+3igwH3FPkt/n3ARKm8 sehHUyyF+fAxLW663y+wccK9E6PHG7khIrtgpOjy0gNo+qNvpTD86tzcOANcZgT2xhXu G93g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wxlaTpwrwbQqN5LBLZrgo7UaJ1F3xfOuESm+bgsaY1Q=; b=orhsb50ihzLTsYvsWQEufBom505gmuUoLhLcMI0ePlgs/Zdjq+rRKhPhZNlF/BAFxn 9VUhGIbU/bf4o0/+yIWQYZ3Ef0urmj8kdPN7lvZcPVmsZRx5TtsZZtpnw0beuTafn9qI bqdFX/xa8VPodvadek0k3n9Y8ylYJS7Loo8pSTkM+S7pK/VfW9J44jVT1RSQKdHCXuan o1qXfpF61DhXBjgTmwMluiM5G3FxXaWytQIXrnFh+LNPdY7PqyKZhysBgzNwn/PXIlid MG9Rdqw7zX9OIc+VSB3ctbLxCwSSkajbsPuTeltOob5SJO5M+vVDkEqpvnx+noS8hcPQ tv3Q== X-Gm-Message-State: AN3rC/5RmwyTF6bXAInoSvzXI7IFLoZZ1YmofkPDmM8dsha4IXeDg7NE tjFEjk/sL6S6BQ== X-Received: by 10.84.160.226 with SMTP id v31mr34950494plg.122.1493056653838; Mon, 24 Apr 2017 10:57:33 -0700 (PDT) Received: from ?IPv6:2620::1000:1512:7874:3c:6eb5:4d8c? ([2620:0:1000:1512:7874:3c:6eb5:4d8c]) by smtp.gmail.com with ESMTPSA id z5sm32089710pfd.76.2017.04.24.10.57.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 10:57:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D8EDE9BD-2F85-45B9-8BF6-8A53919770B8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Robert Quattlebaum In-Reply-To: <44EEBD22-51EB-40A0-AFE4-443C8E06FBDE@tzi.org> Date: Mon, 24 Apr 2017 10:57:32 -0700 Cc: Jim Schaad , core Message-Id: References: <017601d2bd16$873ce1d0$95b6a570$@augustcellars.com> <000201d2bd1f$e5eac590$b1c050b0$@augustcellars.com> <44EEBD22-51EB-40A0-AFE4-443C8E06FBDE@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] TCP, UDP, Proxy and Observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:57:36 -0000 --Apple-Mail=_D8EDE9BD-2F85-45B9-8BF6-8A53919770B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Even a non-caching proxy will have to drop out-of-order observations if = it proxies across UDP and TLS. There is pretty much only one correct = behavior in that case, considering that there is no way to preserve the = observe counter across a draft-ietf-core-coap-tcp-tls-07-style stream. > On Apr 24, 2017, at 10:39 AM, Carsten Bormann wrote: >=20 > On Apr 24, 2017, at 19:26, Jim Schaad wrote: >>=20 >> I do not see anything in RFC 7641 that says that out of order >> packets are dropped by an intermediary. Are you saying this just = based on >> the fact that it is not freshest? >=20 > While there may be many kinds of proxy, the standard caching proxy = will only put fresh data into the cache, and only those would lead to = notifications. >=20 > Observing a resource may not be the best model if you want to keep an = uninterrupted time series of the value of the resource. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --Apple-Mail=_D8EDE9BD-2F85-45B9-8BF6-8A53919770B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Even a non-caching proxy will have to drop out-of-order = observations if it proxies across UDP and TLS. There is pretty much only = one correct behavior in that case, considering that there is no way to = preserve the observe counter across a draft-ietf-core-coap-tcp-tls-07-style stream.

On Apr 24, 2017, at 10:39 AM, Carsten Bormann <cabo@tzi.org> = wrote:

On Apr 24, 2017, at 19:26, Jim Schaad <ietf@augustcellars.com> wrote:

I do not see anything in RFC = 7641 that says that out of order
packets are dropped by an = intermediary.  Are you saying this just based on
the = fact that it is not freshest?

While there may be many kinds of proxy, the standard caching = proxy will only put fresh data into the cache, and only those would lead = to notifications.

Observing a resource may = not be the best model if you want to keep an uninterrupted time series = of the value of the resource.

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


= --Apple-Mail=_D8EDE9BD-2F85-45B9-8BF6-8A53919770B8-- From nobody Tue Apr 25 05:36:00 2017 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 6B72C12EC88; Tue, 25 Apr 2017 05:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-qJLzjJYjvS; Tue, 25 Apr 2017 05:35:57 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (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 4780A12EC85; Tue, 25 Apr 2017 05:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zSyfr+bpXj8QAvL2HVJqpDCw/VifG4EMu3P5i8hEDMo=; b=xQlkMleb/tu1ALgiOrSEnFpOsr 9Dtqigqv7Z4hn6MlPZgbCikNn6T/6ZvSUaDhRCo3EC3jYdSdtog0l8BIp37M/0BpaN8wfXqqDRQ2u LdM1jk5pAadGPP8W5423qvHoEYRbj4fTBPbvRnrdljnK2GQpfPJQVP2M/B/s4pEBt4vMbfrNYmWGh bZB3WxJyejzEbTvVyKktj6lCcrSrquFyHfeE7hnTZkLMsnRCkvkfGUAXklQ4S5WsvpK71VePBtnfw rOxQgQwpMo8jLzJfJ4qRlncsfD1S6QFt20R56ivXUHPA84rnucKiYZpFFUOdpuajF8+2+ajTOt6zu n2Cu8wRw==; Received: from [141.202.54.2] (port=64523 helo=dretpro.local) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2zhD-0007F1-Pv; Tue, 25 Apr 2017 08:35:55 -0400 To: Carsten Bormann References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org From: Erik Wilde Message-ID: Date: Tue, 25 Apr 2017 14:35:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:35:58 -0000 hello carsten. On 2017-04-24 14:55, Carsten Bormann wrote: >> it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed. > Right. Can you be more specific what you would want to see here? two possibilities: - to do things well it would be better to have web link serializations that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take a while. - for the RFC 6690-based variants under consideration right now, it would be helpful to very explicitly point out that they are *not* general-purpose serializations of web links, but instead inherit the limitations of the underlying spec. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue Apr 25 05:50:20 2017 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 3944112EC9D; Tue, 25 Apr 2017 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KroGHSiWTdXU; Tue, 25 Apr 2017 05:50:16 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F78712ECA4; Tue, 25 Apr 2017 05:50:16 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id h123so57648861qke.0; Tue, 25 Apr 2017 05:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5qvgovgsEj6145CjlgdjBcvQgNAGxSCzrRrXNZNl+yg=; b=en4ZqxTx6HwDtZVJrXKaZqAZL4rgwCF0hZBzFNG+TWy/Q5H7/tJJk6gdbzXQtgF+0k ZPSH/pbfpN0OP7BZIiaH25NIo6foeaacz/iTmF27FydcDWcbyqvcPX/+was8rLiz9oGc HfEVMsyAojmV97Y+nBI6POpk/vZdZhDBOcoNnMtr/tYpdp1oonBowGGGyLzXqGFAaXbm +YWvLjXyy/hPTUzEeU6FbUyTMLfoKjF5GxP5JNFf4cCWAQfAgRwALHqVjDjqrJFu+4k3 Ph0oD0rwr5J1hoatEVsl/jPg/yFYqZzmO0iAen8Q0tD+tyt8IOyKtI+LAhOiUNh+FUxs GKGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5qvgovgsEj6145CjlgdjBcvQgNAGxSCzrRrXNZNl+yg=; b=jrjg3YbimVAV3YV7dGyRY9AABPfyTBoTngHW2s3Euz44iuA+HFEmGUV6lyv5QyePld si7S7Wo1IwLg8SYaQG2yTDM0vTmKo1roZLRaX0uXoXsRhierG5UlKgmgDbLFHlexBpXZ 8gGYXViREtKT34S3AxUE9WBsZ+kBPN1QTX8uxon++sDjo0zhzUPeOn45WjuQ2qMGYnAY 1aMRnIG8zpbZJJ5vBO9vIq6IPhqsJPrz7OBIZUuP503urM2jfEqfkwVDo2gAezKogJ7G itjJAR3rMgMYWe5miKcLtE7i8w8fmdQjMJ9h0zyrFIeWD+WfWDAe2SgP1XbayxnUEQLp oGIA== X-Gm-Message-State: AN3rC/6uA1gBQZSGOuTwFLeXuTywCV78IrBSdmqMC7wi4gSIdnx/zszS JO9/CpXP/YXeldEnm8alZkBqjRse/Q== X-Received: by 10.55.41.74 with SMTP id p71mr11448557qkh.110.1493124615856; Tue, 25 Apr 2017 05:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.45.162 with HTTP; Tue, 25 Apr 2017 05:50:15 -0700 (PDT) In-Reply-To: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> From: Herbert Van de Sompel Date: Tue, 25 Apr 2017 14:50:15 +0200 Message-ID: To: Erik Wilde Cc: Carsten Bormann , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org, Herbert Van de Sompel Content-Type: multipart/alternative; boundary=001a1147acdc557ada054dfd2adc Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:50:18 -0000 --001a1147acdc557ada054dfd2adc Content-Type: text/plain; charset=UTF-8 On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde wrote: > hello carsten. > > On 2017-04-24 14:55, Carsten Bormann wrote: > >> it would be better to make sure that serializations of web links actually >>> can represent web links and not just some of the information that they >>> convey. that train may have left the station with RFC 6690, but maybe for >>> the JSON and CBOR serializations that can be changed. >>> >> Right. Can you be more specific what you would want to see here? >> > > two possibilities: > > - to do things well it would be better to have web link serializations > that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take > a while. > > As Erik previously indicated, it would be great if this could be done as part of RFC5988bis. > - for the RFC 6690-based variants under consideration right now, it would > be helpful to very explicitly point out that they are *not* general-purpose > serializations of web links, but instead inherit the limitations of the > underlying spec. > > That would, indeed, be good. But, in case RFC5988bis would spec a (JSON) serialization, it seems to me that it would be rather helpful for the CORE community if the RFC 6690 JSON serialization would be based on it. Cheers herbert > > cheers, > > dret. > > -- > erik wilde | mailto:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | > -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126 == --001a1147acdc557ada054dfd2adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 25, 2017 at 2:35 PM, Erik Wilde <erik.wilde@dret.net> wrote:
hello carst= en.

On 2017-04-24 14:55, Carsten Bormann wrote:
it would be better to make sure that serializations of web links actually c= an represent web links and not just some of the information that they conve= y. that train may have left the station with RFC 6690, but maybe for the JS= ON and CBOR serializations that can be changed.
Right.=C2=A0 Can you be more specific what you would want to see here?

 two possibilities:

- to do things well it would be better to have web link serializations that= cover *all* of RFC 5988 (bis). that's a hard thing to do and will take= a while.


As Erik previously indicated, it would= be great if this could be done as part of RFC5988bis.
=C2=A0
- for the RFC 6690-based variants under consideration right now, it would b= e helpful to very explicitly point out that they are *not* general-purpose = serializations of web links, but instead inherit the limitations of the und= erlying spec.

=

That would, indeed, be good. But, in= case RFC5988bis would spec a (JSON) serialization, it seems to me that it = would be rather helpful for the CORE community if the RFC 6690 JSON seriali= zation would be based on it.=C2=A0

Cheers

herbert

=C2=A0

cheers,

dret.

--
erik wilde | mailto:erik.wilde@dret.net |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret=C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://twitter.com/dret=C2=A0 = =C2=A0 |



--
=
Herbert Van de Sompel
Digital Library Res= earch & Prototyping
Los Alamos National Laboratory, Research Library=
http://p= ublic.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126

=3D= =3D
--001a1147acdc557ada054dfd2adc-- From nobody Tue Apr 25 05:54:53 2017 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 0767712EC7D; Tue, 25 Apr 2017 05:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_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=osram.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 e6wiqcOBf6BT; Tue, 25 Apr 2017 05:54:50 -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 E931D12EC9D; Tue, 25 Apr 2017 05:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CWQw4+ZmByYyXpCUQZJ9B0Rx/CE0TkvqSsPJgyAeJ90=; b=aifib9TWpPDRfwJt4OJECYmKaH8az4uXhO4jx4q/ItauMG2aA2iILfrj4hHW4pcVpvXI+505fCdFPZIZdihzxv3DYrLocZnZNOPRuZvAoGCGYWzCineM8ZvHXW1iL1oDtQ7vEt+CyRcLBkC2TgvRwQVsBGSJ8Zw+cDpmUSuvYUE= Received: from HE1PR07MB1657.eurprd07.prod.outlook.com (10.166.124.135) by HE1PR07MB1660.eurprd07.prod.outlook.com (10.166.124.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 12:54:47 +0000 Received: from HE1PR07MB1657.eurprd07.prod.outlook.com ([10.166.124.135]) by HE1PR07MB1657.eurprd07.prod.outlook.com ([10.166.124.135]) with mapi id 15.01.1061.011; Tue, 25 Apr 2017 12:54:46 +0000 From: "Beck, Stefan" To: "draft-tiloca-core-multicast-oscoap@ietf.org" CC: 'core' , Jim Schaad Thread-Topic: [core] Review on draft-tiloca-core-multicast-oscoap-01 Thread-Index: AdKuTspS7D95VPiCTf6PMOteBsYMvAPaYIng Date: Tue, 25 Apr 2017 12:54:46 +0000 Message-ID: References: <017401d2ae79$5a6378f0$0f2a6ad0$@augustcellars.com> In-Reply-To: <017401d2ae79$5a6378f0$0f2a6ad0$@augustcellars.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=osram.com; x-originating-ip: [32.66.115.43] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1660; 7:Kj0SZ1lKGcMmkQdXYAunkSaD0liLhhSdJfcad3LxF0616tf4gZnZAWKLAwArjBh27B1xF3doz1anFKwOK+sd6aDn6+vWj52JKChqby4/+0fxzFG3w2VmJ2t7MmF9sekkoaNcF5CCiUIavHhPmAU/4R+8HW8D/OLhMKLTB2V4Ao5Iv0wp54lf9Um7BSNBc/WQ90Uxgtn8zwMU812/Ol8UuHcZ9trVcu6VA0RfrksLQjUKs0Bhs16/ghU2tvAWSI/39cAyWz4UYBL8GRweKhK+8FYZfG+uWkDf5nGOLTkGFYB7Y5SkZp5TzDFey4ojvBnAW4IwnUBCaAvzkcPbNT8KMw== x-ms-office365-filtering-correlation-id: 51108cd4-3b3b-4534-e01a-08d48bda4083 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:HE1PR07MB1660; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:HE1PR07MB1660; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1660; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39400400002)(39410400002)(13464003)(377454003)(122556002)(66066001)(7696004)(3846002)(6116002)(102836003)(305945005)(2501003)(74316002)(230783001)(76176999)(77096006)(50986999)(54356999)(6436002)(33656002)(229853002)(110136004)(38730400002)(5640700003)(6506006)(6306002)(561944003)(9686003)(53936002)(6246003)(86362001)(99286003)(55016002)(6916009)(2950100002)(54906002)(8936002)(3280700002)(4326008)(3660700001)(2900100001)(5660300001)(2906002)(81166006)(8676002)(189998001)(2351001)(53546009)(7736002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1660; H:HE1PR07MB1657.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 12:54:46.4485 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1660 Archived-At: Subject: Re: [core] Review on draft-tiloca-core-multicast-oscoap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:54:52 -0000 Hi, On Section 2: Group-level data confidentiality and Source authentication are described as= SHALL, while Message integrity is SHOULD. Intuitively I would consider authentication and integrity as SHALL, while c= onfidentiality could be seen as SHOULD (or even MAY? - as the following tex= t already correctly suggests that data confidentiality may only be required= if privacy sensitive data is exchanged - which is not necessarily the case= , e.g. in simple situations On authentication and integrity: I would use SHALL consistently here - simi= lar to what is already written on "source authentication" in section 1. And= it is implied by the last statement anyway ("Message integrity is provided= through the same means used to provide source authentication.") Section 7.1: the first paragraph addresses the confidentiality part of "Gro= up-level Security", so you could potentially rename 7.1. to "Group-level Da= ta Confidentiality" as one specific part of the security considerations (pr= ovided that this first paragraph remains the only one in 7.1...): - the second paragraph deals with the obvious ("it is required that all gr= oup members are trusted"), so it could even be removed completely? - and the 3rd paragraph would better fit to 7.2 IMO (as the task of removi= ng a compromised group member becomes a key management task - similar to wh= en legitimate - yet uncompromised - group members are leaving). I also agree with Jim's proposal (on section 1, excerpt below), the same co= uld be applied in section 2 (and 7.1) analogously. Stevie -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, April 06, 2017 3:59 AM To: draft-tiloca-core-multicast-oscoap@ietf.org Cc: 'core' Subject: [core] Review on draft-tiloca-core-multicast-oscoap-01 Here are a few comments on this draft. <...> Section 1 - "Source authentication" - suggest the last sentence ends "not t= ampered with either by a different group member or by a non-group member". =09 <...> Jim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 25 06:07:51 2017 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 342441200FC; Tue, 25 Apr 2017 06:07:51 -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 JjSJrpLvIKPH; Tue, 25 Apr 2017 06:07:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89573127B57; Tue, 25 Apr 2017 06:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PD6pKS026446; Tue, 25 Apr 2017 15:06:51 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wC3Q304RBzDHsc; Tue, 25 Apr 2017 15:06:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 25 Apr 2017 15:06:48 +0200 Cc: Erik Wilde , art@ietf.org, Mark Nottingham , IETF , "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514818407.59117-b4ffb0b6498cf5f580cda089da02173a Content-Transfer-Encoding: quoted-printable Message-Id: <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> To: Herbert Van de Sompel X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:07:51 -0000 > On Apr 25, 2017, at 14:50, Herbert Van de Sompel = wrote: >=20 > On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde = wrote: > hello carsten. >=20 > On 2017-04-24 14:55, Carsten Bormann wrote: > it would be better to make sure that serializations of web links = actually can represent web links and not just some of the information = that they convey. that train may have left the station with RFC 6690, = but maybe for the JSON and CBOR serializations that can be changed. > Right. Can you be more specific what you would want to see here? >=20 > two possibilities: >=20 > - to do things well it would be better to have web link serializations = that cover *all* of RFC 5988 (bis). that's a hard thing to do and will = take a while. >=20 >=20 > As Erik previously indicated, it would be great if this could be done = as part of RFC5988bis. Yes. But covering all of RFC 5988 is mainly hard because of the vagaries of = HTTP header field encoding. We don=E2=80=99t have that problem in RFC 6690, so it is easy to have = RFC 6690 and links-json as a proper subset if we want to. > - for the RFC 6690-based variants under consideration right now, it = would be helpful to very explicitly point out that they are *not* = general-purpose serializations of web links, but instead inherit the = limitations of the underlying spec. >=20 >=20 > That would, indeed, be good. But, in case RFC5988bis would spec a = (JSON) serialization, it seems to me that it would be rather helpful for = the CORE community if the RFC 6690 JSON serialization would be based on = it.=20 I would hope so, but remember that links-json is already out there. The RFC 6690 JSON serialization is pretty much a no-brainer, and there = are no obvious ways to do things very different (well, you could choose = a different name for =E2=80=9Chref=E2=80=9D, but that would not be very = bright). CBOR adds a few bike sheds, but these can be painted in the = same color with little effort. If a superset RFC 5988 JSON serialization deviates from this (i.e., is = not a proper superset), I think this would require some willful effort. (I=E2=80=99m happy to be proven wrong; that=E2=80=99s why I was asking = if any specifics are known here already.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 25 09:47:27 2017 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 AE8F212EB44; Tue, 25 Apr 2017 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 iioN6VG7Bwdt; Tue, 25 Apr 2017 09:47:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D05CB129A91; Tue, 25 Apr 2017 09:47:24 -0700 (PDT) Received: from [192.168.178.20] ([93.217.111.164]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyVcA-1bxQWf3moo-015uEj; Tue, 25 Apr 2017 18:46:24 +0200 To: Carsten Bormann , Herbert Van de Sompel References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> Cc: IETF , art@ietf.org, "core@ietf.org WG" , Erik Wilde , draft-ietf-core-links-json.all@ietf.org From: Julian Reschke Message-ID: Date: Tue, 25 Apr 2017 18:46:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hc2flPMI2xoEM8PXdvVJ6YpBzL4x35h2N/07C+H5n+WlR2ldIsT kOmSrI+bsgT4Zr2SReDzoV6h0XGPB9KeIlENoBW+ruN5PecCWuDh5AC/MWyKv6BWZK/5G4q YSYp5WVzWm32NumtRWf4xkZheeHL3o+l4MKDqimlN0OqV0XZFabIqvVKOaooXtlSbeayoSx FpUUqbFcgrg6X2jkGjX9w== X-UI-Out-Filterresults: notjunk:1;V01:K0:rOnBY3m5eYo=:Dn2omTrw4EVngdaeIS8U4O FsUn5q/gNf/bFeuoqsHDzWabMr0gCTYHq1TUzCON45WN/EXz1/WaUs0/9Vr79WasGWT6SKLa3 v5st6ds73Ko/tQWgOlBOj23l9xg3f5DVWy9RrqcIBbni+JHuEKCNUWzFZTl/Ba4jB9PQT0vEU MvZu+MVm2FJx3wh3QsT+NZO81uJa1znx6/+YAP4z/mrUZTkz7LFVxaRz0lCS2UZn0eaZ+4nhP E6xJdEvf5RSTNf1ULyaxc+H9WkqWvOgFqN5hbIqdJVJhuVlOJ8vdd9ODneTVtytdM9oGV4/fD +UaIVBv84JUO1Qw3SGDWsYdpEqy7lGrY8GmRJgVWzyOCDHP+90oZUVXcsTLGFLnfvQ2VJ22Ck UWMusunICnLgl06n3MDxRfl1Jd7kpy5EUfVCDq3ngeKVPeBc/Zdan36iVHj7HNxuuGHlDhNhE g1Oy4wzX0qb6nkP4OIXTz5GxurHvU4pI+QG/pCcW4JFC2vk43JQ2Ye/KzGUQBgxEaOkpgfNBZ luiTFhiX4rpnx7EslAUclVX5rleBDIQ9yuoJyTGC0OqGvML4vvqvkq9IFc3fjIh7tPe60hLHv lUVgvjhnAkU/X36omK1pPng8krm4AP3L5usBwfenj8wRDvgVWwj4TOEGoALhp6y0oE5cC4Ecj vhVjrrTvD4wlEWSJT7sQF0t95dzh3JFxNTIkZnnJgjRf9J8xPze302RTZCF0WdJOsuj32HI+y p2T7G9iY9LhAzKrd3N3dq3VZDHIShZ22VJH02iiecsiuyiNOMc/n7OUcPdADQWYMer66wAFVB iVj+FER Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:47:27 -0000 On 2017-04-25 15:06, Carsten Bormann wrote: > >> On Apr 25, 2017, at 14:50, Herbert Van de Sompel wrote: >> >> On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde wrote: >> hello carsten. >> >> On 2017-04-24 14:55, Carsten Bormann wrote: >> it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed. >> Right. Can you be more specific what you would want to see here? >> >> two possibilities: >> >> - to do things well it would be better to have web link serializations that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take a while. >> >> >> As Erik previously indicated, it would be great if this could be done as part of RFC5988bis. > > Yes. > > But covering all of RFC 5988 is mainly hard because of the vagaries of HTTP header field encoding. > ... Do you have a specific problem in mind? Best regards, Julian From nobody Tue Apr 25 12:01:22 2017 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 C700913178B; Tue, 25 Apr 2017 12:01: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 X2qMWII5vINR; Tue, 25 Apr 2017 12:01:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3EB13178D; Tue, 25 Apr 2017 12:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PJ014b017046; Tue, 25 Apr 2017 21:00:01 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCCFX5KBpzDJ5m; Tue, 25 Apr 2017 21:00:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 25 Apr 2017 20:59:59 +0200 Cc: Herbert Van de Sompel , art@ietf.org, draft-ietf-core-links-json.all@ietf.org, IETF , "core@ietf.org WG" , Erik Wilde X-Mao-Original-Outgoing-Id: 514839599.587282-cfed82419b35f701b30329893f680c6a Content-Transfer-Encoding: quoted-printable Message-Id: <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:01:21 -0000 On Apr 25, 2017, at 18:46, Julian Reschke wrote: >=20 > Do you have a specific problem in mind? This work was done half a decade ago (May 18, 2012, that is), so I = don=E2=80=99t remember all the details. RFC 6690 says: In order to convert an HTTP Link Header field to this link format, first the "Link:" HTTP header is removed, any linear whitespace (LWS) is removed, the header value is converted to UTF-8, and any percent- encodings are decoded. So we get rid of all that fun before it becomes RFC 6690 (and CoAP of = course is all UTF-8 in any case). So far, we have run into one real case where that approach is a = limitation, and that is in URIs: The link coap://example.com?stupid%3Dkey=3D4711 is not distinguishable from coap://example.com?stupid=3Dkey=3D4711 (The typical reaction of an implementer is =E2=80=9Cthen don=E2=80=99t = do that!=E2=80=9D [1,2].) We know that because the CoAP protocol itself also completely runs in = the UTF-8 domain (there is no percent encoding on the wire); I=E2=80=99m = not sure that simplification actually hurt in RFC 6690 use cases yet. (Note that it is rather likely to see user-visible strings in DNS-SD = instance names, which turn into =E2=80=9Cins=E2=80=9D link attributes, = so this is not only a URI/IRI/WVUS [3] issue.) We don=E2=80=99t have a lot of experience with lingering legacy charsets = in HTTP headers in the constrained space, so I=E2=80=99m sure there are = other side effects. Gr=C3=BC=C3=9Fe, Carsten [1]: = http://www.condenaststore.com/-sp/Then-don-t-do-that-New-Yorker-Cartoon-Pr= ints_i14788077_.htm [2]: http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html [3]: https://url.spec.whatwg.org/#valid-url-string (WHATWG Valid URL = String, or WVUS for short) From nobody Tue Apr 25 13:09:58 2017 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 D31651294BD; Tue, 25 Apr 2017 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO3d1RO-ttsv; Tue, 25 Apr 2017 13:09:41 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822F2128CD5; Tue, 25 Apr 2017 13:09:41 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id E59779018A3E; Tue, 25 Apr 2017 13:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=768msT/pCVcCIOXkVMHTvPXcNI8=; b=HKj2hRl35LJd8eNI/Hrp1nCP1VC9 LA29bFPPLMxkvx2idjdYgDl1FscwyCbzj6ZyJ98EuSGm9va3KYzrUeT0r47PUZll Zh8l3Hi600mLG6qa4rHfcx8ezTsK3heIvhmXm8KFD+tTPKSAM27Z2FeUCKP5ycJ6 McWkBzelJXKWWPQ= Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id ADC1C9018A3C; Tue, 25 Apr 2017 13:09:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> Date: Tue, 25 Apr 2017 13:09:40 -0700 Cc: Julian Reschke , IETF , art@ietf.org, draft-ietf-core-links-json.all@ietf.org, "core@ietf.org WG" , Erik Wilde , Herbert Van de Sompel Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:09:43 -0000 > On Apr 25, 2017, at 11:59 AM, Carsten Bormann wrote: >=20 > On Apr 25, 2017, at 18:46, Julian Reschke = wrote: >>=20 >> Do you have a specific problem in mind? >=20 > This work was done half a decade ago (May 18, 2012, that is), so I = don=E2=80=99t remember all the details. > RFC 6690 says: >=20 > In > order to convert an HTTP Link Header field to this link format, = first > the "Link:" HTTP header is removed, any linear whitespace (LWS) is > removed, the header value is converted to UTF-8, and any percent- > encodings are decoded. Well, that's broken. > So we get rid of all that fun before it becomes RFC 6690 (and CoAP of = course is all UTF-8 in any case). >=20 > So far, we have run into one real case where that approach is a = limitation, and that is in URIs: >=20 > The link >=20 > coap://example.com?stupid%3Dkey=3D4711 >=20 > is not distinguishable from >=20 > coap://example.com?stupid=3Dkey=3D4711 >=20 > (The typical reaction of an implementer is =E2=80=9Cthen don=E2=80=99t = do that!=E2=80=9D [1,2].) That isn't a "limitation". It's a bug to decode pct-encoded octets in a URI before decomposing the reference into its parts. ASCII is already in UTF-8. Decoding a pct-encoding doesn't make it "more UTF-8"; it just means the string is no longer a URI reference. That's broken. So = utterly broken that it obviously wasn't reviewed by the right people. > We know that because the CoAP protocol itself also completely runs in = the UTF-8 domain (there is no percent encoding on the wire); I=E2=80=99m = not sure that simplification actually hurt in RFC 6690 use cases yet. *sigh* ....Roy From nobody Tue Apr 25 14:26:52 2017 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 1670D129436; Tue, 25 Apr 2017 14:26:51 -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 lTWt0hOQbt53; Tue, 25 Apr 2017 14:26:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446DA126B6E; Tue, 25 Apr 2017 14:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PLPnO8005255; Tue, 25 Apr 2017 23:25:49 +0200 (CEST) Received: from client-0139.vpn.uni-bremen.de (client-0139.vpn.uni-bremen.de [134.102.107.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCGTn2MXhzDJ7X; Tue, 25 Apr 2017 23:25:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 25 Apr 2017 23:25:48 +0200 Cc: IETF , Julian Reschke , art@ietf.org, Herbert Van de Sompel , "core@ietf.org WG" , Erik Wilde , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514848348.452778-61494f675340a082fab68f2a595dd329 Content-Transfer-Encoding: quoted-printable Message-Id: <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> To: "Roy T. Fielding" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:26:51 -0000 >> RFC 6690 says: >>=20 >> In >> order to convert an HTTP Link Header field to this link format, = first >> the "Link:" HTTP header is removed, any linear whitespace (LWS) is >> removed, the header value is converted to UTF-8, and any percent- >> encodings are decoded. >=20 > Well, that's broken. OK, let me start typing that errata report then. >> coap://example.com?stupid%3Dkey=3D4711 >>=20 >> is not distinguishable from >>=20 >> coap://example.com?stupid=3Dkey=3D4711 >>=20 >> (The typical reaction of an implementer is =E2=80=9Cthen don=E2=80=99t = do that!=E2=80=9D [1,2].) >=20 > That isn't a "limitation=E2=80=9D. =20 For RFC6690 users, it pretty much is, because certain URIs don=E2=80=99t = work. They tend to design their URIs in such a way that they do, probably more = so because these designs are natural for them than because they are = fully aware of that limitation. > It's a bug to decode pct-encoded octets in > a URI before decomposing the reference into its parts. =20 Well, percent-encoding is playing two roles in RFC 3986: hiding = characters within syntactic elements from their delimiter roles, and = encoding non-ASCII (and C0 etc.) characters. The passage I cited from RFC 6690 got nicely rid of the latter, and = broke the former(*). > ASCII is already > in UTF-8. Decoding a pct-encoding doesn't make it "more UTF-8"; it = just > means the string is no longer a URI reference. That's broken. So = utterly > broken that it obviously wasn't reviewed by the right people. So what should I write into the errata report? Or more generally speaking, how should we fix RFC 6690, without creating = a need for constrained nodes to do full URI processing? Maybe it is sufficient to document the limitation in the errata, for = now? And, more to the point of the subject line, how should we handle this on = the JSON/CBOR level? There definitely will be a round-tripping problem with RFC 6690 if the = URIs collide with the above limitation of RFC 6690. But that=E2=80=99s = OK because that defines the subset. To be more general, not doing any percent-decoding of URIs when creating = JSON/CBOR from scratch is probably the easy way, but it means that when = we want to phase out RFC 6690 on the constrained level by replacing it = with JSON/CBOR, there is additional complexity. Horribile dictu, but = maybe IRIs are the right thing to do here. Gr=C3=BC=C3=9Fe, Carsten (*) It may be worth pointing out that the amount of breakage here is = much larger than for CoAP itself, which does the percent-decoding only = after decomposing a URI into what CoAP considers to be its components, = so the URI parsing works properly =E2=80=94 coap://example.com/foo%2fbar = has one path segment, =E2=80=9Cfoo/bar=E2=80=9D. But the application semantics of hiding application delimiters, which my = example above is breaking, is not supported in CoAP either. Some people think that URIs should be carried around in that decomposed = form throughout the constrained space, and I can=E2=80=99t blame them. I don=E2=80=99t have data how many URI libraries in active use in the = non-constrained space get this particular detail right, either. From nobody Tue Apr 25 15:20:00 2017 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 A999413162A; Tue, 25 Apr 2017 15:19:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149315879365.13684.3263173090290877403@ietfa.amsl.com> Date: Tue, 25 Apr 2017 15:19:53 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:19:54 -0000 Reviewer: Elwyn Davies Review result: Not Ready 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-links-json-07 Reviewer: Elwyn Davies Review Date: 2017-04-25 IETF LC End Date: 2017-04-21 IESG Telechat date: 2017-04-27 Summary:Not ready for publication. There a number of issues that need to be addressed as discussed below. In particular whether the formats could be returned as the web link specification instead of RFC 6990 format in response to a GET /.well-known/core request. Having thought about the quote stripping/addition issue cited in Adam Roach's DISCUSS, I would take a slightly different view... see below. Major issues: Intentions: Is it one of the intentions of this draft that a server should be able to return web link descriptions using JSON or CBOR, specifically in response to GET /.well-known/core? Content formats for the new formats are registered (s3.2) - could a user ask for the alternative formats by specifying at ct filter with the GET request? It strikes me that if one has a constrained server of sufficiently limited capabilities that it wants to use CBOR then having to encode the RFC 6690 format responses for the web links requests is wasting resources. Some more thought needs to be given to this as an update to RFC 6690 - If I read correctly, RFC 6690 implicitly requires that a response to GET /.well-known/core MUST be encoded as described in RFC6690. Minor issues: Title: The document appears only to address the CoRE Web Links format rather than any other. Should the title reflect this more precisely, e.g., Representing CoRE Web Links Format in JSON and CBOR s1.1: Concerning: o The simplest thing that could possibly work * Do not cater for RFC 5988 complications caused by HTTP header character set issues [RFC2047] Having ferreted around in RFC 5988 and RFC 2047, I can't see what is being referred to here. However, I observe later that the "title*" attribute (with language specifier) does not appear to be supported (It is missing from Table 1) - is this what is relevant here? If so it needs clarification. [Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing external references to various productions (e.g., ext-value, quoted-string) that are defined in other documents - in the given examples RFC 2987, RFC 2616.] s2.2/s5: This statement: The resulting structure can be represented in CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as: requires that the CDDL draft is a normative reference rather than informative. [Aside: Having skimmed the CDDL draft, I am of the opinion that a good deal more work will be needed to get this ready for publication, possibly to the extent that the CDDL quoted here becomes invalid. Given the simplicity of the specification could it be done without the use of CDDL?] s2.2: There needs to be some discussion of handling of double quoted and non-double quoted strings during conversion: I think it works to require that... >From RFC 6690 to JSON: - If the parameter value is a double quoted string then it should have the double quotes stripped, any necessary JSON character encodings performed and the double quotes repapplied. - if the parameter value is anything else, then the necessary JSON character encodings are done and the result enclosed in double quotes. [what about % encodings on the RFC 6690 side?] >From RFC 6690 to CBOR: - If the parameter value is a double quoted string, the double quotes are stripped and the result used as the CBOR string type value. - Otherwise, the parameter value is used as the CBOR string value. [what about % encodings on the RFC 6690 side?] >From JSON to RFC 6690: - Remove the double quotes from the JSON string value and do any necessary decoding and encoding. Reapply double quotes. Note that this may result in values that were originally not enclosed in double quotes in the RFC 6690 repreentation becoming enclosed in double quotes. However, [AFAICS] this does not alter the semantics of any of the predefined parameters. For example the ABNF productions mean that ct=40 and ct="40" are equivalent (the second case is needed so that one can also have ct="40 41 42"). What IS needed is a statement that this must also apply to any application specific parameters. For example the case in examples 4 and 5 of ..;foo="bar";foo=3;... transforming to "foo":["bar","3"] and then back to ...;foo="bar";foo="3";.. MUST require that the two RFC 6690 representations are equivalent. >From CBOR to RFC 6690: [Essentially the same process - decode/encode and apply double quotes. The discussion of equivalent semantics is equally applicable.] The conversion from CBOR to JSON or in reverse is similar. s2.3: It is not stated whether a CBOR decoder should accept literal use of the encodable parameters - i.e., if the encoded CBOR contains [ "href": "/mumble" ] rather than [1 : "mumble£ ] in CDDL format. Similarly, should the use of the encoded values be mandatory on the CBOR encoder? s2.3, Table 1: Is the omission of title* from the list of parameter names deliberate? If so the omission justifies a note and rationale. Clearly the format of the value for a title* parameter is different from all the others, which may have something to do with this. s2.3/s5: eEfereences in Table 1 make RFC 7252 and RFC 7641 normative. Nits/editorial comments: s1: s/e.g. /e.g., / (two places) s1.1: The term "round-tripping" and the associated text are opaque jargon that would normally be applied to message transmission round a loop rather than format conversion. A more explicit formulation would help naive readers. Suggest (if I understand what was intended): OLD: o Canonical mapping * lossless round-tripping with [RFC6690] and between JSON and CBOR * but not trying for bit-preserving (DER-style) round-tripping NEW: o Canonical mapping * supporting inter-conversion in both directions between any pair of [RFC6690] format and the CBOR and JSON formats defined here with unaltered and unambiguous semantics * but not attempting to ensure that a sequence of conversions from one of the formats through one or both of the others and back to the original would result in an identical representation (c.f., as might be achieved by different BER transcoders rather than by all DER transcoders with ASN.1 [X.690]). ENDS This needs an informative reference to X.690 ... but I am not sure that the DER comparison is essential. s2.2: Suggest: OLD: We straightforwardly map: o the outer collection to an array of links; o each link to a JSON object or CBOR map, mapping attribute names to attribute values. NEW: We straightforwardly map: o the outer collection to an array of parameterized web links; o each parameterized web link to a JSON object or CBOR map, mapping attribute names to attribute values. ENDS s2.2: OLD: The resulting structure can be represented in CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as: NEW: The resulting structure can be represented in CBOR Data Definition Language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl] as shown in Figure 1. s2.4: Note that the use of ct=40 in RFC 6690 is an anchronism. The ct parameter appeared in earlier versions of the draft that led to RFC 6690 but was moved out to be used more generally in CoAP and is actually defined in RFC 7252 as mentioned in Table 1 here. Thus use of ct=40 in the example copied from RFC 6690 really needs an erratum for 6690 but that is for another day! From nobody Tue Apr 25 16:08:47 2017 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 053DB1205F0; Tue, 25 Apr 2017 16:08:39 -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 Tq8gvNDBxS4f; Tue, 25 Apr 2017 16:08:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F7E126B71; Tue, 25 Apr 2017 16:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PN8TaM010863; Wed, 26 Apr 2017 01:08:29 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCJmF1FYXzDJ8x; Wed, 26 Apr 2017 01:08:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149315879365.13684.3263173090290877403@ietfa.amsl.com> Date: Wed, 26 Apr 2017 01:08:28 +0200 Cc: gen-art@ietf.org, ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514854508.320519-706d79887a403956b4df6ab96ff401e3 Content-Transfer-Encoding: quoted-printable Message-Id: <720C9B43-B803-4C99-A366-3C79F463FB23@tzi.org> References: <149315879365.13684.3263173090290877403@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:08:39 -0000 Hi Elwyn, thank you for your review =E2=80=94 that is a lot of good input. Before I start thinking about fixes for the WG to consider, let me = comment on a few items: > Summary:Not ready for publication. There a number of issues that need > to be addressed as discussed below. In particular whether the > formats could be returned as the web link specification instead of RFC > 6990 format in response to a GET /.well-known/core request. >=20 > Having thought about the quote stripping/addition issue cited in Adam > Roach's DISCUSS, I would take a slightly different view... see below. >=20 > Major issues: >=20 > Intentions: > Is it one of the intentions of this draft that a server should be able > to return web link descriptions using JSON or CBOR, specifically in > response to GET /.well-known/core? =20 Maybe not as much an intention as a possible direction that should = remain open. This draft defines two media types. RFC 6690 defined another media = type. =46rom the point of RFC 6690=E2=80=99s registration of = /.well-known/core, RFC 6690 was the only media type available, so the = assumption there is that application/link-format is returned. But if a client sends a CoAP Accept option for one of the two media = types defined here, that should be returnable, too. So we probably should say this explicitly (i.e., update RFC 6690 by = saying this). > Content formats for the new > formats are registered (s3.2) - could a user ask for the alternative > formats by specifying at ct filter with the GET request? It strikes > me that if one has a constrained server of sufficiently limited > capabilities that it wants to use CBOR then having to encode the RFC > 6690 format responses for the web links requests is wasting resources. > Some more thought needs to be given to this as an update to RFC 6690 > - If I read correctly, RFC 6690 implicitly requires that a response to > GET /.well-known/core MUST be encoded as described in RFC6690. That is one way to read it =E2=80=94 however, if you apply the Web model = and the fact that the Accept and Content-Format (integer version of = media type + content coding) options are central to CoAP, a reading that = RFC 6690 just specifies the initial media type for the well-known URI it = defines becomes more likely. But, again, we should make this explicit. > Minor issues: > Title: The document appears only to address the CoRE Web Links format > rather than any other. Should the title reflect this more precisely, > e.g., > Representing CoRE Web Links Format in JSON and CBOR The RFC editor will force us to expand CoRE. Probably even simpler: Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR (The middle line is the title of RFC 6690.) > s1.1: Concerning: > o The simplest thing that could possibly work >=20 > * Do not cater for RFC 5988 complications caused by HTTP > header > character set issues [RFC2047] >=20 > Having ferreted around in RFC 5988 and RFC 2047, I can't see what is > being referred to here. However, I observe later that the "title*" > attribute (with language specifier) does not appear to be supported > (It is missing from Table 1) - is this what is relevant here? If so it > needs clarification.=20 Indeed. > [Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing > external references to various productions (e.g., ext-value, > quoted-string) that are defined in other documents - in the given > examples RFC 2987, RFC 2616.] >=20 > s2.2/s5: This statement: > The resulting structure can be represented in CDDL > [I-D.greevenbosch-appsawg-cbor-cddl] as: >=20 > requires that the CDDL draft is a normative reference rather than > informative. Well, this was meant to be interpreted as informative, but maybe that = should be made more explicit. > [Aside: Having skimmed the CDDL draft, I am of the opinion that a > good deal more work will be needed to get this ready for publication, > possibly to the extent that the CDDL quoted here becomes invalid.=20 I don=E2=80=99t think so, but we would like to hear this opinion in the = CBOR WG, where CDDL is being worked on. > Given the simplicity of the specification could it be done without the > use of CDDL?]=20 The intention was that all the normative information is in English, = that=E2=80=99s why the CDDL reference is informative. > s2.2: There needs to be some discussion of handling of double quoted > and non-double quoted strings during conversion: > I think it works to require that... >> =46rom RFC 6690 to JSON: > - If the parameter value is a double quoted string then it should have > the double quotes stripped, any necessary JSON character encodings > performed and the double quotes repapplied. That=E2=80=99s not how the spec is written. The assumption is that you = already have a JSON or CBOR implementation, so the spec is at the data = model level; it is not going to tell you how to parse or generate JSON = or CBOR. (Parsing and generating does, however, play a role for = RFC6690. Compare the example implementation, which is 90 % RFC 6690 = implementation=E2=80=A6) > - if the parameter value is anything else, then the necessary JSON > character encodings are done and the result enclosed in double > quotes. > [what about % encodings on the RFC 6690 side?] We are having a lovely discussion about percent-encoding right now in a = thread over at art@, ietf@, core@. Let me cite this part from RFC 6690 so you can share the fun: In order to convert an HTTP Link Header field to this link format, first the "Link:" HTTP header is removed, any linear whitespace (LWS) is removed, the header value is converted to UTF-8, and any percent- encodings are decoded. (This obviously creates a limitation on RFC 6690; essentially it can=E2=80= =99t represent URIs with percent-encoded reserved characters. Whether = that limitation should mirror over to the JSON/CBOR side is to be = discussed in that other discussion.) >> =46rom RFC 6690 to CBOR: > - If the parameter value is a double quoted string, the double quotes > are stripped and the result used as the CBOR string type value. > - Otherwise, the parameter value is used as the CBOR string value.=20 > [what about % encodings on the RFC 6690 side?] (See above) >=20 >> =46rom JSON to RFC 6690:=20 > - Remove the double quotes from the JSON string value and do any > necessary decoding and encoding. Reapply double quotes. Note that > this may result in values that were originally not enclosed in double > quotes in the RFC 6690 repreentation becoming enclosed in double > quotes. However, [AFAICS] this does not alter the semantics of any of > the predefined parameters. For example the ABNF productions mean that > ct=3D40 and ct=3D"40" are equivalent (the second case is needed so = that > one can also have ct=3D"40 41 42"). What IS needed is a statement = that > this must also apply to any application specific parameters. =20 Yes, that was one of the points that Mark=E2=80=99s comments pointed = out. > For > example the case in examples 4 and 5 of ..;foo=3D"bar";foo=3D3;... > transforming to "foo":["bar","3"] and then back to > ...;foo=3D"bar";foo=3D"3";.. MUST require that the two RFC 6690 > representations are equivalent. That is essentially an RFC 5988 limitation that RFC 6690 inherits and = Mark=E2=80=99s RFC5988bis repairs by pretty much stating just this. >> =46rom CBOR to RFC 6690:=20 > [Essentially the same process - decode/encode and apply double quotes. > The discussion of equivalent semantics is equally applicable.] >=20 > The conversion from CBOR to JSON or in reverse is similar.=20 (Ditto) > s2.3: It is not stated whether a CBOR decoder should accept literal > use of the encodable parameters - i.e., if the encoded CBOR contains [ > "href": "/mumble" ] rather than [1 : "mumble=C2=A3 ] in CDDL format.=20= It should not. The above specification for JSON could be used as is for the CBOR encoding as well. However, to further reduce message sizes, an extra encoding step is performed: "href" and some commonly occurring attribute names are encoded as small integers. The =E2=80=9Cis=E2=80=9D/=E2=80=9Care" should be interpreted as MUST do = that =E2=80=94 maybe again this needs to be explicit. Should a links-cbor decoder required to reject those 13 strings? Hmm. Interoperability probably says yes, complexity says no. > Similarly, should the use of the encoded values be mandatory on the > CBOR encoder? Yes. > s2.3, Table 1: Is the omission of title* from the list of parameter > names deliberate? If so the omission justifies a note and rationale.=20= > Clearly the format of the value for a title* parameter is different > from all the others, which may have something to do with this. Yes. I=E2=80=99m forgetting what title* is being used for over in the = Big Web, so I=E2=80=99ll have to look this up again. >=20 > s2.3/s5: eEfereences in Table 1 make RFC 7252 and RFC 7641 normative. Here, I fully disagree (sorry, pet peeve =E2=80=94 we are way too lax = with the concept of normative references in the IETF). When specification B uses a string that is mentioned in specification A, = without needing anything else from specification A, this doesn=E2=80=99t = make specification A normative for B. A is normative if you need to read it to implement B; that is not the = case here. > Nits/editorial comments:=20 > s1: s/e.g. /e.g., / (two places) Thanks, a favorite mistake of this non-native speaker. > s1.1: The term "round-tripping" and the associated text are opaque > jargon that would normally be applied to message transmission round a > loop rather than format conversion. =20 (Actually, for me that is a term of art in format conversion. But I = only have worked on format conversions since 1982 :-) Yes, we need to avoid jargon. > A more explicit formulation would > help naive readers. Suggest (if I understand what was intended): > OLD: > o Canonical mapping >=20 > * lossless round-tripping with [RFC6690] and between JSON and > CBOR >=20 > * but not trying for bit-preserving (DER-style) round-tripping > NEW: > o Canonical mapping >=20 > * supporting inter-conversion in both directions between any > pair=20 > of [RFC6690] format and the CBOR and JSON formats defined > here=20 > with unaltered and unambiguous semantics >=20 > * but not attempting to ensure that a sequence of conversions > from=20 > one of the formats through one or both of the others and back > to=20 > the original would result in an identical representation > (c.f.,=20 > as might be achieved by different BER transcoders rather than > by all=20 > DER transcoders with ASN.1 [X.690]). > ENDS > This needs an informative reference to X.690 ... but I am not sure > that the DER comparison is essential. (I hope, not. But thanks for the text suggestion, that will certainly = help.) > s2.2: Suggest: > OLD: > We straightforwardly map: >=20 > o the outer collection to an array of links; >=20 > o each link to a JSON object or CBOR map, mapping attribute names > to > attribute values. >=20 > NEW: > We straightforwardly map: >=20 > o the outer collection to an array of parameterized web links; >=20 > o each parameterized web link to a JSON object or CBOR map, > mapping attribute names to > attribute values. > ENDS Hmm, do we need the term =E2=80=9Cparameterized web link=E2=80=9D for = what most of us call =E2=80=9Clink=E2=80=9D? > s2.2: > OLD: > The resulting structure can be represented in CDDL > [I-D.greevenbosch-appsawg-cbor-cddl] as: > NEW: > The resulting structure can be represented in CBOR Data Definition > Language (CDDL) > [I-D.greevenbosch-appsawg-cbor-cddl] as shown in Figure 1. Yes. > s2.4: Note that the use of ct=3D40 in RFC 6690 is an anchronism. The = ct > parameter appeared in earlier versions of the draft that led to RFC > 6690 but was moved out to be used more generally in CoAP and is > actually defined in RFC 7252 as mentioned in Table 1 here. Thus use > of ct=3D40 in the example copied from RFC 6690 really needs an erratum > for 6690 but that is for another day! =20 Actually, not quite, as =E2=80=9Cct=E2=80=9D is deliberately used in RFC = 6690 in an example only =E2=80=94 you wouldn=E2=80=99t look for a = normative reference to a document defining =E2=80=9Cfoo=E2=80=9D if we = had used that :-) Again, thank you for that thoughtful feedback, this will help us = significantly in making the specification better. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 25 18:54:42 2017 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 22AAB1243FE; Tue, 25 Apr 2017 18:54:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-links-json@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149317168013.24864.5775398036404123780.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 18:54:40 -0700 Archived-At: Subject: [core] Ben Campbell's No Objection on draft-ietf-core-links-json-07: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 01:54:40 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-links-json-07: 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-links-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- On a quick email scan, I gather that the discussion thread resulting from Mark's ART-ART review has not completely resolved, at least as of the time I reviewed the document. That probably needs to be resolved prior to progressing the draft. From nobody Wed Apr 26 01:51:43 2017 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 7C60B131A0D; Wed, 26 Apr 2017 01:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 GwrE6xF9TATN; Wed, 26 Apr 2017 01:51:40 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9975113180D; Wed, 26 Apr 2017 01:51:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D601846D43; Wed, 26 Apr 2017 10:51:37 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D683F36; Wed, 26 Apr 2017 10:51:36 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6084010D; Wed, 26 Apr 2017 10:51:36 +0200 (CEST) Received: (nullmailer pid 3731 invoked by uid 1000); Wed, 26 Apr 2017 08:51:35 -0000 Date: Wed, 26 Apr 2017 10:51:35 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Cc: kerry lynn , draft-ietf-core-resource-directory@ietf.org Message-ID: <20170426085135.2y6epto4argrzepf@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oi6wmw6ojbgwu5a4" Content-Disposition: inline User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: [core] resource-directory: generic ins= and suitability for DNS-SD X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 08:51:42 -0000 --oi6wmw6ojbgwu5a4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE WG, in the last resource-directory meeting, one of the longest single discussion items was how to proceed with the ins=3D attribute. The question in short is whether a simpler description like The resource instance attribute "ins" is a textual parameter that can be used to distinguish between resources of equal resource types within an endpoint or a domain. For example, values can be texts like "Ceiling light, Room 3", "Slot 2", short IDs like "AF39", but also UUIDs or iNumbers. (note that the "unique across the domain" requirement is gone) would still work for creating RD <-> DNS-SD gateways. On the missing uniqueness requirement I'd like to point out that unless the RD is sychronized with DNS-SD (ie. it only responds to registrations when it has complted DNS-SD entry), the gateway would need to have a fall-back plan for collisions anyway: The RD might not even have enforced ins uniqueness, or a client could have not shipped an ins=3D with an exp link at all. Can DNS service discovery based on a resource-directory work with such a laxer ins attribute, and if not, how would you expect an RD to handle duplicates of ins values? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --oi6wmw6ojbgwu5a4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlkAX5QACgkQOY0REtOk veElSQ//etUQMCaTPSAbhNaCmtg1l/DwwYfK+sds/bFTmtJ5GACxrg3UbZlia8oN 2+wn3vYbM3f63vBM/W4ahfcH/0xuPx/4YdbBE5+TNT+nYJ6XHtroR8jtysvSQbdF b5884AQ7db/Cv6u8dlnHYoDCU7dkQAvjhVNXPeYjGfNlABneV88RMRsv52lfNHbQ S6U+RCHFF0gGGG4WFWsTaXpIIzAnH/JrKIeMfFp1pMoRU9t35/uhEWeNi4HRmg2f KYqBtkPKFHVngk/BR8EHQfm4b9t12UVzbRXcQ4VHqeqho8eLw7xfD003kszNWde+ PxpDNbgZEOLs2+7I2Q00+1Jl7HpXIglNUN1+5yWFrarZn5yIN9xs74HLpinFLyC8 q1n8hY7qGyV5W2sITYrurGVKhmrrJqUrHKvOB6HEmkZiOEH4uCWQay1TxXNVCaYO c4eM48E+pvFb+ZoKdAgAxMUCIY3vi4M9TeahvJukiU8kyFcFt8SPaxJxu9hUQq/b lYa7LCtCp6l//E5udBT6fgtfRWD57l7ZiHTGnqoKy/h1eX2Iuzx3MwvrEt9XPArF ReKg05jVz5VhawKaC9vNclRyNF3sGg6jQpGvt1UT+T5osGXvwg4SDyaictCx1BL0 AIoVeR+nTUM1q8Ff3B35Vf1YNBt7lxQ9kbClQjMGyqQMZWyvqoU= =VwTt -----END PGP SIGNATURE----- --oi6wmw6ojbgwu5a4-- From nobody Wed Apr 26 01:53:48 2017 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 AA7C8131A2D; Wed, 26 Apr 2017 01:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 0upm0tDWvF9V; Wed, 26 Apr 2017 01:53:45 -0700 (PDT) Received: from mail4.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 3D022131A28; Wed, 26 Apr 2017 01:53:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493196821; h=from:subject:to:date:message-id; bh=hR033CO0O2zqyTxXo3vrygbriWkC4BbE3OlpwkB5aTA=; b=feS2MZl87D8icC1LNHFgeBNoAuqyTfMBDQfJD0f9e0Kkl0IQGoXBUpVjPKGKbn+HdS97nB5Odgj QlR5qfF5qZ5Y+8nrs+IX06lGbiG/DPLD8VYU8jgpivXSmEUYchO7N1lWre7tpFvifviJKD2OI5ZgS BLbDsyc2FJp4sCDyyv9tCDwkKNVT63q4wfSbP5fzqCNC8nt7GQVLC4PugsnZBl4McRUSbg6PKteyV psN6+y3AzA+1txVCVSxCGMQWEtgJGdVzdlF0Z9TH1vBhJbsoLiBtUciPxu1aKoUavpTDTtPAxbHVR tDTCmrk2hIUhK0X448Je9qzbxj4x98QhL4yQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 01:53:41 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 01:53:34 -0700 From: Jim Schaad To: CC: 'core' Date: Wed, 26 Apr 2017 01:43:14 -0700 Message-ID: <013c01d2be69$26723c70$7356b550$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdK+aQzsAiYCPhiESlGRpkR4uC1l0Q== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Is this a typo in -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 08:53:47 -0000 In section 6 the following text occurs: In descriptive usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that the payload is also allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block). However I think that the last sentence should read "less than 1024 bytes". Jim From nobody Wed Apr 26 02:07:45 2017 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 0ED8A131868; Wed, 26 Apr 2017 02:07:43 -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 0JLSeOwBvPiF; Wed, 26 Apr 2017 02:07:42 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82685129AA1; Wed, 26 Apr 2017 02:07:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 079D046D43; Wed, 26 Apr 2017 11:07:39 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 67C751CF; Wed, 26 Apr 2017 11:07:38 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3CB053BC; Wed, 26 Apr 2017 11:07:38 +0200 (CEST) Received: (nullmailer pid 6451 invoked by uid 1000); Wed, 26 Apr 2017 09:07:37 -0000 Date: Wed, 26 Apr 2017 11:07:37 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: draft-ietf-core-coap-tcp-tls@ietf.org, 'core' Message-ID: <20170426090737.joqmfg5alcpi546i@hephaistos.amsuess.com> References: <013c01d2be69$26723c70$7356b550$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jbblsczzypvmn7gw" Content-Disposition: inline In-Reply-To: <013c01d2be69$26723c70$7356b550$@augustcellars.com> User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [core] Is this a typo in -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:07:43 -0000 --jbblsczzypvmn7gw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 26, 2017 at 01:43:14AM -0700, Jim Schaad wrote: > In descriptive usage, a BERT Option is interpreted in the same way as > the equivalent Option with SZX =3D=3D 6, except that the payload is al= so > allowed to contain a multiple of 1024 bytes (non-final BERT block) or > more than 1024 bytes (final BERT block). >=20 > However I think that the last sentence should read "less than 1024 bytes". Sounds right to me: It extends what is already permitted for SZX=3D6, and <=3D1024 is already allowed for final SZX=3D6 blocks. (In effect, the last BERT block can have any length, only limited by Max-Message-Size). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --jbblsczzypvmn7gw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlkAY1YACgkQOY0REtOk veF91g//cknTrXr/YyyppWrqRNClZnS1r2+3XXvX72PraEJ2D5TevCY/j3vWrjTV V8h9hBkicirITEu4u7AE4TAa3zAnRV5XGh0Qw8GW4lx5bmlwWtIFi9CEgrINmTMK ryqd01EmeYorlBtlXzf0BzBoekJ7yoWj3W6vvbHo636g1QqQKbk+DgIXOB5RRXkV Cp3l5lsMOTt3lVOVslRo3GwwNukgmadXh7UGrGAlNIkRYC7GFVr/R1wz+8JkN2Kb +P7br8pQdiTo33CSZKWvuZcu1L0VmpOH2zxU+UGR78A1Dggr1g+s4f26cr+UYVUL GNdGh/jFSumQrEwi/Hv5OuRFBwynt+MAeybZ8+ZYMK/e5d2A4RGIIM0ala4pOEEi 1uciujdNgBG+MT5i1x474jPZlvTo5Jx4pLdNB4ZZw0PQbszEvOxRLIFRa9JLuC+E kTi37g0MTdyZRfSJpJHBmk+PlK7wUOH0En2DcqH8gL3IDNx4VHAxEcxEEOWCRVM9 9CQeON+9WAoB4kons1JIpzJX8qZOibaUMWMbJ48pkHizkaqrl31buPnsWMU8WXTY Mon3qEX6QGm1eWX855lZWQJfY88UQYCK4WVvS9Iv7283rNKOSiVesWkXTayMfi5J PKot8z0JHhGEr/vtrY75pkdUaLkCmQAoiov/i45dVaSVq0/rBns= =LYEV -----END PGP SIGNATURE----- --jbblsczzypvmn7gw-- From nobody Wed Apr 26 02:11:48 2017 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 A8EB21292C5; Wed, 26 Apr 2017 02:11:46 -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 E0CqC9zrN4Pc; Wed, 26 Apr 2017 02:11:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA40A13181B; Wed, 26 Apr 2017 02:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3Q9AqaP009395; Wed, 26 Apr 2017 11:10:52 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCZ7J2JfwzDJK4; Wed, 26 Apr 2017 11:10:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170426090737.joqmfg5alcpi546i@hephaistos.amsuess.com> Date: Wed, 26 Apr 2017 11:10:51 +0200 Cc: Jim Schaad , draft-ietf-core-coap-tcp-tls@ietf.org, core X-Mao-Original-Outgoing-Id: 514890651.524492-23f697f096201a0137f5c2bf4cae5abb Content-Transfer-Encoding: quoted-printable Message-Id: <068A4DFE-6169-46A0-BBDD-C7583E3C724F@tzi.org> References: <013c01d2be69$26723c70$7356b550$@augustcellars.com> <20170426090737.joqmfg5alcpi546i@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Is this a typo in -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:11:47 -0000 > On Apr 26, 2017, at 11:07, Christian Ams=C3=BCss = wrote: >=20 > On Wed, Apr 26, 2017 at 01:43:14AM -0700, Jim Schaad wrote: >> In descriptive usage, a BERT Option is interpreted in the same way as >> the equivalent Option with SZX =3D=3D 6, except that the payload is = also >> allowed to contain a multiple of 1024 bytes (non-final BERT block) = or >> more than 1024 bytes (final BERT block). >>=20 >> However I think that the last sentence should read "less than 1024 = bytes". >=20 > Sounds right to me: It extends what is already permitted for SZX=3D6, = and > <=3D1024 is already allowed for final SZX=3D6 blocks. (In effect, the = last > BERT block can have any length, only limited by Max-Message-Size). Yes. This seems to be the second time that someone stumbles about that = wording; maybe we can find a better way to say this. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 26 02:45:24 2017 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 AC24B129506; Wed, 26 Apr 2017 02:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=dme3eZv/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SWk5zGto Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKR1Oc1DX4sK; Wed, 26 Apr 2017 02:45:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8241D1293E3; Wed, 26 Apr 2017 02:45:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E757420E7D; Wed, 26 Apr 2017 05:45:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 26 Apr 2017 05:45:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=A8PH9MVBmKKp5u12p8 vVojoDlYvYFIRZJUgXzIWaDx8=; b=dme3eZv/LXIMiLQc5ZWEI3pZslKF8uZJPC cAA5fjyVwjObcbli0oYNKwAz9RmBzq5lf7EKXaWaAFfR/TZEyo0wsXLKi+zAH9PS +L1hGOpHpf9AkGgWu+pMrJJanyCJcHatj2jZ/9OVfmfWv4g3tMBWfOvO2eoX5NmL 8bAEz0ZNIDCJPNpD1FfLIND+uiHO/5vFE+CPgj8s5rCMmSen1AOfUXN39EEVzYwZ FTtcp8334PJJ+AFHdx/g1B4JsKC7jIsDUDmIgKQSaSgRFOzhQqLkHX8e3YuW1C15 X6kFlZBr9PZgMjkC7cT2chTEYyucFrTh80mPHvAr5ua6i0mbmIJg== 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=A8PH9MVBmKKp5u12p8vVojoDlYvYFIRZJUgXzIWaDx8=; b=SWk5zGto aOTahgKSpxl/L2C39sqOH5UehRvSjF/XVgkvtIsAvG/iBI9mmL7K4PcCGFJjEXiO QLRn6T3AxmkEA0TNSuXkFo4wLY0ewR35DJ9yjwoE101P9lfHOlsCKAkuxKgG/y8V xGxZSG44VWiAw2u6BSWV7aOGB+CWbA8ZbPtleQMqcd9q8vi2u/j+CeXN+ZcHPO7b zD72wpz03stKF2gjARq+n/Yfmy0PUVYmhqfLT4vHxWUNF+HbPLbAbvpoSS2idlIs 1uo6WA97Cfl0T35RmF1OgOKuRHwaQK13YVSuy0cp4rRsWtMrI+bmQgtkvmBjsz2D 1LRJa83Asf3Qhg== X-ME-Sender: X-Sasl-enc: gmE4Eq3mgyKg5jyrT8Km9TyQfRTFDyunYDV9Kv1jqUvg 1493199914 Received: from [10.212.112.115] (unknown [85.255.234.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 7376C7E6E3; Wed, 26 Apr 2017 05:45:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <149317168013.24864.5775398036404123780.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 11:00:52 +0100 Cc: The IESG , core-chairs@ietf.org, jaime.jimenez@ericsson.com, draft-ietf-core-links-json@ietf.org, core@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <149317168013.24864.5775398036404123780.idtracker@ietfa.amsl.com> To: Ben Campbell Archived-At: Subject: Re: [core] Ben Campbell's No Objection on draft-ietf-core-links-json-07: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:45:17 -0000 Hi Ben, > On 26 Apr 2017, at 02:54, Ben Campbell wrote: > > On a quick email scan, I gather that the discussion thread resulting from > Mark's ART-ART review has not completely resolved, at least as of the > time I reviewed the document. That probably needs to be resolved prior to > progressing the draft. Yes. A new revision will definitely be needed. From nobody Wed Apr 26 04:05:26 2017 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 DA14E129B39 for ; Wed, 26 Apr 2017 04:05:24 -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 NFkEp2yvcfvW for ; Wed, 26 Apr 2017 04:05:23 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A56A129B38 for ; Wed, 26 Apr 2017 04:05:23 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5CB1146D43; Wed, 26 Apr 2017 13:05:21 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 667D01CF; Wed, 26 Apr 2017 13:05:20 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2F7CF3BC; Wed, 26 Apr 2017 13:05:20 +0200 (CEST) Received: (nullmailer pid 18735 invoked by uid 1000); Wed, 26 Apr 2017 11:05:19 -0000 Date: Wed, 26 Apr 2017 13:05:19 +0200 From: 'Christian =?iso-8859-1?Q?Ams=FCss'?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20170426110519.b7wf6foiom6bbnnz@hephaistos.amsuess.com> References: <013c01d2be69$26723c70$7356b550$@augustcellars.com> <20170426090737.joqmfg5alcpi546i@hephaistos.amsuess.com> <014f01d2be76$d04a8a10$70df9e30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u2bz2rg3sykbxlkh" Content-Disposition: inline In-Reply-To: <014f01d2be76$d04a8a10$70df9e30$@augustcellars.com> User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [core] Is this a typo in -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 11:05:25 -0000 --u2bz2rg3sykbxlkh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 26, 2017 at 03:21:03AM -0700, Jim Schaad wrote: > where in RC 7959 does it say this? To be honest, I don't find it explicitly either; 7959 2.3 only says "The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set." -- I'd be a bit strange to send a final payload longer then the block size, but maybe it's even allowed? Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --u2bz2rg3sykbxlkh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlkAfusACgkQOY0REtOk veHPkQ/+JnYGsGfOnP+7eZa3OXbk3U0KAoAhlPvRImivj3XogZtpNclx+tJTOGWe MI9XfG6ZnCKPs5QVBrBheMne0H7ov6hnJpfESwwRE4ZagmKi6bbVjg+CeYkV3nOJ Cs/e5vxOGTlJuwFy+6v+0sB9C8VfP34M8BQz7XF2dOMg5p1h7u+cfoCh+korW//M V+jvxY3shFie6c+/1rz8L3VCGl8Ma9Ht0KT+xA2PykNYzFAVZbrIjJbHXmEaOK9y PtzqPqSV7ltxeVMA2n2jXPpmnU6Jyy9B/iFiCSs8q70onD19wZA1OyTChz3TwF8o DdfaETkiTh/LFNE7ken5PjqDPkphF5VzMHK+mfsxzh5zLmJSvV1ZnATZX41HrRpW tTDAF/AEue3vF/EDS/rqpFCmEO0wXmHS7kF4Q7dMyqRyNqcHgbKCt1rX+R0HbA87 kGGEHtgTVUiG1J2I13uUDhUP7AehyLC6ZzelnT1V9NdT7LS6WXVmi/3KS+ng3Sqn xKH1ORckuIKV55PYuf5GuZgxqtLOIuCUILOzFa0IYlbAxh7gWAKgvlYxXx6MHMqU gEtfIDjT30e1ypSZ27V+xbKAdxCrRDgaQcO5hh5oW7gANZfN0CEXD1LgyJl98jVQ KdbUoLUQKcHQEktL6XSUxuPI87j+cYU3t5yERSMgOduoav6BMBw= =xJnW -----END PGP SIGNATURE----- --u2bz2rg3sykbxlkh-- From nobody Wed Apr 26 04:51:35 2017 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 C2A1F129B47; Wed, 26 Apr 2017 04:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 WaQJqzGP6ehL; Wed, 26 Apr 2017 04:51:32 -0700 (PDT) Received: from mail4.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 1D3A2127867; Wed, 26 Apr 2017 04:51:31 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493207487; h=from:subject:to:date:message-id; bh=BnH5Spb1HBUni4OynGEHjz349KM2vxt/7YlVu8YBX2Y=; b=eWBGH9zPbDB2fnAJPdlzyVExYUeM3Vs4xGJcP2Xs53PwGZN40b697WHsS43zoNru3HDD6mlBW9v QRsbVOCA/UnK+Sc5ohIWwdYfOwl9lwg12qrFqBIHDJVibRRD/NAQb7cSlSwVgai2dpN67HR3IM7/5 dpRnj6q+XJXHVJHqedA5UjA+5lOTJrq6GYX3MZNyrhcZpeNECq14gP8J7BHzFLjA5N0ai/HjZ3GcF k6Eivd89Gi67AH/Hb6rmjDA6DNbdMzrFTCwruWcJAb3fHzTAeAqfR2iTWpkvZzOZ5NbNzMXFoltkx PUjRZX2bDyFTSTom0Xml1aYPf46gTWM3gaZA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 04:51:27 -0700 Received: from Hebrews (104.129.192.76) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 04:51:19 -0700 From: Jim Schaad To: 'Carsten Bormann' , =?UTF-8?Q?'Christian_Ams=C3=BCss'?= CC: , 'core' References: <013c01d2be69$26723c70$7356b550$@augustcellars.com> <20170426090737.joqmfg5alcpi546i@hephaistos.amsuess.com> <068A4DFE-6169-46A0-BBDD-C7583E3C724F@tzi.org> In-Reply-To: <068A4DFE-6169-46A0-BBDD-C7583E3C724F@tzi.org> Date: Wed, 26 Apr 2017 04:41:00 -0700 Message-ID: <015d01d2be81$fc3b77a0$f4b266e0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEUzt0OTMJBn4JlUXfFeaJjRZ/yEgF5bWMUAhP8UTajNutIQA== X-Originating-IP: [104.129.192.76] Archived-At: Subject: Re: [core] Is this a typo in -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 11:51:34 -0000 -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Wednesday, April 26, 2017 2:11 AM To: Christian Ams=C3=BCss Cc: Jim Schaad ; = draft-ietf-core-coap-tcp-tls@ietf.org; core Subject: Re: [core] Is this a typo in -08 > On Apr 26, 2017, at 11:07, Christian Ams=C3=BCss = wrote: >=20 > On Wed, Apr 26, 2017 at 01:43:14AM -0700, Jim Schaad wrote: >> In descriptive usage, a BERT Option is interpreted in the same way as >> the equivalent Option with SZX =3D=3D 6, except that the payload is = also >> allowed to contain a multiple of 1024 bytes (non-final BERT block) = or >> more than 1024 bytes (final BERT block). >>=20 >> However I think that the last sentence should read "less than 1024 = bytes". >=20 > Sounds right to me: It extends what is already permitted for SZX=3D6,=20 > and > <=3D1024 is already allowed for final SZX=3D6 blocks. (In effect, the = last=20 > BERT block can have any length, only limited by Max-Message-Size). Yes. This seems to be the second time that someone stumbles about that = wording; maybe we can find a better way to say this. [JLS] I think I now understand what this text is supposed to be saying. "except that the payload is also allowed to contain multiple blocks. = For non-final BERT blocks, the payload is always a multiple of 1024 = bytes.=20 For final BERT blocks, the payload is a multiple (possibly 0) of 1024 = bytes plus a partial block of less than 1024 bytes." Jim Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 26 07:12:48 2017 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 7ED4A12EA93; Wed, 26 Apr 2017 07:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-core-links-json@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149321596651.31812.12338305737790192867.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 07:12:46 -0700 Archived-At: Subject: [core] Alissa Cooper's Discuss on draft-ietf-core-links-json-07: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:12:46 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-core-links-json-07: Discuss 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-links-json/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to see the major issue raised by Elwyn in his Gen-ART review resolved before this document proceeds: https://datatracker.ietf.org/doc/review-ietf-core-links-json-07-genart-lc-davies-2017-04-25/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Elwyn's review contains a number of minor issues on which the authors are already engaging (thanks!). https://datatracker.ietf.org/doc/review-ietf-core-links-json-07-genart-lc-davies-2017-04-25/ From nobody Wed Apr 26 07:21:21 2017 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 D8ACC12EC6D; Wed, 26 Apr 2017 07:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QlbgIf9h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VTIHCQM5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbhUtUMEKzyY; Wed, 26 Apr 2017 07:20:59 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C363C12EAA8; Wed, 26 Apr 2017 07:13:53 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 401E82148F; Wed, 26 Apr 2017 10:13:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 26 Apr 2017 10:13:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FoOpNf1wunpNHLG16T GDzYkvX7aWLPJ4GCr4fxmWhME=; b=QlbgIf9hpyLAczQ6dqnotspcVG0Ds1iOhP LxRZOwKpmaJ01In/LPpRsbcIZ8MWtE4qr3qht9arQmdx3Ds7TrZpBlYyL0+9COEr dr6RIjTf96J9nAexwODNBMKU316l6yN1k2VCxUmuJWj1vNyOUS3R9d+tJ4+wPwb1 fvZHsU3L6ofJdwVG/dwVimRifWF0zy6rtgOW+eeJWVZp0Qa9eIPezYP5NcwEk0E7 MbX2tbi511PSPB2rIbdZdUKX0sZovD/WJPce162l/SajEi5bhiwwSJSyKt84m2c3 yI8Ei7BK6PKcQ4XYBy4xFBdWBf3o44cg26/pm/8M/5anH97KuloQ== 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=FoOpNf1wunpNHLG16TGDzYkvX7aWLPJ4GCr4fxmWhME=; b=VTIHCQM5 xRcCBvj10sW+545XF5yndDcWSSEanVc1k0dCw1zYWa2182Znxh3z4RFFKSTeFp9k Fp4pcJYr0X2b0KWXZOJZt9WcSmyHMEc906XpS0TrJBqe4JOVUT1txCG2NlASAr5N ISa5Sb3nFbcTL/ouXymftKaLe4sYD12FPMMMbBEvuXB7aih29IuVWTtO8OgDKb/D ZJMg0n/wfayjtwF4uqfvaWr4C9SYSaMF3orh9dIvlnszRSRJlPTA6vDArR5gzlO2 nJ/BVbyr1OnngFlbouKXBc26inA9TgXQvWDduYzfxjDEpJPBonoAon5J9Ew8iEVr n7RrCYOZ8s9Wxg== X-ME-Sender: X-Sasl-enc: BaM8S32cIUuJonPPxeKpHo/c5Wj+TM/UPs9RmY8tafer 1493216032 Received: from [10.24.116.101] (unknown [128.107.241.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AB6C24765; Wed, 26 Apr 2017 10:13:51 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149315879365.13684.3263173090290877403@ietfa.amsl.com> Date: Wed, 26 Apr 2017 10:13:50 -0400 Cc: gen-art@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <62FD1D61-8C72-45EB-9614-95CA14B91D7B@cooperw.in> References: <149315879365.13684.3263173090290877403@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:21:01 -0000 Elwyn, many thanks for your review. I=E2=80=99ve included it in my = ballot position and am holding a DISCUSS while the major issue gets = resolved. Authors/WG, thanks for engaging with Elwyn=E2=80=99s review. Alissa > On Apr 25, 2017, at 6:19 PM, Elwyn Davies = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Not Ready >=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-links-json-07 > Reviewer: Elwyn Davies > Review Date: 2017-04-25 > IETF LC End Date: 2017-04-21 > IESG Telechat date: 2017-04-27 >=20 > Summary:Not ready for publication. There a number of issues that need > to be addressed as discussed below. In particular whether the > formats could be returned as the web link specification instead of RFC > 6990 format in response to a GET /.well-known/core request. >=20 > Having thought about the quote stripping/addition issue cited in Adam > Roach's DISCUSS, I would take a slightly different view... see below. >=20 > Major issues: >=20 > Intentions: > Is it one of the intentions of this draft that a server should be able > to return web link descriptions using JSON or CBOR, specifically in > response to GET /.well-known/core? Content formats for the new > formats are registered (s3.2) - could a user ask for the alternative > formats by specifying at ct filter with the GET request? It strikes > me that if one has a constrained server of sufficiently limited > capabilities that it wants to use CBOR then having to encode the RFC > 6690 format responses for the web links requests is wasting resources. > Some more thought needs to be given to this as an update to RFC 6690 > - If I read correctly, RFC 6690 implicitly requires that a response to > GET /.well-known/core MUST be encoded as described in RFC6690. >=20 > Minor issues: > Title: The document appears only to address the CoRE Web Links format > rather than any other. Should the title reflect this more precisely, > e.g., > Representing CoRE Web Links Format in JSON and CBOR >=20 > s1.1: Concerning: > o The simplest thing that could possibly work >=20 > * Do not cater for RFC 5988 complications caused by HTTP > header > character set issues [RFC2047] >=20 > Having ferreted around in RFC 5988 and RFC 2047, I can't see what is > being referred to here. However, I observe later that the "title*" > attribute (with language specifier) does not appear to be supported > (It is missing from Table 1) - is this what is relevant here? If so it > needs clarification.=20 > [Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing > external references to various productions (e.g., ext-value, > quoted-string) that are defined in other documents - in the given > examples RFC 2987, RFC 2616.] >=20 > s2.2/s5: This statement: > The resulting structure can be represented in CDDL > [I-D.greevenbosch-appsawg-cbor-cddl] as: >=20 > requires that the CDDL draft is a normative reference rather than > informative. > [Aside: Having skimmed the CDDL draft, I am of the opinion that a > good deal more work will be needed to get this ready for publication, > possibly to the extent that the CDDL quoted here becomes invalid.=20 > Given the simplicity of the specification could it be done without the > use of CDDL?]=20 >=20 > s2.2: There needs to be some discussion of handling of double quoted > and non-double quoted strings during conversion: > I think it works to require that... >> =46rom RFC 6690 to JSON: > - If the parameter value is a double quoted string then it should have > the double quotes stripped, any necessary JSON character encodings > performed and the double quotes repapplied. > - if the parameter value is anything else, then the necessary JSON > character encodings are done and the result enclosed in double > quotes. > [what about % encodings on the RFC 6690 side?] >=20 >> =46rom RFC 6690 to CBOR: > - If the parameter value is a double quoted string, the double quotes > are stripped and the result used as the CBOR string type value. > - Otherwise, the parameter value is used as the CBOR string value.=20 > [what about % encodings on the RFC 6690 side?] >=20 >> =46rom JSON to RFC 6690:=20 > - Remove the double quotes from the JSON string value and do any > necessary decoding and encoding. Reapply double quotes. Note that > this may result in values that were originally not enclosed in double > quotes in the RFC 6690 repreentation becoming enclosed in double > quotes. However, [AFAICS] this does not alter the semantics of any of > the predefined parameters. For example the ABNF productions mean that > ct=3D40 and ct=3D"40" are equivalent (the second case is needed so = that > one can also have ct=3D"40 41 42"). What IS needed is a statement = that > this must also apply to any application specific parameters. For > example the case in examples 4 and 5 of ..;foo=3D"bar";foo=3D3;... > transforming to "foo":["bar","3"] and then back to > ...;foo=3D"bar";foo=3D"3";.. MUST require that the two RFC 6690 > representations are equivalent. >=20 >> =46rom CBOR to RFC 6690:=20 > [Essentially the same process - decode/encode and apply double quotes. > The discussion of equivalent semantics is equally applicable.] >=20 > The conversion from CBOR to JSON or in reverse is similar.=20 >=20 > s2.3: It is not stated whether a CBOR decoder should accept literal > use of the encodable parameters - i.e., if the encoded CBOR contains [ > "href": "/mumble" ] rather than [1 : "mumble=C2=A3 ] in CDDL format.=20= > Similarly, should the use of the encoded values be mandatory on the > CBOR encoder? >=20 > s2.3, Table 1: Is the omission of title* from the list of parameter > names deliberate? If so the omission justifies a note and rationale.=20= > Clearly the format of the value for a title* parameter is different > from all the others, which may have something to do with this. >=20 > s2.3/s5: eEfereences in Table 1 make RFC 7252 and RFC 7641 normative. >=20 > Nits/editorial comments:=20 > s1: s/e.g. /e.g., / (two places) >=20 > s1.1: The term "round-tripping" and the associated text are opaque > jargon that would normally be applied to message transmission round a > loop rather than format conversion. A more explicit formulation would > help naive readers. Suggest (if I understand what was intended): > OLD: > o Canonical mapping >=20 > * lossless round-tripping with [RFC6690] and between JSON and > CBOR >=20 > * but not trying for bit-preserving (DER-style) round-tripping > NEW: > o Canonical mapping >=20 > * supporting inter-conversion in both directions between any > pair=20 > of [RFC6690] format and the CBOR and JSON formats defined > here=20 > with unaltered and unambiguous semantics >=20 > * but not attempting to ensure that a sequence of conversions > from=20 > one of the formats through one or both of the others and back > to=20 > the original would result in an identical representation > (c.f.,=20 > as might be achieved by different BER transcoders rather than > by all=20 > DER transcoders with ASN.1 [X.690]). > ENDS > This needs an informative reference to X.690 ... but I am not sure > that the DER comparison is essential. >=20 > s2.2: Suggest: > OLD: > We straightforwardly map: >=20 > o the outer collection to an array of links; >=20 > o each link to a JSON object or CBOR map, mapping attribute names > to > attribute values. >=20 > NEW: > We straightforwardly map: >=20 > o the outer collection to an array of parameterized web links; >=20 > o each parameterized web link to a JSON object or CBOR map, > mapping attribute names to > attribute values. > ENDS >=20 > s2.2: > OLD: > The resulting structure can be represented in CDDL > [I-D.greevenbosch-appsawg-cbor-cddl] as: > NEW: > The resulting structure can be represented in CBOR Data Definition > Language (CDDL) > [I-D.greevenbosch-appsawg-cbor-cddl] as shown in Figure 1. >=20 > s2.4: Note that the use of ct=3D40 in RFC 6690 is an anchronism. The = ct > parameter appeared in earlier versions of the draft that led to RFC > 6690 but was moved out to be used more generally in CoAP and is > actually defined in RFC 7252 as mentioned in Table 1 here. Thus use > of ct=3D40 in the example copied from RFC 6690 really needs an erratum > for 6690 but that is for another day! =20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Apr 26 08:52:59 2017 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 B00FE131476; Wed, 26 Apr 2017 08:52:50 -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 rHfLtRPALlI5; Wed, 26 Apr 2017 08:52:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BED131460; Wed, 26 Apr 2017 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3QFpku5028088; Wed, 26 Apr 2017 17:51:46 +0200 (CEST) Received: from client-0227.vpn.uni-bremen.de (client-0227.vpn.uni-bremen.de [134.102.107.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCl1s6lR2zDH15; Wed, 26 Apr 2017 17:51:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> Date: Wed, 26 Apr 2017 17:51:45 +0200 Cc: IETF , Julian Reschke , art@ietf.org, draft-ietf-core-links-json.all@ietf.org, "core@ietf.org WG" , Erik Wilde , Herbert Van de Sompel X-Mao-Original-Outgoing-Id: 514914705.088075-62d7dcc2c4f9f617e52eb3a25c091a6c Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> To: "Roy T. Fielding" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:52:51 -0000 On Apr 25, 2017, at 23:25, Carsten Bormann wrote: >=20 > OK, let me start typing that errata report then. Below is a draft errata report. Is this information correct? Is it sufficient? Obviously, this errata report doesn=E2=80=99t by itself answer the = important questions raised about links-json, but it might be a useful = outcome of this discussion anyway. Gr=C3=BC=C3=9Fe, Carsten Report Errata for RFC6690 Date: 2017-04-26 Name: Carsten Bormann Email: cabo@tzi.org Type: Editorial Section: 2 Original Text: [...] In order to convert an HTTP Link Header field to this link format, first the "Link:" HTTP header is removed, any linear whitespace (LWS) is removed, the header value is converted to UTF-8, and any percent- encodings are decoded. Corrected Text: (add after unchanged original text:) Note that this percent-decoding damages URIs that percent-encode reserved characters (i.e., characters out of ":/?#[]@!$&'()*+,;=3D", not including the double quotes). Such URIs therefore generally cannot be successfully used with RFC 6690 link-format. Notes: Fully percent-decoding URIs before placing them into the link-format reduces complexity in processing link-format, but creates a limitation on the set of URIs that link-format faithfully can represent. This may not be as widely known as is desirable, creating a pitfall for unwitting users of RFC 6990. From nobody Wed Apr 26 10:12:57 2017 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 9432712955D; Wed, 26 Apr 2017 10:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsqE8Dichnhf; Wed, 26 Apr 2017 10:12:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ACCBB131544; Wed, 26 Apr 2017 10:12:54 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QHCgq7059727 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 12:12:43 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Elwyn Davies , gen-art@ietf.org Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org References: <149315879365.13684.3263173090290877403@ietfa.amsl.com> From: Adam Roach Message-ID: <20e3b49f-4868-bc4e-baa9-ec777fdf34f2@nostrum.com> Date: Wed, 26 Apr 2017 12:12:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <149315879365.13684.3263173090290877403@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:12:56 -0000 On 4/25/17 17:19, Elwyn Davies wrote: > >From JSON to RFC 6690: > - Remove the double quotes from the JSON string value and do any > necessary decoding and encoding. Reapply double quotes. Note that > this may result in values that were originally not enclosed in double > quotes in the RFC 6690 repreentation becoming enclosed in double > quotes. However, [AFAICS] this does not alter the semantics of any of > the predefined parameters. For example the ABNF productions mean that > ct=40 and ct="40" are equivalent (the second case is needed so that > one can also have ct="40 41 42"). What IS needed is a statement that > this must also apply to any application specific parameters. For > example the case in examples 4 and 5 of ..;foo="bar";foo=3;... > transforming to "foo":["bar","3"] and then back to > ...;foo="bar";foo="3";.. MUST require that the two RFC 6690 > representations are equivalent. This has the reciprocal problem that using quotes with (e.g.) sz and hreflang is a violation of the ABNF in RFC6690. /a From nobody Wed Apr 26 11:20:59 2017 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 2EE9C13156A; Wed, 26 Apr 2017 11:20:58 -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 4yTDYMOUd1-9; Wed, 26 Apr 2017 11:20:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40982131565; Wed, 26 Apr 2017 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3QIKnc6028132; Wed, 26 Apr 2017 20:20:49 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCpKs0RWgzDH41; Wed, 26 Apr 2017 20:20:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20e3b49f-4868-bc4e-baa9-ec777fdf34f2@nostrum.com> Date: Wed, 26 Apr 2017 20:20:47 +0200 Cc: Elwyn Davies , gen-art@ietf.org, IETF , core , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514923647.182059-f87b135b40f402b437f2bb96c0d3467d Content-Transfer-Encoding: quoted-printable Message-Id: References: <149315879365.13684.3263173090290877403@ietfa.amsl.com> <20e3b49f-4868-bc4e-baa9-ec777fdf34f2@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:20:58 -0000 On Apr 26, 2017, at 19:12, Adam Roach wrote: >=20 > This has the reciprocal problem that using quotes with (e.g.) sz and = hreflang is a violation of the ABNF in RFC6690. Yes. Using ABNF for the serialization of an item that should be = described at the data model level (as in 5988bis) is now generally = considered a mistake. To stay compatible with the letter of RFC 6690 = (which probably continues to be a good idea), the reference = implementation in Appendix A of links-json uses the quote-less form = whenever the value is a ptoken, i.e. a sequence of one or more = ptokenchar characters(*). Should we require this, and if yes, should = this be a SHOULD or a MUST? Gr=C3=BC=C3=9Fe, Carsten (*) ptoken =3D 1*ptokenchar ptokenchar =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" From nobody Wed Apr 26 11:46:11 2017 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 3EF7512944D; Wed, 26 Apr 2017 11:46:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-core-links-json@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149323236924.2991.7582327201057511378.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 11:46:09 -0700 Archived-At: Subject: [core] Alia Atlas' No Objection on draft-ietf-core-links-json-07: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:46:09 -0000 Alia Atlas has entered the following ballot position for draft-ietf-core-links-json-07: 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-links-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I did notice that " (Comment to be deleted before submitting this document to the IESG: This list should, again, be checked against relevant references at WGLC time.)" under Table 1 wasn't, in fact, deleted. Has the relevant check been made? From nobody Wed Apr 26 13:41:10 2017 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 B2762127342; Wed, 26 Apr 2017 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugdmQL8N_CtH; Wed, 26 Apr 2017 13:40:58 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0119.outbound.protection.outlook.com [104.47.37.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470B51294AB; Wed, 26 Apr 2017 13:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Ptx+E0wD+L9YgNzm1wTcXzqcziuDkqg6YEGGA2F1JQ=; b=eDMYULUEMBh1Rx4yJaro2mNmxpRs1Bx0b032nXmJoWtOuXXsCM3J99/003Xy5IIxdjzEyyyVAqB7MIR9/FIAvoSqk3mQ/TJW6LNnla/sbv5PUpZa0z+SdKbvPFnL+oePmWsulcnRdOGY/yXaTqpgdPt4QGpU1tn3EBkCmcOziB4= Received: from CY1PR21MB0087.namprd21.prod.outlook.com (10.161.169.140) by CY1PR21MB0088.namprd21.prod.outlook.com (10.161.169.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.0; Wed, 26 Apr 2017 20:40:55 +0000 Received: from CY1PR21MB0087.namprd21.prod.outlook.com ([10.161.169.140]) by CY1PR21MB0087.namprd21.prod.outlook.com ([10.161.169.140]) with mapi id 15.01.1075.000; Wed, 26 Apr 2017 20:40:55 +0000 From: Brian Raymor To: Jim Schaad , 'Carsten Bormann' , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= CC: "draft-ietf-core-coap-tcp-tls@ietf.org" , 'core' Thread-Topic: [core] Is this a typo in -08 Thread-Index: AdK+aQzsAiYCPhiESlGRpkR4uC1l0QAA3+SAAAAc6YAABT5yAAASzE/g Date: Wed, 26 Apr 2017 20:40:55 +0000 Message-ID: References: <013c01d2be69$26723c70$7356b550$@augustcellars.com> <20170426090737.joqmfg5alcpi546i@hephaistos.amsuess.com> <068A4DFE-6169-46A0-BBDD-C7583E3C724F@tzi.org> <015d01d2be81$fc3b77a0$f4b266e0$@augustcellars.com> In-Reply-To: <015d01d2be81$fc3b77a0$f4b266e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR21MB0088; 7:Ym+IddU+u5U1mbHi434UpeijZ+uNYYZ2wM7gFVmu1UOorbPa8IvTZkcG/9bTgw3IIZW0/jAS8WnVw0ip9KuqlGbNIea1uYRcPQzwxhbRlkicAxrNCKiDUpcjacHIiQ27bvKTAuYJ0ys/26PsQmX5ysG0JuW9vlApdzp0f6gEb+YIQQzczDY2I7Xhp2nPrRetH+4/XSgpf6UE7HtzPBbfcjLFhe9Uoa7eSWCHPoc7FhyAYlizIkvkKnrSEpK4cDFD4KTcpyB05d/A7s5nS3yiq+mU3H6+9RxlJQRonsKWVVDWn+ajY1W6Shr50TqLA/KewQ85HktrFkNuymO9NCs2LkLaGK04T2ksazMt22T3Zn0= x-ms-office365-filtering-correlation-id: 2099bb6a-76ec-47fe-738e-08d48ce489ac x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR21MB0088; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR21MB0088; BCL:0; PCL:0; RULEID:; SRVR:CY1PR21MB0088; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(39860400002)(39850400002)(51444003)(13464003)(24454002)(377454003)(7696004)(99286003)(66066001)(8936002)(189998001)(54906002)(5660300001)(4326008)(55016002)(2950100002)(8990500004)(10290500003)(6116002)(3660700001)(102836003)(122556002)(3846002)(81166006)(3280700002)(86362001)(2906002)(86612001)(5005710100001)(38730400002)(93886004)(6436002)(6506006)(50986999)(54356999)(76176999)(2900100001)(77096006)(229853002)(305945005)(25786009)(53546009)(6246003)(7736002)(53936002)(74316002)(9686003)(33656002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR21MB0088; H:CY1PR21MB0087.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 20:40:55.4893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR21MB0088 Archived-At: Subject: Re: [core] Is this a typo in -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:41:00 -0000 VHJhY2tpbmcgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vl cy8xNDMgZm9yIGNvYXAtdGNwLXRscy0wOS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXSANClNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMjYsIDIwMTcgNDo0MSBBTQ0KVG86ICdDYXJzdGVuIEJvcm1hbm4n IDxjYWJvQHR6aS5vcmc+OyAnQ2hyaXN0aWFuIEFtc8O8c3MnIDxjLmFtc3Vlc3NAZW5lcmd5aGFy dmVzdGluZy5hdD4NCkNjOiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzQGlldGYub3JnOyAn Y29yZScgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2NvcmVdIElzIHRoaXMgYSB0eXBv IGluIC0wOA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4g Qm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI2 LCAyMDE3IDI6MTEgQU0NClRvOiBDaHJpc3RpYW4gQW1zw7xzcyA8Yy5hbXN1ZXNzQGVuZXJneWhh cnZlc3RpbmcuYXQ+DQpDYzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRy YWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHNAaWV0Zi5vcmc7IGNvcmUgPGNvcmVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2NvcmVdIElzIHRoaXMgYSB0eXBvIGluIC0wOA0KDQoNCj4gT24gQXBy IDI2LCAyMDE3LCBhdCAxMTowNywgQ2hyaXN0aWFuIEFtc8O8c3MgPGMuYW1zdWVzc0BlbmVyZ3lo YXJ2ZXN0aW5nLmF0PiB3cm90ZToNCj4gDQo+IE9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDAxOjQz OjE0QU0gLTA3MDAsIEppbSBTY2hhYWQgd3JvdGU6DQo+PiBJbiBkZXNjcmlwdGl2ZSB1c2FnZSwg YSBCRVJUIE9wdGlvbiBpcyBpbnRlcnByZXRlZCBpbiB0aGUgc2FtZSB3YXkgYXMNCj4+ICAgdGhl IGVxdWl2YWxlbnQgT3B0aW9uIHdpdGggU1pYID09IDYsIGV4Y2VwdCB0aGF0IHRoZSBwYXlsb2Fk IGlzIGFsc28NCj4+ICAgYWxsb3dlZCB0byBjb250YWluIGEgbXVsdGlwbGUgb2YgMTAyNCBieXRl cyAobm9uLWZpbmFsIEJFUlQgYmxvY2spIG9yDQo+PiAgIG1vcmUgdGhhbiAxMDI0IGJ5dGVzIChm aW5hbCBCRVJUIGJsb2NrKS4NCj4+IA0KPj4gSG93ZXZlciBJIHRoaW5rIHRoYXQgdGhlIGxhc3Qg c2VudGVuY2Ugc2hvdWxkIHJlYWQgImxlc3MgdGhhbiAxMDI0IGJ5dGVzIi4NCj4gDQo+IFNvdW5k cyByaWdodCB0byBtZTogSXQgZXh0ZW5kcyB3aGF0IGlzIGFscmVhZHkgcGVybWl0dGVkIGZvciBT Wlg9NiwgDQo+IGFuZA0KPiA8PTEwMjQgaXMgYWxyZWFkeSBhbGxvd2VkIGZvciBmaW5hbCBTWlg9 NiBibG9ja3MuIChJbiBlZmZlY3QsIHRoZSBsYXN0IA0KPiBCRVJUIGJsb2NrIGNhbiBoYXZlIGFu eSBsZW5ndGgsIG9ubHkgbGltaXRlZCBieSBNYXgtTWVzc2FnZS1TaXplKS4NCg0KWWVzLg0KDQpU aGlzIHNlZW1zIHRvIGJlIHRoZSBzZWNvbmQgdGltZSB0aGF0IHNvbWVvbmUgc3R1bWJsZXMgYWJv dXQgdGhhdCB3b3JkaW5nOyBtYXliZSB3ZSBjYW4gZmluZCBhIGJldHRlciB3YXkgdG8gc2F5IHRo aXMuDQoNCltKTFNdIEkgdGhpbmsgSSBub3cgdW5kZXJzdGFuZCB3aGF0IHRoaXMgdGV4dCBpcyBz dXBwb3NlZCB0byBiZSBzYXlpbmcuDQoNCiJleGNlcHQgdGhhdCB0aGUgcGF5bG9hZCBpcyBhbHNv IGFsbG93ZWQgdG8gY29udGFpbiBtdWx0aXBsZSBibG9ja3MuICBGb3Igbm9uLWZpbmFsIEJFUlQg YmxvY2tzLCB0aGUgcGF5bG9hZCBpcyBhbHdheXMgYSBtdWx0aXBsZSBvZiAxMDI0IGJ5dGVzLiAN CkZvciBmaW5hbCBCRVJUIGJsb2NrcywgdGhlIHBheWxvYWQgaXMgYSBtdWx0aXBsZSAocG9zc2li bHkgMCkgb2YgMTAyNCBieXRlcyBwbHVzIGEgIHBhcnRpYWwgYmxvY2sgb2YgbGVzcyB0aGFuIDEw MjQgYnl0ZXMuIg0KDQpKaW0NCg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCg0K From nobody Wed Apr 26 14:37:45 2017 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 DF49A1292CE; Wed, 26 Apr 2017 14:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXoZCa_LWWsv; Wed, 26 Apr 2017 14:37:42 -0700 (PDT) Received: from homiemail-a121.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B37912709D; Wed, 26 Apr 2017 14:37:42 -0700 (PDT) Received: from homiemail-a121.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a121.g.dreamhost.com (Postfix) with ESMTP id CB86F60001A09; Wed, 26 Apr 2017 14:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=kTIV2paK+Y/7/+g0K87Ygnu4MQU=; b=BqwGNUhv3uZYNaYSBiQb63Bk6WRC NXP3WFn5IB2klpPiHQ8MQtHOugvE/9zovU3en5vfRPgEZuYx3YiDAosgh0vjO9aZ fiL0/EcM2sL520MlTYQCWTbhpfgHfyalY2lxmDtrxUYHHtLM9NkrFjpb2gEeTr3o L4Pp/6U5bd3EhHo= Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a121.g.dreamhost.com (Postfix) with ESMTPSA id 103D360001104; Wed, 26 Apr 2017 14:37:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: Date: Wed, 26 Apr 2017 14:37:40 -0700 Cc: IETF , Julian Reschke , art@ietf.org, Herbert Van de Sompel , "core@ietf.org WG" , Erik Wilde , draft-ietf-core-links-json.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8E2E3319-0540-441C-A2D3-2325FBE199D9@gbiv.com> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:37:44 -0000 > On Apr 26, 2017, at 8:51 AM, Carsten Bormann wrote: >=20 > On Apr 25, 2017, at 23:25, Carsten Bormann wrote: >>=20 >> OK, let me start typing that errata report then. >=20 > Below is a draft errata report. >=20 > Is this information correct? No. An RFC that isn't interoperable (in this case, because it contradicts its own normative references) is a design error. I don't agree with the entire contents of RFC6690. The abstract alone = is enough for me to drop it in the nearest recycling bin; the design has nothing to do with REST (an architectural style, not an architecture). Nevertheless, the error (a non-interoperable design error) in RFC6690 is = in section 4.1. It is either a bad URI template (if the examples are = correct) or a bad description of how to process that template. /.well-known/core{?search*} RFC6570 requires that the above template's values be pct-encoded during expansion, so the examples given in 4.1: The following are examples of valid query URIs: o ?href=3D/foo matches a link-value that is anchored at /foo o ?href=3D/foo* matches a link-value that is anchored at a URI that starts with /foo o ?foo=3Dbar matches a link-value that has a target attribute named foo with the exact value bar o ?foo=3Dbar* matches a link-value that has a target attribute named foo, the value of which starts with bar, e.g., bar or barley o ?foo=3D* matches a link-value that has a target attribute named foo are almost all wrong. They would have to be The following are examples of valid query URIs: o ?href=3D%2Ffoo matches a link-value that is anchored at /foo o ?href=3D%2Ffoo%2A matches a link-value that is anchored at a URI = that starts with /foo o ?foo=3Dbar matches a link-value that has a target attribute named foo with the exact value bar o ?foo=3Dbar%2A matches a link-value that has a target attribute = named foo, the value of which starts with bar, e.g., bar or barley o ?foo=3D%2A matches a link-value that has a target attribute named = foo Alternatively, if the examples are correct, the specification needs to = replace the above URI template with a more accurate list of such templates to = match the examples: /.well-known/core /.well-known/core?href=3D{+reference} /.well-known/core?anchor=3D{+anchor} /.well-known/core?type=3D{+mt} /.well-known/core{?rel} /.well-known/core{?rev} /.well-known/core{?hreflang} /.well-known/core{?media} /.well-known/core{?title} /.well-known/core{?rt} /.well-known/core{?if} /.well-known/core{?sz} /.well-known/core{?link-extension*} /.well-known/core?href=3D{+reference}* /.well-known/core?anchor=3D{+anchor}* /.well-known/core?type=3D{+mt}* /.well-known/core{?rel}* /.well-known/core{?rev}* /.well-known/core{?hreflang}* /.well-known/core{?media}* /.well-known/core{?title}* /.well-known/core{?rt}* /.well-known/core{?if}* /.well-known/core{?sz}* /.well-known/core{?link-extension*}* ... [note that this still has an ambiguity problem for href string values that happen to end in "*"] and then the text in 4.1 should be fixed as well: Original Text: Value Strings are percent-decoded ([RFC3986], Section 2.1) before matching; similarly, Corrected Text: Value Strings for the href, anchor, and type attributes (reserved = templates) are not percent-decoded ([RFC3986], Section 2.1) before matching; for all other templates, Value Strings are percent-decoded only once before matching; note that a value which originally contained a percent-encoded triplet of "%20" would be encoded as "%2520" by a non-reserved template expansion and restored here as "%20". = Similarly, The above would make RFC6690 consistent with its normative references. A more sensible design would separate the response format (which is fine as a media type) from the query syntax (which doesn't need to be limited to link attributes anyway). ....Roy From nobody Thu Apr 27 04:21:16 2017 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 910BB1293D8; Thu, 27 Apr 2017 04:21:15 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149329207554.2847.8641454252020382358@ietfa.amsl.com> Date: Thu, 27 Apr 2017 04:21:15 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-links-json-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 11:21:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-08.txt Pages : 18 Date : 2017-04-27 Abstract: JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-links-json-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-links-json-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-08 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 Thu Apr 27 04:25:08 2017 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 C467A1293E3 for ; Thu, 27 Apr 2017 04:25:07 -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 maaMRrD1BBzy for ; Thu, 27 Apr 2017 04:25:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D88E1293DF for ; Thu, 27 Apr 2017 04:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3RBP2a3024438 for ; Thu, 27 Apr 2017 13:25:02 +0200 (CEST) Received: from client-0199.vpn.uni-bremen.de (client-0199.vpn.uni-bremen.de [134.102.107.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wDF3f4D9XzDHLG; Thu, 27 Apr 2017 13:25:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149329207554.2847.8641454252020382358@ietfa.amsl.com> Date: Thu, 27 Apr 2017 13:25:01 +0200 X-Mao-Original-Outgoing-Id: 514985101.589476-6cef3d07fc20be60727f1d93a1ed7f7c Content-Transfer-Encoding: quoted-printable Message-Id: <26514688-0CAA-4810-9A7F-B77A0660C93D@tzi.org> References: <149329207554.2847.8641454252020382358@ietfa.amsl.com> To: core X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-links-json-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 11:25:08 -0000 Ahead of today=E2=80=99s IESG meeting, I have tried to resolve some of = the IESG and directorate comments. The comments from the detailed review from Mark Nottingham require some = additional work, as does =E2=80=9CAdam=E2=80=99s issue number 2=E2=80=9D = (as called out in the document). And I have probably missed one or two = other comments. Please have a look at=20 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-links-json-08.txt and check that the changes do not cause you any problems. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 27 05:14:12 2017 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 DD1CA129456; Thu, 27 Apr 2017 05:14:02 -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 AbutmvIZvloN; Thu, 27 Apr 2017 05:14:01 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0567712948B; Thu, 27 Apr 2017 05:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3RCDriC003980; Thu, 27 Apr 2017 14:13:53 +0200 (CEST) Received: from client-0199.vpn.uni-bremen.de (client-0199.vpn.uni-bremen.de [134.102.107.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wDG814t1rzDHMD; Thu, 27 Apr 2017 14:13:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149323236924.2991.7582327201057511378.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 14:13:53 +0200 Cc: The IESG , draft-ietf-core-links-json@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 514988033.101547-52945968fd3de3d02838fc5ea123dae2 Content-Transfer-Encoding: quoted-printable Message-Id: <3D4BE6F2-4EAE-4C41-BB3B-2BE06B3591BF@tzi.org> References: <149323236924.2991.7582327201057511378.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Alia Atlas' No Objection on draft-ietf-core-links-json-07: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:14:03 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I did notice that >=20 > " (Comment to be deleted before submitting this document to the = IESG: > This list should, again, be checked against relevant references at > WGLC time.)" under Table 1 wasn't, in fact, deleted. Has the > relevant check > been made? Hi Alia, thank you for noticing this =E2=80=94 we left this in for one round too = many=E2=80=A6 Gone in -08. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-links-json-08.txt Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 27 05:30:48 2017 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 2B685129463; Thu, 27 Apr 2017 05:30:39 -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 nqUhh2g3iTSg; Thu, 27 Apr 2017 05:30:37 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF56A1273B1; Thu, 27 Apr 2017 05:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3RCURe0018959; Thu, 27 Apr 2017 14:30:27 +0200 (CEST) Received: from client-0199.vpn.uni-bremen.de (client-0199.vpn.uni-bremen.de [134.102.107.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wDGW70pv5zDHMX; Thu, 27 Apr 2017 14:30:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <720C9B43-B803-4C99-A366-3C79F463FB23@tzi.org> Date: Thu, 27 Apr 2017 14:30:26 +0200 Cc: gen-art@ietf.org, ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514989026.323576-92920dfcf09ad9fd924409fa3dea0ae4 Content-Transfer-Encoding: quoted-printable Message-Id: <218E712A-7379-4764-B59A-FD0A186F4520@tzi.org> References: <149315879365.13684.3263173090290877403@ietfa.amsl.com> <720C9B43-B803-4C99-A366-3C79F463FB23@tzi.org> To: Elwyn Davies X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-links-json-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:30:39 -0000 Hi Elwyn, we tried one round at your comments. We didn=E2=80=99t tackle the interaction with /.well-known/core =E2=80=94 = I continue to believe what I said yesterday, but we still have to find a = good way to put this into the document. We added a note that we need to decide whether there is an onus on a = receiving CBOR implementation to check for the absence of the 13 strings = as names (=E2=80=9CAdam=E2=80=99s second issue=E2=80=9D). The title* issue also requires some more thinking =E2=80=94 do we even = want to have language tags on a constrained device. Right now, the = document simply leaves the whole subject out, but probably needs a = position on that. Finally, there is the issue that RFC 6690 percent-decodes and how that = should be reflected in the JSON and CBOR variants. We added a whole subsection on converting back to RFC 6690, which = discusses the current pragmatic approach on solving the =E2=80=9Cto = quote or not to quote=E2=80=9D issue. On the editorial side, we addressed the document title, added some = language to make it clear that the CDDL is informative (and actually = added build tool rules to check the examples against the CDDL, ouch), = and quite a few nits. Thank you for the text suggestions (and no, we = didn=E2=80=99t add a reference to X.690 yet :-). Based on Adam=E2=80=99s = suggestions, we found a way to fix the bullet list in 2.2. We still need to review the editorial comments on the detailed = processing of strings etc. (see may previous comments why these didn=E2=80= =99t just drop in). Please have a look at the new text at: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-links-json-08.txt Thank you! Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 27 08:04:48 2017 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 101A1129AC6; Thu, 27 Apr 2017 08:04:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-links-json@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149330548605.2939.7017319597649926609.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 08:04:46 -0700 Archived-At: Subject: [core] Adam Roach's Discuss on draft-ietf-core-links-json-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:04:46 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-links-json-08: Discuss 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-links-json/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ====================================================================== The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. ====================================================================== The document requires that the thirteen defined values MUST be encoded as integers. The document does not define what implementations are to do if they receive a CBOR object that does not conform to this encoding: is the parameter ignored? Is the entire link relation ignored? Do you reject the entire collection of link relations? Or do you just go ahead and parse it anyway, since the intended meaning is unambiguous (even if out of spec)? ====================================================================== The draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively. ====================================================================== This document appears to use CDDL to define the formal schema for both the JSON and CBOR representations of its data format, although the CDDL document itself is cited only informatively. Additionally , figure 1 shows an application of CDDL to define schema for JSON. It's not clear from a skim through the CDDL document that it can be used for JSON; it would appear that using it in this fashion would require additional text in this document to talk about how to apply CDDL to JSON, or waiting for some other document to do so. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The example in Figure 6 would benefit greatly by showing both the array encoding and "foo" encoding used in Figure 4 (including, in particular, the string -- rather than integer -- encoding of the "foo=3" parameter). From nobody Thu Apr 27 13:54:09 2017 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 10AFB12878D; Thu, 27 Apr 2017 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_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=osram.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 TxW7dso3OwzJ; Thu, 27 Apr 2017 13:54:05 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40054.outbound.protection.outlook.com [40.107.4.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80995129B52; Thu, 27 Apr 2017 13:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Osram.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4uV9176dA0x3JtuVtcqJtMJmr4ET/G/CbJSeagKNLJg=; b=Z6rIFVtqWoazwoFVKqPso7zpYmUA5TPXh8AG9mm4pnIGZawOVIJW+Xi4zzeDUbmlWimmmo82UorJSqn4fySz9EmIwxiaUO6lBSX685zDbjhQgfVmzd0R9M+COfLJWqMI9Tr+ncCPENy7V8vFiz3iMKS516eJOy3mKPRI8qECKYo= Received: from VI1PR07MB1663.eurprd07.prod.outlook.com (10.166.143.7) by VI1PR07MB1662.eurprd07.prod.outlook.com (10.166.142.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Thu, 27 Apr 2017 20:50:34 +0000 Received: from VI1PR07MB1663.eurprd07.prod.outlook.com ([10.166.143.7]) by VI1PR07MB1663.eurprd07.prod.outlook.com ([10.166.143.7]) with mapi id 15.01.1075.002; Thu, 27 Apr 2017 20:50:33 +0000 From: "Beck, Stefan" To: Marco Tiloca , "draft-tiloca-core-multicast-oscoap@ietf.org" CC: 'core' Thread-Topic: [core] Review on draft-tiloca-core-multicast-oscoap-01 Thread-Index: AdKuTspS7D95VPiCTf6PMOteBsYMvAPaYIngAG6fVQAACC0AIA== Date: Thu, 27 Apr 2017 20:50:33 +0000 Message-ID: References: <017401d2ae79$5a6378f0$0f2a6ad0$@augustcellars.com> <59021B50.4070903@ri.se> In-Reply-To: <59021B50.4070903@ri.se> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ri.se; dkim=none (message not signed) header.d=none;ri.se; dmarc=none action=none header.from=osram.com; x-originating-ip: [2001:a61:3266:4801:e5e6:a246:e363:a143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1662; 7:5Oia2D6dIipOZcLkbfEgNEPfhegrHl7+2vlRlHS58//NgzyWFT3+6gxO2zpjR6Cw81KsG7/o1NYEf9uoQjfyGBXtzC2VjjDsCIq7M0an1Eg+89CLeeE2ea5E8N/piJXR6UWAoQ3eg8svl2NM59SfpjKXEVTHEZzlSBVQG3zJeecBtuG3sJzi09zoEo/S/WtkA4Z7KHznvYb8jX9fuhZRwaXzEVfpBqiuAVVvWBPqPGtf54DVupY4HCZKPGkrgd6UtXNqrDA5ffPQWfiAMlEuX6iKnOL5IGIgX1wwbrG/FyUbYd8TNJPhNw2axz7v0ggvptqiUSxv2nsU2C8U3Xet7w== x-ms-office365-filtering-correlation-id: af60d3f0-333f-49c6-bb63-08d48daf0ca3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:VI1PR07MB1662; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(6072148); SRVR:VI1PR07MB1662; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1662; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(39860400002)(377454003)(377424004)(13464003)(52314003)(24454002)(4326008)(2906002)(25786009)(99286003)(53546009)(7736002)(2950100002)(53936002)(305945005)(7696004)(230783001)(9686003)(122556002)(6306002)(55016002)(76176999)(54356999)(229853002)(2501003)(8936002)(99936001)(6436002)(2900100001)(102836003)(3660700001)(5660300001)(81166006)(77096006)(50986999)(33656002)(74316002)(6246003)(3280700002)(38730400002)(189998001)(8676002)(86362001)(561944003)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1662; H:VI1PR07MB1663.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010E_01D2BFA8.AC749C60" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 20:50:33.4744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1662 Archived-At: Subject: Re: [core] Review on draft-tiloca-core-multicast-oscoap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 20:54:08 -0000 ------=_NextPart_000_010E_01D2BFA8.AC749C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marco, Thanks for considering my comments. With "simple situations" I meant payload data only, not signatures or = MAC. A sample use case could be group messages that switch on / off dozens or more luminaires at once. There's no sensitive payload data involved = here. And even if encrypted one could easily find out what is going on, just = by monitoring network package flow. Having said that, I fully agree with you though, that encryption should = be the norm anyway. I just stumbled over the use of SHALL, SHOULD and MAY = in those three last bullets of section 2, which is inconsistent IMO. I would change as follows: 1. Group-level data confidentiality: messages sent within the multicast group *SHOULD* be encrypted. ... In particular, messages *SHALL* be encrypted if privacy sensitive data = is exchanged in the group. (or alternatively: describe the privacy concerns = in the Security Considerations section) 2. Source authentication: ok 3. Message integrity: messages sent within the multicast group *SHALL* = be integrity protected. Stevie -----Original Message----- From: Marco Tiloca [mailto:marco.tiloca@ri.se]=20 Sent: Thursday, April 27, 2017 6:25 PM To: Beck, Stefan ; draft-tiloca-core-multicast-oscoap@ietf.org Cc: 'core' Subject: Re: [core] Review on draft-tiloca-core-multicast-oscoap-01 Hello Stefan, Thanks a lot for your review and comments, we have been revising the = draft accordingly. As to your comment: "Intuitively I would consider authentication and integrity as SHALL, = while confidentiality could be seen as SHOULD (or even MAY? - as the following text already correctly suggests that data confidentiality may only be required if privacy sensitive data is exchanged - which is not = necessarily the case, e.g. in simple situations" Do you refer to a signature or a MAC? Also, can you refer to any = particular case where confidentiality is not required? Please, consider that group members do own the key material they need = for encryption anyway, and [1] suggests encryption as the norm and that = newly designed protocols should prefer encryption to cleartext operation. Best regards, /Marco [1] https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/= On 2017-04-25 14:54, Beck, Stefan wrote: > Hi, > On Section 2: > Group-level data confidentiality and Source authentication are = described as SHALL, while Message integrity is SHOULD. > > Intuitively I would consider authentication and integrity as SHALL,=20 > while confidentiality could be seen as SHOULD (or even MAY? - as the=20 > following text already correctly suggests that data confidentiality=20 > may only be required if privacy sensitive data is exchanged - which is = > not necessarily the case, e.g. in simple situations > > On authentication and integrity: I would use SHALL consistently here - = > similar to what is already written on "source authentication" in=20 > section 1. And it is implied by the last statement anyway ("Message=20 > integrity is provided through the same means used to provide source=20 > authentication.") > > Section 7.1: the first paragraph addresses the confidentiality part of "Group-level Security", so you could potentially rename 7.1. to = "Group-level Data Confidentiality" as one specific part of the security = considerations (provided that this first paragraph remains the only one in 7.1...): > - the second paragraph deals with the obvious ("it is required that = all group members are trusted"), so it could even be removed completely? > - and the 3rd paragraph would better fit to 7.2 IMO (as the task of removing a compromised group member becomes a key management task - = similar to when legitimate - yet uncompromised - group members are leaving). > > > I also agree with Jim's proposal (on section 1, excerpt below), the = same could be applied in section 2 (and 7.1) analogously. > > Stevie > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Thursday, April 06, 2017 3:59 AM > To: draft-tiloca-core-multicast-oscoap@ietf.org > Cc: 'core' > Subject: [core] Review on draft-tiloca-core-multicast-oscoap-01 > > Here are a few comments on this draft. > > <...> > > Section 1 - "Source authentication" - suggest the last sentence ends = "not tampered with either by a different group member or by a non-group = member". > =09 > <...> > > Jim > > > _______________________________________________ > 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 -- Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=E5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order = to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. ------=_NextPart_000_010E_01D2BFA8.AC749C60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MjcyMDUw MzFaMCMGCSqGSIb3DQEJBDEWBBRlvpRGgVW6vWk1fMytcF6SjFbbUDCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEANjgDs0cx9PttPBsB fdvsbAOM+6PbERIdBTJHg8YHweke2bOY12LgO80gqGjZpYxVOXV91az92Hq+S8uR1nD0n1LpTirl CI5C2kLSsZYIA48hNtdmrAyedzZaXU01PJwHJcWoQv8r6OaoM1KgdU3q+YW6TxI9/TP7GIG+TI21 TgXJU20Ki+UZvkrMxmJsSgCA2ZxAWGHFClLf+X7Vcv2giLpDDdTC2KFoYZldUDYLCaWqizZShy1D 0kq3sMR1r2KtAb0tITWZEOzVJXzU0mOOweTJ/prKcnBz4xmRGxV+cLJIyomi+5s2kYo8c11n69IT aRrbmG7EZ61f3nKEbTwlqAAAAAAAAA== ------=_NextPart_000_010E_01D2BFA8.AC749C60-- From nobody Fri Apr 28 01:01:53 2017 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 7613D129C4C for ; Fri, 28 Apr 2017 01:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 vFwkUsCdAOWw for ; Fri, 28 Apr 2017 01:01:50 -0700 (PDT) Received: from mail4.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 7FC82129AD8 for ; Fri, 28 Apr 2017 00:58:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493366284; h=from:subject:to:date:message-id; bh=ObttAnqup6qRAfogSzKSv8ai2fhBD0QM1S8xpXIoz7Q=; b=AA8olK4yeP1xmYmMIzPU/MIz9pFb3nEmoynStwBdfY7u4IG1qkK4n9gjTUsoqWb9EW0O1Xthu1w F29pMrnTxg70hqQFzSzcmr7Cd/wVpDlzzddPNs+b0sJePiryEYLcDAoPE1yQqye1YprtT4yzzv0fd qpYesF27DI2Sk+gfTLiCgCcUjzpJghp3ZnhvWE86veHsP5zik4C8zoS7josvzx8w539hh4WTN+k2f pbP4jHZcmagPTGWpe9DLoLjKl0kFrtA3qY2Jf9GUM+VaBdV3MxcOpCgbLTZHb79R64gEYv/atdhND rYbvo12rJSKpr4eF+gE4tUgT5Wqioedy95Qw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 00:58:03 -0700 Received: from Hebrews (193.253.56.155) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 00:57:56 -0700 From: Jim Schaad To: 'core' Date: Fri, 28 Apr 2017 09:57:24 +0200 Message-ID: <026d01d2bff5$16f9ad40$44ed07c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdK/9GS6MlUaeEOVQsWm0SA0bK8FWA== X-Originating-IP: [193.253.56.155] Archived-At: Subject: [core] CoAP + TLS question on signaling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:01:51 -0000 I am trying to decide where to put the signaling code in my stack and as part of that question I started to wonder if the signaling messages are applicable to the UDP and other transport cases as well. I also wanted to be sure that there was no intention that if a release w/ an alternative address is sent, there is no intention that any state would be transferred between to the new connection. Jim From nobody Fri Apr 28 01:38:21 2017 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 E58C8127A90 for ; Fri, 28 Apr 2017 01:38:20 -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 pKvBbWLNuuBQ for ; Fri, 28 Apr 2017 01:38:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E64124234 for ; Fri, 28 Apr 2017 01:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3S8YTqP018182; Fri, 28 Apr 2017 10:34:29 +0200 (CEST) Received: from client-0027.vpn.uni-bremen.de (client-0027.vpn.uni-bremen.de [134.102.107.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wDnDP2zKkzDHh8; Fri, 28 Apr 2017 10:34:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <026d01d2bff5$16f9ad40$44ed07c0$@augustcellars.com> Date: Fri, 28 Apr 2017 10:34:28 +0200 Cc: core X-Mao-Original-Outgoing-Id: 515061268.580933-2f92548c463020139c4b78e842339edd Content-Transfer-Encoding: quoted-printable Message-Id: <7A06C749-CF3D-4699-AE3E-8575EA782334@tzi.org> References: <026d01d2bff5$16f9ad40$44ed07c0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] CoAP + TLS question on signaling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:38:21 -0000 Hi Jim, > I am trying to decide where to put the signaling code in my stack and = as > part of that question I started to wonder if the signaling messages = are > applicable to the UDP and other transport cases as well. =20 As defined they are not; they are defined for TCP, TLS, ws, wss. Now is it likely that this will ever change? For UDP, no. Signaling is about the current connection, and there is no = such thing in UDP. The only signaling function that doesn=E2=80=99t = really need the connection is PING/PONG, and we have other ways of doing = this. (The only new thing here, the custody option, only makes sense = for a sequence-preserving reliable connection.) DTLS does have a connection, but the current signaling messages are not = very useful for controlling that. Still not that likely. Other transports: Could be. Christian Groves' draft for CoAP over = WebRTC data channel certainly uses them. > I also wanted to be sure that there was no intention that if a release = w/ an > alternative address is sent, there is no intention that any state = would be > transferred between to the new connection. =20 Indeed, this option only says how to get a new connection; there is no = intention that its state is otherwise influenced. We should probably say that; opened an issue (#144). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 28 04:48:59 2017 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 C71491287A7 for ; Fri, 28 Apr 2017 04:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 r-9tfTGGsmP8 for ; Fri, 28 Apr 2017 04:48:56 -0700 (PDT) Received: from mail4.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 CD9C512EAD0 for ; Fri, 28 Apr 2017 04:45:01 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493379896; h=from:subject:to:date:message-id; bh=3gKgGzr3eMg5zW+wOfWYHVd9TWHfuNUXJrCeWH4DHEA=; b=YRrlhULQENHSncQGwFq5UIDyma5N3rwev6+FJAo0t4wD1jLzVDId2NqllQkNHVUHJ19fE0E8aQ8 qVHVp8McQc/19uBFYrufM59QW+htW05wwqy9j3W7cyy/UXhEBnOJ7H18zO+9pEIKkzRqMAT8c+Njh USrJkFvuWcJ18z49Npa8BLXKMc986TET4Ijv+Ci+/imj3gTtrgUGHJQ3eHeEl0Ioorz6zYqw1+dPi cDh8JfnAjCpB8DeXWGTXKQIV4YfSU4Sm5qIkEQiSDSrxVwsNFsAiVjisiyegH1NkeZVOoM/Wms2FZ DY0tjj7En+x7Cc7QOXQeNnpguwgwqiKI3JSA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 04:44:55 -0700 Received: from Hebrews (193.253.56.155) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 04:44:49 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: 'core' References: <026d01d2bff5$16f9ad40$44ed07c0$@augustcellars.com> <7A06C749-CF3D-4699-AE3E-8575EA782334@tzi.org> In-Reply-To: <7A06C749-CF3D-4699-AE3E-8575EA782334@tzi.org> Date: Fri, 28 Apr 2017 13:44:21 +0200 Message-ID: <027901d2c014$c8e8e1f0$5abaa5d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJyZLltaF9usU8uJbTFU+j7yado6AHWTu3KoIysPxA= X-Originating-IP: [193.253.56.155] Archived-At: Subject: Re: [core] CoAP + TLS question on signaling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 11:48:58 -0000 See inline. -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Friday, April 28, 2017 10:34 AM To: Jim Schaad Cc: core Subject: Re: [core] CoAP + TLS question on signaling Hi Jim, > I am trying to decide where to put the signaling code in my stack and=20 > as part of that question I started to wonder if the signaling messages = > are applicable to the UDP and other transport cases as well. As defined they are not; they are defined for TCP, TLS, ws, wss. Now is it likely that this will ever change? For UDP, no. Signaling is about the current connection, and there is no = such thing in UDP. The only signaling function that doesn=E2=80=99t = really need the connection is PING/PONG, and we have other ways of doing = this. (The only new thing here, the custody option, only makes sense = for a sequence-preserving reliable connection.) [JLS] I am unsure that the max message size might not be a useful option = to send between items. While this can be detected in other ways, it = might still be useful for a client to say that I want something even = smaller. [JLS] I am not sure that I understand why the custody option is based on = a sequence-preserving reliable connection. I don't see any reason why = 1) I cannot have two active requests on a single reliable connection = (separated by the token) and 2) there is any reason to assume that = requests will create responses in order. I would expect that some = "heavy duty" requests might generate responses out of order thus killing = the sequence preservation. Additionally, an ACK followed later by a = response should be detected for the custody option. DTLS does have a connection, but the current signaling messages are not = very useful for controlling that. Still not that likely. Other transports: Could be. Christian Groves' draft for CoAP over = WebRTC data channel certainly uses them. [JLS] Yes, I was actually thinking of SMS at the time. Jim > I also wanted to be sure that there was no intention that if a release = > w/ an alternative address is sent, there is no intention that any=20 > state would be transferred between to the new connection. Indeed, this option only says how to get a new connection; there is no = intention that its state is otherwise influenced. We should probably say that; opened an issue (#144). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 28 06:24:08 2017 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 1E1C1129C52 for ; Fri, 28 Apr 2017 06:24:06 -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 nzCdfiK5Rzlv for ; Fri, 28 Apr 2017 06:24:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2224512EA97 for ; Fri, 28 Apr 2017 06:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3SDJxw4011941; Fri, 28 Apr 2017 15:19:59 +0200 (CEST) Received: from client-0068.vpn.uni-bremen.de (client-0068.vpn.uni-bremen.de [134.102.107.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wDvYq45p0zDHs1; Fri, 28 Apr 2017 15:19:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <027901d2c014$c8e8e1f0$5abaa5d0$@augustcellars.com> Date: Fri, 28 Apr 2017 15:19:59 +0200 Cc: core X-Mao-Original-Outgoing-Id: 515078399.264174-f1524af45cfe60234ece422695b2effc Content-Transfer-Encoding: quoted-printable Message-Id: References: <026d01d2bff5$16f9ad40$44ed07c0$@augustcellars.com> <7A06C749-CF3D-4699-AE3E-8575EA782334@tzi.org> <027901d2c014$c8e8e1f0$5abaa5d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] CoAP + TLS question on signaling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 13:24:06 -0000 > [JLS] I am unsure that the max message size might not be a useful = option to send between items. While this can be detected in other ways, = it might still be useful for a client to say that I want something even = smaller. Yes. We would need to put more protocol around that, as it is not quite = clear what the capability would be applied to. Devices occasionally change their addresses, and the address might be = re-used by another device that does not implement this message. So right now I feel more comfortable with 4.13 =E2=80=9CRequest entity = too large=E2=80=9D (RFC 7959 Section 2.5); this has the same problems = around an undefined validity period, but people are likely to implement = this as a hint. > [JLS] I am not sure that I understand why the custody option is based = on a sequence-preserving reliable connection. =20 Well, it says =E2=80=9Ceverything you sent before you sent this PING = I=E2=80=99m responding to has been processed=E2=80=9D. That statement has a meaning on a sequenced connection, but not with UDP = where packets can be reordered. > I don't see any reason why 1) I cannot have two active requests on a = single reliable connection (separated by the token) (NSTART considerations notwithstanding). > and 2) there is any reason to assume that requests will create = responses in order. I would expect that some "heavy duty" requests = might generate responses out of order thus killing the sequence = preservation. Additionally, an ACK followed later by a response should = be detected for the custody option. I think you are proposing an interpretation of the form =E2=80=9Ceverythin= g I sent you a response for has been processed=E2=80=9D. Wouldn=E2=80=99t that be something you would want to attach to the = responses instead of sending it separately? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 28 06:34:44 2017 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 1C2EF1205D3; Fri, 28 Apr 2017 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 fsncKb0u0cio; Fri, 28 Apr 2017 06:34:33 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC642127275; Fri, 28 Apr 2017 06:31:23 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 1336A223499; Fri, 28 Apr 2017 13:31:19 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 28 Apr 2017 15:31:21 +0200 To: "ace@ietf.org" , core From: Ludwig Seitz Message-ID: Date: Fri, 28 Apr 2017 15:31:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=Up4TD64B c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=AzvcPWV-tVgA:10 a=C01ViRMlAAAA:8 a=QLPfpYkryAO4RqcpiSkA:9 a=QEXdDO2ut3YA:10 a=IVNNpgEr6-sA:10 a=V2CapFxqm0gA:10 a=ePWGEMN2vnwA:10 a=Iuy1Xl9CZTQdwcv9aEVZ:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [core] IKEA uses CoAP and DTLS for their smart lights X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 13:34:35 -0000 FYI https://mjg59.dreamwidth.org/47803.html /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Fri Apr 28 06:48:24 2017 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 2DEB91293F5; Fri, 28 Apr 2017 06:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajBHSXNXpqJE; Fri, 28 Apr 2017 06:48:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7C0127601; Fri, 28 Apr 2017 06:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3SDipc9003682; Fri, 28 Apr 2017 15:44:51 +0200 (CEST) Received: from client-0068.vpn.uni-bremen.de (client-0068.vpn.uni-bremen.de [134.102.107.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wDw6W1sJbzDHt3; Fri, 28 Apr 2017 15:44:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 28 Apr 2017 15:44:51 +0200 Cc: "ace@ietf.org" , core X-Mao-Original-Outgoing-Id: 515079891.118724-f6b0bd4c85cbb739d811893a05458463 Content-Transfer-Encoding: quoted-printable Message-Id: <36B76346-FD68-4FD4-A5F2-26B9BB86DE20@tzi.org> References: To: Ludwig Seitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] IKEA uses CoAP and DTLS for their smart lights X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 13:48:11 -0000 On Apr 28, 2017, at 15:31, Ludwig Seitz wrote: >=20 > FYI >=20 >=20 > https://mjg59.dreamwidth.org/47803.html Yes. There has been a flurry of activity in the tinydtls and libcoap projects = in the last weeks, as these seem to be the implementations of choice to = talk to the devices (if you are not using Californium). Lots of hackers/makers are now putting libcoap support into their = various home hub/home bridge projects. This also has further increased the mindshare of LWM2M, which the IKEA = application is based on. The interesting part is that the whole setup makes IKEA TRADFRI a quite = secure implementation of IoT, compared to what=E2=80=99s on the market = today. Maybe we are witnessing the tipping point towards the real Internet of = Things. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Apr 29 21:26:57 2017 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 D408012420B; Sat, 29 Apr 2017 21:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Smy9Vbl3vhCc; Sat, 29 Apr 2017 21:26:52 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CC61292D3; Sat, 29 Apr 2017 21:24:41 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A9DF229CA6F; Sun, 30 Apr 2017 13:24:39 +0900 (JST) Received: by mail-oi0-f48.google.com with SMTP id x184so62464533oia.1; Sat, 29 Apr 2017 21:24:39 -0700 (PDT) X-Gm-Message-State: AN3rC/4S76KihGisreuTUda46+/nmDsyZ+fOmaHMXgHkrb1wmykvWYxA HEyCq0PMAfUS5IBnuPIG5G+NO2p0SA== X-Received: by 10.157.2.101 with SMTP id 92mr7246001otb.211.1493526278364; Sat, 29 Apr 2017 21:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Sat, 29 Apr 2017 21:24:37 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Sat, 29 Apr 2017 21:24:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03918c48e9d8054e5aaf1a Archived-At: Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 04:26:56 -0000 --94eb2c03918c48e9d8054e5aaf1a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, As far as I've read -08 draft, I think this point has not been addressed yet. I hope some folks could elaborate a bit more if they think this is not an important point for the draft. -- Yoshi On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor wrote: > I think that I understand your perceptions better. Prior to adoption of > coap-tcp-tls and before I was active in the WG, I recall discussions > related to the confusion over application vs transport reliability in CoA= P > especially as related to CON and NON. What was intended? > > > > Tim Carey outlined some concerns in: > > https://tools.ietf.org/html/draft-carey-core-std-msg-vs-tran > s-adapt-00#section-2 > > > > This topic was presented in detail at IETF 93 - > https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - > starting on slide 23. > > > > And in a related thread on the mailing list back in 2015 - > https://www.ietf.org/mail-archive/web/core/current/msg06280.html - > Carsten responded: > > > > > In any case, CON and NON are about message layer semantics, not about > application semantics > > > -- you gave them a meaning they don't have. > > > > By IETF 94, the authors were reporting =E2=80=93 =E2=80=9CMost of the Con= fusion > around CON/NON was resolved=E2=80=9D. > > > > Where relevant, I=E2=80=99ve added clarifications - such as the Appendix = related > to differences in Observe for reliable transports. > > > > Both Carsten and Hannes could probably offer more context if needed. > > > > *From:* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > *Sent:* Friday, April 21, 2017 2:08 PM > *To:* Brian Raymor > *Cc:* Yoshifumi Nishida ; tsv-art@ietf.org; > draft-ietf-core-coap-tcp-tls@ietf.org; core@ietf.org; ietf@ietf.org > *Subject:* Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 > > > > Hi Brian, > > > > Just in case, > > Reliable transports only provide reliability at transport level. It > doesn't provide reliability in application protocol level. > > > > RFC7252 has reliability mechanisms in it since it uses UDP. This means it > has abilities to check both transport and app level reliability. > > This draft only provides transport level reliability and apps will need t= o > detect app protocol failure by themselves. > > This means 7252 and this draft are not totally equivalent from the > viewpoint of applications. > > > > I am not saying this is wrong or bad, but I believe app developer should > aware this point. > > -- > > Yoshi > > > > On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor > wrote: > > Hi Yoshi, > > > > > OK. I also think we should state that the protocol should notify the > failure events to applications. > > > Since errors can happen not only in TCP, but also TLS and websocket > level, mentioning only TCP close or reset might not > > > be enough. > > > > After reviewing with the authors, an additional clarification was appende= d > to 3.4 Connection Health - https://github.com/core-wg/coa > p-tcp-tls/pull/140/files > > > > The opinion of the authors (and Gengyu WEI=E2=80=99s recent response - > https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that > RFC6455 covers the WebSocket case and does not need to be repeated here. > > > > > When we use 7252, I think applications basically don't need to implemen= t > timeouts or retry mechanisms as the protocol > > > provides such things. > > > > RFC7252 provides timeouts and retries because it's implementing a TCP-lik= e > reliability mechanism over UDP - https://tools.ietf.org/html/rf > c7252#section-2.1 > > > > > However, when we use this one, it seems applications will need to have > such mechanisms. Isn't it a bit confusing? I am thinking that > > > there need to be some guidance here. > > > BTW, PONG is one example. > > > > For coap-tcp-tls, there are multiple early implementations. This has neve= r > been reported as a source of confusion. > > > > >> My sense is that we should treat this as an update to RFC7959 based on > the original language: > > > I don't have a strong opinion here. Updating 7959 is fine for me if it'= s > clearer to CoAP people. > > > > I've merged the change - https://github.com/core-wg/coa > p-tcp-tls/pull/138/files > > > > Thanks again for helping us to improve the quality of the draft, > > > > =E2=80=A6Brian > > > --94eb2c03918c48e9d8054e5aaf1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
As far as I've read -08 draft, I think this= point has not been addressed yet. I hope some folks could elaborate a bit = more if they think this is not an important point for the draft.
= --
Yoshi

On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <Brian.= Raymor@microsoft.com> wrote:

I think that I understand your perceptions better. = Prior to adoption of coap-tcp-tls and before I was active in the WG, I reca= ll discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. Wha= t was intended?

=C2=A0

Tim Carey outlined some concerns in:<= /span>

https://tools.i= etf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2=

=C2=A0

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-9= 3-core-0.pdf - starting on slide 23.

=C2=A0

And in a related thread on the mailing list back in= 2015 - https://www.ietf.org/mail-archive/web/core/current= /msg06280.html - Carsten responded:

=C2=A0

> In any case, CON and NON are about message lay= er semantics, not about application semantics

> -- you gave them a meaning they don't have= .

=C2=A0

By IETF 94, the authors were reporting =E2=80=93 = =E2=80=9CMost of the Confusion around=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CON/NON was resolved=E2=80=9D.

=C2=A0

Where relevant, I=E2=80=99ve added clarifications -= such as the Appendix related to differences in Observe for reliable transp= orts.

=C2=A0

Both Carsten and Hannes could probably offer more c= ontext if needed.

=C2=A0=

From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad= .jp]
Sent: Friday, April 21, 2017 2:08 PM
To: Brian Raymor <Brian.Raymor@microsoft.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>; tsv-art@ietf.org; draft-ietf-core-coap-tcp= -tls@ietf.org; = core@ietf.org; ietf@= ietf.org
Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07<= u>

=C2=A0

Hi Brian,

=C2=A0

Just in case,

Reliable transports only provide reliability at tran= sport level. It doesn't provide reliability in application protocol lev= el.=C2=A0

=C2=A0

RFC7252 has reliability mechanisms in it since it us= es UDP. This means it has abilities to check both transport and app level r= eliability.

This draft only provides transport level reliability= and apps will need to detect app protocol failure by themselves.=C2=A0<= /u>

This means 7252 and this draft are not totally equiv= alent from the viewpoint of applications.=C2=A0

=C2=A0

I am not saying this is wrong or bad, but I believe = app developer should aware this point.

--

Yoshi

=C2=A0

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <<= a href=3D"mailto:Brian.Raymor@microsoft.com" target=3D"_blank">Brian.Raymor= @microsoft.com> wrote:

Hi Yoshi,

=C2=A0

> OK. I also think we should s= tate that the protocol should notify the failure events to applications.=C2= =A0

> Since errors can happen not = only in TCP, but also TLS and websocket level, mentioning only TCP close or= reset might not

> be enough.

=C2=A0

After reviewing with the authors,= an additional clarification was appended to 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files

=C2=A0

The opinion of the authors (and G= engyu WEI=E2=80=99s recent response - https://www.ietf.org/mail-archive/web/core/current/msg08622.html<= /a>) is that RFC6455 covers the WebSocket case and does not need to be repe= ated here.

=C2=A0

> When we use 7252, I think ap= plications basically don't need to implement timeouts or retry mechanis= ms as the protocol

> provides such things.

=C2=A0

RFC7252 provides timeouts and ret= ries because it's implementing a TCP-like reliability mechanism over UD= P - https://tools.ietf.org/html/rfc7252#section-2.1

=C2=A0

> However, when we use this on= e, it seems applications will need to have such mechanisms. Isn't it a = bit confusing? I am thinking that

> there need to be some guidan= ce here.

> BTW, PONG is one example.=

=C2=A0

For coap-tcp-tls, there are multi= ple early implementations. This has never been reported as a source of conf= usion.

=C2=A0

>> My sense is that we shou= ld treat this as an update to RFC7959 based on the original language:

> I don't have a strong op= inion here. Updating 7959 is fine for me if it's clearer to CoAP people= .

=C2=A0

I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

=C2=A0

Thanks again for helping us to improve the quality = of the draft,

=C2=A0

=E2=80=A6Brian

=C2=A0


--94eb2c03918c48e9d8054e5aaf1a--