Re: [core] [CoRE] Working Group Last Call (WGLC) of draft-ietf-core-target-attr-01

[Carsten Bormann <[e-mail]>]

On 2023-02-20, at 10:25, Esko Dijk <[e-mail]> wrote:
> 
> Hi all,
>  
> I also reviewed and the document looks almost complete.
>  
> Two suggested fixes:
>  
> Section 5 of [RFC8075]
> -->  Section 5.5 of [RFC8075]

Good idea!
Now part of https://github.com/core-wg/core-target-attr/pull/9
 
> “-- Carsten”
> -->  this was probably meant to be removed ;)

Well, this is an editor’s note, so the entire will be removed by the RFC editor.
Putting a name here probably alerts a bit more to the fact that this is an editor’s note (<cref in RFCXML parlance).

> And one question on “security considerations”: should the designated expert perform any security-related review task? If yes, we should describe it. If not, we may clarify that’s up to the requester to consider.
> As an extreme example if someone wants to register an attribute “password” that stores a plain-text password for access to certain resources.  It may be ok if the link format is accessed over (D)TLS.
> If the targeted use is in plain unsecured discovery, it may not be a good idea. Should the expert consider this and maybe other security aspects?

Practical question: Where would this review go?
There may be other quality-of-specification issues.
I think it would be great if the expert gave the registrant some feedback on this, but there is no formal place(*) where this should be archived and no authority for the expert to decide the registration proposal is too shabby to register.

Grüße, Carsten

(*) Which brings up the question whether we should have a policy to discuss on the core-parameters list, like Section 7 of RFC 6690:

   Registration requests should be sent to the [e-mail]
   mailing list, marked clearly in the subject line (e.g., "NEW RESOURCE
   TYPE - example" to register an "example" relation type or "NEW
   INTERFACE DESCRIPTION - example" to register an "example" Interface
   Description).

   Within at most 14 days of the request, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision to the review list and IANA.  Denials should include an
   explanation and, if applicable, suggestions as to how to make the
   request successful.

   Decisions (or lack thereof) made by the Designated Expert can be
   first appealed to Application Area Directors (contactable using the
   [e-mail] email address or directly by looking up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied with the response, to the full IESG (using
   the [e-mail] mailing list).

I don’t think we will be earning ourselves eternal glory for the way this has worked out so far.
But I did want to bring it up as a possibility.