Re: [core] Éric Vyncke's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT)

[Christian Amsüss <[e-mail]>]

(This is one of the point-to-point follow-up mails on the RD -25
reviews; for the preface, please see the preceding mail on "The various
positions on draft-ietf-core-resource-directory-25" at
<https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).

As DISCUSS:

> Thank you for the work put into this document. I am little puzzled by the
> document shepherd's write-up dated more than one year ago (the responsible AD
> has even changed and the change is not reflected in the write-up)... while
> well-written this write-up seems to indicate neither a large consensus nor a
> deep interest by the CORE WG community. But, I am trusting the past and
> current responsible ADs on this aspect.

response:

The shepherd write-up has been updated.

> Did the authors check with 6MAN WG about the new RDAO option for IPv6 NDP ? I
> was unable to find any 6MAN email related to this new NDP option and, after
> checking with the 6MAN WG chairs, they also do not remember any discussion.

response:

Just recently (see GENERIC-6MAN).

> == DISCUSS ==
> 
> -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration
> (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if
> address is configured via SLAAC, DHCPv6 other-information can be used to
> configure the Recursive DNS Server (or possibly the RD).

response:

Thanks, fixed in https://github.com/core-wg/resource-directory/pull/263.

Conversely, the RDAO's applicability is now phrased more generally as well.

> -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this
> RDAO sent ? I guess unicast Router Advertisement but this MUST be specified.

response:

Indeed; fixed in https://github.com/core-wg/resource-directory/pull/262.

As COMMENT:

> == COMMENTS ==
> 
> In general, I wonder how much interactions and exchanges of ideas have
> happened in the long history of this document with the DNSSD (DNS Service
> Discovery) Working Group that has very similar constraints (sleeping nodes)
> and same objectives.

WGF-5
response:

Discussion was primarily on the level of granularity of service description
(what is announced in DNS-SD often corresponds to multiple resources in an RD),
and on protocol negotiation (input which is more suitable for the
protocol-negotiation work than it is going into RD).

> -- Section 2 -- To be honest: I am not too much an APP person; therefore, I
> was surprised to see "source address (URI)" used to identify the "anchor="...
> I do not mind too much the use of "destination address (URI)" as it is really
> a destination but the anchor does not appear to me as a "source address". Is
> it common terminology ? If so, then ignore my COMMENT, else I suggest to
> change to "destination URI" and simply "anchor" ?

response:

"Context" is the term that RFC8288 uses, and other than when defining the
Context we don't use source address for that (as that term is used more
commonly with CoAP/UDP messages).

The "source" part in the definition has no clear lineage in RFC8288 (which does
not introduce the term formally), it stems from a link going "from" somewhere
(the context, or source) "to" somewhere (the target, or destination).

> -- Section 3.3 -- Should the lifetime be specified in seconds at first use in
> the text?

WGF-3
response:

The lifetime is thought of as a quantity of time, which is only expressed in
multiples of a unit when serialized (and there, it is consistently used with
seconds).

> -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use
> the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited
> later.

response:

For Home and Industrial Automation, IoT is indeed used more commonly these
days. Updated in https://github.com/core-wg/resource-directory/pull/297.

> Please expand and add reference for 6LBR.

response:

Done (in https://github.com/core-wg/resource-directory/pull/297).

> Using 'modern' technologies (cfr LP-WAN WG) could also add justification to
> section 3.5.

response:

At least with the currently available setups, the cellular applications have
the "advantage" (from the perspective of motivating the RD) that they are less
integrated with typical application deployments, and thus have a more
pronounced need for discovery in networks that are not under full control of
the device operator.

> -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is
> the value of MCD1 ? The IANA section discuss about it but it may help the
> reader to give a hint before (or simply use TBDx that is common in I-D).

response:

TBDx would have been easier in hindight, but there's hope that until RFC editor
replaces that, more people will be reading the diffs than new people that might
stumble here will read the document, so it's kept that way.

> Any reason to use "address" rather than "group" in "When answering a
> multicast request directed at a link-local address" ?

No, and 'group' should reduce the chances of readers overlooking that this is
about multicasts. (Changed in
https://github.com/core-wg/resource-directory/pull/297).

> Later "to use one of their own routable addresses for registration." but
> there can be multiple configured prefixes... Which one should the RD select ?
> Should this be specified ?

response:

I don't think it needs to be fully specified out (especially as this is merely
a suggestion), but the terms of RFC6724 seem to be helpful and were added in
https://github.com/core-wg/resource-directory/pull/298.

A review from this has been requested in the review request to 6MAN (see
GENERIC-6MAN).

> As a co-author of RFC 8801, I would have appreciated to read PvD option
> mentionned to discover the RD. Any reason why PvD Option cannot be used ?

response:

Probably because 8801 was just published, and the RDAO predates even -pvd-00 by
a year.

Sassiness aside, as I understand the PvD option from a skim and the vague
recollections of having had a look at this at some earlier time, this would be
orthogonal to the RDAO: a router with multiple PvDs could forward the RDAO from
either uplink inside PvD options, and pick a primary one to forward to
PvD-unaware hosts.

I don't see any conflict, but don't see much potential either (are there many
constrained devices that benefit from becoming PvD-aware?) -- so I'd keep it as
with any other RA option: They can be combined, but there's no particular
reason to point that out on either side.

If such a combination can be expected, this could be a good example for the
"MAY keep concurrent registrations if explicitly configured to do so" part, but
that was not added in this iteration for lack of known use cases.

(This is slightly more interesting in cases when the RD picks the addresses; a
note on that will appear in the next version of
draft-amsuess-core-resource-directory-extensions).

> -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in
> order to be able to use a lifetime in units of seconds (to be consistent with
> other NDP options).

response:

Implementors will appreciate that; done in
https://github.com/core-wg/resource-directory/pull/299.

> -- Section 5 -- May be I missed it, but, can an end-point register multiple
> base URI ? E.g., multiple IPv6 addresses.

response:

No, that is deferred to protocol-negotiation (where whatever comes out of it is
expected to do multiple addresses on the same protocol just as well as
different protocols).

> -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781.

response:

Leaving it in the draft as-is, anticipting that IANA just picking the next
available number will create less total cognitive load than another set changed
lines in the diffs.

> == NITS ==
> 
> -- Section 2 -- The extra new lines when defining "Sector" are slighly
> confusing. Same applies to "Target" and "Context". This is cosmetic only.

response:

We're having issues with the tooling here; if it can't be ironed out before the
final version, this will be fixed manually during the handover to RFC editor.

Issue: https://github.com/core-wg/resource-directory/issues/252