Subject: [core] Question on draft-fossati-core-publish-option-02

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 22 Oct 2013 13:58:02 -0400

Hi Thomas,

Thanks for your interesting draft
(http://tools.ietf.org/html/draft-fossati-core-publish-option-02).  I
have one fundamental question.  How is a client directed synchronously
to go towards the delegated Endpoint?  In other words, suppose a client
had a priori (e.g. at provisioning or startup) obtained the URI of the
SEP for the resource that it was interested in.  Your I-D is very clear
on how the SEP can delegate a resource to a delegated Endpoint.  But how
would the client, in a synchronous manner, know that the resource is no
longer at the SEP but to go instead to the delegated Endpoint?  

(I did see your Section 3, Discovery, but this to me seemed to be
somehow a specific use case and not a general approach.  Apologies if I
missed something obvious.)

Best Regards,

Akbar

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Oct 2013 21:59:00 +0100

Thank you Akbar for taking the time to review it.

As far as your question:

On Tue, Oct 22, 2013 at 6:58 PM, Rahman, Akbar
<[email-masked]> wrote:
> How is a client directed synchronously to go
> towards the delegated Endpoint?  In other words, suppose a client had a
> priori (e.g. at provisioning or startup) obtained the URI of the SEP for the
> resource that it was interested in.

This is a great example, and one which we've not documented in the
current I-D but should have been (next round!).

In this case, I would expect the client doing an href query to the
(multicast) /.well-known/core interface:

REQ: GET /.well-known/core?href=coap://sleepy.example.org/res

and get the following response back from the delegated Proxy (or from
another endpoint who happens to have this information):

RES: 2.05 Content
<coap://sleepy.example.org/res>;
  anchor="coap://proxy.example.org/";
  rel="proxies"

which tells the client that coap://proxy.example.org "proxies" the
requested resource, so that it can then issue its Proxy-URI request
for that resource to said proxy.

> Your I-D is very clear on how the SEP
> can delegate a resource to a delegated Endpoint.  But how would the client,
> in a synchronous manner, know that the resource is no longer at the SEP but
> to go instead to the delegated Endpoint?

I hope my previous example is clear enough.  If you are not satisfied,
please shout :-)

> (I did see your Section 3, Discovery, but this to me seemed to be somehow a
> specific use case and not a general approach.  Apologies if I missed
> something obvious.)

Well, the intention is to make it a general approach, it should not
look like an ad hoc solution :-)

We set an explicit design constraint to reuse the discovery model of
RFC6690 as much as possible -- in line with our aim at providing a
fully "in-protocol" solution to the sleepy problem.
To make RFC6690 a building block that also supports the
sleepy/intermittent scenario, we had to bring in the "proxies" link
relation, that works around some semantic and syntactic limitation of
the "hosts" relation.  Using this new thing, the proxy not only hands
off packets around, but also participates into discovery, by
advertising resources that may be "hidden" to the other side of a CoAP
network.

Cheers

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 23 Oct 2013 13:26:55 -0400

Hi Thomas,

Thanks for the detailed and useful clarification.  The only open
question in my mind is what happens if the delegated proxy happens to be
not link local and not site local?  Does this mean that then a global
multicast href query would need to be attempted by the client?

/Akbar

-----Original Message-----
From: Thomas Fossati [mailto:[email-masked]] 
Sent: Tuesday, October 22, 2013 4:59 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: Question on draft-fossati-core-publish-option-02

As far as your question:

On Tue, Oct 22, 2013 at 6:58 PM, Rahman, Akbar
<[email-masked]> wrote:
> How is a client directed synchronously to go towards the delegated 
> Endpoint?  In other words, suppose a client had a priori (e.g. at 
> provisioning or startup) obtained the URI of the SEP for the resource 
> that it was interested in.

RES: 2.05 Content

which tells the client that coap://proxy.example.org "proxies" the
requested resource, so that it can then issue its Proxy-URI request for
that resource to said proxy.

> can delegate a resource to a delegated Endpoint.  But how would the 
> client, in a synchronous manner, know that the resource is no longer 
> at the SEP but to go instead to the delegated Endpoint?

> somehow a specific use case and not a general approach.  Apologies if 
> I missed something obvious.)

Well, the intention is to make it a general approach, it should not look
like an ad hoc solution :-)

We set an explicit design constraint to reuse the discovery model of
RFC6690 as much as possible -- in line with our aim at providing a fully
"in-protocol" solution to the sleepy problem.
To make RFC6690 a building block that also supports the
sleepy/intermittent scenario, we had to bring in the "proxies" link
relation, that works around some semantic and syntactic limitation of
the "hosts" relation.  Using this new thing, the proxy not only hands
off packets around, but also participates into discovery, by advertising
resources that may be "hidden" to the other side of a CoAP network.

Cheers

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 23 Oct 2013 22:00:46 +0100

Hi Akbar,

> multicast href query would need to be attempted by the client?

Are we going to register any global scope addresses for CoAP?  From
what I read is in coap-18, it looks like the IANA request will cover
link and site local addresses only.  (As one of the editors of
groupcomm you sure know better than me: could you clarify this point
please?)

Anyway, in cases where the multicast query is too expensive, or not
possible, I'd reckon the Client should be pre-configured to either:

- make Proxy-URI requests straight to the delegated Proxy, or
- ask a rendez-vous point (e.g. a RD) where Proxies can publish links
of the resources they explicitly proxy for.

BTW, a nice thing about the 'proxies' relation is that it can be used
by a set of mutually trusted and co-operating Proxy nodes to exchange
information about the resources that they made accessible/reachable to
other nodes:

P1 requests /.well-known/core?rel=proxies to P2, obtaining the list of
resources that are visible to P2.  P1 can then update its "resource
routing" table adding P2 as next-hop for said resources.  Viceversa,
P2 could query P1 to create the other slice of the map.

Cheers.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 23 Oct 2013 17:11:51 -0400

Hi Thomas,

what I read is in coap-18, it looks like the IANA request will cover
link and site >local addresses only.  (As one of the editors of
groupcomm you sure know better than me: could you clarify this point
>please?)

Sorry if my original question was a bit vague.  But to answer your
question.  You are correct that CoAP-18 does not specify global scope
for IPv6 multicast, but for IPv4 it says the following which I
understand to be the IPv4 equivalent of global scope address.

   http://tools.ietf.org/html/draft-ietf-core-coap-18#section-12.8

   IPv4  -- "All CoAP Nodes" address [TBD1], from the IPv4 Multicast
      Address Space Registry.  As the address is used for discovery that
      may span beyond a single network, it should come from the
      Internetwork Control Block (224.0.1.x, RFC 5771).

What we have in Groupcommis:

  http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.8

  A client should use CoAP multicast with the smallest possible
      multicast scope that fulfills the application needs.  As an
      example, site-local scope is always preferred over global scope IP
      multicast if this fulfills the application needs.

/Akbar

-----Original Message-----
From: Thomas Fossati [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 5:01 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: Question on draft-fossati-core-publish-option-02

Hi Akbar,

On Wed, Oct 23, 2013 at 6:26 PM, Rahman, Akbar
<[email-masked]> wrote:
> question in my mind is what happens if the delegated proxy happens to 
> be not link local and not site local?  Does this mean that then a 
> global multicast href query would need to be attempted by the client?

Are we going to register any global scope addresses for CoAP?  From what
I read is in coap-18, it looks like the IANA request will cover link and
site local addresses only.  (As one of the editors of groupcomm you sure
know better than me: could you clarify this point
please?)

- make Proxy-URI requests straight to the delegated Proxy, or
- ask a rendez-vous point (e.g. a RD) where Proxies can publish links of
the resources they explicitly proxy for.

BTW, a nice thing about the 'proxies' relation is that it can be used by
a set of mutually trusted and co-operating Proxy nodes to exchange
information about the resources that they made accessible/reachable to
other nodes:

Cheers.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Oct 2013 23:34:13 +0200

On 23 Oct 2013, at 23:00, Thomas Fossati <[email-masked]> wrote:

> Are we going to register any global scope addresses for CoAP?  

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24))

224.0.1.187	All CoAP Nodes	[RFC-ietf-core-coap-18]	2013-07-25

and

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

Variable Scope Multicast Addresses

FF0X:0:0:0:0:0:0:FD	All CoAP Nodes	[RFC-ietf-core-coap-18]	2013-07-25

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 23 Oct 2013 22:43:44 +0100

Akbar,

On Wed, Oct 23, 2013 at 10:11 PM, Rahman, Akbar
<[email-masked]> wrote:
> You are correct that CoAP-18 does not specify global scope

you are right, it's 224.0.1.187 btw -- just checked with IANA :-)

So, to get back to your original question: if the physical medium is
multicast friendly, then in principle the global href query could be a
plausible way to discover the Proxy.  Since one only node is supposed
to respond (i.e. the one explicitly delegated by the SEP), this is not
going to flood the requester.

Does it look sensible to you?

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 24 Oct 2013 23:25:46 -0400

Yes, but any scheme that generates frequent global scope multicast
requests is not a good thing even if only one node will respond (i.e.
because the multicast request traffic is still going out and taking
bandwidth and being read by all members of that global multicast group
even if only one node ultimately responds).

-----Original Message-----
From: Thomas Fossati [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 5:44 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: Question on draft-fossati-core-publish-option-02

Akbar,

On Wed, Oct 23, 2013 at 10:11 PM, Rahman, Akbar
<[email-masked]> wrote:
> You are correct that CoAP-18 does not specify global scope for IPv6 
> multicast, but for IPv4 it says the following which I understand to be

> the IPv4 equivalent of global scope address.

So, to get back to your original question: if the physical medium is
multicast friendly, then in principle the global href query could be a
plausible way to discover the Proxy.  Since one only node is supposed to
respond (i.e. the one explicitly delegated by the SEP), this is not
going to flood the requester.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 25 Oct 2013 16:40:59 +0100

Hi Akbar,

> even if only one node ultimately responds).

of course you are right, and I would not suggest this as a best practice indeed.

As I said earlier, there are at least two safer options to attempt
before falling back to a globally scoped multicast query:
1) pre-configure the client with the delegated proxy address and make
the Proxy-URI request straight away;
2) pre-configure the client with the address of an endpoint (RD,
proxy, etc.) that can respond to unicast "proxies" requests about the
SEP, get the delegated proxy address, and produce the Proxy-URI
request.

Cheers

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 25 Oct 2013 21:57:41 -0400

+1

-----Original Message-----
From: Thomas Fossati [mailto:[email-masked]] 
Sent: Friday, October 25, 2013 11:41 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: Question on draft-fossati-core-publish-option-02

Hi Akbar,

> even if only one node ultimately responds).

of course you are right, and I would not suggest this as a best practice
indeed.

As I said earlier, there are at least two safer options to attempt
before falling back to a globally scoped multicast query:
1) pre-configure the client with the delegated proxy address and make
the Proxy-URI request straight away;
2) pre-configure the client with the address of an endpoint (RD, proxy,
etc.) that can respond to unicast "proxies" requests about the SEP, get
the delegated proxy address, and produce the Proxy-URI request.

Cheers