Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman wrote: > - Add [IKEV2IANA] to the Normative References; it will point to the > URL of the IANA registry. I don't like the idea of splitting the normative content of RFC 4306 to two different places. An informative reference would be very useful (and probably some of the tables may contain stuff that could be just removed). But if I'm writing code to send an IDi payload of type ID_FQDN, the numbers for "IDi" and "ID_FQDN" should be in this RFC (either somewhere near the text that describes IDi and ID_FQDN, or in a table -- that doesn't matter very much). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
>> 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. > >I completely agree on that. I also agree with Valery and Tero. Dave Wierbowski ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Valery Smyslov writes: > >> 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? This is good example of confision what happens when you point to external iana registry. In RFC4306 we have "Nak (Response only)". If you look to the iana registry for eap, you cannot find that one. You do find "Legacy Nak". Are those two same? As both tables have also the number 2 associated to the code, you know they are same. Reading RFC3748 you notice that it uses both "Nak" and "Legacy Nak". > 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. I completely agree on that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman writes: > 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. Then we are already in trouble. There is lots of developers who do not know about the IANA tables, they just grab the RFCs (without knowing about the IETF) and start to implement them. Not all developers follow IETF work, and quite a lot of developers do not know how IETF work, and what is the relation between IETF and IANA and so on. Also I do not think developers NEED to know the this kind of things, it should be enough for them to grab the documents and implement them. I do not think it is mandatory for them to understand what different IANA registration procedures mean. There is also lots of developers who do not know the difference between Informational RFC and Standard track RFC, and if they see numbers in the IANA registry they will think they should implement all of them. > I am now deeply concerned with this WG's relationship to the IANA > registry. We are not talking about the developers who are working on this WG. The whole world is not this WG, there is other people out there. Also I myself do find extra unnecessary indirections very annoying, and if possible, I try to avoid those. > >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 really a bug in IANA registry, as RFC4106 use those names, and it did allocate them. It is bug in the RFC5282, which should have used the same names for the same algorithms. On the other hand the rfc5282 do have table mapping the names it uses to the ENCR identifier numbers, and it DOES NOT have IANA actions for the Encryption Transform identifiers table, as those numbers have already been allocated before. > 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. On of the problems is the RFC4106 which predates IKEv2, which means it used completely different naming scheme than what was used in the rest of the documents, i.e. their algorithms do not have ENCR_* format, but is just text. I do not think we change that anymore. > >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. I do not think anybody proposed to get rid of the IANA registry. I think everybody agreed that yes, we should have pointer to the IANA registry. But as those numbers are never going to change, they should also be listed here. > >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. Which means they existing numbers are not going to change. There may be new numbers meaning almost same thing (but with fixed semantics), but the old number can only mean exactly what was meant at the time the RFC was written. > >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. Extra lookup which WILL cause more bugs, which means implementations are not interoperable. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
> >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". > > We still agree, and your answer is still inconsistent. If you worry about > those type of developers, then you must want to get rid of the IANA registry, > because that is what is giving them the silly ideas. No, I didn't mean that. I meant that the simpler description of the protocol is, the better implementation is (usually) developed by an average person. In this context adding one more step in the process of developing may (and, I think, will) lead to increasing number of non-ineroperable implementations. I suspect, you may get just the opposite results than you expects. > >I fail to understand how removing values from the RFC will help > >understanding the context for them. > > The context for the values is "they are assigned and maintained by IANA". > It is not "they came from this RFC". You may not like that, but that's how the IETF works. IANA doesn't assign any number by its own will - there must be request for that number and a corresponding RFC. And if this is a change to existing number, then this new RFC must either update base RFC or make it obsolete. Is it right? And even laziest developer will start implementing from finding the most recent RFC, updates and errata. > >It's not hard, but what for? I see some drawbacks and I don't see > >how it will help interoperability. > > Again: it helps interoperability if developers look in the IANA registry at the time > of coding and see changes have been made to what they thought was true based > only on reading an RFC. Those changes don't come from IANA itself, they come from updating RFC. And it is this RFC, which developer starts implementing from, not IANA. And only after finding this RFC he/she will usually go to IANA. And making changes to already assigned values must be as rare as possible, because it automatically makes existing implementations non-compliant. On the other hand, adding new values usually doen't affect base protocol. > >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. > > The IANA registry lists the current RFCs. Do you not think that is enough clue? No. RFC Editor Search Engine gives much more information regarding current status of RFC, existence of updates and errata. IANA is best for looking for protocol extensions, but it gives only current snapshot of the situation. If some values were changed, IANA wouldn't keep old references, and if you want to keep your product interoperable with previous versions, IANA won't help you. And if you remove number values from RFC, keepeng new products interoperable with previous in case of changing some assigned values will become next to impossible - you just will have no sources for old numbers. Regards, Smyslov Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 12:19 AM +0300 11/30/09, Valery Smyslov wrote:
>>>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".
We still agree, and your answer is still inconsistent. If you worry about those
type of developers, then you must want to get rid of the IANA registry, because
that is what is giving them the silly ideas.
>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]
Sorry, I misunderstood what you were saying. Yes, that is a good suggestion;
I'll make it happen.
>>>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.
I do not presume that. I presume that this WG is not concerned about it;
otherwise, we would have created our own IANA registry for the EAP values we
use. We didn't.
>I fail to understand how removing values from the RFC will help
>understanding the context for them.
The context for the values is "they are assigned and maintained by IANA". It is
not "they came from this RFC". You may not like that, but that's how the IETF
works.
>>>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.
Again: it helps interoperability if developers look in the IANA registry at the
time of coding and see changes have been made to what they thought was true
based only on reading an RFC.
>>>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.
Your second paragraph is a shining example of why this should have been done in
RFC 4306, and why we should not presume that what we do in IKEv2bis will be
held constant.
>>>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 mu
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
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-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...
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 TypeNotation Reference
--- - -
0 No Next Payload [RFC4306]
1-32 Reserved [RFC4306]
33-48 Defined in [RFC4306][RFC4306]
49-127Unassigned [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. Thos
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 11:11 PM +0300 11/27/09, Valery Smyslov wrote:
>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.
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.
>>>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...
These are the full definition of the semantics of the groups. How would you
change this?
>>>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?
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 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.
Correct.
>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.
>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.
>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.
>>>, 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.
This seems inconsistent to me ("it's OK to need a second file for some things
but not others").
>>>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 a
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
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
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 11:42 AM +0300 11/27/09, Valery Smyslov wrote: >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). This is incorrect. The proposal is to remove the value numbers from the tables, not the figures that contain the substructures. Anything that is only in the RFC would obviously not be removed. >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? If not, how do you rectify this with your concern about confusion? I am now deeply concerned with this WG's relationship to the IANA registry. >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. >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. >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? Yes, in my current draft, I already did that, and repeated the boilerplate. > 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. >I think, removing all magic numbers from the RFC would make implementing >less convinient Yes. >and more error-prone No. >, 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. >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. >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. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
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
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
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" To: "IPsecme WG" 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
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
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Given the amount of interest on the list, I prefer the "do nothing" approach. Just add this text somewhere (maybe multiple times): This table is (these tables are) only current as of the publication date of RFC 4306. Other values may have been added since, or will be added after the publication of this document. Implementors are advised to refer to [IANA] for the latest values. And be done with it. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Paul Hoffman > Sent: Thursday, November 26, 2009 19:11 > To: Tero Kivinen > Cc: IPsecme WG > Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from > IKEv2bis > > At 1:25 PM +0200 11/26/09, Tero Kivinen wrote: > >Paul Hoffman writes: > > > - Remove the numbers from every table > > > >I would rather keep the numbers for those tables which are really > >needed for implementing the protocol. > > And here we disagree completely. > > >I hate when I am implementing something and reading the RFC, and then > >suddenly I notice that I need to go and fetch some url somewhere to > >find the actual numbers, even worse when I am doing that in airplane > >or similar where I do not have network connectivity... > > In this case, you only need to fetch a single page from IANA for all the > tables. If you did that for any of the tables, you would have it for all > of them. > > It does not feel appropriate to optimize for the case of someone coding > IPsec without Internet access for a few hours. > > --Paul Hoffman, Director > --VPN Consortium > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 1:25 PM +0200 11/26/09, Tero Kivinen wrote: >Paul Hoffman writes: > > - Remove the numbers from every table > >I would rather keep the numbers for those tables which are really >needed for implementing the protocol. And here we disagree completely. >I hate when I am implementing something and reading the RFC, and then >suddenly I notice that I need to go and fetch some url somewhere to >find the actual numbers, even worse when I am doing that in airplane >or similar where I do not have network connectivity... In this case, you only need to fetch a single page from IANA for all the tables. If you did that for any of the tables, you would have it for all of them. It does not feel appropriate to optimize for the case of someone coding IPsec without Internet access for a few hours. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman writes: > Based on Tero and Yaron's responses, I have a different idea: > > - Leave all the tables in I think the encryption, hash algorithm etc tables could be removed completely, i.e. the Transform type n tables in section 3.3.2. Those tables change quite often, and they are not really needed for implementation, as almost every implementation will anyways only implement some of those, and/or offer a way to easily add new algorithms when those come. > - Removed the "reserved", "reserved to IANA", and "private use" lines > - Precede each table with the following boilerplate paragraph: >The following table only lists the entries that appeared >in [IKEV2]. There may be new entries, private use values, >and so on; see [IKEV2IANA] for up-to-date information. > - Add [IKEV2IANA] to the Normative References; it will point to the > URL of the IANA registry. These all are ok for me. > - Remove the numbers from every table I would rather keep the numbers for those tables which are really needed for implementing the protocol. I hate when I am implementing something and reading the RFC, and then suddenly I notice that I need to go and fetch some url somewhere to find the actual numbers, even worse when I am doing that in airplane or similar where I do not have network connectivity... Usually I assume that if I need to implement RFC, I should be able to do it mostly by using just that RFC or some other RFCs. This is not true always as there are references to the crypto algorithms found in textbooks, or standards defined by other bodies, but here I do not think there is reason to require using external reference. The numbers that are there in the tables are not going to change, so they will not get outdated, they will not get to be wrong. There might be new ones added, and the warning you propose should take care of that. If there would be an possiblity that for example Exchanget type IKE_AUTH could change from its current value of 35 to something else, then I would agree leaving it out from the RFC, but as it is going to be that same number forever, I do not see any reason why I should use indirection to find out what that number is. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
On Wed, Nov 25, 2009 at 08:39:08AM -0800, Paul Hoffman wrote: > - Add [IKEV2IANA] to the Normative References; it will point to the URL of > the IANA registry. Yes, this is better. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Based on Tero and Yaron's responses, I have a different idea: - Leave all the tables in - Remove the numbers from every table - Removed the "reserved", "reserved to IANA", and "private use" lines - Precede each table with the following boilerplate paragraph: The following table only lists the entries that appeared in [IKEV2]. There may be new entries, private use values, and so on; see [IKEV2IANA] for up-to-date information. - Add [IKEV2IANA] to the Normative References; it will point to the URL of the IANA registry. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman writes: > Yes, I should have worked this out more fully before posting. > > In all cases, I would add a reference to the IANA registry. > > Only lists code points: remove the whole table > 2.22: IPComp Tranform IDs > 3.3.2: Encryption, PRF, integrity, DH group, ESN I can agree removing those whole tables. > 3.1: Exchange types > 3.3.1: Protocol ID > 3.3.5: Transform attributes > 3.15: CFG type These I would leave in, but remove the RESERVED, RESERVED TO IANA and PRIVATE USE lines, i.e. leave only the values used in this document. These are needed when developing the protocol, and having yet another indirection there would just be annoying developers. > Lists semantics, remove the code points but leave the semantics: > 3.5: Identification types > 3.10.1: Notify messages > 3.13.1: Traffic selectors I would keep values for those too, but remove RESERVED/PRIVATE etc ranges, i.e. keep numbers needed to implement this protocol (and referenced by this RFC), but by removing the reserved and private use range definitions, it makes it clear this is not full list, so if someone wants to see full list, they need to go to the iana-registry. And I would move these to the same category: > 3.2: Next payload type -- remove value > 3.3.2: Transform type -- remove type number > 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED > 3.15.1: Attribute types -- remove type number I.e. leave number. > 3.3.3: Transform types by protocol -- leave in whole table This I agree :-) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Hi Paul, I have marked below with an asterisk those that I think should stay in the document, because they are important to understanding/implementing the protocol. Overall, I'm not sure this exercise is worth our time. In particular if we strip tables of their values, there's a high risk of introducing inconsistencies between the document and the IANA registry. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, November 24, 2009 19:31 > To: IPsecme WG > Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from > IKEv2bis > > Yes, I should have worked this out more fully before posting. > > In all cases, I would add a reference to the IANA registry. > > Only lists code points: remove the whole table > 2.22: IPComp Tranform IDs > 3.1: Exchange types [*] > 3.3.1: Protocol ID [*] > 3.3.2: Encryption, PRF, integrity, DH group, ESN > 3.3.5: Transform attributes [* ??] > 3.15: CFG type [*] > > Lists semantics, remove the code points but leave the semantics: > 3.5: Identification types > 3.10.1: Notify messages > 3.13.1: Traffic selectors > > Other: > 3.2: Next payload type -- remove value > 3.3.2: Transform type -- remove type number > 3.3.3: Transform types by protocol -- leave in whole table > 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED > 3.15.1: Attribute types -- remove type number > > > --Paul Hoffman, Director > --VPN Consortium > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Yes, I should have worked this out more fully before posting. In all cases, I would add a reference to the IANA registry. Only lists code points: remove the whole table 2.22: IPComp Tranform IDs 3.1: Exchange types 3.3.1: Protocol ID 3.3.2: Encryption, PRF, integrity, DH group, ESN 3.3.5: Transform attributes 3.15: CFG type Lists semantics, remove the code points but leave the semantics: 3.5: Identification types 3.10.1: Notify messages 3.13.1: Traffic selectors Other: 3.2: Next payload type -- remove value 3.3.2: Transform type -- remove type number 3.3.3: Transform types by protocol -- leave in whole table 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED 3.15.1: Attribute types -- remove type number --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman writes: > This has flummoxed a few reviewers. Tables such as those in section > 3.3.2 are already out of date because things have been added since > RFC 4306. I propose that we remove all these tables from IKEv2bis, > and add notes pointing to the current IANA registries. I cannot see > how doing this lookup will hurt developers: in fact, it forces them > to actually look at the up-to-date tables. I can see how we might > want to leave the tables in, but it really is confusing. I would be in favor of removing the tables which are updated frequently, but I think most of the tables should still stay in the IKEv2bis. For example I think IKEv2 exchange types, Next Payload Types, Protocol ID, Transform type values etc should stay, but for example tables like Transform type 1 (Encryption Algorithm) could point to the IANA registry. I.e if table is integral part of the protocol, then it should stay in the IKEv2bis document, but if it is something like listing of crypto algorithm etc, then it can be changed to point to the IANA registry. Mostly that means that if the IANA registry has some other RFC(s) as reference for the values in the registry (ENCR_3DES points ot RFC2451 etc, PRF_HMAC_MD5 points to RFC2104) then it it is useful to put references to the IANA registry. On the other hand if only references in the IANA registry is back to the RFC4306 (or IKEv2bis document in future), then its bit pointless to ask people to go to the iana registry to see that they should read this document they are reading to get more information :-) For examples of such registries are Next Payload Type, Transform Type Values, IKEv2 Transform Attribute Types, IKEv2 Identification Payload ID Types, IKEv2 Certificate Encodings... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Typically IETF specs don't require someone implementing RFC to actually find and read the IANA registry -- all the needed numbers are in the RFC. (The IANA registry is just an IETF process tool for making sure the same number doesn't get used for multiple purposes, not part of the actual protocol specification.) Perhaps the "reserved to IANA: 12-200" etc. lines are slightly confusing, and we could omit them (and say something like "this document specifies the meaning of these values; to find what values are specified in other documents, go look at the IANA registry") Best regards, Pasi > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of ext Paul Hoffman > Sent: 24 November, 2009 02:37 > To: IPsecme WG > Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis > > This has flummoxed a few reviewers. Tables such as those in section > 3.3.2 are already out of date because things have been added since RFC > 4306. I propose that we remove all these tables from IKEv2bis, and add > notes pointing to the current IANA registries. I cannot see how doing > this lookup will hurt developers: in fact, it forces them to actually > look at the up-to-date tables. I can see how we might want to leave the > tables in, but it really is confusing. > > --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
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Hi Paul, Please add to Issue #123 a list of the affected tables. For example, I wouldn't imagine the list of notification types moving away, even though it's already been extended by IANA. Similarly for the stuff in Sec. 3.6, which is strongly related to descriptive text. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Steven Bellovin > Sent: Tuesday, November 24, 2009 5:20 > To: Paul Hoffman > Cc: ipsec@ietf.org; Dan McDonald > Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from > IKEv2bis > > > On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote: > > I *really* don't think it is that hard for a developer to resolve a URL > and read the tables there. > > > Leave out the table; give the URL and mention 4306. If you have two more- > or-less authoritative sources for the same information, some folks will > use one and some the other. Point to the URL as *the* source, and say > that it subsumes all values given in 4306. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote: > I *really* don't think it is that hard for a developer to resolve a URL and > read the tables there. Leave out the table; give the URL and mention 4306. If you have two more-or-less authoritative sources for the same information, some folks will use one and some the other. Point to the URL as *the* source, and say that it subsumes all values given in 4306. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 8:37 PM -0500 11/23/09, Dan McDonald wrote:
>On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
>> >Can you move 'em to an appendix, with a permanent URL reference to the IANA
>> >up-to-date versions?
>>
>> As long as you mean "an appendix that clearly says 'these were in RFC 4306
>> but are now out-of-date but are here just for reference and you want to
>> look at '", I'm OK with that as well.
>
>I'd actually go one better -- snapshot what's on IANA today (or the day
>before RFC-editor pulls the switch) with the warning you quote ('... just
>for reference and you want to look at '). The warning and URL is the
>critical part.
Oh, yuck. No. I could see doing this to keep the "bis" nature of the document
intact by providing the old tables, but not creating a clone of the IANA
registry. I *really* don't think it is that hard for a developer to resolve a
URL and read the tables there.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote: > The warning and URL is the critical part. "are the critical part," - uggh, mustn't press Send so quickly. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
> >Can you move 'em to an appendix, with a permanent URL reference to the IANA
> >up-to-date versions?
>
> As long as you mean "an appendix that clearly says 'these were in RFC 4306
> but are now out-of-date but are here just for reference and you want to
> look at '", I'm OK with that as well.
I'd actually go one better -- snapshot what's on IANA today (or the day
before RFC-editor pulls the switch) with the warning you quote ('... just
for reference and you want to look at '). The warning and URL is the
critical part.
Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 8:12 PM -0500 11/23/09, Dan McDonald wrote: >On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote: > >> This has flummoxed a few reviewers. Tables such as those in section 3.3.2 >> are already out of date because things have been added since RFC 4306. I >> propose that we remove all these tables from IKEv2bis, and add notes >> pointing to the current IANA registries. I cannot see how doing this lookup >> will hurt developers: in fact, it forces them to actually look at the >> up-to-date tables. I can see how we might want to leave the tables in, but >> it really is confusing. > >Can you move 'em to an appendix, with a permanent URL reference to the IANA >up-to-date versions? As long as you mean "an appendix that clearly says 'these were in RFC 4306 but are now out-of-date but are here just for reference and you want to look at '", I'm OK with that as well. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote: > This has flummoxed a few reviewers. Tables such as those in section 3.3.2 > are already out of date because things have been added since RFC 4306. I > propose that we remove all these tables from IKEv2bis, and add notes > pointing to the current IANA registries. I cannot see how doing this lookup > will hurt developers: in fact, it forces them to actually look at the > up-to-date tables. I can see how we might want to leave the tables in, but > it really is confusing. Can you move 'em to an appendix, with a permanent URL reference to the IANA up-to-date versions? Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
This has flummoxed a few reviewers. Tables such as those in section 3.3.2 are already out of date because things have been added since RFC 4306. I propose that we remove all these tables from IKEv2bis, and add notes pointing to the current IANA registries. I cannot see how doing this lookup will hurt developers: in fact, it forces them to actually look at the up-to-date tables. I can see how we might want to leave the tables in, but it really is confusing. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
