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

[Alvaro Retana <[e-mail]>]

On November 17, 2020 at 1:15:34 PM, Adrian Farrel wrote:


Hi!

You mentioned below that you expect the DEs to apply the instructions
using "the correct meanings of the words".  You are the current DE, I
have no doubt you'll apply the "correct meaning" -- you know what that
is: you wrote it!   My concerns are mostly about future DEs, or people
requesting allocations correctly interpreting the meaning.

To be honest, I read through your answers and I still have a lot of
concerns.  It is too late/early for me to come up with more text...I
may also be overthinking it.  I would love to get a 3rd party opinion.

In the meantime, I put some more comments/concerns inline.

Thanks!

Alvaro.



> > 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."
...
> > [] 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).
...
> 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."

As I offered, I started a conversation with the IESG about this topic.
The responses so far (only 2) agree with (1) a DE can determine an ID
is enough, and (2) we should update the boilerplate.

My proposal was to replace the last sentence of the boilerplate with
"Internet-Drafts should be referenced as "work in progress.", or
something similar.  Other suggestions are welcome of course.




> > 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).

Aside: Expert Review is not Specification Required...but that doesn't
preclude the instructions from requiring one; e.g. rfc7370.


The text says that the "DE is expected to check the clarity of purpose
and use of the requested code points".  No specification is required,
but a (short) description is.  So, the DE would send a note to idr
saying: "There's a request for a BGP-LS TLV."  Maybe include who
requested it, and the description.  Is that it?  Should the
description always be included?  Maybe you're considering that to be
part of the request...can we please be clear on what idr should know?


> 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).

One or two weeks sound reasonable.  I would like to see that in the
text: either specifically call out a time frame for review/comments,
or at least say "the DE must accept comments/reviews over a reasonable
amount of time".

> 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.

Fair point, it is a request for comments, not consensus.

Should the DE reply to the comments on the list?  There's a
possibility that the DE doesn't agree with the feedback related to
"Hey, this conflicts with the work we are doing in the WG," and
decides to approve the request.  Should the WG be informed of the
allocation and any reasoning?

What does it mean for work to be in "conflict"?  Is an alternate
solution to work being done in the WG a conflict?  For example, the DE
thinks that the proposal to advertise a sw version in a new TLV is not
in conflict with a potential alternate solution to add it to an
existing TLV...just an example.

How are conflicts of opinion resolved?


A significant driver for the change in policy (as I understand the
discussion from the mailing list) is to speed up allocations, not
having to prove WG interest (rfc7120).  I am concerned about cases
where the WG discusses other potential ways to achieve a solution,
potential in the sense that they are theoretical and not active
work...but that could become active -- we may end up in some sort of
"race condition".

BTW, what is considered "active work"?  Is that published draft or an
adopted one?

Also, I'm assuming that "published within the IETF" means an RFC in
the IETF stream.  Is that a good assumption?


Having idr know that there is a request with just a short description,
and not setting a clear expectation that comments will matter (or at
least be addressed seems useless to me.  In fact, it sounds as if it
could be a source of conflict.

Maybe I'm missing the point.



> 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."

If I propose something on the list and no one pays attention to me,
and I then ask for a codepoint, is that from "within the IETF"?  What
if my idea was not accepted (people just didn't like it, but there's
no alternate proposal)?  In both of these cases I didn't write a
draft, just posted a (short) description to the list asking for
feedback.

There seems to be an incentive to ask for allocation first and then
come to the WG.  Granted that some manufacturers may want to implement
their idea first (strategic advantage), but this can also be used as a
lever: my idea may not be the best, but I already have an
implementation with an approved codepoint...



> Any suggestions of how to express this?
...
> > [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.

Yeah...just like with a lot of the process RFCs, I think there's room
for  interpretation.  As I said, I worry the interpretation that
(future) DEs may have.

I'll grant you that it is better to use must/should than other words
to try to get a similar interpretation (e.g. rfc8200).



> > 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.

...there may not be a 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?

Pfft...sure.

There is no required direct link between the allocation policy and the
underlying work becoming an RFC...which could still result in
affecting the integrity of BGP-LS (the original text).

I don't think this paragraph needs to be included at all.