[core] I-D Action: draft-ietf-core-resource-directory-10.txt

[i***@ietf.org]

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 : CoRE Resource Directory
Authors : Zach Shelby
Michael Koster
Carsten Bormann
Peter van der Stok
Filename : draft-ietf-core-resource-directory-10.txt
Pages : 52
Date : 2017-03-13

Abstract:
In many M2M applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which hosts
descriptions of resources held on other servers, allowing lookups to
be performed for those resources. This document specifies the web
interfaces that a Resource Directory supports in order for web
servers to discover the RD and to register, maintain, lookup and
remove resource descriptions. Furthermore, new link attributes
useful in conjunction with an RD are defined.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-resource-directory-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-10


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[peter van der Stok]

Hi Core,

This new version of the resource directory addresses the issues raised
during the last few months on the ML.

This new version includes:
Con(text) query parameter better defined
Simple discovery text improved
Update and entry uniqueness improved
Clarified existence of registration resource
DNS extensions (exp, ins query parameters) removed
And other mistakes and ambiguities removed.

The authors think that this version is ready for WGLC

Peter


-------- Oorspronkelijke bericht --------
Onderwerp: [core] I-D Action: draft-ietf-core-resource-directory-10.txt
Datum: 2017-03-13 21:01
Afzender: internet-***@ietf.org
Ontvanger: <i-d-***@ietf.org>
Kopie: ***@ietf.org

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 : CoRE Resource Directory
Authors : Zach Shelby
Michael Koster
Carsten Bormann
Peter van der Stok
Filename : draft-ietf-core-resource-directory-10.txt
Pages : 52
Date : 2017-03-13

Abstract:
In many M2M applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which hosts
descriptions of resources held on other servers, allowing lookups to
be performed for those resources. This document specifies the web
interfaces that a Resource Directory supports in order for web
servers to discover the RD and to register, maintain, lookup and
remove resource descriptions. Furthermore, new link attributes
useful in conjunction with an RD are defined.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-resource-directory-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-10


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Christian Amsüss]

Hello Peter,

Post by peter van der Stok
And other mistakes and ambiguities removed.

among those, I just happened to note that instead of (say) </rd-lookup>
being advertised as rt=core.rd-lookup (which would then have triggered
string-appending "/ep" to it), the individual records are now advertised.

Much appreciated; this makes implementation of resource trees smoother!
(Actually I found an inconsistency of my implementation of -09, and
looking it up, it was fixed in this version I had not read before).


It does add one easily fixed quirx, however:

In the lookup URI template, there's now /{+rd-looup-base}/{lookup-type}.
Is that distinction still needed? The base can't be discovered now any
more, so I'd say this now should be

| URI Template: /{+type-lookup}{?d,...}
|
| type-lookup := RD lookup location (mandatory). Discovered for a given
| type in .well-known/core by its resource type, where it SHOULD be
| listed. The recommended value for this variable is:
| "/rd-lookup/{type}". Mandatory to be present for types "ep" and
| "res", optional for "d" and "gp".

(Or maybe you they can stay "base URIs", but be many; that's only
terminology then).

I've gone through the rest of the document; "is used to discover the
base URI for RD Lookup operations" would need to speak of "URIs".

Post by peter van der Stok
Con(text) query parameter better defined

Sounds good now.

Post by peter van der Stok
Simple discovery text improved

The term "Simple directory discovery" was dropped from the descriptions
but survived in 5.3.3; it should probably say "simple registration"
there.


Other notes (some on nitpicking level, but if we're at WGLC level I
suppose that's OK):

* 5.2 mentions '"core.gp" is used to discover the base URI for RD group
operations'. Shouldn't this be "core.rd-group"? (Unsure as not yet
really familiar with all the groupcom things).

* 5.2 lists HTTP support but no HTTP response codes

* 5.2 first request/response example: needless quotes about a ct

* 5.3 example: The HTTP requester will probably want to set a con= too
unless it actually sends the HTTP request from its port 80.

* 7. 'The domain lookup returns every lookup domain with a base RD
resource value (e.g. "/rd") encapsulated within angle brackets.' (and
similarly the following group paragraph): This sounds contradictory to
the example given later (which returns '<>;d="domain1"'), where
nothing is encapsulated in the angle brackets.

* 9.3 "con" entry: Since the latest changes this should include "path"
too.

* 10.1.2: In the requests from the CT, the domain parameter is given
per-resource in the payload. Isn't that exclusively used as a query
parameter in registration?

Later in the group setup POST, the semicolons after the <> are
missing in the payload, and the colon in 'coap//' in the con
parameter, which has abundant quotation marks.

* 10.2: "./well-known/core" -> "/."


I haven't updated my implementation yet, but don't see any trouble on
that road. Looks good to me, all things considered.

Best regards
Christian

[peter van der Stok]

Hi Christian,

Thank for the feedback; see below.

Post by Christian Amsüss
Hello Peter,

Post by peter van der Stok
And other mistakes and ambiguities removed.

among those, I just happened to note that instead of (say) </rd-lookup>
being advertised as rt=core.rd-lookup (which would then have triggered
string-appending "/ep" to it), the individual records are now
advertised.
Much appreciated; this makes implementation of resource trees smoother!

Good to read.

Post by Christian Amsüss
(Actually I found an inconsistency of my implementation of -09, and
looking it up, it was fixed in this version I had not read before).
In the lookup URI template, there's now
/{+rd-looup-base}/{lookup-type}.
Is that distinction still needed? The base can't be discovered now any
more, so I'd say this now should be
| URI Template: /{+type-lookup}{?d,...}
|
| type-lookup := RD lookup location (mandatory). Discovered for a given
| type in .well-known/core by its resource type, where it SHOULD be
| "/rd-lookup/{type}". Mandatory to be present for types "ep" and
| "res", optional for "d" and "gp".
(Or maybe you they can stay "base URIs", but be many; that's only
terminology then).

URIs it will be; rd-lookup-base is also used later; and is an
understandable concept.

Post by Christian Amsüss
I've gone through the rest of the document; "is used to discover the
base URI for RD Lookup operations" would need to speak of "URIs".

Post by peter van der Stok
Con(text) query parameter better defined

Sounds good now.

Post by peter van der Stok
Simple discovery text improved

The term "Simple directory discovery" was dropped from the descriptions
but survived in 5.3.3; it should probably say "simple registration"
there.

agreed.

Post by Christian Amsüss
Other notes (some on nitpicking level, but if we're at WGLC level I

not yet.

Post by Christian Amsüss
* 5.2 mentions '"core.gp" is used to discover the base URI for RD group
operations'. Shouldn't this be "core.rd-group"? (Unsure as not yet
really familiar with all the groupcom things).

No opinion. see what the co-authors think.

Post by Christian Amsüss
* 5.2 lists HTTP support but no HTTP response codes

Correct;

Post by Christian Amsüss
* 5.2 first request/response example: needless quotes about a ct

correct, again.

Post by Christian Amsüss
* 5.3 example: The HTTP requester will probably want to set a con= too
unless it actually sends the HTTP request from its port 80.

good suggestions

Post by Christian Amsüss
* 7. 'The domain lookup returns every lookup domain with a base RD
resource value (e.g. "/rd") encapsulated within angle brackets.' (and
similarly the following group paragraph): This sounds contradictory to
the example given later (which returns '<>;d="domain1"'), where
nothing is encapsulated in the angle brackets.

Yep, have to solve that one way or the other.

Post by Christian Amsüss
* 9.3 "con" entry: Since the latest changes this should include "path"
too.

mistakes come and go, in spite of github

Post by Christian Amsüss
* 10.1.2: In the requests from the CT, the domain parameter is given
per-resource in the payload. Isn't that exclusively used as a query
parameter in registration?

change it, thanks for looking at it.

Post by Christian Amsüss
Later in the group setup POST, the semicolons after the <> are
missing in the payload, and the colon in 'coap//' in the con
parameter, which has abundant quotation marks.

thanks again.

Post by Christian Amsüss
* 10.2: "./well-known/core" -> "/."

there is also another instance; also here mistakes come and go.

Post by Christian Amsüss
I haven't updated my implementation yet, but don't see any trouble on
that road. Looks good to me, all things considered.

Many thanks,

peter

Post by Christian Amsüss
Best regards
Christian