[rssac-caucus] Best Practices for the Distribution of Anycast Instances of the Root Name Service WP Conclusion
Dear RSSAC Caucus, Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results. Please let me know if you have any suggestions or questions. All the best, Kaveh.
On Feb 2, 2018, at 10:06 AM, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
Thanks Kaveh and WP members, I read through the document and have the following comments: Table 1: Rows in this table should be either Letters+Orgs or just Orgs. I suggest removing "(A/J root)" from the Verisign row. Section 3, third paragraph: I worry that this paragraph, which talks about DOS events, makes it sound like these are more serious or likely to occur than they really are. Has there ever been a time when a significant proportion of servers were unable to return answers in a timely manner? I think its important to state these as reasons why we utilize anycast, but we should also not give the false impression that widespread unavailability is likely to happen. Section 4: I think the values of 30ms low latency and 100ms high latency are good. Section 4: Somewhere in this section maybe it would be appropriate to state that the nature of traffic from recursive name servers can impact the perceived latency? If a recursive mostly asks the root about existing TLDs then those are highly cachable, but a recursive (or user population) that sends a lot of queries for non-existing TLDs may have a worse overall user experience? Section 4 "The RSSAC asks" bold text: I like this line of questioning, however I wonder if "maximum latency" should maybe be something else like median or mean, or 90th percentile instead? I think maximum might actually be unbounded. Also I wonder if it should just be left at "with the DNS root service" and drop "as opposed to a single root server" from the question. Section 4, last para: Glad to see the line about how increased latency may be due to peering relationships between ISPs. I think that is very important. Section 6.1: both the first and third paragraphs seem to talk about forged routes for longer prefixes? DW
Wessels, Duane via rssac-caucus wrote:
Section 3, third paragraph: I worry that this paragraph, which talks about DOS events, makes it sound like these are more serious or likely to occur than they really are. Has there ever been a time when a significant proportion of servers were unable to return answers in a timely manner? ...
yes. in 2001, only f-root was up continuously, loss free, from all monitoring stations.
... I think its important to state these as reasons why we utilize anycast, but we should also not give the false impression that widespread unavailability is likely to happen.
i agree that softening this language is a good idea, because things are not fragile today. -- P Vixie
Table 1: Rows in this table should be either Letters+Orgs or just Orgs. I suggest removing "(A/J root)" from the Verisign row. I suggest putting this in two different rows, actually, unless they are being announced in the same manner on all locations (which traceroute seems to indicate that they are not).
It "doesn't really matter" who runs the server, I think. Rather, for a study like this, it is about how the servers are different. -- Robert MARTIN-LEGENE Internet Infrastructure Specialist Packet Clearing House
On Feb 5, 2018, at 1:59 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
Table 1: Rows in this table should be either Letters+Orgs or just Orgs. I suggest removing "(A/J root)" from the Verisign row.
I would agree. Specifically, the RSSAC is trying to move away from letters, which are there primarily to facilitate compression of the priming message. We are trying to change to identifying organizations (which you may imagine takes some reminding-of-ourselves to make happen) and away from letters. At least in part, that is to making it (at least conceptually) simpler to add an identity.
Thanks Kaveh and Work Party members, This is personal opinion, all hats off. I have some concerns about "Recommendation 3: RSOs should consider the value of certifying their resources through the RPKI, as a potential way to assure route origin authenticity in the future" I believe it is premature for the RSSAC to recommend that the RSOs consider the future use of RPKI. I think the RSSAC caucus itself should first consider if the RPKI is at a maturity level for use by root server operators in so much as evaluating the standards maturity, operational processes and resiliency of RPKI operators, diversity of RPKI repositories, and diversity of certification organisations in so far as having all resources of all root server operators vested with (currently) 3 RIR organisations. Thanks Terry
On 3 Feb 2018, at 4:06 am, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
All the best, Kaveh.
<27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Feb 5, 2018, at 5:29 PM, Terry Manderson <terry@terrym.net> wrote:
I have some concerns about "Recommendation 3: RSOs should consider the value of certifying their resources through the RPKI, as a potential way to assure route origin authenticity in the future"
I believe it is premature for the RSSAC to recommend that the RSOs consider the future use of RPKI. I think the RSSAC caucus itself should first consider if the RPKI is at a maturity level for use by root server operators in so much as evaluating the standards maturity, operational processes and resiliency of RPKI operators, diversity of RPKI repositories, and diversity of certification organisations in so far as having all resources of all root server operators vested with (currently) 3 RIR organisations.
I gather you're not a true believer :-) I would comment that there are two sides to RPKI deployment from the perspective of someone implementing it (and a third at the RIR). One is signing one's advertisements with a key registered with one's favorite RIR; the other is deciding whether or not to believe routes that are not signed, or are incorrectly signed. I would suggest that creating and registering a suitably-signed key (not self-signed; I would think it needs to be signed at least by the RIR it is registered with and by the organization that will be advertising it, and in a perfect world, I would hope it's also signed by each of the companies it is to be advertised to), and then signing advertisements as they are sent, is something every BGP-speaker can and should do today. RPKI makes no sense unless it is highly probable that a party can receive advertisements and verify them in fact receives them, which implies that they have been sent. Thinking in terms of a rant chart, if every completion point on the chart is gated by an initial event, moving this initial event moves the entire thing, and "it's not yet good enough" is a self-fulfilling prophecy. Over time, and this is not necessarily instant, the BGP speaker that is signing its advertisements needs to also be verifying the advertisements it receives. Again, "it's not yet good enough" will be a self-fulfilling prophecy if nobody is checking whether it's delivering the data needed. The final step is the introduction of a policy on the part of the individual organization that it will treat advertisements differently and perhaps ignore them depending on whether they are correctly signed. That, I would argue, is down the road a way. I might suggest a modified policy, however. This is more complex, but it may in the end be more manageable. I would suggest that each advertisement an organization receives is either not signed, signed but incorrectly (wrong key, invalid, or something), or correctly signed. When any BGP speaker starts advertising their signed route, I suspect that there will be fits and starts - it is signed, there is a fault, it is changed, la-de-da, and finally it stabilizes. A signed advertisement is only useful for policy once it has stabilized. So... I might suggest that there be a per-advertisement state machine. Advertisements have never been correctly signed, they are somewhere in the process of stabilizing, or they are stable. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and it is not correctly signed, I apply the same policy I do today. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and receive a correctly-signed advertisement (which includes accessing the PKI and verifying the signature), I move it to the second state (stabilizing) and continue to apply the policy I do today. In the second state, though, I note what the sender appears to do - they might come and go, change the key, fumble, or other things, and I note the timestamp and the event. At a point at which the provider has decided to trust RPKI for some subset of its routing AND the given advertisement has been consistently correctly signed for mumble time units, and <LOCAL POLICY> says to do so, the advertisement is moved to the third state - stable. When the advertisement has been deemed to be stable, I trust validly signed advertisements, both positive and negative, and I ignore anything else. What I might be interested to hear from the caucus is, first, whether they would recommend a similar approach, or whether they have a better idea, and second, whether the software that implements that it stable and usable. In the event of a "yes", I might expect a recommended game plan, which might be a link to a web page.
fred, i agree with every word you said, but not with your conclusion. terry, i disagree with every word you said, but not with your conclusion. if rootops sign their bgp announcements with rpki, then this would give a boost to the eventual possibility of bgp listeners rejecting unsigned or wrongsigned announcements that compete with ours. that's obvious. rpki isn't an obvious winner, with or without rootops participation. we should only adopt costs or complexities whose benefits are clearer than this one is. as an arin trustee for nine years, i drank and sold the rpki coolaid, out of inter-rir messaging and budgeting solidarity. now that i'm out, i see rpki as one of several possible timelines. paul re: Fred Baker wrote:
On Feb 5, 2018, at 5:29 PM, Terry Manderson<terry@terrym.net> wrote:
I have some concerns about "Recommendation 3: RSOs should consider the value of certifying their resources through the RPKI, as a potential way to assure route origin authenticity in the future"
I believe it is premature for the RSSAC to recommend that the RSOs consider the future use of RPKI. I think the RSSAC caucus itself should first consider if the RPKI is at a maturity level for use by root server operators in so much as evaluating the standards maturity, operational processes and resiliency of RPKI operators, diversity of RPKI repositories, and diversity of certification organisations in so far as having all resources of all root server operators vested with (currently) 3 RIR organisations.
I gather you're not a true believer :-)
I would comment that there are two sides to RPKI deployment from the perspective of someone implementing it (and a third at the RIR). One is signing one's advertisements with a key registered with one's favorite RIR; the other is deciding whether or not to believe routes that are not signed, or are incorrectly signed.
I would suggest that creating and registering a suitably-signed key (not self-signed; I would think it needs to be signed at least by the RIR it is registered with and by the organization that will be advertising it, and in a perfect world, I would hope it's also signed by each of the companies it is to be advertised to), and then signing advertisements as they are sent, is something every BGP-speaker can and should do today. RPKI makes no sense unless it is highly probable that a party can receive advertisements and verify them in fact receives them, which implies that they have been sent. Thinking in terms of a rant chart, if every completion point on the chart is gated by an initial event, moving this initial event moves the entire thing, and "it's not yet good enough" is a self-fulfilling prophecy.
Over time, and this is not necessarily instant, the BGP speaker that is signing its advertisements needs to also be verifying the advertisements it receives. Again, "it's not yet good enough" will be a self-fulfilling prophecy if nobody is checking whether it's delivering the data needed.
The final step is the introduction of a policy on the part of the individual organization that it will treat advertisements differently and perhaps ignore them depending on whether they are correctly signed. That, I would argue, is down the road a way.
I might suggest a modified policy, however. This is more complex, but it may in the end be more manageable. I would suggest that each advertisement an organization receives is either not signed, signed but incorrectly (wrong key, invalid, or something), or correctly signed. When any BGP speaker starts advertising their signed route, I suspect that there will be fits and starts - it is signed, there is a fault, it is changed, la-de-da, and finally it stabilizes. A signed advertisement is only useful for policy once it has stabilized. So...
I might suggest that there be a per-advertisement state machine. Advertisements have never been correctly signed, they are somewhere in the process of stabilizing, or they are stable. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and it is not correctly signed, I apply the same policy I do today. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and receive a correctly-signed advertisement (which includes accessing the PKI and verifying the signature), I move it to the second state (stabilizing) and continue to apply the policy I do today. In the second state, though, I note what the sender appears to do - they might come and go, change the key, fumble, or other things, and I note the timestamp and the event. At a point at which the provider has decided to trust RPKI for some subset of its routing AND the given advertisement has been consistently correctly signed for mumble time units, and<LOCAL POLICY> says to do so, the advertisement is moved to the third state - stable.
When the advertisement has been deemed to be stable, I trust validly signed advertisements, both positive and negative, and I ignore anything else.
What I might be interested to hear from the caucus is, first, whether they would recommend a similar approach, or whether they have a better idea, and second, whether the software that implements that it stable and usable. In the event of a "yes", I might expect a recommended game plan, which might be a link to a web page.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- P Vixie
The RPKI itself does not necessarily indicates signing BGP messages. The RPKI allows the holder of Internet Number Resources to make verifiable statements about those resources. For example the RSO can issue a Route Origination Authorization (ROA) [RFC6482] to authorize one or more ASes to originate routes for the prefix that contains the IP address of this root sever. The routing control system can use ROA for root to validate BGP announcement, like it uses IRR data, having nothing to do with signatures. While validation of the path of a route calls for BGPSEC (RFC 8205), which relies on the validation of router certificate that provided by the RPKI. Given the BGPSEC deployment and application is more complicated and might have a long to way to go overwhelming, I would suggest the RSOs work with RIR to publish their ROAs as they employ the RPKI “as a potential way to assure route origin authenticity in the future” . Di
在 2018年2月7日，08:09，Paul Vixie <paul@redbarn.org> 写道：
fred, i agree with every word you said, but not with your conclusion.
terry, i disagree with every word you said, but not with your conclusion.
if rootops sign their bgp announcements with rpki, then this would give a boost to the eventual possibility of bgp listeners rejecting unsigned or wrongsigned announcements that compete with ours. that's obvious.
rpki isn't an obvious winner, with or without rootops participation.
we should only adopt costs or complexities whose benefits are clearer than this one is. as an arin trustee for nine years, i drank and sold the rpki coolaid, out of inter-rir messaging and budgeting solidarity. now that i'm out, i see rpki as one of several possible timelines.
paul
re:
Fred Baker wrote:
On Feb 5, 2018, at 5:29 PM, Terry Manderson<terry@terrym.net> wrote:
I have some concerns about "Recommendation 3: RSOs should consider the value of certifying their resources through the RPKI, as a potential way to assure route origin authenticity in the future"
I believe it is premature for the RSSAC to recommend that the RSOs consider the future use of RPKI. I think the RSSAC caucus itself should first consider if the RPKI is at a maturity level for use by root server operators in so much as evaluating the standards maturity, operational processes and resiliency of RPKI operators, diversity of RPKI repositories, and diversity of certification organisations in so far as having all resources of all root server operators vested with (currently) 3 RIR organisations.
I gather you're not a true believer :-)
I would comment that there are two sides to RPKI deployment from the perspective of someone implementing it (and a third at the RIR). One is signing one's advertisements with a key registered with one's favorite RIR; the other is deciding whether or not to believe routes that are not signed, or are incorrectly signed.
I would suggest that creating and registering a suitably-signed key (not self-signed; I would think it needs to be signed at least by the RIR it is registered with and by the organization that will be advertising it, and in a perfect world, I would hope it's also signed by each of the companies it is to be advertised to), and then signing advertisements as they are sent, is something every BGP-speaker can and should do today. RPKI makes no sense unless it is highly probable that a party can receive advertisements and verify them in fact receives them, which implies that they have been sent. Thinking in terms of a rant chart, if every completion point on the chart is gated by an initial event, moving this initial event moves the entire thing, and "it's not yet good enough" is a self-fulfilling prophecy.
Over time, and this is not necessarily instant, the BGP speaker that is signing its advertisements needs to also be verifying the advertisements it receives. Again, "it's not yet good enough" will be a self-fulfilling prophecy if nobody is checking whether it's delivering the data needed.
The final step is the introduction of a policy on the part of the individual organization that it will treat advertisements differently and perhaps ignore them depending on whether they are correctly signed. That, I would argue, is down the road a way.
I might suggest a modified policy, however. This is more complex, but it may in the end be more manageable. I would suggest that each advertisement an organization receives is either not signed, signed but incorrectly (wrong key, invalid, or something), or correctly signed. When any BGP speaker starts advertising their signed route, I suspect that there will be fits and starts - it is signed, there is a fault, it is changed, la-de-da, and finally it stabilizes. A signed advertisement is only useful for policy once it has stabilized. So...
I might suggest that there be a per-advertisement state machine. Advertisements have never been correctly signed, they are somewhere in the process of stabilizing, or they are stable. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and it is not correctly signed, I apply the same policy I do today. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and receive a correctly-signed advertisement (which includes accessing the PKI and verifying the signature), I move it to the second state (stabilizing) and continue to apply the policy I do today. In the second state, though, I note what the sender appears to do - they might come and go, change the key, fumble, or other things, and I note the timestamp and the event. At a point at which the provider has decided to trust RPKI for some subset of its routing AND the given advertisement has been consistently correctly signed for mumble time units, and<LOCAL POLICY> says to do so, the advertisement is moved to the third state - stable.
When the advertisement has been deemed to be stable, I trust validly signed advertisements, both positive and negative, and I ignore anything else.
What I might be interested to hear from the caucus is, first, whether they would recommend a similar approach, or whether they have a better idea, and second, whether the software that implements that it stable and usable. In the event of a "yes", I might expect a recommended game plan, which might be a link to a web page.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- P Vixie
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Di Ma wrote:
The RPKI itself does not necessarily indicates signing BGP messages.
...
Given the BGPSEC deployment and application is more complicated and might have a long to way to go overwhelming, I would suggest the RSOs work with RIR to publish their ROAs as they employ the RPKI “as a potential way to assure route origin authenticity in the future” .
all rpki use today is prospective. it relies on people publishing ROAs even knowing that there's no benefit (nobody is rejecting unsigned routes or even preferring signed over unsigned paths) and some cost (as people begin to actually verify, both the verification and the signing will at first be fragile and error-prone). i am likely to participate in this prospective rpki activity, personally, because as with ipv6 and dnssec, there is a significant last-mover advantage, which means somebody has to go first when it still makes no sense, and that's what i always do. i do not however agree that the RSO's ought to participate in this road-paving exercise. they should sign when it makes actual sense on that day for them to sign -- not to enable some idealized future. -- P Vixie
Dear RSSAC Caucus, The review period for this document ended on February 16th. I have edited the document based on the comments provided on list and a high-level changelog is below. - Changed table 2 to remove all references to root letters - Added sentence in section 3, paragraph 4 - Added sentence to end of section 4 - Reordered text in section 6.1 - Removed recommendation 3 on RPKI - Added Paul Muchene to Ackowledgements section Final CLEAN and REDLINE versions of the document are attached to this mail and will be archived here on this list. If the RSSAC Caucus decides to take up this subject again this document will be available. The RSSAC Caucus Work Party on Best Practices for the Distribution of Anycast Instances of the Root Name Service will now be closed. Thanks again to all the work party members and other RSSAC Caucus members that provided feedback. —Andrew
On Feb 2, 2018, at 19:06, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
All the best, Kaveh.
<27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Andrew, Thanks for updating the document to incorporate the various comments and for providing the new version. I do believe that removing recommendation 3 on RPKI does not reflect a consensus of the discussion both recently and earlier on the mail list. As I read the various posting to the list, arguments were made both for and against make use of RPKI and a very small number of posts about whether or not the RSSAC should recommend that RSO’s should _consider_ the use of RPKI. I would like to ask that you review both the recent and earlier posts related to the RPKI recommendation. My interpretation of the consensus of the previous and recent mail list discussion is that some people supported RSO's using RPKI, some people opposed RSO’s using RPKI, and a number of people supported that each RSO should individually consider use of RPKI as a satisfactory compromise as well as being consistent with the concept independent RSO making their own operational decisions. It was only in the recent comment period when one or two comments were made to delete the RPKI recommendation and I thought that others had responded saying leave it so I thought the recommendation was going to stay in or, at most, be reworded in some manner. Regards, Russ
On Feb 21, 2018, at 11:08 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
The review period for this document ended on February 16th. I have edited the document based on the comments provided on list and a high-level changelog is below.
- Changed table 2 to remove all references to root letters - Added sentence in section 3, paragraph 4 - Added sentence to end of section 4 - Reordered text in section 6.1 - Removed recommendation 3 on RPKI - Added Paul Muchene to Ackowledgements section
Final CLEAN and REDLINE versions of the document are attached to this mail and will be archived here on this list. If the RSSAC Caucus decides to take up this subject again this document will be available.
The RSSAC Caucus Work Party on Best Practices for the Distribution of Anycast Instances of the Root Name Service will now be closed. Thanks again to all the work party members and other RSSAC Caucus members that provided feedback.
—Andrew
On Feb 2, 2018, at 19:06, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
All the best, Kaveh.
<27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
<21FebruaryAnycastDocument-CLEAN.pdf><21FebruaryAnycastDocument-CLEAN.docx><21FebruaryAnycastDocument-REDLINE.docx>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
I would be happy with either rewording the recommendation to have the caucus (via a work party) assess RPKI on various dimensions (and perhaps identifying alternatives) OR removing the recommendation. As stated, I am simply not comfortable with the current wording. Cheers Terry
On 23 Feb 2018, at 8:42 am, Russ Mundy <mundy@tislabs.com> wrote:
Andrew,
Thanks for updating the document to incorporate the various comments and for providing the new version.
I do believe that removing recommendation 3 on RPKI does not reflect a consensus of the discussion both recently and earlier on the mail list. As I read the various posting to the list, arguments were made both for and against make use of RPKI and a very small number of posts about whether or not the RSSAC should recommend that RSO’s should _consider_ the use of RPKI.
I would like to ask that you review both the recent and earlier posts related to the RPKI recommendation. My interpretation of the consensus of the previous and recent mail list discussion is that some people supported RSO's using RPKI, some people opposed RSO’s using RPKI, and a number of people supported that each RSO should individually consider use of RPKI as a satisfactory compromise as well as being consistent with the concept independent RSO making their own operational decisions. It was only in the recent comment period when one or two comments were made to delete the RPKI recommendation and I thought that others had responded saying leave it so I thought the recommendation was going to stay in or, at most, be reworded in some manner.
Regards, Russ
On Feb 21, 2018, at 11:08 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
The review period for this document ended on February 16th. I have edited the document based on the comments provided on list and a high-level changelog is below.
- Changed table 2 to remove all references to root letters - Added sentence in section 3, paragraph 4 - Added sentence to end of section 4 - Reordered text in section 6.1 - Removed recommendation 3 on RPKI - Added Paul Muchene to Ackowledgements section
Final CLEAN and REDLINE versions of the document are attached to this mail and will be archived here on this list. If the RSSAC Caucus decides to take up this subject again this document will be available.
The RSSAC Caucus Work Party on Best Practices for the Distribution of Anycast Instances of the Root Name Service will now be closed. Thanks again to all the work party members and other RSSAC Caucus members that provided feedback.
—Andrew
On Feb 2, 2018, at 19:06, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
All the best, Kaveh.
<27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
<21FebruaryAnycastDocument-CLEAN.pdf><21FebruaryAnycastDocument-CLEAN.docx><21FebruaryAnycastDocument-REDLINE.docx>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Thanks Russ and Terry for the comments. I likely misread the consensus on list regarding recommendation 3. One thing I noticed when deleting it was that there are no other references to RPKI anywhere else in the document. There is no associated discussion of RPKI in the document to serve as background for the recommendation. Given that, and taking into account the discussions on the Caucus list as well as discussions in the work party. What do members think about using the following text as a new recommendation 3? "The RSSAC Caucus should investigate and assess the value of the Resource Public Key Infrastructure (RPKI) as a possible framework for validating the route advertisements of RSOs." Please indicate on list if the above rewording is satisfactory or propose new text. Especially if you previously sent mail to the list on this topic. Please respond by March 2nd, and please keep in mind that this will not become a publication and as such does not represent consensus opinion of the RSSAC or RSSAC Caucus. It will merely be used a starting point if/when this topic is ever explored again. Thanks, Andrew
On Feb 23, 2018, at 01:06, Terry Manderson <terry@terrym.net> wrote:
I would be happy with either rewording the recommendation to have the caucus (via a work party) assess RPKI on various dimensions (and perhaps identifying alternatives) OR removing the recommendation.
As stated, I am simply not comfortable with the current wording.
Cheers Terry
On 23 Feb 2018, at 8:42 am, Russ Mundy <mundy@tislabs.com> wrote:
Andrew,
Thanks for updating the document to incorporate the various comments and for providing the new version.
I do believe that removing recommendation 3 on RPKI does not reflect a consensus of the discussion both recently and earlier on the mail list. As I read the various posting to the list, arguments were made both for and against make use of RPKI and a very small number of posts about whether or not the RSSAC should recommend that RSO’s should _consider_ the use of RPKI.
I would like to ask that you review both the recent and earlier posts related to the RPKI recommendation. My interpretation of the consensus of the previous and recent mail list discussion is that some people supported RSO's using RPKI, some people opposed RSO’s using RPKI, and a number of people supported that each RSO should individually consider use of RPKI as a satisfactory compromise as well as being consistent with the concept independent RSO making their own operational decisions. It was only in the recent comment period when one or two comments were made to delete the RPKI recommendation and I thought that others had responded saying leave it so I thought the recommendation was going to stay in or, at most, be reworded in some manner.
Regards, Russ
On Feb 21, 2018, at 11:08 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
The review period for this document ended on February 16th. I have edited the document based on the comments provided on list and a high-level changelog is below.
- Changed table 2 to remove all references to root letters - Added sentence in section 3, paragraph 4 - Added sentence to end of section 4 - Reordered text in section 6.1 - Removed recommendation 3 on RPKI - Added Paul Muchene to Ackowledgements section
Final CLEAN and REDLINE versions of the document are attached to this mail and will be archived here on this list. If the RSSAC Caucus decides to take up this subject again this document will be available.
The RSSAC Caucus Work Party on Best Practices for the Distribution of Anycast Instances of the Root Name Service will now be closed. Thanks again to all the work party members and other RSSAC Caucus members that provided feedback.
—Andrew
On Feb 2, 2018, at 19:06, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
All the best, Kaveh.
<27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
<21FebruaryAnycastDocument-CLEAN.pdf><21FebruaryAnycastDocument-CLEAN.docx><21FebruaryAnycastDocument-REDLINE.docx>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Hi Andrew, I would be fine with this version of the RPKI recommendation in the report. Russ
On Feb 23, 2018, at 5:37 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Thanks Russ and Terry for the comments. I likely misread the consensus on list regarding recommendation 3.
One thing I noticed when deleting it was that there are no other references to RPKI anywhere else in the document. There is no associated discussion of RPKI in the document to serve as background for the recommendation. Given that, and taking into account the discussions on the Caucus list as well as discussions in the work party. What do members think about using the following text as a new recommendation 3?
"The RSSAC Caucus should investigate and assess the value of the Resource Public Key Infrastructure (RPKI) as a possible framework for validating the route advertisements of RSOs."
Please indicate on list if the above rewording is satisfactory or propose new text. Especially if you previously sent mail to the list on this topic.
Please respond by March 2nd, and please keep in mind that this will not become a publication and as such does not represent consensus opinion of the RSSAC or RSSAC Caucus. It will merely be used a starting point if/when this topic is ever explored again.
Thanks, Andrew
On Feb 23, 2018, at 01:06, Terry Manderson <terry@terrym.net> wrote:
I would be happy with either rewording the recommendation to have the caucus (via a work party) assess RPKI on various dimensions (and perhaps identifying alternatives) OR removing the recommendation.
As stated, I am simply not comfortable with the current wording.
Cheers Terry
On 23 Feb 2018, at 8:42 am, Russ Mundy <mundy@tislabs.com> wrote:
Andrew,
Thanks for updating the document to incorporate the various comments and for providing the new version.
I do believe that removing recommendation 3 on RPKI does not reflect a consensus of the discussion both recently and earlier on the mail list. As I read the various posting to the list, arguments were made both for and against make use of RPKI and a very small number of posts about whether or not the RSSAC should recommend that RSO’s should _consider_ the use of RPKI.
I would like to ask that you review both the recent and earlier posts related to the RPKI recommendation. My interpretation of the consensus of the previous and recent mail list discussion is that some people supported RSO's using RPKI, some people opposed RSO’s using RPKI, and a number of people supported that each RSO should individually consider use of RPKI as a satisfactory compromise as well as being consistent with the concept independent RSO making their own operational decisions. It was only in the recent comment period when one or two comments were made to delete the RPKI recommendation and I thought that others had responded saying leave it so I thought the recommendation was going to stay in or, at most, be reworded in some manner.
Regards, Russ
On Feb 21, 2018, at 11:08 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
The review period for this document ended on February 16th. I have edited the document based on the comments provided on list and a high-level changelog is below.
- Changed table 2 to remove all references to root letters - Added sentence in section 3, paragraph 4 - Added sentence to end of section 4 - Reordered text in section 6.1 - Removed recommendation 3 on RPKI - Added Paul Muchene to Ackowledgements section
Final CLEAN and REDLINE versions of the document are attached to this mail and will be archived here on this list. If the RSSAC Caucus decides to take up this subject again this document will be available.
The RSSAC Caucus Work Party on Best Practices for the Distribution of Anycast Instances of the Root Name Service will now be closed. Thanks again to all the work party members and other RSSAC Caucus members that provided feedback.
—Andrew
On Feb 2, 2018, at 19:06, kranjbar <kranjbar@ripe.net> wrote:
Dear RSSAC Caucus,
Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results.
Please let me know if you have any suggestions or questions.
All the best, Kaveh.
<27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
<21FebruaryAnycastDocument-CLEAN.pdf><21FebruaryAnycastDocument-CLEAN.docx><21FebruaryAnycastDocument-REDLINE.docx>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Dear RSSAC Caucus, The review period for the proposed text for recommendation 3 closed March 2nd. Hearing no objections to the new text, please find the final CLEAN and REDLINE versions of this document attached. The only change was to add the new text for recommendation 3. Thanks, Andrew On Feb 21, 2018, at 17:08, Andrew Mcconachie <andrew.mcconachie@icann.org<mailto:andrew.mcconachie@icann.org>> wrote: Dear RSSAC Caucus, The review period for this document ended on February 16th. I have edited the document based on the comments provided on list and a high-level changelog is below. - Changed table 2 to remove all references to root letters - Added sentence in section 3, paragraph 4 - Added sentence to end of section 4 - Reordered text in section 6.1 - Removed recommendation 3 on RPKI - Added Paul Muchene to Ackowledgements section Final CLEAN and REDLINE versions of the document are attached to this mail and will be archived here on this list. If the RSSAC Caucus decides to take up this subject again this document will be available. The RSSAC Caucus Work Party on Best Practices for the Distribution of Anycast Instances of the Root Name Service will now be closed. Thanks again to all the work party members and other RSSAC Caucus members that provided feedback. —Andrew On Feb 2, 2018, at 19:06, kranjbar <kranjbar@ripe.net<mailto:kranjbar@ripe.net>> wrote: Dear RSSAC Caucus, Please find attached outcome document of ‘Best Practices for the Distribution of Anycast Instances of the Root Name Service’ work party. As it was mentioned in the caucus updates, the work party did not conclude with finishing all of it’s tasks but had many deep discussions about the questions raised in the work plan. This document summarises all of those discussions and conclusions and, at any point in time, if RSSAC or RSSAC Caucus feels one of the questions should be explored in more detail, we always have the option of booting up a new work party around that single issue and achieve more fine grained results. Please let me know if you have any suggestions or questions. All the best, Kaveh. <27 November anycast document.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus <21FebruaryAnycastDocument-CLEAN.pdf><21FebruaryAnycastDocument-CLEAN.docx><21FebruaryAnycastDocument-REDLINE.docx>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
On Mon 2018-03-05 13:53:37+0000 Andrew wrote:
The review period for the proposed text for recommendation 3 closed March 2nd. Hearing no objections to the new text, please find the final CLEAN and REDLINE versions of this document attached. The only change was to add the new text for recommendation 3.
Should the 'final' version still have the DRAFT watermark? The 'comment' at the beginning of 7.2 references 2.2.2 and 2.2.3, but neither exist. I think the correct references would be 7.2 and 7.3. -- Robert Story <http://www.isi.edu/~rstory> USC Information Sciences Institute <http://www.isi.edu/>
On Mar 13, 2018, at 12:13, Robert Story <rstory@isi.edu> wrote:
On Mon 2018-03-05 13:53:37+0000 Andrew wrote:
The review period for the proposed text for recommendation 3 closed March 2nd. Hearing no objections to the new text, please find the final CLEAN and REDLINE versions of this document attached. The only change was to add the new text for recommendation 3.
Should the 'final' version still have the DRAFT watermark?
The 'comment' at the beginning of 7.2 references 2.2.2 and 2.2.3, but neither exist. I think the correct references would be 7.2 and 7.3.
Hi Robert, Apologies for the late response, catching up on mail after ICANN 61. This document is only ‘final’ in the sense that work on it has been halted. The comment period has closed, so the version that was sent to the list on March 5th will remain the final archived version. I left the DRAFT watermark in to make it clear that this is not a publication. Thanks, Andrew
participants (10)
-
Andrew Mcconachie -
Di Ma -
Fred Baker -
kranjbar -
Paul Vixie -
Robert MARTIN-LEGENE -
Robert Story -
Russ Mundy -
Terry Manderson -
Wessels, Duane