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

[Barry Leiba <[e-mail]>]

Éric, will you please check version -26 and see if your DISCUSS is
handled there?

Thanks,
Barry

On Wed, Aug 5, 2020 at 3:33 AM Éric Vyncke via Datatracker
<[e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-core-resource-directory-25: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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.
>
> 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.
>
> BTW, I appreciated the use of ASCII art to represent an entity-relationship
> diagram !
>
> Please find below a couple of non-blocking COMMENTs (and I would appreciate a
> reply to each of my COMMENTs) and 2 blocking DISCUSS points (but only trivial
> actions/fixes are required).
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == 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).
>
> -- 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.
>
>
> ----------------------------------------------------------------------
> 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.
>
> -- 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.
>
>
>