[core] Resource Directory: Simplifying Domains

[Carsten Bormann]

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

[peter van der Stok]

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

Post by Carsten Bormann
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
https://www.ietf.org/mailman/listinfo/core

[Dijk, Esko]

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:core-***@ietf.org] On Behalf Of peter van der Stok
Sent: Friday, April 21, 2017 9:04
To: Carsten Bormann <***@tzi.org>
Cc: Core <***@ietf.org>
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

Post by Carsten Bormann
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
***@ietf.org
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.

[Lauri Piikivi]

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

Post by Dijk, Esko
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-----
Sent: Friday, April 21, 2017 9:04
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

Post by Carsten Bormann
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

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.

[Michael Koster]

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

Post by Lauri Piikivi
Hi alls,
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

Post by Dijk, Esko
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-----
Sent: Friday, April 21, 2017 9:04
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

Post by Carsten Bormann
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[peter van der Stok]

Hi Lauri,

a partial response,

Post by Lauri Piikivi
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.

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

[Dijk, Esko]

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:***@xs4all.nl]
Sent: Monday, May 08, 2017 9:43
To: Lauri Piikivi <***@arm.com>
Cc: Dijk, Esko <***@philips.com>; Carsten Bormann <***@tzi.org>; ***@vanderstok.org; Core <***@ietf.org>
Subject: Re: [core] Resource Directory: Simplifying Domains

Hi Lauri,

a partial response,

Post by Lauri Piikivi
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.

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

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

[Michael Koster]

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

Post by Dijk, Esko
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 <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
-----Original Message-----
Sent: Monday, May 08, 2017 9:43
Subject: Re: [core] Resource Directory: Simplifying Domains
Hi Lauri,
a partial response,

Post by Lauri Piikivi
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.

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.
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
________________________________
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

[peter van der Stok]

Hi,

some suggestions
OLD

Post by Dijk, Esko
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.

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

Post by Dijk, Esko
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.

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