[AVT] Review of draft-ietf-avt-rtp-atrac-family-13

[Tom Taylor <tom.taylor at rogers.com>]

The Working Group Last Call period expired for 
draft-ietf-avt-rtp-atrac-family-13 without comment on the AVT list. There was 
one objection on the Media Types list, that it is unacceptable to register a 
media type in the IETF tree without giving a reference to the source 
documentation. The submitting organization is discussing the matter.

Here are my own comments. There are a few fixes that are essential, followed by 
a long list of trivial editorial changes.

Issues that need fixing:

1. Numbering of fragments

There is an inconsistency in the numbering of fragments. Section 5.3.1 says it 
starts from 0. Section 5.3.2.2, first sentence of the second paragraph, says 
that it starts from 1. The example in section 6.2 also shows it starting from 1. 
Before deciding too quickly what is the right answer, you should also think 
about and indicate in section 5.3.1 what the value should be for an unfragmented 
frame.

2. Normative language in section 7.5.2

There is a "should", a "must", and a "recommended" (mis-spelled) in section 
7.5.2 that should probably be capitalized. There is also a lower-case 
"recommended" near the end of section 7.5.3.

3. Cut-and-paste error in section 7.9?

First example offer shows the same rtpmap description for payload types 98 and 
99. Should payload type 99 be the same as in the answer?

4. Obsolete reference

Your final normative reference [8] should now be to 
draft-ietf-mmusic-decoding-dependency-01.


Trivial:

- most I-Ds have the authors' organization (e.g., Sony Corporation) in the draft 
header. You're turning down a chance to put your organization's name in front of 
the public :)

- section 1, first para first line: are designed -> is designed
[to agree with "family"]

- section 1, second para, fourth line: add comma at the end after "codecs"

- section 4.1 third line: octect -> octet

- section 4.4 second line: "decoding gap" by -> "decoding gap" at

- section 4.4 again: I suggest adding a sentence: "For further details, see 
section 5.3.2.1." You could also consider adding a reference to RFC 2198 as a 
more sophisticated approach (implying a new informative reference).

- I assume section 4.5.2 has multiple paragraphs, but the blank lines between 
them are missing. Anyway, in what appears to be the third para:
   can not -> cannot
   only with ignoring -> only, ignoring

- section 5.1, second para (first after Figure 3), last sentence:
   In case of using redundant mechanism, -> When using the redundancy mechanism 
described in section 5.3.2.1,

- section 5.2:
   Extention -> Extension
   In last line of timestamp description: sigalling -> signalling

- section 5.3.1, Continuous flag:
   Might make more sense to call this the "Continuation flag", here and 
elsewhere in the document.
   fragmentaion -> fragmentation

- section 5.3.2: is it too obvious to say that if multiple frames in a packet 
cover multiple sampling times, the frames must be ordered by increasing sample 
time? And as a consequence, when the redundancy mechanism of section 5.3.2.1 is 
used, the redundant frames come first and the timestamp corresponds to the 
sampling time of the oldest redundant frame. Also, probably should say that the 
frames in a packet, including the redundant ones, must cover a continuous time 
interval. The calculation in section 5.3.2.1 depends on these assumptions.

- section 5.3.2 first para third line: preceeded -> preceded

- section 5.3.2, block length description: final sentence could be confusing and 
should be deleted. The first para of the section already says that each frame is 
preceded by the Layer Type flag as well as the Block Length.

- section 5.3.2.1 first para, second-last line:
   and to expand -> and warns it to expand

- section 5.3.2.1, Figure 7:
   reciever -> receiver
   Exmaple -> Example

- section 5.3.2.2, first to second lines of second para:
   packet, its -> packet with its

- section 5.3.2.2, third para has its ideas in the wrong order, I think. I 
suggest that the para be rewritten to read:

   "Packets containing related fragmented frames MUST have identical
    timestamps. Thus, while the Continuous bit and Fragment Number fields
    indicate fragmentation and a means to reorder the packets, the
    timestamp can be used to determine which packets go together."

- section 7.3, channelID description, second-last line:
   could be used -> could be used in this case

- section 7.3, maxptime description:
   a multiple frames can not -> multiple frames cannot
   reciever -> receiver

- section 7.4 first para: The Table 1. is explaining -> Table 1 explains

- section 7.5.1, Media subtype:
   channels SHALL also be included -> channels (0 or 1) SHALL also be specified

- section 7.5.3, remaining parameters bullet, fifth line:
   MUST be existing -> MUST be present

- section 7.6, second line: either -> either of

- section 7.7 first bullet:
   configuration(s) that is provided -> configuration(s) provided

- section 7.7, final para, first sentence:
   scaleble -> scalable
   the attribute -> the attributes

- section 9.1 first para: preferrable -> preferable

- section 9.1 second para:
   for encryption affecting -> that encryption will affect

- section 9.2 first line: due malicious -> due to malicious

Tom Taylor
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt