IP Security Maintenance and Extensions
charter-ietf-ipsecme-13

Substantive comments:

(1) I don't see the value in having an expiration date in a WG charter because it's not enforced in practice. The previous version of this charter said the WG would close if the charter wasn't updated by Dec 2017, but the WG continued to exist without the charter being updated. This charter seems tightly scoped enough to just get the work done according to the milestone dates or close sooner if people lose interest.

(2) I think it might be worth a few words to state the reason why the goal was for the new IKEv2 mode to have the same quantum resistant properties as existed in IKEv1, rather than better/fuller quantum resistance. 


Nits:

Based on the number of grammar and wording errors I found in this charter, I would strongly suggest doing a clean-up pass to make sure all of the text reads properly. Here is what I found:

(1)
s/to have similar quantum resistant properties than IKEv1 had/to have similar quantum resistant properties that IKEv1 had/

(2)
s/in form of counter/in the form of a counter/

(3)
I can't parse this sentence:

"A growing number of use cases for constrained network - but not
limited to - have shown interest in reducing ESP (resp. IKEv2)
overhead by compressing ESP (resp IKEv2) fields."

(4)
OLD
Currently IKE peers have no explicit way
to indicate each other which signature format(s) the support, that
leads to ineroperability problems.

NEW
Currently IKE peers have no explicit way
to indicate to each other which signature format(s) they support. That
leads to ineroperability problems.

(5) The milestones need to be updated. Some of the dates and draft names are wrong.

Just to hammer on:  the use of an expiration date on the charter for this WG has already proven not useful -- as we are already 6 months past the last expiration date and the WG was not closed.

I agree with Alissa's substantive and editorial comments.

Lots of good points made already that I won't repeat.

I agree that I don’t see value in having the expiration date. Why does the working group feel this is needed?

s/IPsec SA. non-standard/IPsec SA. Non-standard/

I don't object to this proposed charter going for internal review, but do have one question.

When looking at some of the work items, I see 

"A possible starting point is draft-yeung-g-ikev2" (nit, missing closing period)

"draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression."

"draft-smyslov-ipsecme-ikev2-compression and raft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression." (nit, should be "starting points")

"draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting point for this item."

If you're using different language to convey a nuance, that would be fine (I'm missing it, but I miss things). 

If you're saying the same thing in all four cases, I'd suggest using the same phrasing in each case. so working group chairs and participants aren't trying to figure out whether "possible starting point" and "could be used as a starting point" are the same as "expected to be good starting points" and "are good starting points".

I think I see "A possible starting point is" in most charters that point to individual drafts, which lets the working group decide whether to adopt that proposal or work on a different approach, but do the right thing, of course.

For the "The internal address failure indication in IKEv2" item it might be good to talk to 3GPP since they seem to be the only potential consumer of this work.