Subject: one more IESG question about RFC 2553bis or 2292bis

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Oct 2002 15:46:33 -0400

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 15 Oct 2002 11:56:51 +0900

>>>>> On Mon, 14 Oct 2002 15:46:33 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> Thoughts on how to proceed?

This is a good catch.  If I remember correctly, a separate draft
(draft-itojun-ipv6-flowlabel-api-01.txt --I don't know if this is the
latest one) was issued to clarify the API for flow labels.  After some
discussions, however, the revise of the draft was suspended, because
the protocol usage of flow labels was still unclear.  (And, this was
the reason why the draft was not incorporated into rfc2292bis.)

Thus, I think the best way is

- to remove the paragraph of 2553bis in question, and
- (if necessary) to clarify the detailed usage of sin6_flowinfo is not
  defined in 2553bis because the protocol specification of flow labels
  is still unclear.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------