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

[Eric Rescorla <[e-mail]>]

On Mon, Dec 3, 2018 at 6:01 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> ---
>
> >>> 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.
>
> Do you think we need to add some text about it?
>
> Related to that, if ICE is used, if both UDP and TCP candidates are
> offered, endpoints might not know what kind of transport will eventually be
> selected. Perhaps there should be a note about that?
>
> Something like:
>
> "Note: When ICE is used, where the candidates represent both reliable and
> unreliable transports, the ICE process will determine what type of
> transport will eventually be used."
>

Well, ICE can flip-flop the transport, so I think if you have anything
other than ICE-TCP (which is to say anyone who uses ICE) then you have to
assume it's unreliable

-Ekr



---
>
> >>> 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 not willing to go to the mat over it.
>
> I will see what I can do.
>
> ---
>
>     >>> 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"
>
>    I will modify as suggested.
>
> Regards,
>
> Christer
>
>
>