Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-05.txt

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 22 May 2013 13:44:15 +0000

Dear Zach,
dear list

I was looking at the draft to clean up the experimental implementation included in Californium. Thereby I stumbled over the following things:

4. Simple Directory Discovery:
I think it should be clearer that POSTed links do not end up in the RD's /.well-known/core resource as absolute URIs. Giving a Location in the 2.01 Created response should fix that. Some reference to the lifetime of the RD entry and the possibility of periodic validation might be useful here.

5.1. Discovery:
The IP part overlaps with "4.1. Finding a Directory Server." Maybe this can be separated into a common section before the simple and function set RD.
"discovering the RD using the CoRE Link Format (also see Section 4.1)" is also a bit confusing. I guess this is referring to multicast discovery, so this should be mentioned directly (possibly in this new section mentioned above).

5. Resource Directory Function Set:
I was wondering what should happen when someone performs a GET on the EP location, e.g., GET /rd/4521.
Can we provide something useful there? Otherwise the document should hint that GET should be disallowed in this context.

7. RD Lookup Function Set:
The link </ep> in the responses to the domain lookup feels odd. Or maybe it is artificially pressing the domain list into the Link Format...
I would at least expect links to the rd-lookup where the domain information can be used (analogous to a ct attribute where the requester can also pick from a list):

</rd-lookup/res>;d="domain1 domain2"

Should "d" and the other attributes (ep, gp) be proper link-extensions? I guess we have to, if we want application/link-format to define the RESTful interaction including the filtering with attributes.
How does "gp" relate to draft-ietf-core-groupcomm?

9. Security Considerations:
A forward reference or the mentioning of access control should already be provided in the function set definitions. These random numbers under /rd/ lured me into thinking of them as access tokens. But they are quite bad for this purpose...

General:
The sub-resources of rd-lookup defined by a URI Template somehow conflict with my current understanding of REST. (Sorry for bringing up this topic again...)
./res, ./ep, and ./d are never linked from anywhere and cannot be discovered. So it is a classic service coupling. Should we just live with that or can we fix this somehow, e.g., with separate rt attributes and entries in /.well-known/core?
Otherwise the RD is quite nicely built around the CoRE Link Format media type.

Ciao
Matthias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Zach Shelby
> Sent: Monday, February 25, 2013 23:17
> To: [email-masked] WG
> Subject: [core] Fwd: New Version Notification for draft-shelby-core-
> resource-directory-05.txt
> 
> I have posted a new version of the RD draft, now including group support,
> alignment with the OMA Lightweight M2M standards work and improved
> interfaces. Thanks to Esko and Peter for help with the group support.
> 
> Regards,
> Zach
> 
> Begin forwarded message:
> 
> > From: [email-masked]
> > Subject: New Version Notification for
> > draft-shelby-core-resource-directory-05.txt
> > Date: February 25, 2013 11:13:11 PM GMT+01:00
> > To: [email-masked]
> > Cc: [email-masked], [email-masked]
> >
> >
> > A new version of I-D, draft-shelby-core-resource-directory-05.txt
> > has been successfully submitted by Zach Shelby and posted to the IETF
> > repository.
> >
> > Filename:	 draft-shelby-core-resource-directory
> > Revision:	 05
> > Title:		 CoRE Resource Directory
> > Creation date:	 2013-02-25
> > Group:		 Individual Submission
> > Number of pages: 27
> > URL:             http://www.ietf.org/internet-drafts/draft-shelby-core-
> resource-directory-05.txt
> > Status:          http://datatracker.ietf.org/doc/draft-shelby-core-resource-
> directory
> > Htmlized:        http://tools.ietf.org/html/draft-shelby-core-resource-
> directory-05
> > Diff:            http://www.ietf.org/rfcdiff?url2=draft-shelby-core-resource-
> directory-05
> >
> > 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 resources descriptions.  Furthermore, new link attributes
> >   useful in conjunction with an RD are defined.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> 
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sensinode.com @SensinodeIoT
> Mobile: +358 40 7796297
> Twitter: @zach_shelby
> LinkedIn: http://fi.linkedin.com/in/zachshelby
> 6LoWPAN Book: http://6lowpan.net
> 
> 
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Mon, 27 May 2013 10:26:10 +0300

Hi Matthias,

> I think it should be clearer that POSTed links do not end up in the RD's /.well-known/core resource as absolute URIs. Giving a Location in the 2.01 Created response should fix that. Some reference…

Yes, let's do that. 

> "discovering the RD using the CoRE Link Format (also see Section 4.1)" is also a bit confusing. I guess this is referring to multicast discovery, so this should be mentioned directly (possibly in t…

Agreed. We added the simple discovery afterwards when merging in Carsten's draft. The integration could definitely be better.

> Can we provide something useful there? Otherwise the document should hint that GET should be disallowed in this context.

Should be disallowed. 

> </rd-lookup/res>;d="domain1 domain2"

OK, let's look at this and other ways to improve that.

> How does "gp" relate to draft-ietf-core-groupcomm?

Yes, all those parameters need to be registered. However, we are missing a registry :-/ Someone needs to write an App Area proposal to make an Web Linking attribute registry as that is a more general IETF thing. 

For registration (and lookup) parameters we should define our own registry. 

> A forward reference or the mentioning of access control should already be provided in the function set definitions. These random numbers under /rd/ lured me into thinking of them as access tokens. But they are quite bad for this purpose…

Oh no, they are not access tokens for sure. That just gives the RD the freedom to organise its internal storage as it liked. What the RD returns as the Location: is really up to the RD. 

> ./res, ./ep, and ./d are never linked from anywhere and cannot be discovered. So it is a classic service coupling. Should we just live with that or can we fix this somehow, e.g., with separate rt a…

Let's think about that, I am flexible regarding this one.  

> Otherwise the RD is quite nicely built around the CoRE Link Format media type.

Thanks for the implementation-oriented review, much appreciated!  Looks like this would give us our first set of Tickets as a WG document :-) 

Zach