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 f

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 ar

Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

On Jul 16, 2015, at 9:56 AM, Stephen Kent mailto: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?

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

Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

On Jul 15, 2015, at 4:41 PM, Stephen Kent 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 trea

Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

Sandy, On Jul 7, 2015, at 11:41 AM, Stephen Kent 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,

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 becau

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 affilia

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

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

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

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 sid

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 an

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

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 I

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 pr

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 > wrote: I think it would be interesting to hear from the RIR's as to w

Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

On Jul 8, 2015, at 1:30 PM, Sandra Murphy 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 s

Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

On Jul 7, 2015, at 11:41 AM, Stephen Kent 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 >> operat

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, wit

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 d

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 t

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

[sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

A new version of I-D, draft-ymbk-sidr-transfer-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-sidr-transfer Revision: 00 Title: Resource Transfer in the Resource Public Key Infrastructure Document date: 2015-05-30