Hi Hannes, On Sat, 9 Apr 2011, Hannes Gredler wrote:
> | > I have no problem listing various transports. I thought there was a > suggestion to > | > keep one of them mandatory to encourage better interoperability. That > makes > | > some sense. > | > | Frankly the interoperability argument is a very strong one for me. Yes, at > every > | step and with every component of this design we could enumerate a laundry > list > | of possible technologies, but, frankly, it seems like a less than useful > exercise > | of constructing complexity and threatening interoperability of the resultant > | system. If the intention is to produce robust specifications that allow > cleanly > | interoperable implementations then it makes sense for me to produce a > | specification that makes specific selections from the choice set. > > the question is *what* is that we try to standardize ? - is it > > 1. the application level communication protocol between caches and routers > 2. the application level communication protocol between caches and routers > and the transport ? > it's 1. However, an (inherent) requirement of the protocol is (a) to deliver the data such that it is authenticated and (b) the integrity of the data can be verified. Otherwise, at least from my perspective, the protocol would be useful. Leaving the mechanism for authentication and integrity undefined would result in a not well-defined protocol. From an implementation and deployment perspective, this is quite painful. We do not breach the "spirit of good layering" if we precisely define how this requirement can be achieved. Maybe, the question is if there is anything else to achieve the goals, which is not out-dated, implemented, and beyond the current suggestions. Best regards matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:[email protected] .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
