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

[Barry Leiba <[e-mail]>]

Erik, will you please check Christian's response and version -26, and
see if your DISCUSS is handled?

Thanks,
Barry

On Tue, Nov 3, 2020 at 12:29 PM Christian Amsüss <[e-mail]> wrote:
>
> (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:
>
> > [ section 4.1.1 ]
> >
> > * Did this get presented to 6man at any point, either via mail to the list or
> >   chair or in a presentation slot at an IETF meeting or a 6man interim?
> >
> >   I feel confident that there would be no objection to the option as described
> >   here, but the working group should have its chance to make an evaluation
> >   irrespective of my opinion.
>
> see: GENERIC-6MAN
>
> >   If this is to be used when link-local methods don't work, another option
> >   would have been to add an RD PVD API key and recommend including a PVD
> >   option.
>
> response:
>
> The RDAO should compose well with PvD based options without further measures,
> but does not receive explicit treatment here as no use of PvDs is known with
> constrained devices yet. Please see the more comprehensive discussion of PvD in
> the comment Éric Vyncke raised.
>
> > [ section 4.1.1 & 9.2 ]
> >
> > * Please clarify which ND messages can carry an RDAO.  I suspect they should
> >   only appear in RAs, but it would be good to state the expectation explicitly.
>
> respond:
>
> You are right, and the text now says so.
>
> The concrete change is in https://github.com/core-wg/resource-directory/pull/262.
>
> > [ Appendix A. ]
> >
> > * Can you explain the ff35:30:2001:db8:1 construction?  RFC 3306 section 4
> >   defines some fine-grained structure, and I'm wondering how a group ID of 1
> >   is selected/computed/well known.  If there is already a COAP document
> >   describing this vis. RFC 3307 section 4.*, perhaps it's worth dropping a
> >   reference in here.
>
> response:
>
> See GENERIC-FFxxDB
>
> As COMMENT:
>
> > [ section 1 ]
> >
> > * I'm unclear on what "disperse networks" might mean.
>
> response:
>
> Well how do I phrase this ... so were we. As the term does not provide
> justification for using an RD, it was removed from abstract and introduction in
> https://github.com/core-wg/resource-directory/pull/269.
>
> > [ section 10.1.1 ]
> >
> > * What is meant by "therefore SLAAC addresses are assigned..." followed by this
> >   table of not-very-random-looking IPv6 addresses?
> >
> >   Is the assumption that there might not be some off-network DNS server but
> >   there is some RA with a /64 A=1 PIO?
>
> response:
>
> There are two scenarios that satisfy the tacit assumptions -- a router can be
> in place without an uplink or any DNS server and still supply ULA A=1 PIOs, or
> there is a routable prefix around, but not yet coordinated with the lighting
> installation.
>
> The 2001:db8:: addresses are indeed not what one would get out of SLAAC, but
> full random addresses would make the examples hard to read. Where the addresses
> are introduced, they are now called stand-in addresses for the examples (see
> https://github.com/core-wg/resource-directory/pull/268 for full
> change).