[DNSOP] Re: Artart Last Call review of draft-ietf-dnsop-structured-dns-error-12

[Paul Kyzivat <[e-mail]>]

Tiru,

You have mostly addressed my concerns. I've included a few followup 
questions below.

On 4/23/25 1:42 AM, tirumal reddy wrote:

>     1) NIT: Section 4 - c: (contact)
> 
>     This allows sips but not sip URIs. Sips is not widely used.
>     Please consider allowing sip URLs.
> 
> Allowing "sip" URI introduces security issues, "sips" offers encrypted 
> transport for SIP messages.

I'm aware of that. Yet, AFAIK sips URIs are rarely used in sip 
implementations. (They were added to get through the security review for 
RFC3261.) I think there would often be trouble invoking a sips URI. 
Also, why isn't there similar concern for the security of mailto?

But if you think you can't get through a security review with sip then 
so be it.

>     3) ISSUE: Section 8 - Extended DNS Error Code
> 
>     The phrasing here, for both the section title and the content, is odd
>     and confusing. For clarity and consistency with section 7, I suggest a
>     title of "New Extended DNS Error Code Definition".
> 
>     And then the body could start with: "This document defines the
>     following
>     new IANA-registered Extended DNS Error Code." The existing text will
>     then require some tweaking to align with this rephrasing.
> 
>     And then to avoid confusion, perhaps change the title of section
>     11.4 to
>     "New Extended DNS Error Code Registration".
> 
> No, the section title and its body is consistent with the sections in 
> RFC 8914 defining Extended DNS Error Codes, please see 
> https://datatracker.ietf.org/doc/html/rfc8914#section-4 
> <https://datatracker.ietf.org/doc/html/rfc8914#section-4>

OK, I see why you want to phrase these this way. But it doesn't read the 
same way here as in rfc8914. This is because rfc8914 has comparable 
definitions as subsections of section 4 titled "Defined Extended DNS 
Errors", which gives context.

You could create a similar structure to provide the context. E.g.,

8. New Extended DNS Errors

    This document defines an addition to the EDE codes defined in
    [RFC8914].

8.1 Extended DNS Error Code TBA1 - Blocked by Upstream DNS Server

    ...

I realize it looks a little odd to have a section with only one 
subsection, but it does make the document easier to follow.

>     6) ISSUE: Section 11.2 - New Registry for Contact URI Scheme
> 
>     Could you please add some text describing the role and responsibilities
>     of the Change Controller? What sort of changes are allowed? More than
>     additions?
> 
> IETF review is required to update the registry, see 
> https://datatracker.ietf.org/doc/html/rfc8126#section-4.8 
> <https://datatracker.ietf.org/doc/html/rfc8126#section-4.8>, change 
> controller is IETF.

I think you are missing my point. I'm looking for a more in-depth 
definition of the role of "Change Controller". I checked, and this term 
is currently not used in Domain Name System (DNS) Parameters.

I just realized that your definitions of new IANA registries fail to 
specify Registration Procedures, which is required. I think you can 
achieve what you want by specifying that the Registration Procedure is 
"IETF Review", "Standards Action", or "IESG Approval". Then you can omit 
all mention of Change Controller.

>     7) ISSUE: Section 11.3 - New Registry for DNS SubError Code...
>     Also, again, could you please add some text describing the role and
>     responsibilities of the Change Controller? What sort of changes are
>     allowed? More than additions?

See above.

	Thanks,
	Paul