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

[Zach Shelby <[e-mail]>]

Hi Matthias,

On May 22, 2013, at 4:44 PM, Kovatsch Matthias <[e-mail]> wrote:

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

Yes, let's do that. 

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

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

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

Should be disallowed. 

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

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

> 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?

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. 

> 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…

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. 

> 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?

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

> 
> Ciao
> Matthias
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Zach Shelby
>> Sent: Monday, February 25, 2013 23:17
>> To: [e-mail] 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: [e-mail]
>>> Subject: New Version Notification for
>>> draft-shelby-core-resource-directory-05.txt
>>> Date: February 25, 2013 11:13:11 PM GMT+01:00
>>> To: [e-mail]
>>> Cc: [e-mail], [e-mail]
>>> 
>>> 
>>> 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: [phone]
>> Twitter: @zach_shelby
>> LinkedIn: http://fi.linkedin.com/in/zachshelby
>> 6LoWPAN Book: http://6lowpan.net
>> 
>> 
>> 
>> 
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net