On 2013-11-20 19:23, Jari Arkko wrote: > Thank you for your extensive review and Magnus thank you for > addressing the issues. Are you tracking the nits from below?
Yes, I will edit them in as part of the update taking care of the discuss the document has gotten. /Magnus > > I have balloted no-obj. > > Jari > > On Nov 19, 2013, at 6:57 PM, Elwyn Davies <elw...@dial.pipex.com> > wrote: > >> I have been selected as an additional General Area Review Team >> (Gen-ART) reviewer for this draft (for background on Gen-ART, >> please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please wait for direction from your document shepherd or AD before >> posting a new version of the draft. >> >> Document: draft-ietf-mmusic-rfc2326bis-38.txt Reviewer: Elwyn >> Davies Review Date: 2013/11/19 IESG Telechat date: 2013/11/21 >> >> Summary: This draft is ready for publication as a Standards Track >> RFC. My extensive last call comments on the main body of the draft >> have been thoroughly dealt with - thanks, Magnus and others. I >> didn't have time previously to review the appendices in detail. >> Below are quite a few nits relating to the appendices that can be >> dealt with during RFC Editor processing. (A couple of them are >> areas where a little extra clarification or explanation is needed >> rather than purely language issues). >> >> Major Issues: (none) >> >> Minor Issues: (none) >> >> Nits: General: agree on consistent use of either 'lower layer' or >> 'lower-layer'. >> >> s App A: s/how functions/how the functions/, s/syntex illegal line >> breaks/line breaks that are not allowed by the formal syntax but >> are needed/ >> >> ssA.1-A.4, paras just before message flow: In each case the >> example mentions 'movie' for the firsttime whereas the earlier txt >> just refers to 'media' It might be better just to stick to >> 'media'. >> >> sA.1: s/For purposes/For the purposes/, s/like the host/such as the >> host domain name/, s/equal value with date/to a value equal to the >> current date and time/ >> >> sA.3, para 1: s/crypto contexts to get a secured/cryptographic >> contexts to request and facilitate secured/, s/fetch this/fetch the >> media/, s/In the this session/In this session/, s/This is >> pipeline/These are pipelined/ >> >> sA.4, para 1: s/a bit more tweaks/a few more tweaks/ >> >> sA.7, para 1: s/clients request/client's request/ >> >> s App. B, para 1: s/response will returned/will be returned/ >> >> s App. B, para 2: s/If two or more is/If rwo or more streams are/ >> >> s App. B, para 3? s/The below state machine/The state machine >> below/ >> >> sB.4, para 1: s/one or more requisite/one or more prerequisites/ >> >> sB.4, para 2: s/requisite/prerequisite/ (2 places), s/restrictions >> to when/restrictions as to when/, s/As it in the general case can't >> be determined if it was an unrecoverable error or not/As it is not >> possible, in the general case, to determine whether an error was >> unrecoverable or not/ >> >> sB.4, para below Table 15: s/depending/dependent/ (2 places) >> >> sC.1.1, para 3: s/with use of/with the use of/ >> >> sC.1.2, para 1: s/over lower transport layer UDP/over a UDP lower >> transport layer/ >> >> sC.1.2, 3rd bullet: s/unless in case/except for the case when/ >> >> sC.1.2, 5th and 6th bullets are exact duplicates - remove one! >> >> sC.1.4, last para: s/as default/as the default/ >> >> sC.1.4.1: s/crypto/cryptographic/ >> >> sC.1.4.1, item 3: Does the cert validation process need a >> reference? >> >> sC.1.4.1, item 4: Does the encooding of the cert in the MIKEY >> message need a reference to say how it is done? >> >> sC.1.4.1, item 8 bullets: Expand 'spec' in various places. In last >> bullet s/to enable client/to enable the client/ >> >> sC.1.4.1, last para: s/where the client's identity is not necessary >> to authenticate/where it is not necessary to authenticate the >> client's identity/ >> >> sC.1.6.3, para 1: s/on short to medium/in the short to medium/, >> s/the used bit-rate/the bit-rate used/ ['used thingy' implies >> second-hand or recycled as opposed to 'thingy used' implies 'thingy >> (currently) in use']. >> >> sC.1.6.4, para 3 et seq (including sC.2.2, para 3): Consistent use >> of 'rtcp-mux' vs 'RTCP-mux'. >> >> sC.1.6.4, para 3: Is the first 'recommended' a 'RECOMMENDED'.. I am >> not sure. >> >> sC.1.6.4, para 4: Maybe be a pointer to IANA registration in >> s22.1.3 would be useful? >> >> sC.1.6.4, para 5: s/are here provided/are procided here/ [original >> form is right, but archaic] >> >> sC.2.1, para 2: s/go through/going through/ (probably) but I don't >> properly understand what the point of this 'note well' is supposed >> to be. What are the (evil/unexpected) consequences of the media >> streams going through the proxy - and why would they not do this >> otherwise? >> >> s2.2, para 1: s/over lower transport layer TCP/over a TCP lower >> transport layer/ >> >> sC.3, para 1: s/The below text/The text below/ >> >> sC.3, paea 2: I can't parse the first sentence. What is (not) >> affected by 'without being affected by jumps...'. >> >> sC.3, para 2 (and paras 3, 4 and 5): 'montotonically increasing' >> does not imply what I think is required, i.e., that the next >> sequence number is the one in the last packet of the previous range >> + 1 ['monotonically increasing' just means it isn't less than the >> one in the last packet and could be several more.] Maybe 'next in >> sequence'. >> >> sC.3, para 3: s/it arrives timely and still/it arrives in a timely >> fashion and still carries/, s/media has frame/media has a frame/, >> s/burden to render/burden of rendering/ >> >> sC.3, para 4: s/that anyway caches/that expect to cache/ >> >> sC.3, para 5: s/provided stream/generated stream/ (or maybe >> 'rendered' or 'delivered') >> >> sC.3, para 5: s/the RTP timestamp when resuming MUST represent the >> duration the delivery was halted/the RTP timestamp on resumption >> MUST have increased to a value that represents the time for which >> delivery was halted/, s/RTP sequnce number/The RTP sequence >> number/, s/that likely contain/that are likely to contain/, >> s/packets part/the packets that are part/, s/rely on that a server >> will align/rely on a server aligning the timestamps and sequence >> numbers/ >> >> sC.4, para 3: s/better opportunity/better opportunities/ >> >> sC.4, next to last para: s/misunderstood commonly/commonly >> misunderstood/ >> >> sC.6, para 2: s/can easier/can more easily/ >> >> SC.3: Might be better to (re?)expand NPT in this section rather >> than either sC.6 or sC.7 (or expand in all of them). >> >> sC.11, para 1: s/lower transport/lower layer transport/, s/to be >> meet/to be carried out/ (or at least s/meet/met/). >> >> sC.11, bullet 3: s/RTP info/RTP-info/??? >> >> sD.1.1, para 1: s/on media level/on the media level/ (or maybe 'in >> each media description'?) >> >> sD.1.1, 1st note para: s/use absolute URI/use absolute URIs/ >> >> sD.1.1, para after 1st note para: s/need special/needs special/, >> s/result in control URI/result in a control URI/ >> >> sD.1.5, last para: s/there exist no RTSP mode suitable for/no RTSP >> modes exist that are designed for/, s/in client/in the client/ >> >> sD.1.6, para 4/ s/non dynamic/non-dynamic/ >> >> sD.1.7, last para/ s/be unnecessary/being unnecesarily/ >> >> sD.3, para 1@: s/there are both a media-level/there are both >> media-level/ >> >> sD.4, para 2: s/grouped medias/grouped media/ >> >> s App. E: s/considered/regularly utilized/? (or just omit 'and >> considered' - not sure it gains anything and can't think what is >> really meant by it). >> >> sE.2, para 3: s/2 hour/2 hours/ >> >> sE.3, last para: s/receives the session/receive the session/ >> >> sE.4, para 2: s/redistribute/redistributes/ >> >> >> >> >> >> >> >> >> >> sA.3, para 3: s/valid MIKEY message/valid MIKEY messages/ >> >> _______________________________________________ Gen-art mailing >> list Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
