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: <823687B0-1798-4054-85C8-4A1089323966@iii.ca>
Date: Mon, 27 Jul 2026 10:05:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F5FED20-B659-43C0-8031-6500CBB9040A@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>
 <92C8DC7F-DE0F-4B21-9B4B-24852E7D456B@staff.rfc-editor.org>
 <CADJ3otHOV9p6jdTJsCW0g75vCqRYFuYoEA+NWm1ktimUxAoHTw@mail.gmail.com>
 <C9DBBF40-A84C-4A97-8E79-E51691AB3135@staff.rfc-editor.org>
 <823687B0-1798-4054-85C8-4A1089323966@iii.ca>
To: Cullen Fluffy Jennings <fluffy@iii.ca>,
 Kaustubh Inamdar <kaustubh.ietf@gmail.com>,
 Sreekanth Narayanan <sknth.n@protonmail.com>
Message-ID-Hash: 532HHXBYZU76EY2GUQ2WU56KGOENS5CZ
CC: Andy Newton <andy@hxr.us>, RFC Editor <rfc-editor@rfc-editor.org>,
 auth48archive@rfc-editor.org, asap-chairs@ietf.org, art-ads@ietf.org,
 Marc Petit-Huguenin <marc@petit-huguenin.org>,
 Charles Eckel <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/C9fYsvCRlbcAZ77HEFGQi5NEFDI>

Hi Cullen,

Thanks for the reply! We=E2=80=99ve marked your approval on the Final =
Review status page for this document; see =
https://queue.rfc-editor.org/final-review/rfc10006/.

Once Andy approves the changes to the JSON in Section 9.1, we can move =
this document forward in publication process.=20

Best regards,

Rebecca VanRheenen
RFC Production Center


> On Jul 26, 2026, at 9:57=E2=80=AFAM, Cullen Fluffy Jennings =
<fluffy@iii.ca> wrote:
>=20
>=20
> I have reviewed and looks good to me.=20
>=20
> I am OK to publish.=20
>=20
> Thank you.
>=20
>=20
>> On Jul 22, 2026, at 9:24=E2=80=AFAM, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>=20
>> Hi Kaustubh,
>>=20
>> We've marked your approval on the Final Review status page for this =
document; see https://queue.rfc-editor.org/final-review/rfc10006/.
>>=20
>> We can move this document forward in the publication process after we =
receive approval from Cullen and the AD.
>>=20
>> Thank you,
>>=20
>> Rebecca VanRheenen
>> RFC Production Center
>>=20
>>=20
>>=20
>>> On Jul 21, 2026, at 10:10=E2=80=AFPM, Kaustubh Inamdar =
<kaustubh.ietf@gmail.com> wrote:
>>>=20
>>> Hi Rebecca,
>>> The changes look good to me.=20
>>>=20
>>> Best,
>>> Kaustubh
>>>=20
>>> On Tue, 21 Jul 2026 at 01:01, Rebecca VanRheenen =
<rvanrheenen@staff.rfc-editor.org> wrote:
>>> Hi authors,
>>>=20
>>> FYI that we have added the following text to the copyright in the =
YANG module in Section 7.2. This addition is per Section 4.8 of RFC =
9907.
>>>=20
>>>>  All revisions of IETF and IANA published modules can be found
>>>>  at the YANG Parameters registry group
>>>>  (https://www.iana.org/assignments/yang-parameters).
>>>=20
>>> The updated 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
>>>=20
>>> Thank you,
>>>=20
>>> Rebecca VanRheenen
>>> RFC Production Center
>>>=20
>>>=20
>>>=20
>>>> 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
>>>=20
>>=20
>=20