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(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com]
Sent: Thursday, June 14, 2007 3:55 AM
To: ietf(_at_)ietf(_dot_)org
Cc: iesg(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf