Subject: 6MAN WG Last Call: <draft-ietf-6man-flow-update-01.txt>

From: Bob Hinden <[email-masked]>
Date: Sun, 16 Jan 2011 17:31:40 -0800

All,

This message starts a 6MAN Working Group Last Call on advancing:

	Title           : Update to the IPv6 flow label specification
	Author(s)       : S. Amante, et al.
	Filename        : draft-ietf-6man-flow-update-01.txt
	Pages           : 13
	Date            : 2011-01-10
	
        http://tools.ietf.org/html/draft-ietf-6man-flow-update-01       

as an Informational RFC.  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 January 31, 2011.

Regards,
Bob Hinden & Brian Haberman
6MAN Chairs

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Jan 2011 12:19:50 -0500

I admit to only recently jumping into this discussion and gettng
caught up on the various drafts, but why are we doing this document?

> 	Title           : Update to the IPv6 flow label specification

That is the title, but it doesn't update anything at all. It says this
explicitly. It says:

   The intention of this document is to explain this in more detail and
   to propose changes to RFC 3697 intended to remove the uncertainties
   and encourage active usage of the flow label.  It does not formally
   update RFC 3697.

So we now publish as RFCs proposals to make changes to standards track
documents, without actually making a change? This seems like it will
confuse the community.

Seems to me that if we do not formally clarify the preceding documents
(if they need clarifying), we are wasting our time, and that there
really isn't a problem here that needs fixing.

And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC),
that document is a BCP and does not update any of the previous Flow
Label documents.

If we need to update the Flow Label specs, we should do so, and this
document could be part of that or a rational for the changes. But
absent any changes to the existing standards, I am not comfortable
with publishing this document.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jan 2011 09:38:31 +1300

Thomas,

> really isn't a problem here that needs fixing.

There's clearly a problem (20 unused bits and enormous confusion about
how they could be used). And clearly the goal is 3697bis. The reason for
this draft, as I believe we've discussed over some months, is to set the
scene for 3697bis. Indeed we have two choices:

1) agree on the substance of the intended updates and publish them as a
stake in the ground, then develop 3697bis.

2) agree on the substance of the intended updates (by means of the
present WGLC), and then proceed directly to develop 3697bis.

I understood that we'd agreed on 1) but the WG Chairs can tell me I'm wrong.

> that document is a BCP and does not update any of the previous Flow

Correct. It doesn't need to; it is additional practice and the intention
is to ensure that it's compatible both with 3697 and the eventual 3697bis.
(I agree with your comment on that draft that the phrasing on this
point is clumsy.)

> with publishing this document.

I would be too, if it was the end of the road, but we have an author
team all set to start on 3697bis once we have a clear consensus in
the WG about the changes to be made. Can you propose text that is
clearer than the following?

   (In the Abstract)
   This document describes and motivates proposed
   changes to the specification in order to clarify it, making it clear
   what types of usage are possible, and to introduce some additional
   flexibility.  It does not formally update RFC 3697.

   (In the Introduction)

     Brian

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Jan 2011 16:19:16 -0500

> There's clearly a problem (20 unused bits and enormous confusion
> about how they could be used).  And clearly the goal is 3697bis. The
> reason for this draft, as I believe we've discussed over some
> months, is to set the scene for 3697bis. Indeed we have two choices:

> present WGLC), and then proceed directly to develop 3697bis.

I would find it helpful to see the proposed changes to 3697bis. If I
don't see them, I can't tell for sure whether I agree with the
justification for making changes. Also, if we want the justification
to be correct, it needs to be in sync with the actual changes. If we
publish the proposed changes first, and then make changes, we risk the
two not being in sync (when people start discussing the actual changes
and realize what is really at issue). Or we risk never actually
getting agreement on the changes, and then flow-update ends up being
the "end of the road".

If we already know what changes will be made, please put them on the
table and let's decide and move on.

How big of a document are we talking about for the actual changes?

> the WG about the changes to be made.

What are those proposed changes? And can we guage consensus now,
before publishing the documents? I don't like this idea that we say
there is agreement on the proposed changes, but we don't actually know
what they are.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Jan 2011 13:58:19 -0800

Brian,

> I understood that we'd agreed on 1) but the WG Chairs can tell me I'm wrong.

After a short discussion, the chairs think that it would be preferable to either have this document become an update to RFC3697 itself, or have an RFC3697bis draft be written to be considered in parallel.  In the last case this draft would be the justification and background, and the RFC3697bis draft would be an implementers spec (that is, what to do, not why).  I note that RFC3697 is only 9 pages long.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jan 2011 11:25:59 +1300

Thomas,

Section 4 of the draft is explicitly the proposed normative changes;
no more and no less, starting at

"  A description of the changes follows.  They are written in normative
   language to avoid ambiguity.  They are mainly not written as specific
   text changes to RFC 3697, and significant rewriting of the latter is
   needed to incorporate these changes."

Expressing them as diffs to 3697 would produce an unreadable mess.

I imagine that the resulting 3697bis would be about the same length
as 3697.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jan 2011 11:32:34 +1300

Sure, we can do that. I suggest repurposing the present draft as
a rationale document, so basically what we have to do is merge its
section 4 into 3697.

FYI the proposed authors for 3697bis are
 Shane Amante
 Brian Carpenter
 Sheng Jiang
 Jarno Rajahalme

Since the WG adopted draft-ietf-6man-flow-update, should
we post 3697bis immediately as a 6man draft?

Regards
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 18 Jan 2011 08:05:10 -0800

Brian,

> we post 3697bis immediately as a 6man draft?

Yes, please do that.  That is consistent with making the other flow label drafts 6man w.g. group documents.

Thanks,
Bob