Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt
Stefan Winter <stefan.winter@restena.lu> Mon, 16 July 2012 06:29 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ECC11E807F for <radext@ietfa.amsl.com>; Sun, 15 Jul 2012 23:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 8gkgJYwLETsv for <radext@ietfa.amsl.com>; Sun, 15 Jul 2012 23:29:36 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83A21F846A for <radext@ietf.org>; Sun, 15 Jul 2012 23:29:36 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C46431057F for <radext@ietf.org>; Mon, 16 Jul 2012 08:30:19 +0200 (CEST)
Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7F36A1057D for <radext@ietf.org>; Mon, 16 Jul 2012 08:30:19 +0200 (CEST)
Message-ID: <5003B4F7.7030603@restena.lu>
Date: Mon, 16 Jul 2012 08:30:15 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: radext@ietf.org
References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C44967A@SZXEML510-MBS.china.huawei.com> <4FFED1D3.7060706@restena.lu> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C44B782@SZXEML510-MBS.china.huawei.com> <5000483E.5030800@restena.lu> <CAM+1sVDju57qbn1ZRo8hng6UK-HCk_0R245RcQVcB9D45QrK9Q@mail.gmail.com>
In-Reply-To: <CAM+1sVDju57qbn1ZRo8hng6UK-HCk_0R245RcQVcB9D45QrK9Q@mail.gmail.com>
X-Enigmail-Version: 1.4.3
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigBF59F13E07E6362A03CAC4CA"
X-Virus-Scanned: ClamAV
Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 06:29:39 -0000
Hello, > I haven't read the (competing?) drafts in a while, but one issue in your > most recent mail caught my attention. > > What's the fundamental difference between a string type encoding using > an (unregistered) user-private URN namespace and a Vendor > Specific Enumeration for an integer type? The latter is > an officially discouraged technique, in the RADIUS Design Guidelines, as > I recall. There is no vendor-specific enumeration in the other draft at all. That draft is very specific about sending IPv6 and/or IPv4 counter values, so there are exactly three defined enum values for those two traffic classes. The attribute is Acct-Traffic-Statistics.Stack-Type - the name suggests that it is not meant to be extensible to carry more meaning than the IP stack version. When discussing DSCP traffic classes as something people might want to count, the author introduced an entire new attribute for that, Acct-Traffic-Statistics.DSCP-Type. It is only meant to be used in conjunction with the IP stack one, to report on the intersecting set of these two orthogonal properties. All other values in these two attributes are reserved, suggesting that IETF Action is necessary to add new values. IOW, there is *no* extensibility in that draft. Assuming that people out there will at some point want to count other conditions in their accounting records, this forces them to hijack one of the reserved numbers, therewith breaking semantics of these attributes and hampering interop. > Flexibility for small users, who can't be bothered with managed > namespaces and codepoints is all well and good, but it seems to me that > the purpose of doing work in the IETF is to guarantee a high level > multi-vendor interoperability by formally defining such things. No? Sure: that's why the URN namespace option is devised to carry labels with defined and published meanings, which ensures interop. The non-URN strings are only meant for local use. They don't guarantee any interoperability - if the accounting data is to be shared across enterprises, they need to define a "proper" URN one and use that. As I wrote earlier, I don't care much about that use case, I could also live with dropping that option 2. It's just that I believe openness in this aspect doesn't hurt; the strings are compared char-by-char to find the one with a specific meaning anyway and it technically makes no difference at all whether it starts with "urn:" or not. And if we forbid that kind of use, my gut feeling from above applies here at well: if people want to use it in a non-URN way, they will. So if it doesn't hurt protocol-wise to provide a local-use loophole, and might help some people, we can just as well do it. (I am talking of local use as in the current IAB draft about protocol extensions: http://tools.ietf.org/html/draft-iab-extension-recs-17, Section 3.2.2; it might be useful to point to that reference in a later rev) Greetings, Stefan Winter > > Regards, > > Dave > > David B. Nelson > Director of Technology > Elbrys Networks, Inc. > www.elbrys.com <http://www.elbrys.com> > +1.603.570.2636 > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
- [radext] Fwd: New Version Notification for draft-… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Peter Deacon
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Peter Deacon
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Dave Nelson
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Peter Deacon
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Peter Deacon
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Peter Deacon
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Alan DeKok
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter
- Re: [radext] Fwd: New Version Notification for dr… Leaf yeh
- Re: [radext] Fwd: New Version Notification for dr… Stefan Winter