> It says a host > MAY set the flow label, for instance, rather than what it MUST do. I > think it would be better for the document to say a HOST just sets it > to 0. Or, if that is not right, what it SHOULD/MUST do. We want > predictable behavior from the originating hosts.
But we can't do that realistically. A host may choose to set the flow label on no traffic at all, on particular types of traffic that it cares about, or on all traffic (unlikely). This will be a matter of local policy configuration, and/or the level of QOS support available in that particular version of that particular operating system. What this document attempts to say is what should happen in cases where hosts *choose* to activate the flow label. So the whole document is inevitably a MAY. Perhaps it would be better if that was explicit - an applicability statement written as a MAY, but SHOULDs in the body of the text to define the desired behaviour. Thanks for reading it anyway! Brian Thomas Narten wrote: > > Hmm. There was much discussion in SLC on the Flow Label. Quite a lot > of mail in the weeks immediately after SLC. Then quiet. Then a new ID > appears. More silence. Something like 45 minutes of agenda time has > been allocated next week for the topic. Has no one had time to read > the draft yet? :-) > > Here are some high-level comments for folks to think about. > > The scope of the document could be narrowed. I think its focus might > better be just what a host and router MUST do in order to be > compliant. There is a fair amount of additional text that talks about > MAYs with regards to possible usages. > > It could say more about what a host is supposed to do. It says a host > MAY set the flow label, for instance, rather than what it MUST do. I > think it would be better for the document to say a HOST just sets it > to 0. Or, if that is not right, what it SHOULD/MUST do. We want > predictable behavior from the originating hosts. > > In fact, the document might just have too many MAYs. It seems like it > is trying to not make it illegal for someone to experiment with the > flow label. I'm OK with that, but that doesn't need to be put in the > spec as MAYs. It should be clear what RFC-compliant implementations > are supposed to do. Not sure it needs to say anything more. People are > always free to experiment. > > There is perhaps too much wording about what signaling (and "methods") > should do with the flow label. IMO, much (all?) of this is future > work, and this document shouldn't constrain it in anyway. For example, > there may well be too much wording about how one might use the flow > label. For example, there is wording about allowing the receiver to > tell the sender what flow label should be used. This seems premature. > > There is even wording that suggests classifiers need to handle > wildcarding of the source and dest fields in the tuple. Not sure how > much of that is appropriate. > > In summary, I think it would be good for this document to make it > clear exactly what compliant hosts and routers MUST do. Trying to say > anything more than that may tending towards speculation that is > premature. > > Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
