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

[Esko Dijk <[e-mail]>]

Thanks, I do think the expert could send an email to the core-parameters list in case of any doubt/issues/questions. This could be security-related, or it could be a concern of required orchestration: if different names with similar / same intent being registered.
If no response on core-parameters within some time (7 days?) then the expert can opt to just continue.

In the end, the expert makes the decision and not the email list collectively. And for most cases the mailing list wouldn't be needed.

> I don’t think we will be earning ourselves eternal glory for the way this has worked out so far.

No reason to avoid mailing lists altogether ;)  
The issue seems to be if the registration request is sent to a mailing list. If rather it is requested to IANA as suggested by this draft, then IANA delegates it to one specific expert, it should be much faster. IANA can reassign the expert in case the first one doesn't respond.

Regards
Esko

-----Original Message-----
From: Carsten Bormann <[e-mail]> 
Sent: Monday, February 20, 2023 13:38
To: Esko Dijk <[e-mail]>
Cc: Thomas Fossati <[e-mail]>; Marco Tiloca <marco.tiloca=[e-mail]>; [e-mail]
Subject: Re: [core] [CoRE] Working Group Last Call (WGLC) of draft-ietf-core-target-attr-01

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.