Re: [Dime] Issue#30 status

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 28 February 2014 13:48 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79521A049E for <dime@ietfa.amsl.com>; Fri, 28 Feb 2014 05:48:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBOISpiBjVAt for <dime@ietfa.amsl.com>; Fri, 28 Feb 2014 05:48:40 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 95BDF1A048A for <dime@ietf.org>; Fri, 28 Feb 2014 05:48:39 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id ec20so2751338lab.29 for <dime@ietf.org>; Fri, 28 Feb 2014 05:48:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wPgaGZF08Y5bADAs12MXDh37losClV3F9kZ7lfFRI8E=; b=kl6xlWzGKhUjgmVL5Dd1R+B2k0FMimb/qFo25qyDVjekpDw/0smlnkreREsVjiV1IZ cGc4zqpp8e/noeNKoExR62T2Ccmm74hGmayIVMEbVfQ+DdSZekow3Ef0RQRrO6cmkeu5 ZAOOMNMvFq6keQZhBpMWPkl1Rji0prY/VOPzMBeNOrPgB0K5N/5PDFAeClVNE3K2TIw/ YTQe4iMrQcUeLVUTA5fy8BB3gi7waZqU54N82mWliifBf9s1hCKSqjTIx/scG1V4RePy y/XHPa9qmI1tOZ4mcDacN1vTK0Ky9nLHNX4gtPHHAIFi7CtjBPEbnRcDXPnbamkBpvKm +s9w==
X-Received: by 10.152.6.199 with SMTP id d7mr11590825laa.22.1393595317059; Fri, 28 Feb 2014 05:48:37 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id q8sm4009955lbr.3.2014.02.28.05.48.32 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 05:48:32 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net>
Date: Fri, 28 Feb 2014 15:48:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B94C00CB-B125-4954-A3B4-8D2D997A440B@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <B5E91287-7462-4531-9F48-C5F124C19BE3@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Gs4R3AnhBZ347OYKAao4FNxVxaE
Cc: Ben Campbell <ben@nostrum.com>, "dime@ietf.org list" <dime@ietf.org>
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 13:48:42 -0000

<as a chair>

Right. We are going back and forth and continue to do that as long
as none of these moving parts can be nailed down. My proposal here
is that we simply agree now that OC-Supported-Features is in every
answer message. Period. Get one corner nailed down.

The rest of the fixing inconsistencies and missing/excess parts
listed below then need to be done according to the above decision.

- JOuni


On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

> Anders,
> 
> Yes, if we conclude that there is a requirement for OC-Supported-Features to be sent in answers, then it should be included in every answer. However, I still don't see that requirement. In addition we would need some text specifying the expected behaviour of the reacting node when receiving OC-Supported-Features in an answer, keeping in mind that the reacting node cannot know whether it was the server or an agent that inserted the OC-Supported-Feature, and whether or not a subsequent request will be routed via that node.
> 
> Ulrich
> 
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Anders
> Sent: Thursday, February 27, 2014 6:14 PM
> To: Ben Campbell; Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
> 
> I also agree that including OC-Supported-Features in every answer is preferable. In addition to mirroring Requests, it is in-line with how Supported-Features are managed in at least some 3GPP interfaces as well.
> 
> /Anders
> 
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Wednesday, February 26, 2014 9:19 AM
> To: Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
> 
> 
> On Feb 26, 2014, at 9:14 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
> 
>> SRD> We don't have consensus yet, but if we agree on the need for reacting nodes to know whether there is support for DOIC in the Diameter network then I think the requirement would be similar to how we are handling overload reports.  The reporting node MUST ensure that all reacting nodes receive the OC-Supported-Features AVP.  This can be done by including the AVP in all answer messages or it can be done by remembering to whom the AVP has been sent.
> 
> Given the trivial nature of sending and reading OC-Supported-Features, I think we should put it in every answer. This mirrors the way we handle it in requests.
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime