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

[Grzegorz Piotr 0rchel <[e-mail]>]

All viewed and approved. For my high internet standards and security. Ready
for publish unless my eye miss something, if so let give me suggestion or
improvements. Thank you so much and next draft will try be more active and
pro.


Grzegorz Piotr Orchel executive director GGO Trust

On Tue, 14 Jul 2026 at 21:58, Rebecca VanRheenen via auth48archive <
[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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >
>
> --
> auth48archive mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>