As far as I can tell, this is the crux of the problem with
NEA - that in general it's simply unreasonable for a network
to demand that every host that connect to it conform to
arbitrary policies for configuration of those hosts. IETF
should not be standardizing unreasonable expectations. And
even if the behavior is in some limited set of circumstances
reasonable (which is debatable), IMHO IETF should hesitate to
define standards for corner cases.
That is not my understanding of the problem statement.
My understanding is that the specification will provide a description of the
host configuration policy to the network, thus allowing the network to better
decide whether to let the host connect.
that's my understanding also. but nothing you said here contradicts my
statement. if connection of the host to the network is predicated on
having the host conform to whatever arbitrary policy the network wishes
to impose on how the host is configured, then it's unreasonable. the
most that the network should be able to do is impose limitations on the
kinds of traffic that host sends to or receives from the network.
more broadly, the likely effect of standardizing a protocol that lets
the network insist on a particular configuration for a host is to make
the network less flexible over time, by reducing the number of kinds of
hosts that can connect to a network. the unintended consequence of this
proposal would thus be to reduce the flexibility of the Internet.
It is a network protocol, not an inter-network protocol.
true, but not relevant to this argument.
The other problem I have with this charter is one that I have
with many charters these days - it presupposes a particular
design or architecture
before the working group has actually met, when this should
be an engineering decision taken by the consensus of the
working group AFTER analysis of the problem space.
That is the approach that the IETF has been configured for for 15 years.
yes, and IMHO it's been wrong for 15 years.
Working Groups that do no begin with a tightly defined architecture usually
fail.
that might say more about how WGs operate than anything else.
we claim to do engineering around here, but the discipline of
engineering requires that we understand a problem before we attempt to
solve it. as long as we're not bothering to do that, we shouldn't be
surprised when working groups produce "solutions" that don't solve
problems. and there are plenty of these to be found in rfc-index.txt.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf