Skip to main content

FFV1 Video Coding Format Versions 0, 1, and 3
draft-ietf-cellar-ffv1-20

Revision differences

Document history

Date Rev. By Action
2021-08-18
20 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-06-03
20 (System) RFC Editor state changed to AUTH48
2021-04-01
20 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-03-29
20 Francesca Palombini Closed request for Early review by ARTART with state 'Overtaken by Events'
2021-03-18
20 (System) RFC Editor state changed to EDIT from MISSREF
2021-03-10
20 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-03-10
20 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-03-10
20 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-03-10
20 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-03-03
20 (System) RFC Editor state changed to MISSREF
2021-03-03
20 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-03-03
20 (System) Announcement was received by RFC Editor
2021-03-03
20 (System) IANA Action state changed to In Progress
2021-03-03
20 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-03-03
20 Amy Vezza IESG has approved the document
2021-03-03
20 Amy Vezza Closed "Approve" ballot
2021-03-03
20 Amy Vezza Ballot approval text was generated
2021-03-02
20 Murray Kucherawy IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-02-23
20 Barry Leiba IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2021-02-23
20 Barry Leiba
[Ballot comment]
Thanks very much for having addressed all my comments, and special thanks for the work in clearing up the meanings of things in …
[Ballot comment]
Thanks very much for having addressed all my comments, and special thanks for the work in clearing up the meanings of things in Section 3.8.1.1.  I think I do understand it now, and I think the work you've done in making that happen has made this a better document.
2021-02-23
20 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2021-02-23
20 Michael Niedermayer New version available: draft-ietf-cellar-ffv1-20.txt
2021-02-23
20 (System) Forced post of submission
2021-02-23
20 (System) Request for posting confirmation emailed to previous authors: Dave Rice , Jerome Martinez , Michael Niedermayer
2021-02-23
20 Michael Niedermayer Uploaded new revision
2020-12-01
19 Roman Danyliw
[Ballot comment]
(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks …
[Ballot comment]
(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review).

I support Barry Lieba’s Discuss position.

Thanks for addressing my DISCUSS.

On the security considerations:

** Section 6.  Per the reference to [RFC4732], which selection is relevant here? Is it Section 2.1.1?

** Section 6.  The assertions about the security properties of [REFIMPL] don’t make sense to me in this document.  While it is extremely helpful that there is a high-quality reference implementation, it’s relevance to this spec isn’t clear.  This code isn’t normative.  Recommend removal all text after the paragraph “None of the content carried in FFV1 is intended to be executable”.
2020-12-01
19 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2020-12-01
19 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-12-01
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-12-01
19 Dave Rice New version available: draft-ietf-cellar-ffv1-19.txt
2020-12-01
19 (System) New version approved
2020-12-01
19 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Michael Niedermayer , Dave Rice
2020-12-01
19 Dave Rice Uploaded new revision
2020-10-21
18 Roman Danyliw
[Ballot comment]
(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks …
[Ballot comment]
(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review).

I support Barry Lieba’s Discuss position.

Thanks for addressing some of the comments in -18.

On the security considerations:

** Section 6.  Per the reference to [RFC4732], which selection is relevant here? Is it Section 2.1.1?

** Section 6.  The assertions about the security properties of [REFIMPL] don’t make sense to me in this document.  While it is extremely helpful that there is a high-quality reference implementation, it’s relevance to this spec isn’t clear.  This code isn’t normative.  Recommend removal all text after the paragraph “None of the content carried in FFV1 is intended to be executable”.
2020-10-21
18 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-10-08
18 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-10-07
18 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-10-07
18 Benjamin Kaduk
[Ballot comment]
I support Roman's Discuss.

I am balloting Abstain in that I am not confident that this
document has received sufficient review, but have …
[Ballot comment]
I support Roman's Discuss.

I am balloting Abstain in that I am not confident that this
document has received sufficient review, but have not identified
specific flaws or areas of uncertainty that sould justify blocking
publication, and accordingly do not wish to block its publication.  In
particular, I am not confident that I myself understand how all the
pieces fit together -- even though some of my comments below might
indicate internal inconsistencies or other issues that would justify a
Discuss position, I am not fully confident in that, nor am I confident
that I could judge that they have been adequately addressed by any
proposed changes to the document's text.  (This is in large part related
to Barry's Discuss.)

That said, my review comments on the document appear below.

It might make sense to have a bit of discussion on what types of things
would (or would not) change in a new micro version, vs new "macro"
version, and what could be said to be "invariants" of the format overall.

Should we give more treatment (or even an IANA registry) for how
extensibility will be achieved for (e.g.) new "coder_type" and
"colorspace_type" values?

Section 2.2.9.4

  "get_bits( i )" is the action to read the next "i" bits in the
  bitstream, from most significant bit to least significant bit, and to
  return the corresponding value.  [...]

[I guess this "value" is always in the form of an unsigned integer.]

Section 3.3

  It is expected (to be confirmed) to remove this exception for the
  median predictor in the next version of the FFV1 bitstream.

When can/will the confirmation process happen?  When version 4 is
finalized?

Section 3.6

The discussion seems to imply that the chroma planes are not used in
FFV4 (and so the check for "version <= 3" in the logic here is just for
future compatibility); is that correct?

Section 3.7

  color space.  In YCbCr for each "Plane", each "Line" is coded from
  top to bottom and for each "Line", each "Sample" is coded from left
  to right.  In JPEG2000-RCT for each "Line" from top to bottom, each

Is there a reason that we use "JPEG2000-RCT" in the prose here, but
"RGB" for the section 3.7.2 heading?

Section 3.8.1.1

The defined terms do not cover all terms used (so I conclude that there
are unnamed intermediate values) and the formulae themself do not do a
great job of conveying where the overall inputs/outputs are, thus the
flow of the encoding logic.  Captions on the figures might help, which
could include indications of which intermediate values from from formula
to formula.  It also seems like some of the intermediate values could be
usefully named, e.g., R_(i) seems to serve the role of the remaining
range at a given step.

Section 3.8.1.2

Does "non binary" mean "non-integer", i.e., floating point?
We don't seem to use the "non binary" term elsewhere in the document.

I'm also not sure I'm reading the formula properly -- state is a uint8_t
but the indexing into it seems to make more sense to me if treated as
bit indexing, not byte indexing.  (E.g., 'a' is only doubled when
iterating through 22..31, indicating bitwise representation.)

      int e = 0;
      while (get_rac(c, state + 1 + min(e, 9)) { //1..10
          e++;
      }

It looks like this enters an infinite loop if get_rac(c, state + 10)
returns true; is there something to enforce that this does not happen?

  "get_rac" returns a boolean, computed from the bytestream as
  described in Section 3.8.1.1.

I suggest saying a little bit more about how this works, e.g., that the
boolean is a single-bit integer value, and how this functional notation
maps to the interfaces of the expressions in Section 3.8.1.1.

Section 3.8.2.1

What is 'bits' (the argument to the last get_bits() call) in Figure 20?
(Is it the same "bits_per_raw_sample" from §3.8?  If so, that
description should be qualified to apply more broadly than just "the
equation below".)

Section 3.8.2.2.1

What are 'x' and 'w' (and how are they set)?

What are the semantics of "run_mode" values 1 vs 2?

Section 3.8.2.3

I guess it's implicit that "output_number" is of the appropriate (width)
type for the desired output bit width.

Section 3.8.2.4

I guess "i += i" vs "i *= 2" is just a matter of style.

Where does the 'bits' input to sign_extend() come from?
(Is it the same "bits_per_raw_sample" from §3.8?  If so, that
description should be qualified to apply more broadly than just "the
equation below".)

Section 3.8.2.4.1

I suggest rewording or using a section reference for "normal difference
coding" as the phrase "difference coding" does not suffice (via text
search) to find the referenced procedure, since this is the only
instance of the phrase in the document.

Section 4.1

I'm not sure how to parse "number of equal entries -1".  In combination
with the example I can guess what is meant, but I still can't parse the
text.

The "Table" listed in the example does not seem to conform to "second
half [...] is identical to the first with flipped sign".

Also, the QuantizationTable() pseudocode suggests that the Table should
have 256 entries, but this example only has 16.  (That may be fine for
example purposes, but the difference should be called out.)

Section 4.2

C uses 0-indexed arrays, but the pseudocode seems to use 1-indexed
arrays (e.g., state_transition_delta[]).  Perhaps this is noteworthy.

Section 4.5

If 'reserved' is only present when version <=1, it seems unlikely that a
revision of this specification would assign semantics to it.

Section 4.6.x

nit: "if not present" could be taken to suggest that this field is
optional at field-level granularity (vs. at header-/version-level
granularity); "if header not present" might be slightly more clear.

Section 6

If we are attempting to differentiate between "format" and "codec", are
the uses of "codec" in this section all correct?

It may (or may not) be worth calling out the importance of internal
consistency within an implementation as to whether the Parameters()
appear in the ConfigurationRecord() or in each Frame().

  In all of the conditions above, the decoder and encoder was run
  inside the [VALGRIND] memory debugger as well as clangs address
  sanitizer [Address-Sanitizer], which track reads and writes to

nit: "clang's" with apostrophe.

Section 10

I don't see a particular reason that RFC 6716 needs to be a normative
reference.

(I also agree with Roman that there doesn't seem to be need to reference
both C90 and C18.)

Appendix A, B

It is surprising to see BCP 14 keywords in these nominally informative
sections.
2020-10-07
18 Benjamin Kaduk [Ballot Position Update] New position, Abstain, has been recorded for Benjamin Kaduk
2020-10-07
18 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-10-07
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-10-07
18 Dave Rice New version available: draft-ietf-cellar-ffv1-18.txt
2020-10-07
18 (System) New version approved
2020-10-07
18 (System) Request for posting confirmation emailed to previous authors: Dave Rice , Michael Niedermayer , Jerome Martinez
2020-10-07
18 Dave Rice Uploaded new revision
2020-10-07
17 Roman Danyliw
[Ballot discuss]
A simple clarification.

Section 6.
  Implementations of the FFV1 codec need to take appropriate security
  considerations into account, as outlined in …
[Ballot discuss]
A simple clarification.

Section 6.
  Implementations of the FFV1 codec need to take appropriate security
  considerations into account, as outlined in [RFC4732]

RFC4732 only covers DoS.  A buffer overflow (as described in the subsequent text of this paragraph) in a codec implementation could have dramatically more significant consequences for the endpoint (or the services it provides) than a DoS.  It could potentially lead to arbitrary remote code execution on the system (barring defensive mitigations provided by sandboxing in the app, OS execution protections; and/or end-point protection software) which pretty much enables an attacker to do anything of their choosing on the system.  Please note that.
2020-10-07
17 Roman Danyliw
[Ballot comment]
(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks …
[Ballot comment]
(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review).

I support Barry Lieba’s Discuss position.

A few comments on the framing of the codec description:

** Section 1.  Is “non-experimental use” the same as production use?

** References.  Why use C89/90 for syntax and C18 for operator precedence?  Wouldn’t C18 work for both?

** References. 

-- Doesn’t Section 4.3.3.2 required [ISO.14496-12.2015] as a normative reference to parse the "glbl" box in the ConfigurationRecord bitstream?

-- Doesn’t Section 4.3.3.3 required [NUT] as a normative reference to parse the ConfigurationRecord bitstream?

On the security considerations:

** Section 6.  Per the reference to [RFC4732], which selection is relevant here? Is it Section 2.1.1?

** Section 6.  The assertions about the security properties of [REFIMPL] don’t make sense to me in this document.  While it is extremely helpful that there is a high-quality reference implementation, it’s relevance to this spec isn’t clear.  This code isn’t normative.  Recommend removal all text after the paragraph “None of the content carried in FFV1 is intended to be executable”.
2020-10-07
17 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to Discuss from No Objection
2020-10-07
17 Roman Danyliw
[Ballot comment]
Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review).

I support Barry Lieba’s Discuss position. …
[Ballot comment]
Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review).

I support Barry Lieba’s Discuss position.

A few additional comments on the framing of the codec description not already mentioned by my peers:

** Section 1.  Is “non-experimental use” the same as production use?

** References.  Why use C89/90 for syntax and C18 for operator precedence?  Wouldn’t C18 work for both?

** References. 
-- Doesn’t Section 4.3.3.2 required [ISO.14496-12.2015] as a normative reference to parse the "glbl" box in the ConfigurationRecord bitstream?

-- Doesn’t Section 4.3.3.3 required [NUT] as a normative reference to parse the ConfigurationRecord bitstream?

On the security considerations:
** Section 6.  Per the reference to [RFC4732], which selection is relevant here? Is it Section 2.1.1?  If so, the risks due to end-point compromise are much broader than DoS.

** Section 6.  The assertions about the security properties of [REFIMPL] don’t make sense to me in this document.  While it is extremely helpful that there is a high-quality reference implementation, it’s relevance to this spec isn’t clear.  This code isn’t normative.  Recommend removal all text after the paragraph “None of the content carried in FFV1 is intended to be executable”.
2020-10-07
17 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-10-06
17 Spencer Dawkins Added during IESG review - thanks, Alvaro.
2020-10-06
17 Spencer Dawkins This document now replaces draft-niedermayer-cellar-ffv1 instead of None
2020-10-05
17 Alvaro Retana [Ballot comment]
The datatracker should indicate that this draft replaces draft-niedermayer-cellar-ffv1.  The indication appears on the tools page, but not the datatracker.
2020-10-05
17 Alvaro Retana Ballot comment text updated for Alvaro Retana
2020-10-05
17 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-10-05
17 Robert Wilton
[Ballot comment]
Hi,

Thank you for taking the time to document FFV1 version 0, 1 and 3.

I support Barry's discuss in that I found …
[Ballot comment]
Hi,

Thank you for taking the time to document FFV1 version 0, 1 and 3.

I support Barry's discuss in that I found this document hard to read and interpret.  I think that I would struggle to implement a FFV1 encoder/decoded from scratch based on this document.  However, this is a long way outside my area of expertise and there is perhaps a corpus of basic video codec knowledge that is assumed in this specification.

Is the intention of this document that it gets obsoleted when FFV1 version 4 is documented?

I haven't reviewed the entirety of this document, but I do have some comments of particular areas of the document that I found hard to follow that additional text or explanation may be helpful.

Overall, having some more introduction text explaining the overall structure of the encoding , i.e. how the different parts fit together would likely help readability.

3.1.  Border

      Figure 2: A depiction of FFV1's assumed border for a set example
                                  Samples.

I wasn't sure whether an extra row at the bottom of this table would have been helpful, but perhaps it is not required because it is not referenced.


3.2.  Samples

  The labels for these relative "Samples" are made of the first letters
  of the words Top, Left and Right.
 
Don't feel obliged to change this, but I wonder whether keep lowercase for all of the relative positions might have been clearer.  E.g., perhaps using "tt" instead of "T" and "ll" instead of "L".

3.3.  Median Predictor

  Exception for the median predictor ...

Possibly putting the exception text into a 3.3.1 sub-section would aid readability.

3.4.  Quantization Table Sets

It wasn't clear to me what a "Quantized Sample Differences" is.


3.7.2.  RGB

  Cb = b - g
  Cr = r - g
  Y = g + (Cb + Cr) >> 2
  g = Y - (Cb + Cr) >> 2
  r = Cr + g
  b = Cb + g
 
Perhaps split into two sets of 3 equations to define the relationship in either direction.

  Exception for the JPEG2000-RCT conversion ...
 
Again, putting this into a sub-section (3.7.2.1) might aid readability, i.e. the split between what is desired vs what is being described due to bugs in real implementations.


3.8.  Coding of the Sample Difference

  coder_input = [(sample_difference + 2 ^ (bits - 1)) &
                (2 ^ bits - 1)] - 2 ^ (bits - 1)
               
It wasn't clear to me what [] brackets meant here.

3.8.1.1.  Range Binary Values

I found this hard to follow, as in I couldn't figure out what it means.

3.8.1.4.  State Transition Table

It wasn't really clear to me what these were used for.

3.8.2.1.  Signed Golomb Rice Codes

Unclear what is meant by "ESC case"

Regards,
Rob
2020-10-05
17 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-10-05
17 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I found it fascinating while it describes the codec algorithms.

Please find below a …
[Ballot comment]
Thank you for the work put into this document. I found it fascinating while it describes the codec algorithms.

Please find below a couple of non-blocking COMMENT points.

I also support Alissa's point about using figure numbers/legends.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
May I suggest to expand/explain FFV1 on first use ? Still wondering what FFV1 means BTW...
Also, the lossless encoding is probably the key property of this codec and should probably be mentioned in the abstract.

-- Section 2 --
In an informational document, the use of BCP 14 is not required. Suggest to remove this part.

-- Section 7 --
Should it be included in section 8 rather than referenced to?
2020-10-05
17 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-10-02
17 Martin Duke
[Ballot comment]
I found this quite difficult to follow. An introductory section that explains the overall framework and how the various components fit in it …
[Ballot comment]
I found this quite difficult to follow. An introductory section that explains the overall framework and how the various components fit in it would be very helpful.
2020-10-02
17 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-10-02
17 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-25
17 Murray Kucherawy IESG state changed to IESG Evaluation from IESG Evaluation - Defer
2020-09-23
17 Alissa Cooper
[Ballot comment]
Glad to see this work finishing up.

I think it would be better if each figure were explained in the text (e.g., "..., …
[Ballot comment]
Glad to see this work finishing up.

I think it would be better if each figure were explained in the text (e.g., "..., as shown in Figure 9"), or if the figure numbers were dropped.
2020-09-23
17 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-21
17 Erik Kline
[Ballot comment]
[[ comments ]]

[ section 3.3 ]

* Suggest either defining colorspace_type value and coder_type values
  before using them, or provide a …
[Ballot comment]
[[ comments ]]

[ section 3.3 ]

* Suggest either defining colorspace_type value and coder_type values
  before using them, or provide a reference in this section (i.e. just
  include a reference to sections 4.2.3 and 4.2.5).


[[ nits ]]

[ section 3.2 ]

* In the description of Figure 3:
  "relatively positions" -> "relatively positioned", I think.

[ section 3.3 ]

* "signed 16-bit signed integer": choose any one instance of 'signed', I'd say

[ section 3.7.2 ]

* "and then if used transparency" -> "and then, if used, transparency"
2020-09-21
17 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-21
17 Murray Kucherawy Telechat date has been changed to 2020-10-08 from 2020-09-24
2020-09-21
17 Murray Kucherawy IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2020-09-18
17 Barry Leiba
[Ballot discuss]
There are a number of things I’d like to discuss, because I find them not understandable.  Perhaps it’s simply because I’m not a …
[Ballot discuss]
There are a number of things I’d like to discuss, because I find them not understandable.  Perhaps it’s simply because I’m not a codec expert, but, while I understand that this is written for readers who will actually be implementing he FFV1 codec, some of them will also not be “experts”.  That said, I’m sure some of this is just a case of “give Barry some clue and it’s fine.”

— Section 2.1 —
You use the term “symbol” here and later, without defining it, and I don’t know what it is.  A byte?  A character?  A string of bits?  What length?

— Section 3.8.1.1 —
I’m not sure how to interpret the stuff in this section.  First, I don’t know why there are seven “figures”, with no captions nor other explanation.  Second, I’m having trouble making sense out of things like this:

  S_(i + 1, C_(i)) =  zero_state_(S_(i, C_(i)))  AND
              l_(i) =  L_(i)                      AND
              t_(i) =  R_(i) - r_(i)              <==
              b_(i) =  0                          <==>
              L_(i) <  R_(i) - r_(i)

Can you explain how this is meant to be read?  Maybe it’s just me, and maybe after you explain it I’ll whack myself on the head and say, “Doh!”

Third, you say, “S_(0, i) is the i-th initial state,” but you haven’t previously introduced the term “state”, and I don’t know what it means.

— Section 3.8.1.2 —

  "get_rac" returns a boolean, computed from the bytestream as
  described in Section 3.8.1.1.

I see nothing in Section 3.8.1.1 that describes get_rac.

— Section 3.8.1.3 —

  At keyframes all Range coder state variables are set to their initial
  state.

What does “at keyframes” mean?

— Section 3.8.1.5 —
This is just a list of numbers with no explanation.  It needs text explaining what it means.

— Section 3.8.2.2 —

  The level is identical to the predicted one.
  The run and the first different level are coded.

What does “level” mean?  It’s not defined anywhere.

— Section 4.3.1 —

  "reserved_for_future_use" has semantics that are reserved for future
  use.

Yes, that seems rather obvious, though it’s oddly worded.  But then you say what to do with “this value”, and nowhere do you say what the value is.  How does one know?
2020-09-18
17 Barry Leiba
[Ballot comment]
Some editorial comments that I ask you to please consider:

General: It’s jarring to see the defined terms, such as “Sample” and “Pixel” …
[Ballot comment]
Some editorial comments that I ask you to please consider:

General: It’s jarring to see the defined terms, such as “Sample” and “Pixel” in quotes every time they’re used.  More common practice is to quote them when they’re first defined, and then to just use the capitalization to show that they’re defined terms.  I find that the quotes affect the readability and make it somewhat more of a challenge to read.

— Section 2.1 —

  "Plane": A discrete component of a static image comprised of

Total, total nit, and pet peeve: “composed of” or “comprising”, but not “comprised of”.

— Section 2.2.2 —
You’re missing “a % b”, which is referenced in Section 2.2.6.

— Section 2.2.4 —

  "a > b" means a is greater than b.
  "a >= b" means a is greater than or equal to b.
  "a < b" means a is less than b.
  "a <= b" means a is less than or equal b.
  "a == b" means a is equal to b.
  "a != b" means a is not equal to b.
 
I don’t think anyone will misunderstand this, so it’s a very small thing, but… might this be better said as, ‘ "a > b" is true when a is greater than b. ‘ (and similarly for the rest)?

— Section 2.2.5 —

  "min(a,b)" means the smallest of two values a and b.
  "max(a,b)" means the largest of two values a and b.

Nit: “smaller” and “larger”, for only two.

— Section 2.2.7 —

  "a...b" means any value starting from a to b, inclusive.

“starting”?  I would leave that word out.

— Section 2.2.9.1 —

  "remaining_bits_in_bitstream( )" means the count of remaining bits

Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as do Sections 4.4 and 4.5.  This should too, yes?

— Section 3.2 —

      Figure 3: A depiction of how relatively positions Samples are
                      references within this document.

I think you mean “positioned” and “referenced”, yes?

— Section 3.3 —

  Background: a two's complement signed 16-bit signed integer was used

I’d remove the first “signed”.

— Section 3.8.2 —

  The end of the bitstream of the "Frame" is filled with 0-bits until
  that the bitstream contains a multiple of 8 bits.

Is “that” just an extra word that needs to be struck, or is something else wrong here?  And is this meant to be what we usually call “padding”?

— Section 4 —

  Within the following sub-sections, pseudo-code is used to explain the
  structure of each FFV1 bitstream component, as described in
  Section 2.2.1.

I read this as saying that Section 2.2.1 describes the structure of each FFV1 bitstream component, until I went back there and looked.  I suggest reordering the sentence to help the reader a bit:

NEW
  Within the following sub-sections, pseudo-code is used, as described
  in Section 2.2.1, to explain the structure of each FFV1 bitstream
  component.
END

— Section 4.5 —

  Encoders SHOULD NOT fill these bits.
  Decoders SHOULD ignore these bits.

Before this you describe two kinds of bits, and it’s not clear whether these are talking about both kinds, or just the latter.  I think changing “these” to “reserved” is better.

— Section 6 —

  A frequent security problem in image
  and video codecs is also to not check for integer overflows, for
  example to allocate "frame_pixel_width * frame_pixel_height" in
  "Pixel" count computations without considering that the
  multiplication result may have overflowed the arithmetic types range.

This is somewhat complex and awkward (arguably a comma splice), and I suggest splitting the sentence thus:

NEW
  A frequent security problem in image
  and video codecs is failure to check for integer overflows.  An
  example is allocating "frame_pixel_width * frame_pixel_height" in
  "Pixel" count computations without considering that the
  multiplication result may have overflowed the arithmetic types range.
END

I might also make the “must” in the last sentence of that paragraph be “MUST”.
2020-09-18
17 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2020-09-14
17 Amy Vezza Placed on agenda for telechat - 2020-09-24
2020-09-12
17 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-09-12
17 Murray Kucherawy Ballot has been issued
2020-09-12
17 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2020-09-12
17 Murray Kucherawy Created "Approve" ballot
2020-09-12
17 Murray Kucherawy Ballot writeup was changed
2020-09-07
17 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-09-06
17 Qin Wu Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Qin Wu. Sent review to list.
2020-09-04
17 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-09-04
17 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cellar-ffv1-17. 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-ffv1-17. 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 Media Types registry located at:

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

a new media type is to be registered in the video type registry as follows:

Name: FFV1
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 actions 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 list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-09-03
17 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2020-09-03
17 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2020-08-24
17 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-09-07):

From: The IESG
To: IETF-Announce
CC: Michael Richardson , "Peter B." , superuser@gmail.com, cellar@ietf.org …
The following Last Call announcement was sent out (ends 2020-09-07):

From: The IESG
To: IETF-Announce
CC: Michael Richardson , "Peter B." , superuser@gmail.com, cellar@ietf.org, cellar-chairs@ietf.org, draft-ietf-cellar-ffv1@ietf.org, pb@das-werkstatt.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (FFV1 Video Coding Format Version 0, 1, and 3) to Informational RFC


The IESG has received a request from the Codec Encoding for LossLess
Archiving and Realtime transmission WG (cellar) to consider the following
document: - 'FFV1 Video Coding Format Version 0, 1, and 3'
  as Informational RFC

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 2020-09-07. 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 FFV1, a lossless intra-frame video encoding
  format.  FFV1 is designed to efficiently compress video data in a
  variety of pixel formats.  Compared to uncompressed video, FFV1
  offers storage compression, frame fixity, and self-description, which
  makes FFV1 useful as a preservation or intermediate video format.




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



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

This document contains a downward reference to RFC 4732.


2020-08-24
17 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-08-24
17 Cindy Morgan Last call announcement was changed
2020-08-24
17 Cindy Morgan Last call announcement was generated
2020-08-21
17 Murray Kucherawy Last call was requested
2020-08-21
17 Murray Kucherawy Last call was requested
2020-08-21
17 Murray Kucherawy Last call announcement was changed
2020-08-21
17 Murray Kucherawy IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup
2020-08-21
17 Murray Kucherawy Last call announcement was changed
2020-08-21
17 Murray Kucherawy Last call announcement was generated
2020-08-21
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-08-21
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-08-21
17 Dave Rice New version available: draft-ietf-cellar-ffv1-17.txt
2020-08-21
17 (System) New version approved
2020-08-21
17 (System) Request for posting confirmation emailed to previous authors: Dave Rice , Michael Niedermayer , Jerome Martinez
2020-08-21
17 Dave Rice Uploaded new revision
2020-07-30
16 Murray Kucherawy Jerome has some document changes pending in response to the GenART review.
2020-07-30
16 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup
2020-07-21
16 Liang Xia Request for Last Call review by SECDIR Completed: Ready. Reviewer: Liang Xia. Sent review to list.
2020-07-18
16 Murray Kucherawy Awaiting disposition of GenART feedback.
2020-07-18
16 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead
2020-07-16
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-07-13
16 Joel Halpern Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2020-07-13
16 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-07-13
16 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cellar-ffv1-16. 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-ffv1-16. 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 video Media Types registry on the Media Types registry page located at:

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

a single, new media type will be registered as follows:

Name: FFV1
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 actions 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 list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-07-09
16 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2020-07-09
16 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2020-07-09
16 Jean Mahoney Requested Last Call review by GENART
2020-07-03
16 Jean Mahoney Closed request for Last Call review by GENART with state 'Withdrawn': Reviewer rejected request
2020-07-03
16 Gyan Mishra Assignment of request for Last Call review by GENART to Gyan Mishra was rejected
2020-07-02
16 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2020-07-02
16 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2020-07-02
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2020-07-02
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2020-07-02
16 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-07-02
16 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-07-16):

From: The IESG
To: IETF-Announce
CC: cellar@ietf.org, cellar-chairs@ietf.org, draft-ietf-cellar-ffv1@ietf.org, pb@das-werkstatt.com, "Peter …
The following Last Call announcement was sent out (ends 2020-07-16):

From: The IESG
To: IETF-Announce
CC: cellar@ietf.org, cellar-chairs@ietf.org, draft-ietf-cellar-ffv1@ietf.org, pb@das-werkstatt.com, "Peter B." , Michael Richardson , superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (FFV1 Video Coding Format Version 0, 1, and 3) to Informational RFC


The IESG has received a request from the Codec Encoding for LossLess
Archiving and Realtime transmission WG (cellar) to consider the following
document: - 'FFV1 Video Coding Format Version 0, 1, and 3'
  as Informational RFC

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 2020-07-16. 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 FFV1, a lossless intra-frame video encoding
  format.  FFV1 is designed to efficiently compress video data in a
  variety of pixel formats.  Compared to uncompressed video, FFV1
  offers storage compression, frame fixity, and self-description, which
  makes FFV1 useful as a preservation or intermediate video format.




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



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

This document contains a downward reference to RFC 4732.


2020-07-02
16 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-07-02
16 Murray Kucherawy Last call was requested
2020-07-02
16 Murray Kucherawy Ballot approval text was generated
2020-07-02
16 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-07-02
16 Murray Kucherawy Last call announcement was changed
2020-07-02
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-02
16 Dave Rice New version available: draft-ietf-cellar-ffv1-16.txt
2020-07-02
16 (System) New version approved
2020-07-02
16 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2020-07-02
16 Dave Rice Uploaded new revision
2020-07-02
15 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-06-29
15 Peter Bubestinger-Steindl
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.


## Addressed Comments

On April 29th 2020, Murray S. Kucherawy posted comments on version -13. Those
comments were mainly remarks and suggestions about wording, formatting and a few
clarification improvements.

These comments were addressed and fixed in several patches and sorted out
completely by June 23rd 2020.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on FFV1. Especially since it is based on 40 year old algorithms.



# Other Points

  * There is a downref to
    [RFC 4732 (Internet Denial-of-Service Considerations)](https://tools.ietf.org/html/rfc4732)
  * The downref is currently not listed yet in
    [IETF's Downref Registry](https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry)




2020-06-29
15 Peter Bubestinger-Steindl
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.


## Addressed Comments

On April 29th 2020, Murray S. Kucherawy posted comments on version -13. Those
comments were mainly remarks and suggestions about wording, formatting and a few
clarification improvements.

These comments were addressed and fixed in several patches and sorted out
completely by June 23rd 2020.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on FFV1. Especially since it is based on 40 year old algorithms.


# Other Points

  * There is a downref to
    [RFC 4732 (Internet Denial-of-Service Considerations)](https://tools.ietf.org/html/rfc4732)
  * The downref is currently not listed yet in
    [IETF's Downref Registry](https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry)




2020-06-29
15 Peter Bubestinger-Steindl
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.


## Addressed Comments

On April 29th 2020, Murray S. Kucherawy posted comments on version -13. Those
comments were mainly remarks and suggestions about wording, formatting and a few
clarification improvements.

These comments were addressed and fixed in several patches and sorted out
completely by June 23rd 2020.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on FFV1. Especially since it is based on 40 year old algorithms.


# Other Points

  * There is a downref to [RFC 4732 (Internet Denial-of-Service Considerations)](https://tools.ietf.org/html/rfc4732)
  * The downref is currently not listed yet in [IETF's Downref Registry](https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry)




2020-06-29
15 Peter Bubestinger-Steindl
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.


## Addressed Comments

On April 29th 2020, Murray S. Kucherawy posted comments on version -13. Those
comments were mainly remarks and suggestions about wording, formatting and a few
clarification improvements.

These comments were addressed and fixed in several patches and sorted out
completely by June 23rd 2020.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on FFV1. Especially since it is based on 40 year old algorithms.


# Other Points

  * There is a downref to
    [RFC 4732 (Internet Denial-of-Service Considerations)](https://tools.ietf.org/html/rfc4732)
  * The downref is currently not listed yet in
    [IETF's Downref Registry](https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry)




2020-06-23
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-06-23
15 Dave Rice New version available: draft-ietf-cellar-ffv1-15.txt
2020-06-23
15 (System) New version approved
2020-06-23
15 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Michael Niedermayer , Dave Rice
2020-06-23
15 Dave Rice Uploaded new revision
2020-06-01
14 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-05-26
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-05-26
14 Dave Rice New version available: draft-ietf-cellar-ffv1-14.txt
2020-05-26
14 (System) New version approved
2020-05-26
14 (System) Request for posting confirmation emailed to previous authors: Dave Rice , Jerome Martinez , Michael Niedermayer
2020-05-26
14 Dave Rice Uploaded new revision
2020-04-28
13 Murray Kucherawy Ballot writeup was changed
2020-04-28
13 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-04-28
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-04-28
13 Dave Rice New version available: draft-ietf-cellar-ffv1-13.txt
2020-04-28
13 (System) New version approved
2020-04-28
13 (System) Request for posting confirmation emailed to previous authors: Michael Niedermayer , Jerome Martinez , Dave Rice
2020-04-28
13 Dave Rice Uploaded new revision
2020-03-25
12 Amy Vezza Shepherding AD changed to Murray Kucherawy
2020-01-29
12 Adam Roach Waiting for new document to address blocking comments from AD review
2020-01-29
12 Adam Roach IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-01-28
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-01-28
12 Dave Rice New version available: draft-ietf-cellar-ffv1-12.txt
2020-01-28
12 (System) New version approved
2020-01-28
12 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2020-01-28
12 Dave Rice Uploaded new revision
2020-01-27
12 Adam Roach Waiting for new document to address blocking comments from AD review
2020-01-27
12 Adam Roach IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-01-27
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-01-27
12 Dave Rice New version available: draft-ietf-cellar-ffv1-12.txt
2020-01-27
12 (System) New version approved
2020-01-27
12 (System) Request for posting confirmation emailed to previous authors: Dave Rice , Jerome Martinez , Michael Niedermayer
2020-01-27
12 Dave Rice Uploaded new revision
2020-01-02
11 Adam Roach See AD Review at https://mailarchive.ietf.org/arch/msg/cellar/4MNYpqz1VGtZ1oiQIfgfw_cdOKk
2020-01-02
11 Adam Roach IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-11-18
11 Adam Roach Changed consensus to Yes from Unknown
2019-11-18
11 Adam Roach IESG state changed to AD Evaluation from Publication Requested::AD Followup
2019-10-23
11 Dave Rice New version available: draft-ietf-cellar-ffv1-11.txt
2019-10-23
11 (System) New version approved
2019-10-23
11 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2019-10-23
11 Dave Rice Uploaded new revision
2019-10-10
10 Dave Rice New version available: draft-ietf-cellar-ffv1-10.txt
2019-10-10
10 (System) New version approved
2019-10-10
10 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2019-10-10
10 Dave Rice Uploaded new revision
2019-09-06
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-09-06
09 Dave Rice New version available: draft-ietf-cellar-ffv1-09.txt
2019-09-06
09 (System) New version approved
2019-09-06
09 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2019-09-06
09 Dave Rice Uploaded new revision
2019-08-30
08 Adam Roach Waiting on authors to submit a version that meets RFC line length limits
2019-08-30
08 Adam Roach IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested
2019-08-13
08 Dave Rice New version available: draft-ietf-cellar-ffv1-08.txt
2019-08-13
08 (System) New version approved
2019-08-13
08 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2019-08-13
08 Dave Rice Uploaded new revision
2019-08-05
07 Alexey Melnikov Shepherding AD changed to Adam Roach
2019-03-27
07 Cindy Morgan Shepherding AD changed to Alexey Melnikov
2019-02-28
07 Peter Bubestinger-Steindl
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on FFV1. Especially since it is based on 40 year old algorithms.



# Other Points
None at the moment.




2019-02-28
07 Peter Bubestinger-Steindl
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on algorithms or parts of FFV1, but it's not 100% guaranteed.



# Other Points
None at the moment.




2019-02-28
07 Michael Richardson Notification list changed to Michael Richardson <mcr+ietf@sandelman.ca>, "Peter B." <pb@das-werkstatt.com> from Michael Richardson <mcr+ietf@sandelman.ca>
2019-02-28
07 Michael Richardson Document shepherd changed to Peter B.
2019-02-27
07 Michael Richardson
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on algorithms or parts of FFV1, but it's not 100% guaranteed.



# Other Points





2019-02-27
07 Michael Richardson Responsible AD changed to Ben Campbell
2019-02-27
07 Michael Richardson IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-02-27
07 Michael Richardson IESG state changed to Publication Requested from I-D Exists
2019-02-27
07 Michael Richardson IESG process started in state Publication Requested
2019-02-27
07 Michael Richardson Tag Doc Shepherd Follow-up Underway cleared.
2019-02-27
07 Michael Richardson
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
Ben Campbell is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on algorithms or parts of FFV1, but it's not 100% guaranteed.



# Other Points





2019-02-27
07 Michael Richardson Notification list changed to Michael Richardson <mcr+ietf@sandelman.ca>
2019-02-27
07 Michael Richardson Document shepherd changed to Michael Richardson
2019-02-27
07 Michael Richardson Intended Status changed to Informational from None
2019-02-27
07 Michael Richardson Tag Doc Shepherd Follow-up Underway set.
2019-02-27
07 Michael Richardson IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-02-27
07 Michael Richardson
# Summary

The document shepherd is Peter Bubestinger-Steindl.
[TODO] is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design …
# Summary

The document shepherd is Peter Bubestinger-Steindl.
[TODO] is the responsible Area Director.

This document describes FFV1, a lossless video encoding format. The design of
FFV1 considers the storage of image characteristics, data fixity, and the
optimized use of encoding time and storage requirements. FFV1 is designed to
support a wide range of lossless video applications such as long-term
audiovisual preservation, scientific imaging, screen recording, and other video
encoding scenarios that seek to avoid the generational loss of lossy video
encodings.  This document defines version 0, 1 and 3 of FFV1.

The working group has chosen Informational as the requested publication type.


# Review and Consensus

Since FFV1 (version 0,1,3) already exists and is in production use for many
years already, there was a clear consensus for these versions. Although the
number of people interested in, and working with this format is growing, the
document itself was written and reviewed by a rather small group.

This small group however, consists of a team of experts in audiovisual format
encodings, where most of them have actively been working with FFV1 since its
early days. The knowhow and expertise in this group is a good mix between AV,
codec implementation, real world lossless video use cases, as well as mathematics.

FFV1 was mainly described for use in an audiovisual preservation context, which
is currently still its major use case. Its reference implementation is in FFmpeg
(which is also currently the most widely used one). Additional implementations
were written according to an earlier version of this document, by one of its
authors, Jérôme Martinez in "[MediaConch](https://mediaarea.net/MediaConch)" and
"[RAWCooked](https://mediaarea.net/RAWcooked)".
MediaConch was designed as conformance checker for validating FFV1 files
according to its specs.

I have personally tested and verified all three: the reference implementation (see:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/), as well as
MediaConch and RAWcooked.

I found the document very well written and easy and clear to understand, and was
actually a bit surprised that it is so comprehensible, considering that it is
describing a video encoding format. I have not double-checked the math behind it
though.



# Intellectual Property

Each author has confirmed conformance with BCP 78/79 to the best of their
knowledge.

During the PREFORMA project, which was looking for "good quality standardised
file formats for preserving data content in the long term" (Quote:
http://www.preforma-project.eu/), Professor Björn Lundell from the Swedish
University of Skövde (http://www.preforma-project.eu/skovde.html), was to check
licensing and patent situations of evaluated formats.

He did not discover any IPR claims on parts/algorithms of FFV1.
The current known consensus about this is, that is is highly unlikely that there
are IPR claims on algorithms or parts of FFV1, but it's not 100% guaranteed.



# Other Points





2019-02-06
07 Dave Rice New version available: draft-ietf-cellar-ffv1-07.txt
2019-02-06
07 (System) New version approved
2019-02-06
07 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2019-02-06
07 Dave Rice Uploaded new revision
2019-02-02
06 Michael Richardson The WGLC on this document was started on 2019-02-02, and will run until 2019-02-16.
2019-02-02
06 Michael Richardson IETF WG state changed to In WG Last Call from WG Document
2018-10-18
06 Dave Rice New version available: draft-ietf-cellar-ffv1-06.txt
2018-10-18
06 (System) New version approved
2018-10-18
06 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2018-10-18
06 Dave Rice Uploaded new revision
2018-09-25
05 Dave Rice New version available: draft-ietf-cellar-ffv1-05.txt
2018-09-25
05 (System) New version approved
2018-09-25
05 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2018-09-25
05 Dave Rice Uploaded new revision
2018-07-27
04 Dave Rice New version available: draft-ietf-cellar-ffv1-04.txt
2018-07-27
04 (System) New version approved
2018-07-27
04 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2018-07-27
04 Dave Rice Uploaded new revision
2018-07-05
03 Matthew Miller Request for Early review by GENART Completed: On the Right Track. Reviewer: Matthew Miller. Sent review to list.
2018-06-01
03 Dave Rice New version available: draft-ietf-cellar-ffv1-03.txt
2018-06-01
03 (System) New version approved
2018-06-01
03 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2018-06-01
03 Dave Rice Uploaded new revision
2018-06-01
02 Liang Xia Request for Early review by SECDIR Completed: Ready. Reviewer: Liang Xia. Sent review to list.
2018-05-31
02 Jean Mahoney Request for Early review by GENART is assigned to Matthew Miller
2018-05-31
02 Jean Mahoney Request for Early review by GENART is assigned to Matthew Miller
2018-05-31
02 Tero Kivinen Request for Early review by SECDIR is assigned to Liang Xia
2018-05-31
02 Tero Kivinen Request for Early review by SECDIR is assigned to Liang Xia
2018-05-29
02 Michael Richardson Requested Early review by ARTART
2018-05-29
02 Michael Richardson Requested Early review by GENART
2018-05-29
02 Michael Richardson Requested Early review by SECDIR
2018-05-22
02 Michael Richardson Tag Other - see Comment Log cleared.
2018-05-22
02 Michael Richardson IETF WG state changed to WG Document from Waiting for WG Chair Go-Ahead
2018-04-22
02 Dave Rice New version available: draft-ietf-cellar-ffv1-02.txt
2018-04-22
02 (System) New version approved
2018-04-22
02 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2018-04-22
02 Dave Rice Uploaded new revision
2018-01-26
01 Dave Rice New version available: draft-ietf-cellar-ffv1-01.txt
2018-01-26
01 (System) New version approved
2018-01-26
01 (System) Request for posting confirmation emailed to previous authors: Jerome Martinez , Dave Rice , Michael Niedermayer
2018-01-26
01 Dave Rice Uploaded new revision
2018-01-04
00 (System) Document has expired
2017-07-03
00 Tessa Fallon Added to session: IETF-99: cellar  Fri-0930
2017-07-03
00 Tessa Fallon reconcile with previously approved WG informational draft
2017-07-03
00 Tessa Fallon Tag Other - see Comment Log set.
2017-07-03
00 Tessa Fallon IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2017-07-03
00 Dave Rice New version available: draft-ietf-cellar-ffv1-00.txt
2017-07-03
00 (System) WG -00 approved
2017-07-02
00 Dave Rice Set submitter to "Dave Rice ", replaces to (none) and sent approval email to group chairs: cellar-chairs@ietf.org
2017-07-02
00 Dave Rice Uploaded new revision