Generic Application of Bidirectional Forwarding Detection (BFD)
draft-ietf-bfd-generic-05

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert No Objection

Comment (2008-06-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
INTRODUCTION, paragraph 10:
>    Comments on this draft should be directed to rtg-bfd@ietf.org.

  Remove this sentence.

(Ross Callon; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2009-03-05)
No email
send info
As I read this document, I realized that it covers extremely well the
aspects for applying it to routing protocols and routing-protocol -like
situations. However, upon reading the title, abstract, and introduction
I had actually expected more information about WHEN BFD can be applied
and in particular when it cannot. I also expected better coverage of
what the issues are in applying it across different types of 
environments, e.g., multipath, on-link, networks that employ
various types of filtering, etc.

A few cases in point: is BFD applicable over paths and not just links,
and under what conditions? What are the congestion avoidance 
implications? (Word "congestion" does not appear in the document set,
btw.) Using BFD as a means to detect
liveness of connectivity to a number of peers across the Internet may
not be wise, if it causes constant packet flows to all of them unless
you specify what kind of parameters would be suitable (e.g., infrequent
messaging would still be OK).

Update: Generic: I did not see very much changes relating to my Discuss. I believe at least the applicability of Echo mode should be discussed, maybe other things too. This is not too hard to do (and we already agree on the technical content, like the fact that Echo mode cannot be performed over situations like the multihop), can you suggest text?

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection (2008-06-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Sandy Murphy's SecDir review identified a number of places
that would benefit from some clarification/editorial changes;
these should be fixed during AUTH48 (if not earlier).

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2008-06-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The title page header should indicate that the intended status for
  this document: Proposed Standard.

(Tim Polk; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Ward; former steering group member) Recuse

Recuse ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info