Hi Arturo,
On 23/08/11 9:56 PM, "Arturo Servin" <[email protected]> wrote: > Terry, > > My basic comment is that this is not a bad idea, in fact is good for > the IANA IPv4 Special Purpose Address Registry. But for the IANA registries > for v4 and v6 even though there is benefit, the matter of modify them is IMHO > complex in nature. I just don't see the complexity. Its an extra column that specifies the routing intent[1], and gives a clear signal if anything should change, for example the 'future use' blocks or 6to4 (without rehashing that escapade). [1] I'll iterate, this says that the prefix is intended to be routable. It doesn't say that it must be routable, or makes any guarantees. But gives a strong explicit indication of what is already implied. > > See some other comments in line. > > > No, but then IANA registry only holds /8s and almost all of them are > routable. The ones that are not routable are described in other RFCs (i.e. > 1918). So, the information is not there but we already know it. Actually no, the IANA is the registry for /0. It points to who administers the allocations irrespective of prefix length. > >> Just as 169.254.0.0/16 is intended as Not Routable. Do you disagree with >> that? > > No, but you cannot tag this one in IANA IPv4 Address Space Registry. Why not? it was reserved by IETF action in an IANA considerations section. yes? >> >> I disagree, I see advantage in that it adds a completely unambiguous >> statement of what is routable and what is not. Surely that is helpful for >> those people beating their heads against organisations who are still >> filtering 1/8, 14/8 etc.. > > There is and advantage, I won't deny it. But I think that it is too > much effort and too little real benefit. too much effort? That is an interesting point of view. > > If people continues to filter 1/8 with all the fuss about IPv4, > darknet and so on that we have made, I really doubt that adding a field in > IANA registry is going to change that. Just a few weeks ago I pointed out both no-more-slash-8s and routing-intent to an australian operator who was having a painful time with an allocation in filtering. He used both of them as arguments to one organisation doing the filtering and got positive movement. I am in the boat that every little bit helps. > > >> >>> >>> "The IANA address registries currently do not have a uniform and >>> consistent nomenclature to signal if an allocation is intended to be >>> publicly routed" >>> >>> Because they are mainly /8 (v4) and /12 (v6) assigned to RIRs, there >>> is no need for any signal or it is irrelevant. >> >> I disagree. Signaling the routing intent also provides a perfect reflection >> on what should be seen in RPKI through the manifestation of RPKI objects. >> see draft-ietf-rpki-iana-objects. > > Yes, but only for the IANA IPv4 Special Purpose Address Registry. For > the rest, what is the benefit vs effort to explicitly state that a specific > /12 is routable if we already know that? because it makes it obvious. It helps people that are not fully and 100% glued to the registry(ies) published data. It allows people to 'double check' what gets published as RPKI objects conforms to the obvious expectation. This builds trust. >> >> This is a registry - it records the routing intent of a prefix. >> Are you saying that IANA does not have the mechanisms to follow what the >> IETF tells it to do? > > Besides /8 (v4) and /12 (v6) and the small pieces of IETF reserved > space IANA does not have explicit data to say that a prefix is routable or It certainly has enough information in RFCs to say that a prefix is _intended_ to be routable. yes? > not. Even for the /8s and /12s (and some /23s I think) I am not sure that IANA > can unilaterally tag a resource already assigned to the RIRs, in either case > is the IETF and IAB who should do it and may be grow is not the place. So are you suggesting that when a prefix is allocated IANA can no longer add information about that allocation? That seems wrong to me. And IANA isn't unilaterally doing anything. It is being told what to do by the IETF process. >> >> Sorry, you have me confused. What policy field does this enter? Please be >> specific. Because I'm not seeing it. > > ASO Global policies. They deal in how assigned space to RIR is managed > in a global scope, they also instructs IANA how to allocate space to them. Why > tagging the allocated space as routed should be out (or in) of global > policies? (rhetorical question) Um.. I'm not an ASO policy expert (and nor should I be) as routing-intent doesn't affect how the allocations are made to the RIRs. It doesn't change any of it (based on my quick read). If it does, please point out the paragraphs and the policies where it does. > > You are intended to modify space assigned to RIRs (some of them), some By saying that the space that is allocated to them is intended to be routable (minus any segments that are reserved by IETF direction)?? I'm strugglng to see how that is 'modified'.. If I were to say turn the status of 203/8 from 'allocated' to 'reserved' then I would be with you as that is grossly inappropriate. > may argue (not me now) that this should be dealt as a global policy coming > from the RIRs. Other may say that is IETF matter in grow, some other IAB. > Honestly I am not sure which one is the rightful owner to decide what to do. > But I think that this could easy turn complex and the benefit is so little > that it is not worth of the discussion. Interesting perspective :-) Cheers Terry _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
