Re: draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben)

Hi,


> -- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are not going to result in interoperable implementations. The various efforts to decide you can still use CEMA even when the peer does not advertise it remind me of the rules of Fizzbin ( 
> http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to resolve names to IP addresses for comparison purposes in 4.4, I have to ask if we really think the benefit is worth the complexity? Can it be streamlined somehow?

In the past, we spent lots of time in order to clarify these sections, based on input from e.g. Eric Burger and yourself.  And, there aren't any major changes compared to version -03.

I really don't know how it can be further streamlined, and suggest to keep it as it is.


-----------------------


--1, 2nd paragraph" "middleboxes must read the message"

Just read? Or parse, or modify?

> -- "address:port"  (recurs throughout document)
>
> address and port. 

Ok.


-----------------------


> -- "c/m- line"  (recurs throughout document)
>
> c and m-lines, or c-line and m-line. (i.e. don't use "/" as a conjunction)

Ok.


-----------------------


> -- 1, 3rd paragraph: "...that normally result in negative performance impact"
>
> _which_ normally _results_...

Ok.


-----------------------


> -- 2, "Fingerprint Based TLS Authentication: An MSRP endpoint..."
>
> I don't think Fingerprint based TLS authn _is_ an endpoint--it's an action. (repeats for name-based..)

Ok.


-----------------------

--2, "Name-Based..."

Definition is hard to parse. I think the point is two-fold. The endpoint uses a trusted CA to establish the validity of the peer certificate, then compares the SAN of the peer certificate has a match for the peer's  MSRP URI.

I am not sure I understand. Do you have a suggestion for modified text?


-----------------------

> --2, "MSRP B2BUA" "... terminates an MSRP connection from one MSRP endpoint and reoriginates that connection..."
>
> s/connection/session

Ok.


-----------------------


> -- "...SIP B2BUA terminates a SIP session...
>
> s/session/dialog  (or transaction).

Ok.


-----------------------


> -- 4.2, step one  on receipt of an answer:
>
> I have trouble parsing this

I think the text is clear. It says that the c/m does not match path, and that the endpoint will become passive.

But, if you think the text can be improved, feel free to suggest text.


-----------------------


> -- 4.2, step 3 on receipt of an answer
>
> -- 4.4, paragraph 6 (Note) : "... MSRP URI must always contain a port."
>
> ... when used in an SDP path attribute.

Ok.


-----------------------


> -- 6.2, 1st paragraph: "... where the offerer does not support the CEMA extension."
>
> Doesn't that preempt some of the endpoint workarounds for when the peer does not advertise CEMA?

Yes, and the Middlebox doesn't need to enable MSRP B2BUA functionality in cases where the workarounds can be used.


-----------------------


> -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide."
>
> Decide what?

I suggest to remove that sentence, and re-write the subsequent sentence in the following way:

 	"In the end it is up to the endpoint to decide whether the signaling path is trusted or not, and unless
	unless cryptographic end-to-end SDP integrity protection or encryption is used it may be hard for the
	 endpoint to make that decision."


-----------------------

Regards,

Christer