Subject: Re: [core] Resource Directory: Simplifying Domains

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 4 May 2017 16:30:18 +0000

Hello,

the proposed simplification would differ from the current Domain concept.  In the current concept, a registering endpoint (or a tool 'CT' on its behalf) can create arbitrary new domains by putting in a d=<string> either in the URI or in the individual links being registered. In the proposed concept, the Domains are limited to the resources already pre-hosted at the RD. (E.g. /rd/domain1, /rd/domain2 - only choice between these 2 domains and not arbitrary other ones.)

Agree with Peter that for the constrained endpoint (that's e.g. just registering) it is easiest as written currently - it just registers without d parameters to the default domain; without having to choose between domains.

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Friday, April 21, 2017 9:04
To: Carsten Bormann <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] Resource Directory: Simplifying Domains

Hi Carsten,

my hip gun shot reaction.
The alternative seems more complex to handle than the original from application point of view.
In my opinion, the application ease of use takes precedence here.

Peter

Carsten Bormann schreef op 2017-04-20 20:15:
> In the current resource directory, multiple domains are pretty much
> ships in the night to each other; domains "compartmentalize" the RD.
> After we had a discussion of RD domains between the authors, I'm no
> longer sure we actually need all this mechanism.
> Instead, each such compartment/domain could be modeled as a separate
> resource directory of its own.
> Multiple domains could be offered as multiple resource directories,
> e.g. under
>
>     /rd/{domain}
>
> (This does not mean that there need to be multiple copies of RD
> software running etc., it just means a resource directory
> implementation could offer multiple of the entry points called
> "resource directories" under different URIs.)
>
> The remaining questions are
>
> -- how does a client find the resource directory for the domain it
>    wants to register under.
> -- how does a client list the resource directories and find the
>    "domain" for each.
>
> Listing the resource directories could simply be done by offering a
> collection interface to them.  The domain property could be converted
> into a URI and listed in the resource directory.  Construction of an
> RD URI could be via a template as shown above.
>
> Before we further flesh out this design, I'd like to know who has
> implemented domains (which are optional in the current RD) and how
> much they would be impacted by such a simplification.
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

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

________________________________
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: Lauri Piikivi <[email-masked]>
Date: Fri, 5 May 2017 13:10:27 +0000

Hi alls,

We may have some misaligned definition for domain. V10 of the draft says in definitions:
      This specification assumes that the list
      of Domains supported by an RD is pre-configured by that RD.  When
      a domain is exported to DNS, the domain value equates to the DNS
      domain name.

But then we do allow the d= parameter for registrations. Also there seems to be some weakness in the text with the domain being in the URI, and then the location information in the response should have the same domain? I think there would need to be some clarification also regarding the authentication and access control of the device, as it would be very natural to place a device in certain domain based on the certificate. Access control may become very hard, if there are arbitrary domains. Then again multiple groups seem to be needed for a more fine tuned access control

In chapter 3 it says "The domain an endpoint is associated with can
   be defined by the RD or configured by an outside entity.  This
   information hierarchy is shown in Figure 2."
Does that mean that the Device can configure it at run-time? The Figure 2 could be clarified if multiple domains or groups are allowed. It seems multiple groups are allowed, and a device can be in multiple groups, as in chapter 7 there is an example "The following example shows a client performing a lookup for all groups an endpoint belongs to"

 I would like to keep it simple, 1 domain per endpoint, device can propose but server dictates as the ep must be unique in the domain.So if there is some configuration in directory it overrides device proposals. For restful URIs, the domain and group should be in the URI  for a resource — the location returned by the directory. That makes it a bit clunky to have multiple groups for an endpoint. But it is possible if we want multiple and arbitrary groups.

BR
- Lauri

> "On 04 May 2017, at 19:30, Dijk, Esko <[email-masked]> wrote:
>
> Hello,
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Koster <[email-masked]>
Date: Fri, 5 May 2017 07:14:05 -0700

Hi,

It looks like we do not prohibit rd-lookup-* operations from returning results from multiple domains. 

I think one would need to use something like:

    GET /example/rd-lookup-res?d="exampledomain"&rt=core.pubsub 

to restrict results to one domain.

Of course, one could have a policy that only allows particular clients/users access to particular domains.

I had not thought of the use case where registering with a domain ID that doesn't exist would create it. We should explicity state in the document if create-on-registration is optional, i.e. may be rejected with a 4.xx code. 

Best regards,

Michael

> On May 5, 2017, at 6:10 AM, Lauri Piikivi <[email-masked]> wrote:
> 
> 
> Hi alls,
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 08 May 2017 09:43:28 +0200

Hi Lauri,

a partial response,

>       a domain is exported to DNS, the domain value equates to the DNS
Thanks for pointing this out.
There clearly is confusion about the use of domain in the RD, and its 
eventual use
as the DNS domain.
I agree that this confusion must be removed.  In my mind there are two 
domain concepts:
the RD one and the DNS one.

IMO, It is the responsibility of the RD to DNS mapping agent to specify 
restrictions if the RD domain is mapped to the DNS domain.

Peter

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 8 May 2017 07:50:15 +0000

Michael,

currently the ad-hoc creation of domains follows from the text e.g. the examples on page 40 . There each room in a building gets its own Domain in the RD. Now the RD can't possibly know these room IDs beforehand, so these are created on-the-fly.
A Commissioning Tool (CT) as in that example would typically know which Domain a device is to be assigned to, however the endpoint itself (if doing the registration itself) would typically not know this - so it would use the default domain.

@Peter,

agree that in the way currently Domains are defined and used , some infrastructure entity (the RD itself?) is responsible for mapping it do a DNS domain. E.g. if the CT register a node under domain d=R2-4-015 then this entity would know that it maps to DNS 'R2-4-015.building.example.com'   for example.   But the 'RD to DNS mapping agent' is not mentioned in the I-D so may be good to clarify this more. (Also where this entity resides.)

Esko

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Monday, May 08, 2017 9:43
To: Lauri Piikivi <[email-masked]>
Cc: Dijk, Esko <[email-masked]>; Carsten Bormann <[email-masked]>; [email-masked]; Core <[email-masked]>
Subject: Re: [core] Resource Directory: Simplifying Domains

Hi Lauri,

a partial response,

Thanks for pointing this out.
There clearly is confusion about the use of domain in the RD, and its eventual use as the DNS domain.
I agree that this confusion must be removed.  In my mind there are two domain concepts:
the RD one and the DNS one.

IMO, It is the responsibility of the RD to DNS mapping agent to specify restrictions if the RD domain is mapped to the DNS domain.

Peter

---

From: Michael Koster <[email-masked]>
Date: Tue, 9 May 2017 09:35:46 -0700

Hi Esko,

I didn't realize the example was creating domains upon first registration. 

I guess we should review the text in the draft:

Sec. 2 has this:

   Domain
      In the context of a Resource Directory, a domain is a logical
      grouping of endpoints.  This specification assumes that the list
      of Domains supported by an RD is pre-configured by that RD.  When
      a domain is exported to DNS, the domain value equates to the DNS
      domain name.

Sec. 3:

An RD can be logically segmented by the use of Domains.  
The domain an endpoint is associated with can be defined 
by the RD or configured by an outside entity.  This information 
hierarchy is shown in Figure 2.

If we want to allow creation on registrtion, we will need to rework this text and probably add some explicit description to section 5.

Best regards,

Michael

> On May 8, 2017, at 12:50 AM, Dijk, Esko <[email-masked]> wrote:
> 
> Michael,
> 
> agree that in the way currently Domains are defined and used , some infrastructure entity (the RD itself?) is responsible for mapping it do a DNS domain. E.g. if the CT register a node under domain d=R2-4-015 then this entity would know that it maps to DNS 'R2-4-015.building.example.com <http://r2-4-015.building.example.com/>'   for example.   But the 'RD to DNS mapping agent' is not mentioned in the I-D so may be good to clarify this more. (Also where this entity resides.)
> 
> Esko
> 
> From: peter van der Stok [mailto:[email-masked] <mailto:[email-masked]>]
> To: Lauri Piikivi <[email-masked] <mailto:[email-masked]>>
> Cc: Dijk, Esko <[email-masked] <mailto:[email-masked]>>; Carsten Bormann <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Core <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 10 May 2017 09:28:22 +0200

Hi,

some suggestions
OLD
>       a domain is exported to DNS, the domain value equates to the DNS

NEW
   Domain
In the context of a Resource Directory, a domain is a logical
grouping of endpoints.  This specification assumes that the list
of Domains supported by an RD is populated during registration or 
pre-configured.
When a domain is exported to DNS, the domain value may be equated to the 
DNS
domain name.

OLD
> hierarchy is shown in Figure 2.

NEW

An RD can be logically segmented by the use of Domains.
The domain an endpoint is associated with can be defined
by the RD or configured during registration.  This information
hierarchy is shown in Figure 2.

Cheerio,

Peter