Dear RFC editors,
thank you for your work on polishing the document and your list of good
questions.
Our apologies for taking longer than expected to respond -
after I prepared a draft response on which we had to align among us
authors, I was on sick leave for a couple of days.
We enclose below our aligned responses to the given list of questions.
We authors agree on most changes. For a small part of them we see good
reason to return to the original text or we suggest further enhancement,
all of which we also list below.
Please let us know if anything remains to be clarified.
Best regards,
David von Oheimb and co-authors
On 11.02.25 00:05, rfc-edi...@rfc-editor.org wrote:
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!--[rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review and confirm that this is how you would like
"BRSKI-AE" to be expanded both in the title and throughout the rest of
this document.
Original:
BRSKI-AE: Alternative Enrollment Protocols in BRSKI
Current:
BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative
Enrollment
-->
OLD:
BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with
Alternative Enrollment
NEW:
BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with
Alternative Enrollment Protocols
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use onhttps://www.rfc-editor.org/search. -->
BRSKI, IoT, zero-touch onboarding, alternative enrollment protocols, CMP,
self-contained signed objects, end-to-end proof of origin, auditable
source authentication
3) <!-- [rfced] We have updated the text below to improve readability. Please
review to ensure these changes do not alter your intended meaning.
Original:
It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and
to the registrar, which is the access point of the target domain,
and to possibly further components of the domain where it will be
operated.
Current:
It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA) [RFC8995] and the
registrar (which is the access point of the target domain) and to
possibly further components of the domain where it will be
operated.
-->
Pretty good.
Just may add commas to separate the clauses more clearly, if you agree
this would help:
OLD:
[RFC8995] and the registrar (which is the access point of the target
domain) and to
NEW (optional, or keep OLD):
[RFC8995], to the registrar (which is the access point of the target
domain), and to
4) <!-- [rfced] Please review the following questions and changes regarding the
terminology list in Section 2:
a.) FYI - We have updated some list items to have a 1:1 relationship between
abbreviation and expansion. Please carefully review these changes and let us
know of any objections.
Please add NEW:
local RA: same as LRA.
b.) As this list contains a mixture of definitions and abbreviations, may we
separate these items into two separate lists for readability?
Yes.
c.) We note that several abbreviations appear in this document that are not
included in the terminology list in Section 2 (see some examples
below). Please review and let us know if these or any other terms should be
added.
(Note that we have already added a list item for Certification Authority (CA)
as this abbreviation appears in other definitions in this list.)
Key Encapsulation Mechanism (KEM)
Certificate Request Message Format (CRMF)
Simple Certificate Enrolment Protocol (SCEP)
Certificate Management over CMS (CMC)
Autonomic Control Plane (ACP)
-->
Please add NEW:
Certificate Request Message Format (CRMF)
Simple Certificate Enrolment Protocol (SCEP)
Certificate Management over CMS (CMC)
(The other two abbreviations are just used very locally, so no need to
add them.)
5) <!-- [rfced] May we clarify the content in the parenthetical text below?
Original:
Binding a certificate signing request (CSR) to an existing
authenticated credential (the BRSKI context, the IDevID certificate)
enables proof of origin...
Perhaps:
Binding a Certificate Signing Request (CSR) to an existing
authenticated credential (such as the BRSKI context or the IDevID
certificate)
enables proof of origin...
-->
OLD:
(such as the BRSKI context or the IDevID certificate)
NEW:
(which in the BRSKI context is the IDevID certificate)
6) <!-- [rfced] FYI - For ease of the reader, we have broken up the following
sentences below into two. Please let us know any objections.
Original:
What the registrar needs to do is to authenticate and pre-authorize the
pledge and to indicate this to the (second) RA by signing the forwarded
certification request with its private key and a related certificate
that has the id-kp- cmcRA extended key usage attribute.
...
It will recognize whether the protocol
it uses and the specific request it wants to perform are understood
and supported by the domain registrar by sending the request to the
respective endpoint according to the above addressing scheme and then
evaluating the HTTP status code of the response.
Current:
What the registrar needs to do is authenticate and pre-authorize the
pledge and indicate this to the (second) RA. This is done by signing the
forwarded certification request with its private key and a related
certificate
that has the id-kp-cmcRA extended key usage attribute.
...
It will recognize whether the protocol
it uses and the specific request it wants to perform are understood
and supported by the domain registrar. This is done by sending the
request to the respective endpoint according to the above addressing
scheme and then evaluating the HTTP status code of the response.
-->
Fine.
7) <!--[rfced] To avoid the awkward hyphenation of "PKCS #10-formatted CSRs",
may we update the text as follows?
Original:
[RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs
with a Full PKI Request message sent to the "/fullcmc" endpoint.
Perhaps:
[RFC7030], Section 2.5 sketches wrapping CSRs formatted per PKCS #10
with a Full PKI Request message sent to the "/fullcmc" endpoint.
-->
Fine.
8) <!-- [rfced] We note the use of "FullCMCRequest" in the following sentence;
however, RFC 7030 uses the term "Full CMC Request". May we update this
instance for consistency with RFC 7030?
Original:
The proof of identity can be provided as part of a FullCMCRequest, based on
CMS [RFC5652] and signed with an existing IDevID secret.
Perhaps:
The proof of identity can be provided as part of a Full CMC Request based on
CMS [RFC5652] and signed with an existing IDevID secret.
-->
Fine.
9) <!-- [rfced] In the sentence below, may we update "follows" for clarity?
Original:
Note: From the definition of the interaction with the MASA in
[RFC8995], Section 5 follows that it may be synchronous (using
voucher request with nonces) or asynchronous (using nonceless
voucher requests).
Perhaps:
Note: From the definition of the interaction with the MASA in
Section 5 of [RFC8995], it may be synchronous (using
voucher requests with nonces) or asynchronous (using nonceless
voucher requests).
-->
We are note sure, maybe it would be more clear to write as follows;
please choose as you prefer:
OLD:
From the definition of the interaction with the MASA in Section 5 of
[RFC8995],
NEW (optional, or keep OLD):
The definition of the interaction with the MASA in Section 5 of
[RFC8995] implies that
10) <!-- [rfced] How may we clarify what "as not already done" and "it" refer to
in the text below?
Original:
* RA: performs centralized certificate management functions as a
public-key infrastructure for the domain operator. As far as not
already done by the domain registrar, it performs the final
validation and authorization of certification requests.
Perhaps:
* RA: This performs centralized certificate management functions as a
public-key infrastructure for the domain operator. As far as what is
not already done by the domain registrar, the RA performs the final
validation and authorization of certification requests.
-->
OLD:
As far as what is not already done by the domain registrar
NEW:
Insofar these functions are not already done by the domain registrar,
(or
NEW':
In case these functions are not entirely performed by the domain registrar,
)
11) <!-- [rfced] Throughout this document, we note that RFCs 8895 and 9483 are
often referred to with shortened titles or nicknames such as "BRSKI" and
"LCMPP", respectively.
For clarity, because these names also represent protocols, we plan to update
these document nicknames to just their RFC number (in order to help the reader
distinguish between the RFC itself and the protocol). Please see some examples
below and let us know any objections.
Originals:
In this document, references to CMP follow the Lightweight CMP
Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the
subset of CMP defined in LCMPP sufficiently meets the required
functionality.
* MASA: functionality as described in BRSKI [RFC8995]. The voucher
exchange with the MASA via the domain registrar is performed as
described in BRSKI.
* Ownership tracker: This is as defined in BRSKI.
Perhaps:
In this document, references to CMP follow [RFC9483] rather than
[RFC4210] and [RFC9480], as the subset of CMP defined in [RFC9483]
sufficiently meets the required functionality.
* MASA: This has the functionality as described in [RFC8995].
The voucher exchange with the MASA via the domain registrar is
performed as described in [RFC8995].
* Ownership Tracker: This is as defined in [RFC8995].
-->
OK for BRSKI -> [RFC8995]. We use LCMPP not as the name of a protocol -
it is the name of the profile defined in [RFC9483]. Therefore, please
keep "Lightweight CMP Profile (LCMPP)" and "LCMPP". Yet for the only
case where we actually mean the respective protocol, so in the
abbreviation list in section 2within the item for "BRSKI-AE"please
change (also for simplicit)y: OLD: Lightweight CMP (see LCMPP) NEW:
CMP
12) <!-- [rfced] In Section 4.1, should "Discovery phase" and "Identification
phase"
be updated to "Discover phase" and "Identity phase", respectively, to better
match the figure from Section 2.1 of RFC 8995?
Original:
Based on the diagram in BRSKI [RFC8995], Section 2.1 and the
architectural changes, the original protocol flow is divided into
several phases showing commonalities and differences to the original
approach as follows.
* Discovery phase: mostly as in BRSKI step (1). For details see
Section 4.2.1.
* Identification phase: same as in BRSKI step (2).
Perhaps:
Based on the diagram in [RFC8995], Section 2.1 and the
architectural changes, the original protocol flow is divided into
several phases showing commonalities and differences to the original
approach as follows.
* Discover phase: This is mostly as in step (1) of [RFC8995]. For
details see Section 4.2.1.
* Identity phase: This is the same as in step (2) of [RFC8995].
-->
We consider the suggested change problematic because, e.g.,
"Discover phase" it could be misread as "this discovers a phase".
Moreover, BRSKI section 2.1 does not use "phase" in the figure nor in
the labels of the list elements.
So for consistency with that, please remove form your suggestion the
"phase" part:
OLD:
Discovery phase: This
NEW:
Discover: This
OLD:
Identity phase: This
NEW:
Identify: This
(and in the sequel):
OLD:
Voucher exchange phase: This
NEW:
Voucher exchange: This
13) <!--[rfced] To improve the readability of the following sentence, may we
update
it as follows?
Original:
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is REQUIRED to use.
Perhaps:
It is REQUIRED to use the (D)TLS channel established between the
pledge and registrar to transport the certificate enrollment request
and response messages.
-->
Fine.
14) <!-- [rfced] Should "options applicable" be updated to "applicable options"
in the text below?
Original:
Section 5 discusses selected suitable enrollment protocols and options
applicable.
Perhaps:
Section 5 discusses selected suitable enrollment protocols and applicable
options.
-->
Yes.
15) <!-- [rfced] As this sentence begins Section 4.2.4, may we clarify what
"This" refers to?
Additionally, may we make a similar update in Appendix A.5?
Original:
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
This replaces the EST integration for PKI bootstrapping described in
[RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the
final phase, see below).
...
A.5. Infrastructure Isolation Policy
This refers to any case in which network infrastructure is normally
isolated from the Internet as a matter of policy, most likely for
security reasons.
Perhaps:
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
RA/CA certificate enrollment replaces the EST integration for PKI
bootstrapping described in Section 5.9 of [RFC8995] (while Section 5.9.4
of [RFC8995] remains as the final phase; see below).
...
A.5. Infrastructure Isolation Policy
The infrastructure isolation policy refers to any case in which...
-->
4.2.4
OLD:
RA/CA certificate enrollment replaces
NEW:
The specification in this section replaces
A.5
OLD:
The infrastructure isolation policy refers
NEW:
The approach described in this section refers
16) <!-- [rfced] To improve readability, may we update the list below as
follows?
Original:
They include the application scenario, the capabilities of the registrar
and of the local RA possibly co-located with the registrar, the enrollment
protocol being used, and the specific contents of the request.
Perhaps:
They include the application scenario, the capabilities of the registrar,
the capabilities of the local RA possibly co-located with the registrar,
the enrollment protocol being used, and the specific contents of the
request.
-->
Fine.
17) <!--[rfced] Should the following artwork element be reformatted as
a bulleted list, per text from the preceding paragraph?
Original:
The following list of endpoints provides an illustrative example of a
domain registrar supporting several options for EST as well as for
CMP to be used in BRSKI-AE.
...
/.well-known/brski/voucherrequest
/.well-known/brski/voucher_status
/.well-known/brski/enrollstatus
/.well-known/est/cacerts
/.well-known/est/csrattrs
/.well-known/est/fullcmc
/.well-known/cmp/getcacerts
/.well-known/cmp/getcertreqtemplate
/.well-known/cmp/initialization
/.well-known/cmp/pkcs10
-->
As you prefer.
18) <!-- [rfced] Formatting and XML:
a.) There are several author comments present in the XML. Please
review and confirm that none of these comments still need to be
addressed. Note that the comments will be deleted prior to
publication.
Yes, fine to delete them.
b.) Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
Please use <aside> for the following note paragraphs:
Note: From the definition of the interaction with the MASA in
[RFC8995], Section 5 follows that it may be synchronous (using
voucher requests with nonces) or asynchronous (using nonceless
voucher requests).
Note: The message exchanges marked OPTIONAL in Figure 2 below
cover all those supported by the use of EST in BRSKI. The last
OPTIONAL one, namely certificate confirmation, is not supported by
EST but by CMP and other enrollment protocols.
Note that the optional certificate confirmation by the pledge to the
PKI described above is independent of the mandatory enrollment status
telemetry done between the pledge and the registrar in the final
phase of BRSKI-AE, which is described next.
Note that independent of the certificate confirmation within CMP,
enrollment status telemetry with the registrar at the BRSKI level
will be performed as described in [RFC8995], Section 5.9.4.
Note: We chose the suffix "cmp" here rather than some other
abbreviation like "lcmpp" mainly because this document defines the
normative CMP instantiation of BRSKI-AE, which implies adherence to
LCMPP is necessary and sufficient.
Note: If EST was used, the registrar could give implicit consent on a
certification request by forwarding the request to a PKI entity using
a connection authenticated with a certificate containing an id-kp-
cmcRA extension.
c.) We note the following different uses regarding this document's use of <tt>
styling and quotation marks. In the HTML and PDF outputs, the text enclosed in
<tt> is output in fixed-width font. In the txt output, there are no changes to
the font. Please review carefully and let us know if any updates should be made
for consistency:
the <tt>caPubs</tt> field
the acp-node-name field (no quotes or <tt> styling)
<tt>"brski-reg-cmp"</tt>
brski-reg-cmp (no quotes or <tt> styling)
<tt>"brski-registrar"</tt>
<tt>"/.well-known/est/simpleenroll"</tt>
<tt>"/.well-known/<enrollment-protocol>/<request>"</tt>
<tt>"/fullcmc"</tt> endpoint
<tt>"/simpleenroll"</tt> endpoint
'<tt>est</tt>'
'<tt>cmp</tt>'
<tt><enrollment-protocol></tt>
<tt><request></tt>
The label <tt>[OPTIONAL forwarding]</tt>
'renewal' option
"tls-unique" value
the tls-unique value (no quotes)
-->
Good point.
OLD:
the <tt>caPubs</tt> field
NEW:
the '<tt>caPubs</tt>' field
OLD:
the acp-node-name field
NEW:
the 'acp-node-name' field
(several times:)
OLD:
<tt><enrollment-protocol></tt>
NEW:
"<tt><enrollment-protocol></tt>"
(several times:)
OLD:
<tt><request></tt>
NEW:
"<tt><request></tt>"
OLD:
The label <tt>[OPTIONAL forwarding]</tt>
NEW:
The label '<tt>[OPTIONAL forwarding]</tt>'
OLD:
the tls-unique value
NEW:
the "tls-unique" value
19) <!-- [rfced] Abbreviations:
a.) FYI - We have updated the expansion of LDevID throughout the document
as follows. Please review and let us know of any objections.
Original:
Locally significant Device IDentifier (LDevID)
Current:
Local Device Identifier (LDevID)
Please revert this change, as the official name does include "Locally
significant" and the "IDentifier" is meant to point out that the first
two letters are part of the abbreviation.
b.) We note the following expanded forms of "PKI" are used after the
abbreviation is introduced. May we update these instances below to the
abbreviation?
Public-Key Infrastructure
public-key infrastructure
Figure 1:
OLD:
Public-Key Infrastructure
NEW:
Public-Key Infrastructure (PKI)
4.1
OLD:
a public-key infrastructure
NEW:
a PKI
c.) May we update instances of "local RA" to the abbreviation "LRA"?
Please keep "local RA", which contrasts better with "full RA".
d.) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Autonomic Control Plane (ACP)
Certificate Management over CMS (CMC)
Cryptographic Message Syntax (CMS)
Constrained Application Protocol (CoAP)
Simple Certificate Enrollment Protocol (SCEP)
-->
Fine.
20) <!-- [rfced] Please review the following changes and questions we have
regarding the References section:
a.) [UNISIG-Subset-137]
The provided URL returns the message: "The requested page could not be found."
We found the following URL from the European Union Agency for Railways (ERA)
website, which matches the specification described in this reference, but it
is a more up-to-date version from May 2023. Would you like to use this version
and URL instead?
https://www.era.europa.eu/sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf
Current:
[UNISIG-Subset-137]
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
137, Version 1.0.0, December 2015,
<https://www.era.europa.eu/sites/default/files/filesystem/
ertms/ccs_tsi_annex_a_-_mandatory_specifications/
set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
_subset-137_v100.pdf>.
Sigh, the original link was ugly and prone to break, and meanwhile it did.
Please use instead this link:
NEW:
https://www.era.europa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf
b.) [BRSKI-AE-OVERVIEW]
FYI - We have removed the text below from the <annotation> element in this
reference. If you would like to include this note, we recommend placing it in
the document where this reference is cited (rather than in the references
section).
"Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF
116."
Then please re-add the description of what was actually meant, namely
only slide 4,
as we indicated above for section 4.2:
NEW:
can be found in the graphics on slide 4 of [BRSKI-AE-overview].
c.) [IEC-62351-9]
Would you like to update to the newest version of this reference? The cited
version of this reference has been withdrawn. In addition, this version of the
document references the SCEP Internet-Draft rather than RFC 8894 (SCEP). RFC
8894 is cited in the 2023 version.
Current:
[IEC-62351-9]
International Electrotechnical Commission, "Power systems
management and associated information exchange - Data and
communications security - Part 9: Cyber security key
management for power system equipment", IEC 62351-9:2017,
May 2017,<https://webstore.iec.ch/en/publication/30287>.
-->
Yes, please update to the latest version,
apparently available at https://webstore.iec.ch/en/publication/66864
21) <!-- [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. -->
We did not notice any problematic words.
As non-native speakers, we anyway believe that your script would know
better than us.
Mostly independently of the questions answered above, here is a list of
changes requested by the authors
relative to the update you provided at
https://www.rfc-editor.org/authors/rfc9733-rfcdiff.html :
Global
/(since OVERVIEW and DISCOVERY would wrongly look like abbreviations:)/
OLD:
BRSKI-AE-OVERVIEW
NEW:
BRSKI-AE-overview
Global
OLD:
BRSKI-DISCOVERY
NEW.
BRSKI-discovery
1.
OLD:
Initial Device Identifier (IDevID)
NEW:
Initial Device IDentifier (IDevID)
1.
OLD:
voucher exchange [RFC8366]
NEW:
voucher [RFC8366] exchange
2.
OLD:
BRSKI-AE: BRSKI with Alternative Enrollment.
NEW:
BRSKI with Alternative Enrollment Protocols (BRSKI-AE)
2.
OLD:
IDevID: Initial Device Identifier
NEW:
IDevID: Initial Device IDentifier
2.
OLD:
LDevID: Local Device Identifier
NEW.
LDevID: Locally Significant Device IDentifier
4.2.
OLD:
can be found at [BRSKI-AE-OVERVIEW].
NEW:
can be found in the graphics on slide 4 of [BRSKI-AE-overview].
6.
We are ok with your change
from "Lightweight CMP Profile (LCMPP, [RFC9483])"
to "Lightweight CMP Profile (LCMPP) [RFC9483]"
because it improves consistency with the style used in sections 1 and 5.1.
Yet please just note that this change incurs a minor textual discrepancy
with the Description entry at /
/https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski-reg-cmp
which uses/"/Lightweight CMP Profile (LCMPP, [RFC9483])".
A.1
OLD:
These communicate within the railroad car but also exchange information
between railroad cars,
forming a train with track-side equipment and/or possibly with backend
systems.
NEW:
These communicate within the railroad car but also exchange information
with other railroad cars
of the same train and with track-side equipment and/or possibly with
backend systems.
On 11.02.25 00:04, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/02/10
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered 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
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
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
*rfc-edi...@rfc-editor.org (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).
*auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; 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,
auth48archive@rfc-editor.org 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/rfc9733.xml
https://www.rfc-editor.org/authors/rfc9733.html
https://www.rfc-editor.org/authors/rfc9733.pdf
https://www.rfc-editor.org/authors/rfc9733.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9733-diff.html
https://www.rfc-editor.org/authors/rfc9733-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9733-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9733
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9733 (draft-ietf-anima-brski-ae-13)
Title : BRSKI-AE: Alternative Enrollment Protocols in BRSKI
Author(s) : D. von Oheimb, S. Fries, H. Brockhaus
WG Chair(s) : Toerless Eckert, Sheng Jiang
Area Director(s) : Warren Kumari, Mahesh Jethanandani
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
