Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 8 Dec 2014 19:59:23 +0000

Hi Christer,

Thanks for the thorough review and insightful comments. I’ve forwarded to the BFCP list, adding a few comments (as an individual) inline. I expect others to comment as well. More inline.

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Sunday, December 7, 2014 at 3:42 AM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>
Subject: Comments on draft-ietf-bfcpbis-rfc4583bis-10

Hi Charles,

My comments on RFC4583bis.

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.

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”.

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-negotiation-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 understand. For a new reader, I think your suggested change will help, so I’m in favor of it.

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?

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-05#page-28 for attributes defined in RFC 4583, and  define  the mux category for new attributes defined within this draft.

Cheers,
Charles

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Dec 2014 08:17:03 +0000

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.
>

Please look at section 6 in https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt

>> 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".
>> 
>> Q3:
 >
> 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-negotiation-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 understand. 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, and is
   willing to use, a cipher suite with an associated certificate.

   The authentication certificates are interpreted and validated as
   defined in [RFC4572].  Self-signed certificates can be used securely,
   provided that the integrity of the SDP description is assured as
   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- line
   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 MUST
   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, the 
       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 BFCP
      connection, it MUST assign a zero port value to the m- line
      associated with the BFCP connection, following the procedures in
      [RFC3264].

---------------

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?

>> 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.
>

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 will
   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 NOT
   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 the
   'active/passive' status of the endpoints will again be determined
   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.

------------
 
> Yes. I'm thinking we need to point to https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05#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).

Regards,

Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 9 Dec 2014 23:53:49 +0000

On 12/9/14, 12:17 AM, "Christer Holmberg" <[email-masked]>
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.
>>
>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 ³cat²
as an example):

---
   Name: cat

   Value: cat-value

   Usage Level: session

   Charset Dependent: no

   Syntax:

      cat-value = category
      category = byte-string
        ; Note: syntax is vague because usage is not understood

   Example:

      a=cat: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¹t 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-negotiation-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
>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:
>
>--------
>

That looks pretty straightforward and clear to me. Adding the floorctrl
attribute will complicate it some, but I think its still manageable.

>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.²

>
>
>
> 
>>> 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.
>

I am okay with this. Its a nice summary. Our previous reference 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 explicitly indicate that.
>>
>> Yes. I'm thinking we need to point to
>>https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05#page-
>>28 for attributes defined in RFC 4583, and  define  the mux category for
>>new attributes defined within this draft.
>
>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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Dec 2014 11:03:35 +0000

Hi,

> This section makes consistent use of the following template (using ³cat² as an example):
>
> ---
>   Name: cat
>
>   Value: cat-value
>
>   Usage Level: session
>
>   Charset Dependent: no
>
>   Syntax:
>
>      cat-value = category
>      category = byte-string
> I don¹t 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.

That is how SDP attributes currently are supposed to be defined and registered, and I think everyone defining/registering attributes should be aligned. 

If someone has issues with the current proposal, I think it should be raised on the MMUSIC list.

--------------

>>>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.

I would be ok with subsections.

--------------

>>> 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
>>comfortable with the existing document structure and my familiarity 
>>with it make it straightforward  for me to understand. For a new 
>>reader, I think your suggested change will help, so I'm in favor of 
>>it.
>
>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:

...

> That looks pretty straightforward and clear to me. Adding the floorctrl attribute will complicate it some, but I think its still manageable.

Good.

--------------

> Yes. This was inherited from RFC 4583, and it is the consequence of the lenient normative language immediately before it.
>

If the role will change whenever the other peer is sending an offer, I think you should add some text to make that clear.

But, is that really what you want?

Another option would be to say that the roles are determined only when the BFCP connection is established/re-established.

But, I'll let it up to you to decide what you want :)

--------------

>>>> 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.
>>>

...

> I am okay with this. Its a nice summary. Our previous reference to RFC 5763, section 5, did not address session modification. This fixes that.

Good.

--------------

>>>28 for attributes defined in RFC 4583, and  define  the mux category 
>>>for new attributes defined within this draft.
>>
>>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?

That is fine. But, if it goes beyond the scope of the draft, I think it would be good to explicitly indicate it, so that anyone who might want to use BFCP with BUNDLE knows that a separate definition is needed.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Dec 2014 09:56:09 -0500

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 says.

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:
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 11:42:38 +0000

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:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 10. joulukuuta 2014 16:56
To: [email-masked]
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 says.

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:
>>>> discussed on the MMUSIC list, and Paul K can give more information 
>>>> if needed.
>>>
> <
> I don¹t 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:
>>>>
> 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:
>>>
>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-
>>> 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 understand. 
>>> For a new reader, I think your suggested change will help, so I'm in 
>>> favor of it.
>>
> That looks pretty straightforward and clear to me. Adding the 
> floorctrl attribute will complicate it some, but I think its still manageable.
>
>>
>> Q3b:
>>
> Yes. This was inherited from RFC 4583, and it is the consequence of 
> the lenient normative language immediately before it.
>
>>>> 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.
>>
>>> 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.
>>>
> 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
>>
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 11 Dec 2014 18:27:51 +0000

(as an individual)

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 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 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?

Cheers,
Charles

On 12/11/14, 3:42 AM, "Christer Holmberg" <[email-masked]>
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
>
>there is clarity in the syntax of attributes, and that developers reading
>those will know what they are expected to do to parse them.
>
>OTOH, it does imply that the attribute names it defines should be matched
>in a case-insensitive way, which is contrary to what 4566 says.
>
>sections where the attribute syntax is currently defined, and then simply
>cross reference those definitions from the IANA Considerations section.
>
>	Thanks,
>	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Dec 2014 13:34:29 -0500

> 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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 18:38:02 +0000

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 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 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?
>

I'm fine having the current structure too :)

(However, as I indicated in another comment, I still think the attributes should be defined in dedicated (sub-) sections.)

Regards

Christer

>> 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
>>
>> 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.
>>
>> simply cross reference those definitions from the IANA Considerations section.
>>
>> 	Thanks,
>> 	Paul
>>
>>>>>> 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.
>>>>>
>>>>>> 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:
>>>>>
>>>>> each section defining an SDP attribute include a few sentences 
>>>>> about Offer/Answer).
>>>>>
>>>>> because I am comfortable with the existing document structure and 
>>>>> my familiarity with it make it straightforward for me to understand.
>>>>> 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:
>>>>
>>>> --------
>>>>
>>>>     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.
>>>>
>>>>     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.
>>>>
>>>> Does this mean that the role may change every time an endpoint - 
>>>> for whatever reason - sends an updated offer?
>>>
>>>>>> 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.
>>>>>
>>> I am okay with this. Its a nice summary. Our previous reference to 
>>> RFC 5763, section 5, did not address session modification. This fixes that.
>>>
>>>>
>>>>> Q5:
>>>>>
>>>>> 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.
>>>>
>>>> also need to describe how BFCP is identified when bundled with 
>>>> other protocols (RTP etc).
>>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 11 Dec 2014 18:50:25 +0000

On 12/11/14, 10:38 AM, "Christer Holmberg"
<[email-masked]> wrote:

>(However, as I indicated in another comment, I still think the attributes
>should be defined in dedicated (sub-) sections.)

Sounds good!

Cheers,
Charles