On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton <rwil...@cisco.com> wrote:
> Hi authors, WG, > > Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They > are all minor/nit comments, meaning that I'll leave it to the authors > discretion as to how they want to handle these comments. > > Minor level comments: > > (1) p 3, sec 2. The alt Namespace > > Groups wishing to create new alternative namespaces may create their > alternative namespace under a label that names their namespace under the > .alt pseudo-TLD. The .alt namespace is unmanaged. > > This seems slightly strong given that the ISE draft is planning on setting > up a registry somewhere. So, perhaps "The .alt namespace is not managed by > the IETF or IANA"? > Good point. Here is the original with a bit more text for context: "The .alt namespace is unmanaged. This document does not define a registry or governance model for the .alt namespace." I don't really know if GNU creating a registry really counts at "managing" the .alt namespace, but we can skip that philosophical question by rewording it like so: "This document defines neither a registry nor governance model for the .alt namespace, as it is not managed by the IETF or IANA. " (2) p 3, sec 2. The alt Namespace > > > This document > does not define a registry or governance model for the .alt namespace. > Developers, applications and users should not expect unambiguous mappings > from names to name resolution mechanisms. > > > Is "Developers, applications, users should not expect unambiguous > mappings" a bit strong? A possible alternative could be: "Developers, > applications and users are not guaranteed to have unambiguous mappings from > names to name resolution mechanisms." > Hmmm - I'm not sure if it is actually a bit strong, I think that the issue is more that we cannot really tell developers or users to "expect" anything — my auntie might well expect some.name.gns.alt to be an unambiguous mapping, and telling her that she shouldn't expect this is silly - she doesn't read RFCs[0] I changed this to "There is no guarantee of unambiguous mappings from names to name resolution mechanisms." ? I removed the "Developers, applications and users" wording as it just opens the question of who should expect this (cats?), or who might be guaranteed anything (chimps?). (3) p 3, sec 2. The alt Namespace > > Currently deployed projects and protocols that are using pseudo-TLDs may > choose to move under the .alt pseudo-TLD, but this is not a requirement. > > I was wondering whether we could we be slightly stronger here and use > "recommended to move" rather than "may choose to move"? I.e., I think that > the IETF position could reasonably be that we would like these to all turn > up under alt and not squat in the root namespace. > This works for me - it's not a requirement, and so people can happily ignore it. Of course, even if it were a requirement, people can still happily ignore it… ( https://i.cbc.ca/1.3173445.1438223040!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/winnipeg-blue-bombers.jpg ) > Nit level comments: > > (4) p 6, sec Appendix A. Changes / Author Notes. > > * During AD review, made a few more requested changes > > As a minor nit, I think that these comments were during the WGLC, rather > than AD review. > Fair 'nuff, fixed. I also added some additional names to the acknowledgement section - *huge* apologies to anyone we may have missed… Warren. [0]: I know this for a fact, as she doesn't actually exist :-P On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton <rwil...@cisco.com> wrote: > Hi authors, WG, > > Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They > are all minor/nit comments, meaning that I'll leave it to the authors > discretion as to how they want to handle these comments. > > Minor level comments: > > (1) p 3, sec 2. The alt Namespace > > Groups wishing to create new alternative namespaces may create their > alternative namespace under a label that names their namespace under the > .alt pseudo-TLD. The .alt namespace is unmanaged. > > This seems slightly strong given that the ISE draft is planning on setting > up a registry somewhere. So, perhaps "The .alt namespace is not managed by > the IETF or IANA"? > > (2) p 3, sec 2. The alt Namespace > > This document > does not define a registry or governance model for the .alt namespace. > Developers, applications and users should not expect unambiguous mappings > from names to name resolution mechanisms. > > Is "Developers, applications, users should not expect unambiguous > mappings" a bit strong? A possible alternative could be: "Developers, > applications and users are not guaranteed to have unambiguous mappings from > names to name resolution mechanisms." > > (3) p 3, sec 2. The alt Namespace > > Currently deployed projects and protocols that are using pseudo-TLDs may > choose to move under the .alt pseudo-TLD, but this is not a requirement. > > I was wondering whether we could we be slightly stronger here and use > "recommended to move" rather than "may choose to move"? I.e., I think that > the IETF position could reasonably be that we would like these to all turn > up under alt and not squat in the root namespace. > > Nit level comments: > > (4) p 6, sec Appendix A. Changes / Author Notes. > > * During AD review, made a few more requested changes > > As a minor nit, I think that these comments were during the WGLC, rather > than AD review. > > Regards, > Rob >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
