On 13/05/2025 14:00, Valery Smyslov wrote:
Hi Gorry,
Gorry Fairhurst has entered the following ballot position for
draft-ietf-ipsecme-ikev2-qr-alt-08: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thanks for producing this I-D for IKE. I really found it helpful to understand
how this could work and to explain the new method.
Thank you.
I have two comments that I really think ought to be considered before
progression (but which I do not need to DISCUSS:
(1) Please consider whether this ought to use RFC-2119 language, as /MAY/, it
could be a protocol action (you or the responsbile AD will know best): "If this
is inappropriate for the initiator, it may immediately delete this SA."
The reason a lowercase "may" is used and not an RFC2119 "MAY" is that
this is a local decision of initiator and not a not a protocol-related action.
Thus, it does not affect interoperability.
Perhaps "can" may be used instead to eliminate any confusion.
Your opinion?
I usually say that can is good in such cases to avoid any potential
misreading.
(2) Appendix A contains a RFC 2119 keyword: /MAY/. I do not think this is
normal to use keywords on appendices (you or the responsbile AD will know
best), please consider using a lower case /may/ or simply explain it is an
/alternative/.
Good catch, changed to lowercase "may".
===
I stumbled several times for non-technical reasons when reading, and therefore
I have a few comments that I hope will allow others to also easilly read this
useful I-D, for which I have tried to suggest new wording:
Abstract:
"way to get protection" - the word "get" seems to read strange to me, could you
consider using "provide" or soemthing similar?
Changed to "provide".
"but protects the initial IKEv2
SA too", could be "but also protects the initial IKEv2 SA."
Changed as you proposed.
Introduction:
"At the time this extension was being developed, it was a consensus in the
IPsecME WG that it is the IPsec traffic the one that mostly needs to be
protected.", could be: "At the time this extension was being developed, the
consensus in the IPsecME WG was to specify protection for the IPsec traffic."
Hmm. The current text stresses that the main idea of the consensus was that
only the IPsec traffic required this protection, not IKE traffic. Perhaps:
At the time this extension was being developed, the consensus in the
IPsecME WG was
that it is the IPsec traffic the one that mostly needs to be protected.
Does it work for you?
Happy for you to use other words, but this doesn't quite read correctly,
perhaps something like:
At the time this extension was being developed, the consensus in the
IPsecME WG was
that only the IPsec traffic was to be protected.
"However, in some situations it is desirable to have this protection for IKE
SA", include /the/: "However, in some situations it is desirable to have this
protection for the IKE SA".
Fixed, thank you.
"An example of such situation is Group", include
/a/ and /the/: "An example of such a situation is the Group"
Fixed, thank you.
"In this protocol
group policy and session keys are transferred from Group Controller/Key Server
(GCKS) to Group Members (GM) immediately once an initial IKE SA is created. ",
include /a/ and /the/: "In this protocol, group policy and session keys are
immediately transferred from a Group Controller/Key Server (GCKS) to the Group
Members (GM) once an initial IKE SA is created."
Fixed too. Using a proper article sometimes (with some definition of
"sometimes") pops off of my head.
Spec:
"then the responder MUST return NO_PROPOSAL_CHOSEN notification.", include
/a/? > "then the responder MUST return a NO_PROPOSAL_CHOSEN notification."
As I already mentioned, I'm not an expert in articles (they do not exist in
Russian),
but perhaps "the" is more appropriate here? NO_PROPOSAL_CHOSEN is a well
known notify message type defined in RFC 7296, so my rusted English grammar
knowledge tells me that "the" may be OK here (and I will be happy to update this
knowledge if I'm wrong).
Yes. That would be OK.
"If the negotiation was successful, the initiator includes one or more
PPK_IDENTITY_KEY
notification containing PPK identities the initiator believes are appropriate
for the IKE SA being created, into the IKE_INTERMEDIATE request.", could be:
"If the negotiation was successful, the initiator includes one or more
PPK_IDENTITY_KEY notifications into the IKE_INTERMEDIATE request,
containing
the PPK identities that the initiator believes are appropriate for the IKE SA
being created."
Perhaps a better text would be:
If the negotiation was successful, the initiator includes one or more
PPK_IDENTITY_KEY notification into the IKE_INTERMEDIATE request with
PPK identities the initiator believes are appropriate for the IKE SA
being created,
(replaced "containing" with "with"). Your opinion?
Thanks, yes.
Bullet 1&3:"If the responder is configured with one of the PPKs
which IDs were sent by the initiator and this PPK matches the initiator's",
seems hard to parse, maybe /with an ID that was sent/ ... or something similar?
(the same comment applies to bullet 3).
How about:
1. If the responder is configured with a PPK, which ID was among IDs
sent by the initiator, ...
and
3. If the responder does not have any PPKs proposed by the initiator ...
Your opinion?
Much better.
Bullet 2:"has some of proposed PPKs",
include /the/: "has some of the proposed PPKs"
Fixed, thanks.
"In case the responder", could be: "In the case that a responder"
Fixed, thanks.
All changes are made in my local copy.
Regards,
Valery.
Thanks, for your quick response, I enjoyed learning about this.
Your responsible AD will tell you if you should make a new revision, but
likely you'll need to do them when you have collected sufficient comments.
Gorry
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
