Subject: [Ioam] Benoit Claise's No Objection on charter-ietf-ioam-00-02: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 15 Feb 2017 07:43:44 -0800

Benoit Claise has entered the following ballot position for
charter-ietf-ioam-00-02: 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.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ioam/

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

I believe this functionality is important for network manageability. As a
reminder, this work got some support in OPSAWG.
And yes, there is the famous community debate: manageability vs privacy
... as seen in the RFC 7258 text and ballots:

       While PM is an attack, other forms of monitoring that might fit
the
       definition of PM can be beneficial and not part of any attack,
e.g.,
       network management functions monitor packets or flows and
anti-spam
       mechanisms need to see mail message content.  Some monitoring
can
       even be part of the mitigation for PM, for example, certificate
       transparency [RFC6962] involves monitoring Public Key
Infrastructure
       in ways that could detect some PM attack techniques.  However,
there
       is clear potential for monitoring mechanisms to be abused for PM,
so
       this tension needs careful consideration in protocol design. 
Making
       networks unmanageable to mitigate PM is not an acceptable
outcome,
       but ignoring PM would go against the consensus documented here. 
An
       appropriate balance will emerge over time as real instances of
this
       tension are considered.

I know the end users don't care about this, but some operators still have
network to operate.

Based on the recent IESG thread, the charter text could be improved, as
discussed:
- by Adrian Farrel:

    We want to define a layer-independent, encapsulation-independent
generic data format for carrying any OAM information in user data
packets. We expect this to be useful in the following list of forwarding
encapsulations <insert list> but the actual use of and encapsulation of
this generic data format will be worked on in coordination with the
working groups responsible for those encapsulations.

- by Joe Clarke:

    For example, would
    IOAM headers be excluded from packets that did not have any data
payload?

    Yeah, this is a bikeshed, but would text such as "packets within
    existing network flows" be better or clearer?

- By Tal Mizrahi:

    [RFC6291] OAM in our context stands for Operations, Administration,
and Maintenance.

- Frank Brockners:

    IOAM would be focused on gathering data, not interpreting data on
network nodes. I.e. IOAM is for operations support *not* for active
management of nodes

I'll most probably ballot yes when those clarifications are introduced.

Note: in the end, I don't care in which area this work is done. What
counts is the willingness to do work and the expertise.

Regards, Benoit