It seems I was accidentally dropped from the mailing list just before the last call went out. In addition to Jarno's comments, let me add to what jak said: ...
> > - Allowing a specific flow label value to be assigned via a signaling > > protocol to identify flows with different source and destination > > addresses. > > > > This is a concern. I agree that keeping a simple flow label usage might be > better for now, until we have more experience. However, I can also see an > argument that it might simplify signaling in certain cases, for example, > multi-user voice sessions such as a teleconference. There are two points here. One is that we have to allow for SCTP's multiple addresses. The current text may be a little unclear on this. Another is that not everybody, and not every QoS mechanism, agrees on what a "flow" is - and we didn't want to be too restrictive. However, the text does seem to need a fix. > > > The draft may be trying to accommodate uses of the flow label that were not > > agreed to by the working group. Defiantly, yes. I don't think it's for this WG to second-guess future usages. We should leave as many options open as possible. > > > > There are a number of other areas in the draft that need additional > > discussion and/or clarification. These include: > > > > - No default time out for the life time for specific flow label values. > > - No requirement that signaling mechanisms must include a lifetime > > when providing flow label setup information. > > I believe the issue here is flow label state, and not flow labels per se. I > agree that the document should state that flow label state should be soft state, > and that there should be a requirement that flow label state have a specific > lifetime. Personally, I agree as long as it's "should" in both cases. > > However, as the document is trying to set up requirements, I believe specifying > a default lifetime for all applications would be inappropriate. I think it is > enough to require that signaling protocols and applications specify a default. > The default may differ depending on the application. But the default needs to be known downstream, where there may be no specific knowledge about the application. So I think a default is needed. > > > > - No default mechanisms if flow label values requested via a signaling > > mechanisms conflict with existing flow label values. Surely the request simply fails? But it's not clear that this WG has any business saying how the signalling should work. > > - Security considerations need to discuss the impact of labeling flows > > of encrypted traffic. > > > > It is not immediately clear to me whether additional requirements in this area > are needed, but it would not hurt to spend some time considering these. IPSEC already considered this when deciding not to cover the flow label field. I'm really not sure what else there is to say. On all these points, if change is needed, please send text. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
