Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt

[Roberta Presta <[e-mail]>]

Hello Christian,

thank you for your comments.
Please see below.

Il 11/10/2013 05:16, Christian Groves ha scritto:
> Hello Simon and Roberta,
>
> Thanks for the updates. I had a look and have a few comments below:
>
> 1. Sect.1 bullet 2 : The Config allows captures and encodings to be 
> selected so I would propose to update the wording:
>     2.  enabling a MC to request the desired <media captures and the 
> resulting> multimedia streams from the offering MP.
We have considered a stream as a capture encoding, i.e. the association 
of a media capture and a capture encoding, as per the framework 
definition of "stream".
We will recall such definition in section "Terminology".
>
> 2. Sect.3 1st para: The MC not only requests the stream but receives 
> them. I propose updating the text:
>   ...while the client side is represented by the Media Consumer, which 
> requests <and receives> the media streams.
>
OK.
> 3. Sect. 3 3rd para: Similar comment to 1 above. I propose rewording:
> The MC selects the desired <captures and> streams coming from the MP 
> by using...
Same considerations of point 1.
>
> 4. Sect. 3.x: The tables have "Type". Is this really needed as it is 
> explained in the text. Plus 3.2 the message name is "Response" and the 
> type is "Response". It seems superfluous.
>
The type of the message is an important characteristic.
Indeed, notifications, requests and responses are the three main classes 
of CLUE messages.
A request is issued only by a MC to a MP, and each request expects a 
response message coming from the opposite direction.
A notification (like the advertisement) is an asynchronous announce.
CLUE messages are demultiplexed in a CLUE endpoint on the basis of the 
type of the message:
- A MC receives only responses and notifications, while it issues only 
requests
- A MP receives only requests and issues responses and notifications
CLUE messages are expected to belong to one of the aforementioned 
categories (and this is reflected in the schema definitions).
The draft definitely needs more text about it.

> 5. Sect.3.3: Nit: Rescription should be "Description"
>
OK.
> 6. Sect 3.x: Are we missing a message? There is a Response for a 
> Configure but there is no response to an Advertisement. If the MC 
> receives an Advertisement there should at least be an indication that 
> it was received OK. Why would a response to a Configure or an 
> Advertisement be handled differently. I think the RE-ADV should only 
> be used when the MC needs to refresh its state, not for indicating 
> that there is a Advertisement message syntax problem, etc. Note: this 
> is a similar comment as Paul's regarding the application level ACK. I 
> don't think that a ADV needs an immediate CFG.
>
Currently in the draft there isn't a mechanism that acknowledge the ADV.
We have not considered acknowledge mechanisms at all and we have tried 
to only rely on timeouts and retry mechanisms, i.e., if nothing happens 
within the timeout interval and the timeout fires, then the message is 
issued again. This is repeated until the max number of retry is achieved.
We can discuss the  introduction of acks for notification messages. An 
acknowledgement mechanism should not be needed by the request-response 
couples since the responses act as acks.
The READV functionality could be then reduced to the one of a simple 
refresh request, since problems with the received ADV could be treated 
otherwise.

> 7. Sect.5 2nd para: What is meant by ".. if the number of trials is 
> below the retry
>    threshold...?
>
Explained in answer to point 6. We will correct the text in order to 
make it clearer.
> 8. Sect.5 3rd para: As per 6 I think that rather than RE-ADV a 
> "ADV-RESP" would be sent indicating an error condition. A MP should be 
> the one to decide to determine if another ADV is sent.
>
I'm OK with decoupling the READV functionality from the problems with a 
received ADV as per point 6.

> 9. Sect.5 3rd para: This indicates that if there is an error with the 
> ADV the MC goes from state "receive ADV" to "IDLE". What doesn't 
> appeared to be covered is what happens if the MC is in "IN CALL" state 
> when it receives the ADV and there's an error? I would assume that 
> rather than go to IDLE on error that it would go back to "IN CALL"? 
> The state could potentially be affected by what error is received.

The IN CALL state indicates that the media streams the  MP and the MC 
have agreed on (and are aware of) the media streams to be exchanged 
within the call.
When a MC/MP goes out from the IN CALL state it means that something has 
changed and that the media streams currently exchanged may not be 
aligned with the ones known at the CLUE level.
For example, if a MP stops sending a certain media stream for any 
reason, it issues a new advertisement to the MC after such change.
Once received the ADV, the MC then flows from the IN CALL state to the 
ADV RECEIVED one and, if there are problems with the ADV, moves back to 
the IDLE state, which is a state where MP and MC are not aligned with 
the streams actually involved in the conference. It does not mean that 
there are no streams currently exchanged between the peers.

>
> 10. Sect.5 General: The term "CALL" is used. For me this encompasses 
> the entire session. i.e. to be "IN CALL" it would assume the CLUE 
> negotiation is done, the media streams are configured and media is 
> flowing etc. As this is describing a CLUE state machine should we 
> instead use CLUE specific terminology? i.e. "IN CALL" -> "CAPTURES 
> NEGOTIATED" etc.
>
The IN CALL state can be seen as a "negotiation completed" state where 
both the CLUE parties have successfully agreed on the media streams to 
be exchanged at the CLUE level.
We could change the name of the state or alternatively add more text to 
clarify the concept.

> 11. Sect. 6 General: As per 6 above I think there should be an 
> application level response, either saying success or error. Once that 
> is received then it should wait for a CONFIG or RE-ADV.
>
See point 6 answer.
> 12 Sect. 6 Para.5: As per 9 above. If the MP receives a CONFIG that 
> has error when it is an a IN CALL state I would expect that it remain 
> in an in call state. Rather than go back to IDLE.
>
See point 9 answer.
> 13 General: Do we need to define the scope of the states that they 
> only cover CLUE? or do they have further scope. E.g. If the CLUE state 
> is Terminated does this indicate some other behaviour that the MP or 
> MC should do? i.e. send updated SIP O/A to remove media. Btw, I'm not 
> suggesting this extended scope.
>
I think it is still premature in this phase.
> 14 Sect 7. Para.1: Nit - Suggested update: "... the message cannot be 
> processed <further>." Some processing has to be done to determine 
> version.
>
OK.
> 15 Sect 7. Para.3: Nit - "subsequet" -> "subsequent"
>
OK.
> 16 Sect 7. Para.3: The changes need to be backwards compatible not 
> only in terms of schema but also semantically and procedurally as well.
I agree. We will add text about that concept.

>
> 16 Sect 7. Para.4: I'm not a big supporter of having versions related 
> to different CLUE protocol drafts. Compliance to a CLUE version isn't 
> just based on the version of the schema. e.g. what if we change the 
> procedural handling of an existing XML element? The schema wouldn't 
> change. I'd prefer simply working towards v1.0.
>
> 17 Sect 7. Para.5: nits: "ascpect"->"aspect", 
> "explicitely"->"explicitly", "would up"-> "would <be> up"
>
OK.
> 18 Sect 8.1 para 4: It mentions here that " Elements or attributes 
> from unknown namespaces MUST be ignored". If the MP or MC receives 
> such an element I would expect that an error be returned to the ADV or 
> CFG message it contained or?
We have conceived an extensions negotiation mechanism (via the OPTIONS 
request/response message) that should avoid to fall into that situation 
(i.e. when a peer sends a message with xml elements coming from unknown 
namespaces).
However, extensions as elements placed in correspondence of <any> are 
typically conceived to indicate something more than the basic behavior 
of the CLUE negotiation.
If the other part is not able to understand that "something more", it 
does nothing less than the ordinary behavior.
>
> 19 Sect 8.1: I guess each of the last 3 bullets should be possible 
> depending on the type of data. I think that we need to separate the 
> actual syntax and structures (i.e. CS, CSEs, STSs etc) from the 
> Captures attributes. It should be possible to create new attributes or 
> update their value through an extension mechanism rather than need to 
> update the protocol version. Is this what is meant by the 3rd bullet? 
> Updates to the syntax and structures should need a new version.
>
Yes, the third bullet refers to a mechanism that enables to create new 
attributes without update the data model schema version and preserving 
the compatibility with it.
However,  according to that possibility, new attributes should be 
defined elsewhere and also in this case the new schema should be linked 
wherever we want to exploit  that extension.
> 19 Sect 8.2: I think a new message does need a new version so this 
> should be the ONLY chance.
As per the OPTIONS mechanism we are able to handle both data model and 
protocol updates.
In that vision, there are stable protocol and data model versions (with 
associated schema files), and extensions defined in other XML schemas.
Let's say that we have:
1) an extension for the data model, i.e. a schema file S1 defining new 
data model elements. For example, we can imagine a schema defining other 
audio capture attributes represented by XML elements placed in 
correspondence of the <any> element in the data model audio capture 
definition.
2) an extension for the protocol, i.e. a schema file S2 defining for 
example a new notification message that makes the MP able to inform the 
MC about the availabilty and the status of video captures only.
The MC supporting both extensions issues an OPTIONS containing the 
references of both S1 and S2.
The MP supporting both extensions recognizes the schemas and then knows 
that it can issue specific notifications according to the format 
provided in S2 and that it can use also the features defined in S1 to 
describe the available audio captures.

>
> 20 Sect 9 Para.3: Nit instatiated->instantiated.
>
OK.
> 21 Sect 9: I think we had some previous discussion that the OPTIONs 
> should only occur once at the start of the CLUE channel. This didn't 
> seem to be covered.
>
Yes, the OPTIONS occurs once at the start of the CLUE channel. It is not 
written explicitly, but there is a description and a picture of the 
mechanism explained in sec. 9.1.
We will add these important details in the next version.

> 22 Sect 9: Why is the MC responsible for sending the OPTIONS message? 
> I would have thought that as the MP sends the ADV (which is 
> effectively the first message) that it would send it?
>
With the introduction of the OPTIONS message, the ADV is no more the 
first message to be sent.
The state machines represent the evolution of the MP and of the MC after 
that the version of the protocol and the involved extensions have been 
agreed with the OPTIONS message.
The OPTIONS message is conceived as a request that expects a response.
It is the MC that issues that request, providing to the MP the supported 
extensions and the higher supported protocol version. In that way, the 
MP can select the extensions in the set supported by the MC and then use 
only information that is understood by the MC.


Roberta

> Regards, Christian
>
> On 8/10/2013 10:21 PM, Simon Pietro Romano wrote:
>> ...here it is.
>>
>> Simon
>>
>> Inizio messaggio inoltrato:
>>
>>> *Da: *[e-mail] <mailto:[e-mail]>
>>> *Oggetto: **New Version Notification for 
>>> draft-presta-clue-protocol-02.txt*
>>> *Data: *08 ottobre 2013 13:20:31 GMT+02:00
>>> *A: *Roberta Presta <[e-mail] 
>>> <mailto:[e-mail]>>, Simon Pietro Romano 
>>> <[e-mail] <mailto:[e-mail]>>, Simon Romano 
>>> <[e-mail] <mailto:[e-mail]>>
>>>
>>>
>>> A new version of I-D, draft-presta-clue-protocol-02.txt
>>> has been successfully submitted by Roberta Presta and posted to the
>>> IETF repository.
>>>
>>> Filename:draft-presta-clue-protocol
>>> Revision:02
>>> Title:CLUE protocol
>>> Creation date:2013-10-08
>>> Group:Individual Submission
>>> Number of pages: 26
>>> URL: 
>>> http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt
>>> Status: http://datatracker.ietf.org/doc/draft-presta-clue-protocol
>>> Htmlized: http://tools.ietf.org/html/draft-presta-clue-protocol-02
>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-02
>>>
>>> Abstract:
>>>   The CLUE protocol is an application protocol conceived for the
>>>   description and negotiation of a CLUE telepresence session. The
>>>   design of the CLUE protocol takes into account the requirements and
>>>   the framework defined, respectively, in [I-D.ietf-clue-framework] and
>>>   [I-D.ietf-clue-telepresence-requirements].  The companion document
>>>   [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as
>>>   well as on the SIP/SDP session establishment phase.  We herein focus
>>>   on the application level perspective.  Message details, together with
>>>   the behavior of both the Media Provider and the Media Consumer are
>>>   discussed.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of 
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org 
>>> <http://tools.ietf.org>.
>>>
>>> The IETF Secretariat
>>>
>>>
>>
>> _\\|//_
>>       ( O-O )
>>  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>> Simon Pietro Romano
>> Universita' di Napoli Federico II
>>  Computer Engineering Department
>>   Phone: [phone] -- Fax: [phone]
>>  e-mail: [e-mail] <mailto:[e-mail]>
>>
>> <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli
>>  idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                      oooO
>>   ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>        \ (            (   )
>>                         \_)          ) /
>>                          (_/
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> clue mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>