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 <[email protected]
<mailto:sm%[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
