Re: [Ecrit] draft-polk-local-emergency-rph-namespace-01.txt was Re:draft-ietf-ecrit-local-emergency-rph-namespace-01
"James M. Polk" <jmpolk@cisco.com> Thu, 16 June 2011 19:36 UTC
Return-Path: <jmpolk@cisco.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0B11E8143 for <ecrit@ietfa.amsl.com>; Thu, 16 Jun 2011 12:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.751
X-Spam-Level:
X-Spam-Status: No, score=-108.751 tagged_above=-999 required=5 tests=[AWL=-1.848, BAYES_00=-2.599, MANGLED_OFF=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLP7CsOmF4m8 for <ecrit@ietfa.amsl.com>; Thu, 16 Jun 2011 12:36:14 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6716011E8110 for <ecrit@ietf.org>; Thu, 16 Jun 2011 12:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=11365; q=dns/txt; s=iport; t=1308252974; x=1309462574; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=e2RIG1eHJonmFYhl6WlZCdfqzi1srj8HP6eI93wE5dQ=; b=DEetSuozOOsH5xoPdrIJLZWBWSt3Mz8st2Qt8PY49gHqYIjHBdFcV9MJ yuLS/29cHGZb5jjkaVbG/4vFwZO6JS3RgKV5uIaY0h7Pw6/8buagKQ0oi 4hm7r0weFS0vRNIioUvSGAKWXj21g6Ff9EHmdCcv3siyLhjIuuiPLZGn+ 0=;
X-IronPort-AV: E=Sophos;i="4.65,377,1304294400"; d="scan'208";a="715043868"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2011 19:35:49 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5GJZm6f019945; Thu, 16 Jun 2011 19:35:48 GMT
Message-Id: <201106161935.p5GJZm6f019945@mtv-core-1.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 16 Jun 2011 14:35:47 -0500
To: "DOLLY, MARTIN C (ATTSI)" <md3135@att.com>, jmpolk@cisco.com
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBF21@gaalpa1msgusr7e.u gd.att.com>
References: <14C85D6CCBE92743AF33663BF5D24EBA093DBF21@gaalpa1msgusr7e.ugd.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] draft-polk-local-emergency-rph-namespace-01.txt was Re:draft-ietf-ecrit-local-emergency-rph-namespace-01
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2011 19:36:15 -0000
At 01:43 PM 6/16/2011, DOLLY, MARTIN C (ATTSI) wrote: >James > >Thanks. What is the target for approval? this is no longer a WG item (don't get me started on that without beers in front of us!), the PROTO write-up has already written and is about to go to the IESG as an individual submission on a standards track - so it could be an RFC within 2-3 months. Is that the kind of answer you were looking for (wrt "target for approval")? cheers James >Regards, > >Martin >Martin C. Dolly >Sent to you by AT&T... America's Fastest Mobile >Broadband Network. Rethink Possible. >+1.609.903.3360 > >----- Original Message ----- >From: James M. Polk <jmpolk@cisco.com> >To: DOLLY, MARTIN C (ATTSI); Janet P Gunn ><jgunn6@csc.com>; James M. Polk <jmpolk@cisco.com> >Cc: ecrit@ietf.org <ecrit@ietf.org> >Sent: Thu Jun 16 14:25:22 2011 >Subject: RE: [Ecrit] >draft-polk-local-emergency-rph-namespace-01.txt >was Re:draft-ietf-ecrit-local-emergency-rph-namespace-01 > >At 10:22 AM 6/16/2011, DOLLY, MARTIN C (ATTSI) wrote: > >Hello, > > > >I agree that âqueuingâ as a method needs to >o > >be mentioned, as it will be used in commercial deployments. > >likely in the US, but not likely in some other >markets. The queuing method is listed as the >method of use, but the doc clearly states the >preemption method is not prevented either. > > > > >Also, à is the term in the namespace âesnetâ global? > >verses being jug just US based? > >What in the IETF is only US based (that's standards track)? > >To your question - of course it's a global >namespace, as I call out 911 (which isn't only US >based), 112 (used by 3GPP - and nearly ubiquitous >throughout European GSM systems), and 999 (used >in the UK) as the style of calls this namespace is intended for. > >James > > > > >Regards, > > > >Martin Dolly > >Lead Member Technical Staff > >Core & Government/Regulatory Standards > >AT&T Services, Inc. > >md3135@att.com > >+1-609-903-3360 > > > > > > > >From: ecrit-bounces@ietf.org > >[mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn > >Sent: Thursday, June 16, 2011 9:52 AM > >To: James M. Polk > >Cc: ecrit@ietf.org > >Subject: [Ecrit] > >draft-polk-local-emergency-rph-namespace-01.txt > >was Re:draft-ietf-ecrit-local-emergency-rph-namespace-01 > > > > > >James, > > > >Apologies for the cut and paste error on the > >current document name- fixed now. > > > >I still think it is important that queuing be > >MENTIONED in the Intro- even if it is a vague as > >"...possibly in addition to, or instead of, queuing" > > > >For the rest, if no one else agrees with my > >concerns, I will plead guilty to being pedantic, and let it go. > > > >You already fixed my primary concern. > > > >Janet > >, > > > >From: > >"James M. Polk" <jmpolk@cisco.com> > >To: > >Janet P Gunn/USA/CSC@CSC, Janet P Gunn/USA/CSC@CSC > >Cc: > >ecrit@ietf.org > >Date: > >06/15/2011 09:24 PM > >Subject: > >Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 > > > > > > > > > > > >At 01:53 PM 6/15/2011, Janet P Gunn wrote: > > > > >Comments on the new version > > > > > > > > >In the second paragraph of the Intro, I suggest > > >changing "understandable" to "understood", to > > >better parallel the wording in 4412. > > > > > >I am still concerned that the Introduction > > >mentions ONLY "MLPP-like" behavior (and does not > > >mention queuing AT ALL), when the namespace is > > >being registered as "queue-based". I have no > > >problem with the discussion of MLPP-like > > >behavior- but the Intro needs to mention queueing AS WELL. > > > >I disagree. The Intro is merely informative, and > >the above request is treating the queuing as > >normative, which is a limitation I do not want to do. > > > > > > >I also still think that "MLPP - like behavior > > >without the prememption", and without queueing, > > >is pretty useless. It cannot "ensure more the > > >important calls are established or retained" > > > >sure it can. > > > >voice isn't the only think that is traversing the > >routers, even within an ESInet. > > > > > > >Furthermore, the second part of the sentence is > > >a non sequitor - "THEREFORE (my caps) the > > >"esnet" namespace is given 5 priority-levels". > > > >what was the sentence before and after the one > >you quote? They provide some context to having > >more than one or two priority-levels. > > > > >The need for 5 priority levels is orthogonal to > > >whether it is MLPP-like or queue-based. If you > > >got rid of the "therefore", and made it two sentences, it would be fine. > > > >"therefore" is concluding what was just said to > >justify why more than 1 or 2 priority-levels are > >being assigned to this namespace. > > > > > > >In section 2, I still have problems with this sentence > > > > > > "The "esnet" namespace SHOULD only be used in times of an emergency, > > > where at least one end of the signaling is within a local emergency > > > organization." > > > > > >This, of course, begs the question -what is the > > >definition of a ââ¬Ã à âtime of emergencyâÃÂ? > > > >you mean locaal emergency" right? > > > >Is it not clear that in local emergencies one > >(effectively) dials a number like 911 or 112 or 999? > > > >Who does this type of dialing? > > > >answer - local citizens > > > >Who do they call? > > > >answer - PSAPs > > > >I'm not going to define each of these terms - > >especially a highly subjective one like "times of > >an emergency" (which is a phrase, not a term). > >Citizens self-determine when they are experiences > >or witnessing a time of emergency and either act on it or choose not to. > > > >The point is that this is generally (hence the > >SHOULD) for citizen-to-authority communications, > >not authority-to-authority or > >authority-to-citizen communications; and I'm not > >going to define any of those phrases either). > > > > >Does some authority have to formally declare > a âtime of e emergencyâÃÂ? > > > >you're kre killing me here.... it's > >citizen-to-authority communication like the diagram shows. > > > >If someone is breaking into your house, do you > >really need to wait for an authority to declare > >"a time of emergency" before you call 911? really?! > > > > >It would seem that, by definition, every > > >911/112/999 call represents a âtime o of >f > > >emergencyâÃÂ, at least for the calller. > > > >>yeah... so what can you conclude from that? That > >maybe its all about citizen-to-authority > >communications (which is shown in the diagram)? > > > > > > >And what do you mean by âone end of > > signaling? Is a B2BUA an âenˆ âendâÃÂ? > > > >can a B2BUA by itselfself representt a citizen, or > >does a B2BUA continue the received signaling from > >a UA (albeit as a separate dialog or call leg) > >towards a PSAP for the 911/112/999 call? > > > >This document is NOT building an architecture, > >not even attempting to, and I'm not inclined > to be drug down that path either. > > > > > > > > >What is the definition of âa local emergency > > >organizationÃnâÃÂÃÂ? Is that the same as a PSAP? > > > >you'rre killing me here (again)... do I need to > >define each word in this ID before you agree to consider it? > > > >I've got a better idea, I can remove the context > >for why this namespace is needed and just make it > >a 3 page IANA registration doc. That solves all > >the terminology issues (by not having any). > > > >But seriously, even the abstract draws this distinction: > > > > "... for local emergency > > usage to a public safety answering point (PSAP) ..." > > > > > > >If a PSAP is directly connected to the (public) > > >Service Provider network, without a separate > > >âESI n networkÃkâÃÂ, is it allowed to use this namespacee? > > > > >which Internet police would prevent this? > > > >This document cannot define all the different > >network configurations possible, nor should it try. > > > > > > > > >At the end of 3.2, > > > "The remaining rules originated in RFC 4412 apply with regard to an > > > RP actor, who understands more than one namespace, and MUST maintain > > > its locally significant relative priority order." > > >is still awkwardly worded, but the content is OK. > > > >I'm going to stick with your "ok"... > > > > > > > > >In section 5 I still have problems following this sentence > > > > > >"...the implications of using this > > > namespace within the field incorrectly can potentially cause a large > > > impact on a network, given that this indication is to give > > > preferential treatment of marked traffic great preference within the > > > network verses other traffic. " > > > > > >First, âmarkedâàcoulcould mean many different > > >things. Second, given that you have 5 different > > >priority levels, it is unlikely that they ALL > > >âgive preferentitial treatment t of marked > > >traffic great preferenceâà(which is also redundant). > > > > > >I still prefer > > > > > >âIncorrectly using this namesespace within the > > >ReResource-Priority header field can cause a large > > >impact on a network. For some priority > > >values, this namespace can give great > > >preference within the network over other traffic.âà> >This is the Sec-Cons sectioon, and the idea of > >marked packets or calls is the proper description. > > > > > > >Finally, I think it would make sense to include > > >an informative reference for "MLPP-like behavior"- perhaps 4411. > > > >4411 creates, defines, describes how the > >preemption indication is communicated, which has > >nothing directly to do with this doc. If > >anything, MLPP is described in 4412 which is > >already a normative reference in this doc. > > > >James > > > >BTW - the subject line is wrong above, it's not > >"draft-ietf-ecrit-...-01.txt" anymore, it's > >"draft-polk-...-01.txt", making this a non-WG > >item. This gives me a far greater latitude in how I edit the doc... > > > > > > > > >Janet > > > > > >This is a PRIVATE message. If you are not the > > >intended recipient, please delete without > > >copying and kindly advise us by e-mail of the mistake in delivery. > > >NOTE: Regardless of content, this e-mail shall > > >not operate to bind CSC to any order or other > > >contract unless pursuant to explicit written > > >agreement or government initiative expressly > > >permitting the use of e-mail for such purpose. > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > ><https://www.ietf.org/mailman/listinfo/ecrit>ht > > tps://www.ietf.org/mailman/listinfo/ecrit > >
- Re: [Ecrit] draft-polk-local-emergency-rph-namesp… DOLLY, MARTIN C (ATTSI)
- Re: [Ecrit] draft-polk-local-emergency-rph-namesp… James M. Polk
- Re: [Ecrit] draft-polk-local-emergency-rph-namesp… DOLLY, MARTIN C (ATTSI)