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

From: [email-masked]
Date: Mon, 13 Mar 2017 13:01:44 -0700

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/

---

From: peter van der Stok <[email-masked]>
Date: Tue, 14 Mar 2017 08:37:38 +0100

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: [email-masked]
Ontvanger: <[email-masked]>
Kopie: [email-masked]

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.

Abstract:

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.

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 16 Mar 2017 17:43:30 +0100

Hello Peter,

> 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".

> Con(text) query parameter better defined

Sounds good now.

> 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

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: peter van der Stok <[email-masked]>
Date: Mon, 20 Mar 2017 13:52:41 +0100

Hi Christian,

Thank for the feedback; see below.

> Much appreciated; this makes implementation of resource trees smoother!
Good to read.
> (Or maybe you they can stay "base URIs", but be many; that's only

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

> but survived in 5.3.3; it should probably say "simple registration"
agreed.
> Other notes (some on nitpicking level, but if we're at WGLC level I
  not yet.
>   really familiar with all the groupcom things).
No opinion. see what the co-authors think.
> * 5.2 lists HTTP support but no HTTP response codes
Correct;
> * 5.2 first request/response example: needless quotes about a ct
correct, again.
>   unless it actually sends the HTTP request from its port 80.
good suggestions
>   nothing is encapsulated in the angle brackets.
Yep, have to solve that one way or the other.
> * 9.3 "con" entry: Since the latest changes this should include "path"
mistakes come and go, in spite of github
>   parameter in registration?
change it, thanks for looking at it.
>   parameter, which has abundant quotation marks.
thanks again.
> * 10.2: "./well-known/core" -> "/."

there is also another instance; also here mistakes come and go.
> that road. Looks good to me, all things considered.

Many thanks,

peter