Message-ID: <49FB4C97.7030007@ericsson.com>
Date: Fri, 01 May 2009 22:25:11 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Milan Patel <milanpa@nortel.com>
References: <499D6530.9040208@ericsson.com>
 <0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com>
 <49B4F019.2020904@ericsson.com>
 <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com>
In-Reply-To: <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt
Precedence: list

Hi,

thanks for putting together a new version of the draft. I still have a 
couple of minor comments on the following paragraph:

"If registration is successful, the 200 (OK) response from a legacy
    registrar is unlikely to include the "sos" URI parameter in the
    Contact header.  The UAC is aware of its registered contact address
    and address-of-record, however, is unable to distinguish between this
    registration and a non-emergency registration."

Clarifying why it is "unlikely" would be useful. Is it because RFC 3261 
gives registrars the freedom to do so, or because current implementation 
behave in different ways, or ...?

Also, the last sentence says that the UAC will not be able to 
distinguish this registration from a non-emergency registration. Well, 
that is because this indeed is a non-emergency registration for the 
legacy registrar. I would remove that whole sentence or, if you want to 
include that information, clarify that the registrar will treat this 
registration as any non-emergency registration.

Thanks,

Gonzalo


Milan Patel wrote:
> Hi Gonzalo,
> 
> Version 4 of draft-patel-ecrit-sos-parameter addresses all the comments
> you provided in the expert review. Please can you confirm that you are
> OK with its contents and that all the issues you had previously
> highlighted are now resolved.
> http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04
> Best regards,
> Milan
> 
> Milan Patel
> Carrier Networks Core Standards
> Nortel
> milanpa@nortel.com
> Telephone +44 162 843 2381 / ESN 560 2381
> Mobile +44 774 053 9261 / ESN 748 9261
> 
> For the Companies listed below, The Institute of Chartered Accountants
> in England and Wales authorises A R Bloom, S Harris and C Hill to act as
> Insolvency Practitioners under section 390(2)(a) of the Insolvency Act
> 1986 and the Association of Chartered Certified Accountants authorises A
> M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of
> the Insolvency Act 1986.
> 
> The affairs, business and property of the Companies are being managed by
> the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who
> act as agents of the Companies only and without personal liability.
> 
> The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel
> GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks
> SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks
> Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel
> Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel
> Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL;
> Nortel Networks AB; Nortel Networks International Finance & Holding BV
> 
> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] 
> Sent: 09 March 2009 10:32
> To: Patel, Milan (MOP:EP10)
> Cc: ecrit@ietf.org; Hannes Tschofenig
> Subject: Re: [Ecrit] Expert review of
> draft-patel-ecrit-sos-parameter-03.txt
> 
> Hi,
> 
> the problem with this text is that it specifies behavior for entities
> that will not implement this specification. The new section should
> describe how a legacy registrar will handle, following regular SIP
> rules, a REGISTER request with the sos parameter. However, it cannot
> specify extra behavior for such a legacy registrar. That is the whole
> point of backwards compatibility: to support unchanged legacy
> applications that will not implement the new functionality.
> 
> In any case, I believe you can use most of the text you proposed below. 
> It just needs to be rephrased so that it is more descriptive and non
> normative.
> 
> Thanks,
> 
> Gonzalo
> 
> Milan Patel wrote:
>> Folks,
>>
>> In response to Gonzalo's comment on backwards compatibility, I propose
> 
>> a subclause "4.3 Backwards compatibility issues" as follows:
>>
>> ----------------------------------------------------------------------
>> --
>> ----------------------------------
>> 4.3	Backwards compatibility issues
>> The backwards compatibility scenario considered in this document is 
>> where the registrar does not support the "sos" URI parameter. In this 
>> case, if the registrar receives a REGISTER request that includes the 
>> "sos" URI parameter in the Contact header, the registrar MUST proceed 
>> with registration procedures and silently ignore the URI-parameter in 
>> accordance with RFC 3261. This ensures the user is registered and thus
> 
>> can successfully initiate an emergency call.
>>
>> The drawback of proceeding with registration is if the 
>> address-of-record is barred or has roaming restrictions applied, then 
>> these restrictions will not be lifted and thus registration will be 
>> unsuccessful. This may limit the UAC's ability to successfully place
> an emergency call.
>> If registration is successful, the registrar shall return a 200 (OK) 
>> response to the UAC and does not include the "sos" URI parameter in 
>> the Contact header. The UAC is aware of its registered contact address
> 
>> and address-of-record, however, cannot distinguish between this 
>> registration and a non-emergency registration.
>> ----------------------------------------------------------------------
>> --
>> --------------------------------------
>>
>> Comments/feedback/suggestions for improvement are appreciated. I will 
>> address Gonzalo's other comments in version -04 of the draft as well.
>>
>> Best regards,
>> Milan
>>
>> Milan Patel
>> Carrier Networks Core Standards
>> Nortel
>> milanpa@nortel.com
>> Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / 
>> ESN 748 9261
>>
>> For the Companies listed below, The Institute of Chartered Accountants
> 
>> in England and Wales authorises A R Bloom, S Harris and C Hill to act 
>> as Insolvency Practitioners under section 390(2)(a) of the Insolvency 
>> Act
>> 1986 and the Association of Chartered Certified Accountants authorises
> 
>> A M Hudson to act as an Insolvency Practitioner under section 
>> 390(2)(a) of the Insolvency Act 1986.
>>
>> The affairs, business and property of the Companies are being managed 
>> by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill
> 
>> who act as agents of the Companies only and without personal
> liability.
>> The Companies are Nortel Networks UK Limited; Nortel Networks SA; 
>> Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel 
>> Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; 
>> Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel 
>> Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks
> 
>> Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel
> 
>> Networks Romania SRL; Nortel Networks AB; Nortel Networks 
>> International Finance & Holding BV
>>
>> -----Original Message-----
>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
> 
>> Of Gonzalo Camarillo
>> Sent: 19 February 2009 13:57
>> To: ecrit@ietf.org
>> Subject: [Ecrit] Expert review of 
>> draft-patel-ecrit-sos-parameter-03.txt
>>
>> Folks,
>>
>> I have been asked to perform an expert review of the following draft:
>>
>> http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt
>>
>> The approach taken by the draft seems OK in general. I have a few 
>> comments though:
>>
>> The requirement in Section 3 is too specific because it already 
>> assumes that the solution will be an indication in the SIP header 
>> fields. The requirement does not need to make that assumption. I would
> 
>> remove "by providing an appropriate indication in the SIP header
> fields".
>> In Section 5, the reference to RFC 2234 should be replaced with one to
> 
>> RFC 5234.
>>
>> Also in Section 5, the formal syntax should be rewritten so that it is
> 
>> compatible with the ABNF in RFC 3261. RFC 3261 already defines 
>> uri-parameter as follows:
>>
>>    uri-parameter   =  transport-param / user-param / method-param
>>                       / ttl-param / maddr-param / lr-param / 
>> other-param
>>
>>    other-param       =  pname [ "=" pvalue ]
>>    pname             =  1*paramchar
>>    pvalue            =  1*paramchar
>>
>> This document should simply define a new value for pname.
>>
>> The document does not talk about backwards compatibility. What happens
> 
>> if the registrar does not understand the 'sos' parameter? Will it do 
>> the right thing? Will the UAC detect the failure? Is there a need to 
>> define an option tag?... the document should address these points.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>