Subject: [Dime] Snapshot of -02 version of DOIC draft

From: Steve Donovan <[email-masked]>
Date: Sat, 08 Mar 2014 11:19:00 +0000

All,

I have made updates to the -02 version of the DOIC draft based on
resolution to the following issues:

24, 32, 50, 51, 52, 47 and 37

I had also started to make updates for issues 29, 31 and 34 before we
agreed that the proposed text needs to be updated in the issue tracker
before the edits are made.  I'll clean up these updates when we have the
wording put into issue tracker.

To those who own issues in issue tracker, if we have resolution of the
issue on the mailing list please update issue tracker ASAP so the edits
can be put into the -02 draft.

Thanks,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Sat, 08 Mar 2014 11:20:37 +0000

One other thing, the latest snapshot can be found here:

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

This is very much a work in progress with a number of items that will
need to be cleaned up before it is submitted to the IETF.

Steve

On 3/8/14 11:19 AM, Steve Donovan wrote:
> before the edits are made.  I'll clean up these updates when we have
> the wording put into issue tracker.
>
> issue on the mailing list please update issue tracker ASAP so the
> edits can be put into the -02 draft.
>
> Thanks,
>
> Steve
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Mar 2014 12:06:46 +0000

Hello Steve,

According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be included in all request messages sent by a DOIC supporting node. (not yet agreed).

Text marked in green below requires updates:

5.3.1.  Reacting Node Endpoint Considerations

   The basic principle is that the request message initiating endpoint
   (i.e. the "reacting node") announces its support for the overload
   control mechanism by including in the request message the OC-
   Supported-Features AVP with those capabilities it supports and is
   willing to use for this Diameter session (or transaction in a case of
   a non-session state maintaining applications, see Section 3.1.2 for
   more details on Diameter sessions).  It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint.  In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features.

   Once the endpoint that initiated the request message receives an
   answer message from the remote endpoint, it can detect from the
   received answer message whether the remote endpoint supports the
   overload control solution and in a case it does, what features are
   supported.  The support for the overload control solution is based on
   the presence of the OC-Supported-Features AVP in the Diameter answer
   for existing application.

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: sábado, 08 de marzo de 2014 12:19
To: [email-masked]
Subject: [Dime] Snapshot of -02 version of DOIC draft

All,

I have made updates to the -02 version of the DOIC draft based on resolution to the following issues:

I had also started to make updates for issues 29, 31 and 34 before we agreed that the proposed text needs to be updated in the issue tracker before the edits are made.  I'll clean up these updates when we have the wording put into issue tracker.

To those who own issues in issue tracker, if we have resolution of the issue on the mailing list please update issue tracker ASAP so the edits can be put into the -02 draft.

Thanks,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 17 Mar 2014 12:11:53 -0500

Maria Cruz,

I updated the text based on what was put in the issue tracker when you
closed the issue.

Are you suggesting that this issue needs to be re-opened so we can
discuss whether OC-Supported-Features is needed in mid-session requests?

Steve

On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
>
> Hello Steve,
>
>  
>
> According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be
> included in all request messages sent by a DOIC supporting node. (not
> yet agreed).
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Steve Donovan
> *Sent:* sábado, 08 de marzo de 2014 12:19
> *To:* [email-masked]
> *Subject:* [Dime] Snapshot of -02 version of DOIC draft
>
>  
>
> All,
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 17 Mar 2014 21:32:30 +0000

Hello,

Well, text needs to be cleaned since it has impacts along the doc, apart from what is being discussed.
Not sure whether it is better to open a new issue or reopen this one.  Both options are fine with me.
Cheers
/MCruz

From: Steve Donovan [mailto:[email-masked]]
Sent: lunes, 17 de marzo de 2014 18:12
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft

Maria Cruz,

I updated the text based on what was put in the issue tracker when you closed the issue.

Are you suggesting that this issue needs to be re-opened so we can discuss whether OC-Supported-Features is needed in mid-session requests?

Steve

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: sábado, 08 de marzo de 2014 12:19
To: [email-masked]<mailto:[email-masked]>
Subject: [Dime] Snapshot of -02 version of DOIC draft

All,

Thanks,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Mar 2014 07:58:10 -0500

Maria Cruz,

Let me first try to convince you that we don't need the session scoping
of OC-Supported-Features.  If I'm not successful then we can open an issue.

The two options is to scope the capability advertisement to be either
transaction-based or session-based.  A subset of applications, those
that do not use sessions, will be transaction-based by definition. 
Applications that use sessions could use either transaction or session
scoping on capability advertisement.

The one clear advantage of allowing for session-based scoping is it
reduces the size of non session initiating requests and answers.  I
don't see other advantages but may be missing some.

The big disadvantage I see for session-based scoping is the impact on
agents.  This would require agents to become session aware, something
that is otherwise not required.  It might also require sharing that
session-state across multiple agents.  Again, this is not otherwise
required.

The following are the advantages I see for supporting only
transaction-based scoping:

1) Consistency across all applications.  There is no need to have two
implementations of DOIC, one for session-based applications and another
for transaction-based applications.  The DOIC handler can always go to
the same place to determine the results of the capabilities exchange --
the OC-Supported-Features AVP in the appropriate message -- instead of
having to go the to stored session state if the scope is session-based.

2) Statelessness - Transaction-based scoping allows for capability
advertisement to be completely stateless. 

3) Agent impacts - Transaction-based scoping removes the need for
maintaining per session DOIC state in agents.  This is a big advantage
(in my opinion).

One other point is that supporting transaction-based scoping in
session-based applications does not break anything.  It does have the
negative of adding the OC-Supported-Features AVP to all messages, but
that is a small negative.

Regards,

Steve

On 3/17/14 4:32 PM, Maria Cruz Bartolome wrote:
> *From:*Steve Donovan [mailto:[email-masked]]
> *Sent:* lunes, 17 de marzo de 2014 18:12
> *To:* Maria Cruz Bartolome; [email-masked]
> *Subject:* Re: [Dime] Snapshot of -02 version of DOIC draft
>
>  
>
> Maria Cruz,
>
>     According to conclusion on #Issue 51: OC-Supported-Feature AVP
>     MUST be included in all request messages sent by a DOIC supporting
>     node. (not yet agreed).
>
>      
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     I had also started to make updates for issues 29, 31 and 34 before
>     we agreed that the proposed text needs to be updated in the issue
>     tracker before the edits are made.  I'll clean up these updates
>     when we have the wording put into issue tracker.
>
>     To those who own issues in issue tracker, if we have resolution of
>     the issue on the mailing list please update issue tracker ASAP so
>     the edits can be put into the -02 draft.
>
>     Thanks,
>
>     Steve
>
>  
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Mar 2014 09:10:47 -0500

I was under the impression that Jouni's original text did have, at least by implication, session scoping of OC-Supported-Features, and that we had discussed and decided against it.

I would also argue that the lifetime of a certain configuration of OC-Supported-Features and lifetimes of sessions are likely to be widely different. Many installations will be constantly establishing and terminating sessions. I don't think the size advantage for mid-session requests would turn out to be much of an advantage in practice.

Thanks!

Ben.

On Mar 18, 2014, at 7:58 AM, Steve Donovan <[email-masked]> wrote:

> Maria Cruz,
> 
> Let me first try to convince you that we don't need the session scoping of OC-Supported-Features.  If I'm not successful then we can open an issue.
> 
> The two options is to scope the capability advertisement to be either transaction-based or session-based.  A subset of applications, those that do not use sessions, will be transaction-based by definition.  Applications that use sessions could use either transaction or session scoping on capability advertisement.
> 
> The one clear advantage of allowing for session-based scoping is it reduces the size of non session initiating requests and answers.  I don't see other advantages but may be missing some.
> 
> The big disadvantage I see for session-based scoping is the impact on agents.  This would require agents to become session aware, something that is otherwise not required.  It might also require sharing that session-state across multiple agents.  Again, this is not otherwise required.
> 
> The following are the advantages I see for supporting only transaction-based scoping:
> 
> 1) Consistency across all applications.  There is no need to have two implementations of DOIC, one for session-based applications and another for transaction-based applications.  The DOIC handler can always go to the same place to determine the results of the capabilities exchange -- the OC-Supported-Features AVP in the appropriate message -- instead of having to go the to stored session state if the scope is session-based. 
> 
> 2) Statelessness - Transaction-based scoping allows for capability advertisement to be completely stateless.  
> 
> 3) Agent impacts - Transaction-based scoping removes the need for maintaining per session DOIC state in agents.  This is a big advantage (in my opinion).
> 
> One other point is that supporting transaction-based scoping in session-based applications does not break anything.  It does have the negative of adding the OC-Supported-Features AVP to all messages, but that is a small negative.
> 
> Regards,
> 
> Steve
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 18 Mar 2014 14:51:29 +0000

Steve,

I was in favor already of capability advertisement per transaction :)

What I meant, but I can see I did not convey my message successfully, is that since we have agreed OC-Supported-Features is included in every message, then this implies a capability advertisement per transaction, and then some text that was before there to consider capability advertisement per session should be removed/updated, like the one I highlighted in green below.

I hope this clarifies
Thanks
/MCruz

From: Steve Donovan [mailto:[email-masked]]
Sent: martes, 18 de marzo de 2014 13:58
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft

Maria Cruz,

Regards,

Steve

From: Steve Donovan [mailto:[email-masked]]
Sent: lunes, 17 de marzo de 2014 18:12
To: Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft

Maria Cruz,

Steve

Best regards
/MCruz

All,

Thanks,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Mar 2014 09:58:25 -0500

Maria Cruz,

My apologies, I misunderstood your comments.

I agree we need to remove the text you indicated, and any other similar
text.  I actually reflected that in the proposal I made yesterday for
the resolution to issue #29.  Hopefully I didn't miss any required changes.

Regards,

Steve

On 3/18/14 9:51 AM, Maria Cruz Bartolome wrote:
>
> Steve,
>
>  
>
> I was in favor already of capability advertisement per transaction J
>
>  
>
> What I meant, but I can see I did not convey my message successfully,
> is that since we have agreed OC-Supported-Features is included in
> every message, then this implies a capability advertisement per
> transaction, and then some text that was before there to consider
> capability advertisement per session should be removed/updated, like
> the one I highlighted in green below.
>
>  
>
> I hope this clarifies
>
> Thanks
>
> /MCruz
>
>  
>
> *Sent:* martes, 18 de marzo de 2014 13:58
> Let me first try to convince you that we don't need the session
> scoping of OC-Supported-Features.  If I'm not successful then we can
> open an issue.
>
> implementations of DOIC, one for session-based applications and
> another for transaction-based applications.  The DOIC handler can
> always go to the same place to determine the results of the
> capabilities exchange -- the OC-Supported-Features AVP in the
> appropriate message -- instead of having to go the to stored session
> state if the scope is session-based.
>
>     *To:* Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]>
>         MUST be included in all request messages sent by a DOIC
>         supporting node. (not yet agreed).
>
>          
>
>         I had also started to make updates for issues 29, 31 and 34
>         before we agreed that the proposed text needs to be updated in
>         the issue tracker before the edits are made.  I'll clean up
>         these updates when we have the wording put into issue tracker.
>
>         To those who own issues in issue tracker, if we have
>         resolution of the issue on the mailing list please update
>         issue tracker ASAP so the edits can be put into the -02 draft.
>
>         Thanks,
>
>         Steve
>
>      
>
>  
>