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

[Martin Vigoureux <[e-mail]>]

Hello Adrian,

thank you. Please see in-line.

Le 2021-03-23 à 23:30, Adrian Farrel a écrit :
> 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?

No. My point is that if the DE decides not to follow this "SHOULD only 
consider WG documents" (and thus considers a request arising from 
something else, e.g., a simple e-mail) that he states what are the valid 
reasons for considering it.

On the other hand, if the valid reason is simply that a request was 
made, then I see no reason to make a distinction between WG/AD-sponsored 
Documents and the other supporting formats, and then SHOULD is not 
necessary here.

> 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.
Thanks. I think that it's going to be difficult to be exhaustive here.
Could we simply say that if the allocation is rejected, the DE 
SHOULD/MUST provide the reasons for this decision?
> 
> Cheers,
> Adrian
> 
> 
> 
> 
>