Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-03.txt

From: "Gunn, Janet" <[email-masked]>
Date: Fri, 14 Feb 2003 16:05:36 -0500

Most of these comments are editorial rather than content-based.

Abstract
Is there a definition of "stub domain"?

1.1.1	
NCS is now part of the Department of Homeland Security.

The non governmental participants in GETS are a LOT more than "a select set
of individuals"  I THINK the GETS users are split roughly 50/50 between
government and non government users.

1.2
Should say "...interactive voice has a lower threshold of loss than elastic
applications..."
NOT
"...than other elastic applications..."  Interactive voice is NOT an elastic
application.

What do you mean by "carriers"?

"...some of the protocols of discussed in section 4..." 
should be
"...some of the protocols discussed in section 4..." 

Section 2, pg 6
When talking about "higher probability" it would be helpful to define
"higher probability than WHAT".  I am assuming  it means "higher probability
than for an equivalent  non-emergency call".

I don't agree with the statement  "... probability ... cannot easily be
quantified."  I quantify probability all the time.

Some kind of weird formatting "=A0" before "Hence, ..."

Pg 7
"More
   specifically, we associate this objective in the context of IP
   telephony acting as part of the Public Telephone Network (PTN).
   This, as opposed to the use of IP telephony within a private or stub
   network."
Might want to put this in the scope section.

"a higher probability
   of call completion than that of normal IP telephony call traffic." Might
want to say this earlier.

Pg 8
Authentication is not necessarily centralized.

Section 3- First sentence needs to be reworked to reflect that you now have
TWO (not just ONE) objectives.

Pg 11 reference to Henning's document - it no longer refers explicitly to
headers.

Pg 12 Here you introduce MLPP.  Would it make sense to also discuss it in
section 1.1?

Pg 15.  This statement is NOT true:
"As a point of reference, existing SLAs established by the NCS
   for GETS service tend to focus on a maximum allocation of (e.g., 1%)
   of calls allowed to be established through a given LEC using HPC.
   Once this limit is reached, all other GETS calls experience the same
   probability of call completion as the general public.  "

GETS is ENGINEERED for 1% GETS calls, and some of the SLAs refer to such a
limit, but there is NO real time MECHANISM to track GETS usage, and NO real
time MECHANISM to change the treatment of GETS calls.

In WPS (the wireless extension to GETS) there IS a traffic threshold (25%
WPS in a single cell) beyond which the priority treatment for radio channels
changes.  But NOT in GETS.

Under "traffic engineering", might it make sense to discuss the Sprint and
Genuity access link traffic engineering approaches described in Atlanta.

Pg 16.

In general, PSTN authentication does NOT need to be PIN based.  WPS
authentication is not PIN based, and, for GSM, not centralized.  In
discussing generic PSTN based priority systems, it would be helpful to
describe them in a way which encompasses both WPS AND GETS. (WPS is now
operational, at least as "IOC phase 1".)

Section 5 Key Scenarios

"imply", not "infer"

Pg 18 
"The fact that
   each administrative domain peers with each other as part of the PSTN,
   means that existing security, in the form of Personal Identification
   Number (PIN) authentication (under the context of telephony
infrastructure protection), is the default scope of security. "

No longer true.  WPS authentication "exists" (went live Dec 22), and is NOT
PIN based.  To describe PINs as the "default mechanism" WOULD place
"additional requirements on existing authorized emergency telephony
systems."

Page 22

Under standards work, you might want to make reference to the changes to the
CDMA standards to support emergency traffic.  Like the CPC, there MAY be a
need to translate these new parameters into SIP, etc.

Janet
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 21, 2003 7:52 AM
Cc: [email-masked]
Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Emergency Preparedness Working
Group of the IETF.

	Title		: Framework for Supporting IEPS in IP Telephony
	Author(s)	: K. Carlberg, I. Brown
	Filename	: draft-ietf-ieprep-framework-03.txt
	Pages		: 27
	Date		: 2003-1-20
	
This document presents a framework for supporting authorized
emergency related communication within the context of IP telephony.
We present a series of objectives that reflect a general view of how
authorized emergency service, in line with the Emergency
Telecommunications Service (ETS), should be realized within today's
IP architecture and service models.  From these objectives, we
present a corresponding set of protocols and capabilities, which
provide a more specific set of recommendations regarding existing
IETF protocols.  Finally, we present two scenarios that act as
guiding models for the objectives and functions listed in this
document.  These, models, coupled with an example of an existing
service in the PSTN, contribute to a constrained solution space.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-framework-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ieprep-framework-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ieprep-framework-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 14 Feb 2003 19:11:28 -0500

> government and non government users.

Relative to the total US telephone-accessible population, the total
number of authorised GETS users is *TINY*.

So "select set of individuals" seems indisputably accurate, regardless
of what percentage are govt/non-govt.

Ran

---

From: Ken Carlberg <[email-masked]>
Date: Sat, 15 Feb 2003 20:27:39 +0000

> Is there a definition of "stub domain"?

definitions and references can be found in rfc 1631, 3022, 1322, 1364,
1477, 1478, 1745, and some others

> NCS is now part of the Department of Homeland Security.

I'll note this in the next version of the draft

> The non governmental participants in GETS are a LOT more than "a select
> set of individuals" I THINK the GETS users are split roughly 50/50
> between government and non government users.

i think "select set of individuals" is fine.  nothing breaks with the
phrase and it doesn't relate to size.  but the point is taken that the
system is not just a collections of users from the govt.

> 1.2
> Should say "...interactive voice has a lower threshold of loss than
> elastic applications..." NOT "...than other elastic applications..."
> Interactive voice is NOT an elastic application.

the change will be made.

> What do you mean by "carriers"?

telco carriers.  i've not come across the term carriers in association
with ISPs.  however, i shall extend the term so that it will read as
"telecom carriers"

> "...some of the protocols discussed in section 4..." 

the change will be made.

> "higher probability than WHAT".  I am assuming it means "higher
> probability than for an equivalent non-emergency call".

ok.  additional verbage will be added to provide a point of comparison.

> quantified."  I quantify probability all the time.

the meaning statement is within a larger context as stated below:

   The critical word in this objective
   is "probability", as opposed to assurance or guarantee -- the latter
   two placing a higher burden on the network.  It stands to reason,
   though, that the word "probability" is a less tangible description
   that cannot be easily quantified.  It is relative in relation to
   other traffic transiting the same network.

I'm not sure its fair to cut out so much of what is stated and expect
the parts to stand on its own.  as I stated in the comments on the
General Requirements, aspects such as delay, loss, and jitter can be
(within limitations) addressed by the network.  so if one is going to
focus on probability, which of those three does one concentrate on?  to
me, that not an easy question to make a definitive statement about. 

> Some kind of weird formatting "=A0" before "Hence, ..."

its a problem i have with NROFF.  i'll fix it in the next release.

> Might want to put this in the scope section.

noted.

> "a higher probability
>    of call completion than that of normal IP telephony call traffic." 
> 
> Might want to say this earlier.

noted

> Authentication is not necessarily centralized.

page 8 doesn't have any word on authentication. is there a specific
phrase or sentence that you were concerned about?  your statement is
a bit general and I'd rather not read things into that may not be
there.

> Section 3- First sentence needs to be reworked to reflect that you now
> have TWO (not just ONE) objectives.

ok, the change will be made.

> Pg 11 reference to Henning's document - it no longer refers explicitly
> to headers.

the original passage is:

   [15] is a (soon to be) RFC that defines the requirements for a new
   header field for SIP in reference to resource priority.  This new
   header field is meant to provide an additional measure of distinction
   that can influence the behavior of gateways and SIP proxies.

my understanding is that it pertains to requirements for a header *field*.  
so yes, we are in agreement.

> Pg 12 Here you introduce MLPP.  Would it make sense to also discuss it
> in section 1.1?

i'll give it some thought. 

> GETS is ENGINEERED for 1% GETS calls, and some of the SLAs refer to such
> a limit, but there is NO real time MECHANISM to track GETS usage, and NO
> real time MECHANISM to change the treatment of GETS calls.

you've totally lost me.  if you claim that my statement of "SLAs...focus
on a maximum allocation" is incorrect, how can you then state that "SLAs
refer to such a limit"?  are the words "focus" and "refer" that different?

we have also had private discussions of how some vendors provide limits
on trunk queuing used for GETS calls.  is that not a real-time
functionality?  usage of a service, and in particular its individual
components, can be in several forms.  my original passage does not refer
to a specific form nor where limits exist.

> In WPS (the wireless extension to GETS) there IS a traffic threshold
> (25% WPS in a single cell) beyond which the priority treatment for radio
> channels changes.  But NOT in GETS.

ok.  but as stated above, i did not refer to a specific form of
threshold or mechanism used to achieve it int he original passage.

> Under "traffic engineering", might it make sense to discuss the Sprint
> and Genuity access link traffic engineering approaches described in
> Atlanta.

I'll review what was presented to see what can be added to the TE section.

> operational, at least as "IOC phase 1".)

i'll defer my response to Ian on this.

> "imply", not "infer"

ok

> No longer true.  WPS authentication "exists" (went live Dec 22), and is
> NOT PIN based.  To describe PINs as the "default mechanism" WOULD place

understood about WPS and its use of the unique SIM identifier.  again,
i'll defer to Ian on the subject of security.  however, i have a
question about the subject of PINs.  Is there a general term that
encompasses the use of PINs (the numbers that people use to identify use
of service) and unique identifiers used to phone SIMs?  in my ignorance,
I thought that these two unique identifiers could be termed as PINs.

> Page 22
> 
> Under standards work, you might want to make reference to the changes to
> the CDMA standards to support emergency traffic.  Like the CPC, there
> MAY be a need to translate these new parameters into SIP, etc.

if we add info into the body of the document refering to CDMA standards,
then we'll certainly add the corresponding reference.

regards,

-ken

---

From: Ian Brown <[email-masked]>
Date: Sun, 16 Feb 2003 13:55:52 -0000

Janet wrote:
>describe them in a way which encompasses both WPS AND GETS. (WPS is 
>now operational, at least as "IOC phase 1".)

OK -- I'll make a couple of updates in the next version.

Thanks,
Ian.

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 16 Feb 2003 10:44:03 -0500

On Saturday, Feb 15, 2003, at 15:27 America/Montreal, Ken Carlberg 
>> Interactive voice is NOT an elastic application.

I disagree with the claim that "interactive voice is NOT an elastic
application".  There are deployed VoIP systems (e.g. in production use
by US DoD) that provide an existence proof that VoIP can be an elastic
application.  Those systems shift from higher-bandwidth codecs to
lower-bandwidth codecs in response to detected congestion on access 
links.
That doesn't mean that all VoIP deployments have that property,
but clearly *some* definitely do today (and have done for a few years 
now).

> with ISPs.  however, i shall extend the term so that it will read as

Would be better talk about "telephony carriers" or "IP carriers"
to reduce ambiguity.  "telecom carriers" is an ambiguous term,
unfortunately.

Ran

---

From: Ken Carlberg <[email-masked]>
Date: Mon, 17 Feb 2003 13:27:11 +0000

> That doesn't mean that all VoIP deployments have that property, but
> clearly *some* definitely do today (and have done for a few years now).

yes, good point.  and we also have potential feedback from RTCP (when
its not being blocked).  its ia case of all TCP apps are elastic, and
UDP based apps have a tendency not to be -- its up to the developer to
add it.  I'll make this distinction clearer in the next draft.

> Would be better talk about "telephony carriers" or "IP carriers" to
> reduce ambiguity.  "telecom carriers" is an ambiguous term,
> unfortunately.

ok, i'll expand the respective terms for clarity

-ken