As Jack has completed his updates to RFC 2553, I've put it back on the
IESG for consideration for publication. That prompted the following
comment from Bill Fenner.

Thoughts on how to proceed?
================
Thomas,

  Here's an issue that I just discovered today.  I can't tell whether
it's a 2553bis issue or a 2292bis issue (or both).

2553bis says:
The sin6_flowinfo field is a 32-bit field that contains two pieces of
information: the traffic class and the flow label.  The contents and
interpretation of this member is specified in [1].

[1] is RFC 2460, and doesn't really say anything about sin6_flowinfo
per se, but does have the picture of the first 32 bits of the IPv6
packet, and knowing history I know it means that the bottom 28 bits
of the sin6_flowinfo field goes after the version.

2292bis says to use the IPV6_TCLASS socket option or ancillary
data and doesn't mention sin6_flowinfo.
   To specify the outgoing traffic class value, just specify the control
   information as ancillary data for sendmsg() or using setsockopt().


I think having two different ways to specify the traffic class is
confusing, especially since 2292bis doesn't refer to the 2553bis
way, nor does it say which one is actually used if both are specified.

Another problem is that 2460 doesn't say what to put in the sin6_flowinfo
(although you can kind of guess), so 2553bis's assertion that 'The
contents and interpretation of this member is specified in [1].' is not
really true.

A possible solution to both of these problems is to remove the traffic
class from the sin6_flowinfo, and define the sin6_flowinfo to just contain
the 20 bit Flow Label.  If the solution is to instead expand 2292bis to
talk about the interaction with sin6_flowinfo, then 2553bis should define
the actual contents of sin6_flowinfo, not just vaguely refer to 2460.
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   0   | Traffic Class |           Flow Label                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
would probably be fine.


  Bill

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

Reply via email to