Document: draft-ietf-ecrit-phonebcp-16.txt Reviewer: Miguel Garcia 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? - 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 ....". - 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. - 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. - 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? 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. - 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. - 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. Nits: - Expands acronyms at first occurrence. This includes: PSAP, PIDF, PIDF-LO, HELD, LCP, and LoST. - 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