Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Thu, 01 Oct 2015 06:42:57 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-pwe3-iccp-stp-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 9 Oct 2015 02:44:16 +0000

Hi Barry,

Thanks for the comments. Please see the in-lines below.

> -----Original Message-----
> From: Pals [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, October 01, 2015 9:43 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with
> COMMENT)
> 
> 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.

[MZ] Authors has gone through the document. Now the ones that aren't cleared have been cleared.

> 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.
> 
> 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?

[MZ] It is for a performance reason. The following sentences will be added.

The update of the information contained in the State TLVs depends on that in the configuration TLVs. By sending the TLVs in the above order, the two peers may begin to update STP state as early as possible in the middle of exchanging these TLVs.

Thanks,
Mingui

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Oct 2015 07:47:40 -0700

Thanks, Mingui, for your response, and for considering my comments!

Barry