Re: [Pals] Warren Kumari's No Objection on draft-ietf-pals-p2mp-pw-lsp-ping-03: (with COMMENT)

[Warren Kumari <[e-mail]>]

Okey dokey -- that all works for me.

Thanks,
W

On Wed, Jun 21, 2017 at 12:26 PM Parag Jain (paragj) <[e-mail]>
wrote:

> Hi Warren
>
> Please see inline.
>
>
> On 2017-06-21, 11:26 AM, "Warren Kumari" <[e-mail]> wrote:
>
>     Warren Kumari has entered the following ballot position for
>     draft-ietf-pals-p2mp-pw-lsp-ping-03: 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-p2mp-pw-lsp-ping/
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     I like the solution, but the document could do with some editing.
>
>     Major:
>     1: Sec 1.  Introduction
>     O:  Multi-segment Pseudowires support is out of scope of this document
> at
>     present and may be included in future. P:  Multi-segment Pseudowires
> support is
>     out of scope of this document. C: Once published as an RFC, the
> document
>     doesn't change. Could be "... may be addressed in a future document",
> but I'd
>     suggest leaving it out.
>
> Will change to “Multi-segment Pseudowires support is out of scope of this
> document”.
>
>
>     2: General
>     The document has many unexpanded acronyms, e.g: ACH in "... MPLS label
> stack
>     and IPv4 or IPv6 ACH."  In the Introduction you have: "such as P2MP
> ATM over
>     PSN." - while PSN might count as a well known acronym, it feels like,
> in an
>     Intro it should be less opaque - see
>     https://www.rfc-editor.org/materials/abbrev.expansion.txt for RFC
> known
>     acronyms.
>
> Will fix. Also go through the doc for any more missed acronyms.
>
>     3: The "Controlling Echo Responses" section feels weak -- it says
> that  "The
>     procedures ... **can** be applied to P2MP PW LSP Ping." (emphasis
> added) - it
>     feels like this should be a SHOULD? I think better a description of
> the DoS
>     implications (other than just pointing at RFC6425) is also important.
>
> Will change to should. RFC6425 describes the need and procedures
> themselves in detail. IMO, adding details to  this document is not needed.
> I will refer to specific Sections of RFC6425 to make it more explicit. Let
> me know if that will work.
>
>     Nits:
>     1: The document would benefit from some serious grammar checking --
> e.g:
>     "... Echo Request to inform the receiver at P2MP MPLS LSP tail, of the
> P2MP PW
>     being tested." - extra ','. "For Inclusive P-Trees, P2MP MPLS LSP
> label itself
>     can uniquely identify the Throughout the document..." - missing 'the'
> - things
>     like this, and confusion over plurals (especially near acronyms) makes
> the
>     document hard to read / review.
>
> Will fix.
>
>     2: "P2MP ATM over PSN.   Requirements for ... " - extra space (nit!)
>
> will fix.
>
>     3: Sec 8.  Security Considerations
>     "The proposal introduced in this document does not introduce any new
> security
>     considerations beyond that already apply to [RFC6425]." -- this
> sentence is
>     poorly formed. Perhaps "beyond those that..."? Or "beyond those in"?
>
> will fix.
>
> Thanks
> Parag
>
>
>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf