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:brian.e.carpenter@xxxxxxxxx] > Sent: Thursday, June 14, 2007 3:55 AM > To: ietf@xxxxxxxx > Cc: iesg@xxxxxxxx > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf