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

[Mingui Zhang <[e-mail]>]

Hi Barry,

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


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

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

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

[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