Hi Paul,
please, see inline.
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.
If a developer does not know how to read the IANA tables, we are all in
trouble. Nothing in the tables says you must implement every thing in
these tables, of course.
Are you proposing that we get rid of the IANA registry altogether, or we
hide it from developers?
Not, of course.
If not, how do you rectify this with your concern about confusion?
For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I
think,
a newcomer could be confused by a long list of all possible numbers.
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.
This is a bug in the IANA registry that needs to be fixed. It is not
related to the values being in the RFC. Tero has spent a lot of time
trying to fix the registry, but clearly we need more effort here. I will
certainly make sure that the names in the registry match those in RFC
4306, and that the exact names are used in IKEv2bis.
For RFC4306 that seems to be true.
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.
Again, I am concerned that you think we should get rid of the IANA
registry. That is not how the IETF works.
No, you didn't get the point. I meant that Diffie-Hellman Group Transform
IDs table
in two cases doesn't assign individual numbers, just ranges. For example:
1-2 Defined in Appendix B [RFC4306]
14-18Defined in [RFC3526] [RFC3526]
So, in first case it just points back to RFC4306 Appendix B, where the
actual
numbers (what is 1 and what is 2) are assigned. Probably it may (and must)
be changed, but in its current form it's ridiculos - you went to IANA for
real numbers and have found only pointer back to RFC4306 where you
just have come from...
What about EAP Message format and magic numbers? Remove and just
reference RFC3748 (or IANA entry for EAP)?
No, those were left in because they came from an RFC, not from a
particular IANA registry where the names match what we have in IKEv2bis.
EAP numbers listed in RFC4306 might also be changed in future,
so from your logic it's better just to point to
http://www.iana.org/assignments/eap-numbers, right?
I think, removing all magic numbers from the RFC would make implementing
less convinient
Yes.
and more error-prone
No.
I don't agree with you. Remember, when IKEv2 was being developed,
one of the motivations for single self-contained document was complaint
from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
was very inconvinient and provoked confusions that led to interoperability
problems. Now you suggest to make IKEv2 not self-contained again.
Of course, I understand that IANA registry is not another RFC, but
I still prefer single self-contained document for core protocol.
If you need extensions - go to IANA and look for added numbers,
but core protocol must be implementable reading as few sources,
as possible, preferrably one.
, so I strongly support either do
nothing
approach, or Tero's suggestion.
This is completely inconsistent. Tero's approach would lead you to need
the IANA registry to implement IKEv2.
Tero's approach is a compromise. You will need the IANA only for
few types of magic numbers, most of which don't affect protocol
logic. I can leave with it.
Those numbers won't change, so their
presence must not hurt,
This is probably incorrect. In many WGs, when errors are found in old
definitions, the error is corrected *and a new value is assigned*. That is
the only way to assure interoperability.
As far as I understand, in this case new RFC must be issued,
which will obsolete current one, won't it? If so, no contradiction.
just will make implementing of base protocol more
convinient.
The goal of our work is clarity and interoperability, not convenience,
particularly when the inconvenience is remedied by one extra lookup.
Just out of curiosity: is such approach (removing magic numbers from RFC
completely) widely used in IETF? If memory serves me, all RFC I've read
contained their magic numbers (of course they were duplicated in IANA)
and that didn't lead to interoperability problems, I think. What is an
origin
for your conclusion that this practice leads to
