[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt
Hi,
My comments between the <christer> and </christer> tags.
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf Of John-Luc Bakker
> Sent: 7. toukokuuta 2009 6:08
> To: Milan Patel; Gonzalo Camarillo
> Cc: ecrit at ietf.org
> Subject: Re: [Ecrit] Expert review of
> draft-patel-ecrit-sos-parameter-03.txt
>
> Hi Milan,
>
> I would like to pick up on Gonzalo's comment below:
>
> > 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.
>
> In the meanwhile, the document does talk about backwards
> compatibility.
>
> However, the legacy registrar will do the only (right) thing
> it can do but from a perspective of the UE that might not be
> the anticipated
> (right) thing.
>
> It is my understanding that an emergency registration can
> happen at any time and a UE is not required to immediately
> follow up the successful registration with an emergency call
> or tear down the emergency registration after the emergency call.
>
> Suppose a UAC has one public user identity and it performs a
> normal registration with some feature tags. Subsequently, the
> same UAC performs an emergency registration with different
> feature tags. Would the legacy registrar "refresh" the
> binding, then the S-CSCF would apply "emergency"
> feature tags to all session requests.
>
> An option tag would prevent this.
>
> If in agreement, I suggest the following changes to the draft
> (between <new> and </new> tags):
>
> 4.1. REGISTER Request
>
> When the UA sends a REGISTER request for emergency
> registration, the
> "sos" URI parameter MUST be appended to the URI in the Contact
> Header<new> and the option-tag "e-reg" must be included in
> the Proxy-Require and Require header</new>. This serves as
> an indication to the
> registrar that the
> request is for emergency registration<new> and it is only
> accepted if emergency registration is supported</new>.
>
> Example:
>
> Contact: "Alice" <sip:alice at example.com;sos> ;q=0.7; expires=3600
>
> In the event that more than one Contact header field is included in
> the REGISTER request, only the contact addresses that include the
> "sos" URI parameter shall be considered as emergency registered
> contact addresses.
>
> <new>
> Upon receipt of a 420 (Bad Extension) response the UAC will
> use an existing registration or initiate another registration.
> </new>
<christer>
Why would you need to insert the option-tag in the Proxy-Require header)
Why do you need intermediates to support the "sos" parameter? Isn't it
enough if the registrar, which in this case acts as UAS (and therefor
applies the Require header) support the "sos" parameter?
</christer>
Regards,
Christer
> 4.3. Backwards compatibility issues
>
> The backwards compatibility scenario considered in this document is
> where a legacy registrar does not support the "sos" URI parameter.
>
> <new>
> This document registers an option tag with IANA in section 6.2.
> Inclusion of the option tag will prevent a legacy registrar
> from handling the request.
> </new>
>
> 6. IANA Considerations
> <new>
> 6.2 SIP URI parameter
> </new>
> This specification defines one new SIP URI parameter, as per the
> registry created by RFC 3969 [RFC3969]
>
> Parameter Name: sos
>
> Predefined Values: none
>
> Reference: [RFCXXXX]
>
> [NOTE TO IANA: Please replace XXXX with the RFC number of this
> specification.]
> <new>
> 6.2 SIP Option Tag
>
> This specification registers a new SIP option tag, as per the
> guidelines in Section 27.1 of RFC 3261 [RFC3261].
>
> Name: e-reg
>
> Description: This option tag is used to identify the
> emergency registration extension. When used in a Supported
> header, it indicates that a User Agent understands the
> extension. When used in a Require header field of a REGISTER
> request, it indicates that the registrar is not expected to
> process the registration unless it supports the emergency
> registration extension.
> </new>
>
> Regards,
>
> John-Luc
>
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf Of Milan Patel
> Sent: Tuesday, April 28, 2009 8:36 AM
> To: Gonzalo Camarillo
> Cc: ecrit at ietf.org
> Subject: Re: [Ecrit] Expert review of
> draft-patel-ecrit-sos-parameter-03.txt
>
> 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 at 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 at ericsson.com]
> Sent: 09 March 2009 10:32
> To: Patel, Milan (MOP:EP10)
> Cc: ecrit at 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 at 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 at ietf.org
> [mailto:ecrit-bounces at ietf.org] On Behalf
>
> > Of Gonzalo Camarillo
> > Sent: 19 February 2009 13:57
> > To: ecrit at 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 at ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain
> confidential information, privileged material (including
> material protected by the solicitor-client or other
> applicable privileges), or constitute non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender
> and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and
> may be unlawful.
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>