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

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: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
> Zach Shelby
> Sent: Monday, February 25, 2013 23:17
> To: core@ietf.org 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: internet-drafts@ietf.org
> > Subject: New Version Notification for
> > draft-shelby-core-resource-directory-05.txt
> > Date: February 25, 2013 11:13:11 PM GMT+01:00
> > To: zach@sensinode.com
> > Cc: srdjan.krco@ericsson.com, cabo@tzi.org
> >
> >
> > 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
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core