From mailnull@www1.ietf.org Tue Oct 1 12:13:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24762 for ; Tue, 1 Oct 2002 12:13:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91GEwF13784 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 12:14:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91GEwv13781 for ; Tue, 1 Oct 2002 12:14:58 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24753 for ; Tue, 1 Oct 2002 12:12:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91G9Wv13550; Tue, 1 Oct 2002 12:09:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91G88v13495 for ; Tue, 1 Oct 2002 12:08:08 -0400 Received: from mclmx.mail.saic.com (mclmx.mail.saic.com [149.8.64.10] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24334 for ; Tue, 1 Oct 2002 12:06:05 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 1 Oct 2002 12:07:50 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002100112075003732 ; Tue, 01 Oct 2002 12:07:50 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Oct 2002 12:08:56 -0400 Message-Id: From: "King, Kimberly S." To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-10 (w/14) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Oct 2002 12:07:47 -0400 > > Does REQ-10, taken along with REQ-14, say all network elements must > > understand the mechanism (at least enough to provide a list > of supported > > name spaces or enough to be tell the name space is not supported)? > > Not really. It could just mean that one should be able to > find out if a > network element supports any scheme. If the network element doesn't > support the scheme at all, it can return the protocol equivalent of > "Huh?", without having a clue whether this was a feature asking for > priority treatment or a Big Mac. > What happens if I ask for a Big Mac feature today? Do all network elements return the protocol equivalent of "Huh?" or does this reflect a modification of all network elements? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 12:20:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25476 for ; Tue, 1 Oct 2002 12:20:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91GMK714166 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 12:22:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91GMKv14163 for ; Tue, 1 Oct 2002 12:22:20 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25464 for ; Tue, 1 Oct 2002 12:20:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91GHDv13936; Tue, 1 Oct 2002 12:17:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91GGFv13914 for ; Tue, 1 Oct 2002 12:16:15 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24826 for ; Tue, 1 Oct 2002 12:14:14 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91GGBZC027183; Tue, 1 Oct 2002 12:16:11 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91GG95T025376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Oct 2002 12:16:11 -0400 (EDT) Message-ID: <3D99CA24.1080804@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-10 (w/14) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Oct 2002 12:15:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > What happens if I ask for a Big Mac feature today? Do all network elements > return the protocol equivalent of "Huh?" or does this reflect a modification > of all network elements? To be concrete: One way to ask for a feature in SIP is via the Require header, as in (many details elided) INVITE sip:alice@burgerking.com SIP/2.0 Require: BigMac would return the status response SIP/2.0 420 Bad Extension Unsupported: BigMac (Methods would be requested via OPTIONS and returned in Allow, but that's not likely to be applicable in our application.) All SIP systems have to support this mechanism today, as it is the foundation of the feature negotiation mechanism. Henning _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 14:44:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01030 for ; Tue, 1 Oct 2002 14:44:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91Ijow22150 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 14:45:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Ijov22147 for ; Tue, 1 Oct 2002 14:45:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01003 for ; Tue, 1 Oct 2002 14:43:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91IiJv22054; Tue, 1 Oct 2002 14:44:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Ih5v22018 for ; Tue, 1 Oct 2002 14:43:05 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00910 for ; Tue, 1 Oct 2002 14:41:01 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91Ih0ZC010568; Tue, 1 Oct 2002 14:43:00 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91Igk5T008248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Oct 2002 14:42:47 -0400 (EDT) Message-ID: <3D99EC81.106@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Oct 2002 14:42:09 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > 1. Preserve any priority scheme in the CSN when applying SIP bridging > > This would prevent loss of information in the CSN. It might also make sense > to limit this case to where both CSN's use the same priority scheme (e.g., > suppose CSN 1 is employing MLPP. Then MLPP information is presented in full > to CSN 2 but there is no attempt in the IP network to translate MLPP into a > different priority scheme). > > Question for WG: Can this be done with existing RFCs or new drafts? Are > there any specific security or other requirements in this case? I believe this can be done with existing drafts, such as the R-P document. It could also be done with ISUP bridging, but that assumes that both sides use ISUP and the same version of it. RFC 3372 describes this architecture in some detail. > > 2. Introduce priority scheme at SIP endpoints (e.g., SIP user agents, > gateways, media servers). > > This would allow new optional functionality such as providing emergency > users preferred access to gateway or media server resources, allowing > preemption to occur at endpoints, etc. This option increases complexity and > has security issues that will also need to be addressed. I believe the security issues aren't all that different than those we already face - you need to prevent unauthorized access. I don't see how this increases protocol complexity. It may increase implementation complexity slightly, but many existing media systems already have priorities of one sort or another. Maintaining two (or more) queues instead of one isn't terribly challenging for an application, particularly if you don't do preemption. The pseudo is nothing but if (incoming request has high priority) insert into queue1 else insert into queue2 and if request is done pick next from queue1 if empty, pick next from queue2 > > Questions for WG: What are the requirements for these endpoints? Would a > SIP endpoint be required to determine what priority scheme(s) a gateway > employs? Would the gateway be required to communicate the security > information it must have before allowing priority access to resources? I'm confused by your distinction. A gateway *is* a special case of a SIP endpoint. (I'm treating a decomposed MG/MGC as a logical gateway here.) The gateway or, in case of a decomposed version, the MGC, speaks SIP. > > 3. Introduce priority of SIP messages within SIP proxy servers. > > This would allow certain SIP messages to have preferred treatment over other > messages. Now on the surface, it might seem like this kind of preferred > treatment addresses one of the working groups expressed concerns - > congestion. However, there are different types of congestion. > > In reviewing some prior messages to this list, it seems a great deal of > emphasis has been placed upon QoS so that packets associated with emergency > communications are less likely to be dropped during transport in the event > of congestion. This type of prioritization is in the realm of techniques > like DiffServ or RSVP and hence out of scope for SIP or SIPPING. Very much so. > > The priority of SIP messages within SIP proxy servers isn't likely to > address the transport congestion issue-SIP proxies typically don't have > knowledge of QoS resources and SIP messages don't typically traverse the > same path as the media streams. The congestion with respect to gateway or > other endpoint resources has been handled in 2 above. > > So, what SIP proxy server prioritization could do is possibly help a server > decide which message requests in setting up sessions should be preferred. > It was pointed out in the joint IEPREP-SIPPING meeting in Yokohama, that SIP > proxies are fast and prioritizing the individual handling of messages may > have limited value. SIP proxies must also be DOS resistant. Also recall This is not generally true. While SIP proxies *can* be fast, they often execute a significant amount of logic. One can usefully think of a SIP proxy as having some of the same properties as a web server. A web server can be very fast if all it does is serve static pages, but can take significant amounts of time to process cgi, servlet or similar requests. SIP servers can do the same type of processing - indeed, the mechanisms such as servlets and cgi are effectively the same in SIP and HTTP servers. Just as for web servers, services may be created by users and may very significantly in complexity. For example, they can include database accesses ("Is this person on the telemarketer list?" "Does this person making an outbound call have enough credit left?"). Some people don't just want to replicate the phone system in SIP :-) Thus, a very reasonable mechanism for a robust server is to say "priority calls don't get to do cgi stuff". That said, my perception is that whether we say anything about this or not, implementors can use the same techniques we specify for bridging or gateway resources to do resource priorities within a proxy. This is not something we need to specify since it is a matter of product differentiation. It is not externally visible, except possibly as a crashed server. > that there are many SIP requests per session and they occur in both > directions. Suppose a caller with priority calls a caller with regular > capabilities. SIP proxies will send setup requests in both directions. > Would one want priority treatment of exclusively the direction from the > priority user to the regular one? If not, there will be additional > complexity and security concerns in "transferring" the priority of the > caller to that of the callee. There is also complexity in checking requests This sounds complicated, but is a red herring. You already need to match up requests with each other and with responses. (Among other reasons, to detect retransmissions and to deal with state at the cgi and servlet level.) Thus, this is in effect a freebie - if a request from A to B had priority, the response from B to A will be associated with that and can easily get the same treatment. (Systems that I'm familiar with already treat responses to existing requests with priority, since they help clean out work and avoid having a lot of half-completed requests hanging around and timing out.) Association is via a hard-to-fake cryptographically random identifier used as the hash key. To be sure, this does not cover all cases. For example, for call-stateless proxies, mid-call requests from a low-privilege callee to the high-privilege caller will not be prioritized, in all likelihood. By definition, the call is already up at that time, so this is probably less of an issue in any event. With a few exceptions in special cases (COMET comes to mind), call setup has requests only going from caller to callee. > have the necessary authentication per SIP message, per SIP proxy over > possibly different security domains. This is a formidable problem for a > feature whose utility has already been questioned (see > http://www.softarmor.com/sipping/meets/ietf54/slides/ieprep-sipping-joint.pp > t ). See above. I think this is largely an implementation issue which we can safely ignore since everybody will have a different notion what their proxy is doing or not doing. Smart implementors will ignore the slides and build robust systems; dumb implementors will tell their boss that the IETF said this can't be done :-) > > Given the above and our tight deadlines, I am going to suggest we first > focus on the requirements for 1 and 2 above. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 15:33:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02499 for ; Tue, 1 Oct 2002 15:33:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91JZ9F24369 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 15:35:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91JZ9v24364 for ; Tue, 1 Oct 2002 15:35:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02476 for ; Tue, 1 Oct 2002 15:33:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91JY6v24283; Tue, 1 Oct 2002 15:34:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91JXRv24247 for ; Tue, 1 Oct 2002 15:33:27 -0400 Received: from [140.32.132.66] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02427 for ; Tue, 1 Oct 2002 15:31:21 -0400 (EDT) Received: from mail.nps.navy.mil by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Tue, 1 Oct 2002 12:31:55 -0700 Received: from there ([131.120.179.247]) by capella.nps.navy.mil (8.12.2/8.12.2) with SMTP id g91JJkUi025727 for ; Tue, 1 Oct 2002 12:19:47 -0700 (PDT) Message-Id: <200210011919.g91JJkUi025727@capella.nps.navy.mil> Content-Type: text/plain; charset="iso-8859-1" From: Rex Buddenberg To: "Ieprep (E-mail)" X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g91JXRv24248 Subject: [Ieprep] Fwd: [CAP] CAP input demo / update Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Oct 2002 12:34:21 -0700 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit No, this isn't VoIP and SIP so tune it out if that's where your head is. But it is emergency services use of the Internet. ---------- Forwarded Message ---------- Subject: [CAP] CAP input demo / update Date: Tue, 1 Oct 2002 12:02:47 -0700 From: Art Botterell To: CAP-list@incident.com [sorry if this is a duplicate... having a bit of trouble with the listserver today!] Friends - As you know, we're demonstrating some applications of the current draft alert message format in Northern Virginia, under the auspices of the ComCARE Alliance. As part of that demo we've posted an input form, with a "pop-up" graphic tool for drawing affected-area polygons, that renders an alert message and passes it off to various processors. Please feel free to play with it for the next few days... after that we'll need to restrict it to actual demo use, at least for awhile. The input tool is at ... it works best on Internet Explorer on Windows. If you fill out the form and submit it, you'll see the XML format message returned to you. (The message also gets routed to several of our partners, so be considerate of what you write!) This demo is based on the current (version 0.5a) working draft of the alert message format. As for ongoing work on the message format itself... we're still waiting for the final report from the Partnership for Public Warning's workshop in Emmitsburg last June... but I've spoken with some folks who've seen review copies and it doesn't sound like there'll be anything too terribly revolutionary in it. And we still hope to launch a more formal standards-track process under PPW auspices. If that comes to pass, it'll provide an improved mechanism for processing the feedback from the workshop and some other ideas and comments that have been accumulating. Otherwise we'll just have to move ahead with such resources as we can muster. Stand by for news... - Art ----------------------------------------------------------------------- "cap-list" is an email list for discussion about ideas and requirements for a Common Alerting Protocol. It is not to be used for product announcements, advertising or advocacy. To join the list, send email to "cap-list-request@incident.com" with the word "subscribe" in the message body. To unsubscribe, send mail to the same address with a body text of "unsubscribe". For more information about the Common Alerting Protocol, visit . ----------------------------------------------------------------------- ------------------------------------------------------- -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 15:53:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03289 for ; Tue, 1 Oct 2002 15:53:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91Jt3I25546 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 15:55:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Jt3v25543 for ; Tue, 1 Oct 2002 15:55:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03283 for ; Tue, 1 Oct 2002 15:52:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Jr9v25488; Tue, 1 Oct 2002 15:53:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Jqav25470 for ; Tue, 1 Oct 2002 15:52:36 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03238 for ; Tue, 1 Oct 2002 15:50:31 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 1 Oct 2002 15:51:04 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002100115471410337 ; Tue, 01 Oct 2002 15:47:14 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Oct 2002 15:47:03 -0400 Message-Id: From: "King, Kimberly S." To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] requirements document(s) to SIPPING MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Oct 2002 15:47:13 -0400 > > > > 2. Introduce priority scheme at SIP endpoints (e.g., SIP > user agents, > > gateways, media servers). > > > > This would allow new optional functionality such as > providing emergency > > users preferred access to gateway or media server > resources, allowing > > preemption to occur at endpoints, etc. This option > increases complexity and > > has security issues that will also need to be addressed. > > I believe the security issues aren't all that different than those we > already face - you need to prevent unauthorized access. I'm glad to hear you say that. I wasn't sure how to read some of the security requirements. "SEC-1: More rigorous: Prioritized access to network and end system resources imposes particularly stringent requirements on authentication and authorization mechanisms since access to prioritized resources may impact overall system stability and performance, not just result in theft of, say, a single phone call." Part of this process is just understanding what is being said. > don't see how > this increases protocol complexity. It may increase implementation > complexity slightly, but many existing media systems already have > priorities of one sort or another. Maintaining two (or more) queues > instead of one isn't terribly challenging for an application, > particularly if you don't do preemption. The pseudo is nothing but > > if (incoming request has high priority) > insert into queue1 > else > insert into queue2 > > and > > if request is done > pick next from queue1 > if empty, pick next from queue2 > The case of endpoint prioritization is an important case that we should address. Sure, the above pseudo code is trivial and represents a policy saying high priority can starve everything else (assuming you want this in a loop). That's one policy. It's fine that this is trivial after working out the requirements but part of the complexity is figuring out the requirements. > > > > Questions for WG: What are the requirements for these > endpoints? Would a > > SIP endpoint be required to determine what priority > scheme(s) a gateway > > employs? Would the gateway be required to communicate the security > > information it must have before allowing priority access to > resources? > > I'm confused by your distinction. A gateway *is* a special > case of a SIP > endpoint. (I'm treating a decomposed MG/MGC as a logical > gateway here.) > The gateway or, in case of a decomposed version, the MGC, speaks SIP. Yes, the gateway *is* a special case of a SIP endpoint. I brought it out as an example because it has resources that your document specifies as potentially a bottleneck. The purpose of the exchange was to focus on underlying assumptions and requirements so we can provide a good requirements document for SIP/SIPPING that meets the needs of the ieprep community. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 16:10:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03727 for ; Tue, 1 Oct 2002 16:10:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91KCUI26663 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 16:12:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KCUv26660 for ; Tue, 1 Oct 2002 16:12:30 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03710 for ; Tue, 1 Oct 2002 16:10:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KB6v26632; Tue, 1 Oct 2002 16:11:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KAdv26578 for ; Tue, 1 Oct 2002 16:10:39 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03653 for ; Tue, 1 Oct 2002 16:08:36 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91KARZC016270; Tue, 1 Oct 2002 16:10:27 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91KAP5T015624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Oct 2002 16:10:26 -0400 (EDT) Message-ID: <3D9A010B.3010900@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: ieprep@ietf.org Subject: Re: [Ieprep] draft-ietf-ieprep-sip-reqs-00.txt References: <42.2c6b356a.2a9ccf72@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Oct 2002 16:09:47 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mpierce1@aol.com wrote: > Comments on draft-ietf-ieprep-sip-reqs-00: > > 2. Instead of CN for the abbreviation, I would suggest SCN (Switched > Circuit Network). Well, Kimberly used CSN. From a quick Google search, both terms seem to be in use. I don't much care either way... > 4. End of section again refers to four resources (gateway, CN, IP > network resources, and receiver). The text in Section 3 also defined SIP > proxy resources. > I added proxy with (x). > The meaning of the (x) in the table is not clear. For example, although > it says that (x) means the resource is in the CN, the first row in the > table which is the IP-only case has an (x). The "as the ..." part is too narrow; I just dropped it. > > REQ-1 implies that the U.S. defense network priority scheme is different > than Q.735. It is identical. NATO requirements (also five levels) are > also the same. Reworded as Q.735, also implemented by the U.S. defense network and NATO, has five levels > The British Government Telephone Preference Scheme (GTPS) is > fundamentally different. It does not control call setup beyond simply > determining who gets dial tone. > > I suggest this requirement should read: > Changed. > > REQ-12 Need to make it clear that the "existing schemes" refers to the > PSTN and the "future schemes" refers to the plan for IP. Noted. > > 7. The statement that priority mechanisms can be categorized by priority > queue or preemption is a little restrictive. There are other mechanisms > which don't fit in either of these two, such as alternate routing and > exemption from traffic controls. Most of these additional ones could be > categorized as making additional resources available to the priority > calls. I would suggest something like: Added/reworded. > SEC-9 (Confidentiality) should be separated somewhat from ETS. While it > is true that many emergency calls would want confidentiality, many > regular calls also do. Further, the lack of confidentiality would not be > a reason for not allowing an ETS call to go through, as implied by the > statement "must be protected". > Since "intercept" is often understood to refer to "lawful intercept", > this statement about "protected from intercept" should be changed to > read "unlawful intercept". Reworded must to should. Noted that callers may be willing to sacrifice confidentiality to get a call through. > > SEC-10 Same comment as for SEC-9. Thanks for your comments. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 16:17:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03885 for ; Tue, 1 Oct 2002 16:17:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91KIuM26945 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 16:18:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KIuv26942 for ; Tue, 1 Oct 2002 16:18:56 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03873 for ; Tue, 1 Oct 2002 16:16:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KHSv26887; Tue, 1 Oct 2002 16:17:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KH0v26836 for ; Tue, 1 Oct 2002 16:17:00 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03852 for ; Tue, 1 Oct 2002 16:14:56 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91KGqZC016734; Tue, 1 Oct 2002 16:16:52 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91KGp5T016124 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Oct 2002 16:16:51 -0400 (EDT) Message-ID: <3D9A0289.3080505@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Oct 2002 16:16:09 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I'm glad to hear you say that. I wasn't sure how to read some of the > security requirements. > > "SEC-1: More rigorous: Prioritized access to network and end > system resources imposes particularly stringent > requirements on authentication and authorization mechanisms > since access to prioritized resources may impact overall > system stability and performance, not just result in theft > of, say, a single phone call." I added a more explicit reference to the resource mentioned earlier. SEC-1 applies to all of them. (I'm not sure if that's where the confusion came from.) > The case of endpoint prioritization is an important case that we should > address. Sure, the above pseudo code is trivial and represents a policy > saying high priority can starve everything else (assuming you want this in a > loop). That's one policy. It's fine that this is trivial after working out > the requirements but part of the complexity is figuring out the > requirements. I don't think we need to specify a particular queueing policy. I'm a bit lost as to what impact on requirements this might have. (I can't see any new ones.) > The purpose of the exchange was to focus on underlying assumptions and > requirements so we can provide a good requirements document for SIP/SIPPING > that meets the needs of the ieprep community. > Thanks for all your close reading and comments. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 1 16:25:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04150 for ; Tue, 1 Oct 2002 16:25:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91KRFr27234 for ieprep-archive@odin.ietf.org; Tue, 1 Oct 2002 16:27:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KRFv27231 for ; Tue, 1 Oct 2002 16:27:15 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04146 for ; Tue, 1 Oct 2002 16:25:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KQ2v27201; Tue, 1 Oct 2002 16:26:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91KP7v27176 for ; Tue, 1 Oct 2002 16:25:07 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04087 for ; Tue, 1 Oct 2002 16:22:59 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91KOoZC017101; Tue, 1 Oct 2002 16:24:50 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g91KOL5T016707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Oct 2002 16:24:22 -0400 (EDT) Message-ID: <3D9A044F.7080702@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Carlberg CC: ieprep@ietf.org Subject: Re: [Ieprep] (no subject) References: <963.1023887575@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Oct 2002 16:23:43 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > the above may need a bit of clarification. I think one could argue that > a specific NameSpace represents a "particular priority mechanism". I will formulate a bit more positively. > > I can gather that what you are saying is that the NameSpace should not > reflect a specific organization or implementation. And you also want to > avoid a one-to-one correlation between a namespace and geographic/geo- > political boundaries. thats fine. Indeed. > > one the other hand, I assume that NameSpace(s) that correlate to a > standard like MLPP (from ITU) would be fine. valid interpretation? > > also, would it be fine to state that private or experimental NameSpace(s) > could be defined, but they simply would not be registered with IANA. We > kind of have that with the current diff-serv allocation of code points. > The one difference with the diff-serv analogy is that I do NOT think there > will be a need to additional parameter stating whether the NameSpace is > public or private. if the NameSpace is not one listed by IANA, then by > default its private. Yes; noted. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 2 11:30:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24664 for ; Wed, 2 Oct 2002 11:30:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92FVhN30304 for ieprep-archive@odin.ietf.org; Wed, 2 Oct 2002 11:31:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92FVhv30301 for ; Wed, 2 Oct 2002 11:31:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24656 for ; Wed, 2 Oct 2002 11:29:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92FUGv30184; Wed, 2 Oct 2002 11:30:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92FTPv30147 for ; Wed, 2 Oct 2002 11:29:25 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24592 for ; Wed, 2 Oct 2002 11:27:23 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Wed, 2 Oct 2002 11:29:05 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002100211290600986 for ; Wed, 02 Oct 2002 11:29:06 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 11:30:12 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] overall issues and REQ-11 thru REQ-15 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Oct 2002 11:29:05 -0400 First, some overall issues: High-level Question: What involvement is needed by the local IP network or SIP carrier for the user to make use of a gateway's ability to invoke GETS, MLPP or some other service on the CSN? GETS Example: User wishes to place GETS call from SIP phone to a phone in the CSN (via a gateway). CASE A: The gateway doesn't support the priority scheme. It sure might be nice if it understood that 710 was a valid area code and routed this to the CSN for authorization and preferential treatment in the CSN using GETS. The IP network or SIP carrier may have no particular relationship with the user. CASE B: The gateway does support the priority scheme. At that point, it is a matter of policy, if the gateway and user do some exchange authentication/authorization and gives the user preferential access to a gateway port. Then the 710 call is routed to the CSN. The IP network or SIP carrier may have no particular relationship with the user. CASE C: The gateway supports the priority scheme and the IP network or SIP carrier also have a business relationship with the user (or GETS service). In this case, the authentication/authorization could potentially be for the entire GETS service. Not only is the user authorized for (perhaps preferential) use of the gateway, the user is authorized for the full GETS system and a true destination is entered by the gateway (i.e., perhaps the user really wanted to call 202-555-1212). In this case, there are some pretty explicit relationships assumed. So, what are we talking about? Maybe it is best left ambiguous since the schemes I've heard voiced here use different techniques. The circuit-switched landline GETS model authenticates in the PSTN (at particular IXCs) after the user dials the 710 "area code". However, the traditional circuit-switched MLPP and GTPS systems have their authentication built in based upon the physical line. When moving MLPP to an IP environment (a.k.a. Assured Service) then it appears http://www.ietf.org/internet-drafts/draft-pierce-sipping-assured-service-02. txt "It must be possible to verify that the calling party is authorized to use the Assured Service and the requested precedence level value and to take the appropriate action if the calling party attempts to use a higher level." The network operator and the assured service user seem to have a known established relationship. It is my understanding (and I could be wrong) that Assured Service is to be deployed on a priviate network where the local IP networks and SIP carrier have an known relationship with the user. Do the requirements assume any underlying relationship between the local IP network or SIP carrier and the user? Should they? Onward...the remaining requirements REQ-11: Identity-independent: The user identity is insufficient to identify the priority level of the request. The same identity can issue non-prioritized requests as well as prioritized ones, with the range of priorities determined by the job function of the caller. The choice of the priority is made based on human judgement, following a set of general rules that are likely to be applied by analogy rather than precise mapping of each condition. For example, a particular circumstance may be considered similarly grave compared to one which is listed explicitly. Comment: I think we are in new territory here. With MLPP, certain lines are provisioned to be able to make calls at a prescribed level(s). With traditional landline circuit-switched GETS, the user identity (+ PIN) is sufficient to identify the priority of the call. In the U.K's Government Telephone Preference Scheme, lines are divided into classes to determine what lines get to place outgoing calls. So, I presume REQ-11 is directed solely at the Topology B--IP at the Start? REQ-12: Independent of network location: While some existing schemes restrict the set of priorities based on the line identity, it is recognized that future schemes should be flexible enough to avoid such reliance. Instead, a combination of authenticated user identity, user choice and policy determines the request treatment. REQ-13: Multiple simultaneous schemes: Some user agents will need to support multiple different priority schemes, as several will remain in use in networks run by different agencies and operators. (Not all user agents will have the means of authorizing callers using different schemes, and thus may be configured at run-time to only recognize certain namespaces.) REQ-14: Discovery: A terminal should be able to discover which priority name spaces are supported by a network element. Discovery may be explicit, where a user agent requests a list of the supported name spaces or it may be implicit, where it attempts to use a particular name space and is then told that this name space is not supported. If I understood Henning's email Re: [Ieprep] IEPREP SIP REQ-10 (w/14), this requirement request default treatment of network elements not supporting the proposed mechanism and gives some options (no not OPTIONS) for appropriate responses from those that do. "(Methods would be requested via OPTIONS and returned in Allow, but that's not likely to be applicable in our application.) All SIP systems have to support this mechanism today, as it is the foundation of the feature negotiation mechanism." REQ-15: Testing: It must be possible to test the system outside of emergency conditions, to increase the chances that all elements work during an actual emergency. In particular, critical elements such as indication, authentication, authorization and call routing must be testable. I suspect what is really being requested is that the mechanism isn't something that is switched on only during emergencies but rather something that is always available if requested (and hence can be tested outside of emergency situations). Comments? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 2 12:08:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26579 for ; Wed, 2 Oct 2002 12:08:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92GAG001233 for ieprep-archive@odin.ietf.org; Wed, 2 Oct 2002 12:10:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92GAFv01230 for ; Wed, 2 Oct 2002 12:10:15 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26570 for ; Wed, 2 Oct 2002 12:08:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92G93v01163; Wed, 2 Oct 2002 12:09:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92G81v01096 for ; Wed, 2 Oct 2002 12:08:01 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26500 for ; Wed, 2 Oct 2002 12:05:58 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Oct 2002 17:07:08 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: "King, Kimberly S." cc: "Ieprep (E-mail)" Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 In-reply-to: Your message of "Wed, 02 Oct 2002 11:29:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1381.1033574826@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Oct 2002 17:07:06 +0100 > GETS Example: User wishes to place GETS call from SIP phone to a phone in > the CSN (via a gateway). > > CASE A: The gateway doesn't support the priority scheme. It sure might be > nice if it understood that 710 was a valid area code and routed this to the > CSN for authorization and preferential treatment in the CSN using GETS. The > IP network or SIP carrier may have no particular relationship with the user. the 710 number and whatever services associated with it are two different and cascading items. 710 should be recognized by all LECs, CLECs, etc within the US. additional high probability of completion (HPC) services is in addition to that and may exist depending on the service contracted by the customer (ie, US govt). > Do the requirements assume any underlying relationship between the local IP > network or SIP carrier and the user? Should they? which "requirements" are you referring to? I ask because you talk of MLPP and the Pierce draft (which imo is presented more in terms of describing a service, and not really a set of requirements) as well as Henning's draft. If you are referringto Hennings draft, than in my opinion, the answer to your question should be no because Henning's draft is very narrow in scope and only aims at SIP, not what's underneath it. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 2 12:40:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27663 for ; Wed, 2 Oct 2002 12:40:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92Gg9g03363 for ieprep-archive@odin.ietf.org; Wed, 2 Oct 2002 12:42:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92Gg9v03360 for ; Wed, 2 Oct 2002 12:42:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27638 for ; Wed, 2 Oct 2002 12:40:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92GfKv03299; Wed, 2 Oct 2002 12:41:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92GeFv03218 for ; Wed, 2 Oct 2002 12:40:15 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27533 for ; Wed, 2 Oct 2002 12:38:12 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Wed, 2 Oct 2002 12:39:56 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002100212395616353 ; Wed, 02 Oct 2002 12:39:56 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 12:41:02 -0400 Message-Id: From: "King, Kimberly S." To: "'Ken Carlberg'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] overall issues and REQ-11 thru REQ-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Oct 2002 12:39:53 -0400 inline > -----Original Message----- > From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] > Sent: Wednesday, October 02, 2002 12:07 PM > > > Do the requirements assume any underlying relationship > between the local IP > > network or SIP carrier and the user? Should they? > > which "requirements" are you referring to? I ask because you talk of > MLPP and the Pierce draft (which imo is presented more in terms of > describing a service, and not really a set of requirements) as well > as Henning's draft. > I'm hoping that the requirements to be given to SIP/SIPPING will represent the requirements of the ieprep community (thus include the Assured Service needs). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 2 13:53:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00964 for ; Wed, 2 Oct 2002 13:53:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92Ht1Y08044 for ieprep-archive@odin.ietf.org; Wed, 2 Oct 2002 13:55:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92Ht1v08041 for ; Wed, 2 Oct 2002 13:55:01 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00910 for ; Wed, 2 Oct 2002 13:52:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92Hs8v07886; Wed, 2 Oct 2002 13:54:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92Hm0v07606 for ; Wed, 2 Oct 2002 13:48:00 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00628 for ; Wed, 2 Oct 2002 13:45:56 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g92HlnZC009202; Wed, 2 Oct 2002 13:47:49 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g92Hll5T019075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Oct 2002 13:47:49 -0400 (EDT) Message-ID: <3D9B3118.7070408@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Oct 2002 13:47:04 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > What involvement is needed by the local IP network or SIP carrier > for the user to make use of a gateway's ability to invoke GETS, MLPP or some > other service on the CSN? > > GETS Example: User wishes to place GETS call from SIP phone to a phone in > the CSN (via a gateway). > > CASE A: The gateway doesn't support the priority scheme. It sure might be > nice if it understood that 710 was a valid area code and routed this to the > CSN for authorization and preferential treatment in the CSN using GETS. The > IP network or SIP carrier may have no particular relationship with the user. This seems to be purely a configuration issue, requiring no further protocol work. The gateway would treat the SIP phone like a somewhat odd telephone extension, with the usual DTMF-based authorization. > > CASE B: The gateway does support the priority scheme. At that point, it is > a matter of policy, if the gateway and user do some exchange > authentication/authorization and gives the user preferential access to a > gateway port. Then the 710 call is routed to the CSN. The IP network or > SIP carrier may have no particular relationship with the user. I'm not sure if you consider "SIP network" = "gateway", but in any event, auth* would require some relationship to the user. Hard to authenticate somebody you haven't met, if indirectly (via some cert). > > CASE C: The gateway supports the priority scheme and the IP network or SIP > carrier also have a business relationship with the user (or GETS service). > In this case, the authentication/authorization could potentially be for the > entire GETS service. Not only is the user authorized for (perhaps > preferential) use of the gateway, the user is authorized for the full GETS > system and a true destination is entered by the gateway (i.e., perhaps the > user really wanted to call 202-555-1212). In this case, there are some > pretty explicit relationships assumed. > > So, what are we talking about? A is not interesting (no SIP protocol features involved); both B and C could happen, but, again, from a protocol perspective, I don't see why it matters. in case B, the user may have to authenticate twice, both via some challenge/response and DTMF, but that's a user interface issue. > > Maybe it is best left ambiguous since the schemes I've heard voiced here use > different techniques. The circuit-switched landline GETS model > authenticates in the PSTN (at particular IXCs) after the user dials the 710 > "area code". However, the traditional circuit-switched MLPP and GTPS > systems have their authentication built in based upon the physical line. Also, this strongly depends on the trust relationship between the various parties. I don't think that's something we want to get into, as it appears to be largely an operational issue. > > When moving MLPP to an IP environment (a.k.a. Assured Service) then it > appears > http://www.ietf.org/internet-drafts/draft-pierce-sipping-assured-service-02. > txt > > "It must be possible to verify that the calling party is authorized to > use the Assured Service and the requested precedence level value and > to take the appropriate action if the calling party attempts to use a > higher level." > The network operator and the assured service user seem to have a known > established relationship. It is my understanding (and I could be wrong) > that Assured Service is to be deployed on a priviate network where the local > IP networks and SIP carrier have an known relationship with the user. > > Do the requirements assume any underlying relationship between the local IP > network or SIP carrier and the user? Should they? No, I don't think they do (or should). I'm wary of attempting to write down all permutations and network configurations. Generally, the IETF seems to want to stay away from "business models" and network configurations and stick to things that are necessary for interoperation. I think your discussion and taxonomy is useful, just not something I would want to have to expand into an RFC... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 2 14:03:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01483 for ; Wed, 2 Oct 2002 14:03:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92I4qw08491 for ieprep-archive@odin.ietf.org; Wed, 2 Oct 2002 14:04:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92I4qv08488 for ; Wed, 2 Oct 2002 14:04:52 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01434 for ; Wed, 2 Oct 2002 14:02:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92I41v08458; Wed, 2 Oct 2002 14:04:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92I3vv08429 for ; Wed, 2 Oct 2002 14:03:57 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01407 for ; Wed, 2 Oct 2002 14:01:53 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g92I3pZC010143; Wed, 2 Oct 2002 14:03:51 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g92I3o5T020440 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Oct 2002 14:03:51 -0400 (EDT) Message-ID: <3D9B34DB.5090308@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Oct 2002 14:03:07 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > REQ-11: Identity-independent: The user identity is insufficient > to identify the priority level of the request. The same > identity can issue non-prioritized requests as well as > prioritized ones, with the range of priorities determined > by the job function of the caller. The choice of the > priority is made based on human judgement, following a set > of general rules that are likely to be applied by analogy > rather than precise mapping of each condition. For example, > a particular circumstance may be considered similarly grave > compared to one which is listed explicitly. > > > Comment: I think we are in new territory here. With MLPP, certain lines > are provisioned to be able to make calls at a prescribed level(s). With > traditional landline circuit-switched GETS, the user identity (+ PIN) is > sufficient to identify the priority of the call. In the U.K's Government > Telephone Preference Scheme, lines are divided into classes to determine > what lines get to place outgoing calls. So, I presume REQ-11 is directed > solely at the Topology B--IP at the Start? I suppose this depends on what you mean by 'user identity'. At the user-level, the GETS user still has the same identity (name, SSN, telephone number) whether placing a GETS call or not. You could view the GETS id+pin as another identity or as a credential for the same person, since the id+pin are (I would guess) not meant to be shared by several people. SIP makes the problem a bit more interesting since you have at least three identifiers: - your IP address - your From SIP URI - your authentication ID (Digest user name) You may have more with network-asserted IDs. Yes, this makes sense only in an IP-originated scenario, unless the gateway from the CSN effectively emulates a user (e.g., queries user via some kind of IVR system and then inserts this information into the SIP request). Also, as we discussed in other venues, I think it would be very useful if one could separate the notion of identity from privilege. > REQ-15: Testing: It must be possible to test the system outside > of emergency conditions, to increase the chances that all > elements work during an actual emergency. In particular, > critical elements such as indication, authentication, > authorization and call routing must be testable. > > I suspect what is really being requested is that the mechanism isn't > something that is switched on only during emergencies but rather something > that is always available if requested (and hence can be tested outside of > emergency situations). Noted. > > Comments? > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 2 18:28:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09922 for ; Wed, 2 Oct 2002 18:28:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92MTtM24746 for ieprep-archive@odin.ietf.org; Wed, 2 Oct 2002 18:29:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92MTtv24743 for ; Wed, 2 Oct 2002 18:29:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09918 for ; Wed, 2 Oct 2002 18:27:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92MQCv24667; Wed, 2 Oct 2002 18:26:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92MP6v24627 for ; Wed, 2 Oct 2002 18:25:06 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09874 for ; Wed, 2 Oct 2002 18:23:00 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 18:23:17 -0400 Message-ID: From: "Gunn, Janet" To: "'King, Kimberly S.'" , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-1 to REQ-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Oct 2002 18:23:07 -0400 -----Original Message----- From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] Sent: Monday, September 30, 2002 1:06 PM To: Ieprep (E-mail) Subject: [Ieprep] IEPREP SIP REQ-1 to REQ-5 It might be productive to go through Henning's http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-00.txt document to fix ideas and generate remarks on outstanding issues. We can take a phased approach where the first 5 requirements are listed below. Requirements 1,4,5 seem pretty clear and I asked a few questions of 2 and 3. Any comments? REQ-1: Not specific to one mechanism or country: The mechanism should not be specific to one country or particular priority mechanism. For example, there are currently at least four priority schemes in widespread use: Q.735, with five levels, the U.S. defense network and NATO with five levels, the United States GETS (Government Emergency Telecommunications Systems) scheme with implied higher priority and the British Government Telephone Preference Scheme (GTPS) system. JPG - Are Q.735, US DOD and NATO two different schemes, or just different names for the same schemes? Any particular implementation MAY be specific to a particular country or scheme. And not all schemes will be supported across IP networks. For instance, I find it hard to see how GTPS (which essentially addresses who gets "dial tone" could be implemented in, or across, an IP network. REQ-2: Independent of particular network architecture: The mechanism should work in the widest variety of SIP-based systems. It should not be restricted to particular operators or types of networks, such as wireless networks or protocol profiles and dialects in certain types of networks. How would one know if a proposed solution met REQ-2? If not restricted to particular operators or types of networks, does it mean it should work for all? The document lists 4 network models and 4 hybrid networks (or topologies). Does "network architecture" refer to these previously introduced items? JPG does this mean it should be consistent with the standardized protocol, and not take advantage of customizations or proprietary enhancements? REQ-3: Invisible to IP network: It should be possible to use the mechanism in IP networks that are unaware of the mechanism and in restricted networks. Obviously, such networks will not be able to provide enhanced services. Is "restricted network" the Restricted SIP networks defined earlier? If it must be possible to use the mechanism in restricted SIP networks yet in those networks "users may be restricted to particular SIP applications and cannot add SIP protocol elements such as header fields or use SIP methods beyond a proscribed set ", does this mean that the mechanism must be part of the default set of allowable applications and protocol elements? I recognize "such networks will not be able to provide enhanced services" but I'm trying to understand how the mechanism should be able to be used even if users are restricted from adding protocol elements without the mechanism being part of the default set. REQ-4: Usage of existing namespaces: Since there are a number of existing resource priority schemes for both the PSTN and private networks, it is likely that converged or VoIP networks will inherit these naming schemes. REQ-5: No loss of information: For the CN-IP-CN case, there should be no loss of signaling information caused by transiting the IP network. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 3 11:43:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19428 for ; Thu, 3 Oct 2002 11:43:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g93FjMS29111 for ieprep-archive@odin.ietf.org; Thu, 3 Oct 2002 11:45:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FjLv29108 for ; Thu, 3 Oct 2002 11:45:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19387 for ; Thu, 3 Oct 2002 11:43:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Fhgv28959; Thu, 3 Oct 2002 11:43:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FgIv28883 for ; Thu, 3 Oct 2002 11:42:18 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19072 for ; Thu, 3 Oct 2002 11:40:14 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Oct 2002 11:40:31 -0400 Message-ID: From: "Gunn, Janet" To: "'King, Kimberly S.'" , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 3 Oct 2002 11:40:21 -0400 -----Original Message----- From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] Sent: Monday, September 30, 2002 2:04 PM To: Ieprep (E-mail) Subject: [Ieprep] IEPREP SIP REQ-6 to REQ-10 Below are additional requirements from Henning's document http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-00.txt . I asked questions of 9 and 10. Any comments on any of these requirements? REQ-6: Extensibility: New naming schemes may need to be defined as resource priority mechanism are applied in additional private networks, or if a VoIP-specific priority scheme is being defined. [JPG] New priority schemes may be defined in the Circuit Switched Network, and will need to be able to interact with IP networks REQ-7: Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the requests invokes a certain named policy that may well have those properties. [JPG] Just a side note that this distinction also exists in the CSN side. For instance setting the Precedence (aka MLPP) parameter results in quite different behavior in a GSM mobile carrier's (wire line) network from the behavior in a DOD network. This also means that a CSN/IP gateway may need to consider the source/destination of the indication in implementing any associated policy. REQ-8: Request-neutral: The mechanism chosen should work for any SIP request, not just, say, INVITE. It is then a matter of policy as to whether marking a particular SIP request leads to differentiated treatment or whether a particular SIP request needs to request such treatment by non-SIP means. REQ-9: Default behavior: Network terminals configured to use priority scheme may occasionally end up making calls in a network that does not support such a scheme or the terminal may have an older list of priorities in a namespace. In those cases, the protocol must support a sensible default behavior that maximizes the chance for call completion without compromising network integrity. What is a sensible default behavior that maximizes the chance for call completion under circumstances where networks or terminals don't understand the scheme or have outdated information? Is regular SIP default call setup an acceptable solution? If not, does someone have an example solution of something satisfying the above requirement? [JPG] Again, a side note that may or may not be directly relevant. In the CSN, some priority schemes are "fail open" and some are not. I suspect a single type of "default behavior" for all priority schemes involving IP Telephony will not be appropriate. REQ-10: Address-neutral: The mechanism cannot rely on identifying a set of destination addresses or URI schemes. For example, in GETS-like schemes, the caller can reach any PSTN destination with increased probability of call completion, not just a limited set. It appears REQ-10 adds that any address or URI scheme is a valid destination. Let's assume REQ-14 is accepted (we can later debate this potential requirement in another thread covering this requirement). [JPG] Another side note/clarification. In a "GETS-like scheme", it may not be true that "the caller can reach any PSTN destination with increased probability of call completion." For instance, some users may be authorized to make international GETS calls, and other users may be restricted to domestic GETS calls. But it is certainly true that the mechanism cannot rely on a pre-identified set of destinations. "REQ-14: Discovery: A terminal should be able to discover which priority name spaces are supported by a network element. Discovery may be explicit, where a user agent requests a list of the supported name spaces or it may be implicit, where it attempts to use a particular name space and is then told that this name space is not supported." Does REQ-10, taken along with REQ-14, say all network elements must understand the mechanism (at least enough to provide a list of supported name spaces or enough to be tell the name space is not supported)? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 3 12:37:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23237 for ; Thu, 3 Oct 2002 12:37:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g93GdRC01045 for ieprep-archive@odin.ietf.org; Thu, 3 Oct 2002 12:39:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93GdRv01042 for ; Thu, 3 Oct 2002 12:39:27 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23192 for ; Thu, 3 Oct 2002 12:37:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93GcAv00941; Thu, 3 Oct 2002 12:38:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Gbfv00883 for ; Thu, 3 Oct 2002 12:37:41 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23101 for ; Thu, 3 Oct 2002 12:35:35 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g93GbPZC013543; Thu, 3 Oct 2002 12:37:25 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g93GbN5T003080 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Oct 2002 12:37:24 -0400 (EDT) Message-ID: <3D9C7216.3000406@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'King, Kimberly S.'" , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 03 Oct 2002 12:36:38 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [JPG] New priority schemes may be defined in the Circuit Switched Network, > and will need to be able to interact with IP networks Noted. > [JPG] Just a side note that this distinction also exists in the CSN side. > For instance setting the Precedence (aka MLPP) parameter results in quite > different behavior in a GSM mobile carrier's (wire line) network from the > behavior in a DOD network. This also means that a CSN/IP gateway may need > to consider the source/destination of the indication in implementing any > associated policy. Noted. > [JPG] Again, a side note that may or may not be directly relevant. In the > CSN, some priority schemes are "fail open" and some are not. I suspect a > single type of "default behavior" for all priority schemes involving IP > Telephony will not be appropriate. Certainly. > > [JPG] Another side note/clarification. In a "GETS-like scheme", it may not > be true that "the caller can reach any PSTN destination with increased > probability of call completion." For instance, some users may be authorized > to make international GETS calls, and other users may be restricted to > domestic GETS calls. But it is certainly true that the mechanism cannot > rely on a pre-identified set of destinations. The "cannot rely on a pre-identified set" is the main point I'm trying to make here. Any restrictions would be a matter of local policy, but not a protocol mechanism. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 3 15:55:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03002 for ; Thu, 3 Oct 2002 15:55:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g93JuV412005 for ieprep-archive@odin.ietf.org; Thu, 3 Oct 2002 15:56:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93JuQv12002 for ; Thu, 3 Oct 2002 15:56:26 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02989 for ; Thu, 3 Oct 2002 15:54:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93JtRv11981; Thu, 3 Oct 2002 15:55:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Jrsv11924 for ; Thu, 3 Oct 2002 15:53:54 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02944 for ; Thu, 3 Oct 2002 15:51:34 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Oct 2002 15:51:52 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] overall issues and REQ-11 thru REQ-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 3 Oct 2002 15:51:42 -0400 > REQ-11: Identity-independent: The user identity is insufficient > to identify the priority level of the request. The same > identity can issue non-prioritized requests as well as > prioritized ones, with the range of priorities determined > by the job function of the caller. The choice of the > priority is made based on human judgement, following a set > of general rules that are likely to be applied by analogy > rather than precise mapping of each condition. For example, > a particular circumstance may be considered similarly grave > compared to one which is listed explicitly. > Also, as we discussed in other venues, I think it would be very useful if one could separate the notion of identity from privilege. [JPG] In the US, the FCC has made it clear that any priority service on the PUBLIC CSN must be invoked on a call by call basis, not just on the basis of the identity of the user or the instrument. To the extent that IP telephony services will wish to interface with the US public phone network, it is ESSENTIAL that the notion of identity be separated from the notion of privilege. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 4 13:31:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14337 for ; Fri, 4 Oct 2002 13:31:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94HXOI22001 for ieprep-archive@odin.ietf.org; Fri, 4 Oct 2002 13:33:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HXOv21998 for ; Fri, 4 Oct 2002 13:33:24 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14306 for ; Fri, 4 Oct 2002 13:31:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HWRv21960; Fri, 4 Oct 2002 13:32:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HUmv21823 for ; Fri, 4 Oct 2002 13:30:48 -0400 Received: from imo-d10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14159 for ; Fri, 4 Oct 2002 13:28:42 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d10.mx.aol.com (mail_out_v34.13.) id a.35.2de74fa0 (25914); Fri, 4 Oct 2002 13:30:40 -0400 (EDT) Message-ID: <35.2de74fa0.2acf2a40@aol.com> Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 To: KIMBERLY.S.KING@saic.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_35.2de74fa0.2acf2a40_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Oct 2002 13:30:40 EDT --part1_35.2de74fa0.2acf2a40_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/2/2002 11:31:36 AM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes: > First, some overall issues: > > High-level Question: > > What involvement is needed by the local IP network or SIP carrier > for the user to make use of a gateway's ability to invoke GETS, MLPP or some > other service on the CSN? > > > > CASE B: The gateway does support the priority scheme. At that point, it is > a matter of policy, if the gateway and user do some exchange > authentication/authorization and gives the user preferential access to a > gateway port. Then the 710 call is routed to the CSN. The IP network or > SIP carrier may have no particular relationship with the user. > [MAP] As described above in Case B, seems this is a case in which the gateway supports only a part of the service (authenticates the user who dialed 710-, but doesn't handle entry of the actual destination number. As commented before, this should not be an accaptable operation, since it requires the user to perform 2 authentication functions, one with the gateway and one with the CSN that gets the 710- call and then requests entry of the real destination number. > > > When moving MLPP to an IP environment (a.k.a. Assured Service) then it > appears > http://www.ietf.org/internet-drafts/draft-pierce-sipping-assured-service-02. > txt > > "It must be possible to verify that the calling party is authorized to > use the Assured Service and the requested precedence level value and > to take the appropriate action if the calling party attempts to use a > higher level." > The network operator and the assured service user seem to have a known > established relationship. It is my understanding (and I could be wrong) > that Assured Service is to be deployed on a priviate network where the local > IP networks and SIP carrier have an known relationship with the user. > [MAP] This basic requirement to authenticate the user may be satisfied in different ways. Yes, Assured Service is intended for a "private network", but unfortunately, that term is losing its meaning, or becoming non-explicit. Yes, the network operator and the user must have a known relationship. (Note that this presumes that there really is a "network operator" here.) > Do the requirements assume any underlying relationship between the local IP > network or SIP carrier and the user? [MAP] Yes, there must also be a known relationship here. > Onward...the remaining requirements > > REQ-11: Identity-independent: The user identity is insufficient > to identify the priority level of the request. The same > identity can issue non-prioritized requests as well as > prioritized ones, with the range of priorities determined > by the job function of the caller. The choice of the > priority is made based on human judgement, following a set > of general rules that are likely to be applied by analogy > rather than precise mapping of each condition. For example, > a particular circumstance may be considered similarly grave > compared to one which is listed explicitly. > > > Comment: I think we are in new territory here. With MLPP, certain lines > are provisioned to be able to make calls at a prescribed level(s). With > traditional landline circuit-switched GETS, the user identity (+ PIN) is > sufficient to identify the priority of the call. In the U.K's Government > Telephone Preference Scheme, lines are divided into classes to determine > what lines get to place outgoing calls. So, I presume REQ-11 is directed > [MAP] GETS had only one level because of the signaling limitations at the time. IEPS should be approached from the assumption that some users would need multiple levels, like MLPP, so that the priority is not automatically implied by the user identity. > > REQ-15: Testing: It must be possible to test the system outside > of emergency conditions, to increase the chances that all > elements work during an actual emergency. In particular, > critical elements such as indication, authentication, > authorization and call routing must be testable. > > I suspect what is really being requested is that the mechanism isn't > something that is switched on only during emergencies but rather something > that is always available if requested (and hence can be tested outside of > [MAP} One could instead state the obvious requirement: "The system must be turned on at all times, that is, it must not require service provider actions to enable its use." Mike Pierce Artel --part1_35.2de74fa0.2acf2a40_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/2/2002 11:31:36 AM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes:


First, some overall issues:  

High-level Question:

What involvement is needed by the local IP network or SIP carrier
for the user to make use of a gateway's ability to invoke GETS, MLPP or some
other service on the CSN?

<snip>

CASE B:  The gateway does support the priority scheme.  At that point, it is
a matter of policy, if the gateway and user do some exchange
authentication/authorization and gives the user preferential access to a
gateway port.  Then the 710 call is routed to the CSN.  The IP network or
SIP carrier may have no particular relationship with the user.



[MAP] As described above in Case B, seems this is a case in which the gateway supports only a part of the service (authenticates the user who dialed 710-, but doesn't handle entry of the actual destination number. As commented before, this should not be an accaptable operation, since it requires the user to perform 2 authentication functions, one with the gateway and one with the CSN that gets the 710- call and then requests entry of the real destination number.

<snip>

When moving MLPP to an IP environment (a.k.a. Assured Service) then it
appears
http://www.ietf.org/internet-drafts/draft-pierce-sipping-assured-service-02.
txt

"It must be possible to verify that the calling party is authorized to
  use the Assured Service and the requested precedence level value and
  to take the appropriate action if the calling party attempts to use a
  higher level."  
The network operator and the assured service user seem to have a known
established relationship.  It is my understanding (and I could be wrong)
that Assured Service is to be deployed on a priviate network where the local
IP networks and SIP carrier have an known relationship with the user.




[MAP] This basic requirement to authenticate the user may be satisfied in different ways. Yes, Assured Service is intended for a "private network", but unfortunately, that term is losing its meaning, or becoming non-explicit. Yes, the network operator and the user must have a known relationship. (Note that this presumes that there really is a "network operator" here.)

Do the requirements assume any underlying relationship between the local IP
network or SIP carrier and the user?  Should they?



[MAP] Yes, there must also be a known relationship here.


Onward...the remaining requirements

       REQ-11: Identity-independent: The user identity is insufficient
            to identify the priority level of the request. The same
            identity can issue non-prioritized requests as well as
            prioritized ones, with the range of priorities determined
            by the job function of the caller. The choice of the
            priority is made based on human judgement, following a set
            of general rules that are likely to be applied by analogy
            rather than precise mapping of each condition. For example,
            a particular circumstance may be considered similarly grave
            compared to one which is listed explicitly.


Comment:  I think we are in new territory here.  With MLPP, certain lines
are provisioned to be able to make calls at a prescribed level(s).  With
traditional landline circuit-switched GETS, the user identity (+ PIN) is
sufficient to identify the priority of the call.  In the U.K's Government
Telephone Preference Scheme, lines are divided into classes to determine
what lines get to place outgoing calls.  So, I presume REQ-11 is directed
solely at the Topology B--IP at the Start?



[MAP] GETS had only one level because of the signaling limitations at the time. IEPS should be approached from the assumption that some users would need multiple levels, like MLPP, so that the priority is not automatically implied by the user identity.

<snip>

       REQ-15: Testing: It must be possible to test the system outside
            of emergency conditions, to increase the chances that all
            elements work during an actual emergency. In particular,
            critical elements such as indication, authentication,
            authorization and call routing must be testable.

I suspect what is really being requested is that the mechanism isn't
something that is switched on only during emergencies but rather something
that is always available if requested (and hence can be tested outside of
emergency situations).



[MAP} One could instead state the obvious requirement: "The system must be turned on at all times, that is, it must not require service provider actions to enable its use."

Mike Pierce
Artel

--part1_35.2de74fa0.2acf2a40_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 09:05:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14310 for ; Wed, 9 Oct 2002 09:05:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99D7VK20350 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 09:07:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99D7Vv20347 for ; Wed, 9 Oct 2002 09:07:31 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14302 for ; Wed, 9 Oct 2002 09:05:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99D6cv19765; Wed, 9 Oct 2002 09:06:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99D50v19684 for ; Wed, 9 Oct 2002 09:05:00 -0400 Received: from imo-r08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14236 for ; Wed, 9 Oct 2002 09:02:51 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v34.13.) id a.3f.1308a7da (25914); Wed, 9 Oct 2002 09:04:50 -0400 (EDT) Message-ID: <3f.1308a7da.2ad58372@aol.com> Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 To: KIMBERLY.S.KING@saic.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_3f.1308a7da.2ad58372_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Oct 2002 09:04:50 EDT --part1_3f.1308a7da.2ad58372_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/30/2002 2:10:22 PM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes: > REQ-7: Separation of indication and policy: The indication > should not describe a particular detailed treatment, as it > is likely that this depends on the nature of the resource > and local policy. Instead, it should invoke a particular > named policy. As an example, instead of specifying that a > certain SIP request should be granted queueing priority, > not cause preemption, but be restricted to three-minute > sessions, the requests invokes a certain named policy that > may well have those properties. > The above seems so intuitively obvious to me that I wonder why it is even necessary to state it. Or else, maybe it has some completely different meaning or connotation than what I think it means. I don't think I have heard any proposal, nor can I think of one, that would not comply with this, but I'm afraid it means something more to someone. I believe there was a comment once, which I took as only half serious, to the effect that one would not code a priority as "Queue me first, preempt lower priority traffic, don't drop my packets". (Of course, SIP actually allows coding like this!) If two priority values are "low" and "high", would someone claim that this violates the above requirement? The "indication" certainly describes something about the treament. Mike Pierce Artel --part1_3f.1308a7da.2ad58372_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/30/2002 2:10:22 PM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes:


       REQ-7: Separation of indication and policy: The indication
            should not describe a particular detailed treatment, as it
            is likely that this depends on the nature of the resource
            and local policy.  Instead, it should invoke a particular
            named policy. As an example, instead of specifying that a
            certain SIP request should be granted queueing priority,
            not cause preemption, but be restricted to three-minute
            sessions, the requests invokes a certain named policy that
            may well have those properties.





The above seems so intuitively obvious to me that I wonder why it is even necessary to state it. Or else, maybe it has some completely different meaning or connotation than what I think it means.

I don't think I have heard any proposal, nor can I think of one, that would not comply with this, but I'm afraid it means something more to someone. I believe there was a comment once, which I took as only half serious, to the effect that one would not code a priority as "Queue me first, preempt lower priority traffic, don't drop my packets". (Of course, SIP actually allows coding like this!)

If two priority values are "low" and "high", would someone claim that this violates the above requirement? The "indication" certainly describes something about the treament.

Mike Pierce
Artel
--part1_3f.1308a7da.2ad58372_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 09:26:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15437 for ; Wed, 9 Oct 2002 09:26:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99DS3f21295 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 09:28:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99DS3v21292 for ; Wed, 9 Oct 2002 09:28:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15416 for ; Wed, 9 Oct 2002 09:25:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99DR7v21260; Wed, 9 Oct 2002 09:27:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99DQhv21228 for ; Wed, 9 Oct 2002 09:26:43 -0400 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15315 for ; Wed, 9 Oct 2002 09:24:33 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.49]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g99DQZlR004509 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Oct 2002 09:26:36 -0400 (EDT) Message-ID: <3DA42E27.4070204@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: KIMBERLY.S.KING@saic.com, ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 References: <3f.1308a7da.2ad58372@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Oct 2002 09:24:55 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The above seems so intuitively obvious to me that I wonder why it is > even necessary to state it. Or else, maybe it has some completely > different meaning or connotation than what I think it means. There was fear that this might not be obvious to all. > > I don't think I have heard any proposal, nor can I think of one, that > would not comply with this, but I'm afraid it means something more to > someone. I believe there was a comment once, which I took as only half > serious, to the effect that one would not code a priority as "Queue me > first, preempt lower priority traffic, don't drop my packets". (Of > course, SIP actually allows coding like this!) > > If two priority values are "low" and "high", would someone claim that > this violates the above requirement? The "indication" certainly > describes something about the treament. I think the litmus test is that one should be able to specify, for each such label, at least two independent and interoperable implementations that are different in the behavioral details (such as queueing, dropping, rerouting, traffic controls, etc.). On the other hand, I don't think we can rule out that if some three-letter agency specifies the implementation precisely ("must implement absolute priority with preemption of existing calls"), that this is always achievable. The classical example that would not necessarily satisfy this requirement would be the old IPv4 TOS bits ("low delay", "high reliability"). Also, in order to make progress, it may be useful to "forgive" some obviousness in the document and heave this thing (after another round) over the fence to SIPPING, even if one could save a few bytes in the RFC and I-D archive. > > Mike Pierce > Artel _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 09:32:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15683 for ; Wed, 9 Oct 2002 09:32:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99DYJh21597 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 09:34:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99DYJv21594 for ; Wed, 9 Oct 2002 09:34:19 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15666 for ; Wed, 9 Oct 2002 09:32:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99DX3v21537; Wed, 9 Oct 2002 09:33:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99DW5v21504 for ; Wed, 9 Oct 2002 09:32:05 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15559 for ; Wed, 9 Oct 2002 09:29:55 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Wed, 9 Oct 2002 09:28:19 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002100909282004489 for ; Wed, 09 Oct 2002 09:28:20 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QRX11>; Wed, 9 Oct 2002 09:29:28 -0400 Message-Id: From: "King, Kimberly S." To: "'Mpierce1@aol.com'" , KIMBERLY.S.KING@saic.com, ieprep@ietf.org Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Oct 2002 09:28:19 -0400 Mike, "The above seems so intuitively obvious to me that I wonder why it is even necessary to state it. Or else, maybe it has some completely different meaning or connotation than what I think it means. " It may have a different meaning. It makes sense to allow labels in standards. For example, I might want to have labels saying CodeBlue, CodeRed, CodeGreen. These labels just make it easy to identify things. But it is policy that gives them meaning and policy might be different in your network than mine. You might say CodeBlue traffic means "Queue me first, drop lower priority traffic before dropping my packets" where you define lower priority is CodeGreen. I might have a different policy on my network. Also, you might find the policy didn't produce the behavior that you wanted. You don't need to change the standard, you just change your local policy (the way you allocate resources and the allocation can be based upon classifications given by labels). So, while the point might seem obvious, I think it is worth stating. It comes from some IETF history where policies were enmeshed with labels and things didn't work out. I hope this helps. Kimberly -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, October 09, 2002 9:05 AM To: KIMBERLY.S.KING@saic.com; ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 In a message dated 9/30/2002 2:10:22 PM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes: REQ-7: Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the requests invokes a certain named policy that may well have those properties. The above seems so intuitively obvious to me that I wonder why it is even necessary to state it. Or else, maybe it has some completely different meaning or connotation than what I think it means. I don't think I have heard any proposal, nor can I think of one, that would not comply with this, but I'm afraid it means something more to someone. I believe there was a comment once, which I took as only half serious, to the effect that one would not code a priority as "Queue me first, preempt lower priority traffic, don't drop my packets". (Of course, SIP actually allows coding like this!) If two priority values are "low" and "high", would someone claim that this violates the above requirement? The "indication" certainly describes something about the treament. Mike Pierce Artel _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 09:49:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16684 for ; Wed, 9 Oct 2002 09:49:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99Dp8f22889 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 09:51:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Dp8v22886 for ; Wed, 9 Oct 2002 09:51:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16672 for ; Wed, 9 Oct 2002 09:48:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Do6v22824; Wed, 9 Oct 2002 09:50:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Dnev22782 for ; Wed, 9 Oct 2002 09:49:40 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16549 for ; Wed, 9 Oct 2002 09:47:30 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Oct 2002 14:49:01 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Henning Schulzrinne cc: Mpierce1@aol.com, KIMBERLY.S.KING@saic.com, ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 In-reply-to: Your message of "Wed, 09 Oct 2002 09:24:55 EDT." <3DA42E27.4070204@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1352.1034171339@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Oct 2002 14:48:59 +0100 > Also, in order to make progress, it may be useful to "forgive" some > obviousness in the document and heave this thing (after another round) > over the fence to SIPPING, even if one could save a few bytes in the RFC > and I-D archive. yes, please do!!! -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 10:35:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19810 for ; Wed, 9 Oct 2002 10:35:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99EawV26094 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 10:36:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Eawv26091 for ; Wed, 9 Oct 2002 10:36:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19777 for ; Wed, 9 Oct 2002 10:34:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Ea7v26061; Wed, 9 Oct 2002 10:36:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99EZBv26013 for ; Wed, 9 Oct 2002 10:35:11 -0400 Received: from bootstrap.agcs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19703 for ; Wed, 9 Oct 2002 10:33:01 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id HAA10785 for ; Wed, 9 Oct 2002 07:35:06 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id H3PXUI00.JZ7 for ; Wed, 9 Oct 2002 07:35:06 -0700 Received: FROM agcs.com BY mkultra ; Wed Oct 09 07:35:05 2002 -0700 Message-ID: <3DA43E99.6EA7C73@agcs.com> From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "King Kimberly S." CC: "'Mpierce1@aol.com'" , ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 References: Content-Type: multipart/mixed; boundary="------------9A07D1015366A816008A2820" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Oct 2002 07:35:05 -0700 This is a multi-part message in MIME format. --------------9A07D1015366A816008A2820 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike, I also think there is value in isolating the labels from the policy. If I had an ordered list of priorities such as 1, 2, 3, ...N. It would be difficult to introduce a new label and policy in the middle such as 2.5. Also, the policies associated with a pair of labels may result in different treatment based on the wishes of the user, but not imply that one label had "more preference" than the other. "King, Kimberly S." wrote: > Mike, > > "The above seems so intuitively obvious to me that I wonder why it is even > necessary to state it. Or else, maybe it has some completely different > meaning or connotation than what I think it means. " > > It may have a different meaning. It makes sense to allow labels in > standards. For example, I might want to have labels saying CodeBlue, > CodeRed, CodeGreen. These labels just make it easy to identify things. > > But it is policy that gives them meaning and policy might be different in > your network than mine. You might say CodeBlue traffic means "Queue me > first, drop lower priority traffic before dropping my packets" where you > define lower priority is CodeGreen. I might have a different policy on my > network. > > Also, you might find the policy didn't produce the behavior that you wanted. > You don't need to change the standard, you just change your local policy > (the way you allocate resources and the allocation can be based upon > classifications given by labels). > > So, while the point might seem obvious, I think it is worth stating. It > comes from some IETF history where policies were enmeshed with labels and > things didn't work out. > > I hope this helps. > > Kimberly > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Wednesday, October 09, 2002 9:05 AM > To: KIMBERLY.S.KING@saic.com; ieprep@ietf.org > Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 > > In a message dated 9/30/2002 2:10:22 PM Eastern Standard Time, > KIMBERLY.S.KING@saic.com writes: > > REQ-7: Separation of indication and policy: The indication > should not describe a particular detailed treatment, as it > is likely that this depends on the nature of the resource > and local policy. Instead, it should invoke a particular > named policy. As an example, instead of specifying that a > certain SIP request should be granted queueing priority, > not cause preemption, but be restricted to three-minute > sessions, the requests invokes a certain named policy that > may well have those properties. > > The above seems so intuitively obvious to me that I wonder why it is even > necessary to state it. Or else, maybe it has some completely different > meaning or connotation than what I think it means. > > I don't think I have heard any proposal, nor can I think of one, that would > not comply with this, but I'm afraid it means something more to someone. I > believe there was a comment once, which I took as only half serious, to the > effect that one would not code a priority as "Queue me first, preempt lower > priority traffic, don't drop my packets". (Of course, SIP actually allows > coding like this!) > > If two priority values are "low" and "high", would someone claim that this > violates the above requirement? The "indication" certainly describes > something about the treament. > > Mike Pierce > Artel > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------9A07D1015366A816008A2820 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org:AG Communication Systems adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;-12184 fn:Stuart Goldman end:vcard --------------9A07D1015366A816008A2820-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 12:06:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23433 for ; Wed, 9 Oct 2002 12:06:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99G7lP00590 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 12:07:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G7lv00587 for ; Wed, 9 Oct 2002 12:07:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23427 for ; Wed, 9 Oct 2002 12:05:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G79v32672; Wed, 9 Oct 2002 12:07:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G6ov32439 for ; Wed, 9 Oct 2002 12:06:50 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23413 for ; Wed, 9 Oct 2002 12:04:41 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Oct 2002 17:06:28 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: ieprep@ietf.org Cc: rja@extremenetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1639.1034179586@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] policy & labels Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Oct 2002 17:06:26 +0100 there has been a recurring discussion about policy and labels -- people for it, against it, confused by its separation, etc. so it may be helpful to have a separate discussion about the subject so that we can put it to rest andmove on to other stuff. so, to start the fun, lets see how the following statement grabs folks... ------------------------------- The process of distinguishing traffic by means of a label can be accomplished in one of two ways. The first is with a single label, which acts as a binary on/off indicator distinguishing a set of data/flows from all other data/flows. The characteristics (e.g., drop precedence) that one may apply to this single labeled traffic versus all other traffic is what is refered to as policy. In addition, the type of traffic (VoIP, ftp, http, etc.) associated with a label is a separate issue and defined via a policy. Another way of distinguishing traffic is to use a set of *related* labels. This set may convey various measures of a characteristic that is internal to that set. An example of this case is the Assured Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in RFC2597. Within each AF class, M different levels of drop level precedence may be assigned to an IP packet. Note that the exact level of drop precendence is not defined for any level. Further, different classes, and different PHBs, are unrelated. From this example, we can make a more general statement and say that one may choose to attribute a type of characteristic to a related set of labels. However, the characteristics between one set of defined labels to all other sets of unrelated labels is separate and not part of the defined label set. ------------------------------- Does the above seem reasonable statement to make? Does it need to be more precise, more constrained, less constrained? let thine arrows fly forth :-) -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 15:54:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01643 for ; Wed, 9 Oct 2002 15:54:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99JuKi13810 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 15:56:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99JuKv13807 for ; Wed, 9 Oct 2002 15:56:20 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01635 for ; Wed, 9 Oct 2002 15:54:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99JtYv13787; Wed, 9 Oct 2002 15:55:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Js5v13749 for ; Wed, 9 Oct 2002 15:54:05 -0400 Received: from imo-m07.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01569 for ; Wed, 9 Oct 2002 15:51:53 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m07.mx.aol.com (mail_out_v34.13.) id i.106.198e8d89 (3940); Wed, 9 Oct 2002 15:53:52 -0400 (EDT) Message-ID: <106.198e8d89.2ad5e34f@aol.com> Subject: Re: [Ieprep] policy & labels To: K.Carlberg@cs.ucl.ac.uk, ieprep@ietf.org CC: rja@extremenetworks.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_106.198e8d89.2ad5e34f_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Oct 2002 15:53:51 EDT --part1_106.198e8d89.2ad5e34f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/9/2002 12:08:24 PM Eastern Standard Time, K.Carlberg@cs.ucl.ac.uk writes: > there has been a recurring discussion about policy and labels -- people > for it, against it, confused by its separation, etc. so it may be helpful > to have a separate discussion about the subject so that we can put it to > rest andmove on to other stuff. > > so, to start the fun, lets see how the following statement grabs folks... > > ------------------------------- > > The process of distinguishing traffic by means of a label can be > accomplished in one of two ways. The first is with a single label, > which acts as a binary on/off indicator distinguishing a set of > data/flows from all other data/flows. The characteristics (e.g., drop > precedence) that one may apply to this single labeled traffic versus > all other traffic is what is refered to as policy. In addition, the > type of traffic (VoIP, ftp, http, etc.) associated with a label is a > separate issue and defined via a policy. > > Another way of distinguishing traffic is to use a set of *related* > labels. This set may convey various measures of a characteristic that > is internal to that set. An example of this case is the Assured > Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in > RFC2597. Within each AF class, M different levels of drop level > precedence may be assigned to an IP packet. Note that the exact level > of drop precendence is not defined for any level. Further, different > classes, and different PHBs, are unrelated. > > From this example, we can make a more general statement and say that > one may choose to attribute a type of characteristic to a related set > of labels. However, the characteristics between one set of defined > labels to all other sets of unrelated labels is separate and not part > of the defined label set. > > ------------------------------- > > > Does the above seem reasonable statement to make? Does it need to be > more precise, more constrained, less constrained? > > let thine arrows fly forth :-) > > -ken > I'm sure there will be a lot of responses, which will only point out the confusion on this issue. Mine: The above doesn't help me understand the point. This discussion started with "indication" and "policy" and my question related to what it means to say that there must be a "separation" between them. I know that there have been previous statements about "labels" and "policy" and I've been trying to understand what that means for some time. I've worked on signaling protocols for many years and no one ever had to make such a distinction. We defined protocols with data fields, defined values to go in those fields, and defined meanings for those values. And the protocol usually defined the procedures to go along with those meanings/values. Never a problem. So why is this now such a big deal? I think this whole thing about "policy" vs" "label" (or "indication") is a non-issue and should be dropped so we can get on with defining what is needed. Henning noted that the old IPv4 TOS bits ("low delay" and "high reliability") were examples of not satisfying this requirement, I presume meaning that the "indication" and "policy" are not separated. I still don't know what that means. If the signaling requirement is to signal two things: "low delay needed" or "normal delay acceptable", it makes sense to define a bit where the "true" value means "low delay needed". Maybe this is short-sighted if there were later a need to signal "medium delay required", but that doesn't make it wrong. In this case, it seems to me that "separation" of the "indication" and the "policy" would mean that the protocol definition (standard) would have to say: 0 = treatment a 1 = treatment b and the "policy" in each device (not in the standard) would somehow know that: a = normal delay b = low delay needed If that approach were followed for every field or piece of information in the protocol, the specification would look pretty silly, and I seriously doubt that sufficient interoperability would ever occur. I question what this requirement means, since I think some will use it to say that the protocol can't define a priority parameter with values like "low", "medium", and "high". Mike Pierce Artel --part1_106.198e8d89.2ad5e34f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/9/2002 12:08:24 PM Eastern Standard Time, K.Carlberg@cs.ucl.ac.uk writes:


there has been a recurring discussion about policy and labels -- people
for it, against it, confused by its separation, etc.  so it may be helpful
to have a separate discussion about the subject so that we can put it to
rest andmove on to other stuff.

so, to start the fun, lets see how the following statement grabs folks...

-------------------------------

 The process of distinguishing traffic by means of a label can be
 accomplished in one of two ways.  The first is with a single label,
 which acts as a binary on/off indicator distinguishing a set of
 data/flows from all other data/flows.  The characteristics (e.g., drop
 precedence) that one may apply to this single labeled traffic versus
 all other traffic is what is refered to as policy.  In addition, the
 type of traffic (VoIP, ftp, http, etc.) associated with a label is a
 separate issue and defined via a policy.  

 Another way of distinguishing traffic is to use a set of *related*
 labels. This set may convey various measures of a characteristic that
 is internal to that set.  An example of this case is the Assured
 Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in
 RFC2597.  Within each AF class, M different levels of drop level
 precedence may be assigned to an IP packet.  Note that the exact level
 of drop precendence is not defined for any level.  Further, different
 classes, and different PHBs, are unrelated.

 From this example, we can make a more general statement and say that
 one may choose to attribute a type of characteristic to a related set
 of labels.  However, the characteristics between one set of defined
 labels to all other sets of unrelated labels is separate and not part
 of the defined label set.  

-------------------------------


Does the above seem reasonable statement to make?  Does it need to be
more precise, more constrained, less constrained?

let thine arrows fly forth :-)

-ken




I'm sure there will be a lot of responses, which will only point out the confusion on this issue.

Mine: The above doesn't help me understand the point. This discussion started with "indication" and "policy" and my question related to what it means to say that there must be a "separation" between them. I know that there have been previous statements about "labels" and "policy" and I've been trying to understand what that means for some time. I've worked on signaling protocols for many years and no one ever had to make such a distinction. We defined protocols with data fields, defined values to go in those fields, and defined meanings for those values. And the protocol usually defined the procedures to go along with those meanings/values. Never a problem.

So why is this now such a big deal? I think this whole thing about "policy" vs" "label" (or "indication") is a non-issue and should be dropped so we can get on with defining what is needed.

Henning noted that the old IPv4 TOS bits ("low delay" and "high reliability") were examples of not satisfying this requirement, I presume meaning that the "indication" and "policy" are not separated. I still don't know what that means. If the signaling requirement is to signal two things: "low delay needed" or "normal delay acceptable", it makes sense to define a bit where the "true" value means "low delay needed". Maybe this is short-sighted if there were later a need to signal "medium delay required", but that doesn't make it wrong. In this case, it seems to me that "separation" of the "indication" and the "policy" would mean that the protocol definition (standard) would have to say:
0 = treatment a
1 = treatment b

and the "policy" in each device (not in the standard) would somehow know that:
a = normal delay
b = low delay needed

If that approach were followed for every field or piece of information in the protocol, the specification would look pretty silly, and I seriously doubt that sufficient interoperability would ever occur.

I question what this requirement means, since I think some will use it to say that the protocol can't define a priority parameter with values like "low", "medium", and "high".

Mike Pierce
Artel
--part1_106.198e8d89.2ad5e34f_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 9 17:15:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04989 for ; Wed, 9 Oct 2002 17:15:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99LH6k19289 for ieprep-archive@odin.ietf.org; Wed, 9 Oct 2002 17:17:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99LH6v19286 for ; Wed, 9 Oct 2002 17:17:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04986 for ; Wed, 9 Oct 2002 17:14:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99LGKv19248; Wed, 9 Oct 2002 17:16:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99LFcv19224 for ; Wed, 9 Oct 2002 17:15:38 -0400 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04965 for ; Wed, 9 Oct 2002 17:13:26 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g99LFMlR013431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Oct 2002 17:15:23 -0400 (EDT) Message-ID: <3DA49C04.1090708@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Carlberg CC: ieprep@ietf.org, rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels References: <1639.1034179586@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Oct 2002 17:13:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My 2c (Euro): I think there are actually two separate problems here, binding and specificity. As usual in networking, this is partially a question of indirection or bindings, I think. Any protocol identifier value can either mean a specific thing or be bound to a specific interpretation at "run time" or per "session". This binding can be more-or-less-static, as part of some profile (generally bad), or dynamically signaled, as, say, the binding between RTP payload type numbers and codecs is in SDP. (SIP is, at heart, a binding protocol.) Late binding is necessary if, for efficiency reasons, the space of the identifier is insufficient to contain all possible values and if only a small set is likely to be needed at the same time. This is, generally, not the case for text-based protocols, as there is no shortage of label space. (It's equivalent to a variable-length integer of unbounded length.) Thus, dynamic binding of some short identifier to the "real" thing is not necessary here and likely to be counterproductive. If my understanding of DiffServ is correct, there is a recommended DSCP for each PHB, but one could bind one locally, with a yet-to-be-specified mechanism. One reason is that the DSCP is very short (6 bits), so running out of code points is a very real problem. A separate question is the level of detail that is specified; this is sometimes referred to as "policy vs. mechanism". A crude way to put this might be "externally visible behavior vs. local implementation". For example, it may be sufficient to specify that "for the same call, if you only change the labeling, it should not get worse treatment". This avoids having to specify behavior which may be left to local capabilities, such as displacement of existing calls. In general, I think you want the minimum amount of mechanism detail so as to give maximum freedom to implementations to optimize for local circumstances ("narrow interface"). As one example, the PHBs don't specify precisely how the queueing mechanism needs to be implemented or, as another example, IntServ guaranteed service doesn't specify the precise algorithm, just the externally visible behavior, even though there's only one known mechanism to implement it precisely. In our case, however, we are mostly "importing" external descriptions. The specificity of the behavior description is given by others. SIP is just the messenger. This argues, in particular, that we can't just have a limited set of mechanisms ("don't queue", "preempt"), as that would make extensions difficult. (On the other hand, if you know you can exhaustively specify the list of behaviors, it's clearly better to do that, as it reduces the number of failure cases. You can then test for all bit combinations and know that nobody can surprise you.) It does not, in my opinion, rule out a reference to a very detailed scheme. Similarly, in principle, you could have fairly detailed PHB descriptions that govern all relevant packet treatment. Indeed, recent history is an indication that too abstract a specification may not be implementable at all, leading to a more precise (and thus constraining) specification. Clearly, this is not a bright line, to the left of which lies sainthood and to the right religious dogma. (One could draw parallels that religious denominations come to different conclusions as to how much their relevant texts are policy vs. mechanism, but I won't go there.) I don't think anybody in the group is arguing that we should have an exhaustive set of behavior descriptions, where the labeling is some combination of these parameters. This does not mean that, as argued above, that you need to apply additional layers of indirection. At the danger of more analogies, the problem is not dissimilar to including URIs with multiple schemes (which SIP does a lot...). Relevant end systems need to know what to do with them, but the protocol itself can be fairly open to new ones, without affecting the core protocol functionality itself. Ken Carlberg wrote: > there has been a recurring discussion about policy and labels -- people > for it, against it, confused by its separation, etc. so it may be helpful > to have a separate discussion about the subject so that we can put it to > rest andmove on to other stuff. > > so, to start the fun, lets see how the following statement grabs folks... > > ------------------------------- > > The process of distinguishing traffic by means of a label can be > accomplished in one of two ways. The first is with a single label, > which acts as a binary on/off indicator distinguishing a set of > data/flows from all other data/flows. The characteristics (e.g., drop > precedence) that one may apply to this single labeled traffic versus > all other traffic is what is refered to as policy. In addition, the > type of traffic (VoIP, ftp, http, etc.) associated with a label is a > separate issue and defined via a policy. > > Another way of distinguishing traffic is to use a set of *related* > labels. This set may convey various measures of a characteristic that > is internal to that set. An example of this case is the Assured > Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in > RFC2597. Within each AF class, M different levels of drop level > precedence may be assigned to an IP packet. Note that the exact level > of drop precendence is not defined for any level. Further, different > classes, and different PHBs, are unrelated. > > From this example, we can make a more general statement and say that > one may choose to attribute a type of characteristic to a related set > of labels. However, the characteristics between one set of defined > labels to all other sets of unrelated labels is separate and not part > of the defined label set. > > ------------------------------- > > > Does the above seem reasonable statement to make? Does it need to be > more precise, more constrained, less constrained? > > let thine arrows fly forth :-) > > -ken > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 11:57:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10788 for ; Thu, 10 Oct 2002 11:57:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AFwgQ18970 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 11:58:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFwfv18967 for ; Thu, 10 Oct 2002 11:58:41 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10741 for ; Thu, 10 Oct 2002 11:56:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFvGv18902; Thu, 10 Oct 2002 11:57:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFuDv18841 for ; Thu, 10 Oct 2002 11:56:13 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10124 for ; Thu, 10 Oct 2002 11:54:01 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 11:54:22 -0400 Message-ID: From: "Gunn, Janet" To: "'Ken Carlberg'" , ieprep@ietf.org Cc: rja@extremenetworks.com Subject: RE: [Ieprep] policy & labels MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 11:54:12 -0400 OK, I am going to be as simplistic as possible. At the root of it, there need to be enough different labels that there is at least a one-to-one mapping (could be many-to-one) from label to policy in any given environment. If we want to have N different policies in a given environment, there must be at least N different labels. An "environment" could be the whole Internet, a particular subnetwork, or even a single router or gateway. This does not prevent a single label being associated with several different policies in several different environments, though this should generally be discouraged (for human comprehension reasons as much as anything), except when the policies are very closely related. So, we need to have figured out in advance how many different policies we will want in effect in a given environment. Then we can figure out what parameters are needed to create those labels. (I am using "labels" in a broad sense. If you have two parameters, each of which can have 3 values, I would call that 9 labels.) -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Wednesday, October 09, 2002 12:06 PM To: ieprep@ietf.org Cc: rja@extremenetworks.com Subject: [Ieprep] policy & labels there has been a recurring discussion about policy and labels -- people for it, against it, confused by its separation, etc. so it may be helpful to have a separate discussion about the subject so that we can put it to rest andmove on to other stuff. so, to start the fun, lets see how the following statement grabs folks... ------------------------------- The process of distinguishing traffic by means of a label can be accomplished in one of two ways. The first is with a single label, which acts as a binary on/off indicator distinguishing a set of data/flows from all other data/flows. The characteristics (e.g., drop precedence) that one may apply to this single labeled traffic versus all other traffic is what is refered to as policy. In addition, the type of traffic (VoIP, ftp, http, etc.) associated with a label is a separate issue and defined via a policy. Another way of distinguishing traffic is to use a set of *related* labels. This set may convey various measures of a characteristic that is internal to that set. An example of this case is the Assured Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in RFC2597. Within each AF class, M different levels of drop level precedence may be assigned to an IP packet. Note that the exact level of drop precendence is not defined for any level. Further, different classes, and different PHBs, are unrelated. From this example, we can make a more general statement and say that one may choose to attribute a type of characteristic to a related set of labels. However, the characteristics between one set of defined labels to all other sets of unrelated labels is separate and not part of the defined label set. ------------------------------- Does the above seem reasonable statement to make? Does it need to be more precise, more constrained, less constrained? let thine arrows fly forth :-) -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 12:03:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12797 for ; Thu, 10 Oct 2002 12:03:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AG5aN19557 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 12:05:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AG5av19554 for ; Thu, 10 Oct 2002 12:05:36 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12635 for ; Thu, 10 Oct 2002 12:03:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AG4ev19516; Thu, 10 Oct 2002 12:04:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AG0Rv19076 for ; Thu, 10 Oct 2002 12:00:27 -0400 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11128 for ; Thu, 10 Oct 2002 11:58:17 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.49]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AG0B0x028725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 12:00:13 -0400 (EDT) Message-ID: <3DA5A3A5.7040009@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'Ken Carlberg'" , ieprep@ietf.org, rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 11:58:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since in our context, the label supply is infinite, I'm not sure we need to worry about this particular issue. There are more labels than IPv6 addresses, the Internet's definition of infinite :-) Gunn, Janet wrote: > OK, I am going to be as simplistic as possible. > > At the root of it, there need to be enough different labels that there is at > least a one-to-one mapping (could be many-to-one) from label to policy in > any given environment. > > If we want to have N different policies in a given environment, there must > be at least N different labels. An "environment" could be the whole > Internet, a particular subnetwork, or even a single router or gateway. > > This does not prevent a single label being associated with several > different policies in several different environments, though this should > generally be discouraged (for human comprehension reasons as much as > anything), except when the policies are very closely related. > > So, we need to have figured out in advance how many different policies we > will want in effect in a given environment. Then we can figure out what > parameters are needed to create those labels. > > (I am using "labels" in a broad sense. If you have two parameters, each of > which can have 3 values, I would call that 9 labels.) > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 12:09:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13165 for ; Thu, 10 Oct 2002 12:09:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AGBHE20377 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 12:11:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGBGv20374 for ; Thu, 10 Oct 2002 12:11:16 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13143 for ; Thu, 10 Oct 2002 12:09:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGA5v20319; Thu, 10 Oct 2002 12:10:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AG9vv20297 for ; Thu, 10 Oct 2002 12:09:57 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13084 for ; Thu, 10 Oct 2002 12:07:48 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 12:08:07 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "'Ken Carlberg'" , ieprep@ietf.org, rja@extremenetworks.com Subject: RE: [Ieprep] policy & labels MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 12:07:56 -0400 True, but in order to be useful (both for human and machine comprehension) there then needs to be a structure to the set of labels, and we need to get approval to use them that way. So I still think that identifying the policies we will want to implement is an important part of figuring out how we want to structure the labels. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, October 10, 2002 11:58 AM To: Gunn, Janet Cc: 'Ken Carlberg'; ieprep@ietf.org; rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels Since in our context, the label supply is infinite, I'm not sure we need to worry about this particular issue. There are more labels than IPv6 addresses, the Internet's definition of infinite :-) Gunn, Janet wrote: > OK, I am going to be as simplistic as possible. > > At the root of it, there need to be enough different labels that there is at > least a one-to-one mapping (could be many-to-one) from label to policy in > any given environment. > > If we want to have N different policies in a given environment, there must > be at least N different labels. An "environment" could be the whole > Internet, a particular subnetwork, or even a single router or gateway. > > This does not prevent a single label being associated with several > different policies in several different environments, though this should > generally be discouraged (for human comprehension reasons as much as > anything), except when the policies are very closely related. > > So, we need to have figured out in advance how many different policies we > will want in effect in a given environment. Then we can figure out what > parameters are needed to create those labels. > > (I am using "labels" in a broad sense. If you have two parameters, each of > which can have 3 values, I would call that 9 labels.) > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 12:24:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13739 for ; Thu, 10 Oct 2002 12:24:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AGQ8721049 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 12:26:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGQ7v21042 for ; Thu, 10 Oct 2002 12:26:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13705 for ; Thu, 10 Oct 2002 12:23:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGP6v20986; Thu, 10 Oct 2002 12:25:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGOFv20956 for ; Thu, 10 Oct 2002 12:24:15 -0400 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13669 for ; Thu, 10 Oct 2002 12:22:05 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.49]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AGO2lR028127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 12:24:04 -0400 (EDT) Message-ID: <3DA5A93D.7030100@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'Ken Carlberg'" , ieprep@ietf.org Subject: Re: [Ieprep] policy & labels References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 12:22:21 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit While I'll get slapped with a wet noodle for mentioning solutions, I had proposed a scheme, namely namespace.label, which may satisfy your requirements. 'namespace' identifies the name space (such as GETS). This allows everybody to have a high, low and medium label. Since there doesn't seem to be an existing name space, namespaces and labels would be registered with IANA. The number is likely going to be small. Gunn, Janet wrote: > True, but in order to be useful (both for human and machine comprehension) > there then needs to be a structure to the set of labels, and we need to get > approval to use them that way. So I still think that identifying the > policies we will want to implement is an important part of figuring out how > we want to structure the labels. > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 12:52:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14764 for ; Thu, 10 Oct 2002 12:52:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AGs5b22675 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 12:54:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGs5v22672 for ; Thu, 10 Oct 2002 12:54:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14754 for ; Thu, 10 Oct 2002 12:51:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGr7v22631; Thu, 10 Oct 2002 12:53:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AGqVv22595 for ; Thu, 10 Oct 2002 12:52:31 -0400 Received: from [140.32.132.66] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14703 for ; Thu, 10 Oct 2002 12:50:19 -0400 (EDT) Received: from mail.nps.navy.mil by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Thu, 10 Oct 2002 09:50:36 -0700 Received: from there ([131.120.179.247]) by capella.nps.navy.mil (8.12.2/8.12.2) with SMTP id g9AGpn5J000376; Thu, 10 Oct 2002 09:51:49 -0700 (PDT) Message-Id: <200210101651.g9AGpn5J000376@capella.nps.navy.mil> Content-Type: text/plain; charset="iso-8859-1" From: Rex Buddenberg To: "Gunn, Janet" , "'Ken Carlberg'" , ieprep@ietf.org Subject: Re: [Ieprep] policy & labels X-Mailer: KMail [version 1.3.2] Cc: rja@extremenetworks.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9AGqVv22596 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 09:50:23 -0700 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Before we all get too carried away, at least some consciousness of prior art is worthwhile. A decade ago, Alf Weaver (UVa) was doing simulation research with FDDI which has 8 priority levels. I can't be terribly specific about why (discharged grey matter RAM cells), but Alf found that any more than 4 levels of priority and things lost definition -- you passed the point of diminishing returns. Something like "if you have a mixed load of frames of all 8 priority levels, the first three get treated properly; the rest all tumble into a common". IEEE 802.5 token rings also have 4 levels of priority; to my knowledge never ever used. The Mil version of X.25 had four as well, mirroring the military messaging system (see below). Carefully written into the MilStd; probably never used. (Priority labeling in LANs is a rightfully neglected area -- we've been killing the problem by throwing bandwidth at it. But this observation is not true across complex internets or radio-WANs). XTP was an also-ran transport protocol (again about a decade old) that had the attribute of reliable multicast (which TCP can't do). XTP had a whole byte set aside for priority indicators. Never matured enough that anybody used the priority features, so what this 'DSCP' meant was never defined. But everybody that worked on the protocol agreed that a single byte was far more than we'd actually need. The list can get longer, but the trend appears to be that anything over four levels is overkill ... even if those priority labels are actually used. The DS byte in IPv4 used to be known as the Type of Service byte (before we actually started using it) and had the whole 8 bits theoretically available. 2**8 was clearly more than anybody was going to need ... things slimmed down as differential services became a real cross-ISP implementation issue. The military's messaging system has had four levels of precedence (five if you look in the really find print in the comms manual). Flash (z), immediate (o), priority (p) and routine (r) - the fifth was known as Flash Override (y) and available only to JCS -- the switching system was at least in theory supposed to know that and react accordingly. These precedence indicators were equally available (excepting y) to users and network managers (aka radiomen) for both substantive and net management traffic. The military's messaging system has run at capacity for years -- there's a Parkinson's Law effect in operation here. The shortcomings in the system never have seemed to be rooted in a dearth of precedence indicators -- there are enough, but rather in precedence creep where everybody is cheating to keep up with the other cheaters. (The other form of cheating was to use the precedence indicator as an attention-getter rather than a QoS needs indicator). Reality check: this formal messaging system has been in place for 40 years -- at least since 1968 when Autodin debuted. There is still a lot of operational infrastructure that uses it, but it's now rapidly becoming obsolete. The few times I actually see formal message traffic these days, it's wrapped up in an e-mail envelope so the precedence indicator becomes part of the body of a composite message and is invisible to the e-mail handling system or it's underlying plumbing. Any help? On Thursday 10 October 2002 08:54 am, Gunn, Janet wrote: > OK, I am going to be as simplistic as possible. > > At the root of it, there need to be enough different labels that there is > at least a one-to-one mapping (could be many-to-one) from label to policy > in any given environment. -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 13:55:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17733 for ; Thu, 10 Oct 2002 13:55:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AHuo825969 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 13:56:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AHunv25966 for ; Thu, 10 Oct 2002 13:56:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17728 for ; Thu, 10 Oct 2002 13:54:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AHtEv25873; Thu, 10 Oct 2002 13:55:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AHsdv25840 for ; Thu, 10 Oct 2002 13:54:39 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17622 for ; Thu, 10 Oct 2002 13:52:28 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 13:52:47 -0400 Message-ID: From: "Gunn, Janet" To: "'Rex Buddenberg'" , "'Ken Carlberg'" , ieprep@ietf.org Cc: rja@extremenetworks.com Subject: RE: [Ieprep] policy & labels MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 13:52:35 -0400 While they are all "labels", I think there are two qualitatively different things- categories of traffic within a given policy (e.g., the priority levels within MLPP), and the number of different policies (e.g., pre-emption at call set up, queueing at call setup, per packet queueing discipline at transit nodes) -----Original Message----- From: Rex Buddenberg [mailto:budden@nps.navy.mil] Sent: Thursday, October 10, 2002 12:50 PM To: Gunn, Janet; 'Ken Carlberg'; ieprep@ietf.org Cc: rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels Before we all get too carried away, at least some consciousness of prior art is worthwhile. A decade ago, Alf Weaver (UVa) was doing simulation research with FDDI which has 8 priority levels. I can't be terribly specific about why (discharged grey matter RAM cells), but Alf found that any more than 4 levels of priority and things lost definition -- you passed the point of diminishing returns. Something like "if you have a mixed load of frames of all 8 priority levels, the first three get treated properly; the rest all tumble into a common". IEEE 802.5 token rings also have 4 levels of priority; to my knowledge never ever used. The Mil version of X.25 had four as well, mirroring the military messaging system (see below). Carefully written into the MilStd; probably never used. (Priority labeling in LANs is a rightfully neglected area -- we've been killing the problem by throwing bandwidth at it. But this observation is not true across complex internets or radio-WANs). XTP was an also-ran transport protocol (again about a decade old) that had the attribute of reliable multicast (which TCP can't do). XTP had a whole byte set aside for priority indicators. Never matured enough that anybody used the priority features, so what this 'DSCP' meant was never defined. But everybody that worked on the protocol agreed that a single byte was far more than we'd actually need. The list can get longer, but the trend appears to be that anything over four levels is overkill ... even if those priority labels are actually used. The DS byte in IPv4 used to be known as the Type of Service byte (before we actually started using it) and had the whole 8 bits theoretically available. 2**8 was clearly more than anybody was going to need ... things slimmed down as differential services became a real cross-ISP implementation issue. The military's messaging system has had four levels of precedence (five if you look in the really find print in the comms manual). Flash (z), immediate (o), priority (p) and routine (r) - the fifth was known as Flash Override (y) and available only to JCS -- the switching system was at least in theory supposed to know that and react accordingly. These precedence indicators were equally available (excepting y) to users and network managers (aka radiomen) for both substantive and net management traffic. The military's messaging system has run at capacity for years -- there's a Parkinson's Law effect in operation here. The shortcomings in the system never have seemed to be rooted in a dearth of precedence indicators -- there are enough, but rather in precedence creep where everybody is cheating to keep up with the other cheaters. (The other form of cheating was to use the precedence indicator as an attention-getter rather than a QoS needs indicator). Reality check: this formal messaging system has been in place for 40 years -- at least since 1968 when Autodin debuted. There is still a lot of operational infrastructure that uses it, but it's now rapidly becoming obsolete. The few times I actually see formal message traffic these days, it's wrapped up in an e-mail envelope so the precedence indicator becomes part of the body of a composite message and is invisible to the e-mail handling system or it's underlying plumbing. Any help? On Thursday 10 October 2002 08:54 am, Gunn, Janet wrote: > OK, I am going to be as simplistic as possible. > > At the root of it, there need to be enough different labels that there is > at least a one-to-one mapping (could be many-to-one) from label to policy > in any given environment. -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 14:01:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17997 for ; Thu, 10 Oct 2002 14:01:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AI3Cx26348 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 14:03:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AI3Cv26345 for ; Thu, 10 Oct 2002 14:03:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17972 for ; Thu, 10 Oct 2002 14:01:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AI24v26234; Thu, 10 Oct 2002 14:02:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AI12v26147 for ; Thu, 10 Oct 2002 14:01:02 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17843 for ; Thu, 10 Oct 2002 13:58:52 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 13:59:11 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "'Ken Carlberg'" , ieprep@ietf.org Subject: RE: [Ieprep] policy & labels MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 13:59:02 -0400 Yes, that satisfies it (as do a number of other schemes). But is there a one-to-one mapping between namespace and policy? If I remember correctly, I thought I was corrected when I used "GETS" as an example of a name space. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, October 10, 2002 12:22 PM To: Gunn, Janet Cc: 'Ken Carlberg'; ieprep@ietf.org Subject: Re: [Ieprep] policy & labels While I'll get slapped with a wet noodle for mentioning solutions, I had proposed a scheme, namely namespace.label, which may satisfy your requirements. 'namespace' identifies the name space (such as GETS). This allows everybody to have a high, low and medium label. Since there doesn't seem to be an existing name space, namespaces and labels would be registered with IANA. The number is likely going to be small. Gunn, Janet wrote: > True, but in order to be useful (both for human and machine comprehension) > there then needs to be a structure to the set of labels, and we need to get > approval to use them that way. So I still think that identifying the > policies we will want to implement is an important part of figuring out how > we want to structure the labels. > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 14:45:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19377 for ; Thu, 10 Oct 2002 14:45:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AIl9n29074 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 14:47:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AIl9v29071 for ; Thu, 10 Oct 2002 14:47:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19365 for ; Thu, 10 Oct 2002 14:44:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AIk9v29027; Thu, 10 Oct 2002 14:46:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AIj3v29002 for ; Thu, 10 Oct 2002 14:45:03 -0400 Received: from bootstrap.agcs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19290 for ; Thu, 10 Oct 2002 14:42:51 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id LAA23176 for ; Thu, 10 Oct 2002 11:44:56 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id H3S42W00.1GE for ; Thu, 10 Oct 2002 11:44:56 -0700 Received: FROM agcs.com BY mkultra ; Thu Oct 10 11:44:55 2002 -0700 Message-ID: <3DA5CAA6.A7DE0B54@agcs.com> From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gunn Janet" CC: "'Rex Buddenberg'" , "'Ken Carlberg'" , ieprep@ietf.org, rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels References: Content-Type: multipart/mixed; boundary="------------1ACB5C9B75EC5E77256B0408" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 11:44:55 -0700 This is a multi-part message in MIME format. --------------1ACB5C9B75EC5E77256B0408 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, This is a very enlightening discussion so far. I did get a bit concerned when it drifted toward having an infinite number of labels since it may be useful if the labels could be mapped at the gateway to the legacy PSTN where infinity within the protocol is not as popular. I agree with the concept that based on prior experience there is likely not to be an unlimited number of labels. Recent ITU-T contributions on the PSTN side were looking at a half dozen values being defined with an octet for the field thus leaving 250 unassigned values. It is my sense that not binding policy to the labels too early will allow a greater richness in the policy agreements (SLA's) that can be reached between the near end and far end for service, and the ability to more easily modify them over time and as more entrants join in. "Gunn, Janet" wrote: > While they are all "labels", I think there are two qualitatively different > things- categories of traffic within a given policy (e.g., the priority > levels within MLPP), and the number of different policies (e.g., pre-emption > at call set up, queueing at call setup, per packet queueing discipline at > transit nodes) > > -----Original Message----- > From: Rex Buddenberg [mailto:budden@nps.navy.mil] > Sent: Thursday, October 10, 2002 12:50 PM > To: Gunn, Janet; 'Ken Carlberg'; ieprep@ietf.org > Cc: rja@extremenetworks.com > Subject: Re: [Ieprep] policy & labels > > Before we all get too carried away, at least some consciousness of prior art > > is worthwhile. > > A decade ago, Alf Weaver (UVa) was doing simulation research with FDDI which > > has 8 priority levels. I can't be terribly specific about why (discharged > grey matter RAM cells), but Alf found that any more than 4 levels of > priority > and things lost definition -- you passed the point of diminishing returns. > Something like "if you have a mixed load of frames of all 8 priority levels, > > the first three get treated properly; the rest all tumble into a common". > IEEE 802.5 token rings also have 4 levels of priority; to my > knowledge never > ever used. The Mil version of X.25 had four as well, mirroring the military > > messaging system (see below). Carefully written into the MilStd; probably > never used. > (Priority labeling in LANs is a rightfully neglected area -- we've > been > killing the problem by throwing bandwidth at it. But this observation is > not > true across complex internets or radio-WANs). > XTP was an also-ran transport protocol (again about a decade old) > that had > the attribute of reliable multicast (which TCP can't do). XTP had a whole > byte set aside for priority indicators. Never matured enough that anybody > used the priority features, so what this 'DSCP' meant was never defined. > But > everybody that worked on the protocol agreed that a single byte was far more > > than we'd actually need. > The list can get longer, but the trend appears to be that anything > over four > levels is overkill ... even if those priority labels are actually used. > > The DS byte in IPv4 used to be known as the Type of Service byte (before we > actually started using it) and had the whole 8 bits theoretically available. > > 2**8 was clearly more than anybody was going to need ... things slimmed down > > as differential services became a real cross-ISP implementation issue. > > The military's messaging system has had four levels of precedence (five if > you look in the really find print in the comms manual). Flash (z), > immediate > (o), priority (p) and routine (r) - the fifth was known as Flash Override > (y) > and available only to JCS -- the switching system was at least in theory > supposed to know that and react accordingly. These precedence indicators > were equally available (excepting y) to users and network managers (aka > radiomen) for both substantive and net management traffic. > The military's messaging system has run at capacity for years -- > there's a > Parkinson's Law effect in operation here. The shortcomings in the system > never have seemed to be rooted in a dearth of precedence indicators -- there > > are enough, but rather in precedence creep where everybody is cheating to > keep up with the other cheaters. (The other form of cheating was to use the > > precedence indicator as an attention-getter rather than a QoS needs > indicator). > Reality check: this formal messaging system has been in place for 40 > years > -- at least since 1968 when Autodin debuted. There is still a lot of > operational infrastructure that uses it, but it's now rapidly becoming > obsolete. The few times I actually see formal message traffic these days, > it's wrapped up in an e-mail envelope so the precedence indicator becomes > part of the body of a composite message and is invisible to the e-mail > handling system or it's underlying plumbing. > > Any help? > > On Thursday 10 October 2002 08:54 am, Gunn, Janet wrote: > > OK, I am going to be as simplistic as possible. > > > > At the root of it, there need to be enough different labels that there is > > at least a one-to-one mapping (could be many-to-one) from label to policy > > in any given environment. > > -- > b > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------1ACB5C9B75EC5E77256B0408 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org:AG Communication Systems adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;-12184 fn:Stuart Goldman end:vcard --------------1ACB5C9B75EC5E77256B0408-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 15:17:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20377 for ; Thu, 10 Oct 2002 15:17:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AJJVZ30694 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 15:19:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJJVv30691 for ; Thu, 10 Oct 2002 15:19:31 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20326 for ; Thu, 10 Oct 2002 15:17:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJIKv30572; Thu, 10 Oct 2002 15:18:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJElv30416 for ; Thu, 10 Oct 2002 15:14:47 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20196 for ; Thu, 10 Oct 2002 15:12:35 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 15:12:55 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] overall issues and REQ-11 thru REQ-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 15:12:44 -0400 [JPG comments in line. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, October 02, 2002 1:47 PM To: King, Kimberly S. Cc: Ieprep (E-mail) Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 > What involvement is needed by the local IP network or SIP carrier > for the user to make use of a gateway's ability to invoke GETS, MLPP or some > other service on the CSN? > > GETS Example: User wishes to place GETS call from SIP phone to a phone in > the CSN (via a gateway). > > CASE A: The gateway doesn't support the priority scheme. It sure might be > nice if it understood that 710 was a valid area code and routed this to the > CSN for authorization and preferential treatment in the CSN using GETS. The > IP network or SIP carrier may have no particular relationship with the user. This seems to be purely a configuration issue, requiring no further protocol work. The gateway would treat the SIP phone like a somewhat odd telephone extension, with the usual DTMF-based authorization. [JPG] The gateway needs to recognize 710 as a valid prefix, and know what to do with it (at a minimum route it to something that knows what to REALLY do with it, such as one of the 3 GETS IXCs, or a GETS capable LEC). > > CASE B: The gateway does support the priority scheme. At that point, it is > a matter of policy, if the gateway and user do some exchange > authentication/authorization and gives the user preferential access to a > gateway port. Then the 710 call is routed to the CSN. The IP network or > SIP carrier may have no particular relationship with the user. I'm not sure if you consider "SIP network" = "gateway", but in any event, auth* would require some relationship to the user. Hard to authenticate somebody you haven't met, if indirectly (via some cert). [JPG] Even if there is no direct relationship between the user and the gateway, there needs to be an indirect relationship, e.g., the user has a relationship with a database or other auth* agent, and the gateway also has a relationship with the database or auth* agent. [JPG] And there may be two (or more) variants of "support the priority scheme." One variant would be to perform the auth* and then provide the requested special service. Another would be to provide the requested special service IFF the request carried a valid (trusted) indicator that it had already been auth*ed. In this case, a request that had not already been auth*ed would fail. Presumably the first alternative is better than the second, but the second is still better than case A. [JPG] While it is possible that a user might need to be auth*ed twice, it is in every one's interest to try to avoid that in setting up the business relationship. > > CASE C: The gateway supports the priority scheme and the IP network or SIP > carrier also have a business relationship with the user (or GETS service). > In this case, the authentication/authorization could potentially be for the > entire GETS service. Not only is the user authorized for (perhaps > preferential) use of the gateway, the user is authorized for the full GETS > system and a true destination is entered by the gateway (i.e., perhaps the > user really wanted to call 202-555-1212). In this case, there are some > pretty explicit relationships assumed. > > So, what are we talking about? A is not interesting (no SIP protocol features involved); both B and C could happen, but, again, from a protocol perspective, I don't see why it matters. in case B, the user may have to authenticate twice, both via some challenge/response and DTMF, but that's a user interface issue. > > Maybe it is best left ambiguous since the schemes I've heard voiced here use > different techniques. The circuit-switched landline GETS model > authenticates in the PSTN (at particular IXCs) after the user dials the 710 > "area code". However, the traditional circuit-switched MLPP and GTPS > systems have their authentication built in based upon the physical line. [JPG] Some of the (future) variants of GETS use the instrument or line identification as part of the auth* process, and may auth* somewhere other than the IXC. So it needs to be more general. Also, this strongly depends on the trust relationship between the various parties. I don't think that's something we want to get into, as it appears to be largely an operational issue. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 15:30:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20802 for ; Thu, 10 Oct 2002 15:30:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AJW4m31314 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 15:32:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJW4v31311 for ; Thu, 10 Oct 2002 15:32:04 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20792 for ; Thu, 10 Oct 2002 15:29:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJV5v31263; Thu, 10 Oct 2002 15:31:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJUFv31225 for ; Thu, 10 Oct 2002 15:30:15 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20741 for ; Thu, 10 Oct 2002 15:28:02 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 15:28:21 -0400 Message-ID: From: "Gunn, Janet" To: "'Ken Carlberg'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] overall issues and REQ-11 thru REQ-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 15:28:11 -0400 -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Wednesday, October 02, 2002 12:07 PM To: King, Kimberly S. Cc: Ieprep (E-mail) Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 > GETS Example: User wishes to place GETS call from SIP phone to a phone in > the CSN (via a gateway). > > CASE A: The gateway doesn't support the priority scheme. It sure might be > nice if it understood that 710 was a valid area code and routed this to the > CSN for authorization and preferential treatment in the CSN using GETS. The > IP network or SIP carrier may have no particular relationship with the user. the 710 number and whatever services associated with it are two different and cascading items. 710 should be recognized by all LECs, CLECs, etc within the US. additional high probability of completion (HPC) services is in addition to that and may exist depending on the service contracted by the customer (ie, US govt). [JPG] SHOULD is the operative word. Unfortunately it is not something that is guaranteed. For that reason, there may also be other dialed sequences (e.g., 800 numbers) that also invoke GETS. The gateway should also correctly handle those invocations (though it may "think" it is just invoking an 800 call). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:05:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22136 for ; Thu, 10 Oct 2002 16:05:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AK7XG01252 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:07:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AK7Xv01249 for ; Thu, 10 Oct 2002 16:07:33 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22117 for ; Thu, 10 Oct 2002 16:05:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AK6Qv00635; Thu, 10 Oct 2002 16:06:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AK5fv00582 for ; Thu, 10 Oct 2002 16:05:41 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22039 for ; Thu, 10 Oct 2002 16:03:28 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 16:03:49 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] requirements document(s) to SIPPING MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:03:39 -0400 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 01, 2002 2:42 PM To: King, Kimberly S. Cc: Ieprep (E-mail) Subject: Re: [Ieprep] requirements document(s) to SIPPING ... Maintaining two (or more) queues instead of one isn't terribly challenging for an application, particularly if you don't do preemption. The pseudo is nothing but if (incoming request has high priority) insert into queue1 else insert into queue2 and if request is done pick next from queue1 if empty, pick next from queue2 [JPG] Agree that a simple set of multiple FIFO queues is "easy". However, when there is a desire (based on business considerations) to "give priority if there are only a few of them, but not let them take over everything", the logic can become quite tortuous. So, in making decisions, it is not safe to ASSUME a simple queue logic. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:22:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22526 for ; Thu, 10 Oct 2002 16:22:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKONJ01860 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:24:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKONv01857 for ; Thu, 10 Oct 2002 16:24:23 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22503 for ; Thu, 10 Oct 2002 16:22:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKN7v01821; Thu, 10 Oct 2002 16:23:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKMRv01791 for ; Thu, 10 Oct 2002 16:22:27 -0400 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22467 for ; Thu, 10 Oct 2002 16:20:09 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AKLxOI007032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 16:22:01 -0400 (EDT) Message-ID: <3DA5E102.5060102@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:20:18 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [JPG] Agree that a simple set of multiple FIFO queues is "easy". However, > when there is a desire (based on business considerations) to "give priority > if there are only a few of them, but not let them take over everything", the > logic can become quite tortuous. So, in making decisions, it is not safe to > ASSUME a simple queue logic. Agreed; however, per-class "bandwidth" allocation this is a standard problem in networking, handled at line rates and in hardware for routers. Thus, this is still fairly common. (This is also fairly similar to CPU scheduling code, which also is fairly well understood and not hard for anybody who's taken OS in undergrad.) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:28:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22766 for ; Thu, 10 Oct 2002 16:28:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKUF202137 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:30:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKUFv02134 for ; Thu, 10 Oct 2002 16:30:15 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22745 for ; Thu, 10 Oct 2002 16:28:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKT4v02062; Thu, 10 Oct 2002 16:29:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKSXv02027 for ; Thu, 10 Oct 2002 16:28:33 -0400 Received: from bootstrap.agcs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22659 for ; Thu, 10 Oct 2002 16:26:19 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id NAA03934 for ; Thu, 10 Oct 2002 13:28:25 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id H3S8VC00.I3F for ; Thu, 10 Oct 2002 13:28:24 -0700 Received: FROM agcs.com BY mkultra ; Thu Oct 10 13:28:24 2002 -0700 Message-ID: <3DA5E2E8.8B3369FE@agcs.com> From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gunn Janet" CC: "'Henning Schulzrinne'" , "King Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: Content-Type: multipart/mixed; boundary="------------F4E2A2148B614BB1002B65FC" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 13:28:24 -0700 This is a multi-part message in MIME format. --------------F4E2A2148B614BB1002B65FC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Janet, I think you are right that it can become more complex very easily if one adds factors such as time in queue, etc. I have seen systems that work from the highest priority queue but every so often visit the lower priority ones so that they are not completely denied service. I could see that becoming an interesting discussion point as to if the higher queue priority is an absolute (one never serves an n-1 queue if there is an entry in the n queue) or relative (after serving a handful of n queue entries, we serve 1 from the n-1 queue. This could be recursive.) "Gunn, Janet" wrote: > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 01, 2002 2:42 PM > To: King, Kimberly S. > Cc: Ieprep (E-mail) > Subject: Re: [Ieprep] requirements document(s) to SIPPING > > ... > > Maintaining two (or more) queues > instead of one isn't terribly challenging for an application, > particularly if you don't do preemption. The pseudo is nothing but > > if (incoming request has high priority) > insert into queue1 > else > insert into queue2 > > and > > if request is done > pick next from queue1 > if empty, pick next from queue2 > > [JPG] Agree that a simple set of multiple FIFO queues is "easy". However, > when there is a desire (based on business considerations) to "give priority > if there are only a few of them, but not let them take over everything", the > logic can become quite tortuous. So, in making decisions, it is not safe to > ASSUME a simple queue logic. > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------F4E2A2148B614BB1002B65FC Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org:AG Communication Systems adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;-12184 fn:Stuart Goldman end:vcard --------------F4E2A2148B614BB1002B65FC-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:33:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23042 for ; Thu, 10 Oct 2002 16:33:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKZEZ02513 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:35:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKZEv02510 for ; Thu, 10 Oct 2002 16:35:14 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23034 for ; Thu, 10 Oct 2002 16:33:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKY5v02399; Thu, 10 Oct 2002 16:34:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKULv02158 for ; Thu, 10 Oct 2002 16:30:21 -0400 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22753 for ; Thu, 10 Oct 2002 16:28:08 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AKUBAl025589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 16:30:13 -0400 (EDT) Message-ID: <3DA5E2EE.8090204@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:28:30 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [JPG] The gateway needs to recognize 710 as a valid prefix, and know what to > do with it (at a minimum route it to something that knows what to REALLY do > with it, such as one of the 3 GETS IXCs, or a GETS capable LEC). Not necessarily. In many (smaller network) cases, the gateways are about as smart or dumb as a PBX, i.e., they just talk to a local PSTN switch. A carrier will likely have to do the routing, as you mention; the gateway effectively acts like a local telephone switch with rather peculiar line interfaces or a tandem with an IP trunk interface. In both cases, this is invisible to the IP side. Since we don't specify boxes, I don't think we need to worry about this. > [JPG] Even if there is no direct relationship between the user and the > gateway, there needs to be an indirect relationship, e.g., the user has a > relationship with a database or other auth* agent, and the gateway also has > a relationship with the database or auth* agent. Yes, typically the gateway won't do the authentication itself, particularly if its of the MGCP-kind. The associated SIP UA will do this. In that case, SIP ends on the UA, so the gateway is just a remote "extension" of the SIP UA. > > [JPG] And there may be two (or more) variants of "support the priority > scheme." One variant would be to perform the auth* and then provide the > requested special service. Another would be to provide the requested > special service IFF the request carried a valid (trusted) indicator that it > had already been auth*ed. In this case, a request that had not already been > auth*ed would fail. Presumably the first alternative is better than the > second, but the second is still better than case A. A network-assigned identity extension for SIP has been specified; others, less dependent on trust boundaries, are in progress. I don't see the need for additional work here. > [JPG] Some of the (future) variants of GETS use the instrument or line > identification as part of the auth* process, and may auth* somewhere other > than the IXC. So it needs to be more general. In VoIP, I don't see how "line identification" can be useful (or even what this should mean). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:33:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23061 for ; Thu, 10 Oct 2002 16:33:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKZcP02533 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:35:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKZcv02530 for ; Thu, 10 Oct 2002 16:35:38 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23038 for ; Thu, 10 Oct 2002 16:33:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKYBv02452; Thu, 10 Oct 2002 16:34:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKX2v02327 for ; Thu, 10 Oct 2002 16:33:02 -0400 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22860 for ; Thu, 10 Oct 2002 16:30:48 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AKWXAl027697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 16:32:35 -0400 (EDT) Message-ID: <3DA5E37C.7090802@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: goldmans@agcs.com CC: Gunn Janet , "King Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: <3DA5E2E8.8B3369FE@agcs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:30:52 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I could see that becoming an interesting discussion point as to if the higher > queue priority is an absolute (one never serves an n-1 queue if there is an > entry in the n queue) or relative (after serving a handful of n queue entries, > we serve 1 from the n-1 queue. This could be recursive.) Before we rathole here: this is far outside the scope of the WG. This is an implementation issue. We're not even specifying the algorithms at this point, let alone the precise queueing mechanism. The discussion started to simply state that such differential request treatment is *possible*, in many different ways, none of which will likely be specified in the IETF. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:36:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23166 for ; Thu, 10 Oct 2002 16:36:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKcCW03199 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:38:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKcCv03196 for ; Thu, 10 Oct 2002 16:38:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23151 for ; Thu, 10 Oct 2002 16:35:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKb4v02703; Thu, 10 Oct 2002 16:37:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKaNv02562 for ; Thu, 10 Oct 2002 16:36:23 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23078 for ; Thu, 10 Oct 2002 16:34:10 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 16:34:30 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] overall issues and REQ-11 thru REQ-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:34:20 -0400 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, October 10, 2002 4:29 PM To: Gunn, Janet Cc: King, Kimberly S.; Ieprep (E-mail) Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 > [JPG] The gateway needs to recognize 710 as a valid prefix, and know what to > do with it (at a minimum route it to something that knows what to REALLY do > with it, such as one of the 3 GETS IXCs, or a GETS capable LEC). Not necessarily. In many (smaller network) cases, the gateways are about as smart or dumb as a PBX, i.e., they just talk to a local PSTN switch. [JPG] That is the problem. Some PBXs are so dumb that they don't recognize 710 as a valid "area code", and drop the call. We would prefer to avoid that situation in the IP gateway. I agree that a carrier may have to do the routing- but the gateway has to be willing to pass it to the carrier. A carrier will likely have to do the routing, as you mention; the gateway effectively acts like a local telephone switch with rather peculiar line interfaces or a tandem with an IP trunk interface. In both cases, this is invisible to the IP side. Since we don't specify boxes, I don't think we need to worry about this. > [JPG] Even if there is no direct relationship between the user and the > gateway, there needs to be an indirect relationship, e.g., the user has a > relationship with a database or other auth* agent, and the gateway also has > a relationship with the database or auth* agent. Yes, typically the gateway won't do the authentication itself, particularly if its of the MGCP-kind. The associated SIP UA will do this. In that case, SIP ends on the UA, so the gateway is just a remote "extension" of the SIP UA. ... > [JPG] Some of the (future) variants of GETS use the instrument or line > identification as part of the auth* process, and may auth* somewhere other > than the IXC. So it needs to be more general. In VoIP, I don't see how "line identification" can be useful (or even what this should mean). [JPG] Maybe the IP address or URI? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:39:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23290 for ; Thu, 10 Oct 2002 16:39:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKfQm03448 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:41:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKfQv03445 for ; Thu, 10 Oct 2002 16:41:26 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23287 for ; Thu, 10 Oct 2002 16:39:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKe5v03347; Thu, 10 Oct 2002 16:40:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKbOv03145 for ; Thu, 10 Oct 2002 16:37:24 -0400 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23134 for ; Thu, 10 Oct 2002 16:35:11 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AKaxAl001693 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 16:37:10 -0400 (EDT) Message-ID: <3DA5E486.7090401@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'Ken Carlberg'" , ieprep@ietf.org Subject: Re: [Ieprep] policy & labels References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:35:18 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Yes, that satisfies it (as do a number of other schemes). But is there a > one-to-one mapping between namespace and policy? If I remember correctly, I > thought I was corrected when I used "GETS" as an example of a name space. No, the namespace identifies the policy "group", typically borrowed from some existing PSTN scheme that we want to interwork with. An example namespace might be Q735 (for Q.735 labels). Unless I'm fundamentally misunderstanding something here, nobody is proposing an Internet-specific new namespace at this time. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:40:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23367 for ; Thu, 10 Oct 2002 16:40:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKgBi03496 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:42:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKgBv03493 for ; Thu, 10 Oct 2002 16:42:11 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23326 for ; Thu, 10 Oct 2002 16:39:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKf3v03436; Thu, 10 Oct 2002 16:41:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKeuv03422 for ; Thu, 10 Oct 2002 16:40:56 -0400 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23268 for ; Thu, 10 Oct 2002 16:38:43 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AKekxM011990 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 16:40:47 -0400 (EDT) Message-ID: <3DA5E569.2050608@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:39:05 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [JPG] That is the problem. Some PBXs are so dumb that they don't recognize > 710 as a valid "area code", and drop the call. We would prefer to avoid > that situation in the IP gateway. I agree that a carrier may have to do the > routing- but the gateway has to be willing to pass it to the carrier. You will have corporate-style gateways (even if they are located on the premises of a three-letter agency), so both cases will occur. > > [JPG] Maybe the IP address or URI? The URI identifies the user and maybe some random host name. The IP address often varies from call to call and is furthermore trivially spoofed, at least within the same network. Thus, I don't think that this is something we should recommend. It serves no purpose that I can discern. Why would I care which IP address originated the request? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:42:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23485 for ; Thu, 10 Oct 2002 16:42:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKiYw03638 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:44:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKiYv03635 for ; Thu, 10 Oct 2002 16:44:34 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23470 for ; Thu, 10 Oct 2002 16:42:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKh3v03566; Thu, 10 Oct 2002 16:43:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKgsv03527 for ; Thu, 10 Oct 2002 16:42:54 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23384 for ; Thu, 10 Oct 2002 16:40:41 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 16:41:01 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" , goldmans@agcs.com Cc: "King Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] requirements document(s) to SIPPING MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:40:51 -0400 I agree we don't want to follow this tangent into any detail. I thought the relevant point was whether or not dealing with IEPREP traffic could impose enough of a processing load on the [switch/router/gateway/etc.] that processing capacity (rather than communications bandwidth) might be the bottleneck. Thus, whether or not any kind of prioritization/labeling with regard to [switch/router/gateway/etc.] would be relevant. Janet -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, October 10, 2002 4:31 PM To: goldmans@agcs.com Cc: Gunn, Janet; King Kimberly S.; Ieprep (E-mail) Subject: Re: [Ieprep] requirements document(s) to SIPPING > I could see that becoming an interesting discussion point as to if the higher > queue priority is an absolute (one never serves an n-1 queue if there is an > entry in the n queue) or relative (after serving a handful of n queue entries, > we serve 1 from the n-1 queue. This could be recursive.) Before we rathole here: this is far outside the scope of the WG. This is an implementation issue. We're not even specifying the algorithms at this point, let alone the precise queueing mechanism. The discussion started to simply state that such differential request treatment is *possible*, in many different ways, none of which will likely be specified in the IETF. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:46:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23607 for ; Thu, 10 Oct 2002 16:46:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKm1Z03796 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:48:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKm1v03793 for ; Thu, 10 Oct 2002 16:48:01 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23590 for ; Thu, 10 Oct 2002 16:45:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKl5v03764; Thu, 10 Oct 2002 16:47:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKkCv03719 for ; Thu, 10 Oct 2002 16:46:12 -0400 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23527 for ; Thu, 10 Oct 2002 16:43:45 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AKjfxM013410 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Oct 2002 16:45:42 -0400 (EDT) Message-ID: <3DA5E68F.909@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: goldmans@agcs.com, "King Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:43:59 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I thought the relevant point was whether or not dealing with IEPREP traffic > could impose enough of a processing load on the [switch/router/gateway/etc.] > that processing capacity (rather than communications bandwidth) might be the > bottleneck. Thus, whether or not any kind of prioritization/labeling with > regard to [switch/router/gateway/etc.] would be relevant. Indeed. I thought I had addressed this issue in an earlier message (short summary: sometimes, depending on what a proxy does with requests), after which somebody mentioned that prioritizing would be too difficult. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 16:49:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23698 for ; Thu, 10 Oct 2002 16:49:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKp9C03923 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 16:51:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKp9v03920 for ; Thu, 10 Oct 2002 16:51:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23677 for ; Thu, 10 Oct 2002 16:48:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKo5v03877; Thu, 10 Oct 2002 16:50:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKnbv03845 for ; Thu, 10 Oct 2002 16:49:37 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23654 for ; Thu, 10 Oct 2002 16:47:24 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 16:47:44 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 16:47:34 -0400 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, September 30, 2002 8:15 PM To: King, Kimberly S. Cc: Ieprep (E-mail) Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 New wording suggestion: "Network terminals configured to use a priority scheme may occasionally end up making calls in a network that does not support such a scheme. In those cases, the protocol must support a sensible default behavior that treats the call no worse than a call that did not invoke the priority scheme." [JPG] That works for me. > REQ-10: Address-neutral: The mechanism cannot rely on > identifying a set of destination addresses or URI schemes. > For example, in GETS-like schemes, the caller can reach any > PSTN destination with increased probability of call > completion, not just a limited set. > > It appears REQ-10 adds that any address or URI scheme is a valid > destination. Let's assume REQ-14 is accepted (we can later debate this > potential requirement in another thread covering this requirement). Indeed. I'll say that explicitly. [JPG] I would rather say "any address or URI scheme may be a valid destination". [JPG] Some schemes will be have an open population of destinations, others (e.g. MLPP) may have a closed populations of destinations. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 17:07:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24246 for ; Thu, 10 Oct 2002 17:07:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AL8ot05409 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 17:08:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AL8ov05406 for ; Thu, 10 Oct 2002 17:08:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24239 for ; Thu, 10 Oct 2002 17:06:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AL85v05390; Thu, 10 Oct 2002 17:08:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AL7av05368 for ; Thu, 10 Oct 2002 17:07:36 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24219 for ; Thu, 10 Oct 2002 17:05:23 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 17:05:43 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-1 to REQ-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 17:05:34 -0400 I am a little confused about the relationship between "protocol", "policy", and "mechanism". It seems to me that the "protocol" should definitely be independent of the underlying technology (cable, 3GPP, etc.). But similarly, it seems that the policy might very well be specific to the underlying technology. And I am not sure what is meant by "mechanism". -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, September 30, 2002 7:59 PM To: King, Kimberly S. Cc: Ieprep (E-mail) Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5 General remark: finding reasonable compromise between being unduly specific and uselessly vague is hard. Thus, concrete wording suggestions are always appreciated. > REQ-2: Independent of particular network architecture: The > mechanism should work in the widest variety of SIP-based > systems. It should not be restricted to particular > operators or types of networks, such as wireless networks > or protocol profiles and dialects in certain types of > networks. > > How would one know if a proposed solution met REQ-2? If not restricted to > particular operators or types of networks, does it mean it should work for > all? While you probably can't prove that something can work in every single network that anybody could ever dream up, you will definitely know when REQ-2 is *not* met. Without naming names, this is meant to ensure, for example, that there is no 3GPP-specific or PacketCable-specific solution. (Both organizations use SIP, with extensions, in their respective architectures, for 3G wireless and cable modems.) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 17:34:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24805 for ; Thu, 10 Oct 2002 17:34:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ALZiD06304 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 17:35:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ALZhv06301 for ; Thu, 10 Oct 2002 17:35:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24779 for ; Thu, 10 Oct 2002 17:33:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ALZ5v06255; Thu, 10 Oct 2002 17:35:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ALXnv06195 for ; Thu, 10 Oct 2002 17:33:49 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24706 for ; Thu, 10 Oct 2002 17:31:35 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 17:31:55 -0400 Message-ID: From: "Gunn, Janet" To: "'Mpierce1@aol.com'" , KIMBERLY.S.KING@saic.com, mplsgeek@yahoo.com, budden@nps.navy.mil, K.Carlberg@cs.ucl.ac.uk Cc: ieprep@ietf.org Subject: RE: [Ieprep] requirements document(s) (Accounting) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C270A4.6E908E30" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 17:31:45 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C270A4.6E908E30 Content-Type: text/plain; charset="iso-8859-1" I think it is a business issue. If the carrier (circuit switched or packet switched) is going to bill someone (end user or government entity) on the basis of call volume (number, or number and duration), then a detailed accounting record is needed by both parties. if the carrier is going to bill independent of call volume, detailed accounting may not be needed. But I don't see that emergency services would need accounting any more or less than other VOIP services (maybe slightly different accounting data if one is generated). The CSN itself will almost certainly generate a CDR. But I don't think that that, in itself, means that SIP needs to generate a CDR. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Thursday, September 26, 2002 9:30 AM To: KIMBERLY.S.KING@saic.com; mplsgeek@yahoo.com; budden@nps.navy.mil; K.Carlberg@cs.ucl.ac.uk Cc: ieprep@ietf.org Subject: Re: [Ieprep] requirements document(s) In a message dated 9/24/2002 8:19:20 AM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes: [Gunn, Janet NE] ... I believe an original issue was whether accounting must be a general ieprep requirement. It appears that it may occur (and is listed as an issue) but isn't a general ieprep requirement; however, if this item is critical for assured service (sometimes called MLPP) then perhaps a more specific MLPP requirements draft should cover this. [MAP} The requirement for Accounting was included in draft-pierce-sipping-assured-service-02. If more needs to be said, I could add it. Any ideas? I feel quite certain the accounting is a basic requirement of GETS today. Surely the government's contract with service providers requires them to be able to record evidence of the use of the service, both the number of total uses as well as detail about each use. Question 1: Can we assume the above is acceptable and consider the accounting issue for the general ieprep requirement closed? If I am reading the concerns with accounting, the comments appear to be focused on not on general ieprep requirements but with respect to IP telephony. It appears the underlying reason some seek it is to determine after the fact who has used the service and at what priority. This essentially asks for a "call detail record" CDR with priority info included. Question 2: Is a CDR an ieprep IP Telephony requirement or is this an MLPP specific requirement? [MAP] The requirement listed in draft-pierce-sipping-assured-service was for what you called a "Call detail record". I used the term "accounting", maybe erroneously. Guess we need to be careful with this word, since some assume (maybe correctly) that "accounting" only relates to collection of money. Yes, I believe the ability to do CDR is a requirement for both. If a service provider elects to turn it off, fine. I understand a "requirement" in a document as meaning that a compliant piece of equipment must have the capability, not that the user of the equipment must use the capability. Question 2a: Is a CDR only a reasonable requirement when interacting with CSN gateways? [MAP] Whether or not CDR (or accounting) is required should be independent from the architecture, such as whether interacting with CSN gateways. Mike Pierce Artel ------_=_NextPart_001_01C270A4.6E908E30 Content-Type: text/html; charset="iso-8859-1"
I think it is a business issue.  If the carrier (circuit switched or packet switched) is going to bill someone (end user or government entity) on the basis of call volume (number, or number and duration), then a detailed accounting record is needed by both parties.  if the carrier is going to bill independent of call volume, detailed accounting may not be needed.
 
But I don't see that emergency services would need accounting any more or less than other VOIP services (maybe slightly different accounting data if one is generated).
 
The CSN itself will almost certainly generate a CDR.  But I don't think that that, in itself, means that SIP needs to generate a CDR.
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Thursday, September 26, 2002 9:30 AM
To: KIMBERLY.S.KING@saic.com; mplsgeek@yahoo.com; budden@nps.navy.mil; K.Carlberg@cs.ucl.ac.uk
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] requirements document(s)

In a message dated 9/24/2002 8:19:20 AM Eastern Standard Time, KIMBERLY.S.KING@saic.com writes:


[Gunn, Janet NE] ... 


I believe an original issue was whether accounting must be a general ieprep
requirement.  It appears that it may occur (and is listed as an issue) but
isn't a general ieprep requirement; however, if this item is critical for
assured service (sometimes called MLPP) then perhaps a more specific MLPP
requirements draft should cover this.



[MAP} The requirement for Accounting was included in draft-pierce-sipping-assured-service-02. If more needs to be said, I could add it. Any ideas?

I feel quite certain the accounting is a basic requirement of GETS today. Surely the government's contract with service providers requires them to be able to record evidence of the use of the service, both the number of total uses as well as detail about each use.


Question 1: Can we assume the above is acceptable and consider the
accounting issue for the general ieprep requirement closed?

If I am reading the concerns with accounting, the comments appear to be
focused on not on general ieprep requirements but with respect to IP
telephony.  It appears the underlying reason some seek it is to determine
after the fact who has used the service and at what priority.  This
essentially asks for a "call detail record" CDR with priority info included.


Question 2: Is a CDR an ieprep IP Telephony requirement or is this an MLPP
specific requirement?



[MAP] The requirement listed in draft-pierce-sipping-assured-service was for what you called a "Call detail record". I used the term "accounting", maybe erroneously. Guess we need to be careful with this word, since some assume (maybe correctly) that "accounting" only relates to collection of money.

Yes, I believe the ability to do CDR is a requirement for both. If a service provider elects to turn it off, fine. I understand a "requirement" in a document as meaning that a compliant piece of equipment must have the capability, not that the user of the equipment must use the capability.


Question 2a: Is a CDR only a reasonable requirement when interacting with
CSN gateways?



[MAP] Whether or not CDR (or accounting) is required should be independent from the architecture, such as whether interacting with CSN gateways.


Mike Pierce
Artel
------_=_NextPart_001_01C270A4.6E908E30-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 10 22:40:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29558 for ; Thu, 10 Oct 2002 22:40:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9B2fwE19960 for ieprep-archive@odin.ietf.org; Thu, 10 Oct 2002 22:41:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B2fwv19957 for ; Thu, 10 Oct 2002 22:41:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29527 for ; Thu, 10 Oct 2002 22:39:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B2fAv19932; Thu, 10 Oct 2002 22:41:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B2eKv19901 for ; Thu, 10 Oct 2002 22:40:20 -0400 Received: from imo-r08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29513 for ; Thu, 10 Oct 2002 22:38:04 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v34.13.) id r.161.157751f1 (25914); Thu, 10 Oct 2002 22:39:59 -0400 (EDT) Message-ID: <161.157751f1.2ad793fe@aol.com> Subject: Re: [Ieprep] requirements document(s) (Accounting) To: Janet.Gunn@DynCorp.com, KIMBERLY.S.KING@saic.com, mplsgeek@yahoo.com, budden@nps.navy.mil, K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_161.157751f1.2ad793fe_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Oct 2002 22:39:58 EDT --part1_161.157751f1.2ad793fe_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/10/2002 5:34:07 PM Eastern Standard Time, Janet.Gunn@DynCorp.com writes: > I think it is a business issue. If the carrier (circuit switched or packet > switched) is going to bill someone (end user or government entity) on the > basis of call volume (number, or number and duration), then a detailed > accounting record is needed by both parties. if the carrier is going to > bill independent of call volume, detailed accounting may not be needed. > > But I don't see that emergency services would need accounting any more or > less than other VOIP services (maybe slightly different accounting data if > one is generated). > > The CSN itself will almost certainly generate a CDR. But I don't think > that that, in itself, means that SIP needs to generate a CDR. > [MAP] You are generally correct regarding "billing", but that is not the issue here. When a network provides the capability for a user to place a voice call and get priority over others, including possible preemption, it must keep a record of the uses of that priority service. (Whether or not that record must include duration of the call may be open, but I'd bet they would want it.) I believe this requirement exists no matter what technology is being used to transport the communications, whether circuit switched networks, packet networks, or carrier pigeons. Mike Pierce Artel --part1_161.157751f1.2ad793fe_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/10/2002 5:34:07 PM Eastern Standard Time, Janet.Gunn@DynCorp.com writes:


I think it is a business issue.  If the carrier (circuit switched or packet switched) is going to bill someone (end user or government entity) on the basis of call volume (number, or number and duration), then a detailed accounting record is needed by both parties.  if the carrier is going to bill independent of call volume, detailed accounting may not be needed.

But I don't see that emergency services would need accounting any more or less than other VOIP services (maybe slightly different accounting data if one is generated).

The CSN itself will almost certainly generate a CDR.  But I don't think that that, in itself, means that SIP needs to generate a CDR.



[MAP] You are generally correct regarding "billing", but that is not the issue here.

When a network provides the capability for a user to place a voice call and get priority over others, including possible preemption, it must keep a record of the uses of that priority service. (Whether or not that record must include duration of the call may be open, but I'd bet they would want it.)

I believe this requirement exists no matter what technology is being used to transport the communications, whether circuit switched networks, packet networks, or carrier pigeons.

Mike Pierce
Artel
--part1_161.157751f1.2ad793fe_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 03:33:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13384 for ; Fri, 11 Oct 2002 03:33:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9B7Yxq08318 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 03:34:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B7Yxv08315 for ; Fri, 11 Oct 2002 03:34:59 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13374 for ; Fri, 11 Oct 2002 03:32:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B7YJv08291; Fri, 11 Oct 2002 03:34:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B7X7v08269 for ; Fri, 11 Oct 2002 03:33:07 -0400 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13302 for ; Fri, 11 Oct 2002 03:30:49 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9B7WnAl023840 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Oct 2002 03:32:50 -0400 (EDT) Message-ID: <3DA67E3B.1060705@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Janet.Gunn@DynCorp.com, KIMBERLY.S.KING@saic.com, mplsgeek@yahoo.com, budden@nps.navy.mil, K.Carlberg@cs.ucl.ac.uk, ieprep@ietf.org Subject: Re: [Ieprep] requirements document(s) (Accounting) References: <161.157751f1.2ad793fe@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 03:31:07 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is clearly good advice to operators, but not something that affects protocol design, as far as I can tell. If we were to write a BCP for operators of VoIP emergency services, this might be useful to include. As far as I know, we're not (at the moment). > > When a network provides the capability for a user to place a voice call > and get priority over others, including possible preemption, it must > keep a record of the uses of that priority service. (Whether or not that > record must include duration of the call may be open, but I'd bet they > would want it.) > > I believe this requirement exists no matter what technology is being > used to transport the communications, whether circuit switched networks, > packet networks, or carrier pigeons. > > Mike Pierce > Artel _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 06:15:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15545 for ; Fri, 11 Oct 2002 06:15:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BAGqt16309 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 06:16:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BAGqv16306 for ; Fri, 11 Oct 2002 06:16:52 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15530 for ; Fri, 11 Oct 2002 06:14:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BAG8v16274; Fri, 11 Oct 2002 06:16:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BAFWv16250 for ; Fri, 11 Oct 2002 06:15:32 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15520 for ; Fri, 11 Oct 2002 06:13:22 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 11 Oct 2002 06:14:34 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101106142329975 ; Fri, 11 Oct 2002 06:14:23 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QSX0R>; Fri, 11 Oct 2002 06:15:33 -0400 Message-Id: From: "King, Kimberly S." To: "'Stuart (Stu) Goldman '" , "'Gunn Janet '" Cc: "''Henning Schulzrinne' '" , "'King Kimberly S. '" , "'Ieprep (E-mail) '" Subject: RE: [Ieprep] requirements document(s) to SIPPING MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 06:14:22 -0400 "I could see that becoming an interesting discussion point as to if the higher queue priority is an absolute (one never serves an n-1 queue if there is an entry in the n queue) or relative (after serving a handful of n queue entries, we serve 1 from the n-1 queue. This could be recursive.)" Yes, interesting policy but we should focus on requirements, rather than neat ways to schedule resources. -----Original Message----- From: Stuart (Stu) Goldman To: Gunn Janet Cc: 'Henning Schulzrinne'; King Kimberly S.; Ieprep (E-mail) Sent: 10/10/2002 4:28 PM Subject: Re: [Ieprep] requirements document(s) to SIPPING Janet, I think you are right that it can become more complex very easily if one adds factors such as time in queue, etc. I have seen systems that work from the highest priority queue but every so often visit the lower priority ones so that they are not completely denied service. I could see that becoming an interesting discussion point as to if the higher queue priority is an absolute (one never serves an n-1 queue if there is an entry in the n queue) or relative (after serving a handful of n queue entries, we serve 1 from the n-1 queue. This could be recursive.) "Gunn, Janet" wrote: > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 01, 2002 2:42 PM > To: King, Kimberly S. > Cc: Ieprep (E-mail) > Subject: Re: [Ieprep] requirements document(s) to SIPPING > > ... > > Maintaining two (or more) queues > instead of one isn't terribly challenging for an application, > particularly if you don't do preemption. The pseudo is nothing but > > if (incoming request has high priority) > insert into queue1 > else > insert into queue2 > > and > > if request is done > pick next from queue1 > if empty, pick next from queue2 > > [JPG] Agree that a simple set of multiple FIFO queues is "easy". However, > when there is a desire (based on business considerations) to "give priority > if there are only a few of them, but not let them take over everything", the > logic can become quite tortuous. So, in making decisions, it is not safe to > ASSUME a simple queue logic. > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep <> _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 07:30:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16975 for ; Fri, 11 Oct 2002 07:30:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BBWEm19622 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 07:32:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBWDv19619 for ; Fri, 11 Oct 2002 07:32:13 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16949 for ; Fri, 11 Oct 2002 07:30:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBVWv19542; Fri, 11 Oct 2002 07:31:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBUhv19489 for ; Fri, 11 Oct 2002 07:30:43 -0400 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16861 for ; Fri, 11 Oct 2002 07:28:34 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9BBUTxM028119 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Oct 2002 07:30:32 -0400 (EDT) Message-ID: <3DA6B5EE.40507@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rex Buddenberg CC: "Gunn, Janet" , "'Ken Carlberg'" , ieprep@ietf.org, rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels References: <200210101651.g9AGpn5J000376@capella.nps.navy.mil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 07:28:46 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm confused by your message. We're not debating the merits of the number of priority levels nor "messaging", but rather importing existing voice call levels into a VoIP environment. Thus, the military ('you') and ITU (Q.735) provide the number of levels, not the IETF. I tend to agree that more than three levels of priority is generally of dubious merit, but that's beyond our bailiwick. (There will be LAN priority for wireless LANs, btw: 802.11e). Rex Buddenberg wrote: > Before we all get too carried away, at least some consciousness of prior art > is worthwhile. > > A decade ago, Alf Weaver (UVa) was doing simulation research with FDDI which > has 8 priority levels. I can't be terribly specific about why (discharged > grey matter RAM cells), but Alf found that any more than 4 levels of priority > and things lost definition -- you passed the point of diminishing returns. > Something like "if you have a mixed load of frames of all 8 priority levels, > the first three get treated properly; the rest all tumble into a common". > IEEE 802.5 token rings also have 4 levels of priority; to my knowledge never > ever used. The Mil version of X.25 had four as well, mirroring the military > messaging system (see below). Carefully written into the MilStd; probably > never used. > (Priority labeling in LANs is a rightfully neglected area -- we've been > killing the problem by throwing bandwidth at it. But this observation is not > true across complex internets or radio-WANs). > XTP was an also-ran transport protocol (again about a decade old) that had > the attribute of reliable multicast (which TCP can't do). XTP had a whole > byte set aside for priority indicators. Never matured enough that anybody > used the priority features, so what this 'DSCP' meant was never defined. But > everybody that worked on the protocol agreed that a single byte was far more > than we'd actually need. > The list can get longer, but the trend appears to be that anything over four > levels is overkill ... even if those priority labels are actually used. > > > The DS byte in IPv4 used to be known as the Type of Service byte (before we > actually started using it) and had the whole 8 bits theoretically available. > 2**8 was clearly more than anybody was going to need ... things slimmed down > as differential services became a real cross-ISP implementation issue. > > > The military's messaging system has had four levels of precedence (five if > you look in the really find print in the comms manual). Flash (z), immediate > (o), priority (p) and routine (r) - the fifth was known as Flash Override (y) > and available only to JCS -- the switching system was at least in theory > supposed to know that and react accordingly. These precedence indicators > were equally available (excepting y) to users and network managers (aka > radiomen) for both substantive and net management traffic. > The military's messaging system has run at capacity for years -- there's a > Parkinson's Law effect in operation here. The shortcomings in the system > never have seemed to be rooted in a dearth of precedence indicators -- there > are enough, but rather in precedence creep where everybody is cheating to > keep up with the other cheaters. (The other form of cheating was to use the > precedence indicator as an attention-getter rather than a QoS needs > indicator). > Reality check: this formal messaging system has been in place for 40 years > -- at least since 1968 when Autodin debuted. There is still a lot of > operational infrastructure that uses it, but it's now rapidly becoming > obsolete. The few times I actually see formal message traffic these days, > it's wrapped up in an e-mail envelope so the precedence indicator becomes > part of the body of a composite message and is invisible to the e-mail > handling system or it's underlying plumbing. > > > Any help? > > > On Thursday 10 October 2002 08:54 am, Gunn, Janet wrote: > >>OK, I am going to be as simplistic as possible. >> >>At the root of it, there need to be enough different labels that there is >>at least a one-to-one mapping (could be many-to-one) from label to policy >>in any given environment. > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 07:54:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17729 for ; Fri, 11 Oct 2002 07:54:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BBtld21010 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 07:55:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBtlv21007 for ; Fri, 11 Oct 2002 07:55:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17715 for ; Fri, 11 Oct 2002 07:53:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBt9v20979; Fri, 11 Oct 2002 07:55:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBs4v20915 for ; Fri, 11 Oct 2002 07:54:04 -0400 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17616 for ; Fri, 11 Oct 2002 07:51:55 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9BBrxOI004756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Oct 2002 07:54:00 -0400 (EDT) Message-ID: <3DA6BB70.4050705@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 07:52:16 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I am a little confused about the relationship between "protocol", "policy", > and "mechanism". > > It seems to me that the "protocol" should definitely be independent of the > underlying technology (cable, 3GPP, etc.). By protocol in this context, I mean, SIP, since that's the subject of discussion. SIP is indeed completely oblivious as to whether it's running on 3GPP, cable or wet string, ignoring the desire by the Wet String Consortium to insert various special extensions into SIP. > > But similarly, it seems that the policy might very well be specific to the > underlying technology. I see no reason why it should be or, even if it is, why we should care. Even if it were the case that wet string gateways always and only support policy A (and nobody else does), the negotiation mechanism (as required by the requirement document) will discover this, without the originating side having to know or care that part of the path is made of twine and another of rubberbands. This avoids tying things together that shouldn't be. Thus, if wet strings suddenly support policy B in addition to A, the system can handle it. If rubber bands also are enhanced to support policy A, again, no need to encode the knowledge of rubber bands into every SIP device. > > And I am not sure what is meant by "mechanism". The "how": how a policy is translated into concrete actions. Think of policy = speed limit is 55 mph mechanism = radar traps, police cruisers, speeding tickets _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 08:22:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18628 for ; Fri, 11 Oct 2002 08:22:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BCNhn22539 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 08:23:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCNhv22536 for ; Fri, 11 Oct 2002 08:23:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18575 for ; Fri, 11 Oct 2002 08:21:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCN6v22502; Fri, 11 Oct 2002 08:23:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCMbv22483 for ; Fri, 11 Oct 2002 08:22:37 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18548 for ; Fri, 11 Oct 2002 08:20:28 -0400 (EDT) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 1556567117; Fri, 11 Oct 2002 04:38:38 -0400 (EDT) Subject: Re: [Ieprep] requirements document(s) (Accounting) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <161.157751f1.2ad793fe@aol.com> Message-Id: <1D2D7080-DD14-11D6-86D3-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 08:22:31 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 10, 2002, at 22:39 America/Montreal, Mpierce1@aol.com wrote: > When a network provides the capability for a user to place a voice > call and get priority over others, including possible preemption, it > must keep a record of the uses of that priority service. (Whether or > not that record must include duration of the call may be open, but I'd > bet they would want it.) > > I believe this requirement exists no matter what technology is being > used to transport the communications, whether circuit switched > networks, packet networks, or carrier pigeons. Disagree. Here is a counter-example. A service provider might offer "routine" and "preferred" service using DiffServ for packet marketing. It likely will charge on a flat-rate basis for this, with a customer falling into one of two categories: routine-only service routine-or-preferred service In this case, it would be up to the end-user to mark the DiffServ bits correctly prior to the packet arriving at the service provider. And the service provider would probably merely configure the edge device to re-write the DiffServ bits to "routine" for all customers having the routine-only service offering. Existing network equipment often has this capability because this is what IP service providers have been asking for over the past few years. I'll observe that today nearly all IP service providers primarily offer flat-rate billing. The next most common method (far less common than flat rate) is to count the sum of the traffic moving through an interface over some unit of time and charge based on a percentile (often 90 percentile) of that traffic count. Most IP service providers do not have the capability to perform packet accounting today. So if accounting is really a requirement, then this service will not be widely available from IP service providers anytime soon. Note that in my example the IP service provider is deliberately not participating in any application-layer services (e.g. VoIP). Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 08:32:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18951 for ; Fri, 11 Oct 2002 08:32:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BCXjf22831 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 08:33:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCXjv22828 for ; Fri, 11 Oct 2002 08:33:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18947 for ; Fri, 11 Oct 2002 08:31:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCX5v22808; Fri, 11 Oct 2002 08:33:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCWxv22794 for ; Fri, 11 Oct 2002 08:32:59 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18934 for ; Fri, 11 Oct 2002 08:30:49 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 11 Oct 2002 13:32:51 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Henning Schulzrinne cc: ieprep@ietf.org Subject: Re: [Ieprep] policy & labels In-reply-to: Your message of "Wed, 09 Oct 2002 17:13:40 EDT." <3DA49C04.1090708@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <891.1034339570@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 13:32:50 +0100 thanks for the additional perspective. my default thinking process tends to center on the relationship of labels and a desire to retain a great deal of flexability in their specification and association of characteristics. I want to have a schema that allows one the freedom to describe the relationship (importance?) of *related* labels as in the case of MLPP. And I also want to have a separation of unrelated labels and a separation of the type of mechanism to achieve the characterization associated with a label -- this separation in the form of local policy for whomever is providing support N sets of labels. In the case of SIP, presumably in the form of N namespaces. And before anyone panics, the N set is not all defined namespaces, but just those that have been contracted by a provider to support. -ken ps, I believe we are in agreement -----------------Original Message------------------- Subject: Re: [Ieprep] policy & labels From: Henning Schulzrinne Date: Wed, 09 Oct 2002 17:13:40 -0400 (22:13 BST) To: Ken Carlberg Cc: ieprep@ietf.org, rja@extremenetworks.com My 2c (Euro): I think there are actually two separate problems here, binding and specificity. As usual in networking, this is partially a question of indirection or bindings, I think. Any protocol identifier value can either mean a specific thing or be bound to a specific interpretation at "run time" or per "session". This binding can be more-or-less-static, as part of some profile (generally bad), or dynamically signaled, as, say, the binding between RTP payload type numbers and codecs is in SDP. (SIP is, at heart, a binding protocol.) Late binding is necessary if, for efficiency reasons, the space of the identifier is insufficient to contain all possible values and if only a small set is likely to be needed at the same time. This is, generally, not the case for text-based protocols, as there is no shortage of label space. (It's equivalent to a variable-length integer of unbounded length.) Thus, dynamic binding of some short identifier to the "real" thing is not necessary here and likely to be counterproductive. If my understanding of DiffServ is correct, there is a recommended DSCP for each PHB, but one could bind one locally, with a yet-to-be-specified mechanism. One reason is that the DSCP is very short (6 bits), so running out of code points is a very real problem. A separate question is the level of detail that is specified; this is sometimes referred to as "policy vs. mechanism". A crude way to put this might be "externally visible behavior vs. local implementation". For example, it may be sufficient to specify that "for the same call, if you only change the labeling, it should not get worse treatment". This avoids having to specify behavior which may be left to local capabilities, such as displacement of existing calls. In general, I think you want the minimum amount of mechanism detail so as to give maximum freedom to implementations to optimize for local circumstances ("narrow interface"). As one example, the PHBs don't specify precisely how the queueing mechanism needs to be implemented or, as another example, IntServ guaranteed service doesn't specify the precise algorithm, just the externally visible behavior, even though there's only one known mechanism to implement it precisely. In our case, however, we are mostly "importing" external descriptions. The specificity of the behavior description is given by others. SIP is just the messenger. This argues, in particular, that we can't just have a limited set of mechanisms ("don't queue", "preempt"), as that would make extensions difficult. (On the other hand, if you know you can exhaustively specify the list of behaviors, it's clearly better to do that, as it reduces the number of failure cases. You can then test for all bit combinations and know that nobody can surprise you.) It does not, in my opinion, rule out a reference to a very detailed scheme. Similarly, in principle, you could have fairly detailed PHB descriptions that govern all relevant packet treatment. Indeed, recent history is an indication that too abstract a specification may not be implementable at all, leading to a more precise (and thus constraining) specification. Clearly, this is not a bright line, to the left of which lies sainthood and to the right religious dogma. (One could draw parallels that religious denominations come to different conclusions as to how much their relevant texts are policy vs. mechanism, but I won't go there.) I don't think anybody in the group is arguing that we should have an exhaustive set of behavior descriptions, where the labeling is some combination of these parameters. This does not mean that, as argued above, that you need to apply additional layers of indirection. At the danger of more analogies, the problem is not dissimilar to including URIs with multiple schemes (which SIP does a lot...). Relevant end systems need to know what to do with them, but the protocol itself can be fairly open to new ones, without affecting the core protocol functionality itself. ----------------------------------------------- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 08:41:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19199 for ; Fri, 11 Oct 2002 08:41:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BCgcj23663 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 08:42:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCgcv23660 for ; Fri, 11 Oct 2002 08:42:38 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19178 for ; Fri, 11 Oct 2002 08:40:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCg4v23643; Fri, 11 Oct 2002 08:42:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCfWv23625 for ; Fri, 11 Oct 2002 08:41:32 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19119 for ; Fri, 11 Oct 2002 08:39:22 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 11 Oct 2002 13:41:26 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: ieprep@ietf.org, rja@extremenetworks.com Subject: Re: [Ieprep] policy & labels In-reply-to: Your message of "Wed, 09 Oct 2002 15:53:51 EDT." <106.198e8d89.2ad5e34f@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <906.1034340085@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 13:41:25 +0100 > So why is this now such a big deal? I think this whole thing about "policy" > vs" "label" (or "indication") is a non-issue and should be dropped so we > can get on with defining what is needed. the consensus on this list and at meetings has been that policy vs label is an issue. so, its not going to be dropped. my hope is that the added comments from Henning were helpful in explaining the issue. > 0 = treatment a > 1 = treatment b > > and the "policy" in each device (not in the standard) would somehow > know that: > a = normal delay > b = low delay needed > If that approach were followed for every field or piece of information > in the protocol, the specification would look pretty silly, and I > seriously doubt that sufficient interoperability would ever occur. no, this is a poor interpretation of my previous message. i purposely mentioned articulating a set of characteristics for a related set of labels such as those that one would expect with MLPP. I also mentioned AF as a particular example that one could use in defining labels. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 08:46:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19491 for ; Fri, 11 Oct 2002 08:46:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BClo523890 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 08:47:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BClnv23887 for ; Fri, 11 Oct 2002 08:47:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19462 for ; Fri, 11 Oct 2002 08:45:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BClFv23848; Fri, 11 Oct 2002 08:47:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCk2v23797 for ; Fri, 11 Oct 2002 08:46:02 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19292 for ; Fri, 11 Oct 2002 08:43:52 -0400 (EDT) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 597DC67117; Fri, 11 Oct 2002 05:01:58 -0400 (EDT) Subject: Re: [Ieprep] policy & labels Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: Ken Carlberg From: RJ Atkinson In-Reply-To: <891.1034339570@cs.ucl.ac.uk> Message-Id: <612F6EA4-DD17-11D6-86D3-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 08:45:53 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm concerned that some folks are reading "label" and inferring "SIP or other telephony application label". I read "label" and understand that this might be a telephony application label or a DiffServ code point or some other non-telephony label or some other non-application-layer label. This difference in reading seems to be causing (some) folks to talk past each other in a way that does not help the group to converge to consensus. For my part, I think that where "label" happens to be an instance of a DiffServ/IP ToS bit pattern, people are confused if they think that more than 2 or 3 total user labels will be available in real deployments from large ISPs (and having DiffServ supported at all for customer traffic is not a given, by the way).[1] Ran rja@extremenetworks.com [1] The long-standing "Internet Control" code point from RFC-791 is widely used in ISP routers to prefer BGP traffic over other traffic in order to maximise Internet reachability and to maximise stability of inter-domain routing. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 08:56:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19851 for ; Fri, 11 Oct 2002 08:56:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BCvjY24211 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 08:57:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCvjv24208 for ; Fri, 11 Oct 2002 08:57:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19825 for ; Fri, 11 Oct 2002 08:55:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCv7v24191; Fri, 11 Oct 2002 08:57:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCuLv24166 for ; Fri, 11 Oct 2002 08:56:21 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19777 for ; Fri, 11 Oct 2002 08:54:11 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 11 Oct 2002 13:56:13 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: RJ Atkinson cc: ieprep Subject: Re: [Ieprep] policy & labels In-reply-to: Your message of "Fri, 11 Oct 2002 08:45:53 EDT." <612F6EA4-DD17-11D6-86D3-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <937.1034340972@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 13:56:12 +0100 > I'm concerned that some folks are reading "label" and inferring > "SIP or other telephony application label". I read "label" and > understand that this might be a telephony application label > or a DiffServ code point or some other non-telephony label > or some other non-application-layer label. yes, totally agreed. part of the motivation of the original note was to get possible feedback that would allow us to expand on the requirement (of the general-requirements draft) on the separation of policy and labels. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:31:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23440 for ; Fri, 11 Oct 2002 10:31:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEX6428861 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:33:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEX6v28858 for ; Fri, 11 Oct 2002 10:33:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23375 for ; Fri, 11 Oct 2002 10:30:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEW7v28714; Fri, 11 Oct 2002 10:32:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEVFv28670 for ; Fri, 11 Oct 2002 10:31:15 -0400 Received: from imo-d10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23217 for ; Fri, 11 Oct 2002 10:29:04 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d10.mx.aol.com (mail_out_v34.13.) id j.119.18fbc00d (4262); Fri, 11 Oct 2002 10:31:06 -0400 (EDT) Message-ID: <119.18fbc00d.2ad83aaa@aol.com> Subject: Re: [Ieprep] policy & labels To: rja@extremenetworks.com, K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_119.18fbc00d.2ad83aaa_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:31:06 EDT --part1_119.18fbc00d.2ad83aaa_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 8:48:09 AM Eastern Standard Time, rja@extremenetworks.com writes: > I'm concerned that some folks are reading "label" and inferring > "SIP or other telephony application label". I read "label" and > understand that this might be a telephony application label > or a DiffServ code point or some other non-telephony label > or some other non-application-layer label. > > This difference in reading seems to be causing (some) folks to talk past > each other in a way that does not help the group to converge to > consensus. > [MAP] Yes, it's obvious that different folks have a different understanding of what "label" and "policy" (and "indication") mean. That is why I questioned the requirement that says "REQ-7: Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy." Can someone point me to a definition of the word "label" when used in this context? We are still talking about SIP (I hope), but I do not find the word defined or used in RFC3261. Mike Pierce Artel --part1_119.18fbc00d.2ad83aaa_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 8:48:09 AM Eastern Standard Time, rja@extremenetworks.com writes:


I'm concerned that some folks are reading "label" and inferring
"SIP or other telephony application label".  I read "label" and
understand that this might be a telephony application label
or a DiffServ code point or some other non-telephony label
or some other non-application-layer label.

This difference in reading seems to be causing (some) folks to talk past
each other in a way that does not help the group to converge to
consensus.



[MAP] Yes, it's obvious that different folks have a different understanding of what "label" and "policy" (and "indication") mean. That is why I questioned the requirement that says "REQ-7: Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy."

Can someone point me to a definition of the word "label" when used in this context? We are still talking about SIP (I hope), but I do not find the word defined or used in RFC3261.

Mike Pierce
Artel

--part1_119.18fbc00d.2ad83aaa_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:31:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23453 for ; Fri, 11 Oct 2002 10:31:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEX8M28876 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:33:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEX8v28873 for ; Fri, 11 Oct 2002 10:33:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23380 for ; Fri, 11 Oct 2002 10:30:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEWBv28733; Fri, 11 Oct 2002 10:32:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEVHv28680 for ; Fri, 11 Oct 2002 10:31:17 -0400 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23221 for ; Fri, 11 Oct 2002 10:29:06 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id i.134.15d385c9 (4262); Fri, 11 Oct 2002 10:31:09 -0400 (EDT) Message-ID: <134.15d385c9.2ad83aad@aol.com> Subject: Re: [Ieprep] policy & labels To: K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org, rja@extremenetworks.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_134.15d385c9.2ad83aad_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:31:09 EDT --part1_134.15d385c9.2ad83aad_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 8:41:39 AM Eastern Standard Time, K.Carlberg@cs.ucl.ac.uk writes: > > So why is this now such a big deal? I think this whole thing about > "policy" > > vs" "label" (or "indication") is a non-issue and should be dropped so we > > can get on with defining what is needed. > > the consensus on this list and at meetings has been that policy vs > label is an issue. [MAP] Yes, I understand that the "consensus" has been that "policy" vs label" is an issue, but I think that the ongoing discussion indicates that no one knows what the issue is, or at least, everyone has a different idea of what it means. This is getting no where fast. > my hope is that > [MAP] Yes, I guess Henning's comments are helping to make something clear (they usually do), but I still don't see what the impact is to the task at hand which is to define a way to carry an indication of the priority level of the call through SIP. > > > 0 = treatment a > > 1 = treatment b > > > > and the "policy" in each device (not in the standard) would somehow > > know that: > > a = normal delay > > b = low delay needed > > > If that approach were followed for every field or piece of information > > in the protocol, the specification would look pretty silly, and I > > seriously doubt that sufficient interoperability would ever occur. > > [MAP] It may be an incorrect interpretation, but it is not "poor". I really couldn't tell what you were trying to say, and the comments indicate that others couldn't either. Mike Pierce Artel --part1_134.15d385c9.2ad83aad_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 8:41:39 AM Eastern Standard Time, K.Carlberg@cs.ucl.ac.uk writes:


> So why is this now such a big deal? I think this whole thing about "policy"
> vs" "label" (or "indication") is a non-issue and should be dropped so we
> can get on with defining what is needed.

the consensus on this list and at meetings has been that policy vs
label is an issue.  so, its not going to be dropped.



[MAP] Yes, I understand that the "consensus" has been that "policy" vs label" is an issue, but I think that the ongoing discussion indicates that no one knows what the issue is, or at least, everyone has a different idea of what it means. This is getting no where fast.


my hope is that
the added comments from Henning were helpful in explaining the issue.



[MAP] Yes, I guess Henning's comments are helping to make something clear (they usually do), but I still don't see what the impact is to the task at hand which is to define a way to carry an indication of the priority level of the call through SIP.


> 0 = treatment a
> 1 = treatment b
>
> and the "policy" in each device (not in the standard) would somehow
> know that:
> a = normal delay
> b = low delay needed

> If that approach were followed for every field or piece of information
> in the protocol, the specification would look pretty silly, and I
> seriously doubt that sufficient interoperability would ever occur.

no, this is a poor interpretation of my previous message.



[MAP] It may be an incorrect interpretation, but it is not "poor". I really couldn't tell what you were trying to say, and the comments indicate that others couldn't either.

Mike Pierce
Artel


--part1_134.15d385c9.2ad83aad_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:31:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23467 for ; Fri, 11 Oct 2002 10:31:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEXCb28899 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:33:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEXCv28895 for ; Fri, 11 Oct 2002 10:33:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23399 for ; Fri, 11 Oct 2002 10:31:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEWEv28752; Fri, 11 Oct 2002 10:32:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEVLv28684 for ; Fri, 11 Oct 2002 10:31:21 -0400 Received: from imo-r05.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23224 for ; Fri, 11 Oct 2002 10:29:10 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v34.13.) id j.ac.2eb92c3d (4262); Fri, 11 Oct 2002 10:31:12 -0400 (EDT) Message-ID: Subject: Re: [Ieprep] requirements document(s) (Accounting) To: rja@extremenetworks.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_ac.2eb92c3d.2ad83ab0_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:31:12 EDT --part1_ac.2eb92c3d.2ad83ab0_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 8:21:10 AM Eastern Standard Time, rja@extremenetworks.com writes: > On Thursday, Oct 10, 2002, at 22:39 America/Montreal, Mpierce1@aol.com > wrote: > > When a network provides the capability for a user to place a voice > > call and get priority over others, including possible preemption, it > > must keep a record of the uses of that priority service. (Whether or > > not that record must include duration of the call may be open, but I'd > > bet they would want it.) > > > > I believe this requirement exists no matter what technology is being > > used to transport the communications, whether circuit switched > > networks, packet networks, or carrier pigeons. > > Disagree. Here is a counter-example. > [MAP] Once again, your response and comments focus of "billing". I was not talking about "billing". I am talking about the need to keep call records in order to detect use of the priority service, and to be able to detect misuse (someone using it that is not authorized or someone who is authorized but using it incorrectly). Mike Pierce Artel --part1_ac.2eb92c3d.2ad83ab0_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 8:21:10 AM Eastern Standard Time, rja@extremenetworks.com writes:


On Thursday, Oct 10, 2002, at 22:39 America/Montreal, Mpierce1@aol.com
wrote:
> When a network provides the capability for a user to place a voice
> call and get priority over others, including possible preemption, it
> must keep a record of the uses of that priority service. (Whether or
> not that record must include duration of the call may be open, but I'd
> bet they would want it.)
>
> I believe this requirement exists no matter what technology is being
> used to transport the communications, whether circuit switched
> networks, packet networks, or carrier pigeons.

Disagree.  Here is a counter-example.



[MAP] Once again, your response and comments focus of "billing". I was not talking about "billing". I am talking about the need to keep call records in order to detect use of the priority service, and to be able to detect misuse (someone using it that is not authorized or someone who is authorized but using it incorrectly).

Mike Pierce
Artel

--part1_ac.2eb92c3d.2ad83ab0_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:42:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23858 for ; Fri, 11 Oct 2002 10:42:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEi4S29732 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:44:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEi4v29729 for ; Fri, 11 Oct 2002 10:44:04 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23840 for ; Fri, 11 Oct 2002 10:41:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEh5v29700; Fri, 11 Oct 2002 10:43:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEglv29681 for ; Fri, 11 Oct 2002 10:42:47 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23743 for ; Fri, 11 Oct 2002 10:40:30 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Oct 2002 10:40:50 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-1 to REQ-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:40:38 -0400 Thanks for the clarification on mechanism. I agree that we shouldn't care about the technology dependant differences in policy. I CAN see, though that it would make sense to implement, for instance, multiple priority classes when you have low bandwidth connections to be shared, and a single priority class when you have high bandwidth connections to be shared, even if the relative utilization is the same. I think these would count as different policies. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, October 11, 2002 7:52 AM To: Gunn, Janet Cc: King, Kimberly S.; Ieprep (E-mail) Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5 > I am a little confused about the relationship between "protocol", "policy", > and "mechanism". > > It seems to me that the "protocol" should definitely be independent of the > underlying technology (cable, 3GPP, etc.). By protocol in this context, I mean, SIP, since that's the subject of discussion. SIP is indeed completely oblivious as to whether it's running on 3GPP, cable or wet string, ignoring the desire by the Wet String Consortium to insert various special extensions into SIP. > > But similarly, it seems that the policy might very well be specific to the > underlying technology. I see no reason why it should be or, even if it is, why we should care. Even if it were the case that wet string gateways always and only support policy A (and nobody else does), the negotiation mechanism (as required by the requirement document) will discover this, without the originating side having to know or care that part of the path is made of twine and another of rubberbands. This avoids tying things together that shouldn't be. Thus, if wet strings suddenly support policy B in addition to A, the system can handle it. If rubber bands also are enhanced to support policy A, again, no need to encode the knowledge of rubber bands into every SIP device. > > And I am not sure what is meant by "mechanism". The "how": how a policy is translated into concrete actions. Think of policy = speed limit is 55 mph mechanism = radar traps, police cruisers, speeding tickets _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:50:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24220 for ; Fri, 11 Oct 2002 10:50:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEpov30110 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:51:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEpov30107 for ; Fri, 11 Oct 2002 10:51:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24208 for ; Fri, 11 Oct 2002 10:49:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEp4v30083; Fri, 11 Oct 2002 10:51:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEo4v30003 for ; Fri, 11 Oct 2002 10:50:04 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24091 for ; Fri, 11 Oct 2002 10:47:49 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 778EC67104 for ; Fri, 11 Oct 2002 07:05:27 -0400 (EDT) Subject: Re: [Ieprep] policy & labels Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <119.18fbc00d.2ad83aaa@aol.com> Message-Id: <9BFC9614-DD28-11D6-85CF-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:49:13 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com wrote: > Can someone point me to a definition of the word "label" when used in > this context? Any kind of label at any protocol layer, not limited in scope to telephony applications or any particular telephony related protocol (e.g. SIP). Any telephony-specific requirements (e.g. SIP labels) would be **out of scope** for the general requirements document and would only be present in a telephony-specific requirements document. > We are still talking about SIP (I hope), but I do not find the word > defined or used in RFC3261. I do NOT think we are talking only about SIP or specifically about SIP, so I think the above sentence is an example of the confusion I was referring to. I think the requirements document is talking about any kind of label (e.g. DiffServ codepoint, SIP label, whatever other labels that might exist at any protocol layer). Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:51:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24295 for ; Fri, 11 Oct 2002 10:51:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEqix30186 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:52:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEqiv30183 for ; Fri, 11 Oct 2002 10:52:44 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24240 for ; Fri, 11 Oct 2002 10:50:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEq4v30132; Fri, 11 Oct 2002 10:52:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEplv30103 for ; Fri, 11 Oct 2002 10:51:47 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24205 for ; Fri, 11 Oct 2002 10:49:36 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 11 Oct 2002 10:51:04 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101110510329542 ; Fri, 11 Oct 2002 10:51:03 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QS81S>; Fri, 11 Oct 2002 10:52:13 -0400 Message-Id: From: "King, Kimberly S." To: "'Henning Schulzrinne'" , "Gunn, Janet" Cc: goldmans@agcs.com, "King Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] requirements document(s) to SIPPING MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:51:02 -0400 > > Indeed. I thought I had addressed this issue in an earlier message > (short summary: sometimes, depending on what a proxy does with > requests), after which somebody mentioned that prioritizing > would be too > difficult. Somebody mentioned that this added complexity especially over possibly different security domains and that the utility of such a feature had already been questioned by the SIPPING working group. That somebody did not say that writing a scheduling algorithm to process priority vs. something else was difficult. (It seems that somebody took an OS class when getting a bachelors degree in computer science and doesn't consider those types of algorithms challenging.) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:52:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24329 for ; Fri, 11 Oct 2002 10:52:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BErtd30263 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:53:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BErtv30260 for ; Fri, 11 Oct 2002 10:53:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24322 for ; Fri, 11 Oct 2002 10:51:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEr6v30236; Fri, 11 Oct 2002 10:53:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEqNv30165 for ; Fri, 11 Oct 2002 10:52:23 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24219 for ; Fri, 11 Oct 2002 10:50:08 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 767E167104 for ; Fri, 11 Oct 2002 07:07:57 -0400 (EDT) Subject: Re: [Ieprep] policy & labels Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <134.15d385c9.2ad83aad@aol.com> Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:51:47 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com wrote: > > [MAP] Yes, I guess Henning's comments are helping to make something > clear (they usually do), but I still don't see what the impact is to > the task at hand which is to define a way to carry an indication of > the priority level of the call through SIP. That task is OUT OF SCOPE for the general IEprep Requirements document. It might be IN SCOPE for a telephony-specific requirements document, depending on how detailed one wanted to get. Requirements should be high-level, so independent of particular protocols (e.g. SIP). Something in SIP itself (or in DiffServ itself) would be an example of a *mechanism*. High-level requirements must not specify mechanisms. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:57:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24489 for ; Fri, 11 Oct 2002 10:57:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BEx6R30544 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 10:59:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEx5v30541 for ; Fri, 11 Oct 2002 10:59:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24476 for ; Fri, 11 Oct 2002 10:56:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEw5v30443; Fri, 11 Oct 2002 10:58:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEvIv30411 for ; Fri, 11 Oct 2002 10:57:18 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24399 for ; Fri, 11 Oct 2002 10:55:07 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 11 Oct 2002 15:57:11 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: ieprep@ietf.org Subject: Re: [Ieprep] policy & labels In-reply-to: Your message of "Fri, 11 Oct 2002 10:31:09 EDT." <134.15d385c9.2ad83aad@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1127.1034348231@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 15:57:11 +0100 > [MAP] Yes, I understand that the "consensus" has been that "policy" vs > label" is an issue, but I think that the ongoing discussion indicates > that no one knows what the issue is, or at least, everyone has a > different idea of what it means. This is getting no where fast. I don't agree with your assessment that no one knows what the issue is. > [MAP] It may be an incorrect interpretation, but it is not "poor". I > really couldn't tell what you were trying to say, and the comments > indicate that others couldn't either. actually, the use of the word "poor" in the previous message, was a poor choice of words on my part. so, my apologies. my original comment was meant as a starting point. it was stated in a general sense, and as it has been mentioned in the past, there can be a tradeoff by not being too specific. as for Henning's response, it seemed more of an extension of my original thread with some additional thoughts regarding SIP. I don't recall a comment of confusion on his part (though if he wants to add that now in retrospect, thats fine). and I regret that my attempt to provide some help has continued the confusion for you. regards, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 10:58:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24527 for ; Fri, 11 Oct 2002 10:58:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BF02i30611 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 11:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BF01v30608 for ; Fri, 11 Oct 2002 11:00:01 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24523 for ; Fri, 11 Oct 2002 10:57:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEx4v30533; Fri, 11 Oct 2002 10:59:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BEwWv30464 for ; Fri, 11 Oct 2002 10:58:32 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24423 for ; Fri, 11 Oct 2002 10:56:16 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 2370D67104 for ; Fri, 11 Oct 2002 07:14:05 -0400 (EDT) Subject: Re: [Ieprep] requirements document(s) (Accounting) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 10:57:55 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com wrote: > [MAP] Once again, your response and comments focus of "billing". I was > not talking about "billing". I am talking about the need to keep call > records in order to detect use of the priority service, and to be able > to detect misuse (someone using it that is not authorized or someone > who is authorized but using it incorrectly). No, the comments were not focused on billing. Please re-read them more closely. Typically (and specifically in my example), ISPs do *zero* accounting of how many packets/bytes use the preferred service versus the routine service. Generally speaking, the equipment that ISPs use is not capable of such accounting (e.g. for DiffServ, which was my counter example). In this example, the ISP equipment only performs a pre-configured policy decision (i.e. customer X is permitted to send packets marked preferred xor customer X is not permitted to send packets marked preferred) that is typically implemented as a kind of packet filter on the ingress interface to the ISP from customer X. Note that in this model, any customer able to send a packet marked as preferred is capable of sending 100% of their traffic with the preferred marking. Also note that zero *accounting* is occuring. Regards, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 12:07:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26752 for ; Fri, 11 Oct 2002 12:07:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BG8o302262 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 12:08:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BG8ov02259 for ; Fri, 11 Oct 2002 12:08:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26697 for ; Fri, 11 Oct 2002 12:06:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BG8Bv02249; Fri, 11 Oct 2002 12:08:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BG7sv02217 for ; Fri, 11 Oct 2002 12:07:54 -0400 Received: from imo-r08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26686 for ; Fri, 11 Oct 2002 12:05:42 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v34.13.) id j.ba.2d5f969d (4262); Fri, 11 Oct 2002 12:07:41 -0400 (EDT) Message-ID: Subject: Re: [Ieprep] requirements document(s) (Accounting) To: rja@extremenetworks.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_ba.2d5f969d.2ad8514c_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 12:07:40 EDT --part1_ba.2d5f969d.2ad8514c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 11:00:53 AM Eastern Standard Time, rja@extremenetworks.com writes: > On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com > wrote: > > [MAP] Once again, your response and comments focus of "billing". I was > > not talking about "billing". I am talking about the need to keep call > > records in order to detect use of the priority service, and to be able > > to detect misuse (someone using it that is not authorized or someone > > who is authorized but using it incorrectly). > > No, the comments were not focused on billing. Please re-read them > [MAP] I did, and so can everyone else. You talk mostly about billing. Further, you are talking about "packets", which is not the issue here. Let's focus on the accounting requirements for priority calls. > > Typically (and specifically in my example), ISPs do *zero* accounting > of how many packets/bytes use the preferred service versus the routine > service. > Generally speaking, the equipment that ISPs use is not capable of such > accounting > (e.g. for DiffServ, which was my counter example). In this example, the > ISP equipment > only performs a pre-configured policy decision (i.e. customer X is > permitted to send > packets marked preferred xor customer X is not permitted to send packets > marked > preferred) that is typically implemented as a kind of packet filter on the > ingress > interface to the ISP from customer X. Note that in this model, any > customer able > to send a packet marked as preferred is capable of sending 100% of their > traffic > with the preferred marking. Also note that zero *accounting* is occuring. > > Regards, > > Ran > [MAP] And I couldn't imagine stating a requirement that anyone must record things like number of packets/bytes that are transferred as a result of setting up a high priority call. I suppose someone may want to bill on that basis, but that was not the point. We're talking about requirements for creating a CDR for the call setup, not the requirements for counting packet transfer. Mike Pierce Artel --part1_ba.2d5f969d.2ad8514c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 11:00:53 AM Eastern Standard Time, rja@extremenetworks.com writes:


On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com
wrote:
> [MAP] Once again, your response and comments focus of "billing". I was
> not talking about "billing". I am talking about the need to keep call
> records in order to detect use of the priority service, and to be able
> to detect misuse (someone using it that is not authorized or someone
> who is authorized but using it incorrectly).

   No, the comments were not focused on billing.  Please re-read them
more closely.



[MAP] I did, and so can everyone else. You talk mostly about billing. Further, you are talking about "packets", which is not the issue here. Let's focus on the accounting requirements for priority calls.


   Typically (and specifically in my example), ISPs do *zero* accounting
of how many packets/bytes use the preferred service versus the routine service.
Generally speaking, the equipment that ISPs use is not capable of such accounting
(e.g. for DiffServ, which was my counter example).  In this example, the ISP equipment
only performs a pre-configured policy decision (i.e. customer X is permitted to send
packets marked preferred xor customer X is not permitted to send packets marked
preferred) that is typically implemented as a kind of packet filter on the ingress
interface to the ISP from customer X.  Note that in this model, any customer able
to send a packet marked as preferred is capable of sending 100% of their traffic
with the preferred marking.  Also note that zero *accounting* is occuring.

Regards,

Ran



[MAP] And I couldn't imagine stating a requirement that anyone must record things like number of packets/bytes that are transferred as a result of setting up a high priority call. I suppose someone may want to bill on that basis, but that was not the point. We're talking about requirements for creating a CDR for the call setup, not the requirements for counting packet transfer.

Mike Pierce
Artel
--part1_ba.2d5f969d.2ad8514c_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 12:07:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26766 for ; Fri, 11 Oct 2002 12:07:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BG8sW02277 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 12:08:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BG8sv02274 for ; Fri, 11 Oct 2002 12:08:54 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26701 for ; Fri, 11 Oct 2002 12:06:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BG87v02232; Fri, 11 Oct 2002 12:08:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BG7qv02213 for ; Fri, 11 Oct 2002 12:07:52 -0400 Received: from imo-m02.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26683 for ; Fri, 11 Oct 2002 12:05:40 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m02.mx.aol.com (mail_out_v34.13.) id j.57.132b6c58 (4262); Fri, 11 Oct 2002 12:07:45 -0400 (EDT) Message-ID: <57.132b6c58.2ad85151@aol.com> Subject: Re: [Ieprep] policy & labels To: rja@extremenetworks.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_57.132b6c58.2ad85151_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 12:07:45 EDT --part1_57.132b6c58.2ad85151_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 10:51:53 AM Eastern Standard Time, rja@extremenetworks.com writes: > On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com wrote: > > Can someone point me to a definition of the word "label" when used in > this context? > > Any kind of label at any protocol layer, not limited in scope to telephony > applications or any particular telephony related protocol (e.g. SIP). > > Any telephony-specific requirements (e.g. SIP labels) would be **out of > scope** > for the general requirements document and would only be present in a > [MAP] I take the above to mean that you can't point me to an existing definition of "label" (like in an RFC). > > > We are still talking about SIP (I hope), but I do not find the word > > defined or used in RFC3261. > > I do NOT think we are talking only about SIP or specifically about SIP, > so I think the above sentence is an example of the confusion I was > [MAP] We are discussing a requirement in the draft titled "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol". > > I think the requirements document is talking about any kind of label > (e.g. DiffServ codepoint, SIP label, whatever other labels that might > [MAP] Also, the requirement we are discussing is in a list of requirements that is preceeded by the statement: "calls are marked in various ways to indicate priorities. Below are some requirements for such mechanisms." i.e., this discussion is not about marking packets. That will be an interesting discussion for another day. This discussion is about marking call setup (in the INVITE) and nothing more. You use the term "SIP label" as if I should know what that means. As I noted, the word is not used in RFC 3261. RFC 3261 defines terms for "Header", "Header Field", and "Header Field Value". The end result we're trying to get to is the definition of a new header for Resource-priority. So why don't we use those defined SIP terms for the remainder of this discussion. That would reduce confusion. > > Ran > > Mike Pierce Artel --part1_57.132b6c58.2ad85151_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 10:51:53 AM Eastern Standard Time, rja@extremenetworks.com writes:


On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com wrote:
> Can someone point me to a definition of the word "label" when used in this context?

Any kind of label at any protocol layer, not limited in scope to telephony
applications or any particular telephony related protocol (e.g. SIP).

Any telephony-specific requirements (e.g. SIP labels) would be **out of scope**
for the general requirements document and would only be present in a
telephony-specific requirements document.



[MAP] I take the above to mean that you can't point me to an existing definition of "label" (like in an RFC).


> We are still talking about SIP (I hope), but I do not find the word
> defined or used in RFC3261.

I do NOT think we are talking only about SIP or specifically about SIP,
so I think the above sentence is an example of the confusion I was
referring to.



[MAP] We are discussing a requirement in the draft titled "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol".


I think the requirements document is talking about any kind of label
(e.g. DiffServ codepoint, SIP label, whatever other labels that might
exist at any protocol layer).



[MAP] Also, the requirement we are discussing is in a list of requirements that is preceeded by the statement:

"calls are marked in various ways to indicate priorities. Below are some requirements for such mechanisms."

i.e., this discussion is not about marking packets. That will be an interesting discussion for another day. This discussion is about marking call setup (in the INVITE) and nothing more.

You use the term "SIP label" as if I should know what that means. As I noted, the word is not used in RFC 3261. RFC 3261 defines terms for "Header", "Header Field", and "Header Field Value". The end result we're trying to get to is the definition of a new header for Resource-priority. So why don't we use those defined SIP terms for the remainder of this discussion. That would reduce confusion.


Ran




Mike Pierce
Artel
--part1_57.132b6c58.2ad85151_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 12:30:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27409 for ; Fri, 11 Oct 2002 12:30:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BGVm502904 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 12:31:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BGVmv02901 for ; Fri, 11 Oct 2002 12:31:48 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27386 for ; Fri, 11 Oct 2002 12:29:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BGV6v02882; Fri, 11 Oct 2002 12:31:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BGUTv02848 for ; Fri, 11 Oct 2002 12:30:29 -0400 Received: from bootstrap.agcs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27329 for ; Fri, 11 Oct 2002 12:28:15 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id JAA06927 for ; Fri, 11 Oct 2002 09:30:22 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id H3TSIM00.Q4R for ; Fri, 11 Oct 2002 09:30:22 -0700 Received: FROM agcs.com BY mkultra ; Fri Oct 11 09:30:21 2002 -0700 Message-ID: <3DA6FC9D.5316CD7E@agcs.com> From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: rja@extremenetworks.com, ieprep@ietf.org Subject: Re: [Ieprep] requirements document(s) (Accounting) References: Content-Type: multipart/mixed; boundary="------------3F1FC22D4901820F104B5E97" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 09:30:21 -0700 This is a multi-part message in MIME format. --------------3F1FC22D4901820F104B5E97 Content-Type: multipart/alternative; boundary="------------DE8C3612BFD7330F26B5548B" --------------DE8C3612BFD7330F26B5548B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike, A question for you: (I really don't want to get caught up in the discussion aspect about if accounting needs protocol or not.) My question is simply that in the PSTN network "accounting" consisted of two different mechanisms. There was the AMA record for the particular call which generated billing information specific to that call. There also were a great number of peg counters that provided information about how often and which special treatments were actually invoked and how often they resulted in a successful call. Are you envisioning either or both mechanisms? Mpierce1@aol.com wrote: > In a message dated 10/11/2002 11:00:53 AM Eastern Standard Time, > rja@extremenetworks.com writes: > > > >> On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com >> >> wrote: >> > [MAP] Once again, your response and comments focus of "billing". I >> was >> > not talking about "billing". I am talking about the need to keep >> call >> > records in order to detect use of the priority service, and to be >> able >> > to detect misuse (someone using it that is not authorized or >> someone >> > who is authorized but using it incorrectly). >> >> No, the comments were not focused on billing. Please re-read >> them >> more closely. > > > > > [MAP] I did, and so can everyone else. You talk mostly about billing. > Further, you are talking about "packets", which is not the issue here. > Let's focus on the accounting requirements for priority calls. > > >> >> Typically (and specifically in my example), ISPs do *zero* >> accounting >> of how many packets/bytes use the preferred service versus the >> routine service. >> Generally speaking, the equipment that ISPs use is not capable of >> such accounting >> (e.g. for DiffServ, which was my counter example). In this example, >> the ISP equipment >> only performs a pre-configured policy decision (i.e. customer X is >> permitted to send >> packets marked preferred xor customer X is not permitted to send >> packets marked >> preferred) that is typically implemented as a kind of packet filter >> on the ingress >> interface to the ISP from customer X. Note that in this model, any >> customer able >> to send a packet marked as preferred is capable of sending 100% of >> their traffic >> with the preferred marking. Also note that zero *accounting* is >> occuring. >> >> Regards, >> >> Ran > > > > > [MAP] And I couldn't imagine stating a requirement that anyone must > record things like number of packets/bytes that are transferred as a > result of setting up a high priority call. I suppose someone may want > to bill on that basis, but that was not the point. We're talking about > requirements for creating a CDR for the call setup, not the > requirements for counting packet transfer. > > Mike Pierce > Artel --------------DE8C3612BFD7330F26B5548B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mike,

A question for you:

(I really don't want to get caught up in the discussion aspect about if accounting needs protocol or not.)

My question is simply that in the PSTN network "accounting" consisted of two different mechanisms. There was the AMA record for the particular call which generated billing information specific to that call. There also were a great number of peg counters that provided information about how often and which special treatments were actually invoked and how often they resulted in a successful call. Are you envisioning either or both mechanisms?

Mpierce1@aol.com wrote:

In a message dated 10/11/2002 11:00:53 AM Eastern Standard Time, rja@extremenetworks.com writes:
 
 
On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com
wrote:
> [MAP] Once again, your response and comments focus of "billing". I was
> not talking about "billing". I am talking about the need to keep call
> records in order to detect use of the priority service, and to be able
> to detect misuse (someone using it that is not authorized or someone
> who is authorized but using it incorrectly).

   No, the comments were not focused on billing.  Please re-read them
more closely.


 

[MAP] I did, and so can everyone else. You talk mostly about billing. Further, you are talking about "packets", which is not the issue here. Let's focus on the accounting requirements for priority calls.
 

 
   Typically (and specifically in my example), ISPs do *zero* accounting
of how many packets/bytes use the preferred service versus the routine service.
Generally speaking, the equipment that ISPs use is not capable of such accounting
(e.g. for DiffServ, which was my counter example).  In this example, the ISP equipment
only performs a pre-configured policy decision (i.e. customer X is permitted to send
packets marked preferred xor customer X is not permitted to send packets marked
preferred) that is typically implemented as a kind of packet filter on the ingress
interface to the ISP from customer X.  Note that in this model, any customer able
to send a packet marked as preferred is capable of sending 100% of their traffic
with the preferred marking.  Also note that zero *accounting* is occuring.

Regards,

Ran


 

[MAP] And I couldn't imagine stating a requirement that anyone must record things like number of packets/bytes that are transferred as a result of setting up a high priority call. I suppose someone may want to bill on that basis, but that was not the point. We're talking about requirements for creating a CDR for the call setup, not the requirements for counting packet transfer.

Mike Pierce
Artel

--------------DE8C3612BFD7330F26B5548B-- --------------3F1FC22D4901820F104B5E97 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org:AG Communication Systems adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;-12184 fn:Stuart Goldman end:vcard --------------3F1FC22D4901820F104B5E97-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 12:50:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27796 for ; Fri, 11 Oct 2002 12:50:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BGpj903945 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 12:51:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BGpjv03942 for ; Fri, 11 Oct 2002 12:51:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27788 for ; Fri, 11 Oct 2002 12:49:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BGp5v03917; Fri, 11 Oct 2002 12:51:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BGolv03902 for ; Fri, 11 Oct 2002 12:50:47 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27771 for ; Fri, 11 Oct 2002 12:48:34 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id C17E867104; Fri, 11 Oct 2002 09:06:47 -0400 (EDT) Subject: Re: [Ieprep] requirements document(s) (Accounting) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep@ietf.org To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: Message-Id: <943322AC-DD39-11D6-85CF-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 12:50:42 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 11, 2002, at 12:07 America/Montreal, Mpierce1@aol.com wrote: > [MAP] I did, and so can everyone else. You talk mostly about billing. > Further, you are talking about "packets", which is not the issue here. > Let's focus on the accounting requirements for priority calls. You have misread my comments twice so far. I think the problem is that you are thinking about telephony calls and SIP, which I was not (and am not) talking about. I'm talking about labels in the context of the general requirements document from Carlberg & Atkinson. In any event, my comments were NOT about billing -- so if you think they are, then you aren't reading what I wrote. And given your track record of problems understanding others words also, I'm now at a loss for words on how to help you understand what I wrote. Terribly sorry. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 13:52:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00344 for ; Fri, 11 Oct 2002 13:52:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BHrm707062 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 13:53:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHrmv07059 for ; Fri, 11 Oct 2002 13:53:48 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00286 for ; Fri, 11 Oct 2002 13:51:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHqIv06953; Fri, 11 Oct 2002 13:52:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHppv06924 for ; Fri, 11 Oct 2002 13:51:51 -0400 Received: from imo-r07.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00210 for ; Fri, 11 Oct 2002 13:49:39 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r07.mx.aol.com (mail_out_v34.13.) id 7.124.1845387e (25914); Fri, 11 Oct 2002 13:51:16 -0400 (EDT) Message-ID: <124.1845387e.2ad86993@aol.com> Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 To: hgs@cs.columbia.edu CC: KIMBERLY.S.KING@saic.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_124.1845387e.2ad86993_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 13:51:15 EDT --part1_124.1845387e.2ad86993_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/9/2002 9:26:58 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > Also, in order to make progress, it may be useful to "forgive" some > obviousness in the document and heave this thing (after another round) > over the fence to SIPPING, even if one could save a few bytes in the RFC > and I-D archive. > [MAP] It's become clear to me, with the ongoing discussion under "Policy and labels", that this requirement REQ-7, as currently written, could be misinterpreted by some in the future, and may itself become a hinderance to making progress. I would suggest that it be rephrased to refer to SIP specific terminology and be very explicit about what the requirement is. Otherwise, this requirement should be deleted. I would suggest the following: REQ-7: Separation of indication and policy. The choice of Header Field Values to indicate priority levels should not in themselves describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should indicate a particular named policy. As an example, instead of specifying a Header Field Value of "Queue, no preemption, limit to 3 minutes", the request should indicate a Value of "High priority", while the local policy in some or all devices is to provide such treatment to "High Priority" calls. Mike Pierce Artel --part1_124.1845387e.2ad86993_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/9/2002 9:26:58 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


Also, in order to make progress, it may be useful to "forgive" some
obviousness in the document and heave this thing (after another round)
over the fence to SIPPING, even if one could save a few bytes in the RFC
and I-D archive.




[MAP] It's become clear to me, with the ongoing discussion under "Policy and labels", that this requirement REQ-7, as currently written, could be misinterpreted by some in the future, and may itself become a hinderance to making progress.

I would suggest that it be rephrased to refer to SIP specific terminology and be very explicit about what the requirement is. Otherwise, this requirement should be deleted. I would suggest the following:

REQ-7: Separation of indication and policy. The choice of Header Field Values to indicate priority levels should not in themselves describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should indicate a particular named policy. As an example, instead of specifying a Header Field Value of "Queue, no preemption, limit to 3 minutes", the request should indicate a Value of "High priority", while the local policy in some or all devices is to provide such treatment to "High Priority" calls.

Mike Pierce
Artel
--part1_124.1845387e.2ad86993_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 13:52:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00357 for ; Fri, 11 Oct 2002 13:52:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BHs5J07086 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 13:54:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHs5v07083 for ; Fri, 11 Oct 2002 13:54:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00316 for ; Fri, 11 Oct 2002 13:51:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHqQv06976; Fri, 11 Oct 2002 13:52:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHpsv06928 for ; Fri, 11 Oct 2002 13:51:54 -0400 Received: from imo-d08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00214 for ; Fri, 11 Oct 2002 13:49:42 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d08.mx.aol.com (mail_out_v34.13.) id j.17f.1008a380 (25914); Fri, 11 Oct 2002 13:51:43 -0400 (EDT) Message-ID: <17f.1008a380.2ad869af@aol.com> Subject: Re: [Ieprep] requirements document(s) (Accounting) To: rja@extremenetworks.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_17f.1008a380.2ad869af_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 13:51:43 EDT --part1_17f.1008a380.2ad869af_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 12:51:08 PM Eastern Standard Time, rja@extremenetworks.com writes: > You have misread my comments twice so far. > > I think the problem is that you are thinking about telephony calls and SIP, > which I was not (and am not) talking about. I'm talking about labels in the > context of the general requirements document from Carlberg & Atkinson. > > In any event, my comments were NOT about billing -- so if you think they > are, then you aren't reading what I wrote. And given your track record of > problems understanding others words also, I'm now at a loss for words on how > to help you understand what I wrote. Terribly sorry. > Ran, I really don't understand what you're getting so upset about and why you're resorting to such nasty statements. They have no place on this e-mail list. I hope we're not referring to a different set of your comments, which your statement above about me misreading it twice would imply. The text from your e-mail of Oct 11 is the following: ------------------------------------------------------------------------------ ----------------------------------- A service provider might offer "routine" and "preferred" service using DiffServ for packet marketing. It likely will charge on a flat-rate basis for this, with a customer falling into one of two categories: routine-only service routine-or-preferred service In this case, it would be up to the end-user to mark the DiffServ bits correctly prior to the packet arriving at the service provider. And the service provider would probably merely configure the edge device to re-write the DiffServ bits to "routine" for all customers having the routine-only service offering. Existing network equipment often has this capability because this is what IP service providers have been asking for over the past few years. I'll observe that today nearly all IP service providers primarily offer flat-rate billing. The next most common method (far less common than flat rate) is to count the sum of the traffic moving through an interface over some unit of time and charge based on a percentile (often 90 percentile) of that traffic count. Most IP service providers do not have the capability to perform packet accounting today. So if accounting is really a requirement, then this service will not be widely available from IP service providers anytime soon. ------------------------------------------------------------------------------ --------------------------------------- The first paragraph talks about "charge on a flat-rate basis". The third paragraph talks about "flat-rate billing" and "charge based on..." The point I made in my previous e-mail, which you didn't comment on, was that the second paragraph, in talking about packets, is outside the scope of the discussion on call accounting requirements. If you would limit your comments to the subject at hand, which is accounting requirements to detect misuse of the priority service, and limit it to call setup requirements, not packet transfer requirements, maybe we could come to some quick agreements on the issues. Mike Pierce Artel --part1_17f.1008a380.2ad869af_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 12:51:08 PM Eastern Standard Time, rja@extremenetworks.com writes:


You have misread my comments twice so far.

I think the problem is that you are thinking about telephony calls and SIP,
which I was not (and am not) talking about.  I'm talking about labels in the
context of the general requirements document from Carlberg & Atkinson.

In any event, my comments were NOT about billing -- so if you think they
are, then you aren't reading what I wrote.  And given your track record of
problems understanding others words also, I'm now at a loss for words on how
to help you understand what I wrote.  Terribly sorry.



Ran,

I really don't understand what you're getting so upset about and why you're resorting to such nasty statements. They have no place on this e-mail list.

I hope we're not referring to a different set of your comments, which your statement above about me misreading it twice would imply. The text from your e-mail of Oct 11 is the following:
-----------------------------------------------------------------------------------------------------------------

   A service provider might offer "routine" and "preferred" service using DiffServ
for packet marketing.  It likely will charge on a flat-rate basis for this,
with a customer falling into one of two categories:
       routine-only service
       routine-or-preferred service

   In this case, it would be up to the end-user to mark the DiffServ bits
correctly prior to the packet arriving at the service provider.  And
the service provider would probably merely configure the edge device
to re-write the DiffServ bits to "routine" for all customers having the
routine-only service offering.  Existing network equipment often has
this capability because this is what IP service providers have been
asking for over the past few years.

   I'll observe that today nearly all IP service providers primarily offer
flat-rate billing.  The next most common method (far less common than flat rate)
is to count the sum of the traffic moving through an interface over some unit of time
and charge based on a percentile (often 90 percentile) of that traffic count.
Most IP service providers do not have the capability to perform packet accounting today.
So if accounting is really a requirement, then this service will not be widely
available from IP service providers anytime soon.

---------------------------------------------------------------------------------------------------------------------

The first paragraph talks about "charge on a flat-rate basis".
The third paragraph talks about "flat-rate billing" and "charge based on..."

The point I made in my previous e-mail, which you didn't comment on, was that the second paragraph, in talking about packets, is outside the scope of the discussion on call accounting requirements.

If you would limit your comments to the subject at hand, which is accounting requirements to detect misuse of the priority service, and limit it to call setup requirements, not packet transfer requirements, maybe we could come to some quick agreements on the issues.

Mike Pierce
Artel
--part1_17f.1008a380.2ad869af_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 13:52:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00370 for ; Fri, 11 Oct 2002 13:52:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BHs6Z07101 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 13:54:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHs6v07098 for ; Fri, 11 Oct 2002 13:54:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00321 for ; Fri, 11 Oct 2002 13:51:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHqUv07007; Fri, 11 Oct 2002 13:52:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BHpuv06932 for ; Fri, 11 Oct 2002 13:51:56 -0400 Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00218 for ; Fri, 11 Oct 2002 13:49:44 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v34.13.) id z.22.304132c7 (25914); Fri, 11 Oct 2002 13:51:11 -0400 (EDT) Message-ID: <22.304132c7.2ad8698f@aol.com> Subject: Re: [Ieprep] requirements document(s) (Accounting) To: goldmans@agcs.com CC: rja@extremenetworks.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_22.304132c7.2ad8698f_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 13:51:11 EDT --part1_22.304132c7.2ad8698f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 12:30:40 PM Eastern Standard Time, goldmans@agcs.com writes: > My question is simply that in the PSTN network "accounting" consisted of two > different mechanisms. There was the AMA record for the particular call > which generated billing information specific to that call. There also were > a great number of peg counters that provided information about how often > and which special treatments were actually invoked and how often they > resulted in a successful call. Are you envisioning either or both > mechanisms? > [MAP] I was speaking of the capabilities that would allow the network administrator to determine who has violated the rules for use of a priority service. That would require "AMA-type" records, even if not used for billing. Peg counters (per trunk group, etc) would be a separate issue, but not the one to address this need. I don't think we have ever dealt with "Peg count" type recording in SIP (nor can I imagine how to). Hope this helps. Mike Pierce Artel --part1_22.304132c7.2ad8698f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 12:30:40 PM Eastern Standard Time, goldmans@agcs.com writes:


My question is simply that in the PSTN network "accounting" consisted of two different mechanisms. There was the AMA record for the particular call which generated billing information specific to that call. There also were a great number of peg counters that provided information about how often and which special treatments were actually invoked and how often they resulted in a successful call. Are you envisioning either or both mechanisms?



[MAP] I was speaking of the capabilities that would allow the network administrator to determine who has violated the rules for use of a priority service. That would require "AMA-type" records, even if not used for billing. Peg counters (per trunk group, etc) would be a separate issue, but not the one to address this need. I don't think we have ever dealt with "Peg count" type recording in SIP (nor can I imagine how to).

Hope this helps.

Mike Pierce
Artel
--part1_22.304132c7.2ad8698f_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 15:16:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02805 for ; Fri, 11 Oct 2002 15:16:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BJHoa11416 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 15:17:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJHnv11413 for ; Fri, 11 Oct 2002 15:17:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02797 for ; Fri, 11 Oct 2002 15:15:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJGHv11342; Fri, 11 Oct 2002 15:16:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJDRv11241 for ; Fri, 11 Oct 2002 15:13:27 -0400 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02688 for ; Fri, 11 Oct 2002 15:11:13 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9BDDbAl019209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Oct 2002 09:13:38 -0400 (EDT) Message-ID: <3DA6CE1B.5060703@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Carlberg CC: ieprep Subject: Re: [Ieprep] policy & labels References: <937.1034340972@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 09:11:55 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As an add-on: while general discussions are certainly useful and maybe educational, we, as a WG, also, I believe, want to get some documents out the door. Thus, may I suggest that people clearly state - which, if any, WG document they are addressing in their comments; - whether they are suggesting changes to an existing document (and clearly state those changes, if not as a wording suggestion, then at least in what is unclear, incomplete or wrong); - or requesting clarification without expecting changes. This would certainly help one document author... Ken Carlberg wrote: >>I'm concerned that some folks are reading "label" and inferring >>"SIP or other telephony application label". I read "label" and >>understand that this might be a telephony application label >>or a DiffServ code point or some other non-telephony label >>or some other non-application-layer label. > > > yes, totally agreed. part of the motivation of the original note > was to get possible feedback that would allow us to expand on the > requirement (of the general-requirements draft) on the separation of > policy and labels. > > -ken > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 15:18:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02892 for ; Fri, 11 Oct 2002 15:18:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BJKbP11598 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 15:20:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJKav11595 for ; Fri, 11 Oct 2002 15:20:36 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02868 for ; Fri, 11 Oct 2002 15:18:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJJ9v11540; Fri, 11 Oct 2002 15:19:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJISv11468 for ; Fri, 11 Oct 2002 15:18:28 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02827 for ; Fri, 11 Oct 2002 15:16:15 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 6CF1267104; Fri, 11 Oct 2002 11:34:27 -0400 (EDT) Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <124.1845387e.2ad86993@aol.com> Message-Id: <33F2F2D8-DD4E-11D6-A062-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 15:18:20 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 11, 2002, at 13:51 America/Montreal, Mpierce1@aol.com wrote: > [MAP] It's become clear to me, with the ongoing discussion under > "Policy and labels", that this requirement REQ-7, as currently > written, could be misinterpreted by some in the future, and may itself > become a hinderance to making progress. So far, everyone except you seems to be able to understand the written meaning quite clearly. For the record, I don't think there is a problem with clarity. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 11 15:18:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02902 for ; Fri, 11 Oct 2002 15:18:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BJKbX11613 for ieprep-archive@odin.ietf.org; Fri, 11 Oct 2002 15:20:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJKbv11610 for ; Fri, 11 Oct 2002 15:20:37 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02871 for ; Fri, 11 Oct 2002 15:18:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJJ4v11512; Fri, 11 Oct 2002 15:19:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJH3v11395 for ; Fri, 11 Oct 2002 15:17:03 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02756 for ; Fri, 11 Oct 2002 15:14:48 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id AF82967104; Fri, 11 Oct 2002 11:32:59 -0400 (EDT) Subject: Re: [Ieprep] requirements document(s) (Accounting) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep@ietf.org To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <17f.1008a380.2ad869af@aol.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Oct 2002 15:16:52 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 11, 2002, at 13:51 America/Montreal, Mpierce1@aol.com wrote: > If you would limit your comments to the subject at hand, which is > accounting requirements to detect misuse of the priority service, and > limit it to call setup requirements, not packet transfer requirements, > maybe we could come to some quick agreements on the issues. Au Contraire. The topic of all of my postings is generalised use of labels (per Carlberg's general requirements draft). On the topic of telephony requirements, which is different than the topic that I've been talking about, I concur with Ken Carlberg. There is a rough consensus evident -- that rough consensus is different from your own espoused view. Like Ken, I don't plan to spend a lot more time responding to your disingenuous postings. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Oct 12 15:38:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29680 for ; Sat, 12 Oct 2002 15:38:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9CJe8O12936 for ieprep-archive@odin.ietf.org; Sat, 12 Oct 2002 15:40:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJe8v12933 for ; Sat, 12 Oct 2002 15:40:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29665 for ; Sat, 12 Oct 2002 15:37:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJcqv12870; Sat, 12 Oct 2002 15:38:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJbiv12848 for ; Sat, 12 Oct 2002 15:37:44 -0400 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29647 for ; Sat, 12 Oct 2002 15:35:31 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9CJbVX4010891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 12 Oct 2002 15:37:33 -0400 (EDT) Message-ID: <3DA87993.6070902@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 12 Oct 2002 15:35:47 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I CAN see, though that it would make sense to implement, for instance, > multiple priority classes when you have low bandwidth connections to be > shared, and a single priority class when you have high bandwidth connections > to be shared, even if the relative utilization is the same. I think these > would count as different policies. In those cases, I would favor declaring multiple classes and have devices that can confidently predict that they don't need this, merge multiple priorities into one. That way, the originator doesn't have to worry about the remote details and it only affects behavior of the one party with intimate knowledge of the local circumstances. This is indeed a good example of a different mechanism that achieves the policy goal ("good treatment for the high-priority folks") with a locally-optimized mechanism ("do nothing special for them"). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Oct 12 15:49:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29820 for ; Sat, 12 Oct 2002 15:49:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9CJp6o13103 for ieprep-archive@odin.ietf.org; Sat, 12 Oct 2002 15:51:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJp6v13100 for ; Sat, 12 Oct 2002 15:51:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29817 for ; Sat, 12 Oct 2002 15:48:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJo5v13081; Sat, 12 Oct 2002 15:50:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJnav13057 for ; Sat, 12 Oct 2002 15:49:36 -0400 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29778 for ; Sat, 12 Oct 2002 15:47:22 -0400 (EDT) Received: from cs.columbia.edu ([132.229.213.51]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9CJfcu5000726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 12 Oct 2002 15:41:39 -0400 (EDT) Message-ID: <3DA87A89.1000408@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Gunn, Janet" , goldmans@agcs.com, "Ieprep (E-mail)" Subject: Re: [Ieprep] requirements document(s) to SIPPING References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 12 Oct 2002 15:39:53 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Somebody mentioned that this added complexity especially over possibly > different security domains Not sure what you mean here. > and that the utility of such a feature had > already been questioned by the SIPPING working group. At the danger of repeating myself: One person questioned it. I don't think we (that person and I) disagree, we're just thinking of different kinds of servers. In some kinds of servers (namely, those where most of the work for a request is just getting the request off the wire), it makes very little sense, in others, it does. > > That somebody did not say that writing a scheduling algorithm to process > priority vs. something else was difficult. (It seems that somebody took an > OS class when getting a bachelors degree in computer science and doesn't > consider those types of algorithms challenging.) I'm assuming that whoever writes servers took an OS class. If not, our university will gladly offer such courses for a small fee via distance learning :-) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 08:47:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17381 for ; Mon, 14 Oct 2002 08:47:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ECmgN29709 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 08:48:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ECmfv29706 for ; Mon, 14 Oct 2002 08:48:41 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17364 for ; Mon, 14 Oct 2002 08:46:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EClTv29655; Mon, 14 Oct 2002 08:47:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ECksv29624 for ; Mon, 14 Oct 2002 08:46:54 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17303 for ; Mon, 14 Oct 2002 08:44:42 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Mon, 14 Oct 2002 08:46:38 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101408463821264 for ; Mon, 14 Oct 2002 08:46:38 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QTLG4>; Mon, 14 Oct 2002 08:47:48 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] Atlanta Agenda Scheduling Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 08:46:30 -0400 If you want to discuss issues with drafts at the Atlanta meeting, please request a slot to do so, by sending mail to the WG chairs. Keep in mind: It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues, and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it must be shown how the work falls within the existing charter; no time will be allocated for proposals that do not fit the current WG charter. The appropriate way of bringing new work to the working group is to post an Internet Draft, send a pointer to the draft to the mailing list and promote discussion on the list. Slots on the agenda should be used to discuss outstanding topics that haven't been settled on the mailing list. Keep the number of slides in presentations small. Speakers should budget their at least 25% of their time to allow for discussion/questions. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 09:20:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19006 for ; Mon, 14 Oct 2002 09:20:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EDLwV31263 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 09:21:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDLwv31260 for ; Mon, 14 Oct 2002 09:21:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18984 for ; Mon, 14 Oct 2002 09:19:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDL6v31239; Mon, 14 Oct 2002 09:21:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDKXv31209 for ; Mon, 14 Oct 2002 09:20:33 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18922 for ; Mon, 14 Oct 2002 09:18:20 -0400 (EDT) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 0E26067103 for ; Mon, 14 Oct 2002 05:37:07 -0400 (EDT) Subject: Re: [Ieprep] Atlanta Agenda Scheduling Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 09:20:30 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday, Oct 14, 2002, at 08:46 America/Montreal, King, Kimberly S. wrote: > If you want to discuss issues with drafts at the Atlanta meeting, > please request a slot to do so, by sending mail to the WG chairs. I plan to discuss issues. I don't want a timeslot though, because I won't have a presentation. It would be better, IMHO, if we had few or no presentations, instead focusing on discussion of the drafts and how to move forwards. Procedurally, it is a BAD IDEA to encourage presentations as the above request does. Also, prior to Atlanta it would be helpful if Scott would clarify which I-Ds are considered to be in scope for this WG at this time. We've got a bunch on the IETF site (both draft-ietf-ieprep and individual submissions), several of which overlap significantly. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 09:21:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19064 for ; Mon, 14 Oct 2002 09:21:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EDMmC31333 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 09:22:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDMmv31328 for ; Mon, 14 Oct 2002 09:22:48 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19042 for ; Mon, 14 Oct 2002 09:20:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDM8v31302; Mon, 14 Oct 2002 09:22:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDLAv31248 for ; Mon, 14 Oct 2002 09:21:10 -0400 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18948 for ; Mon, 14 Oct 2002 09:18:57 -0400 (EDT) Received: from cs.columbia.edu ([12.85.5.123]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021014132106.QUMR20527.mtiwmhc11.worldnet.att.net@cs.columbia.edu>; Mon, 14 Oct 2002 13:21:06 +0000 Message-ID: <3DA912DA.1070405@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson CC: ieprep Subject: Re: [Ieprep] policy & labels References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Oct 2002 02:29:46 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [General comment; addresses multiple documents] Just for clarification: the document that triggered this discussion was the requirements document authored by myself, which is specifically meant to be handed to the SIPPING WG and thus addresses SIP specifically. I suspect that mentioning of analogies in other arenas, such as DSCPs, might have gotten us into the non-SIP space. The general requirements document presumably addresses those, although it is not clear (to me) as to who these requirements are currently addressed to. We seem to have at least three different types of things that get tagged with the label 'requirements': (1) Things we believe networks (operators) should do, using existing technology. (2) Additional protocol requirements for existing protocols (such as SIP). (3) Requirements calling for new protocols. We clearly have one document in class 2 (for SIP), but it might help if we could more clearly agree which parts of the other documents fall into (1) or (3). As far as I can tell, we don't have much in category (2) and (3), except possibly concerns except concern expressed at the last WG meeting that applying DiffServ at the packet level is unwise without a yet-to-be-specified admission control mechanism. Henning RJ Atkinson wrote: > > On Friday, Oct 11, 2002, at 10:31 America/Montreal, Mpierce1@aol.com > wrote: > >> >> [MAP] Yes, I guess Henning's comments are helping to make something >> clear (they usually do), but I still don't see what the impact is >> to the task at hand which is to define a way to carry an indication >> of the priority level of the call through SIP. > > > That task is OUT OF SCOPE for the general IEprep Requirements > document. > > It might be IN SCOPE for a telephony-specific requirements document, > depending on how detailed one wanted to get. Requirements should be > high-level, so independent of particular protocols (e.g. SIP). > > Something in SIP itself (or in DiffServ itself) would be an example > of a *mechanism*. High-level requirements must not specify > mechanisms. > > Ran rja@extremenetworks.com > > _______________________________________________ Ieprep mailing list > Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 09:33:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19572 for ; Mon, 14 Oct 2002 09:33:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EDYvc31719 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 09:34:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDYvv31716 for ; Mon, 14 Oct 2002 09:34:57 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19560 for ; Mon, 14 Oct 2002 09:32:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDY5v31697; Mon, 14 Oct 2002 09:34:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDXtv31679 for ; Mon, 14 Oct 2002 09:33:55 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19525 for ; Mon, 14 Oct 2002 09:31:44 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 09:32:02 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-1 to REQ-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 09:31:45 -0400 I absolutely agree that the ORIGINATOR should not have to worry about different mechanisms/policies on different parts of the path. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Saturday, October 12, 2002 3:36 PM To: Gunn, Janet Cc: King, Kimberly S.; Ieprep (E-mail) Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5 > I CAN see, though that it would make sense to implement, for instance, > multiple priority classes when you have low bandwidth connections to be > shared, and a single priority class when you have high bandwidth connections > to be shared, even if the relative utilization is the same. I think these > would count as different policies. In those cases, I would favor declaring multiple classes and have devices that can confidently predict that they don't need this, merge multiple priorities into one. That way, the originator doesn't have to worry about the remote details and it only affects behavior of the one party with intimate knowledge of the local circumstances. This is indeed a good example of a different mechanism that achieves the policy goal ("good treatment for the high-priority folks") with a locally-optimized mechanism ("do nothing special for them"). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 09:34:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19622 for ; Mon, 14 Oct 2002 09:34:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EDa6431788 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 09:36:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDa6v31785 for ; Mon, 14 Oct 2002 09:36:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19596 for ; Mon, 14 Oct 2002 09:33:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDZ5v31747; Mon, 14 Oct 2002 09:35:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDY3v31691 for ; Mon, 14 Oct 2002 09:34:03 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19528 for ; Mon, 14 Oct 2002 09:31:52 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9EDXETU013607 for ieprep@ietf.org; Mon, 14 Oct 2002 09:33:14 -0400 (EDT) From: Scott Bradner Message-Id: <200210141333.g9EDXETU013607@newdev.harvard.edu> To: ieprep@ietf.org Subject: Re: [Ieprep] Atlanta Agenda Scheduling Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 09:33:14 -0400 (EDT) Ran asks: > Also, prior to Atlanta it would be helpful if Scott would clarify > which I-Ds are considered to be in scope for this WG at this time. rather than point to a specific set of IDs it may be better to say where we are as a WG. the primary task on the WG's plate right now is to come to consensus on a requirements document to be forwarded to the sipping working group (obviously that document needs to be SIP-specific) once that is done the WG can work on requirements for other ieprep areas and there are a surfeit of IDs in that space that will have to be reduced to as few as we can get away with (ideally one) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 10:06:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20985 for ; Mon, 14 Oct 2002 10:06:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EE8E501862 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 10:08:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EE8Ev01859 for ; Mon, 14 Oct 2002 10:08:14 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20973 for ; Mon, 14 Oct 2002 10:06:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EE79v01531; Mon, 14 Oct 2002 10:07:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EE6Kv01225 for ; Mon, 14 Oct 2002 10:06:20 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20926 for ; Mon, 14 Oct 2002 10:04:09 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9EE5VxX013732 for ieprep@ietf.org; Mon, 14 Oct 2002 10:05:31 -0400 (EDT) From: Scott Bradner Message-Id: <200210141405.g9EE5VxX013732@newdev.harvard.edu> To: ieprep@ietf.org Subject: [Ieprep] sipping requirements Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 10:05:31 -0400 (EDT) Henning sez: > Just for clarification: the document that triggered this discussion was > the requirements document authored by myself, which is specifically > meant to be handed to the SIPPING WG and thus addresses SIP > specifically. (helping my co-chair focus discussion on this document) draft-ietf-ieprep-sip-reqs-00.txt lists quite a few REQs and SECs (security requirements) - Kimberly started a REQ-by-REQ discussion of them and the discussion has been generally useful but I'd also like to ask if *all* of the requiremnents (both REQ & SEC) are needed - requirements documents should have only the minimum set of requirements to ensure that the protocol does what it needs to do to support the desired functions and no more. in addition - there should be a discussion to see if there is WG consensus on sec 5 (network models) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 10:12:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19065 for ; Mon, 14 Oct 2002 09:21:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EDMmH31346 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 09:22:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDMmv31330 for ; Mon, 14 Oct 2002 09:22:48 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19044 for ; Mon, 14 Oct 2002 09:20:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDM5v31285; Mon, 14 Oct 2002 09:22:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDL1v31227 for ; Mon, 14 Oct 2002 09:21:01 -0400 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18944 for ; Mon, 14 Oct 2002 09:18:49 -0400 (EDT) Received: from cs.columbia.edu ([12.85.5.123]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021014132048.NUCD6348.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Mon, 14 Oct 2002 13:20:48 +0000 Message-ID: <3DA910E4.2040005@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: K.Carlberg@cs.ucl.ac.uk, ieprep@ietf.org Subject: Re: [Ieprep] policy & labels References: <119.18fbc00d.2ad83aaa@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Oct 2002 02:21:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Can someone point me to a definition of the word "label" when used in > this context? We are still talking about SIP (I hope), but I do not find > the word defined or used in RFC3261. [Explanation to draft-ietf-ieprep-sip-rp-requirements] There is no definition of label in SIP. This is meant as a generic term that is syntactically a token, logically (speaking C) an 'enum'. SIP, like most protocols, contains a number of such elements, basically wherever a parameter can assume one of a finite number of pre-defined values. These are all the various namespaces registered with IANA (see their web page listing under sip-parameters). Henning _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:19:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00428 for ; Mon, 14 Oct 2002 15:19:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJKl019032 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:20:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJKlv19029 for ; Mon, 14 Oct 2002 15:20:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00385 for ; Mon, 14 Oct 2002 15:18:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJK8v19013; Mon, 14 Oct 2002 15:20:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJJov18969 for ; Mon, 14 Oct 2002 15:19:50 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00368 for ; Mon, 14 Oct 2002 15:17:35 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:17:55 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:17:45 -0400 I am trying to go through the requirements in the SIP requirements document in detail. I start off with something that needs clarification. "Below are some requirements for such a mechanism; security requirements are discussed in Section 10. REQ-1: Not specific to one mechanism or country: The mechanism should not be specific to one country or particular priority mechanism. For example, there are currently at least four priority schemes in widespread use: Q.735, with five levels, the U.S. defense network and NATO with five levels, the United States GETS (Government Emergency Telecommunications Systems) scheme with implied higher priority and the British Government Telephone Preference Scheme (GTPS) system." This seems to say that "a mechanism must not be specific to a mechanism" which seems contradictory to me. Do we mean "a policy must not be specific to a mechanism"? Or a "labeling must not be specific to a mechanism"? It is also not clear what the antecedent for "such a mechanism" is- do we mean "a mechanism for marking calls to indicate priority"? Or do we mean "a mechanism for providing priority service"? Are Q735, GETS and GTPS supposed to be example of acceptable mechanisms, or unacceptable ones? It sounds as if you are saying that, because they (at least GETS and GTPS) are country specific, they are unacceptable. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:36:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00812 for ; Mon, 14 Oct 2002 15:36:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJbqA20021 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:37:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJbqv20018 for ; Mon, 14 Oct 2002 15:37:52 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00806 for ; Mon, 14 Oct 2002 15:35:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJb6v19587; Mon, 14 Oct 2002 15:37:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJacv19431 for ; Mon, 14 Oct 2002 15:36:38 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00777 for ; Mon, 14 Oct 2002 15:34:22 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:34:42 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: [Ieprep] IEPREP SIP REQ-2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:34:32 -0400 "REQ-2: Independent of particular network architecture: The mechanism should work in the widest variety of SIP-based systems. It should not be restricted to particular operators or types of networks, such as wireless networks or protocol profiles and dialects in certain types of networks." It depends on whether we are talking about a mechanism for marking (i.e. a labeling) or a mechanism for providing priority. If it is a mechanism for providing priority, I don't have a problem with using different mechanisms in different types of networks (e.g. multiple priority levels in a low bandwidth sub network, but a single priority level in a high bandwidth sub network). If it is a mechanism for marking priority, then it is certainly desirable to have the same marking across different technologies. But there do exist systems on the telephony side that use different markings in different sub networks. This imposes additional requirements on the gateways between these sub networks, but it can be done. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:41:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01015 for ; Mon, 14 Oct 2002 15:41:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJhhZ20206 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:43:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJhhv20203 for ; Mon, 14 Oct 2002 15:43:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01001 for ; Mon, 14 Oct 2002 15:41:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJh6v20187; Mon, 14 Oct 2002 15:43:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJgcv20163 for ; Mon, 14 Oct 2002 15:42:38 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00947 for ; Mon, 14 Oct 2002 15:40:22 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:40:43 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: [Ieprep] IEPREP SIP REQ-3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:40:33 -0400 "REQ-3: Invisible to IP network: It should be possible to use the mechanism in IP networks that are unaware of the mechanism and in restricted networks. Obviously, such networks will not be able to provide enhanced services." Assuming that "mechanism" means "mechanism for marking", this is a VERY important requirement. The failure to meet this requirement (in spite of standards) in some parts of the circuit switched network has caused significant problems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:46:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01108 for ; Mon, 14 Oct 2002 15:46:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJmVQ20392 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:48:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJmVv20389 for ; Mon, 14 Oct 2002 15:48:31 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01099 for ; Mon, 14 Oct 2002 15:46:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJl4v20331; Mon, 14 Oct 2002 15:47:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJk7v20298 for ; Mon, 14 Oct 2002 15:46:07 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01076 for ; Mon, 14 Oct 2002 15:43:52 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:44:13 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: [Ieprep] IEPREP SIP REQ-4 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:44:03 -0400 "REQ-4: Usage of existing namespaces: Since there are a number of existing resource priority schemes for both the PSTN and private networks, it is likely that converged or VoIP networks will inherit these naming schemes." This does not sound like an actual requirement. It would certainly be DESIRABLE for the naming conventions in a converged or VOIP network to reflect the naming conventions in the circuit switched network. But not absolutely essential. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:48:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01129 for ; Mon, 14 Oct 2002 15:48:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJnk920464 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:49:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJnjv20461 for ; Mon, 14 Oct 2002 15:49:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01126 for ; Mon, 14 Oct 2002 15:47:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJn5v20433; Mon, 14 Oct 2002 15:49:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJm3v20351 for ; Mon, 14 Oct 2002 15:48:03 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01096 for ; Mon, 14 Oct 2002 15:45:49 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:46:08 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: RE: [Ieprep] IEPREP SIP REQ-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:45:58 -0400 "REQ-5: No loss of information: For the CN-IP-CN case, there should be no loss of signaling information caused by transiting the IP network." This is ABSOLUTELY ESSENTIAL, and also ties in with REQ 3. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:53:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01222 for ; Mon, 14 Oct 2002 15:53:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJteI20619 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:55:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJtev20616 for ; Mon, 14 Oct 2002 15:55:40 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01219 for ; Mon, 14 Oct 2002 15:53:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJt5v20594; Mon, 14 Oct 2002 15:55:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJs7v20570 for ; Mon, 14 Oct 2002 15:54:07 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01189 for ; Mon, 14 Oct 2002 15:51:49 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9EJrtm6026388; Mon, 14 Oct 2002 15:53:55 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9EJrr5T000682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 15:53:54 -0400 (EDT) Message-ID: <3DAB20B9.9060407@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: Re: [Ieprep] IEPREP SIP REQ-4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:53:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This doesn't mean that the name has to be the same, but each existing priority scheme should be mappable one-to-one to a SIP-based scheme. Otherwise, you'll lose in the translation. I'll try to reword. Gunn, Janet wrote: > "REQ-4: Usage of existing namespaces: Since there are a number of > existing resource priority schemes for both the PSTN and > private networks, it is likely that converged or VoIP > networks will inherit these naming schemes." > > This does not sound like an actual requirement. > > It would certainly be DESIRABLE for the naming conventions in a converged or > VOIP network to reflect the naming conventions in the circuit switched > network. But not absolutely essential. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:56:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01271 for ; Mon, 14 Oct 2002 15:56:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJvlj20706 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:57:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJvlv20703 for ; Mon, 14 Oct 2002 15:57:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01248 for ; Mon, 14 Oct 2002 15:55:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJv7v20693; Mon, 14 Oct 2002 15:57:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJuev20659 for ; Mon, 14 Oct 2002 15:56:40 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01241 for ; Mon, 14 Oct 2002 15:54:26 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:54:45 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: [Ieprep] IEPREP SIP REQ-6 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:54:35 -0400 "REQ-6: Extensibility: New naming schemes may need to be defined as resource priority mechanism are applied in additional private networks, or if a VoIP-specific priority scheme is being defined." Like REQ 4, this isn't really worded as a requirement. Possible rewording: "Any naming scheme specified as part of the mechanism should allow for future expansion. Expanded naming schemes may be needed as resource priority mechanism are applied in additional private networks, or if a VoIP-specific priority schemes are defined." _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 15:56:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01284 for ; Mon, 14 Oct 2002 15:56:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EJvnW20729 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 15:57:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJvnv20724 for ; Mon, 14 Oct 2002 15:57:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01256 for ; Mon, 14 Oct 2002 15:55:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJv4v20677; Mon, 14 Oct 2002 15:57:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EJuOv20648 for ; Mon, 14 Oct 2002 15:56:24 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01237 for ; Mon, 14 Oct 2002 15:54:09 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9EJuFm6026509; Mon, 14 Oct 2002 15:56:16 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9EJuE5T000809 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 15:56:15 -0400 (EDT) Message-ID: <3DAB2146.7030801@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: Re: [Ieprep] IEPREP SIP REQ-3 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:55:50 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Given the discussion on "mechanism" and "policy", we have a bit of a word overload problem. I'll try to more clearly highlight where mechanism refers to a "SIP protocol mechanism" or "SIP enhancement". If somebody has a less ugly and cumbersome term, let me know. Gunn, Janet wrote: > "REQ-3: Invisible to IP network: It should be possible to use > the > mechanism in IP networks that are unaware of the mechanism > and in restricted networks. Obviously, such networks will > not be able to provide enhanced services." > > Assuming that "mechanism" means "mechanism for marking", this is a VERY > important requirement. The failure to meet this requirement (in spite of > standards) in some parts of the circuit switched network has caused > significant problems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 16:27:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01861 for ; Mon, 14 Oct 2002 16:27:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EKSi222170 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 16:28:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EKSiv22167 for ; Mon, 14 Oct 2002 16:28:44 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01851 for ; Mon, 14 Oct 2002 16:26:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EKS5v22151; Mon, 14 Oct 2002 16:28:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EKR7v22098 for ; Mon, 14 Oct 2002 16:27:07 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01819 for ; Mon, 14 Oct 2002 16:24:53 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 16:25:12 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: [Ieprep] IEPREP SIP REQ-7 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 16:25:02 -0400 "REQ-7: Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the requests invokes a certain named policy that may well have those properties." Now we have added the word "indication". Is this the same as "mechanism for marking"? If not, how is it different. We have also added the word "treatment". Does this mean "mechanism for providing preferential service"? In this context is "policy" simply a "mapping from a 'mechanism for marking' to a 'mechanism for providing preferential service'"? If so, we need to say so. If not, what is it? The way they are currently worded, REQ 2 and REQ 7 appear, if not contradictory, at least ambiguous. I think I understand what you mean, but only as the result of several exchanges on the list. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 17:12:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02941 for ; Mon, 14 Oct 2002 17:12:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ELDni25212 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 17:13:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELDnv25209 for ; Mon, 14 Oct 2002 17:13:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02928 for ; Mon, 14 Oct 2002 17:11:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELD7v25186; Mon, 14 Oct 2002 17:13:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELCrv25158 for ; Mon, 14 Oct 2002 17:12:53 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02912 for ; Mon, 14 Oct 2002 17:10:37 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9ELCam6006630; Mon, 14 Oct 2002 17:12:36 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9ELCY5T006958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 17:12:35 -0400 (EDT) Message-ID: <3DAB332A.5050107@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-1 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 17:12:10 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since mechanism is used for different things in the document, this can get confusing. I will try to switch to "SIP indication" to indicate the "new" thing that's the subject of the requirement and I'll call "priority scheme" (avoiding mechanism or policy) as the general goal and the PSTN mechanism. I reworded the paragraph accordingly. > REQ-1: Not specific to one mechanism or country: The mechanism > should not be specific to one country or particular > priority mechanism. For example, there are currently at > least four priority schemes in widespread use: Q.735, with > five levels, the U.S. defense network and NATO with five > levels, the United States GETS (Government Emergency > Telecommunications Systems) scheme with implied higher > priority and the British Government Telephone Preference > Scheme (GTPS) system." > > This seems to say that "a mechanism must not be specific to a mechanism" > which seems contradictory to me. Do we mean "a policy must not be specific > to a mechanism"? Or a "labeling must not be specific to a mechanism"? > > It is also not clear what the antecedent for "such a mechanism" is- do we > mean "a mechanism for marking calls to indicate priority"? Or do we mean "a > mechanism for providing priority service"? > > Are Q735, GETS and GTPS supposed to be example of acceptable mechanisms, or > unacceptable ones? It sounds as if you are saying that, because they (at > least GETS and GTPS) are country specific, they are unacceptable. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 17:16:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03044 for ; Mon, 14 Oct 2002 17:16:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ELIhs25379 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 17:18:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELIhv25376 for ; Mon, 14 Oct 2002 17:18:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03040 for ; Mon, 14 Oct 2002 17:16:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELI4v25357; Mon, 14 Oct 2002 17:18:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELHxv25337 for ; Mon, 14 Oct 2002 17:17:59 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03003 for ; Mon, 14 Oct 2002 17:15:44 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9ELHpm6006938; Mon, 14 Oct 2002 17:17:51 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9ELHo5T007307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 17:17:51 -0400 (EDT) Message-ID: <3DAB3466.1070207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 17:17:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > "REQ-2: Independent of particular network architecture: The > mechanism should work in the widest variety of SIP-based > systems. It should not be restricted to particular > operators or types of networks, such as wireless networks > or protocol profiles and dialects in certain types of > networks." > > It depends on whether we are talking about a mechanism for marking (i.e. a > labeling) or a mechanism for providing priority. > > If it is a mechanism for providing priority, I don't have a problem with > using different mechanisms in different types of networks (e.g. multiple > priority levels in a low bandwidth sub network, but a single priority level > in a high bandwidth sub network). As discussed earlier in this general thread, "collapsing" priorities into a smaller set of actually implemented behaviors is an implementation choice that should not be visible to outside parties. > > If it is a mechanism for marking priority, then it is certainly desirable > to have the same marking across different technologies. But there do exist > systems on the telephony side that use different markings in different sub > networks. This imposes additional requirements on the gateways between > these sub networks, but it can be done. However, even if the scheme differs, the sending side should simply find out about the schemes, rather the deduce them indirectly. ("Destination network uses bit twiddling foo, so I need to use namespace bar" would not be good.) Generally speaking, there is currently no way for the sending system to find out whether the gateway terminates in analog circuits, ISUP, bush drums, radio circuits or smoke signals. ("Add additional oily rags for high-priority calls.") _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 17:36:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03347 for ; Mon, 14 Oct 2002 17:36:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ELbxf26560 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 17:37:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELbxv26557 for ; Mon, 14 Oct 2002 17:37:59 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03329 for ; Mon, 14 Oct 2002 17:35:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELbAv26215; Mon, 14 Oct 2002 17:37:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELZwv25945 for ; Mon, 14 Oct 2002 17:35:58 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03309 for ; Mon, 14 Oct 2002 17:33:42 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 17:34:02 -0400 Message-ID: From: "Gunn, Janet" To: "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP SIP REQ-2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 17:33:52 -0400 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 14, 2002 5:17 PM To: Gunn, Janet Cc: King, Kimberly S.; Ieprep (E-mail) Subject: Re: [Ieprep] IEPREP SIP REQ-2 However, even if the scheme differs, the sending side should simply find out about the schemes, rather the deduce them indirectly. ("Destination network uses bit twiddling foo, so I need to use namespace bar" would not be good.) Generally speaking, there is currently no way for the sending system to find out whether the gateway terminates in analog circuits, ISUP, bush drums, radio circuits or smoke signals. ("Add additional oily rags for high-priority calls.") [JPG] How does this relate to Req 14? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 17:55:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03663 for ; Mon, 14 Oct 2002 17:55:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ELvep27040 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 17:57:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELvev27037 for ; Mon, 14 Oct 2002 17:57:40 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03642 for ; Mon, 14 Oct 2002 17:55:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELv5v27001; Mon, 14 Oct 2002 17:57:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ELuvv26982 for ; Mon, 14 Oct 2002 17:56:57 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03629 for ; Mon, 14 Oct 2002 17:54:41 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 17:54:56 -0400 Message-ID: From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" Cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: [Ieprep] IEPREP SIP REQ other comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 17:54:46 -0400 In section 5, network models: "Restricted SIP networks: In restricted SIP networks, users may be restricted to particular SIP applications and cannot add SIP protocol elements such as header fields or use SIP methods beyond a proscribed set. It appears likely that 3GPP/3GPP2 networks will fall into this category, at least initially." It should be "prescribed", not "proscribed". In section 7 the "mechanism" seems to be "the mechanism to provide priority service", whereas in section 6 it seems to be the "mechanism for marking call requests". One requirement that seems to be missing, is that SIP should be able to handle both a marking that says "I am requesting priority treatment foo for this call, but have not yet been authorized for this call" (analogous to dialing the prefix 710) AND a marking that says "This call has already been authorized for priority treatment foo" (analogous to having the "calling party category" set to "HPC"). Or am I missing something? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 20:16:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06114 for ; Mon, 14 Oct 2002 20:16:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F0Hut01041 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 20:17:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0Huv01038 for ; Mon, 14 Oct 2002 20:17:56 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06110 for ; Mon, 14 Oct 2002 20:15:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0E7v00917; Mon, 14 Oct 2002 20:14:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0DGv00896 for ; Mon, 14 Oct 2002 20:13:16 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06060 for ; Mon, 14 Oct 2002 20:10:58 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9F0D1m6021394; Mon, 14 Oct 2002 20:13:01 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9F0Cx5T017548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 20:13:00 -0400 (EDT) Message-ID: <3DAB5D72.60009@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ other comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 20:12:34 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In section 7 the "mechanism" seems to be "the mechanism to provide priority > service", whereas in section 6 it seems to be the "mechanism for marking > call requests". I've gone through the document and tried to replace the generic "mechanism" by a more concrete term or omitted it where it wasn't needed. > > One requirement that seems to be missing, is that SIP should be able to > handle both a marking that says "I am requesting priority treatment foo for > this call, but have not yet been authorized for this call" (analogous to > dialing the prefix 710) AND a marking that says "This call has already been > authorized for priority treatment foo" (analogous to having the "calling > party category" set to "HPC"). Or am I missing something? There are, I believe, four cases: (1) want priority, but not yet authorized -> system should challenge user, which leads to case (2) (2) priority + credentials (e.g., in SIP, a Digest authorization or an S/MIME-signed body) (3) priority + network-asserted identity (NAI): The recipient of the request somehow has reason to believe that the NAI is correct and then check that the identity can request the service. (4) priority approved by third party: Here, the recipient has reason to believe that the request has been vetted by a trusted third party. I can spell out these different scenarios if people believe this to be helpful. For (2), (3) and (4), there are likely several different solutions in SIP. > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 20:17:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06147 for ; Mon, 14 Oct 2002 20:17:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F0Il401078 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 20:18:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0Ikv01075 for ; Mon, 14 Oct 2002 20:18:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06131 for ; Mon, 14 Oct 2002 20:16:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0F4v00957; Mon, 14 Oct 2002 20:15:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0Exv00938 for ; Mon, 14 Oct 2002 20:14:59 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06071 for ; Mon, 14 Oct 2002 20:12:41 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9F0Ekm6021440; Mon, 14 Oct 2002 20:14:46 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9F0Ei5T017719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 20:14:45 -0400 (EDT) Message-ID: <3DAB5DDB.3020609@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] IEPREP SIP REQ-2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 20:14:19 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > However, even if the scheme differs, the sending side should simply find > out about the schemes, rather the deduce them indirectly. ("Destination > network uses bit twiddling foo, so I need to use namespace bar" would > not be good.) > > Generally speaking, there is currently no way for the sending system to > find out whether the gateway terminates in analog circuits, ISUP, bush > drums, radio circuits or smoke signals. ("Add additional oily rags for > high-priority calls.") > > > [JPG] How does this relate to Req 14? REQ-14 is a consequence of what I said, namely that the originator should be able to discover capabilities, but not use any knowledge about network characteristics to infer such capabilities. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 14 22:04:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07889 for ; Mon, 14 Oct 2002 22:04:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F265N05601 for ieprep-archive@odin.ietf.org; Mon, 14 Oct 2002 22:06:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F265v05598 for ; Mon, 14 Oct 2002 22:06:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07886 for ; Mon, 14 Oct 2002 22:03:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F22Fv05491; Mon, 14 Oct 2002 22:02:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F1xDv05403 for ; Mon, 14 Oct 2002 21:59:13 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07823 for ; Mon, 14 Oct 2002 21:56:49 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9F1wvm6027262; Mon, 14 Oct 2002 21:58:58 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9F1wu5T024081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2002 21:58:57 -0400 (EDT) Message-ID: <3DAB7647.4010703@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "'King, Kimberly S.'" , "'Ieprep (E-mail)'" Subject: Re: [Ieprep] IEPREP SIP REQ-7 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Oct 2002 21:58:31 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I will strive to use the word "indication" consistently throughout the document. I hope it strikes the right balance between avoiding terminology overload ("mechanism") and being too specific. Gunn, Janet wrote: > "REQ-7: Separation of indication and policy: The indication > should not describe a particular detailed treatment, as it > is likely that this depends on the nature of the resource > and local policy. Instead, it should invoke a particular > named policy. As an example, instead of specifying that a > certain SIP request should be granted queueing priority, > not cause preemption, but be restricted to three-minute > sessions, the requests invokes a certain named policy that > may well have those properties." > > Now we have added the word "indication". Is this the same as "mechanism for > marking"? If not, how is it different. > We have also added the word "treatment". Does this mean "mechanism for > providing preferential service"? In this context is "policy" simply a > "mapping from a 'mechanism for marking' to a 'mechanism for providing > preferential service'"? If so, we need to say so. If not, what is it? > > The way they are currently worded, REQ 2 and REQ 7 appear, if not > contradictory, at least ambiguous. I think I understand what you mean, but > only as the result of several exchanges on the list. > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:06:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27690 for ; Tue, 15 Oct 2002 08:06:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FC8KR10545 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:08:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FC8Jv10542 for ; Tue, 15 Oct 2002 08:08:19 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27665 for ; Tue, 15 Oct 2002 08:06:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FC7Mv10452; Tue, 15 Oct 2002 08:07:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FC6qv09950 for ; Tue, 15 Oct 2002 08:06:52 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27639 for ; Tue, 15 Oct 2002 08:04:40 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 15 Oct 2002 08:06:31 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101508063127109 ; Tue, 15 Oct 2002 08:06:31 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QTZZ6>; Tue, 15 Oct 2002 08:07:42 -0400 Message-Id: From: "King, Kimberly S." To: "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] Security Requirements for SIPPING SEC-1 to SEC-5 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 08:06:23 -0400 "SEC-1: More rigorous: Prioritized access to network and end system resources imposes particularly stringent requirements on authentication and authorization mechanisms since access to prioritized resources may impact overall system stability and performance, not just result in theft of, say, a single phone call. The authentication and authorization requirements for ETS calls are, in particular, much stronger than for emergency calls (112, 911), where wide access is the design objective, sacrificing caller identification if necessary." We talked about this one before. In reality, you aren't asking for anything stronger than what is used in some commercial systems today, right? I think the "more rigorous" might cause some confusion. " SEC-2: Attack protection: Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack. Thus, authentication and authorization must be able to survive such attacks and defend the resources against these attacks." " SEC-3: Independent of mechanism: Any indication of the resource priority mechanism must be independent of the authentication mechanism, since end systems will impose different constraints on the applicable authentication mechanisms. For example, some end systems may only allow user input via a 12-digit keypad, while others may have the ability to acquire biometrics or read smartcards." "SEC-4: Non-trusted end systems: Since ETS users may use devices that are not their own, systems should support authentication mechanisms that do not require the user to reveal her secret to the device." An example acceptable solution might help to clarify here. If a person enters a PIN or simple password (yes, I know these things are weak security) is that considered revealing the secret to the device? " SEC-5: Subversion of authentication infrastructure: Attackers may attempt to subvert the ETS infrastructure by overloading it with authentication attempts. Thus, mechanisms to delegate authentication and to authenticate as early as possible are required. In particular, the number of packets and the amount of other resources such as computation or storage that an unauthorized user can consume needs to be minimized. In general, unauthorized users must not be able to block CN resources, as they are likely to be more scarce than packet resources. This implies that authentication and authorization must take place on the IP network side rather than using, say, a CN circuit to authenticate oneself via a DTMF sequence. Given the urgency during emergency events, normal statistical fraud detection may be less effective, thus placing a premium on reliable authentication." It appears that statements on the number of packets or amount of resources, or prevention of unauthorized users to block CN resources are policy statements intended to motivate this requirement that says (redundantly?) that SEC-2 must hold. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:11:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27841 for ; Tue, 15 Oct 2002 08:11:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCCuh10730 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:12:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCCtv10727 for ; Tue, 15 Oct 2002 08:12:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27824 for ; Tue, 15 Oct 2002 08:10:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCC4v10685; Tue, 15 Oct 2002 08:12:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCBEv10652 for ; Tue, 15 Oct 2002 08:11:14 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27799 for ; Tue, 15 Oct 2002 08:09:02 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 15 Oct 2002 08:10:57 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101508105718619 ; Tue, 15 Oct 2002 08:10:57 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QTZ7Y>; Tue, 15 Oct 2002 08:12:08 -0400 Message-Id: From: "King, Kimberly S." To: "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 08:10:54 -0400 "SEC-6: Replay: The authentication mechanisms must be resistant to replay attacks. SEC-7: Cut-and-paste: The authentication mechanisms must be resistant to cut-and-paste attacks. SEC-8: Bid-down: The authentication mechanisms must be resistant to bid down attacks." I suppose the above could be collapsed into one requirement that the authentication mechanism is resistant to common attacks (e.g., replay, cut-and-paste, bid down). "SEC-9: Confidentiality: All aspects of ETS are likely to be sensitive and must be protected from intercept and alteration. In particular, requirements for protecting the confidentiality of communications relationships may be higher than for normal commercial service. For SIP, the To, From, Organization, Subject, Priority and Via header fields are examples of particularly sensitive information." Aren't some of these fields important for SIP routing? Do you have an example solution in mind that would protect these fields? " SEC-10: Avoid exposing nature of request: In some circumstances, unauthorized users must not be able to discern that a particular request is using a resource priority mechanism, as that may reveal sensitive information about the nature of the request to the attacker." How does SEC-10 differ from SEC-9? Maybe you could just add one more sensitive "field", i.e., the resource priority mechanism itself. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:15:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28021 for ; Tue, 15 Oct 2002 08:15:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCHe010898 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:17:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCHev10895 for ; Tue, 15 Oct 2002 08:17:40 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28009 for ; Tue, 15 Oct 2002 08:15:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCH4v10865; Tue, 15 Oct 2002 08:17:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCG6v10824 for ; Tue, 15 Oct 2002 08:16:06 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27960 for ; Tue, 15 Oct 2002 08:13:54 -0400 (EDT) Received: from pc-80-193-239-38-hw.blueyonder.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Tue, 15 Oct 2002 13:15:37 +0100 From: Ian Brown To: "King, Kimberly S." , "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] Security Requirements for SIPPING SEC-1 to SEC-5 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 13:16:28 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kimberly asked: > An example acceptable solution might help to clarify here. If a person > enters a PIN or simple password (yes, I know these things are > weak security) is that considered revealing the secret to the device? Yes. You ideally want support for something like a smartcard or SIM that can authenticate itself to the challenger without revealing the secret it uses to do so to intermediate points (including the device such as a telephone that it is working with). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:16:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28064 for ; Tue, 15 Oct 2002 08:16:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCIe411011 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:18:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCIev11007 for ; Tue, 15 Oct 2002 08:18:40 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28060 for ; Tue, 15 Oct 2002 08:16:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCI4v10960; Tue, 15 Oct 2002 08:18:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCHUv10887 for ; Tue, 15 Oct 2002 08:17:30 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28000 for ; Tue, 15 Oct 2002 08:15:18 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 15 Oct 2002 08:17:20 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101508172000122 ; Tue, 15 Oct 2002 08:17:20 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QT5A3>; Tue, 15 Oct 2002 08:18:31 -0400 Message-Id: From: "King, Kimberly S." To: "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] Security Requirements for SIPPING SEC-11 to SEC-14 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 08:17:11 -0400 "SEC-11: Anonymity: For the reasons noted earlier, users have to authenticate themselves towards the network carrying the request. The authentication may be based on capabilities and noms, not necessarily their civil name. Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanisms" Does this type of anonymity require an explicit relationship on the part of the IP/SIP network and the user? Do all users require anonymity? Suppose we are in the SIP to CSN topology, I assume the request destination is the SIP gateway (i.e., the destination is seen from the perspective of the SIP network). Does this requirement "may remain anonymous towards the request destination" preclude the gateways ability to authenticate the user? " SEC-12: Denial-of-service: ETS systems are likely to be subject to deliberate denial-of-service attacks during certain types of emergencies. DOS attacks may be launched on the network itself as well as its authentication and authorization mechanism." As stated, it appears the requirement is that DOS attacks may be launched. Since I really doubt that is the desired requirement, what is it that you are requesting? "SEC-13: Minimize resource use by unauthorized users: Systems should minimize the amount of state, computation and network resources that an unauthorized user can command." I hate to broach the subject, but this sounds like a policy statement. "SEC-14: Avoid amplification: The system must not amplify attacks by causing the transmission of more than one packet to a network address whose reachability has not been verified." Is this standard procedure? If so, why have the requirement? If not, it seems like it would delay call setup and require changes for default behavior (since by SEC-4, ETS users may use phones that are not their own). Also, do you mean "one packet" or one SIP message? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:23:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28357 for ; Tue, 15 Oct 2002 08:23:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCOlm11226 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:24:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCOkv11223 for ; Tue, 15 Oct 2002 08:24:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28326 for ; Tue, 15 Oct 2002 08:22:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCO4v11193; Tue, 15 Oct 2002 08:24:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCN3v11151 for ; Tue, 15 Oct 2002 08:23:03 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28271 for ; Tue, 15 Oct 2002 08:20:51 -0400 (EDT) Received: from pc-80-193-239-38-hw.blueyonder.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Tue, 15 Oct 2002 13:22:56 +0100 From: Ian Brown To: "King, Kimberly S." , "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 13:23:46 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kimberly said: >>...To, From, Organization, Subject, Priority and Via header fields... > Aren't some of these fields important for SIP routing? Do you have an > example solution in mind that would protect these fields? Fields that aren't needed for routing can protected end-to-end using S/MIME. Fields that are can only be protected hop-by-hop using a protocol such as TLS. > " SEC-10: Avoid exposing nature of request: In some circumstances, > unauthorized users must not be able to discern that a > particular request is using a resource priority mechanism, > as that may reveal sensitive information about the nature > of the request to the attacker." > > How does SEC-10 differ from SEC-9? Maybe you could just add one more > sensitive "field", i.e., the resource priority mechanism itself. You also need to consider problems like: what if devices have to contact one of a small set of authorisation servers to obtain a credential before making an ETS call? An attacker could correlate a device making such a request with a call that it made soon after, unless it had used some type of IP anonymiser to contact the server. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:31:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28709 for ; Tue, 15 Oct 2002 08:31:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCWfE11576 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:32:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCWfv11571 for ; Tue, 15 Oct 2002 08:32:41 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28684 for ; Tue, 15 Oct 2002 08:30:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCW6v11537; Tue, 15 Oct 2002 08:32:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCVrv11518 for ; Tue, 15 Oct 2002 08:31:53 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28668 for ; Tue, 15 Oct 2002 08:29:41 -0400 (EDT) Received: from pc-80-193-239-38-hw.blueyonder.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Tue, 15 Oct 2002 13:31:36 +0100 From: Ian Brown To: "King, Kimberly S." , "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] Security Requirements for SIPPING SEC-11 to SEC-14 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 13:32:25 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Do all users require anonymity? No. > Suppose we are in the SIP to CSN topology, I assume the request destination > is the SIP gateway (i.e., the destination is seen from the perspective of > the SIP network). Does this requirement "may remain anonymous towards the > request destination" preclude the gateways ability to > authenticate the user? No -- remember that we (and the gateway in this scenario) are interested in the authorisation of a user to make an ETS call, not necessarily in authenticating their *identity*. > "SEC-13: Minimize resource use by unauthorized users: Systems > should minimize the amount of state, computation and > network resources that an unauthorized user can command." > > I hate to broach the subject, but this sounds like a policy statement. I think it's also an important technical requirement that reduces the impact of DoS attacks. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 08:32:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28755 for ; Tue, 15 Oct 2002 08:32:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCXjN11641 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 08:33:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCXiv11638 for ; Tue, 15 Oct 2002 08:33:44 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28739 for ; Tue, 15 Oct 2002 08:31:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCX3v11614; Tue, 15 Oct 2002 08:33:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCWfv11574 for ; Tue, 15 Oct 2002 08:32:41 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28682 for ; Tue, 15 Oct 2002 08:30:28 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Oct 2002 13:32:29 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: "King, Kimberly S." cc: "Henning Schulzrinne (E-mail)" , "Ieprep (E-mail)" Subject: Re: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 In-reply-to: Your message of "Tue, 15 Oct 2002 08:10:54 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <981.1034685145@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 13:32:25 +0100 >> "SEC-6: Replay: The authentication mechanisms must be resistant to >>replay attacks. >> >> SEC-7: Cut-and-paste: The authentication mechanisms must be >> resistant to cut-and-paste attacks. >> >> SEC-8: Bid-down: The authentication mechanisms must be resistant to >>bid down attacks." > > I suppose the above could be collapsed into one requirement that the > authentication mechanism is resistant to common attacks (e.g., replay, > cut-and-paste, bid down). i would prefer they not be. Hennings draft is the one example of a specific set of requirements targetted at a specific protocol. If we are to do generalizations, I'd prefer they be in other document(s), not one going to SIPPING. cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 09:13:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00425 for ; Tue, 15 Oct 2002 09:13:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FDFDs14281 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 09:15:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDFDv14278 for ; Tue, 15 Oct 2002 09:15:13 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00405 for ; Tue, 15 Oct 2002 09:13:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDERv14212; Tue, 15 Oct 2002 09:14:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDD3v14159 for ; Tue, 15 Oct 2002 09:13:03 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00325 for ; Tue, 15 Oct 2002 09:10:50 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FDCwm6005652; Tue, 15 Oct 2002 09:12:58 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FDCv5T001453 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Oct 2002 09:12:58 -0400 (EDT) Message-ID: <3DAC143D.7010905@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Carlberg CC: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 References: <981.1034685145@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 09:12:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I appreciate all the suggestions, but at some point it's also appropriate to ask "does it make a real difference?". This is a requirements document for SIPPING, not the US constitution. > i would prefer they not be. Hennings draft is the one example of a > specific set of requirements targetted at a specific protocol. If > we are to do generalizations, I'd prefer they be in other document(s), > not one going to SIPPING. > > cheers, > > -ken > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 09:28:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00869 for ; Tue, 15 Oct 2002 09:28:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FDTwe14766 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 09:29:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDTwv14763 for ; Tue, 15 Oct 2002 09:29:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00823 for ; Tue, 15 Oct 2002 09:27:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDTFv14736; Tue, 15 Oct 2002 09:29:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDPXv14572 for ; Tue, 15 Oct 2002 09:25:33 -0400 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00715 for ; Tue, 15 Oct 2002 09:23:20 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id l.156.15e960e8 (3842) for ; Tue, 15 Oct 2002 09:25:26 -0400 (EDT) Message-ID: <156.15e960e8.2add7146@aol.com> To: IEPREP@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_156.15e960e8.2add7146_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 50 Subject: [Ieprep] IEPREP requirements for accounting Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 09:25:26 EDT --part1_156.15e960e8.2add7146_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, The point of a number of my comments the past several weeks is to add a requirement to IEPREP as follows. I don't know whether this should go under "Security", since by itself it does not provide "security" in the normal sense. While this draft concentrates on "ETS", that is, authorized emergency calls, this requirement also applies (maybe even stronger) to public dialed emergency calls like 911 or 112 and it applies to what I have been proposing called "Assured Service". ----------------------------------------- REQ x: Accountability: The security of ETS depends on being able to determine, after the fact, who used the service. This is important in order to detect use by unauthorized persons (through theft of passwords, etc.) as well as improper use by authorized persons. The system or network must provide a capability for maintaining a record of each use, and attempted use, of the service, to include whatever identifying information is available. ----------------------------------------- And before comments related to packet transfer start, the above is not intended in any way to imply that any network element should record transfers of packets or streams of packets that are marked for "preferential treatment". It applies to call setup, i.e., INVITEs. Therefore, it applies directly to SIP, which is the subject of this draft. Mike Pierce Artel --part1_156.15e960e8.2add7146_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

The point of a number of my comments the past several weeks is to add a requirement to IEPREP as follows. I don't know whether this should go under "Security", since by itself it does not provide "security" in the normal sense. While this draft concentrates on "ETS", that is, authorized emergency calls, this requirement also applies (maybe even stronger) to public dialed emergency calls like 911 or 112 and it applies to what I have been proposing called "Assured Service".

-----------------------------------------
REQ x: Accountability: The security of ETS depends on being able to determine, after the fact, who used the service. This is important in order to detect use by unauthorized persons (through theft of passwords, etc.) as well as improper use by authorized persons. The system or network must provide a capability for maintaining a record of each use, and attempted use, of the service, to include whatever identifying information is available.
-----------------------------------------

And before comments related to packet transfer start, the above is not intended in any way to imply that any network element should record transfers of packets or streams of packets that are marked for "preferential treatment". It applies to call setup, i.e., INVITEs. Therefore, it applies directly to SIP, which is the subject of this draft.

Mike Pierce
Artel

--part1_156.15e960e8.2add7146_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 09:31:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00991 for ; Tue, 15 Oct 2002 09:31:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FDWnC14988 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 09:32:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDWnv14985 for ; Tue, 15 Oct 2002 09:32:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00958 for ; Tue, 15 Oct 2002 09:30:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDW6v14959; Tue, 15 Oct 2002 09:32:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDV2v14896 for ; Tue, 15 Oct 2002 09:31:02 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00902 for ; Tue, 15 Oct 2002 09:28:48 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Oct 2002 14:30:53 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Henning Schulzrinne cc: "King, Kimberly S." , "Ieprep (E-mail)" Subject: Re: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 In-reply-to: Your message of "Tue, 15 Oct 2002 09:12:29 EDT." <3DAC143D.7010905@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1099.1034688651@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 14:30:51 +0100 > I appreciate all the suggestions, but at some point it's also > appropriate to ask "does it make a real difference?". This is a > requirements document for SIPPING, not the US constitution. agreed. what i what i was trying to say in the last message is that I'd prefer to keep those security related requirements that were cited "as is" -- ie, don't make changes. as a side observation, I think its nice that folks are involved and commenting. so many times, people have to plead for comments. but I get the feeling that Hennings document has been sufficiently examined. we run the risk of going down every conceiveable interpretation to the point where the document is never finished. it would be nice if we could just get a freeze on it and allow henning to fold in these last comments, and send it over to SIPPING. just my opinion. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 10:08:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02524 for ; Tue, 15 Oct 2002 10:08:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FE9mi17478 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 10:09:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FE9lv17475 for ; Tue, 15 Oct 2002 10:09:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02482 for ; Tue, 15 Oct 2002 10:07:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FE97v17459; Tue, 15 Oct 2002 10:09:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FE8mv17441 for ; Tue, 15 Oct 2002 10:08:48 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02454 for ; Tue, 15 Oct 2002 10:06:34 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FE8im6009612; Tue, 15 Oct 2002 10:08:44 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FE8h5T005467 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Oct 2002 10:08:44 -0400 (EDT) Message-ID: <3DAC214F.3080201@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: IEPREP@ietf.org Subject: Re: [Ieprep] IEPREP requirements for accounting References: <156.15e960e8.2add7146@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 10:08:15 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In my view, this is a strictly operational requirement. It is clearly trivially possible to record SIP requests, including any priority indications or authentication exchanges. If it is more than just keeping a log file, SIP itself is not a candidate for conveying such accounting records to third parties. The format and detail of such logs or accounting records are also beyond the scope of this WG. Thus, I fail to see how this requirement will in any way influence the design choices made in SIP/SIPPING. The requirement is obviously harmless (and a good idea for an operator), but, taking Scott's advice, I would rather concentrate on things that bear on the design process. Mpierce1@aol.com wrote: > To all, > > The point of a number of my comments the past several weeks is to add a > requirement to IEPREP as follows. I don't know whether this should go > under "Security", since by itself it does not provide "security" in the > normal sense. While this draft concentrates on "ETS", that is, > authorized emergency calls, this requirement also applies (maybe even > stronger) to public dialed emergency calls like 911 or 112 and it > applies to what I have been proposing called "Assured Service". > > ----------------------------------------- > REQ x: Accountability: The security of ETS depends on being able to > determine, after the fact, who used the service. This is important in > order to detect use by unauthorized persons (through theft of passwords, > etc.) as well as improper use by authorized persons. The system or > network must provide a capability for maintaining a record of each use, > and attempted use, of the service, to include whatever identifying > information is available. > ----------------------------------------- > > And before comments related to packet transfer start, the above is not > intended in any way to imply that any network element should record > transfers of packets or streams of packets that are marked for > "preferential treatment". It applies to call setup, i.e., INVITEs. > Therefore, it applies directly to SIP, which is the subject of this draft. > > Mike Pierce > Artel > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 10:42:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03712 for ; Tue, 15 Oct 2002 10:42:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FEi2119759 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 10:44:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FEi2v19756 for ; Tue, 15 Oct 2002 10:44:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03688 for ; Tue, 15 Oct 2002 10:41:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FEhMv19672; Tue, 15 Oct 2002 10:43:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FEgHv19628 for ; Tue, 15 Oct 2002 10:42:17 -0400 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03650 for ; Tue, 15 Oct 2002 10:40:05 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 88F5767113; Tue, 15 Oct 2002 06:58:57 -0400 (EDT) Subject: Re: [Ieprep] IEPREP requirements for accounting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: IEPREP@ietf.org To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <156.15e960e8.2add7146@aol.com> Message-Id: <49CDF060-E04C-11D6-A541-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 10:42:11 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Oct 15, 2002, at 09:25 America/Montreal, Mpierce1@aol.com wrote: > While this draft concentrates on "ETS", that is, authorized emergency > calls, this requirement also applies (maybe even stronger) to public > dialed emergency calls like 911 or 112 and it applies to what I have > been proposing called "Assured Service". Support for POTS-like 911 and 112 services are out of scope for this Working Group, but should be in scope for SIPPING. So I'd suggest that you take your comments of that flavour directly over there, rather than raising them here. > ----------------------------------------- > REQ x: Accountability: The security of ETS depends on being able to > determine, after the fact, who used the service. I do not believe the above sentence is factually true. If one really think it is true, maybe a starting point would be for one to provide a more detailed definition of "security". Words that might be more clear (not sure which one's meaning might be) include for example: authentication confidentiality integrity > This is important in order to detect use by unauthorized persons > (through theft of passwords, etc.) as well as improper use by > authorized persons. The system or network must provide a capability > for maintaining a record of each use, and attempted use, of the > service, to include whatever identifying information is available. I do not believe this is a legitimate requirement to place on service providers. As long as the service provider has enough capacity to handle both legitimate and non-legitimate calls, there is no functional need for the service provider to detect or account for the non-legitimate uses/users. This is a business tradeoff between call capacity costs and accounting/detection costs. Different service providers might legitimately make different decisions for that tradeoff based on differing cost structures. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 11:08:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04544 for ; Tue, 15 Oct 2002 11:08:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FF9lw21195 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 11:09:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FF9kv21192 for ; Tue, 15 Oct 2002 11:09:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04525 for ; Tue, 15 Oct 2002 11:07:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FF96v21177; Tue, 15 Oct 2002 11:09:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FF88v21146 for ; Tue, 15 Oct 2002 11:08:08 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04271 for ; Tue, 15 Oct 2002 11:05:56 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FF85m6013785; Tue, 15 Oct 2002 11:08:05 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FF835T010087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Oct 2002 11:08:04 -0400 (EDT) Message-ID: <3DAC2F37.5030800@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ieprep] Re: Security Requirements for SIPPING SEC-1 to SEC-5 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 11:07:35 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit King, Kimberly S. wrote: > "SEC-1: More rigorous: Prioritized access to network and end > system resources imposes particularly stringent > requirements on authentication and authorization > mechanisms > since access to prioritized resources may impact overall > system stability and performance, not just result in theft > of, say, a single phone call. > > The authentication and authorization requirements for ETS > calls are, in particular, much stronger than for emergency > calls (112, 911), where wide access is the design > objective, sacrificing caller identification if necessary." > > We talked about this one before. In reality, you aren't asking for anything > stronger than what is used in some commercial systems today, right? I think > the "more rigorous" might cause some confusion. Clearly, some commercial systems already satisfy this requirement. However, the requirement, discussed at the last meeting, I believe, was that since priority calls can do more harm than "normal" calls (by blocking resources, say), the requirements are in general, more strict. I suspect that this requirement won't make much difference in the design, but given previous discussions, I'd rather not re-open this one. > "SEC-4: Non-trusted end systems: Since ETS users may use devices > that are not their own, systems should support > authentication mechanisms that do not require the user to > reveal her secret to the device." > > An example acceptable solution might help to clarify here. If a person > enters a PIN or simple password (yes, I know these things are weak security) > is that considered revealing the secret to the device? Yes. Note the 'should' - this may not be feasible or necessary in all cases. > > " SEC-5: Subversion of authentication infrastructure: Attackers > It appears that statements on the number of packets or amount of resources, > or prevention of unauthorized users to block CN resources are policy > statements intended to motivate this requirement that says (redundantly?) > that SEC-2 must hold. I agree that the two can be merged. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 11:50:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05476 for ; Tue, 15 Oct 2002 11:50:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FFps623190 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 11:51:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFpsv23187 for ; Tue, 15 Oct 2002 11:51:54 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05451 for ; Tue, 15 Oct 2002 11:49:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFpCv23177; Tue, 15 Oct 2002 11:51:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFoUv23149 for ; Tue, 15 Oct 2002 11:50:30 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05435 for ; Tue, 15 Oct 2002 11:48:16 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FFoQm6017073; Tue, 15 Oct 2002 11:50:26 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FFoP5T013683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Oct 2002 11:50:25 -0400 (EDT) Message-ID: <3DAC3924.9040308@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Ieprep (E-mail)" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ieprep] Re: Security Requirements for SIPPING SEC-11 to SEC-14 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 11:49:56 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > "SEC-14: Avoid amplification: The system must not amplify attacks > by causing the transmission of more than one packet to a > network address whose reachability has not been verified." > > Is this standard procedure? If so, why have the requirement? If not, it > seems like it would delay call setup and require changes for default > behavior (since by SEC-4, ETS users may use phones that are not their own). > > Also, do you mean "one packet" or one SIP message? Roughly the same thing, unless you have (UDP) fragmentation. I added 'or SIP request'. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 11:59:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05798 for ; Tue, 15 Oct 2002 11:59:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FG13g23792 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 12:01:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FG13v23789 for ; Tue, 15 Oct 2002 12:01:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05792 for ; Tue, 15 Oct 2002 11:58:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FG08v23735; Tue, 15 Oct 2002 12:00:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFxWv23655 for ; Tue, 15 Oct 2002 11:59:32 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05682 for ; Tue, 15 Oct 2002 11:57:18 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 15 Oct 2002 11:59:09 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101511590915944 ; Tue, 15 Oct 2002 11:59:09 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0Q4BJ3>; Tue, 15 Oct 2002 12:00:20 -0400 Message-Id: From: "King, Kimberly S." To: "'Ian Brown'" , "King, Kimberly S." , "Henning Schulzrinne (E-mail)" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 11:59:08 -0400 > Kimberly said: > >>...To, From, Organization, Subject, Priority and Via header > fields... > > Aren't some of these fields important for SIP routing? Do > you have an > > example solution in mind that would protect these fields? > > Ian said: > Fields that aren't needed for routing can protected > end-to-end using S/MIME. > Fields that are can only be protected hop-by-hop using a > protocol such as > TLS. > Okay. I am going to bring in some technology, not to mandate solutions, but rather so we can have a better idea of what is being requested here. Let's assume that fields like 'TO' that are normally used for SIP routing are to be protected. Then Ian points out this protection can be obtained by hop-by-hop protection (say using TLS). I then wonder, "does this requirement then limit the solution to only certain SIP networks?". In other words, must all SIP proxies support hop-by-hop protection? Heading to RFC 3261, I see SIPS URI is a way to accomplish secure, encrypted transport to carry all SIP messages from the caller to the domain of the callee. (It doesn't say this is the only way, but it is one way.) "All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme." So it appears that TLS isn't mandatory. REQ-3 indicates the mechanism should be capable of being used in networks "that are only SIP/RTP transparent". Unraveling this requirement in its strongest form says the mechanism is a valid SIP request. (This is because we want this to pass through in SIP/RTP networks and we are only guaranteed that valid SIP messages will pass through these networks.) Are there other ways to perform hop-by-hop protection that must be supported by every SIP proxy or is there an underlying assumption about proxies here? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 15 13:54:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09601 for ; Tue, 15 Oct 2002 13:54:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FHuJx30284 for ieprep-archive@odin.ietf.org; Tue, 15 Oct 2002 13:56:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHuJv30281 for ; Tue, 15 Oct 2002 13:56:19 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09575 for ; Tue, 15 Oct 2002 13:54:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHtCv30235; Tue, 15 Oct 2002 13:55:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHsfv30210 for ; Tue, 15 Oct 2002 13:54:41 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09526 for ; Tue, 15 Oct 2002 13:52:26 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FHsPm6000869; Tue, 15 Oct 2002 13:54:25 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FHsM5T023738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Oct 2002 13:54:24 -0400 (EDT) Message-ID: <3DAC5631.4010805@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "'Ian Brown'" , "Ieprep (E-mail)" Subject: Re: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Oct 2002 13:53:53 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Okay. I am going to bring in some technology, not to mandate solutions, but > rather so we can have a better idea of what is being requested here. > > Let's assume that fields like 'TO' that are normally used for SIP routing > are to be protected. Then Ian points out this protection can be obtained by > hop-by-hop protection (say using TLS). > > I then wonder, "does this requirement then limit the solution to only > certain SIP networks?". In other words, must all SIP proxies support > hop-by-hop protection? They should as of today: Section 26.3.1 of RFC 3261 reads Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication. It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. > So it appears that TLS isn't mandatory. REQ-3 indicates the mechanism See above. IPsec can be used instead, btw. > should be capable of being used in networks "that are only SIP/RTP > transparent". Unraveling this requirement in its strongest form says the > mechanism is a valid SIP request. (This is because we want this to pass > through in SIP/RTP networks and we are only guaranteed that valid SIP > messages will pass through these networks.) > > Are there other ways to perform hop-by-hop protection that must be supported > by every SIP proxy or is there an underlying assumption about proxies here? Since the Internet as constituted today doesn't offer a generic, application-independent encryption service, the answer has to be no. (By "offer", I mean "available to any application anywhere, from any ISP".) As an ooperational practice, we can recommend that networks offering IEPREP services support confidentiality (TLS or IPsec), but this would be another "unfunded mandate", as they call this in Washington. As always, security is not binary - you have to weigh the trade-offs of making the call even if you don't get your favorite security solution. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 16 13:06:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05893 for ; Wed, 16 Oct 2002 13:06:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GH8K115683 for ieprep-archive@odin.ietf.org; Wed, 16 Oct 2002 13:08:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GH8Kv15680 for ; Wed, 16 Oct 2002 13:08:20 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05883 for ; Wed, 16 Oct 2002 13:06:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GGv9v14804; Wed, 16 Oct 2002 12:57:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GGFIv12690 for ; Wed, 16 Oct 2002 12:15:18 -0400 Received: from imo-d06.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04510 for ; Wed, 16 Oct 2002 12:12:53 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v34.13.) id j.ba.2dad64ba (30950); Wed, 16 Oct 2002 12:03:15 -0400 (EDT) Message-ID: Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 To: rja@extremenetworks.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_ba.2dad64ba.2adee7c2_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 50 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Oct 2002 12:03:14 EDT --part1_ba.2dad64ba.2adee7c2_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 3:18:54 PM Eastern Standard Time, rja@extremenetworks.com writes: > On Friday, Oct 11, 2002, at 13:51 America/Montreal, Mpierce1@aol.com > wrote: > > [MAP] It's become clear to me, with the ongoing discussion under > > "Policy and labels", that this requirement REQ-7, as currently > > written, could be misinterpreted by some in the future, and may itself > > become a hinderance to making progress. > > So far, everyone except you seems to be able to understand the written > meaning quite clearly. > > For the record, I don't think there is a problem with clarity. > > [MAP] The discussion of "Policy and Labels" began with an e-mail from Ken that began "there has been a recurring discussion about policy and labels -- people for it, against it, confused by its separation, etc". I have gone back and reviewed all the e-mails, and I don't sense the thread resulted in a common understanding of the issue or the conclusion, so the confusion Ken referred to still exists. Through much of it, there was a problem with knowing just what the scope of the discussion was. If everyone else understands the meaning of "separation of indication and policy" in REQ-7, then perhaps someone can explain it in simple, explicit terms. What I am most concerned about is that someone will later say that this requirement, after we have agreed to it, means that we can not define priority levels as something like "low, mediium, and high". You didn't comment on my suggested rewording. Is it incorrect? Mike Pierce Artel --part1_ba.2dad64ba.2adee7c2_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2002 3:18:54 PM Eastern Standard Time, rja@extremenetworks.com writes:


On Friday, Oct 11, 2002, at 13:51 America/Montreal, Mpierce1@aol.com
wrote:
> [MAP] It's become clear to me, with the ongoing discussion under
> "Policy and labels", that this requirement REQ-7, as currently
> written, could be misinterpreted by some in the future, and may itself
> become a hinderance to making progress.

So far, everyone except you seems to be able to understand the written
meaning quite clearly.

For the record, I don't think there is a problem with clarity.




[MAP] The discussion of "Policy and Labels" began with an e-mail from Ken that began "there has been a recurring discussion about policy and labels -- people
for it, against it, confused by its separation, etc". I have gone back and reviewed all the e-mails, and I don't sense the thread resulted in a common understanding of the issue or the conclusion, so the confusion Ken referred to still exists. Through much of it, there was a problem with knowing just what the scope of the discussion was.

If everyone else understands the meaning of "separation of indication and policy" in REQ-7, then perhaps someone can explain it in simple, explicit terms. What I am most concerned about is that someone will later say that this requirement, after we have agreed to it, means that we can not define priority levels as something like "low, mediium, and high".

You didn't comment on my suggested rewording. Is it incorrect?

Mike Pierce
Artel
--part1_ba.2dad64ba.2adee7c2_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 16 14:09:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07873 for ; Wed, 16 Oct 2002 14:09:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GIBAv20055 for ieprep-archive@odin.ietf.org; Wed, 16 Oct 2002 14:11:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GIBAv20052 for ; Wed, 16 Oct 2002 14:11:10 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07823 for ; Wed, 16 Oct 2002 14:08:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GIAAv19876; Wed, 16 Oct 2002 14:10:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GI9Gv19801 for ; Wed, 16 Oct 2002 14:09:16 -0400 Received: from [140.32.132.66] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07698 for ; Wed, 16 Oct 2002 14:06:59 -0400 (EDT) Received: from mail.nps.navy.mil by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Wed, 16 Oct 2002 11:07:05 -0700 Received: from there ([131.120.179.247]) by capella.nps.navy.mil (8.12.2/8.12.2) with SMTP id g9GI8M34022131; Wed, 16 Oct 2002 11:08:22 -0700 (PDT) Message-Id: <200210161808.g9GI8M34022131@capella.nps.navy.mil> Content-Type: text/plain; charset="iso-8859-1" From: Rex Buddenberg To: Mpierce1@aol.com, rja@extremenetworks.com Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 X-Mailer: KMail [version 1.3.2] Cc: ieprep@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9GI9Gv19802 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Oct 2002 11:07:20 -0700 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The segregation of mechanism and policy/implementation has long been a hallmark of Internet design. It roots back to router design and is fairly well (if tacitly) captured in RFC 1812. The defining historical example is routers -- the mechanism of forwarding IP datagrams is unchanged since the early 80s when IPv4 came into general ARPANET use (replacing the older Network Control Protocol which suffered from several shortcomings, including this lack of separation). But routers, like computers, have evolved enormously since then. The trick is to keep the forwarding function unchanged and allow everything else to evolve. Germane to this discussion is the evolution of routing information protocols. Initially, the ARPANET routers all ran Routing Information Protocol (RIP) and were organized into what we would today call a single autonomous system. RIP limited the diameter of the network (I think to 16 routers??). If your destination was more hops away than that, your grams fell off the edge of the earth before arrival (I recall this happening to e-mail from my US box to Oz (Australia). So RIP had to evolve ... but we can't rip (sorry) up the whole Internet just to replace the routing information protocol. Fortunately, the foresight of router construction allowed us to update these protocols while leaving the basic forwarding mechanism unchanged -- today most of the Internet is organized as autonomous systems with BGP as the common exterior gateway protocol and most autonomous systems running OSPF as the interior (although the specific choice is up to the AS administrator). This separation has recurred in the use of the DS (ex TOS) byte in IP datagrams. We've long agreed to allocate that byte in the header -- the mechanism. But until fairly recently, IETF had not defined the semantics within that byte -- it had been left up to vendors and implementors. The standardization of DSCP was needed in order to ensure that all ISPs read the same meaning out of a particular bit setting (there was a mini-big-endian/ little-endian spat in here, as I recall) and provide uniform per-hop treatment. Extending the reasoning to Ken's comments: we are trying to make the basic mechanism setup and future-proof it. 1. because we need a long-term stable mechanism and 2. because we don't know all we need to know about the implementing altorithms but we can be very sure that the requirements will shift at some time in the fairly near future (a war plan making contact with the enemy). The separation is designed to allow both objectives. On Wednesday 16 October 2002 09:03 am, Mpierce1@aol.com wrote: > In a message dated 10/11/2002 3:18:54 PM Eastern Standard Time, > > rja@extremenetworks.com writes: > > On Friday, Oct 11, 2002, at 13:51 America/Montreal, Mpierce1@aol.com > > > > wrote: > > > [MAP] It's become clear to me, with the ongoing discussion under > > > "Policy and labels", that this requirement REQ-7, as currently > > > written, could be misinterpreted by some in the future, and may itself > > > become a hinderance to making progress. > > > > So far, everyone except you seems to be able to understand the written > > meaning quite clearly. > > > > For the record, I don't think there is a problem with clarity. > > [MAP] The discussion of "Policy and Labels" began with an e-mail from Ken > that began "there has been a recurring discussion about policy and labels > -- people > for it, against it, confused by its separation, etc". I have gone back and > reviewed all the e-mails, and I don't sense the thread resulted in a common > understanding of the issue or the conclusion, so the confusion Ken referred > to still exists. Through much of it, there was a problem with knowing just > what the scope of the discussion was. > > If everyone else understands the meaning of "separation of indication and > policy" in REQ-7, then perhaps someone can explain it in simple, explicit > terms. What I am most concerned about is that someone will later say that > this requirement, after we have agreed to it, means that we can not define > priority levels as something like "low, mediium, and high". > > You didn't comment on my suggested rewording. Is it incorrect? > > Mike Pierce > Artel -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 17 08:42:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08332 for ; Thu, 17 Oct 2002 08:42:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HCiOU19734 for ieprep-archive@odin.ietf.org; Thu, 17 Oct 2002 08:44:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCiOv19731 for ; Thu, 17 Oct 2002 08:44:24 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08275 for ; Thu, 17 Oct 2002 08:42:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCeGv19537; Thu, 17 Oct 2002 08:40:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCcxv19439 for ; Thu, 17 Oct 2002 08:38:59 -0400 Received: from imo-d10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08081 for ; Thu, 17 Oct 2002 08:36:45 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d10.mx.aol.com (mail_out_v34.13.) id 7.bf.2861b89c (25305); Thu, 17 Oct 2002 08:38:40 -0400 (EDT) Message-ID: Subject: Re: [Ieprep] IEPREP SIP REQ other comments To: hgs@cs.columbia.edu, Janet.Gunn@dyncorp.com CC: KIMBERLY.S.KING@saic.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_bf.2861b89c.2ae0094f_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 50 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Oct 2002 08:38:39 EDT --part1_bf.2861b89c.2ae0094f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/14/2002 8:14:46 PM Eastern Daylight Time, hgs@cs.columbia.edu writes: > There are, I believe, four cases: > > (1) want priority, but not yet authorized -> system should challenge > user, which leads to case (2) > > (2) priority + credentials (e.g., in SIP, a Digest authorization or an > S/MIME-signed body) > > (3) priority + network-asserted identity (NAI): The recipient of the > request somehow has reason to believe that the NAI is correct and then > check that the identity can request the service. > > (4) priority approved by third party: Here, the recipient has reason to > believe that the request has been vetted by a trusted third party. > > I can spell out these different scenarios if people believe this to be > helpful. For (2), (3) and (4), there are likely several different > solutions in SIP. > [MAP] Good thought! Presuming we are talking strictly about the requirements leading to approval of the Resource-Priority Header, then it seems reasonable that there are the above 4 cases that need to be signaled. The question (later) would be whether an indication of this is an integral part of the Resource-Priority Header, or it is more general, i.e., does it also apply to other things in the SIP message (besides maybe NAI). Mike Pierce Artel --part1_bf.2861b89c.2ae0094f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/14/2002 8:14:46 PM Eastern Daylight Time, hgs@cs.columbia.edu writes:


There are, I believe, four cases:

(1) want priority, but not yet authorized -> system should challenge
user, which leads to case (2)

(2) priority + credentials (e.g., in SIP, a Digest authorization or an
S/MIME-signed body)

(3) priority + network-asserted identity (NAI): The recipient of the
request somehow has reason to believe that the NAI is correct and then
check that the identity can request the service.

(4) priority approved by third party: Here, the recipient has reason to
believe that the request has been vetted by a trusted third party.

I can spell out these different scenarios if people believe this to be
helpful. For (2), (3) and (4), there are likely several different
solutions in SIP.


[MAP] Good thought! Presuming we are talking strictly about the requirements leading to approval of the Resource-Priority Header, then it seems reasonable that there are the above 4 cases that need to be signaled. The question (later) would be whether an indication of this is an integral part of the Resource-Priority Header, or it is more general, i.e., does it also apply to other things in the SIP message (besides maybe NAI).

Mike Pierce
Artel
--part1_bf.2861b89c.2ae0094f_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 17 08:52:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08808 for ; Thu, 17 Oct 2002 08:52:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HCrlW20130 for ieprep-archive@odin.ietf.org; Thu, 17 Oct 2002 08:53:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCrkv20127 for ; Thu, 17 Oct 2002 08:53:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08714 for ; Thu, 17 Oct 2002 08:51:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCr7v20089; Thu, 17 Oct 2002 08:53:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCqqv20051 for ; Thu, 17 Oct 2002 08:52:52 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08607 for ; Thu, 17 Oct 2002 08:50:38 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 17 Oct 2002 08:52:36 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101708523612522 ; Thu, 17 Oct 2002 08:52:36 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <4Q0QV1R5>; Thu, 17 Oct 2002 08:53:48 -0400 Message-Id: From: "King, Kimberly S." To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: "'Ian Brown'" , "Ieprep (E-mail)" Subject: RE: [Ieprep] Security Requirements for SIPPING MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Oct 2002 08:52:36 -0400 Which security requirements in the document are already offered by SIP and which ones represent new functionality? For example: SEC-4 says ETS users may use devises that are not their own. REQ-3 implies the resource priority mechanism is a valid SIP message (this follows from the definition of what it means to be able to pass through the SIP/RTP transparent network model) May I infer that the features needed to support the signaling for resource priority will then be a part of the normal feature set for SIP end nodes? I think the answer is yes. Previously, I asked: > In other words, must all SIP > proxies support > hop-by-hop protection? Henning replied: > They should as of today: Section 26.3.1 of RFC 3261 reads > > Proxy servers, redirect servers, and registrars MUST > implement TLS, > and MUST support both mutual and one-way authentication. It is > strongly RECOMMENDED that UAs be capable initiating TLS; > UAs MAY also > be capable of acting as a TLS server. > SEC-9 added hop-by-hop encryption was needed to protect fields like 'to' or 'via'. Assume that features needed to support the signaling for resource priority will then be a part of the normal feature set for SIP end nodes along with the security requirements. Does this imply that the behavior for UAs would need to be modified to say they MUST be capable of initiating TLS? My questions center around "what security requirements represents something SIP, SIP proxies, SIP end nodes, etc. don't already support"? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 17 09:05:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09337 for ; Thu, 17 Oct 2002 09:05:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HD77321550 for ieprep-archive@odin.ietf.org; Thu, 17 Oct 2002 09:07:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HD77v21539 for ; Thu, 17 Oct 2002 09:07:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09307 for ; Thu, 17 Oct 2002 09:04:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HD3Av21228; Thu, 17 Oct 2002 09:03:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HD23v21204 for ; Thu, 17 Oct 2002 09:02:03 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09137 for ; Thu, 17 Oct 2002 08:59:49 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 17 Oct 2002 14:01:45 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: rja@extremenetworks.com, ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 In-reply-to: Your message of "Wed, 16 Oct 2002 12:03:14 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <960.1034859703@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Oct 2002 14:01:43 +0100 speaking specifically in terms of henning's SIP requirements draft... > If everyone else understands the meaning of "separation of indication > and policy" in REQ-7, then perhaps someone can explain it in simple, > explicit terms. What I am most concerned about is that someone will > later say that this requirement, after we have agreed to it, means that > we can not define priority levels as something like "low, mediium, and > high". simple answer (in my opinion): yes, you can define priority levels as "low, mediium, and high", though presumably you'll want to be more specific and state "low" in relation to what (e.g., drop precedence). from the original requirements in Hennings draft... REQ-7: Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the requests invokes a certain named policy that may well have those properties. notice the use of the term "detailed treatment". I had read that as *how* with respect to an implementation/mechanism a label is to be supported. next, to borrow from an earlier exchange between yourself and Henning... Date: Wed, 09 Oct 2002 09:24:55 -0400 From: Mpierce1@aol.com > If two priority values are "low" and "high", would someone claim that > this violates the above requirement? The "indication" certainly > describes something about the treament. From:Henning Schulzrinne I think the litmus test is that one should be able to specify, for each such label, at least two independent and interoperable implementations that are different in the behavioral details (such as queueing, dropping, rerouting, traffic controls, etc.). notice the use of the term "implementations". again, I read that as how something is to be done. If henning changes the wording of "detailed treatment" to "implementation", does that help you accept REQ-7 above? (this in addition to the other changes he has agreed on) -------------- switching over to my thread of "policy & labels", i originally stated: Another way of distinguishing traffic is to use a set of *related* labels. This set may convey various measures of a characteristic that is internal to that set. I needed to be more general in my statement so that it could be a applied to SIP or DSCP (or some other type of label). the intent of my choosing the word "related labels" and "characteristic" was to specifically satisfy your concern/need to be able to define labels in the general sense of something like "low medium high". further, I cited AF as an example of prior art that represents a set of labels related to each other (ie, the same class) that have a different measure of a shared characteristic (eg, drop precedence). my hope is that this issue is coming to a close. > [MAP] The discussion of "Policy and Labels" began with an e-mail from > Ken that began "there has been a recurring discussion about policy and > labels -- people for it, against it, confused by its separation, etc". > I have gone back and reviewed all the e-mails, and I don't sense the > thread resulted in a common understanding of the issue or the conclusion, > so the confusion Ken referred to still exists. Through much of it, there > was a problem with knowing just what the scope of the discussion was. the scope of the discussion is a bit of a rat hole and an unfortunate distraction. my need was to say something that can apply to labeling schemas beyond SIP. henning's need is to be more specific and focus on SIP. (roughly similar to one person talking about fruits, and another talking about apples -- a type of fruit). but its probably best to drop this last particular line of discussion. best wishes, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 17 10:51:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13587 for ; Thu, 17 Oct 2002 10:51:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HErrO29077 for ieprep-archive@odin.ietf.org; Thu, 17 Oct 2002 10:53:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HErrv29072 for ; Thu, 17 Oct 2002 10:53:53 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13583 for ; Thu, 17 Oct 2002 10:51:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HEo1v28760; Thu, 17 Oct 2002 10:50:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HEOrv26990 for ; Thu, 17 Oct 2002 10:24:53 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12499 for ; Thu, 17 Oct 2002 10:22:38 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 10:22:58 -0400 Message-ID: From: "Gunn, Janet" To: "'Ken Carlberg'" , Mpierce1@aol.com Cc: rja@extremenetworks.com, ieprep@ietf.org Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Oct 2002 10:22:43 -0400 Addressing just the first part- In my mind the independence of indication and policy does not in any way inhibit me from naming my indications "low, medium, high". But, at the same time, it does not PREVENT me from implementing a policy under which (at least under some circumstances), calls labeled "low" get better performance than calls labeled "high". (An example would be that calls labeled "high" get priority as long as the volume of "high priority calls" remains below a threshold. Once the volume crosses that threshold, they get worse treatment.) -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Thursday, October 17, 2002 9:02 AM To: Mpierce1@aol.com Cc: rja@extremenetworks.com; ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 speaking specifically in terms of henning's SIP requirements draft... > If everyone else understands the meaning of "separation of indication > and policy" in REQ-7, then perhaps someone can explain it in simple, > explicit terms. What I am most concerned about is that someone will > later say that this requirement, after we have agreed to it, means that > we can not define priority levels as something like "low, mediium, and > high". simple answer (in my opinion): yes, you can define priority levels as "low, mediium, and high", though presumably you'll want to be more specific and state "low" in relation to what (e.g., drop precedence). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 06:22:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20309 for ; Fri, 18 Oct 2002 06:22:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IAOCI05052 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 06:24:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IAOCv05049 for ; Fri, 18 Oct 2002 06:24:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20305 for ; Fri, 18 Oct 2002 06:21:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IAN2v05017; Fri, 18 Oct 2002 06:23:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IALgv04984 for ; Fri, 18 Oct 2002 06:21:42 -0400 Received: from imo-d03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20291 for ; Fri, 18 Oct 2002 06:19:28 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v34.13.) id i.3f.1389d5ca (4410); Fri, 18 Oct 2002 06:21:32 -0400 (EDT) Message-ID: <3f.1389d5ca.2ae13aab@aol.com> Date: Fri, 18 Oct 2002 06:21:31 EDT Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 To: K.Carlberg@cs.ucl.ac.uk CC: rja@extremenetworks.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_3f.1389d5ca.2ae13aab_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_3f.1389d5ca.2ae13aab_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/17/2002 3:02:21 PM W. Europe Daylight Time, K.Carlberg@cs.ucl.ac.uk writes: > simple answer (in my opinion): yes, you can define priority levels as > "low, mediium, and high", though presumably you'll want to be more > specific and state "low" in relation to what (e.g., drop precedence). > Thanks for the clarification, but your reference above to "drop precedence" is maybe where the confusion is. This implies that it would be okay to define a "priority level" for call setup as "low, with a higher packet drop precedence", but I have always understood that this was not a good idea, and that the point of REQ-7 and Hennings's remarks was to say that this should not be done since it was too specific and includes local policy into the actual priority value name. Mike Pierce Artel --part1_3f.1389d5ca.2ae13aab_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/17/2002 3:02:21 PM W. Europe Daylight Time, K.Carlberg@cs.ucl.ac.uk writes:


simple answer (in my opinion): yes, you can define priority levels as
"low, mediium, and high", though presumably you'll want to be more
specific and state "low" in relation to what (e.g., drop precedence).



Thanks for the clarification, but your reference above to "drop precedence" is maybe where the confusion is. This implies that it would be okay to define a "priority level" for call setup as "low, with a higher packet drop precedence", but I have always understood that this was not a good idea, and that the point of REQ-7 and Hennings's remarks was to say that this should not be done since it was too specific and includes local policy into the actual priority value name.

Mike Pierce
Artel
--part1_3f.1389d5ca.2ae13aab_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 07:06:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20953 for ; Fri, 18 Oct 2002 07:06:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IB8Cb07463 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 07:08:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IB8Cv07460 for ; Fri, 18 Oct 2002 07:08:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20932 for ; Fri, 18 Oct 2002 07:05:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IB7Hv07354; Fri, 18 Oct 2002 07:07:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IB6lv06834 for ; Fri, 18 Oct 2002 07:06:47 -0400 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20905 for ; Fri, 18 Oct 2002 07:04:32 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Oct 2002 12:06:42 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 In-reply-to: Your message of "Fri, 18 Oct 2002 06:21:31 EDT." <3f.1389d5ca.2ae13aab@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Oct 2002 12:06:42 +0100 Message-ID: <839.1034939202@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > Thanks for the clarification, but your reference above to "drop > precedence" is maybe where the confusion is. This implies that it > would be okay to define a "priority level" for call setup as "low, > with a higher packet drop precedence", but I have always understood > that this was not a good idea, and that the point of REQ-7 and > Hennings's remarks was to say that this should not be done since it > was too specific and includes local policy into the actual priority > value name. (keeping in mind that we are viewing "drop precedence" as only an example -- I'm not advocating or dismissing it, and we are constraining our perspective to SIP).... from my view, there are three things that are not a good idea. one is to articulate the mechanism and rules to *achieve* drop precedence, which is something that Henning has been discussing. we want a measure of lattitude so that several ways can be used to achieve it. further, that the measure of drop precedence should also be a local policy. the second is to avoid high level abstract characteristics. third, when defining a label, one wouldn't want to embed in its definition the relationship between it and non-related labels -- for example, MLPP labels and a NS/EP label are to be viewed as totally unrelated. the relationship of non-related labels is strictly a local policy issue and subject to the service that has been contracted. finally, we also want to accept that labels may have additional constraints or characteristics applied to them as a function of local policy. hence, a provider may be contracted to provide a form of pre-emption for one customer using for example NS/EP, while another provider may be contracted to not support pre-emption for the same label. that decision is a matter of local policy. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 10:32:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28103 for ; Fri, 18 Oct 2002 10:32:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IEY8N19244 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 10:34:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEY8v19241 for ; Fri, 18 Oct 2002 10:34:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28078 for ; Fri, 18 Oct 2002 10:31:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEXAv19177; Fri, 18 Oct 2002 10:33:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEWDv19097 for ; Fri, 18 Oct 2002 10:32:13 -0400 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27996 for ; Fri, 18 Oct 2002 10:29:58 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id r.170.15c0b780 (4418); Fri, 18 Oct 2002 10:31:53 -0400 (EDT) Message-ID: <170.15c0b780.2ae17559@aol.com> Date: Fri, 18 Oct 2002 10:31:53 EDT Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 To: Janet.Gunn@DynCorp.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_170.15c0b780.2ae17559_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_170.15c0b780.2ae17559_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/17/2002 4:25:14 PM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes: > Addressing just the first part- > > In my mind the independence of indication and policy does not in any way > inhibit me from naming my indications "low, medium, high". But, at the same > time, it does not PREVENT me from implementing a policy under which (at > least under some circumstances), calls labeled "low" get better performance > than calls labeled "high". > > (An example would be that calls labeled "high" get priority as long as the > volume of "high priority calls" remains below a threshold. Once the volume > crosses that threshold, they get worse treatment.) > > [MAP] Certainly, the treatment provided in any network element is subject to local control, but I would find it hard to believe that any customer of a priority service would accept a performance as you've described above, presuming that, by the last phrase, you meant "they get worse treatment than the lower priority calls". I certainly hope that we can figure out how to do better than that. I guess this would prompt me to suggest the following additional requirement if and when we start talking about requirements for treatments or procedures: "If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is." Mike Pierce Artel --part1_170.15c0b780.2ae17559_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/17/2002 4:25:14 PM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes:


Addressing just the first part-

In my mind the independence of  indication and policy does not in any way
inhibit me from naming my indications "low, medium, high".  But, at the same
time, it does not PREVENT me from implementing a policy under which (at
least under some circumstances), calls labeled "low" get better performance
than calls labeled "high".  

(An example would be that calls labeled "high" get priority as long as the
volume of "high priority calls" remains below a threshold.  Once the volume
crosses that threshold, they get worse treatment.)



[MAP] Certainly, the treatment provided in any network element is subject to local control, but I would find it hard to believe that any customer of a priority service would accept a performance as you've described above, presuming that, by the last phrase, you meant "they get worse treatment than the lower priority calls". I certainly hope that we can figure out how to do better than that. I guess this would prompt me to suggest the following additional requirement if and when we start talking about requirements for treatments or procedures:

"If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is."

Mike Pierce
Artel
--part1_170.15c0b780.2ae17559_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 10:42:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28591 for ; Fri, 18 Oct 2002 10:42:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IEi6q20463 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 10:44:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEi5v20460 for ; Fri, 18 Oct 2002 10:44:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28588 for ; Fri, 18 Oct 2002 10:41:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEh9v20405; Fri, 18 Oct 2002 10:43:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEeov20250 for ; Fri, 18 Oct 2002 10:40:50 -0400 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28390 for ; Fri, 18 Oct 2002 10:38:34 -0400 (EDT) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 18 Oct 2002 10:40:29 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002101810403009087 ; Fri, 18 Oct 2002 10:40:30 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 10:41:41 -0400 Message-Id: From: "King, Kimberly S." To: "'Mpierce1@aol.com'" , Janet.Gunn@DynCorp.com Cc: ieprep@ietf.org Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 Date: Fri, 18 Oct 2002 10:40:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , >Certainly, the treatment provided in any network element is subject to > local control, but I would find it hard to believe that any customer of a >priority service would accept a performance as you've described above, >presuming that, by the last phrase, you meant "they get worse >treatment than the lower priority calls". I certainly hope that we can >figure out how to do better than that. I guess this would prompt me to >suggest the following additional requirement if and when we start >talking about requirements for treatments or procedures: > "If a priority value is intended to get better service, e.g., higher call >setup probability, it must not be provided a worse service than > lower priority calls no matter what the traffic situation is." This is policy. We don't need to discuss this aspect...just requirements for indication, labeling, marking or whatever it is currently being called. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 12:13:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02156 for ; Fri, 18 Oct 2002 12:13:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IGEoX27011 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 12:14:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IGEov27008 for ; Fri, 18 Oct 2002 12:14:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02150 for ; Fri, 18 Oct 2002 12:12:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IGE9v26977; Fri, 18 Oct 2002 12:14:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IG9Vv26863 for ; Fri, 18 Oct 2002 12:09:31 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02025 for ; Fri, 18 Oct 2002 12:07:14 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9IG9Om6026545; Fri, 18 Oct 2002 12:09:25 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9IG9N5T021099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 18 Oct 2002 12:09:24 -0400 (EDT) Message-ID: <3DB032A7.5000902@cs.columbia.edu> Date: Fri, 18 Oct 2002 12:11:19 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "'Ian Brown'" , "Ieprep (E-mail)" Subject: Re: [Ieprep] Security Requirements for SIPPING References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit King, Kimberly S. wrote: > Which security requirements in the document are already offered by SIP and > which ones represent new functionality? > > For example: > > SEC-4 says ETS users may use devises that are not their own. This can be done with existing SIP implementations, but it probably won't work with existing devices, as they don't "export" their challenges. While I'm not aware of any implementations, it is quite easy to layer a one-time password (OTP) scheme on top of SIP Digest. The untrusted device would only be given a secret that's valid once and can't be used for anything else. This requires no extensions to SIP, but a draft describing the mechanism wouldn't hurt. This would be independent of ETS. > > REQ-3 implies the resource priority mechanism is a valid SIP message (this > follows from the definition of what it means to be able to pass through the > SIP/RTP transparent network model) > > May I infer that the features needed to support the signaling for resource > priority will then be a part of the normal feature set for SIP end nodes? I > think the answer is yes. Indeed. Currently, I see no special protocol enhancements that are required to support the security needs of ETS. Operationally, systems may require stronger measures than they might for ordinary calls. As noted, making any detailed recommendations is beyond the scope of a protocol requirements draft, although pointing out the particular vulnerabilities seems harmless. > SEC-9 added hop-by-hop encryption was needed to protect fields like 'to' or > 'via'. > > Assume that features needed to support the signaling for resource priority > will then be a part of the normal feature set for SIP end nodes along with > the security requirements. Does this imply that the behavior for UAs would > need to be modified to say they MUST be capable of initiating TLS? No, this is not necessary. A user can already insist on an encrypted signaling session by using the RFC 3261 sips: URI scheme. If the terminal (UA) does not support this, the caller trying to place an ETS call then has to make a judgement call and accept reduced signaling confidentiality or forego making the call. > > My questions center around "what security requirements represents something > SIP, SIP proxies, SIP end nodes, etc. don't already support"? I hope the above clarifies this issue. As with other protocols, SIP security is a continuum, not a "is insecure/is secure" binary choice. I suspect the largest security threat in practice may well be people losing their GETS cards while going through airport screening... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 17:33:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10744 for ; Fri, 18 Oct 2002 17:33:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ILYxJ12116 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 17:34:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ILYxv12113 for ; Fri, 18 Oct 2002 17:34:59 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10736 for ; Fri, 18 Oct 2002 17:32:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ILYAv12095; Fri, 18 Oct 2002 17:34:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ILXSv12080 for ; Fri, 18 Oct 2002 17:33:28 -0400 Received: from smtp1.extremenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10702 for ; Fri, 18 Oct 2002 17:31:09 -0400 (EDT) Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id D46B57A0A; Fri, 18 Oct 2002 14:33:17 -0700 (PDT) Date: Fri, 18 Oct 2002 17:33:21 -0400 Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Janet.Gunn@dyncorp.com, ieprep@ietf.org To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <170.15c0b780.2ae17559@aol.com> Message-Id: <39734B12-E2E1-11D6-8537-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Oct 18, 2002, at 10:31 America/Montreal, Mpierce1@aol.com wrote: > "If a priority value is intended to get better service, e.g., higher > call setup probability, it must not be provided a worse service than > lower priority calls no matter what the traffic situation is." This is roughly impossible to guarantee in a large production IP network. This might mean that folks really want to use the PSTN instead. Trying to mandate the above in these requirements would tend to mean that few (if any) ISPs would agree to contract to provide the IEprep service. That outcome seems to be counter-productive. So I oppose the above proposal. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 18 19:49:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12744 for ; Fri, 18 Oct 2002 19:49:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9INpn218396 for ieprep-archive@odin.ietf.org; Fri, 18 Oct 2002 19:51:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INpnv18393 for ; Fri, 18 Oct 2002 19:51:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12741 for ; Fri, 18 Oct 2002 19:49:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INp5v18377; Fri, 18 Oct 2002 19:51:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INoFv18353 for ; Fri, 18 Oct 2002 19:50:15 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12720 for ; Fri, 18 Oct 2002 19:47:53 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 19:48:15 -0400 Message-ID: From: "Gunn, Janet" To: "'Mpierce1@aol.com'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 Date: Fri, 18 Oct 2002 19:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27700.CDC0B8A0" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27700.CDC0B8A0 Content-Type: text/plain; charset="iso-8859-1" There are systems (existing or under development) in the Circuit Switched world which behave as I described. In some contexts, without such constraints, carriers are reluctant to offer priority service at all. I would oppose the suggested requirement as "shooting ourselves in the foot." -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, October 18, 2002 10:32 AM To: Gunn, Janet Cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 In a message dated 10/17/2002 4:25:14 PM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes: Addressing just the first part- In my mind the independence of indication and policy does not in any way inhibit me from naming my indications "low, medium, high". But, at the same time, it does not PREVENT me from implementing a policy under which (at least under some circumstances), calls labeled "low" get better performance than calls labeled "high". (An example would be that calls labeled "high" get priority as long as the volume of "high priority calls" remains below a threshold. Once the volume crosses that threshold, they get worse treatment.) [MAP] Certainly, the treatment provided in any network element is subject to local control, but I would find it hard to believe that any customer of a priority service would accept a performance as you've described above, presuming that, by the last phrase, you meant "they get worse treatment than the lower priority calls". I certainly hope that we can figure out how to do better than that. I guess this would prompt me to suggest the following additional requirement if and when we start talking about requirements for treatments or procedures: "If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is." Mike Pierce Artel ------_=_NextPart_001_01C27700.CDC0B8A0 Content-Type: text/html; charset="iso-8859-1"
There are systems (existing or under development) in the Circuit Switched world which behave as I described.  In some contexts, without such constraints, carriers are reluctant to offer priority service at all.  I would oppose the suggested requirement as "shooting ourselves in the foot."
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Friday, October 18, 2002 10:32 AM
To: Gunn, Janet
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

In a message dated 10/17/2002 4:25:14 PM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes:


Addressing just the first part-

In my mind the independence of  indication and policy does not in any way
inhibit me from naming my indications "low, medium, high".  But, at the same
time, it does not PREVENT me from implementing a policy under which (at
least under some circumstances), calls labeled "low" get better performance
than calls labeled "high".  

(An example would be that calls labeled "high" get priority as long as the
volume of "high priority calls" remains below a threshold.  Once the volume
crosses that threshold, they get worse treatment.)



[MAP] Certainly, the treatment provided in any network element is subject to local control, but I would find it hard to believe that any customer of a priority service would accept a performance as you've described above, presuming that, by the last phrase, you meant "they get worse treatment than the lower priority calls". I certainly hope that we can figure out how to do better than that. I guess this would prompt me to suggest the following additional requirement if and when we start talking about requirements for treatments or procedures:

"If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is."

Mike Pierce
Artel
------_=_NextPart_001_01C27700.CDC0B8A0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sun Oct 20 18:36:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03891 for ; Sun, 20 Oct 2002 18:36:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9KMchO13782 for ieprep-archive@odin.ietf.org; Sun, 20 Oct 2002 18:38:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KMchv13779 for ; Sun, 20 Oct 2002 18:38:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03878 for ; Sun, 20 Oct 2002 18:36:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KMbLv13670; Sun, 20 Oct 2002 18:37:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KMavv13187 for ; Sun, 20 Oct 2002 18:36:57 -0400 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03873 for ; Sun, 20 Oct 2002 18:34:36 -0400 (EDT) Received: from cs.columbia.edu ([12.85.1.119]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021020223650.TZYR20156.mtiwmhc11.worldnet.att.net@cs.columbia.edu>; Sun, 20 Oct 2002 22:36:50 +0000 Message-ID: <3DB32F96.908@cs.columbia.edu> Date: Sun, 20 Oct 2002 18:35:02 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: KIMBERLY.S.KING@saic.com, ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 References: <124.1845387e.2ad86993@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since the requirement document doesn't specifically call for header fields and we were asked to avoid pre-supposing a particular SIP solution, I'd rather not call out the actual protocol details (header) at this time. (This isn't completely disingenuous. There are, after all, several possible SIP indications, such as a special new SIP method, a sip: or tel: URI parameter, a SIP header, a special SIP payload or some yet-to-be-specified out-of-band mechanism. Whether all of them make sense is a SIP WG discussion to be had, based on these requirements.) > [MAP] It's become clear to me, with the ongoing discussion under "Policy > and labels", that this requirement REQ-7, as currently written, could be > misinterpreted by some in the future, and may itself become a hinderance > to making progress. > > I would suggest that it be rephrased to refer to SIP specific > terminology and be very explicit about what the requirement is. > Otherwise, this requirement should be deleted. I would suggest the > following: > > REQ-7: Separation of indication and policy. The choice of Header Field > Values to indicate priority levels should not in themselves describe a > particular detailed treatment, as it is likely that this depends on the > nature of the resource and local policy. Instead, it should indicate a > particular named policy. As an example, instead of specifying a Header > Field Value of "Queue, no preemption, limit to 3 minutes", the request > should indicate a Value of "High priority", while the local policy in > some or all devices is to provide such treatment to "High Priority" calls. > > Mike Pierce > Artel _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sun Oct 20 20:44:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05443 for ; Sun, 20 Oct 2002 20:44:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9L0kH718639 for ieprep-archive@odin.ietf.org; Sun, 20 Oct 2002 20:46:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L0kHv18636 for ; Sun, 20 Oct 2002 20:46:17 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05440 for ; Sun, 20 Oct 2002 20:43:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L0jPv18619; Sun, 20 Oct 2002 20:45:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L0idv18599 for ; Sun, 20 Oct 2002 20:44:39 -0400 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05413 for ; Sun, 20 Oct 2002 20:42:16 -0400 (EDT) Received: from cs.columbia.edu ([12.85.5.174]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021021004418.JBFX4213.mtiwmhc12.worldnet.att.net@cs.columbia.edu> for ; Mon, 21 Oct 2002 00:44:18 +0000 Message-ID: <3DB34D83.3000304@cs.columbia.edu> Date: Sun, 20 Oct 2002 20:42:43 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ieprep@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ieprep] sip-reqs-01 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I plan to submit http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-ieprep-sip-reqs-01.txt to the I-D editor tomorrow afternoon. Please let me know if any of your suggestions were not properly incorporated or if you find other last-minute problems. Thanks. Henning _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 21 15:18:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11830 for ; Mon, 21 Oct 2002 15:18:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LJJuM17183 for ieprep-archive@odin.ietf.org; Mon, 21 Oct 2002 15:19:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJJuv17180 for ; Mon, 21 Oct 2002 15:19:56 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11754 for ; Mon, 21 Oct 2002 15:17:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJIvv17002; Mon, 21 Oct 2002 15:18:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJ8lv16577 for ; Mon, 21 Oct 2002 15:08:47 -0400 Received: from bootstrap.agcs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11053 for ; Mon, 21 Oct 2002 15:06:26 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id MAA13794 for ; Mon, 21 Oct 2002 12:08:40 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id H4CIIG00.35C for ; Mon, 21 Oct 2002 12:08:40 -0700 Received: FROM agcs.com BY mkultra ; Mon Oct 21 12:08:38 2002 -0700 Message-ID: <3DB450B6.4E0028E5@agcs.com> Date: Mon, 21 Oct 2002 12:08:38 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: ieprep@ietf.org Subject: Re: [Ieprep] sip-reqs-01 X-Priority: 2 (High) References: <3DB34D83.3000304@cs.columbia.edu> Content-Type: multipart/mixed; boundary="------------088F3F6E15FEE30B427F92B6" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------088F3F6E15FEE30B427F92B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henning, In reading the document I noticed in Section 3, SIP proxy resources: ..." Responses should naturally receive the same treatment as responses." Is this what was intended or should the text read "Responses should naturally receive the same treatment as requests." ? Henning Schulzrinne wrote: > I plan to submit > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-ieprep-sip-reqs-01.txt > to the I-D editor tomorrow afternoon. Please let me know if any of your > suggestions were not properly incorporated or if you find other > last-minute problems. > > Thanks. > > Henning > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------088F3F6E15FEE30B427F92B6 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org:AG Communication Systems adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;-12184 fn:Stuart Goldman end:vcard --------------088F3F6E15FEE30B427F92B6-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 21 15:18:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11944 for ; Mon, 21 Oct 2002 15:18:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LJKmC17430 for ieprep-archive@odin.ietf.org; Mon, 21 Oct 2002 15:20:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJKlv17427 for ; Mon, 21 Oct 2002 15:20:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11867 for ; Mon, 21 Oct 2002 15:18:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJJjv17160; Mon, 21 Oct 2002 15:19:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJFSv16859 for ; Mon, 21 Oct 2002 15:15:28 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11503 for ; Mon, 21 Oct 2002 15:13:07 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9LJFKm6010789; Mon, 21 Oct 2002 15:15:20 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9LJFI5T007210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Oct 2002 15:15:19 -0400 (EDT) Message-ID: <3DB452A8.4030907@cs.columbia.edu> Date: Mon, 21 Oct 2002 15:16:56 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: goldmans@agcs.com CC: ieprep@ietf.org Subject: Re: [Ieprep] sip-reqs-01 References: <3DB34D83.3000304@cs.columbia.edu> <3DB450B6.4E0028E5@agcs.com> In-Reply-To: <3DB34D83.3000304@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oops, yes. Not sure whether it'll make it into -01 or not. Stuart (Stu) Goldman wrote: > Henning, > > In reading the document I noticed in Section 3, SIP proxy resources: > > ..." Responses should naturally receive the same treatment as > responses." Is > this what was intended or should the text read "Responses should naturally > receive the same treatment as requests." ? > > Henning Schulzrinne wrote: > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Oct 22 07:43:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12466 for ; Tue, 22 Oct 2002 07:43:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MBj4V08083 for ieprep-archive@odin.ietf.org; Tue, 22 Oct 2002 07:45:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MBj4v08080 for ; Tue, 22 Oct 2002 07:45:04 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12461 for ; Tue, 22 Oct 2002 07:42:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MBhqv08044; Tue, 22 Oct 2002 07:43:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MBghv07990 for ; Tue, 22 Oct 2002 07:42:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12128; Tue, 22 Oct 2002 07:40:26 -0400 (EDT) Message-Id: <200210221140.HAA12128@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 22 Oct 2002 07:40:25 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-sip-reqs-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart 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 : Requirements for Resource Priority Mechanisms for the Session Initiation Protocol Author(s) : H. Schulzrinne Filename : draft-ietf-ieprep-sip-reqs-01.txt Pages : 16 Date : 2002-10-21 This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-01.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-sip-reqs-01.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-sip-reqs-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-21143254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-sip-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-sip-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143254.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 23 02:51:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10059 for ; Wed, 23 Oct 2002 02:51:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9N6r8V09779 for ieprep-archive@odin.ietf.org; Wed, 23 Oct 2002 02:53:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N6r7v09776 for ; Wed, 23 Oct 2002 02:53:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10056 for ; Wed, 23 Oct 2002 02:50:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N6l6v09625; Wed, 23 Oct 2002 02:47:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N6jYv09573 for ; Wed, 23 Oct 2002 02:45:34 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10031 for ; Wed, 23 Oct 2002 02:43:07 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9N6jMot013530; Tue, 22 Oct 2002 23:45:22 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AAM25443; Tue, 22 Oct 2002 23:45:47 -0700 (PDT) From: "Cullen Jennings" To: , , Cc: Date: Tue, 22 Oct 2002 23:45:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Ieprep] draft-polk-dhcp-loc-insertion-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Glad to see a draft like this. If Ieprep is the wrong list to post comments on, please accept my apologies. Few clarification: What datum are you using (I suggest WGS 84) - keep in mind NAD 27 can differ from WGS 84 by 200 meters - which is real big deal for E911. UTM coordinates are widely used and include a built in way of describing the accuracy of the measurement. Perhaps they should be considered. Is the ground floor 0 or 1? Same for NA and Europe? In the Lat/Lon, what is the worst error if all the bits are used. Would be sort of nice to know. The fractional bits seem like they might need a bit more info to define how they are computed. Should you mention byte order issues? Thanks, Cullen _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 23 08:59:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16916 for ; Wed, 23 Oct 2002 08:59:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ND1Dl27786 for ieprep-archive@odin.ietf.org; Wed, 23 Oct 2002 09:01:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ND1Dv27783 for ; Wed, 23 Oct 2002 09:01:13 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16888 for ; Wed, 23 Oct 2002 08:58:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ND0Fv27738; Wed, 23 Oct 2002 09:00:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NCxUv27643 for ; Wed, 23 Oct 2002 08:59:30 -0400 Received: from imo-r09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16849 for ; Wed, 23 Oct 2002 08:57:11 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r09.mx.aol.com (mail_out_v34.13.) id j.19b.a9534ea (4328); Wed, 23 Oct 2002 08:59:21 -0400 (EDT) Message-ID: <19b.a9534ea.2ae7f729@aol.com> Date: Wed, 23 Oct 2002 08:59:21 EDT Subject: Re: [Ieprep] IEPREP requirements for accounting To: rja@extremenetworks.com CC: IEPREP@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_19b.a9534ea.2ae7f729_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_19b.a9534ea.2ae7f729_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/15/2002 4:44:29 PM W. Europe Daylight Time, rja@extremenetworks.com writes: > I do not believe this is a legitimate requirement to place on service > providers. > > As long as the service provider has enough capacity to handle both > legitimate > and non-legitimate calls, there is no functional need for the service > provider > to detect or account for the non-legitimate uses/users. This is a business > tradeoff > between call capacity costs and accounting/detection costs. Different > service > providers might legitimately make different decisions for that tradeoff > based on > differing cost structures. > [MAP] Whether or not the service provider needs or wants to keep detailed call records is independent of whether or not they have "enough capacity". Besides, the whole subject here in IEPREP is for the case in which there is not enough capacity. So there is no "business tradeoff". I am proposing that Accounting is a requirement for a very large service provider/network operator (US Defense Department). It is not proper to say that it is not a legitimate requirement to place on such a service provider. It is the service provider itself that demands this capability. My comment is that the IETF must take this functionality into account in the development of any protocol, not that every service provider must support it. For the GETS case, which we are attempted to "convert" to the IP environment - if the US government says they need detailed call records, and they contract with the service provider to provide them, and they are willing to pay the additional cost associated with doing it, you can't say that it is not a legitimate requirement. Yes, it is up to the service provider if they want to do business with the government, but the standard needs to define how they must do it to comply. Mike Pierce Artel --part1_19b.a9534ea.2ae7f729_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/15/2002 4:44:29 PM W. Europe Daylight Time, rja@extremenetworks.com writes:


I do not believe this is a legitimate requirement to place on service providers.

As long as the service provider has enough capacity to handle both legitimate
and non-legitimate calls, there is no functional need for the service provider
to detect or account for the non-legitimate uses/users.  This is a business tradeoff
between call capacity costs and accounting/detection costs.  Different service
providers might legitimately make different decisions for that tradeoff based on
differing cost structures.


[MAP] Whether or not the service provider needs or wants to keep detailed call records is independent of whether or not they have "enough capacity". Besides, the whole subject here in IEPREP is for the case in which there is not enough capacity. So there is no "business tradeoff".

I am proposing that Accounting is a requirement for a very large service provider/network operator (US Defense Department). It is not proper to say that it is not a legitimate requirement to place on such a service provider. It is the service provider itself that demands this capability. My comment is that the IETF must take this functionality into account in the development of any protocol, not that every service provider must support it.

For the GETS case, which we are attempted to "convert" to the IP environment - if the US government says they need detailed call records, and they contract with the service provider to provide them, and they are willing to pay the additional cost associated with doing it, you can't say that it is not a legitimate requirement. Yes, it is up to the service provider if they want to do business with the government, but the standard needs to define how they must do it to comply.

Mike Pierce
Artel

--part1_19b.a9534ea.2ae7f729_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 23 09:00:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17224 for ; Wed, 23 Oct 2002 09:00:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ND2gb27832 for ieprep-archive@odin.ietf.org; Wed, 23 Oct 2002 09:02:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ND2gv27829 for ; Wed, 23 Oct 2002 09:02:42 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17134 for ; Wed, 23 Oct 2002 09:00:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ND23v27816; Wed, 23 Oct 2002 09:02:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ND1Av27779 for ; Wed, 23 Oct 2002 09:01:10 -0400 Received: from imo-m09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16885 for ; Wed, 23 Oct 2002 08:58:51 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m09.mx.aol.com (mail_out_v34.13.) id r.33.2f12547b (4328); Wed, 23 Oct 2002 09:01:00 -0400 (EDT) Message-ID: <33.2f12547b.2ae7f78b@aol.com> Date: Wed, 23 Oct 2002 09:00:59 EDT Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 To: Janet.Gunn@DynCorp.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_33.2f12547b.2ae7f78b_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_33.2f12547b.2ae7f78b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/19/2002 1:50:29 AM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes: > There are systems (existing or under development) in the Circuit Switched > world which behave as I described. In some contexts, without such > constraints, carriers are reluctant to offer priority service at all. I > would oppose the suggested requirement as "shooting ourselves in the foot." > [MAP] I'm surprised by the responses to my suggestion that there should be requirement that: "If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is." If I had suggested that the priority call must always get better service no matter what the traffic situation, I could understand the objection, but I proposed "not worse", i.e., "the same as" if a network can't do better. An architecture or solution which reserves a certain amount of bandwidth (or circuits) for the high priority traffic, and doesn't let high priority traffic overflow to fairly use the other bandwidth (or circuits) should not be acceptable. I don't know what the situation is with WPS. I suspect the limitations there have something to do with the radio interface bandwidth limit and allocation method. Even there, I would think that the excess WPS traffic would get equal treatment with non-WPS traffic. Why (and how) would any carrier object to that? Mike Pierce Artel --part1_33.2f12547b.2ae7f78b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/19/2002 1:50:29 AM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes:


There are systems (existing or under development) in the Circuit Switched world which behave as I described.  In some contexts, without such constraints, carriers are reluctant to offer priority service at all.  I would oppose the suggested requirement as "shooting ourselves in the foot."




[MAP] I'm surprised by the responses to my suggestion that there should be requirement that:

"If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is."

If I had suggested that the priority call must always get better service no matter what the traffic situation, I could understand the objection, but I proposed "not worse", i.e., "the same as" if a network can't do better. An architecture or solution which reserves a certain amount of bandwidth (or circuits) for the high priority traffic, and doesn't let high priority traffic overflow to fairly use the other bandwidth (or circuits) should not be acceptable.

I don't know what the situation is with WPS. I suspect the limitations there have something to do with the radio interface bandwidth limit and allocation method. Even there, I would think that the excess WPS traffic would get equal treatment with non-WPS traffic. Why (and how) would any carrier object to that?

Mike Pierce
Artel




--part1_33.2f12547b.2ae7f78b_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 23 09:21:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21321 for ; Wed, 23 Oct 2002 09:21:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9NDMwl29239 for ieprep-archive@odin.ietf.org; Wed, 23 Oct 2002 09:22:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NDMwv29236 for ; Wed, 23 Oct 2002 09:22:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21230 for ; Wed, 23 Oct 2002 09:20:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NDMKv29180; Wed, 23 Oct 2002 09:22:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NDLRv29127 for ; Wed, 23 Oct 2002 09:21:27 -0400 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20931 for ; Wed, 23 Oct 2002 09:19:07 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9NDLLm6029702; Wed, 23 Oct 2002 09:21:21 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9NDKg4l017128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Oct 2002 09:21:10 -0400 (EDT) Message-ID: <3DB6A283.4090605@cs.columbia.edu> Date: Wed, 23 Oct 2002 09:22:11 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: rja@extremenetworks.com, IEPREP@ietf.org Subject: Re: [Ieprep] IEPREP requirements for accounting References: <19b.a9534ea.2ae7f729@aol.com> In-Reply-To: <19b.a9534ea.2ae7f729@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It is not clear to me that this is a problem the IEPREP working group can solve, realistically. There are probably at least three sub-problems hiding behind the 'accounting' label: (1) an overall architecture - who needs to deliver what data to whom with what timeliness and assurance; (2) what protocols should be used in the transport of such data; (3) the precise data formats for off-line or near-real-time exchange. Clearly, there is very little agreement on (1), with advocates of web-services approaches, RADIUS, DIAMETER, "just ship tapes" and who knows what other architectures all having valid arguments. I doubt that IEPREP will have any more success than earlier efforts in picking a winner here, even assuming that it should. (2) is mostly solved (within the IETF), with DIAMETER, but issues of how non-NAS applications use DIAMETER are still pending (see the various AAA-for-SIP drafts, say). (3) See IPDR.org. There are a number of on-going efforts in the SIPPING WG to define AAA requirements for SIP sessions, as well as obviously the more general on-going AAA work (DIAMETER WG). Unless there is a clear perception that IEPREP requirements differ in some fundamental way from these requirements, I wonder what value IEPREP can add to the discussion. I believe the one useful contribution would be to highlight any major additional requirements that IEPREP-style services impose on accounting, regardless of the lower-level details, compared to ordinary commercial service. To be useful, this has to be more specific than variations on "IEPREP calls are more important, so accounting is more important" or general statements that accounting should be correct, trustable and all the other non-Enron properties. > > For the GETS case, which we are attempted to "convert" to the IP > environment - if the US government says they need detailed call records, > and they contract with the service provider to provide them, and they > are willing to pay the additional cost associated with doing it, you > can't say that it is not a legitimate requirement. Yes, it is up to the > service provider if they want to do business with the government, but > the standard needs to define how they must do it to comply. > > Mike Pierce > Artel > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 23 11:08:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12158 for ; Wed, 23 Oct 2002 11:08:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9NFAlW03614 for ieprep-archive@odin.ietf.org; Wed, 23 Oct 2002 11:10:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NFAlv03611 for ; Wed, 23 Oct 2002 11:10:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12050 for ; Wed, 23 Oct 2002 11:08:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NF9Jv03443; Wed, 23 Oct 2002 11:09:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NF8Uv03340 for ; Wed, 23 Oct 2002 11:08:30 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11599 for ; Wed, 23 Oct 2002 11:06:09 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Oct 2002 11:06:29 -0400 Message-ID: From: "Gunn, Janet" To: "'Mpierce1@aol.com'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10 Date: Wed, 23 Oct 2002 11:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27AA5.BE042390" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27AA5.BE042390 Content-Type: text/plain; charset="iso-8859-1" WHY the carriers object- because it puts the carriers which offer the priority service at a marketing disadvantage (wrt customers not entitled to the priority service) with carriers not offering the priority service. (While an approach COULD be devised which met your proposed requirement and the carriers quantitative concerns, the development cost would have been much higher, and it still might not have overcome the marketing "perception.") HOW the carriers object - by simply not submitting a bid to offer the priority service at all. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, October 23, 2002 9:01 AM To: Gunn, Janet Cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10 In a message dated 10/19/2002 1:50:29 AM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes: There are systems (existing or under development) in the Circuit Switched world which behave as I described. In some contexts, without such constraints, carriers are reluctant to offer priority service at all. I would oppose the suggested requirement as "shooting ourselves in the foot." [MAP] I'm surprised by the responses to my suggestion that there should be requirement that: "If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is." If I had suggested that the priority call must always get better service no matter what the traffic situation, I could understand the objection, but I proposed "not worse", i.e., "the same as" if a network can't do better. An architecture or solution which reserves a certain amount of bandwidth (or circuits) for the high priority traffic, and doesn't let high priority traffic overflow to fairly use the other bandwidth (or circuits) should not be acceptable. I don't know what the situation is with WPS. I suspect the limitations there have something to do with the radio interface bandwidth limit and allocation method. Even there, I would think that the excess WPS traffic would get equal treatment with non-WPS traffic. Why (and how) would any carrier object to that? Mike Pierce Artel ------_=_NextPart_001_01C27AA5.BE042390 Content-Type: text/html; charset="iso-8859-1"
WHY the carriers object- because it puts the carriers which offer the priority service at a marketing disadvantage (wrt customers not entitled to the priority service) with carriers not offering the priority service. (While an approach COULD be devised which met your proposed requirement and the carriers quantitative concerns, the development cost would have been much higher, and it still might not have overcome the marketing "perception.")
 
HOW the carriers object - by simply not submitting a bid to offer the priority service at all.
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, October 23, 2002 9:01 AM
To: Gunn, Janet
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

In a message dated 10/19/2002 1:50:29 AM W. Europe Daylight Time, Janet.Gunn@DynCorp.com writes:


There are systems (existing or under development) in the Circuit Switched world which behave as I described.  In some contexts, without such constraints, carriers are reluctant to offer priority service at all.  I would oppose the suggested requirement as "shooting ourselves in the foot."




[MAP] I'm surprised by the responses to my suggestion that there should be requirement that:

"If a priority value is intended to get better service, e.g., higher call setup probability, it must not be provided a worse service than lower priority calls no matter what the traffic situation is."

If I had suggested that the priority call must always get better service no matter what the traffic situation, I could understand the objection, but I proposed "not worse", i.e., "the same as" if a network can't do better. An architecture or solution which reserves a certain amount of bandwidth (or circuits) for the high priority traffic, and doesn't let high priority traffic overflow to fairly use the other bandwidth (or circuits) should not be acceptable.

I don't know what the situation is with WPS. I suspect the limitations there have something to do with the radio interface bandwidth limit and allocation method. Even there, I would think that the excess WPS traffic would get equal treatment with non-WPS traffic. Why (and how) would any carrier object to that?

Mike Pierce
Artel




------_=_NextPart_001_01C27AA5.BE042390-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 05:13:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00064 for ; Thu, 24 Oct 2002 05:13:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9O9FEo02902 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 05:15:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O9FEv02899 for ; Thu, 24 Oct 2002 05:15:14 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00059 for ; Thu, 24 Oct 2002 05:12:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O9Dnv02844; Thu, 24 Oct 2002 05:13:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O9C6v02796 for ; Thu, 24 Oct 2002 05:12:06 -0400 Received: from smtp1.extremenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29999 for ; Thu, 24 Oct 2002 05:09:43 -0400 (EDT) Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 3C4977A0F; Thu, 24 Oct 2002 02:11:58 -0700 (PDT) Date: Thu, 24 Oct 2002 05:11:59 -0400 Subject: Re: [Ieprep] IEPREP requirements for accounting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: IEPREP@ietf.org To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <19b.a9534ea.2ae7f729@aol.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Oct 23, 2002, at 08:59 America/Montreal, Mpierce1@aol.com wrote: > Besides, the whole subject here in IEPREP is for the case in which > there is not enough capacity. This is not my understanding from either the current drafts or from the WG Charter. Perhaps Scott could clarify this further with respect to the WG Charter ? With respect to drafts, if the above is the authors' intent then such needs to be made MUCH MUCH more clear. > I am proposing that Accounting is a requirement for a very large > service provider/network operator (US Defense Department). It is not > proper to say that it is not a legitimate requirement to place on such > a service provider. It is the service provider itself that demands > this capability. My comment is that the IETF must take this > functionality into account in the development of any protocol, not > that every service provider must support it. It MUST NOT be a requirement levied on other carriers (e.g. commercial firms that choose to offer an IEprep service on a contractual basis). If DoD does require this (and your lack of identification of affiliation begs the question of whether you speak officially on the record for the entire DoD), then I believe what you want is more like these words (no doubt some editing required since I'm writing in haste). The IEprep Architecture should not preclude an operator from performing accounting if that operator chooses to do so, though there is no IEprep requirement that an operator deploy an ability to perform accounting or actually perform such accounting. From conversations with DoD employees close to the DISN, which people actually are the operators of the DISA IP networks, I do not hear that they have any such requirement. From conversations with USAF/USN/USA employees close to their service-specific networks, I also do not hear that they have any such requirement. If DISA/NCS has such a US-specific requirement, it needs to be resolved contractually (by paying money and finding agreeable commercial vendors) rather than by slipping an unfunded mandate into a global IETF standard. > For the GETS case, which we are attempted to "convert" to the IP > environment - if the US government says they need detailed call > records, and they contract with the service provider to provide them, > and they are willing to pay the additional cost associated with doing > it, you can't say that it is not a legitimate requirement. Yes, it is > up to the service provider if they want to do business with the > government, but the standard needs to define how they must do it to > comply. Not at all. Such can and must be defined in contract terms without necessarily being part of the *global* standard. Per-call accounting is NOT a global requirement. Your attempt to insert US-centrism into a global standard is noted and is also very inappropriate behaviour on an IETF list. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 09:47:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07896 for ; Thu, 24 Oct 2002 09:47:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ODn3C17816 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 09:49:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODn3v17813 for ; Thu, 24 Oct 2002 09:49:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07851 for ; Thu, 24 Oct 2002 09:46:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODmDv17713; Thu, 24 Oct 2002 09:48:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODlHv17647 for ; Thu, 24 Oct 2002 09:47:17 -0400 Received: from chntex03.is.dyncorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07682 for ; Thu, 24 Oct 2002 09:44:55 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 09:45:13 -0400 Message-ID: From: "Gunn, Janet" To: "'RJ Atkinson'" , Mpierce1@aol.com Cc: IEPREP@ietf.org Subject: RE: [Ieprep] IEPREP requirements for accounting Date: Thu, 24 Oct 2002 09:45:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Perhaps an other way to put it is that such a requirement MAY be part of the requirements for a PARTICULAR contracted service, but should not be part of the IEPREP requirements- especially not the IEPREP requirements to SIP. HOWEVER, we should be sure that nothing in the general IEPREP requirements precludes, or makes more difficult, such accounting. I don't know that "the whole subject" is for "not enough capacity". But it is certainly most relevant and important when there is not enough capacity. When there is ample capacity, there is generally no need for preferential treatment. But the "not enough capacity" need not be in the IP network, it could be in whatever the IP network interfaces with. -----Original Message----- From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Thursday, October 24, 2002 5:12 AM To: Mpierce1@aol.com Cc: IEPREP@ietf.org Subject: Re: [Ieprep] IEPREP requirements for accounting On Wednesday, Oct 23, 2002, at 08:59 America/Montreal, Mpierce1@aol.com wrote: > Besides, the whole subject here in IEPREP is for the case in which > there is not enough capacity. This is not my understanding from either the current drafts or from the WG Charter. Perhaps Scott could clarify this further with respect to the WG Charter ? With respect to drafts, if the above is the authors' intent then such needs to be made MUCH MUCH more clear. > I am proposing that Accounting is a requirement for a very large > service provider/network operator (US Defense Department). It is not > proper to say that it is not a legitimate requirement to place on such > a service provider. It is the service provider itself that demands > this capability. My comment is that the IETF must take this > functionality into account in the development of any protocol, not > that every service provider must support it. It MUST NOT be a requirement levied on other carriers (e.g. commercial firms that choose to offer an IEprep service on a contractual basis). If DoD does require this (and your lack of identification of affiliation begs the question of whether you speak officially on the record for the entire DoD), then I believe what you want is more like these words (no doubt some editing required since I'm writing in haste). The IEprep Architecture should not preclude an operator from performing accounting if that operator chooses to do so, though there is no IEprep requirement that an operator deploy an ability to perform accounting or actually perform such accounting. From conversations with DoD employees close to the DISN, which people actually are the operators of the DISA IP networks, I do not hear that they have any such requirement. From conversations with USAF/USN/USA employees close to their service-specific networks, I also do not hear that they have any such requirement. If DISA/NCS has such a US-specific requirement, it needs to be resolved contractually (by paying money and finding agreeable commercial vendors) rather than by slipping an unfunded mandate into a global IETF standard. > For the GETS case, which we are attempted to "convert" to the IP > environment - if the US government says they need detailed call > records, and they contract with the service provider to provide them, > and they are willing to pay the additional cost associated with doing > it, you can't say that it is not a legitimate requirement. Yes, it is > up to the service provider if they want to do business with the > government, but the standard needs to define how they must do it to > comply. Not at all. Such can and must be defined in contract terms without necessarily being part of the *global* standard. Per-call accounting is NOT a global requirement. Your attempt to insert US-centrism into a global standard is noted and is also very inappropriate behaviour on an IETF list. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 09:48:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07990 for ; Thu, 24 Oct 2002 09:48:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ODohf17898 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 09:50:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODohv17895 for ; Thu, 24 Oct 2002 09:50:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07966 for ; Thu, 24 Oct 2002 09:48:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODo2v17871; Thu, 24 Oct 2002 09:50:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODnPv17839 for ; Thu, 24 Oct 2002 09:49:25 -0400 Received: from wells.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07880 for ; Thu, 24 Oct 2002 09:47:05 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id GAA19145 for ; Thu, 24 Oct 2002 06:49:21 -0700 (PDT) Message-Id: <4.1.20021024083035.02a8b4d0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 24 Oct 2002 08:49:13 -0500 To: ieprep@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Ieprep] Revised Topologies ID for WG consideration Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , All Here is the pointer to an ID published a little while ago attempting to merely name (with a diagram each) the 4 likely topologies IEPREP should work to. I have removed all requirements and AAA discussion from this ID version. Comments on this Topologies ID are welcome http://www.ietf.org/internet-drafts/draft-polk-ieprep-scenarios-01.txt This ID has (and refers to) an accompanying ID called "Topology Implications" which is not yet published (and might not before the cutoff date Monday). The Implications ID will track open issues the topology discussions cause - as well as the open issues that should be discussed relative to (and maybe a subset of) the topologies, One goal is to hopefully provide a 'how we got here from there' view of some of the WG efforts. Contributions to the Implications ID are *certainly* welcome, as this will live for some time within this WG (until opposed or sent to the IESG). cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 10:09:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08901 for ; Thu, 24 Oct 2002 10:09:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OEBl519492 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 10:11:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OEBlv19489 for ; Thu, 24 Oct 2002 10:11:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08871 for ; Thu, 24 Oct 2002 10:09:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OEB7v19424; Thu, 24 Oct 2002 10:11:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OE9Tv19324 for ; Thu, 24 Oct 2002 10:09:29 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08720 for ; Thu, 24 Oct 2002 10:07:08 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9OE8bnp021710; Thu, 24 Oct 2002 10:08:37 -0400 (EDT) Date: Thu, 24 Oct 2002 10:08:37 -0400 (EDT) From: Scott Bradner Message-Id: <200210241408.g9OE8bnp021710@newdev.harvard.edu> To: Mpierce1@aol.com, rja@extremenetworks.com Subject: Re: [Ieprep] IEPREP requirements for accounting Cc: IEPREP@ietf.org In-Reply-To: Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > > Besides, the whole subject here in IEPREP is for the case in which > > there is not enough capacity. > This is not my understanding from either the current drafts or from the > WG Charter. > Perhaps Scott could clarify this further with respect to the WG Charter this WG does have to think about the case where there is not enough capacity in the IP network on the path that a data stream will use the lack of capacity might be restricted to tail circuits, as might be the general case in US wireline ISPs, or in the infrastructure - the WG should not worry about the case where the IP path spans multiple ISPs but the current deliverable is to say what in this space can be supported using existing IP protocols - it is not to invent new ones Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 15:59:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21359 for ; Thu, 24 Oct 2002 15:59:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OK13c07348 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 16:01:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OK13v07345 for ; Thu, 24 Oct 2002 16:01:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21349 for ; Thu, 24 Oct 2002 15:58:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OJxcv07250; Thu, 24 Oct 2002 15:59:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OJw3v07204 for ; Thu, 24 Oct 2002 15:58:03 -0400 Received: from seahorse.shentel.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21298 for ; Thu, 24 Oct 2002 15:55:40 -0400 (EDT) Received: from stevesilverman (ha30s440.d.shentel.net [204.111.30.184]) by seahorse.shentel.net (8.11.6/8.11.6) with SMTP id g9OJvrM16464; Thu, 24 Oct 2002 15:57:53 -0400 From: "Steve Silverman" To: "RJ Atkinson" , Subject: RE: [Ieprep] IEPREP requirements for accounting Date: Thu, 24 Oct 2002 15:57:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This week there was a large DDoS attack on the DNS system of the Internet. One would think that any system we specified would collect enough information to help stop such attacks. While I do not (unfortunately) own any TELCOs or ISPs, if I did, I wouldn't invest much money on a network that couldn't protect itself. Since one possible attack would involve zombies making emergency phone calls (or any other prioritized call), some sort of tracking info (I would call it accounting info) must be collected by any supporting service provider even if no billing is intended. It probably doesn't pay to charge for emergency calls but that sort of decision is not made by engineers. Steve Silverman > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of > RJ Atkinson > Sent: Thursday, October 24, 2002 5:12 AM > To: Mpierce1@aol.com > Cc: IEPREP@ietf.org > Subject: Re: [Ieprep] IEPREP requirements for accounting > > > ... > > With respect to drafts, if the above is the authors' intent then such > needs > to be made MUCH MUCH more clear. > > > I am proposing that Accounting is a requirement for a very large > > service provider/network operator (US Defense Department). It is not > > proper to say that it is not a legitimate requirement to place on such > > a service provider. It is the service provider itself that demands > > this capability. My comment is that the IETF must take this > > functionality into account in the development of any protocol, not > > that every service provider must support it. > > It MUST NOT be a requirement levied on other carriers (e.g. commercial > firms > that choose to offer an IEprep service on a contractual basis). > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 20:41:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28379 for ; Thu, 24 Oct 2002 20:41:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P0h2s22214 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 20:43:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0h2v22211 for ; Thu, 24 Oct 2002 20:43:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28358 for ; Thu, 24 Oct 2002 20:40:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0gJv22195; Thu, 24 Oct 2002 20:42:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0fSv22160 for ; Thu, 24 Oct 2002 20:41:28 -0400 Received: from smtp1.extremenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28333 for ; Thu, 24 Oct 2002 20:39:01 -0400 (EDT) Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id B64ED7A13; Thu, 24 Oct 2002 17:41:17 -0700 (PDT) Date: Thu, 24 Oct 2002 20:41:18 -0400 Subject: Re: [Ieprep] IEPREP requirements for accounting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: IEPREP@ietf.org To: Scott Bradner From: RJ Atkinson In-Reply-To: <200210241408.g9OE8bnp021710@newdev.harvard.edu> Message-Id: <79BFDFF7-E7B2-11D6-A20D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 24, 2002, at 10:08 America/Montreal, Scott Bradner wrote: > but the current deliverable is to say what in this space can be > supported using existing IP protocols - it is not to invent new ones Current IP protocols generally do not support detailed accounting records as part of the protocols. Some implementations of RADIUS happen to support some level of accounting -- but it isn't part of the RADIUS protocol specification that accounting is required -- to give one example. So, based on Scott's comment above, creating a requirement for detailed accounting seems inappropriate unless a *specific* existing IP protocol can be identified where that IETF protocol specification already requires that accounting support be implemented. If someone has such a specific example, it would be helpful to cite RFC, Section, and page to this list. Regards, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 20:46:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28501 for ; Thu, 24 Oct 2002 20:46:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P0mik22439 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 20:48:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0miv22436 for ; Thu, 24 Oct 2002 20:48:44 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28497 for ; Thu, 24 Oct 2002 20:46:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0m2v22419; Thu, 24 Oct 2002 20:48:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0lIv22390 for ; Thu, 24 Oct 2002 20:47:18 -0400 Received: from smtp1.extremenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28472 for ; Thu, 24 Oct 2002 20:44:51 -0400 (EDT) Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id E5F867A13; Thu, 24 Oct 2002 17:47:07 -0700 (PDT) Date: Thu, 24 Oct 2002 20:47:08 -0400 Subject: Re: [Ieprep] IEPREP requirements for accounting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: "Steve Silverman" From: RJ Atkinson In-Reply-To: Message-Id: <4A87BCC4-E7B3-11D6-A20D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 24, 2002, at 15:57 America/Montreal, Steve Silverman wrote: > This week there was a large DDoS attack on the DNS system of the > Internet. > One would think that any system we specified would collect enough > information to help stop such attacks. By the way, adding accounting actually would create a new vulnerability to DDOS attacks, rather than reducing the vulnerability, because it creates a new attack vector without mitigating any existing attack vector. Consider for example the 20+ year old (and widely published, so I'm not revealing any new data here) external attacks on servers by performing minor attacks which cause SYSLOG to fill the disk and then the full disk causes the server to crash. > Since one possible attack would involve zombies > making emergency phone calls (or any other prioritized call), some > sort of > tracking info (I would call it accounting info) must be collected by > any > supporting service provider even if no billing is intended. No. If a Tier-1 operator has more core capacity than theoretical max offered load, then they are fairly immune from traffic-based DDOS attacks (though the downstream Tier-2 ISPs uplink would not necessarily be immune) and so the Tier-1 would not need to do any form of accounting (indeed, doing such accounting might create a vulnerability for them). Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 24 20:53:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28632 for ; Thu, 24 Oct 2002 20:53:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P0ti022581 for ieprep-archive@odin.ietf.org; Thu, 24 Oct 2002 20:55:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0tiv22578 for ; Thu, 24 Oct 2002 20:55:44 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28628 for ; Thu, 24 Oct 2002 20:53:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0t3v22561; Thu, 24 Oct 2002 20:55:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P0sGv22522 for ; Thu, 24 Oct 2002 20:54:16 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28592 for ; Thu, 24 Oct 2002 20:51:49 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9P0rPVk024242; Thu, 24 Oct 2002 20:53:25 -0400 (EDT) Date: Thu, 24 Oct 2002 20:53:25 -0400 (EDT) From: Scott Bradner Message-Id: <200210250053.g9P0rPVk024242@newdev.harvard.edu> To: rja@extremenetworks.com, sob@harvard.edu Subject: Re: [Ieprep] IEPREP requirements for accounting Cc: IEPREP@ietf.org In-Reply-To: <79BFDFF7-E7B2-11D6-A20D-00039357A82A@extremenetworks.com> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > So, based on Scott's comment above, creating a requirement for detailed > accounting > seems inappropriate unless a *specific* existing IP protocol can be > identified I'm sorry but I do not follow that (specifically not commenting on the question about a requirement for accounting) I do not see anything in the charter that restricts this WG to only producing requirements that describe existing IP protocol functions the charter says: In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. if this WG comes to consensus that a "function or technlogy" that does not curremtly exist is needed to support Internet Emergency Preparedness then this group should state the requirement. To do otherwise would be to produce an incomplete document This group is quite specifically not chartered to develop any new functions or technology. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 25 01:20:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03690 for ; Fri, 25 Oct 2002 01:20:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P5Mke02018 for ieprep-archive@odin.ietf.org; Fri, 25 Oct 2002 01:22:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P5Mkv02015 for ; Fri, 25 Oct 2002 01:22:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03674 for ; Fri, 25 Oct 2002 01:20:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P5Lmv01990; Fri, 25 Oct 2002 01:21:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P5KDv01960 for ; Fri, 25 Oct 2002 01:20:13 -0400 Received: from smtp1.extremenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03538 for ; Fri, 25 Oct 2002 01:17:39 -0400 (EDT) Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 5425D7A13; Thu, 24 Oct 2002 22:19:55 -0700 (PDT) Date: Fri, 25 Oct 2002 01:19:56 -0400 Subject: Re: [Ieprep] IEPREP requirements for accounting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: IEPREP@ietf.org To: Scott Bradner From: RJ Atkinson In-Reply-To: <200210250053.g9P0rPVk024242@newdev.harvard.edu> Message-Id: <6623E584-E7D9-11D6-9243-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 24, 2002, at 20:53 America/Montreal, Scott Bradner wrote: > I'm sorry but I do not follow that Then we aren't communicating clearly, so more details help. :-) > (specifically not commenting on the question about a requirement for > accounting) > > I do not see anything in the charter that restricts this WG to > only producing requirements that describe existing IP protocol > functions > > the charter says: > In particular the working group will devlop a Requirements for > Internet > Emergency Preparedness in the Internet RFC which will detail the > specific > functions and technologies needed to provide support for Emergency > Preparedness systems in the Internet. > > if this WG comes to consensus that a "function or technlogy" that > does not curremtly exist is needed to support Internet Emergency > Preparedness then this group should state the requirement. To do > otherwise would be to produce an incomplete document > > This group is quite specifically not chartered to develop any new > functions or technology. OK. So then (as an example) this WG can't tell SIP how to add labels to SIP or any implementation/deployment details, but could say that some form of label is needed that will solve problems X and Y. (Scott, is that right or wrong ?) It would be good if there were a common understanding on the charter question. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Oct 25 07:28:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19977 for ; Fri, 25 Oct 2002 07:28:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PBU8w29331 for ieprep-archive@odin.ietf.org; Fri, 25 Oct 2002 07:30:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBU8v29328 for ; Fri, 25 Oct 2002 07:30:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19870 for ; Fri, 25 Oct 2002 07:27:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBTAv29257; Fri, 25 Oct 2002 07:29:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBS4v29222 for ; Fri, 25 Oct 2002 07:28:04 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19595 for ; Fri, 25 Oct 2002 07:25:44 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9PBQn1l001274; Fri, 25 Oct 2002 07:26:49 -0400 (EDT) Date: Fri, 25 Oct 2002 07:26:49 -0400 (EDT) From: Scott Bradner Message-Id: <200210251126.g9PBQn1l001274@newdev.harvard.edu> To: rja@extremenetworks.com, sob@harvard.edu Subject: Re: [Ieprep] IEPREP requirements for accounting Cc: IEPREP@ietf.org In-Reply-To: <6623E584-E7D9-11D6-9243-00039357A82A@extremenetworks.com> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > OK. So then (as an example) this WG can't tell SIP how to add labels > to SIP > > or any implementation/deployment details, but could say that some form > of label > is needed that will solve problems X and Y. (Scott, is that right or > wrong ?) how about "sorta right" :-) this group can say that there are problems X & Y that need to be solved for ieprep to work with SIP - it can not tell SIPPING (which gets the requirement 1st) that solving the problems means that a new header is needed - i.e., defining how to meet the requirement is not IEPREP's job SIPPING will then take a look at the requirement to see if it: 1/ can be met in some way with SIP as-is that the ieprep did not figure out, even if the solution is not as "efficient" as IEPREP might like 2/ can be combined with other resuirements that SIPPING has received from other WGs or individuals, and can be reworked to make the requirement more general to solve a wider class of problems, (SIPPING might on its own do this w/o the need for specific other requirements being submitted) 3/ does not make sense 4/ deals with too narrow a situation to warrent changing SIP ("you can't always get what you want, but you generally get what you need") 5/ makes sense as-is in case 1 SIPPING responds to ieprep - 'here is how to do it' in case 3 it sends back a "huh?" message in case 4 it sends back a 'no, and here is why' messgae in case 2 & 5 SIPPING sends the requirement on to SIP which then figures out how best to meet the requirement IEPREP can make a suggestion on how to meet the requirement but SIP can reject the suggestion if SIP thinks that the ieprep suggestion is the wrong way to meet the requirement (I do not suggest that IEPREP should spend time coming up with such suggestions) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Oct 28 06:29:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03602 for ; Mon, 28 Oct 2002 06:29:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SBVhR16736 for ieprep-archive@odin.ietf.org; Mon, 28 Oct 2002 06:31:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SBVhv16733 for ; Mon, 28 Oct 2002 06:31:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03564 for ; Mon, 28 Oct 2002 06:29:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SBUVv16678; Mon, 28 Oct 2002 06:30:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SBTbv16625 for ; Mon, 28 Oct 2002 06:29:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03106; Mon, 28 Oct 2002 06:27:14 -0500 (EST) Message-Id: <200210281127.GAA03106@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 28 Oct 2002 06:27:14 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-requirements-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart 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 : Requirements for Emergency Telecommunication Capabilities in the Internet Author(s) : H. Folts, C. Beard, K. Carlberg Filename : draft-ietf-ieprep-requirements-01.txt Pages : 10 Date : 2002-10-25 This document outlines user requirements for IP-based networks to enable and support an authorized emergency telecommunications service (ETS)for use by authorities to organize and coordinate emergency and disaster relief operations. It provides a basis from which ETS can be negotiated to provide user-acceptable communications. The requirements in this document relate to user expectation and are general, functional, and intended to provide wide latitude in implementation options. This document also provides in-depth background on the state of emergency telecommunication capabilities as they exist today and the motivation for supporting these in IP networks. Specific system requirements involving end-to-end and network issues are presented in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-01.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-requirements-01.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-requirements-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-25112639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25112639.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 09:37:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16627 for ; Wed, 30 Oct 2002 09:37:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UEdkW06974 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 09:39:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEdkv06971 for ; Wed, 30 Oct 2002 09:39:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16594 for ; Wed, 30 Oct 2002 09:37:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEa9v06189; Wed, 30 Oct 2002 09:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEZIv06137 for ; Wed, 30 Oct 2002 09:35:18 -0500 Received: from [209.22.88.17] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16366 for ; Wed, 30 Oct 2002 09:32:53 -0500 (EST) Received: from mtassp3.ncr.disa.mil by [209.22.88.17] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 30 Oct 2002 14:30:13 UT Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 09:35:16 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D23A493@emshqs1.ncr.disa.mil> From: "Folts, Harold" To: "Ieprep List (ieprep@ietf.org)" Date: Wed, 30 Oct 2002 09:35:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28021.8E2041F0" Subject: [Ieprep] Basic Requirements ID Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28021.8E2041F0 Content-Type: text/plain I have posted a revised version of the ieprep basic user requirements ID http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-01.txt that serves as the base for more specific requirements documents in the IDs that have been posted by Ken Carlberg and Ran Atkinson http://www.ietf.org/internet-drafts/draft-carlberg-ets-general-00.txt http://www.ietf.org/internet-drafts/draft-carlberg-ets-telephony-00.txt There has been considerable discussion of the requirements document on the list since the formation of the ieprep working group. In addition the 00 version of the ID was discussed in Yokohama and significantly edited with the assistance of Fred Baker and Scott Bradner. Subsequent to Yokohama, further work was done by Ken and Ran. This all has led to the 01 draft. In discussion with Ken and Ran, the following structure of the ieprep requirements series is outlined below. (A) User-Requirements (B) General-System-Requirements (Ken & Ran) ----------------- --------------------------- (Hal, Cory, Ken) | | +--IP Telephony (Ken & Ran) | Requirements | | | +--MLPP (TBD?) | +--Sensor Nets (TBD?) (C) Framework for ETS IP Telephony (Ken & Ian) (D) Best Common Practice (Fred?) I believe that the many comments expressed on the list have been accommodated and that the basic user requirements ID is now ready for progressing as an Informational RFC. Please provide any comments and indication of agreement/disagreement for this ID to be moved forward at Atlanta. Hal ------_=_NextPart_001_01C28021.8E2041F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Basic Requirements ID

I have posted a revised version of the = ieprep basic user requirements ID

http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-= 01.txt

that serves as the base for more = specific requirements documents in the IDs that have been posted by Ken = Carlberg and Ran Atkinson

http://www.ietf.org/internet-drafts/draft-carlberg-ets-general-00.t= xt

http://www.ietf.org/internet-drafts/draft-carlberg-ets-telephony-00= .txt

There has been considerable = discussion of the requirements document on the list since the formation = of the ieprep working group. In addition the 00 version of the ID was = discussed in Yokohama and significantly edited with the assistance of = Fred Baker and Scott Bradner. Subsequent to Yokohama, further work was = done by Ken and Ran. This all has led to the 01 draft. In discussion = with Ken and Ran, the following structure of the ieprep requirements = series is outlined below.

(A) = User-Requirements    (B) General-System-Requirements = (Ken & Ran)
      = -----------------        = ---------------------------
        (Hal, Cory, = Ken)          = |      
           &= nbsp;           &= nbsp;          = |      
           &= nbsp;           &= nbsp;          +--IP = Telephony (Ken & Ran)
           &= nbsp;           &= nbsp;          = |     Requirements
           &= nbsp;           &= nbsp;          = |       |
           &= nbsp;           &= nbsp;          = |       +--MLPP (TBD?)
           &= nbsp;           &= nbsp;          |
           &= nbsp;           &= nbsp;          +--Sensor = Nets (TBD?)

           &= nbsp;  
           &= nbsp;  (C) Framework for ETS IP Telephony (Ken & Ian)
           &= nbsp;  (D) Best Common Practice (Fred?)

I believe that the many comments = expressed on the list have been accommodated and that the basic user = requirements ID is now ready for progressing as an Informational RFC. = Please provide any comments and indication of agreement/disagreement = for this ID to be moved forward at Atlanta.

Hal


------_=_NextPart_001_01C28021.8E2041F0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 17:21:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15982 for ; Wed, 30 Oct 2002 17:21:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UMNo207468 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 17:23:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UMNov07465 for ; Wed, 30 Oct 2002 17:23:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15945 for ; Wed, 30 Oct 2002 17:21:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UMN7v07448; Wed, 30 Oct 2002 17:23:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UMMiv07397 for ; Wed, 30 Oct 2002 17:22:44 -0500 Received: from imo-r02.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15874 for ; Wed, 30 Oct 2002 17:20:14 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v34.13.) id l.15.1306d3e (3940) for ; Wed, 30 Oct 2002 17:22:32 -0500 (EST) Message-ID: <15.1306d3e.2af1b5a8@aol.com> Date: Wed, 30 Oct 2002 17:22:32 EST To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_15.1306d3e.2af1b5a8_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Subject: [Ieprep] New Internet Drafts Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_15.1306d3e.2af1b5a8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, I have submitted the following 3 drafts: Requirements for Assured Service Capabilities in Voice over IP Architecture for Assured Service Capabilities in Voice over IP Examples for Provision of Preferential Treatment in Voice over IP These are revisions of previous drafts submitted to SIPPING. Since their initial submission, the discussion related to the subjects rasied in these drafts has moved to IEPREP. While these mostly deal with "Assured Service", or the intended service to replace "MLPP" in the military network, I believe that many of the concepts discussed are common with "Authorized Emergency" calls which IEPREP has been focusing on. In fact, "MLPP" in a military network is simply another form of "authorized emergency" priority calls. Please note that these drafts are jointly authored by myself (of "Artel") and Don Choi, of DISA, the agency responsible for establishment of standards and policies for the US Defense Network. These drafts can be found at: http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-req-00 .txt http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-arch-0 0.txt http://www.ietf.org/internet-drafts/draft-pierce-ieprep-pref-treat-examples-00 .txt Mike Pierce Artel --part1_15.1306d3e.2af1b5a8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

I have submitted the following 3 drafts:

Requirements for Assured Service Capabilities in Voice over IP
Architecture for Assured Service Capabilities in Voice over IP
Examples for Provision of Preferential Treatment in Voice over IP

These are revisions of previous drafts submitted to SIPPING. Since their initial submission, the discussion related to the subjects rasied in these drafts has moved to IEPREP.

While these mostly deal with "Assured Service", or the intended service to replace "MLPP" in the military network, I believe that many of the concepts discussed are common with "Authorized Emergency" calls which IEPREP has been focusing on. In fact, "MLPP" in a military network is simply another form of "authorized emergency" priority calls.

Please note that these drafts are jointly authored by myself (of "Artel") and Don Choi, of DISA, the agency responsible for establishment of standards and policies for the US Defense Network.

These drafts can be found at:

http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-req-00.txt
http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-arch-00.txt
http://www.ietf.org/internet-drafts/draft-pierce-ieprep-pref-treat-examples-00.txt

Mike Pierce
Artel
--part1_15.1306d3e.2af1b5a8_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 19:34:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20132 for ; Wed, 30 Oct 2002 19:34:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V0a1f14791 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 19:36:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V0a1v14788 for ; Wed, 30 Oct 2002 19:36:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20122 for ; Wed, 30 Oct 2002 19:33:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V0ZGv14771; Wed, 30 Oct 2002 19:35:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V0YZv14748 for ; Wed, 30 Oct 2002 19:34:35 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20081 for ; Wed, 30 Oct 2002 19:32:00 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9V0SXd20883; Wed, 30 Oct 2002 16:28:34 -0800 (PST) Date: Wed, 30 Oct 2002 16:28:33 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org In-Reply-To: <15.1306d3e.2af1b5a8@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > This document outlines user requirements... This does not in fact appear to be the case. In fact, this appears to outline government expectations of service providers and vendors. The market mechanism for fulfillment of government expectations is for the government to purchase what it wants within the market. Not to impersonate the user community. I'd humbly suggest that since the expectations being outlined in this document are extrordinarily expensive ones, it might benefit the expectant party to moderate its expectations somewhat, or suggest how much it's interested in paying, and allow the market to present offerings which meet that price range. Stating overblown expectations in a financial vacuum is feckless. > There are four basic configurations that come > into play during convergence. These include: > o Pure IP telephony, with no link to the PSTN This appears to be largely ignored in the rest of the document. Out in the real world, however, it appears to be a significant portion of the total, however. > We assume the presence of Service Level Agreements Which are a marketing, sales, and collections fiction. If you want to base a standard on a sales practice, the IETF isn't an appropriate place to do it. > sessions should be provided with with a higher probability of > completion over non-emergency communications. We assume the > presence of a service level agreement to accomplish this. Sales fictions do not accomplish operational objectives. However, one might view QoS as an operational instantiation of SLAs, and it's instructive to note that QoS is substantially more fictional than SLAs. Since it doesn't work and wouldn't provide any desired utility even if it did, it's neither used nor desired on any significant networks. Much less on significant production VoIP networks. > Emergency traffic should be able to transit multiple service > providers. The existence of service level agreements determines > the extent by which this can be accomplished. Could have fooled me. I thought network interconnection determined the extent to which traffic could be exchanged. Silly me. I'll go sign a bunch of SLAs. That's got to be easier than actually building a network. > Networks should be able to support a variety of user applications > including telephony, video, database access, messaging, > telemetry, and web browsing to support emergency operations. Uh, am I really reading this in an IETF document? Hello? Networks SHOULD make toast? > Users should have the option protecting certain sensitive traffic > from eavesdropping and the source/destination of some traffic. "Users" REQUIRE that service providers SHOULD give users the option of putting a big pillowcase over their heads before answering the phone? Or shutting their office door before answering the phone? > Users should have the option of requesting degraded quality of > service when normal or expected QoS cannot be achieved. This one is really cute. Brings to mind the Star Trek movie in which Scotty travels back in time and operates a Mac Plus. Users are more than welcome to request degraded quality of service at any time. Please speak loudly into the mouse, before dialing. So,in summary, what we appear to have here is a document which: - pretends to document "user requirements" while not actually representing users; - asks for hugely expensive "features" without suggesting who, or even whether, anyone would be willing to pay for them; - and is based upon the assumption an idiotic sales practice being ubiquitous. Why are we discussing this, again? -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 19:58:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20679 for ; Wed, 30 Oct 2002 19:58:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V10kY16143 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 20:00:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V10kv16140 for ; Wed, 30 Oct 2002 20:00:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20660 for ; Wed, 30 Oct 2002 19:58:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V103v16109; Wed, 30 Oct 2002 20:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V0xHv16064 for ; Wed, 30 Oct 2002 19:59:17 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20631 for ; Wed, 30 Oct 2002 19:56:46 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9V0rKd21253 for ; Wed, 30 Oct 2002 16:53:20 -0800 (PST) Date: Wed, 30 Oct 2002 16:53:20 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > > Users should have the option protecting certain sensitive traffic > > from eavesdropping and the source/destination of some traffic. > > "Users" REQUIRE that service providers SHOULD give users the option of > putting a big pillowcase over their heads before answering the phone? Sorry, read that as "eavesdropping AT the source/destination". So I'll change my critique to simply pointing out that this is why IPSec exists, so the obvious doesn't need to be reiterated in this document. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 20:06:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20814 for ; Wed, 30 Oct 2002 20:06:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V18kp16990 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 20:08:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V18kv16987 for ; Wed, 30 Oct 2002 20:08:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20802 for ; Wed, 30 Oct 2002 20:06:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V131v16242; Wed, 30 Oct 2002 20:03:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V12lv16218 for ; Wed, 30 Oct 2002 20:02:47 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20705 for ; Wed, 30 Oct 2002 20:00:15 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 8918C67103 for ; Wed, 30 Oct 2002 16:22:12 -0500 (EST) Date: Wed, 30 Oct 2002 20:02:38 -0500 Subject: Re: [Ieprep] I-Ds on Assured Service Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <15.1306d3e.2af1b5a8@aol.com> Message-Id: <72E3C1BA-EC6C-11D6-A53C-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 17:22 America/Montreal, Mpierce1@aol.com wrote: > Please note that these drafts are jointly authored by myself (of > "Artel") and Don Choi, of DISA, the agency responsible for > establishment of standards and policies for the US Defense Network. I'd be very interested to see the folks who actually run the DISN [1] comment here about the deployability of this proposal inside their current operational IP networks. I'm reliably told DISA aren't using DiffServ today in their production IP WANs. For that matter, I'd be interested in feedback from anyone here with hands-on operational experience with a large-scale DiffServ deployment in a production (i.e. not research) IP network. Right now, I'm not familiar with any large-scale deployment of DiffServ in a production IP network, though I know of several small deployments or research projects that have used DiffServ in one way or another. Lack of operational experience with any technology being required in widescale deployment always makes me nervous.[3] Regards, Ran rja@extremenetworks.com [1] DISN is their jargon for the part of DISA that runs their IP networks. At DISA, the folks who work on policy/standards are largely separate from the folks who actually engineer/operate the {N,S}IPRnet and the other more highly classified IP networks. [2] Disclaimer: My employer IP makes routers that implement DiffServ. While this doesn't affect my views, full disclosure is always best in these situations. [3] This is why I also dislike most proposed "enhancements" to (M)BGP4, to give an unrelated example. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 21:37:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23185 for ; Wed, 30 Oct 2002 21:37:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V2d1C21441 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 21:39:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V2d0v21438 for ; Wed, 30 Oct 2002 21:39:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23179 for ; Wed, 30 Oct 2002 21:36:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V2cFv21423; Wed, 30 Oct 2002 21:38:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V2bbv21393 for ; Wed, 30 Oct 2002 21:37:37 -0500 Received: from seahorse.shentel.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23049 for ; Wed, 30 Oct 2002 21:35:06 -0500 (EST) Received: from stevesilverman (ha24s502.d.shentel.net [204.111.29.246]) by seahorse.shentel.net (8.11.6/8.11.6) with SMTP id g9V2bKM03228; Wed, 30 Oct 2002 21:37:20 -0500 From: "Steve Silverman" To: "Bill Woodcock" , Subject: RE: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Date: Wed, 30 Oct 2002 21:37:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > This document outlines user requirements... > > This does not in fact appear to be the case. In fact, this appears to > outline government expectations of service providers and vendors. > > The market mechanism for fulfillment of government expectations is for > the government to purchase what it wants within the market. > > Not to impersonate the user community. If an organization employs the person holding the phone and pays the bills for that person, I believe we typically call that a user organization. > > I'd humbly suggest that since the expectations being outlined in this > document are extrordinarily expensive ones, it might benefit the > expectant party to moderate its expectations somewhat, or suggest how > much it's interested in paying, and allow the market to present > offerings which meet that price range. > > Stating overblown expectations in a financial vacuum is feckless. The user requirements that have been stated are functions that have been used and available for over forty years. Rumor has it, that VoIP can provide these same functions for less money. That's why many people are working on this. If the technology can't match these functions, then we have to decide if we want it. But for the moment, we're trying to build a usable system for our requirements. > > > Users should have the option protecting certain sensitive traffic > > from eavesdropping and the source/destination of some traffic. > > "Users" REQUIRE that service providers SHOULD give users the option of > putting a big pillowcase over their heads before answering the phone? > Or shutting their office door before answering the phone? There other more effective ways of doing this. > > So,in summary, what we appear to have here is a document which: > > - pretends to document "user requirements" while not actually > representing users; We do represent real users. > > - asks for hugely expensive "features" without suggesting who, or even > whether, anyone would be willing to pay for them; The DOD has been supplying and paying for these services for decades. Steve Silverman Houston Associates working for the US Air Force _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Oct 30 22:53:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24841 for ; Wed, 30 Oct 2002 22:53:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V3tst24624 for ieprep-archive@odin.ietf.org; Wed, 30 Oct 2002 22:55:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V3tsv24621 for ; Wed, 30 Oct 2002 22:55:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24824 for ; Wed, 30 Oct 2002 22:53:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V3t4v24607; Wed, 30 Oct 2002 22:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V3sNv24585 for ; Wed, 30 Oct 2002 22:54:23 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24794 for ; Wed, 30 Oct 2002 22:51:51 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 52CF867103; Wed, 30 Oct 2002 19:13:48 -0500 (EST) Date: Wed, 30 Oct 2002 22:54:13 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Bill Woodcock" , To: "Steve Silverman" From: RJ Atkinson In-Reply-To: Message-Id: <6B16166F-EC84-11D6-A53C-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 21:37 America/Montreal, Steve Silverman wrote: > The user requirements that have been stated are functions that have > been > used and available for over forty years. ...in the PSTN, using entirely different underlying technology... > Rumor has it, that VoIP can provide these same functions for less > money. That phrasing is hard to argue with, since it acknowledges so much uncertainty. Personally, I think it is FAR from clear that VoIP (at any price) will provide identical capabilities as the PSTN -- because the underlying communications technologies have VERY different architectures, design objectives, and implementations. I will also note that other "users" (e.g. Japan) have no stated interest in VoIP as an IEprep service -- and are instead focused on how to use IEprep services to provide enhanced performance for traditional Internet applications (e.g. web, email). In short, there are a variety of users, with different desired features/applications/desires. I think a more productive approach would be for discussion here to focus on services that a typical current commercial deployment of standards-based Internet network technology might be able to provide, as compared with trying to put the PSTN-capabilities ("a square peg") into the existing Internet ("a round hole"). (Square pegs are fine if one has a square hole, but they don't fit well in any size of round hole. :-) Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 02:23:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09298 for ; Thu, 31 Oct 2002 02:23:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V7PNi10878 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 02:25:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V7PNv10875 for ; Thu, 31 Oct 2002 02:25:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09295 for ; Thu, 31 Oct 2002 02:22:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V7OBv10845; Thu, 31 Oct 2002 02:24:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V7NXv10807 for ; Thu, 31 Oct 2002 02:23:33 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09262 for ; Thu, 31 Oct 2002 02:20:57 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA07890; Thu, 31 Oct 2002 08:23:15 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA10431; Thu, 31 Oct 2002 08:23:15 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Oct 2002 08:22:43 +0100 Message-ID: <47D438A0510BD611B9470002A58EDAE703E918@mchh2a6e.mchh.siemens.de> From: Ottensmeyer Joerg To: "Ieprep List (ieprep@ietf.org)" Cc: "'Folts, Harold'" Date: Thu, 31 Oct 2002 08:22:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C280AE.4D801660" Subject: [Ieprep] new draft on emtel services and features Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C280AE.4D801660 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I have posted a new draft entitled "The set of Emergency Features = provided in=20 Public Switched Telephone Networks" which should be interesting to the=20 IEPREP WG. Until it appears in the ID repository, it is available via http://www.sctp.de/internet-drafts/draft-otty-ieprep-pstn-features-00.tx= t = =20 =20 best regards -J=F6rg ------_=_NextPart_001_01C280AE.4D801660 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Basic Requirements ID
I have posted=20 a new draft entitled "The set of Emergency Features provided in=20
Public=20 Switched Telephone Networks" which should be interesting to the=20
IEPREP WG.=20 Until it appears in the ID repository, it is available=20 via
http://www.sctp.de/internet-drafts/draft-otty-ieprep-pstn-fea= tures-00.txt
 
best=20 regards
-J=F6rg
------_=_NextPart_001_01C280AE.4D801660-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 04:33:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11111 for ; Thu, 31 Oct 2002 04:33:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V9ZdJ18159 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 04:35:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V9Zdv18155 for ; Thu, 31 Oct 2002 04:35:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11106 for ; Thu, 31 Oct 2002 04:33:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V9YNv18111; Thu, 31 Oct 2002 04:34:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V9Xlv18086 for ; Thu, 31 Oct 2002 04:33:47 -0500 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11092 for ; Thu, 31 Oct 2002 04:31:12 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Oct 2002 09:33:29 +0000 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Bill Woodcock cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-reply-to: Your message of "Wed, 30 Oct 2002 16:28:33 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Oct 2002 09:33:28 +0000 Message-ID: <618.1036056808@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , It would be more constructive if you could provide technical points of discussion and a more precise set of comments. Responses to very general comments/opinions and sarcasm tends to be a bit fruitless in the end. If you wish to stand by your comments as they exist, then perhaps its better to end this particular thread. > Why are we discussing this, again? at the Yokohama meeting, there was basically no contentious arguements expressed about the version -00 draft (nor has there been any on the list that i recall since yokohama). There did seem to be some hallway discussions (one of which I participated in), but a hallway discussion is private and not an open debate and so others not participating cannot be expected to respond to them. the version -01 draft is the result of one such discussion that did make it back to the authors, and as a result, the -01 draft is more constrained, smaller (sections taken out), and has sections that have been reworded to focus on words like "must" and "should". my personal desire would be to hold off final debate on the -01 draft until the carlberg/atkinson requirements drafts have been advanced. but, thats not my call to make. regards, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 10:19:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24336 for ; Thu, 31 Oct 2002 10:19:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VFL8406031 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 10:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VFL8v06028 for ; Thu, 31 Oct 2002 10:21:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24274 for ; Thu, 31 Oct 2002 10:18:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VFJ9v05946; Thu, 31 Oct 2002 10:19:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VFIrv05925 for ; Thu, 31 Oct 2002 10:18:53 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24221 for ; Thu, 31 Oct 2002 10:16:26 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 9E90867103 for ; Thu, 31 Oct 2002 06:38:28 -0500 (EST) Date: Thu, 31 Oct 2002 10:18:48 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <0DC801B5-ECE4-11D6-BC6C-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ken indicates he didn't follow all of Bill's comments. I'll try to restate a few of them -- no doubt Bill will correct any errors I make. Note that I'm just trying to translate Bill's comments, neither agreeing nor disagreeing with them necessarily. I'll make my own comments within a few days. On Wednesday, Oct 30, 2002, at 19:28 America/Montreal, Bill Woodcock wrote: >> This document outlines user requirements... > > This does not in fact appear to be the case. In fact, this appears to > outline government expectations of service providers and vendors. > > The market mechanism for fulfillment of government expectations is for > the government to purchase what it wants within the market. > > Not to impersonate the user community. > > I'd humbly suggest that since the expectations being outlined in this > document are extrordinarily expensive ones, it might benefit the > expectant party to moderate its expectations somewhat, or suggest how > much it's interested in paying, and allow the market to present > offerings which meet that price range. > > Stating overblown expectations in a financial vacuum is feckless. Bill differentiates between government expectations and non-government user requirements and suggests the document is mis-titled and maybe poorly described in its introduction. >> There are four basic configurations that come >> into play during convergence. These include: >> o Pure IP telephony, with no link to the PSTN > > This appears to be largely ignored in the rest of the document. Out in > the real world, however, it appears to be a significant portion of the > total, however. Bill runs one of the larger pure VoIP services deployed today, which might not be widely known outside the IP Carrier community. That service has *no* current or future interconnection with the PSTN. He is observing that the largest VoIP deployments today generally do *not* have any current or planned interconnection with the PSTN. He notes that the document seems unaware of the nature of current large-scale inter-domain VoIP deployments. >> We assume the presence of Service Level Agreements > > Which are a marketing, sales, and collections fiction. If you want to > base a standard on a sales practice, the IETF isn't an appropriate > place to do it. He's saying the assumption is not well founded. >> sessions should be provided with with a higher probability of >> completion over non-emergency communications. We assume the >> presence of a service level agreement to accomplish this. > > Sales fictions do not accomplish operational objectives. However, one > might view QoS as an operational instantiation of SLAs, and it's > instructive to note that QoS is substantially more fictional than SLAs. > Since it doesn't work and wouldn't provide any desired utility even if > it did, it's neither used nor desired on any significant networks. Much > less on significant production VoIP networks. He's noting that most (all that I'm familiar with, actually) current SLAs are written by the IP Carrier with sufficient care that the SLAs are unenforcable, both in practice and in law. Many current IP Carriers outright refuse to offer SLAs today. He also notes that current large-scale production VoIP services, such as his, don't use or need SLAs for proper operation. I'll also note that Bill's VoIP service is intended for primary use when the global Internet is under a lot of stress, so he does care about service availability. >> Emergency traffic should be able to transit multiple service >> providers. The existence of service level agreements determines >> the extent by which this can be accomplished. > > Could have fooled me. I thought network interconnection determined the > extent to which traffic could be exchanged. Silly me. I'll go sign a > bunch of SLAs. That's got to be easier than actually building a > network. Bill is observing that ability to transit in fact relies almost exclusively on the BGP protocol, what is advertised there, and what BGP puts into forwarding tables in deployed routers. Such forwarding is a technical function that is oblivious to the presence/absence of any SLA. >> Networks should be able to support a variety of user applications >> including telephony, video, database access, messaging, >> telemetry, and web browsing to support emergency operations. > > Uh, am I really reading this in an IETF document? Hello? Networks > SHOULD make toast? Not sure what Bill means here. >> Users should have the option protecting certain sensitive traffic >> from eavesdropping and the source/destination of some traffic. > > "Users" REQUIRE that service providers SHOULD give users the option of > putting a big pillowcase over their heads before answering the phone? > Or shutting their office door before answering the phone? Bill's wording is sub-optimal, but I think his point is that if any end-user wants security, then that end-user should be using end-to-end security mechanisms deployed by the user. TLS, ESP, and AH would be examples of such services that are normally deployed by the end-user -- not by the IP carrier. >> Users should have the option of requesting degraded quality of >> service when normal or expected QoS cannot be achieved. > > This one is really cute. Brings to mind the Star Trek movie in which > Scotty travels back in time and operates a Mac Plus. > > Users are more than welcome to request degraded quality of service at > any time. Please speak loudly into the mouse, before dialing. Bill's point seems to be (I'm not entirely sure) that the real deployed Internet has no concept of QoS -- not merely no concept of "good" QoS but no concept of "QoS" at all.[1] For example, there are no large scale DiffServ or RSVP deployments in commercial IP networks today as near as I can tell. Perhaps equally relevant is that IP Carriers have roughly nil capital budget to buy new routers these days, while most deployed routers can't support QoS without suffering degraded packet forwarding rates.[2] Regards, Ran rja@extremenetworks.com [1] Caveat: Most deployed backbone/core routers do differentiate packets that are marked with the "Internet Control" IP ToS bit pattern as defined in RFC-791 -- and give those packets lower drop preference. This is done to try to ensure that BGP traffic, essential for maintaining accurate routing/forwarding tables, is unlikely to be dropped should stress occur on some link. The mechanism is not necessarily part of a broader implementation of IP ToS/DiffServ support. [2] Exceptions exist, but it seems inappropriate to mention specific vendor names on this mailing list. People who are really interested in this can send me private email for my personal (not corporate) opinions on this. I never speak for my employer. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 11:07:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27798 for ; Thu, 31 Oct 2002 11:07:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VG9bn09570 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 11:09:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VG9bv09567 for ; Thu, 31 Oct 2002 11:09:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27787 for ; Thu, 31 Oct 2002 11:07:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VG85v09491; Thu, 31 Oct 2002 11:08:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VG7wv09453 for ; Thu, 31 Oct 2002 11:07:58 -0500 Received: from clifden.donelan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27706 for ; Thu, 31 Oct 2002 11:05:31 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #3) id 187HrM-0003Su-00; Thu, 31 Oct 2002 11:07:52 -0500 Date: Thu, 31 Oct 2002 11:07:52 -0500 (EST) From: Sean Donelan To: RJ Atkinson cc: ieprep Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <0DC801B5-ECE4-11D6-BC6C-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Thu, 31 Oct 2002, RJ Atkinson wrote: > [1] Caveat: Most deployed backbone/core routers do differentiate packets > that are marked with the "Internet Control" IP ToS bit pattern as > defined in RFC-791 -- and give those packets lower drop preference. > This > is done to try to ensure that BGP traffic, essential for maintaining > accurate routing/forwarding tables, is unlikely to be dropped should > stress occur on some link. The mechanism is not necessarily part of > a broader implementation of IP ToS/DiffServ support. While the internals of particular implementations likely vary, as I understand it, a backbone/core router differentiate packets originated by itself. The IP ToS bits are set for bookeeeping purposes. The real method how BGP or link-level Keepalives get to the front of the queue is because when the router originates the packets, it puts some of its own packets at the front of the queue. Packets originating on other routers with the IP ToS bits are not handled differently, even if those protocols would have been prioritized on the same router. Multi-hop BGP packets do not receive special handling by other routers. Since anyone can run any protocol on any port, if backbone/core routers did prioritize port 179 packets; what would happen is people would run Quake/Doom servers on port 179. As you say, the link-level prioritization done by routers is not necessarily part of a broader implementation of IP ToS/DiffServ support. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 11:30:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29490 for ; Thu, 31 Oct 2002 11:30:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VGW1S10649 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 11:32:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGW0v10646 for ; Thu, 31 Oct 2002 11:32:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29407 for ; Thu, 31 Oct 2002 11:29:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGU7v10539; Thu, 31 Oct 2002 11:30:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGTdv10501 for ; Thu, 31 Oct 2002 11:29:39 -0500 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29252 for ; Thu, 31 Oct 2002 11:27:11 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Oct 2002 16:29:29 +0000 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: RJ Atkinson cc: ieprep Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-reply-to: Your message of "Thu, 31 Oct 2002 10:18:48 EST." <0DC801B5-ECE4-11D6-BC6C-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Oct 2002 16:29:28 +0000 Message-ID: <1583.1036081768@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , proxy discussion. cool :-) > Bill differentiates between government expectations and non-government > user requirements and suggests the document is mis-titled and maybe > poorly described in its introduction. ok, this is a critic one can address and respond to. who is considered a can be clarified and expanded upon. > >> There are four basic configurations that come > >> into play during convergence. These include: > >> o Pure IP telephony, with no link to the PSTN > > > > This appears to be largely ignored in the rest of the document. Out in > > the real world, however, it appears to be a significant portion of the > > total, however. > > Bill runs one of the larger pure VoIP services deployed today, > which might not be widely known outside the IP Carrier community. > That service has *no* current or future interconnection with the PSTN. > He is observing that the largest VoIP deployments today generally > do *not* have any current or planned interconnection with the PSTN. > He notes that the document seems unaware of the nature of current > large-scale inter-domain VoIP deployments. understood. the purpose of the passage about "4 basic configurations" was to acknowledge that more than one exists and that users of an authorized emergency service should keep this in mind. what one cannot determine from Bill's original statement is *how* that one scenario he points out (and obviously relates to) is ignored. Is there a requirement missing, or is something else amiss? -- I'd don't know and prefer not to guess. > >> We assume the presence of Service Level Agreements > > > > Which are a marketing, sales, and collections fiction. If you want to > > base a standard on a sales practice, the IETF isn't an appropriate > > place to do it. > > He's saying the assumption is not well founded. we have used the term "business agreement" instead of SLAs in our other documents. the intent is to convey the expectation of a charging in some form of a contracted service that is outside of best effort or normal service. if the term "SLA" has too much baggage or negative association attached to it, a different term can be used. > He's noting that most (all that I'm familiar with, actually) current > SLAs are written by the IP Carrier with sufficient care that the SLAs > are unenforcable, both in practice and in law. Many current IP Carriers > outright refuse to offer SLAs today. and some do. as you know, I've seen and experienced some whoppers > He also notes that current large-scale production VoIP services, such > as his, don't use or need SLAs for proper operation. I'll also note > that Bill's VoIP service is intended for primary use when the global > Internet is under a lot of stress, so he does care about service > availability. understood. > >> Emergency traffic should be able to transit multiple service > >> providers. The existence of service level agreements determines > >> the extent by which this can be accomplished. > > > > Could have fooled me. I thought network interconnection determined the > > extent to which traffic could be exchanged. Silly me. I'll go sign a > > bunch of SLAs. That's got to be easier than actually building a > > network. > > Bill is observing that ability to transit in fact relies almost > exclusively > on the BGP protocol, what is advertised there, and what BGP puts into > forwarding tables in deployed routers. Such forwarding is a technical > function that is oblivious to the presence/absence of any SLA. understood. but this seems to reflect a disconnect and probably a need for additional clarification in the -01 document. The original passage probably should have stated "labeled emergency traffic". The traffic itself could be diff-serv marked IP packets (and before you say "don't expect to use diff-serv" :-), I'll save you the trouble and agree that for now, diff-serv is a VERY rare offering). Or they could be labeled application layer packets. In either case, the user would have the expectation that the labeled traffic transits other providers as opposed to be dropped because it is unrecognized. Further, that this expectation can only exist if "business contracts" have been set up with those that would examine the label. if the business contract doesn't exist, or the labels isn't examined, then expect normal (presumably best effort) service. but again, it would seem that the original passage needs clarifications. that can be done. > >> Users should have the option protecting certain sensitive traffic > >> from eavesdropping and the source/destination of some traffic. > > > > "Users" REQUIRE that service providers SHOULD give users the option of > > putting a big pillowcase over their heads before answering the phone? > > Or shutting their office door before answering the phone? > > Bill's wording is sub-optimal, but I think his point is that if any > end-user wants security, then that end-user should be using end-to-end > security mechanisms deployed by the user. TLS, ESP, and AH would be > examples of such services that are normally deployed by the end-user > -- not by the IP carrier. right, your wording is understood. I think the original passage was meant to touch upon anonymity, but thats conjecture on my part. > >> Users should have the option of requesting degraded quality of > >> service when normal or expected QoS cannot be achieved. > > > > This one is really cute. Brings to mind the Star Trek movie in which > > Scotty travels back in time and operates a Mac Plus. > > > > Users are more than welcome to request degraded quality of service at > > any time. Please speak loudly into the mouse, before dialing. > > Bill's point seems to be (I'm not entirely sure) that the real deployed > Internet has no concept of QoS -- not merely no concept of "good" QoS > but no concept of "QoS" at all.[1] For example, there are no large > scale > DiffServ or RSVP deployments in commercial IP networks today as near > as I can tell. Perhaps equally relevant is that IP Carriers have > roughly > nil capital budget to buy new routers these days, while most deployed > routers > can't support QoS without suffering degraded packet forwarding rates.[2] ok. your interpretation would again seem to foster a need for more clarification on the authors part. the intent of the original passage was aimed at the QoS experienced by the end-user and not necessarily that offered by the network. for example, using lower quality/bandwidth codecs, or adding FEC -- ie, something other than standard end-to-end service. cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 11:37:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29835 for ; Thu, 31 Oct 2002 11:37:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VGdVc11518 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 11:39:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGdVv11515 for ; Thu, 31 Oct 2002 11:39:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29806 for ; Thu, 31 Oct 2002 11:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGc1v11480; Thu, 31 Oct 2002 11:38:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGbrv11464 for ; Thu, 31 Oct 2002 11:37:53 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29740 for ; Thu, 31 Oct 2002 11:35:26 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 8F0F567103; Thu, 31 Oct 2002 07:57:26 -0500 (EST) Date: Thu, 31 Oct 2002 11:37:46 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: Sean Donelan From: RJ Atkinson In-Reply-To: Message-Id: <15ED73DD-ECEF-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 11:07 America/Montreal, Sean Donelan wrote: > While the internals of particular implementations likely vary, as I > understand it, a backbone/core router differentiate packets originated > by itself. For the systems I'm familiar with, the internal implementations do vary, but the concept of operations and intended results are very similar. > The IP ToS bits are set for bookeeeping purposes. Maybe. In at least 2 widely deployed implementations, the IP ToS bits are (were ?) set on outgoing BGP packets in order to provide clues to other deployed routers along the path used by the BGP packets. I haven't run this experiment recently, but it was certainly true ~3 years ago. The behaviour of shipping code might have changed during that time. > The real method how BGP or link-level Keepalives get to the front of > the queue > is because when the router originates the packets, it puts some of its > own packets at the front of the queue. This is true, but incomplete. In at least 2 widely deployed implementations, the code inside ip_input() looks for packets with the magic IP ToS value set and then verifies that they are BGP packets (by looking at protocol=TCP and port=BGP) and handles them with reduced drop preference. The degree of reduced drop preference is unclear to me (and is somewhat debatable) absent some scientific testing, but notionally it is present. > Packets originating on other routers with the IP ToS bits are not > handled > differently, even if those protocols would have been prioritized on the > same router. Multi-hop BGP packets do not receive special handling by > other routers. The above is not the case for at least 2 widely deployed implementations. > Since anyone can run any protocol on any port, if > backbone/core routers did prioritize port 179 packets; what would > happen > is people would run Quake/Doom servers on port 179. It certainly is a potential threat. Many ISPs configure their access routers to strip the IP ToS bits on all packets received from customers -- in order to mitigate such threats. This last practice is a de facto barrier to widespread DiffServ deployment. > As you say, the link-level prioritization done by routers is not > necessarily part of a broader implementation of IP ToS/DiffServ > support. Glad we agree on that. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 11:40:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00136 for ; Thu, 31 Oct 2002 11:40:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VGgnw11728 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 11:42:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGgmv11725 for ; Thu, 31 Oct 2002 11:42:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00108 for ; Thu, 31 Oct 2002 11:40:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGf3v11653; Thu, 31 Oct 2002 11:41:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VGevv11612 for ; Thu, 31 Oct 2002 11:40:57 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29920 for ; Thu, 31 Oct 2002 11:38:31 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id B2E7967103; Thu, 31 Oct 2002 08:00:34 -0500 (EST) Date: Thu, 31 Oct 2002 11:40:54 -0500 Subject: Re: [Ieprep] new draft on emtel services and features Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Ieprep List (ieprep@ietf.org)" To: Ottensmeyer Joerg From: RJ Atkinson In-Reply-To: <47D438A0510BD611B9470002A58EDAE703E918@mchh2a6e.mchh.siemens.de> Message-Id: <8610734C-ECEF-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It would be helpful to add a chapter or appendix discussing the precise national-specific details of the German deployment of IEPS using the German PSTN. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 12:30:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02816 for ; Thu, 31 Oct 2002 12:30:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VHWMe15051 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 12:32:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHWMv15048 for ; Thu, 31 Oct 2002 12:32:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02788 for ; Thu, 31 Oct 2002 12:29:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHV6v14966; Thu, 31 Oct 2002 12:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHUHv14927 for ; Thu, 31 Oct 2002 12:30:17 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02673 for ; Thu, 31 Oct 2002 12:27:50 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VHOHd04409; Thu, 31 Oct 2002 09:24:17 -0800 (PST) Date: Thu, 31 Oct 2002 09:24:17 -0800 (PST) From: Bill Woodcock To: Ken Carlberg cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <618.1036056808@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Thu, 31 Oct 2002, Ken Carlberg wrote: > It would be more constructive if you could provide technical points > of discussion. Peter and I tried that at the last meeting, and nobody wanted to talk about technology. Instead, we get this document, which consists largely of statements of the form "The PSTN makes toast!" and "We _like_ toast!" and "The Internet SHOULD make toast!" and "Salespeople SHOULD tell us that the Internet makes toast!" > at the Yokohama meeting, there was basically no contentious arguements > expressed about the version -00 draft Very generous of you to characterize Peter and myself as uncontentious. Or perhaps you're just forgetting that you ignored everything we said. I would really welcome _any little tidbit of technical anything_ that could be debated. As it is, the document is just a bunch of long-winded platitudes about the PSTN and about sales practices. Not much for an engineer to debate. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 13:02:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05077 for ; Thu, 31 Oct 2002 13:02:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VI4GX17788 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 13:04:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VI4Gv17785 for ; Thu, 31 Oct 2002 13:04:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05057 for ; Thu, 31 Oct 2002 13:01:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VI33v17738; Thu, 31 Oct 2002 13:03:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VI21v17588 for ; Thu, 31 Oct 2002 13:02:01 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04869 for ; Thu, 31 Oct 2002 12:59:33 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VHu7d04986 for ; Thu, 31 Oct 2002 09:56:07 -0800 (PST) Date: Thu, 31 Oct 2002 09:56:07 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <1583.1036081768@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > the purpose of the passage about "4 basic configurations" > was to acknowledge that more than one exists and that users of an > authorized emergency service should keep this in mind. what one > cannot determine from Bill's original statement is *how* that one > scenario he points out (and obviously relates to) is ignored. This was what I was principally objecting to at the Yokohama meeting: there seems to be an underlying assumption that the PSTN will connect to arbitrary other voice networks. My own network appears to be the exception in that PSTN operators do in fact seem to be eager to connect to it and bear the costs of doing so, but in the general case, they don't seem to be interested in doing so. If the document or the expectant party which it represents wants to be able to pick up an arbitrary telephone and call an arbitrary other telephone, this presupposes interconnection between the two networks which serve the respective telephones. I would point out that the expectant party has historically been one of the main consumers of disconnected telephone networks, and was in fact proposing to create yet another just this week at NANOG. So this is clearly not a useful expectation. > > >> We assume the presence of Service Level Agreements > > > Which are a marketing, sales, and collections fiction. > > He's saying the assumption is not well founded. > we have used the term "business agreement" instead of SLAs in our > other documents. Right. So isn't this CLEARLY OUTSIDE THE REALM OF THE IETF? Since when does the IETF standardize business agreements? >>>> Emergency traffic should be able to transit multiple service >>>> providers. > The original passage probably should have stated "labeled emergency > traffic". The traffic itself could be diff-serv marked IP packets. > Or they could be labeled application layer packets. In either case, > the user would have the expectation that the labeled traffic > transits other providers as opposed to be dropped because it is > unrecognized. Then the user's expectation would be unfulfilled. You're completely missing the point. _No_ traffic is going to transit multiple service providers unless the service providers are interconnected. Interconnection is a physical process, not a sales process. > Further, that this expectation can only exist if "business > contracts" have been set up... if the business contract doesn't > exist... then expect normal (presumably best effort) service. No, no, no. If the _physical interconnection_ doesn't exist, then expect _no_ service. Has nothing to do with business contracts. >>> Users are more than welcome to request degraded quality of service at >>> any time. Please speak loudly into the mouse, before dialing. >> Bill's point seems to be that the real deployed Internet has no >> concept of QoS -- not merely no concept of "good" QoS but no >> concept of "QoS" at all. Correct. We all tried, multiple times, but since it made everything worse, rather than better, and cost money rather than saving money, it died a well-deserved death quite a few years ago. End users are perfectly welcome to assume its existence and "request degraded service" all they like. They can also wave magic wands and chant incantations. We'll keep routing packets either way. > the intent of the original passage > was aimed at the QoS experienced by the end-user and not necessarily > that offered by the network. for example, using lower quality/bandwidth > codecs, or adding FEC -- ie, something other than standard end-to-end > service. Then it doesn't belong in the document, does it? Users are welcome to do whatever users do. That doesn't constitute an expectation of service providers. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 13:11:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05635 for ; Thu, 31 Oct 2002 13:11:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VIDER19064 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 13:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIDEv19061 for ; Thu, 31 Oct 2002 13:13:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05596 for ; Thu, 31 Oct 2002 13:10:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIC1v18942; Thu, 31 Oct 2002 13:12:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIBKv18886 for ; Thu, 31 Oct 2002 13:11:20 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05497 for ; Thu, 31 Oct 2002 13:08:52 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VI5Jd05181; Thu, 31 Oct 2002 10:05:19 -0800 (PST) Date: Thu, 31 Oct 2002 10:05:19 -0800 (PST) From: Bill Woodcock To: Steve Silverman cc: ieprep@ietf.org Subject: RE: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Wed, 30 Oct 2002, Steve Silverman wrote: > > > This document outlines user requirements... > > This does not in fact appear to be the case. > If an organization employs the person holding the phone and pays > the bills for that person, I believe we typically call that a user > organization. I suggest you familiarize yourself with the operation of the IETF before attempting to participate. Organizations are not entitled to representation in the IETF. Individuals represent themselves in the IETF. > The user requirements that have been stated are functions that have > been used and available for over forty years. That's nice. Take it to the ITU. We engineer Internet protocols here. > We do represent real users. That's interesting. I look in my phonebook, and I see an "Atkinson" and a "Lothberg" and a "Bradner", but no "Silverman", and no "Force, U.S. Air". -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 13:39:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07103 for ; Thu, 31 Oct 2002 13:39:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VIfH121022 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 13:41:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIfHv21019 for ; Thu, 31 Oct 2002 13:41:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07093 for ; Thu, 31 Oct 2002 13:38:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIe2v20977; Thu, 31 Oct 2002 13:40:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VId7v20923 for ; Thu, 31 Oct 2002 13:39:07 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07033 for ; Thu, 31 Oct 2002 13:36:38 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 5B73667103; Thu, 31 Oct 2002 09:58:43 -0500 (EST) Date: Thu, 31 Oct 2002 13:39:02 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep@ietf.org To: Bill Woodcock From: RJ Atkinson In-Reply-To: Message-Id: <06D8CC2E-ED00-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 12:56 America/Montreal, Bill Woodcock wrote: >> the intent of the original passage >> was aimed at the QoS experienced by the end-user and not necessarily >> that offered by the network. for example, using lower >> quality/bandwidth >> codecs, or adding FEC -- ie, something other than standard end-to-end >> service. > > Then it doesn't belong in the document, does it? Users are welcome to > do > whatever users do. That doesn't constitute an expectation of service > providers. Two comments: 1) I'll push back a bit on Bill about the above. It seems to me that it is OK (and there is precedent) for folks to write non-standards-track documents about topics which are beyond pure protocol specs and publish those as Informational RFCs. It is true that standards-track IETF documents are nearly always protocol specs (the exceptions seem to be a handful of BCPs trying to dispense free clues or discussing IETF processes), but the proposal on the table is for Hal's document to go out as Informational, not standards-track. It is important (and the IESG traditionally will insist) that non-standards-track documents use language that makes it clear that the document is non-standards-track. I'm not sure which precise criteria the IESG use for making that determination during their pre-publication review. 2) I could be wrong, but it seems that one of Bill's concerns is that Hal's document is written editorially so that it can be (mis)read as speaking for "all users" when it is more accurately the perspective of "some users" or "one user" (being DISA/NCS). Re-titling the document or editing the introduction to make it clear that the document provides one user's perspective on IEprep services (and that other perspectives could hypothetically exist) would likely help. Dropping the word "requirements" would also help, since the IETF usage of "requirements" is pretty narrow and normally means that either an implementer has to do a specific thing or an operator (like Bill) has to do a specific thing. That word might be causing unintended confusion here. (Bill might dispute 1 and correct me on 2, but dialogue helps at least for now :-) Regards, Ran rja@extremenetworks.com PS: It would be nice if Bill would also examine and comment on the two I-Ds from Ken Carlberg (draft-carlberg-ets-*). Those are *intended* to eventually become standards-track (BCP or PS, not sure what the IESG wants), so would also benefit from wider review, particularly from operators and implementers. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 13:42:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07244 for ; Thu, 31 Oct 2002 13:42:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VIiFL21185 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 13:44:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIiFv21181 for ; Thu, 31 Oct 2002 13:44:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07218 for ; Thu, 31 Oct 2002 13:41:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIh0v21132; Thu, 31 Oct 2002 13:43:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIgHv21064 for ; Thu, 31 Oct 2002 13:42:17 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07125 for ; Thu, 31 Oct 2002 13:39:48 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 1FAD067103; Thu, 31 Oct 2002 10:01:54 -0500 (EST) Date: Thu, 31 Oct 2002 13:42:13 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Steve Silverman , ieprep@ietf.org To: Bill Woodcock From: RJ Atkinson In-Reply-To: Message-Id: <789ED738-ED00-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 13:05 America/Montreal, Bill Woodcock wrote: >> We do represent real users. > > That's interesting. I look in my phonebook, and I see an "Atkinson" > and a > "Lothberg" and a "Bradner", but no "Silverman", and no "Force, U.S. > Air". (Attempting translation again) The document was not written by one of Bill's VoIP users. And he probably does not intend to offer IEprep capabilities (or even universal interconnection with other VoIP or PSTN services) with his VoIP service. Maybe this means that it would help if the draft were edited to narrow the scope to "commercial VoIP services which are fully interconnected with the PSTN and choose to offer IEprep support" (edit to taste) ? Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 13:57:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08130 for ; Thu, 31 Oct 2002 13:57:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VIxpe21745 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 13:59:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIxov21742 for ; Thu, 31 Oct 2002 13:59:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08122 for ; Thu, 31 Oct 2002 13:57:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIw3v21674; Thu, 31 Oct 2002 13:58:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIvgv21650 for ; Thu, 31 Oct 2002 13:57:42 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08001 for ; Thu, 31 Oct 2002 13:55:12 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VIpjd06271; Thu, 31 Oct 2002 10:51:45 -0800 (PST) Date: Thu, 31 Oct 2002 10:51:45 -0800 (PST) From: Bill Woodcock To: RJ Atkinson cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <06D8CC2E-ED00-11D6-BE27-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > the proposal on the table is for Hal's document to go out as > Informational, not standards-track. It is important (and the IESG > traditionally will insist) that non-standards-track documents use > language that makes it clear that the document is non-standards-track. And not best-practices. So it's documenting one user's experience with the PSTN, and the fact that that one user would prefer it if the Internet operated more like the PSTN, and less like the Internet. > Hal's document is written editorially so that it can be (mis)read as > speaking for "all users" when it is more accurately the perspective > of... "one user" (being DISA/NCS). Correct. > Re-titling the document or editing the introduction to make it clear > that the document provides one user's perspective on IEprep > services (and that other perspectives could hypothetically exist) would > likely help. Dropping the word "requirements" would also help, since > the IETF usage of "requirements" is pretty narrow and normally > means that either an implementer has to do a specific thing or an > operator (like Bill) has to do a specific thing. Correct. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 14:06:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08794 for ; Thu, 31 Oct 2002 14:06:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VJ8je22729 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 14:08:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJ8jv22726 for ; Thu, 31 Oct 2002 14:08:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08790 for ; Thu, 31 Oct 2002 14:06:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJ82v22678; Thu, 31 Oct 2002 14:08:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJ76v22181 for ; Thu, 31 Oct 2002 14:07:06 -0500 Received: from wells.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08699 for ; Thu, 31 Oct 2002 14:04:36 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA08223; Thu, 31 Oct 2002 11:06:44 -0800 (PST) Message-Id: <4.1.20021031123042.027c8830@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 31 Oct 2002 13:06:35 -0600 To: Bill Woodcock From: "James M. Polk" Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Cc: ieprep@ietf.org In-Reply-To: References: <1583.1036081768@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , The IEPREP Charter (paragraph #1): "Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations. Three examples of emergency communications include: 1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN. " Bill - this charter seems to describe networks *other* than yours (because of your choice of interconnectivity issues); therefore I believe your discussion is out of scope for this list until *you* can change the charter to *not* state IEPREP directly involves the commercial telecommunications industry (which means at least also interconnectivity to the PSTN/GSTN/CSN). I have my own issues with the ID, but clearly don't want to hear your ranting BS that doesn't apply to the charter (which the Reqs ID here attempts to do). BTW - this seems like a very good time for *you* to write an ID about the issues and requirements involving Topology "End-to-End IP" from: http://www.ietf.org/internet-drafts/draft-polk-ieprep-scenarios-01.txt THE purpose for that ID is to bring overlapping and unique discussions regarding the similarities and differences surrounding each of the 4 basic Topologies. I have read through ~10 emails that you (and maybe Ran) want your Topology to be overlapping in nature (therefore everything changed) with respect to the other 3 Topologies - yet your unclear reasoning seems to point to your uniqueness relative to the other Topologies. One problem I see with you doing this is your intent on *not* connecting to IEPREP/ETS/GETS/GTPS services of any kind (so why are you commenting at all to this discussion that will not involve you or your network?). Send text or write your own ID -- you seem to feel quite strongly about this. nuff said (in your equally brash manner)! At 09:56 AM 10/31/2002 -0800, Bill Woodcock wrote: > > the purpose of the passage about "4 basic configurations" > > was to acknowledge that more than one exists and that users of an > > authorized emergency service should keep this in mind. what one > > cannot determine from Bill's original statement is *how* that one > > scenario he points out (and obviously relates to) is ignored. > >This was what I was principally objecting to at the Yokohama meeting: >there seems to be an underlying assumption that the PSTN will connect to >arbitrary other voice networks. My own network appears to be the >exception in that PSTN operators do in fact seem to be eager to connect to >it and bear the costs of doing so, but in the general case, they don't >seem to be interested in doing so. > >If the document or the expectant party which it represents wants to be >able to pick up an arbitrary telephone and call an arbitrary other >telephone, this presupposes interconnection between the two networks which >serve the respective telephones. > >I would point out that the expectant party has historically been one of >the main consumers of disconnected telephone networks, and was in fact >proposing to create yet another just this week at NANOG. So this is >clearly not a useful expectation. > > > > >> We assume the presence of Service Level Agreements > > > > Which are a marketing, sales, and collections fiction. > > > He's saying the assumption is not well founded. > > we have used the term "business agreement" instead of SLAs in our > > other documents. > >Right. So isn't this CLEARLY OUTSIDE THE REALM OF THE IETF? Since when >does the IETF standardize business agreements? > > >>>> Emergency traffic should be able to transit multiple service > >>>> providers. > > The original passage probably should have stated "labeled emergency > > traffic". The traffic itself could be diff-serv marked IP packets. > > Or they could be labeled application layer packets. In either case, > > the user would have the expectation that the labeled traffic > > transits other providers as opposed to be dropped because it is > > unrecognized. > >Then the user's expectation would be unfulfilled. > >You're completely missing the point. _No_ traffic is going to transit >multiple service providers unless the service providers are >interconnected. Interconnection is a physical process, not a sales >process. > > > Further, that this expectation can only exist if "business > > contracts" have been set up... if the business contract doesn't > > exist... then expect normal (presumably best effort) service. > >No, no, no. If the _physical interconnection_ doesn't exist, then expect >_no_ service. Has nothing to do with business contracts. > > >>> Users are more than welcome to request degraded quality of service at > >>> any time. Please speak loudly into the mouse, before dialing. > >> Bill's point seems to be that the real deployed Internet has no > >> concept of QoS -- not merely no concept of "good" QoS but no > >> concept of "QoS" at all. > >Correct. We all tried, multiple times, but since it made everything >worse, rather than better, and cost money rather than saving money, it >died a well-deserved death quite a few years ago. > >End users are perfectly welcome to assume its existence and "request >degraded service" all they like. They can also wave magic wands and chant >incantations. We'll keep routing packets either way. > > > the intent of the original passage > > was aimed at the QoS experienced by the end-user and not necessarily > > that offered by the network. for example, using lower quality/bandwidth > > codecs, or adding FEC -- ie, something other than standard end-to-end > > service. > >Then it doesn't belong in the document, does it? Users are welcome to do >whatever users do. That doesn't constitute an expectation of service >providers. > > -Bill > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 14:15:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09097 for ; Thu, 31 Oct 2002 14:15:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VJHG323010 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 14:17:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJHGv23007 for ; Thu, 31 Oct 2002 14:17:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09077 for ; Thu, 31 Oct 2002 14:14:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJG0v22964; Thu, 31 Oct 2002 14:16:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJF3v22938 for ; Thu, 31 Oct 2002 14:15:03 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09004 for ; Thu, 31 Oct 2002 14:12:32 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9VJE5hB029000 for ieprep@ietf.org; Thu, 31 Oct 2002 14:14:05 -0500 (EST) Date: Thu, 31 Oct 2002 14:14:05 -0500 (EST) From: Scott Bradner Message-Id: <200210311914.g9VJE5hB029000@newdev.harvard.edu> To: ieprep@ietf.org Subject: [Ieprep] a message from teh ITU Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , INTERNATIONAL TELECOMMUNICATION UNION COM 16 LS 23 TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD 2001-2004 Original: English Question(s): I/16 Geneva, 15-25 October 2002 Source: ITU-T Study Group 16 Title: New Question on Use of Public Telecommunication Services for Emergency and Disaster Relief Operations LIAISON STATEMENT To: ITU-T Study Groups 2, 3, 4, 9, 11, 12, 13, 15, 17, SSG; ITU-R; ITU-D; ETSI OCG EMTEL Ad Hoc, Project TIPHON, Partnership Project MESA, Partnership Project 3GPP, TC SPAN; IETF ieprep WG; United Nations Working Group on Emergency Telecommunications Approval: Study Group 16 Plenary 25 October 2002 For: Information/Comment Deadline: None Contact: Hal Folts National Communications System USA Tel: +1 703 607-6186 Fax: +1 703 607-4830 Email: foltsh@ncs.gov Your liaison statements are greatly appreciated in response to our liaison statement of 15 February on new work addressing telecommunications capabilities for emergency and disaster operations. The proposed Question, Q.ets/16, has now been approved and is identified as Q.I/16. A copy of the approved text for the Question is available at http://www.itu.int/ITU-T/studygroups/com16/sg16-qi.html. The question has been structured to identify overall requirements, identify the needed telecommunication capabilities, and develop a system framework. Recognizing that there is considerable related work being addressed in many Study Groups and other organizations, close cooperation and liaison (coordination) among the many activities is essential to ensure consistency and completeness in provisioning effective telecommunication capabilities to support emergency and disaster operations. Q.I/16 is intended to facilitate this process. Many of the responses received provided information about the work underway in the many activities. These have been compiled and developed into a "living" table that will continue to be updated as new information emerges. The table can be viewed at: http://www.itu.int/ITU-T/studygroups/com16/ets/live-list.html Please continue to provide information about your specific work on this important subject and your progress in developing revised and new Recommendations and standards. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 14:26:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09660 for ; Thu, 31 Oct 2002 14:26:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VJSUu23450 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 14:28:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJSUv23447 for ; Thu, 31 Oct 2002 14:28:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09615 for ; Thu, 31 Oct 2002 14:26:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJRIv23372; Thu, 31 Oct 2002 14:27:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJQVv23348 for ; Thu, 31 Oct 2002 14:26:31 -0500 Received: from [209.22.88.17] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09547 for ; Thu, 31 Oct 2002 14:24:01 -0500 (EST) Received: from mtassp3.ncr.disa.mil by [209.22.88.17] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 31 Oct 2002 19:21:20 UT Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 14:26:28 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D23A498@emshqs1.ncr.disa.mil> From: "Folts, Harold" To: "'Bill Woodcock'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Date: Thu, 31 Oct 2002 14:26:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Bill Woodcock [mailto:woody@pch.net] > Sent: Thursday, October 31, 2002 1:52 PM > To: RJ Atkinson > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 > > > > the proposal on the table is for Hal's document to go out as > > Informational, not standards-track. It is important > (and the IESG > > traditionally will insist) that non-standards-track > documents use > > language that makes it clear that the document is > non-standards-track. > > And not best-practices. > > So it's documenting one user's experience with the PSTN, and > the fact that > that one user would prefer it if the Internet operated more > like the PSTN, > and less like the Internet. No, this is NOT "one user's" experience with the PSTN at all. The basic user requirements have been derived with considerable discussion, input and support internationally from government (of many nations) and non-government organizations for disaster relief and mittigation to organize and coordinate recovery operations, save lives, and restore the community infrastructure. Users range from local search and rescue, fire, police, medical, utility providers (gas, electric, etc.), construction industry, telecommunication providers, to local government, and national government officials. There is some of this capability in the PSTN today in the US as well as other countries. The objective of this initiative in the IETF is to provide useful capabilites for disaster relief operations using the Internet and packet-based technologies provided by public networks for future benefit to these important activities. Any relationship to existing PSTN is only for backward compatibility to what might exist. More importantly we are looking for enhanced capabililities for supporting future disaster relief operations globally - voice, data, message, video, telemetry, and many more applications. It is expected that in the future voice will likely become less used than other communication applications for emergency and disaster relief support. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 14:53:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11936 for ; Thu, 31 Oct 2002 14:53:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VJtsJ25266 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 14:55:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJtsv25263 for ; Thu, 31 Oct 2002 14:55:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11929 for ; Thu, 31 Oct 2002 14:53:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJt4v25241; Thu, 31 Oct 2002 14:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VJsWv25206 for ; Thu, 31 Oct 2002 14:54:32 -0500 Received: from imo-m06.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11854 for ; Thu, 31 Oct 2002 14:52:02 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m06.mx.aol.com (mail_out_v34.13.) id l.a9.3062a708 (4262) for ; Thu, 31 Oct 2002 14:54:20 -0500 (EST) Message-ID: Date: Thu, 31 Oct 2002 14:54:20 EST To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_a9.3062a708.2af2e46c_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Subject: [Ieprep] New Internet Drafts Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_a9.3062a708.2af2e46c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: This is a corrected copy with the right hyperlinks to the 3 drafts: I have submitted the following 3 drafts: Requirements for Assured Service Capabilities in Voice over IP Architecture for Assured Service Capabilities in Voice over IP Examples for Provision of Preferential Treatment in Voice over IP These are revisions of previous drafts submitted to SIPPING. Since their initial submission, the discussion related to the subjects rasied in these drafts has moved to IEPREP. While these mostly deal with "Assured Service", or the intended service to replace "MLPP" in the military network, I believe that many of the concepts discussed are common with "Authorized Emergency" calls which IEPREP has been focusing on. In fact, "MLPP" in a military network is simply another form of "authorized emergency" priority calls. Please note that these drafts are jointly authored by myself (of "Artel") and Don Choi, of DISA, the agency responsible for establishment of standards and policies for the US Defense Network. These drafts can be found at: http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-req-00 .txt http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-arch-0 0.txt http://www.ietf.org/internet-drafts/draft-pierce-ieprep-pref-treat-examples-00 .txt Mike Pierce Artel --part1_a9.3062a708.2af2e46c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To:

This is a corrected copy with the right hyperlinks to the 3 drafts:

I have submitted the following 3 drafts:

Requirements for Assured Service Capabilities in Voice over IP
Architecture for Assured Service Capabilities in Voice over IP
Examples for Provision of Preferential Treatment in Voice over IP

These are revisions of previous drafts submitted to SIPPING. Since their initial submission, the discussion related to the subjects rasied in these drafts has moved to IEPREP.

While these mostly deal with "Assured Service", or the intended service to replace "MLPP" in the military network, I believe that many of the concepts discussed are common with "Authorized Emergency" calls which IEPREP has been focusing on. In fact, "MLPP" in a military network is simply another form of "authorized emergency" priority calls.

Please note that these drafts are jointly authored by myself (of "Artel") and Don Choi, of DISA, the agency responsible for establishment of standards and policies for the US Defense Network.

These drafts can be found at:

http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-req-00.txt
http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-arch-00.txt
http://www.ietf.org/internet-drafts/draft-pierce-ieprep-pref-treat-examples-00.txt

Mike Pierce
Artel
--part1_a9.3062a708.2af2e46c_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 15:29:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13292 for ; Thu, 31 Oct 2002 15:29:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VKVqo27290 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 15:31:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKVqv27287 for ; Thu, 31 Oct 2002 15:31:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13232 for ; Thu, 31 Oct 2002 15:29:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKV6v27230; Thu, 31 Oct 2002 15:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKTev27119 for ; Thu, 31 Oct 2002 15:29:40 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13144 for ; Thu, 31 Oct 2002 15:27:09 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 9D8B167103 for ; Thu, 31 Oct 2002 11:49:10 -0500 (EST) Date: Thu, 31 Oct 2002 15:29:27 -0500 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit Message-Id: <736E6C52-ED0F-11D6-BE27-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Subject: [Ieprep] draft-ietf-ieprep-requirements-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here are my own comments on this document. There is some overlap with Bill's comments, probably because before my current job I spent some years engineering and operating a multi-continent commercial IP network. I've tried to make specific suggestions on what edits I think are desirable to create a more acceptable Informational document, by way of suggestion. It is conceivable that other kinds of edits (which didn't occur to me so far) would also yield an improved document. I do think that it is desirable and useful to have Informational documents from NCS and other organisations describing what kinds of IEprep capabilities they desire to purchase. A document from Japan on their IAA system would be particularly helpful. I'm trying to organise my comments by the existing documents sectioning. Global comments are marked "meta". Ran rja@extremenetworks.com ------------------------------------------------------------------------ -------- Title: This document does not discuss "requirements" in the usual IETF sense of that word. So the title probably needs editing. Something more like this (edit to taste) would be clearer all around: "US NCS Perspectives on Internet Emergency Preparedness" Abstract: Same issue as with the title. The document does not discuss "requirements" in the usual IETF sense. This use of "requirements" is pretty common in USG/DoD circles, but is not common in IETF circles. Since the primary audience is IETF folks, not DoD folks, editing seems in order. I'd suggest altering the abstract to say that the document outlines the current GETS services using the PSTN and the kinds of GETS-like services that NCS would like to be able to obtain (under normal business arrangement) from VoIP service providers that are interconnected with the PSTN. Conventions: This section and using the capitalised "MUST/SHOULD/MAY" are both inappropriate in an Informational status RFC. That usage is normally only in a standards-track RFC (and rarely but sometimes in an Informational or Experimental protocol specification). Suggest deleting this text. Section 1, meta: It is unclear whether the author intends only VoIP applications when the phrase "Emergency Telecommunications Service" is used xor means other things in addition (e.g. email, web). This needs to be made more clear at a minimum. If only the voice applications are intended, that scoping needs to be a whole lot more clear than it is at present. Section 1, page 2: The claim "...public networking facilities experience severe stress due to damaged infrastructure and heavy traffic loads." might be true for the PSTN. I am aware of no evidence that this is true for the global Internet. For example, on 9/11/01 the Internet did NOT experience severe stress or (unusually) heavy traffic loads, even though there was substantial damaged infrastructure (particularly in lower Manhatten, NY). If the author means the PSTN, please say so. If the author means also the global Internet, please add at least a formal bibliographic citation to documentation supporting the claim (also to include in the REFERENCES section of this draft). Section 1.2, page ?: I think it is possible that the PSTN is migrating to VoIP, as this claims, but I do not think that it is certain to be the case. The PSTN architecture is very much tailored for voice services and the Internet architecture is quite deliberately general (not tailored for voice services). So it isn't really universally accepted that "convergence" is happening or guaranteed to happen. It would be helpful if this section were edited to make more clear whether the scope of this draft is primarily GETS-like voice (which is currently the bulk of the text in this draft) or some specific broader scope. Section 1.3: It would be better to rephrase as "user requirements" into something more like "NCS objectives" or "GETS objectives" or otherwise not use "requirements" in a manner that is not congruent with customary IETF usage of the word "requirements". Section 2: (Repeat comment on Section 1.3) Section 2: Does this mean just voice applications (as seems to be implied) or a broader range of applications ? If the broader range, it would be good to clearly delineate the intended scope. Section 2: Which users should be able to use which public telecom resources ? Today, not all IP Carriers are fully connected with the global Internet. The degree of peering/connectivity of a given carrier is typically governed by a set of business contracts (whose terms are usually not disclosed publicly) which in turn cause BGP routers to be configured in particular ways. The BGP configurations (and the forwarding tables derived from BGP) are the final determinant of what is actually reachable from a given location. SLAs have roughly nothing to do with this. Section 2: Rather than saying "we assume the presence of a service level agreement" it would be better to say something like: Current GETS services provided using the PSTN are provided under normal commercial contracts between NCS and various PSTN carriers. NCS envisions that it will arrange analogous contracts with IP carriers in the future for all IEprep services used or managed by NCS." Section 2: IP is a datagram service. It does not have a call setup phase. For the most part, the network is unaware of IP "sessions" existing. Certainly routers in the middle of the network are typically performing longest-prefix match forwarding of IP packets, with each packet being forwarded independently of each other packet. Different packets in an IP flow might have different drop probabilities or different routing (and hence different latency or jitter characteristics). This connectionless datagram nature of the Internet Architecture is fundamental, hence very unlikely to change. The phrase "session is established" is fairly meaningless in terms of the IP layer or the Internet Architecture. The Internet Architecture does not even possess a Session Layer formally, unlike the ISO OSI Model. Section 2: The discussion about labels needs to be edited so that it is specifically limited/scoped to voice calls that need to interconnect with the PSTN. That discussion is quite irrelevant for non-IEprep disconnected VoIP services, such as the one Bill Woodcock manages. The paper needs to reflect this reality. Section 2: "When networks reach traffic saturation..." needs to be edited to read "If networks reach traffic saturation...". It is common today for large IP Carriers to over-provision their backbones such that the backbone cannot be saturated. Access links not operated by that carrier (e.g. tail circuit into a Tier-2 ISP) might well get saturated, but it is not the case that all networks are vulnerable to saturation. Section 2: ETSI is a fine group, but their expertise is in GSM mobile phones and they do not define Internet Standards. Internet Standards are the province of the IETF. Section 2: It is not possible to prevent denial-of-service attacks or many other kinds of attacks. Carriers are typically NOT responsible for protecting customers from attacks -- customers are responsible for installing and maintaining their own security schemes (e.g. firewalls). So trying to place this burden on the IP Carrier is unreasonable and also inconsistent with the End-to-End Principle. Section 2: Most of the Internet does not have a concept of QoS. For this reason, the concept of "degraded QoS" also does not widely exist. This needs to be edited to scope it only to networks that happen to have some form of QoS. Such networks might constitute the null set today. Section 3: Experience so far with real-time traffic, particularly voice and video, over the Internet is that the challenges are primarily in selecting appropriately resilient codecs/vocoders -- NOT in changing the way the IP network itself is deployed. Experiments with use of Integrated Services (RSVP et alia) caused us to learn that such an approach cannot scale. DiffServ/IP ToS cannot provide fine-grained QoS and has not yet proven itself to be deployable on the large scale in a commercial (not research) IP network. Even the US DoD does not currently support DiffServ/IP ToS in its IP networks (in fact might not have *any* form of explicit QoS support today). Section 4: I am not sure what this means. Section 5: One of my concerns is that deploying additional mechanisms (e.g. QoS) into an IP network generally means increasing the vulnerabilities and operational risks of that network. This ought to be noted here. ------------------------------------------------------------------------ ----------- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 15:31:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13481 for ; Thu, 31 Oct 2002 15:31:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VKXfX27413 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 15:33:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKXfv27410 for ; Thu, 31 Oct 2002 15:33:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13453 for ; Thu, 31 Oct 2002 15:31:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKX1v27389; Thu, 31 Oct 2002 15:33:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKWcv27358 for ; Thu, 31 Oct 2002 15:32:38 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13317 for ; Thu, 31 Oct 2002 15:30:08 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 5FAC267103; Thu, 31 Oct 2002 11:52:15 -0500 (EST) Date: Thu, 31 Oct 2002 15:32:32 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Bill Woodcock , ieprep@ietf.org To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20021031123042.027c8830@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 14:06 America/Montreal, James M. Polk wrote: > Bill - this charter seems to describe networks *other* than yours > (because > of your choice of interconnectivity issues); therefore I believe your > discussion is out of scope for this list until *you* can change the > charter > to *not* state IEPREP directly involves the commercial > telecommunications > industry (which means at least also interconnectivity to the > PSTN/GSTN/CSN). No, Bill's comments aren't out of scope due to charter. Instead, the draft needs to be edited to specifically fit within the scope of this WG's charter and ensure that any reader of the draft is not confused about the intended scope of the draft. > One problem I see with you doing this is your intent on *not* > connecting to > IEPREP/ETS/GETS/GTPS services of any kind (so why are you commenting > at all > to this discussion that will not involve you or your network?). A good reason is that the draft under discussion appears to claim to apply to all networks -- not just those that choose to sell IEprep services. This is easily fixable by editing the draft under discussion -- and that is the right kind of fix to undertake. Regards, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 15:35:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13651 for ; Thu, 31 Oct 2002 15:35:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VKbk328129 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 15:37:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKbkv28126 for ; Thu, 31 Oct 2002 15:37:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13645 for ; Thu, 31 Oct 2002 15:35:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKb0v27578; Thu, 31 Oct 2002 15:37:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VKaHv27515 for ; Thu, 31 Oct 2002 15:36:17 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13570 for ; Thu, 31 Oct 2002 15:33:47 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 7988967103; Thu, 31 Oct 2002 11:55:54 -0500 (EST) Date: Thu, 31 Oct 2002 15:36:11 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Bill Woodcock'" , ieprep@ietf.org To: "Folts, Harold" From: RJ Atkinson In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D23A498@emshqs1.ncr.disa.mil> Message-Id: <64387391-ED10-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 14:26 America/Montreal, Folts, Harold wrote: > No, this is NOT "one user's" experience with the PSTN at all. Until such time as you get other organisations and other countries to represent themselves here and present their perspectives, preferably in their own documents about what services they use today and plan to use in the future, the rest of us (who aren't monetarily or contractually beholden to NCS) can only realistically know that the document represents your views based on your experience at NCS. The ongoing hand-waving that you speak for the whole world just is not credible by itself. Terribly sorry, but that is the reality of the situation. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 16:13:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15239 for ; Thu, 31 Oct 2002 16:13:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VLFpW30325 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 16:15:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLFpv30322 for ; Thu, 31 Oct 2002 16:15:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15234 for ; Thu, 31 Oct 2002 16:13:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLF4v30306; Thu, 31 Oct 2002 16:15:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLEav30286 for ; Thu, 31 Oct 2002 16:14:36 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15213 for ; Thu, 31 Oct 2002 16:12:05 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VL6xd08451; Thu, 31 Oct 2002 13:06:59 -0800 (PST) Date: Thu, 31 Oct 2002 13:06:59 -0800 (PST) From: Bill Woodcock To: "James M. Polk" cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <4.1.20021031123042.027c8830@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Thu, 31 Oct 2002, James M. Polk wrote: > ...public telecommunications capabilities at hand. These > capabilities include: conventional telephone, cellular phones, and > Internet access via online terminals, IP telephones.... Right. So Peter and I both operate global Internet networks over which global voice networks consisting of IP telephones operate. > Therefore, the Internet community needs to consider how it can best > support emergency management and recovery operations. ...and the principal purpose of the voice network that I operate is Internet infrastructure protection, emergency response, and operational change coordination. > this charter seems to describe networks *other* than yours; > therefore I believe your discussion is out of scope for this list Hm. Not quite sure how you come to this conclusion. > IEPREP directly involves the commercial telecommunications > industry (which means at least also interconnectivity to the PSTN/GSTN/CSN). Uh, I thought it explicitly included VoIP networks which _weren't_ interconnected with the PSTN. I think you guys need to make up your minds whether you're trying to require something of me or not. > this seems like a very good time for *you* to write an ID about the > issues and requirements involving Topology "End-to-End IP" from: Uh, I typically only take time away from operational work to respond to requests for my "ranting BS" from the IESG/IAB level. > I have read through ~10 emails that you (and maybe Ran) want > your Topology to be overlapping in nature (therefore everything changed) > with respect to the other 3 Topologies Please clarify this? My objection is to someone suggesting that they're requiring something of me (QoS or interconnection with arbitrary other networks being two examples) which I may either be unable to complete autonomously, which they may be unwilling to pay for, or which I may have neither engineering nor business motivation to do. > One problem I see with you doing this is your intent on *not* connecting to > IEPREP/ETS/GETS/GTPS services of any kind (so why are you commenting at all > to this discussion that will not involve you or your network?). Are they services, networks, or requirements? I can only "connect" my network with another network, not a "service" or a "requirement." If it won't involve me or my network, why is it called a "requirement?" -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 16:26:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15853 for ; Thu, 31 Oct 2002 16:26:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VLSFm30853 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 16:28:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLSFv30850 for ; Thu, 31 Oct 2002 16:28:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15823 for ; Thu, 31 Oct 2002 16:25:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLRRv30760; Thu, 31 Oct 2002 16:27:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLPjv30645 for ; Thu, 31 Oct 2002 16:25:45 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15753 for ; Thu, 31 Oct 2002 16:23:16 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VLJhd08720; Thu, 31 Oct 2002 13:19:44 -0800 (PST) Date: Thu, 31 Oct 2002 13:19:43 -0800 (PST) From: Bill Woodcock To: "Folts, Harold" cc: ieprep@ietf.org Subject: RE: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D23A498@emshqs1.ncr.disa.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > The objective of this initiative in the IETF is to provide > useful capabilites for disaster relief operations using the > Internet and packet-based technologies I'm not seeing any sort of needs-analysis draft in the ieprep-charter page. What mechanism did you employ to determine that these useful capabilities weren't already being provided by the Internet? The goals you state, as opposed to the mechanisms, are clearly better met by the Internet than by the PSTN already. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 16:32:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16039 for ; Thu, 31 Oct 2002 16:32:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VLY2W31139 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 16:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLY2v31136 for ; Thu, 31 Oct 2002 16:34:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16028 for ; Thu, 31 Oct 2002 16:31:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLXKv31118; Thu, 31 Oct 2002 16:33:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLW6v31016 for ; Thu, 31 Oct 2002 16:32:06 -0500 Received: from clifden.donelan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15950 for ; Thu, 31 Oct 2002 16:29:37 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #3) id 187Mv0-0003gk-00; Thu, 31 Oct 2002 16:31:58 -0500 Date: Thu, 31 Oct 2002 16:31:58 -0500 (EST) From: Sean Donelan To: RJ Atkinson cc: ieprep Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: <15ED73DD-ECEF-11D6-BE27-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Thu, 31 Oct 2002, RJ Atkinson wrote: > This is true, but incomplete. In at least 2 widely deployed > implementations, the code inside ip_input() looks for packets with the > magic IP ToS value set and then verifies that they are BGP packets (by > looking at protocol=TCP and port=BGP) and handles them with reduced > drop preference. The degree of reduced drop preference is unclear to > me (and is somewhat debatable) absent some scientific testing, but > notionally it is present. I'll admit I have not tried it recently. Proteon routers were very much ToS aware, and ToS bits could make a significant difference. But most of the other brand routers I tried, ToS seemed to be a no-op, except for locally originated packets. I haven't seen the router source code, so I don't know their precise handling of the ToS bits. Treating the router as a black-box, our testing didn't show any difference between packets with ToS bits and packets without ToS bits. But I didn't try every combination of packet, protocol, port, ToS, etc. So I may have missed the magic combination of priority bits. In any case, because the precise behavior isn't well documented it may not be a great idea to rely on a particular behavior. > It certainly is a potential threat. Many ISPs configure their access > routers to strip the IP ToS bits on all packets received from > customers -- in order to mitigate such threats. This last practice > is a de facto barrier to widespread DiffServ deployment. My experience is only ISPs doing MPLS mangle the ToS bits. Since I used to work with some IBM mainframes, which were ToS aware and got upset when people munged the ToS bits, it was most annoying. Although this may explain why we have recently (in the last 3 months) started seeing attacks containing packets with port 179. Before now I didn't make the connection why they were sending BGP packets to things that didn't talk BGP. I was assuming (dumb mistake) the routers didn't treat transit packets differently. But if the routers prioritize BGP packets over other packets, it would make a more effective DOS technique. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 17:03:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17346 for ; Thu, 31 Oct 2002 17:03:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM5Es01373 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 17:05:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM5Ev01368 for ; Thu, 31 Oct 2002 17:05:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17329 for ; Thu, 31 Oct 2002 17:02:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM44v01326; Thu, 31 Oct 2002 17:04:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM3tv01212 for ; Thu, 31 Oct 2002 17:03:55 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17267 for ; Thu, 31 Oct 2002 17:01:26 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VLvxd09417 for ; Thu, 31 Oct 2002 13:57:59 -0800 (PST) Date: Thu, 31 Oct 2002 13:57:59 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] draft-ietf-ieprep-framework-02.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > there is a maximum packet loss and delay for VoIP traffic, and > both are interdependent. For delays of ~200ms, a corresponding > drop rate of 5% is deemed acceptable. When delay is lower, a > 15-20% drop rate can be experienced and still considered > acceptable. Regardless of a definitive drop rate, it would seem > that interactive voice has a lower threshold of loss than other > elastic applications. No disagreement with any of that. Have you, however, been able to find any IP telephony (by your definition, SIP or equivalent) using site pairs which are experiencing interconnection performance worse than that? The only connection we've been able to find which failed to exceed PSTN quality was actually a satellite modem connection, so it was, in effect, tunnelled through the PSTN. And that was the link adjacent to the end-user, and was carrying no other traffic. Thus no amount of QoS, dif-serv, SLA, et cetera would have been of any help. My operational experience tells me that that's a generalizable truth. That unlike in the PSTN, in the Internet, if there's a path, it'll be sufficient, and if there isn't a path, no amount of QoS will fix the basic lack of ability to forward packets. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 17:07:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17469 for ; Thu, 31 Oct 2002 17:07:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM92d02130 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 17:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM92v02127 for ; Thu, 31 Oct 2002 17:09:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17436 for ; Thu, 31 Oct 2002 17:06:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM7uv02065; Thu, 31 Oct 2002 17:07:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM6qv01445 for ; Thu, 31 Oct 2002 17:06:52 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17391 for ; Thu, 31 Oct 2002 17:04:23 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id E491567103; Thu, 31 Oct 2002 13:26:28 -0500 (EST) Date: Thu, 31 Oct 2002 17:06:44 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: Sean Donelan From: RJ Atkinson In-Reply-To: Message-Id: <0ACA3668-ED1D-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 16:31 America/Montreal, Sean Donelan wrote: > Proteon routers were very much > ToS aware, and ToS bits could make a significant difference. I still miss my Proteons. Agree. > Treating the router as a black-box, our testing didn't show any > difference > between packets with ToS bits and packets without ToS bits. Interesting and useful data. > In any case, because the precise behavior isn't well documented it > may not be a great idea to rely on a particular behavior. Fair. > My experience is only ISPs doing MPLS mangle the ToS bits. Since I > used > to work with some IBM mainframes, which were ToS aware and got upset > when > people munged the ToS bits, it was most annoying. Interesting. > Although this may explain why we have recently (in the last 3 months) > started seeing attacks containing packets with port 179. Before now I > didn't make the connection why they were sending BGP packets to things > that didn't talk BGP. I was assuming (dumb mistake) the routers didn't > treat transit packets differently. But if the routers prioritize BGP > packets over other packets, it would make a more effective DOS > technique. Ah. I was unclear; my bad. I'm not sure whether or not *transit* packets are handled differently in a default router config these days. I should have said that on the receive-side *for packets destined to the receiving router* there was (notional) intelligence to drop other packets rather than drop incoming BGP packets. As your tests didn't indicate it made much difference, this implementation detail might not matter in practice. Thanks, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 17:08:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17492 for ; Thu, 31 Oct 2002 17:08:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VMA7302170 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 17:10:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VMA7v02167 for ; Thu, 31 Oct 2002 17:10:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17484 for ; Thu, 31 Oct 2002 17:07:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM93v02144; Thu, 31 Oct 2002 17:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM8jv02089 for ; Thu, 31 Oct 2002 17:08:45 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17403 for ; Thu, 31 Oct 2002 17:06:16 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 1BE4467103; Thu, 31 Oct 2002 13:28:22 -0500 (EST) Date: Thu, 31 Oct 2002 17:08:37 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20021031123042.027c8830@localhost> Message-Id: <4DFA9D1A-ED1D-11D6-BE27-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 14:06 America/Montreal, James M. Polk wrote: > I have read through ~10 emails that you (and maybe Ran) want > your Topology to be overlapping in nature (therefore everything > changed) > with respect to the other 3 Topologies - yet your unclear reasoning > seems > to point to your uniqueness relative to the other Topologies. I don't recall commenting directly on topologies. So I find the above pretty confusing and am not at all sure of your meaning. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 17:12:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17680 for ; Thu, 31 Oct 2002 17:12:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VMEEu02372 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 17:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VMEEv02369 for ; Thu, 31 Oct 2002 17:14:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17655 for ; Thu, 31 Oct 2002 17:11:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VMD1v02323; Thu, 31 Oct 2002 17:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VMC7v02271 for ; Thu, 31 Oct 2002 17:12:07 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17536 for ; Thu, 31 Oct 2002 17:09:38 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VM6Bd09626 for ; Thu, 31 Oct 2002 14:06:11 -0800 (PST) Date: Thu, 31 Oct 2002 14:06:11 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] draft-ietf-ieprep-framework-02.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > This problem is further compounded when toll-quality service is > expected because it assumes a default service model that is > better than best effort. This in turn can increase the > probability that a form of call-blocking can occur with VoIP or > IP telephony traffic. I'm not able to make sense of this. What's meant by "toll-quality service?" I'm perhaps incorrectly reading that as "voice quality similar to that experienced by users of the PSTN." If that interpretation is as intended, it implies that the authors believe that IP telephony on the commodity Internet doesn't universally exceed that threshold. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 17:20:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17918 for ; Thu, 31 Oct 2002 17:20:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VMMAP02696 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 17:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VMMAv02693 for ; Thu, 31 Oct 2002 17:22:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17883 for ; Thu, 31 Oct 2002 17:19:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VML4v02623; Thu, 31 Oct 2002 17:21:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM0lv00572 for ; Thu, 31 Oct 2002 17:00:47 -0500 Received: from bur-smtp4.genuity.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17028 for ; Thu, 31 Oct 2002 16:58:18 -0500 (EST) Received: from share1.wobnma1-dc1.genuity.net (share1.wobnma1-dc1.genuity.net [4.2.130.40]) by bur-smtp4.genuity.com (8.11.3/8.11.2) with ESMTP id g9VLvvH26657 for ; Thu, 31 Oct 2002 16:57:57 -0500 (EST) X-Recipient: Received: from localhost (kcooper@localhost) by share1.wobnma1-dc1.genuity.net (8.11.6/8.11.6) with ESMTP id g9VM0e704123 for ; Thu, 31 Oct 2002 22:00:40 GMT X-Authentication-Warning: share1.wobnma1-dc1.genuity.net: kcooper owned process doing -bs Date: Thu, 31 Oct 2002 22:00:40 +0000 (GMT) From: "Kelly J. Cooper" X-X-Sender: kcooper@share1.wobnma1-dc1.genuity.net To: ieprep Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Thu, 31 Oct 2002, Sean Donelan wrote: > My experience is only ISPs doing MPLS mangle the ToS bits. Since I used > to work with some IBM mainframes, which were ToS aware and got upset when > people munged the ToS bits, it was most annoying. I believe some ISPs are re-marking packets at the customer edge to indicate higher priority for VoIP (and a 0 priority for everything else) as well. Regards, Kelly J. -- Kelly J. Cooper - Security Engineer, CISSP GENUITY - Main # - 800-632-7638 Woburn, MA 01801 - http://www.genuity.net _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 18:10:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19611 for ; Thu, 31 Oct 2002 18:10:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VNCDf05559 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 18:12:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNCDv05556 for ; Thu, 31 Oct 2002 18:12:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19588 for ; Thu, 31 Oct 2002 18:09:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNB5v05519; Thu, 31 Oct 2002 18:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNAKv05492 for ; Thu, 31 Oct 2002 18:10:20 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19500 for ; Thu, 31 Oct 2002 18:07:50 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VN4Nd10662 for ; Thu, 31 Oct 2002 15:04:23 -0800 (PST) Date: Thu, 31 Oct 2002 15:04:23 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] draft-ietf-ieprep-framework-02.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > Primary Objectives in support of authorized emergency calls: > 2) Interaction with PSTN > The second objective involves the interaction of IP telephony > signaling with existing PSTN support for emergency related voice > communications. As mentioned above in Section 1.2, standard > T1.631 [26] specifies emergency code points for SS7. > Specifically, the National Security and Emergency Preparedness > (NS/EP) Calling Party Category code point is defined for ISUP IAM > messages used by SS7 [26]. Hence, our objective in the > interaction between the PSTN and IP telephony with respect to > IEPS (and national indicators) is a direct mapping between > related code points. This seems problematic to me, in exactly the same way as if a user came before the IETF with a draft which stated that that their objective was to have carriers peer. That's nice, but that's a business decision to be made by the carriers, and it doesn't really serve any useful goal to say that it's nice in an official IETF document. This seems like another statement of the "We like toast!" variety. Simply stating that "interaction with the PSTN is a primary objective" isn't going to get the PSTN carriers to run around buying connections to all the different IP telephony networks, and I doubt the NCS would be really happy paying the marked-up pass-through cost of doing so, even if the telcos felt like doing it. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 18:50:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20658 for ; Thu, 31 Oct 2002 18:50:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VNqe907581 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 18:52:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNqev07578 for ; Thu, 31 Oct 2002 18:52:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20636 for ; Thu, 31 Oct 2002 18:50:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNpBv07460; Thu, 31 Oct 2002 18:51:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNoTv07419 for ; Thu, 31 Oct 2002 18:50:29 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20559 for ; Thu, 31 Oct 2002 18:47:58 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id g9VNiWd11176 for ; Thu, 31 Oct 2002 15:44:32 -0800 (PST) Date: Thu, 31 Oct 2002 15:44:32 -0800 (PST) From: Bill Woodcock To: ieprep@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] draft-ietf-ieprep-framework-02.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > 3.1. Alternate Path Routing > This objective involves the ability to discover and use a > different path to route IP telephony traffic around congestion > points and thus avoid them. Ideally, the discovery process would > be accomplished in an expedient manner (possibly even a priori to > the need of its existence). At this level, we make no > requirements as to how the alternate path is accomplished, or > even at which layer it is achieved -- e.g., the network versus > the application layer. But this kind of capability, at least in > a minimal form, would help contribute to increasing the > probability of call completion of IEPS traffic. I cannot begin to express the depth of my disagreement with this assertion. _Nothing short of a backhoe_ will have a more adverse effect upon the likelihood of call completion than routing it on a path other than that of the production traffic. The degree of increased complexity _which has no other purpose_ and _would receive no other use_. Emergency systems which share no fate with production systems, don't get regular use, and aren't associated with any revenue are, without question, doomed to failure. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 19:15:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21221 for ; Thu, 31 Oct 2002 19:15:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA10H5k09157 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 19:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10H5v09154 for ; Thu, 31 Oct 2002 19:17:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21195 for ; Thu, 31 Oct 2002 19:14:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10G3v09117; Thu, 31 Oct 2002 19:16:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10Fkv09102 for ; Thu, 31 Oct 2002 19:15:46 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21178 for ; Thu, 31 Oct 2002 19:13:15 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 82FF567103; Thu, 31 Oct 2002 15:35:21 -0500 (EST) Date: Thu, 31 Oct 2002 19:15:34 -0500 Subject: Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep To: "Kelly J. Cooper" From: RJ Atkinson In-Reply-To: Message-Id: <0A6C591E-ED2F-11D6-8A6A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 17:00 America/Montreal, Kelly J. Cooper wrote: > I believe some ISPs are re-marking packets at the customer edge to > indicate higher priority for VoIP (and a 0 priority for everything > else) > as well. Very interesting. Thanks for sharing. Are those ISPs also deploying support for IP ToS/DiffServ with multiple queues and so forth ? Is the deployment large-scale in a production network ? Learning more about actual deployment experience with such would be very helpful for the discussion here, IMHO. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 19:18:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21278 for ; Thu, 31 Oct 2002 19:18:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA10K0n09262 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 19:20:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10K0v09259 for ; Thu, 31 Oct 2002 19:20:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21273 for ; Thu, 31 Oct 2002 19:17:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10J1v09237; Thu, 31 Oct 2002 19:19:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10Iav09220 for ; Thu, 31 Oct 2002 19:18:36 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21240 for ; Thu, 31 Oct 2002 19:16:05 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 143BD67103; Thu, 31 Oct 2002 15:38:13 -0500 (EST) Date: Thu, 31 Oct 2002 19:18:27 -0500 Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep@ietf.org To: Bill Woodcock From: RJ Atkinson In-Reply-To: Message-Id: <711E21F0-ED2F-11D6-8A6A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 18:04 America/Montreal, Bill Woodcock wrote: > Simply stating that "interaction with the PSTN is a primary objective" > isn't going to get the PSTN carriers to run around buying connections > to all the different IP telephony networks, and I doubt the NCS would > be really happy paying the marked-up pass-through cost of doing so, > even if the telcos felt like doing it. Bill, To be fair, if NCS have budget to do it and think it is wise use of their budget (and it doesn't contravene whatever rules govern that budget), then I think that is their call to make -- not the IETF's call -- for the same reason that you outline that "obtaining peering" is a business decision among consenting ISPs rather than an IETF decision. I might share your sense that it is likely to be expensive, but I strongly think IETF needs to stay far far away from telling people what kinds of business those people may/should/must undertake (or not undertake). Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 19:21:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21399 for ; Thu, 31 Oct 2002 19:21:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA10NCM09402 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 19:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10NCv09399 for ; Thu, 31 Oct 2002 19:23:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21395 for ; Thu, 31 Oct 2002 19:20:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10M1v09358; Thu, 31 Oct 2002 19:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10Lcv09340 for ; Thu, 31 Oct 2002 19:21:38 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21334 for ; Thu, 31 Oct 2002 19:19:07 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id gA10Fed11808; Thu, 31 Oct 2002 16:15:40 -0800 (PST) Date: Thu, 31 Oct 2002 16:15:40 -0800 (PST) From: Bill Woodcock To: RJ Atkinson cc: ieprep@ietf.org Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt In-Reply-To: <711E21F0-ED2F-11D6-8A6A-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > To be fair, if NCS have budget to do it and think it is wise > use of their budget (and it doesn't contravene whatever rules govern > that budget), then I think that is their call to make -- not the IETF's > call > -- for the same reason that you outline that "obtaining peering" is > a business decision among consenting ISPs rather than an IETF decision. Right... So we don't have IETF documents saying that it's nice to peer, and we don't have IETF documents saying that we like toast, and I don't see that we should have IETF documents which say that it would be nice if the PSTN connected to the rest of the world. Sure, it would be nice, but are they going to do it? None of our business, in an institutional sense. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 19:25:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21494 for ; Thu, 31 Oct 2002 19:25:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA10R8Y09587 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 19:27:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10R8v09584 for ; Thu, 31 Oct 2002 19:27:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21483 for ; Thu, 31 Oct 2002 19:24:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10Q2v09528; Thu, 31 Oct 2002 19:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10PXv09505 for ; Thu, 31 Oct 2002 19:25:33 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21417 for ; Thu, 31 Oct 2002 19:23:02 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 2741B67103; Thu, 31 Oct 2002 15:45:09 -0500 (EST) Date: Thu, 31 Oct 2002 19:25:22 -0500 Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep@ietf.org To: Bill Woodcock From: RJ Atkinson In-Reply-To: Message-Id: <68FF7924-ED30-11D6-8A6A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I know of work on voice over IP over low-bandwidth HF Radio done by US Navy in the early 90s. It worked fine. The critical thing to making it all work was to pick a robust/resilience vocoder algorithm. No QoS was needed. And available bandwidth (for all traffic) was a lot less than 1 Mbps. I'm not suggesting that VoIP is trivial to make work, just that a lot of the anxiety about network QoS seems to be misplaced given various experiments and various real deployments. I think getting the SIP bits working as intended can be pretty hard, for example. Ran On Thursday, Oct 31, 2002, at 16:57 America/Montreal, Bill Woodcock wrote: >> there is a maximum packet loss and delay for VoIP traffic, and >> both are interdependent. For delays of ~200ms, a corresponding >> drop rate of 5% is deemed acceptable. When delay is lower, a >> 15-20% drop rate can be experienced and still considered >> acceptable. Regardless of a definitive drop rate, it would seem >> that interactive voice has a lower threshold of loss than other >> elastic applications. > > No disagreement with any of that. [...] > My operational experience tells me that that's a generalizable truth. > That unlike in the PSTN, in the Internet, if there's a path, it'll be > sufficient, and if there isn't a path, no amount of QoS will fix the > basic lack of ability to forward packets. > > -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Oct 31 19:31:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21647 for ; Thu, 31 Oct 2002 19:31:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA10XDi09758 for ieprep-archive@odin.ietf.org; Thu, 31 Oct 2002 19:33:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10XDv09755 for ; Thu, 31 Oct 2002 19:33:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21620 for ; Thu, 31 Oct 2002 19:30:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10W2v09738; Thu, 31 Oct 2002 19:32:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA10Vuv09720 for ; Thu, 31 Oct 2002 19:31:56 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21608 for ; Thu, 31 Oct 2002 19:29:25 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 5EAC567103; Thu, 31 Oct 2002 15:51:32 -0500 (EST) Date: Thu, 31 Oct 2002 19:31:46 -0500 Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ieprep@ietf.org To: Bill Woodcock From: RJ Atkinson In-Reply-To: Message-Id: <4D74530F-ED31-11D6-8A6A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Oct 31, 2002, at 18:44 America/Montreal, Bill Woodcock wrote: > >> 3.1. Alternate Path Routing >> This objective involves the ability to discover and use a >> different path to route IP telephony traffic around congestion >> points and thus avoid them. Ideally, the discovery process would >> be accomplished in an expedient manner (possibly even a priori to >> the need of its existence). At this level, we make no >> requirements as to how the alternate path is accomplished, or >> even at which layer it is achieved -- e.g., the network versus >> the application layer. But this kind of capability, at least in >> a minimal form, would help contribute to increasing the >> probability of call completion of IEPS traffic. > > I cannot begin to express the depth of my disagreement with this > assertion. _Nothing short of a backhoe_ will have a more adverse > effect upon the likelihood of call completion than routing it on a path > other than that of the production traffic. And actually, this "requirement" is one driven by a PSTN-like architecture where routing is NOT dynamic and instead is static, configured at call setup time. The Internet does not have that problem so doesn't need the above "requirement". With the IP world's dynamic routing, the above requirement is not appropriate or helpful to achieving better quality connectivity during a calamity. The 9/11 calamity, several earthquakes, and sundry other disasters around the world have shown that dynamic IP routing is nearly impossible to beat. To give another example, the Iraqis reportedly used dynamic IP routing to keep some of their command & control networks up and working during the Gulf War -- despite extensive Allied bombing. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep