Hi Keith. Generally, the process goes something like this: - You write a draft (done!) - You present it on the mailing list (done!) - Usually, you ask for a time slot to present at a face-to-face meeting (not mandatory, but helps). The best is if you present it yourself, but if you don't plan to attend, someone else could present it for you. - Next the WG chairs ask the group if it wants to accept this. This involves: - A rough consensus that this is an idea worth pursuing - Enough people committing to read and review - Enough people willing to contribute text. - Determination of the above is at the discretion of the WG chairs. The advantage of presenting at a face-to-face, is that at least the last two questions can be answered there and then. - If there is enough willingness to take on the item, the WG chairs ask the ADs to add this to the charter. - If the ADs determine that this is a good idea, and has a chance of getting done (a motivated author is one of the requirements), they IESG approves the recharter - The WG chairs appoint one or more authors for the WG draft. It's not automatically you, but usually is, and they might add some more people, especially if they have different ideas.
A long process that can take anything from a month to 7 years. See "Wait before WG adoption" in http://www.arkko.com/tools/lifecycle/extremes.html Yoav On Jan 19, 2011, at 7:21 PM, Keith Welter wrote: > > I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown > below. I'd like to ask the working group to accept this as a work item but I > am unfamiliar with the process. What next? > > Thanks, > > Keith Welter > IBM z/OS Communications Server Developer > 1-415-545-2694 (T/L: 473-2694) > > > I noticed a minor problem in section 5: > > "When not using extensible authentication, the peers are authenticated > > by having each sign (or MAC using a padded shared secret as the key, > > as described later in this section) a block of data. > > > > But the padding is not described later in the section. > > > > I will reword the section as follows: > > "5. Authentication Data for Reauthenticating the IKE SA > > > > When not using extensible authentication, the peers are > > authenticated by having each sign (or MAC using a padded shared > > secret as the key) a block of data as described in [IKEv2] Section > > 2.15 except for the following differences: > > > > o For the modified IKE_AUTH request, the octets to be signed > > start with the first octet of the previous Authentication payload > > sent by the initiator and end with the last octet of that payload. > > > > o For the modified IKE_AUTH response, the octets to be signed > > start with the first octet of the previous Authentication payload > > sent by the responder and end with the last octet of that payload." > > > > > > Keith Welter > > IBM z/OS Communications Server Developer > > 1-415-545-2694 (T/L: > > 473-2694)_______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > <ATT00001..txt> _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
