Thomas Narten <nar...@us.ibm.com> wrote: > > This should not be a surprising or controversial change to the > node-requirements document. The WG made the decision earlier that we'd > leave out a reference to the Flow Label work because we didn't want to > have node-requirements block waiting for it, but we would revisit if > that work finished in time. > > It has. > > We should just make this change. There was never any doubt that node > requirements would point to the updated Flow Label RFC.
Alas, there was no mention of this in the document. And, the document is no longer under our control. It has gone through IETF LastCall, also with no mention of an intent to point to an updated Flow Label RFC. And, I quite agree, it would be a better document if it did point to an updated Flow Label RFC. I agree with most of what Thomas says: but I agree more with Brian Carpenter: it's not worth holding up this document for two (or more) months to add this. Beyond that (though I soft-pedaled it) I believe there's rather little chance of the proposed text breezing through in less than four weeks. And personally, I see more value in getting out the document as it stands quickly than in adding much of anything about Flow Labels. > If we say "do it later, when we rev the document again", we should be > realistic in that that probably won't happen for at least another year > and probably more like 2+ years. IMHO, we should commit to revising well within two years whether or not we add language about Flow Labels. I wish we already had language about Flow Labels in there; but I would still believe we shouldn't let the next rev drag on for two or more years: now is the time folks are working on implementing and deploying IPv6, and all indications are that such work will continue for a few years, at the same time details of the various pieces of protocols are evolving. IMHO, a road-map document is critically important, while a many-year-old road-map document can actually detract. Also IMHO, Flow Label remains mostly unused, and of the pieces, it's perhaps best able to wait for inclusion in a road-map. Now, something about process... Thomas certainly knows that to add the text in question, an AD is likely to tell us to recycle the document back to a WG LastCall. I happen to believe that's _very_ likely. And I listen in on the IESG telechats: I recommend to your perusal the Narrative Minutes http://www.ietf.org/iesg/minutes/2011/narrative-minutes-2011-07-14.html where this document was discussed. Recycling this doesn't feel like a slam-dunk at the IESG to me. I'm sure either Ralph Droms or Jari Arkko would allow the document to go back to the WG from AUTH48; I'm not sure either of them would look forward to its next trip through IESG, and I frankly don't see how either of them could say the proposed text doesn't deserve a recycle. That's why I suggested a minimal change, merely an Informational Reference to a document recently published, with no claims about what it says. Please _read_ the Narrative Minutes before you ridicule me for this belief. If it does recycle, IMHO, we'll be asked to respond to a raft of comments by IESG members the first time around (and there were more than are shown in the Narrative Minutes). Frankly, I believe we could get a -ter document out about as fast as we could recycle this one. Thus, though I'm supportive of the text in question, I believe it's better tactics to schedule a milestone to include it in a -ter document. I'm nearly certain that our responsible AD (Jari) would have to rule on either the change in wording or a milestone update: I'm more optimistic about a ruling in favor of adding a milestone. (And even if Jari agreed such a change doesn't require recycling, the RFC Editor would also have to agree, which is by no means a sure thing.) We're facing two separate questions here: - whether we like the wording for a road-map document; and - how long we're willing to hold up this document to get the change. I'm perfectly happy to be in the rough here; but I'm not happy holding up this document at all, nor do I believe four weeks to be a reasonable expectation if we insist on changing this document. If we really choose to insist on this late change even if it takes two or three months, so be it! -- John Leslie <j...@jlc.net> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
