Proposed change to RSSAC001v3 to combine expectations 3.1.B and 3.2.A
Greetings again. During the RSSAC001v3 work party call yesterday, we discussed possibly combining expectations 3.1.B and 3.2.A. To do this, I propose copying the descriptive text from the beginning of 3.2 ("An RSO is expected to choose hardware, software, and other components that allow it to meet the protocol and deployment requirements specified in BCP 40.") to the end of the paragraph in 3.1 that starts "BCP 40 describes...", removing [E.3.2-A] entirely, and relettering the expectations in the rest of 3.2 up one letter. Comments are welcome. --Paul Hoffman
On May 28, 2025, at 11:40 AM, Paul Hoffman via rssac-caucus <rssac-caucus@icann.org> wrote:
Greetings again. During the RSSAC001v3 work party call yesterday, we discussed possibly combining expectations 3.1.B and 3.2.A. To do this, I propose copying the descriptive text from the beginning of 3.2 ("An RSO is expected to choose hardware, software, and other components that allow it to meet the protocol and deployment requirements specified in BCP 40.") to the end of the paragraph in 3.1 that starts "BCP 40 describes...", removing [E.3.2-A] entirely, and relettering the expectations in the rest of 3.2 up one letter.
Comments are welcome.
This would be easier to do in an editable google doc, but I’m not yet convinced 3.1.B and 3.2.A should be combined. Note that 3.1.B applies to RSOs collectively, while 3.2.A applies to RSOs individually. I know that was intentional. DW
On May 28, 2025, at 13:30, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
On May 28, 2025, at 11:40 AM, Paul Hoffman via rssac-caucus <rssac-caucus@icann.org> wrote:
Greetings again. During the RSSAC001v3 work party call yesterday, we discussed possibly combining expectations 3.1.B and 3.2.A. To do this, I propose copying the descriptive text from the beginning of 3.2 ("An RSO is expected to choose hardware, software, and other components that allow it to meet the protocol and deployment requirements specified in BCP 40.") to the end of the paragraph in 3.1 that starts "BCP 40 describes...", removing [E.3.2-A] entirely, and relettering the expectations in the rest of 3.2 up one letter.
Comments are welcome.
This would be easier to do in an editable google doc, but I’m not yet convinced 3.1.B and 3.2.A should be combined.
Note that 3.1.B applies to RSOs collectively, while 3.2.A applies to RSOs individually. I know that was intentional.
<sigh> 3.2-A says that each RSO is expected to do everything in BCP 40 as if each RSO stands alone. Thus, 3.2-A goes beyond BCP 40 to make it per-RSO. Instead of combining them, we might either: - get rid of 3.2-A because it wrongly changes the scope of BCP 40 - get rid of 3.1-B because if every RSO is doing 3.2-A, there is no need for it Thoughts? --Paul Hoffman
<sigh> 3.2-A says that each RSO is expected to do everything in BCP 40 as if each RSO stands alone. Thus, 3.2-A goes beyond BCP 40 to make it per-RSO.
I'd agree that BCP40 is sort of a wrong target for per-RSO expectations. BCP40 is saying what the system must do, and there are likely elements within BCP40 that will apply to each RSO as the system can't support BCP40 if each RSO individually doesn't uphold those parts. So it's confusing. Looking at all the MUST requirements in BCP40 (aka rfc7720) are required
across every instance, which means we should be able to point at it.
IMHO, this weird situation derives from the 001 requirements wanting to refer to those other expectations, which we should do, but at the same time list them as "external". Maybe the right thing to do is drop both 3.2-A and 3.1-B in favor of a more generic statement like "In addition to the requirements in this document, requirements from the IETF on root server operators are documented in BCP40" -- Wes Hardaker USC/ISI
participants (3)
-
Paul Hoffman -
Wes Hardaker -
Wessels, Duane