Re: [AVTCORE] RFC6597

Keep in mind that the challenge in moving a proposed standard to full standard is showing that there are multiple interoperable implementations of every feature in the document.  It’s usually easy to document that most of the content has been implemented multiple times interoperably, but it’s usually hard to show that all of it has.  Sometimes, we end up deleting features in our efforts to get to full standard.

> On Oct 8, 2021, at 10:10 AM, Arbeiter, James <jarbeiter@moriartyandassociates.com> wrote:
> 
> Spencer,
>  
> Thank you for responding in kind and with your comprehensive explanation.
>  
> My initial concern was that this RFC was potentially “dropped” from the radar meaning it was no longer a valid specification because we may have failed to follow up. That appears to be not true. This is good to know.
>  
> Our community (US government based) is expanding its research into AI/ML methods to deliver information in bandwidth-constrained environments. This RFC, which is now in use in some partner NATO nations, may receive more attention in the US because of this research. Since it is an “usable” specification at this point I believe this is sufficient to warrant its continued and possible future uses. Should this RFC become more instrumental as we progress it may at that point be worthwhile to address its movement to an Internet Standard.
>  
> Thank you again, and if I have made any incorrect assumptions, please do correct me.
>  
> Respectively,
>  
> Jim Arbeiter
> NGA/MISB
> Moriarty and Associates
> JArbeiter@MoriartyandAssociates.com <mailto:JArbeiter@MoriartyandAssociates.com>
> 321-355-9858
>  
> From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> 
> Sent: Friday, October 8, 2021 9:40 AM
> To: Arbeiter, James <jarbeiter@moriartyandassociates.com>
> Cc: payload@ietf.org
> Subject: Re: [AVTCORE] RFC6597
>  
> Hi, Jim Arbeiter,
>  
> On Thu, Oct 7, 2021 at 10:29 AM Arbeiter, James <jarbeiter@moriartyandassociates.com <mailto:jarbeiter@moriartyandassociates.com>> wrote:
> In April 2012 RFC6597 was completed and published. While it was assumed this document was on the Standards Track to become an Internet Standard it appears this was not the case. Is there a process needed to continue this document onto becoming an internet standard? Please advise.
>  
> So, now that we've refreshed our memory about the IETF standards process ... 🙂
>  
> Let's go back to your original question. 
> Yes, there is a process to advance to Internet Standard.
> That process doesn't happen automatically.
> For most documents on the standards track, we are happy to leave a document at Proposed Standard level, because "standards track" is the important part for many people inside the IETF. . 
> People outside the IETF care more about that distinction, so if (for example) Society of Motion Picture and Television Engineers (SMPTE) thought it was important that the specification should be an Internet Standard, it's possible to pursue that classification (doesn't have to be a formal body, but it often is)
> I didn't see a reply to your question that included a link to https://www.rfc-editor.org/rfc/inline-errata/rfc6410.html <https://www.rfc-editor.org/rfc/inline-errata/rfc6410.html>, which describes the requirements to advance to Internet Standard (I'm intentionally pointing to the version of that document that includes approved errata), but it looks like the process is (in section 2.2)
>    The IESG, in an IETF-wide Last Call of at least four weeks, confirms
>    that a document advances from Proposed Standard to Internet Standard.
>    The request for reclassification is sent to the IESG along with an
>    explanation of how the criteria have been met.  The criteria are:
>  
>    (1) There are at least two independent interoperating implementations
>        with widespread deployment and successful operational experience.
>  
>    (2) There are no errata against the specification that would cause a
>        new implementation to fail to interoperate with deployed ones.
>  
>    (3) There are no unused features in the specification that greatly
>        increase implementation complexity.
>  
>    (4) If the technology required to implement the specification
>        requires patented or otherwise controlled technology, then the
>        set of implementations must demonstrate at least two independent,
>        separate and successful uses of the licensing process.
>  
> So, the first question is, does someone need this RFC to be an Internet Standard? If so, that's a conversation we could have, and asking if anyone on this mailing list would object is a great first step (because knowing about objections early is always a good thing). 
>  
> Does that help? 
>  
> Best,
>  
> Spencer, wearing absolutely no hats
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt