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

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/02/17 14:05, Tal Mizrahi wrote:
> Hi Stephen,
> 
> Minor comment: as in [RFC6291] OAM in our context stands for
> Operations, Administration, and Maintenance.

Fair enough, thanks.

The question in (3) though stands as to whether the scope
includes (the moral equivalent) of a ping of death or not.
Admin vs. Management in the acronym doesn't really impact
on that.

Cheers,
S.

> 
> 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
>