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