Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2024-03-01
14 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-03-01
14 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-03-01
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-03-01
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-03-01
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-02-29
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-02-29
14 (System) RFC Editor state changed to EDIT
2024-02-29
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-02-29
14 (System) Announcement was received by RFC Editor
2024-02-29
14 (System) IANA Action state changed to In Progress
2024-02-29
14 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-02-29
14 Cindy Morgan IESG has approved the document
2024-02-29
14 Cindy Morgan Closed "Approve" ballot
2024-02-29
14 Cindy Morgan Ballot approval text was generated
2024-02-29
14 (System) Removed all action holders (IESG state changed)
2024-02-29
14 Murray Kucherawy IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2024-01-26
14 Gunter Van de Velde Request closed, assignment withdrawn: Victor Kuarsingh Last Call OPSDIR review
2024-01-26
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version': Cleaning up stale OPSDIR queue
2024-01-14
14 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2024-01-14
14 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-14
14 Martijn van Beurden New version available: draft-ietf-cellar-flac-14.txt
2024-01-14
14 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2024-01-14
14 Martijn van Beurden Uploaded new revision
2024-01-08
13 Murray Kucherawy Based on new comments from Roman.
2024-01-08
13 (System) Changed action holders to Martijn van Beurden, Andrew Weaver (IESG state changed)
2024-01-08
13 Murray Kucherawy IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2024-01-08
13 Roman Danyliw
[Ballot comment]
Thank you to Robert Sparks for the SECDIR review. 

Thank you to the authors (Martijn van Beurden and Andrew Weaver) and the WG …
[Ballot comment]
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?
2024-01-08
13 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2023-12-10
13 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-12-10
13 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-12-10
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-12-10
13 Martijn van Beurden New version available: draft-ietf-cellar-flac-13.txt
2023-12-10
13 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2023-12-10
13 Martijn van Beurden Uploaded new revision
2023-12-05
12 (System) Changed action holders to Martijn van Beurden, Andrew Weaver (IESG state changed)
2023-12-05
12 Murray Kucherawy IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2023-10-19
12 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2023-10-19
12 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this specification.

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

I have two observations that I …
[Ballot comment]
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.
2023-10-19
12 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2023-10-18
12 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2023-10-18
12 Paul Wouters
[Ballot comment]
I support Roman's DISCUSS. Additionally, as this document seems to be documenting existing practice, why is this document not Informational but Standards Track? …
[Ballot comment]
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?"
2023-10-18
12 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2023-10-17
12 Warren Kumari
[Ballot comment]
Firstly, thank you for writing this document. I generally open CODEC documents with trepidation, because I know that I'm not going to understand …
[Ballot comment]
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.
2023-10-17
12 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2023-10-17
12 Roman Danyliw
[Ballot discuss]
** Section 8.4
  The application metadata block is for use by third-party
  applications.  The only mandatory field is a 32-bit identifier.  …
[Ballot discuss]
** Section 8.4
  The application metadata block is for use by third-party
  applications.  The only mandatory field is a 32-bit identifier.  An
  ID registry is being maintained at https://xiph.org/flac/id.html
  (https://xiph.org/flac/id.html).

-- Did the WG discuss the consequences of having normative behavior maintained on this external website?  I currently see < 30 entries.  Why can’t this be maintained by IANA? 

-- This third-party application registry URL needs to be a normative reference.

** Section 8.6.1
  For a more comprehensive list of possible field names, the list of
  tags used in the MusicBrainz project (http://picard-
  docs.musicbrainz.org/en/variables/variables.html) is recommended.

-- It is unclear how this guidance should be treated by implementers.  Is this normative behavior to: (a) use the MusicBrainz URL to understand the semantics of these field making this reference normative; or (b) this is a free-form field outside the scope of this specification but there are community efforts like MusicBrainz which is an _informative_ reference.  In either case this URL needs to be some kind of formal reference.

-- Is there are reason why there isn’t an IANA registry for these field name?

** Section 8.7.1  Please make [ISRC-handbook] a normative reference since that specification describes the track number value.

** Section 8.8.
  the media type and description
  are prepended with a 4-byte length field instead of being null
  delimited strings.

What is the format of “media type”?  Is it https://www.iana.org/assignments/media-types/media-types.xhtml?  I ask because “-->” is later mentioned as an escape sequence.

** Section 8.8.  The values of table 13 are underspecified:

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

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

** Section 8.8.  The URI mechanism described in the Picture field of the metadata block needs further security considerations.  The SECDIR review also pointed this out and discussion on possible new language has started.  This guidance needs to explicitly say that:

-- the Security Considerations of RFC3986 apply (to cover threats of maliciously craft URLs)

-- following external URLs introduces a tracking risk from on-path observers and the operator of the service hosting the URL.  Likewise, the choice of scheme, if it isn’t protected like https, could also introduce integrity attacks by an on-path observer.

-- a malicious operator of the service hosting the URL can return arbitrary content that the parser will read

-- implementers must guard against directory traversal attacks (since relative URIs are permitted) and be cognizant of same-origin issues (and localhost and local network) even more broadly

-- (per SECDIR review) there could be a DoS attack against the operator of the service when the URI from the FLAC file is retrieved

** Section 10.  Since this document is describing normative behavior on embedded this work into another container, that other container needs to be named normatively.  Specifically, please make [RFC3533] (Ogg) and [I-D.ietf-cellar-matroska] (Matroska) normative references.

** Section 12
  FLAC files may contain executable code, although the FLAC format is
  not designed for it and it is uncommon.  One use case where FLAC is
  occasionally used to store executable code is when compressing images
  of mixed mode CDs, which contain both audio and non-audio data, of
  which the non-audio portion can contain executable code.

Thanks for calling this out.  From this cautionary text, it is not clear to me where in the FLAC format this executable code would be insert.  What guidance can be given to implementers about recognizing this executable code and treating it with care?
2023-10-17
12 Roman Danyliw
[Ballot comment]
Thank you to Robert Sparks for the SECDIR review.  Also, thank you to Martijn van Beurden for engaging on the feedback.  Some of …
[Ballot comment]
Thank you to Robert Sparks for the SECDIR review.  Also, thank you to Martijn van Beurden for engaging on the feedback.  Some of my DISCUSS feedback aligns with this review.

** Section 7.
  The flac command-line tool,
  part of the FLAC reference implementation (see Section 11), generates
  streamable subset files by default unless the --lax command-line
  option is used.

-- This single reference to a particular command line option seems out of place.  Why mention this one specifically?  Are there other command line switches that matter?

-- Section 11 has text to remove upon publication.  Should this text also be removed since it won’t make sense without that section?

** Section 8.2.

  The MD5 signature is made by performing an MD5 transformation on the
  samples of all channels interleaved, represented in signed, little-
  endian form. ...

This paragraph describes the need to construct a “MD5 signature”.  I had trouble understanding on what a “MD5 transformation” is.  How is it computed?

** Section 8.8.  Please provide a reference for ID3v3 specification.

** Section 9.1.5
  When a frame number is encoded, the value MUST NOT be larger than
  what fits a value of 31 bits unencoded or 6 bytes encoded.  Please
  note that as most general purpose UTF-8 encoders and decoders follow
  [RFC3629], they will not be able to handle these extended codes.

I was confused on why a UTF-8 encoder or decoder would be used to process a raw octet stream.  Coded numbers don’t seem to be related to text strings.

** Section 9.2.2.  Please provide informative references for “Meridian Lossless Packing codec” and “lossyWAV”.

** Section 10.
  The FLAC format can be used without any container, as it already
  provides for a very thin transport layer.

It wasn’t clear to me what “thin transport layer” meant here.

** Section 10.3.  Recommend being clearer that the “full encapsulation definition of FLAC audio in MP4 is outside the scope of this document”.  Perhaps:
OLD
  The full encapsulation definition of FLAC audio in MP4 files was
  deemed too extensive to include in this document.  A definition
  document can be found at [FLAC-in-MP4-specification]
NEW
The full encapsulation definition of FLAC audio in MP4 files was    deemed too extensive and is out of scope for this document.  A possible approach is found at [FLAC-in-MP4-specification]

** Section 12.
  Parsers MUST employ thorough checks on whether a found coded
  number or seekpoint is at all possible.

Is this check intended to verify that these seekpoints are in bounds?
2023-10-17
12 Roman Danyliw Ballot comment and discuss text updated for Roman Danyliw
2023-10-17
12 Roman Danyliw
[Ballot discuss]
** Section 8.4
  The application metadata block is for use by third-party
  applications.  The only mandatory field is a 32-bit identifier.  …
[Ballot discuss]
** Section 8.4
  The application metadata block is for use by third-party
  applications.  The only mandatory field is a 32-bit identifier.  An
  ID registry is being maintained at https://xiph.org/flac/id.html
  (https://xiph.org/flac/id.html).

-- Did the WG discuss the consequences of having normative behavior maintained on this external website?  I currently see < 30 entries.  Why can’t this be maintained by IANA? 

-- This third-party application registry URL needs to be a normative reference.

** Section 8.6.1
  For a more comprehensive list of possible field names, the list of
  tags used in the MusicBrainz project (http://picard-
  docs.musicbrainz.org/en/variables/variables.html) is recommended.

-- It is unclear how this guidance should be treated by implementers.  Is this normative behavior to: (a) use the MusicBrainz URL to understand the semantics of these field making this reference normative; or (b) this is a free-form field without normative guidance but there is are _informative_ community references.  In either case this URL needs to be some kind of formal reference.

-- Is there are reason why there isn’t an IANA registry for these field name?

** Section 8.7.1  Please make [ISRC-handbook] a normative reference since that specification describes the track number value.

** Section 8.8.
  the media type and description
  are prepended with a 4-byte length field instead of being null
  delimited strings.

What is the format of “media type”?  Is it https://www.iana.org/assignments/media-types/media-types.xhtml?  I ask because “-->” is later mentioned as an escape sequence.

** Section 8.8.  The values of table 13 are underspecified:

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

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

** Section 8.8.  The URI mechanism described in the Picture field of the metadata block needs further security considerations.  The SECDIR review also pointed this out and discussion on possible new language has started.  This guidance needs to explicitly say that:

-- the Security Considerations of RFC3986 apply (to cover threats of maliciously craft URLs)

-- following external URLs introduces a tracking risk from on-path observers and the operator of the service hosting the URL.  Likewise, the choice of scheme, if it isn’t protected like https, could also introduce integrity attacks by an on-path observer.

-- a malicious operator of the service hosting the URL can return arbitrary content that the parser will read

-- implementers must guard against directory traversal attacks (since relative URIs are permitted) and be cognizant of same-origin issues (and localhost and local network) even more broadly

-- (per SECDIR review) there could be a DoS attack against the operator of the service when the URI from the FLAC file is retrieved

** Section 10.  Since this document is describing normative behavior on embedded this work into another container, that other container needs to be named normatively.  Specifically, please make [RFC3533] (Ogg) and [I-D.ietf-cellar-matroska] (Matroska) normative references.

** Section 12
  FLAC files may contain executable code, although the FLAC format is
  not designed for it and it is uncommon.  One use case where FLAC is
  occasionally used to store executable code is when compressing images
  of mixed mode CDs, which contain both audio and non-audio data, of
  which the non-audio portion can contain executable code.

Thanks for calling this out.  From this cautionary text, it is not clear to me where in the FLAC format this executable code would be insert.  What guidance can be given to implementers about recognizing this executable code and treating it with care?
2023-10-17
12 Roman Danyliw
[Ballot comment]
Thank you to Robert Sparks for the SECDIR review.  Also, thank you to Martijn van Beurden for engaging on the feedback.  Some of …
[Ballot comment]
Thank you to Robert Sparks for the SECDIR review.  Also, thank you to Martijn van Beurden for engaging on the feedback.  Some of my DISCUSS feedback aligns with this review.

** Section 7.
  The flac command-line tool,
  part of the FLAC reference implementation (see Section 11), generates
  streamable subset files by default unless the --lax command-line
  option is used.

-- This single reference to a particular command line option seems out of place.  Why mention this one specifically?  Are there other command line switches that matter?

-- Section 11 has text to remove upon publication.  Should this text also be removed since it won’t make sense without that section?

** Section 8.2.

  The MD5 signature is made by performing an MD5 transformation on the
  samples of all channels interleaved, represented in signed, little-
  endian form. ...

This paragraph describes the need to construct a “MD5 signature”.  I had trouble understanding on what a “MD5 transformation” is.  How is it computed?

** Section 8.8.  Please provide a reference for ID3v3 specification.

** Section 9.1.5
  When a frame number is encoded, the value MUST NOT be larger than
  what fits a value of 31 bits unencoded or 6 bytes encoded.  Please
  note that as most general purpose UTF-8 encoders and decoders follow
  [RFC3629], they will not be able to handle these extended codes.

I was confused on why a UTF-8 encoder or decoder would be used to process a raw octet stream.  Coded numbers don’t seem to be related to text strings.

** Section 9.2.2.  Please provide informative references for “Meridian Lossless Packing codec” and “lossyWAV”.

** Section 10.
  The FLAC format can be used without any container, as it already
  provides for a very thin transport layer.

It wasn’t clear to me what “thin transport layer” meant here.

** Section 10.3.  Recommend being clearer that the “full encapsulation definition of FLAC audio in MP4 is outside the scope of this document”.  Perhaps:
OLD
  The full encapsulation definition of FLAC audio in MP4 files was
  deemed too extensive to include in this document.  A definition
  document can be found at [FLAC-in-MP4-specification]
NEW
The full encapsulation definition of FLAC audio in MP4 files was    deemed too extensive and is out of scope for this document.  A possible approach is found at [FLAC-in-MP4-specification]

** Section 12.
  Parsers MUST employ thorough checks on whether a found coded
  number or seekpoint is at all possible.

Is this check mean verifying that these seekpoints are in bounds?
2023-10-17
12 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2023-10-17
12 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2023-10-13
12 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-10-13
12 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-10-13
12 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2023-10-12
12 Robert Sparks Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Robert Sparks. Sent review to list.
2023-10-09
12 Éric Vyncke
[Ballot comment]
Thanks for the work done on this codec, while I am not a codex person, I find the text interesting and easy to …
[Ballot comment]
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.
2023-10-09
12 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2023-10-07
12 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2023-10-06
12 Tero Kivinen Request for Telechat review by SECDIR is assigned to Robert Sparks
2023-10-05
12 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2023-10-02
12 Cindy Morgan Placed on agenda for telechat - 2023-10-19
2023-09-30
12 Murray Kucherawy Ballot has been issued
2023-09-30
12 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2023-09-30
12 Murray Kucherawy Created "Approve" ballot
2023-09-30
12 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2023-09-30
12 Murray Kucherawy Ballot writeup was changed
2023-09-27
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-09-27
12 Martijn van Beurden New version available: draft-ietf-cellar-flac-12.txt
2023-09-27
12 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2023-09-27
12 Martijn van Beurden Uploaded new revision
2023-09-27
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-09-25
11 Reese Enghardt Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Reese Enghardt. Sent review to list.
2023-09-21
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2023-09-19
11 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2023-09-19
11 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cellar-flac-11. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cellar-flac-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the audio namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration is to be made as follows:

Name: flac
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-09-14
11 Jean Mahoney Request for Last Call review by GENART is assigned to Reese Enghardt
2023-09-13
11 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-09-13
11 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-09-27):

From: The IESG
To: IETF-Announce
CC: cellar-chairs@ietf.org, cellar@ietf.org, draft-ietf-cellar-flac@ietf.org, spencerdawkins.ietf@gmail.com, superuser@gmail.com …
The following Last Call announcement was sent out (ends 2023-09-27):

From: The IESG
To: IETF-Announce
CC: cellar-chairs@ietf.org, cellar@ietf.org, draft-ietf-cellar-flac@ietf.org, spencerdawkins.ietf@gmail.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Free Lossless Audio Codec) to Proposed Standard


The IESG has received a request from the Codec Encoding for LossLess
Archiving and Realtime transmission WG (cellar) to consider the following
document: - 'Free Lossless Audio Codec'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-09-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines the Free Lossless Audio Codec (FLAC) format and
  its streamable subset.  FLAC is designed to reduce the amount of
  computer storage space needed to store digital audio signals without
  losing information in doing so (i.e., lossless).  FLAC is free in the
  sense that its specification is open and its reference implementation
  is open-source.  Compared to other lossless (audio) coding formats,
  FLAC is a format with low complexity and can be coded to and from
  with little computing resources.  Decoding of FLAC has seen many
  independent implementations on many different platforms, and both
  encoding and decoding can be implemented without needing floating-
  point arithmetic.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/



No IPR declarations have been submitted directly on this I-D.




2023-09-13
11 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-09-13
11 Cindy Morgan Last call announcement was generated
2023-09-12
11 Murray Kucherawy Last call was requested
2023-09-12
11 Murray Kucherawy Ballot approval text was generated
2023-09-12
11 Murray Kucherawy Ballot writeup was generated
2023-09-12
11 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-09-12
11 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-09-12
11 Murray Kucherawy Last call announcement was generated
2023-09-12
11 (System) Changed action holders to Spencer Dawkins, Michael Richardson (IESG state changed)
2023-09-12
11 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-09-12
11 Martijn van Beurden New version available: draft-ietf-cellar-flac-11.txt
2023-09-12
11 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2023-09-12
11 Martijn van Beurden Uploaded new revision
2023-08-19
10 Barry Leiba Closed request for Early review by ARTART with state 'Overtaken by Events'
2023-08-19
10 Barry Leiba Assignment of request for Early review by ARTART to Cullen Jennings was marked no-response
2023-08-08
10 Murray Kucherawy Expecting a -11, which should be ready for Last Call.
2023-08-08
10 (System) Changed action holders to Spencer Dawkins, Michael Richardson, Martijn van Beurden, Andrew Weaver (IESG state changed)
2023-08-08
10 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2023-08-04
10 (System) Changed action holders to Spencer Dawkins, Michael Richardson (IESG state changed)
2023-08-04
10 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-08-04
10 Martijn van Beurden New version available: draft-ietf-cellar-flac-10.txt
2023-08-04
10 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2023-08-04
10 Martijn van Beurden Uploaded new revision
2023-07-09
09 Murray Kucherawy Changed action holders to Martijn van Beurden, Andrew Weaver, Spencer Dawkins, Michael Richardson
2023-07-09
09 (System) Changed action holders to Martijn van Beurden, Andrew Weaver, Murray Kucherawy (IESG state changed)
2023-07-09
09 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2023-07-03
09 Martijn van Beurden New version available: draft-ietf-cellar-flac-09.txt
2023-07-03
09 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2023-07-03
09 Martijn van Beurden Uploaded new revision
2023-05-09
08 Barry Leiba Request for Early review by ARTART is assigned to Cullen Jennings
2023-05-09
08 Murray Kucherawy Requested Early review by ARTART
2023-05-02
08 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-05-02
08 Murray Kucherawy IESG state changed to AD Evaluation from Publication Requested
2023-04-23
08 Spencer Dawkins
# Spencer Dawkins Shepherd Write-Up for draft-ietf-cellar-flac-08

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few …
# Spencer Dawkins Shepherd Write-Up for draft-ietf-cellar-flac-08

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
The WG is very small (6-8 active participants), but pretty much the entire active part of the WG was involved in the consensus for this document, and the GitHub repo for this specification shows 11 people who have contributed text to the document, and discussion of issues and pull requests usually involves 3-5 participants. More WG members spoke than were silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
This is my first draft to shepherd in Cellar, and I'm really impressed at how NOT contentious discussions were, and how NOT rough consensus was.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
 
Not that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
There are two independent implementations (libFLAC and libavcodec), plus a list of implementations, all described in https://www.ietf.org/archive/id/draft-ietf-cellar-flac-08.html#name-implementation-status.

It's worth noting that one of the challenges for this draft was collecting the long and broad FLAC implementation history, to minimize the amount of incompatibility this spec introduces. To give some idea of this constraint, Windows, Android, MacOS/iOS, and SerinityOS all include FLAC libraries, and FLAC can be implemented on bare hardware, so incompatibility is not taken lightly.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
FLAC is something of a niche codec - it's intended to provide lossless compression, with minimal hardware demands, and without encumbered intellectual property. Most IETF participants who are experts in lossless encoding are already reviewing FLAC in the working group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
Spencer Dawkins requested a media-type review for audio/flac on 04-04-2023. We did get feedback, that the (barely documented) preference is now to consider adding these two attributes: Windows Clipboard Format Name and Uniform Type Identifier.

We've added these attributes, with the following values:
Windows Clipboard Format Name: audio/flac
Uniform Type Identifier: org.xiph.flac

Martijn observes that at only about three RFCs include these attributes (RFC 7946, RFC 8790, and RFC 8428), so he is using "Windows Clipboard Format Name" to match them, instead of "Windows Clipboard Flavour Name", the term used in the media-types discussion.

Spencer observes that our responsible AD is also one of the designated experts for the media types IANA registry, so we're sure that the right thing will happen, given AD Evaluation.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
Yes. The shepherd did a fresh start-to-end review and provided a significant number of comments, which have been addressed, but these fell into a few categories - for example, using BCP 14 keywords to state facts. The shepherd review was posted to the CELLAR mailing list.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The ART issues list is not applicable to codecs.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This draft targets IETF stream, Standards Track, and describes how to implement a technical standard. The datatracker state attributes correctly reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Spencer has sent a last-step-before-publication-requested email to the authors on 04-04-23, asking that they confirm this. Both listed authors have confirmed this. In addition to this, Martijn provided a link to https://mailarchive.ietf.org/arch/msg/cellar/yRr6u7Km6NSH16zEt4HfMp0-P8c/ where Josh Coalson, who held copyright on the original document before FLAC came to the IETF, has consented to having the original document relicensed from GFDL to 3-clause BSD.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes,

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits remain, that I could spot.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The number of Normative references is surprisingly small, but many Informative references are included to provide a pointer to a well-known and well-understood technique that this specification supports. What you need to know, in order to implement this specification, is pretty much described in this draft.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No Normative references are unavailable. Even the Informative references are freely available, unless they are too old to be present on the Internet (very few have a publication date more recent than 1999), and several of these techniques have their own Wikipedia entries, which the working group discussed, and decided that the Wikipedia entry was sufficient for what an implementer needed to understand.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Spencer read the IANA Considerations section and discussed suggestions with the authors.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not Applicable.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2023-04-04
08 Spencer Dawkins
# Spencer Dawkins Shepherd Write-Up for draft-ietf-cellar-flac-08

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few …
# Spencer Dawkins Shepherd Write-Up for draft-ietf-cellar-flac-08

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
The WG is very small (6-8 active participants), but pretty much the entire active part of the WG was involved in the consensus for this document, and the GitHub repo for this specification shows 11 people who have contributed text to the document, and discussion of issues and pull requests usually involves 3-5 participants. More WG members spoke than were silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
This is my first draft to shepherd in Cellar, and I'm really impressed at how NOT contentious discussions were, and how NOT rough consensus was.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
 
Not that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
There are two independent implementations (libFLAC and libavcodec), plus a list of implementations, all described in https://www.ietf.org/archive/id/draft-ietf-cellar-flac-08.html#name-implementation-status.

It's worth noting that one of the challenges for this draft was collecting the long and broad FLAC implementation history, to minimize the amount of incompatibility this spec introduces. To give some idea of this constraint, Windows, Android, MacOS/iOS, and SerinityOS all include FLAC libraries, and FLAC can be implemented on bare hardware, so incompatibility is not taken lightly.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
FLAC is something of a niche codec - it's intended to provide lossless compression, with minimal hardware demands, and without encumbered intellectual property. Most IETF participants who are experts in lossless encoding are already reviewing FLAC in the working group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
Spencer Dawkins requested a media-type review for sudio/flac on 04-04-2023.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
Yes. The shepherd did a fresh start-to-end review and provided a significant number of comments, which have been addressed, but these fell into a few categories - for example, using BCP 14 keywords to state facts. The shepherd review was posted to the CELLAR mailing list.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The ART issues list is not applicable to codecs.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This draft targets IETF stream, Standards Track, and describes how to implement a technical standard. The datatracker state attributes correctly reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Spencer has sent a last-step-before-publication-requested email to the authors on 04-04-23, asking that they confirm this.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes,

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits remain, that I could spot.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The number of Normative references is surprisingly small, but many Informative references are included to provide a pointer to a well-known and well-understood technique that this specification supports. What you need to know, in order to implement this specification, is pretty much described in this draft.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No Normative references are unavailable. Even the Informative references are freely available, unless they are too old to be present on the Internet (very few have a publication date more recent than 1999), and several of these techniques have their own Wikipedia entries, which the working group discussed, and decided that the Wikipedia entry was sufficient for what an implementer needed to understand.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Spencer read the IANA Considerations section and discussed suggestions with the authors.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not Applicable.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2023-04-04
08 Spencer Dawkins Responsible AD changed to Murray Kucherawy
2023-04-04
08 Spencer Dawkins IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-04-04
08 Spencer Dawkins IESG state changed to Publication Requested from I-D Exists
2023-04-04
08 Spencer Dawkins Document is now in IESG state Publication Requested
2023-04-04
08 Spencer Dawkins Tag Doc Shepherd Follow-up Underway cleared.
2023-04-04
08 Spencer Dawkins IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2023-04-04
08 Spencer Dawkins
# Spencer Dawkins Shepherd Write-Up for draft-ietf-cellar-flac-08

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few …
# Spencer Dawkins Shepherd Write-Up for draft-ietf-cellar-flac-08

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
The WG is very small (6-8 active participants), but pretty much the entire active part of the WG was involved in the consensus for this document, and the GitHub repo for this specification shows 11 people who have contributed text to the document, and discussion of issues and pull requests usually involves 3-5 participants. More WG members spoke than were silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
This is my first draft to shepherd in Cellar, and I'm really impressed at how NOT contentious discussions were, and how NOT rough consensus was.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
 
Not that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
There are two independent implementations (libFLAC and libavcodec), plus a list of implementations, all described in https://www.ietf.org/archive/id/draft-ietf-cellar-flac-08.html#name-implementation-status.

It's worth noting that one of the challenges for this draft was collecting the long and broad FLAC implementation history, to minimize the amount of incompatibility this spec introduces. To give some idea of this constraint, Windows, Android, MacOS/iOS, and SerinityOS all include FLAC libraries, and FLAC can be implemented on bare hardware, so incompatibility is not taken lightly.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
FLAC is something of a niche codec - it's intended to provide lossless compression, with minimal hardware demands, and without encumbered intellectual property. Most IETF participants who are experts in lossless encoding are already reviewing FLAC in the working group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
Spencer Dawkins requested a media-type review for sudio/flac on 04-04-2023.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
Yes. The shepherd did a fresh start-to-end review and provided a significant number of comments, which have been addressed, but these fell into a few categories - for example, using BCP 14 keywords to state facts. The shepherd review was posted to the CELLAR mailing list.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The ART issues list is not applicable to codecs.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This draft targets IETF stream, Standards Track, and describes how to implement a technical standard. The datatracker state attributes correctly reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Spencer has sent a last-step-before-publication-requested email to the authors on 04-04-23, asking that they confirm this.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes,

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits remain, that I could spot.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The number of Normative references is surprisingly small, but many Informative references are included to provide a pointer to a well-known and well-understood technique that this specification supports. What you need to know, in order to implement this specification, is pretty much described in this draft.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No Normative references are unavailable. Even the Informative references are freely available, unless they are too old to be present on the Internet (very few have a publication date more recent than 1999), and several of these techniques have their own Wikipedia entries, which the working group discussed, and decided that the Wikipedia entry was sufficient for what an implementer needed to understand.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Spencer read the IANA Considerations section and discussed suggestions with the authors.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not Applicable.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2023-04-03
08 Martijn van Beurden New version available: draft-ietf-cellar-flac-08.txt
2023-04-03
08 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2023-04-03
08 Martijn van Beurden Uploaded new revision
2022-11-18
07 Michael Richardson Tag Doc Shepherd Follow-up Underway set.
2022-11-18
07 Michael Richardson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2022-11-18
07 Michael Richardson Notification list changed to spencerdawkins.ietf@gmail.com because the document shepherd was set
2022-11-18
07 Michael Richardson Document shepherd changed to Spencer Dawkins
2022-10-23
07 Martijn van Beurden New version available: draft-ietf-cellar-flac-07.txt
2022-10-23
07 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2022-10-23
07 Martijn van Beurden Uploaded new revision
2022-10-11
06 Martijn van Beurden New version available: draft-ietf-cellar-flac-06.txt
2022-10-11
06 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2022-10-11
06 Martijn van Beurden Uploaded new revision
2022-09-28
05 Spencer Dawkins IETF WG state changed to In WG Last Call from WG Document
2022-09-27
05 Martijn van Beurden New version available: draft-ietf-cellar-flac-05.txt
2022-09-27
05 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2022-09-27
05 Martijn van Beurden Uploaded new revision
2022-08-21
04 Martijn van Beurden New version available: draft-ietf-cellar-flac-04.txt
2022-08-21
04 Martijn van Beurden New version accepted (logged-in submitter: Martijn van Beurden)
2022-08-21
04 Martijn van Beurden Uploaded new revision
2022-04-23
03 Martijn van Beurden New version available: draft-ietf-cellar-flac-03.txt
2022-04-23
03 Michael Richardson New version approved
2022-04-23
03 (System) Request for posting confirmation emailed to previous authors: Andrew Weaver , Michael Richardson , cellar-chairs@ietf.org
2022-04-23
03 Martijn van Beurden Uploaded new revision
2021-11-01
02 Michael Richardson New version available: draft-ietf-cellar-flac-02.txt
2021-11-01
02 (System) Forced post of submission
2021-11-01
02 (System) Request for posting confirmation emailed to previous authors: Andrew Weaver , Michael Richardson
2021-11-01
02 Michael Richardson Uploaded new revision
2021-04-27
01 Michael Richardson New version available: draft-ietf-cellar-flac-01.txt
2021-04-27
01 (System) New version approved
2021-04-27
01 (System) Request for posting confirmation emailed to previous authors: Andrew Weaver , Josh Coalson , cellar-chairs@ietf.org, unknown-email--
2021-04-27
01 Michael Richardson Uploaded new revision
2020-01-31
00 (System) Document has expired
2019-07-30
00 Michael Richardson Added to session: interim-2019-cellar-06
2019-07-30
00 Michael Richardson Changed consensus to Yes from Unknown
2019-07-30
00 Michael Richardson Intended Status changed to Proposed Standard from None
2019-07-30
00 Michael Richardson This document now replaces draft-weaver-cellar-flac instead of None
2019-07-30
00 Andrew Weaver New version available: draft-ietf-cellar-flac-00.txt
2019-07-30
00 (System) WG -00 approved
2019-07-30
00 Andrew Weaver Set submitter to "Andrew Weaver ", replaces to (none) and sent approval email to group chairs: cellar-chairs@ietf.org
2019-07-30
00 Andrew Weaver Uploaded new revision