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

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 20 Feb 2011 15:34:21 +0100

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?

- 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

BR,

      Miguel

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 25 Feb 2011 09:16:26 +0100

Adding the Gen-ART list

/Miguel

-------- Original Message --------
Subject: Re: Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt
Date: Fri, 25 Feb 2011 09:14:49 +0100
From: Miguel A. Garcia <[email-masked]>
To: Brian Rosen <[email-masked]>
CC: James M. Polk <[email-masked]>, Marc Linsner <[email-masked]>, 
Robert Sparks <[email-masked]>, ecrit Org <[email-masked]>

Hi Brian,

Some more inline comments. I have deleted those parts that do not need
further comments.

On 22/02/2011 19:17, Brian Rosen wrote:
> 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:
>
>> reviewer for this draft. For background on Gen-ART, please see the FAQ at<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>
>> Reviewer: Miguel Garcia<[email-masked]>
>> Review Date: 2011-02-20
>> Summary: This draft is on the right track but has open issues, described in the review.
>>
>> Major issues: None
>>
>> Minor issues:
>>
>> 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.

I am reading and re-reading the text and your explanation, and I am still
quite confused.

First, when the text says "Where a civic form of location is provided", I
don't understand if we are referring to the location that was inserted by
the end device or it refers to the location that the ED/INT/AN will
override. Suggestion: Can we avoid the passive voice and the fuzzy word
"provided"? So, if this location refers to the one that the ED/INT/AN is
supposed to override, then: "When the ED/INT/AD supplies location in
civic format for overriding ..."

And then, for the second part of the sentence, you almost said it in your
explanation": " ... it MUST be possible for the location configuration
protocol to supply a PIDF-LO that contains any of the elements specified
in RFC 4119/5139."

Therefore, the sentence will look like this:

"When the ED/INT/AD supplies location in civic format for overriding, it
MUST be possible for the location configuration protocol to supply a
PIDF-LO that contains any of the elements specified in RFC 4119/5139."

Does it make sense? Is it easier to understand? I hope so.

>
>
>
>>
>>
>>
>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem with the sentence that reads:
>>
>> 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

I accept your comment indicating that protocol here refers to "transport
of location". I think this is hard to comply, but that is a different story.

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

Well, you just described the problem: if the implement didn't read the
document, it is not going to be compliant. If it did read the document,
it has to be compliant. So, I don't understand the SHOULD strength,
because it applies to an implementer who didn't read the document.

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

I understand the goal of the requirement, but I am just saying that it is
not realistic. If you want to have a single codec, then perhaps you
should be looking into the PSAP implementing a variety of codecs.
Otherwise, we are going to be discussing why G.711 and not other codec,
and this is a never ending discussion.

As I said, this requirement is totally unrealistic. No matter what you
write here, it is not going to be implemented by every device vendor in
the world. So, if you want to solve the problem, perhaps you should be
looking at other solutions, like that one I just proposed.

Let me put you an example. This requirement is similar to one that
mandates all humans making emergency calls to speak English towards the
PSAP. Is it realistic? Perhaps not.

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

Honestly, I see this solution is easier to implement than requiring
devices to implement G.711.

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

I think you also need to get rid of the word "only", since there are two
instances for dropping a call. What about this text:

There are two scenarios where the device MUST drop a call:
1) the user is attempting to hung up (the emergency call).
2) an incoming call from the PSAP is received.

In any other scenarios, the device MUST NOT drop a call.

BR,

              Miguel

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