Re: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility]

[Adam Roach <adam at nostrum.com>]

Ben Campbell wrote:
> 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.

I agree wholeheartedly with Ben's sentiment regarding the assumptions 
we're making about SBC behavior, and I think the comparison to NATs is 
quite appropriate. Saying that SBCs operate "by modifying the SDP"[1] is 
as useful as saying that NATs operate "by changing IP addresses." You 
can make certain assumptions about what these changes look like, but 
they're just assumptions. And right now, they're not even documented 
assumptions.

We've been down this road before. For example, we spent a lot of work to 
develop a protocol to characterize NATs based on untested assumptions 
about NAT behavior. It was only after we actually spun up BEHAVE and did 
the work documented in draft-jennings-behave-test-results that we 
realized we had wasted vast man-years of engineering resources for 
naught. RFC 3489 stands as a tombstone to our hubris and carelessness.

I am certain that we have relevant lessons to learn from BEHAVE, and 
that many of them fall in the category of "trying to engineer protocols 
around an undefined entity is folly."

/a

[1] http://www.ietf.org/mail-archive/web/simple/current/msg08392.html