Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Feb 2011 13:17:50 -0500

Thank you for this review.  It shows once again what a brand new set of eyes can do for  document.  My thanks, again, to all the GenART reviewers and the system.

See inline for my responses

On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Please resolve these comments along with any other comments you may receive.
> 
> Document: draft-ietf-ecrit-phonebcp-16.txt
> Reviewer: Miguel Garcia <[email-masked]>
> Review Date: 2011-02-20
> IETF LC End Date: 2011-02-21
> 
> Summary: This draft is on the right track but has open issues, described in the review.
> 
> Major issues: None
> 
> Minor issues:
> 
> - I don't understand the last sentence in Section 6.2.1, which reads:
> 
>   Where a civic form of location is provided, all
>   fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be
>   specified.
> 
> what I don't understand is the meaning of "MUST be able to be specified". And I don't understand if this is a requirement for the service provider, for the access network, or for the end device. Can you explain what is the intention of the sentence?
The notion is that the location configuration protocol may generate a PIDF that contains any of the elements defined in 4119/5139.  All downstream elements must pass all fields.  It applies to all the entities.  Any suggestions for rewording to make this more clear would be appreciated.

> 
> 
> 
> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem with the sentence that reads:
> 
>   If the access network supports more than one location
>   configuration protocol, all such protocols MUST return the same
>   location, within the constraints of the protocols deployed.
> 
> I don't understand how this requirement can be achieved. Assume that an access network supports several location configuration protocols, which are able to determine the location by different means. Ideally all protocols should return the same location, but in practice, it will be difficult, due to the different accuracy and confidence among the various protocols. Additionally, I believe there is nothing the access network administrator can do to make sure that all location protocols will return the same location for a given device.
> 
> Conclusion: I consider this sentence to be a hope rather than a requirement. Perhaps it can be rephrased saying that ".... it is expected that all such protocols will return the same location ....".
This is a PROTOCOL issue and not a location determination issue.  Think of the protocol as being a transport mechanism for the location.  Each transport must return the same location.  This is saying if you have more than one protocol and more than one location determination mechanism, all protocols must return the same location

> 
> 
> 
> - Section 6.5., requirement AN-15/INT-17. It seems that this requirement is duplicated from the second sentence of requirements AN-13/INT-14 (see my previous comment). So, there should be only one requirement with the same text, and my previous comment should apply.
Yes, that is a problem.  I propose to delete the sentence in the prior section, and leave this one.

> 
> 
> 
> - Section 7, Requirement ED-51. I think this requirement also applies to the Service Provider (at least the configuration part of it), so it should get an SP number as well.
Yeah, I see the problem.  It might be easier to just delete the sentence, but I could add an AN requirement.  Anyone else have an opinion?

> 
> 
> 
> - Section 9.2, first bullet point. The text reads:
> 
>                                                                     If
>        the device cannot interpret local dial strings, the Request-URI
>        SHOULD be a dial string URI [RFC4967] with the dialed digits.
> 
> I don't understand how this requirement can be enforced. If someone has not read this document and has not implemented local dial strings, how can you put a requirement around dial string URIs to that person who has not implemented dial string URIs and possibly not read your draft?
If the device implementer didn't read the document, then it wouldn't conform to this document.  If they did, then they should use dial strings.  The device generates this, it doesn't get it from other entity.  I don't understand the problem.

> 
> Perhaps you can say that "it is expected that ...", but not placing a formal requirement.
> 
> This comment also applies to bullet point 2 in the same Section 9.2, regarding the To header field.
Same response.

> 
> 
> 
> - Section 9.2, bullet point 10. The text reads:
> 
>        A SDP offer SHOULD be included in the INVITE.  If voice is
>        supported the offer MUST include the G.711 codec, see
>        Section 14.
> 
> Honestly, this is an unrealistic requirement. G.711 is well known for its bandwidth consumption. Due to this, as far as I know, there is no cellular network in the world that support or uses G.711 either in circuit-switched or VoIP. I don't think this draft is going to change the current status quo. Actually, none has ever got to standardize a single codec for an application. Due to this, protocols like SIP/SDP support an codec negotiation mechanism in the format of the SDP offer answer.
> 
> Other considerations:
> 
> The requirement is nod needed, because in the absence of it, SDP offer answer will get to negotiate to a single codec for the emergency call.
> 
> This requirement falls into the category of national or supranational regulation. There will be organisms which will dictate minimum or recommended support in terms of codecs, and this regulation will be above the requirements in this document.
> 
> My recommendation is to delete this requirement.
> 
> I also noticed that this requirement is also repeated in Section 14, Requirement AD-73. The recommendation is also to delete such requirement.
> 
> Also, req ED-77 in Section 14 tries to do the same with a video codec. The recommendation is still the same.
This has been discussed before.  The goal is to be able to have any device, anywhere, be able to complete an emergency call.  To make that work, you have to have at least one common codec.  It's not something a local regulation could fix: when you get off a plane, your softclient on your VoIP service provider, must be able to complete an emergency call where you are.

The alternative is to have the document have a requirement on PSAPs to implement a relatively long list of codecs, and then have each device implement at least one of those.  That would be quite difficult to make such a list, and even if you did, some service would have a problem.

> 
> 
> 
> - Section 12, the text reads:
> 
>   Dropping of the old call MUST only
>   occur if the user is attempting to hang up
> 
> But the previous sentence says:
> 
>   If in the interval, an incoming call is received from
>   the domain of the PSAP, the device MUST drop the old call and alert
>   for the (new) incoming call.
> 
> So, we have two scenarios for dropping an old call:
> 1) the user is attempting to hung up
> 2) an incoming call is received from the PSAP
> 
> Therefore, I disagree with the "MUST only occur" of the first sentence. Please rephrase the text to avoid contradictions.
Is see your point.  In SIP, hang up requires the complete BYE transaction, and you can be in the middle of that transaction when the new call arrives.  The problem is the word "drop".  What we are attempting to say is that even though you are in the middle of that transaction, you have to abandon it, and accept the new call.  So I need a better word for "drop".

> 
> 
> 
> 
> 
> Nits:
> 
> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, PIDF-LO, HELD, LCP, and LoST.
the terminology sections says:
 This document uses terms from [RFC3261], [RFC5012] and [I-D.ietf-ecrit-framework].

I thought that would be enough.  I can expand the acronyms here.

> 
> - Section 9.2, first bullet point
> s/tree, If/tree. If
> 
> - Section 9.2, second bullet point
> s/not find a a Router/not find a Router
> 
> - Section 11
> s/and the Referred-by: header/and the Referred-by header
Thanks, I'll fix these

> BR,
>     Miguel
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain