Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01
"James M. Polk" <jmpolk@cisco.com> Thu, 16 June 2011 01:24 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 80FD011E8163 for <ecrit@ietfa.amsl.com>; Wed, 15 Jun 2011 18:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uy1yIwuHWcjm for <ecrit@ietfa.amsl.com>; Wed, 15 Jun 2011 18:24:31 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8208E11E8080 for <ecrit@ietf.org>; Wed, 15 Jun 2011 18:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=7251; q=dns/txt; s=iport; t=1308187471; x=1309397071; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=LvjuiIp21Qrd0STYXOWxApwacTiI7SUrR6gw4xXBiTU=; b=WhZQYq+zfCF7ZBQHgO8lAdqqCwzH/agNaqf+gaw1Ao1vH3avWYr/8v5z Bp8Kp3A3UiJaE0fIJNFx5wKvDnK5l8jbutNoWNRbHpuqJYzZtc8gODeyD vDXeOfHLDgFgUEuqB8BF2zs058yMutiOsWa2071Z8D2o/tCh3mxazzcUC Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANZa+U2rRDoI/2dsb2JhbABSpl93q02eL4YmBIcamkc
X-IronPort-AV: E=Sophos;i="4.65,372,1304294400"; d="scan'208";a="337962635"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2011 01:24:31 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5G1OUbn011648; Thu, 16 Jun 2011 01:24:30 GMT
Message-Id: <201106160124.p5G1OUbn011648@mtv-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 15 Jun 2011 20:24:29 -0500
To: Janet P Gunn <jgunn6@csc.com>, Janet P Gunn <jgunn6@csc.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <OFA7971003.AA6DF2E9-ON852578B0.00679525-852578B0.0067D397@ csc.com>
References: <C87DE073.27647%mlinsner@cisco.com> <OF9A370283.14EE1E7E-ON85257776.003DDA78-85257776.003DFFBF@csc.com> <A88F12A7-9A91-43A8-971D-69E1AB842606@nostrum.com> <OF968BAE2F.50D07487-ON85257876.0069D185-85257876.006A4187@csc.com> <OFA7971003.AA6DF2E9-ON852578B0.00679525-852578B0.0067D397@csc.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-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 01:24:32 -0000
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 "local 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 emergencyâ? you're 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 of >emergencyâ, at least for the caller. 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 âendâ? can a B2BUA by itself represent 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â? Is that the same as a PSAP? you're 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 networkâ, is it allowed to use this namespace? 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â could mean many different >things. Second, given that you have 5 different >priority levels, it is unlikely that they ALL >âgive preferential treatment of marked >traffic great preferenceâ (which is also redundant). > >I still prefer > >âIncorrectly using this namespace within the >Resource-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 section, 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
- [Ecrit] draft-ietf-ecrit-local-emergency-rph-name… Marc Linsner
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Janet P Gunn
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Janet P Gunn
- [Ecrit] draft-ietf-ecrit-local-emergency-rph-name… Janet P Gunn
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… James M. Polk
- [Ecrit] draft-polk-local-emergency-rph-namespace-… Janet P Gunn
- Re: [Ecrit] draft-polk-local-emergency-rph-namesp… DOLLY, MARTIN C (ATTSI)
- Re: [Ecrit] draft-polk-local-emergency-rph-namesp… James M. Polk