Subject: [Pals] Spencer Dawkins' No Objection on draft-ietf-pals-status-reduction-04: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Sun, 09 Apr 2017 19:26:20 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-pals-status-reduction-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-pals-status-reduction/

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

In this text,

    -iii. If the new value is smaller then the original one, the PE
            will operate according to the original timer value for a
            period 3.5 times the original timer value, or until the
            first valid PW status refresh reduction message is
received.

Perhaps it would be helpful to explain the choice of 3.5, so that if this
mechanism is deployed for a network where that number is the wrong
number, people will know how to adjust it? 

There are several occurrences where s/then/than/ is needed, I think. I
spotted at least 3.

Other nits …
S/octetc/octets/
S/RECOMENDED/RECOMMENDED/
S/vaules/values/

In section 7. Security Considerations

   The security considerations of [RFC6478] are adequate for the
   proposed mechanism since the operating environment is almost
   identical to the one where this protocol would be deployed. It
should
   also be noted that since this protocol is designed to be deployed
   between two adjacent PEs connected by a physical link, it is not
   possible to misdirect or inject traffic without compromising the PW
   transport link itself. All these situations are covered in the
   security considerations of [RFC6478].

There's an appeal to physical adjacency as a defensive mechanism. If this
protocol is deployed in a tunnel over UDP, would “physical adjacency”
still be true?