Re: [MMUSIC] Review of draft-ietf-mmusic-trickle-ice-sip-02

[Thomas Stach <[e-mail]>]

Simon,

thanks for the review.
More inline.

> WG,
>
> In Prague I volunteered to review this draft. Here's my review.
>
> In general the document is close to being done, but there are a few
> minor things that require a new revision before WGLC.
>
>
> Major
> =====
>
> (nothing)
>
>
> Minor
> =====
>
> - There are quite a few open issues and notes that need to be closed:
>
> 6. Considerations for RTP and RTCP multiplexing
>
>     [OPEN ISSUE: These considerations are of general relevance
>     and might be better suited for draft-ietf-mmusic-trickle-ice
>
> 7.  Considerations for Media Multiplexing
>
>     [OPEN ISSUE: These considerations are of general relevance
>     and might be better suited for draft-ietf-mmusic-trickle-ice.]
My proposal for these is to keep the text in this document.
draft-mmusic-trickle-ice can still include (or repeat) corresponding 
text for other applications
of Trickle ICE outside of SIP.
>
> 9.8.  Rate of INFO Requests
>
>     [OPEN ISSUE: What rate will give a good trade-off? 100ms, 200ms?]
This was discussed in IETF-93. We will not recommend an explicit value.
>
> 9.6.  Info Message Body Parts
>
>     [NOTE: end-of-candidates-att currently lacks a formal definition in
>     [I-D.ietf-mmusic-trickle-ice]]
Something to be resolved in draft-mmusic-trickle-ice. I'll keep this 
note until it is done.
>
>
> - "Section 4.1. Establishing the dialog" says: "The SIP dialog at both
> sides MUST be at least in the early state."
>
> What does "at least" mean in this context? Do states have numerical
> value?
This refers to https://tools.ietf.org/html/rfc3261#section-12.
I could reword to "The dialog at both sides MUST be in early or 
confirmed state"
> I sort of get what the intent is, but it could be stated more
> precisely.
>
>
> - On page 11 I suggest rewording for clarity:
>
> OLD:
>     This
>     INFO message can repeat the candidates that were already provided in
>     the Offer (as would be the case when Half Trickle is performed or
>     when new candidates have not been learned since then) or they can
>     also deliver new new candidates (if available).
> NEW:
>     This
>     INFO message MAY repeat the candidates that were already provided in
>     the Offer (as would be the case when Half Trickle is performed or
>     when new candidates have not been learned since then) and/or they MAY
>     deliver new candidates (if available).
OK
>
>
> - Sections 4.1.2 and 4.1.3 contain this:
>
>     When sending the Answer in the 200 OK response, the Answerers MUST
>     repeat exactly the same Answer that was previously sent in the
>     unreliable provisional response in order to fulfill the corresponding
>     requirements in [RFC3264].
>
> Doesn't that also apply to 4.1.1 and 4.1.4? If so, wouldn't it make
> sense to factor it out so that it applies in every case?
In 4.1.1 and 4.1.4 the answer is sent only once.
In case of 4.1.1 this is a reliable provisional response, in 4.1.4 it is 
either the PRACK (offer in reliable provisional response) or in the ACK 
(offer in 200OK).
RFC6337 deals with unnecessary repetitions, but I don't think we need to 
reference that one here.
>
>
> - On page 18, the example's content-type should be application/sdpfrag.
Will be addressed
>
> - On page 26, please make the lines fit the RFC format line width.
OK
>
>
> Nits
> ====
>
> Page 6: s/In order for to benefit/In order to benefit/
> Page 10: s/provisioanl/provisional/
> Page 12: s/Answerers/Answerer/
> Page 12: s/less candidates/fewer candidates/
> Page 12: s/SIPfrag/SDPfrag/
> Page 12: s/M UST/MUST/
> Page 13: s/less candidates/fewer candidates/
> Page 17: s/local candidates/host candidates/
> Page 22: s/sdp-frag/sdpfrag/
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic