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 <miguel.a.gar...@ericsson.com>
To: Brian Rosen <b...@brianrosen.net>
CC: James M. Polk <jmp...@cisco.com>, Marc Linsner <mlins...@cisco.com>,
Robert Sparks <rjspa...@nostrum.com>, ecrit Org <ec...@ietf.org>
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:
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<miguel.a.gar...@ericsson.com>
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.
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:
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
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.
- 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.
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.
- 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.
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.
- 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".
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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
