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

[Roman Shpount <[e-mail]>]

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

> >>>>>>> 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
> >>
> >> My point was that when you send the offer, and set the 'bfcpver'
> attribute value, if you use ICE you may not yet know whether the transport
> will eventually be reliable
> >> or unreliable (if you offer candidates for both reliable and unreliable
> transports).
> >> I guess we could say that the attribute value must match the transport
> indicated in the 'm' line. That way things will be correct if the remote
> peer does not support ICE.
> >
> > i don't really know what this attribute is used for so it's hard for me
> to say.
> >
> > Can you explain what it does?
>
> It's used to negotiate the BFCP version. The default values are based on
> whether the transport is reliable or unreliable, which is a little strange,
> but 4583bis endpoints will always explicitly include it so there is no
> issues. I withdraw my comment :)
>
>
Any BFCP protocol version used with ICE is always considered unreliable.
ICE-TCP is unreliable since ICE-TCP is not necessarily end-to-end. The only
reliable protocols are TLS/BFCP and TCP/BFCP, neither of which can be used
with ICE.

Regards,
_____________
Roman Shpount