Subject: Re: [Ecrit] Fwd: phonebcp initial comments

From: Robert Sparks <[email-masked]>
Date: Thu, 1 Jul 2010 14:59:29 -0500

I don't have any further comments/questions at this time - I've put this in revised-ID needed.

On Jun 22, 2010, at 1:03 PM, Robert Sparks wrote:

> (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.
> 
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit