Subject: Re: [AVTCORE] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 5 Jul 2016 09:27:38 -0700

Hi Magnus,

We just published version -10.  See below for some comments.

On 06/28/2016 07:35 AM, Magnus Westerlund wrote:
> Authors and WGs,
> 
> In my review for the publication writeup I did spot some issues in the draft. Please consider the following issues:
> 
> 1. Abstract: With the addition of the ZRTP the abstract should benefit from being updated. The ZRTP protocol being possible to multiplex is missing as well as that there are now 4 issues.

Fixed.

> 
> 2. Abstract contains [ref] to RFC 5764. This is an ID nit.

Fixed.

> 
> 3. Section 1. The introduction is not explicitly saying that it updates RFC 5764. I think that can be put as a sentence after:
> 
>    This is achieved by
>    modifying the IANA registries with instructions for coordination
>    between the protocols at risk.

We incorporated this in that sentence and also added it into the abstract.

> 
> 4. Reference ID-nits:
> 
>   == Outdated reference: A later version (-31) exists of
>      draft-ietf-mmusic-sdp-bundle-negotiation-23

Fixed.

> 
> 5. Section 2:
> 
> ID-nits complains about the modified boilerplate for the RFC2119 text. First of all one usually don't cut down the list to only the used ones. The requirement on all caps ones I am very divided about. I do have a preference for unmodified boilerplate, this as I otherwise have to explain in the write-up the ID-nit.

Fixed.

> 
> 6. Section 6:
> 
>    In order to prevent future documents from assigning values from the
>    unused range to a new protocol, this document modifies the RFC 5764
>    demultiplexing algorithm to properly account for TURN channels by
>    allocating the values from 64 to 79 for this purpose.
> 
> I think this text fails to be explicit about that this restricts the TURN Channel space to a more limited set of possible channels when the TURN client does the channel binding request. Thus affecting the TURN channel allocation algorithm in the client implementations, at least when used in combination of muxing.

Fixed.

> 
> Based on this and the fact that this specification changes the IANA registrations performed by RFC5766, I think this document to have "Updates" for RFC5766 also. So please add that in header, abstract and introduction.

Based on our understanding and looking at other RFCs, just updating an IANA registry does not imply a update to the core specification, so we did not made that change.

> 
> 7. Updates RFC5389:
> 
> Looking at the impact also on the STUN protocol I would also think that this requires and "Updates" also for RFC 5389.
> 

Based on the argument above, we do not think that this warrants an "Updates" status.

> 
> 8. Section 10.3:
> 
> The IANA registry name is not the correct one. The IANA page says that the registry name is:
> 
> Traversal Using Relays around NAT (TURN) Channel Numbers
> http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#turn-channel
> 
> Please update.

Fixed.

> 
> 9. Section 12.2:
> 
> The reference to ZRTP [RFC6189] is likely in the wrong category, at the same time moving this to a normative one creates a downref. I guess it one that has to be accepted in this case. I suggest that you move it to the normative references.

We are keeping it informative for now, but we will forward the discussion with the AD to the mailing-list as requested.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 6 Jul 2016 10:47:22 +0200

Hi,

The call has now ended. The authors have updated the document to address 
the issues I raised. The writeup has been uploaded and I have requested 
publication.

If anyone has late feedback, please provide it. We will address it at 
the latest at the end of the IETF last call, most likely earlier.

Cheers

Magnus Westerlund
Chair AVTCORE WG and Document Shepherd.

Den 2016-06-28 kl. 15:04, skrev Magnus Westerlund:
> WGs,
>
> I as WG chair earlier made a mistake in failing to include the relevant
> WGs in our previous WG last call. Thus I would like to make a one week
> confirmation call on the content of
> draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request.
>
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/
>
>
> TRAM WG: Please check that you are okay with the restrictions and
> updates to the TURN channel allocations as well as STUN Method
> restrictions.
>
> TLS WG: I believe you are satisfied with the impact on the TLS IANA
> registry after previous discussions, but you are welcome to confirm this.
>
> ICE: For your information as this impacts protocol mechanism your are
> dependent on.
>
> MMUSIC: For your information due to some notes in regards to BUNDLE and
> RFC7345.
>
> Please provide any feedback by 5th of July.
>
> cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------