Subject: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony

From: Janet Gunn <[email-masked]>
Date: Wed, 2 Jul 2003 06:21:16 -0400 (EDT)

This message somhow got "lost in the ether" the first time, so I am resubmitting it form a different email account.  Which probably guarantees that the original verison will show up.

Janet

Several of us have coauthored a Best Common Practices ID on configuring a single domain, IP bridging, topology to support Emergency Telecommunications Service.

This ID has been published as an Internet draft
http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.txt

We are looking forward to feedback.

The following is the abstract from the ID:

RECOMMENDED best current practices in applying existing 
protocols for operational implementation of an Emergency 
Telecommunications Service (ETS) in a single-domain IP Bridging 
topology are to use a) Session Initiation Protocol (SIP) 
Priority header value of "emergency", b) Session Description 
Protocol (SDP) attribute experimental parameters to designate 
the call (session) as either a National Emergency call, 
International Emergency call, or both, c) MEGACO context 
descriptors of priorities 0-4 and emergency indication, and 
d) Multi-Protocol Label Switching (MPLS) with Exp-Inferred Label 
Switched Paths (E-LSPs) having a dedicated codepoint specifying 
application of ETS Per-Hop Behavior (PHB), where ETS PHB is 
technically specified the same as EF PHB, but with different 
parameter values and associated with an ETS-specific MPLS 
Differentiated Service.  RECOMMENDED best current practices include IP 
Differentiated Services marking using specified codepoints allocated 
from the Experimental and Local Use pool (pool 2) to designate the 
traffic as either National Emergency or International Emergency for 
corresponding ETS PHB use, and signaling between the Signaling Gateway 
(SG) and Media Gateway Controller (MGC) using the MTP3 SS7 protocol 
over the M2UA adaptation protocol with the Stream Control Transmission 
Protocol (SCTP).  Support is suggested for work in progress on 
defining a SIP Resource-Priority header and defining a SIP telephone 
URI extension for calling party category designation.

Since the deadline for submission  of Internet Drafts, we have made several enhancements and clarifications.  We have posted a new version at
https://gets-ic-pmo.is.dyncorp.com/IETF/Documents.htm 

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 2 Jul 2003 10:25:17 -0400

On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote:
> Several of us have coauthored a Best Common Practices ID on 
> configuring a single domain, IP bridging, topology to support 
> Emergency Telecommunications Service.

Thanks for the heads-up. :-)

A BCP document ought to represent actual currently deployed practice and
what the community believes to be the best practice at the time the 
document
is published.

Readers probably should consider whether those two properties hold
for the contents of the above document when reviewing the document.

Ran

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 02 Jul 2003 11:38:43 -0500

At 10:25 AM 7/2/2003 -0400, RJ Atkinson wrote:

>>Several of us have coauthored a Best Common Practices ID on configuring a 
>>single domain, IP bridging, topology to support Emergency 
>>Telecommunications Service.
>
>what the community believes to be the best practice at the time the document
>is published.
>

Fairly clearly, with brand new normative text within this document directed 
at several different WGs and Protocols.... I don't believe the document 
satisfies the guidance of creating a BCP.

If each of these sections of normative text were discussed and reviewed by 
the appropriate WGs (in a Standards Track document or documents per), then, 
perhaps, this document might be more appropriate as an architecture type 
doc....

Bottom line, I don't believe IEPREP can dictate extensions to existing 
protocols. Our AD was clear on this in the recent past. IEPREP can create 
requirements documents directed at other WGs for those WGs to then decide 
on whether to do work on that 'called-for' extension.

As a side comment, there are several new normative topics brought up here 
without any requirements being generated or discussion within this WG (SDP 
to name one).

>Ran

cheers,
James

                                *******************
                    The answer is "42", what's the question?

---

From: Scott Bradner <[email-masked]>
Date: Wed, 2 Jul 2003 12:45:01 -0400 (EDT)

> on whether to do work on that 'called-for' extension.

that is correct

Scott