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
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
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
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
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
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. Those values
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 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
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 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
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 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 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
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 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
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 URL', 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 08:37:32PM -0500, Dan McDonald wrote: SNIP! 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
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 URL', 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 URL'). 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
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
