Re: [Int-area] AD Evaluation : draft-ietf-intarea-provisioning-domains-08

[Tommy Pauly <[e-mail]>]

Hi Suresh,

Thanks very much for the review!

We've posted a new -09 version to incorporate your feedback:

URL:            https://www.ietf.org/internet-drafts/draft-ietf-intarea-provisioning-domains-09.txt <https://www.ietf.org/internet-drafts/draft-ietf-intarea-provisioning-domains-09.txt>
Status:         https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ <https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/>
Htmlized:       https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-09 <https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-09>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-provisioning-domains-09 <https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-provisioning-domains-09>

Detailed responses inline.

Best,
Tommy

> On Dec 2, 2019, at 7:44 AM, Suresh Krishnan <[e-mail]> wrote:
> 
> Hi authors,
> I found this draft generally well written and easy to read but I would like a couple of things fixed in it before I send it off to IETF Last call.
> 
> Major
> ====
> 
> * Section 3
> 
> "The PvD ID is a Fully
>   Qualified Domain Name (FQDN) which MUST belong to the network
>   operator in order to avoid naming collisions."
> 
> Which network operator? Can you please clarify this.

Reworded this section to be more clear.

> 
> * Section 3.1
> 
> How is the Router Lifetime field processed if the R bit is set and the RA header is included? Is the intent that this will always supersede the “outer” Router Lifetime for PvD aware hosts? In any case this needs to be specified as it is not standard RFC4861 behavior.
> 

Added a reference down to the host behavior section, and added a sentence to explain precedence handling.

> * Section 3.4.1
> 
> Not sure if this is the best way to specify stateful DHCPv6. There are stateful options that will not be under a PIO (e.g. IA_PD). I think this document should limit itself to IA_NA and possibly IA_TA. Leaving this unbounded does not seem to be a good idea. Thoughts?
> 

The authors discussed, and we've left this as-is for now; part of the intention is to leave it open for implementations to associate IA_PD if they can. I can let Eric and Pierre chime in more on the details.

> * Section 4.1
> 
> "If the host has a temporary address per[RFC4941] 
>   in this PvD, then hosts SHOULD use a temporary address to
>   fetch the PvD Additional Information and SHOULD deprecate the used
>   temporary address and generate a new temporary address afterward.”
> 
> Not sure why this behavior is required. Can you please explain?

Added both a description of the reason for this (privacy protections), and made the recommendation a MAY.

> 
> * Section 5
> 
> I was thinking that there needs to be some host behavior to be specified related to the H bit and the sequence number here. If the H bit is set and the sequence number is unchanged from a previous successful query I think the host should refrain from sending another https query. If you agree, this needs to be written down.

I've added a new example section that details these considerations. Great suggestion!

> 
> Minor
> =====
> 
> * Section 1
> 
> This text is confusing and self-referential
> 
> OLD:
> Since such options are only
>   considered by hosts implementing this specification, network
>   operators may configure hosts that are 'PvD-aware' with PvDs that are
>   ignored by other hosts.
> 
> Suggest rewording to something like
> 
> Since such options are only
>   considered by hosts implementing this specification, network
>   operators may configure hosts that are 'PvD-aware' with PvDs that are
>   ignored by other hosts.

Fixed!

> 
> * Section 3.1
> 
> Not sure if the definition of the L flag is correct. Does the router actually need to provide the DHCPv4 information to set this? What if it is just a relay?
> 
> * Section 4.1
> 
> Not sure why there is a reference to RFC8615 here.

Remove this reference, and moved down to the IANA registration (where it is relevant).
> 
> Editorial
> ======
> 
> * Section 1
> 
> OLD:
> The ability to associate additional informations
> 
> NEW:
> The ability to associate additional information
> 
> OLD:
> deriving from it
> 
> NEW:
> derived from it

Fixed these.
> 
> Thanks
> Suresh
>