Subject: [core] More comments on draft-ietf-core-resource-directory-09

From: Jan Newmarch <[email-masked]>
Date: Wed, 21 Dec 2016 10:11:27 +1100

Thanks for responses to my earlier queries. Just two more:

Small error in 6.3?

"con :=  Context (optional).  This parameter sets the scheme,
         a
ddress and port at which this server is available in the form
         s
cheme://host:port.  In the absence of this parameter the
         scheme
of the protocol, source IP address and source port of
         the
register request are assumed"

The source port of the request will be a transient port. This isn't the port of the service. It should be the default port

    In the absence of this parameter the scheme of the protocol, source IP address register request are assumed. The port is assumed to be the default port, 5683.

Relation between RD and WK/C:

Resources registered with WK/C include core.rd, core.rd-lookup and
core.rd-group. Nothing is said about the 'sub-resources' /{+rd-lookup-
base}/{lookup-type} such as /rd-lookup/res etc. I would assume these
are not meant to be visible. Should this be stated explicitly? If they
could be visible, what would be their resource type 'rt'?

The same with resources registered with RD such as /rd/4521. If they
were visible through WK/C that would give another lookup mechanism
besides the Lookup Function Set. Probably best to exclude that
explicitly.

The package I am using (aiocoap) makes all resources visible through
WK/C, so would need changes if they are not to be visible.

Thanks

Jan
-- 
Dr Jan Newmarch,
Director of Higher Education (Business and ICT) @ Box Hill,
Adjunct Professor @ University of Canberra

E [email-masked]

---

From: "David Navarro" <[email-masked]>
Date: Wed, 21 Dec 2016 12:23:01 +0100

Hi,

Allow to join the conversation to point another small issue in the OMA LightweightM2M example.

    13.2.3.  Alternate Base URI
  
       If the LWM2M endpoint exposes objects at a base URI other than the
       default empty base path, the endpoint must register the base URI
       using rt="oma.lwm2m".  An example link payload using alternate base
       URI would be:

       </my_lwm2m>;rt="oma.lwm2m",</my_lwm2m/1>,<my_lwm2m/1/0>,<my_lwm2m/5>

       This link payload indicates that the lwm2m objects will be placed
       under the base URI "/my_lwm2m" and that object ID 1 (server) is
       supported, with a single instance 0 existing, and object 5 (firmware
       update) is supported.

In current LWM2M specification, the link payload would be:
    </my_lwm2m>;rt="oma.lwm2m",</1/0>,</5>

LWM2M expects the base path to be prepended to the other URIs. This is probably making LWM2M not RD-compliant.

Regards,
David Navarro 

-----Message d'origine-----
De : core [mailto:[email-masked]] De la part de Jan Newmarch
Envoyé : mercredi 21 décembre 2016 00:11
À : [email-masked]; [email-masked]
Cc : Jan Newmarch <[email-masked]>
Objet : [core] More comments on draft-ietf-core-resource-directory-09

Small error in 6.3?

Resources registered with WK/C include core.rd, core.rd-lookup and core.rd-group. Nothing is said about the 'sub-resources' /{+rd-lookup- base}/{lookup-type} such as /rd-lookup/res etc. I would assume these are not meant to be visible. Should this be stated explicitly? If they could be visible, what would be their resource type 'rt'?

The same with resources registered with RD such as /rd/4521. If they were visible through WK/C that would give another lookup mechanism besides the Lookup Function Set. Probably best to exclude that explicitly.

The package I am using (aiocoap) makes all resources visible through WK/C, so would need changes if they are not to be visible.

Thanks

Jan
--
Dr Jan Newmarch,
Director of Higher Education (Business and ICT) @ Box Hill, Adjunct Professor @ University of Canberra

E [email-masked]

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 23 Dec 2016 15:08:14 +0000

Hello David,

in fact the example on page 27 (top) of the Lightweight M2M spec 1.0 is wrong. That example does not comply to RFC 6690 as it claims to. Since the spec does not specifically states it deviates from RFC 6690, I have to assume it is an error in the example and/or error in interpretation of RFC 6690. Of course I can understand that this error really helps in getting the payload size down ... one of the goals of LWM2M.

The example in the RD draft is correct.

regards
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of David Navarro
Sent: Wednesday, December 21, 2016 12:23
To: [email-masked]; [email-masked]
Subject: Re: [core] More comments on draft-ietf-core-resource-directory-09

Hi,

Regards,
David Navarro

-----Message d'origine-----
De : core [mailto:[email-masked]] De la part de Jan Newmarch Envoyé : mercredi 21 décembre 2016 00:11 À : [email-masked]; [email-masked]
Cc : Jan Newmarch <[email-masked]>
Objet : [core] More comments on draft-ietf-core-resource-directory-09

Small error in 6.3?

Thanks

Jan

E [email-masked]

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 23 Dec 2016 15:27:50 +0000

Hello Jan,

indeed the source port of the register request will typically be a transient port that's chosen by the CoAP library, not the application.
However - I'm not sure the original intention of the text was to mean the default port (5683); maybe it was intended the way written assuming that the CoAP client itself does not host something on port 5683/5684 so it can freely use these ports as source ports(?)

If only default port 5683 is supported when the "con" parameter is left out, it implies that any registrations for secure (coaps://) resources on port 5684 would always need the "con" parameter.
Do the RD authors know what would be intended here?

Is WK/C the Wakaama library?  You are right that typically the sub-resources would not be visible when doing discovery since /rd or /rd-lookup with their respective 'rt' values alone tell all you need to know. But they can be visible. If sub-resources are visible they would not have any 'rt' associated.
The intention of RD is I believe to not show the registered (created) resources like /rd/4521 via the regular /.well-known/core browsing function, however if the RD wants to do that it can. There seems currently nothing in the RD spec blocking this.

regards
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Jan Newmarch
Sent: Wednesday, December 21, 2016 0:11
To: [email-masked]; [email-masked]
Cc: Jan Newmarch <[email-masked]>
Subject: [core] More comments on draft-ietf-core-resource-directory-09

Small error in 6.3?

Thanks

Jan

E [email-masked]

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 23 Dec 2016 16:45:00 +0100

Hello Jan,

(or "hello again", as we've already talked about some of this on [1]
with me wearing my Free Software developer hat, but this here is the
better place)

> The source port of the request will be a transient port. This isn't
> the port of the service. It should be the default port

I'd disagree here. A server that is registering itself at an RD could
very well send the request from the socket it uses server-side too. The
embedded library I've worked with (libcoap) works that way, as does
aiocoap.

A server *can* send the registration request from a different port (that
would typically be a different socket), but then it would need to be
very careful to send from the same IP address if it were to rely on any
"take my address but change the port" mechanism. The server might be
bound to a particular address, so if it were to send from a transient
port, it would need to check for that anyway, and that's even without
ephemeral addresses.

> could be visible, what would be their resource type 'rt'?

IMO it does not hurt to have the resources visible, and it can be left
to the applications to decide. As with any other resources that might be
present due to functionality extensions of the RD or completely
different tasks the same host is doing, both /rd-lookup/ep and /rd/4521
won't do no harm, and won't even be visible to someone querying
/.w-k/c?rt=core.rd*. I wouldn't give them an rt, though, at least not a
core one.

All the best
Christian

[1] https://github.com/chrysn/aiocoap/issues/53

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Jan Newmarch <[email-masked]>
Date: Wed, 28 Dec 2016 10:46:21 +1100

Hi Christian

> The embedded library I've worked with (libcoap) 
> [receives from the endpoints it sends the registration from], as 
> does aiocoap.asyncio.get_event_loop().run_forever(main())

Okay, I was clearly using these libraries incorrectly (create a client
context - with a transient port -  to register and a server context to
handle queries). I now have my code working correctly using only the
server context.

I know it's implied, but could it be made more explicit in the spec as 

    In the absence of this parameter the scheme of the protocol, source
    IP address and source port of the register request are assumed. The
    request should not be sent from a transient port, the registering
    agent is expected to be an endpoint for that scheme, IP and port.
 
> both /rd-lookup/ep and /rd/4521> won't do no harm, and won't even be
> visible to someone querying> /.w-k/c/.w-k/c?rt=core.rd*.

I'm thinking of someone just querying /.w-k/c, without a filter. They
will see all /rd/xxxx resources, even if they don't know their type.
Yes, the endpoint registering the resource is expected to use this when
updating or removing the registration. Maybe I'm reading more into the
spec than I should, but I'm thinking that no-one else apart from the
original registering endpoint should be able to modify/delete the
resources. Eventually that comes down to security but using obscurity
through non-visibility helps achieve this.

Cheers

Jan
-- 
Dr Jan Newmarch