Skip to main content

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

Yes

(Deborah Brungard)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

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

Deborah Brungard Former IESG member
Yes
Yes (for -04) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-10-01 for -04) Unknown
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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-09-29 for -04) Unknown
Please see the nits found in the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06068.html
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-09-30 for -04) Unknown
- 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 IESG member
No Objection
No Objection (for -04) Unknown