Subject: RE: Review of draft-ietf-clue-rtp-mapping-10

From: Roni Even <[email-masked]>
Date: Wed, 11 Jan 2017 08:05:52 +0000

Hi,
Thanks for the review
Inline
Roni

> -----Original Message-----
> From: =?utf-
> 8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj?=
> @ietfa.amsl.com [mailto:=?utf-
> 8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj?=
> @ietfa.amsl.com]
> Sent: יום ג 03 ינואר 2017 13:50
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Review of draft-ietf-clue-rtp-mapping-10
> 
> Reviewer: Jürgen Schönwälder
> Review result: Has Nits
> 
> I do not see any major OPS related issues. While reading the document, I
> found a number of things the authors should look into:
> 
> - Consider to expand SDP and perhaps CLUE in the abstract
[Roni Even] OK
> 
> - Having both CaptureId and CaptureID in 5.1 is a bit confusing (since
>   the two identifiers only differ by the capitalization of the last
>   character)
[Roni Even] I will change it
> 
> - Both nXML mode in emacs and xmlint indicate that the xml in section
>   6 is invalid. Please check. (It could also be an issue with my tools
>   and the namespaces but then also the indentation looks at least
>   somewhat surprising.
[Roni Even] This are partial examples from the clue data model document just to show the relevant part. They were not meant to be valid xml , I can add text to explain this
> 
> - Is the RFC editor expected to	replace XX in the drawing in section
>   5.1 with the value assigned for TBA? If so, I think this needs to be
>   documented somewhere.
[Roni Even] OK
> 
> - Is [email-masked]' is a long term stable identifier
>   for the 'Contact' field of the RTP SDES Compact Header Extensions
>   subregistry?
[Roni Even] I will provide a better email address
> 
> - Security considerations, last	paragraph: What	is 'a lot of trust'?
>   Why is the SHOULD not	a MUST?
[Roni Even] I agree, it is also a passive language
Old text
"In multi-party communication scenarios using RTP Middleboxes, a lot of trust is placed on these middleboxes to preserve the sessions security"
New text
"In multi-party communication scenarios using RTP Middleboxes; these middleboxes are trusted to preserve the sessions security"

As for the "SHOULD maintain" it may depend on application policies (for example allowing users with different security levels into a multipoint conference)

> 
> - s/CaptureIDis/CaptureID is/g
[Roni Even] OK
> 
> - According to idnits, there are RFCs listed in the references that
>   are not cited in the text; please pay attention to idnits reports
[Roni Even] OK

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Jan 2017 23:09:09 +0200

> Summary: Ready with nits.
> 
> Major issues: 0
> 
> Minor issues: 0
> 
> Nits/editorial comments:
> - S1: s/source of Media, such as from one or more Capture
> Devices./source of Media from one or more Capture Devices./
> - S1: s/SIP offer answer/SIP Offer/Answer model/
> - S1: s/recommendations, for the CLUE architecture, about
> how/recommendations for the CLUE architecture on how/
> - S4: s/have main and slides video sources can/have a primary video
> source and a slide video source can/
> - S5: s/CaptureIDis/CaptureID is/

Thanks for your review, Vijay!

Authors, I didn’t see changes related to these observations
in the new document versions… were the comments missed?
While they were small editorial comments, they all made sense
to me at least ;-)

I have balloted no-objection for this document on tomorrow’s
IESG telechat.

Jari