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

["Kovatsch, Matthias" <[e-mail]>]

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