Subject: [Ecrit] Fwd: phonebcp initial comments

From: Robert Sparks <[email-masked]>
Date: Tue, 22 Jun 2010 13:03:40 -0500

(resending from an address that won't land in the moderator queue - chairs - please delete the version that's stuck there)

I'm in the middle of reviewing ecrit-phonebcp in preparation for 
taking it through the rest of the process.  I'd like to start discussing
the comments and questions I've found so far. These are in document order.

Introduction (nits):
Consider a reference and expand the first occurance of SIP in the introduction.
Missing close paren after AN- in the introduction's 1st paragraph

ED-2 may not be sufficiently specified. Did you intend to include devices like
the Tandberg Fieldview or one-way SIP paging/announcement devices?

SP-2 (nit) "This" at the beginnning of the second sentence is potentially
ambiguous. The second sentence isn't really part of the requirement - it's a
consideration for other parts of the system. 

Does ED-11/SP-9 include the counseling service or was it intended to only apply to the sos service?

ED-14/INT-3/AN-3 how is suitable determined? Can any guidance be provided?

ED-15/INT-4/AN-4 Why is override in quotes?

AN-6/INT-5 Can the document explain why 650 m^2 was chosen?

AN-7/INT-6 The requirement to preserve ay access network provided location
  mechanism (not just location) through intermediate devices is hard to
  extract from the existing text.

ED-16/INT-7 Is there a reference to point to (or text to include) that explains
the choice of 100m and 95% confidence?

AN-9 Does "do not support" here mean do not implement or do not use?

ED-12/INT-12 I'm not sure what the second sentence is trying to say.
Is it this?: When devices are deployed in access networks that support
interface-specific location discovery mechanisms such as LLDP-MED...

AN-13/INT-14 (nit) suggest s/meeting this BCP/satisfying the requirements in
this BCP/

ED-22/INT-15 Can you keep trying LCPs after you find the first one that
succeeds? (The requirement currently says "can be used")

ED-24 (nit) There are two ranges listed here that could be collapsed 
(12-21,21-31). Is this just an artifact of editing, or is there a typo?

ED-25 It's not clear whether no response is received means transport, http,
or HELD failure. Does the retry mechanic specified here make sense in the
first two cases? In the third, doesn't HELD provide some retry behavior
based on its error codes? How does this requirement interact with that?

ED-30/INT-23 (nit) "roam" may have connotations of changing networks to some
readers. I think you meant "change location"?

ED-31/INT-24 (nit) I suggest replacing "If the device can detect it has moved",  with "If the device detects a state change that might indicate having moved".

ED-32/AN-18 is "MUST be provided" here intended to convey must use or only must implement?

ED-38 How was 10 seconds chosen?

ED-39/SP16 - Is this requirement trying to point to Rule 3 in section 3 of 5491 or something else? 

SP-17 Should this requirement talk about random choices the way ED-40 does?

ED-41/SP-20 Is this requirement on the generation or verification of location
object (I suspect it's generation, in which case the requirement might be
better written as "MUST be created with" rather than "MUST contain"

ED-??/SP-?? : This indicates additional review of the document is needed. 

ED-42/SP-21 This needs more context (Perhaps it should start out with "When
there are multiple Geolocation header field values provided"?)

SP-22 This requirement is only talking about the initial INVITE and not really
the entire call, correct? Can it be rewritten to focus on that message?

ED-46 Is the requirement here to not use S/MIME at all, or to ensure that if it
is used that these bits also appear in the clear.

ED-47/SP-24 This is awkwardly phrased (in a way that doesn't use MUST
correctly). Right now the only way I can interpret this is "Either TLS or IPSEC
MUST be used to protect location (but see Section 9.1)." If that's the intent,
can the phrase be rewritten this way?

ED-48 What are you trying to describe with "HTTP get" in this requirement?

ED-51 Where is the specification of looking for LoST servers in SRV (can
this requirement add a reference?). Nit: s/it's/its/. ED-52 looks like a
restatement of part of this requirement. Can they be combined?

AN-26 Is this requirement intended to mean the access network's DHCP servers
MUST implement the LoST discovery option, or that the access network must use
the option? How does this relate to the requirement in AN-27?

ED-58 This requirement says MAY, but ED-65 point 12 says SHOULD.

ED-60/SP-31 I suggest replacing "specified" with "used". This requirement needs to be restructured similar to ED-47/SP-24. 

ED-62/SP-33 RFC5626 doesn't discuss persistent TLS between proxies. This
requirement should be more clearly scoped to connections when one element is
the end device.

ED-63/AN-28 Again, suggest s/specified/used/. 

ED-64/AN-29 Suggest being explicit: When TLS session establishement with the
HELD server fails,

ED-65 3 and 4 Why does this need to restate fundamental SIP requirements (like
having a From and Via header field)? Nit: header-> header field throughout the
document

ED-63 5: The Route header should have exactly the bits that LoST returned. It
doesn't make sense to add an ;lr if one wasn't already there. Is the second
half of this requirement accurate (will there never be Route headers for other
reasons, such as Service-Route)?

ED-64 15: Is this requirement trying to point to Accept-Contact with a
"language" parameter? Accept-Language and Caller Preferences aren't related.

SP-34 1: What does "as above" point to?

ED-66/SP-35: How was 30 minutes chosen? ED-65 says "several minutes" 

ED-67/SP-38: This needs expansion/clarification. If the intent is to insist that an endpoint accept the REFER and issue an INVITE, "MUST support" is insufficient. Where you say transaction, I think you mean request. Does this requirement apply only to REFER requests received in this dialog, or is it intended to also apply to REFER requests out-of-dialog, but associated with this dialog using the Target-Dialog extension?

ED-68 Is there a reason to not clean up the cruft before publication (I understand not wanting the numbers to move around much while the working group was developing the document).

ED-79 This requirement makes 5194 a normative down-reference 
	
ED-80 should this point to 3984bis?

ED-81 Where are the *.test URNs defined/registered?

The restatement of requirements in the appendix is dangerous from a document maintenance point of view. There are already some (minor) inconsistencies that I found with a hackish python script - this may not be all of them:

ED-9 :	Endpoints SHOULD be able to have home dial strings provisioned by configuration.
	Endpoints SHOULD be able to have home dial strings provisioned.

ED-60 :	TLS MUST be specified when attempting to signal an emergency call with SIP. IPSEC is an acceptable alternative.
	TLS MUST be specified when attempting to signal an emergency call. IPSEC is an acceptable alternative.

ED-81 : ... and a 404 (Not Found) MUST be returned ...
	... and a 404 (Not found) MUST be returned ...

ED-82 :	(appendix is missing punctuation at end)

SP-8 :	Service providers MAY provide home dial strings by configuration.
	Service providers MAY provision home dial strings in devices.

SP-31 :	TLS MUST be specified when attempting to signal an emergency call with SIP. IPSEC is an acceptable alternative.
	TLS MUST be specified when attempting to signal an emergency call. IPSEC is an acceptable alternative.

AN-11 : ... personnal area ...
	... personal area ...

Only seen once
ED-?? A location with a method of "derived" MUST NOT be used unless no other location is available.
SP-?? A location with a method of "derived" MUST NOT be used unless no other location is available.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 22 Jun 2010 12:19:28 -0700

> the choice of 100m and 95% confidence?

I'm assuming that this was chosen to correspond to WLAN scenario mentioned in the previous section. However, the 100m figure represents
the distance at which a 1 Mbps 802.11 frame can be expected to propagate within a maximum acceptable Frame Error Rate (FER).  However, if higher frame error rates can be tolerated (such as in Beacon reception), then the distance for 95 percent confidence can be greater (or alternatively, the confidence would be lower at 100m).  As an example, in a plane at 3000 m, it is still possible to receive 
and decode Beacons emitted from the homes below, albeit with a high FER.  Also in practice if triangulation is not used, there will be a dependency on the roaming algorithms of WLAN chipsets; "sticky" implementations could make it difficult to deliver an accuracy of 100m with 95% confidence.  

Given this ,the reality is that the accuracy that is achievable will depend on the location technology used, and whether the determination is made by the end-system (Section 6.2.3) or the network (Section 6.2.4).   The FCC Wireless Phase II requirements make these kind of distinctions:

Wireless phones relying on network-based technology must provide Public Safety
 Answering Points (PSAP) with reports on their locations within 100 
meters of accuracy for 67 percent of calls, and within 300 meters for 95
 percent of calls, by Sept. 11, 2012. Phones 
installed with GPS chips, meanwhile, must provide PSAPs with 
reports on their locations within 50 meters of accuracy for 67 percent 
of calls, and within 100 meters for 95 percent of calls, by the same 
date. The FCC also specified certain benchmarks to measure the carriers'
 progress, such as meeting the location accuracy requirements in at 
least 75 percent of PSAPs a carrier serves by 2010.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 22 Jun 2010 22:21:16 +0300

I always argued that these numbers should be removed from the document
since they have nothing to do with the protocol functionality itself but
largely refer to the what regulators decide they find useful (even
though they have no way to verify it later on). 
 
Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Bernard Aboba
	Sent: Tuesday, June 22, 2010 10:19 PM
	To: [email-masked]; [email-masked]
	Subject: Re: [Ecrit] Fwd: phonebcp initial comments

	> the choice of 100m and 95% confidence?
	
	I'm assuming that this was chosen to correspond to WLAN scenario
mentioned in the previous section. However, the 100m figure represents
	the distance at which a 1 Mbps 802.11 frame can be expected to
propagate within a maximum acceptable Frame Error Rate (FER).  However,
if higher frame error rates can be tolerated (such as in Beacon
reception), then the distance for 95 percent confidence can be greater
(or alternatively, the confidence would be lower at 100m).  As an
example, in a plane at 3000 m, it is still possible to receive and
decode Beacons emitted from the homes below, albeit with a high FER.
Also in practice if triangulation is not used, there will be a
dependency on the roaming algorithms of WLAN chipsets; "sticky"
implementations could make it difficult to deliver an accuracy of 100m
with 95% confidence.  
	
	Given this ,the reality is that the accuracy that is achievable
will depend on the location technology used, and whether the
determination is made by the end-system (Section 6.2.3) or the network
(Section 6.2.4).   The FCC Wireless Phase II requirements make these
kind of distinctions:
	
	Wireless phones relying on network-based technology
<http://www.networkworld.com/newsletters/wireless/2004/0412wireless2.htm
l>  must provide Public Safety Answering Points (PSAP) with reports on
their locations within 100 meters of accuracy for 67 percent of calls,
and within 300 meters for 95 percent of calls, by Sept. 11, 2012. Phones
installed with GPS chips
<http://www.networkworld.com/weblogs/cool/archives/2003/002321.html> ,
meanwhile, must provide PSAPs with reports on their locations within 50
meters of accuracy for 67 percent of calls, and within 100 meters for 95
percent of calls, by the same date. The FCC also specified certain
benchmarks to measure the carriers' progress, such as meeting the
location accuracy requirements in at least 75 percent of PSAPs a carrier
serves by 2010.