On the whole I think this looks like quite a reasonable approach, certainly none of the substantive changes from 2460 bother me.
I have two comments ... The first is one of my pet peeves - the over use of those 2119 capitalised words in places they don't belong. Perhaps the worst example is from section 1.3 ... The IPv6 protocol specification SHOULD only state generic rules, if any, governing the use of the flow label field by any flow state establishment method, and MUST enable co-existence of different flow state establishment methods in IPv6 hosts and routers. If this, and 2119 read into it as called for, is to believed, then the state of the IPv6 protocol specification (not any implementation, or product) is an absolute requirement of this specification. That's just weird... Use of those terms is just fine when what is being considered is what an implementation has to do to conform to the spec (which is how they were invented in 1122/1123 after all) but it is really hard to see how they apply in cases like this. Either just exclude 2119 in this doc, and use the upper case for emphasis if it seems to be desired, or carefully consider every case to make sure that the 2119 definitions of the terms actually make sense in the particular context. And second, the flow label is to be defined to be immutable, except when it isn't... There seem to be two exceptions (the text isn't as clear on this as it might be). First, when the sending host has agreed that immutably isn't required (assumed to be as part of some flow state setup mechanism). That's fine, and if it stopped there I probably wouldn't be sending a message at all... The other case, is that the text keeps saying (well, several times at least) that it is OK for the field to be changed, as long as it is restored. That is immutable as far as anyone can tell - there's no need to specifically allow this. If we didn't allow reversible changes, then we wouldn't be able to send packets over ethernets - as there all our nice 1's and 0's get converted into this manchester encoding stuff, and are no longer nice 1's and 0's ... of course, after the packet has arrived everything is back as it should be, so all is fine ... but we don't consider special exceptions to the immutability rules to allow transmission media to alter the values provided they're returned. Nor is it needed here - it just adds confusion. The transmission media, routers along the way, and anything else, is free to do anything at all to the packets - as long as they arrive in the state that they're expected. There's no need to specifically say that. Or perhaps better, if one wants to say that, it should be said in the general form, not applied specifically to one particular field, or it starts to raise the question of just why this particular field is attracting all that attention, and leading to the suspicion that immutable as it applies to this field (other than the exception already covered) is somehow a different kind of immutable than applies to other fields. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
