On Sun, Oct 23, 2005 02:59:06PM -0400, ken carlberg allegedly wrote: > >> 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.
Sounds great. > >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 Thanks and see you. _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
