Re: [Simple] Comments on draft-ietf-simple-msrp-cema-01 - Ben's Editorial Comments

[Christer Holmberg <[e-mail]>]

Hi, 

> >>>> -- section 2, definition of "middle box": " A SIP network device 
> >>>> that modifies SDP media address:port information in 
> order to steer 
> >>>> or anchor media flows described in the SDP, including 
> TCP and TLS 
> >>>> connections used for MSRP communication, through a media proxy 
> >>>> function controlled by the SIP endpoint. "
> >>>> 
> >>>> Thats the usual definition of an SBC. Seems like we are 
> using the 
> >>>> term middlebox only for SBCs. Maybe we should just call 
> it an SBC?
> >>>> There are many types of middleboxes for which CEMA will 
> not apply.
> >>> 
> >>> First, it is not only SBCs. Application Servers can also be 
> >>> affected.
> >>> 
> >>> Second, we had a loooong discussion about the terminology, and 
> >>> Middlebox was a compromise that people could live with, 
> so I really 
> >>> wouldn't like to have that discussion again....
> >>> 
> >>> It is true that there are many types of middleboxes for 
> which CEMA 
> >>> will not apply, and that is why we have text talking 
> about what is 
> >>> the scope of a Middlebox in the draft.
> >>> If you don't think that text is good enough, I'd rather try to 
> >>> improve it rather than changing the terminology.
> >> 
> >> I can live with middlebox, I guess--but I think we either 
> need some 
> >> qualifier to make it clear from the beginning that we are 
> not using 
> >> the term in its usual sense (e.g CEMA middlebox), or we 
> need text up 
> >> front defining what we mean.
> >> As it is, I can think of no generally used definition of middlebox 
> >> that isn't much greater in scope (i.e. anything that 
> relays packets) 
> >> or much lower in scope (transport level policy boxes such 
> as NATs and 
> >> firewalls)
> >> 
> >> Currently, the term appears many time in the introduction, 
> and even 
> >> the abstract, prior to getting any definition of scope. I 
> think many 
> >> readers are going to read that and think to themselves 
> "No, this is 
> >> false--many middleboxes can work just fine without CEMA".
> > 

>> The text in the introduction talk about middleboxes in 
>> general (we should use "m" instead of "M").
> 
> The second paragraph of the intro is pretty much talking 
> about Middleboxes as defined in this draft, not middleboxes 
> in general. I think many readers are going to trip over this, 
> as you have not yet said "In this draft, we use the term 
> middlebox for something specific, and possibly different from 
> what you've heard before" before we start talking about how 
> Middleboxes work.

In my opinion, the 2nd paragraph still talks about middleboxes in general, and what they currently have to do in order to support MSRP.

What about adding a "as defind in section XX [definitions section]" to the last paragraph of the chapter:

			"This specification defines an MSRP extension, Connection Establishment for Media 
			Anchoring (CEMA). CEMA in most cases allows MSRP endpoints to communicate through 
			middleboxes, as defined in section XX, without a need for the middleboxes to be a 
			MSRP B2BUA. In such cases, middleboxes, that want to anchor the MSRP connection simply 
			modify the SDP c/m-line address information, similar to what it does for non-MSRP media 
			types. MSRP endpoints that support the CEMA extension will use the SDP c/m-line address 
			information for establishing the TCP or TLS connection for sending and receiving MSRP messages."

>> Maybe we could use "CEMA Middlebox" elsewhere in the 
>> document, to make it more clear that we are talking about an 
>> entity that acts as described in the Assumptions section.
> 
>On reflection, I'm not sure CEMA middleboxes is the right 
>choice, unless that's only used to mean SBC-like middleboxes 
>that follow the assumptions in [assumption section].

My suggestion is to use "m" in the introduction chapter, and "M" where we refer to the Middlebox as defined in the draft.

Regards,

Christer