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

[Terry Manderson]

Hi Russ and All,

(wearing just a caucus member hat)

> On 30 Sep 2016, at 12:50 AM, Russ Mundy <mundy at tislabs.com> wrote:
> 
>> 
>> 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.
> 

I disagree that this has negative connotations. It's the truth in that RSSAC was not able to reach consensus on this topic, for whatever reason. I like that we are able to say that and am very happy to see such transparency. This doesn't necessarily mean that RPKI et al is bad, but simply RSSAC has not been able to make a determination yet on the technology in light of the root server system. (and also sends a message that there is indeed another work item here for RSSAC, and some liaison with SSAC)

So I liked the proposed text from Duane when I saw it. 

>> 
>>> 
>>> 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

+1

> 
>> 
>>> 
>>> 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.
> 

I support the removal of 2119 boilerplate and the lowercase of the keywords provided it still makes sense - perhaps get a non-technical person to read it and paraphrase it back to us?


Terry