Subject: Re: [Simple] Sessmatch extension [was: secdir review of draft-ietf-simple-msrp-sessmatch]

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Nov 2010 20:16:33 +0100

Hi,

I am going through the comments given by Ben, and I will do some updates based on that.

But, I haven't heard any objections to making sessmatch an extension, so I intend to submit a new version of the draft based on that.

Regards,

Christer

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Saturday, October 30, 2010 6:53 PM
To: Christer Holmberg
Cc: Simple WG; Cullen Jennings; Gonzalo Camarillo
Subject: Re: [Simple] Sessmatch extension [was: secdir review of draft-ietf-simple-msrp-sessmatch]

Yeah, it's pretty hard to grok as a diff.
I think a self-contained extension doc is better.

-hadriel

On Oct 22, 2010, at 6:42 AM, Christer Holmberg wrote:

>
>
>> So if this is all backwards compatible, I rather see this done as an extenuation of 4975 that is not an update to it with real discussion of how this fits into an existing system.
>
> We have put together a new pre-version of the draft, that could be used as base for an extension. It can be found at:
>
> http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-08draft01.txt
>
> I will submit it as soon as you decide to define sessmatch as an extension.
>
>
> ------
>
>
>> But even without such a normative requirement, the mere fact that this discourages the use of an otherwise
>> available security mechanism weakens security.
>
> The draft doesn't discourage anything.
>
> Some applicability restrictions were added based on the IESG security review/discussions.
>
> But, if sessmatch now becomes an optional extension, it becomes more clear that implementors can choose for themselves whether to implement sessmatch or not, taking the restrictions into consideration.
>
> (Unless, of course, there is a way to get rid of the restrictions.)
>
> ------
>
>
>>> I was pretty sure version 06 was backwards compatible, but I am not so sure about version 07.
>>>
>> I'm not sure either - and the fact that is is not obvious to
>> either of us is probably a big hint that some work is needed.
>
> Without information on what exactly you think makes it non-backward compatible, it's difficult for me to address the comment.
>
> There was no change to the session matching procedure itself in -07.
>
> The changes/additions were mainly used to:
>
> 1. Clarify that the MSRP URI comparison mechanism in 4975 is not modified;
> 2. Clarify that the session-id part of the URI, rather than URI comparison, is used for the session matching; and
> 3. Clarify the security restrictions
>
>
> Having said that, due to the clarifications above, we ended up having to update more parts of RFC 4975 than originally planned (and agreed in the WG), so I fully understand that it might be difficult to get a clear overview picture without copy/pasting the text into 4975 etc.
>
> But, if we go for the extension approach, all the 4975 updates will of course go away (as you can see in the draft01 version above).
>
>
> Regards,
>
> Christer
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Nov 2010 21:31:00 +0200

> Yeah, it's pretty hard to grok as a diff.

"Thou art God", if you can grok it as a diff :o)

Cheers,

Gonzalo