Re: [dhcwg] Erik Kline's Yes on draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: (with COMMENT)

[[e-mail]]

Hi Erik

Thanks for your comments. Please see inline below.

Ian

> On 17. Dec 2020, at 02:52, Erik Kline via Datatracker <[e-mail]> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: Yes
> 
> 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-dhc-dhcpv6-pd-relay-requirements/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ questions ]]
> 
> [ general ]
> 
> * Should this aim for BCP?

[if - We used RFC7084 as the template for this as another device
requirements document, which is not BCP. Beyond that, I’m not
sure how this decision gets made.]

> 
> [ section 4.2 ]
> 
> * Seems like the MUST in R-4 is contingent upon implementation of
>  the MAY that precedes it.  It might worth sneaking in some condition
>  phrase like, "If such a mechanism is implemented ... MUST ...".

[if - Changed]

> 
> * It seems to me that R-5 would prevent a client from monitoring the
>  CMTS/BNG for correctly installed routes by sending it a packet with
>  a destination address in its delegated prefix and checking that it gets
>  reflected back (similar to other checks done for tunnels).  (I recognize
>  this is not guaranteed to work in all environments.)
> 
>  What should a client wishing to keep an eye on this stuff do?  Just ping
>  a public service with an address in each source prefix of interest?

[If - If an ISP used the method you describe as a client <-> relay health check as
part of their service design, then the R-5 drop policy can be disabled.

Otherwise, yes pinging a public service sourced from a delegated prefix address
would work.  If ICMP errors are enabled on the relay, then this would also give
the client better visibility if the cause of a failure is due to the relay having lost the
PD.]

> 
> 
> [[ nits ]]
> 
> [ section 2.1 ]
> 
> * "This document serves" -> "This document discusses", or
>  "This document is concerned with", or something, perhaps?
> 
> 
>