Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
RFC 7727

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

(Deborah Brungard) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-09-30 for -04)
No email
send info
- 3.3.5: is that a hard-coded sha1 or md5? if so, why is that
ok? what if 802.1q is fixed/improved e.g. to use sha256?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2015-10-01 for -04)
No email
send info
This is a small thing, but please give some consideration to this:

A 2119 "SHOULD" defines something that implementations need to do unless they have a good reason not to, and fully understand the issues and the consequences of not doing it.  In general, I believe that means that specifications, when they use "SHOULD", need to include enough information for readers to understand why it's a "SHOULD" and to evaluate the consequences.  That seems missing from many of the SHOULDs here, and I'd like to see you go through the document, find the ones that aren't making it clear enough, and beef them up just a little.

An example where this is done right is in Section 4.2.3:

   While a PE has sent out a synchronization request for a particular PE
   node, it SHOULD silently ignore all TLVs from that node, that are
   received prior to the synchronization response and which carry the
   same type of information being requested.  This saves the system from
   the burden of updating state that will ultimately be overwritten by
   the synchronization response. Note that TLVs pertaining to other
   systems should continue to be processed normally.

THe second sentence explains why, and gives me some idea of what to consider when I'm writing my implementation.  Thank you.  There are others that get it right as well.

A particularly weak one is in Section 4.2.1:

   A PE SHOULD follow the following order when advertising its STP state
   upon initial application connection setup:

What's the significance of that order, from an interoperability, performance, or security perspective?  What happens if, because of how my implementation is written, it's easier for me to do them in a different order and I decide to do so, not knowing what the consequences are?

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-09-29 for -04)
No email
send info
Please see the nits found in the SecDir review:

Alvaro Retana No Objection

(Martin Stiemerling) No Objection