Seamless Bidirectional Forwarding Detection (S-BFD)
RFC 7880

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

(Alia Atlas) (was Discuss) Yes

Comment (2016-05-03 for -09)
No email
send info
Thank you for addressing my Discuss concerns.  I look forward to the updated draft.

Alvaro Retana Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2016-05-03 for -09)
No email
send info
DISCUSS cleared based on proposed edits by Carlos. Thanks for addressing it!

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-05-03 for -09)
No email
send info
- Section 11: I've had discussions with people from time
to time about BFD and security. I think I've heard the
claim made that authentication was too expensive. (Note:
I am not saying that I accept that as a valid claim, but
that's a different issue:-)  Anyway, wouldn't the same
issues apply here if they do to classical BFD?  If not,
great, and I'll quote you next time someone says crypto
is too expensive.  But if such claims are also to be made
here, then why would you be specifying something that
will not be used? 

- Do the implementations that are in-progress implement
the BFD authentication schemes for S-BFD?

- Why not recommend that the weaker options from rfc5880
not be used? At least saying to not send passwords in
clear over networks would be a good thing.

- This document could do with an editing pass. There are
quite a few minor grammatical issues that make this a
harder read. I guess the RFC editor will fix those
though, and they're non-fatal, but seems like a pity to
not have done that already.

(Joel Jaeggli) No Objection

Comment (2016-05-04 for -10)
No email
send info
victor kuarsingh performed the opsdir reivew.

Suresh Krishnan No Objection

Comment (2016-05-04 for -10)
No email
send info
Section 3:

This sentence is not clear. Which one of the following Options (1&2) do you intend? I am guessing 2, but it may make sense to clarify in either case.

Current:

   Once the above setup is complete, any network node, having the
   knowledge of the S-BFD discriminator allocated to by a remote node to
   remote entity/entities

Option 1:

   Once the above setup is complete, any network node, having the
   knowledge of the S-BFD discriminator allocated to it by a remote node to
   remote entity/entities

Option 2:

   Once the above setup is complete, any network node, having the
   knowledge of the S-BFD discriminator allocated by a remote node to
   remote entity/entities

Section 7.2.1.  Responder Demultiplexing

The last step in section seems to be pointing to the initiator packet transmission. Shouldn't this point to the responder procedures (Section 7.2.2) instead?

"Chosen reflector BFD session SHOULD transmit a response BFD control packet using procedures described in Section 7.3.2."

Mirja K├╝hlewind (was Discuss) No Objection

Comment (2016-05-04 for -09)
No email
send info
Thanks for addressing my comments! I'll check the updated version next week (after the telechat).

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2016-05-03 for -09)
No email
send info
Thanks for addressing my prior discuss comments in the updated draft, noting them here to check before approval.

This should be pretty easy to address.  In the security consideration section, the following recommendation appears:

 o  SBFDReflector MUST NOT look at the crypto sequence number before
      accepting the packet.

Could you please add text to say what happens (what attacks are possible) if this is looked at?  There is nothing to stop the crypt sequence number from being looked at, right?  Is there a way to actually prevent that?