-----邮件原件----- 发件人: Michael Richardson [mailto:mcr+ietf@xxxxxxxxxxxx] 发送时间: 2020年9月7日 10:41 收件人: Qin Wu <bill.wu@xxxxxxxxxx> 抄送: Jerome Martinez <jerome@xxxxxxxxxxxxx>; ops-dir@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-cellar-ffv1.all@xxxxxxxx; cellar@xxxxxxxx 主题: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 <#secure method=pgpmime mode=sign> Qin Wu <bill.wu@xxxxxxxxxx> wrote: > [Qin]: I get impression you change update RFC process, usually we have > existing, published RFC first, and then make bis document and revise > the existing RFC, now you progress multiple release in parallel, which > is something I haven't seen before. There are many processes. The IETF has often published an Informational draft on an existing "defacto" specification that is unchangeable because it is already deployed. I believe this happened for POP3, IMAP, HTTP 0.9, and a number of other well known protocols. Then we do "v2.0" which is standards track, and which is subject to IETF change control. Except that this time, it is 4.0 not 2.0. [In fact, there is no v2 for ffv because it never got deployed] (Such a process was not done, btw. for TACACS for reasons that were never adequately explained to me) [Qin]: Good clarification, thanks Michale. jerome> FFV1 is a video coding format, like Opus is an audio coding jerome> format, Opus does not specify transport too. FFV1 is intended to jerome> be encapsulated in a container and we don't feel the need to have jerome> a dedicated transport for FFV1, we use (de facto or not) standard jerome> like MP4 (ISO standard) or Matroska (de facto standard and IETF jerome> standard candidate) for the transport. Note that Opus is an IETF jerome> standard (RFC 6716) without transport. > [Qin]: We also see OPUS with RTP transport has been published as > RFC7587. Anyway I leave this issue to you. Yes, but RFC7587 does not define the OPUS CODEC. The OPUS Codec is defined in RFC6716. RFC7587 defines how to carry RFC6716 transmissions in RFC3550 format. We have a document, draft-ietf-cellar-matroska, which is a bit equivalent to RFC7587. But, not involving RTP. If there were interest in using ffv4 in the future over RTP, then we'd have to explain how to do that. CELLAR is focused on archival needs, not real time needs. [Qin]:Not my suggestion to support RTP, just provide analogy. Your clarification looks good to me now. Thanks. > [Qin]: which protocol is used to configure these parameters? How do you > prevent misconfiguration from malicious client? First, it's a data format, not a protocol. So there is no configuration or negotiation involved. The chosen parameters are either valid, and the decoder can deal with them, or it can't. [Qin]: Good explanation, the word "configuration" confuses me a lot, which make me wonder who generate configuration, who install configuration, where these configuration is executed. -- Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
