--- Begin Message ---
> I haven't seen any reply to Nick's email from either David or any of
> the co-Chairs. Now maybe lots is going on in the background, but that
> would seem strange.
>
> I find the situation concerning, but what I find even more concerning
> is the complete lack of response
--- Begin Message ---
> But this time we do need numbers.
voting, eh?
> Question - Should the RIPE Database allow creation of ROUTE objects
> for non RIPE resources?
yes
randy
--- End Message ---
--- Begin Message ---
Question - Should the RIPE Database allow creation of ROUTE objects
for non RIPE resources?
>>
>> yes
>
> then how can we use the traditional irrdb to distinguish between address
> blocks which have been authenticated by the ripe ncc and those which
> have not.
--- Begin Message ---
> Also, what would the distinguisher be for eg. a route: with prefix
> from RIPE and ASN from ARIN?
thanks to the inability to inter-region transfer as-nums, that is
exactly my situation :)
randy
--- End Message ---
> 2) Flag "route:" objects for non-RIPE-managed space with "source:
> RIPE-NONAUTH" to identify non-authoritative data.
why not go the other, more positive, direction, and identify authorised
data with RIPE-AUTH or whatever? no need to be pejorative.
randy
>>> 2) Flag "route:" objects for non-RIPE-managed space with "source:
>>> RIPE-NONAUTH" to identify non-authoritative data.
>>
>> why not go the other, more positive, direction, and identify authorised
>> data with RIPE-AUTH or whatever? no need to be pejorative.
>
> This is not meant to be
this is a brilliant exercise to see how far the community will bend over
in pseudo-politeness while it is being slimed and abused.
randy
>> this is a brilliant exercise to see how far the community will bend over
>> in pseudo-politeness while it is being slimed and abused.
>
> I am nothing if not polite!
>
> I've been through this before, it's far from pleasant, but I'd hoped
> the community had learned from my mistakes on
>> why not go the other, more positive, direction, and identify authorised
>> data with RIPE-AUTH or whatever? no need to be pejorative.
>
> s/RIPE-NONAUTH/RIPE-OTHERRIR/
can there be cases where the source is not an rir? rfc1918 for example?
s/RIPE-NONAUTH/JOB-HATES/ :)
randy
please note that the rirs are a small minority of the irr instances.
i do not have time to deal with putting more lipstick on the poor pig.
randy
could someone unsub these s
sorry for spamming the list, but the headers have no list whinee address
randy
--- Begin Message ---
Dear Valued Customer,
Thank you for contacting Etisalat Domains Support.
This is an automated response confirming the receipt of your ticket. Our team will get back
> Why can't small ISPs use the IRR provided by the RIR?
this may come as a shock, but not all isps are close to their regional
rir.
> You only end up in a third party IRR database (such as RADB) if you
> have a prefix from AfriNIC and an ASN from RIPE.
and hundreds of dollars per year
> But if
[ off list ]
isps need the irr-based filtering 'telcoms' to use all the irr
instances, as small emerging economy isps can not afford radb
and will soon not be able to use ripe. so the attackers will
use the irr instance with lowest security to spoof.
randy
> [ off list ]
well, it wasn't. thanks to header modification by broken do-gooder
email software. do not modify email headers!!!
i think the bottom line here is that the IRR, and by that i mean the
total collection of IRR instances, is poorly secured by design. we
can spend a lot of time with patches and workarounds, or we can take
it for what it is and live with it.
if you want security and authenticity by design, use
> My personal (and I stress personal) opinion moving forward, is that
> the use of an IRR really does not sit well with the management side of
> delegation of authority in a distributed model that we have right now.
>
> If we move to a model where the IRR/RPSL "maintainer" is understood to
> be
This can be a separate effort. However, what I did not mention
earlier is that we probably should disallow the creation of new
out-of-region AUT-NUM objects if they are no longer required to
authorise ROUTE(6) objects.
>>
>> how long do you think it will be before there are no
> We're back to this again... more of our space is being hijacked using
> a RIPE IRR entry:
>
> route: 108.160.128.0/20
> descr: 2nd route
> origin: AS19529
> mnt-by: ADMASTER-MNT
> created: 2017-11-15T17:41:46Z
> last-modified: 2017-11-15T17:41:46Z
>
> once a route/route6 object in RIPE-NONAUTH becomes in conflict with a
> RPKI ROA it should no longer exist.
and once a route/route6 object in the ripe irr instance comes in
conflict with a roa published anywhere in the rpki, it should no longer
exist?
randy
>>> Alex - just create the route object in the correct database.
>> no impure genetics in the ripe database. they should live in theit own
>> neighborhoods!
> I don’t understand what you intend to convene to the working group.
> Genetics are not part of this policy proposal.
maybe. but
> Alex - just create the route object in the correct database.
no impure genetics in the ripe database. they should live in theit own
neighborhoods!
randy
sandra,
firefox on a mac
when i select a weight for one item, the weight i already selected for
some other item often goes blank. i gave up.
also, is the question set
o i would like to know more about x, or
o i think x is important for folk doing my job to know?
randy
is there no parm to whois which results only in the specific answer, not
also the org: person: and grandmother: objects? i want it irrespective
of object type i am looking up.
```
whois -h whois.ripe.net -r -T inetnum 147.28.0.0/16 | egrep -v '^($|%)'
```
is opbject-type specific
randy
> For each newly created ORG record that is put into the data base, if
> the ORG record represents something other than a natural person, does
> NCC staff make any effort to check to make sure that the alleged
> non-person entity actually exists, I mean, you know, as a legal entity,
> somewhere on
Randy Bush via db-wg wrote:
>
> [ off list ]
sigh
apologies
> Randy Bush via db-wg wrote:
>> [ off list ]
> sigh
> apologies
do note that i replied to a message where the From: header had been
*illegally* mangled by the mail exploder.
> From: Nick Hilliard via db-wg
randy
[ off list ]
first, we are chasing an arin troll down a rabbit hole
> organisation: ORG-FNL99-RIPE
> org-name: Foo Networks Limited
> org-type: LIR
> [...]
> mnt-ref:RIPE-NCC-HM-MNT
> mnt-by: RIPE-NCC-HM-MNT
> abuse-c:FOO2000-RIPE
> created:
> the idea is that some org objects are created by users and inserted
> into the ripe database while others are subject to due diligence by
> the ripe ncc. I.e. there's a qualitative difference in data quality
> between the two, but there is no way of distinguishing between them.
aha! ok. i buy
sanjaya:
FWIW, APNIC Whois database has 3 objects with more than one distinct
country attributes, out of the 1,147,623 inetnum/inet6num/autnum
objects.
are these useful to apnic, ops, or even researchers?
randy
perhaps, instead of really rude ad homina, you could try to be
constructive by finding and nominating a really excellent candidate
or two.
randy
> If nobody ever adapts RPSL to the new requirements, RPSL is dead. So
> the question is: Should we throw away the RRDB in favour of something
> else, or do we extend RPSL in the way it was designed?
we have a lot of rpsl-based toolchains out there. this does not mean
we should not work on next
> - RIPE Database is set up to contain hierarchical data already. With this
> proposal, we would take some of this data outside the database in a manner
> that does not guarantee consistency with the database itself. For example,
> 192.168/16 specifies a geofeed file that has different prefixes in
> "should we have a geofeed attribute that accepts a URL, or just a remarks
> attribute with a value prefixed with Geofeed?"
>
> "remarks: Geofeed https://example.com/geofeed.csv;
> vs
> "geofeed: https://example.com/geofeed.csv;
and we're currently trying to bridge two tensions.
there will be
domain: 0.28.147.in-addr.arpa
descr: RG79-147-28-0
admin-c:RB45695-RIPE
tech-c: RB45695-RIPE
zone-c: RB45695-RIPE
nserver:rip.psg.com
nserver:nlns.globnix.net
mnt-by: MAINT-RGNET
source:
> Hi guys
ahem
> GDPR applies to the entire RIPE Database because the RIPE NCC, who
> operate the database, is based in the EU.
appreciate the legal opinion. how come person: objects are allowed?
randy
> This circumvents the (accepted) purpose of the RIPE Database as a
> 'public registry' of who is responsible for Internet resources.
thank you
randy
> What if you had a parent organization and a few sub-organizations and
> each has their own resources (ASN + inetnum) that they wish to manage
> independently (objects, RPKI, etc) without the other sub-organizations
> of parent organization able to affect the resources.
the rpki part is trivial,
> 1. join secret society, learn special handshakes, involve oneself in
> mysterious + private rituals, attend shady meetings in smoke-filled
> rooms with nefarious intent, climb invisible ladder of privilege, fly
> private jet around the world to attend invite-only meetings with kings
> and
hi cynthia
>> Why not use the RPKI to distribute geofeed information?
>
> I think using RPKI for this will make it needlessly complicated for people
> to use. I think we want to make this as simple as possible for someone to
> find.
as i said to job over on the dark side of the force, the ietf,
> And on the note of the main challenge, I also think a part of making it
> simple to implement is to try to have the same API for this between all of
> the RIRs
https://github.com/massimocandela/geofeed-finder
what remains is to go from a remarks: attribute to a first class
geofeed: attribute,
>> from draft-ietf-opsawg-finding-geofeeds
>>
>> Any particular inetnum: object MAY have, at most, one geofeed
>> reference, whether a remarks: or a proper geofeed: attribute when
>> one is defined.
>>
>> now all we need is for the someone or someone's automated system to read
>>
> An interesting question Robert. Perhaps an even more interesting one
> is, if we implement the "geofeed:" attribute, should we allow anyone
> to add any "remarks: Geofeed" or should we flag that as a syntax
> error? Or will any tool that accesses this data ignore any "remarks:"
> attributes if
> If the geofeed doesn't contain the above mentioned means to directly
> or indirectly identify a natural person then GDPR don't apply,
> especially if the geofeed refers only to a country or province.
note that the geofeed spec, RFC8805, is separate from the rpsl-based
means to find the geofeed
>>> If the geofeed doesn't contain the above mentioned means to directly
>>> or indirectly identify a natural person then GDPR don't apply,
>>> especially if the geofeed refers only to a country or province.
>>
>> note that the geofeed spec, RFC8805, is separate from the rpsl-based
>> means to
> What happens when someone (or someone's automated system) pushes an
> object with a "remarks: Geofeed" again?
from draft-ietf-opsawg-finding-geofeeds
Any particular inetnum: object MAY have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute when
> I still see "purpose" on having person: objects in the database.
the network manager handbook used to sit on my desk. i used it a lot.
whois has become less and less useful.
randy
>>> The DB team maintains this list and will exclude an object on request.
>> please exclude all objects i might wish to look up.
perhaps i was being too subtle. the original purpose of the whois
database was for operators to contact each other for coordination and
sharing of exciting events.
> For example, if a /27 IPv4 block is assigned to a legal person, the
> geofeed data will likely not constitute personal data.
does a url pointing to the geofeed data constitute personal data?
randy
> There is an exclude list for the cleanup unreferenced objects job, and
> CAAO-RIPE is excluded, so it will never be deleted.
>
> The DB team maintains this list and will exclude an object on request.
please exclude all objects i might wish to look up.
in
>> Agreed, go for the path of least surprises ⇒ enforce case
>> consistency.
> +1 to that. I know I would forget that myself
except the change is not POLA at all, is it?
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to
> It says in the documentation that you cannot split the primary key
> attribute value over multiple lines.
it's a shame that the NCC does not have a webinar on db use. oh, wait.
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back,
>>> +1 to that. I know I would forget that myself
>>
>> except the change is not POLA at all, is it?
>
> POLA := "principle of least astonishment"?
yep
randy
there is no proof of termination of hacking long deployed specs and
software to fix the bugs in someone's program where they diod not read
the specs.
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
edward,
> Impact Analysis for Implementing the "geofeed:" Attribute
looks ok to me
thanks!
randy
> I have CCed Randy Bush as I thought he might be able to clarify what
> was meant by the following:
>> To minimize the load on RIR whois [RFC3912] services, use of the
>> RIR's FTP [RFC0959] services SHOULD be the preferred access. This
>> also provides bulk access instead of fetching with a
marcel,
i think nick and cynthia answered your question. but there remains the
question of where the heck one goes for day to day routing ops help. as
cynthia pointed out, this wg is more for the policy and technical
underpinnings, not actuall operations. what's strange is that it is not
at
did the db-tf really not look at this?
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header mangling
> did the db-tf really not look at this?
since it seems not, perhaps the wg should not get too far out in front
of the tf.
randy
> Could we consider creating an NWI with a reduced scope?
as an exercise, how minimal can we get?
randy
< i will regret this >
> I'm sure there are DNS people around that can explain to IANA what a
> lame delegation is…
folk: i think it is safe to assume the iana is technically competent.
the problems lies above layer seven, and particularly in the seemingly
eternal ego and power struggle between
> I ask the community for feedback whether publishing incremental
> changes to the delegated stats is useful for them.
not for me. i have no need for up to the minute delegation data,
as i do not hook it into fast churn automation.
randy
---
ra...@psg.com
`gpg --locate-external-keys
[ i wanted to write to you off-list, but illegal header mangling by the
list software prevented it. ]
> The /48 prefix size is the maximum size suggested in the "BCOP for
> Operators: IPv6 prefix assignment for end-users":
>
> I appreciate concerns about privacy, but I'm not wholly convinced
> restricting /48s from having a proper 'geofeed:' attribute is the best
> path forward.
drumroll! and the best path forward is? :)
my non-ecc memory is that this is ncc legal trying not to get highly
specific. i.e. it is not
mornin' job
> Regardless of the cause of the dysfunctionality, I think the Database
> Working Group is the appropriate forum to discuss the problem of being
> unable to use the geofeed RPSL attribute in database objects.
my point is that i think the wg already did. ncc legal, in post-wg
review,
hi ed:
one step forward, one back.
in a previous life, i was a programming language hacker snd compiler
writer. we used to make very strong negative review of any proposals
to muck about with semantics in comment fields. just don't.
randy
--
To unsubscribe from this mailing list, get a
> The RFC says "Until such time...". We have a "geofeed:" attribute now
> so we are past 'such time'. We should no longer even consider, or
> support, "remarks:'' as an option for geofeed.
you have the wrong end of the horse. it is the seeker/fetcher of
geofeed data who decides whether they look
> Why isn't creating an ROA proof enough that I control the address
> range?
who is "i?"
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
> Would it be useful to have a discussion about this at the upcoming
> meeting in Rome?
iff it was a discussion, not walls of powerpoint
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
> [ off list ]
well, i guess not; thank you dmarc
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
[ off list ]
there was a reason jon went with 1366; outsourced the decision.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
> I don't think that is a reasonable conclusion to draw from what was
> said.
to be honest, and maybe because this is my first cup of coffee of the
morning, and it is ietf week, i really don't know what was being said
in an operational way. and, being a researcher, i have no clue about
this
the purpose has been for operational use since dirt was invented. the
geofeed: attribute points to data which operators, namely content
providers, need. maybe we do not need to make a bureaucratic mountain
out of a molehill.
randy
--
To unsubscribe from this mailing list, get a password
> Why is nobody listening here?
preconceived models which do not match what ops actually do
yet another artifact of thinking there are green, blue, magenta, ... IP
addresses
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please
> I was probably being a bit loose with my definitions but are you
> saying that ALL content providers are network operators?
i eagerly await your counter-example
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
> (5) LEGACY resources are not in scope. If there is interest in using
> "geofeed:" with legacy resources we can evaluate.
inetnum:147.28.0.0 - 147.28.15.255
netname:RGNET-RSCH-147-0
country:EE
org:ORG-RO47-RIPE
admin-c:RB45695-RIPE
tech-c:
>> the purpose has been for operational use since dirt was invented. the
> The term 'operational use' has never actually been defined. But if we
> were to define it then I suspect it will be more about network
> operators solving technical problems with keeping networks online.
the network is
> Content providers 'not=' network operators.
given the state of the actual operational internet, this is a rather
shocking statement from a ripe wg co-chair.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
> A lot of this discussion is about interpreting one defined purpose
> trying to make everything fit in order to 'get around' a legal review.
another interpretation is that this discussion is trying to bridge a
rather shocking gap between ncc legal, one db-wg-co-chair, and how the
operational
>>> I was probably being a bit loose with my definitions but are you
>>> saying that ALL content providers are network operators?
>> i eagerly await your counter-example
> It was a question not a statement.
i was answering, perhaps so politely as to confuse you
randy
--
To unsubscribe from
> Since we sent out the form below, not one person has responded :(
i do not believe that statement to be correct
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
> Cross-registry queries are a fact of life. It is advisable to specify
> source lists explicitly because otherwise you can end up with all
> sorts of junk in a query
the ancient grotty code here orders the source query list per peer as it
generate phyltres, prioritiising the one they tell me
> I suggest that this is not just a localized decision of the db-wg, but
> has global implications.
+1, and this aside from the idea having other fatal flaws, as discussed
here before.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription
i just want to fetch the domain object
[ actually, what i would love is to fetch all domain objects with
mnt-by: MAINT-RGNET
but one step at a time ]
ryuu.rg.net:/Users/randy> telnet -4 whois.ripe.net 43
Trying 193.0.6.135...
Connected to whois.ripe.net.
Escape character is
> Just the domain object, not the person object? Add " -r" to your
> query:
and then it seems i can skip the `-T domain`
thanks
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
IANAL and try not to play one on the net. but ...
my reading of why NCC legal has problems with the geofeed: attribute is
that they see the NCC as legally liable for the content of the geofeed
data file to which it points.
this concern may be based, for example, in the courts finding pirate bay
you can do it yourself
announce the more specifics to the provider who gives ddos mediation,
and the less specific, /32, to the non-protecting provider
be sure that any IRR and RPKI data are good for both the aggregate
and the specifics
randy
--
To unsubscribe from this mailing list, get a
> By doing this the internet will always (also under normal
> circumstances) prefer that one provider.
0 - register irr and rpki objects for aggregates and for longer
defensive prefixes
1 - announce only aggregates to both providers
2 - when ddosed,
- do not change announcement of
> Here the problem is "for longer defensive prefixes"
> For example in normal situation I advertise /32 to my ip transit providers.
> When DDoS happens then one of my providers will start advertisin 1x/48
> of my /32 prefix to hi-jack the route from us and filter it.
i did not say that your
> there is no way you can ensure that A Random Network out there will
> accept any/all /48s from your /32.
there is no way to ensure that a random network out there will accept
X for all values of X
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
> I approve of more active WG management for the good of the internet.
i do not.
i am ok with a co-chair explicitly taking their co-chair hat off and
having an opinion with the same weight as everyone else.
i am as happy with activist wg-chairs as i am with activist us supreme
court justices.
> Some of my goals as a co-chair would be
> - To support the moderation of the mailing list and facilitate working
> group tasks
> - Promote active discussion, sending summary emails to make the
> content easier to follow
> - Perform community outreach to raise awareness of this working group
> That would be fine if we had a very active and engaging community. Like we
> had 20 years ago. But the vast vast vast majority of this community is
> silent on almost all database matters. The vocal people are a handful of
> well known members of the community, whose views on many matters are
hi edward,
> If there is no objection, I propose for consistency to also add
> "sponsoring-org:" to the list of inverse query attributes.
why might i not like this? having problems thinking of why not.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
> Peter Hessler volunteered for the working group co-chair position.
cool beans! thanks peter.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
94 matches
Mail list logo
