[Ballot discuss]
This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross notes in his Discuss.

It appears that there are two related disclosures in the system
https://datatracker.ietf.org/ipr/516/ (Nortel 2005-01-06)
https://datatracker.ietf.org/ipr/1143/ (Juniper 2009-05-07)

The first of these was in place when working group and IETF last calls were held, but does not appear to have been flagged. The second is more recent.

It is my intention to pursue the disclosures Ross refers to and then to ensure that the WG and the wider community are consulted.

[Ballot discuss]
This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross notes in his Discuss.

It appears that there are two related disclosures in the system
https://datatracker.ietf.org/ipr/516/ (Nortel 2005-01-06)
https://datatracker.ietf.org/ipr/1143/ (Juniper 2009-05-07)

The first of these was in place when working group and IETF last calls were held, but does not appear to have been flagged. The second is more recent.

It is my intention to pursue the disclosures Ross refers to and then to ensure that the WG and the wider community are consulted.

[Ballot discuss]
It is possible that there might be an IPR statement forthcoming. This discuss is just here until this is cleared up (one way or another).

[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements for this protocol are rather
unusual, since we're basically interested in "liveness" rather than
authentication of some content (and loss of packets moves us to "down"
state) -- so having a weak MAC construction could be acceptable
(but there needs to be text describing why it was done this way).

It would help if the security considerations section had slightly more
text about the threats, and what threats are mitigated by the security
mechanisms (authentication section and GTSM), and what threats still
exist (this is probably quite obvious to the authors -- but in that
case, writing it down should be easy). Also, the Echo function should
be mentioned somewhere here.

[Ballot discuss]
Carrying over DISCUSS from Chris Newman:

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.

[Ballot discuss]
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.

[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements for this protocol are rather
unusual, since we're basically interested in "liveness" rather than
authentication of some content (and loss of packets moves us to "down"
state) -- so having a weak MAC construction could be acceptable
(but there needs to be text describing why it was done this way).

It would help if the security considerations section had slightly more
text about the threats, and what threats are mitigated by the security
mechanisms (authentication section and GTSM), and what threats still
exist (this is probably quite obvious to the authors -- but in that
case, writing it down should be easy). Also, the Echo function should
be mentioned somewhere here.

[Ballot comment]
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

[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements for this protocol are rather
unusual, since we're basically interested in "liveness" rather than
authentication of some content (and loss of packets moves us to "down"
state) -- so having a weak MAC construction could be acceptable
(but there needs to be text describing why it was done this way).

It would help if the security considerations section had slightly more
text about the threats, and what threats are mitigated by the security
mechanisms (authentication section and GTSM), and what threats still
exist (this is probably quite obvious to the authors -- but in that
case, writing it down should be easy). Also, the Echo function should
be mentioned somewhere here.

The protocol has several fields where new values could be allocated in
the future, but no description about how that's done (e.g. by IANA or
otherwise) or what the requirements are (e.g. standards track or first
come first served).

From Alexey Melnikov's SecDir review:

The document should explicitly say that the key for MD5 (SHA1) must be
exactly 128 (160) bits (there's no padding or truncation) -- or if
this is not true, describe how padding/truncation/whatever is done.

[Ballot discuss]
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.

[Ballot discuss]
Section 6.8.3., paragraph 0:
> 6.8.3. Timer Manipulation

  DISCUSS: BFD is congestion-unresponsive, i.e., it doesn't react to
  loss by taking load off the path. For many uses of BFD, especially
  ones that it seems to have been specifically designed for, I don't
  have an issue with this approach. For example, using BFD to monitor
  liveness of directly adjacent routers connected through a single link
  can probably be safely achieved by configuring timers based on
  knowledge of the link capacity and delays, such that BFD will not
  consume significant resources. (An addition to the applicability text,
  by the way, that discusses guidelines for this configuration would be
  very helpful IMO.)
 
  But BFD aims to be a generic protocol to detect the liveness between
  components that can be connected via arbitrary means, over paths
  with many hops and unknown traffic loads. When used for such
  purposes, BFD cannot simply punt on congestion control (see RFC2914).

  I see two ways forward: significantly restrict the scope of
  applicability for BFD, or describe a scheme that adapts transmission
  intervals (= transmission rates) based on RTTs and loss rates.
 
  (After writing this, I saw Jari's DISCUSS and I realize we raise similar
  issues.)

[Ballot comment]
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 ...".

[Ballot discuss]
IANA has questions:

  - Shouldn't you have a registry of Diagnostic codes (section 4.1)?

  - Shouldn't you have a registry of Auth Types (section 4.1)?

  If the answer to both questions is "no," we understand this document
  to have NO IANA Actions.

  I'll clear this DISCUSS position when IANA's questions are resolved.

Proto writeup by Dave Ward (as WG co-chair and author):

1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes. BT had brought together multiple vendors and implementors a year before publishing the docs to make sure every issue was cleared up and intention documented.

    Do you have any concerns about the depth or breadth of the reviews
    that have been performed?
   
    No.

3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No concerns

  5. How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

It represents strong consensus of a large group of implementors.

6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?

    Yes

8. Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with 
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

    Yes, No

  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

    Proposed Standard

10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following 
    sections:

    * Technical Summary:

BFD and the corollary documents define a mechanism for layer 3 forwarding plane failure detection. There are multiple modes (async, echo, demand) for different circumstances. One interesting aspect of BFD is that it has adaptive timers thus, parameters can be modified without tearing down adjacencies. In addition, the amount of BW and overhead incurred by the network and network nodes is completely under the control of the operator.

  * Working Group Summary

There was no opposition to this document.

    * Protocol Quality

The protocol is widely implemented and deployed and has become part of default deployments on the internet. The drafts reflect the lessons learned from the deployed and operation.

IANA Last Call comments:

IANA has questions:

- Shouldn't you have a registry of Diagnostic codes (section 4.1)?

- Shouldn't you have a registry of Auth Types (section 4.1)?

If the answer to both questions is "no," we understand this document
to have NO IANA Actions.