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 |