Kent,
While reviewing this document during Final Review, please resolve (as
necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
2) <!--[rfced] With the publication of RFC 9907, some further updates
throughout the document may be necessary to address the
IANA-maintained module that was originally described in this
document.
a) Please review the text addressing the iana-http-versions module as
part of the text: as the module has been removed, some updates may be
necessary. For example:
Original:
Abstract:
This document presents three YANG 1.1 modules: the "iana-http-
versions" module defines a YANG "typedef" for HTTP protocol versions;
the "ietf-http-client" module defines a YANG "grouping" for
configuring an HTTP client's ability to communicate with an HTTP
service endpoint; and the "ietf-http-server" module defines a
"grouping" for configuring an HTTP server's service endpoints.
Perhaps:
Abstract:
This document [introduces/defines/etc.?] three YANG 1.1 modules:
the "iana-http- versions" module defines a YANG "typedef" for HTTP
protocol versions; the "ietf-http-client" module defines a YANG
"grouping" for configuring an HTTP client's ability to communicate
with an HTTP service endpoint; and the "ietf-http-server" module
defines a "grouping" for configuring an HTTP server's service
endpoints.
Original:
1. Introduction
This document presents three YANG 1.1 modules [RFC7950]:
1. The "iana-http-versions" module defines a YANG "typedef" for HTTP
protocol versions. This module is maintained by IANA, such that
new revisions will be automatically published whenever the
underlying IANA registry is updated to define new HTTP versions.
Perhaps:
1. Introduction
This document [introduces/defines/etc.?] three YANG 1.1 modules [RFC7950]:
1. The "iana-http-versions" module defines a YANG "typedef" for HTTP
protocol versions. This module is maintained by IANA, such that
new revisions will be automatically published whenever the
underlying IANA registry is updated to define new HTTP versions.
Original:
1.1. Relation to Other RFCs
This document presents three YANG modules [RFC7950] that are part of
a collection of RFCs that work together to, ultimately, support the
configuration of both the clients and servers of both the Network
Configuration Protocol (NETCONF) [RFC6241] and RESTCONF protocol
[RFC8040].
Perhaps (note the possible addition of 1.1 to match the sentences
above - if this is a desirable change, similar changes may be
warranted in the other C463 documents that are currently in our
queue): 1.1. Relation to Other RFCs
This document [introduces/defines/etc.?] three YANG 1.1 modules
[RFC7950] that are part of a collection of RFCs that work together
to, ultimately, support the configuration of both the clients and
servers of both the Network Configuration Protocol (NETCONF)
[RFC6241] and RESTCONF protocol [RFC8040].
b) RFC 9907 mentions:
It is RECOMMENDED to include the URL from where to retrieve the recent
version of the module.
Would you like to add any pointer in the document regarding where the
module can be found (i.e.,
https://www.iana.org/assignments/iana-http-versions/)?
Note: we do see the reference entries [IANA-TLS-ALNP-IDS] and
[IANA-YANG-PARAMETERS], which would get a reader to the module, but
9907 has examples of URLs that are more direct like the one we suggest
above.
c) As it looks like iana-http-versions is imported by the
ietf-http-client module, there might be a necessary update to make a
normative reference entry to the URL mentioned above in (b):
currently, all IANA URLs referenced are listed as informative
references.
RFC 9907 states:
If an IANA-maintained YANG module is imported by another module, a
normative reference with the IANA URL from which to retrieve the
IANA-maintained YANG module SHOULD be included.
-->
3) <!--[rfced] In Sections 1 and 2, how may we update this sentence for
clarity? Specifically, does "lower-level to transport layers"
mean that are there layers in between the lower-level and
transport layers? If not, should it perhaps be "lower-level and
transport layers" or "lower-level transport layers"?
Original:
For instance, the "scheme" and "authority" parts of the URI encode
information that portains to lower-level to transport layers.
Perhaps A:
For instance, the "scheme" and "authority" parts of the URI encode
information that pertains to the lower-level and transport layers.
or
Perhaps B:
For instance, the "scheme" and "authority" parts of the URI encode
information that pertains to the lower-level transport layers.
-->
4) <!--[rfced] We had a few questions regarding the following text:
Original:
This document presents one or more YANG modules [RFC7950] that are
part of a collection of RFCs that work together to, ultimately,
support the configuration of both the clients and servers of both
the NETCONF [RFC6241] and RESTCONF [RFC8040] protocols.
a) For clarity, may we update this sentence to indicate that the
modules, not the RFCs, support the configuration of the clients and
servers for both protocols?
Perhaps:
This document presents three YANG modules [RFC7950] that belong to
a collection of RFCs that are designed to work
together. Ultimately, these modules support the configuration of
clients and servers for both the Network Configuration Protocol
(NETCONF) [RFC6241] and RESTCONF protocol [RFC8040].
b) We note a variance in the above text with using simply YANG instead
of YANG 1.1 as was done in previous similar text. Should the
following further update be made (we ask as this sentence (or a very
similar sentence) appears in RFCs 9640-9645 as well as the other C463
documents currently in our queue).
Perhaps:
This document presents three YANG 1.1 modules [RFC7950] that belong
to a collection of RFCs that are designed to work
together. Ultimately, these modules support the configuration of
clients and servers for both the Network Configuration Protocol
(NETCONF) [RFC6241] and RESTCONF protocol [RFC8040].
-->
5) <!--[rfced] May we create a "Conventions" section (similar to that in
RFC 9641) after Section 1.2 ("Specification Language") so we may
include citations for the XML and line wrapping used in this
document? Note that we would place the corresponding W3C
reference entry for the XML under the Informative References
section as the XML schemas show example usage.
Perhaps:
1.3 Conventions
Various examples in this document use XML [W3C.REC-xml-20081126]
encoding.
Various examples in this document contain long lines that may be
folded, as described in [RFC8792].
-->
6) <!--[rfced] Please have a look at the text in Section 1.3 (Adherence
to the NMDA): the current text mentions trust anchors and keys
installed during manufacturing appearing tagged with
<operational>. Is this applicable to ietf-http-client or
ietf-http-server? Should supported-versions be mentioned here
instead? If updates are desired, please provide the new text.-->
7) <!--[rfced] Regarding Section 2.3 ("YANG Module"):
a) We note that a reference to RFC 9298 is included in this YANG
module, but it is not included in the References section and is not
cited elsewhere in the document. May we add RFC 9298 to the lead-in
sentence as shown below and include a corresponding reference entry?
If so, please let us know if it should be listed as normative or
informative.
b) We note that "RFC 9643" is cited in the YANG module but is missing
from the list of references in the lead-in sentence. May we add it as
shown below?
Current:
This YANG module has references to [RFC3986], [RFC9911], [RFC8341],
[RFC9110], and [RFC9645].
Perhaps:
This YANG module has references to [RFC3986], [RFC9298], [RFC9911],
[RFC8341], [RFC9110], [RFC9643], and [RFC9645].
c) We have updated to use "Initial revision." to match the use in RFC
9907. Please let us know any objections.
d) Neither module's description clauses contain the sentence mentioned
in RFC 9907 (below). Please let us know if/how to update:
The "description" statement MUST be present. For modules published
within IETF documents, the appropriate IETF Trust Copyright text
MUST be present, as described in Section 3.1, and MUST contain the
following statement:
All revisions of IETF and IANA published modules can be found at
the "YANG Parameters" registry group:
<https://www.iana.org/assignments/yang-parameters>.
e) Note that the YANG module has been updated per the
formatting option of pyang. Please let us know any concerns.
-->
8) <!-- [rfced] Does "augmented in" mean "augmented into the module"?
Please let us know how this may be clarified. Also note that we
updated "albeit" to "although" (as "albeit" is used when
introducing a phrase (such as an adjective or adverbial phrase)
rather than a complete independent clause).
Original:
Only the "basic" authentication scheme is supported, albeit it must
be enabled by a "feature". Other authentication schemes MAY be
augmented in.
Perhaps:
Only the "basic" authentication scheme is supported, although it must
be enabled by a "feature". Other authentication schemes MAY be
augmented into the module.
-->
9) <!-- [rfced] Section 3.3 (YANG Module): We had the following questions.
a) We note that a reference to RFC 9114 is included in the YANG
module, but it is not included in the References section and is not
cited elsewhere in the document (it only appears as an unlinked
example in Section 5.3).
May we add RFC 9114 to the lead-in sentence as shown below and include
a corresponding reference entry? If so, please let us know if the
entry should be listed as normative or informative. Note that we also
ordered the references by number.
Current:
This YANG module has references to [RFC7317], [RFC7617], [RFC8341],
[RFC9110], [RFC9911], [RFC9643], [RFC9645], and [RFC9984].
Perhaps:
This YANG module has references to [RFC7317], [RFC7617], [RFC8341],
[RFC9110], [RFC9911], [RFC9114], [RFC9643], [RFC9645], and
[RFC9984].
b) As this module imports iana-crypt-hash, does there need to be a normative
reference to this IANA-maintained yang module (i.e.,
https://www.iana.org/assignments/iana-crypt-hash/) per this guidance from RFC
9907?
RFC 9907:
If an IANA-maintained YANG module is imported by another module, a
normative reference with the IANA URL from which to retrieve the
IANA-maintained YANG module SHOULD be included. Although not
encouraged, referencing the RFC that defines the initial version of
the IANA module is acceptable in specific cases (e.g., the imported
version is specifically the initial version, the RFC includes useful
description about the usage of the module).
c) Note that the YANG module has been updated per the
formatting option of pyang. Please let us know any concerns.
-->
10) <!--[rfced] We have the following questions/comments related to the
Security Considerations section:
a) [AD] Please review the mismatch between the text in the Security
Considerations subsections and the template listed at
https://datatracker.ietf.org/doc/html/rfc9907#name-security-considerations-sec.
In particular:
- Section 4.1:
Strays from the template wording. Please also review if the no-data-nodes
paragraph applies.
- Section 4.2:
We believe "None of the readable data nodes" was intended to be "None
of the writable data nodes"; we made the update - please review and
let us know if this change is not correct. Also, the writable/readable
node paragraphs stray from the template wording.
- Section 4.3:
The writable/readable node paragraphs stray from the template wording.
- Sections 4.2 and 4.3:
In the paragraph that starts with "This YANG module uses groupings
from ...", should the RFCs be listed per the template (instead of
"refer to the Security Considerations for dependent YANG modules")?
b) FYI - we have made a number of changes to more closely align the
Security Considerations section with the text appearing at
https://datatracker.ietf.org/doc/html/rfc9907#name-security-considerations-sec.
Please review carefully and let us know any objections.
c) In Section 4.3, is it correct that the server "authenticates"
invalid client credentials, or would it be more correct to say that
the server "accepts" the invalid credentials?
Original:
Misconfigured "client-authentication" may lead the server to authenticate
invalid client credentials.
Perhaps:
Misconfigured "client-authentication" may lead the server to accept
invalid client credentials.
-->
11) <!-- [rfced] Questions regarding Section 5.3 "Considerations for the
"iana-http-versions" YANG Module":
a) FYI: The template for IANA-maintained YANG modules with
enumerations is contained in Section 4.30.3.2 (rather than in Section
4.30.2.1) of RFC 9907. We made the following update as shown below.
Original:
This section follows the template defined in Section 4.30.3.1 of
[I-D.ietf-netmod-rfc8407bis].
Current:
This section follows the template defined in Section 4.30.3.2 of
[RFC9907].
b) The list in this section is missing the "value" entry per the
template in RFC 9907. Should it be added?
Current:
enum:
Replicates a name from the registry.
status:
Include only if a registration has been deprecated or obsoleted.
description:
Contains "Enumeration for the "HTTP/FOO" HTTP protocol version",
where "HTTP/FOO" is a placeholder for the algorithm's name
(e.g., "HTTP/3").
reference:
Replicates the reference(s) from the registry with the title of
the document(s) added (e.g., "RFC 9114: HTTP/3").
Perhaps:
enum:
Replicates a name from the registry.
value:
Contains the decimal value of the IANA-assigned value.
status:
Include only if a registration has been deprecated or obsoleted.
description:
Contains "Enumeration for the "HTTP/FOO" HTTP protocol version",
where "HTTP/FOO" is a placeholder for the algorithm's name
(e.g., "HTTP/3").
reference:
Replicates the reference(s) from the registry with the title of
the document(s) added (e.g., "RFC 9114: HTTP/3").
c) The text in the list above varies from the inputs in RFC 9907 for
"status". Should this text be updated to match RFC 9907?
This doc:
status:
Include only if a registration has been deprecated or obsoleted.
RFC 9907:
"status": Is included only if a registration has been
deprecated or obsoleted. IANA "deprecated" maps
to YANG status "deprecated", and IANA "obsolete"
maps to YANG status "obsolete".
d) In the following description, is the "algorithm's name" correct, or
should it perhaps be the "protocol version name"?
Current:
description:
Contains "Enumeration for the "HTTP/FOO" HTTP protocol version",
where "HTTP/FOO" is a placeholder for the algorithm's name (e.g.,
"HTTP/3").
Perhaps:
description:
Contains "Enumeration for the "HTTP/FOO" HTTP protocol version",
where "HTTP/FOO" is a placeholder for the protocol version name
(e.g., "HTTP/3").
e) Does any text need to be added to the IANA Considerations section
to explicitly address the following requirement from RFC 9907 (Section
4.30.3)?
RFC 9907 states:
In addition to the IANA considerations in Section 3.8, the IANA
Considerations section of an RFC that includes an IANA-maintained YANG
module MUST provide the required instructions for IANA to
automatically perform the maintenance of that IANA module.
We do see the following in the Introduction: This module is maintained
by IANA, such that new revisions will be automatically published
whenever the underlying IANA registry is updated to define new HTTP
versions.
f) The following template text from Section 4.30.3.2 of RFC 9907 does
not appear in this section:
This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module is
available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
Should something like the following be added to the beginning of this
section?
Perhaps:
This document defines the initial version of the IANA-maintained
"iana-http-versions" YANG module. The most recent version of the YANG
module is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
g) Would it be helpful to the reader to include a citation regarding
the creation of the revision statement?
h) We note that the indentation of the example revision statement did
not match that used in RFC 9907. Please review our updates and let us
know any objections.
i) Should some kind of text be added to this document (somewhere)
related to the reasoning behind why enumeration was chosen over
identityref?
>From Section 4.30.2 of RFC 9907:
The decision about which type to use should be made based upon
specifics related to the intended use of the IANA-maintained YANG
module. For example, identities are useful if the registry entries are
organized hierarchically, possibly including multiple
inheritances. The reasoning for the design choice MUST be documented
in the companion specification that registers an IANA-maintained YANG
module.
j) Please see EID 8880 (https://errata.rfc-editor.org/eid8880/) with
regard to the notes IANA is adding to the module and the registry.
Should their placement or lead-in text in the IANA Considerations of
this document be updated?
-->
12) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. We have updated
accordingly. Please let us know any objections.
-->
13) <!--[rfced] RFC 8407 has been replaced by RFC 9907. We have updated
accordingly. Please let us know any objections.
-->
14) <!--[rfced] Please review each artwork element in the XML file and let
us know if any should be marked as sourcecode (or another
element) instead.
In addition, please consider whether the "type" attribute of any
sourcecode element has been set correctly.
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the
current list does not contain an applicable type, feel free to suggest
additions for consideration. Note that it is also acceptable to leave
the "type" attribute not set.
-->
15) <!--[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
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 10009 <draft-ietf-netconf-http-client-server>
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/rfc10009.xml
https://www.rfc-editor.org/authors/rfc10009.html
https://www.rfc-editor.org/authors/rfc10009.pdf
https://www.rfc-editor.org/authors/rfc10009.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc10009-diff.html
https://www.rfc-editor.org/authors/rfc10009-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc10009-xmldiff1.html
Tracking progress
-----------------
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10009/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 10009 (draft-ietf-netconf-http-client-server)
Title : YANG Groupings for HTTP Clients and HTTP Servers
Author(s) : K. Watsen
WG Chair(s) : Kent Watsen, Per Andersson
Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
