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

Peter Psenak <ppsenak@cisco.com> Tue, 09 June 2020 10:53 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81E3A0045; Tue, 9 Jun 2020 03:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOs0kNblRems; Tue, 9 Jun 2020 03:53:47 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECAE3A0061; Tue, 9 Jun 2020 03:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4393; q=dns/txt; s=iport; t=1591700027; x=1592909627; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=pI13VCDOJb+g+RPzWjUXJrMwKM3jK3xHgLsB3B10WHU=; b=QkihIFSEgl7uUO2D7YFvR69uP4jixFsng/lKnxTtGqdSajT6bn9sIyY8 4KBlJrdBBANpgFkrYjr77nZWtgYTXMuZl0nKJHucGt4ZzUTJio5HkseKS wmuhnM4GhnVQpOE5ZnYfc99et53ep0sPR4Mn3B2d09HywwHBHao65ZZTl 4=;
X-IronPort-AV: E=Sophos;i="5.73,491,1583193600"; d="scan'208";a="24532599"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jun 2020 10:53:44 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 059Arhso027555; Tue, 9 Jun 2020 10:53:43 GMT
To: Murray Kucherawy <superuser@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-ospf-te-link-attr-reuse@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Acee Lindem <acee@cisco.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, aretana.ietf@gmail.com
References: <159159605527.5267.14274339615944805237@ietfa.amsl.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <ec15e92d-8195-1eb7-66aa-c5968e271394@cisco.com>
Date: Tue, 09 Jun 2020 12:53:43 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <159159605527.5267.14274339615944805237@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YfMdOtWdazbBGyqHnYVFcvUXzsY>
Subject: Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 10:53:49 -0000

Hi Murray,

thanks for your comments, please see inline:

On 08/06/2020 08:00, Murray Kucherawy via Datatracker wrote:
> 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.

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.

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

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

> 
> (3) In Section 12.3.3, I don't think it's appropriate to use MUST-type language
> 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?


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

fixed.

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


fixed

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

fixed

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

done.

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

I believe it is useful to mention it here.


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


I thought the edited paragraph

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

defines UDAs clearly.



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

done

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

fixed.

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

fixed

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

fixed.

thanks,
Peter
> 
> 
> 
> 
>