Re: [Int-area] [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-03.txt

[<[e-mail]>]

Hi Richard, 

Thank you for promptly addressing the comments. 

This version is stable enough and ready for a hopefully call for adoption. 

Cheers,
Med

> -----Message d'origine-----
> De : Richard Patterson [mailto:[e-mail]]
> Envoyé : lundi 2 juillet 2018 22:06
> Cc : BOUCADAIR Mohamed IMT/OLN; [e-mail] list; [e-mail];
> [e-mail]; [e-mail]; CLOAREC Jean-Yves IMT/OLN
> Objet : Re: [v6ops] New Version Notification for draft-patterson-intarea-
> ipoe-health-03.txt
> 
> Med,  I've just pushed -04 out before the cutoff deadline this
> evening. Hopefully I've correctly integrated your comments.
> 
> A new version of I-D, draft-patterson-intarea-ipoe-health-04.txt
> has been successfully submitted by Richard Patterson and posted to the
> IETF repository.
> 
> 
> 
> Name:           draft-patterson-intarea-ipoe-health
> Revision:       04
> Title:          IP over Ethernet (IPoE) Session Health Checking
> Document date:  2018-07-02
> Group:          Individual Submission
> Pages:          16
> URL:
> https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-
> 04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/
> Htmlized:
> https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-04
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-patterson-intarea-ipoe-health-04
> 
> Abstract:
>    PPP over Ethernet clients have the functionality to detect path
>    unavailability by using PPP Keepalives.  IP over Ethernet does not
>    have this functionality, and it is not specified in the IETF when an
>    IP over Ethernet client should consider its WAN connectivity down,
>    unless there is a physical layer link down event.
> 
>    This document describes a mechanism for IP over Ethernet clients to
>    achieve connectivity validation, similar to that of PPP over
>    Ethernet, by using BFD Echo, or ARP and Neighbor Discovery functions.
> On Mon, 2 Jul 2018 at 19:21, Richard Patterson <[e-mail]> wrote:
> >
> > Hi Med,
> >
> > Thanks once again for your review, comments, and support.
> > I'll address your bullet points in-line below.  I'll try to get a -04
> > out incorporating your feedback before the cut off.
> >
> >
> > On Mon, 2 Jul 2018 at 09:29, <[e-mail]> wrote:
> > > The main comments:
> > > * Use 3 as default retry interval value (consistent with BBF TR-124 and
> some existing implementations).
> >
> > Have reworded the parameter definition to:
> > - Limit (Integer): The number of failed consecutive checks before an
> > action is taken. Default value: 3.
> >
> > > * Generalize the procedure to cover any dynamic configuration means
> (DHCP, as an example among others).
> >
> > I agree for the most part, but I'm unsure about considering TR-69 as
> > dynamically signalled.  I was treating TR-69 as a method for local
> > configuration (which we've now changed to static in -03).
> > I think the idea is the same though, so I'll work your suggested wording
> in.
> >
> > > * Add a guard to prevent loopback and multicast addresses as alternate
> target @
> >
> > Is saying that the field must be a unicast address sufficient, or do
> > you want to specifically call out loopbacks and multicast?
> >
> > > * Double check some part of the text to reflect that both interval and
> retry-interval are now used.
> > >
> > > I do support this effort to be adopted in dhcwg or int-area.
> > >
> > > Cheers,
> > > Med