(as individual)

Simon & Paula,

Thanks for doing this! I have some questions about it:

You have separate state machines for MP and MC, and note that typically 
a node will be both. Are you assuming the messages for both will flow 
over the same data channel? (I assume so.) If so, then I guess there 
must be a low level demux that sorts out the incoming messages and 
directs them to either the MP or MC state machine. And if it becomes 
necessary to add any other messages it will be necessary to ensure that 
the same message type can't be received by both the MC and the MP.

You propose that RE-ADV contain a reason. While I understand 'refresh' 
as a reason, don't the other reasons you mention duplicate the response 
code that would presumably have been sent first? If the reason is 
because there was something incorrect in the prior ADV, is there any 
reason to expect that it will get better when retried? I guess we at 
least ought to recognize that some things can't be fixed by RE-ADV, and 
have a more extreme transition. (Perhaps to reinitialize the data channel.)

Re both state machines:

obviously we need to think about timeouts. ISTM that however we set the 
timeout value, it can result from either a transport level problem or an 
application level problem. Presumably transport level problems will be 
detected by the transport itself, and we may have no control over the 
timeout level for that. If its like TCP, then it is probably longer than 
we would want to wait, so we may get a timeout at application level that 
reflects a transport problem, and that can't be distinguished from an 
application level problem.

If its a transport problem, then there is no point in retrying, since 
the reliable transport will have done what it can and an application 
level retry will be behind that.

Even if we knew we had an application level problem, is it worthwhile to 
retry it over the same data channel?

I see that you call for every ADV to get a response. Were you thinking 
of a tight timeout here, or a loose one.

In MC state machine:

I think it will be easy to get into an infinite loop between ADV 
RECEIVED and TRYING when the CONF is not acceptable. We need to find a 
way to break that loop. Again, I'm not sure how ofter a retry at this 
level will be helpful.

I think there is a missing transition: if in TRYING due to having sent a 
CONF from IN CALL, then it is possible to receive another ADV before the 
response to the CONF. This is also the case where the subsequent 
response to the CONF might be an error. But then the fix is to send a 
CONF to the *new* ADV, rather than the old one.

In MP state machine:

If in WAIT FOR CONF and take the "change tp settings" transition, will 
end up back in WAIT FOR CONF. But now there will be *two* CONFs coming, 
one for each ADV sent. Assuming the messages are properly coded, then it 
will be possible to detect that one is for the wrong ADV. I guess this 
is covered by the "send error response" transition from CONF RECEIVED to 
WAIT FOR CONF. But, as above, having this singe error transition opens 
possibility of an infinite loop. Can fix this one with a separate 
transition from CONF RECEIVED to itself when the received CONF is for 
and old ADV.

	Thanks,
	Paul

On 7/10/13 1:19 PM, Simon Pietro Romano wrote:
> Hello guys,
>
> as you probably noticed, we have just submitted a first attempt at
> defining a state machine for both the CLUE Media Producer and CLUE Media
> Consumer entities.
>
> http://www.ietf.org/id/draft-presta-clue-protocol-00.txt
>
> Please have a look at it and treat it like no more than a first stone in
> the lake of discussion!
>
> Cheers,
>
> Simon