Bidirectional Forwarding Detection (BFD)
RFC 5880

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

(Chris Newman) Discuss

Discuss (2009-03-05 for -)
Version 09 did not add new text to address the first issue (charset of
password).

New text was added about key management ruling it out-of-scope.  That,
by itself, is not sufficient for interoperability.  If keys in an
unspecified format which may or may not be textual, need to be
provisioned in an unspecified fashion, I'm unsure how this will
interoperate.  40-bit WEP took this approach and we got
non-interoperable UIs on different platforms (some require 0x prefix,
some support a text-to-binary on a password, some do not).

---
Section 4.2

If password is human enterred text string, you need to state a charset
and any sort of mandatory-to-implement preparation.   BCP 18 mandates
use of UTF-8 unless you request a variance (that we require a restart of
IETF last call). We have two choices on the standards track for
mandatory-to-implement preparation of human enterred text used for this
sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC
5198).  We do not have a BCP that requires preparation so I'm not going
to hold a discuss over the preparation issue but I recommend you fix it.
There is not likely to be a significant change to net unicode, but there
may be a significant change to SASLprep in the future.  However,
SASLprep will have someone better interoperability for non-ASCII
password characters.

While you could make the password binary so charset issues do not apply,
that's only reasonable if there's a way to bootstrap the binary
password.  If it really is human enterred, as it is with WEP and WPA,
then the WPA approach (where it's a human enterred password rather than
a human enterred hex string -- but some implementations found that user
hostile and invented a non-interoperable string-to-key as a result) has
proved to be more interoperable in practice, IMHO.

Section 4.3, 4.4

You need to define the key management for these keys.  Are they
passwords configured by humans into config files?  If so, the
charset and canonicalization issues apply.

(Adrian Farrel) (was No Objection, Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) (was Discuss, Yes) No Objection

(Lisa Dusseault) (was No Record, No Objection) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2008-06-04)
No email
send info
INTRODUCTION, paragraph 10:
>    Comments on this draft should be directed to rtg-bfd@ietf.org.

  Remove this sentence.

(Pasi Eronen) (was Discuss) No Objection

Comment (2009-02-12)
No email
send info
In Section 8, values 9-31 (for diagnostic code) and 6-255 (for
authentication types) should be marked as "unassigned", not
"reserved".

Section 8, the table of BFD Authentication Types still talks about
diagnostic codes in the column header.

Section 10.2: RFC 2434 has been obsoleted by 5226

(Russ Housley) (was Discuss) No Objection

Comment (2008-06-04)
No email
send info
  The title page header should indicate that the intended status for
  this document: Proposed Standard.

  Section 4.3 says:
  >
  >   Reserved
  >
  >      This byte must be set to zero on transmit, and ignored on
  > receipt.
  >
  As Spencer Dawkins raised in his Gen-ART Review: s/must/MUST/

  Section 6.6 includes:
  >
  > Note that this mechanism requires that the Detection Time negotiated
  > is greater than the round trip time between the two systems, or the
  > Poll mechanism will always fail.  Enforcement of this requirement is
  > outside the scope of this specification.
  >
  Based on the discussion of the Gen-ART Review by Spencer Dawkins, it
  might be better to say "Enforcing the requirement to meet the
  constraint ...".

(Cullen Jennings) No Objection

Comment (2009-03-05 for -)
No email
send info
support Lars discuss

Alexey Melnikov (was Discuss) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) Recuse