Thank you for your extensive review and Magnus thank you for addressing the issues. Are you tracking the nits from below?
I have balloted no-obj. Jari On Nov 19, 2013, at 6:57 PM, Elwyn Davies <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
