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: ops-dir@xxxxxxxx > Cc: clue@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-clue-rtp-mapping.all@xxxxxxxx > 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 'roni.even@xxxxxxxxxxxxxxxxx' 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 >