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

From: Tom Kristensen <[email-masked]>
Date: Tue, 6 Jan 2015 12:52:10 +0100

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) <[email-masked]>
wrote:

> On 12/11/14, 10:38 AM, "Christer Holmberg"
> <[email-masked]> 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 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?
> >>
> >> 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 attributes
> >should be defined in dedicated (sub-) sections.)
>
> Sounds good!
>
> Cheers,
> Charles
>
>
> >
> >Regards
> >
> >Christer
> >
> >
> >
> >
> >> 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
> >>>
> >>> -----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:
> >>>> 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.
> >>>>>>
> >>>>>> 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
> >>>> ³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-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 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].
> >>>>>
> >>>>>
> >>>>> ---------------
> >>>>
> >>>> 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.²
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> 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 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.
> >>>>>
> >>>>> ------------
> >>>>
> >>>> 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-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
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/bfcpbis
> >>>>
> >>>
> >>> _______________________________________________
> >>> bfcpbis mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/bfcpbis
> >>>
> >>> _______________________________________________
> >>> bfcpbis mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/bfcpbis
> >>
> >
>
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/