ietf
[Top] [All Lists]

Re: Gen-art review of draft-ietf-ipsecme-ikev2bis-08.txt

2010-03-20 10:33:13
I am going to push back on this because what you want to add goes against the 
WG consensus for the long-standing RFC that this draft is meant to obsolete. 
This thread directly relates to the logic in the recent/ongoing IETF Last Call 
on draft-ogud-iana-protocol-maintenance-words.

At 1:06 PM +0000 3/20/10, Elwyn Davies wrote:
Major issues:

s3.3.4: The draft states that the list of mandatory to implement suites has 
been removed due to evolution going too fast.  Is this acceptable?

   

draft-ietf-ipsecme-ikev2bis is a revision of RFC 4306, and the paragraph in 
question about removing the mandatory-to-implement suites is copied directly 
from RFC 4306. When the original WG published RFC 4306 over four years ago, 
it decided to split out the suites into what became RFCs 4307 and 4308. 
draft-ietf-ipsecme-ikev2bis changes nothing here.

Does that clear up your issue, or are you saying that 
draft-ietf-ipsecme-ikev2bis should reverse the old policy and explicitly 
pull in the text from RFC 4307 and RFC 4308 into the new document?

 
Neither.

The omly mention of mandatory to implement suites is in s3.3.4 where it
appears to imply (to praphrase) that mandatory to mplement has been
removed because we can't keep up.

That is a very rough paraphrasing. Here are the exact words:
   The specification of suites that MUST and SHOULD be supported for
   interoperability has been removed from this document because they are
   likely to change more rapidly than this document evolves.

   An important lesson learned from IKEv1 is that no system should only
   implement the mandatory algorithms and expect them to be the best
   choice for all customers.

This can be quite happily be read as
'removed to the bit bucket'. As it stands a naive reader might conclude
that he can't guarantee much at all since there are no pointers to where
the list  has been removed *to*.

Fully agree. The lack of pointers to where the list might be was fully 
intentional in RFC 4306, and this proposed update to 4306 does not change that.

This is the master specification for IKE if I understand correctly.

Not at all. It is the specification for the IKEv2 protocol. There is no "master 
specification" of IKEv2 because there are numerous extensions and profiles of 
IKEv2 that have already come out, and more are expected to. This is where this 
thread overlaps with draft-ogud-iana-protocol-maintenance-words. It sounds like 
want a "master specification" a la newtrk (@#$%), and given that this is the 
base protocol spec, you want that to be in this document.

 It
had better say that there MUST always be some mandatory to implement
algorithms, but it is perfectly legitimate to hand of the listing of
those to some other RFC that is less onerous to update.

If this draft "had better" say that, then RFC 4306 should have as well for the 
past 4+ years. It has not. Given that this is the first time we have heard such 
a demand, maybe the need for this linkage is overstated. I agree that not all 
IKEv2 implementers have found RFC 4307 and RFC 4308 easily, or at all. That has 
not hampered interoperability, as can be seen at 
<http://www.vpnc.org/testing.html#IKEv2BasicInterop> and other places.

 It would be IMO
a good idea (as is done with all the rafts of updateable lists) to link
to the starting points of the chain of documents that tells an
implementer what are currently the required  protocols by referencing
RFC 4307 and RFC 4308, but again reminding us that there maybe heirs and
successors.

This is *not* done in all the drafts of updateable lists in the IETF: it is 
done on some of them. The IETF still has no consistent guidance on this, and 
there are plausibly successful examples of different styles of RFCs.

So easy enough to solve.

I know of no survivors of newtrk (@#$%) who would agree with that statement.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>