RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Paul Hoffman wrote: Why not? As long as the reader of the IANA registry can ascertain which codepoint owner is at a particular level, how would that affect interop? Being able to ascertain what the level is isn't enough; you also need to know (and more importantly, care) about the differences in the levels :-) I'd say there are lot of implementors who don't really care that much for the distinctions between an individual Internet-Draft, a WG draft, an Experimental RFC, or Proposed Standard RFC. But if only the latter two (or three) would have proper numbers in them (instead of TBD-BY-IANA), that would send a clear message that this not ready yet... (but of course, this doesn't always work; if there's strong enough pressure to implement, people will invent some numbers there) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
At 12:10 PM +0300 6/15/07, [EMAIL PROTECTED] wrote: Paul Hoffman wrote: Why not? As long as the reader of the IANA registry can ascertain which codepoint owner is at a particular level, how would that affect interop? Being able to ascertain what the level is isn't enough; you also need to know (and more importantly, care) about the differences in the levels :-) I'd say there are lot of implementors who don't really care that much for the distinctions between an individual Internet-Draft, a WG draft, an Experimental RFC, or Proposed Standard RFC. Fully agree. Where we disagree is whether or not the IETF should do something about that more than just saying what our levels are and what they mean. I believe that needs to be sufficient, and our energies are best spent on our standards efforts. But if only the latter two (or three) would have proper numbers in them (instead of TBD-BY-IANA), that would send a clear message that this not ready yet... (but of course, this doesn't always work; if there's strong enough pressure to implement, people will invent some numbers there) Enforcement of our standards process by hiding things that are outside of the process seems both dishonest to, and disrespectful of, typical developers. That does not lead them to the type of interoperability we want. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints
On 2007-06-13 16:37, Jari Arkko wrote: Phillip, My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. ... So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted. I'm definitely in favor of improving the situation. And for applications protocols this is probably an easier problem to begin with. And as I said in the previous e-mail, as far as I know, most new work uses field sizes and types that have less scarcity. However, the Internet runs to a large extent on protocols that were designed decades ago, and some of those protocols have number spaces that are very finite. I don't want to run out of protocol numbers, DHCP message types, etc. Exactly. There are very tight namespaces where we need to apply pretty strict rules to avoid hitting a brick wall, but nobody can disagree that we should design to avoid creating new brick walls. But in the namespaces where there is no brick wall, there are nevertheless reasons to be careful. I'd suggest that people should not only look at the text of 2434bis, but also at RFC 4775 and at draft-carpenter-extension-recs-02.txt. Comments on the latter are very welcome. I don't believe we should do anything that can be interpreted as condoning misappropriation of IANA-assigned values. But I do agree with John Klensin that when something is in actual use, that fact should be recognized, and registered with a factual comment. That helps interoperability even if it offends our formalities. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
At 7:27 AM +0300 6/14/07, [EMAIL PROTECTED] wrote: I think giving out codepoints freely would in many cases encourage having multiple (often half-baked) solutions to the same problem. This is the crux of the issue. Does the IETF want to control bad ideas through the IETF process *and* the IANA registry, or just the IETF process? You are proposing the former, I am proposing the latter. I trust that the IETF process works fine and doesn't need a backup crutch from IANA. I also trust that developers who look in the IANA registry and see four entries, one of which is an RFC and three of which are URLs to individuals and corporate web sites, to be able to make the right decision about what they want to implement. I'm not saying that this particular cooperation would not have happened with less strict IANA policies -- but I do believe that if the bar for getting codepoints and publishing an RFC would be significantly lower than today, we would have a much larger number of poorly concieved and overlapping extensions to various IETF protocols. Fully agree. But we're not talking about lowering the bar to publishing RFCs, only to registering codepoints. (And IMHO that would not always be interop-neutral.) Why not? As long as the reader of the IANA registry can ascertain which codepoint owner is at a particular level, how would that affect interop? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
I am more concerned with timing. All protocols are experimental when they are started. If I need to go through a three year process before I can get the number I need assigned to start my experiment, well I am not going to, an nor is anyone else. That is why I would draw the boundary between layers 6 and 7. Experiments at layer 5 are likely to have rather more serious consequences than at layer 7. This is fortunate since the vast majority of experiments people want to perform are at the application level. On the 'misapropriation' issue, I think that it is important that people understand that nobody owns the Internet and nobody can own it. Just because the IETF won the global data design competition in the 1990s does not mean that it has perpetual ownership of it. IBM once assumed that it owned the PC standard, turns out it did not. That is not the same as saying that it is impossible for IANA to exercise control or that the IETF should not attempt to exercise control in certain areas. What it means is that the IETF needs to be very careful in the areas where it attempts to exercise influence and even more careful in the areas where it attempts to exercise control. The comment I would make on the draft is that it does not differentiate between the protocol layers. What I would like to see the IETF produce is the type of 'software contract' Tony Hoare suggested a software module should present to its environment. I would like to reduce certain types of registration to essentially filling in a Web form. So for example someone who has a new crypto algorithm enters the details into a form which spits out algorithm identifiers. In that case I would really want to avoid publishing an RFC of any type or have the authors be able to make any claim to have been involved in IETF process since 99% of the time the algorithm will be junk. The main use here would be for application layer protocols. I want every protocol to be assigned an identifying SRV prefix and URI at the earliest possible moment. The documentation can follow. If it is necessary to impose some sort of velocity controls we could charge for registrations or alternatively have some non-charging velocity control such as require people to get to level 42 on net.rogue. A mechanism that I think would work very well here would be based on social network size with some form of breadth and connectedness constraints. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 3:55 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: IANA registration constraints On 2007-06-13 16:37, Jari Arkko wrote: Phillip, My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. ... So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted. I'm definitely in favor of improving the situation. And for applications protocols this is probably an easier problem to begin with. And as I said in the previous e-mail, as far as I know, most new work uses field sizes and types that have less scarcity. However, the Internet runs to a large extent on protocols that were designed decades ago, and some of those protocols have number spaces that are very finite. I don't want to run out of protocol numbers, DHCP message types, etc. Exactly. There are very tight namespaces where we need to apply pretty strict rules to avoid hitting a brick wall, but nobody can disagree that we should design to avoid creating new brick walls. But in the namespaces where there is no brick wall, there are nevertheless reasons to be careful. I'd suggest that people should not only look at the text of 2434bis, but also at RFC 4775 and at draft-carpenter-extension-recs-02.txt. Comments on the latter are very welcome. I don't believe we should do anything that can be interpreted as condoning misappropriation of IANA-assigned values. But I do agree with John Klensin that when something is in actual use, that fact should be recognized, and registered with a factual comment. That helps interoperability even if it offends our formalities. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawingsponsorship...)
Every protocol begins as a wild idea by one person. So I don't accept John's point. Forcing groups together is not necessarily a good idea. The counter example I would give is SAML, WS-Trust and OpenID. Merging protocols prematurely can be a mistake. The groups have to be speaking the same language for a start. Requiring a merger for standards process is a good idea, usually, but standards are not always the best approach. If you don't yet understand the problem space you should not be wasting peoples time on the standards circuit. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 12:28 AM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: IANA registration constraints (was: Re: Withdrawingsponsorship...) Paul Hoffman wrote: At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote: The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. It does not need to promote interoperability; being interop-neutral is sufficient. How does giving a codepoint to someone with a crazy (and let's say even dangerous to the Internet) idea hurt interoperability? It seems to be interop-neutral. I think giving out codepoints freely would in many cases encourage having multiple (often half-baked) solutions to the same problem. To give one example we both worked on: I think it's good we didn't allocate codepoints to all the individual MOBIKE protocol proposals (mine, Tero's, Francis's), and instead were forced to work together and converge on a single protocol. Probably the market would have eventually picked one of them as the winner, but meanwhile, the situation would IMHO not have been interop-neutral. (And working together also produced a better protocol than any of the individual drafts were.) I'm not saying that this particular cooperation would not have happened with less strict IANA policies -- but I do believe that if the bar for getting codepoints and publishing an RFC would be significantly lower than today, we would have a much larger number of poorly concieved and overlapping extensions to various IETF protocols. (And IMHO that would not always be interop-neutral.) However: I do agree with John Klensin's statement that there is a difference between registering a parameter for a non-standard specification that is already deployed and in successful use and registering one for a wild idea by one person. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
It seems to me that the IANA registry could provide more influence for the IETF if run as Paul suggests. So I go to the code page for the USELESS cipher. It tells me that the cipher has not been approved by the IETF, has not been endorsed by any professional bodies and is not an IETF standard. We would at last have a mechanism to trump the usual claim that an internet draft has been submitted so please consider me as good as being a standard. Or another organization could run the registry. -Original Message- From: Paul Hoffman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 10:46 AM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: IANA registration constraints (was: Re: Withdrawing sponsorship...) At 7:27 AM +0300 6/14/07, [EMAIL PROTECTED] wrote: I think giving out codepoints freely would in many cases encourage having multiple (often half-baked) solutions to the same problem. This is the crux of the issue. Does the IETF want to control bad ideas through the IETF process *and* the IANA registry, or just the IETF process? You are proposing the former, I am proposing the latter. I trust that the IETF process works fine and doesn't need a backup crutch from IANA. I also trust that developers who look in the IANA registry and see four entries, one of which is an RFC and three of which are URLs to individuals and corporate web sites, to be able to make the right decision about what they want to implement. I'm not saying that this particular cooperation would not have happened with less strict IANA policies -- but I do believe that if the bar for getting codepoints and publishing an RFC would be significantly lower than today, we would have a much larger number of poorly concieved and overlapping extensions to various IETF protocols. Fully agree. But we're not talking about lowering the bar to publishing RFCs, only to registering codepoints. (And IMHO that would not always be interop-neutral.) Why not? As long as the reader of the IANA registry can ascertain which codepoint owner is at a particular level, how would that affect interop? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawingsponsorship...)
We would at last have a mechanism to trump the usual claim that an internet draft has been submitted so please consider me as good as being a standard. ULA-C was in a draft that has expired and was in fact specifically dropped by the WG that produced the ULA RFC. Nevertheless, at least one person believes that means ULA-C is as good as being a standard and has asked the RIRs to begin operating a registry for ULA-C addresses. Or another organization could run the registry. Well, if you want a centrally-registered ULA prefix that is globally unique, you can get one from this registry: http://www.sixxs.net/tools/grh/ula/ NOTE: this is not the same as ULA-C, this is a central registry of pseudo-randomnly generated ULAs as defined in RFC 4193. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
Phillip Hallam-Baker wrote in part: On the 'misapropriation' issue, I think that it is important that people understand that nobody owns the Internet and nobody can own it. Just because the IETF won the global data design competition in the 1990s does not mean that it has perpetual ownership of it. Seems like a peculiar version of the actual history of the IETF and of the Internet design. But, let's NOT get into a deep philosophical discuss of what ownership means. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
Seems like a way of saying 'I am going to contradict you without justifying my position in terms that allow me to criticize any request to do so'. -Original Message- From: Bob Braden [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 1:10 PM To: Hallam-Baker, Phillip Cc: Brian E Carpenter; ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: IANA registration constraints Phillip Hallam-Baker wrote in part: On the 'misapropriation' issue, I think that it is important that people understand that nobody owns the Internet and nobody can own it. Just because the IETF won the global data design competition in the 1990s does not mean that it has perpetual ownership of it. Seems like a peculiar version of the actual history of the IETF and of the Internet design. But, let's NOT get into a deep philosophical discuss of what ownership means. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
John C Klensin wrote: To me, the fundamental question here is whether, in the last analysis, we consider it more important to have * the best and most extensive Internet interoperability possible or * a maximum of real or imagined IETF control over all protocols in use on the Internet. We claim to believe the former and then often behave as if we believe the latter. There are also cases when the latter can also promote the former. The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. Or in other words: we do have many proposals for extending IETF protocols whose primary motivation is not solving a real-world need, but rather finding some work for the standardization guys to do (or getting a PhD or something). Those extensions might even get implemented in some sense of the word (anyone can set up a SourceForge project), but are not even meant to be deployed. If by having some control over IANA allocations we weed out of this stuff, I have no problems with it. But I agree that the controls should not be too strict, so that protocols that actually get deployed are able to get the numbers, and are documented as RFCs (but IMHO something stricter that first come first served is usually beneficial). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
Dave and I appear to be in agreement here. I have spent quite a bit of time thinking what the consequences of a default by a registry of the IANA, ISBN, EUI (aka MAC address) type. My conclusion is: virtually nil. Let us imagine that the folk who assign EUI numbers decide that they are not going to allow Iran or North Korea to register a number. This is far from theoretical, in fact it is US law today. The Iranian manufacturer simply announces that they are going to use a particular prefix and starts making ethernet cards. If you are another manufacturer there is simply no way that you are going to accept the unauthorized Iranian assignment. Similar strategies apply to IANA assignments, including assignment of IPv4 address space. It is best if nobody attempts to employ IANA as an Internet choke point, it is not. The issue is unlikely to come up unless the resource being allocated is finite: Port numbers, DNS RR codes, protocol numbers. My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. I think that it is entirely defensible for IANA to be parsimonious with such assignments because they are essentially the fabric of the Internet. Assignment of non-finite identifiers should be a free for all. Anyone should be allowed to apply for a text based label (i.e. algorithm identifier, SRV prefix, ASN.1 OID) at any time with no process whatsoever. Until now we have been dealing with application protocols that almost exclusively deal with the human-machine interaction: Email, Web, FTP, NNTP. Only a handful of protocols are machine-machine. This is changing with Web Services/Mashups/Semantic Web. In the future we are going to see a vast number of machine-machine protocols, only a tiny proportion of which will be standards based. The lack of standards is a good thing, neither the IETF, W3C or OASIS or all three combined is going to have the bandwidth to standardize everything. And unlike human-machine protocols the cost of running multiple machine-machine protocols in parallel is not unacceptable as a general rule. Moreover premature standardization is a bad thing, particularly when nobody really knows what the protocols should be doing. So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted. -Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 11:49 AM To: John C Klensin Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: IANA registration constraints John C Klensin wrote: Again, there may be exceptions, but I think denial cases should require fairly strong (and public) justification. In the general case, I believe the Internet is better off if even the most terrible of ideas is well-documents and registered --with appropriate warnings and pointers-- if there is any appreciable risk that it will be deployed and seen in the wild. Mostly, I think we (the community) tend to confuse the coordination role of registration with the approval role of standardization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints
Phillip, My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. ... So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted. I'm definitely in favor of improving the situation. And for applications protocols this is probably an easier problem to begin with. And as I said in the previous e-mail, as far as I know, most new work uses field sizes and types that have less scarcity. However, the Internet runs to a large extent on protocols that were designed decades ago, and some of those protocols have number spaces that are very finite. I don't want to run out of protocol numbers, DHCP message types, etc. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
That is why I think this is an area that the IAB should look at. I don't think we should be worried about running out of protocol numbers. Deployment of IPv6 and multicast pretty much demonstrate that it is a non-issue. At the application level we just need to persuade people that, no it is not acceptable or sustainable to have an internet architecture that is dependent on parsimonious assignment of IP Port or DNS RR numbers. Where we have a resource code consumption issue we should either declare the protocol essentially closed for extensions or work out a way to introduce a sustainable extension mechanism. So for example on DHCP I think it would be entirely justifiable to say 'this is an infrastructure for assigning IP addresses and specifying the domain name for the LAN and we do not therefore anticipate assignment of additional codes on an ongoing basis'. This does not rule out special pleading (e.g. geopriv) but clearly signals to people to think somewhere else. Alternatively if we think that every new protocol is going to need a DHCP slot to advertise its existence then we would have to work out a way to insert an extensible mechanism. In the case of DHCP the first approach is clearly the way to go. -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 10:38 AM To: Hallam-Baker, Phillip Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: IANA registration constraints Phillip, My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. ... So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted. I'm definitely in favor of improving the situation. And for applications protocols this is probably an easier problem to begin with. And as I said in the previous e-mail, as far as I know, most new work uses field sizes and types that have less scarcity. However, the Internet runs to a large extent on protocols that were designed decades ago, and some of those protocols have number spaces that are very finite. I don't want to run out of protocol numbers, DHCP message types, etc. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints
Can we please leave the specific opinions about DHCP out of this discussion? The dhc WG has done its due diligence, with review and support from the IETF and the IESG, to put into place processes to govern assignment of extensions to DHCP and to accommodate future extensions to both DHCPv4 and DHCPv6 in the option code space design. This discussion is clearly not the place for opinions about how future extensions to DHCP ought to be managed. If DHCP must be brought into the discussion, please read and understand the relevant RFCs and policies at IANA before using DHCP as a whipping boy/example. - Ralph (who's not bitter at all) On 6/13/07 10:54 AM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: That is why I think this is an area that the IAB should look at. I don't think we should be worried about running out of protocol numbers. Deployment of IPv6 and multicast pretty much demonstrate that it is a non-issue. At the application level we just need to persuade people that, no it is not acceptable or sustainable to have an internet architecture that is dependent on parsimonious assignment of IP Port or DNS RR numbers. Where we have a resource code consumption issue we should either declare the protocol essentially closed for extensions or work out a way to introduce a sustainable extension mechanism. So for example on DHCP I think it would be entirely justifiable to say 'this is an infrastructure for assigning IP addresses and specifying the domain name for the LAN and we do not therefore anticipate assignment of additional codes on an ongoing basis'. This does not rule out special pleading (e.g. geopriv) but clearly signals to people to think somewhere else. Alternatively if we think that every new protocol is going to need a DHCP slot to advertise its existence then we would have to work out a way to insert an extensible mechanism. In the case of DHCP the first approach is clearly the way to go. -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 10:38 AM To: Hallam-Baker, Phillip Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: IANA registration constraints Phillip, My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. ... So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted. I'm definitely in favor of improving the situation. And for applications protocols this is probably an easier problem to begin with. And as I said in the previous e-mail, as far as I know, most new work uses field sizes and types that have less scarcity. However, the Internet runs to a large extent on protocols that were designed decades ago, and some of those protocols have number spaces that are very finite. I don't want to run out of protocol numbers, DHCP message types, etc. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
At 5:51 AM -0700 6/13/07, Hallam-Baker, Phillip wrote: I have spent quite a bit of time thinking what the consequences of a default by a registry of the IANA, ISBN, EUI (aka MAC address) type. My conclusion is: virtually nil. That kinda depends on what is part of that default. I would absolutely want every codepoint to have the best possible reference to a document that shows how the codepoint is used. An RFC is best (as long as the registry is updated when the RFC is); an Internet Draft is OK; a reference to an online non-IETF document is reasonable; an email address is barely acceptable. But there has to be some way for a developer who needs to know what to do when faced with the use of the codepoint to get some information. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote: The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. It does not need to promote interoperability; being interop-neutral is sufficient. How does giving a codepoint to someone with a crazy (and let's say even dangerous to the Internet) idea hurt interoperability? It seems to be interop-neutral. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints
If the repository is active, rather than passive this is of course possible. For example we might map out a DNS spec within the .arpa TLD and use it to distribute machine readable descriptions of the code points. Something of the sort could be done for EUI-48 and -64 space as well of course. It does increase leverage and the ability to enforce assignments to a degree but only to the extent that running code actually refers to the registry and only if there is no possibility of setting up a rival registry. At the end of the day it is impossible to prevent a fork here, there is no magic token in the Internet architecture that says 'mine'. I suspect that if we ever get to the point where the DNS root is signed that there will be multiple signature authorities and multiple signing keys involved. -Original Message- From: Paul Hoffman [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 11:25 AM To: ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: IANA registration constraints At 5:51 AM -0700 6/13/07, Hallam-Baker, Phillip wrote: I have spent quite a bit of time thinking what the consequences of a default by a registry of the IANA, ISBN, EUI (aka MAC address) type. My conclusion is: virtually nil. That kinda depends on what is part of that default. I would absolutely want every codepoint to have the best possible reference to a document that shows how the codepoint is used. An RFC is best (as long as the registry is updated when the RFC is); an Internet Draft is OK; a reference to an online non-IETF document is reasonable; an email address is barely acceptable. But there has to be some way for a developer who needs to know what to do when faced with the use of the codepoint to get some information. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
--On Wednesday, June 13, 2007 08:27 -0700 Paul Hoffman [EMAIL PROTECTED] wrote: At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote: The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. It does not need to promote interoperability; being interop-neutral is sufficient. How does giving a codepoint to someone with a crazy (and let's say even dangerous to the Internet) idea hurt interoperability? It seems to be interop-neutral. As Brian has suggested, this is a discussion that should really be had around the specifics of draft-narten-iana... I believe that discussion needs to be a community one leading to a BCP, because some fundamental policy issues are involved that interact with the IAB's role with regard to IANA and general community interests, not just the policy role that falls to the IESG as the result of its management/steering responsibilities. Fortunately or unfortunately, I don't believe it is worth spending more time on that document until there are firm commitments to moving it forward. Until then, the WGs and IESG will do what they like, with or without adequate consideration of implications, and the community will need to express its opinions and manage by Last Call comments and appeal, if at all. Following Paul's earlier comment, I do believe that there is something the IESG could do on its own initiative and without much fuss that might help with situations like this going forward. The vast majority of the community, at best, skims Last Call announcements and decides to ignore most of the documents because nothing controversial or important to their work leaps out at them. But there are cases in which the IESG, or WG Chairs, or others know that there are issues --either technical or procedural ones, but especially the latter-- that might be controversial. I'd like to see those explicitly identified in Last Call announcements, just as draft-klensin-norm-ref (RFC4897 RSN) requires that downward references be identified. Given this thread, I believe that any registration requirement stronger than good, publicly-available, documentation required (deliberately not using Thomas's terminology to avoid getting tied up with the specifics of those categories) should be called out in that way in Last Call announcements. That said, I think strawmen are very dangerous here and that we should be looking at exactly what is being proposed. To my knowledge, no one has seriously suggested that we should give numbers or parameter values to everyone who asks or every half-baked idea that comes along. I think real specifications of what the requested parameter will mean and be used for are important. I think there is a difference between registering a parameter for a non-standard specification that is already deployed and in successful use and registering one for a wild idea by one person. I think we ought to be thinking seriously about how to handle some registrations/ number allocations that were made on the basis of I-Ds which the IESG and RFC Editor then declined to publish as RFCs. And the solution is probably not to withdraw the registrations, at least IMO. But, again, unless the IESG believes that this topic is important enough to give priority and invest energy in looking at policies and moving documents forward, I fear that this discussion is largely a waste of time. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
John Klensin, You wrote: * * I think real specifications of what the requested parameter will * mean and be used for are important. I think there is a * difference between registering a parameter for a non-standard * specification that is already deployed and in successful use and * registering one for a wild idea by one person. I would note that the purveyors of a non-standard specification that is already deployed and in successful use must have somehow obtained their own number assignment without the IANA's help, or this situation could not arise. And before that specification was successfully deployed, it may well have been a wild idea. There seems to be a logical disconnect here. What am I missing? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Bob Braden writes: I would note that the purveyors of a non-standard specification that is already deployed and in successful use must have somehow obtained their own number assignment without the IANA's help, or this situation could not arise. And before that specification was successfully deployed, it may well have been a wild idea. There seems to be a logical disconnect here. What am I missing? Cases like managesieve. Managesieve is almost a decade old and in real use at many sites. Tens of thousands? Even more? No idea. The port it uses was allocated to another purpose about four years after managesieve was deployed. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
I think that folk should decide where the scope of the IETF starts and ends. The message I think that the IETF should be sending is 'we own layer 6 and everything below'. I don't think that many people are really wanting to perpetrate unauthorized innovations in those layers in any case. In order to defend layer 6 and below the IETF should surrender all control at layer 7 and above. I don't think we can do the second while we still consider port number allocations to be the prinicpal means of protocol discovery. And to support machine to machine protocols effectively we require a policy layer. -Original Message- From: Bob Braden [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 2:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: IANA registration constraints (was: Re: Withdrawing sponsorship...) John Klensin, You wrote: * * I think real specifications of what the requested parameter will * mean and be used for are important. I think there is a * difference between registering a parameter for a non-standard * specification that is already deployed and in successful use and * registering one for a wild idea by one person. I would note that the purveyors of a non-standard specification that is already deployed and in successful use must have somehow obtained their own number assignment without the IANA's help, or this situation could not arise. And before that specification was successfully deployed, it may well have been a wild idea. There seems to be a logical disconnect here. What am I missing? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote: Cases like managesieve. Managesieve is almost a decade old and in real use at many sites. Tens of thousands? Even more? No idea. The port it uses was allocated to another purpose about four years after managesieve was deployed. The smtps port was reallocated too, but Microsoft's MUAs still don't support SMTP+STARTTLS on ports other than 25 and insist on smtps. Postmasters have to just shrug and continue to use port 465 for this purpose. OS vendors can't use the IANA port number list without patches. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTH FITZROY: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
--On Wednesday, June 13, 2007 11:58 -0700 Bob Braden [EMAIL PROTECTED] wrote: John Klensin, You wrote: * * I think real specifications of what the requested parameter will* mean and be used for are important. I think there is a* difference between registering a parameter for a non-standard* specification that is already deployed and in successful use and* registering one for a wild idea by one person. I would note that the purveyors of a non-standard specification that is already deployed and in successful use must have somehow obtained their own number assignment without the IANA's help, or this situation could not arise. And before that specification was successfully deployed, it may well have been a wild idea. There seems to be a logical disconnect here. What am I missing? In the instance at hand, the fact that this document was approved for publication on the standards track, and a parameter value allocated on that basis, before the IPR issues came up and the approval (and parameter value) were withdrawn. In the more general case, yes, we are putting ourselves in a position that encourages inventing parameter values and squatting on them. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Tony Finch wrote: On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote: Cases like managesieve. Managesieve is almost a decade old and in real use at many sites. Tens of thousands? Even more? No idea. The port it uses was allocated to another purpose about four years after managesieve was deployed. The smtps port was reallocated too, but Microsoft's MUAs still don't support SMTP+STARTTLS on ports other than 25 and insist on smtps. Postmasters have to just shrug and continue to use port 465 for this purpose. OS vendors can't use the IANA port number list without patches. The application that 465 was allocated for, runs as an interception proxy or routers so if you were actually to use URD, you break mail clients communicating with exchange servers. There's some serious brokenness in that whole debacle. Tony. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Paul Hoffman wrote: At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote: The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. It does not need to promote interoperability; being interop-neutral is sufficient. How does giving a codepoint to someone with a crazy (and let's say even dangerous to the Internet) idea hurt interoperability? It seems to be interop-neutral. I think giving out codepoints freely would in many cases encourage having multiple (often half-baked) solutions to the same problem. To give one example we both worked on: I think it's good we didn't allocate codepoints to all the individual MOBIKE protocol proposals (mine, Tero's, Francis's), and instead were forced to work together and converge on a single protocol. Probably the market would have eventually picked one of them as the winner, but meanwhile, the situation would IMHO not have been interop-neutral. (And working together also produced a better protocol than any of the individual drafts were.) I'm not saying that this particular cooperation would not have happened with less strict IANA policies -- but I do believe that if the bar for getting codepoints and publishing an RFC would be significantly lower than today, we would have a much larger number of poorly concieved and overlapping extensions to various IETF protocols. (And IMHO that would not always be interop-neutral.) However: I do agree with John Klensin's statement that there is a difference between registering a parameter for a non-standard specification that is already deployed and in successful use and registering one for a wild idea by one person. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints
John C Klensin wrote: Again, there may be exceptions, but I think denial cases should require fairly strong (and public) justification. In the general case, I believe the Internet is better off if even the most terrible of ideas is well-documents and registered --with appropriate warnings and pointers-- if there is any appreciable risk that it will be deployed and seen in the wild. Mostly, I think we (the community) tend to confuse the coordination role of registration with the approval role of standardization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
