Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Teleph ony

From: "Berg, Dennis" <[email-masked]>
Date: Wed, 2 Jul 2003 12:23:06 -0400

Ran,

Understand you comment, and we recognize that there is one case in the ID
where we are not using existing protocols, viz., the Resource Priority
Header.  But, we looked at the ieprep charter statements and thought they
supported that approach, at least partially:

	The working group will develop a BCP RFC or set of RFCs, regarding
	operational implementation of services for Emergency Preparedness
using
	existing Internet protocols. The RFC may include identification of
gaps
	in existing protocols and requirements for use in new protocol or
	protocol feature design. It is out of scope for this working group
to
	do protocol or protocol feature development. 

	Deliverables

	Best Current Practice:
 	 IETF Recommendations for the Emergency Telecommunications Service
 	 using existing protocols - what can be done with existing protocols
 	 and what can not be done.

I.e., the reference to the RPH is covered, at least in part, by the gap
analysis "what can not be done" component of the charter.  To the extent
that it is not, it seems that the right approach is to assume that the RPH
ID will be acted upon and become an RFC before the ieprep BCP is finalized.
If this doesn't happen, of course we would have to revise the BCP draft.

Dennis Berg
CSC
[email-masked]

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]] 
Sent: Wednesday, July 02, 2003 10:25 AM
To: Janet Gunn
Cc: [email-masked]
Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP
Telephony

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

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 02 Jul 2003 14:29:23 -0500

At 12:23 PM 7/2/2003 -0400, Berg, Dennis wrote:

>where we are not using existing protocols, viz., the Resource Priority Header.

Dennis - I believe you might have this backwards (maybe). The R-P header 
has had a requirements ID generated (and RFCd) by IEPREP (3487), and it is 
now properly being worked on by its existing Protocol WG (SIP). I don't see 
the same efforts (requirements IDs) for the other protocols mentioned 
within your ID (SDP, Diffserv, MPLS, MEGACO, etc) that (I believe) must go 
through the same process as the R-P header did (as painful as that was/is - 
hopefully R-P blazed a trail that others will find easier....).

>  But, we looked at the ieprep charter statements and thought they 
>         existing Internet protocols. The RFC may include identification 
> of gaps
>         protocol feature design. It is out of scope for this working 
> group to
>          using existing protocols

I believe this includes all existing extensions to existing protocols - 
which might be part of a discrepancy with your ID, because yours calls for 
many new extensions that each protocol's WGs haven't properly discussed 
(nor have many of these been discussed in IEPREP - SDP being the best 
example of one that hasn't been mentioned before).

I'd say that the R-P header is 'the one' mentioned within your ID that 
*has* been discussed within its appropriate WG, and SIP is close to working 
out the final details of it now. None of the other extensions called for in 
this new ID have been discussed on any other mailing list or in the WG 
meetings that I know of in the last 4 years.

>  - what can be done with existing protocols

What this ID calls for should be the results of much discussion and one or 
more requirements IDs calling for these extensions to occur with proper 
justification of usage and perhaps why existing mechanisms in each protocol 
can't solve what you want.

>ID will be acted upon and become an RFC before the ieprep BCP is 
>finalized.  If this doesn't happen, of course we would have to revise the 
>BCP draft.

As an example of what I mentioned above, where exists a similar 
requirements ID and Standards Track mechanism ID for what you want in/for 
SDP? Or Diffserv (? Or MEGACO?

I believe each doc is required per protocol, per mechanism (meaning there 
could be multiple docs written within one or each WG to solve what you/we 
need).

>From: RJ Atkinson 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony
>
><https://www1.ietf.org/mailman/listinfo/ieprep>https://www1.ietf.org/mailman/listinfo/ieprep 
>

cheers,
James

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