Subject: [Gen-art] Assignments for Oct 27th, 2005

From: "Mary Barnes" <[email-masked]>
Date: Thu, 20 Oct 2005 23:51:27 -0500

Here's the assignments for next week - Oct 27th:
http://www.alvestrand.no/ietf/gen/art/reviewers-051027.html

Several folks have a higher number of reviews due to returns and last
call assignments coming up on the agenda.  

Corresponding spreadsheets are available:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

Let me know if you see any issues or errors.

And please remember Brian's note earlier this week to copy the
shepherding AD and the WG chair(s) on all your reviews next week, since
he's traveling. 

Mary

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Scott W Brim <[email-masked]>
Date: Fri, 21 Oct 2005 12:32:52 -0400

I'm going to assume everyone knows about gen-art.

No objection.  I don't see anything wrong with the listed
requirements, modulo the one question below -- in fact they seem to be
pretty good.  However, I really can't tell if there are requirements
that have been omitted, since I'm not in the area.  

>    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?

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. :-)

swb

---

From: Scott W Brim <[email-masked]>
Date: Sat, 22 Oct 2005 07:09:03 -0400

Sorry, this was a review of draft-ietf-ieprep-domain-req-05.txt.  I
forgot to change the subject line.

---

From: Scott W Brim <[email-masked]>
Date: Sun, 23 Oct 2005 15:52:04 -0400

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?
> >
> 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.

> >>   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.
> >
> thanks for catching that.  it will be fixed :)
> 
> -ken

Thanks and see you.

---

From: ken carlberg <[email-masked]>
Date: Sun, 23 Oct 2005 14:59:06 -0400

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.

      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.

>> discussed in

-ken

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 Oct 2005 17:52:07 -0400

If the IESG chooses to allow the use of the new rules which are still under 
discussion, then this document can be published as an Informational RFC.

I still think it would be a good idea if someone explained why creating an 
intermediate registry was a good idea.  But that is probably a minor issue.

Yours,
Joel M. Halpern

----

APP The "info" URI Scheme for Information Assets with Identifiers in Public 
Namespaces (Informational) - 2 of 2
     <http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-04.txt>draft-vandesompel-info-uri-04.txt
Note: Handling may depend on the results of review of APP 
draft-hansen-2717bis-2718bis-uri-guidelines-06.txt [Open Web Ballot]

Token: <mailto:[email-masked]>Ted Hardie
Reviewer: Joel Halpern (reviewed -02)