[ Yes, I changed the subject, again, so that the threads make sense later. ] On Oct 15, 2024, at 12:22, Darren Kara via rssac-caucus <rssac-caucus@icann.org> wrote:
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.
No one in the Work Party has hinted at anything like that.
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?
In my mind, this belongs to IANA, not the RSSAC. If RSSAC feels that IANA is doing this wrong, then a note to IANA would probably suffice; having said that, I haven't heard what IANA is doing wrong here.
2. RSO communication—this is being discussed elsewhere, but how can we better communicate with the ‘community’ and other stakeholders? NEW WORK PARTY?
RSSAC (not the Caucus) is actively working on this. RSSAC has, so far, not asked for Caucus input on their work.
3. Accepting direct communication from the community to the RSO for $REASONS. NEW WORK PARTY?
RSOs hear directly from the community all the time. Can you be more specific about the problem?
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.
Update what?
i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion?
That is indeed being discussed.
b. Operator experiences a protracted outage, and another RSO needs to temporarily announce the space.
Define "need". Seriously, what noticeable damage is done by an RSO being unresponsive for a long time?
c. Operator capture—needs removal, and another RSO needs to announce for $TIME.
This is a core goal for the RSS GWG.
d. Operator goes rogue or ghosts the RSO and fails to fulfill their obligations.
This is a core goal for the RSS GWG.
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?
I suspect that this is closely related to (4a) above. --Paul Hoffman