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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
