(reminder - my AD hat is off for this part of the discussion)
John Leslie wrote:
...
Hans Kruse <kruse@xxxxxxxxx> wrote:
...
1. If the option appears in a packet, will there be any possible
negative impact on a network element that has no code to process the
option.
This is a genuine issue in the proposal by Dr. Roberts...
But, IMHO, it's far better to _review_ that issue, and document the
negative impacts
I agree. Did I write something that indicated otherwise?
(which we have failed to do for the issue at hand).
Correct, so far. And despite the IESG's recommendation, I expect that
we (the IETF) will get the chance to do so in the case in point.
...
I fundamentally disagree with "There's every reason that the same
standard should apply to specifications developed outside the IETF
exactly as to IETF documents" for the simple reason that it is
non-enforceable.
I also fundamentally disagree, but primarily because it asks for
omniscience, and our supply of potential IESG members is limited
enough without adding "demonstrated omniscience" to the requirements.
It is enforcable and doesn't call for omniscience. When an outside
body or person asks for one of these assignments, they are asked to
provide a justification or specification. That's what the IETF
will review.
...
Beyond stewardship of limited code point space, I see no
justification for the IETF having veto power over standards being
developed to use public standards like IP. The fact that such
independent developments are possible is at the heart of the
success of the Internet.
I agree with Hans here: a _large_ portion of the success of the
Internet has come from being able to develop new ideas without
waiting for the IETF _at_all_.
Yes. What we're arguing about is whether there some specific domains
in which the stability of the Internet is at risk, and whether
parameter assignments in those domains can be treated neutrally.
...
It seems that you want a review of "is this protocol safe to deploy
on the Internet"? I can see the reasoning behind that, but I think
the code point assignment review is the wrong place.
I partly agree with Hans here; but we're likely to get stuck
needing to review it at that point.
In fact, if a spec is developed elsewhere, as in this case, the fact
is that the assignment review is the *only* place available for
IETF review. That, I think, is why RFC 2780 was written
...
What if, in the case above, the code gets assigned along with
publication of an RFC that in fact says that the code in question
"belongs" to another organization and represents a non-IETF
protocol that operators should filter unless they understand the
implications of carrying these packets...
I recommend seriously considering such a possibility.
I agree that this would be very reasonable. It's very analogous to the
Experimental/Local Use diffserv code points.
See draft-fenner-iana-exp-2780-00.txt.
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf