Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)

I am forwarding this discussion/comments with Adrian Farrel in case 
someone has an opinion different than the one I expressed.


-------- Original Message --------
Subject: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with 
DISCUSS and COMMENT)
Date: Tue, 4 Sep 2012 15:32:58 +0200
From: Miguel A. Garcia <[email protected]>
To: Adrian Farrel <[email protected]>
CC: The IESG <[email protected]>, "[email protected]" 
<[email protected]>, "[email protected]" 
<[email protected]>

Hi Adrian:

Thanks for your comments. Please find some answers inline.

On 04/09/2012 14:16, Adrian Farrel wrote:
> Adrian Farrel has entered the following ballot position for
> draft-ietf-simple-chat-16: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks, this is a well-written and easy-to-read document. Just a couple
> (well, three) of small issues that I would like to Discuss.
>
> ---
>
> Surpised that there are no requirements on authetication or control of
> admission to chat rooms. Was this topic discussed by the WG and left out
> on purpose (in which case we should add a note to that effect), was it
> forgotten (in which case we should address it), or is it not relevant
> for this type of chat (in which case you just need to explain it to me)?

This draft expands on many others, including SIP, conferences, SDP, and
MSRP. Authentication and authorization lies withing those protocols.

In particular, this draft builds on RFC 4353 (SIP Conferencing
Framework), which in Section 7 says:

     Conferences frequently require security features in order to properly
     operate.  The conference policy may dictate that only certain
     participants can join, or that certain participants can create new
     policies.  Generally speaking, conference applications are very
     concerned about authorization decisions.  Having mechanisms for
     establishing and enforcing such authorization rules is a central
     concept throughout this document.

     Of course, authorization rules require authentication.  Normal SIP
     authentication mechanisms should suffice for the conference
     authorization mechanisms described here.


>
> I would assume that the INVITE can be policed in some way. The best I
> could find was in Section 5.2
>
>     Participants usually join the chat room by sending an INVITE request
>     to the chat room URI.  As long as the chat room policy allows, the
>     INVITE request is accepted by the focus and the user is brought into
>     the actual chat room.
>
> Indeed, there are several mentions of things being allowed according to
> chat-room policy, but no wider discussion of the full set of policy
> attributes, or how chat room policy is set.

Right, perhaps the text could be improved by replacing the above
paragraph with this one:

Participants usually join the chat room by sending an INVITE request to
the chat room URI. The chat room them uses regular SIP mechanisms to
authenticate the participant. This may include, e.g., client
certificates, SIP Digest authentication [RFC3261], asserted network
identity [RFC3325], etc. As long as the user is authenticated, the INVITE
request is accepted by the focus and the user is brought into
the actual chat room.


Now, about the policy of the chat room. I think you have a good point.
There should be a single place where we can list all the policy
attributes and their semantics. Currently these are spread throughout the
document, making it difficult to keep track of them.

To address this issue, I suggest to add a new section 4.1, (inside the
Overview of Operation), that briefly lists all those policy attributes
and refers to sections where they are described in the appropriate context.

>
> ---
>
> Section 6.1
>
>     On sending a regular message the sender MUST populate the To header
>     of the Message/CPIM wrapper with the URI of the chat room.  The
>     sender SHOULD populate the From header of the Message/CPIM wrapper
>     with a proper identifier by which the user is recognized in the chat
>     room.
>
> I'm uncomfortable with the "SHOULD" here. It implies that you can think
> of a good reason why the sender MAY use some other (improper) identifier
> or no identifier at all. Can you either give an example (perhaps: "The
> sender MAY set an arbitrary and meaningless value in order to hide its
> identitiy"), or tighten the SHOULD to a MUST.

Honestly, I don't remember any scenario where a participant could
populate the From header of the Message/CPIM wrapper with some other
identifier. Even if the user is using an Anonymous URI at the SIP level,
he should use the same URI in Message/CPIM, in which case the MUST is
still valid.

I proposed to replace the SHOULD with a MUST.


>
> ---
>
> Section 6.1
>
>     An MSRP
>     switch that uses this fast forwarding procedure MUST temporarily
>     store the Message-Id of the MSRP message to correlate the different
>     chunks, as well as it MUST temporarily store the list of recipients
>     to which the initial chunks were delivered.
>
> The motivaiton is clear. I think you could add that the storage can be
> released when the last chunk is seen. But what happens when the last
> chunk is not seen (or delayed)? How temporary is the storage, and how is
> it released?

Yes, we can add that the temporary storage is released when the last
chunk is seen or after a reasonable time passes.
>
> Or do we assume that because MSRP uses TCP (or similar) that loss will
> always be accompanied by connection failure and so that is the only
> trigger needed to abandon temporary storage?

Yes, on one side, the assumption is that if a last chunk is not seen is
because there has been a transport failure. Since TCP is used, then the
TCP connection was broken, and is in the process of being re-established.
I am more concerned about what happens if the last chunk is not seen at
all, I am not sure the state the MSRP session will be, even if the
connection is re-established.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 4
>
>     In order to enter a chat room, one must first be created.
>
> Obviously, I spend to much time hanging out with the Queen, but when you
> say "one must be created" I suspect you meant the chat room, not one's
> self. Maybe reword as...
>
> Before a chat room can be entered, it must be created.
>

Ok.


> ---
>
> Section 6.1 (trivial nit)
>
>     The SEND request MUST contain a top-level wrapper of type 'Message/
>     CPIM' according to RFC 3862 [RFC3862].  The actual instant message
>     payload MUST be included as payload of the 'Message/CPIM' wrapper and
>     MAY be of any type negotiated in the SDP 'accept-types' attribute
>     according to the MSRP rules.
>
> I think s/MAY/may/. That is, a type must be set, and the type must be
> only one of those that has been negotiated.
>
>

I think this MAY should actually be a MUST, because as you said, a types
must be said, and this type cannot be anyone, but it MUST be one of those
negotiated.

I like the "according to the MSRP rules", as a mechanism to indicate that
we are not mandating something new, but just copying what MSRP mandates.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain