Eliot Lear wrote:
Brian,
1. There's a presumption that "precedence" and "preemption" are the
mechanisms - but those aren't requirements, they are solutions, and
it isn't clear to me that they can ever be appropriate solutions
in the upper layers of the Internet. The requirement is presumably
that important application level sessions succeed in emergency
situations,
even if less important ones fail. The best way to meet that
requirement might be different for each type of application
protocol. Neither the charter text nor the list of deliverables
recognizes such differentiation; they simply assume that precedence
and preemption are the only possible solutions.
Forgive me a naive question but what is there other than precedence or
preemption?
Well, if you require both real time and elastic applications to continue
to work simultaneously, because both are carrying emergency material,
you actually need to share the resources between them appropriately.
That is more subtle than either precedence or preemption.
Also, I suspect that if the application concerned is some sort of
Web Services based transactional stuff, the fact that a given XML
document forms part of an emergency communication may be buried
so deep in the document that identifying it externally will be
next to impossible, especially if it's encrypted. If it gets
preempted, bad things may happen.
I don't claim to be an expert. But I don't like the idea that
just because precedence and preemption are the preferred models
for circuit-switched emergency communications, they are therefore
correct for the Internet. It doesn't follow, and I don't like
building it into a charter.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf