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

[Brian Rosen <[e-mail]>]

More follow up:

Paul is correct: most implementations do not use sips, and only use sip.  Many implementations support TLS with sip:.  I would suggest you specify sip or sips and have a note that says sip is only to be used when TLS is supported.

Brian


> On Apr 23, 2025, at 11:22 AM, Paul Kyzivat <pkyzivat=[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> art mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]