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

[Erik Kline via Datatracker <[e-mail]>]

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?