[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators v2.

[Russ Mundy]

Folks,

I haven’t seen any discussion on the list about these changes but I wanted to comment prior to the call so my comments are inline.

Russ

> On Sep 23, 2016, at 1:42 PM, Wessels, Duane <dwessels at verisign.com> wrote:
> 
>> 
>> On Sep 23, 2016, at 10:19 AM, Andrew Mcconachie <andrew.mcconachie at icann.org> wrote:
>> 
>> Dear RSSAC Caucus,
>> 
>> On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find Key Technical Elements of Potential Root Operators version 2.2. Redline and clean versions in both pdf and MS Word are attached.
>> 
>> Duane and I worked to include the feedback we received from the two conference calls we had on this document.
>> 
>> Three things that we feel should be highlighted:
>> 1. Section 3.3.7(Address Registries) has been largely rewritten.
> 
> This is the section which mentions RPKI.  The text now says:
> 
> The Internet Engineering Task Force (IETF) and the RIRs have been working to develop and implement standards for routing security in the form of Resource Public Key Infrastructure (RPKI). At the time of publication the RSSAC was not able to reach consensus on whether RPKI should be included in the evaluation of a candidate operator.

I really do not like this wording since, by not ‘endorsing’ the use of RPKI & ROAs, RSSAC is essentially saying that they are negative about the technology.  I strongly object to the negative inference and would rather see no mention of the technology at all than the negative stance inferred in the current wording.

> 
>> 
>> 2. Section 3.6.4(Openness and Participation) has been removed. A single sentence referencing DNS-OARC and DITL collection has been added to section 3.6.1(Data & Measurement).
> 
> The rationale here is that, while openness and participation are very important, they are not really technical elements that could be *measured* during an evaluation of a potential operator.  The suggestion to remove it was made during the second caucus call, which I agree with.  We did add "openness and community participation" to the list of important non-technical elements mentioned in the introduction.

looks good

> 
>> 
>> 3. We would like to request more feedback on the usage of RFC 2119 language(e.g., SHOULD, MUST, MAY). Please discuss on the list.
> 
> Here the suggestion is that these RFC keywords come across as a bit too strong, and while many of us are familiar with them in the IETF context, perhaps the target audience for this document is not.  I think they also lead to confusion because usually we see them in protocol requirements documents.  Our document is neither about protocols, nor is it about placing requirements on operators.  It is advice to evaluators.  I support the suggestion to "lowercase" all the keywords and remove the reference to RFC 2119.

This is not a strongly held view but I would rather drop the caps and wording from the document.

> 
> DW
> 
> 
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus