Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 01 March 2020 23:17 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C93A0B53 for <spring@ietfa.amsl.com>; Sun, 1 Mar 2020 15:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 NaP8mTnDPIo1 for <spring@ietfa.amsl.com>; Sun, 1 Mar 2020 15:17:30 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7033A0B52 for <spring@ietf.org>; Sun, 1 Mar 2020 15:17:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48VzhB1qJ6z6GGLG; Sun, 1 Mar 2020 15:17:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1583104650; bh=GVWfNM+6dn5lZSDY+fso0VZbJb0V/69WXhezEiFFbbA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aU77FpGpD/GlRNiwfIFvPndqIejnvLVnxmdoCYlL+tNoUKBMkp3M2KwyalKhQ5SkO qRN/cIxRfo2+0dshNQxRSU4/KJ4isWdn7Enj3/nSegpY0+XXD1P8ujqQ6eExHr6I66 kNDMwntuLgmE50yHjBsK1x6NliXW/VKtA3sMxcnQ=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48Vzh95FQ5z6GFwK; Sun, 1 Mar 2020 15:17:29 -0800 (PST)
To: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E_=3C5518=5F1582908787=5F5E594573=5F?= =?utf-8?q?5518=5F436=5F1=5F53C29892C857584299CBF5D05346208A48DD1BCA=40OPEXC?= =?utf-8?q?AUBM43=2Ecorporate=2Eadroot=2Einfra=2Eftgroup=3E?= <C8417F71-D61E-42AC-831E-B85269D5D4A5@steffann.nl> <9b677b7c-fe52-dbae-7f83-2b5be5194325@gont.com.ar> <6.2.5.6.2.20200228132634.1060a610@elandnews.com> <9449c98e-b1d6-2c74-b78d-df3f5ba15ebc@nokia.com> =?utf-8?q?=3C6=2E2=2E5=2E6=2E2=2E20200229223634=2E093850f0=40elandnews=2Eco?= =?utf-8?q?m=3E_=3CDBBPR03MB54150500DA829FBAB73DFEC1EEE60=40DBBPR03MB5415=2E?= =?utf-8?q?eurprd03=2Eprod=2Eoutlook=2Ecom=3E?= <6.2.5.6.2.20200301111046.0c0499b0@elandnews.com> <CAOj+MMH3eyjoQe=SokYQ89HM2po01G1V=kgO+653EKx8eaobzw@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <abc665ae-603b-49d9-9ce5-c51c3072e571@joelhalpern.com>
Date: Sun, 1 Mar 2020 18:17:26 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CAOj+MMH3eyjoQe=SokYQ89HM2po01G1V=kgO+653EKx8eaobzw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/bi_CaorGw-6Ke27dRI9uk8Wmp3c>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Mar 2020 23:17:34 -0000

The usual practice when a hair o-authors a document is for the co-chair 
to manage all aspects of the document life cycle.  In this case, due to 
the co-chair being unavailable, we have a bit of a problem.  For 
non-contentious documents, we can easily manage anyway.  In this case, 
the document is quite contentious.  Which makes things complicated.

Yours,
Joel

On 3/1/2020 6:02 PM, Robert Raszuk wrote:
> 
> Exception ? As far as I see it this is rather a norm in multiple WGs 
> across IETF for chair to co-author or contribute to his area of focus. 
> And there is absolutely nothing wrong with it. In fact it is 
> expected for chair to read the draft  and comment othen resulting in 
> becoming a contributor or at least being added to the Ack section.
> 
> If this saga continues any further I recommend we start first by 
> obsoleting RFC8200 too. After all it's main author Bob Hinden was also a 
> 6man chair who requested publication of 2460bis:
> 
> 2016-12-02
> 2016-12-02 17:06:39 -0800
> 	08	Bob Hinden	IETF WG state changed to Submitted to IESG for 
> Publication from WG Consensus: Waiting for Write-Up
> 2016-12-02
> 	08	Bob Hinden	IESG state changed to Publication Requested
> 2016-12-02
> 	08	Bob Hinden	IESG process started in state Publication Requested
> 2016-11-30
> 	08	Bob Hinden	Changed document writeup
> 2016-11-15
> 	08	Bob Hinden	New version available: draft-ietf-6man-rfc2460bis-08.txt
> 
> 
> On Sun, Mar 1, 2020 at 9:38 PM S Moonesamy <sm+ietf@elandsys.com 
> <mailto:sm%2Bietf@elandsys.com>> wrote:
> 
>     Hi Andrew,
> 
>     [Cc to ietf@]
> 
>     I'll disclose that I am also affiliated with a
>     RIR.  I am copying this message to the
>     Responsible Area Director [1] for the SPRING Working Group.
> 
>     At 01:17 AM 01-03-2020, Andrew Alston wrote:
>      >While some on this list have made references to
>      >Bruno’s integrity – let me start by saying – I
>      >make no comment on anyone’s integrity – because
>      >I don’t know Mr. Decraene well enough to comment
>      >on that, and because I find an individual’s
>      >integrity in a discussion about if a potential
>      >conflict exists to be irrelevant. When people
>      >recuse for conflict in any normal environment,
>      >it is not because they will act on the conflict
>      >necessarily, it is because of perception,
>      >because it can taint the issue under discussion,
>      >and it leaves the process open to both attack and appeal.
> 
>     My question was about the process and the role
>     with respect to
>     draft-ietf-spring-srv6-network-programming.  I am
>     not personally acquainted with Mr. Decraene to
>     comment about his integrity.  It has been pointed
>     out to me that the person is well-known.  I don't
>     see what that has to do with the question which I asked.
> 
>     There is a message at
>     https://mailarchive.ietf.org/arch/msg/spring/3zbi71sjcJ8KaFgVIrF2Ymx4GC8/
> 
>     which lists the Responsible Area Director as a
>     Contributor.  In my opinion, the procedural
>     aspects are problematic.  I commented about a
>     somewhat similar topic previously [2].  From what
>     I understand, RFC 2026 is applicable for all
>     documents coming out of the IETF
>     Stream.  According to that RFC, the "procedures
>     are explicitly aimed at recognizing and adopting
>     generally-accepted practices".  One of the
>     definitions in RFC 7776 is: "A conflict of
>     interest may arise if someone involved in the
>     process of handling a harassment report is in the
>     role of Reporter, Respondent, or
>     Subject.  Furthermore, a conflict of interest
>     arises if the person involved in the process of
>     handling a harassment report is closely
>     associated personally or through affiliation with
>     any of the Reporter, Respondent, or
>     Subject".  The general practice, in such a
>     situation, is recusal.  I'll invite the
>     Responsible Area Director to comment about
>     whether there should be an exception to that practice and the
>     rationale for it.
> 
>     Regards,
>     S. Moonesamy
> 
>     1. https://datatracker.ietf.org/wg/spring/about/
>     2.
>     https://mailarchive.ietf.org/arch/msg/ietf/xBjDAIM4hdnSTyxL7QHlbiFX3eE/
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>