From tomkrist@cisco.com Mon Dec 2 00:31:52 2013 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 EBF911AE459 for ; Mon, 2 Dec 2013 00:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 aa3YnRwxaYNd for ; Mon, 2 Dec 2013 00:31:51 -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 5EACB1AE451 for ; Mon, 2 Dec 2013 00:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5619; q=dns/txt; s=iport; t=1385973108; x=1387182708; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=n0e7eHsNghjVGQjmBCaI1zgIiQ1CqiEWw0ZLEpG4+KA=; b=gfsgCG4gLDdSjBJRIVK71MR8DK9DmLtfFYML1JfL4tQ3DT9pNHuyx2GN KczoViXdypWkQTn+Paelh/0nv1Qy7Lqc8ACY740pY6e1OxXTriHI54Xd+ Em3TUBgA1knfe2dS0Kc41uNCepUrM62a3A1/t3B16pE3Vu5rPmHpe+XRi w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQFABNFnFKQ/khM/2dsb2JhbABZgwe5YoEgFm0HgiUBAQEhCgsBBTAGCwwwNAJMDQEHAQGHfb8mjwiEOgOUMYNjhkWLToMqOw X-IronPort-AV: E=Sophos;i="4.93,809,1378857600"; d="scan'208";a="925830" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 02 Dec 2013 08:31:47 +0000 Received: from [10.61.205.159] ([10.61.205.159]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB28Vevv015656; Mon, 2 Dec 2013 08:31:42 GMT Message-ID: <529C456D.60508@cisco.com> Date: Mon, 02 Dec 2013 09:31:41 +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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Joerg Ott Subject: [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, 02 Dec 2013 08:31:53 -0000 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) -- Tom -------- 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. See below for the comments and some suggestions. I don't think the document is ready for any IESG steps yet. But I also don't think it's going to take long to get it there. Cheers, Jörg 5.1. General SHOULD -> MUST be cleared by the sender When moving from a 16- or 32-bit "value" to an unsigned integer, the byte order must be specified. 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? 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? 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? 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? 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) 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. 6.2.3 Fragmentation Is there any guidance on transmitting fragments? (any pacing?) 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. 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. 8.3.2. T2 is unclear 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) 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. Appendix A: Wouldn't the monoticity of the transaction IDs become clearer if increments or 1 in numbers were used? From mary.ietf.barnes@gmail.com Wed Dec 18 14:38:08 2013 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 5CF761AD6A4 for ; Wed, 18 Dec 2013 14:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_LIST=2.3, 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 SFnndJeu0lAT for ; Wed, 18 Dec 2013 14:38:06 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id D31AB1A8028 for ; Wed, 18 Dec 2013 14:38:05 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so1363492wid.9 for ; Wed, 18 Dec 2013 14:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4z7dBZXo08sgzDLz23qV6V2VBiirUHeIYvxJyqpynJM=; b=yJB4Ef8s8U2VEhSJDHZbgorlIHrnNDDDOl22heopECHdrP5SqOr1HQ69xITjfjpVud WlFNTbOgll2WdPwP3PLqWrqPBkA1+cUDy4blP5mCQyF9loPNGYv49ogtp7VPp+dLl5kG W5WqIrwHqcNYC7u/H11EAAaTF5U1mUsrF28FUeWcc19o2q2zHhKcHuMsDtr74CphlBrt isZ7OFvuliQgb916Od63CFkXXLrf2IbjIon35LqoY1pGzizpesyV65yjiyJuixXgvJD0 x1E+9TjpgekeMx8pHCWp4efu3NSZyiLM9iS0Qr7WgxaJv8N9AwaJC/5VSRCzfx7xAHeW cxKA== MIME-Version: 1.0 X-Received: by 10.180.13.170 with SMTP id i10mr2418349wic.36.1387406283791; Wed, 18 Dec 2013 14:38:03 -0800 (PST) Received: by 10.216.172.9 with HTTP; Wed, 18 Dec 2013 14:38:03 -0800 (PST) Date: Wed, 18 Dec 2013 16:38:03 -0600 Message-ID: From: Mary Barnes To: "bfcpbis@ietf.org" Content-Type: multipart/alternative; boundary=001a11c242e0b464cf04edd6b2eb Cc: Richard Barnes , draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org, "bfcpbis-chairs@tools.ietf.org" Subject: [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: Wed, 18 Dec 2013 22:38:08 -0000 --001a11c242e0b464cf04edd6b2eb Content-Type: text/plain; charset=ISO-8859-1 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. *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. 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. 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 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. 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. 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. 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. 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. 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. 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. 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... 10) Related to item 7, this list of changes has no mention of the new "bfcpver" attribute. That definitely should be on this list. *Editorial nits:* 1) Introduction. "These data includes..." -> "This data includes...." (data is now grammatically considered to be a singular noun). 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: 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'. 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 use a bulleted or numbered list versus this hanging list style. --001a11c242e0b464cf04edd6b2eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I have agreed to shepherd this = document on behalf of the WG. =A0I have reviewed this document in preparati= on for doing the PROTO write-up. =A0

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

General Comments:

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

Comments/Questions:

1) I am s= lightly puzzled by the following in section 3:=A0

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

S= ection =A05.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= being used (rather than RFC 4566 which is the normative SDP specification = for this document)? =A0

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. =A0So, =A0my guess is that this is a bug from R= FC 4583. =A0=A0


2) Section 3, next to last paragrap= h. I think it would be more precise to reword this as:

OLD:

=A0 =A0 The fmt (format) list is ignored for BFCP. = =A0The fmt list of BFCP 'm' lines SHOULD contain a single "*&q= uot; character.

NEW:=A0

=A0 =A0The fmt (format) list is not = applicable to BFCP. =A0 The fmt list of 'm' lines in the case of an= y proto field value related to BFCP SHOULD contain a single "*" c= haracter. =A0If the the fmt list contains any other value it is ignored.=A0=


3) =A0Section 4, paragraph above table = 1, 1st sentence. =A0I suggest for clarification to make the following chang= e:

OLD

=A0 =A0 MUST include one in th= e corresponding media description

NEW

=A0 =A0 MUST include a 'floorctrl= 9; attribute in the corresponding media description


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

= =A0 =A0 "Endpoints that use the offer/answer model to establish BFCP c= onnections MUST support the 'floorctrl' attribute. =A0A floor contr= ol server acting as an offerer or as an answerer SHOULD include the attribu= te 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? =A0 =A0IF bad things happen if it's not included, then this p= robably ought to be a MUST. =A0 Or, if there's reasonable situations in= which the floor control server doesn't include the attribute, those sh= ould be explained or at least an example provided.=A0


5) =A0Section =A07. =A0

a) =A01st paragraph after ABNF. =A0"..versions SHOULD be integer= s..". =A0 I would think that ought to be a MUST. =A0What happens if th= e token isn't an integer and what was the motivation for not defining t= he version as an integer versus a token? =A0 If non-integers can be used, t= he scope of what is acceptable for the field needs to be explained.=A0

b) 2nd paragraph after ABNF. =A0I 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 i= mplementations 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= . =A0

c) last paragraph. =A0Related to b, I would think that in= the case of unreliable transports, it's not that an endpoint MUST &quo= t;assume". =A0An endpoint MUST "use" and signal a version nu= mber of 2. =A0 In the case of a reliable transport, if the endpoint does no= t signal a bfcpversion-attribute, then the floor control server MUST use a = value of 1. =A0 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. =A0I still think it's not specified quite right,= but I can live with it.=A0


6) Section 8. =A01st sentence. =A0I= 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 w= hether something is normative even when it's not CAPS. =A0I prefer to j= ust use a different word to remove any confusion, particularly when a diffe= rent word is actually more correct.=A0


7) Section 8.1, =A04th paragraph, 1= st sentence and last sentence. =A0I think the two "SHOULD generate and= offer" ought to be a MUST generate an offer OR you need to specify th= e circumstances under which a client would not generate an offer. =A0


8) Section 9, 1st paragraph. =A0You'= ;re going to have to be more specific about the potential mechanisms for au= thentication - at least provide an example of mechanisms - i.e., I don'= t think "some mechanism" will fly with the SecDir folks.=A0


9) Section 11, 2nd paragraph. =A0I thin= k that the assumes in the following statement needs to be a required. =A0I = suggest the following change:

OLD

=A0 BFC= P assumes that an initial integrity-protected channel is used to exchange..= .

NEW

=A0An initial integrity-protected channe= l is REQUIRED for BFCP to exchange...=A0


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


Editorial nits:

1) Introduction. =A0"These data includes..." -> "This da= ta includes...." =A0(data is now grammatically considered to be a sing= ular noun). =A0

2) Section 3. =A01st paragraph after the indented text. =A0Th= is 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 b= e the 'proto' field:

OLD: =A0 =A0

=A0 =A0 =A0We define four n= ew values for the transport field:

NEW:=A0

=A0 =A0 =A0 This document defines four values for the proto field:

3) Section 5. =A0I suggest the following change:

OLD:

=A0 =A0 =A0We define the 'confi= d' and the 'userid' SDP media-level attributes.

NEW:

=A0 =A0This document defines two SDP media-level at= tributes: 'confid' and 'userid'.


4) Section 6. I suggest the following c= hange:

OLD:=A0

=A0 =A0 We define the '= ;floorid' SDP media-level attribute.

NEW: =A0

=A0 =A0This document defines the 'floorid' SDP media-level= attribute.=A0

5) Section 13. =A0I found this really, really hard to read. = =A0I suggest you use a bulleted or numbered list versus this hanging list s= tyle.=A0


--001a11c242e0b464cf04edd6b2eb-- From mary.ietf.barnes@gmail.com Thu Dec 19 12:27:25 2013 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 0A11E1AE7AE for ; Thu, 19 Dec 2013 12:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_LIST=2.3, 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 IG1BfZaPYUaJ for ; Thu, 19 Dec 2013 12:27:22 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id F226B1AE7AD for ; Thu, 19 Dec 2013 12:27:21 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bz8so2775420wib.5 for ; Thu, 19 Dec 2013 12:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=EgXOSUIVTB4JpkOjQUDbvmwd3s/eiS8uWu8lPhEj67s=; b=KMQ4+wifTR6voyi6RYX/z51U8eh4w/nWv+zpvUuGcCZ/e63BbkYDrHzud65EKYLInz n8IHrQkH65iSQFx1elBiRhIovkxxPn3X4RxLwT52s+ri5QPiIHjG+8my73l7BM+4OZrj Y3oviccKm0Ww3LOpvTE813NWkFMBbcnGwD/2JngQEhcfPMMg6nGAzkN34xJY5ojFGfB+ jH+rpUjbC/DSushmQp5qi61rVjgimUOqgLEbWAynKhEZUBzdvhN3sfiEc1LfcigQn3lC 2UrBjyqKI4NuprexPob8qRo+STFsKRMDaJ5ADBZf/TUQZToDIv3L1pE3N3vyeqY+VTg1 jfVg== MIME-Version: 1.0 X-Received: by 10.180.13.170 with SMTP id i10mr4209680wic.36.1387484839441; Thu, 19 Dec 2013 12:27:19 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 19 Dec 2013 12:27:19 -0800 (PST) Date: Thu, 19 Dec 2013 14:27:19 -0600 Message-ID: From: Mary Barnes To: "draft-ietf-bfcpbis-rfc4582bis.authors@tools.ietf.org" , "bfcpbis@ietf.org" Content-Type: multipart/alternative; boundary=001a11c242e0fc7b1604ede8fcc8 Cc: Richard Barnes , "bfcpbis-chairs@tools.ietf.org" Subject: [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: Thu, 19 Dec 2013 20:27:25 -0000 --001a11c242e0fc7b1604ede8fcc8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. 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 made by 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 deal with those comments/concerns 3) I have reviewed the document in detail - both the entire document and the diffs between RFC4582. I have both comments and nits on text that was 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 distinguish 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 identify 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, etc." 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 Error 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 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). 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 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 that paragraph is also in 5018 (as I don't think you're referring to section 6 of this document). 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 treated as closed (since this is a SHOULD and not a MUST)? Either 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). The "assumes" 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 authentication mechanisms defined that don't require the integrity protected channel. b) 2nd paragraph, last sentence. Under what criteria would a client 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" -> "MUST check" or explain what might happen if the floor control servers doesn't check that the messages 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 MUSTs 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 think the "=10MAY 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 "may"s: (lower 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 normative. If so, it should be a =10MAY and perhaps reworded as I think it'= s trying 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 needs to be revisited. For example, 2nd para, 1st sentence. It would seem that "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 generate an Error response (i.e., why is it a SHOULD and not a MUST)? 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 added for handling incorrect payload length. 12) Section 16.1. "Requiring timely response". Shouldn't there be a reference to section 8.3 (Timers)? 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? *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 be compared" 6) Section 8, 2nd indented paragraph. "must be non-zero" -> "MUST be non-zero" 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 bulleted 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 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 on RFC 5018 for authentication and security. --001a11c242e0fc7b1604ede8fcc8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I have agreed to shepherd this document on behalf of the W= G. =A0I have reviewed this document in preparation for doing the PROTO writ= e-up. =A0
=
I think the document needs a bit of work before it's ready to= progress. =A0I have a few questions/comments, as well as editorial nits wh= ich I think would improve readability and ease of understanding.=A0

Regards,
Mary.=A0


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 made by Joerg:
At this time, I've not seen the authors post any proposals as to h= ow to deal with those comments/concerns

3) I have = reviewed the document in detail - both the entire document and the diffs be= tween RFC4582. I have both comments and nits on text that was also in RFC 4= 582, as well as on the new text, detailed below. Note, that a number of nit= s are around the use of lower case normative words which ought to be upperc= ase to distinguish them from the normal English usage. I think there are a = number of cases where "may"s for example would be much better sta= ted as "can"s. =A0I'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. =A0You need to specify what you = mean by the parenthetical "in a certain way" - that doesn't t= ell you anything. =A0Something like "depending upon policies, privileg= es, etc." is probably more appropriate.=A0

2) Section 6.2.
a) 3rd paragraph, 1st sentenc= e: I don't think this is normative since you're referring to the no= rmative section. =A0I 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? =A0I 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).=A0
c) 4th para, last sentence: "shall" -> "SHALL"<= /div>
d) last para, next to last sentence. =A0Why isn't this "= MUST" request the use of DTLS? If it's a SHOULD, then the impacts = or criteria under which DTLS isn't REQUIRED should be clarified. =A0I s= ee that the paragraph has references to =A05018 Section 5. =A0I think it al= so should be clarified that the "section 6" reference in that par= agraph is also in 5018 (as I don't think you're referring to sectio= n 6 of this document).=A0

3) Section 6.2.1
a) 1st para, 3rd sentence. I= don't think "previous paragraph" is accurate. =A0I think it = would be better to include an explicit reference to section 6.2 or say &quo= t;previous section". =A0=A0
b) next to last sentence ought to be written normatively
OLD=
=A0 =A0The default initial
=A0 =A0interval is set to 5= 00ms and the interval is doubled after each
=A0 =A0retransmission= attempt.
NEW
=A0 =A0The default initial
=A0 =A0interval MUS= T be set to 500ms and the interval MUST be doubled after each
=A0= =A0retransmission attempt.

4) Section 6.2.2, 1st = sentence. =A0What happens if the connection isn't treated as closed (si= nce this is a SHOULD and not a MUST)? =A0Either this is a MUST or the reaso= ns one wouldn't treat the connection as closed and what happens when it= 's not treated as closed need to be explained. =A0

5) Section 6.2.3, indented paragraph. =A0What happens i= f the cookie exchange mechanisms in DTLS aren't used and/or what other = mechanisms could be used? =A0 (Note, also that the should ought to be SHOUL= D).

6) Section 9.1.=A0
a) 1st para, 2nd sentence.= (Similar to comment 9 on rfc4583-bis). =A0The "assumes" needs to= a REQUIRED. =A0
OLD:
=A0 =A0BFCP assumes that there is= an integrity-
=A0 =A0protected channel between the client and the floor control serv= er
=A0 =A0that can be used to exchange their self-signed certific= ates or, more
=A0 =A0commonly, the fingerprints of these certific= ates.=A0

NEW:=A0
=A0 =A0An initial integrity-protected= channel is REQUIRED between the client=A0
=A0 =A0and the floor c= ontrol server that can be used to exchange their=A0
=A0 =A0self-s= igned certificates or, more commonly, the fingerprints of=A0
=A0 =A0these certificates.=A0

OR =A0this need= s to be a SHOULD and then include the text that's in the "Note=85&= quot; in the 3rd paragraph that indicates if there are additional authentic= ation mechanisms defined that don't require the integrity protected cha= nnel.=A0

b) 2nd paragraph, last sentence. =A0Under what criteria= would a client NOT ignore unauthenticated messages or what bad things can = happen if a client doesn't ignore the messages. =A0It might be better t= o make this a MUST. =A0=A0

c) 4th paragraph, 2nd sentence. =A0"SHOULD check&q= uot; -> "MUST check" or explain what might happen if the floor= control servers doesn't check that the messages aren't using an au= thorized User ID. =A0=A0

7) Section 11.1.
a) 4th paragraph. =A0There&#= 39;s three SH=10OULDs in there that all ought to be MUSTs OR the situations= under which the action doesn't need to be done needs to be specified.= =A0
b) 5th paragraph: I don't think that the use of Queue position fie= ld in the last sentence prior to the indented text ought to be normative - = i.e., I think the "=10MAY use the Queue Position field" ought to = be "can use the Queue Position field". =A0
c) Indented text (1st para) after 5th para. =A0 There are several &quo= t;may"s: (lower case) in this paragraph (and the next note), that prob= ably all ought to be "can"s =A0
d) last paragraph. It&#= 39;s not clear to me whether this "may" ought to be normative. If= so, it should be a =10MAY and perhaps reworded as I think it's trying = to say that "the floor chair MAY include STATUS-INFO attributes" = in =A0 =A0Otherwise, a "can" would suffice. =A0

8) Section 12.1.2. =A0There is no normative language in= this section. =A0It needs to be revisited. =A0For example, 2nd para, 1st s= entence. =A0It would seem that "the floor control server will
=A0 =A0respond with a FloorStatus message or with an Error message"= =A0
ought to be "MUST respond.=A0

9) Section= 13.6, 1st para. =A0Under what circumstances would the server NOT generate = an Error response (i.e., why is it a SHOULD and not a MUST)? =A0=A0

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

11) Section 16.1. =A0I think there should be mention of th= e additional text added for handling incorrect payload length.
12) Section 16.1. "Requiring timely response". =A0Shou= ldn't there be a reference to section 8.3 (Timers)? =A0=A0
13) Appendix A. Has there been anyone that has verified the ca= ll flows with a tool or in the lab? =A0If so, who was that? =A0=A0

Nits:

1) Section 3.1, l= ast paragraph. =A0I would prefer this be updated to be much more precise in= terms of CCM=10P. =A0I realize that this document was published well befor= e CCMP, so the text in RFC 4582 is based on draft versions.=A0
OLD:
=A0 =A0Conference control clients using CCMP [17] can s= pecify such floor-
=A0 =A0related settings by editing the floor-i= nformation section of the
=A0 =A0to-be created conference object = provided in the body of a CCMP
=A0 =A0confRequest/create message issued to the conference control ser= ver.

NEW:=A0
=A0 =A0 Conference control = clients using CCMP [17] can specify such floor-
=A0 =A0related se= ttings in the <floor-information> [RFC6501]element of the
=A0 =A0to-be created conference object provided in the body of a CCMP<= /div>
=A0 =A0confRequest/create message issued to the conference contro= l server.

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

3) Section 3.3, last paragraph. "<floor-informa= tion> section" -> =A0"<floor-information> element&quo= t;

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

5) Section 6.2.3:
- seventh paragraph. "= must then retransmit" -> "MUST then retransmit"=A0
<= div>- indented paragraph. "the Payload Length field may be compared&qu= ot; - > "can be compared"=A0

6) Section 8, 2nd indented paragraph. "must be non= -zero" -> "MUST be non-zero"

7) = Section 10.1.1. 1st paragraph after 2nd indented para. "must insert&qu= ot; -> "MUST insert"

8) Section 10.1.2, 5th & 6th paragraphs. =A0"M= AY display" -> "can display" =A0

9) Section 12.2.1. last paragraph. "must insert" -> "MUS= T insert"

10) Section 12.3.1. =A0 last paragraph. "must inse= rt" -> "MUST insert"

11) Section= 16.1. =A0This is a bit hard to read. =A0I would suggest you use a bulleted= or numbered list rather than this hanging list format.=A0

12) References:
a) Per the first nit, a refer= ence to RFC 6501 (XCON Data model) should be added to this document.=A0
b) RFC 4582 should be a normative reference
c) I also sugg= est that RFC 5018 is normative as this document relies on RFC 5018 for auth= entication and security.=A0
--001a11c242e0fc7b1604ede8fcc8-- From mary.ietf.barnes@gmail.com Fri Dec 20 06:44:17 2013 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 E9B3C1AE34F for ; Fri, 20 Dec 2013 06:44:17 -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 61hVfPiPRWAQ for ; Fri, 20 Dec 2013 06:44:16 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EC67C1AE34D for ; Fri, 20 Dec 2013 06:44:15 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id a1so2555764wgh.35 for ; Fri, 20 Dec 2013 06:44:13 -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 :content-type; bh=TIGim4uuVD4NkRb5u7Bp7FwKlWk2s8KiFJfqE5Dwudo=; b=bc2vN3jUlYI6f0VXm69J5nlRJMvGG8wmSQ7yNBKmJuDBO9Yy8wHJpAJgrp7ciSYMJk Sx1DS2RK53WsWK+Bbp+iUuEFB27fuE4oMh15bbDzFrZURg7mwMjWTY2tKnWJfOp2C6si pNXNfmHAg6BK0nWfwIX8T76C8sHeYCrm4b3TUNGa2E2X42Adl+LakDIQM2x7pTCvlRG2 90aDfHx07z8tCAbIoEt4fkK2Q+SoMdl1wWVt6OWKfK0EoR2P/j9Vdej92DbY8ASIow/7 GfhXVOuzqamwfNJj+f9BlAY/vqeKwOwLq3PjL00x1I2kMLECQ5c9FKX15+TFHIqV8Or8 R4Bw== MIME-Version: 1.0 X-Received: by 10.180.13.170 with SMTP id i10mr7583234wic.36.1387550652466; Fri, 20 Dec 2013 06:44:12 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 20 Dec 2013 06:44:12 -0800 (PST) In-Reply-To: <52B4533A.5050007@ericsson.com> References: <52B04EEF.8020200@ericsson.com> <52B1C65E.3050406@ericsson.com> <52B4533A.5050007@ericsson.com> Date: Fri, 20 Dec 2013 08:44:12 -0600 Message-ID: From: Mary Barnes To: "bfcpbis@ietf.org" Content-Type: multipart/alternative; boundary=001a11c242e0bf8ae504edf84f14 Subject: [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, 20 Dec 2013 14:44:18 -0000 --001a11c242e0bf8ae504edf84f14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 an >> 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-__08 >> ). >> Prior to progressing the document we need a review by >> the SDP >> directorate. My understanding is that the MMUSIC WG chairs >> 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. >> >> >> >> >> >> >> > --001a11c242e0bf8ae504edf84f14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI...here's the SDP directorate review for 4583bis.
Mary.=A0

---------- For= warded message ----------
From: Ari Ker=E4= nen <a= ri.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@too= ls.ietf.org" <m= music-chairs@tools.ietf.org>, Charles Eckel <eckelcu@cisco.com>, draft-ietf-bfcpbis-rfc4583bis.auth= ors@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.









--001a11c242e0bf8ae504edf84f14--