[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators v2.
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. 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). 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. Thanks, Andrew
On Sep 23, 2016, at 10:19 AM, Andrew Mcconachie <andrew.mcconachie@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.
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.
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. DW
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@verisign.com> wrote:
On Sep 23, 2016, at 10:19 AM, Andrew Mcconachie <andrew.mcconachie@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@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Sep 29, 2016, at 7:50 AM, Russ Mundy <mundy@tislabs.com> wrote:
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@verisign.com> wrote:
On Sep 23, 2016, at 10:19 AM, Andrew Mcconachie <andrew.mcconachie@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.
Thanks for the feedback, Russ. 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? DW
On 2016-09-29 16:16, Wessels, Duane wrote:
On Sep 29, 2016, at 7:50 AM, Russ Mundy <mundy@tislabs.com> wrote:
On Sep 23, 2016, at 1:42 PM, Wessels, Duane <dwessels@verisign.com> wrote:
On Sep 23, 2016, at 10:19 AM, Andrew Mcconachie <andrew.mcconachie@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.
Thanks for the feedback, Russ.
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 with Russ' point of view and the new text looks good. (Even though I'm not personally convinced about the ROAs either) -- Robert MARTIN-LEGENE Internet Infrastructure Specialist Packet Clearing House
Hi Russ and All, (wearing just a caucus member hat)
On 30 Sep 2016, at 12:50 AM, Russ Mundy <mundy@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
Hi, Terry and Russ,
在 2016年9月30日，07:43，Terry Manderson <terry@terrym.net> 写道：
Hi Russ and All,
(wearing just a caucus member hat)
On 30 Sep 2016, at 12:50 AM, Russ Mundy <mundy@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
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@zdns.cn> wrote:
Hi, Terry and Russ,
在 2016年9月30日，07:43，Terry Manderson <terry@terrym.net> 写道：
Hi Russ and All,
(wearing just a caucus member hat)
On 30 Sep 2016, at 12:50 AM, Russ Mundy <mundy@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@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Wes Hardaker USC/ISI
On 30 Sep 2016, at 17:55, Wes Hardaker <hardaker@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@zdns.cn> wrote: Hi, Terry and Russ,
在 2016年9月30日，07:43，Terry Manderson <terry@terrym.net> 写道：
Hi Russ and All,
(wearing just a caucus member hat)
On 30 Sep 2016, at 12:50 AM, Russ Mundy <mundy@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@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Wes Hardaker USC/ISI _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
I'm afraid I don't have the latest version of the document. Could someone post a fresh copy/link to that? TIA, jaap
Jaap, I have forwarded you the documents privately just now. DW
On Oct 1, 2016, at 9:19 AM, Jaap Akkerhuis <jaap@NLnetLabs.nl> wrote:
I'm afraid I don't have the latest version of the document. Could someone post a fresh copy/link to that?
TIA,
jaap _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
I've made a few small readability / grammar edits. W On Thu, Sep 29, 2016 at 7:43 PM, Terry Manderson <terry@terrym.net> wrote:
Hi Russ and All,
(wearing just a caucus member hat)
On 30 Sep 2016, at 12:50 AM, Russ Mundy <mundy@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 _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
participants (10)
-
Andrew Mcconachie -
Declan Ma -
Jaap Akkerhuis -
Robert Martin-Legene -
Romeo Zwart -
Russ Mundy -
Terry Manderson -
Warren Kumari -
Wes Hardaker -
Wessels, Duane