Re: secdir review of draft-ietf-simple-msrp-sessmatch

[Hadriel Kaplan <[e-mail]>]

On Oct 14, 2010, at 4:27 PM, Cullen Jennings wrote:

> 3) The backwards comparability issue seems huge. Some people have said an endpoint using this draft will not talk with one that only does 4975. Yet if this draft if published as an RFC would basically depreciate the 4975 and replace it with a the result of applying this diff to 4795. So if one person implements the pre update version, and another person the post - it's not clear to me how we migrate from old to new on the existing deployments. A flag day is obviously not going to work. The more I look at this, the more I think this draft needs to be  recast as a backwards compatible extension to 4975 and not a draft that update 4975. When I look at how this changes 4975 it seems to mostly relax the existing security but not disallow things that used to work so I think it should be possible to do this. On a side note, I phoned a few people who I know that have MSRP implementation and none of them had any plans to implement this and were surprised to hear there was a draft that would update in 4975 with a change like this. To me this combined with the no backwards compatibility issue argues strongly for figuring out how to make this an extension instead of a change to MSRP.

Who were those people?
Everyone I've talked to not only knows about it, but has implementations. (though in most cases implementations of the original acm proposal... they're waiting on an RFC before changing again)  Though I will concede my list of vendors to ask this of is by nature going to be prone to doing this, since I talk to folks to interop with and my systems implement acm as well.  

As for the flag-day issue, in theory yes, I think it would require a flag-day if there were a large population of legacy 4975 trying to talk to a population of this extension.  In practice, that hasn't been necessary afaict.  The domains that use full app server MSRP relays, a la 4975, have the ability to interwork to an acm-style model in that app server; the domains that don't have such app servers don't have a problem to begin with, since they had to use an acm approach to not need to have app servers. 


> 4) When I search the email lists, I find more more people who see significant problems with this than I find people that seem to think it is OK. I don't think it has consensus -I think it just has people who stopped care.  The changes that needed to happen in IETF LC to fix this draft so it had any chance of working at all more or less convinced me the WG did not read this draft. The [e-mail] list is not an ideal location for discussion that rewrites pretty much all of the normative text of this draft (which is what is happening here).
> 

I personally stopped caring when implementations of draft-acm showed up and the problem was "solved".  In some ways this fits in quite nicely with the recent discussion on ietf@ietf about  taking too long with RFCs and making their bar very high, and people deploying drafts instead.

-hadriel