[trill] Mirja Kühlewind's No Objection on draft-ietf-trill-irb-13: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Wed, 29 June 2016 22:13 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB0412DA8E; Wed, 29 Jun 2016 15:13:11 -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.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160629221311.30384.53041.idtracker@ietfa.amsl.com>
Date: Wed, 29 Jun 2016 15:13:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/rkpBCXcbW2L67fP35MCswoxX7h0>
Cc: d3e3e3@gmail.com, trill-chairs@ietf.org, draft-ietf-trill-irb@ietf.org, trill@ietf.org
Subject: [trill] Mirja Kühlewind's No Objection on draft-ietf-trill-irb-13: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 22:13:14 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-trill-irb-13: No Objection

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:
https://datatracker.ietf.org/doc/draft-ietf-trill-irb/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two minor comments:

1) There are only few SHOULDs and MUSTs in this whole document 
   and where they are used it is often not very clear what the action 
   is that should follow and how it should be implemented 
  (e.g. "The network operator MUST ensure the consistency of the 
   tenant ID on each edge RBridge for each routing domain."). 
  And maybe there are actually more case where normative 
  language should be used? 
  Please double-check the use of normative langauge in this document!

 2) A similar question on the following part:
  „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re-
   advertise the local tenant Data Label, tenant gateway MAC, and
   related IP prefixes information of the rest tenants to other edge
   RBridges. […] Therefore the transient routes consistency won't 
  cause issues other than wasting some network bandwidth.“
  Wasting network resources actually can be an issue. 
  So why is this not an MUST?