Replies inline, mostly no hat. On 2024/10/15 20:22, Darren Kara via rssac-caucus wrote:
I think this document has too narrow a scope
I think it's just right. The SOW was AIUI mostly intended to create a document that covers all the "dumb questions" that arose when B-root announced their recent change on NANOG and other places. Apart from a thorny question about allocation policies (see below) the work party is *mostly* done.
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?
IANA has an established process for updating the root hints (and the other two official sources of root server addresses listed in RSSAC030) and changes to that are (IMHO) out of our purview. We've touched on the communications (see below).
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?
Hmm, maybe. We've punted on this within the scope of this work party, at least for outbound communications re: root server IP changes. The majority view is that any notifications to anyone beyond IANA are effectively a courtesty notification, and we are currently loathe to formalise anything beyond that. If there was a body that should be in a position to notify the community (where membership of that community is self selecting) it's probably IANA itself but I don't think RSSAC has standing to ask IANA to take that on. For more general communications between the RSOs and stakeholders, that probably has to wait until RSS GS is in place.
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.
How is that different to the work party's current topic?
i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion?
Something like this is being discussed, or more specifically, how to develop a policy that preserves any current address space currently being used for root service such that it can never be used for anything else. In the presence of such a hypothetical policy it is unclear that there is any additional benefit of using CI space, since the primary characteristic of CI space are its allocation and return policies. (Once you have space, the allocation policy doesn't matter. If the global policy is that root service space doesn't get returned, then the CI return policies don't matter either)
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.
Cannot be done (AFAIK) under the current LIR / RIR model (where the IP space is under the control of the individual RSOs) without either the cooperation of the failing RSO or unilateral action by the RIR that would be very likely (IANAL) outside of their T&Cs.
e. A new operator is added, and a new letter is required (likely using CI space from the RIR's).
Subject to resolution of the CI question, this is effectively covered by the current document. Ray