Re: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft

[Peter van der Stok <[e-mail]>]

Hi Matthias,

I think much of the confusion comes from the word "domain" that is
successfully used for many purposes.
In my mind the domain concept in RD (not CoRE specifically) should cater
for many purposes.
The domain concept in DNS and in RD are fully orthogonal.
The domain concept within DNS is motivated by the network topology with
its authoritative domain servers. Naming within an installation is done
by a network manager.
The domain naming within an installation from the point of view of (for
example) a building can be done from a functional point of view (e.g.
hvac, lighting) or a building structure view (offices, floors) or from 
tenant point of view (where the domain can be associated with security
boundaries). These are a few of the examples I learnt about.
The BACnet people warned me to NEVER use the network management domain
structure in the RD domain structure as used in the FQDN, because that
leads usually to conflicts between organizations.

In conclusion: IMO the domain concept in the RD should not be specified
to strictly. (you may argue about the term, but domain is a nice word
here that covers the purpose).

The ins= in RD-DNS-SD is introduced to provide mapping from the RD web
service to the DNS services.
Be aware the discovery in RD (resources) is more fine grained than in
DNS that talks about services that may contain multiple resources.
The purpose is that some web services stored in the RD should be visible
from Internet with a FQDN, such that you can look at (for example) the
temperature in the building without needing access to the RD but by
discovering the temperature service with DNS. 

Please have a look at section 4.1 of RFC6763, where Stuart explains the
purpose of the service instance name and how it can be defined.
The ins= parameter specifies the instance name that can be used in DNS
for a given web service.
The idea is that with a definition of ins=DNS-INSTANCE the mapping is
complete and the web service, discoverable from RD, is also discoverable
from DNS as DNS service. Kerry is still working on getting the mapping
complete.

I hope this helps a bit, although I am not advocating to get things more
strictly defined.

Peter

Kovatsch, Matthias schreef op 2018-06-22 17:31:

> Dear Peter
> 
> I am sorry that I cannot be more active on this issue. I want three things:
> 
> - Avoid terminology conflicts between the two ecosystems (e.g., domain, instance -- not sure if there are more)
> - Make sure we have clear definitions of the attributes we use for discovery in CoRE
> - Make sure we have the right attributes to cover the known use cases
> 
> For this, I think we need the following:
> 
> - Define new attributes where the definition does not fully match the DNS-SD definition (domain, instance, ...more?). One of the biggest questions seems to be "what is a domain in CoRE?".
> 
> - Get the full picture of what attributes are defined, what they mean, and how we should use them. Without this, it is hard to discuss a good way forward. Could someone prepare a full list with references where they come from (e.g., RFC 6690 etc.)?
> 
> - Model the currently known use cases such as "find any resource of type ("rt") x" (e.g., an RD registration interface) or "find all devices owned by y" (e.g., all endpoints with same "d") or "find my and goes to "find the new URI for the exact resource instance z I was configured with previously" (e.g., an on/off resource of a specific light bulb) with the list of available attributes to identify white spots and unclear definitions.
> 
> Some questions, I have:
> 
> I am now not sure what value/benefit "ins" with the DNS-SD meaning would have in CoRE. What does it mean for a device to be an instance within a DNS domain? Is it a manufacturer-wide unique identifier? Will all IoT installations need their own top-level domain?
> 
> What ways of grouping resources in an RD are envisioned? I assumed we group endpoints by owner (=d --> should have a better fitting name), but maybe we want to group them by sub-system or something.
> 
> Best wishes,
> Matthias
> 
> -----Ursprüngliche Nachricht-----
> Von: peter van der Stok [mailto:[e-mail]]
> Gesendet: Donnerstag, 26. April 2018 11:14
> An: Kovatsch, Matthias (CT RDA IOT EWT-DE)
> Cc: [e-mail]; Jim Schaad; 'Christian Amsüss'; [e-mail]
> Betreff: Re: Definition of the ins target attribute - WAS: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> Hi Matthias,
> 
> On of the confusing aspects is indeed the domain.
> Domain is used in two senses:
> + d= as a local domain definition within rd to group resources
> + domain as used in DNS
> 
> In earlier RD texts a mapping was suggested between d= and the DNS
> domain.
> That was abandoned because unusable for most building installations as
> we know them.
> 
> The mapping may be possible for other installations, but it certainly
> cannot be a general rule.
> 
> The RD-DNS-Sd draft does not want to suggest that you need to learn
> DNS-SD to do core discovery,
> but you have to learn DNS-sd to get the RD to DNSSD mapping right.
> ins is an important attribute to select the service type instance needed
> for dnssd.
> 
> I am happy to learn how you want to fit ins values into RD discovery.
> Possibly you need a new attribute in RD
> given that the mapping from RD to DNSSD is not always 1-1.
> 
> Greetings,
> 
> Peter
> 
> Kovatsch, Matthias schreef op 2018-04-25 23:29: Dear all
> 
> My motivation for raising this issue was that I learned that "ins" is
> used differently from its (original) purpose. I agree that there is no
> special handling of "ins" by RD. Having it in the DNS-SD draft might
> shift its meaning or at least perception and definitely visibility.
> Writing its own draft for just "ins" is overkill, though.
> 
> "ins" has an important role within CoRE discovery and we should avoid
> that people overlook it, because they think they do not need DNS-SD
> (and they do not need it for CoRE discovery). So we need to nail down
> its definition and probably mention it in multiple drafts (with proper
> references). I read the text in core-rd-dns-sd and it is roughly fine,
> but sounds a bit like I have to learn DNS-SD to do CoRE discovery.
> Also I am not sure about the following statements within the same
> section 2.1:
> 
> "SHOULD be unique across resources with the same Resource Type
> attribute in the domain it is used." 
> Is "domain" corresponding to RD's "d" parameter and attribute?
> 
> "This attribute is used by a Resource Directory to distinguish between
> multiple instances of the same resource type within the directory" 
> Here it sounds like it needs to be unique across all resources with
> the same Resource Type attribute in the RD.
> 
> Logically and historically, I would have expected that "ins" MUST be
> unique across all resources with the same Resource Type attribute in
> one device (=ep). I don't know if there is a conflict with DNS-SD
> here, so that we cannot define this. Yet a definition to be unique
> within "d" seems to aim for application semantics:
> 
> When unique within "ep", a device from the factory could already have
> "ins" attributes for its resources, for instance, a weather station
> with two temperature sensors, one ins=indoor, one ins=outdoor.
> 
> When unique within "d", someone had to rewrite the "ins" attributes,
> so that they match the deployment or application, for instance,
> ins="indoor kitchen", ins="indoor lobby", ins="outdoor terrace",
> ins="outdoor garage".
> 
> Do we actually have rough consensus on what "ins" actually means and
> how it should be used for discovery within CoRE?
> (There is a high chance that I just missed that due to being busy with
> other stuff...)
> 
> Best wishes,
> Matthias
> 
> -----Ursprüngliche Nachricht-----
> Von: peter van der Stok [mailto:[e-mail]]
> Gesendet: Dienstag, 24. April 2018 11:40
> An: Jim Schaad
> Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Christian Amsüss';
> [e-mail]; [e-mail]
> Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> Related to this is the proper definition of "ins", which
> unfortunately was moved over to the core-rd-dns-sd draft. "ins" is
> used to distinguish resources with the same "rt". Originally, it was
> used for resource within the same device (e.g.,
> </t1>;rt=temperature;ins=indoor,</t2>;rt=temperature;ins=outdoor). By
> now, it often is assumed to require global uniqueness. I claim that
> this is not required when "ep" is used correctly. Using a hierarchy
> of "d" -> "ep"
> -> "ins"
> provides more flexibility than making "ins" globally unique. "ins"
> can still have a global meaning (cf. indoor vs outdoor), but it
> should be re-usable for all resources with similar instance
> semantics. Uniqueness is achieved through "d" and "ep".
> 
> I think "ins" should become part of the RD draft again to be defined
> together with "d" and "ep", as they are part of a larger discovery
> framework. 
> If "ins" does not need to be handled in a special manner by the RD,
> then I would see no reason for it to be part of the RD draft.  Both
> "ep" and "d" are treated in a special manner as the pair is required
> to be globally unique in the RD.  This is not a true statement for the
> "ins" attribute even in the core-rd-dns-sd draft.
> 
> Jim
 "Ins" is used to specify the instance name for DNS records necessary
for DNS-sd service specification the RD-DNS-SD draft specifies
the rules to generate ins values As such it is totally proper that
"ins" rules are specified in a separate draft, because "ins" treatment
is
disconnected from the special treatment specified for "ep" and "d".

Matthias, Are you expressing that an additional need exists to
distinguish registrations?

Peter