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.
Thanks Elwyn,
> The document is fine except that I think it would be appropriate to
> give a brief explanation of the reason for the changeAh, 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.1I 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
Gen-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
