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: 
 <8zKoZKnStXvEbnQw7YpdMqwylp6EF15vJp5WYsdTsMtF61SNLDTlIuXK-nzwId1R-0WzDS9pOxkhy6PjJsPjL6gtIGjcgDk6KZnXc4iNQZc=@protonmail.com>
Date: Thu, 16 Jul 2026 11:33:28 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F42739D3-4F52-4759-940B-C95A0B4CA68F@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>
To: Sreekanth Narayanan <sknth.n@protonmail.com>
Message-ID-Hash: JKGHOTPZYMS3UM6IQQ7LYGTG6MU5ZONG
CC: kaustubh.ietf@gmail.com, fluffy@iii.ca,
 RFC Editor <rfc-editor@rfc-editor.org>, Andy Newton <andy@hxr.us>,
 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_Re=3A_Final_Review=3A_RFC-to-be_10006_=28draft-ietf-a?=
 =?utf-8?q?sap-sip-auto-peer=29_in_XML/GitHub?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/WftufxoP6IOAwN3rZAwpMqFo1cs>

Hi Sreekanth,

Thanks! The lines with the following text are exactly 69 chars, so I =
removed the wrapping for those.

> "https://capserver.example.org/capserver/capdoc.json"

> "https://sipserviceprovider.com/certificateList.pem",

I=E2=80=99ll send a separate email asking the AD for approval of the =
changes.

Best regards,

Rebecca VanRheenen
RFC Production Center


> 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>