Well, Elwyn, here's the problem: apparently the likelihood of these ever
being deployed is vanishingly small. So a protocol could be defined, but
it would be wasted effort. (It's also outside the PCN charter, most
likely because RSVP was supposed to be the transport. But that's another
story ...)
In fact, I and a couple of others started to define a Diameter
application to do the job. I'm not sure how realistic that would have
been, in terms of messaging load. Diameter transport is supposed to be
over TLS these days.
Tom T.
On 14/06/2011 1:20 PM, Elwyn Davies wrote:
Hi, Phil.
It strikes me that the first and second points below are something which
David Harrington perhaps ought to give an opinion on. He has got to
defend it to the IESG.
On the first point, my feeling is that neither the requirements doc nor
this doc is sufficient to guarantee an interoperable implementation.
There seems to me to be a cleft stick here (irrespective of whether this
ends up as informational or experimental.) The WG is is specifying
pieces of functionality that go in two or more different types of boxes
(three if there is a separate implementation of the central decision
point). If the system is going to be generally deployable or even to be
experimented with there may be different implementations. The box types
communicate using the information specifications in the doc. This
appears to require protocol definitions. Where they are defined is
another issue but I feel it has either to be in this doc or in another
doc referenced from this. If they aren't specified I can't see that
anybody will be interested in making commercial implementations.
I see David didn't make any comment about this situation in his write
up, so maybe I am over reacting.
Regards,
Elwyn
...
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
