Subject: RE: [Ieprep] WG last call for General Requirements for ETS

From: "Gunn, Janet" <[email-masked]>
Date: Fri, 14 Feb 2003 15:28:14 -0500

Here are my comments on the "General Requirements" document

Is it "IEPREP" or "Ieprep"?   Both are used.

Section 3
4) Network Functionality

I am not sure that "better packet loss", "better delay" or "better jitter"
is really what we are after. These should be covered by SLAs, whether or not
it is emergency traffic.

 In cases where, at the application level, there is some kind of "admission
control" we want a better probability of  admission.

For inelastic applications, where there is some kind of negotiation for
capacity, etc. we want a "better negotiating position".

For elastic applications (e.g., I am alive) it is still not clear to me what
we want.  Maybe THAT is where we want lower packet loss.

Section 4 
1)	The phrase "better than best effort" is kind of awkward.  Maybe
"other than best effort" would be better.

Janet

-----Original Message-----
From: King, Kimberly S. [mailto:[email-masked]]
Sent: Monday, February 10, 2003 11:39 AM
To: Ieprep (E-mail)
Cc: 'Scott Bradner ' (E-mail)
Subject: [Ieprep] WG last call for General Requirements for ETS

This message announces WG last call for 
General Requirements for Emergency Telecommunication Service
(draft-ietf-ieprep-ets-general-01.txt).  
The intension is for this draft to
have informational RFC status.

The cut-off date for WG last call is Feb 24, 2003.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Sat, 15 Feb 2003 12:34:02 +0000

> Is it "IEPREP" or "Ieprep"?   Both are used.

i'll change it so that its uniform throughout the document.

> I am not sure that "better packet loss", "better delay" or "better
> jitter" is really what we are after. These should be covered by SLAs,
> whether or not it is emergency traffic.

well, I'll agree that at this stage I don't know what specifically is
requested or needed.  the key phrase in the original passage is "CAN be
realized".  Loss, delay, and jitter are areas that can be qualified and
addressed by a network.  An SLA or some form of a business agreement
would be used to identify which areas are being requested as well as the
quantifiable measure that is targeted.

I feel comfortable with identifying loss, delay, jitter as examples of
aspects associated with network functionality and using it in the
pursuit of higher probability.

>  In cases where, at the application level, there is some kind of
> "admission control" we want a better probability of admission.

since you specifically scope the above comment to the application layer,
then it should be placed in requirement(s) documents that are extensions
or more specific to General requirements.  hence, given the two
documents we have, it should be discussed in the Telephony Requirements
draft.  The reason I wish to push the above comment away from the
General Requirements is that I want that draft to stay clear from a
series of "if" or "in the case of..." type statements.  I would like it
to be simple and slim.

> For elastic applications (e.g., I am alive) it is still not clear to me
> what we want.  Maybe THAT is where we want lower packet loss.

again, the above should be addressed in specific requirements for
specific applications or types of applications.  also, one will need
to qualify what is considered a "better negotiating position"

> "other than best effort" would be better.

i'll go along with Senthilkumar's comment on the subject.  also a google
search on the phrase will show a number of hits showing papers that use
the phrase.

-ken