Re: [bfcpbis] Eric Rescorla's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

Eventhough Ekr changed his position from DISCUSS to No Objection, he did have some COMMENTs in his initial review. They can not be seen in the datatracker anymore, but I will still address them.
    
    > S 5.3.
    >      The SDP Offer/Answer procedures for the 'confid' attribute are
    >      defined in Section 10.
    >   
    >   5.3.  SDP 'userid' Attribute
    >   
    >      This section defines the SDP userid' media-level attribute.  The
    >
    > Are there any security considerations around this attribute?
    
The userid does identify a participant (however, it does not contains any user information), but I think the security considerations associated with it belong to 4582bis.

---
    
    > S 5.5.
    >      'bfcpver' attribute in offers and answers.  The attribute value, if
    >      present, MUST be in accordance with the definition of the Version
    >      field in [I-D.ietf-bfcpbis-rfc4582bis].  If the attribute is not
    >      present, endpoints MUST assume a default value in accordance with
    >      [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
    >      the default attribute value is "1", and when used over an unreliable
    >
    > Just for clarity: UDP over TURN-TCP is an unreliable transport, right?
    
I would assume so, but I guess that question is not BFCP specific?

---    

    > S 7.1.
    >      deliver a BFCP message and times out, the endpoint that attempted to
    >      send the message (i.e., the one that detected the TCP timeout) MUST
    >      send an offer in order to re-establish the TCP connection.
    >   
    >      Endpoints that use the offer/answer mechanism to negotiate TCP
    >      connections MUST support the 'setup' and 'connection' attributes.
    >
    > You probably need a reference here.
    
I will add a reference.

---    

    >S 10.1.
    >   
    >      o  MUST associate an SDP 'floorid' attribute (Section 5.4) with the
    >         'm' line; and
    >   
    >      o  MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm'
    >         line of each BFCP-controlled media stream.
    >
    > We managed to mostly purge "associate" from BUNDLE. Can we do it here
    > too?

    We could, but I'd prefer not to. It is not a widely used as in BUNDLE, so my suggestion is we keep it.
    
---
    
    > S 10.2.
    >      o  MUST insert a corresponding 'm' line in the answer, with an
    >         identical 'm' line proto value [RFC3264]; and
    >   
    >      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
    >         answerer only indicates support of BFCP versions also supported by
    >         the offerer; and
    >
    > Is this an odd way of saying you must subset what the offer contained?
    
    Yes - assuming including the same set of values would still count as a subset.

    If so, we could say:

    "The versions indicated by the answer MUST be a subset of the versions indicated by the offerer in the corresponding offer."
    
Regards,

Christer