Re: [sidr] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>(Request to move Connection of IPv6 Domains via IPv4 Clouds(6to4) to Historic status) to Informational RFC

----- Original Message -----
From: "Geoff Huston" <gih@apnic.net>
To: "Randy Bush" <randy@psg.com>; <sidr@ietf.org>
Cc: <draft-ietf-sidr-iana-objects@tools.ietf.org>; "Sandra Murphy"
<Sandra.Murphy@sparta.com>
Sent: Wednesday, June 08, 2011 5:02 PM
>
> On 08/06/2011, at 5:56 PM, Randy Bush wrote:
>
> >> Perhaps, but the issue you allude to is more about calling out routing
> >> intention in each and every RFC that requests a reservation or special
> >> use allocation from IANA.
> >
> > not really.  it's about the mess that is about to be made by (from the
> > document)
> >
> >   If IANA is directed to issue additional RPKI objects in future, this
> >   document will be revised and a new version issued.
> >
> > and before it is even published, a new version is needed.  this is a
> > problem.  we have a standard way of solving this problem, and iana
> > registry.
> >
>
> +1
>
> In my opinion, it would be better to amend this doc to direct the IANA to set
up a registry and then use the registry update processes to make amendments as
and when required as distinct from pumping out -bis -bis bis etc etc cruft in
the RFCs

I think I agree; it depends on how often this is going to happen.  If a new
address appears once a year or more often, then a registry is the right IETF
technology for it.  If it happens once every five years, then a -bis would seem
better.  Historically, these 'funny' addresses have been quite stable but of
late, they seem to have become more frequent.  My assumption is that in these
migratory times, when either IPv6 becomes part of the furniture or else dark
arts get practised with IPv4, then such addresses are likely to appear more
often.

So, registry it should be.

Tom Petch

> >> I firmly believe that the document structure is sound for what is
> >> required for the timely deployment of RPKI.
> >
>
> -1
>
>
> Geoff
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr