Subject: [bess] Terry Manderson's Abstain on draft-ietf-bess-ir-05: (with COMMENT)

From: "Terry Manderson" <[email-masked]>
Date: Wed, 17 Aug 2016 18:00:55 -0700

Terry Manderson has entered the following ballot position for
draft-ietf-bess-ir-05: Abstain

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-bess-ir/

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

I have some concerns about this document that I don't believe can be
easily fixed.

This  document is extremely hard to read and understand, and therefore
comprehend if there are any implications to the information provided. I'm
really not sure that this can be addressed here without a significant
rewrite.  (that might be because the topic itself is deep)

A second is related to how the document positions itself. Its status is
for Standards Track, yet in the introduction it says:

In this document, we provide a clearer and more explicit conceptual
   model for IR P-tunnels, clarifying the relationship between an IR
   P-tunnel and the unicast tunnels that are used for data transmission
   along the IR P-tunnel.

and

 This document does not provide any new protocol elements, or any
   fundamentally new procedures; its purpose is to make explicit just
   how a router is to use the protocol elements and procedures of
   [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR
   P-tunnel, and to prune itself from an IR P-tunnel.

Which to me screamed out informational,  while then updating 6513 and
6514. However there are parts of the document that imply a semantic
change in the use of fields or labels. Eg sect 10, use of timers when
switching Upstream Multicast Hop.. so strongly suggesting a standards
position.

It feels like this document started out to do one thing, eg clarify the
model of IR P-Tunnels and then acquired an extended set of tasks in
dealing with MPLS label allocation policies.

As I can't see a way to make a clear assessment of this document, I am
taking an ABSTAIN position, and I will not block publication.