[Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
charter-ietf-ioam-00-02: Block

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/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------


(1) I think we should have a BoF for this. Given the
similarities with SPUD/PLUS (see [1] below) just going ahead
and chartering this (and in RTG?) seems to be very badly
inconsistent on behalf of the IESG, given the community
concern about at least the meta-data insertion aspects in
common. (And maybe more aspects.)

(2) As with SPUD/PLUS I am very concerned at the potential
privacy (not security) implications of any generic method of
injecting meta-data whether that be into transport layer
flows/sessions or at other layers. I do not see how doing that
at any layer that can potentially span the Internet is
different from doing the same thing at any other layer. I am
concerned that there may not in fact be any acceptable
solution for this problem (other than not aiming to allow any
generic encoding), so I think this is something that does need
to be discussed before external review happens. I am not
convinced by the "domain" boundary argument in the charter -
such things leak and/or the concept of "domain" is too
ill-defined. A further point here is that the suggested
timeline (data format defined in April 2017) clearly suggests
that the idea here is to define a way to add a generic TLV
structure to any packet, which I think equally clearly means
that all of the privacy issues are relevant. 

(3) I assume the "M" in the name is for management. I don't
see what would prevent someone developing a standardised ping
of death if that is the case. (Or actually, possibly many
flavours of that.) And actually that'd probably be inevitable
if the "M" is really seriously meant. I am not sure that we
(the IETF) would like that. That makes me wonder if the scope
here is at all sufficiently well defined - is the implication
of the name that the proponents want to be able to do all
management functions this way, or just some? If just some, then
which, and why is that a good idea?

[1] https://www.ietf.org/proceedings/96/plus.html


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


- I remain unconvinced that this can go ahead before the IPv6
header processing discussion currently happening on
[e-mail] is resolved.

- Were I mostly interested in "transport" issues, I'd be quite
concerned about those as well - there are also things in
common between this and SPUD/PLUS in that respect I figure,
though I'm not anything like expert on that.