Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-ls-registry-04

[Elwyn Davies <[e-mail]>]

It appears that the data tracker has managed to truncate my review.  The whole text should have been....

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-idr-bgp-ls-registry-04
Reviewer: Elwyn Davies
Review Date: 2021-03-05
IETF LC End Date: 2021-03-16
IESG Telechat date: Not scheduled for a telechat

Summary:  The document is fine except that I think it would be appropriate to give a brief explanation of the reason for the change and  to clarify what are the limits of the discretion that is available to the expert if s/he decides to go outside the SHOULD in bullet  of s2.1

Major issues:
None

Minor issues:
s2.1, bullet2: 
       The Designated Experts SHOULD only consider requests that arise
       from I-Ds that have already been accepted....
At present under RFC 7752,  the specifications of new items can be in any suitable archivally stable document, including those produced by other standards bodies.  S2.1 talks only of IETF documents  indicating that the reason for this change might be to give the IETF complete control of the standards for this technology.  However the use of SHOULD indicates that the DE could conceivably consider requests arising by other means;  I think it would be desirable to offer some guidance as to the limits of the DE's discretion here. Or alternatively to specify a MUST. 

Nits/editorial comments:
S1:  A brief explanation of the rationale for the change would be helpful.

This has a bit more about the extent of discretion

Cheers,

Elwyn

Sent from my Galaxy

On 5 Mar 2021 16:27, Adrian Farrel <[e-mail]> wrote:

Thanks Elwyn,

> The document is fine except that I think it would be appropriate to
> give a brief explanation of the reason for the change

Ah, yes, erm 😊

I understand why you're interested. Of course, we don't normally explain why IANA policies are selected.

There's been a fair amount of debate on the list, and the result was we arrived at wanting these policies. I'd prefer not try to summarise how/why the WG ended up like this.

> and  to clarify what
> paths might be available to the expert if s/he decides to go outside the
> SHOULD in bullet  of s.1

I had a couple of rounds of discussion on this with Alvaro. That led us to move nearly every SHOULD to become a MUST, and just two remain.

As well as being the pen-holder for the document, I'm also one of the DEs, so I want to be a bit careful discussing the text that governs how I'm supposed to act.

My reading of this is:

   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.

This allows consideration of other sources of requests. The alternate would be to say "The DE MAY consider requests that arise from I-Ds that have not been accepted by a working group, or other forms of documentation." That's not very helpful. But, I think the important point is that bullet 4 covers what would happen.

   8.  In the event that the document is a Working Group document or is
       AD Sponsored, and that document fails to progress to publication
       as an RFC, the Working Group chairs or AD SHOULD contact IANA to
       coordinate about marking the code points as deprecated.

This is actually guidance to the WG chairs and not the DE. The point here is, I think, that the code points don't need to be marked as deprecated, but it would be good practice. It's not clear to me why chairs wouldn't want to mark such a code point as deprecated, but "MUST" seems a bit strong.

> Minor issues:
> s2.1, bullet2:

I think this refers to the above?

Cheers,
Adrian

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art