Authors and *AD,
While reviewing this document during Final Review, please resolve (as
necessary) the following questions, which are also in the source file.
*AD, please see questions #11 and #14.
1) <!--[rfced] We note that other documents in Cluster C463 use "This
document defines...YANG 1.1 [RFC7950] modules..." Should
something similar be used in this document (Intro or Abstract)?
-->
2) <!--[rfced] We have a few questions related to the following text:
Original:
The basic structure of this YANG data model is guided by Section 16
of [RFC7285] and [RFC7971]. Although the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO standard extensions:
[RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], [RFC9274],
[RFC9275], and [RFC9439].
a) The second sentence is a fragment. Please consider the sentence before
and if the info should be combined.
b) "Section 16" might be attributed to both RFCs; we suggest updating
to disambiguate.
c) Are "ALTO standard extensions" the same as "ALTO protocol extensions"?
Taking a, b, and c into account:
Perhaps:
The basic structure of this YANG data model is guided by Section 16
of [RFC7285] and by [RFC7971]; however, the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO protocol extensions:
[RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], [RFC9274],
[RFC9275], and [RFC9439].
-->
3) <!--[rfced] "Configuring...configuration" reads oddly. Perhaps a
rephrase would be beneficial here?
Original:
* Configuring functionality/capability configuration of ALTO
services.
-->
4) <!--[rfced] We have the following questions/comments related to Table 2:
a) Looking at the references for R6: please review the section number
citation for RFC 7971 (Section 3.3 "ALTO Focus and Scope"). Should
this instead point to Section 3.4 "Monitoring ALTO"? (The only
mention of the word "fail" is in Section 5.2.2.)
b) We have updated to add a third column to the table for the
requirement number. Please let us know any objections.
c) Note also that we have used the same table structure for R8 in
Section 4.3 with this document as the reference. Please let us know
any objections.
-->
5) <!--[rfced] Please clarify "standard". Is the intended meaning that
the related solution "has not yet been standardized" or "has not
become a Standards Track RFC"?
Original:
However, it does not contain any configuration for the
communication among ALTO servers because the related solution
has not become a standard.
Perhaps:
However, it does not contain any configuration for the
communication among ALTO servers because the related
solution has not yet been standardized.
-->
6) <!--[rfced] Should "node" or "choice" or some other noun follow "The
source-params" in this text?
Original:
* The "source-params" to specify where and how to query the data.
-->
7) <!--[rfced] In the following, should "R-3" be made "R3" or "R5-3"
(there is no R-3 in Section 4.2)?
Original (Section 5.4.2):
To satisfy R5-2 and R-3 in Section 4.2...
and
Original (Section 5.4.2):
To satisfy R-3 in Section 4.2...
-->
8) <!--[rfced] We have a few questions about the Descriptions listed in
Table 4 in Section 5.4.2:
a) "configured to" reads strangely. Should this be made "configured
by" or "configured with"? Note that this appears more than once in
the document.
Original:
Used to notify high memory utilization
of the resource configured to an ALTO
server instance.
b) For both descriptions, who is being notified? Please consider rephrasing.
-->
9) <!--[rfced] We have the following questions related to the YANG
module(s):
a) We note that both "ietf-alto" and "ietf-alto-stats" do not list the
authors as contacts (only WG Web and WG List). See Section 4.8 of RFC
9907 for:
The "contact" statement MUST be present. If the module is contained in
a document intended for Standards Track status, then the WG web and
mailing information SHOULD be present, and the main document author or
editor contact information SHOULD be present.
Please let us know how to update.
b) We see several uses of "Reference of". Should these be made
"Reference to" or "Reference for"?
For example:
description
"Reference of an inline EE certificate to authenticate
the TLS client.";
c) Please review the section numbers listed in the reference clause
for "alto-costmap-params". Currently, it cites Sections 11.2.2 and
11.3.2 of RFC 7285. Should this instead be made Sections 11.2.3 and
11.3.2?
d) Please review the section number listed in the reference clause for
"alto-endpointprop-params". Currently, it cites Section 11.5. Should
this instead be made Section 11.4 or 11.4.1?
e) In "alto-endpointprop-params", should
"Endpoint-cost-service-specific configuration" instead say "Endpoint
property service"?
f) Note that the "ietf-alto" YANG module has been updated per the
formatting option of pyang. Please let us know any concerns.
default false -> default "false"
if-feature alto-client -> if-feature "alto-client"
if-feature alto-server -> if-feature "alto-server"
g) Note that the "example-alto-data-source" YANG module has been updated per
the
formatting option of pyang. Please let us know any concerns.
key name -> key "name"
h) Note that the "example-alto-alg" YANG module has been updated per the
formatting option of pyang. Please let us know any concerns.
Original:
+ '= "ietf-datastores:operational"'
{
Current:
+ '= "ietf-datastores:operational"' {
...
Original:
leaf topo-name {
type leafref {
path '/alto:alto/alto:alto-server/alto:data-source'
+ '[alto:source-id'
+ ' = current()/../source-datastore]'
+ '/alto:source-params'
+ '/ex-alto-ds:yang-datastore-source-params'
+ '/ex-alto-ds:target-paths/ex-alto-ds:name';
Current:
leaf topo-name {
type leafref {
path "/alto:alto/alto:alto-server/alto:data-source"
+ "[alto:source-id"
+ " = current()/../source-datastore]"
+ "/alto:source-params"
+ "/ex-alto-ds:yang-datastore-source-params"
+ "/ex-alto-ds:target-paths/ex-alto-ds:name";
-->
10) <!--[rfced] Section 7.2. Should mentions of "similar to num-msg-max"
be updated to instead say "similar to num-upd-msg-max"? We only
see the former in description clauses.
-->
11) <!--[rfced] [AD] We have the following questions/comments related to the
Security Considerations section:
a) We have updated the text to attempt to match the most recent
version of the Security Considerations template at
https://wiki.ietf.org/group/ops/yang-security-guidelines. Please
review these changes carefully and let us know any
objections/concerns.
In particular, please review if a list of RFCs needs to be added to the
"These modules use groupings..." paragraph.
b) We have included some informative reference entries to match the
guidance at the template above. We have also removed the normative
reference entry for RFC 6242 for the same reason.
c) Please review whether any text related to RPC or action operations
should be included. According to the wiki page, there should either
be the boilerplate paragraph or "There are no particularly sensitive
RPC or action operations." We see neither.
-->
12) <!--[rfced] Should "access of" be made "access to" or "access for" in
the following?
Original:
Likewise, this data node can be manipulated to prevent access of
legitimate ALTO clients.
-->
13) <!--[rfced] In the following, "configuration to" reads oddly. Please
rephrase.
Original:
This subtree provides configuration to select a logging system to
capture log messages generated by an ALTO server.
-->
14) <!--[rfced] [AD] In "example-alto-alg" (Appendix A.4), we see the
following BCP 14 keyword:
Original:
The referenced YANG datastore MUST be...
However, according to Section 3.6 of RFC 9907:
"Example YANG modules and example YANG fragments MUST NOT contain
any normative text, including any key words from [RFC2119] and
[RFC8174]."
Please let us know how to update.
-->
15) <!--[rfced] We have the following questions related to abbreviation use
throughout the document:
a) We don't see any uses of CDNi in RFC 9241. We have updated to use
CDNI consistently throughout the document. Please let us know any
objections.
b) We note the use of both ALTO O&M and ALTO OAM. Please review and
confirm that this variation is intentional.
c) Please note that we have added the following to the list of
Acronyms and Abbreviations in Section 3 in order to smooth their
expansions in running text or in a module:
CA - Certificate Authority
EE - End Entity
PSK - Pre-Shared Key
-->
16) <!--[rfced] We have the following questions related to terminology use
throughout the document:
a) Please review the capitalization of "whois" as we frequently see
WHOIS or WhoIs.
b) Please note that we have used the following forms consistently
throughout the document. Please let us know any concerns.
resource ID
data source ID
network map
cost map
entity property map
endpoint cost service
filtered
incremental update
c) We note "ALTO protocol" vs. "ALTO Protocol". Would you like to make
these instances uppercase (per RFCs 7285, 9240, 9241, and 9569) for
consistency?
the Application-Layer Traffic Optimization (ALTO) Protocol (2 instances)
the base ALTO protocol [RFC7285]
the ALTO protocol is extensible
-->
17) <!--[rfced] We have the following questions related to references:
a) We note that example-alto-server-discovery contains a pointer
to RFC 2622, but no citation exists in the document and no reference
entry exists in the References section. Please let us know if there
is somewhere in the prose we could add a citation and if an entry in
the Informative References section is appropriate.
b) We note that RFCs-to-be 10009 and 10010 are listed in the normative
references section. However, we only see pointers to them in the
example module. Looking at Section 3.2.1 of RFC 9907, we see:
"Example YANG modules and example YANG fragments MUST NOT contain any
normative text, including any key words from [RFC2119] and [RFC8174]."
Please review and let us know if updates are necessary.
Note that RFC 8641 is also only used in that example and is listed as an
informative reference.
-->
18) <!--[rfced] The following is a list of the terms that appear in <tt>
tags throughout the document. We note that many appear without
the tags as well. Please review that use of these terms is as
intended and consistent with your intention. Updates may be made
directly to the edited XML file if that is easier for the
authors.
<tt>algorithm</tt>
<tt>auth-client</tt>
<tt>authentication</tt>
<tt>data-source</tt>
<tt>datastore</tt>
<tt>internet-routing-registry</tt>
<tt>l3-unicast-cluster-algorithm</tt>
<tt>netconf</tt>
<tt>oauth2</tt>
<tt>peeringdb</tt>
<tt>protocol</tt>
<tt>resource-params</tt>
<tt>resource</tt>
<tt>restconf</tt>
<tt>server-discovery-manner</tt>
<tt>server-discovery</tt>
<tt>target-paths</tt>
<tt>yang-datastore</tt>
-->
19) <!-- [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.
-->
Thank you.
Megan Ferguson and Karen Moore
RFC Production Center
On Jun 17, 2026, at 11:07 AM, RFC Editor via auth48archive
<[email protected]> wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 10012 <draft-ietf-alto-oam-yang>
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/rfc10012.xml
https://www.rfc-editor.org/authors/rfc10012.html
https://www.rfc-editor.org/authors/rfc10012.pdf
https://www.rfc-editor.org/authors/rfc10012.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc10012-diff.html
https://www.rfc-editor.org/authors/rfc10012-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc10012-xmldiff1.html
Tracking progress
-----------------
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10012/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 10012 (draft-ietf-alto-oam-yang)
Title : YANG Data Models for the Application-Layer Traffic
Optimization (ALTO) Protocol
Author(s) : J. Zhang,
D. Dhody,
K. Gao,
R. Schott,
Q. Ma
WG Chair(s) : Qin Wu, Mohamed Boucadair
Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
