Re: Review of draft-ietf-avt-rtp-atrac-family-13
Tom Taylor <tom.taylor <at> rogers.com>
2008-03-07 04:07:58 GMT
The issues are small enough that a short review will be sufficient. The only
difficult issue is the one Harald raised, about the requirement for a specification.
> Dear Mr.Taylor,
> Thank you for your review and comments on our draft.
> We will fix the matter, and revise the draft as "...atrac-family-14"
> in soon.
> In that case, do we have to re-submit the draft to AVT group and
> have reviewed again in the group, or is there any short cuts?
> Best Regards,
> Jun Matsumoto
>> 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 126.96.36.199, 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  should now be to
>> - 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
>> - 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 188.8.131.52." 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 184.108.40.206,
>> - 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 220.127.116.11 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 18.104.22.168 depends on these
>> - 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 22.214.171.124 first para, second-last line:
>> and to expand -> and warns it to expand
>> - section 126.96.36.199, Figure 7:
>> reciever -> receiver
>> Exmaple -> Example
>> - section 188.8.131.52, first to second lines of second para:
>> packet, its -> packet with its
>> - section 184.108.40.206, 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
>> - 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