I agree. We can have an addendum API spec specifically for this later. /jim [Honor, Commitment, Integrity]
> -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 19, 2002 10:46 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes > > > I'm reluctant to reach any conclusion about this until > we have complete clarity about the flow label, which as > we concluded yesterday still needs more work. So I think > that the current (ambiguous) text is probably OK for now. > I'm afraid it will need revisiting at some time in the future. > > Brian > > JINMEI Tatuya / 神明達哉 wrote: > > > > Unless I've missed something, I've not received any > responses to the > > attached message. I interpreted the silence as a sign that > there is > > no need to update 2292bis wrt the issues in this thread. > Otherwise, > > please let me know. > > > > Thanks, > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D > Center, Toshiba Corp. > > [EMAIL PROTECTED] > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------- > > > > Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes > > Date: Fri, 08 Nov 2002 20:51:38 +0900 > > From: JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]> > > Organization: Research & Development Center, Toshiba Corp., > Kawasaki, > > Japan. > > To: Thomas Narten <[EMAIL PROTECTED]> > > CC: [EMAIL PROTECTED] > > References: <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED]> > > > > >>>>> On Wed, 06 Nov 2002 13:44:49 -0500, > > >>>>> Thomas Narten <[EMAIL PROTECTED]> said: > > > > > With regards to the basic API: > > > > > - Will we want the basic API to ever allow a way to specify the > > > Traffic Class? If so, will it be better to define a new > extension or > > > to overload the Flow Label? > > > > > - Should we point out that some previous versions of the basic API > > > copied both traffic class and flow label info into > packets and that > > > this is now beleived to be wrong and should be fixed? > > > > > I'm OK with either saying setting the Traffic Class through the > > > basic API won't be done in the future, or saying it can > be added but > > > in a way that is completely backwards compatable and will work > > > smoothly with 2292bis (assuming we need two ways of setting the > > > bits). > > > > I personally prefer to deprecate the access to Traffic Class by the > > sin6_flowinfo field (i.e. by the basic API), because > > > > - it (of course) makes the (future) API simple. > > - as far as I know, there should be very few (or even no) > applications > > that rely on the feature. so the backward compatibility issue > > should be not so serious. > > > > I know opinions on the compatibility often varies, and I'm open to > > others' opinions. > > > > > Then there is the Advanced API. Again, from Bill: > > > > > Bill Fenner <[EMAIL PROTECTED]> writes: > > > > >> I am still concerned about the interaction between 2292bis's > > >> IPV6_TCLASS and these implementations, but perhaps we should let > > >> 2553bis go with the "not currently specified" wording > and make the > > >> interaction clear in 2292bis? (Has the WG as a whole > had a chance > > >> to see the suggesiton of leaving sin6_flowinfo simply > unspecified?) > > > > > 2292 doesn't address the flow label. But it does have a way of > > > setting the Traffic Class. But it doesn't mention how it > interacts > > > with Traffic Class settings via the (old) basic APIs. If the > > > intention is that the old ways are invalid, and that one > only sets > > > traffic class through the advanced API, I think the > current approach > > > is fine. Is that what folks are thinking here? > > > > Excuse me, what do you mean by "the current approach"? Do you mean > > that "2292bis has a way of setting the traffic class but it doesn't > > mention the interaction with the (old) basic API"? > > > > If so, and assuming we agree on deprecating this part of the basic > > API, I agree. > > > > However, if our consensus is that some backward > compatibility should > > be provided, I guess 2292bis needs to talk about the interaction. > > > > > Finally, 2292bis seems to assume the Traffic Class is 8 bits in > > > size. It's not any more. It's 6 bits, with the ECN bits > explicitly a > > > separate field. So perhaps 2292bis should be updated to > reflect the > > > new size and have separate way of setting the ECN bits? > Or at least, > > > the text should make it clear how one sets one and not the other, > > > etc. > > > > (this was discussed before at least partly, but) > > I believe 2292bis clearly separates the notion of (6-bit) traffic > > class and 2-bit ECN. For example, section 6.5 contains the > following > > sentences: > > > > Returning the received traffic class is useful for > > programs such as a diffserv debugging tool and for user level ECN > > (explicit congestion notification) implementation. > > > > An example is an implementation of ECN in the kernel, > > setting 2 bits of the traffic class value. > > > > The confusing part would be wording such as "traffic class" > (assuming > > 8 bits) or the socket option name IPV6_TCLASS. In this sense, the > > comment for the ip6_un1_flow field of the ip6_hdr structure > would also > > be confusing: > > > > uint32_t ip6_un1_flow; /* 4 bits version, 8 > bits TC, 20 > > bits flow-ID */ > > > > As I responded before, I personally think the current > wording is okay. > > However, if there's a strong demand to clarify this much more, I'd > > propose to add a note like this: > > > > [RFC-3260] separates an 8-bit field of the IPv6 header, which was > > originally called a single "traffic class" field, into a 6-bit DS > > field and a 2-bit ECN field. However, since this API > only provides a > > single way to get access to the whole 8 bits, the > previous terminology > > "traffic class" will be used to specify the whole bits within this > > document. > > > > Does this make sense? > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate > X-Mozilla-Status: 0009rp. > > [EMAIL PROTECTED] > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
