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?
> (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?
> "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).
> "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?
> 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?
> 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.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
