Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-02.txt

[[e-mail]]

Hi Bernie,

Thanks for the comments. Did you have any thoughts about the proposed change to the title?

Please see inline below.

Thanks,
Ian

> On 7. Oct 2020, at 21:08, Bernie Volz (volz) <[e-mail]> wrote:
> 
> Hi:
> 
> Thanks Ian for the updates.
> 
> I suggest we wait a few days to see if v6ops or ipv6 working groups have any comments (as your emailed them) before I proceed with sending the document on.
> 
> 
> In reviewing, I also noticed the following minor items:
> 
> Minor nit in section 1?
> 
>   Multi-hop DHCPv6 relaying is not affected, as the requirements in
>   this document are solely applicable to the DHCP relay agent co-
>   located with the first-hop router that the DHCPv6 client requesting
>   the prefix is connected to, no changes to any subsequent relays in
>   the path are needed.
> 
> Would "so no changes" (or thus no changes) be appropriate? It just seems something is missing here. Though two free grammar checkers I used didn't seem to flag it broken (either with or without my changes).

[if - Re-reading this, the sentence is overlong and the commas make it difficult to parse. I think the following wording clears this up:

  Multi-hop DHCPv6 relaying is not affected.  The requirements in
  this document are solely applicable to the DHCP relay agent co-
  located with the first-hop router that the DHCPv6 client requesting
  the prefix is connected to, so no changes to any subsequent relays in
  the path are needed.
]

> 
> And, in section 3.5:
> 
>   If the client loses information about a prefix that it is delegated
>   while the lease entry and associated route is still active in the
>   delegating relay, then the relay will forward traffic to the client
>   which the client will return to the relay (which is the client's
>   default gateway (learnt via an RA).  The loop will continue until
>   either the client is successfully reprovisioned via DHCP, or the
>   lease ages out in the relay.
> 
> Missing a second closing parenthesis: (which is the client's default gateway (learnt via an RA)). 

[if - OK]

> 
> Please do not publish an 03 for now as these issues are very minor. We can see if other comments are raised.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg <[e-mail]> On Behalf Of [e-mail]
> Sent: Wednesday, October 7, 2020 6:25 AM
> To: dhcwg <[e-mail]>
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-02.txt
> 
> Hi
> 
> We’ve just posted an update to this draft based on the comments received in WGLC. Many thanks for your reviews and suggestions.
> 
> The major changes since -01 are:
> 
> 1. Rewritten abstract section
> 2. Provided clarification on multi-hop relays
> 3. Changed text related to handling of unknown messages by relays and removed req. G-2 that covered this.
> 4. Provided references to sections in CMTS and BNG documents
> 5. Added section about forwarding loops between clients and relays
> 6. Updated requirement R-4 to detail on avoiding the loops
> 
> I think that all of the WGLC comments are now addressed, with the exception of a question from Ole regarding implementors experience related to requirement R-4. I’ve just sent out a question on v6ops and 6man to see if we can get feedback on this.
> 
> One final question. The draft is currently called "DHCPv6 Prefix Delegating Relay” which is not particularly descriptive. We suggest changing it to ‘Requirements for DHCPv6 Prefix Delegating Relays’. Any objections to this?
> 
> Thanks,
> Ian
>