This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Modifications to the inet6num in the RIPE Database
- Previous message (by thread): Modifications to the inet6num in the RIPE Database
- Next message (by thread): Modifications to the inet6num in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David Kessens
david at Qwest.net
Tue Mar 16 21:25:15 CET 1999
On Tue, Mar 16, 1999 at 06:48:15PM +0100, Poul-Henning Kamp wrote: > In message <009D5362.46E0DF3C.25 at cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO > net" writes: > > > Taking this one step further, and looking back at what we did with IPv4, > > where it would be feasible to say 131.130/16, implying 131.130.0.0/16, > > I wonder if it wouldn't again be worthwhile to restrict the use of these > > shorthand notations in the Address Registry? > > There is certainly something to be said for making it easy for programs > to parse the registry. The current registry abbreviates. While this means a little more work for machines, people seem to have more trouble parsing long lines and are more difficult to fix in this regard than a simple parser in a program. I don't think that adding zeroes makes it easier to read and editing an existing object doesn't get very easy either: inet6num: 3FFE:1100:0:C00::/56 becomes: inet6num: 3FFE:1100:0000:0C00:0000:0000:0000:0000/56 David K. ---
- Previous message (by thread): Modifications to the inet6num in the RIPE Database
- Next message (by thread): Modifications to the inet6num in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]