Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Andy, ... Steve, Given what I said initially in this thread, I thought we were talking about the same thing. I guess not. We could tease this apart, but is it worth it if “Randy’s view” covers all situations? -andy Randy's approach covers both cases, at the cost of some added complexity for what I suspect is the most common case. Whether that's preferable to two similar, but slightly different mechanisms, where one is optimized for the (purported) most common case is a matter of engineering taste. The WG will have to decide at some point, when we have complete, detailed proposals for both. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Andy, The context for the discussion is address space transfer in the RPKI context. We don't have an RFC describing how to do that, AFAIK. So, when you say that this is the scenario we have today, to what are you referring? Steve On Jul 15, 2015, at 4:41 PM, Stephen Kent k...@bbn.com mailto:k...@bbn.com wrote: Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished? -andy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
On Jul 16, 2015, at 9:56 AM, Stephen Kent k...@bbn.commailto:k...@bbn.com wrote: Andy, The context for the discussion is address space transfer in the RPKI context. We don't have an RFC describing how to do that, AFAIK. So, when you say that this is the scenario we have today, to what are you referring? Steve On Jul 15, 2015, at 4:41 PM, Stephen Kent mailto:k...@bbn.comk...@bbn.commailto:k...@bbn.com wrote: Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished? -andy Steve, Given what I said initially in this thread, I thought we were talking about the same thing. I guess not. We could tease this apart, but is it worth it if “Randy’s view” covers all situations? -andy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
On Jul 15, 2015, at 4:41 PM, Stephen Kent k...@bbn.commailto:k...@bbn.com wrote: Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished? -andy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. thank you for putting words in my mouth, especially as they are the correct words :) Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished? in steve's model, one has to implement both. job security for engineers :) randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Sandy, On Jul 7, 2015, at 11:41 AM, Stephen Kent k...@bbn.com wrote: - I think the doc should distinguish between transfers of live address space vs. transfers of space that is not currently in use. The former are more complex tan the latter and thus merit a different discussion operationally, you do not have a solid proof of [dis-]use. and i do not see how they should be treated differently. prudence says do it as if it is live. The TAO I-D describes the differences in constraints imposed on the transfer process based on live vs. unused space. Unused is much, much easier and seems to be the most common type of space transferred across RIR boundaries. Thus it seems worth considering the distinction in a discussion of the problem. I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for MA, and for historical resources. Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space. MA are likely to be live and historical could be live, I suppose. It's interesting that they make these distinctions, presumably for policy purposes. i don't find anything in their policy manual that says transfers are only for unused space. I did not suggested that. What I said was that it seems likely that the growing number of address space transfers will be for unused space, IF the reason for the transfer is a sale of assets. (This seems to be the rationale cited for the growth in v4 address space transfers.) And, I noted that it seems attractive to engineer a solution to for unused space transfers IF the solution is simpler than for live space transfers (it is), and IF unused space transfers are the common case. Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Randy, What I meant to imply is that: - because the entity transferring the space knows whether it is is use - and because asserting that it isn't, when it is, will adversely affect users affiliated with that entity - therefore the entity in question is motivated to get it right - but, in the worst case, the damage is limited to users who could be screwed my the same entity due to other careless/erroneous behavior Steve In the TAO proposal the entity relinquishing the address space is presumed to know, and to declare the transfer accordingly. That seems to be the simplest approach, and if that entity screws up, its users are impacted. and this is the ietf, so who gives a damn about the users? right. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
So, your argument is that because a mis-declaration of space as unused vs. can by an ISP cause harm, we should engineer a transfer model that imposes additional complexity on what seems likely to be the most common case. (I assume transfer of unused space is or will be the most common case because it represents the space that is sold and we've been told that RIRs expect a big increase in transfers due to sales of v4 space.) I acknowledge the merits of your argument, but I also like to engineer solutions that optimize for the common case. Steve - because the entity transferring the space knows whether it is is use as the operators and rirs here keep trying to tell you, this is not a safe assumption. unlike you, some of us make mistakes. - and because asserting that it isn't, when it is, will adversely affect users affiliated with that entity - therefore the entity in question is motivated to get it right - but, in the worst case, the damage is limited to users who could be screwed my the same entity due to other careless/erroneous behavior there are potholes in the road. this does not mean it is ok to dig more of them. in fact, we are trying to reduce them. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
- because the entity transferring the space knows whether it is is use as the operators and rirs here keep trying to tell you, this is not a safe assumption. unlike you, some of us make mistakes. - and because asserting that it isn't, when it is, will adversely affect users affiliated with that entity - therefore the entity in question is motivated to get it right - but, in the worst case, the damage is limited to users who could be screwed my the same entity due to other careless/erroneous behavior there are potholes in the road. this does not mean it is ok to dig more of them. in fact, we are trying to reduce them. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
In the TAO proposal the entity relinquishing the address space is presumed to know, and to declare the transfer accordingly. That seems to be the simplest approach, and if that entity screws up, its users are impacted. and this is the ietf, so who gives a damn about the users? right. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
I disagree. In this context the entity relinquishing the address space should know whether the space is in use or not. We ought to be able to take advantage of this knowledge to simplify the transfer process, when applicable. Steve On 7/10/15 5:14 PM, Randy Bush wrote: making assumptions if and how address space is or is not used is a recipe for mistakes and is not really useful. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Carlos, As Arturo mentions, defining 'actual use' of number resources has proved quite tricky. to an outsider maybe, but the entity initiating the transfer presumably knows, right? There's not need to infer this status from externally observable info. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
In the TAO proposal the entity relinquishing the address space is presumed to know, and to declare the transfer accordingly. That seems to be the simplest approach, and if that entity screws up, its users are impacted. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
yup. we have a long history of trying to assign colors, flavors, sounds, ... to integers. it has never worked out very well. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
How would you define that address space is unused? Because it is unannounced to the global BGP table? Because there is not traffic to it even though is announced? This question has come up in several policy discussion in almost every RIR, it has never been consensus on the answer. So we should probably considered every transfer as been in use. The draft is a good start, thanks for writing it. As soon as I have some time I will send some comments. /as On Fri, 10 Jul 2015 at 18:15 Randy Bush ra...@psg.com wrote: making assumptions if and how address space is or is not used is a recipe for mistakes and is not really useful. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
As Arturo mentions, defining 'actual use' of number resources has proved quite tricky. The only workable assumption is that space that is marked 'available' or 'reserved' in the delegated-extended files is not in use whereas everything else is in use, regardless of whether it is announced in the Internet or not. Even this assumption could lead to unexpected situations here and there as there could be space being recovered that is still routed in bgp while being marked as reserved, not mentioning possible ongoing route hijacks of 'available' space still getting traffic. cheers! -Carlos On 7/11/15 7:18 PM, Arturo Servin wrote: How would you define that address space is unused? Because it is unannounced to the global BGP table? Because there is not traffic to it even though is announced? This question has come up in several policy discussion in almost every RIR, it has never been consensus on the answer. So we should probably considered every transfer as been in use. The draft is a good start, thanks for writing it. As soon as I have some time I will send some comments. /as On Fri, 10 Jul 2015 at 18:15 Randy Bush ra...@psg.com mailto:ra...@psg.com wrote: making assumptions if and how address space is or is not used is a recipe for mistakes and is not really useful. randy ___ sidr mailing list sidr@ietf.org mailto:sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
making assumptions if and how address space is or is not used is a recipe for mistakes and is not really useful. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Andy, In this context live refers to address space in use as opposed to allocated but not in use. So your reply doesn't address the question. Steve On Jul 8, 2015, at 1:30 PM, Sandra Murphy sa...@tislabs.com mailto:sa...@tislabs.com wrote: I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible. The reality is that we rarely get transfers of RPKI certified space, but to answer your question: we don’t deny or delay a transfer just because it is RPKI live. -andy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
On Jul 8, 2015, at 1:30 PM, Sandra Murphy sa...@tislabs.commailto:sa...@tislabs.com wrote: I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible. The reality is that we rarely get transfers of RPKI certified space, but to answer your question: we don’t deny or delay a transfer just because it is RPKI live. -andy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
On Jul 7, 2015, at 11:41 AM, Stephen Kent k...@bbn.com wrote: - I think the doc should distinguish between transfers of live address space vs. transfers of space that is not currently in use. The former are more complex tan the latter and thus merit a different discussion operationally, you do not have a solid proof of [dis-]use. and i do not see how they should be treated differently. prudence says do it as if it is live. The TAO I-D describes the differences in constraints imposed on the transfer process based on live vs. unused space. Unused is much, much easier and seems to be the most common type of space transferred across RIR boundaries. Thus it seems worth considering the distinction in a discussion of the problem. I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for MA, and for historical resources. Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space. MA are likely to be live and historical could be live, I suppose. i don't find anything in their policy manual that says transfers are only for unused space. Here's the page about transfer in general: https://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible. That of course does not mean that transfers only occur between RIRs, or that we can always know whether address space is in use. --Sandy, speaking as a regular ol' member P.S. From the APNIC site, here are some interesting flowcharts of the process: Transfer of unused IPv4 and AS Numbers APNIC account holders (flowchart): https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure%20of%20unused%20IPv4%20and%20AS%20Numbers%20between%20APNIC%20accounts.pdf Transfer procedure of unused IPv4 from ARIN to APNIC accounts (flowchart): https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure%20of%20unused%20IPv4%20from%20ARIN%20to%20APNIC%20accounts.pdf detailed diagram for IPv4 transfer from other RIR to APNIC accounts: https://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources/ARIN-to-APNIC-IPv4-Transfer-with-Fees.jpg signature.asc Description: Message signed with OpenPGP using GPGMail ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Randy, really do appreciate review. you're welcome. do not appreciate pdfs of word docs; makes copy paste and commenting back a major pain. though i have come to suspect that is one of your goals. so i will not comment on your comments in that pdf, though i adopted/adapted the majority, with which i agreed. I review docs in MS Word, because it makes it easy for me to correct typos and to precisely identify where comments apply. Because you reject Word docs, the best accommodation I can offer, given my unwillingness to adopt a different review mechanism, is to generate a PDF of the Word doc. I have no trouble copying and pasting text from a PDF, so I don't understand your comment about the difficulty of copy/paste. I do admit that responding, inline, to comments inn the PDF format is not easy. It would work fine if you accepted the Word doc, but ... - I don't consider myself to be on the hook for a torn Euro protocol back in 2007, you really did say you would do it. but this year it the kook kids would use a blockchain contract; that'll be a fun section to write :) yes, 8 years ago I said that I (the royal I?) could do this. Time passed and I advised you a couple of years ago that it was not going to happen. I relayed this news based on advice from Matt Lepinski, who is much more knowledgeable on these crypto protocols than I. His conclusion was that the papers published on this sort of mechanism did not yet yield mature, practical, implementable protocols. - I think the doc should distinguish between transfers of live address space vs. transfers of space that is not currently in use. The former are more complex tan the latter and thus merit a different discussion operationally, you do not have a solid proof of [dis-]use. and i do not see how they should be treated differently. prudence says do it as if it is live. The TAO I-D describes the differences in constraints imposed on the transfer process based on live vs. unused space. Unused is much, much easier and seems to be the most common type of space transferred across RIR boundaries. Thus it seems worth considering the distinction in a discussion of the problem. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Three observations: - the briefing you cited was a high level discussion that did not make a strong case for the validation revisited I-D. - I submitted comments on the list about Randy's transfer I-D. - draft-kent-sidr-adverse-actions-00 documents a range of potential problems that can arise in the RPKI. The analysis argues for a broader solution that would encompass the overclaiming problem. Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
really do appreciate review. do not appreciate pdfs of word docs; makes copy paste and commenting back a major pain. though i have come to suspect that is one of your goals. so i will not comment on your comments in that pdf, though i adopted/adapted the majority, with which i agreed. - I don't consider myself to be on the hook for a torn Euro protocol back in 2007, you really did say you would do it. but this year it the kook kids would use a blockchain contract; that'll be a fun section to write :) - I think the doc should distinguish between transfers of live address space vs. transfers of space that is not currently in use. The former are more complex tan the latter and thus merit a different discussion operationally, you do not have a solid proof of [dis-]use. and i do not see how they should be treated differently. prudence says do it as if it is live. - the text does not yet adequately describe the steps that need to take place when the Buyer or Seller are not directly under a Swing Point. sent text - the TAO doc described a procedure for resource transfer that avoids the concern you cited in Section 5. good. when we get to that doc, we can then deal i did not finish until after the dreadline. so all will be revealed in two weeks. for a small fee, early peeks might be available. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
In November last year, a more detailed description of transfer was suggested as a means to move ahead with the validation-reconsidered discussion. This draft is such a more detailed description. (http://tools.ietf.org/agenda/91/slides/slides-91-sidr-0.pdf is you can't remember that far back.) But there have been very few comments on this draft. The hope is that this will give the wg the grounds for an informed opinion on the need to alter the RPKI validation process along the lines of the 'validation reconsidered' draft, to quote the presentation. Please, please, please. Start discussion now. Is this accurate from the standpoint of transfer activities? from the standpoint of RPKI actions? And the further question - does this help you to understand the validation reconsidered algorithm? --Sandy, speaking as wg co-chair On Jun 1, 2015, at 8:16 PM, Randy Bush ra...@psg.com wrote: Title: Resource Transfer in the Resource Public Key Infrastructure this is a very rough first draft. all folk who agreed to author have not even reviewed. i published partly to get them to wake up and tell me how broken my understanding is. randy signature.asc Description: Message signed with OpenPGP using GPGMail ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
