Subject: [clue] New Version Notification for draft-kyzivat-clue-signaling-05.txt

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 Sep 2013 21:20:14 -0400

I just posted an updated version of draft-kyzivat-clue-signaling-05.
The announcement is attached.

My intent was to incorporate the versioning that I discussed on the team 
meeting last Tuesday. In doing so I tried to incorporate comments that I 
got at the meeting and after.

As I did it, I found I couldn't avoid making other changes.
In particular, the specification of message responses needed updating, 
and I captured some other agreements we have made along the way.
And this forced me to reorganize things.

The schema has been changed to incorporate the versioning messages, and 
changes in responses.

There is still a lot wrong with this document, but I think it is better.

There were remaining questions about versioning after the design team 
meeting. Now we have a document to refer to when making comments. So 
please take a look and comment further about any concerns you may have.

I need scrutiny on the xml, and on the impact of backward version 
compatibility on xml.

I hope we can talk about this at the interim this coming Tuesday, but it 
will depend on people getting a chance to review it before then.

	Thanks,
	Paul

Subject: New Version Notification for draft-kyzivat-clue-signaling-05.txt
From: [email-masked]
To: Christian Groves <[email-masked]>, Robert Hansen <[email-masked]>, Lennard Xiao <[email-masked]>, Paul Kyzivat <[email-masked]>, Christian Groves <[email-masked]>
Date: Sat, 14 Sep 2013 18:04:32 -0700

A new version of I-D, draft-kyzivat-clue-signaling-05.txt
has been successfully submitted by Paul Kyzivat and posted to the
IETF repository.

Filename:	 draft-kyzivat-clue-signaling
Revision:	 05
Title:		 CLUE Signaling
Creation date:	 2013-09-15
Group:		 Individual Submission
Number of pages: 44
URL:             http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-05.txt
Status:          http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling
Htmlized:        http://tools.ietf.org/html/draft-kyzivat-clue-signaling-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-05

Abstract:
   This document specifies how signaling is conducted in the course of
   CLUE sessions.  This includes how SIP/SDP signaling is applied to
   CLUE sessions as well as defining a CLUE-specific signaling protocol
   that complements SIP/SDP and supports negotiation of CLUE application
   level data.

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.

The IETF Secretariat

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Sep 2013 15:19:38 +1000

Hello Paul,

Some comments:

3.3.1 bullet 1: "Co-ordinated use of SIP and SDP" - How is this relevant 
to CLUE version negotiation? The negotiation is internal to the CLUE 
protocol.

3.3.1 bullet 1: Duplicate "CLUE message exchange"

3.3.1 bullet 1: How does a CLUE version dictate media behaviour?

3.3.2 bullet 6: I think it would be good if their was a definition of 
"backwards" compatible. To me ignoring something isn't backwards 
compatible. For something is backwards compatible when it follow these 
rules:
1) Existing protocol elements, i.e., procedures, attributes values, 
should not be changed unless a protocol error needs to be corrected or 
it becomes necessary to change the operation of the service that is 
being supported by the protocol.
2) The semantics of a message, attribute,or a value should not be changed.
3) Established rules for formatting and encoding messages and parameters 
should not be modified.
4) When information elements are found to be obsolete they can be marked 
as not used. However, the identifier for that information element will 
be marked as reserved. In that way it cannot be used in future versions.

Figure 1: Why are two sets of messages needed? i.e. two Supported. Isn't 
it sufficient for the CLUE channel initiator to send what it supported 
and then the required indicates which of those is being used?

3.2.3 3rd Para: I haven't understood what we gain by having two sets of 
"supported" messages. The version proposal appears to negotiate multiple 
versions in the same CLUE channel, direction dependent. It seems strange 
for an endpoint to say "I can send v1.2, but can only receive v1.1". Why 
wouldn't it be sufficient just to agree on a single version for both 
ends of the CLUE channel?

3.2.3 Last bullet: Is the note consistent with the last bullet and the 
general procedure? If the CLUE channel is re-established and maintains 
state then there doesn't need to be another version negotiation.

3.3.5 This section only talks about "options" which I take it is there 
to indicate whether optional parts of the CLUE specification are 
implemented? How does this relate to any future extension? e.g. if an 
additional capture attribute is defined. Do we see that as an extension 
or should this be part of CLUE version update?

3.3.5.1 <media provider>: I support options but I can't see the point of 
mediaProvider. The very fact that CLUE has been negotiated should mean 
that the endpoints should be able to send and receive Advertisements and 
Configure messages.

3.3.7 Backwards compatibility: I take it Vx is a higher version than Vy? 
Maybe this should be explicit. Also given that major versions are not 
backwards compatible perhaps we need to say Vx.y, Vx.z?

3.3.7 bullets 6,7,8: I think text such as my comment to 3.3.2 would be 
sufficient.

3.3.7 bullet 9: I think the current formulation is confusing. Perhaps it 
would be more understandable to say "If the revision does not introduce 
any changes to: existing protocol elements and procedures, the semantics 
of messages or protocol elements, established rules for formatting and 
encoding (other than to fix errors) then the CLUE version may remain 
unchanged."

3.3.8 Examples: See my above comment on the need for two supported and 
required messages.

Regards, Christian

On 15/09/2013 11:20 AM, Paul Kyzivat wrote:
> My intent was to incorporate the versioning that I discussed on the 
> team meeting last Tuesday. In doing so I tried to incorporate comments 
> that I got at the meeting and after.
>
> The schema has been changed to incorporate the versioning messages, 
> and changes in responses.
>
> I hope we can talk about this at the interim this coming Tuesday, but 
> it will depend on people getting a chance to review it before then.
>
> Thanks,
> Paul
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Robert Hansen <[email-masked]>
Date: Mon, 23 Sep 2013 21:08:37 +0100

Hi Paul,

Really glad to see the new document - I had a few questions on the new 
versioning text.

I'm all for only doing the version negotiation at the start of the 
session (as a mandatory exchange before any other messages can be sent). 
For version support, I don't see any need to ever renegotiate this 
mid-session: any cases where the support version changes mid-call I can 
imagine (eg, silent transfer by a B2BUA) will also necessitate closing 
and reestablishing the CLUE channel, in which case you perform a fresh 
version negotiation.

I do have more concerns about not being able to renegotiate mid-call 
when it comes to the options. Options include behaviours as well as just 
'what extensions to the protocol do I understand', and behaviours may 
well change mid-call. For instance, 'mediaProvider' is the currently 
defined option, and I could well imagine an implementation wanting to 
change that mid-call.

On the other hand, I'm not sure that anything other than the major 
version requires an actual negotiation, rather than something more 
declarative. When it comes to the major version, both sides clearly need 
to agree which to use. However, with the mandate that newer minor 
versions must be backwards compatible with older minor versions by 
ignoring new XML elements (and attributes?) does this actually need 
negotiating? Or can both sides simply state their level of support? 
Assuming the same rule applies to options when XML changes are involved 
then that seems like it could be declarative too. If there is no 
negotiation required then mid-session changes to the options become less 
painful - it's just a new message to state the options rather than 
requiring the far end to send messages in response.

Rob