Subject: Re: [sip-overload] [Fwd: I-D Action:draft-hilt-sipping-overload-07.txt]

From: Charles Shen <[email-masked]>
Date: Mon, 23 Nov 2009 09:27:19 -0500

Hi Victor:

The document itself does not preclude schemas other than the one defined in it.

Thanks

Charles

On Tue, Oct 27, 2009 at 9:41 AM, Victor Pascual Avila
<[email-masked]> wrote:
> Hi,
>
> On Tue, Oct 27, 2009 at 2:13 PM, NOEL, ERIC C (ATTLABS) <[email-masked]> wrote:
>
>> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-package
>
> Is the goal to define a SIP event package enabling notification
> according to various XML schema (please see [1]) or rather mandating
> the support of a particular schema?
>
> [1] Draft ETSI ES 283 039-2 V3.0.0 (2009-06), Section 6
>
> Thanks,
> --
> Victor Pascual Ávila
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 15:40:17 +0100

Well, it does not preclude other schemas to be used in addition to the schema defined in it but it precludes using another schema exclusively. This restriction comes from clause 5.5: "If the Accept header field is present, it MUST include "application/load-control+xml" and MAY include any other types.

I believe it would be more flexible to consider the schema defined in the document as a default schema (i.e. in case the SUBSCRIBE request does not include an Accept header field) but not mandate its support.

Bruno

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Charles Shen
Envoyé : lundi 23 novembre 2009 15:27
À : Victor Pascual Avila
Cc : [email-masked]; NOEL, ERIC C (ATTLABS); Henning Schulzrinne
Objet : Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt]

Hi Victor:

Thanks

Charles

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Nov 2009 09:59:12 -0500

Without a must-support scheme, there is no interoperability, so it kind of defeats the purpose of a standard. Obviously, private parties can always agree on anything they want, but they shouldn't be claiming RFC-overload support, since they won't be able to interoperate.

Henning

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 19:39:59 +0100

Why not splitting the document into two RFCs? RFC-X would define the event package but not mandate any schema. RFC-Y would specify an IETF default schema. Anyone using the event package with exclusively a different schema would claim conformance to RFC-X but not to RFC-Y.
Bruno

-----Message d'origine-----
De : Henning Schulzrinne [mailto:[email-masked]] 
Envoyé : lundi 23 novembre 2009 15:59
À : CHATRAS Bruno RD-CORE-ISS
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt]

Henning

On Nov 23, 2009, at 9:40 AM, <[email-masked]> <[email-masked]> wrote:

> De : [email-masked] 
> [mailto:[email-masked]] De la part de Charles Shen 
> Envoyé : lundi 23 novembre 2009 15:27 À : Victor Pascual Avila Cc : 
> [email-masked]; NOEL, ERIC C (ATTLABS); Henning Schulzrinne 
> Objet : Re: [sip-overload] [Fwd: 
> I-DAction:draft-hilt-sipping-overload-07.txt]
> 
> Hi Victor:
> 
>>> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-pac
>>> k
>>> age
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Nov 2009 13:55:17 -0500

So far, event packages come with a schema. Without it, you don't get meaningful interoperability. I'm afraid I just don't understand the problem. Do you have a problem with the current proposal on a technical level?

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 13:47:51 +0100

-----Message d'origine-----
De : Henning Schulzrinne [mailto:[email-masked]] 
Envoyé : lundi 23 novembre 2009 19:55
À : CHATRAS Bruno RD-CORE-ISS
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt]

So far, event packages come with a schema. Without it, you don't get meaningful interoperability. 
==>BC: Yes indeed so far all RFCs defining an event package come with a schema. That's fact but this is not required by RFC3265 nor is the need for a must-support syntax. Actually, if the following document becomes an RFC, there will be at least one case where the event specification (ua-profile) does not come with any schema.
http://tools.ietf.org/html/draft-ietf-sipping-config-framework-16

I'm afraid I just don't understand the problem. Do you have a problem with the current proposal on a technical level?
==> BC: I don't have any fundamental technical problem with the current proposal and I think the schema it defines is a good default schema. However other schema exists. There is at least one alternative schema documented in an ETSI standard which I believe is likely to be used at the interface between SIP-based networks managed by Telcos, while the default package may well be used in other circumstances, including inside some Telcos' networks.

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 14:06:43 +0100

Hi Martin,

IMS and similar architectures bordered with a set of B2BUA/SBC. Anyway I should have said "between ***some of the *** SIP-based networks managed by Telcos"

Bruno

-----Message d'origine-----
De : DOLLY, MARTIN C (ATTLABS) [mailto:[email-masked]] 
Envoyé : mercredi 25 novembre 2009 13:53
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
Cc : [email-masked]; NOEL, ERIC C (ATTLABS); [email-masked]
Objet : RE: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt]

Bruno,

What SIP-based networks managed by telcos are you speaking of?

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, November 25, 2009 7:48 AM
To: [email-masked]
Cc: [email-masked]; NOEL, ERIC C (ATTLABS); [email-masked]
Subject: Re: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt]

-----Message d'origine-----
De : Henning Schulzrinne [mailto:[email-masked]] Envoyé : lundi 23 novembre 2009 19:55 À : CHATRAS Bruno RD-CORE-ISS Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked] Objet : Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Nov 2009 08:21:05 -0500

On Nov 25, 2009, at 7:47 AM, <[email-masked]> <[email-masked]> wrote:
> syntax. Actually, if the following document becomes an RFC, there will be at least one case where the event specification (ua-profile) does not come with any schema.

From my understanding, that draft is essentially dead, having been replaced by the SIP Forum effort (fortunately, given the former effort's complexity).

> ==> BC: I don't have any fundamental technical problem with the current proposal and I think the schema it defines is a good default schema. However other schema exists. There is at least one alter…

Nothing prevents the usage of that schema, as far as I can tell.

Henning

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 25 Nov 2009 14:25:28 +0100

There is nothing special about IMS in this respect. There is no greater requirement to use SBC in an IMS than there is in any other SIP based network.

regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, November 25, 2009 1:07 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [sip-overload] 
> [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt]
> 
> Hi Martin,
> 
> IMS and similar architectures bordered with a set of 
> B2BUA/SBC. Anyway I should have said "between ***some of the 
> *** SIP-based networks managed by Telcos"
> 
> Bruno
> 
> De : DOLLY, MARTIN C (ATTLABS) [mailto:[email-masked]] Envoyé 
> : mercredi 25 novembre 2009 13:53 À : CHATRAS Bruno 
> RD-CORE-ISS; [email-masked] Cc : 
> [email-masked]; NOEL, ERIC C (ATTLABS); 
> [email-masked] Objet : RE: [sip-overload] 
> [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt]
> 
> Bruno,
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Subject: Re: [sip-overload] 
> [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt]
> 
> De : Henning Schulzrinne [mailto:[email-masked]] Envoyé 
> : lundi 23 novembre 2009 19:55 À : CHATRAS Bruno RD-CORE-ISS 
> Cc : [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] Objet : Re: 
> [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt]
> 
> ==>BC: Yes indeed so far all RFCs defining an event package 
> come with a schema. That's fact but this is not required by 
> RFC3265 nor is the need for a must-support syntax. Actually, 
> if the following document becomes an RFC, there will be at 
> least one case where the event specification (ua-profile) 
> does not come with any schema.
> I'm afraid I just don't understand the problem. Do you have a 
> problem with the current proposal on a technical level?
> ==> BC: I don't have any fundamental technical problem with 
> the current proposal and I think the schema it defines is a 
> good default schema. However other schema exists. There is at 
> least one alternative schema documented in an ETSI standard 
> which I believe is likely to be used at the interface between 
> SIP-based networks managed by Telcos, while the default 
> package may well be used in other circumstances, including 
> inside some Telcos' networks. 
> 
> 
> On Nov 23, 2009, at 1:39 PM, 
> <[email-masked]> 
> <[email-masked]> wrote:
> 
> > Why not splitting the document into two RFCs? RFC-X would 
> define the event package but not mandate any schema. RFC-Y 
> would specify an IETF default schema. Anyone using the event 
> package with exclusively a different schema would claim 
> conformance to RFC-X but not to RFC-Y.
> > Bruno
>

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 14:40:29 +0100

Keith,

That's not what I meant. Of course one can roll-out an IMS without any SBC. I don't dispute that. I was just trying to answer Martin's question: "What SIP-based networks managed by telcos are you speaking of?". In the context of my previous message "SIP-based networks managed by Telcos" was a shortcut to refer to networks such as:

- IMS-based networks (with or without SBC/IBCF..)
- Operator controlled SIP-based networks including typically a number of application servers and a set of SBCs
- ...

Anyway, this discussion is a bit aside from my initial point...

Bruno

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:[email-masked]] 
Envoyé : mercredi 25 novembre 2009 14:25
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : RE: [sip-overload][Fwd:I-DAction:draft-hilt-sipping-overload-07.txt]

regards

Keith 

> IMS and similar architectures bordered with a set of B2BUA/SBC. Anyway 
> I should have said "between ***some of the
> : mercredi 25 novembre 2009 13:53 À : CHATRAS Bruno RD-CORE-ISS; 
> [email-masked] Cc :
> [email-masked]; NOEL, ERIC C (ATTLABS); [email-masked] 
> Objet : RE: [sip-overload] 
> : lundi 23 novembre 2009 19:55 À : CHATRAS Bruno RD-CORE-ISS Cc : 
> [email-masked]; [email-masked]; 
> ==>BC: Yes indeed so far all RFCs defining an event package come with 
> a schema. That's fact but this is not required by
> RFC3265 nor is the need for a must-support syntax. Actually, if the 
> following document becomes an RFC, there will be at least one case 
> where the event specification (ua-profile) does not come with any 
> schema.
> I'm afraid I just don't understand the problem. Do you have a problem 
> with the current proposal on a technical level?
> ==> BC: I don't have any fundamental technical problem with the 
> current proposal and I think the schema it defines is a good default 
> schema. However other schema exists. There is at least one alternative 
> schema documented in an ETSI standard which I believe is likely to be 
> used at the interface between SIP-based networks managed by Telcos, 
> while the default package may well be used in other circumstances, 
> including inside some Telcos' networks.
> 
> 
> define the event package but not mandate any schema. RFC-Y would 
> specify an IETF default schema. Anyone using the event package with 
> exclusively a different schema would claim conformance to RFC-X but 
> not to RFC-Y.
> > Bruno
>

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 14:41:13 +0100

Nothing prevents the usage of that schema, as far as I can tell.
==>BC: I agree. Nothing prevents the use of that schema. However,
according to the current draft, the SIP server sending the SUBSCRIBE
request will have to include both schema identifiers in the Allow-Events
header field although it may not support the default schema (or at least
it does not want to use it towards this peer). Of course in practice
this may not be an issue because in such configurations the other SIP
server will not support it either (or at least will not be willing to
use it) but it sounds more like a trick than a clean solution.