Subject: [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 (fwd)

From: Sandra Murphy <[email-masked]>
Date: Mon, 6 Jun 2011 12:48:13 -0400 (Eastern Daylight Time)

I'm curious.

Could the authors of draft-ietf-sidr-iana-objects comment on whether the 
action mentioned below would have any effect on the rules for IANA issued 
objects wrt RFC3068 prefixes?

--Sandy, speaking as wg chair

---------- Forwarded message ----------
Date: Mon, 6 Jun 2011 09:23:26 -0700
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>
Cc: [email-masked]
Subject: 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

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
    Historic status'
   <draft-ietf-v6ops-6to4-to-historic-04.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-06-20. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

    Experience with the "Connection of IPv6 Domains via IPv4 Clouds
    (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
    unsuitable for widespread deployment and use in the Internet.  This
    document requests that RFC3056 and the companion document "An Anycast
    Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Terry Manderson <[email-masked]>
Date: Mon, 6 Jun 2011 17:36:17 -0700

Hi Sandy,

Wearing just the iana-objects author hat.

It would require a small amount of editing, which in turn will ultimately
result in the prefixes (as termed 'deprecated') being considered unallocated
- and therefore an AS0-ROA SHOULD (eventually) be issued for 2002::/16 and
192.88.99.0/24.

The question I have is about trying to intrude on the RFC-Editor queue now,
while the iana-objects is having all the boxes ticked and is well ahead of
draft-ietf-v6ops-6to4-to-historic-04, or wait for publication of
v6ops-6to4-to-historic and (as already covered in iana-objects) issue an
update.

Cheers
Terry

On 7/06/11 2:48 AM, "Sandra Murphy" <[email-masked]> wrote:

> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Jun 2011 06:36:25 +0000

> The question I have is about trying to intrude on the RFC-Editor queue
> now, while the iana-objects is having all the boxes ticked and is well
> ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication
> of v6ops-6to4-to-historic and (as already covered in iana-objects)
> issue an update.

if you are asking this question, perhaps you should be asking why it is
not a registry.

randy

---

From: Terry Manderson <[email-masked]>
Date: Tue, 7 Jun 2011 16:48:31 -0700

It was an IETF process question, not a document structure question.

.T

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Jun 2011 07:20:21 +0000

>> if you are asking this question, perhaps you should be asking why it is

the question may have been about spacecraft fuel.  but it made pretty
clear that there was a problem with the document structure which will
reappear.

randy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 8 Jun 2011 00:50:17 -0700

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. This has ramifications elsewhere, so for now I firmly believe that the document structure is sound for what is required for the timely deployment of RPKI.

Cheers,
Terry

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Jun 2011 07:56:31 +0000

> 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.

> I firmly believe that the document structure is sound for what is
> required for the timely deployment of RPKI.

this entire doc is pretty irrelevant to timely deployment of the rpki,
as can be seen by running code.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Jun 2011 10:18:11 -0400 (Eastern Daylight Time)

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.

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. 
:-)

---

From: Geoff Huston <[email-masked]>
Date: Thu, 9 Jun 2011 01:02:40 +1000

> problem.  we have a standard way of solving this problem, and iana

+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

>> required for the timely deployment of RPKI.

-1

Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Jun 2011 11:13:38 -0400 (Eastern Daylight Time)

Geoff, I think you are voting for my option (1): retract draft and amend.

Correct?

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Thu, 9 Jun 2011 01:35:59 +1000

> Geoff, I think you are voting for my option (1): retract draft and amend.

If an offered opinion can be construed as a "vote", then yes. 

(And I've offered a gratuitous suggestion as to what would be a productive form of amendment, in my opinion.)

 Geoff

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Jun 2011 08:43:21 -0700

On Jun 8, 2011, at 7:18 AM, Sandra Murphy wrote:

> (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.)
> 
> (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.
> 

Those of us following the discussion on the [email-masked] 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

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Jun 2011 11:45:56 -0400 (Eastern Daylight Time)

> Which IETF have you been participating in where that kind of speed seems even remotely possible? :-(

Hence the smiley.

--Sandy, as wg member only.

---

From: Terry Manderson <[email-masked]>
Date: Wed, 8 Jun 2011 16:35:32 -0700

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" <[email-masked]> wrote:

>> (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.
>> 
>> obsolesence in short order but induces a delay in IANA actions for these iana
>> objects.
>> 
> Those of us following the discussion on the [email-masked] 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. :-)
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jun 2011 08:29:25 +0000

> (The -bis could introduce a registry, if that looks like a good option.)

either is fine with me.  i suspect the former would be easiest on the
rfc-editor.

randy

---

From: "t.petch" <[email-masked]>
Date: Tue, 14 Jun 2011 16:14:52 +0200

----- Original Message -----
From: "Geoff Huston" <[email-masked]>
To: "Randy Bush" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Sandra Murphy"
<[email-masked]>
Sent: Wednesday, June 08, 2011 5:02 PM
> 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