Lets not forget what this specification was attempting to solve, which has been the well known boot strap problem with SIP-CUA's we have collectively ignored since the creation of SIP, especially those that might use (dare I say it) phone numbers. The model here is to make such things as SIP CUA's as easy to use as traditional POTS phones. Plug them in, they work.. at least now after punching in a small data string into the keypad of a device, instead of having to manually Config the device using some on board HTTP app. As the success of some Apple devices testify ( and Skype for that matter) ..making complex electronics configuration nearly stupid proof increases the overall market. :-) This could also expand the market for SIP devices and the for competitive SIP services by permitting them to be sold at mass market outlets without being necessarily tied to one SSP, if, yes, they were compliant with the specification and yes Hadriel you had a branded logo program that insured compliance. The SIP Forum is "not there yet" on that kind of testing, compliance and logo program. Any discussion of how to improve the specification is useful but the goal is the expansion of SIP related services in the market. Gee sort of what we are trying to do with the PBX to SSP issues. -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Scott Lawrence Sent: Thursday, April 08, 2010 9:37 AM To: Hadriel Kaplan Cc: Cullen Jennings; IETF Discussion Mailing List Subject: RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC On Thu, 2010-04-08 at 04:12 -0400, Hadriel Kaplan wrote: > Howdy, > I said I would shut up, but I missed one question from Cullen, which was: > > This conversation constantly confuses the issue of must implement vs must > > deploy. Which one are you objecting to here. > > Answer: I am objecting to there not *being* a distinction between must > implement vs. must deploy in this draft. The draft requires the > implementation and DEPLOYMENT of a SIP Subscription service. It is > not optional to use. It is not optional to deploy. Well, one could argue that a provider could cause the returned SIP url for the change notice subscription to be one for which there is no routing (return 'Link: <sip:devnull.example.org>'). By the rules, the UA would periodically make a DNS request to try to find it, but would be allowed to use the configuration data. Silly, but allowed. No one is going to be forced to use any of this specification. If you don't want the features it provides (automatic initial configuration with prompt updates), then don't use it. At the risk of repeating myself, I want to make sure that one reason for using SUBSCRIBE/NOTIFY for the change notices is clear: there is no other existing standard way to address a specific User Agent. User Agents do not register a contact that identifies the device (or program); they register addresses that identify users (SIP AORs), and those same addresses might well also map to other UAs. If I want to change the configuration of exactly one device, I need a way to send a message just to that one device. Putting a subscription URL in the Link header returned by the HTTPS configuration data response allows the Configuration Service to associate every item of configuration data with the devices that have it, so that when that data it is possible to send a message to exactly the set of devices that need to know. > Through some careful analysis of the implementation requirements > stipulated in the draft, one may be able to find an exemption path to > avoid deployment by means of configuration - but the language of the > requirements to do so is so weak that it's meaningless. If you have a suggestion for better wording that preserves the intent, I'm happy to hear it. > You cannot stipulate that a "UA MAY do foo" in a SIP-Forum profile or > IETF RFC, and then expect administrators to rely on that foo for > anything useful whatsoever, because not all UAs are required to do > foo. Some will, some won't. All of them will be compliant. This > basically defeats the whole point of having an "implementation > profile", imho. In general I agree with that paragraph, and have tried hard not to put that particular kind of problem into this spec. I don't think that any of the examples you cite below produce the kind of problem you describe. I'll attempt below to explain why each are needed... > For example, the following requirements are stipulated: > The User Agent MAY obtain configuration information by any means in > addition to those specified here, and MAY use such information in > preference to any of the steps specified below, but MUST be capable > of using these procedures alone in order to be compliant with this > specification. The MAY 'escape' clauses above are there primarily to allow a configuration to 'stick'. The user of a UA may want to configure it such that the UA can be moved to different networks but keep the association with the SIP domain it is configured for. If I configure my phone to register with my company SIP service, and then take that phone to my home office or a hotel, I may not want it to even try to reconfigure itself to the domain provided by the local network DHCP, even though it needs to use DHCP to get local IP configuration data. They also allow for deployment in particular environments that may have special needs, such as a very high security environment that requires preconfigured keying material and static IP addresses. These clauses are there to make it clear that such behavior is allowed by the specification. The MUST is there to ensure that one cannot argue that because other means are available the device conforms to this spec even though it actually requires that the manual or other mechanisms always be used - exactly the problem you describe above. > The UA MAY at any time return to any earlier step in the > process of obtaining configuration data. I'm not sure how this fits the pattern you're concerned about. It does not allow the device to do anything other than start over doing a step that's in the spec. It's there to give an implementer flexibility in error handling. Perhaps it doesn't need to be said, but I (and others) felt that making this explicit would prevent over-zealous testers from being too rigid in requiring particular error behavior. (In practice, this is always true anyway... the "give up an reboot" response) > The UA MAY use configuration data that is of unknown validity, or > configuration data that is known to be no longer valid, while > attempting to revalidate that data or obtain new data. There is no > assurance that such configuration data is still useful, but the UA is > NOT REQUIRED to stop using or delete the data. This is there to prevent a failure in the configuration system from causing failures in other functions of the UA. Suppose that a device is properly configured for a particular service. The call routing functions of that service are implemented separately from the configuration management parts of that service. The configured device approaches the expiration of its configuration change subscription, and correctly sends a reSUBSCRIBE request to refresh it. Due to some transient failure somewhere (routing problems, the CS system itself is down), that request fails and the configuration change subscription expires. The section above is there to make clear that the device does not have to stop using (or worse, delete) the configuration, thus propagating an error that affects the configuration refresh system into the call processing. Again, I don't see how allowing this causes interoperability problems. > These requirements are all completely meaningless, in the sense that > they do not provide any reliable behavior. It's true that they allow some degree of variability, but I think that some flexibility increases the overall robustness of the system, and that over-specification can be as harmful as under-specification. If you think that any of these do cause interop problems, then I'd be happy to hear about them. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf