Re: [Ecrit] draft-polk-local-emergency-rph-namespace-01.txt was Re:draft-ietf-ecrit-local-emergency-rph-namespace-01

["DOLLY, MARTIN C (ATTSI)" <[e-mail]>]

James

Thanks. What is the target for approval?

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 <[e-mail]>
To: DOLLY, MARTIN C (ATTSI); Janet P Gunn <[e-mail]>; James M. Polk <[e-mail]>
Cc: [e-mail] <[e-mail]>
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 
>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 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.
>[e-mail]
>[phone]
>
>
>
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Janet P Gunn
>Sent: Thursday, June 16, 2011 9:52 AM
>To: James M. Polk
>Cc: [e-mail]
>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" <[e-mail]>
>To:
>Janet P Gunn/USA/CSC@CSC, Janet P Gunn/USA/CSC@CSC
>Cc:
>[e-mail]
>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 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 e 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 o of
> >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 itself 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 networkÃkâ€Â, 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 preferentitial    treatment of marked
> >traffic great preferenceâ€Â (which is also redundant).
> >
> >I still prefer
> >
> >“Incorrectly using this namesespace 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
> >[e-mail]
> ><https://www.ietf.org/mailman/listinfo/ecrit>ht 
> tps://www.ietf.org/mailman/listinfo/ecrit
>