Skip to main content

Bidirectional Forwarding Detection (BFD)
RFC 5880

Discuss


Yes

(Adrian Farrel)

No Objection

(Alexey Melnikov)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

Recuse

(David Ward)

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

Lars Eggert (was Discuss) No Objection

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

  Remove this sentence.

(Chris Newman; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-03-05)
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; former steering group member) (was No Objection, Discuss, Yes) Yes

Yes ()

                            

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection (2009-03-05)
support Lars discuss

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) (was No Record, No Objection) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection (2009-02-12)
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

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) (was Discuss, Yes) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2008-06-04)
  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 ...".

(Tim Polk; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) Recuse

Recuse ()