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

[Terry Manderson <[e-mail]>]

Interesting thread...

I think it is unwise to retract the iana-objects draft. It says precisely
what it needs to in that it describes the RPKI objects that need to be
issued by IANA under the current implied routing assertions.

I do not believe this document should create a new registry.

What I have already drafted, but not uploaded as I am vacillating between
target workgroups is a new (not -bis) small draft that:

1) Requests that IANA _extend_ all the existing IPv4/v6 registries to
include an explicit global routing assertion.

2) Advises what language to put in future IANA considerations sections of
drafts that request an allocation/reservation of prefixes. (..and probably
updating rfc5226.)

3) Defines the rules for the existing allocations/reservations based on
iana-objects.

The reason I am flip-flopping between where to target this draft is that I'm
comfortable that quite a number of workgroups will want to provide input, as
well as authors from previous drafts which have requested v4/v6 registry
action.

At this stage I thing GROW is the most appropriate workgroup for such a
document as it doesn't specifically sit in the SIDR bailiwick.

That said, I am more than happy to take the co-chair's guidance (noting
Chris is also co-chair of GROW) on this topic.

Cheers
Terry

On 9/06/11 1:43 AM, "Paul Hoffman" <[e-mail]> wrote:

> On Jun 8, 2011, at 7:18 AM, Sandra Murphy wrote:
> 
>> OK, folks, so I see two possibilities mentioned here.
>> 
>> (1) Retract the iana-objects draft, update it wrt prefix status changes, and
>> send it back to the RFC-Editor to wait until and if the IESG approves the
>> 6to4-to-historic draft.
>> 
>> (2) Let the iana-objects draft progress, begin work on a -bis immediately.
>> (The -bis could introduce a registry, if that looks like a good option.)
>> 
>> As I see it, process wise:
>> 
>> (1) eliminates the half-skip step of publishing an RFC known to be facing
>> obsolesence in short order but induces a delay in IANA actions for these iana
>> objects.
>> 
>> (2) avoids the planned obsolesence but does not impede IANA actions for these
>> iana objects.
>> 
>> Comments from the group, please, as soon as possible.
> 
> Those of us following the discussion on the [e-mail] list know that it is
> far from clear that draft-ietf-v6ops-6to4-to-historic is going to be adopted
> by the IETF. It has gotten a lot of push-back.
> 
> Given that, #2 seems like the better option. The new draft simply needs to
> pull all the data from the in-queue RFC and make a registry for it. Developers
> follow the RFC-to-be for now, then follow the registry when it is created.
> 
>> P.S.  Note that there is an option (2+) which would produce the -bis so fast
>> (and with care to be compatible with any IESG decision on 6to4) that it would
>> overtake the iana-objects draft on the RFC Editor queue. :-)
> 
> Which IETF have you been participating in where that kind of speed seems even
> remotely possible? :-(
> 
> --Paul Hoffman
>