Re: [httpapi] Lars Eggert's No Objection on draft-ietf-httpapi-rfc7807bis-05: (with COMMENT)

On 15 Feb 2023, at 1:01 am, Lars Eggert <lars@eggert.org> wrote:
> 
> Hi,
> 
> On Feb 15, 2023, at 07:05, Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org> wrote:
>>> On 14 Feb 2023, at 6:44 am, Lars Eggert via Datatracker <noreply@ietf.org> wrote:
>> [...]
>>> ### Section 4.2, paragraph 3
>>> ```
>>>   When evaluating requests, the Expert(s) should consider community
>>>   feedback, how well-defined the problem type is, and this
>>>   specification's requirements.
>>> ```
>>> It's called "expert review" and not "community review" for a reason, because
>>> it's the expert's call. If you want community review, the registration policy
>>> should be "RFC Required" or "IETF Review"..
>> 
>> Yes, and the expert is asked to check with the community; this is hardly unusual.
> 
> So who are "the community" and how does an expert demonstrate they have "considered" the feedback? (I'm thinking about what happens in appeals of expert decisions.)

I did a little digging around and found that we use language about consulting the community already in:

RFC9110 - "The expert(s) can define additional fields to be collected in the registry, in consultation with the community." 
RFC9110 - "Other names can also be registered as permanent if the expert(s) finds that they are in use, in consultation with the community."
RFC9110 - "Provisional entries can be removed by the expert(s) if -- in consultation with the community -- the expert(s) find that they are not in use."
RFC8615 - "Other values can also be registered as permanent, if the experts find that they are in use, in consultation with the community."
RFC9209 - "The expert(s) should consider the following factors when evaluating requests: [...] Community feedback"

I'm sure there are a few more, but in general, the point is to assure that when the Expert has the ability to take unusual and unilateral action, there is at least a bit of transparency in their action. 

The specific community to be consulted and whether it was sufficiently considered are both intentionally vague; in an appeal, the appeal body would make a judgment about whether they are reasonable. It doesn't say "community consensus" (where I would understand your concern completely); only that the Expert should "consult" so that they're not acting in the dark. 

The difference I see between the proposed text and the examples above is that it is a _general_ requirement to consult with the community, whereas all of the examples (barring the last one) are about specific actions that are instigated by the Expert themselves. 

I think community feedback is relevant in this registry because the purpose of the registry is to try to capture those problem types that are amenable to reuse; community discussion can improve the candidates and help winnow out those that are not suitable. We didn't specify one of the more rigorous options because it would discourage use of the registry to the point that it would be useless to define it; I seriously doubt that we're going to see standards-track Problem Type definition RFCs anytime soon.

(feedback about that positioning from HTTP API WG members would be most welcome)

If this is really a problem I'll remove the text; however, it feels like we're being unnecessarily constrained by the terminology here.

>>> ### Uncited references
>>> 
>>> Document obsoletes `RFC7807`, but does not cite it as a reference.
>> 
>> Is that now required? The doc already clearly says it does so in the abstract. I have to say, there seems to be an increasing number of ceremonies for obsoleting something, considering it's captured in metadata at the top of the document.
> 
> It's not required, which is why this is in a comment. But a document obsoleting another document should IMO actually reference it.

It would be *great* if there were a detailed policy on this, rather than having the IESG and then the RFC Editor chime in with their adjustments as authors go through the process.

The only mention of obsoleting I see that's relevant on authors.ietf.org is <https://authors.ietf.org/en/required-content#abstract>:

"If the I-D intends to obsolete or update a previous RFC, ensure the abstract says so explicitly."

If we can get agreement that that's the right thing to do and update the docs accordingly, I'm more than happy to comply; otherwise, I'll leave as is (subject to whatever the RPC decides, no doubt).

>>> #### Section 4.2, paragraph 3
>>> ```
>>> -    and deployment-specific values are not registrable.  Specification
>>> +    and deployment-specific values are not registerable.  Specification
>>> +                                                 +
>>> ```
>> 
>> What is the correction here? The only difference I see is an extra space at the start of the sentence, which is superfluous in the text.
> 
> The ^ points to an inserted character.

You mean '+'? I think I see the problem -- I'm not reading with a fixed-width typeface. Fixed.

(is there another way to show the diff that doesn't require a fixed-width typeface? just a thought.)

Cheers and thanks for the feedback,

> 
> Thanks,
> Lars
> 
> 
> -- 
> httpapi mailing list
> httpapi@ietf.org
> https://www.ietf.org/mailman/listinfo/httpapi

--
Mark Nottingham   https://www.mnot.net/