> >> > Thus, what do you want to see in the third column? "Defined in RFC > >> > 7296"/"Defined in this document"? > >> > >> You could say, "STD79", and "Section X" if you like. > > > I prefer "RFC7296", as it's better known than "STD79" :-) > > Yet, it's incorrect.
I'm not sure. > It fails to include the updates, and it goes stale. The table of payloads in the G-IKEv2 spec will not contain updates anyway. It lists the payloads defined in RFC 7296 and thus it seems appropriate to reference a document where they are defined, not its future updates. As, for example, IANA registries do. > It also wastes all the effort we put into bringing it to Internet Standard. Bad or good, I believe it is a common practice in IETF, no? For example, a well-known RFC 822 is also STD 11, but it is rarely referenced by the latter name... > > The similarity between IKE_AUTH and GSA_AUTH is that both complete > > authenticating peers and creating IKE SA. The difference is that > > IKE_AUTH in addition creates unicast Child SA, so the set of payloads > > It does? I'm puzzled. Do you have any doubts? Quoting RFC 7296 Section 1 (Introduction): In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the first Child SA. Am I missing the point? > >> > Note, that RFC 7296 includes a concept of one-way IKEv2 messages > >> (for > error notification in case no IKE SA exists). > >> > >> Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY > >> is not. > > > GSA_REKEY is "inside" a multicast rekey SA (which is different from > > initial GM<->GCKS IKE SA). > > I think that this new SA needs to be introduced. It is introduced. Section 1: Group rekeys are accomplished using ... the GSA_REKEY pseudo-exchange (a single message distributed to all GMs, usually as a multicast message) ... > I think that there need to be some diagrams. Figure 1 shows the case where rekeying is being done over multicast. Do you think more clarifications are needed? Regards, Valery. > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
