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

[Romeo Zwart]

> On 30 Sep 2016, at 17:55, Wes Hardaker <hardaker at isi.edu> wrote:
> 
> > So I'm hearing a proposal from Russ to strike that paragraph.  In that case the entire section 3.3.7 would read:
> > 
> > ==============================================================================
> > 3.3.7 Address Registries
> > 
> > The candidate operators address space SHOULD be accurately registered in
> > one of the Regional Internet Registry (RIR) public databases.  Additionally,
> > the candidate SHOULD have appropriate entries in relevant public routing
> > registries for their IPv4 and IPv6 address space.
> > ==============================================================================
> > 
> > How does everyone feel about that?
> 
> I agree this is better.  It's not so much that I don't want to "not be transparent"; I'm fine with the world knowing we aren't reaching consensus.  But that's not the place to publish it, as the document isn't meant to describe the "key technical elements we agree upon and stuff we don't".  So I think dropping it makes more sense, and the above wording is sufficient for the document, today at least.

+1 to Wes'  comment above. 

Ons note about the wording: I do believe the 'should' could be made stronger. I fail to see any reasonable objection to registering address space and prefixes, so imo we can phrase this as a 'must'.  

Ah, and since we seem to agree to move away from RFC2119 style the caps should be dropped?
 
Cheers,
Romeo

> 
>> On Thu, Sep 29, 2016 at 7:27 PM, Declan Ma <madi at zdns.cn> wrote:
>> Hi, Terry and Russ,
>> 
>> > 在 2016年9月30日，07:43，Terry Manderson <terry at terrym.net> 写道：
>> >
>> > 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)
>> 
>> It seems to me that we might set up a work item (maybe a Work Party) in terms of root system and RPKI in the light of discussions in this thread.
>> 
>> RPKI as yet another fundamental security enhancement, deserves our attentions with regard to safeguarding the routes to the root  servers, since many efforts have been made by the IETF community and RIRs have started to offer Resource Certification services .
>> 
>> 
>> Di
>> 
>> ZDNS
>> _______________________________________________
>> rssac-caucus mailing list
>> rssac-caucus at icann.org
>> https://mm.icann.org/mailman/listinfo/rssac-caucus
> 
> 
> 
> -- 
> Wes Hardaker
> USC/ISI
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20161001/262146a4/attachment.html>