Re: [Idr] Martin Vigoureux's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with COMMENT)

Adrian Farrel <adrian@olddog.co.uk> Tue, 23 March 2021 22:31 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291943A186C; Tue, 23 Mar 2021 15:31:13 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 kEVOSfXwr7bg; Tue, 23 Mar 2021 15:31:09 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 A16A63A1872; Tue, 23 Mar 2021 15:30:49 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12NMUdIN013273; Tue, 23 Mar 2021 22:30:39 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 799752203B; Tue, 23 Mar 2021 22:30:39 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 640AC2203A; Tue, 23 Mar 2021 22:30:39 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.109.31]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12NMUcPd006934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Mar 2021 22:30:38 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Martin Vigoureux'" <martin.vigoureux@nokia.com>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-idr-bgp-ls-registry@ietf.org>, <idr-chairs@ietf.org>, <idr@ietf.org>, "'Susan Hares'" <shares@ndzh.com>, "'Jie Dong'" <jie.dong@huawei.com>, <aretana.ietf@gmail.com>
References: <161642388684.32091.12908117807432626906@ietfa.amsl.com>
In-Reply-To: <161642388684.32091.12908117807432626906@ietfa.amsl.com>
Date: Tue, 23 Mar 2021 22:30:38 -0000
Organization: Old Dog Consulting
Message-ID: <0cae01d72034$2724a460$756ded20$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHjj/dsedAV4L4CaKfRt3S3uWujSap5Q8wA
Content-Language: en-gb
X-Originating-IP: 84.93.109.31
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26048.003
X-TM-AS-Result: No--4.671-10.0-31-10
X-imss-scan-details: No--4.671-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26048.003
X-TMASE-Result: 10--4.670700-10.000000
X-TMASE-MatchedRID: B0+RG8xpjtTxIbpQ8BhdbPHkpkyUphL9+IfriO3cV8Q/gf7afIrQUxhX VAUo0b41LNIepOdNpi/XVBRKWdNR1wq+1DCPCznVhUy0TABax1xZbM2hfH4YXr3y9NEWyNLa+if ST869BXWYBAChk4D/j80ryr5gJdXwc3G6hWIdD885/8HHX4y4wqm9/6ObPjnDZ4mKJqKFIvbnb/ gCT7Rgr7LUYJKfrJ+TfnR2S3QqRUrBBJREZwyRwpJrW03DacWE0uLgdEYUsFlaDILwf1HV4TZOu 6dp88YfJha5gXbsJru475C4bP2vtuuGtoxRdOqKjoyKzEmtrEd9/z2DYqHY7R9Wmd+D4tStRdCK pj2KVGeh+2mRvRhezCJoUKEoWEMRnySqCTVRfyR9j6Il8VAHFykDYTG6KmZabcPp/oilsshfPeq 3iAoZIvhR4pwr3l+xLqpzglg8PbgRtmDagKSYmE4eFUkH5CFcX4GgfgmcIgZjbFXhnisLtxQoKg htRTgybwduEDfz1Q4QTo4aSQkGq2lj6sOkm2pe8KQMqZXaCzkOZNXmvnJaerEtLGRAe3PG8f4St kBOa34jwlp9J6pJH+4unEwhuIHlHBctNSH2fkIIs18ZTh19+P2rGhrYTIa57V/Rrd7FCxJdreoO XuKvRN45RJH07wZdUuQBnYxdqJ0/mJEvNFL+dZjhZxhC9CTjrXkuON8pnlEvfU/riSJXkRbEsBf gA5M3D5FrZsF+K+YmfJOS9jwQC4gMxLezTxJOXMhTEepcH5BTT/bFAFnIuhGHFrgBwnSro8WMkQ Wv6iWhMIDkR/KfwP306Q4zhC4D3QfwsVk0UbsIoUKaF27lxR5XagaGOYduOHOxsVh4SJmJ9TljH l9ljoMyCT4kXJc01+OpIHtEVK8G7EBCySLXiBsm9Eeh7vfoWdhpWIHA/vtzVPsTPqZIUgkCnkA3 h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrnqg/VrSZEiM=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xSj8NoJTA-Vn47pAT9masEFz-sg>
Subject: Re: [Idr] Martin Vigoureux's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 22:31:13 -0000

Hello Martin,

> I'm not always sure what are the appropriate DISCUSS criteria for a process
> document. I hesitated and in the end chose NoObj. I'd nevertheless really
> appreciate if we could discuss theses points.

All Comments get discussed, and resolved before moving forwards, so the objective is achieved 😊

> The Document allows for an Expert to consider a request which doesn't arise
> from a WG document (or an AD sponsored one) and does so by using SHOULD in the
> following:
>   2.  The Designated Experts SHOULD only consider requests that arise
>       from I-Ds that have already been accepted as Working Group
>       documents or that are planned for progression as AD Sponsored
>       documents in the absence of a suitably chartered Working Group.
> and confirms that in:
>   4.  If the document is not adopted by the IDR Working Group (or its
>       successor),
> I am perfectly fine with that.

Right. 2 and 4 need to be seen together because 4 offers the "MAY" to 2's "SHOULD".

> However, would it be fair to expect from the Expert that he/she communicates to
> the list (as part of step 4) the "valid reasons" and "full implications" of
> agreeing to consider this particular request?

I think the "valid reason" is that a request was made.
To expect the DE to grasp the "full implications" may be a bit much, but the point of 4 saying that the WG must be notified is to allow the WG to raise any concerns.
Is the point here that 4 does not say that the document must be made available to the WG?
We could...

OLD
   If the document is not adopted by the IDR Working Group (or its
   successor), the Designated Expert MUST notify the IDR mailing list
   (or its successor) of the request and allow two weeks for any response.
   Any comments received MUST be considered by the Designated Expert
   as part of the subsequent step.
NEW
   If the document is not adopted by the IDR Working Group (or its
   successor), the Designated Expert MUST notify the IDR mailing list
   (or its successor) of the request and MUST provide access to the
   document.  The Designated Expert MUST allow two weeks for any response.
   Any comments received MUST be considered by the Designated Expert
   as part of the subsequent step.
END

> Also, it isn't clear to me whether an Expert can refuse an allocation to be
> made and what would be the criteria for supporting such decision. I do read
>   5.  The Designated Experts MUST then review the assignment requests
>       on their technical merit.
> This could potentially result in a refusal, but I'm not sure in fact, but if it
> allows for a refusal then that's very vague. There is of course point 6. but
> that's given. Another way (not completely equivalent) of saying this is that I
> get the impression that except in obvious cases (e.g., 6), all requests will be
> granted. Is that the case?

Same as my answer to Ben on this point. Can a DE ever refuse?
The pedantic answer is that it is up to IANA to allocate or refuse to allocate, but that isn't really a helpful answer.
An important point is that IETF consensus can be advised against, but not over-ridden by a DE (but where is that documented for any registry?)
The question is slightly remedied for new registries by 8126 asking for a Change Controller who is, I assume, the person with whom the buck stops. I suppose this document could apply a that back to the BGP-LS registries. (But I confess to not understanding section 2.3 of RFC 8126 - I know what it wants to avoid, but I don't understand the practicalities of change controllers.)

I find giving a shorter answer to your question hard. In the spirit of technical discussion and consensus I like to think that requests would not be refused provided that issues are properly raised and addressed. But ultimately, I think rejection would arise is there was conflict with IETF work, if the proposal was not properly documented, or if the proposal would be harmful to deployments of BGP-LS. If we can come up with a way of wording that, then it seems reasonable to include it.

Cheers,
Adrian