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

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>