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

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 16 Dec 2020 17:52:14 -0800

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?

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

* 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?

[[ nits ]]

[ section 2.1 ]

* "This document serves" -> "This document discusses", or
  "This document is concerned with", or something, perhaps?

---

From: [email-masked]
Date: Thu, 17 Dec 2020 13:42:20 +0100

Hi Erik

Thanks for your comments. Please see inline below.

Ian

> On 17. Dec 2020, at 02:52, Erik Kline via Datatracker <[email-masked]> wrote:
> 

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

>  phrase like, "If such a mechanism is implemented ... MUST ...".

[if - Changed]

>  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.]