Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

Benjamin Kaduk <kaduk@mit.edu> Wed, 17 June 2020 02:22 UTC

Return-Path: <kaduk@mit.edu>
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 21B073A0DAD; Tue, 16 Jun 2020 19:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hP6K-mK7B-Ob; Tue, 16 Jun 2020 19:22:24 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EA23A0DAB; Tue, 16 Jun 2020 19:22:23 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05H2MF8I016983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jun 2020 22:22:17 -0400
Date: Tue, 16 Jun 2020 19:22:14 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Scott Bradner <sob@sobco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-ospf-te-link-attr-reuse.all@ietf.org" <draft-ietf-ospf-te-link-attr-reuse.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Message-ID: <20200617022214.GY11992@kduck.mit.edu>
References: <159216255398.11973.1707971108773200684@ietfa.amsl.com> <BY5PR11MB4337F7515939C0C08CDBE28DC19F0@BY5PR11MB4337.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BY5PR11MB4337F7515939C0C08CDBE28DC19F0@BY5PR11MB4337.namprd11.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3iZS2k2Cgr_Wqw4R6qx00G1LolI>
Subject: Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
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: Wed, 17 Jun 2020 02:22:32 -0000

Hi Les, Scott, Peter,

I appreciate the text about "not subject to standardization and are outside
of the scope of this specification".  That said (inline),

On Sun, Jun 14, 2020 at 09:14:49PM +0000, Les Ginsberg (ginsberg) wrote:
> Scott -
> 
> Allow me to inject myself here. As editor of the companion IS-IS document (draft-ietf-isis-te-app) I have received similar comments - for example from Ben (copied on this thread).
> 
> I continue to be at a loss as to why you believe we have to say something about User Defined Applications beyond what we have already said:
> 
> "User Defined Application Identifier Bits have no relationship to
>    Standard Application Identifier Bits and are not managed by IANA or
>    any other standards body."
> 
> If you do a search through both documents using "standard app" and "user defined app" I think you will find equivalent statements about both. Which means you are asking for some text regarding UDAs that doesn’t exist for SAs.
> Why? 

We give instructions to IANA for how to managed the Standard Application
Identifier Bits.  Is it fair to give guidance to the entity assigning User
Defined Application Identifier Bits (whomever that may be) about things
they might want to consider while doing so?  A "several ways to not shoot
yourself in the foot" guide, as it were, even though such a guide is
inherently incomplete.  If there is nothing useful to say and the key
factors are pretty inherent in how IS-IS/OSPF work, that's fine.  But the
"warnings about potential 'gotcha's" directed at the party assigning UAI
bits is the main topic I was trying to get at in my remarks on the
analogous part of the IS-IS document.

Sorry for having made my point so circuitously.

-Ben