Pedro,
Not sure how the format was defined years ago, may be somebody in the
list could answer this.
However there is a new format that APNIC and RIPE NCC are using:
http://labs.ripe.net/Members/mirjam/new-ripe-ncc-address-statistics-reports
ftp://ftp.apnic.net/public/stats/apnic/README-EXTENDED.TXT
In LACNIC we are planning to adopt a compatible format too.
Regarding an informational RFC about this format, I'll ask around.
Now, same as my comments regarding IANA, I am not sure if RIRs have
explicit information about the routability of a prefix to include them in the
stats file, otherwise they would be IRRs and not RIRs.
Regards,
-as
On 23 Aug 2011, at 10:29, Pedro Torres wrote:
> Arturo,
>
> Who did define the RIR Statistics Exchange Format?
> ftp://ftp.lacnic.net/pub/stats/lacnic/RIR-Statistics-Exchange-Format.txt
>
> Could it not be a IETF work? I think a RFC could be nice place to
> define it because the way it is done today don't have any version
> control, authors, obsoleted standard's, etc. IANA could use that
> definition too... perhaps creating a new value to the 'status' column
> or a new column: PRI.
>
> I like the RIR Statistics Exchange Format. It is an easily-parseable
> representation.
> I don't like the IANA format because some important parts are
> 'Footnotes': hardly-parseable.
>
> I would like to use a RFC to create my parser instead an unknown
> defined doc that can change anytime.
>
> Terry, if you wanna extend your I-D to create a standart to all RIR's
> and an IETF WG is the right place to do this: I am available to help
> you.
>
> Best Regards,
> Pedro
>
> On Tue, Aug 23, 2011 at 8:56 AM, 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.
>>
>> See some other comments in line.
>>
>> On 23 Aug 2011, at 03:20, Terry Manderson wrote:
>>
>>> Hi Arturo,
>>>
>>>
>>> On 23/08/11 4:00 AM, "Arturo Servin" <[email protected]> wrote:
>>>
>>>> Terry
>>>>
>>>> Who defines that one of the other is routable or not?
>>>
>>> Defines?
>>>
>>> It specifies if the prefix is _intended_ to be routable.
>>>
>>>>
>>>> For example, 179/8. It assigned to LACNIC but we cannot claim that
>>>> the
>>>> whole /8 is routable. It would depend in the allocations and the
>>>> organisations
>>>> that are received them to decide if their assignment is or not routable.
>>>
>>> Anything related to 179/8 and the allocations within that are surely the
>>> business of LACNIC. The only thing this is saying is that space within 179/8
>>> is intended to be publically routed. Do you disagree with that statement?
>>
>> 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.
>>
>>> 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.
>>
>>
>>>
>>>>
>>>> For the rest, I have the following comments (Version 0 looked very
>>>> different to v1 / v2):
>>>>
>>>> - I see the importance of the PRI in IANA IPv4 Special Purpose
>>>> Address
>>>> Registry but
>>>> - I do not see any technical advantage to include that information
>>>> in
>>>> the IPv4 and IPv6 registries (as my comment about 179/8)
>>>>
>>>
>>> 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.
>>
>> 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.
>>
>>
>>>
>>>>
>>>> "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?
>>
>>
>>>
>>> Surely transparency and simplicity there is a good thing!
>>>
>>>>
>>>>
>>>> "Work is underway in the IETF to design and document a number of
>>>> systems or architectures to facilitate the desire to secure the
>>>> Internet routing system."
>>>>
>>>> Yes, RPKI is the place and technology to do this, not PRI IMHO.
>>>
>>> I'm not with you on that one. RPKI is just one perceived use of this.
>>>
>>>>
>>>> "Such work will require an explicit statement as to the
>>>> intended public routability of an allocation."
>>>>
>>>> May be (I think it does not), but in any case, the IANA registry is
>>>> not the place. Also, IANA does not have that information. Neither RIRs.
>>>
>>> The IANA certainly should have the ability to say if a prefix allocated or
>>> assigned was intended for seen in a public routing context. The question of
>>> it actually being seen is not in this scope.
>>>
>>>>
>>>> "This document directs IANA to extend all the IPv4 and IPv6 address
>>>> registries to record Public Routing Intent (PRI) as either "Routable"
>>>> or "Not Routable".
>>>>
>>>> IANA does not have the mechanisms to do that.
>>>
>>> I don't understand your statement.
>>> What specifically do you think IANA does not have a mechanism for?
>>>
>>> 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
>> 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.
>>
>>>
>>>>
>>>> Also I think that we are going to waters that we should not go (this
>>>> is going between the technical and policies fields).
>>>
>>> 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)
>>
>> You are intended to modify space assigned to RIRs (some of them),
>> some 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.
>>
>>>
>>> Cheers
>>> Terry
>>
>>
>> Best wishes,
>> .as
>> _______________________________________________
>> GROW mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/grow
>>
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
