A significant comment on "Courtesy Preview: SSAC Report on the Evolution of Internet Name Resolution"
We sent the evo-reso report to OCTO and got a quick response from Paul Hoffman, which we, the work party, need to consider:
Greetings agian. Matt passed the preview to OCTO, and I read it through. It is comprehensive and useful, but I am very concerned about Recommendation 2: "The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities." Please consider passing my concerns on to SSAC.
--Paul
To the best of my knowledge ICANN org has *never* encouraged collaboration or facilitated coordination "among the various namespace communities". Nothing in the body of the document (that I could find) talks about ICANN org doing this, which is good: we shouldn't be doing it. As far as I know, ICANN org is not working with any of the systems listed in Section 5, not even mDNS. From Section 9, SAC113 and RFC 9476 will not help with collaboration or coordination at all: they will give two unmanaged namespaces where there is likely to be collisions at the second level.
OCTO sponsoring the Emerging Identifier Technologies panels is about exposing the ICANN community to the identifiers, not to encourage collaboration or facilitate coordination. The outcome of each one of these has been education of the community and no follow-up with the representatives of the identifiers. Education is not collaboration or coordination.
If SSAC wants to recommend that ICANN org *start* "to encourage collaboration and facilitate coordination among the various namespace communities", it would be useful for this document to say how we might do that and what the harmsand benefits might be. Given that you want to publish the document in the next few weeks, it would likely be better to simply remove this recommendation from the current document and start new work talking about possible work to encourage collaboration and facilitate coordination. (To be clear, I'm quite skeptical that such work would have more benefit than harm, but SSAC might have a different opinion.)
Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community. Given his comment on this, I agree that we should reconsider recommendation 2, with, as I see it, two likely outcomes: 1. We simply remove the recommendation. 2. We change the wording to refer more directly to the Emerging Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings." If we choose path 2, we need to consider whether it's a separate recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols." I'd like to try to get this resolved this week by email, rather than having another work party call, so let's please have a discussion here on the work party mailing list. Thoughts? Barry
On 11 Dec 2023, at 15:01, Barry Leiba <barryleiba@computer.org> wrote:
To the best of my knowledge ICANN org has *never* encouraged collaboration or facilitated coordination "among the various namespace communities".
I think that's true and I also think that is good. ICANN should worry about its own namespace and should not waste time with others.
Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about.
I'm not in this work party as far as I know so I don't know what was discussed. Perhaps there are nuances that I am not aware of. I'm not sure why I'm on this list, to be honest. However I do think it would be a mistake for ICANN to start chasing shadows, or for SSAC to suggest that it should start doing so. Joe
On Mon, Dec 11, 2023 at 10:00 AM, Barry Leiba <barryleiba@computer.org> wrote:
We sent the evo-reso report to OCTO and got a quick response from Paul Hoffman, which we, the work party, need to consider:
Greetings agian. Matt passed the preview to OCTO, and I read it through. It is comprehensive and useful, but I am very concerned about Recommendation 2: "The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities." Please consider passing my concerns on to SSAC.
--Paul
To the best of my knowledge ICANN org has *never* encouraged collaboration or facilitated coordination "among the various namespace communities". Nothing in the body of the document (that I could find) talks about ICANN org doing this, which is good: we shouldn't be doing it. As far as I know, ICANN org is not working with any of the systems listed in Section 5, not even mDNS. From Section 9, SAC113 and RFC 9476 will not help with collaboration or coordination at all: they will give two unmanaged namespaces where there is likely to be collisions at the second level.
OCTO sponsoring the Emerging Identifier Technologies panels is about exposing the ICANN community to the identifiers, not to encourage collaboration or facilitate coordination. The outcome of each one of these has been education of the community and no follow-up with the representatives of the identifiers. Education is not collaboration or coordination.
If SSAC wants to recommend that ICANN org *start* "to encourage collaboration and facilitate coordination among the various namespace communities", it would be useful for this document to say how we might do that and what the harmsand benefits might be. Given that you want to publish the document in the next few weeks, it would likely be better to simply remove this recommendation from the current document and start new work talking about possible work to encourage collaboration and facilitate coordination. (To be clear, I'm quite skeptical that such work would have more benefit than harm, but SSAC might have a different opinion.)
Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than having another work party call, so let's please have a discussion here on the work party mailing list.
Thoughts?
Completely removing a recommendation (especially halving the recommendations :-) ) this late in the process seems like a fairly major change — I think that we should instead just clarify what we meant. Your "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings." seems like fine text to me… W
Barry _______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than having another work party call, so let's please have a discussion here on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems. We could simply make this more DNS-centric and say: "In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS." i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk. Geoff
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text: Original text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities. Proposed text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings. Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS." Please let me know if you are ok or have any objections to this proposal. Best Steve On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear
that those panels were *not* meant to be any sort of forum for
collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC
recommends that the ICANN organization continue to keep the ICANN
community abreast of new developments through such means as the
Emerging Identifier Technologies panels that have been presented at a
number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already
says, "The SSAC recommends that the ICANN organization continue to
track and provide regular updates to the ICANN Board and community on
both alternative protocols that make use of the domain namespace, and
efforts to create mitigations and reduce risks inherent in the
coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here
on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems. We could simply make this more DNS-centric and say: "In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS." i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk. Geoff _______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org> https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I am ok with this Steve Geoff
On 12 Dec 2023, at 10:31 am, Steve Sheng <steve.sheng@icann.org> wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text: Original text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities. Proposed text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings. Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS." Please let me know if you are ok or have any objections to this proposal. Best Steve On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community. Given his comment on this, I agree that we should reconsider recommendation 2, with, as I see it, two likely outcomes: 1. We simply remove the recommendation. 2. We change the wording to refer more directly to the Emerging Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings." If we choose path 2, we need to consider whether it's a separate recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols." I'd like to try to get this resolved this week by email, rather than having another work party call, so let's please have a discussion here on the work party mailing list. Thoughts? It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems. We could simply make this more DNS-centric and say: "In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS." i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk. Geoff _______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org> https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
That looks like a good revision to me, Steve. Thanks. --TW On Mon, Dec 11, 2023 at 10:31 PM Geoff Huston <gih902@gmail.com> wrote:
I am ok with this Steve
Geoff
On 12 Dec 2023, at 10:31 am, Steve Sheng <steve.sheng@icann.org> wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text: Original text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities. Proposed text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings. Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS." Please let me know if you are ok or have any objections to this proposal. Best Steve On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" < ssac-evo-reso-wp-bounces@icann.org <mailto: ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto: gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community. Given his comment on this, I agree that we should reconsider recommendation 2, with, as I see it, two likely outcomes: 1. We simply remove the recommendation. 2. We change the wording to refer more directly to the Emerging Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings." If we choose path 2, we need to consider whether it's a separate recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols." I'd like to try to get this resolved this week by email, rather than having another work party call, so let's please have a discussion here on the work party mailing list. Thoughts? It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems. We could simply make this more DNS-centric and say: "In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS." i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk. Geoff _______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org> https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp < https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy < https://www.icann.org/privacy/policy>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Tara Whalen writes:
That looks like a good revision to me, Steve. Thanks. --TW
Yeah, looks fine to me. And while you are at it, please fix also the reference to Humpty Dumpty. I assume that we will give the whole SSAC a chance to comment on these late minute changes. jaap
On Tue, Dec 12, 2023 at 1:30 AM, Geoff Huston <gih902@gmail.com> wrote:
I am ok with this Steve
Yah, me too… W
Geoff
On 12 Dec 2023, at 10:31 am, Steve Sheng <steve.sheng@icann.org> wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text: Original text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities. Proposed text: Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols. The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings. Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS." Please let me know if you are ok or have any objections to this proposal. Best Steve On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" < ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann. org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation. 2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems. We could simply make this more DNS-centric and say: "In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS." i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk. Geoff _______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org> https://mm. icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/ listinfo/ssac-evo-reso-wp> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy < https://www.icann.org/privacy/policy>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I’ve seen that others have supported this change. Unfortunately, I’m not so sure about the proposed recommendation 2. My understanding of Paul’s comments is that ICANN org is currently not facilitating coordination. Thus, it seems wrong to me to suggest that ICANN org should continue doing exactly that. I like the change to recommendation 1 and I’m inclined to delete recommendation 2. This matches Barry’s path 2 with recommendation 2 being subsumed by path 2. A detailed concern with recommendation 2 as proposed is that the leading phrase — “In order to mitigate …” — does not belong in the recommendation. The “why” of a recommendation should be readily apparent elsewhere in the text. If we want to support Geoff’s observation that “carving out a part of the namespace” is coordination, then that needs to be fully explained in the text, and I don’t believe it is. If I’ve missed something in the text please let me know. Finally, responding to Warren’s concern that deleting a recommendation is a material change, in this case I don’t believe deleting this recommendation is material. I believe it is a clarification insofar as we are combining recommendations 1 and 2 based on comments from those who are going to have to act on these recommendations. This is a feature in my opinion. Others may have a different opinion. Jim On 11 Dec 2023, at 22:31, Steve Sheng wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text:
Original text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities.
Proposed text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings.
Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS."
Please let me know if you are ok or have any objections to this proposal.
Best
Steve
On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear
that those panels were *not* meant to be any sort of forum for
collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC
recommends that the ICANN organization continue to keep the ICANN
community abreast of new developments through such means as the
Emerging Identifier Technologies panels that have been presented at a
number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already
says, "The SSAC recommends that the ICANN organization continue to
track and provide regular updates to the ICANN Board and community on
both alternative protocols that make use of the domain namespace, and
efforts to create mitigations and reduce risks inherent in the
coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here
on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems.
We could simply make this more DNS-centric and say:
"In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS."
i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk.
Geoff
_______________________________________________
SSAC-Evo-Reso-WP mailing list
SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org>
https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy> ) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos> ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
As a participant: I agree with everything Jim said, highlighting two points: - The new text for R2 still does not address Paul's concern about the recommendation to "continue" something that isn't already being done. I agree with Paul that if we change that from "continue" to "begin doing", we should provide some text in the document about how to go about it and why it's likely to be effective, and I really don't think we can. - The recasting of R2 and then merging it into R1, which Steve has posted, works for me, and I don't think it constitutes a full removal of R2 at this point. And I think it's important to address Paul's concern even if it should involve a bit of late-stage backtracking. If you all will recall, there was a lot of concern during the document development, and plenty of discussion about whether we should include R2. Honestly, I think we decided to keep R2 in large part because we were looking for recommendations to include. I (again, as a participant) am happy with Steve's suggestion for R1 and then otherwise removing R2 as now being merged with R1. Barry On Tue, Dec 12, 2023 at 8:55 AM James Galvin <galvin@elistx.com> wrote:
I’ve seen that others have supported this change. Unfortunately, I’m not so sure about the proposed recommendation 2.
My understanding of Paul’s comments is that ICANN org is currently not facilitating coordination. Thus, it seems wrong to me to suggest that ICANN org should continue doing exactly that.
I like the change to recommendation 1 and I’m inclined to delete recommendation 2. This matches Barry’s path 2 with recommendation 2 being subsumed by path 2.
A detailed concern with recommendation 2 as proposed is that the leading phrase — “In order to mitigate …” — does not belong in the recommendation. The “why” of a recommendation should be readily apparent elsewhere in the text.
If we want to support Geoff’s observation that “carving out a part of the namespace” is coordination, then that needs to be fully explained in the text, and I don’t believe it is. If I’ve missed something in the text please let me know.
Finally, responding to Warren’s concern that deleting a recommendation is a material change, in this case I don’t believe deleting this recommendation is material. I believe it is a clarification insofar as we are combining recommendations 1 and 2 based on comments from those who are going to have to act on these recommendations. This is a feature in my opinion. Others may have a different opinion.
Jim
On 11 Dec 2023, at 22:31, Steve Sheng wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text:
Original text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities.
Proposed text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings.
Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS."
Please let me know if you are ok or have any objections to this proposal.
Best
Steve
On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear
that those panels were *not* meant to be any sort of forum for
collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC
recommends that the ICANN organization continue to keep the ICANN
community abreast of new developments through such means as the
Emerging Identifier Technologies panels that have been presented at a
number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already
says, "The SSAC recommends that the ICANN organization continue to
track and provide regular updates to the ICANN Board and community on
both alternative protocols that make use of the domain namespace, and
efforts to create mitigations and reduce risks inherent in the
coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here
on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems.
We could simply make this more DNS-centric and say:
"In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS."
i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk.
Geoff
_______________________________________________
SSAC-Evo-Reso-WP mailing list
SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org>
https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
As a participant: I agree with everything Jim said, highlighting two points:
Yes, on reflection, +1 from me on this.
Honestly, I think we decided to keep R2 in large part because we were looking for recommendations to include.
This matches my recollection; there was dithering over how to present the small amount of recommendation text that we had.
I (again, as a participant) am happy with Steve's suggestion for R1 and then otherwise removing R2 as now being merged with R1.
That seems to work. R1 looks good and includes the important parts of R2 -- so removing R2 (I think) removes the objectionable part that Paul identified. --TW
OK, the discussion seems to have settled now, and I think we have an answer. Is there anyone who thinks that using Steve's version of R1 and then removing R2 is *not* acceptable? I'll ask Steve to move ahead with that at the end of the day Friday if we don't hear any objections. Barry On Tue, Dec 12, 2023 at 11:13 AM Barry Leiba <barryleiba@computer.org> wrote:
As a participant: I agree with everything Jim said, highlighting two points:
- The new text for R2 still does not address Paul's concern about the recommendation to "continue" something that isn't already being done. I agree with Paul that if we change that from "continue" to "begin doing", we should provide some text in the document about how to go about it and why it's likely to be effective, and I really don't think we can.
- The recasting of R2 and then merging it into R1, which Steve has posted, works for me, and I don't think it constitutes a full removal of R2 at this point. And I think it's important to address Paul's concern even if it should involve a bit of late-stage backtracking. If you all will recall, there was a lot of concern during the document development, and plenty of discussion about whether we should include R2.
Honestly, I think we decided to keep R2 in large part because we were looking for recommendations to include. I (again, as a participant) am happy with Steve's suggestion for R1 and then otherwise removing R2 as now being merged with R1.
Barry
On Tue, Dec 12, 2023 at 8:55 AM James Galvin <galvin@elistx.com> wrote:
I’ve seen that others have supported this change. Unfortunately, I’m not so sure about the proposed recommendation 2.
My understanding of Paul’s comments is that ICANN org is currently not facilitating coordination. Thus, it seems wrong to me to suggest that ICANN org should continue doing exactly that.
I like the change to recommendation 1 and I’m inclined to delete recommendation 2. This matches Barry’s path 2 with recommendation 2 being subsumed by path 2.
A detailed concern with recommendation 2 as proposed is that the leading phrase — “In order to mitigate …” — does not belong in the recommendation. The “why” of a recommendation should be readily apparent elsewhere in the text.
If we want to support Geoff’s observation that “carving out a part of the namespace” is coordination, then that needs to be fully explained in the text, and I don’t believe it is. If I’ve missed something in the text please let me know.
Finally, responding to Warren’s concern that deleting a recommendation is a material change, in this case I don’t believe deleting this recommendation is material. I believe it is a clarification insofar as we are combining recommendations 1 and 2 based on comments from those who are going to have to act on these recommendations. This is a feature in my opinion. Others may have a different opinion.
Jim
On 11 Dec 2023, at 22:31, Steve Sheng wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text:
Original text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities.
Proposed text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings.
Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS."
Please let me know if you are ok or have any objections to this proposal.
Best
Steve
On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear
that those panels were *not* meant to be any sort of forum for
collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC
recommends that the ICANN organization continue to keep the ICANN
community abreast of new developments through such means as the
Emerging Identifier Technologies panels that have been presented at a
number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already
says, "The SSAC recommends that the ICANN organization continue to
track and provide regular updates to the ICANN Board and community on
both alternative protocols that make use of the domain namespace, and
efforts to create mitigations and reduce risks inherent in the
coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here
on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems.
We could simply make this more DNS-centric and say:
"In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS."
i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk.
Geoff
_______________________________________________
SSAC-Evo-Reso-WP mailing list
SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org>
https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
This works for me.
On Dec 14, 2023, at 8:44 AM, Barry Leiba <barryleiba@computer.org> wrote:
OK, the discussion seems to have settled now, and I think we have an answer.
Is there anyone who thinks that using Steve's version of R1 and then removing R2 is *not* acceptable? I'll ask Steve to move ahead with that at the end of the day Friday if we don't hear any objections.
Barry
On Tue, Dec 12, 2023 at 11:13 AM Barry Leiba <barryleiba@computer.org> wrote:
As a participant: I agree with everything Jim said, highlighting two points:
- The new text for R2 still does not address Paul's concern about the recommendation to "continue" something that isn't already being done. I agree with Paul that if we change that from "continue" to "begin doing", we should provide some text in the document about how to go about it and why it's likely to be effective, and I really don't think we can.
- The recasting of R2 and then merging it into R1, which Steve has posted, works for me, and I don't think it constitutes a full removal of R2 at this point. And I think it's important to address Paul's concern even if it should involve a bit of late-stage backtracking. If you all will recall, there was a lot of concern during the document development, and plenty of discussion about whether we should include R2.
Honestly, I think we decided to keep R2 in large part because we were looking for recommendations to include. I (again, as a participant) am happy with Steve's suggestion for R1 and then otherwise removing R2 as now being merged with R1.
Barry
On Tue, Dec 12, 2023 at 8:55 AM James Galvin <galvin@elistx.com> wrote:
I’ve seen that others have supported this change. Unfortunately, I’m not so sure about the proposed recommendation 2.
My understanding of Paul’s comments is that ICANN org is currently not facilitating coordination. Thus, it seems wrong to me to suggest that ICANN org should continue doing exactly that.
I like the change to recommendation 1 and I’m inclined to delete recommendation 2. This matches Barry’s path 2 with recommendation 2 being subsumed by path 2.
A detailed concern with recommendation 2 as proposed is that the leading phrase — “In order to mitigate …” — does not belong in the recommendation. The “why” of a recommendation should be readily apparent elsewhere in the text.
If we want to support Geoff’s observation that “carving out a part of the namespace” is coordination, then that needs to be fully explained in the text, and I don’t believe it is. If I’ve missed something in the text please let me know.
Finally, responding to Warren’s concern that deleting a recommendation is a material change, in this case I don’t believe deleting this recommendation is material. I believe it is a clarification insofar as we are combining recommendations 1 and 2 based on comments from those who are going to have to act on these recommendations. This is a feature in my opinion. Others may have a different opinion.
Jim
On 11 Dec 2023, at 22:31, Steve Sheng wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text:
Original text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities.
Proposed text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings.
Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS."
Please let me know if you are ok or have any objections to this proposal.
Best
Steve
On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear
that those panels were *not* meant to be any sort of forum for
collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC
recommends that the ICANN organization continue to keep the ICANN
community abreast of new developments through such means as the
Emerging Identifier Technologies panels that have been presented at a
number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already
says, "The SSAC recommends that the ICANN organization continue to
track and provide regular updates to the ICANN Board and community on
both alternative protocols that make use of the domain namespace, and
efforts to create mitigations and reduce risks inherent in the
coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here
on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems.
We could simply make this more DNS-centric and say:
"In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS."
i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk.
Geoff
_______________________________________________
SSAC-Evo-Reso-WP mailing list
SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org>
https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Works for me. Jim On 14 Dec 2023, at 8:44, Barry Leiba wrote:
OK, the discussion seems to have settled now, and I think we have an answer.
Is there anyone who thinks that using Steve's version of R1 and then removing R2 is *not* acceptable? I'll ask Steve to move ahead with that at the end of the day Friday if we don't hear any objections.
Barry
On Tue, Dec 12, 2023 at 11:13 AM Barry Leiba <barryleiba@computer.org> wrote:
As a participant: I agree with everything Jim said, highlighting two points:
- The new text for R2 still does not address Paul's concern about the recommendation to "continue" something that isn't already being done. I agree with Paul that if we change that from "continue" to "begin doing", we should provide some text in the document about how to go about it and why it's likely to be effective, and I really don't think we can.
- The recasting of R2 and then merging it into R1, which Steve has posted, works for me, and I don't think it constitutes a full removal of R2 at this point. And I think it's important to address Paul's concern even if it should involve a bit of late-stage backtracking. If you all will recall, there was a lot of concern during the document development, and plenty of discussion about whether we should include R2.
Honestly, I think we decided to keep R2 in large part because we were looking for recommendations to include. I (again, as a participant) am happy with Steve's suggestion for R1 and then otherwise removing R2 as now being merged with R1.
Barry
On Tue, Dec 12, 2023 at 8:55 AM James Galvin <galvin@elistx.com> wrote:
I’ve seen that others have supported this change. Unfortunately, I’m not so sure about the proposed recommendation 2.
My understanding of Paul’s comments is that ICANN org is currently not facilitating coordination. Thus, it seems wrong to me to suggest that ICANN org should continue doing exactly that.
I like the change to recommendation 1 and I’m inclined to delete recommendation 2. This matches Barry’s path 2 with recommendation 2 being subsumed by path 2.
A detailed concern with recommendation 2 as proposed is that the leading phrase — “In order to mitigate …” — does not belong in the recommendation. The “why” of a recommendation should be readily apparent elsewhere in the text.
If we want to support Geoff’s observation that “carving out a part of the namespace” is coordination, then that needs to be fully explained in the text, and I don’t believe it is. If I’ve missed something in the text please let me know.
Finally, responding to Warren’s concern that deleting a recommendation is a material change, in this case I don’t believe deleting this recommendation is material. I believe it is a clarification insofar as we are combining recommendations 1 and 2 based on comments from those who are going to have to act on these recommendations. This is a feature in my opinion. Others may have a different opinion.
Jim
On 11 Dec 2023, at 22:31, Steve Sheng wrote:
Thank you all. I have read through the comments as well as the document. Taking all the inputs, I proposed the following text:
Original text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
Recommendation 2: The SSAC recommends that the ICANN organization continue to encourage collaboration and facilitate coordination among the various namespace communities.
Proposed text:
Recommendation 1: The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols.
The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings.
Recommendation 2: In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to facilitate coordination between the various alternative namespace communities and the namespace used by the DNS."
Please let me know if you are ok or have any objections to this proposal.
Best
Steve
On 12/11/23, 5:17 PM, "SSAC-Evo-Reso-WP on behalf of Geoff Huston" <ssac-evo-reso-wp-bounces@icann.org <mailto:ssac-evo-reso-wp-bounces@icann.org> on behalf of gih902@gmail.com <mailto:gih902@gmail.com>> wrote:
Now, we did discuss this at length, and I believe it was the
referenced EIT panels that we were talking about. Paul is very clear
that those panels were *not* meant to be any sort of forum for
collaboration, and were *only* to inform the community.
Given his comment on this, I agree that we should reconsider
recommendation 2, with, as I see it, two likely outcomes:
1. We simply remove the recommendation.
2. We change the wording to refer more directly to the Emerging
Identifier Technologies panels, and say something like, "The SSAC
recommends that the ICANN organization continue to keep the ICANN
community abreast of new developments through such means as the
Emerging Identifier Technologies panels that have been presented at a
number of ICANN meetings."
If we choose path 2, we need to consider whether it's a separate
recommendation or gets subsumed into recommendation 1, which already
says, "The SSAC recommends that the ICANN organization continue to
track and provide regular updates to the ICANN Board and community on
both alternative protocols that make use of the domain namespace, and
efforts to create mitigations and reduce risks inherent in the
coexistence of multiple namespaces and protocols."
I'd like to try to get this resolved this week by email, rather than
having another work party call, so let's please have a discussion here
on the work party mailing list.
Thoughts?
It all depends on how you read the recommendation - without a doubt name space collisions across these various alternative name spaces and the DNS exist and the recent efforts to mitigate the user impact of such collision's by carving out a part of the namespace is to my mind an example of such an effort at coordination between the DNA and alternative name systems.
We could simply make this more DNS-centric and say:
"In order to mitigate the potential harms of collisions between namespaces used by alternative name systems and the DNS, the SSAC recommends that the ICANN organization continue to encourage facilitate coordination between the various alternaive namespace communities and the namespace used by the DNS."
i.e. we have little to say if they talk to each other, but we prefer that to reduce collisions that they talk with the DNS folk.
Geoff
_______________________________________________
SSAC-Evo-Reso-WP mailing list
SSAC-Evo-Reso-WP@icann.org <mailto:SSAC-Evo-Reso-WP@icann.org>
https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp <https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy> ) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos> ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SSAC-Evo-Reso-WP mailing list SSAC-Evo-Reso-WP@icann.org https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (9)
-
Barry Leiba -
Geoff Huston -
Jaap Akkerhuis -
James Galvin -
Joe Abley -
Russ Housley -
Steve Sheng -
Tara Whalen -
Warren Kumari