Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Nov 2010 09:23:42 +0800

Hi Christer,

I think we have a rough consensus that, if this moves forward, it should be as an extension rather than an update. Please go ahead and submit the new version. 

Hopefully this will reduce or remove the confusion around having replacing text from RFC 4975.

Thanks,

Ben.

On Oct 26, 2010, at 3:13 PM, Christer Holmberg <[email-masked]> wrote:

> Hi,
> 
> I think it would be useful for people to know whether we are going to define sessmatch as an MSRP extension (rather than an MSRP update).
> 
> I've put together a draft, which I will submit once/if such decission is made:
> 
> users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-08draft01.txt
> 
> It is easier to read and understand than the current version, which defines sessmatch as an update.
> 
> So, does anyone object to an extension approach?
> 
> Regards,
> 
> Christer
> 
> 
> 
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Ben Campbell [[email-masked]]
> Sent: Tuesday, October 26, 2010 12:02 AM
> To: Simple WG
> Subject: [Simple] draft-ietf-simple-msrp-sessmatch
> 
> [As chair]
> 
> You may have noticed that the IESG returned draft-ietf-simple-msrp-sessmatch back to the working group for further discussion, after it generated some controversy during it's IETF last call and sec-dir reviews. There is a separate thread on the SIMPLE list discussing this, but that thread has had very few people comment. Everyone, please read that thread and offer your opinion. We really need to get closure on this draft.
> 
> Thanks!
> 
> Ben.
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Nov 2010 03:45:45 +0100

Hi,

I've submitted a new version (-08) of the sessmatch draft.

Documentation wise the biggest change is due to the fact that sessmatch is now defined as an extension, rather than an update to RFC 4975. Because of that, all of the text that updated 4975 sections have been removed. There is now only a single section describing the extension, and how the session matching associated with it differs from 4975.

There is an open issue whether we need an option-tag for the extension. Personally I don't think we do, but I would like people's input on that.

We also re-wrote much of the text on TLS and MiTM. For TLS, we also describe the usage of TLS-PSK.

Regards,

Christer

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 9. marraskuuta 2010 3:24
> To: Christer Holmberg
> Cc: Ben Campbell; Simple WG
> Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch
> 
> Hi Christer,
> 
> I think we have a rough consensus that, if this moves 
> forward, it should be as an extension rather than an update. 
> Please go ahead and submit the new version. 
> 
> > I think it would be useful for people to know whether we 
> are going to define sessmatch as an MSRP extension (rather 
> than an MSRP update).
> > 
> > It is easier to read and understand than the current 
> version, which defines sessmatch as an update.
> > 
> > From: [email-masked] [[email-masked]] On 
> Behalf Of 
> > Ben Campbell [[email-masked]]
> > You may have noticed that the IESG returned 
> draft-ietf-simple-msrp-sessmatch back to the working group 
> for further discussion, after it generated some controversy 
> during it's IETF last call and sec-dir reviews. There is a 
> separate thread on the SIMPLE list discussing this, but that 
> thread has had very few people comment. Everyone, please read 
> that thread and offer your opinion. We really need to get 
> closure on this draft.
> > 
> > Thanks!
> > 
> > Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Nov 2010 16:55:27 -0600

(as chair)

Hi,

Please, everyone who expressed concerns about version 07, please comment as to whether 08 improves things.

In particular, this version should remove much or all of the need to, in the words of our AD, "Grok it as a diff". Do you find that to be the case? The chairs would like to make sure we have a version people can understand. Once we have that, then we can see if people still have concerns over the substance.

Please comment as soon as you can--we'd like to get this off our collective plates.

Thanks!

Ben. 

Begin forwarded message:

> From: Christer Holmberg <[email-masked]>
> Date: November 8, 2010 8:45:45 PM CST
> To: Simple WG <[email-masked]>, Ben Campbell <[email-masked]>
> Subject: [Simple] Draft new version: draft-ietf-simple-msrp-sessmatch
> 
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Nov 2010 00:57:21 +0100

Hi,

There is also an open issue whether an option-tag is needed, so please indicate whether you have any opinions on that.

Personally I don't think we'll need an option tag.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: 16. marraskuuta 2010 0:55
> To: Cullen Jennings; Adam Roach; Adrian Georgescu; Hadriel Kaplan
> Cc: Simple WG
> Subject: [Simple] Fwd: Draft new version: 
> draft-ietf-simple-msrp-sessmatch
> 
> (as chair)
> 
> Hi,
> 
> Please, everyone who expressed concerns about version 07, 
> please comment as to whether 08 improves things.
> 
> In particular, this version should remove much or all of the 
> need to, in the words of our AD, "Grok it as a diff". Do you 
> find that to be the case? The chairs would like to make sure 
> we have a version people can understand. Once we have that, 
> then we can see if people still have concerns over the substance.
> 
> > Documentation wise the biggest change is due to the fact 
> that sessmatch is now defined as an extension, rather than an 
> update to RFC 4975. Because of that, all of the text that 
> updated 4975 sections have been removed. There is now only a 
> single section describing the extension, and how the session 
> matching associated with it differs from 4975.
> > 
> > There is an open issue whether we need an option-tag for 
> the extension. Personally I don't think we do, but I would 
> like people's input on that.
> > 
> >> I think we have a rough consensus that, if this moves forward, it 
> >> should be as an extension rather than an update.
> >> are going to define sessmatch as an MSRP extension (rather than an 
> >> MSRP update).
> >>> 
> users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-08dr
> >> a
> >>> ft01.txt
> >>> 
> >> draft-ietf-simple-msrp-sessmatch back to the working group for 
> >> further discussion, after it generated some controversy 
> during it's 
> >> IETF last call and sec-dir reviews. There is a separate 
> thread on the 
> >> SIMPLE list discussing this, but that thread has had very 
> few people 
> >> comment. Everyone, please read that thread and offer your 
> opinion. We 
> >> really need to get closure on this draft.
> >>> 
> >>> Thanks!
> >>> 
> >>> Ben.

---

From: Nancy Greene <[email-masked]>
Date: Mon, 15 Nov 2010 21:59:45 -0500

I agree that there is no need for an option tag.

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: November-15-10 6:57 PM
To: Ben Campbell; Cullen Jennings; Adam Roach; Adrian Georgescu; Hadriel Kaplan
Cc: Simple WG
Subject: Re: [Simple] Fwd: Draft new version: draft-ietf-simple-msrp-sessmatch

Hi,

Regards,

Christer

> Please, everyone who expressed concerns about version 07, please 
> comment as to whether 08 improves things.
> 
> In particular, this version should remove much or all of the need to, 
> in the words of our AD, "Grok it as a diff". Do you find that to be 
> the case? The chairs would like to make sure we have a version people 
> can understand. Once we have that, then we can see if people still 
> have concerns over the substance.
> 
> that sessmatch is now defined as an extension, rather than an update 
> to RFC 4975. Because of that, all of the text that updated 4975 
> sections have been removed. There is now only a single section 
> describing the extension, and how the session matching associated with 
> it differs from 4975.
> > 
> the extension. Personally I don't think we do, but I would like 
> people's input on that.
> >

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Nov 2010 22:59:08 -0600

(as individual)

I think I concur that we don't need a tag. Thinking through this--what happens without a tag?

If a sessmatch implementation and a 4975 implementation engage in a peer to peer session, this the 4975 implementation should not see a difference, since the MSRP URLs in the SDP are unchanged, and the original full MSRP URI will still match using sessmatch rules.

If, on the other hand, the session crosses an SBC, the 4975 client will reject the URL in the To-Path of the first MSRP request sent by the peer as not matching the session. But this also would happen if both peers were 4975 implementations, so it doesn't seem to make a difference. If the sessmatch were to _require_ a sessmatch tag, the failure would be faster and cleaner. But that would break the peer to peer case. I don't think we can expect a client to know if it is behind an SBC, so this doesn't really help, and might even make things worse.

One potential use that Christer and I discussed offline for a sessmatch tag in a Supported header would be to signal to a middle box whether sessmatch was supported. Maybe it acts like an MSRP B2BUA if no tag is present, but not if sessmatch is supported. I don't think this works, as the SBC would have to make the decision before it saw the SDP answer.

Also, I don't think we want to be in the business of specifying middle box behavior.

So, I don't think we need a tag. But I'd like other people to think this through, because I could be wrong ;-)

Thanks,

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Nov 2010 12:37:41 +0100

Hi,

It seems like nobody has expressed a wish/need to define an option-tag, so my intention is to submit a new version of the draft and remove the open issue regarding the option-tag.

However, I think it would be good to add some text to the draft why an option-tag is not defined, in case the question comes up at some point.

So, I was thinking about something like:

"NOTE: As the sessmatch extension, in a peer to peer session, is backward compatible with the RFC 4975 mechanism, the SIMPLE WG 
did not see a need to define a SIP option-tag associated with the sessmatch extension. In case the session path contains an intermediary
that modifies the SDP MSRP routing information, MSRP session establishments that contain RFC 4975 entities will fail. However, that is the
case even without the sessmatch extension. Also, an intermediary will normally make a decission whether to insert itself in the session path 
when it receives the SDP offer. However, it will not be aware about whether the MSRP endpoint acting as SDP answerer supports the sessmatch 
extension until it receives the SDP answer."

Comments?

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 16. marraskuuta 2010 6:59
To: Nancy Greene
Cc: Christer Holmberg; Cullen Jennings; Adam Roach; Adrian Georgescu; Hadriel Kaplan; Simple WG
Subject: Re: [Simple] Fwd: Draft new version: draft-ietf-simple-msrp-sessmatch

(as individual)

Thanks,

Ben.

On Nov 15, 2010, at 8:59 PM, Nancy Greene <[email-masked]> wrote:

>> describing the extension, and how the session matching associated 
>> with it differs from 4975.
>>>