Authors,
While reviewing this document during Final Review, please resolve (as
necessary)
the following questions, which are also in GitHub issues
(see https://github.com/rfc-editor-drafts/FinalReview-rfc10006/issues).
1) <!--[rfced] We note that most of the recently published RFCs containing
YANG modules format their titles as "A YANG Data Model for...", for example:
RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks
(WSONs)
RFC 9093 - A YANG Data Model for Layer 0 Types
RFC 9067 - A YANG Data Model for Routing Policy
Please consider whether the title of this document should be updated.
Current:
Automatic Peering for SIP Trunks
-->
2) <!-- [rfced] Are any updates needed to align the document title, abstract,
and
introduction? Or are these okay as they are?
Specifically:
- "Automatic Peering" appears in the document title but is not mentioned in
the abstract (or elsewhere in the document).
- Should "Auto Peer framework" in the Introduction (and elsewhere) be updated
to "Automatic Peering framework" to align with "Automatic Peering" in the
document title?
- "Trunk" appears in the document title, but not in the abstract or
introduction.
-->
3) <!-- [rfced] We have moved the "Conventions and Terminology" section to
appear
immediately after the Introduction and renamed it "Requirements
Language" (as it only contains the key words boilerplate).
-->
4) <!-- [rfced] "Overview of Operations" section
a) This section contains a brief overview of the subsections, but we do not
see mention of the "Configuration Workflow" subsection in the following
introductory text. May we update as follows to include it?
Original:
This section provides a reference architecture against which the SIP
Auto Peer framework may be implemented. Additionally, terms that are
commonly used in the context of the document are defined. Lastly,
considerations for the choice of network transport between enterprise
and service provider telephony networks are discussed.
Perhaps:
This section provides a reference architecture against which the SIP
Auto Peer framework may be implemented. Additionally, terms that are
commonly used in the context of the document are defined. Last,
considerations for the configuration workflow and the choice of network
transport between enterprise
and service provider telephony networks are discussed.
b) We created a new subsection titled "Terminology" to hold the definitions of
six terms that originally appeared in the section titled "Reference
Architecture".
Original:
2. Overview of Operations
2.1. Reference Architecture
2.2. Configuration Workflow
2.3. Transport
Current:
3. Overview of Operations
3.1. Reference Architecture
3.2. Terminology
3.3. Configuration Workflow
3.4. Transport
-->
5) <!-- [rfced] We note that Figure 1 uses "Cap server". Will readers know what
"Cap server" is? The text introducing the figure uses "HTTP server".
Original:
At a high level, the service provider consists of a SIP
signaling entity (SP-SSE), a media entity for handling media streams
of calls setup by the SP-SSE and an HTTP [RFC9110] server.
-->
6) <!-- [rfced] How may we clarify the text starting with "using which..." in
the
text below?
Original:
Taking the above considerations into account, this document proposes
a Hypertext Transfer Protocol (HTTP)-based workflow using which the
enterprise network can solicit and ultimately obtain the service
provider capability set.
Perhaps:
Taking the above considerations into account, this document proposes
an HTTP-based workflow that the
enterprise network can use to solicit and ultimately obtain the service
provider capability set.
-->
7) <!-- [rfced] Would adding a citation for "OAuth 2.0 specification" be helpful
for readers? Perhaps [RFC6749]?
Original:
Enterprise edge elements could
use the various grant types outlined in the OAuth 2.0 specification
and supported by the service provider in order to obtain the
capability set document.
Perhaps
Enterprise edge elements could
use the various grant types outlined in the OAuth 2.0 specification [RFC6749]
and supported by the service provider in order to obtain the
capability set document.
-->
8) <!-- [rfced] The following text appears at the beginning of Section 7. We do
not see "description of the various nodes within the module defined in
this draft" in this section. Should this sentence be revised to remove
that text and perhaps also mention Section 7.3?
Original:
This section defines a YANG module [RFC7950] for encoding the service
provider capability set. Section 7.1 provides the tree diagram,
which is followed by a description of the various nodes within the
module defined in this draft.
Perhaps:
This section contains a tree diagram (Section 7.1), the YANG module [RFC7950]
for encoding the service provider capability set (Section 7.2), and a
discussion about extending the capability set (Section 7.3).
-->
9) <!-- [rfced] The following references appear in the References section, but
they are not cited in the text. We do see RFCs 5764 and 6716 as well as a
URL corresponding to [iana-crypt-hash-yang-module] in the YANG module in
Section 7.2.
[RFC5764]
[RFC6716]
[iana-crypt-hash-yang-module]
a) May we add these references to the text that introduces the YANG module as
follows so that each reference entry has a corresponding citation in the text?
Note that we renamed [iana-crypt-hash-yang-module] to [iana-crypt-hash].
Original:
This section defines the YANG module for the peering capability set
document. This module depends on existing YANG modules that provide
common YANG data types [RFC6991] and system management [RFC7317]. In
addition, this YANG module references [RFC2833], [RFC4585], [RFC4568],
[RFC4733], [RFC4855], [RFC4961], [RFC7362], [RFC8555] and
[RFC9645].
Perhaps:
This section defines the YANG module for the peering capability set
document. This module depends on existing YANG modules that provide
common YANG data types [RFC6991] and system management [RFC7317]. In
addition, this YANG module references [RFC2833], [RFC4585], [RFC4568],
[RFC4733], [RFC4855], [RFC4961], [RFC5764], [RFC6716], [RFC7362], [RFC8555],
[RFC9645], and [iana-crypt-hash].
b) For the mention of RFC 6716 in the module, should a reference clause be
used?
Original:
identity opus {
base codec-variant;
description "Opus audio codec (RFC 6716).";
Perhaps:
identity opus {
base codec-variant;
description "Opus audio codec (RFC 6716).";
reference
"RFC 6716: Definition of the Opus Audio Codec.";
-->
10) <!-- [rfced] URLS in YANG module
a) We do not see the iana-sip-option-tags module mentioned at the URL listed
in the reference clauses below (i.e.,
https://www.iana.org/assignments/sip-parameters).
Original:
import iana-sip-option-tags {
prefix "iana-sip-option-tags";
reference
"https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml";;
...
leaf-list extension {
type iana-sip-option-tags:sip-option-tag;
description
"A list of SIP option tags (extensions) supported by the
service provider network.";
reference
"https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml";;
Should the URL in these reference clauses for iana-sip-option-tags be updated
to
one of the following?
https://www.iana.org/assignments/yang-parameters/
or
https://www.iana.org/assignments/iana-sip-option-tags/
b) Also, should the URL in the reference clause for iana-crypt-hash align with
the URL used for iana-sip-option-tags?
https://www.iana.org/assignments/yang-parameters/
or
https://www.iana.org/assignments/iana-crypt-hash/ (current)
https://www.iana.org/assignments/yang-parameters/
https://www.iana.org/assignments/iana-crypt-hash/ (current)
Note: A reference entry may need to be added and the text in a) in the
question above may need to be adjusted based on the answer here.
Original:
import iana-crypt-hash {
prefix "ianach";
reference
c) Are any changes to the text in the question above needed based on
the outcome of a) and b)? For example, does a reference entry need to
be added for https://www.iana.org/assignments/iana-sip-option-tags/
and the text below updated to include a citation for it?
Original:
This section defines the YANG module for the peering capability set
document. This module depends on existing YANG modules that provide
common YANG data types [RFC6991] and system management [RFC7317]. In
addition, this YANG module references [RFC2833], [RFC4585], [RFC4568],
[RFC4733], [RFC4855], [RFC4961], [RFC7362], [RFC8555] and
[RFC9645].
-->
11) <!-- [rfced] We changed two instances of "draft" to "document" in
description
clauses within the YANG module in Section 7.2. Should these instances be
updated to "RFC 10006" (and perhaps a reference clause added) as
"document" may not be clear if the module is extracted?
Similarly, in the second description clause below, "this specification" is
also used. Should this also be updated to "RFC 10006"?
Original (both clauses contain "draft"; second also contains "specification"):
description
"A node that identifies the version number of the capability
set document. This draft defines the parameters for variant
1.0; future specifications might define a richer parameter set,
in which case the variant must be changed to 2.0, 3.0 and so
on. Future extensions to the capability set document MUST also
ensure that the corresponding YANG module is defined.";
...
description
"A container that is used to collectively encapsulate the
characteristics of UDP-based audio streams. A future extension
to this draft may extend the media container to describe other
media types. The media container is also used to encapsulate
basic information about Real-Time Transport Protocol (RTP) and
Real-Time Transport Control Protocol (RTCP) from the
perspective of the service provider network. At the time of
writing this specification, video media streams aren't
exchanged between enterprise and service provider SIP
networks.";
Perhaps:
description
"A node that identifies the version number of the capability
set document. RFC 10006 defines the parameters for
variant 1.0; future specifications might define a richer
parameter set, in which case the variant must be changed
to 2.0, 3.0, and so on. Future extensions to the
capability set document MUST also ensure that the
corresponding YANG module is defined.";
reference
"RFC 10006: Automatic Peering for SIP Trunks";
...
description
"A container that is used to collectively encapsulate the
characteristics of UDP-based audio streams. A future
extension to RFC 10006 may extend the media container
to describe other media types. The media container is
also used to encapsulate basic information about
Real-Time Transport Protocol (RTP) and Real-Time
Transport Control Protocol (RTCP) from the perspective
of the service provider network. At the time of writing
RFC 10006, video media streams are not exchanged
between enterprise and service provider SIP networks.";
reference
"RFC 10006: Automatic Peering for SIP Trunks";
-->
12) <!-- [rfced] It appears there may be a reference missing in the text
below. What should appear after "as defined in"?
Original:
In a similar vein, for the RTCP-based feedback mechanism as defined in to
be truly effective, intermediaries must ensure that feedback messages are
passed reliably and with the correct formatting to enterprise endpoints.
-->
13) <!-- [rfced] The following is a run-on sentence. We have added "and" after
"10
to 30 ms". Please review.
Original:
Given that the parameters of media formats can vary from one communication
session to another, for example, across two separate communication
sessions, the packetization time (ptime) used for the PCMU media format
might vary from 10 to 30 ms, the parameters included in the format element
must be the ones that are expected to be invariant from the perspective of
the service provider.
Updated:
Given that the parameters of media formats can vary from one communication
session to another (e.g., across two separate communication sessions), the
packetization time (ptime) used for the PCMU media format might vary from
10 to 30 ms, and the parameters included in the format element must be the
ones that are expected to be invariant from the perspective of the service
provider.
-->
14) <!-- [rfced] May we update the YANG module in Section 7.2 as shown in this
diff file? If yes, we will do this after other changes have been made in
GitHub prior to requesting final approval.
https://www.rfc-editor.org/authors/[email protected]
It compares the current module to the output of the formatting tool. Per
guidance from Martin Bjorklund, this is using pyang to format the module (as
described on the IETF YANG review tools wiki page
(https://wiki.ietf.org/group/ops/yang-review-tools)).
To be clear, with or without the formatting updates, the YANG module parses.
-->
15) <!-- [rfced] "vendorA-config" module in Section 7.3
a) Section 3.2.1 of RFC 9907 states:
An example module SHOULD be named using the term "example", followed
by a hyphen, followed by a descriptive name, e.g., "example-toaster".
Should the "vendorA-config" module in Section 7.3 follow this convention?
b) We get the following error when running pyang on the "vendorA-config"
module. Please let us know if any updates are needed.
error: unexpected keyword "import"
-->
16) <!-- [rfced] Should "2025-12-21" here be updated to "2026-06-15" to align
with
the updated date in the YANG module? Or is the current correct?
Original:
"variant": "ietf-sip-auto-peering:v1-0",
"revision": {
"not-before": "2025-12-21T10:30:00Z",
-->
17) <!-- [rfced] We updated the Reference below to "RFC 10006" to align with the
IANA registry at https://www.iana.org/assignments/yang-parameters. Let us
know any concerns.
Original:
* Name: iana-sip-option-tags
* Maintained by IANA? Y
* Namespace: urn:ietf:params:xml:ns:yang:iana-sip-option-tags
* Prefix: sip-option-tags
* Reference: https://www.iana.org/assignments/sip-parameters/sip-
parameters.xhtml
Updated:
Name: iana-sip-option-tags
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-sip-option-tags
Prefix: sip-option-tags
Reference: RFC 10006
-->
18) <!-- [rfced] Section 10.1 (IANA Considerations)
a) We have some questions about the text below.
- We see similar text in Section 5.3.2 of RFC 9907. Should this text be
updated as shown below to align with RFC 9907 and also reduce possible
redundancy with 'insert this text:' and 'should include this text:'?
- It seems that "Some_IANA_policy" is a placeholder that should be populated
with the name of the applicable IANA policy. Let us know if any updates are
needed.
- This text seems to be about the description substatement. A note 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 action in Section 5.3.2 are
to be overridden. If the text below is from Section 5.3.2, is it necessary to
include it at all?
Original:
- When such a description is not feasible, the description varies on
how the update is triggered.
- If the update is triggered by an RFC, insert this text:
The "description" substatement should include this text: "Applied
updates as specified by RFC XXXX.".
- 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:
The "description" substatement should include this text: "Applied
updates as specified by the registration policy Some_IANA_policy".
Perhaps:
When such a description is not feasible, the description varies on
how the update is triggered 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 10006.
* 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.
b) How should "IANA_SIP_OPTION_TAGS_URL_With_REV" be updated?
Original:
The "reference" substatement points specifically to the published
module (i.e., IANA_SIP_OPTION_TAGS_URL_With_REV).
Perhaps A:
The "reference" substatement points specifically to the published
module at [YANG-PARAMS].
Perhaps B:
The "reference" substatement points specifically to the published
module at <https://www.iana.org/assignments/iana-sip-option-tags/>.
c) FYI: We updated this reference entry as follows:
Original:
[sip-option-parameters]
"SIP Options parameters sub-registry",
<https://www.iana.org/assignments/sip-parameters/sip-
parameters-4.csv>.
Updated:
[SIP-PARAMS]
IANA, "Session Initiation Protocol (SIP) Parameters",
<https://www.iana.org/assignments/sip-parameters>.
-->
19) <!-- [rfced] YANG Security Considerations
a) We added the first three paragraphs of the YANG Security Considerations
template available at
<https://wiki.ietf.org/group/ops/yang-security-guidelines>.
b) We do not see the "Writable nodes section:" from the template included so we
added "There are no particularly sensitive writable data nodes." as indicated
by the template. Let us know any objections.
c) The YANG Security Considerations section only mentions the
"ietf-sip-auto-peering" YANG module; the "iana-sip-option-tags" YANG module is
not mentioned. Should a separate YANG Security Considerations template be
included for the "iana-sip-option-tags" YANG module, or should a statement
about this module be included?
Example of a separate template: See Section 4 of
draft-ietf-netconf-http-client-server
(currently in the RFC Editor queue)
Link:
https://www.ietf.org/archive/id/draft-ietf-netconf-http-client-server-33.html#name-security-considerations
Example of a statement from RFC 9899:
The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-
ipv6-ext-types" define a set of types. These nodes are intended to
be reused by other YANG modules. Each module by itself does not
expose any data nodes that are writable, data nodes that contain
read-only state, or RPCs. As such, there are no additional security
issues related to these YANG modules that need to be considered.
-->
20) <!-- [rfced] May we update this sentence as follows to clarify "using
which"?
Original:
There are alternative mechanisms using which the SIP service provider
can offload its capability set.
Perhaps:
There are alternative mechanisms that the SIP service provider
can use to offload its capability set.
-->
21) <!-- [rfced] Obsoleted references
The following references have been obsoleted. May we replace with the new
documents (i.e., RFCs 9911 and 4733)?
RFC 6991 - obsoleted by RFC 9911
RFC 2833 - obsoleted by RFC 4733
-->
22) <!-- [rfced] Terminology
a) We note the following forms in general text and description clauses in the
YANG module. Are any updates needed for consistency?
T38 relay
t38 relay
T.38 relay
Current:
... the service provider supports t38 relay
... T38 relay.
... service provider uses T.38 relay
b) Should "G729 codec" be updated to "G.729 codec" (with period after "G") in
the description clauses? We note that "G.711" is used in the document.
c) FYI - We have received guidance from Benoit Claise and the YANG Doctors
that "YANG module" and "YANG data model" are preferred. Thus, we have updated
instances of "YANG model(s)" to "YANG data model(s)" throughout accordingly.
-->
23) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
24) <!-- [rfced] Abbreviations
a) How may we expand "SIP-PBX" in the text below?
Original:
The enterprise network consists of a SIP-PBX...
Perhaps:
The enterprise network consists of a SIP Private Branch Exchange (SIP-PBX) ...
b) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Privacy-Enhanced Mail (PEM)
Secure Real-time Transport Protocol (SRTP)
Simplified Data Encryption Standard (SDES)
-->
25) <!-- [rfced] We updated <artwork> to <sourcecode> in the following sections:
Section 4.5
Section 7.1
Section 7.3
Section 9.2 (two blocks)
In Section 7.1, we used type="yangtree", and in Section 7.3, we used
type="yang".
Please let us know how/if to set the type attribute for the sourcecode in
Sections 4.5 and 9.2. The current list of preferred values for "type" is
available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
Also note that it is acceptable to leave the "type" attribute not set.
-->
26) <!-- [rfced] The following line is too long for the TXT output. Please let
us
know how to wrap the line to conform to the 69-character line limit for
sourcecode.
Current:
"$6$OoEJwExxp6U/FRFq$4RkL2lSSGLoKdfGjX4lQLFXo89gc0wtJsKiBxg/BBz6aNwu7C.D3kRUwD7lvJm6rhaCdhSzVh/XfkkAUY2dTu0"
-->
27) <!-- [rfced] Some author comments are present in the XML. Please confirm
that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
Thank you.
Kaelin Foody and Rebecca VanRheenen
RFC Production Center
On Jun 15, 2026, at 6:02 PM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 10006 <draft-ietf-asap-sip-auto-peer>
Your document is now available for Final Review (previously AUTH48). Once it
has been
reviewed and approved by you and all coauthors, 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).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using 'REPLY ALL' as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is an archival mailing list
to preserve discussion about the document while in the RPC editorial
queue; it is not an active discussion list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use 'REPLY ALL',
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc10006.xml
https://www.rfc-editor.org/authors/rfc10006.html
https://www.rfc-editor.org/authors/rfc10006.pdf
https://www.rfc-editor.org/authors/rfc10006.txt
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)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc10006-xmldiff1.html
Tracking progress
-----------------
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 Editor
--------------------------------------
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 -- [email protected]
To unsubscribe send an email to [email protected]
