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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 2 May 2011 16:33:47 -0400

Had some issues with sending to ecrit and IESG, which have been fixed

Begin forwarded message:

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Date: April 27, 2011 8:52:05 PM EDT
To: Dan Romascanu <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, "[email-masked]<mailto:[email-masked]> Org" <[email-masked]<mailto:[email-masked]>>
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".

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.

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.

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.  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.

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 May 2011 19:33:50 -0700

Comments below. 

From: [email-masked]
To: [email-masked]; [email-masked]
Date: Mon, 2 May 2011 16:33:47 -0400
Subject: Fwd: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with	DISCUSS and COMMENT)

Begin forwarded message:From: Brian Rosen <[email-masked]>
Date: April 27, 2011 8:52:05 PM EDT
To: Dan Romascanu <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked], [email-masked], "[email-masked] Org" <[email-masked]>
Subject: Re: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT)

[BA] As noted in the review, I don't have a problem with the document being a BCP. 

[BA] That's my take as well. 

Bernard also writes: 

[BA] I don't have a problem with the document not covering transitional cases -- but it wasn't clear whether that was the intent or not.   IMHO, clarifying that would be helpful.  

[BA] Dan's comment, not mine.  

[BA] Dan's comment, not mine. 

[BA] Dan's comment.

4. Section 17.2: 

The

[BA] This comment came from another Ops-dir reviewer.  
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[BA] Dan's comment.