Re: [DNSOP] AD review of draft-ietf-dnsop-alt-tld-21
Hi Warren, & Paul, Those proposed changes look fine to me, so please can you post an updated version. Regards, Rob From: Warren Kumari Sent: 03 March 2023 23:28 To: Rob Wilton (rwilton) Cc: dnsop@ietf.org; draft-ietf-dnsop-alt-tld@ietf.org Subject: Re: AD review of draft-ietf-dnsop-alt-tld-21 On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton mailto: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<http://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 mailto: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"
Re: [DNSOP] AD review of draft-ietf-dnsop-alt-tld-21
On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton 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 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, > appli
[DNSOP] AD review of draft-ietf-dnsop-alt-tld-21
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
