Re: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-cs-11.txt

[Flemming Andreasen <[e-mail]>]

Hi

I have reviewed the above draft and have some comments (as chair) that 
will need to be addressed before we can move this one forward:

Technical Comments
=============

1) The document defines the "E164" 'addrtype' type as well as the "-" 
'addrtype' to be used in the "c=" line and wants to register these with 
IANA. As it turns out, RFC 3108 also defined these, however they never 
got registered with IANA. While the '-' seems to be defined similarly, 
the syntax for the "164" differs between the two, which is obviously a 
problem, not least considering RFC 3108 is Standards Track. Also, for 
some reason the cs-draft lists RFC 3108 as a normative reference, but it 
does not provide any normative text for its use.


2) The "cs-correlation" attribute includes an extension mechanism, 
however there is no description of how to use it, or any offer/answer 
procedures associated with it. For example, what do cs-draft 
implementations do if they encounter one or more unknown extensions.



- Section 5.2.1
OLD:
Note that <addrtype> and/or <connection-address> should not be
NEW:
Note that <addrtype> and/or <connection-address> MUST NOT be


- Section 5.2.3.1
Can there be at most one cs-correlation attribute per media description 
? If not, are multiple occurrences concatenated ?


- Section 5.2.3.3
OLD:
bit appearing first in the binary data shall be most significant
NEW:
bit appearing first in the binary data SHALL be most significant


- Section 5.3.1
OLD:
circuit-switched bearer is set up should be negotiated
NEW:
circuit-switched bearer is set up MUST be negotiated


- Section 5.6.1
<quote>
    If an Offerer does not know its international E.164 number, it MUST
    set the 'a=setup' attribute to the value 'active'.  If the Offerer
    knows its international E.164 number, it MUST set the value to either
    'actpass' or 'passive'.
</quote>
There may be reasons for an endpoint to not wanting to be passive, and 
hence should we change the last "MUST" to "SHOULD" ?


- Section 5.6.2
</quote>
    After generating and sending the Answer, if the Answerer became the
    active party, it
</quote>
There is a race conditition between this answer making it back to the 
offerer and the correlated incoming call being received by the offerer. 
While this race condition may seem unlikely in practice, it does exist 
and needs to be called out (and ideally with workarounds).


- Section 5.6.2
OLD:
   o  if the SDP Answer contained a value for the "callerid" subfield, 
must set
NEW:
   o  if the SDP Answer contained a value for the "callerid" subfield, 
MUST set


- Section 7 (Security Considerations)
The mechanism defined in this document effectively allows an entity A to 
cause another entity B to generate PSTN calls as A desires. There are 
third-party attack considerations and potential toll charge concerns 
that need to be addressed as part of that.



Editorial Comments
============

- Section 5.6.2, third paragraph
<quote>
If the Answerer is aware of its
    international E.164 number, it MUST include the "a=setup" attribute
    in the Answer and set it to value "passive" or "holdconn".
</quote>
Add: The Answerer MUST also include its E.164 number in the "c=" line.


Section 5.6.2
<quote>
    The Answerer MUST select those correlation mechanisms from the Offer
    it supports, and include an "a=cs-correlation" attribute line in the
    Answer containing those mechanisms it supports.
</quote>
Must the answerer select all the ones it supports or just a non-empty 
subset (clarify) ?


- Section 8.4
Per RFC 4566, Section 8.2.2, when a new "proto" value is registered
<quote>
Registrations MUST also define the rules by which their "fmt" namespace 
is managed (see below).
</quote>
Section 5.2.2 does describe this, however it would be desirable to 
either describe it here as well or include a pointer to Section 5.2.2.


- I have some additional minor editorial comments that I will send in a 
marked-up copy of the doc off-line.


Thanks

-- Flemming



On 5/22/12 6:53 AM, Miguel A. Garcia wrote:
> This is to start a 2-week Working Group Last Call for
>
>        draft-ietf-mmusic-sdp-cs-11.txt
>
> The WGLC ends on June 5th, 2012.
>
> Please reply to this e-mail to send comments, so that the authors and 
> the mailing list are all copied.
>
> /Miguel