From alexb at ripe.net Thu Jul 2 11:42:12 2015 From: alexb at ripe.net (Alex Band) Date: Thu, 2 Jul 2015 11:42:12 +0200 Subject: [db-wg] Temporary origins In-Reply-To: References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> Message-ID: <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> Thanks for sharing your experiences George. I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object. It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets. Seeing that APNIC has positive experiences, would our Community support such an approach considering the up and downsides? Cheers, Alex > On 26 Jun 2015, at 06:43, George Michaelson wrote: > > > > On 25 June 2015 at 21:42, Job Snijders wrote: > On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote: > > For your information, APNIC Hostmasters have moved to a mode of > > operation where for inetnum owners where the AS holder is not the same > > person, and a request is lodged with helpdesk for assistance, the > > hostmasters manually override and create the object for the inetnum > > holder, only removing it if an AS holder objects. The inetnum holder > > needs to be recognised in our systems. > > > > Its a hand-mediated inetnum-only route object. Previous practice was > > to wait for explicit approval from the AS holder. Now, its created > > first, and withdrawn if there is an objection. > > > > There have been no complaints. APNIC HM are considering portal changes > > and other process work to automate this. > > What is the benefit of the hand-mediation? > Or is that just an artifact > of the software implementation? > > Its an artefact of the s/w implementation. I imagine once they work out how to do this in the portal, this will be changed. > > Does APNIC send a notification to the AS > holder that an object was created in which they were referenced? > > Yes. The following template is used: > > ====== > > Dear (ASN custodian), > This is to inform you that the following route/route6 object has been registered in the APNIC Whois Database with your AS number referenced in the "origin" attribute. > > --- > insert route object > --- > > The IP addresses holder has asked that APNIC help register this route object in the APNIC Whois database. > > If you believe your AS number should not be referenced as the "origin" in this route object, please contact us by replying to this email. > > Kind Regards, > > ====== > > cheers > > -George > > > Kind regards, > > Job > From dbwg at c4inet.net Thu Jul 2 12:05:40 2015 From: dbwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 2 Jul 2015 11:05:40 +0100 Subject: [db-wg] Temporary origins In-Reply-To: <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> Message-ID: <20150702100540.GH36186@cilantro.c4inet.net> On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote: >Thanks for sharing your experiences George. > >I'm curious to hear from our Community about what they think >about this mode of operation; simply create the route object on >the inetnum holder's authorisation alone, inform the ASN holder >that it was created and only remove the object if they object. > >It would simplify the authorisation model tremendously and save >a lot of frustration and customer support tickets. > >Seeing that APNIC has positive experiences, would our Community >support such an approach considering the up and downsides? Works for me. It's within the authority of the prefix holder to decide whom to allow to advertise the prefix. If the ASN holder doesn't want to advertise it, don't. Out of interest, do you propose to automate the removal of disputed route: objects? How would that be authorised if maintained solely by the inetnum: maintainer? rgds, Sascha Luck From gert at space.net Thu Jul 2 12:36:44 2015 From: gert at space.net (Gert Doering) Date: Thu, 2 Jul 2015 12:36:44 +0200 Subject: [db-wg] Temporary origins In-Reply-To: <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> Message-ID: <20150702103644.GO67883@Space.Net> Hi, On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote: > I'm curious to hear from our Community about what they think about > this mode of operation; simply create the route object on the inetnum > holder's authorisation alone, inform the ASN holder that it was > created and only remove the object if they object. Would work for me... Gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From f.kriewitz at nynex.de Thu Jul 2 12:45:32 2015 From: f.kriewitz at nynex.de (Frederik Kriewitz) Date: Thu, 2 Jul 2015 10:45:32 +0000 Subject: [db-wg] Temporary origins In-Reply-To: <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> Message-ID: > -----Original Message----- > From: Alex Band on Thursday, July 02, 2015 11:42 AM > > Thanks for sharing your experiences George. > > I'm curious to hear from our Community about what they think about this > mode of operation; simply create the route object on the inetnum holder's > authorisation alone, inform the ASN holder that it was created and only > remove the object if they object. > > It would simplify the authorisation model tremendously and save a lot of > frustration and customer support tickets. > > Seeing that APNIC has positive experiences, would our Community support > such an approach considering the up and downsides? We definitely would support this simplified authorization method. Our primary concern is that it would make polluting the database even easier which might be abuse e.g. to attack (DoS) filter generation tools/access list memory limits. But as this could be done with the current database anyway, we don't think it will be a problem. The big advantage we see is that it would make the creation of route objects with inetnum/origin combinations from different RIRs easier. Once more RIRs adopt this simple authorization model access to their address space via RIPE-NCC-RPSL-MNT should be prevented. That would improve security in the long run. Best Regards, Frederik Kriewitz NYNEX satellite OHG From job at ntt.net Thu Jul 2 16:16:41 2015 From: job at ntt.net (Job Snijders) Date: Thu, 2 Jul 2015 16:16:41 +0200 Subject: [db-wg] Temporary origins In-Reply-To: <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> Message-ID: <20150702141641.GA52630@Vurt.local> On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote: > Thanks for sharing your experiences George. > > I'm curious to hear from our Community about what they think about > this mode of operation; simply create the route object on the inetnum > holder's authorisation alone, inform the ASN holder that it was > created and only remove the object if they object. > > It would simplify the authorisation model tremendously and save a lot > of frustration and customer support tickets. > > Seeing that APNIC has positive experiences, would our Community > support such an approach considering the up and downsides? I support this direction and style of operation. The philosophy that an inetnum holder can unilaterally grant the right to announce a prefix to any ASN makes sense to me, probably is more intuitive to most. Kind regards, Job From tim at ripe.net Thu Jul 2 17:09:50 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 2 Jul 2015 17:09:50 +0200 Subject: [db-wg] Temporary origins In-Reply-To: <20150702100540.GH36186@cilantro.c4inet.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> <20150702100540.GH36186@cilantro.c4inet.net> Message-ID: <40B13820-CE49-43E7-A649-EC4FA3C7A037@ripe.net> > On Jul 2, 2015, at 12:05 PM, Sascha Luck [ml] wrote: > > On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote: >> Thanks for sharing your experiences George. >> >> I'm curious to hear from our Community about what they think >> about this mode of operation; simply create the route object on >> the inetnum holder's authorisation alone, inform the ASN holder >> that it was created and only remove the object if they object. >> >> It would simplify the authorisation model tremendously and save >> a lot of frustration and customer support tickets. >> >> Seeing that APNIC has positive experiences, would our Community >> support such an approach considering the up and downsides? > > Works for me. It's within the authority of the prefix holder to > decide whom to allow to advertise the prefix. If the ASN holder > doesn't want to advertise it, don't. > > Out of interest, do you propose to automate the removal of > disputed route: objects? How would that be authorised if > maintained solely by the inetnum: maintainer? The same authorisation that is currently required to do pre-approval of the ASN side of route object creation, could be used to allow 'post-deletion'. I.e. even though there would be no mnt-by for the ASN holder, they would be able to delete the object provided they have access to the relevant aut-num maintainer (mnt-by, mnt-routes). This way the ASN holder could use existing APIs and web-updates to delete the object in response to the notification of the route object creation (we can easily include a link to web updates). ASNs that want to be more restrictive could even automate querying the database for route objects with their ASN in the "origin:" and delete unwanted objects they find. Regards, Tim Bruijnzeels > > rgds, > Sascha Luck > From snash at arbor.net Thu Jul 2 17:26:19 2015 From: snash at arbor.net (snash) Date: Thu, 02 Jul 2015 15:26:19 +0000 Subject: [db-wg] Temporary origins Message-ID: Alex I think the notification to the ASN holder is a good thing. The notification could include a reference to the inetnum holder so that the ASN holder could make contact more easily, if necessary. If we accept that the inetnum holder has the authority to create, then it is not clear to me why the ASN holder should have the right to delete. If there has been a mistake it is to the detriment only of the inetnum holder's organisation, and they can remove the Route Object and correct it. For clarity - By "ASN holder" we are referring to the origin ASN in the new Route Object, not any other. This policy change would enable a clear and simplified instruction for organisations needing authority to originate temporarily. Thanks Steve > On 26 Jun 2015, at 06:43, George Michaelson wrote: > > > > On 25 June 2015 at 21:42, Job Snijders wrote: > On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote: > > For your information, APNIC Hostmasters have moved to a mode of > > operation where for inetnum owners where the AS holder is not the >same > > person, and a request is lodged with helpdesk for assistance, the > > hostmasters manually override and create the object for the inetnum > > holder, only removing it if an AS holder objects. The inetnum holder > > needs to be recognised in our systems. > > > > Its a hand-mediated inetnum-only route object. Previous practice was > > to wait for explicit approval from the AS holder. Now, its created > > first, and withdrawn if there is an objection. > > > > There have been no complaints. APNIC HM are considering portal >changes > > and other process work to automate this. > > What is the benefit of the hand-mediation? > Or is that just an artifact > of the software implementation? > > Its an artefact of the s/w implementation. I imagine once they work >out how to do this in the portal, this will be changed. > > Does APNIC send a notification to the AS > holder that an object was created in which they were referenced? > > Yes. The following template is used: > > ====== > > Dear (ASN custodian), > This is to inform you that the following route/route6 object has been >registered in the APNIC Whois Database with your AS number referenced >in the "origin" attribute. > > --- > insert route object > --- > > The IP addresses holder has asked that APNIC help register this route >object in the APNIC Whois database. > > If you believe your AS number should not be referenced as the "origin" >in this route object, please contact us by replying to this email. > > Kind Regards, > > ====== > > cheers > > -George > > > Kind regards, > > Job > End of db-wg Digest, Vol 47, Issue 1 ************************************ From randy at psg.com Thu Jul 2 23:06:59 2015 From: randy at psg.com (Randy Bush) Date: Fri, 03 Jul 2015 06:06:59 +0900 Subject: [db-wg] Temporary origins In-Reply-To: <20150702141641.GA52630@Vurt.local> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> <20150702141641.GA52630@Vurt.local> Message-ID: > On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote: >> I'm curious to hear from our Community about what they think about >> this mode of operation; simply create the route object on the inetnum >> holder's authorisation alone, inform the ASN holder that it was >> created and only remove the object if they object. > > I support this direction and style of operation. The philosophy that > an inetnum holder can unilaterally grant the right to announce a > prefix to any ASN makes sense to me, probably is more intuitive to > most. folk seem to be gliding over the last clause in alex's paragraph. are you agreeing with it? i think i am inclined to agree, given the use of peval(as-set:) to get the transitive closure of a peer's prefixes. but it makes me wonder about my use of as-set:s. randy From randy at psg.com Thu Jul 2 23:09:13 2015 From: randy at psg.com (Randy Bush) Date: Fri, 03 Jul 2015 06:09:13 +0900 Subject: [db-wg] Temporary origins In-Reply-To: <40B13820-CE49-43E7-A649-EC4FA3C7A037@ripe.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> <20150702100540.GH36186@cilantro.c4inet.net> <40B13820-CE49-43E7-A649-EC4FA3C7A037@ripe.net> Message-ID: > The same authorisation that is currently required to do pre-approval > of the ASN side of route object creation, could be used to allow > 'post-deletion'. i worry that this is not gonna age well. cruft is going to be ever- increasing. > I.e. even though there would be no mnt-by for the ASN holder, they > would be able to delete the object provided they have access to the > relevant aut-num maintainer (mnt-by, mnt-routes). just to kludge it up a bit more, send 'em a time-limited token with the approval message randy From mgrol at ripe.net Tue Jul 7 15:22:50 2015 From: mgrol at ripe.net (Marc Grol) Date: Tue, 7 Jul 2015 15:22:50 +0200 Subject: [db-wg] Deal with "non-breaking-space"-characters in updates Message-ID: <242AC2F1-DDA2-4492-8489-516C3B81C221@ripe.net> Summary: Currently the whois database accepts ?non-breaking-space?-characters in updates. We propose that whois replaces these ?non-breaking-space?-characters with regular spaces before storing the object. Context: Currently the whois database accepts updates with "non-breaking-space?-characters as part of attribute values. This behaviour is fairly acceptable, since the "non-breaking-space?-character is part of the ?latin1?-character-set which is supported by whois. The whois database treats these "non-breaking-spaces?-characters as regular spaces and considers the object to be syntactically correct. However, the object is stored exactly as it was received from the client: including non-breaking-spaces Problem: We think most of these "non-breaking-spaces? where intended to be regular spaces, but ended up mangled due to copy and paste. So, when such an object is being queried for, the original object (including non-breaking-spaces) is being returned. This is inconvenient. since most clients cannot handle this ?exceptional? character. It many clients it will end up as something like a ???-character. Alternative solutions: -1- Let whois software accept the update but convert "non-breaking-spaces? into regular spaces before storing -2- Consider requests containing "non-breaking-space?-characters as syntactically incorrect, and do not accept updates containing them. -3- Keep current solution: You get what you asked for. Some additional statistics that can be used to understand the size of the problem: Approximately 3.000 objects (out of 8.000.000) contain "non-breaking-space?-characters. Mostly in ?remarks"-, ?description"- and ?address"-attributes? Marc Grol member of ripe?s whois database team mgrol at ripe.net +31648928856 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2602 bytes Desc: not available URL: From nick at inex.ie Tue Jul 7 16:12:21 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 7 Jul 2015 15:12:21 +0100 Subject: [db-wg] Deal with "non-breaking-space"-characters in updates In-Reply-To: <242AC2F1-DDA2-4492-8489-516C3B81C221@ripe.net> References: <242AC2F1-DDA2-4492-8489-516C3B81C221@ripe.net> Message-ID: <559BDE45.3010105@inex.ie> On 07/07/2015 14:22, Marc Grol wrote: > -1- Let whois software accept the update but convert "non-breaking-spaces? > into regular spaces before storing option 1 + document this + issue warning on db update if there's been a nbsp->sp conversion. Nick From woeber at cc.univie.ac.at Wed Jul 8 12:15:57 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Wed, 08 Jul 2015 12:15:57 +0200 Subject: [db-wg] Deal with "non-breaking-space"-characters in updates In-Reply-To: <559BDE45.3010105@inex.ie> References: <242AC2F1-DDA2-4492-8489-516C3B81C221@ripe.net> <559BDE45.3010105@inex.ie> Message-ID: <559CF85D.5020404@cc.univie.ac.at> On 2015-07-07 16:12, Nick Hilliard wrote: > On 07/07/2015 14:22, Marc Grol wrote: >> -1- Let whois software accept the update but convert "non-breaking-spaces? >> into regular spaces before storing I think this is a very bad approach. The software is (supposed to) support UTF-8 transparency. Thus messing around with the characters SHOULD NOT happen. Another aspect is the potential discrepancy of locally stored copies of cryptographically signed updates and the object in the DB. > option 1 + document this + issue warning on db update if there's been a > nbsp->sp conversion. My suggestion is to potentially issue a warning to point out that such a "funny" character is included in the object, if the community really wants that. Otherwise I think the current approach is fine: do nothing :-) > Nick Wilfried From tim at ripe.net Wed Jul 8 16:49:37 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Wed, 8 Jul 2015 16:49:37 +0200 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> Message-ID: <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> Dear working group, On Monday 13 July, the RIPE NCC will remove all RIPE Database maintainer MD5 passwords that have not been changed since November 2011. We are taking this step as a preventative security measure. This decision was taken in response to discussion on the RIPE Database Working Group mailing list and in close consultation with the working group co-chairs. The contacts of maintainers actively used in the past year have already received individual emails instructing them to change their password. If you have not received this email, but you have reason to believe that your password has not been modified since November 2011, you should change your password before Monday. Go to this page to change your password: https://apps.db.ripe.net/change-auth/mntner-renew-password.html If you find that you are locked out of your maintainer after 13 July, you can still regain access to your maintainer later, using this process: https://apps.db.ripe.net/change-auth/#/ If possible, we urge you stop using passwords and adopt a more secure authentication method such as Single Sign-On or PGP: https://www.ripe.net/manage-ips-and-asns/db/support/security/protecting-data If you have any questions, do not hesitate to contact us at: ripe-dbm at ripe.net. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team From rv at NIC.DTAG.DE Wed Jul 8 18:18:19 2015 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom Technik - FMED-41..) Date: Wed, 08 Jul 2015 18:18:19 +0200 Subject: [db-wg] Deal with "non-breaking-space"-characters in updates In-Reply-To: Your message of "Tue, 07 Jul 2015 15:22:50 +0200." <242AC2F1-DDA2-4492-8489-516C3B81C221@ripe.net> Message-ID: <16398.1436372299@x59.NIC.DTAG.DE> > Summary: > Currently the whois database accepts =E2=80=9Cnon-breaking-space=E2=80=9D- > characters in updates. We propose that whois replaces these > =E2=80=9Cnon-breaking-space=E2=80=9D-characters with regular spaces > before storing the object. >From my point of view the whois service currently has to be considered broken and the problem should be considered with a bit broader perspective than discussing the treatment of a single element of the character set. > Context: > Currently the whois database accepts updates with > "non-breaking-space=E2=80=9D-characters as part of attribute values. > This behaviour is fairly acceptable, since the = > "non-breaking-space=E2=80=9D-character is part of the = > =E2=80=9Clatin1=E2=80=9D-character-set which is supported by whois. > The whois database treats these "non-breaking-spaces=E2=80=9D-characters = > as regular spaces and considers the object to be syntactically correct. > However, the object is stored exactly as it was received from the = > client: including non-breaking-spaces > Problem: > We think most of these "non-breaking-spaces=E2=80=9D where intended to = > be regular spaces, but ended up mangled due to copy and paste. > So, when such an object is being queried for, the original object = > (including non-breaking-spaces) is being returned. > This is inconvenient. since most clients cannot handle this = > =E2=80=9Cexceptional=E2=80=9D character. It many clients it will end up = > as something like a =E2=80=9C?=E2=80=99-character. The actual problem is one of interoperability and in Internet tradition we have to take care of it more seriously than as an issue of just convenience! [do we need to discuss the value of that interoperability tradidtion?) Strictly speaking "whois" should be understood as the TCP port 43 database query service; my primary concern right now is applying the guideline of "... be conservative in what you send" to the operation of exactly this service of the RIPE database to ensure interoperability. Tools using the RIPE whois for routing registry queries do expect the responses to contain RPSL objects; RPSL syntax definition (RFC 2622) and traditional implemenatation (see BISON/FLEX in RFC 2622) did not explictly go beyond the 7 bit ASCII character set. It seems that we missed to address some small details when extending the character set used in the RIPE database was done - well, maybe it was just my stupid self that missed an explicit discussion and resolution of those details... (specific pointers from those in the know are welcome!) ACTUAL OPERATIONAL PROBLEM REPORT: We were hit by a real operational problem: our traditional RPSL tools querying the RIPE-whois-Server for some routing registry evaluation failed because unexpected characters occured in semantically significant attributes (members:) of a returned RPSL object (as-set:). > Alternative solutions: > -1- Let whois software accept the update but convert = > "non-breaking-spaces=E2=80=9D into regular spaces before storing > -2- Consider requests containing "non-breaking-space=E2=80=9D-characters = > as syntactically incorrect, and do not accept updates containing them.=20= > > -3- Keep current solution: You get what you asked for. With current service implementation I do NOT get what I am asking for/expecting: I am asking for at least syntactically correct RPSL objects and not some byte string (blob?!) that someone stored for a certain key! Does anybody disagree with the requirement that responses from whois service have to conform to well defined syntax and that interoperability considerations apply? Now the question remains: what version of RPSL syntax is enforced on the whois service response? I do expect something that it is sufficiently conservative/strict to ensure interoperability for clients. I observe: there are 3 different stages in the data flow where you can "manipulate"; the above list of alternatives certainly does NOT consider the third: (a) on input decide what to accept (potentially different per input interface) and how to normalize (b) representation for storage (c) what presentation you use for output (potentially different per output interface and per output options) (I'd agree with Wilfried in that at least one transparent path through the system is desirable and mappings minimized.) Right now I'm not so much interested in what you are doing in (a) and (b); most reasonable things you can do there would allow (c) to present RPSL objects for whois conformant to a very conservative and restricted syntax. LOOKING CLOSER at RPSL syntax: It seems to me that attributes with value syntax different from RFC2622 (p. 6) can be be normalized to strict 7 bit ASCII with no loss of semantic (and in fact that normalization does not need to change anything but white space!). It seems to me that all significant use cases for extended character sets is in attribute values that were defined using ; further it seems likely that existing RPSL tool implementations actually use a very liberal interpretation of "a sequence of ASCII characters" (i.e. more or less "a sequence of characters"). So I propose to define - and implement accordingly: by default the RIPE whois server will return RPSL objects with character set normalization enforced - attributes that have values with syntax not using will be reperesented using only ASCII (7 bit) - attributes using syntax can use the extended charcter set (I'm not sure whether Latin-1 or UTF-8 or something else...) (Potentially the alternatives 1 or 2 might be valid implementation of my proposal! and would be appreciated as quick fixes for a current problem). > Some additional statistics that can be used to understand the size of = > the problem: > Approximately 3.000 objects (out of 8.000.000) contain = > "non-breaking-space=E2=80=9D-characters. Mostly in =E2=80=9Cremarks"-, = > =E2=80=9Cdescription"- and =E2=80=9Caddress"-attributes? thanks for these statistics; though a closer look would be helpful. - How many objects use characters outside of strict ASCII in "RPSL semantically significant attributes", i.e. attributes that use non- syntax? - are all of those "extended characters" to be considered "white space"? (and specifically is there any other extended character to be considered white space beyond "non breaking space"?) > Marc Grol > member of ripe=E2=80=99s whois database team > mgrol at ripe.net > +31648928856 Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From nick at inex.ie Thu Jul 9 11:22:44 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 09 Jul 2015 10:22:44 +0100 Subject: [db-wg] Deal with "non-breaking-space"-characters in updates In-Reply-To: <16398.1436372299@x59.NIC.DTAG.DE> References: <16398.1436372299@x59.NIC.DTAG.DE> Message-ID: <559E3D64.9050403@inex.ie> On 08/07/2015 17:18, Ruediger Volk, Deutsche Telekom Technik - FMED-41.. wrote: > > Summary: > > Currently the whois database accepts =E2=80=9Cnon-breaking-space=E2=80=9D- > > characters in updates. We propose that whois replaces these > > =E2=80=9Cnon-breaking-space=E2=80=9D-characters with regular spaces > > before storing the object. I'm going to giggle a bit here. Wilfried, while I accept your point in principal, Ruediger's mime formatting unintentionally demonstrates how easily nbsp can cause serious breakage, and that there are many locations in an rpslng object which should only accept a limited ASCII charset. Blindly accepting utf8 everywhere is a bad idea. The viable options for handling this are inbound fixup or else rejection of malformed updates. Either is ok with me, but whichever choice is made needs to be documented clearly. Nick From Woeber at CC.UniVie.ac.at Thu Jul 9 11:33:31 2015 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 09 Jul 2015 11:33:31 +0200 Subject: [db-wg] Deal with "non-breaking-space"-characters in updates In-Reply-To: <559E3D64.9050403@inex.ie> References: <16398.1436372299@x59.NIC.DTAG.DE> <559E3D64.9050403@inex.ie> Message-ID: <559E3FEB.4090405@CC.UniVie.ac.at> Ho Nick, Nick Hilliard wrote: > On 08/07/2015 17:18, Ruediger Volk, Deutsche Telekom Technik - FMED-41.. wrote: > >> > Summary: >> > Currently the whois database accepts =E2=80=9Cnon-breaking-space=E2=80=9D- >> > characters in updates. We propose that whois replaces these >> > =E2=80=9Cnon-breaking-space=E2=80=9D-characters with regular spaces >> > before storing the object. > > > I'm going to giggle a bit here. :-) > Wilfried, while I accept your point in principal, Ruediger's mime > formatting unintentionally demonstrates how easily nbsp can cause serious > breakage, and that there are many locations in an rpslng object which > should only accept a limited ASCII charset. Indeed, while reading R?diger's mail I relized that I wasn't thinking along the path that he was. I was more on the issue of "randomly" doing things to updates. > Blindly accepting utf8 everywhere is a bad idea. Right. I think the *everywhere* is the important thing here. > The viable options for > handling this are inbound fixup MAybe, but then at least a Warning should be returned. > or else rejection of malformed updates. My pov is that this option should be chosen. > Either is ok with me, but whichever choice is made needs to be documented > clearly. +1 > Nick Wilfried From sebastian at karotte.org Thu Jul 9 14:03:47 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Thu, 9 Jul 2015 14:03:47 +0200 Subject: [db-wg] Temporary origins In-Reply-To: <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> References: <20150624071546.GY49729@Vurt.local> <20150625162829.GG36186@cilantro.c4inet.net> <20150625.211712.495427159.he@uninett.no> <67505D3C-4601-44B4-ADC2-3ED0CB69179B@ripe.net> Message-ID: <20150709120346.GA30331@danton.fire-world.de> * Alex Band [2015-07-02 11:45]: > Thanks for sharing your experiences George. > > I'm curious to hear from our Community about what they think about > this mode of operation; simply create the route object on the > inetnum holder's authorisation alone, inform the ASN holder that it > was created and only remove the object if they object. > > It would simplify the authorisation model tremendously and save a > lot of frustration and customer support tickets. Hello Alex, I would support that. Could there be a mechanism to block "repeat offenders" from creating route: objects with my AS? I'm just envisioning an "edit war" of people adding a route object and me requesting it to be removed. Or am I just too paranoid/pesimistic? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From tim at ripe.net Mon Jul 13 16:33:22 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Mon, 13 Jul 2015 16:33:22 +0200 Subject: [db-wg] Release 1.80 deployed to production Message-ID: Dear working group, Release 1.80 was just deployed to production, introducing the following changes: = The ?changed:? attribute is now optional, marking phase 2 of deprecating changed. = The "referral-by" attribute in maintainer objects is now deprecated. Update on upcoming releases: Over the past weeks we have been making good progress on improving the integration of web updates with the Single Sign-On system. This will help improve the usability of web updates, but it will also help to reduce the dependency of incidental users of the database on MD5 passwords. Considering the recent trouble with old MD5 passwords on maintainers we believe that there is a lot of value in finishing this work as soon as possible. We are close to a working solution and we will deploy it to the RC environment over the coming weeks, before releasing this to the production environment. As soon as this is done we will get back to implementing phase 3 of deprecating changed (deprecate the "changed:" attribute itself), which we expect to be ready to be deployed to the RC environment by the end of August. Please let us know if you have any questions or comments, Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team From tim at ripe.net Mon Jul 13 17:17:27 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Mon, 13 Jul 2015 17:17:27 +0200 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> Message-ID: Dear working group, > On Jul 8, 2015, at 4:49 PM, Tim Bruijnzeels wrote: > > On Monday 13 July, the RIPE NCC will remove all RIPE Database maintainer MD5 passwords that have not been changed since November 2011. As announced we have now removed the passwords that have not changed since November 2011. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team From admin at support.od.ua Tue Jul 14 11:20:20 2015 From: admin at support.od.ua (Vladislav V. Prodan) Date: Tue, 14 Jul 2015 12:20:20 +0300 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> Message-ID: 2015-07-13 18:17 GMT+03:00 Tim Bruijnzeels : > Dear working group, > > > On Jul 8, 2015, at 4:49 PM, Tim Bruijnzeels wrote: > > > > On Monday 13 July, the RIPE NCC will remove all RIPE Database maintainer > MD5 passwords that have not been changed since November 2011. > > As announced we have now removed the passwords that have not changed since > November 2011. > Poor implementation of a good idea. Now expects a wave of applications for the restoration of access to mnt- objects. E-mail newsletter for these maintainer you tried to do? Where instructions to restore access? -- Vladislav V. Prodan System & Network Administrator support.od.ua -------------- next part -------------- An HTML attachment was scrubbed... URL: From mg at kapper.net Tue Jul 14 11:35:31 2015 From: mg at kapper.net (Martin Gollowitzer) Date: Tue, 14 Jul 2015 09:35:31 +0000 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> Message-ID: <2B805C4E31E6414897AD0A4966772EEC24EDC699@zeroone.hq.local> Hi, > Poor implementation of a good idea. I beg to differ. > Now expects a wave of applications for the restoration of access to mnt- objects. Well, the process is not too complicated. > E-mail newsletter for these maintainer you tried to do? The affected maintainers were contacted beforehand. We had one customer who contacted us about it. They didn't even know their password anymore, so the restoration process had to be done anyway. > Where instructions to restore access? See the database FAQ. ? All the best, Martin From gert at space.net Tue Jul 14 12:22:24 2015 From: gert at space.net (Gert Doering) Date: Tue, 14 Jul 2015 12:22:24 +0200 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> Message-ID: <20150714102224.GV67883@Space.Net> Hi, On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote: > E-mail newsletter for these maintainer you tried to do? > Where instructions to restore access? Maintainers *have* been contacted well in advance, with a simple web form to change their passwords provided. If people can't be bothered, they will notice now. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From hank at efes.iucc.ac.il Tue Jul 14 15:45:10 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 14 Jul 2015 16:45:10 +0300 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: <20150714102224.GV67883@Space.Net> References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> Message-ID: <5.1.1.6.2.20150714164342.002f1ce8@efes.iucc.ac.il> At 12:22 14/07/2015 +0200, Gert Doering wrote: >Hi, > >On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote: > > E-mail newsletter for these maintainer you tried to do? > > Where instructions to restore access? > >Maintainers *have* been contacted well in advance, with a simple web form >to change their passwords provided. Of the dozen or so maintainers I have access to, one had an old MD5. I got an email a few weeks ago, I changed the pswd, end of story. If you are now locked out, you have only yourself to blame. -Hank >If people can't be bothered, they will notice now. > >Gert Doering > -- NetMaster >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From tim at ripe.net Tue Jul 14 15:57:36 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Tue, 14 Jul 2015 15:57:36 +0200 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: <20150714102224.GV67883@Space.Net> References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> <20150714102224.GV67883@Space.Net> Message-ID: Dear working group, > On Jul 14, 2015, at 12:22 PM, Gert Doering wrote: > > Hi, > > On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote: >> E-mail newsletter for these maintainer you tried to do? >> Where instructions to restore access? > > Maintainers *have* been contacted well in advance, with a simple web form > to change their passwords provided. We contacted 7100 active maintainers, meaning maintainers that had made any successful update over the last 12 months. Out of this group 5709 (80%) have reset their password. The remaining maintainers can use the normal maintainer reset process here: https://apps.db.ripe.net/change-auth/#/ As communicated on 17 June inactive maintainers were not contacted: > Note that we do not plan to contact inactive maintainers individually beforehand, or send notifications about this change. Instead we will include a remark in these maintainers explaining why these maintainers were locked and refer to the "forgot mntner password process": https://apps.db.ripe.net/change-auth > > The reason for this is simple. We are simply not able to handle the additional load of supporting password resets for 20,000 inactive maintainers. We can and will however, deal with access recovery requests for these maintainer as needed. Note that many inactive will have forgotten their passwords, so the reset process cannot be used by them. Also many of these maintainers are not actively used, and therefore resetting the passwords for them is not as time critical. Considering that we would not have been able to deal with the load of performing due diligence checks for ALL these maintainers, and the risk we were running with the old password hashes surfacing, we could not postpone and buy more time either. Therefore we opted for helping this group on a case by case basis and spreading the load. Kind regards, Tim Bruijnzeels > > If people can't be bothered, they will notice now. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From admin at support.od.ua Tue Jul 14 16:27:15 2015 From: admin at support.od.ua (Vladislav V. Prodan) Date: Tue, 14 Jul 2015 17:27:15 +0300 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods In-Reply-To: References: <20150507152925.29626a3d@casual> <062B28F7-DFE9-4814-8860-90F7E817C1F3@6core.net> <555CF0C1.3050502@danysek.cz> <32767077-31C6-4C81-A726-7BA44EFC90D5@ripe.net> <75F19A82-892A-4533-966D-4AC0F7FE6BDA@ripe.net> <20150714102224.GV67883@Space.Net> Message-ID: 2015-07-14 16:57 GMT+03:00 Tim Bruijnzeels : > Dear working group, > > > On Jul 14, 2015, at 12:22 PM, Gert Doering wrote: > > > > Hi, > > > > On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote: > >> E-mail newsletter for these maintainer you tried to do? > >> Where instructions to restore access? > > > > Maintainers *have* been contacted well in advance, with a simple web form > > to change their passwords provided. > > We contacted 7100 active maintainers, meaning maintainers that had made > any successful update over the last 12 months. Out of this group 5709 (80%) > have reset their password. Ok, your position is understandable. It could not be registered in ripedb. In the past and it was not just sign up with a clean slate, without the mnt-by. And now the maintainer of discrimination inactivity. Well, do not tell me it was almost 4 years writable controlled by AS. Now it will be easier to divert the issue to LIR, let it manually registers a new record for the maintainer for their customers. -- Vladislav V. Prodan System & Network Administrator support.od.ua -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at ripe.net Thu Jul 16 15:33:31 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 16 Jul 2015 15:33:31 +0200 Subject: [db-wg] Release 1.80.1 deployed: warning users on failed update/delete, if maintainers had passwords removed Message-ID: <1747765A-D5FA-4E4C-822B-17DA402CC787@ripe.net> Dear working group, We have just deployed whois release 1.80.1 to production. We have seen some cases where users were not aware that passwords had been removed from their maintainer, and they would only get an "authorisation failed" error. To help these users debug this issue better we now also include the following warning in case one or more of the maintainers had any passwords removed: "MD5 passwords older than November 2011 were removed for one or more maintainers of this object, see: https://www.ripe.net/removed2011pw" Example case (used by us for testing): > The following object(s) were found to have ERRORS: > > --- > Create FAILED: [person] AP1-TEST Another Person > > person: Another Person > address: Some Address > phone: +12 345 678 90 > nic-hdl: AP1-TEST > mnt-by: OWNER-MNT > source: TEST > > ***Error: Authorisation for [person] AP1-TEST failed > using "mnt-by:" > not authenticated by: OWNER-MNT > > ***Warning: MD5 passwords older than November 2011 were removed for one or more > maintainers of this object, see: https://www.ripe.net/removed2011pw Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team From job at ntt.net Sun Jul 19 16:59:39 2015 From: job at ntt.net (Job Snijders) Date: Sun, 19 Jul 2015 16:59:39 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 Message-ID: <20150719145939.GA50062@Vurt.local> Dear best-db-working-group-in-the-world! I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-) I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage. Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details. Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest. Kind regards, Job From Piotr.Strzyzewski at polsl.pl Sun Jul 19 20:36:03 2015 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sun, 19 Jul 2015 20:36:03 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150719145939.GA50062@Vurt.local> References: <20150719145939.GA50062@Vurt.local> Message-ID: <20150719183603.GA21258@hydra.ck.polsl.pl> On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: > Let me know if you are interested in attending this ad-hoc db-wg > meeting. No worries if you aren't around this time, we'll see each other > at RIPE71 in Budapest. I hope, you mean Bucharest. ;-) Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From job at ntt.net Mon Jul 20 13:48:17 2015 From: job at ntt.net (Job Snijders) Date: Mon, 20 Jul 2015 13:48:17 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150719183603.GA21258@hydra.ck.polsl.pl> References: <20150719145939.GA50062@Vurt.local> <20150719183603.GA21258@hydra.ck.polsl.pl> Message-ID: <20150720114817.GD50062@Vurt.local> On Sun, Jul 19, 2015 at 08:36:03PM +0200, Piotr Strzyzewski wrote: > On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: > > Let me know if you are interested in attending this ad-hoc db-wg > > meeting. No worries if you aren't around this time, we'll see each other > > at RIPE71 in Budapest. > > I hope, you mean Bucharest. ;-) Oops! In my defense, the letters are so close to each other on this keyboard ;-) From job at ntt.net Mon Jul 20 16:29:03 2015 From: job at ntt.net (Job Snijders) Date: Mon, 20 Jul 2015 16:29:03 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150719145939.GA50062@Vurt.local> References: <20150719145939.GA50062@Vurt.local> Message-ID: <20150720142903.GB58281@dhcp-a1b1.meeting.ietf.org> On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: > Dear best-db-working-group-in-the-world! > > I was looking through the IETF93 attendees list and noticed quite a few > familiar names are attending the IETF meeting in Prague this week! :-) > > I'd love to catch up with you and discuss some of the current db-wg > topics face to face, possibly while holding a sparkling beverage. > > Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to > 19:00. I'll arrange a room or spot and follow-up with details. We are meeting at the back of the "ZEST BAR" on the lobby floor. Tim was kind enough to prepare a small list of topics. Kind regards, Job From tim at ripe.net Mon Jul 20 17:04:02 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Mon, 20 Jul 2015 17:04:02 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150720142903.GB58281@dhcp-a1b1.meeting.ietf.org> References: <20150719145939.GA50062@Vurt.local> <20150720142903.GB58281@dhcp-a1b1.meeting.ietf.org> Message-ID: > On Jul 20, 2015, at 4:29 PM, Job Snijders wrote: > > On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: >> Dear best-db-working-group-in-the-world! >> >> I was looking through the IETF93 attendees list and noticed quite a few >> familiar names are attending the IETF meeting in Prague this week! :-) >> >> I'd love to catch up with you and discuss some of the current db-wg >> topics face to face, possibly while holding a sparkling beverage. >> >> Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to >> 19:00. I'll arrange a room or spot and follow-up with details. > > We are meeting at the back of the "ZEST BAR" on the lobby floor. > > Tim was kind enough to prepare a small list of topics. Sure, I am around as well and would love the opportunity to talk about these topics: = route object authorization = RPSL maintainer on out of region route objects = personalized authentication But of course discussion does not need to be limited to this. Kind regards, Tim > > Kind regards, > > Job > From ripedenis at yahoo.co.uk Mon Jul 20 17:02:26 2015 From: ripedenis at yahoo.co.uk (denis) Date: Mon, 20 Jul 2015 17:02:26 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150720142903.GB58281@dhcp-a1b1.meeting.ietf.org> References: <20150719145939.GA50062@Vurt.local> <20150720142903.GB58281@dhcp-a1b1.meeting.ietf.org> Message-ID: <55AD0D82.3080109@yahoo.co.uk> On 20/07/2015 16:29, Job Snijders wrote: > On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: >> Dear best-db-working-group-in-the-world! >> >> I was looking through the IETF93 attendees list and noticed quite a few >> familiar names are attending the IETF meeting in Prague this week! :-) >> >> I'd love to catch up with you and discuss some of the current db-wg >> topics face to face, possibly while holding a sparkling beverage. >> >> Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to >> 19:00. I'll arrange a room or spot and follow-up with details. > > We are meeting at the back of the "ZEST BAR" on the lobby floor. > > Tim was kind enough to prepare a small list of topics. ...and the topics are? (for the benefit of those who won't be there..it is nice to know what is on the radar) cheers denis > > Kind regards, > > Job > From nigel at titley.com Mon Jul 20 17:34:55 2015 From: nigel at titley.com (Nigel Titley) Date: Mon, 20 Jul 2015 16:34:55 +0100 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150719145939.GA50062@Vurt.local> References: <20150719145939.GA50062@Vurt.local> Message-ID: <55AD151F.9060809@titley.com> On 19/07/15 15:59, Job Snijders wrote: > Dear best-db-working-group-in-the-world! > > I was looking through the IETF93 attendees list and noticed quite a few > familiar names are attending the IETF meeting in Prague this week! :-) > > I'd love to catch up with you and discuss some of the current db-wg > topics face to face, possibly while holding a sparkling beverage. > > Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to > 19:00. I'll arrange a room or spot and follow-up with details. > > Let me know if you are interested in attending this ad-hoc db-wg > meeting. No worries if you aren't around this time, we'll see each other > at RIPE71 in Budapest. Please accept my apologies. Although I'll be at IETF, it will only be on a 1-day pass on the following day (and I don't arrive until just before midnight). Nigel From job at ntt.net Sun Jul 26 15:55:57 2015 From: job at ntt.net (Job Snijders) Date: Sun, 26 Jul 2015 15:55:57 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150719145939.GA50062@Vurt.local> References: <20150719145939.GA50062@Vurt.local> Message-ID: <20150726135557.GC33353@Vurt.local> On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: > I'd love to catch up with you and discuss some of the current db-wg > topics face to face, possibly while holding a sparkling beverage. > > Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to > 19:00. I'll arrange a room or spot and follow-up with details. My notes: Attending: Tim Kleefass, Job Snijders, Tim Bruijnzeels, Shane Kerr, Andy Newton, Ruediger Volk * Route object authorisation - rv@ objects to allowing anybody to create a route-object with his own origin asn. Shane Kerr in turn suggests to make the new, relaxed mechanism something to 'opt-out' from (very interesting!) * RPSL utf8/whitespace - someone needs to create a list of all attributes and their expected encoding - by default the output of the whois.ripe.net server should be old-style ASCII (and through a %command you should be able to request the utf8 output) * RPSL maintainer on out of region route objects - add business rule that no object can reference the RPSL maintainer (splot out error message) - remove references to the RPSL maintainer on objects - in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit. Kind regards, Job From ripedenis at yahoo.co.uk Sun Jul 26 19:39:36 2015 From: ripedenis at yahoo.co.uk (denis) Date: Sun, 26 Jul 2015 19:39:36 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150726135557.GC33353@Vurt.local> References: <20150719145939.GA50062@Vurt.local> <20150726135557.GC33353@Vurt.local> Message-ID: <55B51B58.1060100@yahoo.co.uk> Hi Job Thanks for the update. On 26/07/2015 15:55, Job Snijders wrote: > On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote: >> I'd love to catch up with you and discuss some of the current db-wg >> topics face to face, possibly while holding a sparkling beverage. >> >> Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to >> 19:00. I'll arrange a room or spot and follow-up with details. > > My notes: > > Attending: Tim Kleefass, Job Snijders, Tim Bruijnzeels, Shane Kerr, Andy Newton, Ruediger Volk > > * Route object authorisation > - rv@ objects to allowing anybody to create a route-object with his > own origin asn. Shane Kerr in turn suggests to make the new, > relaxed mechanism something to 'opt-out' from (very interesting!) > > * RPSL utf8/whitespace > - someone needs to create a list of all attributes and their > expected encoding > - by default the output of the whois.ripe.net server should be > old-style ASCII (and through a %command you should be able to > request the utf8 output) > > * RPSL maintainer on out of region route objects > - add business rule that no object can reference the RPSL maintainer > (splot out error message) Finally :) But this rule needs an exception to allow objects maintained by the RIPE NCC to reference this MNTNER. Many objects need to reference it as the "mnt-routes:" including 0/0, 0::, all AS-BLOCK objects covering out of region ranges of ASNs and any placeholder INET(6)NUM objects covering out of region ranges of address space. > - remove references to the RPSL maintainer on objects In the interests of user friendliness I would hope you will contact the maintainers of all these objects first and allow them time to replace the references with their own MNTNER object. Otherwise you will create another set of locked objects where the maintainers will eventually have to contact Customer Services to gain access again. > - in essence re-introduce 'auth: none' for out of region objects, in > doing so make the rpsl-maintainer implicit. This is not a good idea. This 'implicitness' requires changes to the software to create exceptions for authorisation on creation of certain object types. The authorisation software is already nightmarishly complex. The public password avoids the need for further complexity by allowing these object creations to follow the normal path for authorisation. cheers denis > > Kind regards, > > Job > From job at ntt.net Sun Jul 26 20:04:00 2015 From: job at ntt.net (Job Snijders) Date: Sun, 26 Jul 2015 20:04:00 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <55B51B58.1060100@yahoo.co.uk> References: <20150719145939.GA50062@Vurt.local> <20150726135557.GC33353@Vurt.local> <55B51B58.1060100@yahoo.co.uk> Message-ID: <20150726180400.GD33353@Vurt.local> On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote: > > - in essence re-introduce 'auth: none' for out of region > > objects, in doing so make the rpsl-maintainer implicit. > > This is not a good idea. This 'implicitness' requires changes to the > software to create exceptions for authorisation on creation of certain > object types. The authorisation software is already nightmarishly > complex. I don't agree with your assessment. Don't forget that the responsibility for the Whois software code quality lays primiarily with RIPE NCC staff. I am confident they'll inform us about potential code complexity issues. Kind regards, Job From snash at arbor.net Mon Jul 27 12:45:30 2015 From: snash at arbor.net (snash) Date: Mon, 27 Jul 2015 10:45:30 +0000 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150726135557.GC33353@Vurt.local> Message-ID: Thanks to Job for reporting this discussion, so that it has reached the mailing list. > * Route object authorisation > - rv@ objects to allowing anybody to create a route-object with his > own origin asn. Does this relate to our mailing list discussion about registering new OriginAS? Can we please have some information about the nature of the objection? Perhaps the reporting is abbreviated, but the proposal so far is NOT "to allowing anybody to create a route-object". The registered "owner" of the address space is the only party entitled to add an authorised OriginAS. If the objection stands, I think it is the first, so we really need to understand it better. Steve Nash From ripedenis at yahoo.co.uk Mon Jul 27 18:13:27 2015 From: ripedenis at yahoo.co.uk (denis) Date: Mon, 27 Jul 2015 18:13:27 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150726180400.GD33353@Vurt.local> References: <20150719145939.GA50062@Vurt.local> <20150726135557.GC33353@Vurt.local> <55B51B58.1060100@yahoo.co.uk> <20150726180400.GD33353@Vurt.local> Message-ID: <55B658A7.7070106@yahoo.co.uk> Hi Job On 26/07/2015 20:04, Job Snijders wrote: > On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote: >>> - in essence re-introduce 'auth: none' for out of region >>> objects, in doing so make the rpsl-maintainer implicit. >> >> This is not a good idea. This 'implicitness' requires changes to the >> software to create exceptions for authorisation on creation of certain >> object types. The authorisation software is already nightmarishly >> complex. > > I don't agree with your assessment. Don't forget that the responsibility > for the Whois software code quality lays primiarily with RIPE NCC staff. > I am confident they'll inform us about potential code complexity issues. I understand where you are coming from. But keep in mind that the software is open source so anyone in the community can study this code (if they want to) and appreciate the complexity that already exists in both the software and data model. Also keep in mind the way this process works. The community asks for something, generally without any regard to how it will be implemented. The RIPE NCC has a lot of wonderful guys who like to give the community what they ask for. And as Shane often says, "it's software, you can do anything you like with software". Of course he is right, but there is always a cost. Given that the community/membership is, to a large extent, reluctant to even discuss the issue of simplifying the data model and bringing the software design into the 21st century, things just get more complex over time. Then the whole software has to be re-written again, as they have done twice already, just to keep it maintainable but without making any substantial improvements. I also think re-introducing and documenting the concept of "auth:none", after it was deprecated about 12 years ago, and at a time when security is a regular discussion topic, is bad PR for this industry. I know the public password achieves the same result, but at least with the password you have to know what to do with it and 'do something'. With "auth:none" you do nothing and things 'just work'. We should be fixing the issue of the public password not making cosmetic changes like this. cheers denis > > Kind regards, > > Job > From job at ntt.net Mon Jul 27 18:21:19 2015 From: job at ntt.net (Job Snijders) Date: Mon, 27 Jul 2015 18:21:19 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <55B658A7.7070106@yahoo.co.uk> References: <20150719145939.GA50062@Vurt.local> <20150726135557.GC33353@Vurt.local> <55B51B58.1060100@yahoo.co.uk> <20150726180400.GD33353@Vurt.local> <55B658A7.7070106@yahoo.co.uk> Message-ID: <20150727162119.GE43978@Vurt.local> On Mon, Jul 27, 2015 at 06:13:27PM +0200, denis wrote: > On 26/07/2015 20:04, Job Snijders wrote: > >On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote: > >>> - in essence re-introduce 'auth: none' for out of region > >>> objects, in doing so make the rpsl-maintainer implicit. > >> > >>This is not a good idea. This 'implicitness' requires changes to the > >>software to create exceptions for authorisation on creation of certain > >>object types. The authorisation software is already nightmarishly > >>complex. > > > >I don't agree with your assessment. Don't forget that the responsibility > >for the Whois software code quality lays primiarily with RIPE NCC staff. > >I am confident they'll inform us about potential code complexity issues. > > I understand where you are coming from. But keep in mind that the software > is open source so anyone in the community can study this code (if they want > to) and appreciate the complexity that already exists in both the software > and data model. > > Also keep in mind the way this process works. The community asks for > something, generally without any regard to how it will be implemented. The > RIPE NCC has a lot of wonderful guys who like to give the community what > they ask for. And as Shane often says, "it's software, you can do anything > you like with software". Of course he is right, but there is always a cost. > > Given that the community/membership is, to a large extent, reluctant to even > discuss the issue of simplifying the data model and bringing the software > design into the 21st century, things just get more complex over time. Then > the whole software has to be re-written again, as they have done twice > already, just to keep it maintainable but without making any substantial > improvements. > > I also think re-introducing and documenting the concept of "auth:none", > after it was deprecated about 12 years ago, and at a time when security is a > regular discussion topic, is bad PR for this industry. I know the public > password achieves the same result, but at least with the password you have > to know what to do with it and 'do something'. With "auth:none" you do > nothing and things 'just work'. We should be fixing the issue of the public > password not making cosmetic changes like this. It should be noted that "auth: none" is not a proposal of mine, merely a short handed way of writing down what could be a method in the context of the RPSL maintainer. IMHO slapping the public "RPSL" password on something might as well don't require anything. I do not wish to reintroduce "auth: none"! But I'd like to see better auth model of out of region resources in the RIPE database. I guess I should have written something like "remove RPSL maintainer and use implicit authorisation" instead of "auth: none" :-) Kind regards, Job From ripedenis at yahoo.co.uk Mon Jul 27 18:28:25 2015 From: ripedenis at yahoo.co.uk (denis) Date: Mon, 27 Jul 2015 18:28:25 +0200 Subject: [db-wg] ad-hoc RIPE db-wg meeting at IETF93 In-Reply-To: <20150727162119.GE43978@Vurt.local> References: <20150719145939.GA50062@Vurt.local> <20150726135557.GC33353@Vurt.local> <55B51B58.1060100@yahoo.co.uk> <20150726180400.GD33353@Vurt.local> <55B658A7.7070106@yahoo.co.uk> <20150727162119.GE43978@Vurt.local> Message-ID: <55B65C29.20101@yahoo.co.uk> On 27/07/2015 18:21, Job Snijders wrote: > On Mon, Jul 27, 2015 at 06:13:27PM +0200, denis wrote: >> On 26/07/2015 20:04, Job Snijders wrote: >>> On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote: >>>>> - in essence re-introduce 'auth: none' for out of region >>>>> objects, in doing so make the rpsl-maintainer implicit. >>>> >>>> This is not a good idea. This 'implicitness' requires changes to the >>>> software to create exceptions for authorisation on creation of certain >>>> object types. The authorisation software is already nightmarishly >>>> complex. >>> >>> I don't agree with your assessment. Don't forget that the responsibility >>> for the Whois software code quality lays primiarily with RIPE NCC staff. >>> I am confident they'll inform us about potential code complexity issues. >> >> I understand where you are coming from. But keep in mind that the software >> is open source so anyone in the community can study this code (if they want >> to) and appreciate the complexity that already exists in both the software >> and data model. >> >> Also keep in mind the way this process works. The community asks for >> something, generally without any regard to how it will be implemented. The >> RIPE NCC has a lot of wonderful guys who like to give the community what >> they ask for. And as Shane often says, "it's software, you can do anything >> you like with software". Of course he is right, but there is always a cost. >> >> Given that the community/membership is, to a large extent, reluctant to even >> discuss the issue of simplifying the data model and bringing the software >> design into the 21st century, things just get more complex over time. Then >> the whole software has to be re-written again, as they have done twice >> already, just to keep it maintainable but without making any substantial >> improvements. >> >> I also think re-introducing and documenting the concept of "auth:none", >> after it was deprecated about 12 years ago, and at a time when security is a >> regular discussion topic, is bad PR for this industry. I know the public >> password achieves the same result, but at least with the password you have >> to know what to do with it and 'do something'. With "auth:none" you do >> nothing and things 'just work'. We should be fixing the issue of the public >> password not making cosmetic changes like this. > > It should be noted that "auth: none" is not a proposal of mine, merely a > short handed way of writing down what could be a method in the context > of the RPSL maintainer. IMHO slapping the public "RPSL" password on > something might as well don't require anything. noted :) > > I do not wish to reintroduce "auth: none"! But I'd like to see better > auth model of out of region resources in the RIPE database. I guess I > should have written something like "remove RPSL maintainer and use > implicit authorisation" instead of "auth: none" :-) agreed, but I still think any changes like this are cosmetic and pointless. cheers denis > > Kind regards, > > Job > From jan at trick77.com Mon Jul 27 18:41:29 2015 From: jan at trick77.com (Jan Saner) Date: Mon, 27 Jul 2015 18:41:29 +0200 Subject: [db-wg] NCC still enforcing descr: content Message-ID: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> Hello Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I?m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html Quote: ----------------------------------------------------------- "> When will this change go into effect? We were thinking of mid April, for two reasons: 1) This gives the working group enough time to comment. 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." ----------------------------------------------------------- I personally know a case where the NCC went as far as to ignore German ?umlauts? in the name and deliberately spell it wrong in the descr: field of the guy?s AUT-NUM object. When he tried to set it right (ae (?) instead of a), the NCC reverted the change. Then there?s a case where someone tried to remove his middle name from the descr: field ?> reverted. Another post on the same subject: https://www.ripe.net/ripe/mail/archives/members-discuss/2015-June/001737.html Looks like there?s still a lot of energy wasted in those descr fields now that the org pointer is mandatory. Cheers From tim at ripe.net Tue Jul 28 18:01:29 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Tue, 28 Jul 2015 18:01:29 +0200 Subject: [db-wg] NCC still enforcing descr: content In-Reply-To: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> References: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> Message-ID: <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> Dear Jan, Working Group, > On Jul 27, 2015, at 6:41 PM, Jan Saner wrote: > > Hello > > Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I?m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: > > https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html > > Quote: > ----------------------------------------------------------- > "> When will this change go into effect? > > We were thinking of mid April, for two reasons: > > 1) This gives the working group enough time to comment. > > 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." > ----------------------------------------------------------- Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-new-functionality.pdf We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May). When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem. Option a: Leave existing cases, "descr:" mandatory, update request forms ======================================================================== We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line. We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go. Option b: Clean up existing cases, "descr:" optional ===================================================== On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object. Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful. Option c: Clean up existing cases, "descr:" mandatory, update request forms =========================================================================== A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided. This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information. I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC From job at ntt.net Wed Jul 29 10:35:53 2015 From: job at ntt.net (Job Snijders) Date: Wed, 29 Jul 2015 10:35:53 +0200 Subject: [db-wg] NCC still enforcing descr: content In-Reply-To: <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> References: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> Message-ID: <20150729083553.GB90017@Vurt.local> On Tue, Jul 28, 2015 at 06:01:29PM +0200, Tim Bruijnzeels wrote: > > On Jul 27, 2015, at 6:41 PM, Jan Saner wrote: > > Since the NCC still seems to heavy-handedly revert changes to descr: > > in AUT-NUM, INETNUM and INETNUM6 I?m wondering what the current > > status of the implementation mentioned by Tim in a post to this list > > from February is: > > > > https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html > > Well, in short I misjudged the effort needed for this, and since then > I presented an update on this at the RIPE meeting, see slide 4 here: > https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-new-functionality.pdf > > We are *nearly* done. We have a bit over 100 aut-num objects to work > on (as compared to 2000 in May). > > When this is fully done, we can present an implementation plan for > this soon, within a few weeks. Before we do so, I would like to ask > the working group for direction on the following. Because sadly, > stopping enforcing this is not as trivial as it might seem. > > Option a: Leave existing cases, "descr:" mandatory, update request forms > ======================================================================== Option A sounds simplest to me, I am confident people will continue to update the "descr:" to align it with reality in a meaningful way. Kind regards, Job From jan at trick77.com Thu Jul 30 21:19:17 2015 From: jan at trick77.com (Jan Saner) Date: Thu, 30 Jul 2015 21:19:17 +0200 Subject: [db-wg] NCC still enforcing descr: content In-Reply-To: <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> References: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> Message-ID: <43919F21-6DAB-4BEC-BD7D-6910688E3557@trick77.com> Hello Tim, Like Job, I?d also appreciate option A. Cheers, Jan > On 28 Jul 2015, at 18:01, Tim Bruijnzeels wrote: > > Dear Jan, Working Group, > > >> On Jul 27, 2015, at 6:41 PM, Jan Saner wrote: >> >> Hello >> >> Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I?m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: >> >> https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html >> >> Quote: >> ----------------------------------------------------------- >> "> When will this change go into effect? >> >> We were thinking of mid April, for two reasons: >> >> 1) This gives the working group enough time to comment. >> >> 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." >> ----------------------------------------------------------- > > Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: > https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-new-functionality.pdf > > We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May). > > When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem. > > > Option a: Leave existing cases, "descr:" mandatory, update request forms > ======================================================================== > > We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line. > > We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go. > > > Option b: Clean up existing cases, "descr:" optional > ===================================================== > On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object. > > Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful. > > > Option c: Clean up existing cases, "descr:" mandatory, update request forms > =========================================================================== > A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided. > > This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information. > > I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback. > > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC From tim at haitabu.net Fri Jul 31 08:56:42 2015 From: tim at haitabu.net (Tim Kleefass) Date: Fri, 31 Jul 2015 08:56:42 +0200 Subject: [db-wg] NCC still enforcing descr: content In-Reply-To: <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> References: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> Message-ID: <55BB1C2A.80901@haitabu.net> Hi Tim et al, On 28.07.2015 18:01, Tim Bruijnzeels wrote: > Option a: Leave existing cases, "descr:" mandatory, update request forms > ======================================================================== > > We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line. > > We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go. I like the part "Leave existing cases". Looking at different inetnums it seams good to have a "descr:" tag beside the "netname:", but I don't have a strong opinion on that. Cheers, Tim From nick at inex.ie Fri Jul 31 12:47:26 2015 From: nick at inex.ie (Nick Hilliard) Date: Fri, 31 Jul 2015 11:47:26 +0100 Subject: [db-wg] NCC still enforcing descr: content In-Reply-To: <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> References: <963A7D74-2963-4EEE-9E66-080F992F98A3@trick77.com> <1540FD04-5DF4-4B39-BEE1-6A025C403692@ripe.net> Message-ID: <55BB523E.2000508@inex.ie> Tim, option B seems like a cleaner long term fix. The org: name in the descr: field is currently well-structured and could be removed easily without affecting any of the other lines. After all, it was inserted by the RIPE NCC in a mass-db operation in the first place. Why is it troublesome to remove again, now that we have a proper fix in place, i.e. mandatory dependence on the org: object? Using descr: for mandatory information should never have been anything more than a short term workaround to a schema problem. Nick On 28/07/2015 17:01, Tim Bruijnzeels wrote: > Dear Jan, Working Group, > > >> On Jul 27, 2015, at 6:41 PM, Jan Saner wrote: >> >> Hello >> >> Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I?m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: >> >> https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html >> >> Quote: >> ----------------------------------------------------------- >> "> When will this change go into effect? >> >> We were thinking of mid April, for two reasons: >> >> 1) This gives the working group enough time to comment. >> >> 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." >> ----------------------------------------------------------- > > Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: > https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-new-functionality.pdf > > We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May). > > When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem. > > > Option a: Leave existing cases, "descr:" mandatory, update request forms > ======================================================================== > > We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line. > > We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go. > > > Option b: Clean up existing cases, "descr:" optional > ===================================================== > On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object. > > Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful. > > > Option c: Clean up existing cases, "descr:" mandatory, update request forms > =========================================================================== > A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided. > > This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information. > > I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback. > > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC > -- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 5313339 52 Lower Sandwith St | INEX - Internet Neutral | Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie