[core] Éric Vyncke's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-core-resource-directory-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. As you can noticed, I have
cleared my 2 DISCUSS points (kept below for archive) thank you also for
replying to my comments over email.

BTW, I appreciated the use of ASCII art to represent an entity-relationship
diagram !

I hope that this helps to improve the document,

Regards,

-éric

== cleared DISCUSS (no more blocking, kept for history) ==

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

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

-- 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" ?

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

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

Please expand and add reference for 6LBR.

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

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

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

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 ?

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 ?

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

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

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

== NITS ==

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