Subject: draft-rajahalme-ipv6-flow-label-00.txt

From: Robert Elz <[email-masked]>
Date: Tue, 18 Dec 2001 17:08:35 +0700

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-masked]
--------------------------------------------------------------------