IETF Logo Mail Archive

Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06

Ben Campbell <ben@nostrum.com> Thu, 22 January 2015 21:37 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 73CCA1A87CA for <dime@ietfa.amsl.com>; Thu, 22 Jan 2015 13:37:26 -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 AaQjgB-2hBxu for <dime@ietfa.amsl.com>; Thu, 22 Jan 2015 13:37:25 -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 0C85B1A8766 for <dime@ietf.org>; Thu, 22 Jan 2015 13:37:25 -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 t0MLbOBf017613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 15:37:24 -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: <54BEC3E7.40703@usdonovans.com>
Date: Thu, 22 Jan 2015 15:37:23 -0600
X-Mao-Original-Outgoing-Id: 443655443.650339-b3b48f39432a16cb7c4988f1965f8886
Content-Transfer-Encoding: 8bit
Message-Id: <5D949CB1-5A5D-45A7-AB88-5B234BC89DF7@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>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/tS4G-RHwJqeOmrSw65TBdj5acOA>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] 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: Thu, 22 Jan 2015 21:37:26 -0000

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


On Jan 20, 2015, at 3:08 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:


At this point, I think we need to either say that sub-avps of DOIC grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT have the m-bit set unless the sub-avp is part of an extension explicitly negotiated in the feature vector.
SRD> I'm ok either way but prefer number 2).

I'm okay with 2, but it's really a bit redundant. If the AVP is a required-to-understand part of an extension, then negotiating the extension should be sufficient. The M-bit adds no additional semantics.

Basically, we are trying to say "never set the M-bit in a way that could cause a transaction to fail." That means either never setting it, or only setting it if you already know the recipient understands the AVP. Or more to the point, "Never set the M-bit unless the M-bit would be irrelevant anyway".

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

iQIcBAEBCgAGBQJUwW2TAAoJEIBWSmyV89QN9HYP/3pMzC7j+d8w/YLssPFjDEzc
BzCVzbzC9FO2AG6YvPs6qME12AaTWq0ow7LbWY2dGVtEFD8GeUzf6rd0d1rSDNoA
gt4U+DxUWVAFdbTsPq3sioElp+zzMpOosEiqMbRdXugTff3phmXtJKnMnG5n1dC6
Nlw2+6v+SFBlyiHQbU2LTZkPI2cQWRR+tN6HbLnqOWURgfbYGI+B+mEGxjRXK2Bj
Rdczd4te9GGg3Lonl/stiGWW+s58uykJR0mGyv96q7bOSQRrOoRcePUjBSE1/EwN
MjAICxREvi6RnoXdc1o9Rl7/wX6rD3Wl75tLMeISQmbKa+Rpsy+AtsV0bgaafXNB
NLfja+yhduCf85uZFYnoKCaHFJFp7i1dob1hFKX5qSTeCVsJJH+NQRtrTgJ0nHG9
pF98dYi/5NvjkzZ3uFRM7pIS438li5s7I76NUSJ4oCrdjdFwd6WEkgor/e1DCp1/
C6xeA5r0DiXKyJgJvgv19XNUP73e3dkF/noc/UAod7ax3M9TytF7ftRiNfv9jeW5
PdcsWh070D7Cjw0xFHRY/6L5+d1ltmsybd/5RFdmOaaJFd2m4TbhPeMvlQUje1Mq
Ra6foimCLxQR3cfkTqRGSBwPtXW9FfLy0obui4pVX3HTAi9ow6cBryhofAdvR89p
ewY/gaZFyth3Tf4yIxcF
=mSxA
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email