[auth48] Re: Final Review: RFC-to-be 10006 (draft-ietf-asap-sip-auto-peer) in XML/GitHub

[Sreekanth Narayanan <[e-mail]>]

Hi Rebecca,

I've reviewed the changes and they are good for me.
We can proceed.

Thanks
Sreekanth

On Tuesday, July 21st, 2026 at 1:01 AM, Rebecca VanRheenen <[e-mail]> wrote:

> Hi authors,
> 
> 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.
> 
> >    All revisions of IETF and IANA published modules can be found
> >    at the YANG Parameters registry group
> >    (https://www.iana.org/assignments/yang-parameters)
> 
> The updated files are available here:
> 
> XML file:
>   https://www.rfc-editor.org/authors/rfc10006.xml
> 
> 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
> 
> 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)
> 
> For the Final Review status of this document, please see:
>   https://queue.rfc-editor.org/final-review/rfc10006/
> 
> 
> Thank you,
> 
> Rebecca VanRheenen
> RFC Production Center
> 
> 
> 
> > On Jul 16, 2026, at 11:33 AM, Rebecca VanRheenen <[e-mail]> wrote:
> >
> > 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’ll 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 AM, Sreekanth Narayanan <[e-mail]> wrote:
> >>
> >> Hi Rebecca,
> >>
> >> Here's the updated file. I've also fixed the wrapping in a couple of other lines that went beyond 69 characters.
> >>
> >> Thanks
> >> Sreekanth
> >>
> >> On Thursday, July 16th, 2026 at 11:16 PM, Rebecca VanRheenen <[e-mail]> wrote:
> >>
> >>> Hi Sreekanth,
> >>>
> >>> Thanks for sending along the updated XML file.
> >>>
> >>> There are two lines that are too long for the TXT output:
> >>>
> >>>> "$6$OoEJwExxp6U/FRFq$4RkL2lSSGLoKdfGjX4lQLFXo89gc0wtJsKiBxg/BBz6aNwu7C.D3kRUwD7lvJm6rhaCdhSzVh/XfkkAUY2dTu0"
> >>>
> >>>> "version": ["ietf-tls-common:tls12", "ietf-tls-common:tls13”]
> >>>
> >>> Can you update the file to wrap these? The line limit for sourcecode is 69 characters.
> >>>
> >>> Thanks!
> >>>
> >>> Rebecca VanRheenen
> >>> RFC Production Center
> >>>
> >>>
> >>>
> >>>> On Jul 16, 2026, at 9:50 AM, Sreekanth Narayanan <[e-mail]> wrote:
> >>>>
> >>>> Hi Rebecca,
> >>>>
> >>>> Here is the XML file updated with the corrected JSON file.
> >>>>
> >>>> Thanks
> >>>> Sreekanth
> >>>>
> >>>> On Thursday, July 16th, 2026 at 4:24 AM, Rebecca VanRheenen <[e-mail]> wrote:
> >>>>
> >>>>> Hi Sreekanth,
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> Note that the RPC parses YANG modules (and ABNF, XML, and MIB), but not JSON.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Rebecca VanRheenen
> >>>>> RFC Production Center
> >>>>>
> >>>>>
> >>>>>> On Jul 15, 2026, at 11:48 AM, Sreekanth Narayanan <[e-mail]> wrote:
> >>>>>>
> >>>>>> Hi Rebecca,
> >>>>>>
> >>>>>> 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:
> >>>>>>
> >>>>>> yanglint -p . [e-mail] 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".
> >>>>>>
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> RFC 7951 requires identityrefs to use the module name in a JSON and strings to not contain the prefix.
> >>>>>>
> >>>>>> Should we change the asap-example.json in the document?
> >>>>>>
> >>>>>> Thanks
> >>>>>> Sreekanth
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Sent with Proton Mail secure email.
> >>>>>>
> >>>>>> On Wednesday, July 15th, 2026 at 6:36 AM, Rebecca VanRheenen <[e-mail]> wrote:
> >>>>>>
> >>>>>>> Hello authors,
> >>>>>>>
> >>>>>>> We have merged the updates in GitHub.
> >>>>>>>
> >>>>>>> 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 ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.
> >>>>>>>
> >>>>>>> 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-diff.html
> >>>>>>>
> >>>>>>> The files are available here:
> >>>>>>>
> >>>>>>> XML file:
> >>>>>>> https://www.rfc-editor.org/authors/rfc10006.xml
> >>>>>>>
> >>>>>>> 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
> >>>>>>>
> >>>>>>> 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)
> >>>>>>>
> >>>>>>> For the Final Review status of this document, please see:
> >>>>>>> https://queue.rfc-editor.org/final-review/rfc10006/
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>>
> >>>>>>> Rebecca VanRheenen
> >>>>>>> RFC Production Center
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jul 14, 2026, at 1:58 PM, Rebecca VanRheenen <[e-mail]> wrote:
> >>>>>>>>
> >>>>>>>> Hi Andy and Sreekanth,
> >>>>>>>>
> >>>>>>>> Thanks for your responses! I updated to use A; see https://github.com/rfc-editor-drafts/FinalReview-rfc10006/pull/1/changes/92b6f32d2b11c145594b7b6fd971458ddbbc58a2.
> >>>>>>>>
> >>>>>>>> I also noted Andy’s approval on the Final Review status page for this document; see https://queue.rfc-editor.org/final-review/rfc10006/.
> >>>>>>>>
> >>>>>>>> I’ll 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.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>> Rebecca VanRheenen
> >>>>>>>> RFC Production Center
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Jul 14, 2026, at 11:07 AM, Andy Newton <[e-mail]> wrote:
> >>>>>>>>>
> >>>>>>>>> Yes, thank you. A works for me.
> >>>>>>>>>
> >>>>>>>>> -andy
> >>>>>>>>>
> >>>>>>>>> On 7/14/26 3:06 AM, Sreekanth Narayanan wrote:
> >>>>>>>>>> Hi Rebecca,
> >>>>>>>>>>
> >>>>>>>>>> Perhaps A sounds good to me. It's more clear than Perhaps B.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> Sreekanth
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tuesday, July 14th, 2026 at 7:29 AM, Rebecca VanRheenen <[e-mail]> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Andy and authors,
> >>>>>>>>>>>
> >>>>>>>>>>> Andy, thanks for reviewing and approving! We have one more question before moving forward. Because “Some_IANA_policy” 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.
> >>>>>>>>>>>
> >>>>>>>>>>> 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:
> >>>>>>>>>>>
> >>>>>>>>>>> Applied updates as specified by the registration policy
> >>>>>>>>>>> Some_IANA_policy.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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]):
> >>>>>>>>>>>
> >>>>>>>>>>> Applied updates as specified by the registration policy
> >>>>>>>>>>> Some_IANA_policy.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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]):
> >>>>>>>>>>>
> >>>>>>>>>>> Applied updates as specified by the registration policy
> >>>>>>>>>>> Some_IANA_policy.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you,
> >>>>>>>>>>>
> >>>>>>>>>>> Rebecca VanRheenen
> >>>>>>>>>>> RFC Production Center
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Jul 13, 2026, at 7:47 AM, Andy Newton <[e-mail]> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ah. Ok, I get it. Approved.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -andy
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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 “Some_IANA_policy” that also appears in Section 10.1 of this document, with some minor differences. Here’s 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.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If the update is triggered by an RFC, the "description"
> >>>>>>>>>>>>>> substatement should include or consist of this text:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Applied updates as specified by RFC XXXX.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If the registration policy for the registry does not require RFC
> >>>>>>>>>>>>>> publication (Section 4 of [RFC8126]), insert this text:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 AM, Andy Newton <[e-mail]> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have one question. What is the "Some_IANA_policy" in 10.1?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -andy
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/9/26 7:33 PM, Rebecca VanRheenen wrote:
> >>>>>>>>>>>>>>> Hi Andy,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We have a few more changes for you to review as AD. Please let us know if you approve.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We’ve 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.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1) Added text to end of first paragraph of Section 3.1 to explain “Cap server” in Figure 1
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Issue #6 (https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/6)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2) Updated URL in reference clause for ‘iana-sip-option-tags’ in the YANG module in Section 7.2 and added normative reference [iana-sip-option-tags]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Issue #11 (https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/11)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 ‘fake’ 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.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Issue #16 (https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/16)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 4) Updates to bulleted list in Section 10.1 (including leaving “Some_IANA_policy”)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Issue #19 (https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/19)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 5) Changes in Section 11.3 (“YANG Security Considerations”)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - first 3 paragraphs of template omitted
> >>>>>>>>>>>>>>> - added paragraph about the “iana-sip-option-tags” module
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The author noted: “This 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’t have this text in the final draft.” (See https://github.com/rfc-editor-drafts/FinalReview-rfc10006/pull/1#discussion_r3446003877)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Issue #20 (https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/20)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Updated Files:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Diff file showing all changes made during Final Review:
> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc10006-auth48diff.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Diff file showing all changes:
> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc10006-alt-diff.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thank you,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Rebecca VanRheenen
> >>>>>>>>>>>>>>> RFC Production Center
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Jun 29, 2026, at 9:25 AM, Andy Newton <[e-mail]> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I have reviewed and approve of the change to use "example-".
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -andy
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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 <[e-mail]> wrote:
> >>>>>>>>>>>>>>>>>> Hi Andy,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> As AD, please review Issue #16 (https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues/16) and let us know how to proceed.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> After other updates are finalized, we will also ask for approval for some changes that are above editorial.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thank you,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Rebecca VanRheenen
> >>>>>>>>>>>>>>>>>> RFC Production Center
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Jun 20, 2026, at 3:48 AM, Sreekanth Narayanan <sknth.n=[e-mail]> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi Rebecca,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thank you for adding me as a collaborator and for all the queries!
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I've also added comments in the RPC Edits PR where necessary. Please take a look.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>>>>> Sreekanth
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Tuesday, June 16th, 2026 at 6:33 AM, [e-mail] <[e-mail]> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> *****IMPORTANT*****
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> RFC Author(s):
> >>>>>>>>>>>>>>>>>>>> --------------
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Your document has now entered Final Review (formerly AUTH48).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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=rpc-github-phase-0-pilot-test)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Your document is available for review at:
> >>>>>>>>>>>>>>>>>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10006
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please do the following:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> b) see the README for details on the Final Review process:
> >>>>>>>>>>>>>>>>>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10006/blob/Approved/README.md
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> c) review the edits in the RPC-edits pull request:
> >>>>>>>>>>>>>>>>>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10006/pulls
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> d) address the issues:
> >>>>>>>>>>>>>>>>>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Once the content is stable in GitHub, we will provide the updated XML file
> >>>>>>>>>>>>>>>>>>>> and the output files for review and approval.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You and your coauthors are responsible for engaging other parties
> >>>>>>>>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>>>>>>>>>>>>>>>>>> your approval.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Details on the status of your Final Review are here:
> >>>>>>>>>>>>>>>>>>>> https://queue.rfc-editor.org/final-review/rfc10006/
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> RFC Production Center
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --------------------------------------
> >>>>>>>>>>>>>>>>>>>> RFC 10006 (draft-ietf-asap-sip-auto-peer)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>> <rfc10006.xml>
> >>>
> >> <rfc10006.xml>
> >
> 
>