See my rant at the end, in response to Christer's email. I haven't
sent it to the list yet.
Am I grasping at too abstract a concept? I.e., ignoring the basic
repugnancy of SBCs, is it reasonable to argue that we shouldn't
_in_general_ modify protocol to work with proprietary devices
without documenting our assumptions about said device behavior and
how the protocol modification works with these assumptions?
------------------------------------
(as individual)
On May 19, 2009, at 12:40 AM, Christer Holmberg wrote:
Hi,
In particular, I am skeptical about doing non-trivial changes
to make MSRP work better across proprietary intermediaries without
some better description of what will and will not work in
the general case (i.e. not just what will work with one vendor.)
As said before, I don't think this is about "one vendor".
So what _is_ it about? To my knowledge, We've had only one vendor
stand up and say "this stuff will work across our SBCs".
You are trying to work around the behavior of proprietary middle
boxes. They may behave similarly in some ways, but not others. For
example, if other vendors don't have support for TCP media, then
there's not much value in this for them. Without some standard
behavior, or some survey of behavior like BEHAVE did with
NATs, we're just sort of hoping things will work most of the time.
That
may be
good enough to write product requirements around, but it's probably
not good enough to write standards around.
What it is about is to allow these middle boxes to treat MSRP more or
less like any other type of TCP media, without having to modify the
MSRP
messages etc.
Of course, some intermediates may not support TCP in the first place,
but that's normal. We don't expect everyone to support everything
we do.
But, OMA PoC uses MSRP, so compliant intermediates will have to
support
TCP. 3GPP IMS uses MSRP, so compliant intermediates will have to
support
TCP. Intermediates also DO exist in other SIP networks, so in order
for
MSRP to work they will have to support TCP. That is what I meant by
the
statement that it's not only about one vendor.
Forgive my ignorance, but does PoC specify intermediary behavior?
So, in my opinion, intermediates can be expected to support TCP. The
issue is with supporting legacy MSRP, and that is what ACM is
trying to
solve.
I do agree that these intermediates aren't standardized, but when it
comes to sending the media through them they all behave in the same
way:
by modifying the SDP.
Of course, If we also for ACM would still use the a=path attribute
for
routing, rather than the c/,- line, the intermeidates will of course
have to be able to modify the a=path attribute. But, no matter
whather
that can be done using configuration (I guess that is what Hadirel
indicated for his product) or whether it requires a software patch,
it's
a relatively small thing compared to having to modify MSRP messages.
Do we expect this draft to specify the actual middlebox behavior
that is enabled by changing the treatment of the path attribute URIs?
The point I am struggling with is, this part of the ACM draft does
not add value in itself. Rather, it sets out to relax an MSRP
requirement to enable another middlebox to add value. But the
behavior of that middlebox is not standardized, and we haven't
really analyzed the requirements for the middlebox to get its job
done. And we know full well that there are security implications
both in this new behavior we propose for the middlebox (i.e.
rewriting path attributes) as well as the presence of the middlebox
in the first place.
This is pretty much the same argument that has been popping up in
all of RAI concerning the collision between SBCs and the SIP
architecture as defined by the IETF.
If we are going to change MSRP to enable SBCs or any other sort of
middlebox, I'd really like to see more documentation on how that
middlebox is expected to behave in context, and how the whole
architecture works when said middlebox is present. I'm not
necessarily talking about normative specification.This is the point
I was trying to get across in previous reviews when I suggested we
needed some use case analysis and possibly call flows to describe
the requirements that section 4.2 sets out to solve.
We spun up a whole working group (BEHAVE) to do this for NATs, and
subsequently learned that many of or generally held assumptions were
wrong.
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple