Hi, let me pop into with my 2 cents.

As an implementer, I strongly dislike an idea to remove all the numbers from
the RFC.
In my opinion, that would confuse people even more than now, for the
following reasons:

1. Magic numbers would become splited between two sources (note, that not
all of them
    are listed in IANA, for example payload types are, but Proposal and
Transform
    substructures types are not, they are specified in the RFC only).

2. IANA registry already contains some very specific entries (like, for
example,
    those that came from RFC4595) and their number will be increasing. I
think,
    those numbers would confuse some implementers, who might be thinking
    that they need to support all of them.

3. Sometimes there might be difficulties in matching names from RFC with
IANA entries.
    For example, IANA registry has an entry named ENCR_AES-CCM_8, but in
    RFC5282 this algorithm is called AEAD_AES_128_CCM_SHORT_8. Are you sure
    these names reference the same algorithm? I prefer to check their IDs in
RFC
    and in IANA registry.

4. Some entries in Diffie-Hellman Group Transform IDs table do not really
assign
    individual numbers, but instead point to other documens, even to RFC4306
itself,
    where the numbers are assigned.

By the way, some magic numbers in RFC4306 are present not only in tables,
but
in text also (for example Payload Types, TS Types). Do they need to be
removed
from text also? What about EAP Message format and magic numbers?
Remove and just reference RFC3748 (or IANA entry for EAP)?

I think, removing all magic numbers from the RFC would make implementing
less convinient and more error-prone, so I strongly support either "do
nothing"
approach, or Tero's suggestion. Those numbers won't change, so their
presence must not hurt, just will make implementing of base protocol more
convinient.

Regards,
Smyslov Valery.



----- Original Message -----
From: "Paul Hoffman" <paul.hoff...@vpnc.org>
To: "IPsecme WG" <ipsec@ietf.org>
Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis


> 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.
>
> 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.
>
> 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.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to