Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08

Charles Shen <charles@cs.columbia.edu> Sun, 14 July 2013 15:28 UTC

Return-Path: <charles.newyork@gmail.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A221F9E6E for <sip-overload@ietfa.amsl.com>; Sun, 14 Jul 2013 08:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+AcAREPyJZq for <sip-overload@ietfa.amsl.com>; Sun, 14 Jul 2013 08:28:11 -0700 (PDT)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id F101521F9C93 for <sip-overload@ietf.org>; Sun, 14 Jul 2013 08:28:10 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id n10so14994552oag.28 for <sip-overload@ietf.org>; Sun, 14 Jul 2013 08:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=z6LHnOxynAnp8R5Zue85k8kL+l6muBzrNm3JtbMjEQY=; b=gXNZG4ZUnP/FjgLyk/eYDeMz4YOOppRhmI1gzvUT8f26SZcuZ9x4R3l2v5WWrm+wmb 5k0Fl3oL0ue7S6mrGKTE4C4Y5kYCLQkCzVPuVCY9cBDlNqE74ICtx8N0SDrOjbe4ZJrC 8uj/5xCtkOGLl30Yds74fm8f+ixJoQY0yKhQwNcdmgPbI5/rGHxWUB348jd+x65bDSKd A9W5K0X1SMZa+FCRK4J9deEmHtLmKugOXGDbgYM+xxiWXqj4O/WF4ihTdGFpikuucFPU ns/Ra0Bt59EWiF9NaLbv/NemB4fwbrxpRBG6Bod9CWyj0fSu8s7VVy7hPXzfm6wksMI1 x0nA==
X-Received: by 10.182.110.226 with SMTP id id2mr40849500obb.95.1373815689465; Sun, 14 Jul 2013 08:28:09 -0700 (PDT)
MIME-Version: 1.0
Sender: charles.newyork@gmail.com
Received: by 10.182.112.131 with HTTP; Sun, 14 Jul 2013 08:27:48 -0700 (PDT)
In-Reply-To: <CAL02cgRCiEqkgh9cmNca6iTXXVu-AsZ5HSpg-8JFZJAZ1PgTFQ@mail.gmail.com>
References: <CAL02cgQW3eJg+f0nwEwihJGRgE82o+B0gSx0LJ6vTP1M8F+n5w@mail.gmail.com> <CAPSQ9ZWuu5fS1jQw6XS4tyPt2ho2pkiCe0FKfboxNv8NrbsNZg@mail.gmail.com> <CAL02cgTD=EwVck90Je4Ou+9Te5aAnFMDMHfNMvBaGOK2EDUNxA@mail.gmail.com> <CAPSQ9ZVLVhepr59KjsjZUFk+C5=xxDuUYHa5CxhBD11Sni=4pQ@mail.gmail.com> <CAL02cgTq+0frn6e63ARm039w9DU8hOz3B==ENr8wjxGNef5kEg@mail.gmail.com> <CAPSQ9ZV2reortRkiR7NYZ=bMhNqkEmEHbbq6DNGnzzhAWi9WSg@mail.gmail.com> <CAL02cgRzwhG0V+M=Uf50hUaTx_pRFGB7XAumhht8Jg3RuiA+FQ@mail.gmail.com> <CAPSQ9ZXeDNPqp3uf2sYwjFy_3p8Z7NK55gBpR=Mw5dcYPNCmOA@mail.gmail.com> <CAPSQ9ZV8ervdD4NP6yTjazPT+-LnaXSX9ZHZstNzS+JJkhC7Nw@mail.gmail.com> <CAL02cgQ5BNyS87MOwLs4LC2emnsfESZ7=KZsJN7xLqpPXkVo4w@mail.gmail.com> <CAPSQ9ZVSqZqCWDf3EZBS_WAp4okpO=QGN3t=UY2JvKtQSRkvWg@mail.gmail.com> <CAL02cgRCiEqkgh9cmNca6iTXXVu-AsZ5HSpg-8JFZJAZ1PgTFQ@mail.gmail.com>
From: Charles Shen <charles@cs.columbia.edu>
Date: Sun, 14 Jul 2013 23:27:48 +0800
X-Google-Sender-Auth: 7AzKk75adrQhBCqVV5Xjmx7_1vc
Message-ID: <CAPSQ9ZWQm-tMxtffkXhjjcwmmTZncyZRMAO8qqeh=k_LWvdEpw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="089e0112ce202859cf04e17a64ab"
Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jul 2013 15:28:13 -0000

Great and thank you!

On Sun, Jul 14, 2013 at 4:04 AM, Richard Barnes <rlb@ipv.sx> wrote:

> I see.  That makes sense.  If the WG approves, I would be OK with Option 2.
> --Richard
>
>
> On Sat, Jul 13, 2013 at 1:24 PM, Charles Shen <charles@cs.columbia.edu>wrote:
>
>> Hi Richard,
>>
>> The reason I think we need to have <many-tel> is that we also want to
>> allow the situation when we only filter a group of phone numbers with
>> the same prefix "eg., +1-212-854", similar to filtering a group of sip
>> ids with the same domain, e.g., "sip.example.com", if we only use
>> <exclude-tel> we would have to list all available prefixes except that
>> one, which doesn't seem very plausible. it looks like <many> in
>> RFC4745 only accepts "domain" attribute, so we need a <many-tel> with
>> the following schema.
>>
>> <xs:complexType name="manyTelType">
>>         <xs:complexContent>
>>             <xs:restriction base="xs:anyType">
>>                 <xs:choice minOccurs="0" maxOccurs="unbounded">
>>                     <xs:element name="exceptTel" type="lc:exceptTelType"/>
>>                     <xs:any namespace="##other"
>>                     minOccurs="0" processContents="lax"/>
>>                 </xs:choice>
>>                 <xs:attribute name="prefix"
>>                 use="optional" type="xs:string"/>
>>             </xs:restriction>
>>         </xs:complexContent>
>>     </xs:complexType>
>>
>> Then we can say
>>
>> <many-tel prefix="+1-212-854"/>
>>
>> in a way similar to
>> <many domain="sip.example.com>
>>
>> Is this something you would agree with?
>>
>> Thanks!
>>
>> Charles
>>
>>
>>
>>
>> On Sat, Jul 13, 2013 at 2:57 AM, Richard Barnes <rlb@ipv.sx> wrote:
>> >
>> > Keep in mind that you're *extending*, not redefining the RFC 4745
>> schema here.
>> >
>> > Option 1 doesn't work.  The schema for <except> in RFC 4745 doesn't
>> allow for attributes other than "domain".
>> >
>> > Option 2 is overkill.  You don't need to define a new <many> element,
>> you can just define a new exception element inside of <many>
>> >
>> > Option 3:
>> >
>> > <from>
>> >   <many>
>> >     <except-tel prefix="+1-212-854"/>
>> >   </many>
>> > </from>
>> >
>> > Then your extension schema is:
>> >
>> > <xs:element name="except-tel" type="exceptTelType"/>
>> > <xs:complexType name="exceptTelType">
>> >   <xs:attribute name="prefix" type="xs:string" use="optional"/>
>> >   <xs:attribute name="id" type="xs:anyURI" use="optional"/>
>> >   <xs:anyAttribute>
>> > </xs:complexType>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen <charles@cs.columbia.edu>
>> wrote:
>> >>
>> >> Hi Richard,
>> >>
>> >> After putting up more thoughts on this as I finalize the revision, I
>> feel that there are really two options:
>> >>
>> >> Option 1:
>> >>
>> >> <from>
>> >>     <many>
>> >>         <except prefix="+1-212-854"/>
>> >>         <except domain="manhattan.example.com"/>
>> >>     </many>
>> >> </from>
>> >>
>> >> Option 2:
>> >>
>> >> <from>
>> >>     <many>
>> >>         <except domain="manhattan.example.com"/>
>> >>     </many>
>> >>     <many-tel>
>> >>         <except-tel prefix="+1-212-854"/>
>> >>     </many-tel>
>> >> </from>
>> >>
>> >> I also attach below the respective changes to the XML of these two
>> options. Both will require extended definition of the RFC4745 identity
>> element (unless we want to call it a different name), option 1 is cleaner
>> in terms of usage. but requires extended definition of not only the RFC4745
>> "identity", also RFC4745 "many" and "except", Option 2 requires extended
>> definition of RFC4745 "identity" but use separate names to extend "many"
>> and "except". Since "many-tel" is independent of "many", everytime we want
>> to include group of identities covering both sip and tel uris we have to
>> specify both "many" and "many-tel". Is there one option that you prefer
>> over the other?
>> >>
>> >> Thanks!
>> >>
>> >> Charles
>> >>
>> >>
>> >>
>> >> OPtion 1: redefinition of identity / many / except
>> >>
>> >>    <!-- SIP ID TYPE -->
>> >>    <xs:complexType name="sip-id-type">
>> >>      <xs:sequence>
>> >>      <element name="from" type="lc:identityType" minOccurs="0"/>
>> >>      <element name="to" type="lc:identityType" minOccurs="0"/>
>> >>      <element name="request-uri" type="lc:identityType" minOccurs="0"/>
>> >>      <element name="p-asserted-identity" type="lc:identityType"
>> >>            minOccurs="0"/>
>> >>      <any namespace="##other" processContents="lax" minOccurs="0"
>> >>            maxOccurs="unbounded"/>
>> >>      </xs:sequence>
>> >>      <anyAtrribute namespace="##other" processContents="lax"/>
>> >>    </xs:complexType>
>> >>
>> >>     <!-- //conditions/identity -->
>> >>     <xs:complexType name="identityType">
>> >>         <xs:complexContent>
>> >>             <xs:restriction base="xs:anyType">
>> >>                 <xs:choice  minOccurs="1" maxOccurs="unbounded">
>> >>                     <xs:element name="one" type="cp:oneType"/>
>> >>                     <xs:element name="many" type="lc:manyType"/>
>> >>                     <xs:any namespace="##other" processContents="lax"/>
>> >>                 </xs:choice>
>> >>             </xs:restriction>
>> >>         </xs:complexContent>
>> >>     </xs:complexType>
>> >>
>> >>     <!-- //identity/many -->
>> >>     <xs:complexType name="manyType">
>> >>         <xs:complexContent>
>> >>             <xs:restriction base="xs:anyType">
>> >>                 <xs:choice minOccurs="0" maxOccurs="unbounded">
>> >>                     <xs:element name="except" type="lc:exceptType"/>
>> >>                     <xs:any namespace="##other"
>> >>                     minOccurs="0" processContents="lax"/>
>> >>                 </xs:choice>
>> >>                 <xs:attribute name="domain"
>> >>                 use="optional" type="xs:string"/>
>> >>                 <xs:attribute name="prefix"
>> >>                 use="optional" type="xs:string"/>
>> >>             </xs:restriction>
>> >>         </xs:complexContent>
>> >>     </xs:complexType>
>> >>
>> >>     <!-- //many/except -->
>> >>     <xs:complexType name="exceptType">
>> >>         <xs:attribute name="domain" type="xs:string" use="optional"/>
>> >>         <xs:attribute name="prefix" type="xs:string" use="optional"/>
>> >>         <xs:attribute name="id" type="xs:anyURI" use="optional"/>
>> >>     </xs:complexType>
>> >>
>> >>
>> >> OPtion 2: redefinition of identity plus defining additional many-tel /
>> except-tel
>> >>
>> >>    <!-- SIP ID TYPE -->
>> >>    <xs:complexType name="sip-id-type">
>> >>      <xs:sequence>
>> >>      <element name="from" type="lc:identityType" minOccurs="0"/>
>> >>      <element name="to" type="lc:identityType" minOccurs="0"/>
>> >>      <element name="request-uri" type="lc:identityType" minOccurs="0"/>
>> >>      <element name="p-asserted-identity" type="lc:identityType"
>> >>            minOccurs="0"/>
>> >>      <any namespace="##other" processContents="lax" minOccurs="0"
>> >>            maxOccurs="unbounded"/>
>> >>      </xs:sequence>
>> >>      <anyAtrribute namespace="##other" processContents="lax"/>
>> >>    </xs:complexType>
>> >>
>> >>     <!-- //conditions/identity -->
>> >>     <xs:complexType name="identityType">
>> >>         <xs:complexContent>
>> >>             <xs:restriction base="xs:anyType">
>> >>                 <xs:choice  minOccurs="1" maxOccurs="unbounded">
>> >>                     <xs:element name="one" type="cp:oneType"/>
>> >>                     <xs:element name="many" type="cp:manyType"/>
>> >>                     <xs:element name="many-tel"
>> type="lc:many-telType"/>
>> >>                     <xs:any namespace="##other" processContents="lax"/>
>> >>                 </xs:choice>
>> >>             </xs:restriction>
>> >>         </xs:complexContent>
>> >>     </xs:complexType>
>> >>     <!-- //identity/many-tel -->
>> >>     <xs:complexType name="many-telType">
>> >>         <xs:complexContent>
>> >>             <xs:restriction base="xs:anyType">
>> >>                 <xs:choice minOccurs="0" maxOccurs="unbounded">
>> >>                     <xs:element name="exceptTel"
>> type="lc:except-telType"/>
>> >>                     <xs:any namespace="##other"
>> >>                     minOccurs="0" processContents="lax"/>
>> >>                 </xs:choice>
>> >>                 <xs:attribute name="domain"
>> >>                 use="optional" type="xs:string"/>
>> >>             </xs:restriction>
>> >>         </xs:complexContent>
>> >>     </xs:complexType>
>> >>     <!-- //many/except -->
>> >>     <xs:complexType name="except-telType">
>> >>         <xs:attribute name="prefix" type="xs:string" use="optional"/>
>> >>         <xs:attribute name="id" type="xs:anyURI" use="optional"/>
>> >>     </xs:complexType>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <charles@cs.columbia.edu>
>> wrote:
>> >>>
>> >>> This makes a lot of sense, fully agree. Thanks!
>> >>>
>> >>> Charles
>> >>>
>> >>>
>> >>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <
>> charles@cs.columbia.edu> wrote:
>> >>>>>
>> >>>>> Hi Richard, please see additional questions regarding "tel" URL
>> grouping:
>> >>>>>
>> >>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <rlb@ipv.sx> wrote:
>> >>>>>>
>> >>>>>> Inline.  Areas of agreement snipped.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <
>> charles@cs.columbia.edu> wrote:
>> >>>>>>>>
>> >>>>>>>> To be clear on this, the ambiguity here is with regard to the
>> <except domain="..."> case.  In the <one id="..."> case, you just do Tel
>> URI comparison.
>> >>>>>>>>
>> >>>>>>>> Thinking on this a little more, it looks like your use of the
>> "domain" parameter actually breaks with RFC 4745.  According to RFC 4745,
>> there must be an exact match between the "domain" value provided by the
>> using protocol and the value in the "domain" parameter.  I can't think of a
>> way that this document could define a way to extract a domain from a
>> telephone number that would meet the semantic you seem to be intending.
>> >>>>>>>>
>> >>>>>>>> So it seems like you need to do one of the following:
>> >>>>>>>> 1. Define a rule for how you compute a domain value from a tel:
>> URI.
>> >>>>>>>> 2. Define a new element for use under <many> (since <except>
>> lacks an extension point)
>> >>>>>>>> 3. Drop support for excluding phone numbers by domain (you just
>> have to enumerate the exceptions individually)
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> [CS] If we opt for Option 1, can we do the following:
>> >>>>>>>
>> >>>>>>> a. assume E.164 numbers always start with + sign, so we can use
>> the digits after the + sign (after removing any visual separaters, as in
>> the Tel URL comparison rules) as the presumed domain value.
>> >>>>>>> b. for local numbers (numbers that do not start with +), the
>> "phone-context" contains the domain value.
>> >>>>>>
>> >>>>>>
>> >>>>>> Are you sure that gives you the expressiveness you want?  It
>> doesn't allow you to exclude based on an arbitrary prefix.  For example,
>> <except domain="+1212"> would not match the URI "tel:+12125551212",
>> because the "domain" value for that URI would be "12125551212".
>> >>>>>>
>> >>>>>> It seems like (2) is the option that's most likely to give you
>> what you want.  Suggest defining something like a "<except-tel>" element,
>> so that you could say something like <except-tel prefix="+1212">.
>> >>>>>
>> >>>>>
>> >>>>>  I am absolutely fine adding another element, but just want to make
>> sure I indeed understand your concern before doing that.
>> >>>>>
>> >>>>> According to the current texts (paragraph 2, pg.18), when the
>> specified domain value starts with a "+" sign, it denotes a number prefix,
>> if its "+1-212", the prefix is "1212" (after removing any visual
>> separaters, as in the Tel URL comparison rules, this needs to be added
>> explicitly), and this prefix is used to match numbers (again after removing
>> any visual separaters), therefore, it should match the number "1212551212"
>> in the tel URL tel:+12125551212.
>> >>>>>
>> >>>>> Did I miss something here? thanks!
>> >>>>>
>> >>>>> Charles
>> >>>>
>> >>>>
>> >>>> I think the concern here isn't with the definition, it's with the
>> fact that you're "re-interpreting" an existing field.  That's bad for
>> interoperability, since if one of these policies is provided to an
>> implementation that doesn't know about the reinterpretation, that
>> implementation with interpret the field incorrectly.  I agree that the risk
>> of misinterpretation is pretty low here (since it's buried in a
>> call-identity element), but it's best to be unambiguous.
>> >>>>
>> >>>> So I would just augment your existing schema to define a new element
>> with the same semantic you have described above.
>> >>>>
>> >>>> --Richard
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
>