From nobody Fri Oct 8 08:02:19 2021 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E4D3A005C for ; Fri, 8 Oct 2021 08:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SUBJ_ALL_CAPS=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSpIYa4mJVyK for ; Fri, 8 Oct 2021 08:02:11 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CFD3A003C for ; Fri, 8 Oct 2021 08:02:11 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id p4so9702479qki.3 for ; Fri, 08 Oct 2021 08:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VJ0lh7THB/pRAWpTlEpgdxXa946BIJ9isknHmwUHvMU=; b=HJjHisvdCSpSvuZMCpVC73CMaCSiyL2LtL2nDTkpSNsOozS+mb+J/C/PvQ6Qjouu2a O/IK9ymElDTPYffZq0LTNllE1eeD9u9rqlb/mPss6TEkGaR3xvl+bSD9G/F430BZIslB 38oE/rgiltTTbUOhJThBv8+BKkAVoZ1cT31XNfDx4PUUGFF/N9T/EdQa6WVecwBY5TtF UTPLy5Hps56RUqQGItN8NfREu5xEDTpbtUmDnlr90htIfhosNqGNoV+nSnWI8Ueoj3km q2at2lhFpTTArbAPwBk/QxUwox9XO9eaWjy7pFzdJGP8ccGh4sJtrstgTwUMrDfHGCIU il2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VJ0lh7THB/pRAWpTlEpgdxXa946BIJ9isknHmwUHvMU=; b=wL9VVHzBlGdYZP64LiDPp9/OWrY2KlkXh7oA3TbNYAbohei2l8MBsJ/jEkrPkZ9hWI n5BuwUK6Rohwgie3bzkJcH6eHtQErM6AAgnwCMlICn1P8KU7xxQBjIEcdOQ54NAt0vJI v4+oqA4WsoHlmPS/Peah570uG9lXfdCQKxyB262n43Ut7eAmknfRyTqWjqTklSy79pcc Z4NzILCBdJMjpoZ17Ddzq0kGiI3tioY4KB8LrZos6U9C4aR0eiuMz0E4HH8mK5/nVW5H yvd5GUHJsPdcQ8MpSYCK4I2t3VHt2e94eRKt6F9wvWayZ6Co7/llNoX4qFlTRZLCBjU3 Cn6g== X-Gm-Message-State: AOAM530DJK2gWpKggpWJfhjSOlbh7jHm8wgFNRX8VeSUe6Z/ClCBc4TO b3nmmjtJm8k+R/ZwAAtLtydl4g8WbFYi8ctT X-Google-Smtp-Source: ABdhPJxbKuODpP6tNLBRpmtvK1v2ZOZ8sxtaDi68THB20Toz38WaT1EpzTiC/jnUGyaC3Iv55CNBIQ== X-Received: by 2002:a37:2e82:: with SMTP id u124mr3398606qkh.58.1633705330060; Fri, 08 Oct 2021 08:02:10 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id u20sm2252269qke.66.2021.10.08.08.02.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Oct 2021 08:02:09 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C9F5BFA1-953A-415A-BD17-54ED6C5841A9" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 8 Oct 2021 11:02:08 -0400 In-Reply-To: Cc: "Apple Inc." , "payload@ietf.org" To: "Arbeiter, James" References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [AVTCORE] RFC6597 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 15:02:17 -0000 --Apple-Mail=_C9F5BFA1-953A-415A-BD17-54ED6C5841A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99s usually = easy to document that most of the content has been implemented multiple = times interoperably, but it=E2=80=99s 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 = wrote: >=20 > Spencer, > =20 > Thank you for responding in kind and with your comprehensive = explanation. > =20 > My initial concern was that this RFC was potentially =E2=80=9Cdropped=E2= =80=9D 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. > =20 > 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 =E2=80=9Cusable=E2=80=9D 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. > =20 > Thank you again, and if I have made any incorrect assumptions, please = do correct me. > =20 > Respectively, > =20 > Jim Arbeiter > NGA/MISB > Moriarty and Associates > JArbeiter@MoriartyandAssociates.com = > 321-355-9858 > =20 > From: Spencer Dawkins at IETF =20 > Sent: Friday, October 8, 2021 9:40 AM > To: Arbeiter, James > Cc: payload@ietf.org > Subject: Re: [AVTCORE] RFC6597 > =20 > Hi, Jim Arbeiter, > =20 > On Thu, Oct 7, 2021 at 10:29 AM Arbeiter, James = > 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. > =20 > So, now that we've refreshed our memory about the IETF standards = process ... =F0=9F=99=82 > =20 > Let's go back to your original question.=20 > 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. .=20 > 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 = , 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: > =20 > (1) There are at least two independent interoperating = implementations > with widespread deployment and successful operational = experience. > =20 > (2) There are no errata against the specification that would cause = a > new implementation to fail to interoperate with deployed ones. > =20 > (3) There are no unused features in the specification that greatly > increase implementation complexity. > =20 > (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. > =20 > 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).=20 > =20 > Does that help?=20 > =20 > Best, > =20 > Spencer, wearing absolutely no hats > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --Apple-Mail=_C9F5BFA1-953A-415A-BD17-54ED6C5841A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s = usually easy to document that most of the content has been implemented = multiple times interoperably, but it=E2=80=99s 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 =E2=80=9Cdropped=E2=80=9D 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 = =E2=80=9Cusable=E2=80=9D 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
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> 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 ... =F0=9F=99=82
 
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, = 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

= --Apple-Mail=_C9F5BFA1-953A-415A-BD17-54ED6C5841A9--