[Gen-art] Re: gen-art review of draft-ietf-ieprep-domain-req-05.txt

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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art