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

Wes Hardaker hardaker at isi.edu
Fri Sep 30 15:55:09 UTC 2016


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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20160930/cec47131/attachment.html>


More information about the rssac-caucus mailing list