This is a really minor comment: you reserve 3-39999 as unassigned and 40K+ as private use. Why not make that boundary 49152, nice binary multiple.
I also wonder if having four Shortcut Notify types might just be simpler to implement, rather than having another layer of type codes. I'm also not clear why a Notify: it seems like it ought to be an entirely normal payload type, cousin to Proposal. One might even argue that this is a new kind of *Proposal*, the "shortcut proposal". My goal here is to reuse as much as the current decoding and validation code as possible. It seems that port numbers belong in the Shortcut Types. I think that an IPv4 shortcut is one that traverse IPv4, and it could have anything inside it. (IPv4, IPv6, maybe even transport mode SAs) I'd rather see IDi/TSi embedded in this using the normal payload structure of IKEv2. Do the IDi/r and TSi/r payloads include their normal 4-byte header? The IDi description says no generic header.... the TSi description should be moved up to the TSi description. Gee, I'd sure rather we weren't encouraging more PSK use. I'm finding the IDx payloads interesting: it is interesting that the identity is being managed here. That sure gets around a whole host of issues with letting the gateways use their own identities, which might be tied up with certificates and other stuff. I think that some recommendation should made (and some MUST implement) about ID types here. I like Appendix A.2. I'm glad you took the suggestion of having the shortcut be learned incrementally. Re: the situation in A.3. If officeGW realizes that peer1 and peer2 are in fact on the same subnet, etc. is there any way for it to tell them to create a "bypass" between them? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
pgpoI6_crRDoJ.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
