$ubject changed as it is now where to put the pointer
[ we have email suggesting putting the geoloc pointer in dns, routing
databases, ... no one has suggested bgp yet, but i assume it is
coming ]
> I assume that someone (entity) publishes a geo-feed
> I assume that location of this feed (a
I have a question which might be about data flow here...
I assume that someone (entity) publishes a geo-feed
I assume that location of this feed (and others) is the goal of this work/draft.
(I have no idea how this is done today.. aside from 1 implementation that
requires a user to 'login'
Hi,
Shouldn't that be solved...?
Maybe a task-force under NRO...? :-)
Regards,
Carlos
On Wed, 16 Sep 2020, Job Snijders wrote:
On Tue, Sep 15, 2020 at 01:52:05PM -0700, Randy Bush wrote:
perchance is RDAP implemented by all RIRs?
Yes, but in 5 slightly different ways :-)
Kind regards
On Tue, Sep 15, 2020 at 01:52:05PM -0700, Randy Bush wrote:
> perchance is RDAP implemented by all RIRs?
Yes, but in 5 slightly different ways :-)
Kind regards,
Job
perchance is RDAP implemented by all RIRs?
randy
> Radb only supports
again, north america is a special snowflake. radb is a routing
registry, not an allocation registry. inetnum: and NetRange: are
allocation objects.
if you get your address space from arin, you have to use their
webby stuff to add the Comments: to the allocation object.
On Mon, Sep 14, 2020 at 6:00 PM Randy Bush wrote:
> > Would your arin approach of netrange work in all regions?
>
>
>
> no. to the best of my knowledge, other regional registries and
>
> independent irr registries use rpsl; i.e. inetnum: and remarks:.
>
Radb only supports
route
-route6
-aut-
> Would your arin approach of netrange work in all regions?
no. to the best of my knowledge, other regional registries and
independent irr registries use rpsl; i.e. inetnum: and remarks:.
randy
On Mon, Sep 14, 2020 at 5:53 PM Randy Bush wrote:
> >> the edit buffer, yet to be published, has
>
> >>
>
> >>Currently, the registry data published by ARIN is not RPSL;
>
> >>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>
> >>key must be treated as "inetnum" an
>> the edit buffer, yet to be published, has
>>
>>Currently, the registry data published by ARIN is not RPSL;
>>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>>key must be treated as "inetnum" and the "Comment" attribute must be
>>treated as "remarks".
>>
>> co
On Mon, Sep 14, 2020 at 3:02 PM Randy Bush wrote:
> the edit buffer, yet to be published, has
>
>
>
>Currently, the registry data published by ARIN is not RPSL;
>
>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>
>key must be treated as "inetnum" and the "Comment"
the edit buffer, yet to be published, has
Currently, the registry data published by ARIN is not RPSL;
therefore, when fetching from ARIN whois, the "NetRange" attribute/
key must be treated as "inetnum" and the "Comment" attribute must be
treated as "remarks".
comments appreciated
ra
>> we are not expecting these lookups to be done frequently. i agree that
>> would hammer servers, both rpsl and geofeed. do you have stronger words
>> to suggest than
>>
>>5. Operational Considerations
>>...
>>An entity fetching geofeed data through these mechanisms MUST NOT do
>>
> > Why not publish RFC8805 Geofeed directly in inetnum remarks section?
>
> for some flat fan out last kilometer providers that could be the
> inetnum: object from hell. there are global providers which segment
> large prefixes over diverse areas. etc.
>
> i doubt the rpsl providers would like m
e know this, which is why the OP $subjest was
>
>
>
> "how would draft-ymbk-opsawg-finding-geofeeds work in noam?"
>
>
>
> > I thought you might know this, and could have saved me a few hours of
>
> > tinkering...
>
>
>
> yikes! did not mean to
hi ca
> I gave your I-D a try in the real world, and it does not work with a
> major player.
i.e. arin and radb, your region, which does not do rpsl as others do.
we know this, which is why the OP $subjest was
"how would draft-ymbk-opsawg-finding-geofeeds work in noam?"
>
yang,
> Why not publish RFC8805 Geofeed directly in inetnum remarks section?
for some flat fan out last kilometer providers that could be the
inetnum: object from hell. there are global providers which segment
large prefixes over diverse areas. etc.
i doubt the rpsl providers would like multi-
On Fri, Sep 11, 2020 at 1:48 PM Randy Bush wrote:
>
> would folk familiar with the north american RIR and IRR registries be
> kind enough to suggest how this might adapt? thanks.
>
Hi Randy,
Why not publish RFC8805 Geofeed directly in inetnum remarks section?
Then there is no more need to host
On Sat, Sep 12, 2020 at 1:13 PM Randy Bush wrote:
> hi camron
>
> sad to say, the days of faxing around number assigments have passed.
> the kiddie googlers who wrote the geofeeds rfc probably have not even
> seen a fax machine. they just did not like having a hundred gnomes in
> the basement de
hi camron
sad to say, the days of faxing around number assigments have passed.
the kiddie googlers who wrote the geofeeds rfc probably have not even
seen a fax machine. they just did not like having a hundred gnomes in
the basement dealing with everybody's formats. given silicon valley
housing c
On Fri, Sep 11, 2020 at 1:49 PM Randy Bush wrote:
> would folk familiar with the north american RIR and IRR registries be
>
> kind enough to suggest how this might adapt? thanks.
>
>
>
> A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
>
> has been successfully submitted by Randy
would folk familiar with the north american RIR and IRR registries be
kind enough to suggest how this might adapt? thanks.
A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.
Name: draft-ymbk-o
22 matches
Mail list logo
