Paul Hoffman writes:
> At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote:
> >Given the amount of interest on the list, I prefer the "do nothing"
> approach. 
> 
> That makes no sense. People seem interested in fixing the problem of
> the lists being confusing. 

I agree that we should do something. 

> There is nothing confusing about removing the assigned numbers: it
> only causes a developer who is actively coding at the moment to grab
> one file from IANA. That file will contain all of the values needed
> for developing from IKEv2bis (including the two new values we are
> assigning), and will also contain values and pointers for other
> extensions in which they might be interested. 

Not only those who are coding, but also those are debugging or
supporting implementations, as quite often they do not remember all
the numbers or the packet formats exactly, so they use the RFC to
check out the packet formats and numbers, and only if numbers are not
there then they need to go to IANA. 

> Removing the assigned numbers also causes people who will be
> expanding on IKEv2bis to actually fetch the IANA registry before
> they do their work. We have a recent example of why that would be
> useful. 

I do not think this would have caused anything, as I most likely would
have also picked numbers 40, and 41 anyways because I remember that 39
was last number used in RFC4306... There is reason why there is IANA
assignment phase in the RFC assignment process, so there was no harm
done even when someone took some numbers instead of using TBA1 and
TBA2.

If we split this to three parts:

1) I think almost everybody can agree that we can remove RESERVED and
   PRIVATE use ranges and numbers from the all tables, and add notice
   saying these are partial lists and go and check IANA for full list.

2) I think quite a lot of people agree that we should remove algorithm
   tables i.e ENCR_*, PRF_*, AUTH_*, Diffie-Hellman groups, extended
   sequence number tables and IPCOMP_*, i.e. all Transform type 1-5
   tables and IPCOMP transform ID table from the RFC.

3) The thing we do not all agree on is whether to keep the numbers for
   the rest of the tables. I.e. do we want to remove numbers from rest?

I myselfo would say yes for 1, and 2, and no for 3. 
-- 
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to