[clue] Ben Campbell's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-clue-protocol-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for all the work on this over the years. I have a few concerns that I
think require discussion prior to publication:

§5.7: Is the "description" field expected to be human readable? If so, are
there internationalization issues to consider?

§6.2, 5th paragraph: This says that if you get an error back for a configure
message, you send a new configure message. This seems likely to cause an
infinite loop unless some guidance is given about escaping the loop when the
endpoints cannot agree on a configuration.

§7:  I’m confused by the versioning mechanisms. This section requires an
endpoint to ignore unknown elements, but it also requires the peer to downgrade
to the highest shared version. These requirements seem to be at cross purposes.
If the peer downgrades, one should only see unknown elements in the case of
implementation errors. The requirement to ignore unknown elements does not come
for free; nor does the requirement to downgrade.

§5.1 and §8: The use of the options message to negotiate extensions seems
underspecified. How does an endpoint compare extensionType elements?  Is a spec
required or expected? Is the extension spec expected to register the URI for
schemaRef somewhere? Does this need to be in IANA?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I've got a number of additional comments that do not seem to rise to the level
of a DISCUSS:

*** Substantive Comments ***

I support Benjamin Kaduk's DISCUSS.

Additionally, I think there's some missing sub-transaction states, at least in
the state machine in Figure 10. When an endpoint sends a message and is waiting
for a response, shouldn't there be a separate waiting state (for example, when
waiting for optionsResponse)? The MP and MC state machines include this sort of
thing but the initial state machine does not. Also, I wonder if there are some
unhandled cases where a configure and advertise message cross on the wire.

- §1 ( also §2, definition of "endpoint"):
I'd like to see a few more words about the relationship between this, the
framework draft, the datachannel draft, and SIP.  Am I correct to understand
that is the only environment the protocol is ever expected to operate in? That
is, is there room for different signaling protocols, different transports, etc?
This also impacts the security considerations. For example if this depends on
the security properties of datachannels (over SCTP and DTLS), then it's worth
some language to the effect that it MUST not be used on other transports, or
that if it is used on other transports they must have similar security
properties.

§2, definition of endpoint: Please cite RFC3261 for SIP. (I have mixed feelings
whether this needs to be normative or informational.)

§4:
- "a lack of interoperability between the
protocol implementations. In order to correctly establish a CLUE
dialogue, the involved CPs MUST have in common a major version number"

That seems like a statement of fact. I suggest reserving the normative keywords
for the actual procedures that require this.

§5:
- ClueID: Is this truly optional in the sence of never required under any
circumstances? - sequenceNr: Is the language about incrementing intended to use
normative keywords? (e.g MUST)? Why do implementations need to send errors for
unexpected sequence numbers when using a reliable protocol? That would only
happen in the case of implementation errors, right? Why is it optional to start
with a random sequence number? Is there a concern about fingerprinting if
people choose otherwise? (I guess as the security considerations mention,
there's a lot of other things to fingerprint.)

- Protocol field: Do you envision non-CLUE messages will ever occur on the same
SCTP association? if not, then why require this? If so, then what should an
endpoint do if it gets a message with something other than "clue" here?

§5.1: "since minor versions are
defined to be both backwards and forwards compatible,"
Please see related DISCUSS comment.

§5.7:

- What is the reason for defining meaning the "100" response code range if no
codes in that range are defined? Why is this different from the 500-900 ranges
that are merely reserved for future use? (I gather there was an intent to be
consistent with SIP error codes, but why not leave that to the first spec that
defines a 1XX code, assuming that ever happens?

- "message. Implementations can (and are encouraged to)
include more specific descriptions of the error condition, if
possible."

Am I correct to assume that implementations should not expect any particular
description text for a given error code? (That used to be a common interop
problem for SIP.)

§6:
- "When the CLUE data channel set up starts ("start channel"), the CP
moves from the IDLE state to the CHANNEL SETUP state."

What does "set up starts" mean? Is this trigged by SDP signaling? SCTP
connection? Is it different for the SCTP client and server? (I suspect the
data-channel draft answers this, but it should at least be cited here.)

§6.1:
- "Finally, if there are changes
in the MP’s telepresence settings ("changed telepresence settings"),
the MP switches to the ADV state."
If I understand correctly, the MC can send new configure messages at any time.
What happens if one arrives in the ADV state but before sending the advertise?

6.2, 2nd paragraph:
-  Is the MC forbidden from sending a configure without the ack field set prior
to sending an ack? - Is the response code limited to 200, are or other 2XX
codes allowed if defined?

§12.3: The mime type isn’t mentioned anywhere else in the doc? Why is it
registered here? What is it used for?

§12.4.1: Why is it necessary to both register these directly in IANA and define
them in a (presumably registered) schema? Am I correct to assume new message
types must also be defined in a schema?

*** Editorial Comments ***

- General:
-- Please proofread for "which" vs "that" usage.
-- Please proofread for null words, especially "obviously" and similar terms,
which some readers might read as condescending.

- Abstract: Is CLUE an acronym? If so, what is its expansion? (If the title is
the expansion, it's very obscure.). If not, why all-caps?

§2: Please expand MCU on first mention.

§4:
- "The subset of the extensions
that are allowed within the CLUE session is also determined in the initiation
phase, such subset being the one including only the extensions that are
supported by both parties" Convoluted sentence, can it be simplified?

- "Hence in a call between two
CPs, A and B, there would be two separate dialogs, as follows:"
Please define the meaning of "dialog" as used in this document. In particular,
that it is not related to SIP's usage of the term.

§5:
"While the ’options’ and ’optionsResponse’ messages are exchanged in
the initiation phase between the CPs, the other messages are involved
in MP-MC dialogues."
This also needs a definition of "dialog" for the meaning to be clear.

§5.5:

- "The MC can send a
’configure’ after the reception of an ’advertisement’ or each time it
wants to request other captures that have been previously advertised
by the MP."
The use of "can" makes this seem optional. I gather from the state machine this
is not the case.

- "It indicates that the ’configure’
message also acknowledges with success the referred advertisement
(’configure’ + ’ack’ message), by applying in that way a piggybacking
mechanism for simultaneously acknowledging and replying to the
’advertisement’ message."
Convoluted sentence.

5.7:
- "200, 300 and 400 codes are considered catch-alls."
Please elaborate on what "catch-all" means in context.

- "Further response codes can be either defined
in future versions of the protocol (by adding them to the related
IANA registry)..."
The parenthetical phrase is redundant to the next sentence.

§6:

- First Paragraph: The first and last sentences are redundant with earlier text
in the draft. Should "MC process" and "MP process" be "MC role" and "MP role"?

§6.1, 3rd paragrap: The first sentence seems out of place, given that much of
the previous paragraph was about what happens in the WAIT FOR CONF state.

- 5th paragraph: "If there are
changes in the MP’s telepresence settings ("changed telepresence
settings"), the MP moves back to the ADV state."
Redundant to previous paragraph.

§8.1, 2nd paragraph: The second sentence is redundant to similar text in §8.