+1 - this articulates my concerns and what I'd like to see done to resolve.
Wes George -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of John Leslie Sent: Monday, May 09, 2011 7:27 PM To: Brian E Carpenter Cc: ipv6@ietf.org; RJ Atkinson Subject: Re: Flow label drafts updated Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > On 2011-05-10 01:02, RJ Atkinson wrote: > >> A much more reasonable approach would be to say (edit to taste): >> >> "The Flow Label SHOULD NOT be changed in transit." > > The authors really need to hear that from more than one person, or to > hear from the WG Chairs that it's a consensus, because it goes against > several months of discussion. I agree with Ran that SHOULD NOT is more appropriate for this case where the horse has long since left the barn. Middleboxes _are_ going to clear it (or worse). OTOH, I don't actually _object_ to MUST NOT -- in the narrow sense that any node that disobeys the MUST NOT isn't speaking the protocol as defined. I do believe we should, regardless, excise all use of the word "immutable" for the Flow Label. That word isn't helping. > I suggest squaring this circle by retaining the MUST NOT (which IMHO > is the present consensus) but making it clear in the security > considerations that there will be exceptions. The problem here is that > the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is > what we really need. SHOULD NOT is not perceived as strong enough. I could live with that; but I really do suggest wordsmithing the 3 uses of "immutable". Additionally, I'd like to see some treatment of what may go wrong if middleboxes change the Flow Label. If I understand, it will partly break load-balancing. Middlebox designers probably don't understand this issue. (Even if they did, they'd likely say, "some users are entirely willing to accept that tradeoff.") -- John Leslie <j...@jlc.net> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
