Telechat Review of draft-ietf-mmusic-rfc2326bis-38
review-ietf-mmusic-rfc2326bis-38-genart-telechat-davies-2013-11-15-00

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/