Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Thu, 20 Nov 2008 09:22:49 -0600

Janet,

With regard to you e-mail below, did you intend that esnet could be at
the same level of priority as ETS & WPS,  or that ETS & WPS need to be
at an even higher priority than esnet?

Stuart Goldman

Alcatel-Lucent 

[email-masked]

+1 602 493 8438

+1 480 414 1260 mobile

P please save a tree by not printing this e-mail.

Janet P Gunn/FED/CSC@CSC 
Sent by: [email-masked] 

10/27/2008 11:45 PM 

To

"James M. Polk" <[email-masked]> 

cc

"'ECRIT'" <[email-masked]>, [email-masked] 

Subject

Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00

  

I apologize for not tracking this as closely as I meant to, as these
comments apply to  earlier versions as well. 

This sentence at the end of sec 1 doesn't quite work. 
"This document IANA registers the "esnet" 
 RPH namespace for use within emergency services networks, not just 
 of those from citizens to PSAPs." (no clear antecedent for "those") 

Perhaps 
"This document IANA registers the "esnet" 
 RPH namespace for use within emergency services networks, not just for
calls or sessions 
  from citizens to PSAPs." 

Section 2 says 
"This document updates the behaviors of the SIP Resource Priority 
 header, defined in [RFC4412], during the treatment options 
 surrounding this new "esnet" namespace only. The usage of the 
 "esnet" namespace does not have a normal, or routine call level.   
 Every use of this namespace will be in times of an emergency, where 
 at least one end of the signaling is with a local emergency 
 organization." 

I don't see this as an "update of the behavior of 4412".  Neither the
ets namespace not the wps 
namespace have a "normal" or "routine" call level.  Every use of the wps
and ets namespaces will 
have priority over calls without RPH. 

You say "This 
 namespace, therefore, MAY be overwritten or deleted, contrary to the 
 rules of RFC 4412 [RFC4412]." 

It is not clear to me why this is "contrary to the rules of 4412".  It
is certainly anticipated 
that other RPH will be overwritten or deleted, when the UAS understands
the namespace. 

4412 says "Existing implementations of RFC 3261 that do not participate
in the 
 resource priority mechanism follow the normal rules of RFC 3261, 
 Section 8.2.2: "If a UAS does not understand a header field in a 
 request (that is, the header field is not defined in this 
 specification or in any supported extension), the server MUST ignore 
 that header field and continue processing the message". " 

But I do not see anywhere that is says that a UAS that DOES understand
the namespace is 
forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says that
"the UAC 
 MAY attempt a subsequent request with the same or different resource 
 value."  This certainly implies the ability to overwrite or delete an
RPH namespace.   

(See also, for instance the PTSC SAC document on the use of the ets and
wps namespaces) 

Immediately following these statements, you give 3 options- 
"These proxies in the service provider 
 MAY either 

 o  accept the existing RPH value with "esnet" in it, if one is 
    present, and grant relative preferential treatment to the request 
    when forwarding it to the ESINet. 

 o  replace any existing RPH value, if one is present, and insert an 
    "esnet" namespace and give relative preferential treatment to the 
    request when forwarding it to the ESINet. 

 o  insert an "esnet" namespace in a new RPH and give relative 
    preferential treatment to the request when forwarding the SIP 
    request towards the ESINet." 

Why do you exclude the possibility of adding the esnet RPH value without
"replacing" an existing RPH value? 

Finally, there is another point that  needs to be made clear.  At least
one person has contacted me expressing concern that this ID implied that
the esnet namespace would  have priority over other namespaces (in
particular wps and ets).  I assured him that this was not the case, that
there was nothing prevent the expected behavior - that the ets and wps
namespaces would be prioritized ahead of esnet in GETS Service Provider
networks. 

However, since the question has already arisen, it would be a good idea
to clarify  this, perhaps in  section 3, where you discuss  the other
namespaces.  In particular, it needs to be made clear in section 3.2
that, even if  "the   local jurisdiction preferred to preempt normal
calls in lieu of 
 completing emergency calls. ", esnet calls will NOT preempt wps or ets
calls. 

By the way, I think you mean "the   local jurisdiction preferred to
preempt normal calls in order to complete emergency calls. "  - not "in
lieu of".  Or perhaps "the   local jurisdiction preferred to preempt
normal calls in lieu of  dropping emergency calls. " 

In fact, it is not clear to me that 4412 permits a call with an RPH
(e.g., esnet)  to preempt a "normal" call (with no RPH namespace).
Section 4.7.2.1 of 4412 says 
"4.7.2.1.  User Agent Servers and Preemption Algorithm 

 A UAS compliant with this specification MUST terminate a session 
 established with a valid namespace and lower-priority value in favor 
 of a new session set up with a valid namespace and higher relative 
 priority value, unless local policy has some form of call-waiting 
 capability enabled. " 

It doesn't say anything about preempting a call with no RPH 

Thanks 

Janet 

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of
e-mail for such purpose. 

"James M. Polk" <[email-masked]> 
Sent by: [email-masked] 

10/27/2008 08:32 PM 

To

"'ECRIT'" <[email-masked]> 

cc

Subject

[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00

  

ECRIT WG

Here is a update to a ID I think is pretty near done, given that this 
is merely an IANA registration ID of an existing mechanism.

Comments are wanted

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Emergency Context Resolution with 
>Internet Technologies Working Group of the IETF.
>
>
>         Title           : IANA Registering a SIP Resource Priority 
> Header Namespace for Local Emergency Communications
>         Author(s)       : J. Polk
>         Filename        : 
> draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
>         Pages           : 9
>         Date            : 2008-10-27
>
>This document creates and IANA registers the new Session Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rp
h-namespace-00.txt
>
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rp
h-namespace-00.txt>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit 

Stuart Goldman

Alcatel-Lucent 

[email-masked]

+1 602 493 8438

+1 480 414 1260 mobile

P please save a tree by not printing this e-mail.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 20 Nov 2008 10:59:52 -0500

Stu,

I intended to say that the esnet namespace needs to be at a LOWER priority 
 than the ets and wps namespaces, in any network that recognizes ets and 
wps as described in 10.5 and 10.6 of RFC4412.

Janet

"GOLDMAN, STUART O \(STUART\)" <[email-masked]> wrote on 
11/20/2008 10:22:49 AM:

> Janet,
> 
> With regard to you e-mail below, did you intend that esnet could be 
> at the same level of priority as ETS & WPS,  or that ETS & WPS need 
> to be at an even higher priority than esnet?
> 
> 
> 
> Stuart Goldman
> Alcatel-Lucent 
> for calls or sessions 
> I don't see this as an "update of the behavior of 4412".  Neither 
> the ets namespace not the wps 
> namespace have a "normal" or "routine" call level.  Every use of the
> wps and ets namespaces will 
> It is not clear to me why this is "contrary to the rules of 4412". 
> It is certainly anticipated 
> that other RPH will be overwritten or deleted, when the UAS 
> understands the namespace. 
> 
in the
> But I do not see anywhere that is says that a UAS that DOES 
> understand the namespace is 
> forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says 
> that "the UAC 
>  value."  This certainly implies the ability to overwrite or delete 
> an RPH namespace. 
> 
> (See also, for instance the PTSC SAC document on the use of the ets 
> and wps namespaces) 
> 
> Why do you exclude the possibility of adding the esnet RPH value 
> without "replacing" an existing RPH value? 
> 
> Finally, there is another point that  needs to be made clear.  At 
> least one person has contacted me expressing concern that this ID 
> implied that the esnet namespace would  have priority over other 
> namespaces (in particular wps and ets).  I assured him that this was
> not the case, that there was nothing prevent the expected behavior -
> that the ets and wps namespaces would be prioritized ahead of esnet 
> in GETS Service Provider networks. 
> 
> However, since the question has already arisen, it would be a good 
> idea to clarify  this, perhaps in  section 3, where you discuss  the
> other namespaces.  In particular, it needs to be made clear in 
> section 3.2  that, even if  "the   local jurisdiction preferred to 
> preempt normal calls in lieu of 
calls.
> preempt normal calls in order to complete emergency calls. "  - not 
> "in lieu of".  Or perhaps "the   local jurisdiction preferred to 
> preempt normal calls in lieu of  dropping emergency calls. " 
> 
> This is a PRIVATE message. If you are not the intended recipient, 
> please delete without copying and kindly advise us by e-mail of the 
> mistake in delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to bind 
> CSC to any order or other contract unless pursuant to explicit 
> written agreement or government initiative expressly permitting the 
> use of e-mail for such purpose. 
> 
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-namespace-00.txt
> >
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-namespace-00.txt>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 11:16:39 -0500

A suggestion was made to me that we should define two namespaces.

One would be used in public networks, and generally would be used to request
resource priority for citizen to authority and possibly authority to citizen
calls.  This would have lower priority than ETS/WPS.

The other would be for use within emergency services IP networks.  It would
be unlikely that ETS/WPS would be used within those networks, but if it was,
some values within the namespace would need higher priority that ETS/WPS.
For example, a message which was an incident commanders “evacuate” message
would be higher than a ETS/WPS traffic.  On the other hand, a citizen to
authority emergency call would have lower priority.

I would be happier with one namespace and more values in that namespace for
all of this, but I was advised that two namespaces was a better choice.

Brian

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Janet P Gunn
Sent: Thursday, November 20, 2008 11:00 AM
To: GOLDMAN, STUART O (STUART)
Cc: [email-masked]
Subject: Re: [Ecrit] Ecrit]
draft-ietf-ecrit-local-emergency-rph-namespace-00

Stu, 

I intended to say that the esnet namespace needs to be at a LOWER priority
 than the ets and wps namespaces, in any network that recognizes ets and wps
as described in 10.5 and 10.6 of RFC4412. 

Janet 

11/20/2008 10:22:49 AM:

> 4412 says "Existing implementations of RFC 3261 that do not participate in
the
calls.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 20 Nov 2008 11:37:15 -0500

Brian,

I need to understand this better.

Exactly what are the constraints of the "emergency services IP network"? 
Is this a network in which EVERY call would have the RPH with the  esnet 
namespace (just varying priority values),and there would be no "normal" 
calls?  Or would their be a mixture of calls with and without RPH wit 
esnet?

Janet

>  than the ets and wps namespaces, in any network that recognizes ets and 
wps

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 12:00:50 -0500

An “Emergency Services IP Network” is a private IP network to which, we hope, all public safety agencies are connected.  It handles all the traffic of a public safety agency, which would include routine and priority citizen to authority, authority to authority and authority to citizen traffic.  It’s not entirely clear to me yet whether we can reuse a number of the existing name spaces as well as a new one.  For example, some of the agency-agency traffic will require pre-emption, but the existing MLPP namespace may be quite sufficient.

It does occur to me that we could have ETS and possibly WPS traffic, in that if the normal access to public facilities traversed the ESInet towards some kind of gateway to a public network, then we would either have to have the ETS/WPS values, or remark them at the edge if a caller inside the ESInet needed to call someone outside the ESInet and needed ETS/WPS priority to do so.   If we carried the priority marking across the ESInet, ETS/WPS would be lower priority than some other traffic, but higher than, for example, citizen to authority emergency calls.

Brian

From: Janet P Gunn [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 11:37 AM
To: Brian Rosen
Cc: [email-masked]; 'GOLDMAN, STUART O (STUART)'
Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00

Brian, 

Exactly what are the constraints of the "emergency services IP network"?  Is this a network in which EVERY call would have the RPH with the  esnet namespace (just varying priority values),and there would be no "normal" calls?  Or would their be a mixture of calls with and without RPH wit esnet? 

Janet

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 09:24:45 -0800

It seems like we're diverging here.  In the ESInet, it seems to me, that
the owner/manager of that ESInet will set the priority treatment as they
deem fit.  Only in the public network arena will real prioritization
have a chance to be "standardized".  So far what do people say is the
ordering?

Public net:
P1. ets/wps? (PSAPs may not be so eager to agree)
P2. esnet
P3. <other/null>

Private net (ESInet):
(anything they want) 

Lastly, what kind of prioritization does a government official (a
servant of the people) get when they themselves initiate an emergency
call?  esnet or ets/wps?  (In a private ESInet, it may be to their
disadvantage to keep the wrong one.)

-roger marshall.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Thursday, November 20, 2008 9:01 AM
> To: 'Janet P Gunn'
> Cc: [email-masked]
> Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> 
> An "Emergency Services IP Network" is a private IP network to 
> which, we hope, all public safety agencies are connected.  It 
> handles all the traffic of a public safety agency, which 
> would include routine and priority citizen to authority, 
> authority to authority and authority to citizen traffic.  
> It's not entirely clear to me yet whether we can reuse a 
> number of the existing name spaces as well as a new one.  For 
> example, some of the agency-agency traffic will require 
> pre-emption, but the existing MLPP namespace may be quite sufficient.
> 
> It does occur to me that we could have ETS and possibly WPS 
> traffic, in that if the normal access to public facilities 
> traversed the ESInet towards some kind of gateway to a public 
> network, then we would either have to have the ETS/WPS 
> values, or remark them at the edge if a caller inside the 
> ESInet needed to call someone outside the ESInet and needed 
> ETS/WPS priority to do so.   If we carried the priority 
> marking across the ESInet, ETS/WPS would be lower priority 
> than some other traffic, but higher than, for example, 
> citizen to authority emergency calls.
> 
> Brian
> 
> 
> 
> Exactly what are the constraints of the "emergency services 
> IP network"?  Is this a network in which EVERY call would 
> have the RPH with the  esnet namespace (just varying priority 
> values),and there would be no "normal" calls?  Or would their 
> be a mixture of calls with and without RPH wit esnet? 
> 
> Janet 
> 
> > For example, a message which was an incident commanders 
> "evacuate" message
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Janet P Gunn

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Nov 2008 14:25:23 -0600

At 10:16 AM 11/20/2008, Brian Rosen wrote:
>For example, a message which was an incident commanders "evacuate" message

Brian

I have to admit this is the first time I'm aware of this suggestion 
(of two namespaces).  To your point about "I would be happier with 
one namespace and more values in that namespace"... is 5 
priority-values not enough? If not, how many do you want?

James

> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local->

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Nov 2008 14:46:30 -0600

>have a chance to be "standardized".  So far what do people say is the

Just to be clear, this discussion is NOT something my namespace ID 
should ever address.  I have no issues with having this discussion - 
but I want to make clear that 
draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make 
priority decisions or even recommendations in the text of the doc.

This ID only creates the namespace *and* the probably scenario in 
which it is intended.

>P1. ets/wps? (PSAPs may not be so eager to agree)

it's not as simple as that.

each <namsepace.priority-value> gets its own slot in any relative 
priority order (per section 8 of RFC4412).

With this in mind, it is *possible* to have a relative priority order like this

P1. ets.4
P2. esnet.4
P3. ets.3  wps.4
P4. esnet.3  esnet.2
P5. wps.3  ets.2
P6. wps.2  ets.1
P7. esnet.1
P8. esnet.0
P9. ets.0  wps.0

notice that within each <namespace>, the numbering order is 
consistent, but that the order relative to the different namespaces 
is whatever the local operator wants to make them.  I do show here 
that at each priority level (e.g., P3, P4, P5, P6 and P9) that there 
are more than one namespace.priority-value combination.  This means, 
within this priority - it's a FIFO situation in which each of the 
namespace.priority-value combinations at this priority level compete 
(i.e., they are equivalent in priority). This is all a local decision.

I think a way to address Brian's comment about preemption is also a 
local decision (because the local jurisdiction needs to live with the 
consequences).  Here's how that can be addressed:

- all these namespace.priority-value combinations *can* be preempted
- only certain namespace.priority-value combinations *can* preempt 
another call.

just a thought about how to solve this...

James

>CONFIDENTIALITY NOTICE: The information contained in this message 
>may be privileged and/or confidential. If you are not the intended 
>recipient, or responsible for delivering this message to the 
>intended recipient, any review, forwarding, dissemination, 
>distribution or copying of this communication or any attachment(s) 
>is strictly prohibited. If you have received this message in error, 
>please notify the sender immediately, and delete it and all 
>attachments from your computer and network.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 20 Nov 2008 16:03:55 -0500

> This ID only creates the namespace *and* the probably scenario in 
Agree
> is whatever the local operator wants to make them. 

At the risk of being a nitnoid, this would NOT be an RFC4412-legal 
ordering,as it reverses the priority values of ets and wps (0 is the 
highest).

 I do show here 
> - all these namespace.priority-value combinations *can* be preempted

I have serious heartburn with this statement. 

In the circuit switched paradigm of preemption (MLPP and eMLPP), only 
calls that are identified a-priori as "part of a preemption domain (or 
similar term)" can be preempted.  "Normal" (unmarked, as opposed to marked 
"routine") calls cannot be preempted. I REALLY don't think we should break 
that aspect of the paradigm without investigating "unintended 
consequences" in great detail.

> > > Subject: Re: [Ecrit] 
> > > Subject: RE: [Ecrit]

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 23:34:40 +0100

1)	Remember that the relationship between namespaces is entirely up to the agreements with the network operator. So referring to something as required to be higher priority is invalid for two reasons:

-	the standards simply will not cover this

-	priority is not simply a matter of servicing all messages in one namespace before another. There may be undertakings to process a certain number of such messages from any namespace within any time period, or any of a host of other conditions. Look at it more as a way of dividing the traffic into separate queues where the queues are serviced by an algorithm which is not standardised but is based on agreements made with the namespace owner. That does not prevent certain namespaces being addressed before anything else.

Certainly with emergency calls, it is common that the traffic can be handled separately, but I believe it is rare that emergency calls take total priority over even normal traffic.

I do agree that callbacks need to be handled separately from citizen to authority calls. I would also suggest that if a call has reached an answer point and is now being redirected to a first responder, that is yet another classification (if such traffic appears on a common network). To distinguish them the appropriate way to to this is to give them different namespaces.

The immediate need in my view is to address the citizen to authority case.

regards

Keith

> Sent: Thursday, November 20, 2008 4:17 PM
> To: 'Janet P Gunn'; GOLDMAN, STUART O (STUART)
> Cc: [email-masked]
> One would be used in public networks, and generally would be 
> used to request resource priority for citizen to authority 
> and possibly authority to citizen calls.  This would have 
> lower priority than ETS/WPS.
> 
> The other would be for use within emergency services IP 
> networks.  It would be unlikely that ETS/WPS would be used 
> within those networks, but if it was, some values within the 
> namespace would need higher priority that ETS/WPS.
> "evacuate" message would be higher than a ETS/WPS traffic.  
> On the other hand, a citizen to authority emergency call 
> would have lower priority.
> 
> I would be happier with one namespace and more values in that 
> namespace for all of this, but I was advised that two 
> namespaces was a better choice.
> 
> Brian
> 
> On Behalf Of Janet P Gunn
>  than the ets and wps namespaces, in any network that 
> recognizes ets and wps as described in 10.5 and 10.6 of RFC4412. 
> 
> Janet 
> 
> > ets namespace not the wps namespace have a "normal" or 
> "routine" call 
> > level.  Every use of the wps and ets namespaces will have priority 
> > over calls without RPH.
> > 
> > You say "This
> > is certainly anticipated that other RPH will be overwritten or 
> > deleted, when the UAS understands the namespace.
> > 
> understand 
> > the namespace is forbidden from deleting it.  For instance, 
> sec 4.7.1 
> > of 4412 says that "the UAC
> > Immediately following these statements, you give 3 options- "These 
> > proxies in the service provider
> >  MAY either
> > 
> > that the ets and wps namespaces would be prioritized ahead 
> of esnet in 
> > GETS Service Provider networks.
> > 
> > other namespaces.  In particular, it needs to be made clear 
> in section 
> > 3.2  that, even if  "the   local jurisdiction preferred to preempt 
> > normal calls in lieu of

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Nov 2008 16:59:32 -0600

At 03:03 PM 11/20/2008, Janet P Gunn wrote:

>ordering,as it reverses the priority values of ets and wps (0 is the highest).

shoot me for not remembering off the top of my pointy head the order 
of ets and wps

;-)

the concept still holds though

>I have serious heartburn with this statement.

this is a comment that is NOT tied to this ID, because there is no 
guidance in this doc to be given on local policy other that the 
concept of relative priority, just to be clear

>In the circuit switched paradigm of preemption (MLPP and eMLPP), 
>only calls that are identified a-priori as "part of a preemption 
>domain (or similar term)" can be preempted.  "Normal" (unmarked, as 
>opposed to marked "routine") calls cannot be preempted. I REALLY 
>don't think we should break that aspect of the paradigm without 
>investigating "unintended consequences" in great detail.
>
> > > > networks.  It would
> > > > recognizes ets and wps

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 20 Nov 2008 18:10:19 -0500

Agree.
Just needs to be made clearer that "there is no guidance in this doc to be 
given on local policy"
Janet

> > > > > > > Re: [Ecrit] 
> > > > > > > other namespaces.  In particular, it needs to be made clear 
in

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Nov 2008 17:29:22 -0600

At 05:10 PM 11/20/2008, Janet P Gunn wrote:

>Agree.
>Just needs to be made clearer that "there is no guidance in this doc 
>to be given on local policy"

it already does this - but I can look (seriously) at making is clearer