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

[Eric Rescorla <[e-mail]>]

On Sun, Dec 2, 2018 at 11:29 AM Christer Holmberg <
[e-mail]> wrote:

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

OK.

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

Sorry, what I mean is "does BFCP count it as an unreliable transport". I
agree it is unreliable.



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

I would prefer to lose it, but I'm notwilling to go to the mat over 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."
>

Yes, though perhaps the term "proper subset" is not widely known outside US
technical circles, so we could say "must be the same or a subset of"

-Ekr


> Regards,
>
> Christer
>
>