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

[Tal Mizrahi <[e-mail]>]

Hi Stephen,

Minor comment: as in [RFC6291] OAM in our context stands for Operations, Administration, and Maintenance.

Cheers,
Tal.

>-----Original Message-----
>From: Ioam [mailto:[e-mail]] On Behalf Of Stephen Farrell
>Sent: Wednesday, February 15, 2017 2:09 PM
>To: The IESG
>Cc: [e-mail]; [e-mail]
>Subject: [EXT] [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with
>BLOCK and COMMENT)
>
>External Email
>
>----------------------------------------------------------------------
>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.
>
>
>_______________________________________________
>Ioam mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ioam