Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt

From: Chris Grundemann <[email-masked]>
Date: Thu, 15 Dec 2011 09:37:39 -0700

Hello and apologies to the list if this is redundant, but what is the
current status of this I-D?

I note that the status page[1] was not updated to reflect this last
call and I do not see any further updates or mention of an -06 or an
IETF last call. Perhaps the authors are working on this off-line?

I am interested in seeing this work completed and am willing to help if needed.

Thanks!
~Chris

[1] - https://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484-revise/history/

On Fri, Nov 4, 2011 at 08:16, Brian Haberman <[email-masked]> wrote:
> All,
>     This message starts a two week 6MAN Working Group on advancing:
>
>     Title     : Update to RFC 3484 Default Address Selection for IPv6
>     Author(s) : Arifumi Matsumoto
>                 Jun-ya Kato
>                 Tomohiro Fujisaki
>                 Tim Chown
>     Filename  : draft-ietf-6man-rfc3484-revise-05.txt
>     Pages     : 12
>     Date      : 2011-10-31
>
> as a Proposed Standard.  Substantive comments and statements of support
> for advancing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will
> end on November 18, 2011.
>
> Regards,
> Brian Haberman & Bob Hinden
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org

---

From: Brian Haberman <[email-masked]>
Date: Thu, 15 Dec 2011 13:32:00 -0500

Hi Chris,
     Unfortunately, the draft is in a limbo state at this point.  The WG
Last Call ended about a month ago with zero comments or statements of
support.  The chairs cannot advance this document without some show of
support by the community.

     I humbly request that members of the working group review this
draft and post their comments, questions, and suggestions to the mailing
list.

Regards,
Brian

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 15 Dec 2011 20:07:39 +0100

> draft and post their comments, questions, and suggestions to the mailing

Brian Carpenter said it all in this post:

Message-ID: <[email-masked]>
Date: Wed, 09 Nov 2011 14:11:14 +1300
From: Brian E Carpenter <[email-masked]>

<snip>
Reading this document as a proposed standard, I think it will confuse
the reader. I think that what we actually need is a 100% replacement
of RFC 3484, that can be read on its own.
</snip>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 15 Dec 2011 15:21:47 -0500

> of RFC 3484, that can be read on its own.

Ah, you are correct.  That message ended up in the wrong mailbox and I
missed it when reviewing the state of the draft in response to Chris' query.

Thanks, Roger.

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Dec 2011 09:24:51 +1300

Well, the end of my conversation is at

http://www.ietf.org/mail-archive/web/ipv6/current/msg14948.html

Summary: "an update that makes it easy for the implementer to find the changes is better."

If it wasn't clear, I believe this document is technically done and needs
to be advanced, but it does need editorial work as indicated above.

Also there was Dave's review:

http://www.ietf.org/mail-archive/web/ipv6/current/msg14984.html

In IESG parlance that all seems like "new I-D needed" to me.

Regards
   Brian Carpenter

On 2011-12-16 08:07, Roger Jørgensen wrote:
> ------------------------------------------------------------------------
>

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 15 Dec 2011 22:52:09 +0100

> to be advanced, but it does need editorial work as indicated above.

Hmm sorry for being unclear, the technical part looked okay as far as
I could tell, but as the quoted words from you, it will probably be
more confusing to have two documents where the last one update/change
the first one. Would be much better to have just one
replacing/updating the old one.

--- Roger J ---

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Dec 2011 11:55:52 +1300

Roger,

> replacing/updating the old one.

That was my first thought, but then I realised it would cause a lot
of delay, and I think getting these changes deployed is quite urgent.

    Brian

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 15 Dec 2011 16:16:57 -0700

> of delay, and I think getting these changes deployed is quite urgent.

I must agree, there is certainly an urgent need to fix the problems in
the current RFC 3484, particularly around the handling of ULAs, etc.
For one example; I am currently working on sorting out proper IPv6
support in UPnP and DLNA (targeting CE) and we have (effectively)
nothing to point to for dynamic source address selection procedures.
Since there appears to be consensus on the technical changes, is there
a way to make the needed editorial changes and then advance to IETF
last call (or a second WG last call at least)?

~Chris

<snip>

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 16 Dec 2011 10:38:07 +0100

> of delay, and I think getting these changes deployed is quite urgent.

what about doing it in two step? First getting this one out since it fix
something quite broken, and then update the old RFC?

-- 

Roger Jorgensen           |

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Dec 2011 10:49:05 +0000

Well, there are two questions here.

One is whether the WG believes the update as described in draft-ietf-6man-rfc3484-revise-05 is correct and complete.  I have not seen (yet) any significant technical concerns raised.  The last of those were discussed and (we believe) resolved in Quebec.  Are there any more?

The other is whether the WG believes we should publish an update, or a complete fresh version of RFC3484.  This was discussed previously in the WG and the update path preferred.  If a fresh version is now deemed more appropriate, I am fine to work on that with the other authors if required.

We just need a decision so we can progress this - it's been so close to release for a long time.  Many of the changes in the update have been implemented in a number of platforms already.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Dec 2011 14:22:18 +1300

Seems to me we all agree on this much:

>> First getting this one out since it fix something quite broken,

Regards
   Brian