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

Simon Pietro Romano <spromano@unina.it> Thu, 04 July 2019 12:24 UTC

Return-Path: <spromano@unina.it>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2512061C; Thu, 4 Jul 2019 05:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NK2bmhpQT9l; Thu, 4 Jul 2019 05:24:03 -0700 (PDT)
Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35CF120698; Thu, 4 Jul 2019 05:23:52 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id x64CNodm029554-x64CNodo029554 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2019 14:23:50 +0200
Received: from [10.20.1.250] (iw452509.net.t-com.hr [195.29.56.30]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id x64CNnf8031279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2019 14:23:50 +0200
From: Simon Pietro Romano <spromano@unina.it>
Message-Id: <9B3D3D3F-2C32-43FF-98E8-E57B35530F60@unina.it>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB19869F-3B26-4305-8516-C6A796484BE3"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 04 Jul 2019 14:23:48 +0200
In-Reply-To: <154268515769.26665.4530527657139603206.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-protocol@ietf.org
To: Ben Campbell <ben@nostrum.com>
References: <154268515769.26665.4530527657139603206.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/JOVlcsXWXoarGj7TArmvt2zo_w8>
Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT)
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 12:24:08 -0000

Hello Ben! You’ll find below our hyper-delayed answers (preceded by [SPR]) to your comments.

Thanks once again for your support and advice,

Simon & Roberta

(Ben Campbell)
Discuss
Discuss (2018-11-19)

[BEN] 

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?

[SPR] We were not thinking of any internationalization-specific issues for this field.

[BEN]

§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.

[SPR] As per our answer to Kaduk's DISCUSS, generally speaking timeouts and retransmissions have been completely removed from the current version of the protocol draft, based on the discussions that we had on the WG mailing list. The draft has now become "Experimental" just because of that. Coming to the specific case mentioned above (sending back a new Configure upon reception of an error message associated with a previous Configure), our guess is that one might try and modify the new Configure based on the feedback received in the error message itself, so to avoid incurring in the exact same situation over and over again. Obviously, after a number of tries (whose value might depend on the specific CLUE implementation and logic) the peer in question should throw in the towel and tear down the session setup process.

[BEN]

§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.

[SPR] Here we were making the difference between the sending and receiving behaviors, coherently with RFC1122. We do know that flexibility never comes for free. Do you think we should be remove that part?

[BEN]

§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 (2018-11-19)

[SPR] We clearly state that extensions need to be accompanied by the following pieces of information: name; external XML Schema defining the XML information and/or the XML messages representing the extension; major standard version of the protocol that the extension refers to. Isn't this enough to guarantee that the mechanism works? Should we add something else?

[BEN]

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. 

[SPR] We tried to address Kaduk's DISCUSS and COMMENTS.

[BEN]

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.

[SPR] Please see our answer to your first DISCUSS comment. In its current status, the draft does not aim at presenting each and every possible protocol situation (corner cases included). 

[BEN]

- §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.

[SPR] The idea is that it is being specified on top of the mentioned protocols. Though, I personally don't see any major issue in implementing the CLUE protocol on top of alternative transports. Obviously, in those cases the security considerations would differ from the ones we are making now in the draft.

[BEN]

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

[SPR] Done (as informative).

[BEN]

§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.

[SPR] "MUST" has now become "must".

[BEN]

§5:
- ClueID: Is this truly optional in the sence of never required under any circumstances?

[SPR] This is what we had in mind. Do you envisage issues with this?

[BEN]

- sequenceNr: Is the language about incrementing intended to use normative keywords? (e.g MUST)?

[SPR] Yep. They have been capitalized in the new version of the draft.

[BEN]

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?

[SPR] Right.

[BEN]

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.)

[SPR] There might obviously be concerns about fingerprinting if the initial sequence number is not random. We were not thinking of mandating a random choice, though. Should we modify the document in that sense?


[BEN]

- 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?

[SPR] The idea was exactly not to prevent implementations from leveraging the same SCTP association for the exchanging of non-CLUE messages. The management of non-CLUE messages would in such a case be left to the specific implementation.

[BEN]

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

[SPR] See our answer to the DISCUSS comment.

[BEN]

§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?

[SPR] We wanted to clearly state that the range in question should be used, for coherence with companion approaches/protocols, for dealing with either delayed or incomplete operations. We can remove that requirement, if you deem it worth.

[BEN]

- "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.)

[SPR] Yep. We're not mandating this to happen.

[BEN]

§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.)

[SPR] See our answer to Kaduk's similar comment about channel initiator and channel receiver.

[BEN]

§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?

[SPR] If I am a MP and my telepresence settings change, I move to the "ADV" state and prepare a new Advertisement to be sent to the MC. If a Configure arrives from the MC while I am preparing the new Advertisement message, I will stay in the ADV state. Once the new Advertisement is ready I will move to the "WAIT FOR ACK" state. The MC on the other side of the channel will eventually receive my new Advertisement and prepare either an Acknowledgement message or a Configure+Acknowledgement message.

[BEN]

6.2, 2nd paragraph: 
-  Is the MC forbidden from sending a configure without the ack field set prior to sending an ack?

[SPR] We're not mandating this explicitly. Though, if I send a Configure prior to the Acknowledgement message, the other peer will simply disregard it, since it will be in the "WAIT FOR ACK" state.

[BEN]

- Is the response code limited to 200, are or other 2XX codes allowed if defined?

[SPR] They are allowed, if defined.

[BEN]

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

[SPR] It is indeed not used elsewhere in the document and might be removed from the draft with no harm. It would definitely be needed just in cases like, e.g., CLUE encapsulation inside HTTP. Since the draft is not proposing that, we can remove the mime type registration section from the document. Is this what you are proposing?

[BEN]

§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?

[SPR] Are you suggesting to just keep the messages definitions embedded in the (to-be-registered) schema, while removing from the draft the request for also registering them inside IANA? You're certainly more expert than us on this kind of issues, so we'll take your advice.

*** Editorial Comments ***

[BEN]

- General:
-- Please proofread for "which" vs "that" usage.

[SPR] Wi did that in the new version of the draft. Hope the two terms are now employed more properly.

[BEN]

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

[SPR] Done.

[BEN

- 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?

[SPR] I believe we discussed this extensively on the list. As far as I can tell, CLUE is "officially" expanded as follows:

"ControLling mUltiple streams for tElepresence". We agreed on using all-caps CLUE in all our documents.

[BEN]

§2: Please expand MCU on first mention.

[SPR] Done.

[BEN]

§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?

[SPR] Done

[BEN]

- "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.

[SPR] Done. We replaced "dialogs" with "message exchange sequences". Hope this works.

[BEN]

§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.

[SPR] Done.

[BEN]

§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.

[SPR] Right. This has become a MUST.

[BEN]

- "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.

[SPR] Modified by removing the piggybacking part.

[BEN]

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

[SPR] Replaced "catch-alls" with "the most generic ones in their respective categories."

[BEN]

- "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.

[SPR] Removed.

[BEN]

§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"?

[SPR] Modified (replaced process with role).

[BEN]

§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.

[SPR] Didn't get this one, sorry.

[BEN]

- 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.

[SPR] We are indeed reiterating on that, since the event in question ("changed telepresence settings) is common to the four states (WAIT FOR ACK, WAIT FOR CONF, CONF RESPONSE and ESTABLISHED) discussed in the section.

[BEN]

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

[SPR] Removed.


                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/



> Il giorno 20 nov 2018, alle ore 04:39, Ben Campbell <ben@nostrum.com> ha scritto:
> 
> 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.
> 
> 
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue