Re: [GROW] Discourage asdot+/asdot?
On Mon, Aug 13, 2018 at 02:29:37PM -0400, Warren Kumari wrote:
> Seriously, 6 different ways to notate a MAC address...
> Nope, this isn't actionable, but thank you for letting me vent!
TBH, RFC 6021:
typedef mac-address {
type string {
pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
}
description
"The mac-address type represents an IEEE 802 MAC address.
The canonical representation uses lowercase characters.
In the value set and its semantics, this type is equivalent
to the MacAddress textual convention of the SMIv2.";
reference
"IEEE 802: IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture
RFC 2579: Textual Conventions for SMIv2";
}
So, the fix is to use a cli one step closer to yang. :-)
-- Jeff
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
On Mon, Aug 13, 2018 at 7:33 AM Nick Hilliard wrote: > > Daniel Shaw wrote on 10/08/2018 08:29: > > I think that on closer examination you may find the AFRINIC whois also > > changed around the same timeframe, perhaps a year later. It seems that > > there may be one (or possibly some other very small number of) test > > objects that did not get converted/clean-up. > > my mistake - afrinic changed to asplain some time in 2012. The AS-TEST > object predates this change (and isn't operationally relevant anyway). This may be (ok, is) off-topic, but this has always really annoyed me: wkumari@Dulles-rtr:~$ show arp Address HWtype HWaddress Flags Mask Iface 192.168.0.122(incomplete) eth1 192.168.0.187ether 00:e0:86:02:da:0b C eth1 192.168.0.188ether 20:3c:ae:5a:dd:4d C eth1 vs: Dulles-Switch#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.0.320 a866.7f04.4f92 ARPA Vlan1 Internet 192.168.0.35- 0015.621c.6540 ARPA Vlan1 vs: TestSwitch#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.0.320 A866.7F04.4F92 ARPA Vlan1 Internet 192.168.0.35- 0015.621F.6540 ARPA Vlan1 vs: About System Model Number : AP7900 Serial Number : ZA0644029848 NMC Serial Number : ZA0644028843 Manufacture Date : 10/29/2006 Hardware Revision : B2 MAC Address : 00 C0 B7 2C 17 C9 Flash Type: AMD A29DL322DB vs: Network Statistics General Hardware Address:001321C2DE82 HP JetDirect:J7949E Firmware Version:V.33.19 vs: LAN1 MAC address00-11-32-16-F7-6F Seriously, 6 different ways to notate a MAC address... Nope, this isn't actionable, but thank you for letting me vent! W > > Nick > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
Daniel Shaw wrote on 10/08/2018 08:29: I think that on closer examination you may find the AFRINIC whois also changed around the same timeframe, perhaps a year later. It seems that there may be one (or possibly some other very small number of) test objects that did not get converted/clean-up. my mistake - afrinic changed to asplain some time in 2012. The AS-TEST object predates this change (and isn't operationally relevant anyway). Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
Gert Doering wrote on 06/08/2018 23:08: It totally wrecked my nice AS3.3 into an ugly large number, but there was strong enough pushing that I was overruled. asdot was something that seemed like a good idea until the day that someone tried to use it in production :-| Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
this was a major war some time back. it might be fun to do it sgain. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
On Mon, 6 Aug 2018 at 22:08, Gert Doering wrote: > On Mon, Aug 06, 2018 at 08:55:47PM +0200, Job Snijders wrote: > > If people agree that a doc discouraging the use of asdot should exist, > > please let me know. > > Nick might remember where the push came from that made "RIPE" (the > community, the NCC, the RIPE DB) change from ASDOT to ASPLAIN. > > It totally wrecked my nice AS3.3 into an ugly large number, but there > was strong enough pushing that I was overruled. So, documents, minutes, > proposals should exist. Vanity should never be a priority :-) Job > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
Hi, On Mon, Aug 06, 2018 at 08:55:47PM +0200, Job Snijders wrote: > If people agree that a doc discouraging the use of asdot should exist, > please let me know. Nick might remember where the push came from that made "RIPE" (the community, the NCC, the RIPE DB) change from ASDOT to ASPLAIN. It totally wrecked my nice AS3.3 into an ugly large number, but there was strong enough pushing that I was overruled. So, documents, minutes, proposals should exist. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
Job Snijders wrote on 06/08/2018 20:35: I'm not the biggest fan of that philosophy. Especially because in the milions of objecst that exist in the combined IRR databases, it appears only four of them have something with ASDOT in the wrong place. right, you didn't mention that the 4 affected objects were the only objects affected across all the main irrdbs. If this is the case, then there is no reason to support asdot. Throw an error and continue processing at the next object. It's not worth complicating the code for just 4 objects, which will almost certainly disappear the next time they are updated. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
On Mon, 6 Aug 2018 at 20:53, Christopher Morrow < christopher.mor...@gmail.com> wrote: > > > On Mon, Aug 6, 2018 at 10:36 AM Job Snijders wrote: > >> On Mon, Aug 06, 2018 at 01:26:41PM -0400, Jeffrey Haas wrote: >> > > On Aug 6, 2018, at 8:20 AM, Nick Hilliard wrote: >> > > >> > > Job Snijders wrote on 06/08/2018 14:22> >> > >> RFC 5396 https://tools.ietf.org/html/rfc5396 described the "asdot+" >> > >> and "asdot" representation formats for AS numbers. I'd personally >> > >> prefer a single canonical way to represent ASNs (asplain), and >> > >> while RFC 5396 proposes the adoption of a decimal value notation >> > >> 'asplain', I don't think there is a document actively discouraging >> > >> the use of asdot and asdot+ We've come across asdot+ notation in >> > >> strange places such as RPSL, and I'm not yet sure how to proceed >> > >> https://github.com/irrdnet/irrd4/issues/48 >> > > >> > > Be liberal in what you accept, and conservative in what you send. >> >> I'm not the biggest fan of that philosophy. Especially because in the >> milions of objecst that exist in the combined IRR databases, it appears >> only four of them have something with ASDOT in the wrong place. >> >> > "hi $USEROFASDOTWRONGLY please do everyone a flavor and switch your > $ASDOTMESS to $ASPLAINSANITY, kthxbi!" > > you could do that, right? and educate to the plan you like ? :) > > (yes, this doesn't solve your larger problem of the next bad-user, which > your proposed writeup might help) > Yes, getting the four objects fixed isn’t too hard. If people agree that a doc discouraging the use of asdot should exist, please let me know. Kind regards, Job > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
On Mon, Aug 6, 2018 at 10:36 AM Job Snijders wrote: > On Mon, Aug 06, 2018 at 01:26:41PM -0400, Jeffrey Haas wrote: > > > On Aug 6, 2018, at 8:20 AM, Nick Hilliard wrote: > > > > > > Job Snijders wrote on 06/08/2018 14:22> > > >> RFC 5396 https://tools.ietf.org/html/rfc5396 described the "asdot+" > > >> and "asdot" representation formats for AS numbers. I'd personally > > >> prefer a single canonical way to represent ASNs (asplain), and > > >> while RFC 5396 proposes the adoption of a decimal value notation > > >> 'asplain', I don't think there is a document actively discouraging > > >> the use of asdot and asdot+ We've come across asdot+ notation in > > >> strange places such as RPSL, and I'm not yet sure how to proceed > > >> https://github.com/irrdnet/irrd4/issues/48 > > > > > > Be liberal in what you accept, and conservative in what you send. > > I'm not the biggest fan of that philosophy. Especially because in the > milions of objecst that exist in the combined IRR databases, it appears > only four of them have something with ASDOT in the wrong place. > > "hi $USEROFASDOTWRONGLY please do everyone a flavor and switch your $ASDOTMESS to $ASPLAINSANITY, kthxbi!" you could do that, right? and educate to the plan you like ? :) (yes, this doesn't solve your larger problem of the next bad-user, which your proposed writeup might help) -chris ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
On Mon, Aug 06, 2018 at 01:26:41PM -0400, Jeffrey Haas wrote: > > On Aug 6, 2018, at 8:20 AM, Nick Hilliard wrote: > > > > Job Snijders wrote on 06/08/2018 14:22> > >> RFC 5396 https://tools.ietf.org/html/rfc5396 described the "asdot+" > >> and "asdot" representation formats for AS numbers. I'd personally > >> prefer a single canonical way to represent ASNs (asplain), and > >> while RFC 5396 proposes the adoption of a decimal value notation > >> 'asplain', I don't think there is a document actively discouraging > >> the use of asdot and asdot+ We've come across asdot+ notation in > >> strange places such as RPSL, and I'm not yet sure how to proceed > >> https://github.com/irrdnet/irrd4/issues/48 > > > > Be liberal in what you accept, and conservative in what you send. I'm not the biggest fan of that philosophy. Especially because in the milions of objecst that exist in the combined IRR databases, it appears only four of them have something with ASDOT in the wrong place. https://tools.ietf.org/html/draft-uijterwaal-rpsl-4byteas-ext-03 didn't make it to RFC status. http://meetings.ripe.net/ripe-55/presentations/jakma-critical-considerations.pdf is interesting too. > > I.e. check for asdot on inbound nrtm feeds and convert to asplain, > > with no option to convert to asdot output. It's inexplicable why > > anyone would output or use asdot these days. > > > > IIRC, Afrinic is the only RIR which outputs asdot from their whois > > server. Everyone else changed to asplain around 2009. > > And these days, if you want as-dot in your stuff, you should expect to > throw a knob to have that happen. Indeed. Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
> On Aug 6, 2018, at 8:20 AM, Nick Hilliard wrote: > > Job Snijders wrote on 06/08/2018 14:22> RFC 5396 > https://tools.ietf.org/html/rfc5396 described the "asdot+" and >> "asdot" representation formats for AS numbers. >> I'd personally prefer a single canonical way to represent ASNs >> (asplain), and while RFC 5396 proposes the adoption of a decimal value >> notation 'asplain', I don't think there is a document actively >> discouraging the use of asdot and asdot+ >> We've come across asdot+ notation in strange places such as RPSL, and >> I'm not yet sure how to proceed >> https://github.com/irrdnet/irrd4/issues/48 > > Be liberal in what you accept, and conservative in what you send. I.e. check > for asdot on inbound nrtm feeds and convert to asplain, with no option to > convert to asdot output. It's inexplicable why anyone would output or use > asdot these days. > > IIRC, Afrinic is the only RIR which outputs asdot from their whois server. > Everyone else changed to asplain around 2009. And these days, if you want as-dot in your stuff, you should expect to throw a knob to have that happen. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Discourage asdot+/asdot?
Job Snijders wrote on 06/08/2018 14:22> RFC 5396 https://tools.ietf.org/html/rfc5396 described the "asdot+" and "asdot" representation formats for AS numbers. I'd personally prefer a single canonical way to represent ASNs (asplain), and while RFC 5396 proposes the adoption of a decimal value notation 'asplain', I don't think there is a document actively discouraging the use of asdot and asdot+ We've come across asdot+ notation in strange places such as RPSL, and I'm not yet sure how to proceed https://github.com/irrdnet/irrd4/issues/48 Be liberal in what you accept, and conservative in what you send. I.e. check for asdot on inbound nrtm feeds and convert to asplain, with no option to convert to asdot output. It's inexplicable why anyone would output or use asdot these days. IIRC, Afrinic is the only RIR which outputs asdot from their whois server. Everyone else changed to asplain around 2009. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
