Subject: [Gen-art] Gen-art telechat review of draft-ietf-mmusic-rfc2326bis-38.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Nov 2013 21:57:14 +0000

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/

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Nov 2013 15:23:13 -0300

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-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Nov 2013 08:26:53 +0100

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 been selected as an additional General Area Review Team
>> (Gen-ART) reviewer for this draft (for background on Gen-ART,
>> please see 
>> Document: draft-ietf-mmusic-rfc2326bis-38.txt Reviewer: Elwyn
>> Davies Review Date: 2013/11/19 IESG Telechat date: 2013/11/21
>> 
>> 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'.
>> 
>> 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/
>> 
>> 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 
>> 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, 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]
>> 
>> 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?
>> 
>> 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 5: s/provided stream/generated stream/ (or maybe
>> 'rendered' or 'delivered')
>> 
>> 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.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/).
>> 
>> sD.1.1, para 1: s/on media level/on the media level/ (or maybe 'in
>> each media description'?)
>> 
>> 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/
>> 
>> considered' - not sure it gains anything and can't think what is
>> really meant by it).
>> 
>> _______________________________________________ Gen-art mailing
>> list [email-masked] 

-- 

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: [email-masked]
----------------------------------------------------------------------