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.
This answer is inconsistent, and that's the crux of the issue I have with
your
concern. We very much want developers to look at the IANA registry;
it's the only way for them to know definitively what values will cause
interoperability. Yet you say things like "a newcomer could be confused
by a long list of all possible numbers". You can't have it both ways.
You probably speaks about "ideal" developers. I speak about real people.
I've seen a few cases when people implemented a bunch of really
unnecessary things just because "it was in standard".
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-18 Defined 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...
These are the full definition of the semantics of the groups. How would
you change this?
Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not
defined in IANA.
For me this is inconsistent. Either change two abovementioned lines to:
1 768-Bit MODP Group [RFC4306]
2 1024-Bit MODP Group [RFC4306]
14 2048-Bit MODP Group [RFC3526]
15 3072-Bit MODP Group [RFC3526]
16 4096-Bit MODP Group [RFC3526]
17 6144-Bit MODP Group [RFC3526]
18 8192-Bit MODP Group [RFC3526]
or, if you think that current situation is OK, then why no to change other
tables
in the same fashion and leave all numbers in the RFC. Just for example:
Value Next Payload Type Notation Reference
-------- ------------------------------- --------- ---------
0 No Next Payload [RFC4306]
1-32 Reserved [RFC4306]
33-48 Defined in [RFC4306] [RFC4306]
49-127 Unassigned [RFC4306]
128-255 Private use [RFC4306]
At least this will made things consistent.
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?
Yes, but *only* if the names and numbers we use in this document match
those exactly
*and* the WG is willing to cede change control to the EAP methods we use
to the IANA
registry that we do not have input to. So far, the WG hasn't said they
want to do that,
so I don't presume to make that change.
I fail to understand your logic here. You seem to want to have ability to
change
already assigned numbers in IKEv2 in the future (and for this purpose remove
them from RFC), but at the same time you seem to presume that other
groups will not ever change their numbers. By the way, at least one RFC
outside
ipsecme WG (I mean RFC5106, EAP-IKEv2) has already listed some of IKEv2
magic numbers (payload types) and has already presumed that they won't
change.
Now you suggest to make IKEv2 not self-contained again.
Correct, because we have already made many changes to the values that
developers need to know.
Those new values could be listed in IKEv2bis RFC, which will update RFC4306.
Of course, I understand that IANA registry is not another RFC, but
I still prefer single self-contained document for core protocol.
Of course, but your preference is at odds with the preference of someone
reading the document needing to understand the context for the values.
I fail to understand how removing values from the RFC will help
understanding the context for them.
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.
Seriously: how hard is "two"? Any serious developer can go look at
a second URL to get the values.
It's not hard, but what for? I see some drawbacks and I don't see
how it will help interoperability.
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.
This seems inconsistent to me ("it's OK to need a second file for some
things but not others").
I didn't say I like it. I said I can bear it. Tero has suggested removing
values for Transform IDs only. Those values mostly are "external" to
IKEv2 logic, it just "transfers" them between network, policy module,
ipsec module and crypto module. Theoretically they should not affect
IKEv2 itself (*). That's why I can bear removing them.
(*) Unfortunately, they do affect: AEAD algorithms require special
handling in construction proposals. But this is another story.
I've been thinking that introducing a new Transform type for
AEAD algorithms instead of reusing Encryption Algorithm Transform
would probably have made protocol simpler and cleaner, but that was that.
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.
That is not true. The new RFC can update just a portion of the old one.
That is how this is normally handled in the IETF.
In any case base RFC will be updated. And the first thing one must do before
implementing any protocol is to find most recent RFC for it, including
all updates and erratas. This is natural way to go, and if one starts
implementing old RFC, then even if you manage to force him to go
to IANA for numbers, I doubt if he will get interoperable product.
Just out of curiosity: is such approach (removing magic numbers from RFC
completely) widely used in IETF?
I do not know if our situation has ever happened in the IETF for a major
protocol.
I will ask around and report back on that.
OK, thank you.
Regards,
Smyslov Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
