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,

IETF individual, with SDO support would work for us

Thanks

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); [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Sent: Thu Jun 16 15:35:47 2011
Subject: Re: [Ecrit] draft-polk-local-emergency-rph-namespace-01.txt   was Re:draft-ietf-ecrit-local-emergency-rph-namespace-01

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 <[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
>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.
> >[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 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
> > >[e-mail]
> > ><https://www.ietf.org/mailman/listinfo/ecrit>ht
> > tps://www.ietf.org/mailman/listinfo/ecrit
> >