The address for <[email protected]> bounced. I see the shepherd mentioned that he was unable to contact Michael. That will be inconvenient once we reach the Auth48 state; I encourage the chairs and co-author to please keep trying.
Thanks! Ben. > On Jun 14, 2018, at 3:20 PM, Ben Campbell <[email protected]> wrote: > > Hi, > > This is my AD Evaluation of draft-ietf-codec-ambisonics-06. Overall the draft > is in good shape. I just have a couple of minor comments/questions, and a few > editorial comments. > > Thanks! > > Ben. > > ———————————————— > > *** Substantive ***: > > §3.2, last sentence: " > Also note that the total output channel number, C, MUST be set in the 3rd > field of the identification header.” > > Is that MUST intended as a new normative requirement? The wording makes it > seem more like a statement of fact. (The prefix of “Also note that…” tends to > suggest the sentence is an FYI rather than a normative requirement. > > §4: I am a little confused by the MAYs in this section. Are there other > alternatives? Is this an example approach? A sentence or two of context would > be helpful. > > *** Editorial ***: > > §2: Please use the boilerplate from RFC 8174 unless there is a reason to do > otherwise. (I note at least one lower case normative keyword (“should”); > there may be more. > > §3.1, > > - first paragraph: First sentence is a fragment. Should there be a > conjunction between the last two values in the list of allowed numbers of > channels? (The pattern repeats in §3.2) > > - figure 1: It would be helpful to define “order” and “degree” (defined in > figure 2) prior to using them. > > §5.2, first sentence: Missing article before “Treatment”. > > §7: s/ “need take” / “need to take" > > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
