Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
From: Rebecca VanRheenen <rvanrheenen@staff.rfc-editor.org>
In-Reply-To: <F42739D3-4F52-4759-940B-C95A0B4CA68F@staff.rfc-editor.org>
Date: Thu, 16 Jul 2026 11:34:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D02DC13-0B03-48A3-A7D9-AEDBB35C4EE4@staff.rfc-editor.org>
References: <178157177921.17.5053891013411922502@rfc-editor.org>
 <fpByeI10SpO9AltDQpmDBCTBzxWruXWwl4M3Ow9VxRe_rNo61P93YCRUHOlMRjVYzLTzo_8Cr0Xe1NDDD_t__vCNtLC2Ao_tebk2qZD6pWs=@protonmail.com>
 <c38c203b-4de1-4251-a902-c6b50a3a2c5d@hxr.us>
 <46BC7DCE-F8CD-499A-9514-B557BCA41392@staff.rfc-editor.org>
 <E669DB0D-4912-4851-A591-430E3CD80F93@staff.rfc-editor.org>
 <2W492puUnKp6c5ip5eYiEGeE3K_p3gK44_zsCoAo5DCXBeP5aJo_Zcv8OdHLu3p1NEjz5AMu0jF9HhT6pEwy07a_HLRBA_58nnjE4KXjxeQ=@protonmail.com>
 <281ADAFD-CDFE-4D2D-A6C0-5AF41B320DA8@staff.rfc-editor.org>
 <X7csAwKGohliD4HY0vZReniMFU3w1SBpqSB6hZPTXv3TiWovAW2OR8PG2SzxBpEaSVIYG2doE_iH2xOPkR5GeeQ3MR207UNZTAxijXol54E=@protonmail.com>
 <8E542143-3F06-490E-9133-4927771BAB25@staff.rfc-editor.org>
 <8zKoZKnStXvEbnQw7YpdMqwylp6EF15vJp5WYsdTsMtF61SNLDTlIuXK-nzwId1R-0WzDS9pOxkhy6PjJsPjL6gtIGjcgDk6KZnXc4iNQZc=@protonmail.com>
 <F42739D3-4F52-4759-940B-C95A0B4CA68F@staff.rfc-editor.org>
To: Andy Newton <andy@hxr.us>
Message-ID-Hash: ZUOJ3WMPFZR6PI6QIE6YJHQG5TYBG7LK
CC: kaustubh.ietf@gmail.com, Sreekanth Narayanan <sknth.n@protonmail.com>,
 fluffy@iii.ca, RFC Editor <rfc-editor@rfc-editor.org>,
 auth48archive@rfc-editor.org, asap-chairs@ietf.org, art-ads@ietf.org,
 marc@petit-huguenin.org, eckelcu@cisco.com
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_=5BAD=5D_Re=3A_Final_Review=3A_RFC-to-be_10006_=28dra?=
 =?utf-8?q?ft-ietf-asap-sip-auto-peer=29_in_XML/GitHub?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/Vs2rg_7JDX34g1syWCruyjrMKtU>

Hi Andy,

Please review and approve the changes to the JSON in Section 9.1.

This diff files shows just the changes to the JSON:
https://www.rfc-editor.org/authors/rfc10006-lastrfcdiff.html

These diff files show all edits (search for =E2=80=9C9.1=E2=80=9D to =
view the changes to JSON):
https://www.rfc-editor.org/authors/rfc10006-diff.html
https://www.rfc-editor.org/authors/rfc10006-rfcdiff.html (side by side)

Author explanation of changes:=20
>=20
> I've reviewed the files and there is only one that stuck out when =
validating the asap-example.json file with the yang module using =
yanglint. I get the following issue:
>=20
> yanglint -p . ietf-sip-auto-peering@2025-12-21.yang =
asap-example-new.json
> libyang err : Invalid identityref "tlscmn:tls12" value - unable to map =
prefix to YANG schema. =
(/ietf-sip-auto-peering:sip-auto-peering/security/signaling/version) =
(line 1)
> libyang err : Invalid identityref "tlscmn:tls13" value - unable to map =
prefix to YANG schema. =
(/ietf-sip-auto-peering:sip-auto-peering/security/signaling/version) =
(line 1)
> libyang err : Invalid enumeration value =
"iana-sip-option-tags:one-hundred-rel". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
> libyang err : Invalid enumeration value "iana-sip-option-tags:timer". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
> libyang err : Invalid enumeration value =
"iana-sip-option-tags:replaces". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
> libyang err : Invalid enumeration value "iana-sip-option-tags:path". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
> YANGLINT[E]: Failed to parse input data file "asap-example-new.json".
>=20
> To solve the linting in the json file, I had to do the following:
> 1. Replace tlscmn with ietf-tls-common
> 2. Remove "iana-sip-option-tags" prefix from the strings in the =
"extension" member.
>=20
> RFC 7951 requires identityrefs to use the module name in a JSON and =
strings to not contain the prefix.


Best regards,

Rebecca VanRheenen
RFC Production Center


> On Jul 16, 2026, at 11:33=E2=80=AFAM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>=20
> Hi Sreekanth,
>=20
> Thanks! The lines with the following text are exactly 69 chars, so I =
removed the wrapping for those.
>=20
>> "https://capserver.example.org/capserver/capdoc.json"
>=20
>> "https://sipserviceprovider.com/certificateList.pem",
>=20
> I=E2=80=99ll send a separate email asking the AD for approval of the =
changes.
>=20
> Best regards,
>=20
> Rebecca VanRheenen
> RFC Production Center
>=20
>=20
>=20
>> On Jul 16, 2026, at 10:57=E2=80=AFAM, Sreekanth Narayanan =
<sknth.n@protonmail.com> wrote:
>>=20
>> Hi Rebecca,
>>=20
>> Here's the updated file. I've also fixed the wrapping in a couple of =
other lines that went beyond 69 characters.
>>=20
>> Thanks
>> Sreekanth
>>=20
>> On Thursday, July 16th, 2026 at 11:16 PM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>=20
>>> Hi Sreekanth,
>>>=20
>>> Thanks for sending along the updated XML file.
>>>=20
>>> There are two lines that are too long for the TXT output:
>>>=20
>>>> =
"$6$OoEJwExxp6U/FRFq$4RkL2lSSGLoKdfGjX4lQLFXo89gc0wtJsKiBxg/BBz6aNwu7C.D3k=
RUwD7lvJm6rhaCdhSzVh/XfkkAUY2dTu0"
>>>=20
>>>> "version": ["ietf-tls-common:tls12", "ietf-tls-common:tls13=E2=80=9D]=

>>>=20
>>> Can you update the file to wrap these? The line limit for sourcecode =
is 69 characters.
>>>=20
>>> Thanks!
>>>=20
>>> Rebecca VanRheenen
>>> RFC Production Center
>>>=20
>>>=20
>>>=20
>>>> On Jul 16, 2026, at 9:50=E2=80=AFAM, Sreekanth Narayanan =
<sknth.n@protonmail.com> wrote:
>>>>=20
>>>> Hi Rebecca,
>>>>=20
>>>> Here is the XML file updated with the corrected JSON file.
>>>>=20
>>>> Thanks
>>>> Sreekanth
>>>>=20
>>>> On Thursday, July 16th, 2026 at 4:24 AM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>>>=20
>>>>> Hi Sreekanth,
>>>>>=20
>>>>> Thanks for your question. If updates to the JSON are needed, =
please email us an updated XML file that includes the changes. Use the =
XML file in the email below as it contains all the updates so far. Note =
that we will ask the AD to approve any changes to code.
>>>>>=20
>>>>> Note that the RPC parses YANG modules (and ABNF, XML, and MIB), =
but not JSON.
>>>>>=20
>>>>> Thanks!
>>>>>=20
>>>>> Rebecca VanRheenen
>>>>> RFC Production Center
>>>>>=20
>>>>>=20
>>>>>> On Jul 15, 2026, at 11:48=E2=80=AFAM, Sreekanth Narayanan =
<sknth.n@protonmail.com> wrote:
>>>>>>=20
>>>>>> Hi Rebecca,
>>>>>>=20
>>>>>> Thanks for this. I've reviewed the files and there is only one =
that stuck out when validating the asap-example.json file with the yang =
module using yanglint. I get the following issue:
>>>>>>=20
>>>>>> yanglint -p . ietf-sip-auto-peering@2025-12-21.yang =
asap-example-new.json
>>>>>> libyang err : Invalid identityref "tlscmn:tls12" value - unable =
to map prefix to YANG schema. =
(/ietf-sip-auto-peering:sip-auto-peering/security/signaling/version) =
(line 1)
>>>>>> libyang err : Invalid identityref "tlscmn:tls13" value - unable =
to map prefix to YANG schema. =
(/ietf-sip-auto-peering:sip-auto-peering/security/signaling/version) =
(line 1)
>>>>>> libyang err : Invalid enumeration value =
"iana-sip-option-tags:one-hundred-rel". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
>>>>>> libyang err : Invalid enumeration value =
"iana-sip-option-tags:timer". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
>>>>>> libyang err : Invalid enumeration value =
"iana-sip-option-tags:replaces". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
>>>>>> libyang err : Invalid enumeration value =
"iana-sip-option-tags:path". =
(/ietf-sip-auto-peering:sip-auto-peering/extension) (line 1)
>>>>>> YANGLINT[E]: Failed to parse input data file =
"asap-example-new.json".
>>>>>>=20
>>>>>>=20
>>>>>> To solve the linting in the json file, I had to do the following:
>>>>>> 1. Replace tlscmn with ietf-tls-common
>>>>>> 2. Remove "iana-sip-option-tags" prefix from the strings in the =
"extension" member.
>>>>>>=20
>>>>>> RFC 7951 requires identityrefs to use the module name in a JSON =
and strings to not contain the prefix.
>>>>>>=20
>>>>>> Should we change the asap-example.json in the document?
>>>>>>=20
>>>>>> Thanks
>>>>>> Sreekanth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Sent with Proton Mail secure email.
>>>>>>=20
>>>>>> On Wednesday, July 15th, 2026 at 6:36 AM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>>>>>=20
>>>>>>> Hello authors,
>>>>>>>=20
>>>>>>> We have merged the updates in GitHub.
>>>>>>>=20
>>>>>>> Please review the XML file and its TXT, HTML, and PDF outputs, =
and let us know if any changes are required or if you approve the RFC =
for publication. We consider this your final assent that the document is =
ready for publication. To request changes or approve your RFC for =
publication, please reply to this email. Please use =E2=80=98REPLY =
ALL=E2=80=99, as all the parties CCed on this message need to see your =
approval.
>>>>>>>=20
>>>>>>> Also, note that we applied formatting changes to the YANG module =
in Section 7.2 and to the example module in Section 7.3 per issue #15 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/15). =
Both modules parse. To see just these formatting updates, please see =
this diff file:
>>>>>>> =
https://auth48-transition.rfc-editor.org/authors/rfc10006-yangformatting-d=
iff.html
>>>>>>>=20
>>>>>>> The files are available here:
>>>>>>>=20
>>>>>>> XML file:
>>>>>>> https://www.rfc-editor.org/authors/rfc10006.xml
>>>>>>>=20
>>>>>>> Output files:
>>>>>>> https://www.rfc-editor.org/authors/rfc10006.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc10006.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc10006.html
>>>>>>>=20
>>>>>>> Comprehensive diff file of the text:
>>>>>>> https://www.rfc-editor.org/authors/rfc10006-diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc10006-rfcdiff.html (side =
by side)
>>>>>>> https://www.rfc-editor.org/authors/rfc10006-alt-diff.html (makes =
viewing moved text easier)
>>>>>>>=20
>>>>>>> For the Final Review status of this document, please see:
>>>>>>> https://queue.rfc-editor.org/final-review/rfc10006/
>>>>>>>=20
>>>>>>> Thank you,
>>>>>>>=20
>>>>>>> Rebecca VanRheenen
>>>>>>> RFC Production Center
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Jul 14, 2026, at 1:58=E2=80=AFPM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>>>>>>>=20
>>>>>>>> Hi Andy and Sreekanth,
>>>>>>>>=20
>>>>>>>> Thanks for your responses! I updated to use A; see =
https://github.com/rfc-editor-drafts/FinalReview-rfc10006/pull/1/changes/9=
2b6f32d2b11c145594b7b6fd971458ddbbc58a2.
>>>>>>>>=20
>>>>>>>> I also noted Andy=E2=80=99s approval on the Final Review status =
page for this document; see =
https://queue.rfc-editor.org/final-review/rfc10006/.
>>>>>>>>=20
>>>>>>>> I=E2=80=99ll now merge the RPC-edits pull request, and I will =
then provide files by email for Sreekanth and the other authors to =
review and approve.
>>>>>>>>=20
>>>>>>>> Best regards,
>>>>>>>>=20
>>>>>>>> Rebecca VanRheenen
>>>>>>>> RFC Production Center
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Jul 14, 2026, at 11:07=E2=80=AFAM, Andy Newton =
<andy@hxr.us> wrote:
>>>>>>>>>=20
>>>>>>>>> Yes, thank you. A works for me.
>>>>>>>>>=20
>>>>>>>>> -andy
>>>>>>>>>=20
>>>>>>>>> On 7/14/26 3:06 AM, Sreekanth Narayanan wrote:
>>>>>>>>>> Hi Rebecca,
>>>>>>>>>>=20
>>>>>>>>>> Perhaps A sounds good to me. It's more clear than Perhaps B.
>>>>>>>>>>=20
>>>>>>>>>> Thanks
>>>>>>>>>> Sreekanth
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Tuesday, July 14th, 2026 at 7:29 AM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Hi Andy and authors,
>>>>>>>>>>>=20
>>>>>>>>>>> Andy, thanks for reviewing and approving! We have one more =
question before moving forward. Because =E2=80=9CSome_IANA_policy=E2=80=9D=
 may be confusing to readers, what are your thoughts about adding some =
explanatory text? 'Perhaps A' below adds a parenthetical to explain what =
Some_IANA_policy refers to. 'Perhaps B' does the same but also aligns =
the text in the bullet with similar text in Section 5.3.2 of RFC 9907.
>>>>>>>>>>>=20
>>>>>>>>>>> Current:
>>>>>>>>>>> * If the update is triggered following other IANA =
registration
>>>>>>>>>>> policy (Section 4 of [RFC8126]) but not all the values in =
the
>>>>>>>>>>> registry are covered by the same policy, insert this text:
>>>>>>>>>>>=20
>>>>>>>>>>> Applied updates as specified by the registration policy
>>>>>>>>>>> Some_IANA_policy.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Perhaps A:
>>>>>>>>>>> * If the update is triggered following another IANA =
registration
>>>>>>>>>>> policy but not all the values in the registry are covered by =
the
>>>>>>>>>>> same policy, insert this text (where "Some_IANA_policy" =
refers
>>>>>>>>>>> to one of the defined registration policies in Section 4 of =
[RFC8126]):
>>>>>>>>>>>=20
>>>>>>>>>>> Applied updates as specified by the registration policy
>>>>>>>>>>> Some_IANA_policy.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Perhaps B:
>>>>>>>>>>> * If the registration policy for the registry does not =
require RFC
>>>>>>>>>>> publication, insert this text (where "Some_IANA_policy" =
refers to one of
>>>>>>>>>>> the defined registration policies defined in Section 4 of =
[RFC8126]):
>>>>>>>>>>>=20
>>>>>>>>>>> Applied updates as specified by the registration policy
>>>>>>>>>>> Some_IANA_policy.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Thank you,
>>>>>>>>>>>=20
>>>>>>>>>>> Rebecca VanRheenen
>>>>>>>>>>> RFC Production Center
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> On Jul 13, 2026, at 7:47=E2=80=AFAM, Andy Newton =
<andy@hxr.us> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>> Ah. Ok, I get it. Approved.
>>>>>>>>>>>>=20
>>>>>>>>>>>> -andy
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 10-07-2026 5:59 PM, Rebecca VanRheenen wrote:
>>>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>>> This document (and one other currently in the RPC queue) =
are the first documents with IANA-maintained modules since RFC 9907 was =
published.
>>>>>>>>>>>>> Section 10.1 in this document seems to use the template in =
Section 4.30.3.2 of RFC 9907. The template points to Section 5.3.2 of =
RFC 9907, which contains text with =E2=80=9CSome_IANA_policy=E2=80=9D =
that also appears in Section 10.1 of this document, with some minor =
differences. Here=E2=80=99s the text from Section 5.3.2 of RFC 9907 (you =
can see how it is similar to the text in Section 10.1 of this document):
>>>>>>>>>>>>>> When such a description is not feasible, the description =
varies in
>>>>>>>>>>>>>> accordance with the trigger for the update.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> If the update is triggered by an RFC, the "description"
>>>>>>>>>>>>>> substatement should include or consist of this text:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Applied updates as specified by RFC XXXX.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> If the registration policy for the registry does not =
require RFC
>>>>>>>>>>>>>> publication (Section 4 of [RFC8126]), insert this text:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Applied updates as specified by the registration policy
>>>>>>>>>>>>>> <Some_IANA_policy>.
>>>>>>>>>>>>> In issue #19 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/19), =
we questioned if "Some_IANA_policy" is a placeholder that should be =
populated with the name of the applicable IANA policy, but we were told =
that is not meant to be replaced. We also noted that the text under the =
"Description Substatements:" heading of the template in Section 4.30.3.2 =
of RFC 9907 says to complete that section only if the actions in Section =
5.3.2 are to be overridden. If the text is from Section 5.3.2, we =
questioned if it is necessary to include it at all but were told to =
retain it.
>>>>>>>>>>>>> Perhaps Sreekanth and the other authors can also provide =
more information.
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Rebecca VanRheenen
>>>>>>>>>>>>> RFC Production Center
>>>>>>>>>>>>>> On Jul 10, 2026, at 10:38=E2=80=AFAM, Andy Newton =
<andy@hxr.us> wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I have one question. What is the "Some_IANA_policy" in =
10.1?
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> -andy
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 7/9/26 7:33 PM, Rebecca VanRheenen wrote:
>>>>>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> We have a few more changes for you to review as AD. =
Please let us know if you approve.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> We=E2=80=99ve included links to the related issues in =
GitHub, but we also created diff files as we believe they may be easier =
to review (see below). If needed, feel free to either reopen/discuss an =
issue in GitHub or discuss on this email thread. Approval should be sent =
by email.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 1) Added text to end of first paragraph of Section 3.1 =
to explain =E2=80=9CCap server=E2=80=9D in Figure 1
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Issue #6 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/6)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 2) Updated URL in reference clause for =
=E2=80=98iana-sip-option-tags=E2=80=99 in the YANG module in Section 7.2 =
and added normative reference [iana-sip-option-tags]
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Issue #11 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/11)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 3) Changes to the example module in Section 7.3 to align =
with the guidance in RFC 9907 and allow it to parse using pyang. =
Specifically, is the =E2=80=98fake=E2=80=99 contact information =
necessary/helpful? And is the namespace correct? We ask because this =
differs from what we see in some other example modules, like those in =
RFCs 9922 and 9742.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Issue #16 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/16)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 4) Updates to bulleted list in Section 10.1 (including =
leaving =E2=80=9CSome_IANA_policy=E2=80=9D)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Issue #19 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/19)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 5) Changes in Section 11.3 (=E2=80=9CYANG Security =
Considerations=E2=80=9D)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> - first 3 paragraphs of template omitted
>>>>>>>>>>>>>>> - added paragraph about the =E2=80=9Ciana-sip-option-tags=E2=
=80=9D module
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> The author noted: =E2=80=9CThis text was removed during =
earlier reviews by yangdoctors primarily because this module cannot be =
accessed via YANG-based management protocols. The paragraph below this =
talks about how a JSON capability set document should be created and =
that document must adhere to the schema defined by the =
ietf-sip-auto-peering YANG module. We shouldn=E2=80=99t have this text =
in the final draft.=E2=80=9D (See =
https://github.com/rfc-editor-drafts/FinalReview-rfc10006/pull/1#discussio=
n_r3446003877)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Issue #20 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/20)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Updated Files:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Updated XML and output files:
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc10006.xml
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc10006.txt
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc10006.pdf
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc10006.html
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Diff file showing all changes made during Final Review:
>>>>>>>>>>>>>>> =
https://www.rfc-editor.org/authors/rfc10006-auth48diff.html
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Diff file showing all changes:
>>>>>>>>>>>>>>> =
https://www.rfc-editor.org/authors/rfc10006-alt-diff.html
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Rebecca VanRheenen
>>>>>>>>>>>>>>> RFC Production Center
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On Jun 29, 2026, at 9:25=E2=80=AFAM, Andy Newton =
<andy@hxr.us> wrote:
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> I have reviewed and approve of the change to use =
"example-".
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> -andy
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On 28-06-2026 2:24 PM, Sreekanth Narayanan wrote:
>>>>>>>>>>>>>>>>> Hi Andy & Rebecca,
>>>>>>>>>>>>>>>>> I've made changes to the module as needed.
>>>>>>>>>>>>>>>>> It's now called example-vendor-config and follows the =
examples shown in other recent RFCs.
>>>>>>>>>>>>>>>>> Please review the new suggestion.
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Sreekanth
>>>>>>>>>>>>>>>>> On Friday, June 26th, 2026 at 4:06 AM, Rebecca =
VanRheenen <rvanrheenen@staff.rfc-editor.org> wrote:
>>>>>>>>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> As AD, please review Issue #16 =
(https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/16) =
and let us know how to proceed.
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> After other updates are finalized, we will also ask =
for approval for some changes that are above editorial.
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> Rebecca VanRheenen
>>>>>>>>>>>>>>>>>> RFC Production Center
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> On Jun 20, 2026, at 3:48=E2=80=AFAM, Sreekanth =
Narayanan <sknth.n=3D40protonmail.com@dmarc.ietf.org> wrote:
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Hi Rebecca,
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Thank you for adding me as a collaborator and for =
all the queries!
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> I've replied to all issues except #29 (Ready for =
Final review) with my comments. I've closed 4 issues that seem =
informational and I'm OK with the changes.
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> I've also added comments in the RPC Edits PR where =
necessary. Please take a look.
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>> Sreekanth
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> On Tuesday, June 16th, 2026 at 6:33 AM, =
rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> wrote:
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>>>>>>>>>>> --------------
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Your document has now entered Final Review =
(formerly AUTH48).
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Final Review is being handled in GitHub as part of =
the GitHub pilot test
>>>>>>>>>>>>>>>>>>>> (see =
https://www.rfc-editor.org/rpc/wiki/doku.php?id=3Drpc-github-phase-0-pilot=
-test).
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Your document is available for review at:
>>>>>>>>>>>>>>>>>>>> =
https://github.com/rfc-editor-drafts/FinalReview-rfc10006
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Please do the following:
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> a) accept your invitations to join the repo as =
collaborators. We need GitHub
>>>>>>>>>>>>>>>>>>>> usernames for Kaustubh and Sreekanth in order to =
send invites. We have already
>>>>>>>>>>>>>>>>>>>> sent invites to Cullen (author), Andy (AD), Marc =
(document shepherd), and
>>>>>>>>>>>>>>>>>>>> Jean (WG chair). We can also send an invite to =
Gonzalo (WG chair) if a GitHub
>>>>>>>>>>>>>>>>>>>> username is provided.
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> b) see the README for details on the Final Review =
process:
>>>>>>>>>>>>>>>>>>>> =
https://github.com/rfc-editor-drafts/FinalReview-rfc10006/blob/Approved/RE=
ADME.md
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> c) review the edits in the RPC-edits pull request:
>>>>>>>>>>>>>>>>>>>> =
https://github.com/rfc-editor-drafts/FinalReview-rfc10006/pulls
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Note: The diff in the 'Files Changed' view in the =
RPC-edits pull request may
>>>>>>>>>>>>>>>>>>>> be difficult to read because some text was moved =
and deleted (e.g., removed
>>>>>>>>>>>>>>>>>>>> Appendix A, switched order of subsections in =
References section so that
>>>>>>>>>>>>>>>>>>>> Normative comes before Informative, moved the =
Acknowledgements section to the
>>>>>>>>>>>>>>>>>>>> correct location). If you need a cleaner diff, =
please review the diff files
>>>>>>>>>>>>>>>>>>>> provided in the README (especially the alt-diff).
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> d) address the issues:
>>>>>>>>>>>>>>>>>>>> =
https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Once the content is stable in GitHub, we will =
provide the updated XML file
>>>>>>>>>>>>>>>>>>>> and the output files for review and approval.
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> You and your coauthors are responsible for engaging =
other parties
>>>>>>>>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary =
before providing
>>>>>>>>>>>>>>>>>>>> your approval.
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Once the document has been reviewed and approved by =
all of the authors,
>>>>>>>>>>>>>>>>>>>> it will be published as an RFC.  If an author is no =
longer available,
>>>>>>>>>>>>>>>>>>>> there are several remedies; see the Unavailable =
Authors section
>>>>>>>>>>>>>>>>>>>> =
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Details on the status of your Final Review are =
here:
>>>>>>>>>>>>>>>>>>>> https://queue.rfc-editor.org/final-review/rfc10006/
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> RFC Production Center
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>> RFC 10006 (draft-ietf-asap-sip-auto-peer)
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>> Title            : Automatic Peering for SIP Trunks
>>>>>>>>>>>>>>>>>>>> Author(s)        : K. Inamdar,
>>>>>>>>>>>>>>>>>>>>            S. Narayanan,
>>>>>>>>>>>>>>>>>>>>            C. Jennings
>>>>>>>>>>>>>>>>>>>> WG Chair(s)      : Jean Mahoney, Gonzalo Salgueiro
>>>>>>>>>>>>>>>>>>>> Area Director(s) : Charles Eckel, Andy Newton
>>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>> <rfc10006.xml>
>>>=20
>> <rfc10006.xml>
>=20