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