Re: [MMUSIC] Last chance to comment [Re: I-D Action: draft-ietf-mmusic-ice-sip-sdp-27.txt] - Text on ICE PAC

[Roman Shpount <[e-mail]>]

We cannot remove FQDN without breaking compatibility with RFC 5245. Based
on RFC 5245, FQDN can be legally specified in connection-address. FQDN
handling there is nonsensical, but grammar still allows it, so the safest
option is to allow FQDN in connection-address but ignore it.

Regards,
_____________
Roman Shpount


On Mon, May 20, 2019 at 6:31 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> First, if we are going to remove support of FQDN (see other thread), there
> is no need to mention it.
>
>
>
> Second, I don’t think you need to repeat so much of what is defined in ICE
> PAC (which may even still change). I suggest something like:
>
>
>
> “[draft-holmberg-ice-pac] provides guidance on finding working candidate
> pairs, and is useful to prevent premature declaration of ICE failure
>
> e.g., if the peer has not provided any candidates, or if all provided
> candidates have failed or have been discarded.”!
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
> *From: *Suhas Nandakumar <[e-mail]>
> *Date: *Monday, 20 May 2019 at 22.27
> *To: *Christer Holmberg <[e-mail]>
> *Cc: *Flemming Andreasen <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: [MMUSIC] Last chance to comment [Re: I-D Action:
> draft-ietf-mmusic-ice-sip-sdp-27.txt] - Text on ICE PAC
>
>
>
> Thanks Christer. I agree with the intent here.
>
>
>
> How about this version
>
>
>
>    “In certain scenarios when either no candidates were provided in the
>
>    offer or all the provided candidates were discarded (say, due to
>
>    unsupported address type or FQDN name resolution failure), the
>
>    answerer MAY treat it as an immediate ICE processing failure or
>
>    choose to wait for the peer reflexive candidates
>
>    to arrive to perform the connectivity checks
>
>    (see [draft-holmberg-ice-pac]. However, If no peer reflexive candidates
>
>    arrive until the connectivity checks timesout, the ICE
>
>    processing is considered as failure."
>
>
>
> On Mon, May 20, 2019 at 1:08 PM Christer Holmberg <
> [e-mail]> wrote:
>
> Hi,
>
>
>
> The new text says:
>
>
>
>    “In certain scenarios when either no candidates were provided in the
>
>    offer or all the provided candidates were discarded (say, due to
>
>    unsupported address type or FQDN name resolution failure), the
>
>    answerer MUST NOT consider this as immediate ICE processing failure
>
>    but instead MUST wait for the peer reflexive candidates to arrive to
>
>    carryout the connectivity checks or eventually time out on the
>
>    connectivity checks (see [draft-holmberg-ice-pac]).”
>
>
>
> I don’t think we shall have these MUST NOT and MUST.
>
>
>
> As I have commented in the ICE WG, ICE PAC only gives guidance on how long
> to wait before declaring ICE failure, but an agent is still allowed to
> declare ICE failiure whenever it wants without being non-compliant with the
> spec.
>
>
>
> Also, since ICE PAC is generic ICE, I don’t think ice-sip-sdp shall add
> any normative text in addition to what is already included in ICE PAC.
>
>
>
> However, I do agree that referencing ICE PAC is a good idea, but perhaps
> it’s enough to say that ICE PAC gives guidance.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From: *mmusic <[e-mail]> on behalf of Flemming Andreasen <
> [e-mail]>
> *Date: *Monday, 20 May 2019 at 17.35
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[MMUSIC] Last chance to comment [Re: I-D Action:
> draft-ietf-mmusic-ice-sip-sdp-27.txt]
>
>
>
> Greetings MMUSIC
>
> We believe this version resolves all outstanding issues. This will be the
> last chance to comment before we submit the document for Publication
> Request. If you have any comments, please make sure to provide them to the
> authors and the MMUSIC mailing list no later than Friday May 25.
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
> On 5/19/19 12:43 AM, Suhas Nandakumar wrote:
>
> Version 27 has editorial changes for using the term connection address
> instead of IP Address.
>
>
>
> Please let us know if you have any questions
>
>
>
> Cheers
>
> Suhas
>
>
>
> On Sat, May 18, 2019 at 9:42 PM <[e-mail]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiparty Multimedia Session Control WG
> of the IETF.
>
>         Title           : Session Description Protocol (SDP) Offer/Answer
> procedures for Interactive Connectivity Establishment (ICE)
>         Authors         : Marc Petit-Huguenin
>                           Suhas Nandakumar
>                           Ari Keranen
>         Filename        : draft-ietf-mmusic-ice-sip-sdp-27.txt
>         Pages           : 42
>         Date            : 2019-05-18
>
> Abstract:
>    This document describes Session Description Protocol (SDP) Offer/
>    Answer procedures for carrying out Interactive Connectivity
>    Establishment (ICE) between the agents.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-27
> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-27
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-27
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>