Subject: [MMUSIC] Éric Vyncke's No Objection on draft-ietf-mmusic-ice-sip-sdp-36: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sat, 13 Jul 2019 08:30:58 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-36: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document; I just have a couple of comments
and some nits. All easy to fix.

Regards,

-éric

== COMMENTS ==

-- Section 3.2.4 --

Please add reference to STUN.

-- Section 3.2.6 --

The example would benefit by having an IPv6 candidate. Same applies for section
4.2.

-- Section 4.1 --

It is not clear to me whether FQDN are valid: they are accepted by the grammar
but they are rejected in the text.

== NITS ==

-- Abstract --

Not sure whether the sentence about obsoleting RFC 5245 has its place in the
abstract.

-- Section 3.4.1.1.1. --

Please use quotes around "0.0.0.0" and "::".

-- section 9.1.1 --

Typo in the contact email "[email-masked]"

-- Appendix A --

IPv6 addresses are usually all lower case :-)

---

From: Roman Shpount <[email-masked]>
Date: Sat, 13 Jul 2019 19:48:40 -0400

Hi Éric,

Regarding section 4.1 and FQDN: Based on this draft FQDN in ICE candidate
is allowed but such candidates must not be generated and these candidates
must be ignored when received. The intent is to define procedures for
generating and handling such candidates in the future draft. Current
language seemply makes sure FQDN candidates can be added in the future with
minimal interop issues.

Roman Shpount

On Sat, Jul 13, 2019, 11:31 Éric Vyncke via Datatracker <[email-masked]>
wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2019 17:13:14 -0500

Just one quick comment...

> The example would benefit by having an IPv6 candidate. Same applies 

I'm usually the one who makes this comment, and I explicitly decided not 
to on this document. :)

The point of the examples in this document is to demonstrate the 
presence of a NAT. While they could be replaced with NPTv6 examples (or 
other examples of IPv6 address translation), I think that doing so would 
not be in the spirit of the IAB statement on IPv6, even if stateless.

/a

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 16 Jul 2019 19:59:26 -0700

Thanks Éric for the review.  Please see inline.

Cheers
Suhas

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

[Suhas] I tend to agree with Adam here. We do have an example with IPv6
address but
we let this one stay as it is for the reasons Adam mentioned.

> but they are rejected in the text.
[Suhas] Roman eloquently clarified the reasoning here. There was a long
discussion
threads on this very topic to include/not include and define the exact FQDN
resolution mechanisms as part of ICE candidate exchange. Eventually we
decided to
go with what we have as the best compromise since FQDN resolution and
dealing with
edge cases across v4/v6 networks were outside the scope of this
specification.

> Not sure whether the sentence about obsoleting RFC 5245 has its place in

[Suhas] Since original RFC5245 is spit into 2 drafts (RFC8445 and
ice-sip-sdp) ,
this draft also obsoletes RFC5245.

> Please use quotes around "0.0.0.0" and "::".

[Suhas] Will do.

> Typo in the contact email "[email-masked]"

[Suhas] Thanks for catching this. will do

> IPv6 addresses are usually all lower case :-)

[suhas]  Ah ! my bad . I will fix them .

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 17 Jul 2019 06:02:53 +0000

Adam,

Good point, let's ignore this COMMENT

-éric

On 17/07/2019, 00:13, "Adam Roach" <[email-masked]> wrote:

    
    
    /a

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 17 Jul 2019 06:49:53 +0000

Suhas

Thank you very much for the time taken to reply. Your replies do make sense

Regards,

-éric

From: Suhas Nandakumar <[email-masked]>
Date: Wednesday, 17 July 2019 at 04:59
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "Flemming Andreasen (fandreas)" <[email-masked]>, "[email-masked]" <[email-masked]>, mmusic WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] Éric Vyncke's No Objection on draft-ietf-mmusic-ice-sip-sdp-36: (with COMMENT)

Cheers
Suhas

On Sat, Jul 13, 2019 at 8:31 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-36: No Objection

Regards,

-éric

== COMMENTS ==

-- Section 3.2.4 --

-- Section 3.2.6 --

[Suhas] I tend to agree with Adam here. We do have an example with IPv6 address but
we let this one stay as it is for the reasons Adam mentioned.

-- Section 4.1 --

[Suhas] Roman eloquently clarified the reasoning here. There was a long discussion
threads on this very topic to include/not include and define the exact FQDN
resolution mechanisms as part of ICE candidate exchange. Eventually we decided to
go with what we have as the best compromise since FQDN resolution and dealing with
edge cases across v4/v6 networks were outside the scope of this specification.

== NITS ==

-- Abstract --

[Suhas] Since original RFC5245 is spit into 2 drafts (RFC8445 and ice-sip-sdp) ,
this draft also obsoletes RFC5245.

-- Section 3.4.1.1.1. --

[Suhas] Will do.

-- section 9.1.1 --

Typo in the contact email "[email-masked]<mailto:[email-masked]>"

-- Appendix A --

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic