[Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Tue, 10 May 2016 14:08 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 218EA12D09F; Tue, 10 May 2016 07:08:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kuehlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160510140801.538.20501.idtracker@ietfa.amsl.com>
Date: Tue, 10 May 2016 07:08:01 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/KE4poUgY-k8FPtWQEsKZNEAiEL0>
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org
Subject: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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 May 2016 14:08:01 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I fully agree with all discuss comments made by Ben and Alissa. However,
the summary here might be that this information might simply be not very
useful for the uses cases described. And there might be other mechanisms
that do not require any trust and that can address the uses cases easier
and more appropriate such a simply prioritization of a certain
application in the request handler/request agent or relative priorities
within one application (on sent-out). 

However, the one part that does actually concern me is:
"When using DRMP priority information, Diameter nodes MUST use the
   default priority for transactions that do not have priority specified
   in a DRMP AVP."
This part could lead to starvation of requests that do not define a
priority, e.g. because there are not supporting it (yet). However these
starved requests could effectively have a higher priortiy than the
request that they get starved by.


Why do you need 15 different priority levels? Wouldn't be two enough for
all or your use cases?