Re: [core] Erik Kline'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:

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