On Thu, 13 Mar 2003, Alex Conta wrote: > Please remember: publishing IPv6 specs as proposed > standard (RFC), was never dependent on publishing or referencing an API.
Then again, not all that may IPv6 specs state that implementation MUST provide applications with a way to set "foo". > > 2) implementations not implementing all of the flow label spec, ie. just > > blatantly ignoring the MUST (compare with the temporary/public address > > knob in the default address selection, in RFC3484 sect 5r7 -- this was a > > bad last-minute compromise which nobody have implemented AFAIK) > > > > It is a fact of life to have non-fully compliant implementations. > That is orthogonal to the progress of a specification to proposed > standard. Depends on what you want. I'd prefer working, useful specifications which do not have requirements which are not met. > > I wonder if they realized the implications. I'm sure that e.g. people > > focusing on the network part of the flow label would really appreciate > > having a flow labels guaranteed to be distinct, so their use in QoS and > > whatever would be a lot simplified, but that ignores the big picture at > > the expense of looking at only part of the solution space. > > > > I think they did. Even though it is succinct, the specification defines, > or mentions a number of mechanisms pertinent to a very diverse set of > views, and uses. Personally, I favor some over the others, but after > thinking, and understanding, I agreed that all can work. This was > essential for being part of the current consensus, which took a long > time, and a lot of work, from the WG, the authors, the WG chairs, and > the area directors. Consensus is not useful unless the result is useful. > > The spec very clearly states that flow labeling enables classification > > based on (src, dst, flow label). That is clearly different than (src, > > dst, protocol, srcport, dstport). > > > > You're pointing now to a difference in the placement of the fields in > the headers, which I think is orthogonal to the difference you were > pointing at before, to which I responded that there is no difference. No, I'm not interested in the placement -- I'm concerned about the data available to the network operator, and the assumptions the spec will give him on its applicability. > Earlier, I think you were trying to say that without flow label, there > is a certain model, which changes with the use of the flow label. That's correct. > Essentially, I responded that it is not the case, the model does not > change: the model of trusting/doubting a flow label is not different > from the model of trusting/doubting a pair of ports and a protocol > number: they're all set by the source node of the packets, and are part > of some classifiers set with some direct/indirect knowledge/agreement > from network infrastructure operators. If you believe adding the flow label in the mix does not change the model, I'd maybe call it naivete. The question is how much (and how) it's changed. But perhaps it would be better to have a look at some of the security considerations text I proposed on the list a few hours ago, and if you disagree, try to describe how you see the the model between the network and source nodes so we could understand the views better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
