From nobody Tue Jan 6 03:52:22 2015 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 6418D1A914B for ; Tue, 6 Jan 2015 03:52:20 -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 u8bYiXfDb6R0 for ; Tue, 6 Jan 2015 03:52:13 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BEF01A9142 for ; Tue, 6 Jan 2015 03:52:12 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so19476232lbi.30 for ; Tue, 06 Jan 2015 03:52:11 -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=uLVPpC0nlmRtgMYGKFgsDvorZT0nPV1UFAFCAYNCRwA=; b=ujJIx9Lc3oE5YH3P4euoJTto/XMyKJp6PpDZr/wwhLZ4cm5jQr0XQ90iOV8pG5Tnmd /q6vahu0Z5HX4VN5hrmRfObQ+/Drb3jMfMWY+tF7qtDil8/+bDeM0nj0mG9o129ltXKw r/iTNBlRghmUNcWa7sIGyLcCJJW25Tgl22L3ZUj7GiIMtMG6+MNNqJe/Lpc9twplfKw1 3ab87cvIclK4U88DfsjFmr/UdZ7mLzjq4/lxTFlDXMK3cWY9m3aV/bnX9oyFE9c7XOQS YN1aEsa5Wl63UIp8iSrXouOOE4Ah6q2l0e4k2KBVlFw7rrKcTvBNJolADFIB33DMzKlL n2LQ== MIME-Version: 1.0 X-Received: by 10.112.168.164 with SMTP id zx4mr99351344lbb.28.1420545130829; Tue, 06 Jan 2015 03:52:10 -0800 (PST) Received: by 10.25.170.16 with HTTP; Tue, 6 Jan 2015 03:52:10 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <54885F09.6010706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> <5489E3B5.9020300@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58F83A@ESESSMB209.ericsson.se> Date: Tue, 6 Jan 2015 12:52:10 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a11c23564e9218b050bfa6f51 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/epc8rmoOoQacaC2z63Cb_lj478A Cc: "bfcpbis@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-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, 06 Jan 2015 11:52:20 -0000 --001a11c23564e9218b050bfa6f51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm back from my pretty longYule vacation and intend to issue a new version of this draft tomorrow, restructuring slightly according to the understanding distilled from this discussion. That is, adding separate subsections for the attributes in a consistent manner and assorted fixes listed earlier in the thread. Also, a couple of minor additions will be added as a result of running an ABNF verification on the draft. -- Tom On 11 December 2014 at 19:50, Charles Eckel (eckelcu) wrote: > On 12/11/14, 10:38 AM, "Christer Holmberg" > wrote: > > >Hi, > > > >>> I agree in general, but specifically in the case of this draft, it > >>> should have been completed long ago and it is very close to being sen= t > >>> to the IESG now. I do not think it should be used to test the new > >>> template. Only one of its attributes are new and the rest of from > >>> rfc4583. Chances are, there will be some additional changes to the > >>> template before 4566bis is finished, and either 4583bis will need to > >>> be updated again or it will still deviate from the template. Wouldn't > >>> it be more reasonable to use a new draft defining new SDP attributes > >>>as a test vehicle? > >> > >> Given what you say I certainly won't press the issue. > >> While it would be nice, I don't see it as essential. > > > >I'm fine having the current structure too :) > > > >(However, as I indicated in another comment, I still think the attribute= s > >should be defined in dedicated (sub-) sections.) > > Sounds good! > > Cheers, > Charles > > > > > >Regards > > > >Christer > > > > > > > > > >> On 12/11/14, 3:42 AM, "Christer Holmberg" > >> > >> wrote: > >> > >>> Hi, > >>> > >>> In order to figure out whether Paul's suggestion works, someone needs > >>> to use it - before the SDP-bis draft is published as RFC :) > >>> > >>> It's a very small task to change it. I could do it, but I'd like > >>> others to also try it out, and provide feedback. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> -----Original Message----- > >>> From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Paul > >>> Kyzivat > >>> Sent: 10. joulukuuta 2014 16:56 > >>> To: bfcpbis@ietf.org > >>> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 > >>> > >>> I'm here to discuss how I think the attribute declaration updates to > >>> 4566bis should apply here. > >>> > >>> (Note that I haven't been closely following this draft. I noted > >>> Christer's comments, and then scanned the draft to find relevant > >>> sections.) > >>> > >>> First, the template I have introduced in 4566bis is new, and hasn't > >>> been thoroughly reviewed. It is good to "debug" it and fine tune it. > >>> > >>> Second, I have *some* sympathy for bis drafts in general. It is hard > >>> to decide how much to change, and what to leave alone. OTOH, I set > >>> out specifically to improve the mechanism for definition of > >>> attributes, and did update all the definitions in 4566bis. My goal is > >>> to ensure that there is clarity in the syntax of attributes, and that > >>> developers reading those will know what they are expected to do to > >>>parse them. > >>> > >>> I find that what is in this document now does at least define the > >>> syntax unambiguously. > >>> > >>> OTOH, it does imply that the attribute names it defines should be > >>> matched in a case-insensitive way, which is contrary to what 4566 say= s. > >>> > >>> I think it would be "nice" if the attribute declarations here were > >>> updated to the new format - a help in getting on the new path. > >>> > >>> My inclination would be to convert to the new format, inline in the > >>> sections where the attribute syntax is currently defined, and then > >>> simply cross reference those definitions from the IANA Considerations > >>>section. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 12/9/14 6:53 PM, Charles Eckel (eckelcu) wrote: > >>>> On 12/9/14, 12:17 AM, "Christer Holmberg" > >>>> > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>>>> Q1: > >>>>>>> > >>>>>>> There is a new "template" for defining SDP attributes. It has > >>>>>>> been discussed on the MMUSIC list, and Paul K can give more > >>>>>>> information if needed. > >>>>>> > >>>>>> A ptr to that would be helpful. I scanned the MMUSIC list quickly > >>>>>> but must have missed it. > >>>>> > >>>>> Please look at section 6 in > >>>>> https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt > >>>> > >>>> This section makes consistent use of the following template (using > >>>> =C2=B3cat=C2=B2 as an example): > >>>> > >>>> --- > >>>> Name: cat > >>>> > >>>> Value: cat-value > >>>> > >>>> Usage Level: session > >>>> > >>>> Charset Dependent: no > >>>> > >>>> Syntax: > >>>> > >>>> cat-value =3D category > >>>> category =3D byte-string > >>>> ; Note: syntax is vague because usage is not understood > >>>> > >>>> Example: > >>>> > >>>> a=3Dcat:foo.bar > >>>> > >>>> This attribute gives the dot-separated hierarchical category of > >>>>the > >>>> session. This is to enable a receiver to filter unwanted > >>>> sessions by > >>>> category. There is no central registry of categories. > >>>> > >>>> < > >>>> > >>>> I don=C2=B9t believe draft-ietf-bfcpbis-rfc4583bis-10 should include= such > >>>> info for each attribute because similar information is already > >>>> captured in the IANA considerations sections in for the format > >>>> appropriate for IANA considerations. > >>>> > >>>>> > >>>>> > >>>>> > >>>>>>> Q2: > >>>>>>> > >>>>>>> Most SDP attributes are defined in their own sections - which is > >>>>>>> good. > >>>>>>> But, sometimes the section name contains the name of the > >>>>>>> attribute, and sometimes not. I think it would be good to be > >>>>>>> consistent, and always call the section "SDP xxx attribute". > >>>> > >>>> The IANA considerations section does this (i.e. SDP attribute name > >>>> in section title). Sections 4-7 are organized by functionality > >>>> rather than by SDP attribute. As such, I think the existing names > >>>> are appropriate. We could add subsections for each attribute within > >>>> these sections that are named according to the name of the > >>>> corresponding SDP attribute. That said, I do think such additions > >>>> would be all that useful. > >>>> > >>>>>>> > >>>>>>> Q3: > >>>>>> > >>>>>> There is no dedicated SDP Offer/Answer procedure section (instead, > >>>>>> each section defining an SDP attribute include a few sentences > >>>>>> about Offer/Answer). > >>>>>> > >>>>>> I think it would be good to have a dedicated SDP Offer/Answer > >>>>>> procedure section, following the structure in RFC 3264. I've had > >>>>>> to do that e.g. > >>>>>> for BUNDLE and SCTP-SDP. > >>>>>> > >>>>>> I had a look at > >>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiatio > >>>>>> n- > >>>>>> 13 as an example. I see how we could rename and reorganize the > >>>>>> existing content along these lines. I struggle with this a bit > >>>>>> because I am comfortable with the existing document structure and > >>>>>> my familiarity with it make it straightforward for me to understan= d. > >>>>>> For a new reader, I think your suggested change will help, so I'm > >>>>>> in favor of it. > >>>>> > >>>>> I took the text from the SCTP-SDP draft (note that the text may > >>>>> still change), and tried to convert it into BFCP. Some parts are > >>>>> probably still missing (for example, I realized that I forgot to > >>>>> add text regarding the SDP 'floorctrl' attribute) , and maybe the > >>>>> BFCP draft uses different terminology, but feel free to use it as a > >>>>>base: > >>>>> > >>>>> -------- > >>>>> > >>>>> 9. SDP Offer/Answer Procedures > >>>>> > >>>>> 9.1. General > >>>>> > >>>>> This section defines the SDP Offer/Answer [RFC3264] procedures > >>>>>for > >>>>> negotiating and establishing an BFCP connection. > >>>>> > >>>>> If the m- line proto value is ' TCP/TLS/BFCP ' or ' > >>>>> UDP/TLS/BFCP ', each > >>>>> endpoint MUST provide a certificate fingerprint, using the SDP > >>>>> 'fingerprint' attribute [RFC4145], if the endpoint supports, an= d > >>>>>is > >>>>> willing to use, a cipher suite with an associated certificate. > >>>>> > >>>>> The authentication certificates are interpreted and validated a= s > >>>>> defined in [RFC4572]. Self-signed certificates can be used > >>>>> securely, > >>>>> provided that the integrity of the SDP description is assured a= s > >>>>> defined in [RFC4572]. > >>>>> > >>>>> NOTE: The procedures apply to a specific m- line describing an > >>>>>BFCP > >>>>> connection. If an offer or answer contains multiple m- line > >>>>> describing BFCP connections, the procedures are applied > >>>>>separately > >>>>> to each m- line. > >>>>> > >>>>> 9.2. Generating the Initial SDP Offer > >>>>> > >>>>> When the offerer creates an initial offer, the offerer: > >>>>> > >>>>> o MUST, if the m- line proto value is 'TCP/BFCP', > >>>>>'TCP/TLS/BFCP' or > >>>>> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section > >>>>> X], with an > >>>>> 'actpass' value, with the m- line; > >>>>> > >>>>> o MUST, if the m- line proto value is 'TCP/BFCP' or > >>>>>'TCP/TLS/BFCP', > >>>>> associate an SDP 'connection' attribute [Section 8.4], with= a > >>>>> 'new' value, with the m- line; and > >>>>> > >>>>> In addition, if the offerer acts as the floor control server, > >>>>> the > >>>>> offerer: > >>>>> > >>>>> o MUST associate an SDP 'confid' attribute [Section X], with > >>>>> the > >>>>> m- line; > >>>>> > >>>>> o MUST associate an SDP 'userid' attribute [Section X], with > >>>>> the > >>>>> m- line; > >>>>> > >>>>> o MUST associate an SDP 'floorid' attribute [Section X], with > >>>>> the > >>>>> m- line; and > >>>>> > >>>>> o MUST associate an SDP 'label' attribute [Section X], with > >>>>> the > >>>>> m- line. > >>>>> > >>>>> 9.3. Generating the SDP Answer > >>>>> > >>>>> When the answerer receives an offer, which contains an m- line > >>>>> describing a BFCP connection, if the answerer accepts the m- li= ne > >>>>> it: > >>>>> > >>>>> o MUST insert a corresponding m- line in the answer, with an > >>>>> identical m- line proto value [RFC3264]; and > >>>>> > >>>>> o MUST, if the m- line proto value is 'TCP/BFCP', > >>>>>'TCP/TLS/BFCP' or > >>>>> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section > >>>>> X], with an > >>>>> 'active' or 'passive' value, with the m- line; > >>>>> > >>>>> In addition, if the answerer acts as the floor control server, > >>>>> the > >>>>> answerer: > >>>>> > >>>>> o MUST associate an SDP 'confid' attribute [Section X], with > >>>>> the > >>>>> m- line; > >>>>> > >>>>> o MUST associate an SDP 'userid' attribute [Section X], with > >>>>> the > >>>>> m- line; > >>>>> > >>>>> o MUST associate an SDP 'floorid' attribute [Section X], with > >>>>> the > >>>>> m- line; and > >>>>> > >>>>> o MUST associate an SDP 'label' attribute [Section X], with > >>>>> the > >>>>> m- line. > >>>>> > >>>>> Once the answerer has sent the answer, the answerer: > >>>>> > >>>>> o MUST, if the answerer is the 'active' endpoint, and if a TCP > >>>>> connection > >>>>> associated with the m- line is to be established (or > >>>>> re-established), > >>>>> initiate the establishing of the TCP connection; and > >>>>> > >>>>> o MUST, if the answerer is the 'active' endpoint, and if an > >>>>> TLS/DTLS > >>>>> connection associated with the m- line is to be established > >>>>>(or > >>>>> re-established), initiate the establishing of the TLS/DTLS > >>>>> connection > >>>>> (by sending a ClientHello message). > >>>>> > >>>>> If the answerer does not accept the m- line in the offer, it MU= ST > >>>>> assign a zero port value to the corresponding m- line in the > >>>>>answer. > >>>>> In addition, the answerer MUST NOT establish an SCTP > >>>>>association, or > >>>>> a DTLS connection, associated with the m- line. > >>>>> > >>>>> 9.4. Offerer Processing of the SDP Answer > >>>>> > >>>>> When the offerer receives an answer, which contains an m- line > >>>>> with a > >>>>> non-zero port value, describing a BFCP connection, the offerer: > >>>>> > >>>>> o MUST, if the offer is the 'active' endpoint, and if a TCP > >>>>> connection > >>>>> associated with the m- line is to be established (or > >>>>> re-established), > >>>>> initiate the establishing of the TCP connection; and > >>>>> > >>>>> o MUST, if the offerer is the 'active' endpoint, and if an > >>>>>TLS/DTLS > >>>>> connection associated with the m- line is to be established > >>>>>(or > >>>>> re-established), initiate the establishing of the TLS/DTLS > >>>>> connection > >>>>> (by sending a ClientHello message). > >>>>> > >>>>> If the m- line in the answer contains a zero port value, the > >>>>>offerer > >>>>> MUST NOT establish an TCP connection, or a TLS/DTLS connection, > >>>>> associated with the m- line. > >>>>> > >>>>> 9.5. Modifying the Session > >>>>> > >>>>> When an offerer sends an updated offer, in order to modify a > >>>>> previously established BFCP connection, it follows the > >>>>>procedures in > >>>>> Section 9.2, with the following exceptions: > >>>>> > >>>>> o If the BFCP connection is carried on top of TCP, and unless > >>>>>the > >>>>> offerer wants to re-establish an existing TCP connection, t= he > >>>>> offerer MUST associate an SDP connection attribute, with > >>>>> an 'existing' value, with the m- line; and > >>>>> > >>>>> o If the offerer wants to disable a previously established BFC= P > >>>>> connection, it MUST assign a zero port value to the m- line > >>>>> associated with the BFCP connection, following the procedure= s > >>>>>in > >>>>> [RFC3264]. > >>>>> > >>>>> > >>>>> --------------- > >>>> > >>>> That looks pretty straightforward and clear to me. Adding the > >>>> floorctrl attribute will complicate it some, but I think its still > >>>> manageable. > >>>> > >>>>> > >>>>> Q3b: > >>>>> > >>>>> The following sentence in 4583bis is a little confusing: > >>>>> > >>>>> "If the 'floorctrl' attribute is not used in an offer/answer > >>>>> exchange, > >>>>> by default the offerer and the answerer will act as a floor > >>>>>control > >>>>> client and as a floor control server, respectively." > >>>>> > >>>>> Does this mean that the role may change every time an endpoint - > >>>>> for whatever reason - sends an updated offer? > >>>> > >>>> Yes. This was inherited from RFC 4583, and it is the consequence of > >>>> the lenient normative language immediately before it. > >>>> > >>>> "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 this > >>>> attribute in its session descriptions.=C2=B2 > >>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>> Q4: > >>>>>>> > >>>>>>> For DTLS and Offer/Answer, there are a few references to RFC 5763 > >>>>>>> here and there. But, I think it would be good to have explicit > >>>>>>> text on the Offer/Answer considerations regarding DTLS - > >>>>>>> especially since there have been quite a bit of discussions about > >>>>>>>that lately. > >>>>>> > >>>>>> Are you suggesting a copy/paste of the relevant text from RFC 5763 > >>>>>> in additional to a reference, or is there an calcification of what > >>>>>> is provided in RFC 5763 that you added for SCTP that would be > >>>>>> helpful for this draft? > >>>>> > >>>>> In the SCTP-SDP draft I have the following text, which is aligned > >>>>> with RFC 5763, but provides a little more details. > >>>>> > >>>>> You could probably use the text just by replacing the proto field > >>>>> values with the ones used for BFCP. > >>>>> > >>>>> ------------- > >>>>> > >>>>> 8.3.3. TLS Role Determination > >>>>> > >>>>> If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the > >>>>> 'active/passive' status is used to determine the TLS roles. > >>>>> Following the procedures in [RFC4572], the 'active' endpoint wi= ll > >>>>> take the TLS client role. > >>>>> > >>>>> Once a DTLS connection has been established, if the > >>>>>'active/passive' > >>>>> status of the endpoints change during a session, a new DTLS > >>>>> connection MUST be established. Therefore, endpoints SHOULD NO= T > >>>>> change the 'active/passive' status in subsequent offers and > >>>>>answers, > >>>>> unless they want to establish a new DTLS connection. > >>>>> > >>>>> If the transport parameters or the key fingerprints change, the > >>>>> endpoints MUST establish a new DTLS connection. In such case t= he > >>>>> 'active/passive' status of the endpoints will again be determin= ed > >>>>> following the procedures in [RFC4145], and the new status will = be > >>>>> used to determine the TLS roles associated with the new DTLS > >>>>> connection. > >>>>> > >>>>> NOTE: The procedure above is identical to the one defined for > >>>>>SRTP- > >>>>> DTLS in [RFC5763]. > >>>>> > >>>>> NOTE: A new DTLS connection needs to be established if the > >>>>>transport > >>>>> parameters or the key fingerprints change. > >>>>> > >>>>> ------------ > >>>> > >>>> I am okay with this. Its a nice summary. Our previous reference to > >>>> RFC 5763, section 5, did not address session modification. This fixe= s > >>>>that. > >>>> > >>>>> > >>>>>> Q5: > >>>>>> > >>>>>> The draft does not define how to use BFCP within a BUNDLE group. > >>>>>> That is fine, but I think it would be good to explicitly indicate > >>>>>> that. > >>>>>> > >>>>>> Yes. I'm thinking we need to point to > >>>>>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-0 > >>>>>> 5# > >>>>>> page- > >>>>>> 28 for attributes defined in RFC 4583, and define the mux > >>>>>> category for new attributes defined within this draft. > >>>>> > >>>>> Defining the mux category is one thing. > >>>>> > >>>>> But, if you want to define usage of BFCP within a BUNDLE group, you > >>>>> also need to describe how BFCP is identified when bundled with > >>>>> other protocols (RTP etc). > >>>> > >>>> I think this goes beyond what is needed for this draft. If someone > >>>> wants to use BFCP with BUNDLE, they can define that usage. Sounds > >>>> reasonable? > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> > >>>>> 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/ --001a11c23564e9218b050bfa6f51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm back from my pretty longYule vacation and intend t= o issue a new version of this draft tomorrow, restructuring slightly accord= ing to the understanding distilled from this discussion. That is, adding se= parate subsections for the attributes in a consistent manner and assorted f= ixes listed earlier in the thread.

Also, a couple = of minor additions will be added as a result of running an ABNF verificatio= n on the draft.

-- Tom

On 11 December 2014 a= t 19:50, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:<= br>
On 12/11/14, 10:38 AM, "Christer Hol= mberg"
<christer.holmberg@eri= csson.com> wrote:

>Hi,
>
>>> I agree in general, but specifically in the c= ase of this draft, it
>>> should have been completed long ago and it is very close to be= ing sent
>>> to the IESG now. I do not think it should be used to test the = new
>>> template. Only one of its attributes are new and the rest of f= rom
>>> rfc4583. Chances are, there will be some additional changes to= the
>>> template before 4566bis is finished, and either 4583bis will n= eed to
>>> be updated again or it will still deviate from the template. W= ouldn't
>>> it be more reasonable to use a new draft defining new SDP attr= ibutes
>>>as a test vehicle?
>>
>> Given what you say I certainly won't press the issue.
>> While it would be nice, I don't see it as essential.
>
>I'm fine having the current structure too :)
>
>(However, as I indicated in another comment, I still think the attribut= es
>should be defined in dedicated (sub-) sections.)

Sounds good!

Cheers,
Charles


>
>Regards
>
>Christer
>
>
>
>
>> On 12/11/14, 3:42 AM, "Christer Holmberg"
>> <christer.hol= mberg@ericsson.com>
>> wrote:
>>
>>> Hi,
>>>
>>> In order to figure out whether Paul's suggestion works, so= meone needs
>>> to use it - before the SDP-bis draft is published as RFC :) >>>
>>> It's a very small task to change it. I could do it, but I&= #39;d like
>>> others to also try it out, and provide feedback.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> -----Original Message-----
>>> From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Paul
>>> Kyzivat
>>> Sent: 10. joulukuuta 2014 16:56
>>> To: bfcpbis@ietf.org >>> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583b= is-10
>>>
>>> I'm here to discuss how I think the attribute declaration = updates to
>>> 4566bis should apply here.
>>>
>>> (Note that I haven't been closely following this draft. I = noted
>>> Christer's comments, and then scanned the draft to find re= levant
>>> sections.)
>>>
>>> First, the template I have introduced in 4566bis is new, and h= asn't
>>> been thoroughly reviewed. It is good to "debug" it a= nd fine tune it.
>>>
>>> Second, I have *some* sympathy for bis drafts in general. It i= s hard
>>> to decide how much to change, and what to leave alone. OTOH, I= set
>>> out specifically to improve the mechanism for definition of >>> attributes, and did update all the definitions in 4566bis. My = goal is
>>> to ensure that there is clarity in the syntax of attributes, a= nd that
>>> developers reading those will know what they are expected to d= o to
>>>parse them.
>>>
>>> I find that what is in this document now does at least define = the
>>> syntax unambiguously.
>>>
>>> OTOH, it does imply that the attribute names it defines should= be
>>> matched in a case-insensitive way, which is contrary to what 4= 566 says.
>>>
>>> I think it would be "nice" if the attribute declarat= ions here were
>>> updated to the new format - a help in getting on the new path.=
>>>
>>> My inclination would be to convert to the new format, inline i= n the
>>> sections where the attribute syntax is currently defined, and = then
>>> simply cross reference those definitions from the IANA Conside= rations
>>>section.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0Paul
>>>
>>> On 12/9/14 6:53 PM, Charles Eckel (eckelcu) wrote:
>>>> On 12/9/14, 12:17 AM, "Christer Holmberg"
>>>> <chri= ster.holmberg@ericsson.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>>> Q1:
>>>>>>>
>>>>>>> There is a new "template" for defini= ng SDP attributes. It has
>>>>>>> been discussed on the MMUSIC list, and Paul K = can give more
>>>>>>> information if needed.
>>>>>>
>>>>>> A ptr to that would be helpful. I scanned the MMUS= IC list quickly
>>>>>> but must have missed it.
>>>>>
>>>>> Please look at section 6 in
>>>>> https://tools.ietf.org/id/draft-ietf-= mmusic-rfc4566bis-12.txt
>>>>
>>>> This section makes consistent use of the following templat= e (using
>>>> =C2=B3cat=C2=B2 as an example):
>>>>
>>>> ---
>>>>=C2=A0 =C2=A0 =C2=A0 Name: cat
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 Value: cat-value
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 Usage Level: session
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 Charset Dependent: no
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 Syntax:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cat-value =3D category >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0category =3D byte-string<= br> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; Note: syntax is = vague because usage is not understood
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 Example:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dcat:foo.bar
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 This attribute gives the dot-separated= hierarchical category of
>>>>the
>>>>=C2=A0 =C2=A0 =C2=A0 session.=C2=A0 This is to enable a rec= eiver to filter unwanted
>>>> sessions by
>>>>=C2=A0 =C2=A0 =C2=A0 category.=C2=A0 There is no central re= gistry of categories.
>>>>
>>>> <
>>>>
>>>> I don=C2=B9t believe draft-ietf-bfcpbis-rfc4583bis-10 shou= ld include such
>>>> info for each attribute because similar information is alr= eady
>>>> captured in the IANA considerations sections in for the fo= rmat
>>>> appropriate for IANA considerations.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Q2:
>>>>>>>
>>>>>>> Most SDP attributes are defined in their own s= ections - which is
>>>>>>> good.
>>>>>>> But, sometimes the section name contains the n= ame of the
>>>>>>> attribute, and sometimes not. I think it would= be good to be
>>>>>>> consistent, and always call the section "= SDP xxx attribute".
>>>>
>>>> The IANA considerations section does this (i.e. SDP attrib= ute name
>>>> in section title). Sections 4-7 are organized by functiona= lity
>>>> rather than by SDP attribute. As such, I think the existin= g names
>>>> are appropriate. We could add subsections for each attribu= te within
>>>> these sections that are named according to the name of the=
>>>> corresponding SDP attribute. That said, I do think such ad= ditions
>>>> would be all that useful.
>>>>
>>>>>>>
>>>>>>> Q3:
>>>>>>
>>>>>> There is no dedicated SDP Offer/Answer procedure s= ection (instead,
>>>>>> each section defining an SDP attribute include a f= ew sentences
>>>>>> about Offer/Answer).
>>>>>>
>>>>>> I think it would be good to have a dedicated SDP O= ffer/Answer
>>>>>> procedure section, following the structure in RFC = 3264. I've had
>>>>>> to do that e.g.
>>>>>> for BUNDLE and SCTP-SDP.
>>>>>>
>>>>>> I had a look at
>>>>>> http://tools.ietf.org/html/d= raft-ietf-mmusic-sdp-bundle-negotiatio
>>>>>> n-
>>>>>> 13 as an example. I see how we could rename and re= organize the
>>>>>> existing content along these lines. I struggle wit= h this a bit
>>>>>> because I am comfortable with the existing documen= t structure and
>>>>>> my familiarity with it make it straightforward for= me to understand.
>>>>>> For a new reader, I think your suggested change wi= ll help, so I'm
>>>>>> in favor of it.
>>>>>
>>>>> I took the text from the SCTP-SDP draft (note that the= text may
>>>>> still change), and tried to convert it into BFCP. Some= parts are
>>>>> probably still missing (for example, I realized that I= forgot to
>>>>> add text regarding the SDP 'floorctrl' attribu= te) , and maybe the
>>>>> BFCP draft uses different terminology, but feel free t= o use it as a
>>>>>base:
>>>>>
>>>>> --------
>>>>>
>>>>> 9.=C2=A0 SDP Offer/Answer Procedures
>>>>>
>>>>> 9.1.=C2=A0 General
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0This section defines the SDP Offer/= Answer [RFC3264] procedures
>>>>>for
>>>>>=C2=A0 =C2=A0 =C2=A0negotiating and establishing an BFC= P connection.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0If the m- line proto value is '= TCP/TLS/BFCP ' or '
>>>>> UDP/TLS/BFCP ', each
>>>>>=C2=A0 =C2=A0 =C2=A0endpoint MUST provide a certificate= fingerprint, using the SDP
>>>>>=C2=A0 =C2=A0 =C2=A0'fingerprint' attribute [RF= C4145], if the endpoint supports, and
>>>>>is
>>>>>=C2=A0 =C2=A0 =C2=A0willing to use, a cipher suite with= an associated certificate.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0The authentication certificates are= interpreted and validated as
>>>>>=C2=A0 =C2=A0 =C2=A0defined in [RFC4572].=C2=A0 Self-si= gned certificates can be used
>>>>> securely,
>>>>>=C2=A0 =C2=A0 =C2=A0provided that the integrity of the = SDP description is assured as
>>>>>=C2=A0 =C2=A0 =C2=A0defined in [RFC4572].
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0NOTE: The procedures apply to a spe= cific m- line describing an
>>>>>BFCP
>>>>>=C2=A0 =C2=A0 =C2=A0connection.=C2=A0 If an offer or an= swer contains multiple m- line
>>>>>=C2=A0 =C2=A0 =C2=A0describing BFCP connections, the pr= ocedures are applied
>>>>>separately
>>>>>=C2=A0 =C2=A0 =C2=A0to each m- line.
>>>>>
>>>>> 9.2.=C2=A0 Generating the Initial SDP Offer
>>>>>
>>>>>=C2=A0 =C2=A0 When the offerer creates an initial offer= , the offerer:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the m- line proto = value is 'TCP/BFCP',
>>>>>'TCP/TLS/BFCP' or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'UDP/TLS/BFCP'= ;, associate an SDP setup attribute [Section
>>>>> X], with an
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 'actpass' value, wi= th the m- line;
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the m- line proto = value is 'TCP/BFCP' or
>>>>>'TCP/TLS/BFCP',
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associate an SDP '= ;connection' attribute [Section 8.4], with a
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'new' value, = with the m- line; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0In addition, if the offerer acts as= the floor control server,
>>>>> the
>>>>> offerer:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= confid' attribute [Section X], with
>>>>> the
>>>>> m- line;
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= userid' attribute [Section X], with
>>>>> the
>>>>> m- line;
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= floorid' attribute [Section X], with
>>>>> the
>>>>> m- line; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= label' attribute [Section X], with
>>>>> the
>>>>> m- line.
>>>>>
>>>>> 9.3.=C2=A0 Generating the SDP Answer
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0When the answerer receives an offer= , which contains an m- line
>>>>>=C2=A0 =C2=A0 =C2=A0describing a BFCP connection, if th= e answerer accepts the m- line
>>>>>=C2=A0 =C2=A0 =C2=A0it:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST insert a corresponding= m- line in the answer, with an
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 identical m- line proto val= ue [RFC3264]; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the m- line proto = value is 'TCP/BFCP',
>>>>>'TCP/TLS/BFCP' or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'UDP/TLS/BFCP'= ;, associate an SDP setup attribute [Section
>>>>> X], with an
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 'active' or 'pa= ssive' value, with the m- line;
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0In addition, if the answerer acts a= s the floor control server,
>>>>> the
>>>>> answerer:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= confid' attribute [Section X], with
>>>>> the
>>>>> m- line;
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= userid' attribute [Section X], with
>>>>> the
>>>>> m- line;
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= floorid' attribute [Section X], with
>>>>> the
>>>>> m- line; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST associate an SDP '= label' attribute [Section X], with
>>>>> the
>>>>> m- line.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0Once the answerer has sent the answ= er, the answerer:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the answerer is th= e 'active' endpoint, and if a TCP
>>>>> connection
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the m= - line is to be established (or
>>>>> re-established),
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initiate the establis= hing of the TCP connection; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the answerer is th= e 'active' endpoint, and if an
>>>>> TLS/DTLS
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 connection associated with = the m- line is to be established
>>>>>(or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 re-established), initiate t= he establishing of the TLS/DTLS
>>>>> connection
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (by sending a ClientHello m= essage).
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0If the answerer does not accept the= m- line in the offer, it MUST
>>>>>=C2=A0 =C2=A0 =C2=A0assign a zero port value to the cor= responding m- line in the
>>>>>answer.
>>>>>=C2=A0 =C2=A0 =C2=A0In addition, the answerer MUST NOT = establish an SCTP
>>>>>association, or
>>>>>=C2=A0 =C2=A0 =C2=A0a DTLS connection, associated with = the m- line.
>>>>>
>>>>> 9.4.=C2=A0 Offerer Processing of the SDP Answer
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0When the offerer receives an answer= , which contains an m- line
>>>>> with a
>>>>>=C2=A0 =C2=A0 =C2=A0non-zero port value, describing a B= FCP connection, the offerer:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the offer is the &= #39;active' endpoint, and if a TCP
>>>>> connection
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the m= - line is to be established (or
>>>>> re-established),
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initiate the establis= hing of the TCP connection; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 MUST, if the offerer is the= 'active' endpoint, and if an
>>>>>TLS/DTLS
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 connection associated with = the m- line is to be established
>>>>>(or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 re-established), initiate t= he establishing of the TLS/DTLS
>>>>> connection
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (by sending a ClientHello m= essage).
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0If the m- line in the answer contai= ns a zero port value, the
>>>>>offerer
>>>>>=C2=A0 =C2=A0 =C2=A0MUST NOT establish an TCP connectio= n, or a TLS/DTLS connection,
>>>>>=C2=A0 =C2=A0 =C2=A0associated with the m- line.
>>>>>
>>>>> 9.5.=C2=A0 Modifying the Session
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0When an offerer sends an updated of= fer, in order to modify a
>>>>>=C2=A0 =C2=A0 =C2=A0previously established BFCP connect= ion, it follows the
>>>>>procedures in
>>>>>=C2=A0 =C2=A0 =C2=A0Section 9.2, with the following exc= eptions:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the BFCP connection is c= arried on top of TCP, and unless
>>>>>the
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offerer wants to re-e= stablish an existing TCP connection, the
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offerer MUST associat= e an SDP connection attribute, with
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 an 'existing' value= , with the m- line; and
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the offerer wants to dis= able a previously established BFCP
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 connection, it MUST assign = a zero port value to the m- line
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with the BFCP co= nnection, following the procedures
>>>>>in
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC3264].
>>>>>
>>>>>
>>>>> ---------------
>>>>
>>>> That looks pretty straightforward and clear to me. Adding = the
>>>> floorctrl attribute will complicate it some, but I think i= ts still
>>>> manageable.
>>>>
>>>>>
>>>>> Q3b:
>>>>>
>>>>> The following sentence in 4583bis is a little confusin= g:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0"If the 'floorctrl' at= tribute is not used in an offer/answer
>>>>> exchange,
>>>>>=C2=A0 =C2=A0 =C2=A0by default the offerer and the answ= erer will act as a floor
>>>>>control
>>>>>=C2=A0 =C2=A0 =C2=A0client and as a floor control serve= r, respectively."
>>>>>
>>>>> Does this mean that the role may change every time an = endpoint -
>>>>> for whatever reason - sends an updated offer?
>>>>
>>>> Yes. This was inherited from RFC 4583, and it is the conse= quence of
>>>> the lenient normative language immediately before it.
>>>>
>>>>=C2=A0 =C2=A0 "Endpoints that use the offer/answer mod= el to establish BFCP
>>>>=C2=A0 =C2=A0 connections MUST support the 'floorctrl&#= 39; attribute.=C2=A0 A floor control
>>>>=C2=A0 =C2=A0 server acting as an offerer or as an answerer= SHOULD include this
>>>>=C2=A0 =C2=A0 attribute in its session descriptions.=C2=B2<= br> >>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Q4:
>>>>>>>
>>>>>>> For DTLS and Offer/Answer, there are a few ref= erences to RFC 5763
>>>>>>> here and there. But, I think it would be good = to have explicit
>>>>>>> text on the Offer/Answer considerations regard= ing DTLS -
>>>>>>> especially since there have been quite a bit o= f discussions about
>>>>>>>that lately.
>>>>>>
>>>>>> Are you suggesting a copy/paste of the relevant te= xt from RFC 5763
>>>>>> in additional to a reference, or is there an calci= fication of what
>>>>>> is provided in RFC 5763 that you added for SCTP th= at would be
>>>>>> helpful for this draft?
>>>>>
>>>>> In the SCTP-SDP draft I have the following text, which= is aligned
>>>>> with RFC 5763, but provides a little more details.
>>>>>
>>>>> You could probably use the text just by replacing the = proto field
>>>>> values with the ones used for BFCP.
>>>>>
>>>>> -------------
>>>>>
>>>>> 8.3.3.=C2=A0 TLS Role Determination
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0If the m- line proto value is '= SCTP/DTLS' or 'DTLS/SCTP', the
>>>>>=C2=A0 =C2=A0 =C2=A0'active/passive' status is = used to determine the TLS roles.
>>>>>=C2=A0 =C2=A0 =C2=A0Following the procedures in [RFC457= 2], the 'active' endpoint will
>>>>>=C2=A0 =C2=A0 =C2=A0take the TLS client role.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0Once a DTLS connection has been est= ablished, if the
>>>>>'active/passive'
>>>>>=C2=A0 =C2=A0 =C2=A0status of the endpoints change duri= ng a session, a new DTLS
>>>>>=C2=A0 =C2=A0 =C2=A0connection MUST be established.=C2= =A0 Therefore, endpoints SHOULD NOT
>>>>>=C2=A0 =C2=A0 =C2=A0change the 'active/passive'= status in subsequent offers and
>>>>>answers,
>>>>>=C2=A0 =C2=A0 =C2=A0unless they want to establish a new= DTLS connection.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0If the transport parameters or the = key fingerprints change, the
>>>>>=C2=A0 =C2=A0 =C2=A0endpoints MUST establish a new DTLS= connection.=C2=A0 In such case the
>>>>>=C2=A0 =C2=A0 =C2=A0'active/passive' status of = the endpoints will again be determined
>>>>>=C2=A0 =C2=A0 =C2=A0following the procedures in [RFC414= 5], and the new status will be
>>>>>=C2=A0 =C2=A0 =C2=A0used to determine the TLS roles ass= ociated with the new DTLS
>>>>>=C2=A0 =C2=A0 =C2=A0connection.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0NOTE: The procedure above is identi= cal to the one defined for
>>>>>SRTP-
>>>>>=C2=A0 =C2=A0 =C2=A0DTLS in [RFC5763].
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0NOTE: A new DTLS connection needs t= o be established if the
>>>>>transport
>>>>>=C2=A0 =C2=A0 =C2=A0parameters or the key fingerprints = change.
>>>>>
>>>>> ------------
>>>>
>>>> I am okay with this. Its a nice summary. Our previous refe= rence to
>>>> RFC 5763, section 5, did not address session modification.= This fixes
>>>>that.
>>>>
>>>>>
>>>>>> Q5:
>>>>>>
>>>>>> The draft does not define how to use BFCP within a= BUNDLE group.
>>>>>> That is fine, but I think it would be good to expl= icitly indicate
>>>>>> that.
>>>>>>
>>>>>> Yes. I'm thinking we need to point to
>>>>>> https://tools.ietf.org/html/= draft-ietf-mmusic-sdp-mux-attributes-0
>>>>>> 5#
>>>>>> page-
>>>>>> 28 for attributes defined in RFC 4583, and=C2=A0 d= efine=C2=A0 the mux
>>>>>> category for new attributes defined within this dr= aft.
>>>>>
>>>>> Defining the mux category is one thing.
>>>>>
>>>>> But, if you want to define usage of BFCP within a BUND= LE group, you
>>>>> also need to describe how BFCP is identified when bund= led with
>>>>> other protocols (RTP etc).
>>>>
>>>> I think this goes beyond what is needed for this draft. If= someone
>>>> wants to use BFCP with BUNDLE, they can define that usage.= Sounds
>>>> reasonable?
>>>>
>>>> Cheers,
>>>> Charles
>>>>
>>>>>
>>>>> 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



--
=
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepre= sence/
## to= mkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0htt= p://folk.uio.no/tomkri/
--001a11c23564e9218b050bfa6f51-- From nobody Mon Jan 19 13:55:54 2015 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 8AF871B2CC4; Mon, 19 Jan 2015 13:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9aWDlcXcOsjp; Mon, 19 Jan 2015 13:55:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EF21B2CBC; Mon, 19 Jan 2015 13:55:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Charles Eckel" To: alcoop@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119215552.28582.29371.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 13:55:52 -0800 Archived-At: Cc: iesg-secretary@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org Subject: [bfcpbis] Publication has been requested for draft-ietf-bfcpbis-rfc4582bis-12 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 21:55:53 -0000 Charles Eckel has requested publication of draft-ietf-bfcpbis-rfc4582bis-12 as None on behalf of the BFCPBIS working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ From nobody Wed Jan 28 14:06:18 2015 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 63F441A0379 for ; Wed, 28 Jan 2015 12:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 gAP75PxBB1Mv; Wed, 28 Jan 2015 12:42:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC801A005C; Wed, 28 Jan 2015 12:42:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128204232.20079.18998.idtracker@ietfa.amsl.com> Date: Wed, 28 Jan 2015 12:42:32 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 14:06:04 -0800 Subject: [bfcpbis] ID Tracker State Update Notice: X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 20:42:33 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ From nobody Thu Jan 29 13:20:07 2015 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 56C521A0174 for ; Thu, 29 Jan 2015 13:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 l_947pST41L8 for ; Thu, 29 Jan 2015 13:19:58 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B00E1A00ED for ; Thu, 29 Jan 2015 13:19:58 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7BC1320486 for ; Thu, 29 Jan 2015 16:19:56 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 29 Jan 2015 16:19:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:from:content-type:subject:message-id:date:to :mime-version; s=mesmtp; bh=9k/D7MAawBDSP87C8MDFFpqHY+s=; b=FBb2 CFUFzmiXlYEzdHuC/H0ii/1HMxnNUHZKsga5eCHNoaS2nnIJrUwhlYclUlAmereG JM4nwRWvp/KBFK3IL/G6XDzXvbhjO5VoW4UZSj+ykcs54LVUGQanytxG0Q/KeN8K ZfIHYSQgPSXrGQUab92wllyf1mHn10r4SnzxPcQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject :message-id:date:to:mime-version; s=smtpout; bh=9k/D7MAawBDSP87C 8MDFFpqHY+s=; b=pHZca2g9C3+M4/ZKjqjV3+qJlmJduUt4aJdsOuXjcV3xWUpM 1O+1L/5ES4yXteWi/ppAcVqVXFrlNO9+RKpP3k8J8BXvnFI3GgZ0MAw8LEnpaeva kSyS5SOUYN9pFz3vkRuvpxOLwLK2W99scSdRXIAh3MeSahs1RY9RJmsUt8s= X-Sasl-enc: tBVE9eZ17k8dgmoLOBOSzuHWpplEXUZUJKmilS9LvD+x 1422566395 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 840E66801C7 for ; Thu, 29 Jan 2015 16:19:55 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_C5D297A8-7B5D-44F3-9553-7CA3314094D6" Message-Id: Date: Thu, 29 Jan 2015 13:19:52 -0800 To: bfcpbis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 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, 29 Jan 2015 21:20:01 -0000 --Apple-Mail=_C5D297A8-7B5D-44F3-9553-7CA3314094D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed this draft in preparation for IETF LC. Overall the = document appears in good shape. I have a few questions and comments I=92d = like to discuss before issuing the IETF last call. I=92ve also included = some editorial nits that should be addressed together with any last call = comments. Comments and questions: =3D Section 5.1 =3D "If an endpoint receives a message with an=09 unsupported version field value, the receiving server MUST = send an=09 Error message with parameter value 12 (Unsupported Version) = to=09 indicate this.=94 This seems a little misleading since RFC 4582 didn=92t specify what to = do upon receipt of a message with a version other than 1. = Implementations that do not get upgraded to be compliant with 4582bis = (which could certainly account for some of those that will not support = version 2) will therefore never send the error specified here. This = seems like it should at least be noted given the MUST-level requirement. = The same applies in Section 13.7. =3D Section 7 =3D "BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94 I realize this requirement comes from RFC 4582, but I=92d like to = understand why it has not been updated to be consistent with more = current guidance on cipher suite selection (e.g., = https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4). =3D Sections 8, 8.1, 8.2 =3D It seems like the transaction ID requirements regarding = non-reuse/monotonically increasing IDs are re-stated multiple times = across these three sections, in slightly different ways, to the point = where it=92s not clear exactly what they are. It seems like they are: (1) Reliable transport, server-initiated transaction: ID is 0 (2) Unreliable transport, server-initiated transaction: ID MUST be = monotonically increasing (except for wrap-around) (3) Reliable transport, client-initiated transaction: ID MUST NOT be 0 = and MUST NOT be reused in another message from the client until a = response from the server is received for the transaction, but need not = be monotonically increasing (e.g., a lower, recently used ID could be = re-used once a response is received) (4) Unreliable transport, client-initiated transaction: ID MUST be = monotonically increasing (except for wrap-around) Is (3) the correct interpretation of the text in 8.1? If so, why not = just require IDs in all client-initiated transactions to be = monotonically increasing? =3D Section 9 (impacts Section 14 as well) =3D "BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP.=94 What are the cases where clients and servers do not need to be = authenticating each other? I know this requirement and the other = SHOULD-level requirements around use of TLS/DTLS are carried over from = RFC 4582, but I=92m concerned that they aren=92t as strong as they = should be. For a conference where the signaling traffic is authenticated = and confidentiality and integrity protected, why is it ok for the floor = control traffic not to be? Could these requirements be adjusted to = require use of TLS/DTLS at least in cases where the signaling is also = protected? =3D Section 14 =3D See the point above about ciphersuites. =93Non-null encryption=94 is not = a sufficient minimum baseline, and if the requirements change in Section = 7 they should be reflected here as well. Editorial nits to be resolved with LC comments: =3D Section 5.1 =3D =93The version field MUST be set to 1 when using BFCP over a reliable transport, i.e. as in [2].=94 I find it a little odd to reference the spec you=92re obsoleting in this = sentence, especially since BFCP over a reliable transport is completely = specified in this bis document. I would suggest dropping the i.e. = clause. "The version field MUST be set to 2 when using BFCP over an unreliable transport with the extensions specified in this document.=94 The bit about =93with the extensions specified in this document=94 is = extraneous and should be removed. "If an endpoint receives a message with an=09 unsupported version field value, the receiving server MUST = send an=09 Error message with parameter value 12 (Unsupported Version) = to=09 indicate this.=94 Use of the word =93server=94 here makes it sound as if only servers = could receive headers with unsupported versions. Should this be =93the = receiving endpoint=94? =3D Section 6.2.4 =3D "[23], Section 6.7 provides useful recommendations =85=94 The links in the references are not quite right. =3D Section 8.3.2 =3D s/when fires/when fired/ =3D Section 14 =3D s/high-jack/hijack/ =3D Section B.1 =3D "situation where multiple different and non-interoperable would co- exist in the market.=94 There is a word missing after =93non-interoperable."= --Apple-Mail=_C5D297A8-7B5D-44F3-9553-7CA3314094D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I have reviewed this draft = in preparation for IETF LC. Overall the document appears in good shape. = I have a few questions and comments I=92d like to discuss before issuing = the IETF last call. I=92ve also included some editorial nits that should = be addressed together with any last call = comments.

Comments and = questions:

=3D Section 5.1 =3D
"If= an endpoint receives a message with an
  =    unsupported version field value, the receiving = server MUST send an
     Error message with = parameter value 12 (Unsupported Version) to
  =    indicate this.=94

This = seems a little misleading since RFC 4582 didn=92t specify what to do = upon receipt of a message with a version other than 1. Implementations = that do not get upgraded to be compliant with 4582bis (which could = certainly account for some of those that will not support version 2) = will therefore never send the error specified here. This seems like it = should at least be noted given the MUST-level requirement. The same = applies in Section 13.7.


=3D= Section 7 =3D
"BFCP entities MUST support, at a minimum, = the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite = [6].=94

I realize this requirement comes from = RFC 4582, but I=92d like to understand why it has not been updated to be = consistent with more current guidance on cipher suite selection = (e.g., h= ttps://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4).
=


=3D Sections 8, 8.1, 8.2 = =3D
It seems like the transaction ID requirements regarding = non-reuse/monotonically increasing IDs are re-stated multiple times = across these three sections, in slightly different ways, to the point = where it=92s not clear exactly what they are. It seems like they = are:

(1) Reliable transport, server-initiated = transaction: ID is 0
(2) Unreliable transport, = server-initiated transaction: ID MUST be monotonically increasing = (except for wrap-around)
(3) Reliable transport, = client-initiated transaction: ID MUST NOT be 0 and MUST NOT be reused in = another message from the client until a response from the server is = received for the transaction, but need not be monotonically increasing = (e.g., a lower, recently used ID could be re-used once a response is = received)
(4) Unreliable transport, client-initiated = transaction: ID MUST be monotonically increasing (except for = wrap-around)

Is (3) the correct interpretation = of the text in 8.1? If so, why not just require IDs in all = client-initiated transactions to be monotonically = increasing?


=3D Section 9 = (impacts Section 14 as well) =3D
"BFCP clients SHOULD = authenticate the floor control server before
  =  sending any BFCP message to it or accepting any BFCP message from = it.
   Similarly, floor control servers SHOULD = authenticate a client before
   accepting any BFCP = message from it or sending any BFCP message to = it.

   BFCP supports TLS/DTLS mutual = authentication between clients and
   floor control = servers, as specified in Section 9.1.  This is the
  =  RECOMMENDED authentication mechanism in = BFCP.=94

What are the cases where clients and = servers do not need to be authenticating each other? I know this = requirement and the other SHOULD-level requirements around use of = TLS/DTLS are carried over from RFC 4582, but I=92m concerned that they = aren=92t as strong as they should be. For a conference where the = signaling traffic is authenticated and confidentiality and integrity = protected, why is it ok for the floor control traffic not to be? Could = these requirements be adjusted to require use of TLS/DTLS at least in = cases where the signaling is also = protected?


=3D Section 14 = =3D
See the point above about ciphersuites. =93Non-null = encryption=94 is not a sufficient minimum baseline, and if the = requirements change in Section 7 they should be reflected here as = well.


Editorial nits to be = resolved with LC comments:

=3D Section 5.1 = =3D
=93The version field MUST be set to 1 when using BFCP over a = reliable
   transport, i.e. as in = [2].=94

I find it a little odd to reference the = spec you=92re obsoleting in this sentence, especially since BFCP over a = reliable transport is completely specified in this bis document. I would = suggest dropping the i.e. clause.

"The version = field MUST be set to 2 when
   using BFCP over an = unreliable transport with the extensions specified
  =  in this document.=94

The bit about =93with = the extensions specified in this document=94 is extraneous and should be = removed.

"If an endpoint receives a message = with an =
    unsupported version field = value, the receiving server MUST send an
    = Error message with parameter value 12 (Unsupported Version) to =
    indicate = this.=94

Use of the word =93server=94 here = makes it sound as if only servers could receive headers with unsupported = versions. Should this be =93the receiving = endpoint=94?

=3D Section 6.2.4 = =3D
"[23], Section 6.7 provides useful recommendations = =85=94

The links in the references are not = quite right.

=3D Section 8.3.2 = =3D
s/when fires/when = fired/

=3D Section = 14 =3D
s/high-jack/hijack/

=3D Section = B.1 =3D
"situation where multiple different and non-interoperable = would co-
   exist in the = market.=94

There is a word missing after = =93non-interoperable."
= --Apple-Mail=_C5D297A8-7B5D-44F3-9553-7CA3314094D6--