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

09:41.hk S8  Jan. 06 2021

Good Day,

It means nothing this when , ISP without officially acclaimed in a document
that it is supporting the DHCP-PD ... over months no feedback on it ?!

Sincerely
Li HUANG

On Thu, Dec 17, 2020, 20:42 <ianfarrer@gmx.com> wrote:

> Hi Erik
>
> Thanks for your comments. Please see inline below.
>
> Ian
>
> > On 17. Dec 2020, at 02:52, Erik Kline via Datatracker <noreply@ietf.org>
> 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?
> >
> >
> >
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>