Subject: [clue] Comments on draft-presta-clue-protocol-04

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 May 2014 10:54:02 -0400

I reviewed the new version. It is looking very good. I noted the 
following points:

Section 1 (Intro):

In the following:

    depicted respectively in [I-D.kyzivat-clue-signaling] and
    [I-D.kyzivat-clue-signaling].  CLUE protocol messages flowing upon

presumably there should be references to two *different* documents!

Section 3:

This section introduces terminology that is widely used and easily 
confused: CP (CLUE Participant?), CI (Channel Initiator), CR (Channel 
Receiver). I think these need to be in the definitions section.

Section 4:

This is just esthetic, but I don't love the naming of the 
re-advertisement message (READV). When I see it I can't prevent myself 
from trying to parse it as READ-V rather than RE-ADV. Perhaps it could 
be changed to RE-ADV? What do others think?

Section 4.2:

Shouldn't responseCode be a short?

Doesn't this message have both a 'v' attribute as well as a <version> 
element? What is the expected relationship between these?

Section 4.7:

The lastReceivedAdv is shown as a short. But I think the sequence 
numbers are integers.

Section 5:

While I know what you are trying to say, I find the following confusing:

    Over such a channel there are typically two CLUE streams between the
    channel terminations flowing in opposite directions.  In other words,
    typically, both channel terminations act simultaneously as a MP and
    as a MC.

Rather than "two CLUE streams", it might be clearer to say "two CLUE 
negotiations". E.g.:

    Over such a channel there may be multiple CLUE negotiations
    between the channel terminations. Each negotiation involves one MP
    and one MC. If both channel terminations (CPs?) act simultaneously
    as both MP and MC then there will be two concurrent negotiations. We
    herein discuss a single negotiation.

That is just a thought - maybe there is a better word than negotiation. 
This doesn't cover the fact that the options exchange is yet another 
negotiation, but that one doesn't involve one MP and one MC.)

Also, somewhere is a mention that separate sequence numbers are to be 
maintained for each of these negotiations. But I didn't see that notion 
fleshed out anywhere.

Section 6:

This state machine is a little confusing because, IIUC, it is a merge of 
two state machines - one for the CI and one for the CR. I think it would 
be clearer to show these separately.

I don't understand what is intended regarding exchange of OPTIONS 
messages while in the ACTIVE state. That needs some explanation.

Section 6.1:

Doesn't the message need to be parsed according to the schema simply to 
determine the message type? So won't parse errors be detected *before* 
message-specific processing? In fact it probably must be processed by 
the clue-participant state machine. I'm not sure how that can result in 
changes to the MC or MP state.

I guess *semantic* errors with an advertisement can be handled according 
to the MC state machine.

If there is an assumption that there are multiple stages of parsing, 
done at different points within the state machines, then that needs to 
be explained.

(I am postponing doing a detailed analysis of the state machines.)

Section 7:

Since major versions are incompatible, how should an implementation 
structure the OPTIONS message to maximize the possibility of interoperation?

Suppose X supports only v1.0, Y supports only v2.0, and Z supports both 
v1.0 and v2.0. When Z is sending the initial OPTIONS message on a 
channel, what should it set "v" to? It has to choose either 1.0 or 2.0, 
but either choice means it won't be able to negotiate clue with one of 
the other endpoints.

It seems like we need some way to exclude the OPTIONS message from 
versioning.

The following is a little odd, but might solve the problem:

- define v1.0, that includes *only* the OPTIONS message and
   its response.
- define v2.0, that includes OPTIONS and everything else you have
   defined.
- require all clue implementations to support at least v1.0 and
   one other version.

Then, The initial OPTIONS message could always be sent with v=1.0. It 
could indicate support for whatever versions it supports.

E.g., Suppose X only supports v1.0, and Y only supports v2.0.

Section 8:

I think we need to state a rule about processing of unknown elements 
that fall within the "any" placeholders in the schemas. In particular, 
in general I think we need an "ignore unknown stuff" rule. That is 
needed so that a higher versioned participant doesn't have to strip out 
everything in its messages that isn't compatible with the peer's lower 
version.

But it can't be a universal ignore unknown stuff rule. For instance you 
can't ignore unknown message types - you must at least send a error 
about those.

Section 9:

I haven't reviewed the schema in detail yet.

General editorial issue:

All the XML is shown aligned to the left margin.
Can it be indented?

	Thanks,
	Paul