Subject: [Ieprep] WG last call for IP Telephony Requirements for ETS

From: "King, Kimberly S." <[email-masked]>
Date: Mon, 10 Feb 2003 11:39:10 -0500

This message announces WG last call for 
IP Telephony Requirements for Emergency Telecommunication Service
(draft-ietf-ieprep-ets-telephony-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

---

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 17 Feb 2003 13:01:41 -0500

Maybe I am not clear about what goes in the "telephony requirements" and
what goes in the "framework".  For instance, the framework document talks
quite clearly about "high probability of call completion".  That would seem
to be an appropriate application "IP Telephony Requirement."  What am I
missing?

Janet

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Saturday, February 15, 2003 1:43 PM
To: Gunn, Janet
Cc: Ieprep (E-mail)
Subject: Re: [Ieprep] WG last call for IP Telephony Requirements for ETS

one thing i wanted to add in case i wasn't clear in my last message.  i
have no objections to adding a item on application level admission
control in the Telephony Requirements document.  but it would be
easier to articulate something if you had a specific item in mind.
Perhaps Mike Pierce has a thought on the subject.

-ken

---

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 18 Feb 2003 14:23:15 -0500

Ken said:
>i could add some verbage to this affect of distinguishing the telephony
>requirements from the SIPPING document.  it didn't seem necessary
>at the time given that the documents were products of separate
>groups with separate scopes/charter.  how do the chairs (and co-author)
>feel?

This chair doesn't feel strongly about this issue and thinks either way is
fine.

Kimberly

-----Original Message-----
From: Ken Carlberg
To: Gunn, Janet
Cc: Ieprep (E-mail)
Sent: 2/17/2003 1:50 PM
Subject: Re: [Ieprep] WG last call for IP Telephony Requirements for ETS

> what goes in the "framework".  For instance, the framework document
> talks quite clearly about "high probability of call completion".  That
> would seem to be an appropriate application "IP Telephony
Requirement."
> What am I missing?

the framework document discusses high probability as an objective, and
in particular a default position with respect to Policy.  It also goes
on to state that Policy can be used to basically over-ride probability
and use pre-emption (please excuse the hand waving with respect to
mechanisms and how this is deployed -- i assume at gateways or servers
that retain application level state of a 'call').

now, if as you suggest "high probability of call completion" is a
requirement, in what form should it be (Must?, Should?)?  And does this
adversely affect efforts like MLPP where pre-emption (as opposed to
probability) is a requirement?

this is why it is easier for us to work with a specific suggested
articulation of a requirement than just the general subject of
"high probability call completion is a requirement".

> Maybe that could be made more explicit.  It makes sense now, but I
> didn't "get" that aspect of it from the actual document

i could add some verbage to this affect of distinguishing the telephony
requirements from the SIPPING document.  it didn't seem necessary
at the time given that the documents were products of separate
groups with separate scopes/charter.  how do the chairs (and co-author)
feel?

-ken

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 26 Feb 2003 22:33:13 +0000

Ok, here is an attempt to add a requirement to the draft regarding
IP telephony signaling.  

  Application Layer Signaling

  Application-layer mechanisms specifically targeted to recognize ETS type
  labels MUST be ABLE to support better than best effort service.  This
  support SHOULD focus on probability of forwarding packets used for call
  completion.  Probability MAY reach 100% depending on the local policy
  associated with the label.  Local policy MUST also be used to determine
  IF better than best effort is to be applied to a specific label (or
  related set of labels).

  The above paragraph MUST be taken in its entirety.  The ability to
  support better than best effort does not mean that the application-layer
  mechanism is expected to be activated.  Further, we do not define the
  means by which better than best effort is or should be realized.
  Application-layer mechanims that do not recognize ETS type labels are
  not subject to this requirement.

comments/thoughts?

-ken