Free Lossless Audio Codec
draft-ietf-cellar-flac-14

I support Roman's DISCUSS. Additionally, as this document seems to be documenting existing practice, why is this document not Informational but Standards Track? Does the IETF have the rights to modify the FLAC format or to release an updated version?

Unfortunately, the Shepherds review does not answer the question "Why is this the proper type of RFC?"

Thank you to Robert Sparks for the SECDIR review.  

Thank you to the authors (Martijn van Beurden and Andrew Weaver) and the WG for documenting this already deployed format.


** Section 8.8. 

-- [Per -12] per value = 1, “PNG file icon of 32x32 pixels”, please provide a reference to the PNG format

[Per -13] Thanks for adding [RFC2083].  This needs to be a normative reference since the code point is being specified here.

-- [Per -12] per value = 17, “A bright colored fish”, what is that?

[Per -13] Thanks for adding:

==[ snip ]==
   The origin and use of value 17, "A bright colored fish", is unclear.
   This was copied to maintain compatibility with ID3v2.
==[ snip ]==

Recommend being clearer on what implementations should do when encountering this value?  Should they discard it when encountering it?  Should guidance be given to new implementations not to emit it?

Firstly, thank you for writing this document. I generally open CODEC documents with trepidation, because I know that I'm not going to understand anything in it -- but this document was remarkably well written and simple to grok.

I had originally written this ballot as a DISCUSS ballot (see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/), but have just changed it to NoObj.

Like Roman I am concerned about having the registry at https://xiph.org/flac/id.html . While I'm sure that everyone intends to keep xiph.org around forever, it does feel like having this as an IANA maintained registry would make more sense (in the "put all your eggs in one basket, and then watch that basket." (Andrew Carnegie)).

I'd strongly suggest that the authors (in consultation with the Xiph org) consider asking IANA to maintain this.

Thanks for working on this specification.

I am supporting Roman's discussion on potential creating registry with IANA.

I have two observations that I want to share -

   - The Picture metadata block description could be enhanced for the reader/implementers if there are some description about the motivation/usage of this metadata block in the codec, as this block is kind of different of nature than the rest.

   - I understand that it is a codec specification and it should be agnostic to transport used to carry the encoded bits/frames. However, it would be great if we can emphasize the use of secure transport protocol to transport the encoded frames in the security section.

Thanks for the work done on this codec, while I am not a codex person, I find the text interesting and easy to read.

Please write "Hertz" and not "hertz".

Section 8.2: I do not think that MD5 is a signature, it is a hash.

Section 8.6, where is the name 'Vorbis' coming from ?

Section 8.6.1, should the MusicBrainz be a *normative* reference ?

Section 8.6.2, I cannot parse/understand `The channel mask consists of flag bits indicating which channels are present, stored in a hexadecimal representation preceded by 0x.`

Section 8.8, please add a normative reference for ID3v2. Also, I am unsure whether "MiB" and "GiB" are the usual abbreviations in IETF documents.

Section D.2.9, s/ MD5 sum./ MD5 checksum./ ?

I find also weird that both authors have no affiliation ;-) But, this is OK.