Any application layer label mechanisms used to support ETS MUST be
capable of supporting both the set of ETS and non-ETS (presumably,
normal) users.
I'm not sure about this one, perhaps because I don't understand what
it means. I can envision, for example, applications that are only
used in ETS situations, and are only capable of running with ETS
labels. Are they disallowed? No special apps?
I can see a requirement that any application which is used during
normal times must still be usable during "medium emergencies". Is
that the goal?
the intent of the requirement was to discourage designs/
specifications that totally ignore a "normal" condition -- even if
the application is used exclusively by ETS type users (e.g., first
responders like Fireman). The practice of taking into account the
"normal" condition is found in existing specifications of MLPP, eMLPP
for GSM, and Project 16 for mobile radio.
admittedly, when the above requirement was written, I had in mind
existing IETF applications and I wanted to squash any attempted
augmentation that damaged its legacy operation for "normal" or non-
ETS type users.
How does the following sound?
Regarding existing IETF specified applications, augmentations
in the form
of labeling mechanisms to support ETS MUST NOT adversely
affect its
legacy usage by non-ETS users. With respect to future
applications, such
labeling mechanisms SHOULD allow the application to support a
"normal"
(non-emergency) condition.
Also a nit in case there is another version ...
If proxies take such action, then the security measures
discussed in
[rfc3689] MUST be considered. More discussion about security
in the
single domain context is discussed in section 5.
You don't mean to say that the discussion is discussed. :-)
thanks for catching that. it will be fixed :)
-ken
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
