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? > 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 > 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" ? > 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. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
