Re: [Tsv-art] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

"Pete Resnick" <resnick@episteme.net> Fri, 07 December 2018 21:16 UTC

Return-Path: <resnick@episteme.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DB5130FEC; Fri, 7 Dec 2018 13:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4lMw1pV6tu6; Fri, 7 Dec 2018 13:16:34 -0800 (PST)
Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDD129AB8; Fri, 7 Dec 2018 13:16:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id BA6DE6FAB0FD; Fri, 7 Dec 2018 15:16:32 -0600 (CST)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1GfS8sKzsFW; Fri, 7 Dec 2018 15:16:30 -0600 (CST)
Received: from [172.16.1.76] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 10E5A6FAB0ED; Fri, 7 Dec 2018 15:16:30 -0600 (CST)
From: Pete Resnick <resnick@episteme.net>
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: Joe Touch <touch@strayalpha.com>, ombudsteam@ietf.org, tsv-ads@ietf.org, ops-ads@ietf.org, tsv-art@ietf.org, opsec wg mailing list <opsec@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf <ietf@ietf.org>
Date: Fri, 07 Dec 2018 15:16:29 -0600
X-Mailer: MailMate (1.12.2r5568)
Message-ID: <20B602F2-5D9E-4482-9018-58D38EC98C4B@episteme.net>
In-Reply-To: <CAL9jLab=Cbwvvxu2p=wOfeGZ4L4xCfqUCV-uZdOor24R54Fncw@mail.gmail.com>
References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <c959d8cb6f6a04a8da8318cfa89da341@strayalpha.com> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <C4D47788-0F3D-4512-A4E3-11F3E6EC230B@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <C929A8B9-D65C-4EF7-9707-2238AE389BE3@strayalpha.com> <CAL9jLaY4h75KK4Bh-kZC6-5fJupaNdUfm1gK2Dg99jBntMCEyQ@mail.gmail.com> <C47149DC-CAF2-449F-8E18-A0572BBF4746@strayalpha.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <e5198c02-ebc6-ee3e-96cb-fd2831164f41@gmail.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <E008EA4B-74D3-4251-BFB8-B88F544B2A99@strayalpha.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <CAL9jLaYPPiXECcLdCfe35tCwBaSvswObo7skO7pqN2t2TXskqw@mail.gmail.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> <CAL9jLaaEGM49j9nKWb+x_GsakKd2hUhK2U1oW3Vbme5Ot1r42w@mail.gmail.com> <A9084623-1C3E-4203-8046-9C6D0857821A@strayalpha.com> <CAL9jLab=Cbwvvxu2p=wOfeGZ4L4xCfqUCV-uZdOor24R54Fncw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_A4B9BC1D-9C1D-4749-9E45-8D0F77E65FB2_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[2793, 3514], "plain":[2104, 2139], "uuid":"F1A49072-1E89-4EDB-B897-45C0B4D9BB94"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/2d6DDUvD8y0jMNdU1dYKeeuOjwQ>
Subject: Re: [Tsv-art] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 21:16:37 -0000

With my Ombudsperson-hat firmly on my head:

If you do wish to make a report to the Ombudsteam, please do that in 
private email; Cc'ing a bunch of mailing lists is an inappropriate venue 
for such a report.

That said, it's not clear that this falls under our purview. From the 
Introduction to RFC 7776:

     The IETF has general policies for managing disruptive behavior in 
the
     context of IETF activities.  In particular, [RFC7154] provides a 
set
     of guidelines for personal interaction in the IETF, and [RFC2418] 
and
     [RFC3934] give guidelines for how to deal with disruptive behavior
     that occurs in the context of IETF working group face-to-face
     meetings and on mailing lists.

     However, there is other problematic behavior that may be more
     personal and that can occur in the context of IETF activities
     (meetings, mailing list discussions, or social events) that does 
not
     directly disrupt working group progress but nonetheless is
     unacceptable behavior between IETF Participants.  This sort of
     behavior, described in the IESG Statement "IETF Anti-Harassment
     Policy" [Policy], is not easily dealt with by our previously 
existing
     working group guidelines and procedures.  Therefore, this document
     sets forth procedures to deal with such harassing behavior.

     These procedures are intended to be used when other IETF policies 
and
     procedures do not apply or have been ineffective.

Since this is all taking place on public lists, and at least at first 
glance does not appear to be the kind of "more personal" behavior that 
RFC 7776 is talking about, it seems like going to the appropriate AD, or 
WG chair, or IETF list sergeant-at-arms, would be the more obvious first 
step. But again, first glances are not always accurate, so if you (or 
anyone) feels that particular behavior has crossed the line into the 
inter-personal sort (as against simply disruptive), please do not 
hesitate to drop an email to the Ombudsteam; we're more than happy to 
discuss it and help resolve it, privately.

pr

On 6 Dec 2018, at 23:27, Christopher Morrow wrote:

> On Thu, Dec 6, 2018 at 9:11 AM Joe Touch <touch@strayalpha.com> wrote:
>
>>
>>
>> On Dec 5, 2018, at 10:28 PM, Christopher Morrow 
>> <morrowc.lists@gmail.com>
>> wrote:
>>
>>
>>
>> On Thu, Dec 6, 2018 at 12:31 AM Joe Touch <touch@strayalpha.com> 
>> wrote:
>>
>>> Additionally, packets don’t emerge from different mole endpoints 
>>> or are
>>> IP  processed in any way. The mold acts like a wire, which is fine. 
>>> That
>>> can be done by IP tunnels too. But not routers that converge and 
>>> diverge
>>> packets.
>>>
>>
>> That got mangled by autocorrect.  Packets aren’t supposed to be IP
>> processed by links. To the extent that MPLS does this, it is broken 
>> vs the
>> Internet arch.  Remember that MPLS tries to emulate a router path 
>> that
>> can’t keep up.  It can - and does - fail to do so correctly in some 
>> cases.
>>
>>
> Joe, frankly I'm pretty sad that your behavior here is such as this.
> I would like the IETF Ombudsteam to have a  chat with you are your 
> behavior
> and your lack of listening to reasoned input from folk who both 
> implement
> and operate networks, equipment and the protocols which make up the
> Internet at large. You are not helping your case nor the case of the
> protocols in question.
>
> If the ombudsteam are unable/unwilling to interact here I'd like the
> responsible ADs for ops/tsv to have a chat with you about this.
>
> Again, if HBH headers are meaningless and not needed, then go through 
> the
>>> proper process and remove them from IPv6. If not, stop trying to 
>>> hobble
>>> this protocol to the point where we all realize why nobody wants to 
>>> use it.
>>>
>>>
>> I think everyone here is actually happy to see v6 progress.
>>
>>
>> As am I - in Standards.  It shouldn’t ‘progress’ on ops.
>>
>> note I'm not trying to be intentionally combative, just attempting to 
>> say:
>> "the best answer for the user here is PROBABLY to just have the core 
>> ignore
>> all the EH business entirely"
>>
>>
>> Again, if they’re not needed, fine. Remove them in Standards.
>>
>> However, if the role of ops is to decide what standards to ignore, 
>> then
>> perhaps the IESG should reconsider the area’s charter.
>>
>> Joe
>>