From tomkrist@cisco.com Thu Jan 9 04:53:40 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA8F1AE271 for ; Thu, 9 Jan 2014 04:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 JU-XJg18dAmv for ; Thu, 9 Jan 2014 04:53:38 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id BF9E91AE0F7 for ; Thu, 9 Jan 2014 04:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9635; q=dns/txt; s=iport; t=1389272008; x=1390481608; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MDgP+4k0HnQuA1zsULkf1zFxzFQoHmpeWR53LTo8Pfg=; b=aTMpSocYwv0lOu+MrNOhT2VlMhKE1a2f+bJt6gso3893njQPiItdSGD+ T1FSaBnrnWzha1RuZ7g4MAjvengw2bUTAkWFn5WEnpJpb6UY1GMKl6pEE twDTPEczZIgGGy75Z9JBRGy6balleJcEcdTkoOWuGR67h1F2j2JCMPYq6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAAObzlKQ/khM/2dsb2JhbABZgwu3R4MIgREWdIIlAQEBAwEdCgsBBTAGCgEMBAsYCRYPCQMCAQIBRQYBDAEHAQGHeAjEcRePBQeENwEDlDODZIZFi1CDLjs X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="scan'208";a="2715928" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 09 Jan 2014 12:53:27 +0000 Received: from [10.61.192.42] ([10.61.192.42]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s09CrQY6018783; Thu, 9 Jan 2014 12:53:26 GMT Message-ID: <52CE9BC6.1090109@cisco.com> Date: Thu, 09 Jan 2014 13:53:26 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "bfcpbis@ietf.org" , Joerg Ott References: <529C456D.60508@cisco.com> In-Reply-To: <529C456D.60508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] Joerg's review - Fwd: Reviewing draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 12:53:41 -0000 Inline below. On 12/02/2013 09:31 AM, Tom Kristensen wrote: > Relaying Jörg's review sent to the authors of the draft 2013-11-30. > > Please, step forward with any reactions or input regarding the two > reviews we received recently. My plan is to go through them and provide > feedback to the list ASAP. > > (Jörg is added to the copy list, since he's not following the BFCPbis > mailing list) No reactions or comments triggered on the list. (And apologize for a loooong yule and new year vacation). However, here are my comments and suggestions for the issues Jörg had. > -------- Original Message -------- > > Hi Gonzalo and all, > > thanks a lot for the diff, this is really useful! > > So, I have gone in some detail through the document and found a > bunch of issues to be addressed. Most of those revolve around > the use of unreliable transport, which appears to be underspecified > in a number of ways. [...] > 5.1. General > > SHOULD -> MUST be cleared by the sender I don't see the need for change since the flag has no meaning when using reliable transport and especially not since it is a MUST for the receiver to ignore it in that case. Anyway, changing it to MUST works fine with me if that's what the WG wants! Also, since this is an extension of RFC 4582 we have used the same style as in the original draft. For instance in 5.2.6 (for the Padding bits) and in 5.2.6.1 (for the R bits), where the sender SHOULD set clear the bits and the receiver MUST ignore them. > When moving from a 16- or 32-bit "value" to an unsigned > integer, the byte order must be specified. The second sentence in Section 5 says that all "the protocol values MUST be sent in network byte order". That should be sufficient, shouldn't it? > 5.1. R bit > > Question: Can it happen that transport changes in a relay? If > my dim memory serves me right, then STUN relay may change the > transport and thus the reliability. They won't interpret BFCP, > however, and so the bit would suddenly be wrong. Or is this > scenario prohibited? You mean TURN not STUN I presume. A TURN relay may have an unreliable and reliable hop on each hop. However, the TURN relaying(/"tunneling") magic added to the packets will be removed before the BFCP packets reaches the BFCP stack. And since on hop is unreliable the extensions for unreliable transport is still needed. > 5.2. Use of SHOULD > > Quite a few places state a SHOULD requirement, e.g., for sending > error messages. But this doesn't make sense. Based upon which > grounds would an endpoint _not_ send an error message? I do agree in principle, but again and if I remember correctly the SHOULD here was used to comply with the style used in the original RFC 4582. See for instance the SHOULD requirement to send an Error message in Section 13 (for Unknown Primitive). Since the revision of RFC 4582 was done to add support for unreliable transport and in addition to fix important issues (such known bugs/typos/unclear text), I'm not sure we want to change the SHOULD to MUST and potentially generate issues for existing RFC 4582 compliant implementations out there. However, we can without any problem make the use of error messages mandatory (with MUST) in the sections added for unreliable transport of course. Such as in Section 6.2 and probably some more places. > 5.2.6 Generic error > > Is it specified what the receiver of a non-specific error is > supposed to do? Apparently, it cannot talk to the server. So, > abandon floor control? Well, for me the Generic Error is kind of a safety net in situations where the existing error codes are not meaningful. So one implementation might simply abandon floor control/BFCP as a consequence another might have some error recovery that is possible - depending on context. Any need for text describing this fluffy assumption? :) Or do people have other interpretations? > 5.3.14, 5.3.15., and 5.3.17 > > It seems that FloorRequestStatusAck, FloorStatusAck, and GoodbyeAck > are essentially packet-level acks. So why not have just a single > code point for those, since they all carry a transaction id anyway? True and if I remember correctly this has been discussed earlier on. Reasons like having explicit acks matching request primitive and potentially extensibility per request type later on might be enough to keep it as is? I think so at least. > 6.2 Unreliable Transport > > The text often talks about UDP datagrams, even though DTLS > transport appears assumed. > > "Entities MUST have at most one outstanding request transaction at > any one time." > > This probably wants the addition of a "per peer", otherwise a floor > control server would be in trouble. (Section 6.2.1 has this right) Indeed, a good point! This will be changed to make it consistent and clear. > 6.2 Hello > > Clients MUST announce their presence to the floor control server by > sending a Hello message. The floor control server responds to the > Hello message with a HelloAck message. The client considers the > floor control service as present and available only upon receiving > the HelloAck message. > > When does the server consider the client to have disappeared so that > it can discard state? > > It seems I can run a client, send a Hello message, get the HelloAck, > and then send a floor control request with a spoofed IP address, and > predict and fake the response for the first message I am expecting > from the server in response. Then, I have state installed that will > generate packets and retransmissions to a random target until the > server discards the client state. But there is no mention when the > state would be discarded. > > Maybe this is less of an attack problem since this is bound to a > conference somewhere, but I still don't have a mechanism to get > rid of the transport state -- could be important particularly when > new connections are instantiated. While it is stated that the old > state is lost (for the new instance of the client), will it be > discarded? There is no guidance. Hmmm, not sure how to best handle that situation. Using DTLS would make the IP address spoofing harder at least, and it is recommended to use TLS for both TCP and UDP transport. What can people propose for this? Is it sufficient to describe what the server should do when the number of retransmissions are tried? > 6.2.3 Fragmentation > > Is there any guidance on transmitting fragments? (any pacing?) No, and one justification for keeping the fragmentation scheme simple and avoid specifying for instance pacing, is that the BFCP messages are binary and generally small in size. The probability for using the fragmentation scheme is smal and the need for pacing fragments even lower! > How is N defined? One would assume N = ceil (msgsize/MTUsize), but > an implementer might decide to use a larger N. In any case, when > we use N in the spec, it must be said how it is established. I agree and I think using N = ceil(msgsize/MTUsize) is a good way to specify how to choose N. > 8.2 Transaction number re-use. > > The text currently states that a transaction number "MUST NOT be > reused in another message from the floor control server checks > whether until the appropriate response from the client sending is > received for the transaction". > > If the ID is monotonically increasing (modulo wrap-around) why not > make re-use illegal? Allowing re-use seems to be calling for > trouble, especially in case some transactions may refer to others > by their ID or if transactions last longer. Very true and a good point. Re-use is potentially creating trouble... And since monotonical increasing values are required in the second last paragraph of Section 8, we should ban re-use in Section 8.2. OK? > 8.3.2. T2 is unclear Yes, probably true! One way of dealing with that is to remove timer T2 completely and let the implementations decide when to release knowledge. Another to brush up the specification of T2 of course. I'll be back with a proposal if clarification is needed! > 9.1 Authentication > > The text states: > > BFCP messages received over an authenticated TLS/DTLS connection are > considered authenticated. A floor control server that receives a > BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TLS/ > DTLS by generating an Error message, as described in Section 13.8, > with an Error code with a value of 9 (Use TLS) or a value of 11 (Use > DTLS) respectively. Clients SHOULD simply ignore unauthenticated > messages. > > "can" -> MUST or MAY (this is normative behavior) True. > But does this work? A server has one connection to a client. So, > if the server has at its disposition to accept TCP/UDP but the client > should ignore such messages, with the connection bidirectional, then > this de-facto mandates TLS/DTLS, doesn't it? Or the client would > never react. I'n not that fluent in TLS/DTLS to make a definitive answer there. Anybody out there willing to explain why this works or not? > Appendix A: Wouldn't the monoticity of the transaction IDs become > clearer if increments or 1 in numbers were used? True, but increments of 1 is not mandated. What do you mean by using increments, having an initial Transaction ID and using "+x" or something in later messages? -- Tom From 2mkristensen@gmail.com Fri Jan 10 02:58:01 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E351ADFA9 for ; Fri, 10 Jan 2014 02:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6UMeUh10oRYA for ; Fri, 10 Jan 2014 02:57:59 -0800 (PST) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 295071AD93D for ; Fri, 10 Jan 2014 02:57:59 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id cy11so4388619qeb.27 for ; Fri, 10 Jan 2014 02:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=or0wE/JpgVwxM4THTrsCbHdVp9aYNST7im0CU0o3Bzg=; b=kfO8zB59RxHiC04ZwpoSqosxXJ4nGB0lfo9nC4P+y/mJOGro+j91JmtOTIh74AElkM TphXfPDYsF7dClFaB/uXiCoiL3k0Q0GUvvDj/ax7OgPV1TRCmdAjg7iGfDUdXTAh22XA A3UHmxt30Dj7lNsQnbfvzdmwfCZ08JpAxKraMjqSPNSgpdZYzkuN3zNemu/bvkODLhI6 fIBaFme5y7Ri085yINmxRrtTKDgsFpn8ovf3eMs73QicgiXByFWYMHRByLKHN1oq84CQ PQqzEF9BywHFIk95oMntskI61SIfwGBbmrUSuF4oup+T/yNOeBWmSUp8TXV10+onhcUg u8qg== MIME-Version: 1.0 X-Received: by 10.224.167.15 with SMTP id o15mr5941248qay.96.1389351469218; Fri, 10 Jan 2014 02:57:49 -0800 (PST) Received: by 10.229.189.9 with HTTP; Fri, 10 Jan 2014 02:57:49 -0800 (PST) In-Reply-To: References: <52B04EEF.8020200@ericsson.com> <52B1C65E.3050406@ericsson.com> <52B4533A.5050007@ericsson.com> Date: Fri, 10 Jan 2014 11:57:49 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Mary Barnes Content-Type: multipart/alternative; boundary=089e01294f64ca7f5304ef9b9872 Cc: "bfcpbis@ietf.org" , Tom Kristensen Subject: Re: [bfcpbis] Fwd: SDP directorate Review request: X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:58:01 -0000 --089e01294f64ca7f5304ef9b9872 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My comments to the review: http://www.ietf.org/mail-archive/web/mmusic/current/msg12891.html Feel free to discuss it on the MMUSIC list preferably. -- Tom On 20 December 2013 15:44, Mary Barnes wrote: > FYI...here's the SDP directorate review for 4583bis. > > Mary. > > ---------- Forwarded message ---------- > From: Ari Ker=E4nen > Date: Fri, Dec 20, 2013 at 8:24 AM > Subject: Re: SDP directorate Review request: > > To: Mary Barnes > Cc: "mmusic-chairs@tools.ietf.org" , > Charles Eckel , > draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org, Richard Barnes > > > > Hi Mary, > > Ali turned out to be a very fast reviewer :) > > Here's the SDP review: http://www.ietf.org/mail- > archive/web/mmusic/current/msg12884.html > > Happy holidays! > > > Cheers, > Ari > > > On 12/18/13 5:59 PM, Ari Ker=E4nen wrote: > >> Hi Mary, >> >> Unfortunately not at least a good one. >> >> Sometimes we get a volunteer the same day (no one has volunteered for >> this draft yet), sometimes we have to ask a few times, and sometimes we >> end up doing it by ourselves if no one volunteers. We have usually given >> at least a few weeks for volunteers before using the last option. >> >> Given the holidays (e.g., I'll be out of office from next Friday until >> 4th of January), I would not be surprised if we have to wait until >> January to get someone. >> >> >> Cheers, >> Ari >> >> On 12/18/13 5:52 PM, Mary Barnes wrote: >> >>> Do you have an ETA for getting a volunteer just so we know the timing? >>> >>> Thanks, >>> Mary. >>> >>> >>> On Tue, Dec 17, 2013 at 7:17 AM, Ari Ker=E4nen >> > wrote: >>> >>> Hi Mary, >>> >>> Yes, the MMUSIC chairs assign (well, kindly ask volunteers for :) >>> SDP directorate reviews. I'll send a request and get back to you >>> once we have a volunteer. >>> >>> >>> Cheers, >>> Ari >>> >>> >>> On 12/17/13 12:00 AM, Mary Barnes wrote: >>> >>> Sorry for the duplicate, but I thought it best to resend with a= n >>> edited >>> subject line. >>> >>> Thanks, >>> Mary. >>> >>> >>> On Mon, Dec 16, 2013 at 10:09 AM, Mary Barnes >>> >>> >> >> wrote: >>> >>> Hi guys, >>> >>> I have agreed to be the shepherd for >>> draft-ietf-bfcpbis-rfc4583bis-__08 >>> >>> (http://tools.ietf.org/html/__draft-ietf-bfcpbis-rfc4583bis-__0= 8 >>> ). >>> Prior to progressing the document we need a review by >>> the SDP >>> directorate. My understanding is that the MMUSIC WG chair= s >>> do the >>> assignments for the SDP directorate. If that is not the >>> case, can >>> you please forward to whomever does those and cc me. >>> Otherwise, >>> can you please assign someone to review this document? >>> Given the >>> holidays, I think it would be reasonable to expect the >>> review to be >>> completed by January 13th. >>> >>> Thanks, >>> Mary. >>> >>> >>> >>> >>> >>> >>> >> > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --089e01294f64ca7f5304ef9b9872 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My comments to the review:=

http://www.ietf.org/mail-archive/web/mmusic/current= /msg12891.html

Feel free t= o discuss it on the MMUSIC list preferably.

-- Tom

On 20 December 2013 15:44, Mary Barnes <mary.ietf.barnes@gmai= l.com> wrote:
FYI...here's the SDP directorate revi= ew for 4583bis.

Mary.=A0

---------- Forwar= ded message ----------
From: Ari Ker=E4nen= <ari.keranen@ericsson.com>
Date: Fri, Dec 20, 2013 at 8:24 AM
Subject: Re: SDP directorate Review r= equest: <draft-ietf-bfcpbis-rfc4583bis-08.txt>
To: Mary Barnes <= ;mary.ietf.= barnes@gmail.com>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>, Ch= arles Eckel <ecke= lcu@cisco.com>, draft-ietf-bfcpbis-rfc4583bis.authors= @tools.ietf.org, Richard Barnes <rlb@ipv.sx>


Hi Mary,

Ali turned out to be a very fast reviewer :)

Here's the SDP review: http://www.ietf.org/mail-archive/web/mmusic/current/msg12884.html

Happy holidays!


Cheers,
Ari


On 12/18/13 5:59 PM, Ari Ker=E4nen wrote:
Hi Mary,

Unfortunately not at least a good one.

Sometimes we get a volunteer the same day (no one has volunteered for
this draft yet), sometimes we have to ask a few times, and sometimes we
end up doing it by ourselves if no one volunteers. We have usually given at least a few weeks for volunteers before using the last option.

Given the holidays (e.g., I'll be out of office from next Friday until<= br> 4th of January), I would not be surprised if we have to wait until
January to get someone.


Cheers,
Ari

On 12/18/13 5:52 PM, Mary Barnes wrote:
Do you have an ETA for getting a volunteer just so we know the timing?

Thanks,
Mary.


On Tue, Dec 17, 2013 at 7:17 AM, Ari Ker=E4nen <ari.keranen@ericsson.com
<mailto:ar= i.keranen@ericsson.com>> wrote:

=A0 =A0 Hi Mary,

=A0 =A0 Yes, the MMUSIC chairs assign (well, kindly ask volunteers for :) =A0 =A0 SDP directorate reviews. I'll send a request and get back to yo= u
=A0 =A0 once we have a volunteer.


=A0 =A0 Cheers,
=A0 =A0 Ari


=A0 =A0 On 12/17/13 12:00 AM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 Sorry for the duplicate, but I thought it best to resend wi= th an
=A0 =A0 =A0 =A0 edited
=A0 =A0 =A0 =A0 subject line.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Mary.


=A0 =A0 =A0 =A0 On Mon, Dec 16, 2013 at 10:09 AM, Mary Barnes
=A0 =A0 =A0 =A0 <mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>
=A0 =A0 =A0 =A0 <mailto:mary.ietf.barnes@__gmail.com
=A0 =A0 =A0 =A0 <mailto:mary.ietf.barnes@gmail.com>>> wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0Hi guys,

=A0 =A0 =A0 =A0 =A0 =A0 =A0I have agreed to be the shepherd for
=A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-bfcpbis-rfc4583bis-__08

=A0 =A0 =A0 =A0 (http://tools.ietf.org/html/__dra= ft-ietf-bfcpbis-rfc4583bis-__08
=A0 =A0 =A0 =A0 <http://tools.ietf.org/html/draft-= ietf-bfcpbis-rfc4583bis-08>).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Prior to progressing the document we need a= review by
=A0 =A0 =A0 =A0 the SDP
=A0 =A0 =A0 =A0 =A0 =A0 =A0directorate. =A0My understanding is that the MMU= SIC WG chairs
=A0 =A0 =A0 =A0 do the
=A0 =A0 =A0 =A0 =A0 =A0 =A0assignments for the SDP directorate. =A0If that = is not the
=A0 =A0 =A0 =A0 case, can
=A0 =A0 =A0 =A0 =A0 =A0 =A0you please forward to whomever does those and cc= me.
=A0 =A0 =A0 =A0 Otherwise,
=A0 =A0 =A0 =A0 =A0 =A0 =A0can you please assign someone to review this doc= ument?
=A0 =A0 =A0 =A0 Given the
=A0 =A0 =A0 =A0 =A0 =A0 =A0holidays, I think it would be reasonable to expe= ct the
=A0 =A0 =A0 =A0 review to be
=A0 =A0 =A0 =A0 =A0 =A0 =A0completed by January 13th.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Mary.










_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis




--
# Cisco = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/telepresenc= e/
## tomkri= st@cisco.com =A0| =A0http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--089e01294f64ca7f5304ef9b9872-- From eckelcu@cisco.com Mon Jan 13 10:41:37 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7341A1AE1A1 for ; Mon, 13 Jan 2014 10:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 G2Xt3QFulREJ for ; Mon, 13 Jan 2014 10:41:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 88D271AE1BD for ; Mon, 13 Jan 2014 10:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12033; q=dns/txt; s=iport; t=1389638482; x=1390848082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gvM534gCTDAUmL/Ue2hsPCVOTodb5G2gNgSufnqkoK8=; b=C2QuX2jJmofgesMgifCNaG7A7bSJxlK2k+yQO245TLpqOUkKYgPvlGAq mpEZCNPRa8eE8OTF94Y/X0FzRo3SHal7GIsRYiOV7E8IkuYmmAJ63OAVD VyoiVsz2o+/K7x3Hl0Lwm4wD4Rm0lLEKhBdmygBVnqK5D6G5+rTGbwn6s U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAPky1FKtJXG8/2dsb2JhbABagws4VrkjT4EYFnSCJQEBAQMBAQEBGgpBBgsMBAIBCBguJwslAgQBDQWHfAgNxH0TBI8HB4Q3BIkLiyiDZJIVgy2CKg X-IronPort-AV: E=Sophos;i="4.95,654,1384300800"; d="scan'208";a="297042558" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 13 Jan 2014 18:41:21 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0DIfL5C032266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 18:41:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 12:41:20 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" , Joerg Ott Thread-Topic: [bfcpbis] Joerg's review - Fwd: Reviewing draft-ietf-bfcpbis-rfc4582bis Thread-Index: AQHPEI8MkuAylBz21Uivb+PX6cV1Vw== Date: Mon, 13 Jan 2014 18:41:19 +0000 Message-ID: References: <529C456D.60508@cisco.com> <52CE9BC6.1090109@cisco.com> In-Reply-To: <52CE9BC6.1090109@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.85.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5C9593CA399A0A4CBDD297229EF7E7E5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] Joerg's review - Fwd: Reviewing draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 18:41:37 -0000 Hi Tom, Thanks for reviving this. Please see inline. On 1/9/14 4:53 AM, "Tom Kristensen (tomkrist)" wrote: > >Inline below. > >On 12/02/2013 09:31 AM, Tom Kristensen wrote: > > Relaying J=F6rg's review sent to the authors of the draft 2013-11-30. > > > > Please, step forward with any reactions or input regarding the two > > reviews we received recently. My plan is to go through them and provide > > feedback to the list ASAP. > > > > (J=F6rg is added to the copy list, since he's not following the BFCPbis > > mailing list) > >No reactions or comments triggered on the list. (And apologize for a >loooong yule and new year vacation). >However, here are my comments and suggestions for the issues J=F6rg had. > > > -------- Original Message -------- > > > > Hi Gonzalo and all, > > > > thanks a lot for the diff, this is really useful! > > > > So, I have gone in some detail through the document and found a > > bunch of issues to be addressed. Most of those revolve around > > the use of unreliable transport, which appears to be underspecified > > in a number of ways. > >[...] > > > 5.1. General > > > > SHOULD -> MUST be cleared by the sender > >I don't see the need for change since the flag has no meaning when using >reliable transport and especially not since it is a MUST for the >receiver to ignore it in that case. Anyway, changing it to MUST works >fine with me if that's what the WG wants! > >Also, since this is an extension of RFC 4582 we have used the same style >as in the original draft. For instance in 5.2.6 (for the Padding bits) >and in 5.2.6.1 (for the R bits), where the sender SHOULD set clear the >bits and the receiver MUST ignore them. After rereading RFC 2119, this looks like a case where it is better to fix the original RFC as part of extending it rather than follow the conventions put in place by the origin RFC. As there does not seem to be any reason or circumstances to justify NOT clearing the flag/bits, I think both instances should be changed from SHOULD to MUST. > > > When moving from a 16- or 32-bit "value" to an unsigned > > integer, the byte order must be specified. > >The second sentence in Section 5 says that all "the protocol values MUST >be sent in network byte order". That should be sufficient, shouldn't it? I think so. > > > 5.1. R bit > > > > Question: Can it happen that transport changes in a relay? If > > my dim memory serves me right, then STUN relay may change the > > transport and thus the reliability. They won't interpret BFCP, > > however, and so the bit would suddenly be wrong. Or is this > > scenario prohibited? > >You mean TURN not STUN I presume. A TURN relay may have an unreliable >and reliable hop on each hop. However, the TURN relaying(/"tunneling") >magic added to the packets will be removed before the BFCP packets >reaches the BFCP stack. And since on hop is unreliable the extensions >for unreliable transport is still needed. > > > 5.2. Use of SHOULD > > > > Quite a few places state a SHOULD requirement, e.g., for sending > > error messages. But this doesn't make sense. Based upon which > > grounds would an endpoint _not_ send an error message? > >I do agree in principle, but again and if I remember correctly the >SHOULD here was used to comply with the style used in the original RFC >4582. See for instance the SHOULD requirement to send an Error message >in Section 13 (for Unknown Primitive). > >Since the revision of RFC 4582 was done to add support for unreliable >transport and in addition to fix important issues (such known >bugs/typos/unclear text), I'm not sure we want to change the SHOULD to >MUST and potentially generate issues for existing RFC 4582 compliant >implementations out there. > >However, we can without any problem make the use of error messages >mandatory (with MUST) in the sections added for unreliable transport of >course. Such as in Section 6.2 and probably some more places. Here as well, I think it best to adhere to RFC 2119 rather than follow conventions used previously in RFC 4582. We have fixed some other issues with the original already, and I think we should fix these as well. I believe this to be more of matter of interpretation of the guidance of RFC 2119 rather than a real change to the BFCP protocol. > > > 5.2.6 Generic error > > > > Is it specified what the receiver of a non-specific error is > > supposed to do? Apparently, it cannot talk to the server. So, > > abandon floor control? > >Well, for me the Generic Error is kind of a safety net in situations >where the existing error codes are not meaningful. So one implementation >might simply abandon floor control/BFCP as a consequence another might >have some error recovery that is possible - depending on context. > >Any need for text describing this fluffy assumption? :) Or do people >have other interpretations? The paragraph above the table states: If an error code is not recognized by the receiver, then the receiver MUST assume that an error exists, and therefore that the original message that triggered the Error message to be sent is processed, but the nature of the error is unclear. I would expect the same to be true when receiving a "Generic Error". The action taken in response to such an error is implementation and context dependent. > > > 5.3.14, 5.3.15., and 5.3.17 > > > > It seems that FloorRequestStatusAck, FloorStatusAck, and GoodbyeAck > > are essentially packet-level acks. So why not have just a single > > code point for those, since they all carry a transaction id anyway? > >True and if I remember correctly this has been discussed earlier on. >Reasons like having explicit acks matching request primitive and >potentially extensibility per request type later on might be enough to >keep it as is? I think so at least. I agree. > > > 6.2 Unreliable Transport > > > > The text often talks about UDP datagrams, even though DTLS > > transport appears assumed. > > > > "Entities MUST have at most one outstanding request transaction at > > any one time." > > > > This probably wants the addition of a "per peer", otherwise a floor > > control server would be in trouble. (Section 6.2.1 has this right) > >Indeed, a good point! This will be changed to make it consistent and >clear. Yes, good catch. > > > 6.2 Hello > > > > Clients MUST announce their presence to the floor control server by > > sending a Hello message. The floor control server responds to the > > Hello message with a HelloAck message. The client considers the > > floor control service as present and available only upon receiving > > the HelloAck message. > > > > When does the server consider the client to have disappeared so that > > it can discard state? > > > > It seems I can run a client, send a Hello message, get the HelloAck, > > and then send a floor control request with a spoofed IP address, and > > predict and fake the response for the first message I am expecting > > from the server in response. Then, I have state installed that will > > generate packets and retransmissions to a random target until the > > server discards the client state. But there is no mention when the > > state would be discarded. > > > > Maybe this is less of an attack problem since this is bound to a > > conference somewhere, but I still don't have a mechanism to get > > rid of the transport state -- could be important particularly when > > new connections are instantiated. While it is stated that the old > > state is lost (for the new instance of the client), will it be > > discarded? There is no guidance. > >Hmmm, not sure how to best handle that situation. > >Using DTLS would make the IP address spoofing harder at least, and it is >recommended to use TLS for both TCP and UDP transport. > >What can people propose for this? Is it sufficient to describe what the >server should do when the number of retransmissions are tried? That sounds sensible for UDP. For TCP, it can be based on not being able to establish a connection to the client. Both of these are similar to receiving an ICMP error, as described in section 6.2.2. > > > 6.2.3 Fragmentation > > > > Is there any guidance on transmitting fragments? (any pacing?) > >No, and one justification for keeping the fragmentation scheme simple >and avoid specifying for instance pacing, is that the BFCP messages are >binary and generally small in size. The probability for using the >fragmentation scheme is smal and the need for pacing fragments even lower! > > > How is N defined? One would assume N =3D ceil (msgsize/MTUsize), but > > an implementer might decide to use a larger N. In any case, when > > we use N in the spec, it must be said how it is established. > >I agree and I think using N =3D ceil(msgsize/MTUsize) is a good way to >specify how to choose N. > > > 8.2 Transaction number re-use. > > > > The text currently states that a transaction number "MUST NOT be > > reused in another message from the floor control server checks > > whether until the appropriate response from the client sending is > > received for the transaction". > > > > If the ID is monotonically increasing (modulo wrap-around) why not > > make re-use illegal? Allowing re-use seems to be calling for > > trouble, especially in case some transactions may refer to others > > by their ID or if transactions last longer. > >Very true and a good point. Re-use is potentially creating trouble... >And since monotonical increasing values are required in the second last >paragraph of Section 8, we should ban re-use in Section 8.2. OK? Works for me. Of course the ID will need to be able to wrap around once the defined range is exhausted. > > > 8.3.2. T2 is unclear > >Yes, probably true! One way of dealing with that is to remove timer T2 >completely and let the implementations decide when to release knowledge. >Another to brush up the specification of T2 of course. Perhaps it is better to remove T2 and instead rely on T1 expiration following final retransmission serving as trigger to release knowledge of transaction. > >I'll be back with a proposal if clarification is needed! > > > 9.1 Authentication > > > > The text states: > > > > BFCP messages received over an authenticated TLS/DTLS connection are > > considered authenticated. A floor control server that receives a > > BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TLS/ > > DTLS by generating an Error message, as described in Section 13.8, > > with an Error code with a value of 9 (Use TLS) or a value of 11 (Use > > DTLS) respectively. Clients SHOULD simply ignore unauthenticated > > messages. > > > > "can" -> MUST or MAY (this is normative behavior) > >True. MAY seems appropriate to me. > > > But does this work? A server has one connection to a client. So, > > if the server has at its disposition to accept TCP/UDP but the client > > should ignore such messages, with the connection bidirectional, then > > this de-facto mandates TLS/DTLS, doesn't it? Or the client would > > never react. > >I'n not that fluent in TLS/DTLS to make a definitive answer there. >Anybody out there willing to explain why this works or not? I think the last sentence need to be changes to read as follows: "Clients configured to require the use of TLS/DTLS MUST ignore unauthenticated messages." > > > Appendix A: Wouldn't the monoticity of the transaction IDs become > > clearer if increments or 1 in numbers were used? > >True, but increments of 1 is not mandated. What do you mean by using >increments, having an initial Transaction ID and using "+x" or something >in later messages? > >-- Tom Cheers, Charles >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Tue Jan 14 11:04:11 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A011AE13F for ; Tue, 14 Jan 2014 11:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NCTs8tdtWPD3 for ; Tue, 14 Jan 2014 11:04:09 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E730E1AE10D for ; Tue, 14 Jan 2014 11:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6440; q=dns/txt; s=iport; t=1389726238; x=1390935838; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9vQfjq/TscTtAVDeIE674aBP1EEi/UTGhp+Yy2fyP+0=; b=L308aj/EmsIuvPUOzxMoP5ot/00h9+Eo4avsfps5c3FRh99N4Qy2D0UU 46lnq5xCjVYU6mhdmkmRdaWAsE8bYPm/bAYrW3wQkyan0Ew6elFiTM3rb NlrXSe4lTip0uVS4wUenKYUy3Z+fYqB9BHPPcquarpEIxguEsQgRaNg2T Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAP+I1VKtJXG+/2dsb2JhbABagws4VroPT4EWFnSCJgEBBAEBATcuBhsCAQglERAnCyUCBAESiAMBDcQqF45cMgKENQSYHoEwkGWDLYIq X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="297303990" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jan 2014 19:03:57 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0EJ3vTg018451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 19:03:57 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 13:03:56 -0600 From: "Charles Eckel (eckelcu)" To: Gonzalo Camarillo , "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt Thread-Index: AQHO2UtQ49CFBHKOV0uSdd6Uxkz0ApoVSW6AgCEbPYCATn30AA== Date: Tue, 14 Jan 2014 19:03:56 +0000 Message-ID: References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> <52934193.5050304@ericsson.com> In-Reply-To: <52934193.5050304@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.21] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A93E7A829DA0D4897D3F856C2662153@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:04:11 -0000 Hi Gonzalo, I was looking through the archives and did not see any response to you comments. Sorry for the delay. Please see inline. On 11/25/13 4:24 AM, "Gonzalo Camarillo" wrote: >Hi Tom, > >thanks for keeping the draft alive. I have had q quick look at Section 6 >and I have a few comments. > >http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-10#section-6 > >The first paragraph of Section 6 states that an entity can choose TCP or >UDP depending on the environment. Lately, the IESG is asking authors to >be a bit more explicit about operational issues. So, I think we should >add a few sentences explaining (briefly) who makes that decision. Is it >the implementation that first tries TCP and, if it does not work, it >falls back to UDP? Or do we expect administrators to configure this >depending on the environment? We can describe several potential >different deployment scenarios as well. In practice I have typically seen this configured as either use TCP first and fallback to UDP or vice versa. Depending on the product and environment, the choose of defaulting to TCP vs. UDP is made. The text in Appendix B describes the challenges with using TCP in some environments. In such environments, UDP would be typically be configured as the default. =20 > >The second paragraph of Section 6.2 explains that the floor control >server is considered present and available upon receiving a HelloAck >message. We should also explain the circumstances in which the service >is considered to have become unavailable (e.g., ICMP messages or >timeouts). > >The following is the last sentence of the 3rd paragraph of Section 6.2: > >> Concordantly, messages sent by the floor >> control server that are not transaction-completing (e.g., FloorStatus >> announcements as part of a FloorQuery subscription) are server- >> initiated transactions that require acknowledgement messages from the >> floor participant and chair entities to which they were sent. > > >I do not think the term "transaction-completing" have been defined in >the document. We should use a different term or, even better, explain >explicitly what we mean. Also, I do not understand the point the >sentence is intended to make. We should rephrase. How about: Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent. > >The 4th paragraph of Section 6.2 talks about the "Unable to parse" >message in the context of unreliable transports. Why don't we use that >with TCP as well? Is it because of backward compatibility issues? If so, >we should add a clarifying note. RFC 4582 stated the following, "If a BFCP entity (a client or a floor control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished." As there is no concept of a connection with UDP, we decided to handle by defining the new error code. > >The following sentence appears in the first paragraph of page 41: > >> The subsequent changes in state for >> the request are new transactions whose Transaction ID is determined >> by the floor control server and whose receipt by the client >> participant shall be acknowledged with a FloorRequestStatusAck >> message. > >Instead of "shall be", we should write "MUST be" if this behavior has >not been normatively defined anywhere else, or "is" if the behavior has >been normatively defined somewhere else. The normative language for this situation is in section 10.1.3, "When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction." I think replacing "shall be" with "is" is fine. > >The following paragraph appears later in Section 6.2: > >> If a client wishes to end its BFCP connection with a floor control >> server, it is RECOMMENDED that the client send a Goodbye message to >> dissociate itself from any allocated resources. If a floor control >> server wishes to end its BFCP connection with a client (e.g., the >> Focus of the conference informs the floor control server that the >> client has been kicked out from the conference), it is RECOMMENDED >> that the floor control server send a Goodbye message towards the >> client. > >Why is it RECOMMENDED (i.e., SHOULD level) instead of REQUIRED (i.e., >MUST level)? This comment is also somewhat related to my first comment >above about BFCP entities considering other entities gone. Have we >defined at which point can they forget their state information? This >also relates to the last paragraph of Section 6.2.2 that talks about >using STUN connectivity checks for this. We should probably talk about >all this somewhere. I cannot think of good reason for not sending a Goodbye. It may be that the Goodbye fails, and I think there may be existing implementations that do not send the Goodbye, but from a protocol perspective MUST/REQUIRED strength seems appropriate. > >The following paragraph appears in Section 6.2.3: > >> When a BFCP implementation receives a BFCP message fragment, it MUST >> buffer the fragment until it has received the entire BFCP message. >> The state machine should handle the BFCP message only after all the >> fragments for the message have been received. > >However, the paragraph after that seems to contradict the "MUST" above >because it allows receivers to discard incomplete buffers. I think it needs to read as follows, "When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission Timer expires." There is also a "must" that should be changed to "MUST" in the paragraph describing the retransmission timer. Cheers, Charles > >Cheers, > >Gonzalo > >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Tue Jan 14 11:21:41 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCED1AE20F for ; Tue, 14 Jan 2014 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.738 X-Spam-Level: X-Spam-Status: No, score=-12.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tEPoihEaAhmC for ; Tue, 14 Jan 2014 11:21:38 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE91AE1DA for ; Tue, 14 Jan 2014 11:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23507; q=dns/txt; s=iport; t=1389727287; x=1390936887; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SlHsQGwWlB+Fc3+33Sg3vHyXIJpqiDeGoMhEfhRkqQc=; b=Cz7W0kU9U1z8q6RWRGLzQQWA1fEXJOJLvCgtpnX1drPp+CqnpP9QVAH0 bF7Ohelb9yKYg6Pg0xhuY4uKP8T5benzOa3GCCKGThhBAedho7rqtQE9s nRPb48p3yzrq85FEDEdILgyy77zji+Xfh5WTxggLIpRBOLHgIZ3oSS7AT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFALON1VKtJV2c/2dsb2JhbABYAoJHRIEOul+BFhZ0giUBAQEEJ0cLEAIBCBEDAQIXEQchERQJCAIEAQ0Fh3ADEAG+LA2FYReMdIICEQcSC4QaBJYygWyMWoU7gy2BcTk X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208,217";a="297307683" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jan 2014 19:21:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0EJLQLk029576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 19:21:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 13:21:26 -0600 From: "Charles Eckel (eckelcu)" To: Mary Barnes , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08 Thread-Index: AQHO/EHWPXlnsYnVUUKGA2VBH15lqZqEoZUA Date: Tue, 14 Jan 2014 19:21:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.21] Content-Type: multipart/alternative; boundary="_000_CEFACA7A1A7A7eckelcuciscocom_" MIME-Version: 1.0 Cc: Richard Barnes , "draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org" , "bfcpbis-chairs@tools.ietf.org" Subject: Re: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:21:42 -0000 --_000_CEFACA7A1A7A7eckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mary, Thanks for the comments as part of the writeup. Please see inline. From: Mary Barnes > Date: Wednesday, December 18, 2013 2:38 PM To: "bfcpbis@ietf.org" > Cc: Richard Barnes >, "draft-ietf-bfcpbis-rfc= 4583bis.authors@tools.ietf.org" >, "bfcpbis-chairs= @tools.ietf.org" > Subject: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-0= 8 Hi all, I have agreed to shepherd this document on behalf of the WG. I have review= ed this document in preparation for doing the PROTO write-up. I think the document needs a bit of work before it's ready to progress. I = have a few questions/comments, as well as editorial nits which I think woul= d improve readability and ease of understanding. General Comments: The document requires an SDP directorate review prior to progressing. I ha= ve requested that of the MMUSIC WG chairs. At the time of this review, Al= i Begen has agreed to do that review. Comments/Questions: 1) I am slightly puzzled by the following in section 3: m=3D ... Section 5.14 of RFC 4566 states the following: m=3D ... So, this looks to be like the RFC 2327 ABNF for m lines is being used (rath= er than RFC 4566 which is the normative SDP specification for this document= )? m=3D Note, that the IANA registration section appears to be based on RFC 4566 as= the values are specified as being applicable to the 'pro to' field. So, = my guess is that this is a bug from RFC 4583. Yes, the SDP directorate review hit on this as well. It needs to be fixed t= o align with RFC 4566. 2) Section 3, next to last paragraph. I think it would be more precise to r= eword this as: OLD: The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' li= nes SHOULD contain a single "*" character. NEW: The fmt (format) list is not applicable to BFCP. The fmt list of 'm' l= ines in the case of any proto field value related to BFCP SHOULD contain a = single "*" character. If the the fmt list contains any other value it is i= gnored. In another thread, I proposed to change from SHOULD to MUST. I am okay with= your proposal as well, especially if there are known reasons and/or implem= entations that already do otherwise. 3) Section 4, paragraph above table 1, 1st sentence. I suggest for clarif= ication to make the following change: OLD MUST include one in the corresponding media description NEW MUST include a 'floorctrl' attribute in the corresponding media descrip= tion Agreed. 4) Section 4, 3rd paragraph from the end: "Endpoints that use the offer/answer model to establish BFCP connection= s MUST support the 'floorctrl' attribute. A floor control server acting as= an offerer or as an answerer SHOULD include the attribute in its session d= escriptions." Since the latter is a SHOULD what happens if the attribute is NOT included?= Under what circumstances is it okay for the server not to include it? I= F bad things happen if it's not included, then this probably ought to be a = MUST. Or, if there's reasonable situations in which the floor control ser= ver doesn't include the attribute, those should be explained or at least an= example provided. Agreed in principle. There is a discussion of which way to go on MMUSIC th= read in which I proposed MUST was appropriate for servers. 5) Section 7. a) 1st paragraph after ABNF. "..versions SHOULD be integers..". I would= think that ought to be a MUST. What happens if the token isn't an integer= and what was the motivation for not defining the version as an integer ver= sus a token? If non-integers can be used, the scope of what is acceptable= for the field needs to be explained. Agreed, and I think MUST be integers is fine. b) 2nd paragraph after ABNF. I can see why supporting the version is a SHO= ULD (since it is a new field) and RFC 4583 did not define a version, but I = think that needs to be more clearly documented and I think it ought to be R= EQUIRED for anyone that is using UDP and obviously, older implementations o= f TCP (i.e., those only compliant to RFC 4583 and not this document) ought = to be the only ones that aren't using the version field. Yep. c) last paragraph. Related to b, I would think that in the case of unrelia= ble transports, it's not that an endpoint MUST "assume". An endpoint MUST = "use" and signal a version number of 2. In the case of a reliable transpo= rt, if the endpoint does not signal a bfcpversion-attribute, then the floor= control server MUST use a value of 1. I'm recalling a fair amount of mai= ling list discussion on this one, so if you can point to the thread where t= his text was agreed, I can let this one go. I still think it's not specifi= ed quite right, but I can live with it. I think it would be good to tighten up the wording as you suggested. 6) Section 8. 1st sentence. I think this should be a "can use TCP or UDP"= and not a "may use TCP or UDP". Note, there is the perennial debate with r= egards to whether something is normative even when it's not CAPS. I prefer= to just use a different word to remove any confusion, particularly when a = different word is actually more correct. Works for me. 7) Section 8.1, 4th paragraph, 1st sentence and last sentence. I think th= e two "SHOULD generate and offer" ought to be a MUST generate an offer OR y= ou need to specify the circumstances under which a client would not generat= e an offer. Agreed. 8) Section 9, 1st paragraph. You're going to have to be more specific abou= t the potential mechanisms for authentication - at least provide an example= of mechanisms - i.e., I don't think "some mechanism" will fly with the Sec= Dir folks. What is we were to say that TLS/DTLS is preferred, but other mechanisms are= possible and outside the scope of this document. 9) Section 11, 2nd paragraph. I think that the assumes in the following st= atement needs to be a required. I suggest the following change: OLD BFCP assumes that an initial integrity-protected channel is used to excha= nge... NEW An initial integrity-protected channel is REQUIRED for BFCP to exchange... Yep. 10) Related to item 7, this list of changes has no mention of the new "bfcp= ver" attribute. That definitely should be on this list. Good catch. Editorial nits: 1) Introduction. "These data includes..." -> "This data includes...." (da= ta is now grammatically considered to be a singular noun). 2) Section 3. 1st paragraph after the indented text. This could be writte= n more concisely (and per technical doc standards not as the 1st person) as= follows (and per comment 1) above, I think this should be the 'proto' fiel= d: OLD: We define four new values for the transport field: NEW: This document defines four values for the proto field: 3) Section 5. I suggest the following change: OLD: We define the 'confid' and the 'userid' SDP media-level attributes. NEW: This document defines two SDP media-level attributes: 'confid' and 'user= id'. 4) Section 6. I suggest the following change: OLD: We define the 'floorid' SDP media-level attribute. NEW: This document defines the 'floorid' SDP media-level attribute. 5) Section 13. I found this really, really hard to read. I suggest you us= e a bulleted or numbered list versus this hanging list style. Works for me. Cheers, Charles --_000_CEFACA7A1A7A7eckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2CE77CCCE9B91F4AB979DB3187B400D2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Mary,

Thanks for the comments as part of the writeup. Please see inline.

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Wednesday, December 18, 2013 = 2:38 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Cc: Richard Barnes <rlb@ipv.sx>, "draft-ietf-bfcpbis-rfc4583bis.auth= ors@tools.ietf.org" <draft-ietf-bfcpbis-rfc4583bis.authors@tools.i= etf.org>, "bfcpbis-chairs@tool= s.ietf.org" <b= fcpbis-chairs@tools.ietf.org>
Subject: [bfcpbis] PROTO review com= ments on draft-ietf-bfcpbis-rfc4583bis-08

Hi all,

I have agreed to shepherd this document on behalf of the WG.  I h= ave reviewed this document in preparation for doing the PROTO write-up. &nb= sp;

I think the document needs a bit of work before it's ready to progress= .  I have a few questions/comments, as well as editorial nits which I = think would improve readability and ease of understanding. 

General Comments:

The document requires an SDP directorate review prior to prog= ressing.  I have requested that of the MMUSIC WG chairs.   At the= time of this review, Ali Begen has agreed to do that review. 

Comments/Questions:

1) I am slightly puzzled by the following in section 3: =

m=3D<media> <port> <transport> <fmt> = ...

Section  5.14 of RFC 4566 states the following:

m=3D<media> <port> <proto> <fmt> ...<= /p>

So, this looks to be like the RFC 2327 ABNF for m lines is be= ing used (rather than RFC 4566 which is the normative SDP specification for= this document)?  

m=3D<media> <port> <transport> <fmt list= >

Note, that the IANA registration section appears to be based = on RFC 4566 as the values are specified as being applicable to the 'pro to'= field.  So,  my guess is that this is a bug from RFC 4583.  = ; 
Yes, the SDP directorate review hit on this as well. It needs to be fi= xed to align with RFC 4566.


2) Section 3, next to last paragraph. I think it would be mor= e precise to reword this as:

OLD:

    The fmt (format) list is ignored for BFCP. &nbs= p;The fmt list of BFCP 'm' lines SHOULD contain a single "*" char= acter.

NEW: 

   The fmt (format) list is not applicable to BFCP.=   The fmt list of 'm' lines in the case of any proto field value rela= ted to BFCP SHOULD contain a single "*" character.  If the t= he fmt list contains any other value it is ignored. 

In another thread, I proposed to change from SHOULD to MUST. I am okay= with your proposal as well, especially if there are known reasons and/or i= mplementations that already do otherwise.


3)  Section 4, paragraph above table 1, 1st sentence. &n= bsp;I suggest for clarification to make the following change:

OLD

    MUST include one in the corresponding media des= cription

NEW

    MUST include a 'floorctrl' attribute in the cor= responding media description
Agreed.


4) Section 4, 3rd paragraph from the end:

    "Endpoints that use the offer/answer model= to establish BFCP connections MUST support the 'floorctrl' attribute. &nbs= p;A floor control server acting as an offerer or as an answerer SHOULD incl= ude the attribute in its session descriptions."

Since the latter is a SHOULD what happens if the attribute is= NOT included? Under what circumstances is it okay for the server not to in= clude it?    IF bad things happen if it's not included, then this= probably ought to be a MUST.   Or, if there's reasonable situations in which the floor control server doesn't include th= e attribute, those should be explained or at least an example provided.
Agreed in principle. There is a discussion of which way to go  on= MMUSIC thread in which I proposed MUST was appropriate for servers.


5)  Section  7.  

a)  1st paragraph after ABNF.  "..versions SHO= ULD be integers..".   I would think that ought to be a MUST. &nbs= p;What happens if the token isn't an integer and what was the motivation fo= r not defining the version as an integer versus a token?   If non-inte= gers can be used, the scope of what is acceptable for the field needs to be exp= lained. 
Agreed, and I think MUST be integers is fine.

b) 2nd paragraph after ABNF.  I can see why supporting t= he version is a SHOULD (since it is a new field) and RFC 4583 did not defin= e a version, but I think that needs to be more clearly documented and I thi= nk it ought to be REQUIRED for anyone that is using UDP and obviously, older implementations of TCP (i.e., those only= compliant to RFC 4583 and not this document) ought to be the only ones tha= t aren't using the version field.  

Yep.


c) last paragraph.  Related to b, I would think that in = the case of unreliable transports, it's not that an endpoint MUST "ass= ume".  An endpoint MUST "use" and signal a version numb= er of 2.   In the case of a reliable transport, if the endpoint does not signal a bfcpversion-attribute, then the floor control server MUS= T use a value of 1.   I'm recalling a fair amount of mailing list disc= ussion on this one, so if you can point to the thread where this text was a= greed, I can let this one go.  I still think it's not specified quite right, but I can live with it. 
I think it would be good to tighten up the wording as you suggested.



6) Section 8.  1st sentence.  I think this should b= e a "can use TCP or UDP" and not a "may use TCP or UDP"= . Note, there is the perennial debate with regards to whether something is = normative even when it's not CAPS.  I prefer to just use a different word to remove any confusion, particularly when a different word is actual= ly more correct. 
Works for me.



7) Section 8.1,  4th paragraph, 1st sentence and last se= ntence.  I think the two "SHOULD generate and offer" ought t= o be a MUST generate an offer OR you need to specify the circumstances unde= r which a client would not generate an offer.
Agreed.

 


8) Section 9, 1st paragraph.  You're going to have to be= more specific about the potential mechanisms for authentication - at least= provide an example of mechanisms - i.e., I don't think "some mechanis= m" will fly with the SecDir folks. 
What is we were to say that TLS/DTLS is preferred, but other mechanism= s are possible and outside the scope of this document.


9) Section 11, 2nd paragraph.  I think that the assumes = in the following statement needs to be a required.  I suggest the foll= owing change:

OLD

  BFCP assumes that an initial integrity-protected chann= el is used to exchange...

NEW

 An initial integrity-protected channel is REQUIRED for = BFCP to exchange... 
Yep.


10) Related to item 7, this list of changes has no mention of= the new "bfcpver" attribute.  That definitely should be on = this list.
Good catch.

 


Editorial nits:

1) Introduction.  "These data includes..." -&g= t; "This data includes...."  (data is now grammatically cons= idered to be a singular noun).  

2) Section 3.  1st paragraph after the indented text. &n= bsp;This could be written more concisely (and per technical doc standards n= ot as the 1st person) as follows (and per comment 1) above, I think this sh= ould be the 'proto' field:

OLD:    

     We define four new values for the transpo= rt field:

NEW: 

      This document defines four values for th= e proto field:

3) Section 5.  I suggest the following change:

OLD:

     We define the 'confid' and the 'userid' S= DP media-level attributes.

NEW:

   This document defines two SDP media-level attrib= utes: 'confid' and 'userid'.


4) Section 6. I suggest the following change:

OLD: 

    We define the 'floorid' SDP media-level attribu= te.

NEW:  

   This document defines the 'floorid' SDP media-le= vel attribute. 

5) Section 13.  I found this really, really hard to read= .  I suggest you use a bulleted or numbered list versus this hanging l= ist style. 
Works for me.

Cheers,
Charles



 --_000_CEFACA7A1A7A7eckelcuciscocom_-- From eckelcu@cisco.com Tue Jan 14 11:45:13 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C441A1AE1F6 for ; Tue, 14 Jan 2014 11:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.738 X-Spam-Level: X-Spam-Status: No, score=-12.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vh6RfwwD1bBF for ; Tue, 14 Jan 2014 11:45:10 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3C1AE1A6 for ; Tue, 14 Jan 2014 11:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27445; q=dns/txt; s=iport; t=1389728699; x=1390938299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rZll9y6MQVG6lm3ik1XaJV7uRu9jAIfcOCjJ3tBvgcU=; b=K7J8vlDt1yyDCTYpse0kXSh3V6lU0unzRp34ZiTm+5F0RAAV/pb4I/H0 GF5FUqkpH06EWZtQn3vcv+Bd0dgXdwKDj/4NqSzXB8kj4vd+bv4edMzQ0 VDzch+3wC92+ApieZvdXHK8q2pnEAOJ5Q7XIfQ6CEFEtr5CVFWddP/vks s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAGWS1VKtJXG+/2dsb2JhbABQCoJHRDhWuhBPgRYWdIIlAQEBBCdBERACAQgRAwECFwoHByERFAkIAgQBDQUJEodVAxABDb4ODYVhF4x0gTcLAQEtEREHBgwMhBkEljKBbIxahTuDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="scan'208,217";a="297376690" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jan 2014 19:44:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0EJiwZt027346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 19:44:58 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 13:44:58 -0600 From: "Charles Eckel (eckelcu)" To: Mary Barnes , "draft-ietf-bfcpbis-rfc4582bis.authors@tools.ietf.org" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4582bis-10 Thread-Index: AQHO/Pi9Daan68JtW02dsjrLVYE4+JqEprmA Date: Tue, 14 Jan 2014 19:44:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.21] Content-Type: multipart/alternative; boundary="_000_CEFACFF41A7CEeckelcuciscocom_" MIME-Version: 1.0 Cc: Richard Barnes , "bfcpbis-chairs@tools.ietf.org" Subject: Re: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4582bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:45:14 -0000 --_000_CEFACFF41A7CEeckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Great comments Mary. I agree with all your suggestions. I have added my 2 c= ents in regard to your questions inline. From: Mary Barnes > Date: Thursday, December 19, 2013 12:27 PM To: "draft-ietf-bfcpbis-rfc4582bis.authors@tools.ietf.org" >, "bfcpbis@ietf.org" > Cc: Richard Barnes >, "bfcpbis-chairs@tools.i= etf.org" > Subject: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4582bis-1= 0 I have agreed to shepherd this document on behalf of the WG. I have review= ed this document in preparation for doing the PROTO write-up. I think the document needs a bit of work before it's ready to progress. I = have a few questions/comments, as well as editorial nits which I think woul= d improve readability and ease of understanding. Regards, Mary. General: 1) I still have not had a response from Keith Drage nor Joerg Ott with rega= rds to IPR, so I cannot forward the document to the AD even after the docum= ent is updated until I get those responses. 2) Obviously, the WG needs to agree proposed solutions to the points made b= y Joerg: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00249.html At this time, I've not seen the authors post any proposals as to how to dea= l with those comments/concerns 3) I have reviewed the document in detail - both the entire document and th= e diffs between RFC4582. I have both comments and nits on text that was als= o in RFC 4582, as well as on the new text, detailed below. Note, that a num= ber of nits are around the use of lower case normative words which ought to= be uppercase to distinguish them from the normal English usage. I think th= ere are a number of cases where "may"s for example would be much better sta= ted as "can"s. I've identified some of those below, but I don't think it's= worth the effort to change them all (nor my effort to identify them all). = ` Comments/questions: 1) Section 3.4, 1st paragraph. You need to specify what you mean by the pa= renthetical "in a certain way" - that doesn't tell you anything. Something= like "depending upon policies, privileges, etc." is probably more appropri= ate. 2) Section 6.2. a) 3rd paragraph, 1st sentence: I don't think this is normative since you'r= e referring to the normative section. I suggest "shall form" -> "forms". b) 4th paragraph. Under what conditions would a server not send an Error me= ssage or is that statement just specifically sending an error message with = a parameter value of 10? I can't see why this isn't a MUST. If it's really= a should, more text is needed as to what happens if it isn't sent (or why = not sending the Error message is okay). I believe this was because it may not be possible to form a valid response = because it was not possible to parse fields that are required to be include= d in the response, such as the transaction ID. c) 4th para, last sentence: "shall" -> "SHALL" d) last para, next to last sentence. Why isn't this "MUST" request the use= of DTLS? If it's a SHOULD, then the impacts or criteria under which DTLS i= sn't REQUIRED should be clarified. I see that the paragraph has references= to 5018 Section 5. I think it also should be clarified that the "section= 6" reference in that paragraph is also in 5018 (as I don't think you're re= ferring to section 6 of this document). I think the server can choose to require DTLS or not. If it requires DTLS f= or the request, it MUST respond the request with "Use DTLS). 3) Section 6.2.1 a) 1st para, 3rd sentence. I don't think "previous paragraph" is accurate. = I think it would be better to include an explicit reference to section 6.2= or say "previous section". b) next to last sentence ought to be written normatively OLD The default initial interval is set to 500ms and the interval is doubled after each retransmission attempt. NEW The default initial interval MUST be set to 500ms and the interval MUST be doubled after eac= h retransmission attempt. 4) Section 6.2.2, 1st sentence. What happens if the connection isn't treat= ed as closed (since this is a SHOULD and not a MUST)? Either this is a MUS= T or the reasons one wouldn't treat the connection as closed and what happe= ns when it's not treated as closed need to be explained. 5) Section 6.2.3, indented paragraph. What happens if the cookie exchange = mechanisms in DTLS aren't used and/or what other mechanisms could be used? = (Note, also that the should ought to be SHOULD). 6) Section 9.1. a) 1st para, 2nd sentence. (Similar to comment 9 on rfc4583-bis). The "ass= umes" needs to a REQUIRED. OLD: BFCP assumes that there is an integrity- protected channel between the client and the floor control server that can be used to exchange their self-signed certificates or, more commonly, the fingerprints of these certificates. NEW: An initial integrity-protected channel is REQUIRED between the client and the floor control server that can be used to exchange their self-signed certificates or, more commonly, the fingerprints of these certificates. OR this needs to be a SHOULD and then include the text that's in the "Note= =85" in the 3rd paragraph that indicates if there are additional authentica= tion mechanisms defined that don't require the integrity protected channel. b) 2nd paragraph, last sentence. Under what criteria would a client NOT ig= nore unauthenticated messages or what bad things can happen if a client doe= sn't ignore the messages. It might be better to make this a MUST. c) 4th paragraph, 2nd sentence. "SHOULD check" -> "MUST check" or explain = what might happen if the floor control servers doesn't check that the messa= ges aren't using an authorized User ID. 7) Section 11.1. a) 4th paragraph. There's three SH=10OULDs in there that all ought to be M= USTs OR the situations under which the action doesn't need to be done needs= to be specified. b) 5th paragraph: I don't think that the use of Queue position field in the= last sentence prior to the indented text ought to be normative - i.e., I t= hink the "=10MAY use the Queue Position field" ought to be "can use the Que= ue Position field". c) Indented text (1st para) after 5th para. There are several "may"s: (lo= wer case) in this paragraph (and the next note), that probably all ought to= be "can"s d) last paragraph. It's not clear to me whether this "may" ought to be norm= ative. If so, it should be a =10MAY and perhaps reworded as I think it's tr= ying to say that "the floor chair MAY include STATUS-INFO attributes" in = Otherwise, a "can" would suffice. 8) Section 12.1.2. There is no normative language in this section. It nee= ds to be revisited. For example, 2nd para, 1st sentence. It would seem th= at "the floor control server will respond with a FloorStatus message or with an Error message" ought to be "MUST respond. 9) Section 13.6, 1st para. Under what circumstances would the server NOT g= enerate an Error response (i.e., why is it a SHOULD and not a MUST)? This is inherited from RFC 4582. I agree that MUST seems appropriate. 10) Section 13.7, 1st para. Same comment as 9 above. 11) Section 16.1. I think there should be mention of the additional text a= dded for handling incorrect payload length. 12) Section 16.1. "Requiring timely response". Shouldn't there be a refere= nce to section 8.3 (Timers)? Yes. 13) Appendix A. Has there been anyone that has verified the call flows with= a tool or in the lab? If so, who was that? Not sure, but I expect yes. Hopefully someone can else can respond to this. Nits: 1) Section 3.1, last paragraph. I would prefer this be updated to be much = more precise in terms of CCM=10P. I realize that this document was publish= ed well before CCMP, so the text in RFC 4582 is based on draft versions. OLD: Conference control clients using CCMP [17] can specify such floor- related settings by editing the floor-information section of the to-be created conference object provided in the body of a CCMP confRequest/create message issued to the conference control server. NEW: Conference control clients using CCMP [17] can specify such floor- related settings in the [RFC6501]element of the to-be created conference object provided in the body of a CCMP confRequest/create message issued to the conference control server. 2) Section 3.2, 1st para, 2nd sentence. "These data include=85" -> This da= ta includes 3) Section 3.3, last paragraph. " section" -> " element" 4) Section 6.2, 4th para, last sentence: "shall" -> "SHALL" 5) Section 6.2.3: - seventh paragraph. "must then retransmit" -> "MUST then retransmit" - indented paragraph. "the Payload Length field may be compared" - > "can b= e compared" 6) Section 8, 2nd indented paragraph. "must be non-zero" -> "MUST be non-ze= ro" 7) Section 10.1.1. 1st paragraph after 2nd indented para. "must insert" -> = "MUST insert" 8) Section 10.1.2, 5th & 6th paragraphs. "MAY display" -> "can display" 9) Section 12.2.1. last paragraph. "must insert" -> "MUST insert" 10) Section 12.3.1. last paragraph. "must insert" -> "MUST insert" 11) Section 16.1. This is a bit hard to read. I would suggest you use a b= ulleted or numbered list rather than this hanging list format. 12) References: a) Per the first nit, a reference to RFC 6501 (XCON Data model) should be a= dded to this document. b) RFC 4582 should be a normative reference c) I also suggest that RFC 5018 is normative as this document relies on RFC= 5018 for authentication and security. Sounds good. Cheers, Charles --_000_CEFACFF41A7CEeckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <465CF26670D6A9429DB8C4698DFD6C52@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Great comments Mary. I agree with all your suggestions. I have added m= y 2 cents in regard to your questions inline.

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thursday, December 19, 2013 1= 2:27 PM
To: "draft-ietf-bfcpbis-rfc4582bi= s.authors@tools.ietf.org" <draft-ietf-bfcpbis-rfc4582bis.authors@t= ools.ietf.org>, "bfcpbis@ietf.org" <<= a href=3D"mailto:bfcpbis@ietf.org">bfcpbis@ietf.org>
Cc: Richard Barnes <rlb@ipv.sx>, "bfcpbis-chairs@tools.ietf.org" <bfcpbis-chairs@tools.ietf.org> Subject: [bfcpbis] PROTO review com= ments on draft-ietf-bfcpbis-rfc4582bis-10

= I have agreed to shepherd this document on behalf of the WG.  I have r= eviewed this document in preparation for doing the PROTO write-up.  
=
= I think the document needs a bit of work before it's ready to progress. &nb= sp;I have a few questions/comments, as well as editorial nits which I think= would improve readability and ease of understanding. 
=
= Regards,
= Mary. 


General:
1) I still have not had a response from Keith Drage nor Joerg Ott with= regards to IPR, so I cannot forward the document to the AD even after the = document is updated until I get those responses.

2) Obviously, the WG needs to agree proposed solutions to the points m= ade by Joerg:
At this time, I've not seen the authors post any proposals as to how t= o deal with those comments/concerns

3) I have reviewed the document in detail - both the entire document a= nd the diffs between RFC4582. I have both comments and nits on text that wa= s also in RFC 4582, as well as on the new text, detailed below. Note, that = a number of nits are around the use of lower case normative words which ought to be uppercase to distingui= sh them from the normal English usage. I think there are a number of cases = where "may"s for example would be much better stated as "can= "s.  I've identified some of those below, but I don't think it's worth the effort to change them all (nor my effort to ide= ntify them all). `


Comments/questions:

1) Section 3.4, 1st paragraph.  You need to specify what you mean= by the parenthetical "in a certain way" - that doesn't tell you = anything.  Something like "depending upon policies, privileges, e= tc." is probably more appropriate. 

2) Section 6.2.
a) 3rd paragraph, 1st sentence: I don't think this is normative since = you're referring to the normative section.  I suggest "shall form= " -> "forms".
b) 4th paragraph. Under what conditions would a server not send an Err= or message or is that statement just specifically sending an error message = with a parameter value of 10?  I can't see why this isn't a MUST. If i= t's really a should, more text is needed as to what happens if it isn't sent (or why not sending the Error message = is okay). 

I believe this was because it may not be possible to form a valid resp= onse because it was not possible to parse fields that are required to be in= cluded in the response, such as the transaction ID.

c) 4th para, last sentence: "shall" -> "SHALL"<= /div>
d) last para, next to last sentence.  Why isn't this "MUST&q= uot; request the use of DTLS? If it's a SHOULD, then the impacts or criteri= a under which DTLS isn't REQUIRED should be clarified.  I see that the= paragraph has references to  5018 Section 5.  I think it also should be clarified that the "section 6" reference in th= at paragraph is also in 5018 (as I don't think you're referring to section = 6 of this document). 

I think the server can choose to require DTLS or not. If it requires D= TLS for the request, it MUST respond the request with "Use DTLS).


3) Section 6.2.1
a) 1st para, 3rd sentence. I don't think "previous paragraph"= ; is accurate.  I think it would be better to include an explicit refe= rence to section 6.2 or say "previous section".   
b) next to last sentence ought to be written normatively
OLD
   The default initial
   interval is set to 500ms and the interval is doubled afte= r each
   retransmission attempt.
NEW
   The default initial
   interval MUST be set to 500ms and the interval MUST be do= ubled after each
   retransmission attempt.

4) Section 6.2.2, 1st sentence.  What happens if the connection i= sn't treated as closed (since this is a SHOULD and not a MUST)?  Eithe= r this is a MUST or the reasons one wouldn't treat the connection as closed= and what happens when it's not treated as closed need to be explained.  

5) Section 6.2.3, indented paragraph.  What happens if the cookie= exchange mechanisms in DTLS aren't used and/or what other mechanisms could= be used?   (Note, also that the should ought to be SHOULD).

6) Section 9.1. 
a) 1st para, 2nd sentence. (Similar to comment 9 on rfc4583-bis). &nbs= p;The "assumes" needs to a REQUIRED.  
OLD:
   BFCP assumes that there is an integrity-
   protected channel between the client and the floor contro= l server
   that can be used to exchange their self-signed certificat= es or, more
   commonly, the fingerprints of these certificates. 

NEW: 
   An initial integrity-protected channel is REQUIRED betwee= n the client 
   and the floor control server that can be used to exchange= their 
   self-signed certificates or, more commonly, the fingerpri= nts of 
   these certificates. 

OR  this needs to be a SHOULD and then include the text that's in= the "Note=85" in the 3rd paragraph that indicates if there are a= dditional authentication mechanisms defined that don't require the integrit= y protected channel. 

b) 2nd paragraph, last sentence.  Under what criteria would a cli= ent NOT ignore unauthenticated messages or what bad things can happen if a = client doesn't ignore the messages.  It might be better to make this a= MUST.   

c) 4th paragraph, 2nd sentence.  "SHOULD check" -> &= quot;MUST check" or explain what might happen if the floor control ser= vers doesn't check that the messages aren't using an authorized User ID. &n= bsp; 

7) Section 11.1.
a) 4th paragraph.  There's three SHOULDs in there that all o= ught to be MUSTs OR the situations under which the action doesn't need to b= e done needs to be specified. 
b) 5th paragraph: I don't think that the use of Queue position field i= n the last sentence prior to the indented text ought to be normative - i.e.= , I think the "MAY use the Queue Position field" ought to be= "can use the Queue Position field".  
c) Indented text (1st para) after 5th para.   There are several &= quot;may"s: (lower case) in this paragraph (and the next note), that p= robably all ought to be "can"s  
d) last paragraph. It's not clear to me whether this "may" o= ught to be normative. If so, it should be a MAY and perhaps reworded a= s I think it's trying to say that "the floor chair MAY include STATUS-= INFO attributes" in    Otherwise, a "can" would su= ffice.  

8) Section 12.1.2.  There is no normative language in this sectio= n.  It needs to be revisited.  For example, 2nd para, 1st sentenc= e.  It would seem that "the floor control server will
   respond with a FloorStatus message or with an Error messa= ge" 
ought to be "MUST respond. 

9) Section 13.6, 1st para.  Under what circumstances would the se= rver NOT generate an Error response (i.e., why is it a SHOULD and not a MUS= T)?  

This is inherited from RFC 4582. I agree that MUST seems appropriate.<= /div>

 

10) Section 13.7, 1st para. Same comment as 9 above. 

11) Section 16.1.  I think there should be mention of the additio= nal text added for handling incorrect payload length.

12) Section 16.1. "Requiring timely response".  Shouldn= 't there be a reference to section 8.3 (Timers)?   

Yes.


13) Appendix A. Has there been anyone that has verified the call flows= with a tool or in the lab?  If so, who was that?   

Not sure, but I expect yes. Hopefully someone can else can respond to = this.


Nits:

1) Section 3.1, last paragraph.  I would prefer this be updated t= o be much more precise in terms of CCMP.  I realize that this doc= ument was published well before CCMP, so the text in RFC 4582 is based on d= raft versions. 
OLD:
   Conference control clients using CCMP [17] can specify su= ch floor-
   related settings by editing the floor-information section= of the
   to-be created conference object provided in the body of a= CCMP
   confRequest/create message issued to the conference contr= ol server.

NEW: 
    Conference control clients using CCMP [17] can specify s= uch floor-
   related settings in the <floor-information> [RFC650= 1]element of the
   to-be created conference object provided in the body of a= CCMP
   confRequest/create message issued to the conference contr= ol server.

2) Section 3.2, 1st para, 2nd sentence.  "These data include= =85" -> This data includes

3) Section 3.3, last paragraph. "<floor-information> sectio= n" ->  "<floor-information> element"

4) Section 6.2, 4th para, last sentence: "shall" -> "= ;SHALL"

5) Section 6.2.3:
- seventh paragraph. "must then retransmit" -> "MUST= then retransmit" 
- indented paragraph. "the Payload Length field may be compared&q= uot; - > "can be compared" 

6) Section 8, 2nd indented paragraph. "must be non-zero" -&g= t; "MUST be non-zero"

7) Section 10.1.1. 1st paragraph after 2nd indented para. "must i= nsert" -> "MUST insert"

8) Section 10.1.2, 5th & 6th paragraphs.  "MAY display&q= uot; -> "can display"  

9) Section 12.2.1. last paragraph. "must insert" -> "= ;MUST insert"

10) Section 12.3.1.   last paragraph. "must insert" -&g= t; "MUST insert"

11) Section 16.1.  This is a bit hard to read.  I would sugg= est you use a bulleted or numbered list rather than this hanging list forma= t. 

12) References:
a) Per the first nit, a reference to RFC 6501 (XCON Data model) should= be added to this document. 
b) RFC 4582 should be a normative reference
c) I also suggest that RFC 5018 is normative as this document relies o= n RFC 5018 for authentication and security. 

Sounds good.

Cheers,
Charles
--_000_CEFACFF41A7CEeckelcuciscocom_-- From christer.holmberg@ericsson.com Wed Jan 15 06:27:46 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FD31AE375 for ; Wed, 15 Jan 2014 06:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 IiwAc8YnaxQC for ; Wed, 15 Jan 2014 06:27:44 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE5C1AE373 for ; Wed, 15 Jan 2014 06:27:43 -0800 (PST) X-AuditID: c1b4fb32-b7f2b8e0000073bf-12-52d69ad2f9fc Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 33.AC.29631.2DA96D25; Wed, 15 Jan 2014 15:27:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Wed, 15 Jan 2014 15:27:30 +0100 From: Christer Holmberg To: "bfcpbis@ietf.org" Thread-Topic: TCP/TLS: Who is TLS server when the connection goes down and is re-established? Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPng== Date: Wed, 15 Jan 2014 14:27:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5FB1EAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvje6lWdeCDH6u0bf4t+4okwOjx5Il P5kCGKO4bFJSczLLUov07RK4MuY2cRX0mFa0nHnH3sB4T7eLkZNDQsBE4vzHK2wQtpjEhXvr gWwuDiGBE4wSZ7bfY4VwljBK7FnWCZTh4GATsJDo/qcN0iAioCmxeftdJhBbWCBKYvanA8wg JSIC8RIrWnMhSvQkzhxczw5iswioSiw5OgOsnFfAV2Ly4UuMIDYj0N7vp9aAxZkFxCVuPZnP BHGPgMSSPeeZIWxRiZeP/7GCjJcQUJRY3i8HUZ4vsbdtIiPESEGJkzOfsExgFJqFZNIsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJxcX5 eXrFqZsYgVFxcMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoHRpej08hbuF8fO6mmsXCT6/c+lB3uMRW3+VEq8dLm/6vzPmG/aSQ41F2Zq7N2ovZ9pbdrW tu/res/ufOx5o2GfklOeuSC/t2P2S+3fh1UMC/rWpBsceDqJ9/26KaoLuk4Xab3/XvS8q1rc f9r3zTFxfjV8Za+UGJ1mr3R9HD35ad7bG+Kbv3KlKLEUZyQaajEXFScCAGzi7h1YAgAA Subject: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:27:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5FB1EAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I realize the following comes late in the process, and I apologize if it ha= s been discussed, but it is related to something which just has recently po= pped up in 3GPP, and it's not addressed in the draft. Section 7 says the following: "For a TCP/TLS connection established using an SDP offer/answer exchange [7], the answerer (which may be the c= lient or the floor control server) always acts as the TLS server." Q1: Assume the TCP/TLS connection, for whatever reason, goes down. Now, I assume that whoever endpoint is "active" will most likely try to re-= establish the TCP connection. But, if the "active" endpoint doesn't send an Offer (i.e. it simply tries t= o re-establish the TCP connection based on the previously negotiated SDP in= formation), who will act as TLS server? There is no Answerer. One alternative would be to mandate the sending of an Offer when the TCP/TL= S connection is re-established. Then it would be clear who is Offerer, and = who is Answerer. Another alternative would be to say that whoever was previously Answerer wi= ll act as TLS server. Q2: Assume there is an Offer/Answer transaction during the session. Now, the TC= P/TLS connection is not affected by that, but the TLS roles may change (if = whoever was Offerer in the previous O/A transaction is now Answerer). I think some wording would be needed about that also. One alternative is to say that the TLS roles may change, but that doesn't a= ffect the TCP/TLS connection. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C5FB1EAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I realize the following comes late in the process, a= nd I apologize if it has been discussed, but it is related to something whi= ch just has recently popped up in 3GPP, and it’s not addressed in the= draft.

 

Section 7 says the following:

 

“For a TCP/TLS co= nnection established using an SDP

         &nb= sp;      offer/answer exchange [7], the answerer (= which may be the client or

         &nb= sp;      the floor control server) always acts as = the TLS server.”

 

Q1:

 

Assume the TCP/TLS connection, for whatever reason, = goes down.

 

Now, I assume that whoever endpoint is “active= ” will most likely try to re-establish the TCP connection.=

 

But, if the “active” endpoint doesn̵= 7;t send an Offer (i.e. it simply tries to re-establish the TCP connection = based on the previously negotiated SDP information), who will act as TLS se= rver? There is no Answerer.

 

One alternative would be to mandate the sending of a= n Offer when the TCP/TLS connection is re-established. Then it would be cle= ar who is Offerer, and who is Answerer.

 

Another alternative would be to say that whoever was= previously Answerer will act as TLS server.

 

 

Q2:

 

Assume there is an Offer/Answer transaction during t= he session. Now, the TCP/TLS connection is not affected by that, but the TL= S roles may change (if whoever was Offerer in the previous O/A transaction = is now Answerer).

 

I think some wording would be needed about that also= .

 

One alternative is to say that the TLS roles may cha= nge, but that doesn’t affect the TCP/TLS connection.

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C5FB1EAESESSMB209erics_-- From tomkrist@cisco.com Thu Jan 16 06:48:00 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC951AE307 for ; Thu, 16 Jan 2014 06:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.739 X-Spam-Level: X-Spam-Status: No, score=-7.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 otLL4GWDxzjz for ; Thu, 16 Jan 2014 06:47:58 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E4AD11AE2FE for ; Thu, 16 Jan 2014 06:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10248; q=dns/txt; s=iport; t=1389883666; x=1391093266; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fa4q2pUI1QHilm1j0+J2xXK8D1UlbRja8e3ONgIVvkA=; b=hfxnrXDKCpUQruHKpmmovs//A4GDApejTizgoBtHj9hct2IcM2eiur7f Bm4PAp8MzwR1kWSFRKlMIntZsmLLFh82w6fFAbqhrTPkF/E+rlrEJhjQE 5HIr0RujyS1rcRX2dvBQomvTvRoe4kH8NjGbEbaIkUuCYiyLVhgXErj0R 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAJ/w11KQ/khM/2dsb2JhbABXAoMLuRGDCIELFnSCJQEBAQMBJxE2CgEQCxgJDQkPCQMCAQIBRQYNAQcBAReHYQjEQReOPUIHEguEGwEDmCGGRotRgy47gS4HFw X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="3721742" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 14:47:45 +0000 Received: from [10.61.86.87] (ams3-vpn-dhcp5720.cisco.com [10.61.86.87]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0GEliIF025296; Thu, 16 Jan 2014 14:47:44 GMT Message-ID: <52D7F10B.5070401@cisco.com> Date: Thu, 16 Jan 2014 15:47:39 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "bfcpbis@ietf.org" , "bfcpbis-chairs@tools.ietf.org" , draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org Subject: Re: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:48:00 -0000 I went through and commented on this in my favourite editor (Emacs obviously), but forgot to paste it in and respond until now. I have updated my comments to align with Charles Eckel's recent response too. Inline below. On 12/18/2013 11:38 PM, Mary Barnes wrote: > Hi all, > > I have agreed to shepherd this document on behalf of the WG. I have > reviewed this document in preparation for doing the PROTO write-up. > > I think the document needs a bit of work before it's ready to progress. > I have a few questions/comments, as well as editorial nits which I think > would improve readability and ease of understanding. > > _General Comments:_ > > The document requires an SDP directorate review prior to progressing. I > have requested that of the MMUSIC WG chairs. At the time of this review, > Ali Begen has agreed to do that review. Yes, I have commented on his issues on the MMUSIC mailing list. > _Comments/Questions:_ > > 1) I am slightly puzzled by the following in section 3: > > m= ... > > Section 5.14 of RFC 4566 states the following: > > m= ... > > So, this looks to be like the RFC 2327 ABNF for m lines is being used > (rather than RFC 4566 which is the normative SDP specification for this > document)? > > m= > > Note, that the IANA registration section appears to be based on RFC 4566 > as the values are specified as being applicable to the 'pro to' field. > So, my guess is that this is a bug from RFC 4583. Yes, an inherited bug that will be fixed without complications. > 2) Section 3, next to last paragraph. I think it would be more precise > to reword this as: > > OLD: > > The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' > lines SHOULD contain a single "*" character. > > NEW: > > The fmt (format) list is not applicable to BFCP. The fmt list of 'm' > lines in the case of any proto field value related to BFCP SHOULD > contain a single "*" character. If the the fmt list contains any other > value it is ignored. Agree. That is a more precise wording for the fmt part. Charles Eckel touched upon this as well and was okay with this, especially if there are known reasons and/or implementations that already do otherwise. Well, once upon a time there was a SIP based product from a (large french) vendor that used 0 (I think) - don't think that product is still maintained. But it might be out there in the wild still. Will fix. > 3) Section 4, paragraph above table 1, 1st sentence. I suggest for > clarification to make the following change: > > OLD > > MUST include one in the corresponding media description > > NEW > > MUST include a 'floorctrl' attribute in the corresponding media description Fine with me, will update. > 4) Section 4, 3rd paragraph from the end: > > "Endpoints that use the offer/answer model to establish BFCP connections > MUST support the 'floorctrl' attribute. A floor control server acting as > an offerer or as an answerer SHOULD include the attribute in its session > descriptions." > > Since the latter is a SHOULD what happens if the attribute is NOT > included? Under what circumstances is it okay for the server not to > include it? IF bad things happen if it's not included, then this > probably ought to be a MUST. Or, if there's reasonable situations in > which the floor control server doesn't include the attribute, those > should be explained or at least an example provided. The default behaviour/assumption if the 'floorctrl' attribute is not used is explained in the paragraph below, i.e. offerer == client and answerer == server. I agree that the formulation "is not used in an offer/answer exchange" might point towards usage other than offer/answer, but the sentence continues with explaining what the offerer and answerer will assume. So fine with me. OK? If not, I will not object using MUST here - as also proposed by Charles Eckel. > 5) Section 7. > > a) 1st paragraph after ABNF. "..versions SHOULD be integers..". I would > think that ought to be a MUST. What happens if the token isn't an > integer and what was the motivation for not defining the version as an > integer versus a token? If non-integers can be used, the scope of what > is acceptable for the field needs to be explained. I agree, this will be upgraded to a MUST if people doesn't object. And if this will ever change non-integer versions must be specified in another draft/RFC and this draft probably have to be updated as well - since semantics for specific versions are specified later in Section 7. > b) 2nd paragraph after ABNF. I can see why supporting the version is a > SHOULD (since it is a new field) and RFC 4583 did not define a version, > but I think that needs to be more clearly documented and I think it > ought to be REQUIRED for anyone that is using UDP and obviously, older > implementations of TCP (i.e., those only compliant to RFC 4583 and not > this document) ought to be the only ones that aren't using the version > field. Is it sufficient to merge in the following sentence after the second sentence in that paragraph? "However, endpoints that supports RFCXXXX, and not only the RFC 4583 subset, is REQUIRED to support and use the 'bfcpver' attribute." (Or something along those lines). A complicating factor here is that some pre-standard implementations, as experienced on recent SIPit and SuperOp test events, is out there and is not using the 'bfcpver' attribute. However, demanding that implementations following the new RFC from this draft have to use the version attribute should be perfectly fine. > c) last paragraph. Related to b, I would think that in the case of > unreliable transports, it's not that an endpoint MUST "assume". An > endpoint MUST "use" and signal a version number of 2. In the case of a > reliable transport, if the endpoint does not signal a > bfcpversion-attribute, then the floor control server MUST use a value of > 1. I'm recalling a fair amount of mailing list discussion on this one, > so if you can point to the thread where this text was agreed, I can let > this one go. I still think it's not specified quite right, but I can > live with it. I can't find too much discussion about this, but I agree that the word "assume" is not good here. What about reformulating this last paragraph to: "If a 'bfcpver' attribute is not present, default values are based on the transport specified in the m-line (Section 3). When used over an unreliable transport, an endpoint MUST use a value of "2", and when used over a reliable transport, an endpoint MUST use a value of "1". This is in line with the definition of the Version field in [8]." Any better? > 6) Section 8. 1st sentence. I think this should be a "can use TCP or > UDP" and not a "may use TCP or UDP". Note, there is the perennial debate > with regards to whether something is normative even when it's not CAPS. > I prefer to just use a different word to remove any confusion, > particularly when a different word is actually more correct. Well explained, the change is fine with me. > 7) Section 8.1, 4th paragraph, 1st sentence and last sentence. I think > the two "SHOULD generate and offer" ought to be a MUST generate an offer > OR you need to specify the circumstances under which a client would not > generate an offer. OK > 8) Section 9, 1st paragraph. You're going to have to be more specific > about the potential mechanisms for authentication - at least provide an > example of mechanisms - i.e., I don't think "some mechanism" will fly > with the SecDir folks. Too bad, since this is inherited from RFC 4583 - but of course that text wasn't perfect ;) Anyway, isn't the mechanisms meant here mentioned in the paragraphs below? If so, might extending to "using some mechanism, as explained below" be a valid solution in front of the SecDir review? Or as Charles Eckel proposed, pointing towards TLS/DTLS as the preferred mechanism, but other mechanisms exists but are outside the scope of this document. > 9) Section 11, 2nd paragraph. I think that the assumes in the following > statement needs to be a required. I suggest the following change: > > OLD > > BFCP assumes that an initial integrity-protected channel is used to > exchange... > > NEW > > An initial integrity-protected channel is REQUIRED for BFCP to exchange... Yes, I'll adopt that one. No assumption, we will require! > 10) Related to item 7, this list of changes has no mention of the new > "bfcpver" attribute. That definitely should be on this list. Indeed! It's missing since it arrived late, but that's just a poor excuse... > _Editorial nits:_ > > 1) Introduction. "These data includes..." -> "This data includes...." > (data is now grammatically considered to be a singular noun). OK > 2) Section 3. 1st paragraph after the indented text. This could be > written more concisely (and per technical doc standards not as the 1st > person) as follows (and per comment 1) above, I think this should be the > 'proto' field: > > OLD: > > We define four new values for the transport field: > > NEW: > > This document defines four values for the proto field: OK > 3) Section 5. I suggest the following change: > > OLD: > > We define the 'confid' and the 'userid' SDP media-level attributes. > > NEW: > > This document defines two SDP media-level attributes: 'confid' and 'userid'. OK > 4) Section 6. I suggest the following change: > > OLD: > > We define the 'floorid' SDP media-level attribute. > > NEW: > > This document defines the 'floorid' SDP media-level attribute. OK > 5) Section 13. I found this really, really hard to read. I suggest you > use a bulleted or numbered list versus this hanging list style. Sure, I'll tweak the XML curses and make it more readable. -- Tom From tomkrist@cisco.com Thu Jan 16 07:15:00 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1731AE4D5 for ; Thu, 16 Jan 2014 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hH3tyN-3bV-I for ; Thu, 16 Jan 2014 07:14:59 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 27CD71AE4D3 for ; Thu, 16 Jan 2014 07:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2741; q=dns/txt; s=iport; t=1389885287; x=1391094887; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vh3w92iiIoWX399UVpj9hlxnEUZharoVPSQ4gtxyOaw=; b=jNRgE7XjG+r4KNvMTnUrFvMoI5OcBdLWpsj3tlqghCzmim5nz4/JLqQO zd8kGsmn9U+mec31m6Hzuy1PQx6MCddiMgMl/SgADvKjnMoBbQjzsQhSI Q6kmiWY1Q5+mUl6dINf6mdZgdSYZNqYStlNSEsG7ulmBkqvyTxDAqaxWy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAJX211KQ/khR/2dsb2JhbABZgwu5EYMIgQsWdIIlAQEBAwEyAQVAAQULCxgJFg8JAwIBAgFFBg0BBwEBh3gIxE0Xjn8HhDgBA5ghhkaLUYFvgT87 X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="3722938" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 15:14:46 +0000 Received: from [10.61.86.87] (ams3-vpn-dhcp5720.cisco.com [10.61.86.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0GFEkbY025154; Thu, 16 Jan 2014 15:14:46 GMT Message-ID: <52D7F766.8000402@cisco.com> Date: Thu, 16 Jan 2014 16:14:46 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:15:01 -0000 On 01/15/2014 03:27 PM, Christer Holmberg wrote: > Hi, > > I realize the following comes late in the process, and I apologize if it > has been discussed, but it is related to something which just has > recently popped up in 3GPP, and it’s not addressed in the draft. Not too late, since we are still not finished! Anyway, the TCP/TLS connection reuse is not altered while extending BFCP to support unreliable transport. Any fixes now must be backwards compatible in some way. That said and based on what I have seen from different vendors, most of them still use TCP (without TLS) :) So, at least if we are changing anything to solve these issues, we should add an informational note indicating this is a change where legacy, pure RFC 4582 implementations might differ in behaviour... By the way: How these issues was solved in 3GPP are along the lines of what you propose below? > Section 7 says the following: > > “For a TCP/TLS connection 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.” > > Q1: > > Assume the TCP/TLS connection, for whatever reason, goes down. > > Now, I assume that whoever endpoint is “active” will most likely try to > re-establish the TCP connection. > > But, if the “active” endpoint doesn’t send an Offer (i.e. it simply > tries to re-establish the TCP connection based on the previously > negotiated SDP information), who will act as TLS server? There is no > Answerer. > > One alternative would be to mandate the sending of an Offer when the > TCP/TLS connection is re-established. Then it would be clear who is > Offerer, and who is Answerer. > > Another alternative would be to say that whoever was previously Answerer > will act as TLS server. I'm not too fond of yet another re-INVITE being mandated, so if we will fix this issue mandating the previous answerer to be the TLS server would be my preference. > Q2: > > Assume there is an Offer/Answer transaction during the session. Now, the > TCP/TLS connection is not affected by that, but the TLS roles may change > (if whoever was Offerer in the previous O/A transaction is now Answerer). > > I think some wording would be needed about that also. > > One alternative is to say that the TLS roles may change, but that > doesn’t affect the TCP/TLS connection. A healthy TCP/TLS connection shouldn't be affected at all, should it? However, any potential connection re-establishment will need to monitor who was the last answerer to do the TLS initiation correctly. Hopefully I did understand the issue here, and added my 2 zlotys or pence or whatever, -- Tom From christer.holmberg@ericsson.com Thu Jan 16 11:36:24 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7CD1A1F61 for ; Thu, 16 Jan 2014 11:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 eNdE0u3TqQix for ; Thu, 16 Jan 2014 11:36:22 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2B21A1F54 for ; Thu, 16 Jan 2014 11:36:22 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-32-52d834a9445a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3F.12.23787.9A438D25; Thu, 16 Jan 2014 20:36:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.120]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0347.000; Thu, 16 Jan 2014 20:36:08 +0100 From: Christer Holmberg To: Tom Kristensen Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPngAy768AAAq9+j4= Date: Thu, 16 Jan 2014 19:36:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com> In-Reply-To: <52D7F766.8000402@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje5KkxtBBt8XCVn8W3eUyeLKkV9s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGsaMX2Qvmy1XcenWUrYGxTaKLkZNDQsBE 4vDCLnYIW0ziwr31bF2MXBxCAocYJToXLINyljBK9C6ey9zFyMHBJmAh0f1PG6RBREBdom/v d7BmZgFNiauHdzGC2MICGRJzlu4CKxcRyJRomKwAYVpJ7F1fBlLBIqAq0dLzHKyCV8BXon2a NEhYSCBLomX7ayYQmxNo4P5vv8EGMgJd9v3UGiaIReISt57MZ4K4WEBiyZ7zzBC2qMTLx/9Y IWwliR8bLrFA1BtIvD83nxnC1pZYtvA1mM0rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKs YmTPTczMSS833MQIjI6DW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanF hxiZODilGhjdNf7pXdJi+Ci0NdFM8Ux88yqp30HXnUMSsr0O/VznEbo/f5FVqJencb3r7pta 0j51LNxKKckPhXlCDJRvfO5xmSIy7Vq5gAm7+tXtH46IPZvMzXPWcsGcY283cx18etfoC2tA kMfMDz/cmWYeYEjTjFn6+m3fz+2zn6a41QW1WzB1brZrW6TEUpyRaKjFXFScCABLbCT6XAIA AA== Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:36:24 -0000 Hi Tom, >> I realize the following comes late in the process, and I apologize if it >> has been discussed, but it is related to something which just has >> recently popped up in 3GPP, and it=92s not addressed in the draft. > > Not too late, since we are still not finished! Anyway, the TCP/TLS > connection reuse is not altered while extending BFCP to support > unreliable transport. Any fixes now must be backwards compatible in some > way. > > That said and based on what I have seen from different vendors, > most of them still use TCP (without TLS) :) > > So, at least if we are changing anything to solve these issues, we > should add an informational note indicating this is a change where > legacy, pure RFC 4582 implementations might differ in behaviour... I am not suggesting to change anything - I am suggesting to specify somethi= ng which is currently unspecified :) > By the way: How these issues was solved in 3GPP are along the lines of wh= at you propose below? We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week. However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week. >> Section 7 says the following: >> >> =93For a TCP/TLS connection 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.=94 >> >> Q1: >> >> Assume the TCP/TLS connection, for whatever reason, goes down. >> >> Now, I assume that whoever endpoint is =93active=94 will most likely try= to >> re-establish the TCP connection. >> >> But, if the =93active=94 endpoint doesn=92t send an Offer (i.e. it simpl= y >> tries to re-establish the TCP connection based on the previously >> negotiated SDP information), who will act as TLS server? There is no >> Answerer. >> >> One alternative would be to mandate the sending of an Offer when the >> TCP/TLS connection is re-established. Then it would be clear who is >> Offerer, and who is Answerer. >> >> Another alternative would be to say that whoever was previously Answerer >> will act as TLS server. > > I'm not too fond of yet another re-INVITE being mandated, so if we will > fix this issue mandating the previous answerer to be the TLS server > would be my preference. Assuming that, then my follow-up question is: When you say "previous answerer", do you refer to the answerer in the lates= t Offer/Answer transaction, OR the answerer in the last Offer/Answer transa= ction that established/re-established the TCP/TLS connection (those Offer/A= nswer transactions may, or may not, be the same). >> Q2: >> >> Assume there is an Offer/Answer transaction during the session. Now, the >> TCP/TLS connection is not affected by that, but the TLS roles may change >> (if whoever was Offerer in the previous O/A transaction is now Answerer)= . >> >> I think some wording would be needed about that also. >> >> One alternative is to say that the TLS roles may change, but that >> doesn=92t affect the TCP/TLS connection. > > A healthy TCP/TLS connection shouldn't be affected at all, should it? Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server. >However, any potential connection re-establishment will need to monitor >who was the last answerer to do the TLS initiation correctly. > >Hopefully I did understand the issue here, and added my 2 zlotys or >pence or whatever, I think you did understand the issue :) Regards, Christer From christer.holmberg@ericsson.com Mon Jan 20 17:21:49 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713C61A027A for ; Mon, 20 Jan 2014 17:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 c2ybmnfSPtTq for ; Mon, 20 Jan 2014 17:21:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3F5C1A0002 for ; Mon, 20 Jan 2014 17:21:45 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-6e-52ddcba99863 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 46.FF.23787.9ABCDD25; Tue, 21 Jan 2014 02:21:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 02:21:44 +0100 From: Christer Holmberg To: Tom Kristensen Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPngAy768AAAq9+j4A1NzWIA== Date: Tue, 21 Jan 2014 01:21:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje7K03eDDLqm8ln8W3eUyeLKkV9s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGpNs32AvOq1RMmvKevYFxv2wXIyeHhICJ xP+pe9khbDGJC/fWs3UxcnEICRxilFjV9JwRwlnCKPHk6iSgKg4ONgELie5/2iANIgLqEn17 v4M1MwtoSlw9vIsRxBYWyJBY8u8EG0i5iECmRMNkBYhyJ4n5r66ygNgsAqoSvT92grXyCvhK /O55wA6xaiOjxJE3rUwgCU4BP4mj1z+ygdiMQMd9P7WGCWKXuMSHg9eZIY4WkFiy5zyULSrx 8vE/VghbSWLF9kuMEPV6EjemTmGDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQs YGRZxciem5iZk15uuIkRGCMHt/zW3cF46pzIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTAGxC2YnHHjSpO4nggr29JKJy6/2UvXXuUKssuNt+p1s3010SVpzX7ViYXS u1fJ7+Z/ckq2Zlapstzt0GXhy9wD1gg4KhnVX0rfZnP6g1dgWiejzXL2ufy2E11bFDasMbwp Pjs3fQ7PtLff3QO+OdeqHr/S7CTL6beB879c/BS3I5KHpr4N2aXEUpyRaKjFXFScCAAjSiBu XwIAAA== Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 01:21:49 -0000 Hi, Some initial text proposal: "If the TCP connection is lost, the "active" endpoint is responsible for re= -establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles." Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christe= r Holmberg L=E4hetetty: 16. tammikuuta 2014 21:36 Vastaanottaja: Tom Kristensen Kopio: bfcpbis@ietf.org Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established? Hi Tom, >> I realize the following comes late in the process, and I apologize if=20 >> it has been discussed, but it is related to something which just has=20 >> recently popped up in 3GPP, and it's not addressed in the draft. > > Not too late, since we are still not finished! Anyway, the TCP/TLS=20 > connection reuse is not altered while extending BFCP to support=20 > unreliable transport. Any fixes now must be backwards compatible in=20 > some way. > > That said and based on what I have seen from different vendors, most=20 > of them still use TCP (without TLS) :) > > So, at least if we are changing anything to solve these issues, we=20 > should add an informational note indicating this is a change where=20 > legacy, pure RFC 4582 implementations might differ in behaviour... I am not suggesting to change anything - I am suggesting to specify somethi= ng which is currently unspecified :) > By the way: How these issues was solved in 3GPP are along the lines of wh= at you propose below? We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week. However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week. >> Section 7 says the following: >> >> "For a TCP/TLS connection 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." >> >> Q1: >> >> Assume the TCP/TLS connection, for whatever reason, goes down. >> >> Now, I assume that whoever endpoint is "active" will most likely try=20 >> to re-establish the TCP connection. >> >> But, if the "active" endpoint doesn't send an Offer (i.e. it simply=20 >> tries to re-establish the TCP connection based on the previously=20 >> negotiated SDP information), who will act as TLS server? There is no=20 >> Answerer. >> >> One alternative would be to mandate the sending of an Offer when the=20 >> TCP/TLS connection is re-established. Then it would be clear who is=20 >> Offerer, and who is Answerer. >> >> Another alternative would be to say that whoever was previously=20 >> Answerer will act as TLS server. > > I'm not too fond of yet another re-INVITE being mandated, so if we=20 > will fix this issue mandating the previous answerer to be the TLS=20 > server would be my preference. Assuming that, then my follow-up question is: When you say "previous answerer", do you refer to the answerer in the lates= t Offer/Answer transaction, OR the answerer in the last Offer/Answer transa= ction that established/re-established the TCP/TLS connection (those Offer/A= nswer transactions may, or may not, be the same). >> Q2: >> >> Assume there is an Offer/Answer transaction during the session. Now,=20 >> the TCP/TLS connection is not affected by that, but the TLS roles may=20 >> change (if whoever was Offerer in the previous O/A transaction is now An= swerer). >> >> I think some wording would be needed about that also. >> >> One alternative is to say that the TLS roles may change, but that=20 >> doesn't affect the TCP/TLS connection. > > A healthy TCP/TLS connection shouldn't be affected at all, should it? Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server. >However, any potential connection re-establishment will need to monitor=20 >who was the last answerer to do the TLS initiation correctly. > >Hopefully I did understand the issue here, and added my 2 zlotys or=20 >pence or whatever, I think you did understand the issue :) Regards, Christer _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis From pkyzivat@alum.mit.edu Mon Jan 20 17:33:39 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530CE1A0255 for ; Mon, 20 Jan 2014 17:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 6nqZ6QBHbXql for ; Mon, 20 Jan 2014 17:33:37 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1AF1A0002 for ; Mon, 20 Jan 2014 17:33:37 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta12.westchester.pa.mail.comcast.net with comcast id GFoK1n0011GhbT85CRZdKb; Tue, 21 Jan 2014 01:33:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id GRZc1n00P3ZTu2S3TRZcMt; Tue, 21 Jan 2014 01:33:37 +0000 Message-ID: <52DDCE70.1090707@alum.mit.edu> Date: Mon, 20 Jan 2014 20:33:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: bfcpbis@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390268017; bh=7ll5A+qPspEbEsn9bFgJNaybSJq1hUxPXac9FfbtEdI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jGiGwzqqMEWVRRFvZm6pZWC9HtSqae6c+uJJ59cMKM6nFq5MHf6M5Q2hCshLp6ifh uR+Z2bMn6/Yre+y5AN0nmFrV1CQcL0oNVqutllkC0fJFcklqMFAwTrDGZo6/bHCbG4 9NKJb4ywTw9sZMEKL1GRdG6JfX7cGAn56UhMv/Js9yveoIhG4lxGAoFsxKxWSapuJy HAqGs7BajSZ1Qdo1FXoF97U2X3l7nnfAgV0nswjO1WmnQgiOMXeGAp29TdAs9AuQTl vW0o5rBd9KxscBdZwO97sLDgptpbEwcHkcZkrkUqebc5Qdu2wBT5ay0oAoMI6xo6T7 blZWC8JDlHlGg== Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 01:33:39 -0000 On 1/20/14 8:21 PM, Christer Holmberg wrote: > Hi, > > Some initial text proposal: > > "If the TCP connection is lost, the "active" endpoint is responsible for re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP Offers and Answers will not impact the previously negotiated TLS roles." Is the passive endpoint expected to listen for the connection attempt at all times, or when it has noticed that the old connection is lost, or only when there has been a new O/A? (It is kind of a waste to maintain a listener when you have an active connection and aren't expecting more. And it is asking for trouble, since you might get a new connection when you think the old one is still functional.) I realize this is old stuff, but I'm surprised that it didn't follow comedia about all of this, including who is active. Thanks, Paul > Regards, > > Christer > > -----Alkuperäinen viesti----- > Lähettäjä: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer Holmberg > Lähetetty: 16. tammikuuta 2014 21:36 > Vastaanottaja: Tom Kristensen > Kopio: bfcpbis@ietf.org > Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? > > > Hi Tom, > >>> I realize the following comes late in the process, and I apologize if >>> it has been discussed, but it is related to something which just has >>> recently popped up in 3GPP, and it's not addressed in the draft. >> >> Not too late, since we are still not finished! Anyway, the TCP/TLS >> connection reuse is not altered while extending BFCP to support >> unreliable transport. Any fixes now must be backwards compatible in >> some way. >> >> That said and based on what I have seen from different vendors, most >> of them still use TCP (without TLS) :) >> >> So, at least if we are changing anything to solve these issues, we >> should add an informational note indicating this is a change where >> legacy, pure RFC 4582 implementations might differ in behaviour... > > I am not suggesting to change anything - I am suggesting to specify something which is currently unspecified :) > >> By the way: How these issues was solved in 3GPP are along the lines of what you propose below? > > We have had some discussions in 3GPP, and there are some text suggestions for the upcoming meeting next week. > > However, the discussions so far have been mostly about Q2. Q1 came up on a mailing list just this week, and whill be discussed at the 3GPP meeting next week. > >>> Section 7 says the following: >>> >>> "For a TCP/TLS connection 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." >>> >>> Q1: >>> >>> Assume the TCP/TLS connection, for whatever reason, goes down. >>> >>> Now, I assume that whoever endpoint is "active" will most likely try >>> to re-establish the TCP connection. >>> >>> But, if the "active" endpoint doesn't send an Offer (i.e. it simply >>> tries to re-establish the TCP connection based on the previously >>> negotiated SDP information), who will act as TLS server? There is no >>> Answerer. >>> >>> One alternative would be to mandate the sending of an Offer when the >>> TCP/TLS connection is re-established. Then it would be clear who is >>> Offerer, and who is Answerer. >>> >>> Another alternative would be to say that whoever was previously >>> Answerer will act as TLS server. >> >> I'm not too fond of yet another re-INVITE being mandated, so if we >> will fix this issue mandating the previous answerer to be the TLS >> server would be my preference. > > Assuming that, then my follow-up question is: > > When you say "previous answerer", do you refer to the answerer in the latest Offer/Answer transaction, OR the answerer in the last Offer/Answer transaction that established/re-established the TCP/TLS connection (those Offer/Answer transactions may, or may not, be the same). > > >>> Q2: >>> >>> Assume there is an Offer/Answer transaction during the session. Now, >>> the TCP/TLS connection is not affected by that, but the TLS roles may >>> change (if whoever was Offerer in the previous O/A transaction is now Answerer). >>> >>> I think some wording would be needed about that also. >>> >>> One alternative is to say that the TLS roles may change, but that >>> doesn't affect the TCP/TLS connection. >> >> A healthy TCP/TLS connection shouldn't be affected at all, should it? > > Correct. The question is whether such Offer/Answer can affect the TCP/TLS roles - even if the TCP/TLS connection itself if not affected. That could have impact on the case in Q1, where the TCP/TLC connection goes down, and it needs to be determined who is TLS server. > >> However, any potential connection re-establishment will need to monitor >> who was the last answerer to do the TLS initiation correctly. >> >> Hopefully I did understand the issue here, and added my 2 zlotys or >> pence or whatever, > > I think you did understand the issue :) > > Regards, > > Christer > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From christer.holmberg@ericsson.com Mon Jan 20 17:44:35 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2ABF1A0282 for ; Mon, 20 Jan 2014 17:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 RdFUEpeHR3f5 for ; Mon, 20 Jan 2014 17:44:33 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCE31A0002 for ; Mon, 20 Jan 2014 17:44:32 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-0c-52ddd100c070 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 80.6E.03802.001DDD25; Tue, 21 Jan 2014 02:44:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 02:44:23 +0100 From: Christer Holmberg To: Paul Kyzivat , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPngAy768AAAq9+j4A1NzWIP//+WMA///tb0A= Date: Tue, 21 Jan 2014 01:44:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> In-Reply-To: <52DDCE70.1090707@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjS7DxbtBBsv3y1j8W3eUyWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGlbWTmAp2GFRsfP2QuYGxVb2LkYNDQsBE 4vuyyi5GTiBTTOLCvfVsXYxcHEIChxglTt7/zg6SEBJYwijR+EwJpJ5NwEKi+582SFhEIFDi 0L5pTCC2sECGxJJ/J9hASkQEMiUaJitAlPhJLDxyDGwKi4CqxL31h8DKeQV8JeYvP8gEsWo6 k8S/qVNYQBKcAjoSb5+2soLYjED3fD+1BqyBWUBc4sPB68wQdwpILNlzHsoWlXj5+B8rhK0k sWL7JUaIej2JG1OnsEHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9N zMxJLzfaxAiMg4NbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGNUlJmc+6fdiKrzG7RP8R4x32vUN3Hzv/l9atOSoko6A7GYVg87ZS0oL/whPlHSc9MCA r6ljlbOd2Zy4m6kOmq8XJs0QWbC3S32j+dJjv9lOzuDtTBJ2fMCrbVJRf1fa1aR889adm+av C2pr+jUv1Lp3F9fDJSoFIcF3ZkxUuutcsn7VtLkVdkosxRmJhlrMRcWJAGMKa5xRAgAA Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 01:44:36 -0000 Hi, >> Some initial text proposal: >> >> "If the TCP connection is lost, the "active" endpoint is responsible for= re-establishing the TCP connection. >> >> Unless a new TLS session is negotiated, subsequent SDP Offers and Answer= s will not impact the previously negotiated TLS roles." > > Is the passive endpoint expected to listen for the connection attempt at = all times, or when it has noticed that the old connection is lost, or only = when=20 > there has been a new O/A? (It is kind of a waste to maintain a listener w= hen you have an active connection and aren't expecting more.=20 > And it is asking for trouble, since you might get a new connection when y= ou think the old one is still functional.) If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or? If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection. > I realize this is old stuff, but I'm surprised that it didn't follow come= dia about all of this, including who is active. I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server. Regards, Christer > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Chris= ter=20 > Holmberg > L=E4hetetty: 16. tammikuuta 2014 21:36 > Vastaanottaja: Tom Kristensen > Kopio: bfcpbis@ietf.org > Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes d= own and is re-established? > > > Hi Tom, > >>> I realize the following comes late in the process, and I apologize=20 >>> if it has been discussed, but it is related to something which just=20 >>> has recently popped up in 3GPP, and it's not addressed in the draft. >> >> Not too late, since we are still not finished! Anyway, the TCP/TLS=20 >> connection reuse is not altered while extending BFCP to support=20 >> unreliable transport. Any fixes now must be backwards compatible in=20 >> some way. >> >> That said and based on what I have seen from different vendors, most=20 >> of them still use TCP (without TLS) :) >> >> So, at least if we are changing anything to solve these issues, we=20 >> should add an informational note indicating this is a change where=20 >> legacy, pure RFC 4582 implementations might differ in behaviour... > > I am not suggesting to change anything - I am suggesting to specify=20 > something which is currently unspecified :) > >> By the way: How these issues was solved in 3GPP are along the lines of w= hat you propose below? > > We have had some discussions in 3GPP, and there are some text suggestions= for the upcoming meeting next week. > > However, the discussions so far have been mostly about Q2. Q1 came up on = a mailing list just this week, and whill be discussed at the 3GPP meeting n= ext week. > >>> Section 7 says the following: >>> >>> "For a TCP/TLS connection 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." >>> >>> Q1: >>> >>> Assume the TCP/TLS connection, for whatever reason, goes down. >>> >>> Now, I assume that whoever endpoint is "active" will most likely try=20 >>> to re-establish the TCP connection. >>> >>> But, if the "active" endpoint doesn't send an Offer (i.e. it simply=20 >>> tries to re-establish the TCP connection based on the previously=20 >>> negotiated SDP information), who will act as TLS server? There is no=20 >>> Answerer. >>> >>> One alternative would be to mandate the sending of an Offer when the=20 >>> TCP/TLS connection is re-established. Then it would be clear who is=20 >>> Offerer, and who is Answerer. >>> >>> Another alternative would be to say that whoever was previously=20 >>> Answerer will act as TLS server. >> >> I'm not too fond of yet another re-INVITE being mandated, so if we=20 >> will fix this issue mandating the previous answerer to be the TLS=20 >> server would be my preference. > > Assuming that, then my follow-up question is: > > When you say "previous answerer", do you refer to the answerer in the lat= est Offer/Answer transaction, OR the answerer in the last Offer/Answer tran= saction that established/re-established the TCP/TLS connection (those Offer= /Answer transactions may, or may not, be the same). > > >>> Q2: >>> >>> Assume there is an Offer/Answer transaction during the session. Now,=20 >>> the TCP/TLS connection is not affected by that, but the TLS roles=20 >>> may change (if whoever was Offerer in the previous O/A transaction is n= ow Answerer). >>> >>> I think some wording would be needed about that also. >>> >>> One alternative is to say that the TLS roles may change, but that=20 >>> doesn't affect the TCP/TLS connection. >> >> A healthy TCP/TLS connection shouldn't be affected at all, should it? > > Correct. The question is whether such Offer/Answer can affect the TCP/TLS= roles - even if the TCP/TLS connection itself if not affected. That could = have impact on the case in Q1, where the TCP/TLC connection goes down, and = it needs to be determined who is TLS server. > >> However, any potential connection re-establishment will need to=20 >> monitor who was the last answerer to do the TLS initiation correctly. >> >> Hopefully I did understand the issue here, and added my 2 zlotys or=20 >> pence or whatever, > > I think you did understand the issue :) > > Regards, > > Christer > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis From pkyzivat@alum.mit.edu Tue Jan 21 06:10:49 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36B51A00D3 for ; Tue, 21 Jan 2014 06:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 es9eGtKJF8bt for ; Tue, 21 Jan 2014 06:10:47 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 997621A00D2 for ; Tue, 21 Jan 2014 06:10:47 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id GdtN1n0010ldTLk5DeAnZZ; Tue, 21 Jan 2014 14:10:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id GeAn1n0043ZTu2S01eAnEa; Tue, 21 Jan 2014 14:10:47 +0000 Message-ID: <52DE7FE6.3000203@alum.mit.edu> Date: Tue, 21 Jan 2014 09:10:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "bfcpbis@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390313447; bh=QXDKBiIl0KLYX2NCUrEvNTAMhuCHFFCrwZiCTexx9qM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JxYc2dXzlB2IHPiRde5zBZDMm8sDbYseufCJR2M61+cW81XN4+Jhbbn/TE8qrq58J AoWgjLXBLcJ1HAcMYMPGn4uuJyZ/2EF0IbF8Fz4jdylvOwQhlHYr2TgObsawM3xAUw UJ9VzMUWIl/ji+qU7mBhpCDD7TDzj9+IeXt8vHgBo/bOvX3UCJqVZrL9/b/P1CVuA+ k7Mri+zd1RKAAEx1Scqz2dX+h8Mm9rW52IOJXPEoBABNydGPqb+CerRgpEbWxPhfhu jo02OXIKQNAhWDvPeMVAtIFsY/itB7FsLZPQIRKqbTlT8fXmd5d4NYMpFAtITa+st5 MO0FaSzhTOdYQ== Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:10:50 -0000 On 1/20/14 8:44 PM, Christer Holmberg wrote: > Hi, > >>> Some initial text proposal: >>> >>> "If the TCP connection is lost, the "active" endpoint is responsible for re-establishing the TCP connection. >>> >>> Unless a new TLS session is negotiated, subsequent SDP Offers and Answers will not impact the previously negotiated TLS roles." >> >> Is the passive endpoint expected to listen for the connection attempt at all times, or when it has noticed that the old connection is lost, or only when >> there has been a new O/A? (It is kind of a waste to maintain a listener when you have an active connection and aren't expecting more. >> And it is asking for trouble, since you might get a new connection when you think the old one is still functional.) > > If a TCP connection has been established, I think it is enough to listen for the connection when it has noticed that the old connection is lost. I assume both endpoints would detect that more or less at the same time, or? > > If a TCP connection has NOT been established, one would listen only when there has been a O/A used to negotiate the TCP connection. WFM. >> I realize this is old stuff, but I'm surprised that it didn't follow comedia about all of this, including who is active. > > I am not sure I understand. Comedia IS used to indicate who is active. However, comedia is NOT used to indicate who is TLS client/server. OK. > Regards, > > Christer > > > > >> -----Alkuperäinen viesti----- >> Lähettäjä: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer >> Holmberg >> Lähetetty: 16. tammikuuta 2014 21:36 >> Vastaanottaja: Tom Kristensen >> Kopio: bfcpbis@ietf.org >> Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? >> >> >> Hi Tom, >> >>>> I realize the following comes late in the process, and I apologize >>>> if it has been discussed, but it is related to something which just >>>> has recently popped up in 3GPP, and it's not addressed in the draft. >>> >>> Not too late, since we are still not finished! Anyway, the TCP/TLS >>> connection reuse is not altered while extending BFCP to support >>> unreliable transport. Any fixes now must be backwards compatible in >>> some way. >>> >>> That said and based on what I have seen from different vendors, most >>> of them still use TCP (without TLS) :) >>> >>> So, at least if we are changing anything to solve these issues, we >>> should add an informational note indicating this is a change where >>> legacy, pure RFC 4582 implementations might differ in behaviour... >> >> I am not suggesting to change anything - I am suggesting to specify >> something which is currently unspecified :) >> >>> By the way: How these issues was solved in 3GPP are along the lines of what you propose below? >> >> We have had some discussions in 3GPP, and there are some text suggestions for the upcoming meeting next week. >> >> However, the discussions so far have been mostly about Q2. Q1 came up on a mailing list just this week, and whill be discussed at the 3GPP meeting next week. >> >>>> Section 7 says the following: >>>> >>>> "For a TCP/TLS connection 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." >>>> >>>> Q1: >>>> >>>> Assume the TCP/TLS connection, for whatever reason, goes down. >>>> >>>> Now, I assume that whoever endpoint is "active" will most likely try >>>> to re-establish the TCP connection. >>>> >>>> But, if the "active" endpoint doesn't send an Offer (i.e. it simply >>>> tries to re-establish the TCP connection based on the previously >>>> negotiated SDP information), who will act as TLS server? There is no >>>> Answerer. >>>> >>>> One alternative would be to mandate the sending of an Offer when the >>>> TCP/TLS connection is re-established. Then it would be clear who is >>>> Offerer, and who is Answerer. >>>> >>>> Another alternative would be to say that whoever was previously >>>> Answerer will act as TLS server. >>> >>> I'm not too fond of yet another re-INVITE being mandated, so if we >>> will fix this issue mandating the previous answerer to be the TLS >>> server would be my preference. >> >> Assuming that, then my follow-up question is: >> >> When you say "previous answerer", do you refer to the answerer in the latest Offer/Answer transaction, OR the answerer in the last Offer/Answer transaction that established/re-established the TCP/TLS connection (those Offer/Answer transactions may, or may not, be the same). >> >> >>>> Q2: >>>> >>>> Assume there is an Offer/Answer transaction during the session. Now, >>>> the TCP/TLS connection is not affected by that, but the TLS roles >>>> may change (if whoever was Offerer in the previous O/A transaction is now Answerer). >>>> >>>> I think some wording would be needed about that also. >>>> >>>> One alternative is to say that the TLS roles may change, but that >>>> doesn't affect the TCP/TLS connection. >>> >>> A healthy TCP/TLS connection shouldn't be affected at all, should it? >> >> Correct. The question is whether such Offer/Answer can affect the TCP/TLS roles - even if the TCP/TLS connection itself if not affected. That could have impact on the case in Q1, where the TCP/TLC connection goes down, and it needs to be determined who is TLS server. >> >>> However, any potential connection re-establishment will need to >>> monitor who was the last answerer to do the TLS initiation correctly. >>> >>> Hopefully I did understand the issue here, and added my 2 zlotys or >>> pence or whatever, >> >> I think you did understand the issue :) >> >> Regards, >> >> Christer >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From 2mkristensen@gmail.com Thu Jan 23 02:48:49 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1725F1A0435 for ; Thu, 23 Jan 2014 02:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 KqRUtu8KJV-5 for ; Thu, 23 Jan 2014 02:48:46 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D3D881A03F0 for ; Thu, 23 Jan 2014 02:48:45 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id i8so2169274qcq.22 for ; Thu, 23 Jan 2014 02:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HI2Ox6TWL0Ccn2gM0q6rAoeFgLIvLlPZLFQBLiylbFk=; b=qyB+RTtgZ3mCudaWyo0Ps5KI8x41X3SBJFdDnqFVQozYG8mYIvasu7UfrBH/NXWjBV FlYH3B7QJFhXP+GmNdrTFRB2/dxmyOwxTl4EM3KUQRRd72kGrF1azHvrZxVXTGykC83q yZpXTYP6cqhRSFQn5mVW4M4Ox29Wf5us8t53sUagJzYS+j3WOM2YO4LnbaX3yDBtokAE PsC3NNdGRaG87Y6r0OEK1Y3gJjR3ULteg2l/4n9lRwddl2ZGCDk2W4RUZhE5RHMvnJE+ KGRrWDsT5bPOA77lopBH5083qDs3dgES3i5imF/yaOjm2cjCB/FYIFNXAbZIL7en2m+S HYXA== MIME-Version: 1.0 X-Received: by 10.140.31.247 with SMTP id f110mr9695850qgf.58.1390474124792; Thu, 23 Jan 2014 02:48:44 -0800 (PST) Received: by 10.229.2.69 with HTTP; Thu, 23 Jan 2014 02:48:44 -0800 (PST) In-Reply-To: <52DE7FE6.3000203@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu> Date: Thu, 23 Jan 2014 11:48:44 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113a9c024716f304f0a0fc42 Cc: "bfcpbis@ietf.org" , Paul Kyzivat , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 10:48:49 -0000 --001a113a9c024716f304f0a0fc42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Christer, not only did you discover the issue - you also provided the fix (and text for it). That solves what is currently missing in the draft and in RFC 4582. I will add your text, or at least a very similar version, to the upcoming version of the draft. -- Tom On 21 January 2014 15:10, Paul Kyzivat wrote: > On 1/20/14 8:44 PM, Christer Holmberg wrote: > >> Hi, >> >> Some initial text proposal: >>>> >>>> "If the TCP connection is lost, the "active" endpoint is responsible >>>> for re-establishing the TCP connection. >>>> >>>> Unless a new TLS session is negotiated, subsequent SDP Offers and >>>> Answers will not impact the previously negotiated TLS roles." >>>> >>> >>> Is the passive endpoint expected to listen for the connection attempt a= t >>> all times, or when it has noticed that the old connection is lost, or o= nly >>> when >>> there has been a new O/A? (It is kind of a waste to maintain a listener >>> when you have an active connection and aren't expecting more. >>> And it is asking for trouble, since you might get a new connection when >>> you think the old one is still functional.) >>> >> >> If a TCP connection has been established, I think it is enough to listen >> for the connection when it has noticed that the old connection is lost. = I >> assume both endpoints would detect that more or less at the same time, o= r? >> >> If a TCP connection has NOT been established, one would listen only when >> there has been a O/A used to negotiate the TCP connection. >> > > WFM. > > > I realize this is old stuff, but I'm surprised that it didn't follow >>> comedia about all of this, including who is active. >>> >> >> I am not sure I understand. Comedia IS used to indicate who is active. >> However, comedia is NOT used to indicate who is TLS client/server. >> > > OK. > > > Regards, >> >> Christer >> >> >> >> >> -----Alkuper=E4inen viesti----- >>> L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Chr= ister >>> Holmberg >>> L=E4hetetty: 16. tammikuuta 2014 21:36 >>> Vastaanottaja: Tom Kristensen >>> Kopio: bfcpbis@ietf.org >>> Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes >>> down and is re-established? >>> >>> >>> Hi Tom, >>> >>> I realize the following comes late in the process, and I apologize >>>>> if it has been discussed, but it is related to something which just >>>>> has recently popped up in 3GPP, and it's not addressed in the draft. >>>>> >>>> >>>> Not too late, since we are still not finished! Anyway, the TCP/TLS >>>> connection reuse is not altered while extending BFCP to support >>>> unreliable transport. Any fixes now must be backwards compatible in >>>> some way. >>>> >>>> That said and based on what I have seen from different vendors, most >>>> of them still use TCP (without TLS) :) >>>> >>>> So, at least if we are changing anything to solve these issues, we >>>> should add an informational note indicating this is a change where >>>> legacy, pure RFC 4582 implementations might differ in behaviour... >>>> >>> >>> I am not suggesting to change anything - I am suggesting to specify >>> something which is currently unspecified :) >>> >>> By the way: How these issues was solved in 3GPP are along the lines of >>>> what you propose below? >>>> >>> >>> We have had some discussions in 3GPP, and there are some text >>> suggestions for the upcoming meeting next week. >>> >>> However, the discussions so far have been mostly about Q2. Q1 came up o= n >>> a mailing list just this week, and whill be discussed at the 3GPP meeti= ng >>> next week. >>> >>> Section 7 says the following: >>>>> >>>>> "For a TCP/TLS connection 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." >>>>> >>>>> Q1: >>>>> >>>>> Assume the TCP/TLS connection, for whatever reason, goes down. >>>>> >>>>> Now, I assume that whoever endpoint is "active" will most likely try >>>>> to re-establish the TCP connection. >>>>> >>>>> But, if the "active" endpoint doesn't send an Offer (i.e. it simply >>>>> tries to re-establish the TCP connection based on the previously >>>>> negotiated SDP information), who will act as TLS server? There is no >>>>> Answerer. >>>>> >>>>> One alternative would be to mandate the sending of an Offer when the >>>>> TCP/TLS connection is re-established. Then it would be clear who is >>>>> Offerer, and who is Answerer. >>>>> >>>>> Another alternative would be to say that whoever was previously >>>>> Answerer will act as TLS server. >>>>> >>>> >>>> I'm not too fond of yet another re-INVITE being mandated, so if we >>>> will fix this issue mandating the previous answerer to be the TLS >>>> server would be my preference. >>>> >>> >>> Assuming that, then my follow-up question is: >>> >>> When you say "previous answerer", do you refer to the answerer in the >>> latest Offer/Answer transaction, OR the answerer in the last Offer/Answ= er >>> transaction that established/re-established the TCP/TLS connection (tho= se >>> Offer/Answer transactions may, or may not, be the same). >>> >>> >>> Q2: >>>>> >>>>> Assume there is an Offer/Answer transaction during the session. Now, >>>>> the TCP/TLS connection is not affected by that, but the TLS roles >>>>> may change (if whoever was Offerer in the previous O/A transaction is >>>>> now Answerer). >>>>> >>>>> I think some wording would be needed about that also. >>>>> >>>>> One alternative is to say that the TLS roles may change, but that >>>>> doesn't affect the TCP/TLS connection. >>>>> >>>> >>>> A healthy TCP/TLS connection shouldn't be affected at all, should it? >>>> >>> >>> Correct. The question is whether such Offer/Answer can affect the >>> TCP/TLS roles - even if the TCP/TLS connection itself if not affected. = That >>> could have impact on the case in Q1, where the TCP/TLC connection goes >>> down, and it needs to be determined who is TLS server. >>> >>> However, any potential connection re-establishment will need to >>>> monitor who was the last answerer to do the TLS initiation correctly. >>>> >>>> Hopefully I did understand the issue here, and added my 2 zlotys or >>>> pence or whatever, >>>> >>> >>> I think you did understand the issue :) >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> bfcpbis mailing list >>> bfcpbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/bfcpbis >>> _______________________________________________ >>> bfcpbis mailing list >>> bfcpbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/bfcpbis >>> >>> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a113a9c024716f304f0a0fc42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Christer, not only did you discover the issue - you= also provided the fix (and text for it). That solves what is currently mis= sing in the draft and in RFC 4582.

I will add your text,= or at least a very similar version, to the upcoming version of the draft.<= div>
-- Tom

On 21 January 2014 15:10, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 1/20/14 8:44 PM, Christ= er Holmberg wrote:
Hi,

Some initial text proposal:

"If the TCP connection is lost, the "active" endpoint is res= ponsible for re-establishing the TCP connection.

Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles."

Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en
there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more.
And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.)

If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection.

WFM.


I realize this is old stuff, but I'm surprised that it didn't follo= w comedia about all of this, including who is active.

I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server.

OK.


Regards,

Christer




-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer<= br> Holmberg
L=E4hetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: bfcpbis@ietf.o= rg
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established?


Hi Tom,

I realize the following comes late in the process, and I apologize
if it has been discussed, but it is related to something which just
has recently popped up in 3GPP, and it's not addressed in the draft.

Not too late, since we are still not finished! Anyway, the TCP/TLS
connection reuse is not altered while extending BFCP to support
unreliable transport. Any fixes now must be backwards compatible in
some way.

That said and based on what I have seen from different vendors, most
of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we
should add an informational note indicating this is a change where
legacy, pure RFC 4582 implementations might differ in behaviour...

I am not suggesting to change anything - I am suggesting to specify
something which is currently unspecified :)

By the way: How these issues was solved in 3GPP are along the lines of what= you propose below?

We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week.

However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week.

Section 7 says the following:

"For a TCP/TLS connection 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."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely = try
to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it = simply
tries to re-establish the TCP connection based on the previously
negotiated SDP information), who will act as TLS server? There is no
Answerer.

One alternative would be to mandate the sending of an Offer when the
TCP/TLS connection is re-established. Then it would be clear who is
Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously
Answerer will act as TLS server.

I'm not too fond of yet another re-INVITE being mandated, so if we
will fix this issue mandating the previous answerer to be the TLS
server would be my preference.

Assuming that, then my follow-up question is:

When you say "previous answerer", do you refer to the answerer in= the latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer transaction that established/re-established the TCP/TLS connection (tho= se Offer/Answer transactions may, or may not, be the same).


Q2:

Assume there is an Offer/Answer transaction during the session. Now,
the TCP/TLS connection is not affected by that, but the TLS roles
may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that
doesn't affect the TCP/TLS connection.

A healthy TCP/TLS connection shouldn't be affected at all, should it?

Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server.

However, any potential connection re-establishment will need to
monitor who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or
pence or whatever,

I think you did understand the issue :)

Regards,

Christer

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



--
= # Cisco =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/tel= epresence/
## tomkrist@cisco.com =A0| =A0http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--001a113a9c024716f304f0a0fc42-- From eckelcu@cisco.com Fri Jan 24 14:42:11 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432C51A01E0 for ; Fri, 24 Jan 2014 14:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.736 X-Spam-Level: X-Spam-Status: No, score=-12.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 f923IVilCEz2 for ; Fri, 24 Jan 2014 14:42:08 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4468F1A010A for ; Fri, 24 Jan 2014 14:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11393; q=dns/txt; s=iport; t=1390603327; x=1391812927; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IHt2V4zgzbYTpTDdrKa7C2Gcc92UKvbna5QwpPPrcPU=; b=QtJ3yNOX8IVvfxFcm8cR55TaKepElYV6vlITamynaHJuUfRi+lPdQ6zz AxYQCSjZXqjlmmJ/JjNuTPpllO34fuIKvzTDS+bNTuTrDZQ4OytsKVnnE sBK2QMUo1YvgEAoBj9iDLwHWC7nlg/zbyLmOsbZX5GjygTgK0UqAWuI0x A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAO/r4lKtJV2Z/2dsb2JhbABYAoMMOFa7b0+BCBZ0giUBAQEDAQEBASRHCwULAgEIGBYYJwslAgQBDQUbh2IIDckgEwSOSkIHEguEGwEDmCeSHoMtgWoHFyI X-IronPort-AV: E=Sophos;i="4.95,715,1384300800"; d="scan'208";a="299576065" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jan 2014 22:41:48 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0OMflG7021895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 22:41:48 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 16:41:47 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Mary Barnes Thread-Topic: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08 Thread-Index: AQHPGVV2eo89ZoxirUulY9xQVEy7Ww== Date: Fri, 24 Jan 2014 22:41:46 +0000 Message-ID: References: <52D7F10B.5070401@cisco.com> In-Reply-To: <52D7F10B.5070401@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.123.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8BEB791B0F740C41ADAEA77E72166D94@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "bfcpbis@ietf.org" , "bfcpbis-chairs@tools.ietf.org" , "draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org" Subject: Re: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:42:11 -0000 On 1/16/14 6:47 AM, "Tom Kristensen (tomkrist)" wrote: >I went through and commented on this in my favourite editor (Emacs >obviously), but forgot to paste it in and respond until now. I have >updated my comments to align with Charles Eckel's recent response too. Thanks for that. More inline. > >Inline below. > > >On 12/18/2013 11:38 PM, Mary Barnes wrote: > > Hi all, > > > > I have agreed to shepherd this document on behalf of the WG. I have > > reviewed this document in preparation for doing the PROTO write-up. > > > > I think the document needs a bit of work before it's ready to progress. > > I have a few questions/comments, as well as editorial nits which I >think > > would improve readability and ease of understanding. > > > > _General Comments:_ > > > > The document requires an SDP directorate review prior to progressing. I > > have requested that of the MMUSIC WG chairs. At the time of this >review, > > Ali Begen has agreed to do that review. > >Yes, I have commented on his issues on the MMUSIC mailing list. > > > _Comments/Questions:_ > > > > 1) I am slightly puzzled by the following in section 3: > > > > m=3D ... > > > > Section 5.14 of RFC 4566 states the following: > > > > m=3D ... > > > > So, this looks to be like the RFC 2327 ABNF for m lines is being used > > (rather than RFC 4566 which is the normative SDP specification for this > > document)? > > > > m=3D > > > > Note, that the IANA registration section appears to be based on RFC >4566 > > as the values are specified as being applicable to the 'pro to' field. > > So, my guess is that this is a bug from RFC 4583. > >Yes, an inherited bug that will be fixed without complications. > > > 2) Section 3, next to last paragraph. I think it would be more precise > > to reword this as: > > > > OLD: > > > > The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' > > lines SHOULD contain a single "*" character. > > > > NEW: > > > > The fmt (format) list is not applicable to BFCP. The fmt list of 'm' > > lines in the case of any proto field value related to BFCP SHOULD > > contain a single "*" character. If the the fmt list contains any other > > value it is ignored. > >Agree. That is a more precise wording for the fmt part. > >Charles Eckel touched upon this as well and was okay with this, >especially if there are known reasons and/or implementations that >already do otherwise. Well, once upon a time there was a SIP based >product from a (large french) vendor that used 0 (I think) - don't think >that product is still maintained. But it might be out there in the wild >still. Will fix. > > > 3) Section 4, paragraph above table 1, 1st sentence. I suggest for > > clarification to make the following change: > > > > OLD > > > > MUST include one in the corresponding media description > > > > NEW > > > > MUST include a 'floorctrl' attribute in the corresponding media >description > >Fine with me, will update. > > > 4) Section 4, 3rd paragraph from the end: > > > > "Endpoints that use the offer/answer model to establish BFCP >connections > > MUST support the 'floorctrl' attribute. A floor control server acting >as > > an offerer or as an answerer SHOULD include the attribute in its >session > > descriptions." > > > > Since the latter is a SHOULD what happens if the attribute is NOT > > included? Under what circumstances is it okay for the server not to > > include it? IF bad things happen if it's not included, then this > > probably ought to be a MUST. Or, if there's reasonable situations in > > which the floor control server doesn't include the attribute, those > > should be explained or at least an example provided. > >The default behaviour/assumption if the 'floorctrl' attribute is not >used is explained in the paragraph below, i.e. offerer =3D=3D client and >answerer =3D=3D server. > >I agree that the formulation "is not used in an offer/answer exchange" >might point towards usage other than offer/answer, but the sentence >continues with explaining what the offerer and answerer will assume. So >fine with me. OK? > >If not, I will not object using MUST here - as also proposed by Charles >Eckel. > > > 5) Section 7. > > > > a) 1st paragraph after ABNF. "..versions SHOULD be integers..". I would > > think that ought to be a MUST. What happens if the token isn't an > > integer and what was the motivation for not defining the version as an > > integer versus a token? If non-integers can be used, the scope of what > > is acceptable for the field needs to be explained. > >I agree, this will be upgraded to a MUST if people doesn't object. > >And if this will ever change non-integer versions must be specified in >another draft/RFC and this draft probably have to be updated as well - >since semantics for specific versions are specified later in Section 7. > > > b) 2nd paragraph after ABNF. I can see why supporting the version is a > > SHOULD (since it is a new field) and RFC 4583 did not define a version, > > but I think that needs to be more clearly documented and I think it > > ought to be REQUIRED for anyone that is using UDP and obviously, older > > implementations of TCP (i.e., those only compliant to RFC 4583 and not > > this document) ought to be the only ones that aren't using the version > > field. > >Is it sufficient to merge in the following sentence after the second >sentence in that paragraph? >"However, endpoints that supports RFCXXXX, and not only the RFC 4583 >subset, is REQUIRED to support and use the 'bfcpver' attribute." >(Or something along those lines). Works for me, though should be "endpoints =8A are". > >A complicating factor here is that some pre-standard implementations, as >experienced on recent SIPit and SuperOp test events, is out there and is >not using the 'bfcpver' attribute. However, demanding that >implementations following the new RFC from this draft have to use the >version attribute should be perfectly fine. Agreed, and stating that when omitted the default is "1" for TCP and "2" for UDP addresses the problem of pre-standard UDP implementations as well. > > > c) last paragraph. Related to b, I would think that in the case of > > unreliable transports, it's not that an endpoint MUST "assume". An > > endpoint MUST "use" and signal a version number of 2. In the case of a > > reliable transport, if the endpoint does not signal a > > bfcpversion-attribute, then the floor control server MUST use a value >of > > 1. I'm recalling a fair amount of mailing list discussion on this one, > > so if you can point to the thread where this text was agreed, I can let > > this one go. I still think it's not specified quite right, but I can > > live with it. > >I can't find too much discussion about this, but I agree that the word >"assume" is not good here. What about reformulating this last paragraph >to: > >"If a 'bfcpver' attribute is not present, default values are based on >the transport specified in the m-line (Section 3). When used over an >unreliable transport, an endpoint MUST use a value of "2", and when used >over a reliable transport, an endpoint MUST use a value of "1". This is >in line with the definition of the Version field in [8]." > >Any better? Better, but how about: "If a 'bfcpver' attribute is not present, default values are inferred from the transport specified in the m-line (Section 3). In accordance with definition of the Version field in [8], when used over a reliable transport the default value is "1", and when used over an unreliable transport the default value is "2". > > > 6) Section 8. 1st sentence. I think this should be a "can use TCP or > > UDP" and not a "may use TCP or UDP". Note, there is the perennial >debate > > with regards to whether something is normative even when it's not CAPS. > > I prefer to just use a different word to remove any confusion, > > particularly when a different word is actually more correct. > >Well explained, the change is fine with me. > > > 7) Section 8.1, 4th paragraph, 1st sentence and last sentence. I think > > the two "SHOULD generate and offer" ought to be a MUST generate an >offer > > OR you need to specify the circumstances under which a client would not > > generate an offer. > >OK > > > 8) Section 9, 1st paragraph. You're going to have to be more specific > > about the potential mechanisms for authentication - at least provide an > > example of mechanisms - i.e., I don't think "some mechanism" will fly > > with the SecDir folks. > >Too bad, since this is inherited from RFC 4583 - but of course that text >wasn't perfect ;) >Anyway, isn't the mechanisms meant here mentioned in the paragraphs >below? If so, might extending to "using some mechanism, as explained >below" be a valid solution in front of the SecDir review? > >Or as Charles Eckel proposed, pointing towards TLS/DTLS as the preferred >mechanism, but other mechanisms exists but are outside the scope of this >document. This still works for me :) Cheers, Charles > > > 9) Section 11, 2nd paragraph. I think that the assumes in the following > > statement needs to be a required. I suggest the following change: > > > > OLD > > > > BFCP assumes that an initial integrity-protected channel is used to > > exchange... > > > > NEW > > > > An initial integrity-protected channel is REQUIRED for BFCP to >exchange... > >Yes, I'll adopt that one. No assumption, we will require! > > > 10) Related to item 7, this list of changes has no mention of the new > > "bfcpver" attribute. That definitely should be on this list. > >Indeed! It's missing since it arrived late, but that's just a poor >excuse... > > > > _Editorial nits:_ > > > > 1) Introduction. "These data includes..." -> "This data includes...." > > (data is now grammatically considered to be a singular noun). > >OK > > > 2) Section 3. 1st paragraph after the indented text. This could be > > written more concisely (and per technical doc standards not as the 1st > > person) as follows (and per comment 1) above, I think this should be >the > > 'proto' field: > > > > OLD: > > > > We define four new values for the transport field: > > > > NEW: > > > > This document defines four values for the proto field: > >OK > > > 3) Section 5. I suggest the following change: > > > > OLD: > > > > We define the 'confid' and the 'userid' SDP media-level attributes. > > > > NEW: > > > > This document defines two SDP media-level attributes: 'confid' and >'userid'. > >OK > > > 4) Section 6. I suggest the following change: > > > > OLD: > > > > We define the 'floorid' SDP media-level attribute. > > > > NEW: > > > > This document defines the 'floorid' SDP media-level attribute. > >OK > > > 5) Section 13. I found this really, really hard to read. I suggest you > > use a bulleted or numbered list versus this hanging list style. > >Sure, I'll tweak the XML curses and make it more readable. > > >-- Tom >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From georgehanes@hushmail.com Thu Jan 30 14:05:10 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4461A04DB for ; Thu, 30 Jan 2014 14:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_NEUTRAL=0.112, SPF_PASS=-0.001] autolearn=ham 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 Engfb2yJLjg0 for ; Thu, 30 Jan 2014 14:05:07 -0800 (PST) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 439941A04B2 for ; Thu, 30 Jan 2014 14:05:07 -0800 (PST) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 0CA1D402E9 for ; Thu, 30 Jan 2014 22:05:04 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2014 22:05:03 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D5A686018A; Thu, 30 Jan 2014 22:05:03 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 30 Jan 2014 17:05:03 -0500 To: bfcpbis@ietf.org From: georgehanes@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140130220503.D5A686018A@smtp.hushmail.com> Subject: [bfcpbis] Be cautious of this computer science conference X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:10:53 -0000 Be cautious of this computer science conference If you have any thought of attending the world’s biggest f-a-k-e conference in computer science http://www.world-academy-of-science.org you should visit any websites below https://sites.google.com/site/worlddump1 or https://sites.google.com/site/dumpconf https://sites.google.com/site/moneycomp1 https://sites.google.com/site/worlddump4 The organizer of this conference is H-amid A-rabnia http://www.cs.uga.edu/~hra a professor from University of Georgia, Athens, US. He already earned millions of dollars from the registration fee. He recently started a new conference CSCI due to his hunger for money http://www.americancse.org He did not reveal the reviews and reviewers' information for all the papers he received, despite repeated requests and challenges. The reason for his failure is there are no reviews and reviewers and he just cheated the research community for more than a decade by announcing that each draft paper is reviewed by two experts. We challenge him to publish these details at the conference website. Where are your experts? Where are your reviews? Soon he comes up with a story announcing that he lost all the information having reviews and reviewers because of computer crash or theft. DBLP stopped indexing these conferences since 2011 and displayed an explicit message; "The DBLP Advisory Board decided to discontinue indexing of this conference series". Visit http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html as a sample. He was forced to remove his name, the university of Georgia name, and university of Georgia email address from the conference’s contact page because the University has banned him from doing that. Do not spoil your resume by publishing in this conference. Apologies for posting to multiple mailing lists. Spreading the news is the only way to stop this conference from harming innocent researchers. Respectfully, Many researchers cheated by these conferences