On Feb 2, 2025, at 06:47, Andrew McConachie via rssac-caucus <rssac-caucus@icann.org> wrote:
Dear RSSAC Caucus Members,
Duane, Ray, Ozan, and myself met on Thursday and merged all outstanding suggestions in the document.
https://docs.google.com/document/d/1ad1aaymsaDkBdBfXYPj19_PbNeIVnu6dQ2lb2L4A...
This starts a week review of this document. Please review it by Sunday February 9th.
If there are no significant suggestions this document will be sent to the RSSAC for a vote and eventual publication.
Sorry for late review. Good document. Minor suggestions (fine to just ignore them as they may not be appropriate or already discussed): - "Root hints data should be retrieved …” It seems to me that it would be useful to add a link to where the source of this data is. That way it becomes clear what we are talking about. (Root hints could I think be interpreted in various ways). - "“root hints” are a set of addresses which can be used by applications”. While it is theoretically possible that a generic/user/ application may have that data, it is essentially in resolvers. Resolvers are “applications” per se, but I think it is a bit misleading for a normal reader that would see “applications” as any application. I understand that the next sentence talks about the resolvers, but the rest of the paragraph is back to “applications”. I wonder if more specific text should be used such as s/application/name resolving application/ or similar. - "RSOs are expected to ensure that a future service address does not have a negative reputation in well-known address reputation databases.”. I understand the idea, but wonder how this is very practical and in fact really useful, as reputation databases are highly dynamic and are based on various heuristics that may lead to false reputation. More over what are the “well-known address reputation databases”: one may identify one where another may identify another. Finally I’m not even sure the community has agreement on what exactly negative reputation means and if the criteria are clear and based on consensus (if yes, then a link could be added as reference to the definition/criteria of reputation). If people really care about saying something like that, then at least make it way less assertive. Ex: s/ensure/review/. s/does not have/is not tainted with/. s/in well-known address reputation databases//. Regards, Marc.
Thanks, Andrew
On 12 Dec 2024, at 17:02, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
Duane, Ray and myself met today to discuss the RSSAC Caucus Guidelines for Changing IP Addresses Work Party.
We are requesting the full RSSAC Caucus review this publication from now until January 8th, 2025.
https://docs.google.com/document/d/1ad1aaymsaDkBdBfXYPj19_PbNeIVnu6dQ2lb2L4A...
The document is mostly stable. We modified the final two sentences of Section 3.4 and marked them as modified text. Otherwise we only merged text from our last call.
We are cancelling next week's meeting on December 19th, 2024. The work party's next call will be on January 9th, 2025. On that call the work party will review comments received in this full Caucus review cycle.
Depending on the comments received between now and January 8th, and the outcome of the call on January 9th, we may have a second full Caucus review. It really depends on how many comments we receive between now and January 9th. Staff will send a reminder on January 2nd, 2025 to remind everyone to review the document in the new year.
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.