[dconn] Re: IANA Considerations in draft-ietf-dconn-domainconnect

[Pawel Kowalik <[e-mail]>]

Hi Murray,

thank for the feedback and sorry for being slow on the response... 
vacation time.

Feedback below. Please let me know if the new text addresses the issues 
you raised (here or directly in GitHub).

On 23.07.26 12:14, Murray S. Kucherawy wrote:
> Hi, some feedback on Section 12 of this document.
>
> First about Section 12.6, the media type reservation: It's not enough 
> to just refer to the Security Considerations section of this 
> document.  RFC 6838 Section 4.6 (please review it) requires that you 
> include a statement about whether the payload of the media type is 
> executable, but I don't see that here.  We would push back on this if 
> presented in its current form.

PK> Good point. I expanded the media type registration with elements 
required in RFC 6838 Section 4.6. This led me to add also a section 
related to template onboarding/trust to the Security Considerations, as 
currently the topic was only covered in Trust Model.

Drafted changes:

https://github.com/Domain-Connect/spec/pull/209/changes

>
> Generally in Section 12, there's a lot of SHOULDs.  Use of BCP 14 key 
> words is a discouraged practice in IANA considerations sections.  For 
> example, IANA is not going to enforce the review period specified in 
> 12.1, nor will they ensure that the Subject of the review request 
> follows any particular form.  That's simply not a service they 
> provide. They manage the registry, but generally don't get involved in 
> the decisions about what goes in.  At best this language can try to 
> bind the Designated Expert, but advice to DEs is mostly about how to 
> decide whether to approve a registration request.  I think a lot of 
> this language should be reviewed.
>
As mentioned in the IETF 126 session the text was an almost verbatim 
copy of rfc8747.
BCP 14 language was my edit pass, which as it seems was unfortunate.

PK> Now I made a second revision of IANA considerations eliminating the 
elements you mentioned.

> More generally: Do we really need all of this complexity? What does it 
> give us?  What are we trying to protect?  What's wrong with just 
> Specification Required with some advice about when to say "yes" or "no"?
PK> what do you mean by "all of this complexity"? That one namespace is 
"RFC Required" and the other namespace is "Specification Required"?
It mirrors Standars Tree and Vendor Tree of rfc6838 and is the matter of 
whether IETF would want to be exclusive on extending the protocol core 
elements, or we are fine with a lower bar just based on "Specification 
Required" and expert review.

I don't have personal experience what would be a down side of doing so 
vs. keeping more strict policy.

Anyway, I drafted a change to address other issues you raised. happy to 
hear back if it is addressing your issues.
https://github.com/Domain-Connect/spec/pull/208/changes

Kind Regards,
Pawel