> On Dec 6, 2024, at 06:38, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > Hi Paul, > > thank you for your review. Please, see inline. > >>> Subject: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-rename-esn >> >> I am in favour of adoption and have reviewed the document. Thanks to Valery >> for >> writing this draft. >> >> Comments: >> >> I don't like the phrase "Transform ID 0" because each transform type has its >> own >> transform id 0. I would prefer to use Transform Type 5 and talk about the >> value 0, >> etc. > > "Transform ID" is the official name for transform type values :-) > > I think that you are referring to the bulleted list at page 5, right? > > If we change this text as following (leaving other places where transform IDs > are mentioned intact): > > * Value 0 for transform type 5 defines [...] > * Value 1 for transform type 5 defines [...] > > will this resolve your concern?
Yes > >> I would remove everything but the last sentence from Section 4 Security >> Considerations. eg just say nothing changes. It removes repetition and it >> doesn't >> really beling in this section anyway. > > OK. > >> nits: >> >> The receiver maintains sliding window -> The receiver maintains a sliding >> window >> >> and are instead deducted -> and are instead deduced > > Fixed. > >> Since the decision whether to enable anti-replay protection is ultimately >> taken by >> the receiver >> >> Since the decision whether to enable anti-replay protection is taken by the >> receiver >> independently of the sender > > Hmm... I'm not sure that this is a good change. "Independently" to my ear > sounds > like we can imagine an alternative, when receiver's decision could depend on > sender, > which is not the case. Perhaps the better text would be: > > OLD: > Since the decision whether to enable anti-replay protection is taken by the > receiver > > NEW: > Since the decision whether to enable anti-replay protection is taken by the > receiver based only on the receiver's local policy Looks good. > >> Both AH and ESP specifications allow the sender to relax their duties of >> maintaining >> Both AH and ESP specifications allow the sender to avoid maintaining >> >> if there is a way to notify the sender -> if the sender has been notified > > I'm unsure that this is the correct change too. To my ear, the new text > implies that there was a possibility in the protocol to notify the sender, > but for some reason it wasn't happen. Instead, the current text tries > to say that currently there is no way to notify the sender. > > Perhaps better "if the sender could be notified" ? Could be is not strong enough. If we extend IKEv2 it could be (but not have been) notified. How about if the sender has been notified somehow > >> AH and ESP rely on the Internet Key Exchange protocol version 2 -> AH and ESP >> are usually established using the Internet Key Exchange protocol > > Fixed. And yes, make the doc Standards Track so we don’t get any downref issues later. It modifies a standard track RFC. It doesn’t matter that it doesn’t add entries to any registries. Paul _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
