[92773] in North American Network Operators' Group
Re: that 4byte ASN you were considering...
daemon@ATHENA.MIT.EDU (David W. Hankins)
Tue Oct 10 19:05:15 2006
Date: Tue, 10 Oct 2006 16:03:54 -0700
From: "David W. Hankins" <David_Hankins@isc.org>
To: nanog@nanog.org
In-Reply-To: <20061010212354.GA17533@msrl.com>
Errors-To: owner-nanog@merit.edu
--LZFKeWUZP29EKQNE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Oct 10, 2006 at 09:23:54PM +0000, Michael Shields wrote:
> Personally, I care less about which notation we choose to express
> four-byte ASNs than that *everyone choose one notation*. Choosing a
Totally, and I would be surprised if that were not the eventual
outcome. In the absence of any other format, the dotted quad will
probably bubble up into user interfaces eventually.
I think everyone else is wrong that there is going to be some sort
of heinous "y2k" doomsday scenario here in regards to breaking their
current-day scripts or operational practices, or if there were that
this is an issue to take up with the IETF rather than the vendors
making said changes.
> As to whether this is within the scope of the IETF, note that they are
> already going far, far beyond this in the Netconf WG, which is defining
> a complete router configuration protocol.
Netconf absolutely, and zeroconf too. These are machine languages,
they aren't user interfaces. So this is just a level of indirection.
If someone were suggesting a change to the netconf wire format
that is not reverse compatible, that's obviously something that
should be brought up at the IETF!
But a change to the config file or web/scripting interface or
whatever that you use to trigger Netconf into action?
Totally not their bag.
--
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP. Email training@isc.org.
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
--LZFKeWUZP29EKQNE
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFFLCbacXeLeWu2vmoRArkZAKCRpzby9Ke2cI5oT+FC1WgT8ibkmgCfRWX5
lD3TRwVwaMjdpuq79X4ei94=
=dpo6
-----END PGP SIGNATURE-----
--LZFKeWUZP29EKQNE--
