IETF Logo Mail Archive

Re: [Dime] Conclusion for the Report Type

"Nirav Salot (nsalot)" <nsalot@cisco.com> Tue, 10 December 2013 05:15 UTC

Return-Path: <nsalot@cisco.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 6FDD31AE1C5 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 21:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 V8OX9bwwbusc for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 21:15:35 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A810B1AE1C4 for <dime@ietf.org>; Mon, 9 Dec 2013 21:15:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2093; q=dns/txt; s=iport; t=1386652531; x=1387862131; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C0/NjdnWZ6Pxx9a07V4SvwuVXPDtUfLL+Na1/2JXTOA=; b=CmjpoHNH+TYdCmKWtAq+sjC3tzn8ZAg6uf1vzJTpZG56/u7MlYizgmsL 1wQvkQ8OkR9rSUgSaWIlCNKa+CZ4VvPe5H2Su5It7cWK3pPfOwUOLr3tk 3Df5vtYjl+L/oDl6wHXM6FM7Biv0vNPvxOrjEkFrD6jhYpCqvvzQb4Pg/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAJOiplKtJV2c/2dsb2JhbABZgwc4U7kWgSMWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiHeg3AUBMEjlQ4BoMagRMDqieDKYIq
X-IronPort-AV: E=Sophos;i="4.93,863,1378857600"; d="scan'208";a="290447174"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2013 05:15:30 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBA5FUIX006951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 05:15:30 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 23:15:30 -0600
From: "Nirav Salot (nsalot)" <nsalot@cisco.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>, "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZBgN7qEWGWcUC1LbudqyUITZpM42pg
Date: Tue, 10 Dec 2013 05:15:29 +0000
Message-ID: <A9CA33BB78081F478946E4F34BF9AAA014D2D959@xmb-rcd-x10.cisco.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
In-Reply-To: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.142.140.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] Conclusion for the Report Type
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: Tue, 10 Dec 2013 05:15:37 -0000

Jouni,

I am fine with the principles you have mentioned below for Report Type.
I also prefer to use enumerated type for this AVP if that does not risk the extendibility of this AVP.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Monday, December 09, 2013 5:30 PM
To: dime@ietf.org list
Subject: [Dime] Conclusion for the Report Type

Folks,

We need a conclusion here so that I can actually write something into the -01. How about the following (I try to reflect as many points given here as possible):

1) The basic principle for the Report Type use is that only one
   OLR per report type is allowed unless the report type and the
   OLR reflecting the new report type define exact semantics how
   to differentiate between multiple OLRs with the same report
   type. In 3GPP context, for example, a report type with an AVP
   that identifies an APN could be such a differentiator.. and that
   would need a new report type where an implementation exactly
   knows to look for this additional AVP without guesswork or 
   fuzzy heuristics.

2) A new report type or a set of new report types require a new
   feature to be allocated/defined so that both endpoints know how
   to handle the new report type that was defined after the
   publication of the baseline specification. The handling of the
   new report types must be defined (along with the new AVPs it
   might need to be included into the OC-OLR AVP).

3) With 2) in place I do not care whether the OC-Report-Type is
   enumerated or unsigned (flag vector?). I still favour Enumerated
   myself as it forces the protocol designer to come up with a 
   cleaner design ;)

4) For the baseline we only define host and realm report types.
   We do not allow multiple OLRs with these report types i.e.
   single instances of OLRs with host and/or realm are allowed.

- Jouni
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

v2.23.0 | Report a Bug | By Email