Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
draft-ietf-pwe3-iccp-stp-05

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

Alvaro Retana No Objection

(Deborah Brungard; former steering group member) Yes

Yes ( for -04)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (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?

(Ben Campbell; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-09-29 for -04)
No email
send info
Please see the nits found in the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06068.html

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (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?

(Terry Manderson; former steering group member) No Objection

No Objection ( for -04)
No email
send info