Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03

["Charles Eckel (eckelcu)" <[e-mail]>]

Works for me.

Thanks,
Charles

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Monday, November 05, 2012 8:00 AM
> To: Charles Eckel (eckelcu)
> Cc: Tom Kristensen (tomkrist); [e-mail]
> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
> 
> Hi Charles,
> 
> the point is that if we have decided not to be consistent across
> transports, we need to explain why in the RFCs. So, please, add some
> text (a few sentences should be enough) explaining why (i.e., something
> along the lines of your email below).
> 
> Thanks,
> 
> Gonzalo
> 
> On 04/11/2012 6:44 PM, Charles Eckel (eckelcu) wrote:
> > Hi Gonzalo,
> >
> > We discussed this at IETF 82. I remember because I presented a slide on it
> :)
> >
> > RFC 4582 states the following with regard to TLS:
> >
> >    Which party, the client or the floor control server, acts as the TLS
> >    server depends on how the underlying TCP connection is established.
> >    For example, when the TCP connection is established using an SDP
> >    offer/answer exchange [7], the answerer (which may be the client or
> >    the floor control server) always acts as the TLS server.
> >
> > For  DTLS, we considered the following alternatives:
> >
> > 1.The answerer always acts as the TLS/DTLS server, per RFC 4583 (as
> currently defined)
> > 2.The BFCP server always acts as the TLS/DTLS server
> > 3.The offerer always offers setup:actpass and the answerer answers either
> setup:active or setup:passive, where setup:active is RECOMMENDED (per
> RFC 5763)
> >
> > The consensus was that (3) was the preferred option, because it adheres
> to RFC 5763, does not overload offer/answer semantics, and it works for
> offerless INVITE with B2BUAs.
> >
> > Additional details are available in the alias archive:
> > http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00007.html
> > and also in the meeting minutes:
> > http://tools.ietf.org/wg/bfcpbis/minutes?item=minutes82.html
> >
> > At the time of this decision, we did not consider changing the existing
> guidance in RFC 4582 regarding TLS connection establishment. Doing so
> would introduce a backward compatibility concern.
> >
> > Cheers,
> > Charles
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Gonzalo Camarillo
> >> Sent: Sunday, November 04, 2012 10:52 AM
> >> To: Tom Kristensen (tomkrist)
> >> Cc: [e-mail]
> >> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
> >>
> >> Hi Tom,
> >>
> >> the way it is defined right now, how to determine which endpoint is the
> >> TLS or DTLS server is different in TLS (the answerer) and in DTLS
> >> (depends on the setup attribute). Why do you think we should not be
> >> consistent across both transports?
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >>
> >>
> >> On 30/10/2012 8:19 AM, Tom Kristensen wrote:
> >>> Gonzalo,
> >>>
> >>> I'll add a definition of "BFCP connection" in rfc4582bis to avoid
> >>> confusion.
> >>>
> >>> Regarding the setup attr. I merely reflected in rfc4583bis what has been
> >>> part of rfc4582 for a while.
> >>> - Cf. http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06#section-
> 7
> >>> - Note that the setup attr. is also used in DTLS-SRTP, cf. RFC 5763.
> >>>
> >>> -- Tom
> >>>
> >>> On 10/30/2012 12:51 PM, Gonzalo Camarillo wrote:
> >>>> Hi Tom,
> >>>>
> >>>> thanks for your answers.
> >>>>
> >>>> With respect to the term BFCP connection, in addition to making a
> >>>> consistent use of it across both documents, make sure it is defined
> >>>> somewhere so that implementers are clear on what it means.
> >>>>
> >>>> Regarding UDP, we cannot really use the setup attribute for that. That
> >>>> attribute is defined for connection oriented protocols. Additionally,
> we
> >>>> need to be consistent regarding DTLS and TLS server determination.
> >>>> Section 8 explains how to determine the endpoint acting as the TLS
> >>>> server (i.e., the answerer). We cannot determine which endpoint acts
> as
> >>>> the DTLS server in a different way.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Gonzalo
> >>>>
> >>>>
> >>>> On 30/10/2012 11:43 AM, Tom Kristensen wrote:
> >>>>
> >>>>> On 10/24/2012 04:27 PM, Gonzalo Camarillo wrote:
> >>>>>
> >>>>>> Folks,
> >>>>>>
> >>>>>>
> >>>>> [...]
> >>>>>
> >>>>>> Comments on draft-ietf-bfcpbis-rfc4583bis-03
> >>>>>>
> >>>>>> Section 3 includes a discussion about how to set the port field. That
> >>>>>> discussion is only relevant to TCP. The new draft needs to explain
> that
> >>>>>> and add a discussion about port handling in UDP.
> >>>>>>
> >>>>>>
> >>>>> Good catch. Reorganizing the text and adding this for UDP:
> >>>>>
> >>>>>    "When UDP is used as transport, the port field contains the
> >>>>>     port to which the remote endpoint will direct BFCP messages
> >>>>>     regardless of the value of the 'setup' attribute."
> >>>>>
> >>>>>
> >>>>>> Also, the document needs to discuss what is the equivalent of
> >>>>>> establishing a TCP connection (i.e., it allows endpoints to start
> >>>>>> exchanging BFCP messages) in UDP.
> >>>>>>
> >>>>>>
> >>>>> The term "BFCP connection" is used in rfc4582bis/rfc4583bis
> >> independent
> >>>>> of underlying transport.
> >>>>>
> >>>>>   (For rfc4582bis: I propose we keep this common term regardless of
> >>>>> underlying transport and change the three occurrences of "BFCP
> >>>>> association" in Section 6.2 and 8.31 to "BFCP connection" as well.)
> >>>>>
> >>>>> However, we do indeed need to specify the counterpart of Section 7
> >> "TCP
> >>>>> Connection Management" for UDP as transport. Will add a sentence or
> >> two,
> >>>>> since using UDP as transport is quite straight forward. Will also need
> >>>>> to add a UDP description to Section 8, i.e. mandate using the 'setup'
> >>>>> attribute when DTLS is used.
> >>>>>
> >>>>> Added to start of Section 7, now renamed to "BFCP Connection
> >>>>> Management":
> >>>>>    "BFCP connections may use TCP or UDP as underlying transport.
> BFCP
> >>>>>     entities exchanging BFCP messages over UDP will direct the BFCP
> >>>>>     messages to the peer side connection address and port provided in
> >>>>>     the SDP 'm' line. TCP connection management is more complicated
> >>>>>     and is described below."
> >>>>> And the subsection named "TCP Connection Management" follows.
> >>>>>
> >>>>> Added this sentence at the end of Section 8:
> >>>>>    "Endpoints that use the offer/answer model to establish a DTLS
> >>>>> association MUST
> >>>>>     support the 'setup' attribute, as defined in RFC 4145. When
> >>>>>     DTLS is used with UDP, the 'setup' attribute indicates which of the
> >>>>> endpoints
> >>>>>     (client or floor control server) initiates the DTLS association
> >>>>> setup."
> >>>>>
> >>>>>
> >>>>>> Section 6 contains the following new paragraph:
> >>>>>>
> >>>>>> " Note: In [15] 'm-stream' was erroneously used in Section 9.
> Although
> >>>>>>     the example was non-normative, it is implemented by some
> >> vendors.
> >>>>>>     Therefore, it is RECOMMENDED to support parsing and interpreting
> >>>>>>     'm-stream' the same way as 'mstrm' when receiving."
> >>>>>>
> >>>>>> The text should clarify (or be more explicit about) whether existing
> >>>>>> implementations are floor control server implementations or client
> >>>>>> implementations. The idea is that new implementers know clearly
> >> what
> >>>>>> exactly they need to support in order to be backwards compatible
> with
> >>>>>> those legacy implementations (whose implementers did not read
> RFCs
> >> but
> >>>>>> only the examples :-) ).
> >>>>>>
> >>>>>>
> >>>>> Yeah, what kind of developers do this kind of things? :-P
> >>>>>
> >>>>> Usage of a=floorid (and mstrm/m-stream) applies to endpoints willing
> >> to
> >>>>> act as server, will add this to the second sentence in the note:
> >>>>>    "[...] some vendors and occurs in cases where the endpoint is willing
> >>>>> to act as an server."
> >>>>>
> >>>>>
> >>>>>> The last paragraph of Section 8 discusses which entity behaves as the
> >>>>>> TLS server. Do we need a similar discussion for DTLS?
> >>>>>>
> >>>>>>
> >>>>> Indeed. Handled above.
> >>>>>
> >>>>> -- Tom
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> bfcpbis mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/bfcpbis