Following up on what Paul said, I think this document has too narrow a scope. It addresses something that has happened infrequently, and unless someone is hinting at something, it shouldn’t occur for a while—at least not without plenty of notice and under controlled circumstances. I’ve been reading through the thread but haven’t had much time to respond. Between recovering from the heart attack, job hunting, and just enjoying life, things have been a bit slow on my end. That said, I believe the following points have been discussed and either need the scope of the current document extended or require the formation of a new work party: 1. Updating root hints and everything that entails, with proper communication and, hopefully, smooth propagation to the folks who need it (e.g., software vendors). NEW WORK PARTY? 2. RSO communication—this is being discussed elsewhere, but how can we better communicate with the ‘community’ and other stakeholders? NEW WORK PARTY? 3. Accepting direct communication from the community to the RSO for $REASONS. NEW WORK PARTY? 4. The current document doesn’t seem to address future scenarios and focuses only on instances where an RSO is changing a current address. I think the following should be considered: a. In-place changes where an RSO needs to update for $REASONS. i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion? b. Operator experiences a protracted outage, and another RSO needs to temporarily announce the space. c. Operator capture—needs removal, and another RSO needs to announce for $TIME. d. Operator goes rogue or ghosts the RSO and fails to fulfill their obligations. e. A new operator is added, and a new letter is required (likely using CI space from the RIR's). i. Should a global policy be proposed to reserve some CI space in each RIR's pool for expansion? Respectfully submitted for your consideration. I believe the document should include or expand on some future-proofing to account for these possibilities. -- Darren Kara darren@thekaras.org On Tue, Oct 15, 2024, at 12:22 PM, Paul Hoffman via rssac-caucus wrote:
Greetings, all. I'm seeing a lot of things in that thread that have nothing to do with the thread topic. They do have to do with possible future interesting work for the RSSAC Caucus.
Please consider starting a new thread with your new idea for work. This will help those of us who might want to work with you to know where you are going.
If you really are commenting on the current document, please maybe point more carefully at which words in the document you think need changing. This will help those of us who think the document is pretty much done know where it might not be.
Thanks!
--Paul Hoffman _______________________________________________ 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.