Subject: [clue] Initial comments on draft-even-clue-call-flows-00

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2014 15:11:09 -0400

My most general observation - you ask:

    Question: do we want full XML for CLUE messages or just pseudo code
    providing the parameters?

Good question. IMO using XML will make the call flows hard to write and 
hard to read - the essential features get buried in a mass of 
uninteresting detail. OTOH, if we use pseudo-code then we run the risk 
of being imprecise and accidentally leaving out essential detail.

If we go with pseudo-code then we had better agree on what it will be.

After the option exchange, what is shown is:

-> ADV
<- CFG
-> CFG Resp
<- ADV
-> CFG
<- CFG Resp

I think this is not a reasonable sequence without some intervening O/As. 
In particular, an offer with the encodings needs to be received before a 
CFG can be sent.

Also, there are multiple valid sequences. For instance, Alice and Bob 
may send ADV more or less simultaneously.

IMO we ought to show multiple possibilities, while recognizing that we 
can't show them all. But showing alternatives can also get tedious to 
write and read if done in full detail. I suspect we need a way to show 
these things at various levels of detail. For instance show sequences of 
clue messages with no detail (like I just did above) as alternative ways 
that things might transpire. And then pick one of those to show in more 
detail - showing the actual messages.

Similarly, we might at a high level simply show where offers and answers 
are being sent, and then detail out some of them.

This might work for the content of clue messages too - mostly use 
pseudo-code, but then show the expansion of one or a few pseudo-code 
messages into actual xml.

This same principle could be used for ICE and SRTP - abbreviate or omit 
from most examples but expand in one or a few.

The following are more detailed comments. They may be moot given the above.

Section 1:

    The examples will not include ICE and SRTP negotiations but the
    actual usage SHOULD include ICE and SRTP.

I think it is fine that early drafts don't worry about these.
But we may want to eventually include at least one example of each. I 
have an open mind about this.

Section 3:

The Invite message doesn't have a To header.

The feature tag on the Contact should be '+sip.clue', not 'CLUE'.

In the SDP of the 200 ok:

       m=application 54100 DTLS/SCTP 54111
       a=sctpmap:54100 webrtc-datachannel

s/54111/54100/

In the establishment of the data channel the labeling of the messages is 
confusing. Is this what you mean: (This will be messed up due to 
proportional font):

     Alice                                               Bob

          ClientHello                  -------->
          Certificate*
          ClientKeyExchange
          CertificateVerify*
          [ChangeCipherSpec]
                                       <--------          ServerHello
                                                         Certificate*
                                                   ServerKeyExchange*
                                                  CertificateRequest*

                                       <--------      ServerHelloDone
          Finished                     -------->
                                                   [ChangeCipherSpec]
                                       <--------             Finished
          Application Data             <------->     Application Data

I assume the statement "The SCTP messages are carried in the DATA 
messages" means "The SCTP messages are carried in DTLS DATA messages".

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jun 2014 12:01:55 +1000

Hello Roni,

Thanks for the initial draft.

Some additional comments:
0. General: Perhaps we should focus on the use cases that we want to 
document? Do we want just the basic symmetric flow described in detail 
and then maybe only parts of other use cases? etc. Do we want to show 
unsuccessfull/error cases? Fall back case?

1. General: Would it be possible to have numbered sub-headings for the 
various stages in the flow. e.g. cl.3.1 Invite, cl.3.2 200OK, cl.3.3 
DTLS establishment, etc. I think this would make it easier to review, 
comment etc.

2. Cl.3 : Should we describe what approach will be taken with the call 
flow. E.g. we have the option to send both the basic media and clue 
media in the first INVITE or to only send basic media.

3. Cl.3: Do we need the fingerprint attribute given we're doing DTLS?

4. Cl.3: Pseudo code vs XML : I think it depends what the goal of the 
document is? I would lean towards the XML as this gives an example of 
the data model and going through the exercise of writing XML will serve 
as a check of the data model draft.

5. Cl.3 pg 6: In the option response it uses sequenceNr=4. Is there any 
reason you used that number? The last configure from Alice also uses 
sequenceNr=4. I know this is valid from an implementation view but if 
you were hoping to avoid overlap in the flows there is one.

6. Cl.3 - CLUE flows seem to be missing the Advertisement ACK.

Regards, Christian

On 24/06/2014 5:11 AM, Paul Kyzivat wrote:
> Good question. IMO using XML will make the call flows hard to write 
> and hard to read - the essential features get buried in a mass of 
> I think this is not a reasonable sequence without some intervening 
> O/As. In particular, an offer with the encodings needs to be received 
> before a CFG can be sent.
>
> these things at various levels of detail. For instance show sequences 
> of clue messages with no detail (like I just did above) as alternative 
> ways that things might transpire. And then pick one of those to show 
> in more detail - showing the actual messages.
>
> Similarly, we might at a high level simply show where offers and 
> answers are being sent, and then detail out some of them.
>
> This same principle could be used for ICE and SRTP - abbreviate or 
> omit from most examples but expand in one or a few.
>
> In the establishment of the data channel the labeling of the messages 
> is confusing. Is this what you mean: (This will be messed up due to 
> proportional font):
>
>     Alice                                               Bob
>
>          ClientHello                  -------->
>          Certificate*
>          ClientKeyExchange
>          CertificateVerify*
>          [ChangeCipherSpec]
>                                       <-------- ServerHello
> Certificate*
> ServerKeyExchange*
> CertificateRequest*
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jun 2014 13:19:45 +1000

Just a followup to the pseudo code vs XML issue. Perhaps we can align 
the XML in the call flow draft with the examples provided in the data 
model draft (e.g. cl.22)? That way we'd only need to specify it in one 
place.

Christian

On 24/06/2014 12:01 PM, Christian Groves wrote:
> the data model and going through the exercise of writing XML will 
> serve as a check of the data model draft.
>
> 5. Cl.3 pg 6: In the option response it uses sequenceNr=4. Is there 
> any reason you used that number? The last configure from Alice also 
> uses sequenceNr=4. I know this is valid from an implementation view 
> but if you were hoping to avoid overlap in the flows there is one.
>
>> uninteresting detail. OTOH, if we use pseudo-code then we run the 
>> risk of being imprecise and accidentally leaving out essential detail.
>>
>> IMO we ought to show multiple possibilities, while recognizing that 
>> we can't show them all. But showing alternatives can also get tedious 
>> to write and read if done in full detail. I suspect we need a way to 
>> show these things at various levels of detail. For instance show 
>> sequences of clue messages with no detail (like I just did above) as 
>> alternative ways that things might transpire. And then pick one of 
>> those to show in more detail - showing the actual messages.
>>