Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

["Ketan Talaulikar (ketant)" <[e-mail]>]

+1 to what Les mentioned and it does look to me that the text from RFC7370 Sec 4 (which is also not surprisingly Adrian's product 😊) aligns more closely to the original intention (at least what I had in mind) when we started down this path.

In my view, the goal of this update is not to allow the IDR WG review to be bypassed for allocation. The issue was more about the RFC7120 requirements and the "non-permanent" nature of IDs.

https://mailarchive.ietf.org/arch/msg/idr/dJ3n_8VGC5kYYkBqX4Z6138IZao/

Thanks,
Ketan

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 18 November 2020 04:21
To: [e-mail]; 'Alvaro Retana' <[e-mail]>; [e-mail]
Cc: 'idr@ietf. org' <[e-mail]>; [e-mail]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Adrian (and Alvaro) -

Apologies for inserting myself in this discussion...but as regards "Section2.1.  Guidance for Designated Experts"

It seems you have largely retained the text from https://tools.ietf.org/html/rfc7752#section-5.1 - but I am wondering why you don't replace this text with text similar to https://www.rfc-editor.org/rfc/rfc7370.html#section-4 ?
(which - as you may recall - you actually wrote)

What I don’t like about the current text in Section 2.1 is:

1)It seems to be somewhat ambiguous as to whether a document is required.

Saying 

"any  request for one of these code points has been made available for
   review and comment within the IETF" 

suggests that it might be allowed to request/assign a codepoint w/o a document.
Is this really what you intend?

2)I do not know why the DE needs to:

"post the request to  the IDR Working Gorup mailing list (or a successor mailing list
   designated by the IESG)"

NIT: s/Gorup/Group

I suppose this might relate to my point #1 in that if it were allowed to request a codepoint w/o a document then the relevant WG might not know about the request. So if you agree to point #1 then the need for this text goes away.

Something I DO like is the statement:

"the DE must
   ensure that any other request for a code point does not conflict with
   work that is active or already published within the IETF."

RFC 7370 does not make this explicit statement, but clearly this is desirable/required.

    Les

> -----Original Message-----
> From: Idr <[e-mail]> On Behalf Of Adrian Farrel
> Sent: Tuesday, November 17, 2020 12:16 AM
> To: 'Alvaro Retana' <[e-mail]>; draft-ietf-idr-bgp-ls- 
> [e-mail]
> Cc: 'idr@ietf. org' <[e-mail]>; [e-mail]
> Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01
> 
> Hi Alvaro,
> 
> Thanks for this. As usual, nits are an embarrassment.
> 
> Inline for the detailed discussion.
> 
> A
> 
> > 94	      Internet-Drafts are draft documents valid for a maximum of six
> > 95	      months and may be updated, replaced, or obsoleted by other
> > 96	      documents at any time.  It is inappropriate to use Internet-Drafts
> > 97	      as reference material or to cite them other than as "work in
> > 98	      progress."
> >
> > [major] Related to the use of IDs to satisfy Specification Required.
> >
> > The general practice is to let the DEs decide if an ID is sufficient.
> > Clear instructions go a long way.
> >
> > The motivation discussed on the list is focused only on speeding up 
> > allocations by eliminating the rfc7120-related part of the process.
> >
> > This document is not the best place to introduce a discussion about 
> > the boilerplate, or the interpretation of other documents.
> >
> > Please reword the motivation.
> >
> > [] I know the conversation about IDs, their boilerplate, and the 
> > Specification Required policy has come up several times, and that
> > rfc8126 didn't include the best possible text.  I will bring this up 
> > to the IESG (again), but I suspect that the result will be to hold 
> > any potential changes until rfc8126bis (I think Michelle @ IANA 
> > mentioned that she was working on it).
> 
> I know that you had a conversation with IANA about it being up to the 
> DEs to determine what is “permanent and readily available”…and that it 
> could include I-Ds (if the DEs determined that was ok).
> 
> The problem with this statement is that the DEs might take a view on 
> the appropriateness of using an I-D for this purpose.
> 
> Hence, this document makes it clear to the DE that they are expected 
> to allow assignment resulting from an I-D. It removes that element of 
> determination from the DE.
> 
> [In this case of these registries and their DEs, this is a good thing. 
> I am one of the DEs for the registries and I (in general) do not 
> consider that permanent assignment based on an I-D is a good thing. In fact, I think it is a bad idea.
> However, this document gives me clear instructions that for these 
> registries I must not take that into account.
> 
> But, do we need the motivation in this document? Probably not.
> 
> I think we can safely just delete...
>    It is often considered that it is the responsibility of the Designated
>    Expert to make a determination as to whether a specification meets the
>    requirement to be permanent and readily publicly available.  A degree
>    of contention arises in this case because Internet-Drafts are now 
> permanently
>    archived in the IETF's tools archive, yet each such document is marked
>    with a piece of boilerplate text as follows that brings doubt about its
>    suitability as a permanent record:
> 
>       Internet-Drafts are draft documents valid for a maximum of six months
>       and may be updated, replaced, or obsoleted by other documents at any
>       time.  It is inappropriate to use Internet-Drafts as reference
>       material or to cite them other than as "work in progress."
> 
> > 129	2.1.  Guidance for Designated Experts
> >
> > 131	   Section 5.1 of [RFC7752] gives guidance to Designated Experts.  This
> > 132	   section replaces that guidance.
> >
> > 134	   In all cases of review by the Designated Expert (DE) described here,
> > 135	   the DE is expected to check the clarity of purpose and use of the
> > 136	   requested code points.  Additionally, the DE must verify that any
> > 137	   request for one of these code points has been made available for
> > 138	   review and comment within the IETF: the DE will post the request
> to
> > 139	   the IDR Working Gorup mailing list (or a successor mailing list
> > 140	   designated by the IESG).  If the request comes from within the IETF,
> > 141	   it should be documented in an Internet-Draft.  Lastly, the DE must
> > 142	   ensure that any other request for a code point does not conflict
> with
> > 143	   work that is active or already published within the IETF.
> >
> > [major] "the DE must verify that any request for one of these code 
> > points has been made available for review and comment within the IETF:
> > the DE will post the request to the IDR..."
> >
> > The text in rfc7752 asks that "any specification produced in the 
> > IETF that requests one of these code points has been made available for
> > review by the IDR..."   But the updated text talks about the
> > *request*, not the *specification*, which is what I assume is what 
> > you want idr to see, and is in line with the original instructions.
> > Right?
> 
> The text is as intended. This is indicative of the change from 
> "Specification Required" (a specification must exist and so can be 
> shown to the WG) to "Expert Review" (no specification is required, so 
> when there is no specification, only the request can be shown).
> 
> No change to text.
> 
> > [major] On the same text...  What is the expectation when posting 
> > the specification to idr?  Can the DE move on once he/she sends a 
> > message to idr, or is there some feedback/discussion/confirmation expected?
> > The text explicitly talks about being "available for review" -- what 
> > type of review is expected?
> 
> Was not setting any expectations on the DE here. They can do what they 
> consider reasonable.
> Personally, I would expect comments over one or two weeks and would 
> accept any type of review (of the request).
> 
> No change to text proposed. We *could* codify this if someone has a 
> proposal.
> 
> > [major] Related to possible WG feedback...  How much attention are 
> > the DEs expected to pay to the WGs review?  The Expert Review policy 
> > can clearly result in the allocation of codepoints to specifications 
> > that don't have IETF consensus/approval/favorable reviews...
> 
> I would expect DEs to listen to feedback, but make their own decision. 
> If, for example, some feedback said, "Hey, this conflicts with the 
> work we are doing in the WG," I would expect the DE to check this out. 
> If some feedback said, "This will cause the Internet to crash," the DE is also expected to check it out.
> But, it is not a request for consensus, it is a request for review.
> 
> Again, I am not proposing any text change for this.
> 
> > [major] "If the request comes from within the IETF..."  How is it 
> > determined that the request comes from "within the IETF"?  For 
> > example, the case where a draft is discussed/adopted in a WG, and 
> > the WG (not just the authors) decide to ask for an allocation seems 
> > like a case where the request comes from "within the IETF": the WG 
> > making the request is part of the IETF.  What are other cases?
> 
> Agree, this is ambiguous. Not trying to say, "The request comes from 
> the IETF," but, "From within the IETF." That is, in any way from 
> within the IETF process. I think that includes, on an IETF mailing list.
> 
> It's more of an expression of the converse. "Requests that come direct 
> to the DEs or IANA without first approaching the IETF."
> 
> Any suggestions of how to express this?
> 
> > [major] Do you really want all the sub-registries to use the same DE 
> > instructions?  An important difference between Expert Review and 
> > Specification Required is that the former is not covered by the 
> > early allocation process in rfc7120 -- which, I think is part of the 
> > objective.  The space in the registries is large (so there shouldn't 
> > be significant issues with unused codepoints), except for the 
> > "BGP-LS Protocol-IDs" one which only has 255 possible values; that 
> > is still pretty big for its purpose.  Just want to check everyone is 
> > ok with this.
> 
> This is my understanding of what IDR wanted.
> 
> > An alternative would be to still use Expert Review, and to add 
> > rfc7370-like instructions.  In short: the DE would follow an Early 
> > Allocation process akin to rfc7120 (just for this 
> > sub-registry)...not only when assigning a value, but also if deallocation is needed.
> 
> So, no change proposed.
> 
> > [major] Why isn't rfc2119 language used in the DE instructions?  As 
> > written, the DEs, for example, can decide to not enforce the ID 
> > requirement for no good reason.
> 
> I don't think 2119 language is any more legally enforceable than 
> regular English. There is "must" and "should" in these instructions, 
> and my expectation is that a DE would use them in the correct meanings 
> of the words.
> 
> AFAIK, the purpose of 2119 is to clarify (or make bold) implementation 
> behaviors for protocol specs.
> 
> > 160	   This change in allocation policy should not have any effect on the
> > 161	   integrity of BGP-LS since there is no change to the review
> > 162	   requirements for the work that underlies the request.
> >
> > [major] Yes, there is!!  Specification Required asks for a 
> > specification to be stable (discussion, adoption in a WG, etc.) 
> > before granting (early) allocation -- this document leaves that 
> > decision to the DEs and what they may consider to be "clear".
> 
> Hmmmm, no, I don't think so. The change is for code point assignment, 
> not for protocol specification.
> This is, of course, the area of debate when reducing the requirements 
> for code point assignment. IDR likes the idea of making code points 
> readily available so as to reduce squatting, help avoid clashes, and 
> make it clear what code points are being used for.
> 
> We could possibly reword this as...
> 
>    This change in allocation policy is not expected to not have any
>    effect on the integrity of BGP-LS standards track specifications
>    since there is no change to the review requirements for the
>    work that underlies the request if it is to become an RFC.
> 
> Would that help?
> 
> Cheers,
> Adrian
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr