Brian, >> There was one change from rfc2553bis-07 to rfc2553bis-08. In response >> to a comment from the IESG, the description of the sin6_flowinfo field >> was changed from: >> >> 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]. >> >> to: >> >> The sin6_flowinfo field is a 32-bit field intended to contain >> flow-related information. The exact use of this field is not >> currently specified. >> >> This in essence matches the IEEE spec, which is silent on the >> subject of sin6_flowinfo. > >I understand the problem with the old language, but the new language >is a bit disturbing too. RFC 2474 and RFC 3168 do specify 8 of these >bits, and 4 of them are inoperative in the API (the version number bits).
First let me say I'm open to suggestions for better wording. While RFC 2474 and RFC 3168 specify bits in the IPv4 and IPv6 headers, they do not specify anything about the use of sin6_flowinfo to affect or retrieve those bits. The same problem exists with the original reference to RFC 2460, which specifies the format of the IPv6 header, but does not specify anything about sin6_flowinfo. Even if we assume the sin6_flowinfo field is formatted in the same way as the first 4 bytes of the IPv6 header (i.e. version, class, and flow), we still have not specified how the sin6_flowinfo field is used. So we have two choices: hold rfc2553bis while we define the use of the sin6_flowinfo field, or defer that definition to another spec as we did with sin6_scope_id (rfc2553bis-08 reflects the latter choice). - Jack -------------------------------------------------------------------- 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] --------------------------------------------------------------------
