Paul Hoffman writes: > > Partially yes, but unfortunately all of the authors of those actual > > protocols decided that they wanted to continue publishing those drafts > > as individual RFCs, and each of them used different way to negotiate > > them, so there was no way to even implement multiple of them. > > Is this true? Because each has it's own way to negotiate its use, > one should be able to implement multiple of the competing proposals > as-is, yes? Before I proposed my common way to negotiate only one of the proposed protocols included any kind of support for indicating which version is used. The other two just assumed that initiator selects the method and responder supports it without any negotiation, meaning there was no way to make initiator version which supports multiple methods without trying the first method, if that failed, then starting IKE_SA_INIT from the beginning and trying second method etc... This has already been changing as one of the drafts is already changed to support what I have described in my draft, and another author has said he will update his. The third one already had negotiation altough done bit differently to compared what I proposed. As an implementor I myself I want to keep this problem concentrated in my code, meaning I do not want to make three completely differently done implementations for the same thing, when I can instead make generic changes to common code once, and separate the secure password method related processing in one module taking care as any methods needed to be implemented. > > At least this drafts gives you that option to implement multiple of > > them if you want. This draft only provides instructions for those > > other draft authors so they can at least common methods to negotiate > > the feature and use common method to trasmit data between peers. > > True, but it is still punting the problem of us having just one. Yes, but there is nothing I can do to that. I cannot fix the problem that all 3 drafts were sent forward and most likely will be published. If someone will decided only one of them will go forward (and there will not be any other ever) then my draft will be mostly unneeded as all of my draft can be put inside that one protocol draft going forward just like draft-shin-augmented-pake has already done. If there is no need to make sure multiple drafts make the negotiation and common payload things similarly as there is only one draft, then this draft is not needed. I am also the IANA expert for the IKEv2 registries, and that was the main reason I wanted to have common way to do things instead of doing dozen new allocations to the registries just to support 3 bit different ways to do same thing (when 3 allocations is enough). I wanted to point this out to the draft authors as early as possible, so it will not come as suprise to the authors that I do not support their way of allocating that many codepoints from the registries. -- kivinen@xxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf