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

[actech <actech at jp.sony.com>]

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 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