Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 28 Apr 2011 12:12:25 +0200

Hi, 

See in-line. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, April 28, 2011 3:52 AM
> To: Romascanu, Dan (Dan)
> Cc: The IESG; [email-masked]; 
> [email-masked]; [email-masked] Org
> Subject: Re: Dan Romascanu's Discuss on 
> draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT)
> 
> Please see inline for my responses to this:
> On Apr 27, 2011, at 8:41 AM, Dan Romascanu wrote:
> 
> > 
> > Part of the issues in the DISCUSS were raised in Bernard 
> Aboba's OPS-DIR review. I recommend all his review to be 
> addressed. I included in my DISCUSS those issues that seemed 
> to me critical. 
> > 
> > 1. A number of the recommendations made would appear to assume an 
> > all-IP NG911 "NENA i3" architecture, as opposed to the "NENA i2" 
> > transitional architecture.  In those cases, the 
> recommendations would 
> > represent "Best Future Practice" rather than "Best Current 
> Practice".
> We have tried to base our BCP on other IETF BCPs.  Of course, 
> there is wide variation.  This document represents what we 
> think devices should do going forward.  The IETF has no 
> document type called "Best Future Practice".
> 

I know :-) 

The solution is IMO clarifying the language and especially which one  of
the environments (all-IP) the requirements relate to. 

> > 
> > In a number of cases normative language appears to be used in ways 
> > different from those described in RFC 2119.  In some cases, 
> the term 
> > "SHOULD" is used in situations where statutes or 
> regulations may mandate behavior.
> We believe this to be the best choice.  It's MUST except in 
> specified circumstances.  The circumstances are when 
> regulations say otherwise.

It would be good to clarify this in the document. 

> 
> >   
> > 
> > I agree here with Bernard that the BCP status is probably 
> adequate, but in some places the requirements need clarification. 
> > 
> > Bernard also writes: 
> > 
> > Overall, I was left with the question as to whether the 
> > recommendations in this document applied beyond "all-IP"
> > deployments based on the framework document, to 
> transitional "NENA i2" 
> > environments as well.  I suspect that the "INT"
> > requirements would also apply to gateways between IP and 
> legacy PSAPs, 
> > but this isn't stated explicitly.
> This is not intended to be a transition document.  Transition 
> needs to be considered in the context of current, nation 
> specific emergency services.  i2 is U.S. specific, and major 
> changes were made in the Canadian version and are proposed in 
> the British version of how VoIP is supported in their current 
> TDM based systems.  We believe therefore that the IETF is not 
> the appropriate venue for a transition document.

If the view is that this document is targeting an all IP environment -
this needs to be made clear.

> 
> > 
> > I also find odd the fact that the document does not refer 
> at least informationaly to the NENA i2 and i3 architectures. 
> The behavior of the system and requirements may be different 
> in i2 and i3 environments. There are places where behavior 
> should be configurable or negotiated to allow for better 
> behavior in a transitional environment. There are also places 
> where behavior will be prescribed by local statues or 
> regulations, so that configuration and/or negotiation is a 
> practical requirement.
> It would be inappropriate to refer to i2 and i3 in -phonebcp. 

Why? It's not about the specific North-American regulatory aspects, it's
about the fact that the document targets an all-IP architecture which is
associated to i3 for everybody who deals with emergency. 

>  I do think we could refer to it in -framework however, and 
> we will draft a paragraph that does that.
> 
> > 
> > 2. I had a hard time translating some of the AN (Access 
> Networks related) requirements. For example: 
> > 
> >   AN-5 Access networks supporting copper, fiber or other 
> hard wired IP
> >   packet service SHOULD support location configuration.  If 
> the network
> >   does not support location configuration, it MUST require 
> every device
> >   that connects to the network to support end system 
> measured location.
> > 
> > If I am an operator of an AN that does not support location 
> configuration how should I read the requirement? Is this an 
> administrative requirement, or should the network be designed 
> so that devices that do not support end system measured 
> location (and have it activated?) cannot connect to the network? 
> I think it's very clear.  You have a choice - implement an 
> LCP or require all devices on your net to support end system 
> measured location.  HOW you do that is up to you.  It's 
> access network specific.  It may very well be L2 specific.
> 

I am still confused. Is this an administrative requirement? Users of
access networks assume that they have access at basic emergency services
when connecting to the network. Will the access provider tell them 'no
such service unless the device supports end system measured location'
and sign him contractually on this? 

> > 
> > 3. ED-3 is confusing. I think that it tries to state that 
> string recognition MUST be supported and that the endpoints 
> SHOULD provide this function, but if this is not the case the 
> SP MAY do it. If I am correct than this needs to be an ED/SP 
> requirement, and I would like the cases of exception to be 
> clarified. If I mis-understood please help me understand, 
> maybe with some text changes. 
> You understand it correctly.  SP-7 is the requirement on the 
> SP.  While we could combine this, I personally think it makes 
> more sense as it is.
> 
> > 
> > 4. Section 17.2: 
> > 
> >> The
> >   registration process is Expert review by ECRIT working group, its
> >   successor, or, in their absence, the IESG.  
> > 
> > I suggest to define this policy as Expert Review as per RFC 
> 5226 and have a Designated Expert nominated. The designated 
> expert can than use help from ECRIT, IESG, or other in the future. 
> We will do this
> 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > COMMENT:
> > 
> ----------------------------------------------------------------------
> > 
> > I support Pete's part of the DISCUSS that states that section 12 
> > points to a security hole that needs to be addressed
> We agree.  We will have to do something for this
> 
> > 
> 
>