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

Robert Raszuk <> Sun, 01 March 2020 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF1903A0B18 for <>; Sun, 1 Mar 2020 15:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rm1AlhuxHuqY for <>; Sun, 1 Mar 2020 15:02:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7B4E3A0B16 for <>; Sun, 1 Mar 2020 15:02:23 -0800 (PST)
Received: by with SMTP id v19so7877698ote.8 for <>; Sun, 01 Mar 2020 15:02:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zloy4C9oQ/DaTcleghrJWHNzPkboQos33Iw/rxJIMvw=; b=JDy0jNs0HPpS5Cs7o0LqdqSNcojWn+n+Yx8dIL2PtMdNAhutZh/x8belYMsyXRCBql SrjpopsucNMIoHYxojK9Vj9uOns6/obuoWNU2GVATZVI2A658ncl6tiws69TGEuLRmNU LVWwhAF55w74BLp+8/nW0ea9sPU1dFZBt06UlLN0O+AkNL6/GOo0nyIa/hiB36iqWIsJ YuKVHE6zPYRXBfRdrRYZ9EbVndyr9fYu7zm+hyelh5i1ZxcBfElmf64n6BjhKlMpFZ0v HgWLGrePv+gUx+GWZiiQwyvUnlOnJfgzYr3tvJ4jXmGgo1rCkg/I/VSraenRsnCc3bg7 fxWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zloy4C9oQ/DaTcleghrJWHNzPkboQos33Iw/rxJIMvw=; b=IGZEWaHrLNp8i6T04iHA2NU7VOPlPR/ersaBPrxy+dO7Dd6txOGGNLtaD9fM2DndmB vKoS7C2JFLeA0APsJNM3ntqNorQbLK8dUY7F4+NXZ4yZYb2aQdFZIGLX2xU9ToOifHiR qrYkPUQKCRMGEfg/JoSEiNd8A09IAG+f0Mg2hJZVihCab4o9KQZn4+EI6EYf4FaG86Du Mo1D3n4NzeP+JOhFKNX9hmkSxNXZRIjsJkkZLZ9CmQxCg7jql4qnQhvlcH/mYilzZ1vP jMcvg+BrGdQl0pz47yyt8hZGfYh5IRkXs9OJHGpTB6l2X3uLRdBKUBilQD1UItnGT1dG 7vZA==
X-Gm-Message-State: APjAAAUbcga2uzgeC4dCMEgYP88IZuNFUT45CUz2Ws42P4qBB0xMIkj9 D0cw37N124NGp055PdFy5Dy+F9h6Vq2vYYqdewi36Q==
X-Google-Smtp-Source: =?utf-8?q?APXvYqyMJEC2KK+2tT/xoDuz72MRFZGpGIlBEiUZ+ZxE?= =?utf-8?q?7dbbr2cNWRDrUfeXhOxUE3vIRQXQGTxhT68MO115ZADYsAA=3D?=
X-Received: by 2002:a9d:6a4f:: with SMTP id h15mr11228109otn.86.1583103743077; Sun, 01 Mar 2020 15:02:23 -0800 (PST)
MIME-Version: 1.0
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?= <> <> <> <> =?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?= <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 2 Mar 2020 00:02:13 +0100
Message-ID: <>
To: S Moonesamy <>
Cc: Andrew Alston <>, IETF <>, SPRING WG <>
Content-Type: multipart/alternative; boundary="0000000000003fc0f1059fd310c7"
Archived-At: <>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Mar 2020 23:02:27 -0000

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 17:06:39 -0800
08 Bob Hinden IETF WG state changed to Submitted to IESG for Publication from
WG Consensus: Waiting for Write-Up

08 Bob Hinden IESG state changed to Publication Requested

08 Bob Hinden IESG process started in state Publication Requested

08 Bob Hinden Changed document writeup

08 Bob Hinden New version available: draft-ietf-6man-rfc2460bis-08.txt

On Sun, Mar 1, 2020 at 9:38 PM S Moonesamy <> 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
> 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.
> 2.