Subject: [Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Sun, 07 Jun 2020 23:00:55 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: 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-ospf-te-link-attr-reuse/

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

Three main things from me:

(1) I found I'm in agreement below with some of the points raised in the posted
OPSDIR review.  Please give that another once-over.

(2) A grammatical point: I think nearly every instance in this document of
"which" should be replaced by "that".

(3) In Section 12.3.3, I don't think it's appropriate to use MUST-type language
to constrain future document authors.

And now, my nit-storm:

Section 1:
* "... attribute advertisements - examples of which ..." -- hyphen should be a
comma * "... for a link that is not enabled for RSV-TE." -- s/RSV/RSVP/ * "...
path via that link it will result ..." -- comma after "link"

Section 3:
* Please define, or provide a reference for, "GMPLS".

Section 4.1:
* "... not inspected by OSPF, that acts as ..." -- s/that/which instead/

Section 5:
* Several changes to this paragraph suggested:
OLD:
   On top of advertising the link attributes for standardized
   applications, link attributes can be advertised for the purpose of
   application that is not defined as standardized one.  We call such
   application a user defined application.  What such application might
   be is not subject to the standardization and is outside of the scope
   of this specification.
NEW:
   On top of advertising the link attributes for standardized
   applications, link attributes can be advertised for the purpose of
   applications that are not standardized.  We call such an
   application a "User Defined Application" or "UDA".  These applications are
   not subject to standardization and are outside of the scope
   of this specification.

* Is the snapshot of the current content of the Link Attribute Application
Identifier Registry needed?  The rest of the document doesn't seem to reference
it. * "... to advertise all UDAs." -- although it's fairly clear at this point
what a UDA is, I suggest defining it somewhere above, maybe by hanging it off
one of the other places where the full name is used such as in the paragraph
above

Section 6.1:
* Please expand "IPFRR" on first use.

Section 6.2:
* "All these can be used ..." -- s/All/All of/

Section 11:
* "- e.g.  RSVP-TE -" -- comma after "e.g."
* "... one need to make sure ..." -- s/need/needs/
* "... applications, where the enablement ..." -- remove comma
* "... such application - e.g.  LFA." -- change to "such application.  An
example of this is LFA."

Section 12.3.4:
* "Link attributes that are NOT allowed  ..." -- s/NOT/not/

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Jun 2020 12:53:43 +0200

Hi Murray,

thanks for your comments, please see inline:

> https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

which ones in particular? I've responded to all of them, so it's hard 
for me to figure out which ones do you have in mind.

> "which" should be replaced by "that".

I let this be checked by the English language experts :)

> to constrain future document authors.

What we are saying is that if there is a router in the network that does 
not understand this new way of advertising the link attributes, all 
routers MUST continue to advertise it in the old way (on top of possibly 
advertising new way). What constrain would this pose to future documents?

> path via that link it will result ..." -- comma after "link"

fixed.

> * Please define, or provide a reference for, "GMPLS".

fixed

> * "... not inspected by OSPF, that acts as ..." -- s/that/which instead/

fixed

>     not subject to standardization and are outside of the scope

done.

> it. * 

I believe it is useful to mention it here.

"... to advertise all UDAs." -- although it's fairly clear at this point
> one of the other places where the full name is used such as in the paragraph

I thought the edited paragraph

"On top of advertising the link attributes for standardized 
applications...."

defines UDAs clearly.

> * Please expand "IPFRR" on first use.

done

> * "All these can be used ..." -- s/All/All of/

fixed.

> * "... such application - e.g.  LFA." -- change to "such application.  An

fixed

> * "Link attributes that are NOT allowed  ..." -- s/NOT/not/

fixed.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 9 Jun 2020 14:59:32 +0000

Hi Peter, Murray, 

On 6/9/20, 6:53 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Murray,

I think I've changed all the instances where "which" was being used with a defining clause. See attached diff.

Thanks,
Acee

    fixed.

    fixed

    fixed

    done.

    defines UDAs clearly.

    done

    fixed.

    fixed

    fixed.

    thanks,
    Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 Jun 2020 11:19:13 +0200

Thanks Acee, I fixed them all.

Peter