IETF Logo Mail Archive

Re: [Dime] DOIC M-Bit usage (was Re: WLGC #2 for draft-ietf-dime-ovli-06)

Ben Campbell <ben@nostrum.com> Fri, 23 January 2015 15:43 UTC

Return-Path: <ben@nostrum.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 DA24F1A9232 for <dime@ietfa.amsl.com>; Fri, 23 Jan 2015 07:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 nvoW7tp2QsuG for <dime@ietfa.amsl.com>; Fri, 23 Jan 2015 07:43:30 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2390C1A9177 for <dime@ietf.org>; Fri, 23 Jan 2015 07:43:30 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0NFhPHX013088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 09:43:26 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset="utf8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Pgp-Agent: GPGMail 2.5b4
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <54C26BB3.1010401@usdonovans.com>
Date: Fri, 23 Jan 2015 09:43:25 -0600
X-Mao-Original-Outgoing-Id: 443720605.102611-965eeff831ccf236942d70fb41d2efba
Content-Transfer-Encoding: 8bit
Message-Id: <726C8230-94C1-4DDB-8EB2-EB5820B3130D@nostrum.com>
References: <54B5399D.3020600@gmail.com> <AEE2E3C8-9ADF-4D0F-9793-B1F15A0EFDBA@nostrum.com> <54BEA19E.80309@usdonovans.com> <444F5015-38E2-4D19-A5F8-EBC32BAD38F6@nostrum.com> <54BEC3E7.40703@usdonovans.com> <54C10B60.7010405@usdonovans.com> <087A34937E64E74E848732CFF8354B92098ADD13@ESESSMB101.ericsson.se> <56CE9F81-1BE9-489A-9C80-52D0DBAD2609@nostrum.com> <087A34937E64E74E848732CFF8354B92098ADF6A@ESESSMB101.ericsson.se> <54C249E1.5050702@usdonovans.com> <AAADB66E-EFDF-4084-8D58-C98A6CD107A6@nostrum.com> <54C26BB3.1010401@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/-e2Q5HX6xzrdga9uvqSewp4FtWo>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] DOIC M-Bit usage (was Re: WLGC #2 for draft-ietf-dime-ovli-06)
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, 23 Jan 2015 15:43:32 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On Jan 23, 2015, at 9:41 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

What's the point of 2)? It still introduces a way that a DOIC extension might cause the application transaction to fail. Do we want that?

On Jan 23, 2015, at 7:17 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

I would propose the following resolution to the M-bit issue:

1) We say that new extensions MUST NOT require the M-bit be set for new sub-AVPs of the OC-Supported-Features AVP or the OC-OLR AVP.

2) We indicate that if there a new extension includes behavior that requires 6733 defined M-bit behavior then the new extension can define a new AVP. It just can't make that new AVP part of OC-Supported-Features or OC-OLR.
SRD> Well, there's nothing we can do to prevent it, which makes it redundant to even say it.  So, I plan to do 1).  I'll wait until Monday to publish -07 (assuming we have resolution to all the issues) to give our European friends a chance to comment.


Works for me.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUwmwdAAoJEIBWSmyV89QNFLIP/AkpABA54OlKpbhq4c7dFjqj
mNeZaoFZyirusCiJ43NxQv4DPTP+2aqqCAw6BNtkQgsIu3MH+oFwJn/eeZRql5La
wGRnnEZpt4qSLElk1yW/U2UupmwTWUm+/TKyLFhAlpN4TQc5AKoxryOEZ50E2/V4
RQktS338k+RB48IDx6TC/fDC+TTPsrLuqu3EbEP2kZiYlOcu1gcIOmpCbevpCkX9
D9o3laMQJQKAjPtLr6tSzpw7GWP1mdr8SlthSeL/E8RErpltVEnIeQf7+Xo8hkit
o+v1B/40FAbZnVN7OEz20pIBg7275Ma6b2E6Lu351n0uZ2do92fzc/3TsEfg90eg
hAJEq3q5e+S824nexTULxnsHdXh+OQRlzKCks4Pv8id3YKdyBQZ5dm5CEzo9xAFi
t3disG3xQqHbZ8U6eDShGqcXJmrlJ9er28Tduw1S08xiFLFJKYwQkgbBfD50ZwK1
U8ZZDw3/+EfvRd6n75eCLy5bnkESEeaPmCYYGthgx+amZ2cd1xUscbv1p9pxXudS
rV+JHEVLfYgDLYvcr8e5H1YQ9c5MMMNh8MtfSYkASsD14UNfDAz7i1vvHRKYmedT
LUF8NKxa3ySTaFR9WB+b4MQctY/wtUxeS9M96r+2EVJ03A/zsQhFAGicmWQM9cO2
fcI9AA5g612eaFuZaW8K
=yeS/
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email