Subject: A sad farewell

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 3 Nov 2020 15:42:12 +0100

Dear friends and acquaintances,

After 20 years of writing tools for the IETF, I will let my contract for
tools maintenance lapse at the end of the year, and move on to other things.
The reason is the attitude of the current IETF Chair and LLC Board towards
contractors in particular and IETF participants in general.  Care for the
community doesn't seem to matter to them.

The current Chair and LLC Board seems to see contractors, including the
secretariat and myself, not as members of the community, but simply someone
who should do what they are told by the authority in charge.  This in total
contrast with the approach of Russ Housley as IETF Chair; he explicitly
tried to make the secretariat and other contractors an integral part of the
community, inviting them in, rather than pushing them out.

Remembering how supportive the previous full Exec Dir, Ray Pelletier had
been with respect to the tools work, I was hoping that things would change
at the end of last year with Jay Daley; unfortunately it hasn't; rather the
opposite, and it has simply become too painful to carry on.

Things got bad at the end of last year, when the LLC Board went back on their
word after accepting my bid on the RFP in full without reservations; they
simply changed the contract offered without one word of conversation about
the changes.  My bid would have been substantially different for an RFP with
the conditions in that contract.  That was tough, but the final straw came at
the beginning of 2020, when a Tools Architecture and Strategy Team was
established to look at the tools future, and I was excluded from it.  Being
considered a replaceable cog and not a part of the community is not a fun
environment in which to work, and I've been depressed for most of the year
following that.

The consequence is, as indicated above, that I  will not sign on to any
contract renewal or bid on any new RFP when the current term runs out for
the tools maintenance contract at the end of the year.

Many and big thanks are due to all the IETF chairs who have supported and
encouraged my tools work: Harald Alvestrand, Brian Carpenter, Russ Housley,
and Jari Arkko.  Huge appreciation and gratitude also goes to Robert Sparks
and Russ Housley for the privilege of working with them in the Tools Team
and the TMC (Tools Management Committee).  And finally, thanks to all the
members of the community who over the years have made it a joy to do tools
work, by expressing their appreciation of the tools.

----------

The longer story, for background, to explain how I came to feel so strongly
about being excluded from tools architecture work and having the LLC Board
go back on their word without even thinking it was worth talking to me about
it:

I wrote my first draft of a draft in 1999; my first meeting was IETF 49.

In 2001, Sami Vaarala and I both presented drafts outlining NAT traversal
for Mobile IP, and based on the way we worked to merge these and build
consensus, I became co-chair of MIP4, a position I held till the group was
closed in 2015 (although there was essentially no activity during the last
5 years).

I early thought it absolutely silly that in the internet age, IETF documents
were not available as HTML documents with internal and external links.  That
led to rfcmarkup (2002), which was deployed to provide htmlized versions of
RFCs, and later drafts, first on my own domain, and later on tools.ietf.org.

As I was writing drafts, I was annoyed with having to manually check the format
requirements (line length, boilerplate, and whatnot), and adapted an awk
snipped as a 10-line script to check line length for me (2003).  That grew,
and became 'idnits'.

Having to read new revisions of drafts, to keep up with other Mobile IP
contributions, I found it annoying not to know where the changes in the new
rev were, and how much was changed.  This led to 'rfcdiff' (2003).

As WG co-chairs, we had to put together a summary of the status of the various
documents before each meeting -- that status report was the main way to let
participants know about draft progress, since there was no datatracker in
2000, and no WG support in the IESG tracker tool when it appeared.  Doing the
summary each meeting was very much drudge work, and becoming tired of repeating
the exercise each meeting, I created a document status page for MIP4, updated
automatically from various text files available from the draft repository and
the IESG tracker (around 2004).  Other chairs saw this, and asked me to do the
same for them, and it grew from there, and was eventually incorporated into the
official datatracker as WG pages.

Around late 2006/early 2007, serious SQL injection vulnerabilities were
discovered in the datatracker as it was then.  After a lot of feet-dragging
by the vendor in addressing the vulnerabilities, Bill Fenner and I started
a skunk-works project to completely rewrite the publicly accessible datatracker
from old-style Perl to Python and Django.  For 2 months we worked up to 10
hours per day, and disclosed the effort only when we had enough in place to
show that the effort was viable.  The powers that were applauded the effort,
and we carried through, and released the rewrite in June 2007.

I continued to do tools work during 40%-50% of my time up till 2016, at no
cost to the IETF -- all work and tools were donated by myself or my employer
over the years.  In 2016 I was about to switch employers, and the IETF
Chair and several previous chairs saw the opportunity to get me to work full
time on IETF tools, which I happily did until the current chair started to
seriously treat me not as a member of the community but as a contractor that
needed to be told just what to do in early 2018.  After that, things went
downhill.

As mentioned earlier, the final straw came early this year, when Alissa and
Jay decided to set up a Tools Architecture and Strategy Team, and excluded
me from that work.  That was to me such a clear and unequivocal statement
of me not being considered part of the community that it drove me into a
depression, from which I could only partially recover by distancing myself
from the tools effort more and more.  The depression has gone in waves in
the following months, often triggered by additional actions and statements
showing the same attitude.

I don't know which attitude the next Chair will have, but even if it's more
in line with earlier chairs, the LLC Board and Jay, who have been part of
making this year a miserable one for me, will still be there, not much changed.

So it's not with joy I move on and look for other things to occupy me; it's
with sadness in abandoning an area in which I've invested a lot of myself
over the last 20 years.

My best wishes to you all going forward.

	Henrik

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 3 Nov 2020 16:03:35 +0100

Dear Henrik,

this is all very unfortunate. In my experience, the IETF tools
(including xml2rfc) have improved immensely in the recent past and I
feel delighted and privileged to be able to use these tools rather that
some corporate-like rubbish. Also, you have always been prepared to help
and answer questions, even silly ones. So, thank you very much.

Good luck,

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Nov 2020 10:04:09 -0500

Hernik:

I am sad that you will not be participating any longer.  I will miss you.

In July 2007, I told the whole plenary about the heroic rewrite that you and Bill Fenner did for all of us:

	https://www.ietf.org/proceedings/69/slides/plenaryw-3/sld9.htm

I wish you well.

Russ

> On Nov 3, 2020, at 9:42 AM, Henrik Levkowetz <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 3 Nov 2020 11:00:35 -0500

Hi Henrik,

The IETF community owes tremendous gratitude to you for all your years of hard work in service to the community. Huge thanks to you. I’m sorry to have caused you suffering such that you’ve decided to move on. 

Best,
Alissa

---

From: Ron Bonica <[email-masked]>
Date: Tue, 3 Nov 2020 17:19:05 +0000

Henrik,

You will be severely missed.

Good luck in whatever comes next.

                                                   Ron

Juniper Business Use Only

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Russ Housley
Sent: Tuesday, November 3, 2020 10:04 AM
To: Henrik Levkowetz <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Re: A sad farewell

[External Email. Be cautious of content]

Hernik:

        https://urldefense.com/v3/__https://www.ietf.org/proceedings/69/slides/plenaryw-3/sld9.htm__;!!NEt6yMaO-gk!TYOs5pfCv2S85pEhP4oMLvlXqWfwQfDbxgEGl9WL1otlo6nicWDbV1Q4VV00Tpva$

I wish you well.

Russ

> After 20 years of writing tools for the IETF, I will let my contract 
> for tools maintenance lapse at the end of the year, and move on to other things.
> The reason is the attitude of the current IETF Chair and LLC Board 
> towards contractors in particular and IETF participants in general.  
> Care for the community doesn't seem to matter to them.
>
> The current Chair and LLC Board seems to see contractors, including 
> the secretariat and myself, not as members of the community, but 
> simply someone who should do what they are told by the authority in 
> charge.  This in total contrast with the approach of Russ Housley as 
> IETF Chair; he explicitly tried to make the secretariat and other 
> contractors an integral part of the community, inviting them in, rather than pushing them out.
>
> Remembering how supportive the previous full Exec Dir, Ray Pelletier 
> had been with respect to the tools work, I was hoping that things 
> would change at the end of last year with Jay Daley; unfortunately it 
> hasn't; rather the opposite, and it has simply become too painful to carry on.
>
> Things got bad at the end of last year, when the LLC Board went back 
> on their word after accepting my bid on the RFP in full without 
> reservations; they simply changed the contract offered without one 
> word of conversation about the changes.  My bid would have been 
> substantially different for an RFP with the conditions in that 
> contract.  That was tough, but the final straw came at the beginning 
> of 2020, when a Tools Architecture and Strategy Team was established 
> to look at the tools future, and I was excluded from it.  Being 
> considered a replaceable cog and not a part of the community is not a 
> fun environment in which to work, and I've been depressed for most of the year following that.
>
> The consequence is, as indicated above, that I  will not sign on to 
> any contract renewal or bid on any new RFP when the current term runs 
> out for the tools maintenance contract at the end of the year.
>
> Many and big thanks are due to all the IETF chairs who have supported 
> and encouraged my tools work: Harald Alvestrand, Brian Carpenter, Russ 
> Housley, and Jari Arkko.  Huge appreciation and gratitude also goes to 
> Robert Sparks and Russ Housley for the privilege of working with them 
> in the Tools Team and the TMC (Tools Management Committee).  And 
> finally, thanks to all the members of the community who over the years 
> have made it a joy to do tools work, by expressing their appreciation of the tools.
>
> ----------
>
> The longer story, for background, to explain how I came to feel so 
> strongly about being excluded from tools architecture work and having 
> the LLC Board go back on their word without even thinking it was worth 
> talking to me about
> it:
>
> In 2001, Sami Vaarala and I both presented drafts outlining NAT 
> traversal for Mobile IP, and based on the way we worked to merge these 
> and build consensus, I became co-chair of MIP4, a position I held till 
> the group was closed in 2015 (although there was essentially no 
> activity during the last
> 5 years).
>
> I early thought it absolutely silly that in the internet age, IETF 
> documents were not available as HTML documents with internal and 
> external links.  That led to rfcmarkup (2002), which was deployed to 
> provide htmlized versions of RFCs, and later drafts, first on my own domain, and later on tools.ietf.org.
>
> As I was writing drafts, I was annoyed with having to manually check 
> the format requirements (line length, boilerplate, and whatnot), and 
> adapted an awk snipped as a 10-line script to check line length for me 
> (2003).  That grew, and became 'idnits'.
>
> Having to read new revisions of drafts, to keep up with other Mobile 
> IP contributions, I found it annoying not to know where the changes in 
> the new rev were, and how much was changed.  This led to 'rfcdiff' (2003).
>
> As WG co-chairs, we had to put together a summary of the status of the 
> various documents before each meeting -- that status report was the 
> main way to let participants know about draft progress, since there 
> was no datatracker in 2000, and no WG support in the IESG tracker tool 
> when it appeared.  Doing the summary each meeting was very much drudge 
> work, and becoming tired of repeating the exercise each meeting, I 
> created a document status page for MIP4, updated automatically from 
> various text files available from the draft repository and the IESG 
> tracker (around 2004).  Other chairs saw this, and asked me to do the 
> same for them, and it grew from there, and was eventually incorporated into the official datatracker as WG pages.
>
> Around late 2006/early 2007, serious SQL injection vulnerabilities 
> were discovered in the datatracker as it was then.  After a lot of 
> feet-dragging by the vendor in addressing the vulnerabilities, Bill 
> Fenner and I started a skunk-works project to completely rewrite the 
> publicly accessible datatracker from old-style Perl to Python and 
> Django.  For 2 months we worked up to 10 hours per day, and disclosed 
> the effort only when we had enough in place to show that the effort 
> was viable.  The powers that were applauded the effort, and we carried through, and released the rewrite in June 2007.
>
> I continued to do tools work during 40%-50% of my time up till 2016, 
> at no cost to the IETF -- all work and tools were donated by myself or 
> my employer over the years.  In 2016 I was about to switch employers, 
> and the IETF Chair and several previous chairs saw the opportunity to 
> get me to work full time on IETF tools, which I happily did until the 
> current chair started to seriously treat me not as a member of the 
> community but as a contractor that needed to be told just what to do 
> in early 2018.  After that, things went downhill.
>
> As mentioned earlier, the final straw came early this year, when 
> Alissa and Jay decided to set up a Tools Architecture and Strategy 
> Team, and excluded me from that work.  That was to me such a clear and 
> unequivocal statement of me not being considered part of the community 
> that it drove me into a depression, from which I could only partially 
> recover by distancing myself from the tools effort more and more.  The 
> depression has gone in waves in the following months, often triggered 
> by additional actions and statements showing the same attitude.
>
> I don't know which attitude the next Chair will have, but even if it's 
> more in line with earlier chairs, the LLC Board and Jay, who have been 
> part of making this year a miserable one for me, will still be there, not much changed.
>
> So it's not with joy I move on and look for other things to occupy me; 
> it's with sadness in abandoning an area in which I've invested a lot 
> of myself over the last 20 years.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 3 Nov 2020 12:51:07 -0500

Thanks, Henrik, for all your hard and wonderful work!  It's been
fabulous to work with you.

Barry

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 3 Nov 2020 14:19:52 -0500

I am very sorry to hear that Henrik. Thanks for everything you have done for us over the years. The tools work you did made my IETF work as an author, chair, reviewer and AD much more pleasant and efficient. We will greatly miss you.

Regards
Suresh

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 3 Nov 2020 19:41:37 +0000

Henrik,

Sad news indeed but I am sure that your next endeavor will be fantastic.

The tool chains you build with the community are key to correctly process documents as participant, author, WG chair, and as AD. Your work has saved many hours to many people!

Finally, thank you for the long but interesting history at the end of your note.

Fair winds

-éric
PS: my first IETF meeting was also IETF-49 in San Diego !

-----Original Message-----
From: ietf <[email-masked]> on behalf of Henrik Levkowetz <[email-masked]>
Date: Tuesday, 3 November 2020 at 15:43
To: IETF Discussion <[email-masked]>
Subject: A sad farewell

    ----------

    	Henrik

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Nov 2020 21:07:45 +0100

I find the responses on this thread quite frustrating.

They are exactly like what i have come to experience when people
have to leave big companies because of horribly bad management and
nobody sees a way to improve management. I would have hoped
that IETF culture and community influence was better and that
something like this should not have happened or could even be
reversed by community outcry and forcing change in leadership
behavior.

I am sorry to hear the insight about LLC operations, because to me
the contributor facing view i had was very positive. But either i am
not on the right mailing lists, or these internal conflicts are
not exposed at all for the community to be able to influence them.

In any case, i fear that progress of tooling, especially in these
critical times of migration to XMLv3 starting to expose limitations
and IMHO a need for ongoing "free-of-process" improvement of tooling.

To me, IETF is best when it is driven by engagement of contributors,
and (rough) community consensus, and not by leadership decisions.
Unfortunately, i think we are shifting more and more to this leadership
preference based constrainment of innitiatives, innovation and activities,
spending more time on prohibiting activities than encouraging them.
This is IMHO, what is going to kill IETF if it continues.

To me, the tooling team was predominantly visible through the
extreme responsible hands-on work of Henrik, and i just considered
him to be the lead contributor to the "tools-track", so the fact
that he was because of reasons of contract and management decisions
kept out of the strategy is exactly the problem of self-righteous
managemenet centric companies. I guess we never had better oversight
of management tradition, because we came from a long time where we
may have just been very lucky in our choices of leadership. I don't know.

*sigh*

Cheers
    toerless

-- 
---
[email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 3 Nov 2020 20:23:05 +0000

Hi Henrik,

sorry to hear about your decision. Your heritage will stay and we all as well as future generations will benefit from what you have brought to the IETF, making is possible to work effectively as the basis for designing good protocols and making the Internet work better. I hope you will stay in some way engaged in the community and maybe have some time to refocus on that part of the work!

Mirja

On 03.11.20, 15:43, "ietf on behalf of Henrik Levkowetz" <[email-masked] on behalf of [email-masked]> wrote:

    ----------

    	Henrik

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Nov 2020 15:27:29 -0500

> This is IMHO, what is going to kill IETF if it continues.

+1.

The proper role of the leadership is to facilitate community consensus, 
but I keep seeing examples of leadership trying to dictate outcomes.

Keith

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 03 Nov 2020 21:43:49 +0100

Well said and of course thanks to Henrik for all the good work. I really think it is unfortunate that we come to this situation. He was always very patient with our desperation when something was not working, even if it could be our fault and not the tools.

I also fail to see how come he was excluded from the Tools Architecture and Strategy Team. Can someone explain that?

Is the IETF going in the direction that the management is on top of the community up to the point of excluding community members?

Is the next step not allowing someone to participate in a WG? Come on this needs an explanation, it is clearly even discriminatory.

Regards,
Jordi
@jordipalet

El 3/11/20 21:10, "ietf en nombre de Toerless Eckert" <[email-masked] en nombre de [email-masked]> escribió:

    *sigh*

    Cheers
        toerless

    -- 
    ---
    [email-masked]

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 Nov 2020 20:47:44 +0000

Hiya,

Henrik: I'm very sad that you felt you had to reach
that conclusion. I think the IETF will be the worse.
Many many thanks for your work over the years and
especially for what always seemed to me the lightning
quick responses whenever a question or issue came up.

>> and (rough) community consensus, and not by leadership decisions.

Big +1 from me to that.

>> spending more time on prohibiting activities than encouraging them.

I'm less sure of about some of the above. Managing a mix of
volunteers and contractors and people who are both is likely
really hard and surely very different from management within
the large IT company that's maybe the most common sponsor of
IETF activities. And ISTM that the way management is done in
such companies has changed since I escaped 'em and landed
back in academia around 2002ish.

That said, I do worry that some of what I'd see as the less
desirable management practices from such employers are maybe
impacting on the volunteerism that's core for the IETF. I'm
not confident that I know that though. And we're probably
also benefiting from the management practices in such places
that have improved a lot in recent times too, so it's not
all a one-way thing.

 > The proper role of the leadership is to facilitate community consensus,

Also a big +1 to that.

Perhaps a least-bad outcome here might include some of the
I* bodies reflecting some more on volunteerism and all we
gain from that.

S.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 3 Nov 2020 16:41:41 -0500

Hi Hendrik,

This is very sad. I would like first to thank you very much for the tools
you developed for us and the time you dedicated to the community. I have
always been convinced these tools were doing what we expected because
they were developed by someone that is part of us and thought for 18 years.
I also want to thank you for the reactivity when a glitch was encountered.
Thank you very much for your time.

I am concerned by the pattern of people leaving the IETF this way and
believe that this issue should be considered seriously by the community.

Yours,
Daniel

On Tue, Nov 3, 2020 at 9:43 AM Henrik Levkowetz <[email-masked]>
wrote:

> documents
> various

-- 
Daniel Migault
Ericsson

---

From: S Moonesamy <[email-masked]>
Date: Tue, 03 Nov 2020 15:51:50 -0800

Hi Henrik,

Thank you for tools.ietf.org.  I found it to be very useful over the 
years.  I would also like to thank you your quick responses to my 
queries.  It is the second exit over the recent years ...

Regards,
S. Moonesamy

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 3 Nov 2020 17:18:55 -0800

Hello Henrik,

It was great working with you as chair of MIP4, and I use your tools 
every day that I work on IETF stuff.  You have my sincere thanks and 
appreciation.

Regards,
Charlie P.

---

From: Jay Daley <[email-masked]>
Date: Wed, 4 Nov 2020 15:33:04 +1300

Henrik, thank you for your long and immensely valuable contribution to the IETF tools.  Your hard work, prolific output and high quality code have been instrumental in getting the tools to where they are now.  

I often hear the criticism that the IETF is too focused on bespoke tools, but if we look at Datatracker, to name just one of many, and at how productive it has enabled the IETF to be, it’s clear that a strategy of community-led tools development has been a resounding success.  Thank you for being such a key part of that.

I also want to thank, rather belatedly, Netnod for their many years of funding some of the many hours Henrik has spent working on IETF tools.

Jay

> On 4/11/2020, at 3:42 AM, Henrik Levkowetz <[email-masked]> wrote:
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Wed, 4 Nov 2020 13:04:14 +0800

Henik,

This is very sad news. The IETF tools means a lot for me as working 
group chair and I have enjoyed working with you. Please know that you 
will be greatly missed.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Soininen, Jonne (Nokia - FI/Espoo)" <[email-masked]>
Date: Wed, 4 Nov 2020 07:32:03 +0000

Hi Henrik,

Thank you very much for the long years you've worked on the tools to help the IETF work better. I'm sad to see you go, but I wish you all the best on your future endeavors. I hope our paths will cross also in the future, which I think they will.

Cheers,

Jonne.

On 03/11/2020, 16.43, "ietf on behalf of Henrik Levkowetz" <[email-masked] on behalf of [email-masked]> wrote:

    ----------

    	Henrik

---

From: "Dirk Kutscher" <[email-masked]>
Date: Wed, 04 Nov 2020 10:02:41 +0100

Dear Henrik,

thanks for all the hard work and excellent support in the past.

Wishing you all the best,

Dirk

On 3 Nov 2020, at 15:42, Henrik Levkowetz wrote:

> for
> towards
> the
> had
> on their
> fun
> any
> and
> strongly
> traversal
> the format
> IP
> were
> at no
> Alissa and
> more
> it's

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Nov 2020 10:01:17 +0100

On Tue, Nov 03, 2020 at 09:07:45PM +0100,
 Toerless Eckert <[email-masked]> wrote 
 a message of 178 lines which said:

> not on the right mailing lists, or these internal conflicts are not
> exposed at all for the community to be able to influence them.

I concur: ordinary participants of the IETF were not aware there was
such a big problem. It is annoying to discover it only too late.

Because of this ignorance, I cannot say who is right or wrong. I just
hope that the IETF will not go the way of corporate management style,
with dumb contractors just doing what they are told to do. Tools are
better when they are developed by people who care and who use them.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Nov 2020 10:30:15 +0100

Hi Henrik,

this is sad news indeed.

I’m sure not very many in the IETF realize how much the cogs and wheels of the IETF standards creation process have relied on your diligent work, and on your foresight on where we should move towards.  That will make for not-so-smooth operation in the next couple of years, although I’m sure the tools team will be up to the challenge.

On an organizational level, this shows again our talent to not handle the spectrum between volunteer expert contributions and contract management properly.  We seem to have a knack for creating what might in other places be called a “hostile work environment”…  I don’t have specific proposals right now, except maybe that we put this problem a little higher on our agenda.

This is also quite sad on a personal level.  I enjoyed meeting you at IETFs (even if the time was always limited), and I enjoyed your solution-focused approach to my sometimes a bit terse emails when something went wrong (or just didn’t work as I imagined it should).  Of all the reasons why you might want to change what you do and how you do it, the situation you mention sounds particularly unpleasant.  In any case, I wish you good luck and happiness in your next endeavors.  Here in the IETF, you will be missed.

Grüße, Carsten

---

From: Lloyd W <[email-masked]>
Date: Wed, 4 Nov 2020 20:58:24 +1100

it's interesting reading the mail archives for this selected team:

https://mailarchive.ietf.org/arch/msg/tools-arch/41Yg6lCrDMwz90P3qdv9BNN5FCQ/

"This is an important effort for the IETF community"
- but it is not a community effort? How does the IETF run these days?

Lloyd Wood
[email-masked]

looking forward to the Center for Democracy and Technology
resolving the US election and constitutional crisis. Go, team!

> On 4 Nov 2020, at 07:28, Keith Moore <[email-masked]> wrote:
> 
> The proper role of the leadership is to facilitate community consensus, but I keep seeing examples of leadership trying to dictate outcomes.
> 
> Keith
> 
> 
> 
>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 4 Nov 2020 14:38:52 +0100

> I also want to thank, rather belatedly, Netnod for their many years of funding some of the many hours Henrik has spent working on IETF tools.

You are welcome!

For context I'm the chairman of the foundation that owns netnod [1] and was responsible for
contacts with the IETF related to Henriks work while he worked for netnod.

Henrik worked for netnod for many years and towards the last couple of years switched to working
full time on IETF tools. During this time there was an agreement between netnod and the IETF that
roughly 40% of Henriks time would be funded by netnod.

The year before Jay took on the role as LLC chair I was contacted by Portia Wenze-Danley who
informed us that after a decision by IETF leadership, netnod would be required to submit a
competitive bid for Henriks contract - ie a bid for what was in substantial parts a donation.

At that point Henrik decided to submit a bid under his own flag and netnod naturally ended the
sponsorship at the same time. I expressed my surprise to Portia and later to Jay about how
the relationship with Henrik and netnod was managed.

	Best R
	Leif Johansson

[1] The TU-foundation is jointly controlled by the Swedish University Network and the Swedish
Network Users Society that counts. The current board is me, Olle Johansson and Peter Löthberg.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Nov 2020 09:24:16 -0600

> may have just been very lucky in our choices of leadership. I don't know.

+1 on all points. Congrats to Toerless for being outspoken.

Behcet

> > I am very sorry to hear that Henrik. Thanks for everything you have done
> for us over the years. The tools work you did made my IETF work as an
> author, chair, reviewer and AD much more pleasant and efficient. We will
> greatly miss you.
> >
> > Regards
> > Suresh
> >

---

From: Ralph Droms <[email-masked]>
Date: Wed, 4 Nov 2020 14:32:53 -0500

Henrik - Best wishes in your future endeavors.  Your many contributions will continue to be of critical benefit to the IETF and your ongoing participation will be missed.  I have always regarded you as a key leader and contributor to the IETF, who is a shining example of the volunteerism, consensus-based decision making and collegial behavior that have made the IETF successful.  Although we haven't chatted in a few years, I have very fond memories of our times together at IETF meetings and I will continue to wish you well in the future.

- Ralph

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Nov 2020 20:55:42 +0100

Am 03.11.2020 um 15:42 schrieb Henrik Levkowetz:
> ...

Henrik,

bad news, giving your importance in progressing the tools landscape over
all these years. I hope that there's a plan in place to hand over the
stuff that you've been working on, but it would clearly be better if the
problems you mentioned could be resolved in such a way that you feel
comfortable in staying.

FWIW, the two of us *did* have quite a few disagreements in the last two
years about the v3 transition/implementation/evolution - but that
doesn't mean that I don't appreciate your hard work in this area.

While we're at it: this seems to be a good opportunity to thank
everybody who is spending a sizable amount of their available time -
often unpaid time, btw - to maintain and progress all these tools we
rely on. This is not only about writing and maintaining these (remember
the time we had to work on the ancient TCL code 10 years ago just to be
able to support ever-changing header&boilerplate requirements?), but
also about patiently helping people with their authoring/submission
problems at any time of the day.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2020 09:29:23 +1300

I've sent my thanks and appreciation privately to Henrik, so all
I will say here, with Leif's message as a convenient hook, is this:

Whatever we think about the past, the future is what matters.
Everybody can influence that future by means of their inputs to
NomCom. This year there are not only inputs for each individual
candidate, but also for some major topics that NomCom should
consider, for example:
https://datatracker.ietf.org/nomcom/2020/feedback/?topic=26
https://datatracker.ietf.org/nomcom/2020/feedback/?topic=22

Regards
   Brian Carpenter

On 05-Nov-20 02:38, Leif Johansson wrote:
> .

---

From: Benoit Claise <[email-masked]>
Date: Wed, 4 Nov 2020 21:33:21 +0100

Henrik, all,

I see a lot of well-deserved "thank you" emails. I could add to those 
... even if I did thank you many times verbally in the past.

However, I'm with Toerless here: frustrated
How does a community-centric organization such as the IETF arrive to a 
point of making its most passionate/dedicated people feel so excluded 
and frustrated that they leave the organization. The community and the 
current/future IESG must reflect on that ... if we want to the IETF to 
remain relevant.

When I was in the IESG, I witnessed that the real guardians of the IETF 
process is actually the secretariat: they know what could (not) be done 
and gently corrected ADs' mistakes. Similarly, the real guardians of the 
tools are Henrik & company.
The secretariat and tools team might be contractors, but first of all, 
they're members of the community. And they should be considered as such!
Remove the secretariat & the tools team and the IETF will simply stop 
working.

I'm thankful for Henrik's dedication to this organization but at the 
same time sorry, sad, and frustrated.

Regards, Benoit

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Nov 2020 14:57:33 -0600

> https://datatracker.ietf.org/nomcom/2020/feedback/?topic=22
Folks, this is good point!

Behcet

> >> I also want to thank, rather belatedly, Netnod for their many years of
> funding some of the many hours Henrik has spent working on IETF tools.
> >>
> >
> > You are welcome!
> >

---

From: Keith Moore <[email-masked]>
Date: Wed, 4 Nov 2020 16:00:11 -0500

On 11/3/20 9:33 PM, Jay Daley wrote:

> I often hear the criticism that the IETF is too focused on bespoke tools

The Internet is a bespoke tool, or at least, it started out that way.   
When the IETF is hostile to tool makers, it's hostile to continued 
development of the Internet.

Keith

---

From: Joseph Touch <[email-masked]>
Date: Wed, 4 Nov 2020 13:17:05 -0800

Hi, Henrik,

As someone who both uses your tools and developed my own, I want to thank you for your contributions but also note that I completely understand your position.

I am surprised only that this doesn’t happen more often.

Joe

> On Nov 3, 2020, at 6:42 AM, Henrik Levkowetz <[email-masked]> wrote:
>

---

From: "Jim Fenton" <[email-masked]>
Date: Wed, 04 Nov 2020 14:32:22 -0800

Henrik,

There’s little to say that hasn’t been said already, except that I 
personally appreciate your enormous contributions to IETF and your 
patience and support with my attempts to contribute in a very small way 
through code sprints and such. I have gained a real appreciation for the 
infrastructure that you and your team have developed and cheerfully 
supported without which IETF wouldn’t function nearly as well as it 
does today.

Your departure leaves a big hole, both in terms of expertise but also 
dedication to the mission of IETF.

Best wishes on your future activities.

-Jim

---

From: Alia Atlas <[email-masked]>
Date: Wed, 4 Nov 2020 19:17:20 -0500

Henrik,

Benoit has put into words better than I could my feelings.  I am very sad
to see your email
and deeply appreciate all your contributions over an extended time to the
IETF as part of
the community.  I greatly enjoyed and appreciated the chances I had to
collaborate with you.

Regards,
Alia

On Wed, Nov 4, 2020 at 3:33 PM Benoit Claise <bclaise=
[email-masked]> wrote:

> >> I am very sorry to hear that Henrik. Thanks for everything you have
> done for us over the years. The tools work you did made my IETF work as an

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Nov 2020 11:54:34 +0300

It's very sad news indeed... 

Henrik, thank you very much for your work, for your patience
to answer (sometimes stupid) questions and for your willingness 
to always help when a problem arose.

Valery.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 5 Nov 2020 10:10:04 +0100

Henrik,

I can only add to what others said in terms of thanks and appreciation.  

I have a question for you and the leadership:

Is there the opportunity for both you and IETF leadership take this lengthy and well deserved stream of thanks and appreciation as an indication that we do not want to lose another valued member of our community, and maybe have a few more discussions?  I know that’s asking a lot, and I am certain that there are things I don’t know about this situation, but perhaps there is some as-of-yet unexplored avenue; an RSET, if you will.  It may be stressful for all of you in the short run, and in the end it may come to naught, but perhaps – perhaps – it could be beneficial to all in the longer term.

Eliot

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 5 Nov 2020 10:22:24 +0100

Dear Henrik, all,

The work of Henrik made my life as an IETFer and co-chair immensely
easier.. and to have used alternative solutions in other SDOs I have come
to appreciate it even more!
Thank you, Henrik, for all the work and for making the tools be as helpful
as possible.

If possible in this complex situation, I would add my +1 on Eliot's RSET
proposal.

Alexander

On Thu, Nov 5, 2020 at 10:10 AM Eliot Lear <lear=[email-masked]>
wrote:

> Is there the opportunity for both you and IETF leadership take this
> lengthy and well deserved stream of thanks and appreciation as an
> indication that we do not want to lose another valued member of our
> community, and maybe have a few more discussions?  I know that’s asking a
> lot, and I am certain that there are things I don’t know about this
> situation, but perhaps there is some as-of-yet unexplored avenue; an RSET,
> if you will.  It may be stressful for all of you in the short run, and in
> the end it may come to naught, but perhaps – perhaps – it could be
> beneficial to all in the longer term.
>
> Eliot
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Nov 2020 11:25:23 +0100

> I have a question for you and the leadership:

Many of us have thought the same, but didn’t speak up because we definitely don’t want to push Henrik into something that continues to be unpleasant.

But if the underlying problems can really be addressed, and the slate can be cleaned, that would be great!

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 5 Nov 2020 12:57:26 +0100

Hi Eliot,

On 2020-11-05 10:10, Eliot Lear wrote:
> community, and maybe have a few more discussions? I know that’s
> asking a lot, and I am certain that there are things I don’t know
> about this situation, but perhaps there is some as-of-yet unexplored
> avenue; an RSET, if you will. It may be stressful for all of you in
> the short run, and in the end it may come to naught, but perhaps –
> perhaps – it could be beneficial to all in the longer term.

To answer the direct question:  I believe there definitely are things
that can and _should_ be done, but they are not in the area of discussions
to resolve a situation, because this isn't a matter of a 'situation' in
that sense.

At the bottom of this is, I believe, a lack of an explicit requirement
on the IETF Chair and LLC Director positions that candidates must have
shown ability and inclination to care for the community.  I believe the
NomCom need that laid out as a permanent point to consider, in addition
to the various domain-specific qualifications they have been and are
considering for the various positions they fill.

I believe the situation in which I've found myself would not have come to
be if previous NomComs had put ability and inclination to care for the
community as an important factor in selection of people who have roles
that involve community care and community building.  This includes the
LLC Board, because of the outsize effect some of their decisions can have
on contracts and agreements, for the secretariat and others.

Please understand that I don't want domain knowledge to be ignored or
played down; I want awareness of the community, what creates (and tears
down) a community, and inclination to care for it to be included as a
factor.

And I think it requires explicit mention in relevant RFCs, either covering
the NomCom's work or the individual positions where it's most needed.

Regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 5 Nov 2020 13:28:18 +0100

> https://datatracker.ietf.org/nomcom/2020/feedback/?topic=22

Indeed.  What Brian said.  Emphatically.

	Henrik

---

From: Mehmet Ersue <[email-masked]>
Date: Thu, 05 Nov 2020 14:35:55 +0100

+1Cheers,Mehmet
-------- Ursprüngliche Nachricht --------Von: Benoit Claise <bclaise=[email-masked]> Datum: 04.11.20  21:34  (GMT+01:00) An: Toerless Eckert <[email-masked]>, Henrik Levkowetz <[email-masked]> Cc: IETF Discussion <[email-masked]> Betreff: Re: A sad farewell Henrik, all,I see a lot of well-deserved "thank you" emails. I could add to those ... even if I did thank you many times verbally in the past.However, I'm with Toerless here: frustratedHow does a community-centric organization such as the IETF arrive to a point of making its most passionate/dedicated people feel so excluded and frustrated that they leave the organization. The community and the current/future IESG must reflect on that ... if we want to the IETF to remain relevant.When I was in the IESG, I witnessed that the real guardians of the IETF process is actually the secretariat: they know what could (not) be done and gently corrected ADs' mistakes. Similarly, the real guardians of the tools are Henrik & company.The secretariat and tools team might be contractors, but first of all, they're members of the community. And they should be considered as such!Remove the secretariat & the tools team and the IETF will simply stop working.I'm thankful for Henrik's dedication to this organization but at the same time sorry, sad, and frustrated.Regards, Benoit> I find the responses on this thread quite frustrating.>> They are exactly like what i have come to experience when people> have to leave big companies because of horribly bad management and> nobody sees a way to improve management. I would have hoped> that IETF culture and community influence was better and that> something like this should not have happened or could even be> reversed by community outcry and forcing change in leadership> behavior.>> I am sorry to hear the insight about LLC operations, because to me> the contributor facing view i had was very positive. But either i am> not on the right mailing lists, or these internal conflicts are> not exposed at all for the community to be able to influence them.>> In any case, i fear that progress of tooling, especially in these> critical times of migration to XMLv3 starting to expose limitations> and IMHO a need for ongoing "free-of-process" improvement of tooling.>> To me, IETF is best when it is driven by engagement of contributors,> and (rough) community consensus, and not by leadership decisions.> Unfortunately, i think we are shifting more and more to this leadership> preference based constrainment of innitiatives, innovation and activities,> spending more time on prohibiting activities than encouraging them.> This is IMHO, what is going to kill IETF if it continues.>> To me, the tooling team was predominantly visible through the> extreme responsible hands-on work of Henrik, and i just considered> him to be the lead contributor to the "tools-track", so the fact> that he was because of reasons of contract and management decisions> kept out of the strategy is exactly the problem of self-righteous> managemenet centric companies. I guess we never had better oversight> of management tradition, because we came from a long time where we> may have just been very lucky in our choices of leadership. I don't know.>> *sigh*>> Cheers>      toerless>> On Tue, Nov 03, 2020 at 02:19:52PM -0500, Suresh Krishnan wrote:>> I am very sorry to hear that Henrik. Thanks for everything you have done for us over the years. The tools work you did made my IETF work as an author, chair, reviewer and AD much more pleasant and efficient. We will greatly miss you.>>>> Regards>> Suresh>>>>> On Nov 3, 2020, at 9:42 AM, Henrik Levkowetz <[email-masked]> wrote:>>>>>> Dear friends and acquaintances,>>>>>> After 20 years of writing tools for the IETF, I will let my contract for>>> tools maintenance lapse at the end of the year, and move on to other things.>>> The reason is the attitude of the current IETF Chair and LLC Board towards>>> contractors in particular and IETF participants in general.  Care for the>>> community doesn't seem to matter to them.>>>>>> The current Chair and LLC Board seems to see contractors, including the>>> secretariat and myself, not as members of the community, but simply someone>>> who should do what they are told by the authority in charge.  This in total>>> contrast with the approach of Russ Housley as IETF Chair; he explicitly>>> tried to make the secretariat and other contractors an integral part of the>>> community, inviting them in, rather than pushing them out.>>>>>> Remembering how supportive the previous full Exec Dir, Ray Pelletier had>>> been with respect to the tools work, I was hoping that things would change>>> at the end of last year with Jay Daley; unfortunately it hasn't; rather the>>> opposite, and it has simply become too painful to carry on.>>>>>> Things got bad at the end of last year, when the LLC Board went back on their>>> word after accepting my bid on the RFP in full without reservations; they>>> simply changed the contract offered without one word of conversation about>>> the changes.  My bid would have been substantially different for an RFP with>>> the conditions in that contract.  That was tough, but the final straw came at>>> the beginning of 2020, when a Tools Architecture and Strategy Team was>>> established to look at the tools future, and I was excluded from it.  Being>>> considered a replaceable cog and not a part of the community is not a fun>>> environment in which to work, and I've been depressed for most of the year>>> following that.>>>>>> The consequence is, as indicated above, that I  will not sign on to any>>> contract renewal or bid on any new RFP when the current term runs out for>>> the tools maintenance contract at the end of the year.>>>>>> Many and big thanks are due to all the IETF chairs who have supported and>>> encouraged my tools work: Harald Alvestrand, Brian Carpenter, Russ Housley,>>> and Jari Arkko.  Huge appreciation and gratitude also goes to Robert Sparks>>> and Russ Housley for the privilege of working with them in the Tools Team>>> and the TMC (Tools Management Committee).  And finally, thanks to all the>>> members of the community who over the years have made it a joy to do tools>>> work, by expressing their appreciation of the tools.>>>>>> ---------->>>>>> The longer story, for background, to explain how I came to feel so strongly>>> about being excluded from tools architecture work and having the LLC Board>>> go back on their word without even thinking it was worth talking to me about>>> it:>>>>>> I wrote my first draft of a draft in 1999; my first meeting was IETF 49.>>>>>> In 2001, Sami Vaarala and I both presented drafts outlining NAT traversal>>> for Mobile IP, and based on the way we worked to merge these and build>>> consensus, I became co-chair of MIP4, a position I held till the group was>>> closed in 2015 (although there was essentially no activity during the last>>> 5 years).>>>>>> I early thought it absolutely silly that in the internet age, IETF documents>>> were not available as HTML documents with internal and external links.  That>>> led to rfcmarkup (2002), which was deployed to provide htmlized versions of>>> RFCs, and later drafts, first on my own domain, and later on tools.ietf.org.>>>>>> As I was writing drafts, I was annoyed with having to manually check the format>>> requirements (line length, boilerplate, and whatnot), and adapted an awk>>> snipped as a 10-line script to check line length for me (2003).  That grew,>>> and became 'idnits'.>>>>>> Having to read new revisions of drafts, to keep up with other Mobile IP>>> contributions, I found it annoying not to know where the changes in the new>>> rev were, and how much was changed.  This led to 'rfcdiff' (2003).>>>>>> As WG co-chairs, we had to put together a summary of the status of the various>>> documents before each meeting -- that status report was the main way to let>>> participants know about draft progress, since there was no datatracker in>>> 2000, and no WG support in the IESG tracker tool when it appeared.  Doing the>>> summary each meeting was very much drudge work, and becoming tired of repeating>>> the exercise each meeting, I created a document status page for MIP4, updated>>> automatically from various text files available from the draft repository and>>> the IESG tracker (around 2004).  Other chairs saw this, and asked me to do the>>> same for them, and it grew from there, and was eventually incorporated into the>>> official datatracker as WG pages.>>>>>> Around late 2006/early 2007, serious SQL injection vulnerabilities were>>> discovered in the datatracker as it was then.  After a lot of feet-dragging>>> by the vendor in addressing the vulnerabilities, Bill Fenner and I started>>> a skunk-works project to completely rewrite the publicly accessible datatracker>>> from old-style Perl to Python and Django.  For 2 months we worked up to 10>>> hours per day, and disclosed the effort only when we had enough in place to>>> show that the effort was viable.  The powers that were applauded the effort,>>> and we carried through, and released the rewrite in June 2007.>>>>>> I continued to do tools work during 40%-50% of my time up till 2016, at no>>> cost to the IETF -- all work and tools were donated by myself or my employer>>> over the years.  In 2016 I was about to switch employers, and the IETF>>> Chair and several previous chairs saw the opportunity to get me to work full>>> time on IETF tools, which I happily did until the current chair started to>>> seriously treat me not as a member of the community but as a contractor that>>> needed to be told just what to do in early 2018.  After that, things went>>> downhill.>>>>>> As mentioned earlier, the final straw came early this year, when Alissa and>>> Jay decided to set up a Tools Architecture and Strategy Team, and excluded>>> me from that work.  That was to me such a clear and unequivocal statement>>> of me not being considered part of the community that it drove me into a>>> depression, from which I could only partially recover by distancing myself>>> from the tools effort more and more.  The depression has gone in waves in>>> the following months, often triggered by additional actions and statements>>> showing the same attitude.>>>>>> I don't know which attitude the next Chair will have, but even if it's more>>> in line with earlier chairs, the LLC Board and Jay, who have been part of>>> making this year a miserable one for me, will still be there, not much changed.>>>>>> So it's not with joy I move on and look for other things to occupy me; it's>>> with sadness in abandoning an area in which I've invested a lot of myself>>> over the last 20 years.>>>>>> My best wishes to you all going forward.>>>>>>>>> 	Henrik>>>>>>>>>>>>

---

From: Eric Gray <[email-masked]>
Date: Thu, 5 Nov 2020 14:19:17 +0000

+1

From: ietf <[email-masked]> On Behalf Of Mehmet Ersue
Sent: Thursday, November 5, 2020 8:36 AM
To: Benoit Claise <bclaise=[email-masked]>; Toerless Eckert <[email-masked]>; Henrik Levkowetz <[email-masked]>
Cc: IETF Discussion <[email-masked]>
Subject: Re: A sad farewell

+1

Cheers,
Mehmet

-------- Ursprüngliche Nachricht --------
Von: Benoit Claise <bclaise=[email-masked]<mailto:bclaise=[email-masked]>>
Datum: 04.11.20 21:34 (GMT+01:00)
An: Toerless Eckert <[email-masked]<mailto:[email-masked]>>, Henrik Levkowetz <[email-masked]<mailto:[email-masked]>>
Cc: IETF Discussion <[email-masked]<mailto:[email-masked]>>
Betreff: Re: A sad farewell

Henrik, all,

Regards, Benoit

>>> On Nov 3, 2020, at 9:42 AM, Henrik Levkowetz <[email-masked]<mailto:[email-masked]>> wrote:
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 5 Nov 2020 14:32:30 +0000

I am also concerned about what I am seeing here, and also remember the departure of the RFC Editor.

I no longer understand the IETF commercial governance structure and its oversight mechanism, but I have a feeling that a board of respected neutral parties needs to be convened to conduct a review and report their findings.

- Stewart

> On 5 Nov 2020, at 14:19, Eric Gray <eric.gray=[email-masked]> wrote:
> 
> +1
>  
> Von: Benoit Claise <bclaise=[email-masked] <mailto:bclaise=[email-masked]>>
> An: Toerless Eckert <[email-masked] <mailto:[email-masked]>>, Henrik Levkowetz <[email-masked] <mailto:[email-masked]>>
> Cc: IETF Discussion <[email-masked] <mailto:[email-masked]>>
> >>> On Nov 3, 2020, at 9:42 AM, Henrik Levkowetz <[email-masked] <mailto:[email-masked]>> wrote:
> >>>

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 5 Nov 2020 12:41:27 -0500

On Thu, Nov 05, 2020 at 02:32:30PM +0000, Stewart Bryant wrote:
> I no longer understand the IETF commercial governance structure and
> its oversight mechanism, but I have a feeling that a board of
> respected neutral parties needs to be convened to conduct a review
> and report their findings.

Agreed.  I'd also suggest that while it's easy to lay the blame at the
feet of certain individuals and their perceived failings "to care for
the community", it's also a good idea to take a look at the *systems*
that are in place, and whether there is something about the
structures, or what various RFC's or other documents may have caused
individuals to assume that they were *supposed* to have to have taken
a more corporate, "professional", attitude which ended up treating
members of the community as cogs in a machine....

I wonder if perhaps this was an unintended side effect of trying to
make the IETF "all growned up" and more of a "professional standards
body" ala ISO....

	       		    	    - Ted

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2020 22:42:10 +0100

> make the IETF "all growned up" and more of a "professional standards

Who in their right mind tries to negotiate a donation ... unless they really don't
want it.

What manner of "grown up" management involves dicking around with the person
who you rely on for key infrastructure... unless you believe it should all move
to github anyway and our "bespoke tools" really don't matter that much.

	Cheers Leif

---

From: Larry Masinter <[email-masked]>
Date: Thu, 5 Nov 2020 15:08:30 -0800

> unless you believe it should all move to github anyway and our "bespoke
tools" really don't matter that much.

There has been enormous progress in the last decade in the area of
collaborative tools for document creation and review.

While github isn't THE answer, the "bespoke tools" developed to support
legacy workflows really DON'T matter that much.
Google Docs, Dropbox, Microsoft Office, Acrobat, git.ietf.org might all be
options.

Right now, IETF is in the unenviable position of imposing a serious tax of
attention for people who don't care about text formats to make a
contribution.
It's a bad filter of ideas to only allow those who can deal with XML in
whichever is the version du jour.  The expeeriment in file format chage has
taken too long and the world has moved on.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 6 Nov 2020 00:22:30 +0100

On 2020-11-06 00:08, Larry Masinter wrote:
> While github isn't THE answer, the "bespoke tools" developed to support legacy workflows really DON'T matter that much.
> Google Docs, Dropbox, Microsoft Office, Acrobat, git.ietf.org <http://git.ietf.org> might all be options.
> 
> Right now, IETF is in the unenviable position of imposing a serious tax of attention for people who don't care about text formats to make a contribution.
> It's a bad filter of ideas to only allow those who can deal with XML in whichever is the version du jour.  The expeeriment in file format chage has taken too long and the world has moved on.
> 

I'm sure there is an IETF mailing list somewhere where this and other points on tools are discussed and
subject to IETF consensus.

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 05 Nov 2020 17:37:18 -0600

On 5 Nov 2020, at 17:08, Larry Masinter wrote:

> While github isn't THE answer, the "bespoke tools" developed to 
> support legacy workflows really DON'T matter that much.
> Google Docs, Dropbox, Microsoft Office, Acrobat, git.ietf.org might 
> all be options.
>
> Right now, IETF is in the unenviable position of imposing a serious 
> tax of attention for people who don't care about text formats to make 
> a contribution.

Larry, I apologize if this sounds harsh, but text formats have almost 
nothing to do with the bespoke tools and I don't think you really 
understand how our toolchain is being used or the breadth of functions 
being provided. Do any of the tools on your list, *without bespoke 
customization*, support working group document management along these 
lines?

- a tree of state management (with different trees for WG vs AD 
management; if you haven't looked at the document state tree, you should 
before answering the question)
- balloting by IESG, which integrates heavily with state management
- integration with meeting agendas (such that documents can appear as 
topic items, meeting materials can be managed, calendars can show 
pointers to those items and online meeting calls)...
- role-based ACL (ability to change different attributes or edit the 
document depending on whether you're the AD, chair, doc editor, doc 
shepherd, participant, review team member, etc.)
- review team assignments with due-date reminders and templates / forms 
for reviews

And the list goes on and on. Again, the text format of the documents has 
little to nothing to do with these issues.

If you're simply saying we should adjust our workflow to conform to some 
other tool, that seems completely backwards and I think the suggestion 
is misguided. If you're saying that it will just take some 
customizations of these other tools to accomplish what we want, I think 
you wildly underestimate the amount of customization that will be 
needed.

Yes, there are loads of ways we can and probably should integrate things 
like git document management and other editing tools into our toolchain. 
And the tools team has done those sorts of integrations for many years. 
But the suggestion that it is so simply replaced is seriously 
misunderstanding the tools we have and our workflows.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 00:39:47 +0100

On 2020-11-06, at 00:08, Larry Masinter <[email-masked]> wrote:
> 
> only allow those who can deal with XML

Submitting an I-D has never required skills in XML and still doesn’t.

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Nov 2020 15:48:30 -0800

> On Nov 5, 2020, at 3:37 PM, Pete Resnick <[email-masked]> wrote:
> 
> If you're simply saying we should adjust our workflow to conform to some other tool,

Everyone else does. Look at what Jira and github are used for.  

The world has moved on. IMO, unless you (or others who want the alternate too) are volunteering to build tools - at the direction of others, and probably for insufficient funds or for free - there is no other path forward. 

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 5 Nov 2020 18:55:52 -0500

Joe, I think you missed an important part of Pete's message.

Even if we use other tools, we will need cusotmization to match our 
process requirements.  No, it does not have to work exactly like tools. 
and datatracker. work.  We have done a lot there to make AD and chair 
jobs tractable.  Someone will have to figure out how to do that for any 
other tool we start to use.  It is not even obvious that it can be done. 
  And it is certainly not obvious that it would be easy.

Yours,
Joel

---

From: Larry Masinter <[email-masked]>
Date: Thu, 5 Nov 2020 16:03:26 -0800

which group in IETF or the LLC or ISOC or whatever is chartered to discuss
such long-term issues, though? It's out of scope for SHMOO, Is IETF
committed to having a unique (bespoke, open-source?) toolchain?
I think IETF toolchains should meet the old standard for standards:
multiple, independent, interoperable implementations.  Multiple = more than
one = not bespoke (unless you mean that term in some other way?

On Thu, Nov 5, 2020 at 3:45 PM Pete Resnick <[email-masked]> wrote:

> Google Docs, Dropbox, Microsoft Office, Acrobat, git.ietf.org might all
> be options.
>
>    topic items, meeting materials can be managed, calendars can show pointers
>    to those items and online meeting calls)...
>    - review team assignments with due-date reminders and templates /
>    forms for reviews
>
> other tool, that seems completely backwards and I think the suggestion is
> misguided. If you're saying that it will just take some customizations of
> these other tools to accomplish what we want, I think you wildly
> underestimate the amount of customization that will be needed.
>
> And the tools team has done those sorts of integrations for many years. But
> the suggestion that it is so simply replaced is seriously misunderstanding
> the tools we have and our workflows.
>
> pr
> --

-- 
--
https://LarryMasinter.net <http://larry.masinter.net>

---

From: Jay Daley <[email-masked]>
Date: Fri, 6 Nov 2020 13:09:58 +1300

> On 6/11/2020, at 1:03 PM, Larry Masinter <[email-masked]> wrote:
> 
> which group in IETF or the LLC or ISOC or whatever is chartered to discuss such long-term issues, though? It's out of scope for SHMOO, Is IETF committed to having a unique (bespoke, open-source?) toolchain?
> I think IETF toolchains should meet the old standard for standards: multiple, independent, interoperable implementations.  Multiple = more than one = not bespoke (unless you mean that term in some other way?

The Tools Architecture and Strategy Team.  https://datatracker.ietf.org/group/tools-arch/about/ <https://datatracker.ietf.org/group/tools-arch/about/>

Jay

> 
> 
> 
> On Thu, Nov 5, 2020 at 3:45 PM Pete Resnick <[email-masked] <mailto:[email-masked]>> wrote:
> Google Docs, Dropbox, Microsoft Office, Acrobat, git.ietf.org <http://git.ietf.org/> might all be options.
> 
> Larry, I apologize if this sounds harsh, but text formats have almost nothing to do with the bespoke tools and I don't think you really understand how our toolchain is being used or the breadth of functions being provided. Do any of the tools on your list, without bespoke customization, support working group document management along these lines?
> 
> a tree of state management (with different trees for WG vs AD management; if you haven't looked at the document state tree, you should before answering the question)
> balloting by IESG, which integrates heavily with state management
> integration with meeting agendas (such that documents can appear as topic items, meeting materials can be managed, calendars can show pointers to those items and online meeting calls)...
> role-based ACL (ability to change different attributes or edit the document depending on whether you're the AD, chair, doc editor, doc shepherd, participant, review team member, etc.)
> review team assignments with due-date reminders and templates / forms for reviews
> And the list goes on and on. Again, the text format of the documents has little to nothing to do with these issues.
> 
> If you're simply saying we should adjust our workflow to conform to some other tool, that seems completely backwards and I think the suggestion is misguided. If you're saying that it will just take some customizations of these other tools to accomplish what we want, I think you wildly underestimate the amount of customization that will be needed.
> 
> Yes, there are loads of ways we can and probably should integrate things like git document management and other editing tools into our toolchain. And the tools team has done those sorts of integrations for many years. But the suggestion that it is so simply replaced is seriously misunderstanding the tools we have and our workflows.
> 
> pr
> -- 
> Pete Resnick https://www.episteme.net/ <https://www.episteme.net/>
> https://LarryMasinter.net <http://larry.masinter.net/>

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Joseph Touch <[email-masked]>
Date: Thu, 5 Nov 2020 16:21:45 -0800

> On Nov 5, 2020, at 3:55 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Even if we use other tools, we will need cusotmization to match our process requirements. 

I think you missed the point of my reply:

	everyone else seems to be adapting their processes to available tools

Jira was designed for trouble tickets in software development, but is being used for a LOT of other things too.

Sure, you can claim we’re “special” and “unique” and need a custom or even adapted solution. 

But that means we have to find someone willing to adapt the tools, under the direction of others, for the money we’re willing to pay - AND support those mods.

We just found out that’s not so easy, so maybe it’s time to change assumptions.

Joe

---

From: Larry Masinter <[email-masked]>
Date: Thu, 5 Nov 2020 16:23:53 -0800

which group should talk about document collaboration tools and ietf
processes.

Surveying the tools is a topic for  https://going-remote.info

On Thu, Nov 5, 2020 at 3:48 PM Joe Touch <[email-masked]> wrote:

> other tool,
> The world has moved on. IMO, unless you (or others who want the alternate
> too) are volunteering to build tools - at the direction of others, and
> probably for insufficient funds or for free - there is no other path
> forward.
>
> Joe
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2020 13:25:21 +1300

On 06-Nov-20 13:09, Jay Daley wrote:
> 
> 
>> On 6/11/2020, at 1:03 PM, Larry Masinter <[email-masked] <mailto:[email-masked]>> wrote:
>>
> The Tools Architecture and Strategy Team.  https://datatracker.ietf.org/group/tools-arch/about/

"The TAS team is expected to consult widely with the IETF community..."

I assume the venue for that is [email-masked] ?

   Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 6 Nov 2020 13:28:24 +1300

> On 6/11/2020, at 1:25 PM, Brian E Carpenter <[email-masked]> wrote:
> 

You will need to ask the chairs that but the page does point to the mailing list [email-masked]

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Nov 2020 00:40:53 +0000

*   which group in IETF or the LLC or ISOC or whatever is chartered to discuss such long-term issues, though?

https://www.ietf.org/about/groups/tools/

  *   I think IETF toolchains should meet the old standard for standards: multiple, independent, interoperable implementations.  Multiple = more than one = not bespoke (unless you mean that term in some other way?

The IETF has to have a standard input format for things that the authors intend to become RFC’s.  Are you arguing about that?  Or do you just not like that the official choice is XML with custom tags?

You’re not obligated to use that – there are converters that take MSWord, markdown, integrate with github actions, etc. You just have to get to XML so the IETF can work with it.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 5 Nov 2020 16:53:08 -0800

Any document workflow that requires a manual format conversion at an
interface with a review function fails miserably because the comments are
made on the processed output and don't map back readily to comments on the
author's source.

On Thu, Nov 5, 2020 at 4:41 PM Salz, Rich <[email-masked]> wrote:

>
>
>    - which group in IETF or the LLC or ISOC or whatever is chartered to
>    discuss such long-term issues, though?
>
>
>
>    - I think IETF toolchains should meet the old standard for standards:
> The IETF has to have a standard input format for things that the authors
> intend to become RFC’s.  Are you arguing about that?  Or do you just not
> like that the official choice is XML with custom tags?
>
>
>
> You’re not obligated to use that – there are converters that take MSWord,
> markdown, integrate with github actions, etc. You just have to get to XML
> so the IETF can work with it.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Nov 2020 00:57:12 +0000

Jay's note was a little incorrect.

There is a tools-team which is described on https://www.ietf.org/about/groups/tools/ and has an open email list called tools-discuss at https://www.ietf.org/mailman/listinfo/tools-discuss  This group works on things like code sprints, data tracker, IETF issues for the RPC, and so on. They've also discussed hosting, containers, Jabber/IM experiments, and so on.

There is another group, recently chartered, called the tools architecture and strategy team. That charter is to look at longer-range issues and is purposefully a closed-membership group, although the archives are public. I am one of the co-chairs. You can think of the recent document-preparation survey as one of the first inputs into tools-arch.

Hope this helps.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Nov 2020 00:59:47 +0000

*   Any document workflow that requires a manual format conversion at an interface with a review function fails miserably because the comments are made on the processed output and don't map back readily to comments on the author's source.

Do you know any publication system that places no restrictions on input format?  Or do I not understand what you are asking.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 5 Nov 2020 17:22:15 -0800

I was pointing out a fundamental. It doesn't help that authors can submit
documents in other forms than XML if authors get back comments, suggestions
in another form.  Using Git to manage document edits also implies you've
agreed to the input format.

On Thu, Nov 5, 2020 at 4:59 PM Salz, Rich <[email-masked]> wrote:

>
>
>    - Any document workflow that requires a manual format conversion at an
> Do you know any publication system that places no restrictions on input
> format?  Or do I not understand what you are asking.
>

---

From: Joseph Touch <[email-masked]>
Date: Thu, 5 Nov 2020 17:47:19 -0800

> On Nov 5, 2020, at 5:22 PM, Larry Masinter <[email-masked]> wrote:
> 
> Using Git to manage document edits also implies you've agreed to the input format.

And that Git supports that format (e.g., text, for XML source).

I don’t think Git can itself track Word diffs, e.g. If requiring Git manage edits is a criteria, you’ve walled the solution in (and it’s standing in 1970).

Joe

---

From: Keith Moore <[email-masked]>
Date: Thu, 5 Nov 2020 22:18:08 -0500

> Everyone else does. Look at what Jira and github are used for.

Jira is an abomination, and a great way to waste time without getting 
anything useful done.  The rest of the world might work that way, but 
that's no excuse for IETF to do so.

(github has its place, but I'm still not convinced it's a great way to 
collaboratively edit text documents.   I think it's an interesting 
experiment though and something useful will probably be learned from it.)

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 6 Nov 2020 12:19:20 +0900

> Submitting an I-D has never required skills in XML and still doesn’t.

Indeed. Plain text generated by nroff is good enough for me to
prepare an ID on quantum error correction.

						Masataka Ohta

---

From: Joseph Touch <[email-masked]>
Date: Thu, 5 Nov 2020 19:46:08 -0800

> On Nov 5, 2020, at 7:18 PM, Keith Moore <[email-masked]> wrote:
> 
> Jira is an abomination, and a great way to waste time without getting anything useful done.  The rest of the world might work that way, but that's no excuse for IETF to do so.
> 

The point is that we either adapt to (or find a way to use) existing tools, or not only pay to build them but find someone willing to take our money.

Again, we just found out the latter isn’t so easy. I don’t think the doors will be knocked down with volunteers, even for pay.

Joe

---

From: Lloyd W <[email-masked]>
Date: Fri, 6 Nov 2020 16:34:51 +1100

I'm becoming convinced that these incidents (losses of experienced RFC Editor and tools contract work) are examples of managing for short-term overheads and cost savings, rather than for longer-term organisational needs and growth.

Or it's the open source culture exploitation - why pay for anyone's time if the community can be made to replace and do it for free?

Are there other examples? Is it still reasonable to talk about "long term" for the IETF?

Lloyd Wood
[email-masked]

> On 6 Nov 2020, at 01:33, Stewart Bryant <[email-masked]> wrote:
> 
>> Von: Benoit Claise <bclaise=[email-masked]>
>> An: Toerless Eckert <[email-masked]>, Henrik Levkowetz <[email-masked]>

---

From: Leif Johansson <[email-masked]>
Date: Fri, 6 Nov 2020 06:52:19 +0100

Skickat från min iPhone

> 6 nov. 2020 kl. 04:20 skrev Keith Moore <[email-masked]>:
> 
> 
Also y’all should take a look at their price trajectory over the last few years...

---

From: Amelia Andersdotter <[email-masked]>
Date: Fri, 6 Nov 2020 08:18:59 +0100

> subject to IETF consensus.
In fact, SHMOO is chartered to look at technical requirements for tools
used for online meetings. You're all welcome to participate there!

best regards,

-- 
^\...~...~...~...~...~.../^
Amelia Andersdotter
IETF SHMOO WG Co-Chair
https://datatracker.ietf.org/group/shmoo/about/

Director of Strategic Initiatives, CENTR
www.centr.org
^\...~...~...~...~...~.../^

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Nov 2020 07:49:20 -0300

Henrik,

I'm sad to hear your note.

As I'm thankful for your work (and help that you've provided when I've 
needed it), may I suggest the community that besides showing our 
appreciation for Henrik's work (or, as a way of showing it), we try to 
find a way to remediate the situation, rather than greeting him "goodbye"?

Just my two cents,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 Nov 2020 13:51:57 +0000

Since you mention feedback via a form below, I wanted to note that people may wish to join next week's IETF LLC board call and ask questions during the open session (I usually ask during Any Other Business / AOB). See https://ietf.org/about/groups/llc-board/meeting-info/ for the Webex link -- 12 November at 20:00 UTC.

As a side note, it is quite rare that more than 1 or 2 observers attend and I can't recall the last time anyone asked a question during AOB.

Regards
Jason

On 11/4/20, 3:30 PM, "ietf on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    Whatever we think about the past, the future is what matters.
    Everybody can influence that future by means of their inputs to
    NomCom. This year there are not only inputs for each individual
    candidate, but also for some major topics that NomCom should
    consider, for example:
    https://urldefense.com/v3/__https://datatracker.ietf.org/nomcom/2020/feedback/?topic=26__;!!CQl3mcHX2A!URvA5Nx79RsNl1fuZ_Rk2zbIKmi447FTe_gMAE-NMcR4-vWah1upX9mUJ3AltrOccy-N3Q$
    https://urldefense.com/v3/__https://datatracker.ietf.org/nomcom/2020/feedback/?topic=22__;!!CQl3mcHX2A!URvA5Nx79RsNl1fuZ_Rk2zbIKmi447FTe_gMAE-NMcR4-vWah1upX9mUJ3AltrMFa6Q8UA$

    Regards
       Brian Carpenter

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 Nov 2020 13:59:13 +0000

> Right now, IETF is in the unenviable position of imposing a serious tax of attention for people who don't care about text formats to make a contribution. It's a bad filter of ideas to only allow those who can deal with XML in whichever is the version du jour.  The expeeriment in file format chage has taken too long and the world has moved on.

It may interest people to know that the topic of XMLv3 is on the IETF LLC’s board meeting agenda next week (it will occur during the Executive Director's report). See also this recent blog post at https://www.ietf.org/blog/rfc-v3-xml-issues/.

The board meeting info is at https://ietf.org/about/groups/llc-board/meeting-info/ for the Webex link -- 12 November at 20:00 UTC.

Jason

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Nov 2020 14:05:35 -0000

Jason,

Thanks for this.

Just so you know, I've only been to a couple of board calls, and I noted the AOB section, but it didn't register with me that the floor was open for questions from all-comers. Not that I had questions to ask, and it may be that I just happened to hit the calls where mentioning that anyone could ask a question was accidentally dropped. 

Maybe make it a little clearer in the agenda? E.g....
Part I: Public
7. AOB and Questions from Any Dial-in Observer

Cheers,
Adrian

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Livingood, Jason
Sent: 06 November 2020 13:52
To: [email-masked]
Subject: Re: A sad farewell

Regards
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 Nov 2020 14:46:27 +0000

Great feedback - will make that change now!
Jason

On 11/6/20, 9:09 AM, "ietf on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Jason,

    Thanks for this.

    Cheers,
    Adrian

    -----Original Message-----
    From: ietf <[email-masked]> On Behalf Of Livingood, Jason
    Sent: 06 November 2020 13:52
    To: [email-masked]
    Subject: Re: A sad farewell

    Since you mention feedback via a form below, I wanted to note that people may wish to join next week's IETF LLC board call and ask questions during the open session (I usually ask during Any Other Business / AOB). See https://urldefense.com/v3/__https://ietf.org/about/groups/llc-board/meeting-info/__;!!CQl3mcHX2A!TJW2od8KK8HrVslCODg431FlxlwWD79gbqy1NtfSJKBQ7DJxkwjSRL57-YQsu2Z-hl0-PQ$  for the Webex link -- 12 November at 20:00 UTC.

    Regards
    Jason

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Nov 2020 08:15:19 -0300

On 5/11/20 21:57, Salz, Rich wrote:
> There is another group, recently chartered, called the tools architecture and strategy team. That charter is to look at longer-range issues and is purposefully a closed-membership group, although the archives are public.

How are/were members selected?

Thanks,

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 6 Nov 2020 10:40:34 -0500

Hi Fernando,

> On Nov 6, 2020, at 6:15 AM, Fernando Gont <[email-masked]> wrote:
> 

I manage the membership of the team, same as for the other teams and directorates in the general area. The team page is here: https://datatracker.ietf.org/group/tools-arch/about/ <https://datatracker.ietf.org/group/tools-arch/about/>

I’ve included below the initial message I sent to Henrik, Robert, and Russ about the team when I was thinking about forming it. As you can see, the idea of this team was to get some new people together with people with extensive IETF tools experience and split the load of considering some of the bigger picture strategic and architectural aspects from the day-to-day maintenance, development, and oversight of the tools. I had good follow-up on this email with Robert where we discussed it on several calls. I never heard anything about it from Henrik, and the team was formed about three weeks after I sent this email and after the full tools team, IESG, and IAB were looped in.

As Rich noted, in its nine months of existence the team has had a small amount of discussion, mostly focused on authoring tools. https://mailarchive.ietf.org/arch/browse/tools-arch/ <https://mailarchive.ietf.org/arch/browse/tools-arch/>

Best,
Alissa

--------

> 
> From: Alissa Cooper <[email-masked]>
> Subject: IETF tools architecture and strategy team
> Date: January 16, 2020 at 4:44:33 PM EST
> To: Russ Housley <[email-masked]>, Henrik Levkowetz <[email-masked]>, Robert Sparks <[email-masked]>
> Cc: Jay Daley <[email-masked]>
> 
> Hi all,
> 
> I've put together a description for a new team in the General area, the tools architecture and strategy team (see attached). Based on observations of the tools team over the last few years and discussions with Jay, I think there is a need to dedicate more and separate resources from the community to thinking about the overall architecture of the IETF tools and support for them. The tools suite has grown organically and serves many needs (thanks to you and our dedicated volunteers!), but it would be nice to have more coherence of strategy and architecture across the whole suite. 
> 
> The development of this should not distract from the day-to-day work that you and the contracted developers put in, nor from the operational oversight that the tools team provides. At the same time, my hope is that having the kinds of guidance outlined in the team description will reduce friction in the tools development process over time and make the whole operation run more smoothly. If there are important topics that you think are missing from the initial topics list, please let me know.
> 
> I’ll be reaching out to the people listed in the document to gauge their interest in participating and later informing the community, but I wanted you to be aware of this from the outset while it’s still in development. There are a couple of people listed there who are not IETF participants but who have a lot of experience with large-scale software deployments and management, to provide some external perspective. Robert, I’ve listed you as tools team liaison in the hope that you can serve as a bridge between the teams, and the team description has some words about having you establish plans and workflows. Let me know what you think.
> 
> Let me know if you have questions, comments, or concerns. I would also be happy to jump on a call if you want to discuss further.
> 
> Best,
> Alissa
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Nov 2020 15:44:32 +0000

The IETF Chair.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Nov 2020 11:02:41 -0500

My tool, RFCTool can accept input in Word, or Markdown or both. It is open
source and runs on OSX, Linux and Windows.

I don't currently support diffs but I could and this is something I am
planning to add at some point when I get round to the real purpose of the
Mesh which is to support end-to-end secure social media (the service
supporting the forums cannot read the contents of the forums).

RFCTool can generate output in any of the input formats. So it can be used
to create a Markdown version of a Word document for comparison purposes.
That would work in an OK way today but it could be made more robust.

Having written a dozen drafts that combine text, graphics, source code and
examples, I think this approach is going to be essential in the future.

Most people in this thread seem to be asking 'how do I produce the
documents I produce today in XML2RFCv3. That is the wrong question. You
will quickly find you change the way you work because you want to produce
different types of document.

You are not going to have a single input source file. You will have many.
Some of those inputs will be generated by other tools. Consider for
example, the Mesh schema draft.

https://www.ietf.org/archive/id/draft-hallambaker-mesh-schema-06.html

The reason I can produce so many drafts by myself is that I am using a very
powerful tool chain. This document actually has about 30 input files:

1) Base document (Word). This contains the bulk of the prose. Word document
styles are used for paragraph, etc. markup. This provides me with spelling
and grammar checking and a decent UI.

2) Examples. Data produced by running the reference implementation in a
captive environment is converted to Markdown using Goedel Scripting.

3) Diagrams. These were produced using Viso but I was forced to switch to a
modified version of GOAT because Viso can't produce the non standard SVG
required and conversion is not viable.

4) Schema. I believe that the primary purpose of a schema language should
be to document the serialization format. I use several schema languages of
my own design. These also generate markdown output.

Machine generated output tends to be more consistent than human which is a
major advantage when engaged in repetitive edit cycles. It is far from
foolproof.

The point I am making here is that comparing diffs on the input files is
really not going to be helpful when other people adopt similar approaches.
The solution in my view is to create an output for the purpose of
comparison.

On Thu, Nov 5, 2020 at 8:48 PM Joseph Touch <[email-masked]> wrote:

> I don’t think Git can itself track Word diffs, e.g. If requiring Git
> manage edits is a criteria, you’ve walled the solution in (and it’s
> standing in 1970).
>
> Joe
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 6 Nov 2020 08:42:06 -0800

> On Nov 6, 2020, at 8:02 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> My tool, RFCTool can accept input in Word, or Markdown or both. It is open source and runs on OSX, Linux and Windows.

Typing XML in Word is not really Word (E.g., references, anchors, tag data, etc.). 

IMO, the point of a Word template is to have it be able to edit and print drafts as they would be seen by users AND to allow use of Word’s internal cross-reference capability. 

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Nov 2020 12:06:30 -0500

> Typing XML in Word is not really Word (E.g., references, anchors, tag

Why on earth did you assume that was what I was doing?

IMO, the point of a Word template is to have it be able to edit and print
> drafts as they would be seen by users AND to allow use of Word’s internal
> cross-reference capability.
>

Of course. I use an open source library that parses the Word document for
me and returns a parse tree containing all the paragraph and line markup,
cross references, etc. etc.

I do use a very small amount of pseudo-XML at the very start of a document
because this is a more convenient means of expressing the IETF specific
markup than breaking that all out into Word tags. I am also using xml tags
for citations because we need those broken out into normative and
informative and the Word citation manager isn't really fit for purpose.

I can easily extend the converter so that instead of typing
<norm="draft-hallambaker-mesh-architecture"/> for a normative citation of
that draft you would use a Word line style so that all you see is
draft-hallambaker-mesh-architecture, preferably in a different color. I am
planning something of the sort the next time I work on that part of the
tool because I would like to be able to break out defined terms in the same
way.

Another obvious change would be to merge the RFCTool and Kramdown approach
to markdown and tagging. The issue there being that I am trying to align
with Git Markdown and Carsten has a legacy thing.

Sure, the Word editing mode can be made to be made into something more
native if that would encourage folk to use it. Making those changes is
'probably not' a great deal of work. The issues would come from Word format
being really very complex under the covers.

https://github.com/hallambaker/PHB-Build-Tools

This is where the text is at the moment. This plus citations and include
file directives in the running text are basically the only places that use
XML.

Mathematical Mesh 3.0 Part IV: Schema Reference

Mesh Schema Reference

<series>draft-hallambaker-mesh-schema

      <status>informational

      <stream>independent

<ipr>trust200902

<author>Phillip Hallam-Baker

    <surname>Hallam-Baker

    <initials>P. M.

    <firstname>Phillip

    <email>[email-masked]

    <organization>ThresholdSecrets.com

<also>http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html

The Mathematical Mesh ‘The Mesh’ is an end-to-end secure infrastructure
that facilitates the exchange of configuration and credential data between
multiple user devices. The core protocols of the Mesh are described with
examples of common use cases and reference data.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list (
[email-masked]), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.
Introduction

This document describes the data structures of the Mathematical Mesh with
illustrative examples. For an overview of the Mesh objectives and
architecture, consult the accompanying *Architecture Guide*
<norm="draft-hallambaker-mesh-architecture"/>. For information on the
implementation of the Mesh Service protocol, consult the accompanying *Protocol
Reference* <norm="draft-hallambaker-mesh-protocol"/>

---

From: tom petch <[email-masked]>
Date: Fri, 6 Nov 2020 17:28:14 +0000

> Are there other examples? Is it still reasonable to talk about "long term" for the IETF?

Two swallows do not make a summer!  but if this was a top-down managed 
organisation, then the manager might be thinking who else is in a 
comparable situation to the two losses and go talk to them to see if 
they have any feedback that will diminish the chance of a third swallow.

Tom Petch

---

From: Joseph Touch <[email-masked]>
Date: Fri, 6 Nov 2020 09:53:23 -0800

> On Nov 6, 2020, at 9:06 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> On Fri, Nov 6, 2020 at 11:42 AM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> On Nov 6, 2020, at 8:02 AM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>> 

From the instructions on inserting anchors and references. 

> Of course. I use an open source library that parses the Word document for me and returns a parse tree containing all the paragraph and line markup, cross references, etc. etc.
> 
> I do use a very small amount of pseudo-XML at the very start of a document because this is a more convenient means of expressing the IETF specific markup than breaking that all out into Word tags. I am also using xml tags for citations because we need those broken out into normative and informative and the Word citation manager isn't really fit for purpose.

And for cross-references, e.g., “See Section 12” or “See Figure 22”.

By the time you add it up, you’re taking a good chunk of why Word is useful and pushing it off to explicitly entered XML.

> I can easily extend the converter so that instead of typing <norm="draft-hallambaker-mesh-architecture"/> for a normative citation of that draft you would use a Word line style so that all you see is draft-hallambaker-mesh-architecture, preferably in a different color.

That’s not a Word cross-reference. That’s a line style. 

Joe

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Nov 2020 14:04:45 -0500

Fernando:

https://datatracker.ietf.org/group/tools/about/ <https://datatracker.ietf.org/group/tools/about/>

The Tools Team is part of the GEN Area, so the members are appointed by the IETF Chair.  Of course, volunteering ia a great way to start...

Russ

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 20:18:50 +0100

On 2020-11-06, at 02:22, Larry Masinter <[email-masked]> wrote:
> 
> I was pointing out a fundamental. It doesn't help that authors can submit documents in other forms than XML if authors get back comments, suggestions in another form.  Using Git to manage document edits also implies you've agreed to the input format.

Programmers are used to getting comments in other forms than their input language.
They write “a < 1” and get back a comment that the program crashes now and then.

It is not productive to put the onus of dealing with an input format on the reviewers.  They should have an easy time.  It is the authors that have to bear the main load of dealing with comments.  (That is a simple math issue, at least if you agree that we should have more reviewers on a document than authors.)

I can’t believe the discussion of a serious organizational and social problem is degenerating into a discussion of technical issues again.  I’ve changed the subject, but of course I can’t do that retroactively for the other messages that are off-topic for the main thread.

Grüße, Carsten

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 06 Nov 2020 13:31:23 -0600

On 6 Nov 2020, at 13:18, Carsten Bormann wrote:

> I can’t believe the discussion of a serious organizational and 
> social problem is degenerating into a discussion of technical issues 
> again.  I’ve changed the subject, but of course I can’t do that 
> retroactively for the other messages that are off-topic for the main 
> thread.

Yes, I apologize for contributing to that. Instead of simply responding 
to Larry by saying, "Please don't belittle Henrik's contribution and the 
organizational issue he brought up by making this about your tooling 
concerns", I went after his tooling concerns. The latter should've at 
the very least been taken a different thread or list, if not simply 
ignored.

pr

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 20:31:48 +0100

> I don’t think Git can itself track Word diffs, e.g. If requiring Git manage edits is a criteria, you’ve walled the solution in (and it’s standing in 1970).

Whoa.  It’s Word that is trying to live that 1970’s dream, WYSIWYG.

It has taken a long time for the community to realize that this approach is not productive for collaboration on technical documents.  
That’s why today we use git (which now is the gold standard for collaborative development) and markdown (or some other humane markup language).

(I usually collaborate on slides with Keynote.  
I fully understand the pull that this kind of tools exerts [in particular if done right], and they are great for one-off stuff like slides.  
But that is a kind of tool that is less central to the core business of the IETF.)

[Why do I react so strongly here?
I have edited one RFC using Word, RFC 3095, with a herd of 15 co-authors. 
Never, never, never again.]

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 20:47:01 +0100

> 
> Carsten has a legacy thing

That is a fun subject, and maybe something that can actually give back to the discussion that this subject has forked off from.

In the IETF, drafts often have a long and protracted life.
Over a time of half a decade and more.
So stability in the authoring formats is gold.
(Which irks me, because there are some small aspects of kramdown-rfc I would otherwise improve [on the other hand, I am surprised how well it kept over its first decade].)

How is this relevant to the main thread discussion?
Only someone who is familiar with the actual work can properly assess (or even come up with) this “requirement” (read: objective with a strong weighting).
We need to treat people who have acquired this familiarity (and have the intellectual versatility to actively make use of it) with respect.
(Even if they happen to straddle the boundary between respected community member and “just a contractor”(*).)

Grüße, Carsten

(*) You know where you heard this phrase first.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 6 Nov 2020 15:24:26 -0500

On Thu, Nov 5, 2020 at 7:41 PM Salz, Rich <rsalz=[email-masked]>
wrote:

>  *...*

I periodically do documents that get published as RFCs and I'm not sure if
I've submitted even one in XML. Actually I think there was one case some
time ago where I was making minor changes to a document that was already in
XML. I and a number of other people just submit text documents in the form
of internet-drafts, produced by nroff or whatever. Works fine without any
need on my part to "get to XML".

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Nov 2020 16:34:17 -0500

> Submitting an I-D has never required skills in XML and still doesn’t.

And after 25 years of people telling us that text is dead, and we should move
on to their favorite vendor-proprietary tool, and get with the "hip" kids,
guess what: text-based markdown is all over github (gitlab, wiki*, ...)

Text based formats continue to win: markdown, yaml, JSON, etc.
All the cool kids use text based things today.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2020 21:36:57 -0500

>All the cool kids use text based things today.

In our little bubble we do.

In the other 99% of the world everyone exchanges MS Word documents.  I'm
certainly not saying that's wonderful, but it's reality.

I'd say Word is semi-proprietary. There is a nominal spec for DOCX
files (they're zip archives containing XML files), and what Word
actually does is close ehough to the spec that Libreoffice, Apple
Pages et al. can mostly keep up.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 7 Nov 2020 06:55:13 +0100

> certainly not saying that's wonderful, but it's reality.

Hammer/nail.

99 % of the world is not collaboratively developing high-quality technical specifications, so I don’t care that much about those 99 % as a role model.

I expect the minutes from the apartment owners’ meeting to be in MS-Word.
Or a random document from our university administration (which is slowly learning not to send around MS-Word documents as a replacement for emails :-).

But technical documents in the computer science department?  Ha.
Gitlab, hackmd/codimd, and (in the math/theoretical computer science world) overleaf are our collaboration platforms.

(My information security class uses markdown for all its assignments.
Even though that is not identified as a learning objective of that class, it creates great satisfaction to talk to alumni a couple of years later and hear unsolicited testimonials how they have weaned themselves off the time-wasting use of other formats.)

It is much harder to get rid of MS-Excel...

Grüße, Carsten

---

From: Christian Huitema <[email-masked]>
Date: Fri, 6 Nov 2020 23:11:36 -0800

> 99 % of the world is not collaboratively developing high-quality technical specifications, so I don’t care that much about those 99 % as a role model.

A lot of the rest of the world is working collaboratively, including
using commercial products like Microsoft's Office 365 to develop reports
and other documents. Or rival products from other companies. Whether
they are on par with our "high quality specifications" is debatable, but
I have no doubt that at least some are. I am definitely not proposing
that we immediately switch to using commercial products, but you cannot
just dismiss the experience of all these users.

> Or a random document from our university administration (which is slowly learning not to send around MS-Word documents as a replacement for emails :-).
Sure. Sending iterative versions of large documents by e-mail is not
exactly recommended practice. State of the art communication uses cloud
services from that. Kind of the whole reason why Microsoft developed
servers like SharePoint, or services like Office365. And of course
Microsoft is not alone there, Google has services like that too, and
quite a few other companies. Again, I am not advocating moving to such
services. Just mentioning that they do in fact exist
> Even though that is not identified as a learning objective of that class, it creates great satisfaction to talk to alumni a couple of years later and hear unsolicited testimonials how they have wea…

It may very well be that ad hoc tools developed for our community end up
better for us than generic tools developed by commercial companies. But
you should not take that for granted. After all, the commercial success
of these companies depends on keeping customers happy, and collaboration
on documents, spreadsheets or other items is their bread-and-butter.

-- Christian Huitema

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 7 Nov 2020 09:14:41 +0000

Not commenting on the core of the discussion but only agreeing with John about the 'proprietary' feature of MS-Word file format as I 'played' recently on a conversion tool [*] from IETF XMLv[23] to the Microsoft .DOCX. Actually and for many years, the format is open and public: http://officeopenxml.com/ it is indeed a lot of XML files that are zipped together with a docx extension.

Personally, I won't be happy to select MS-Word as the TOOL but I won't disagree too much on using Office Open XML FORMAT. The nuance is important IMHO. And the same reasoning of course for other tools and formats.

And of course, we can also wonder why we, as a community, have no problem to use github.com ;-)

-éric

[*] https://github.com/evyncke/xml2docx and/or the very basic conversion https://www.vyncke.org/xml2docx/, all being proof of concept and not real tools of course

-----Original Message-----
From: ietf <[email-masked]> on behalf of John Levine <[email-masked]>
Organization: Taughannock Networks
Date: Saturday, 7 November 2020 at 03:37
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: and... text for the win

    R's,
    John

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 7 Nov 2020 15:08:25 +0100

> Not commenting on the core of the discussion but only agreeing with John about the 'proprietary' feature of MS-Word file format as I 'played' recently on a conversion tool [*] from IETF XMLv[23] to…

The MOOX (Microsoft open office XML) formats are documented to some extent in an ECMA standard that was fast-tracked as an ISO standard, and the .docx part of the MOOX specification is even almost usable in practice.  So, yes, this is around.  So is, e.g., docbook, which is actually does have the structure for what is needed for publishing specification.

> Personally, I won't be happy to select MS-Word as the TOOL but I won't disagree too much on using Office Open XML FORMAT. The nuance is important IMHO. And the same reasoning of course for other to…

I’m not sure why I would want to incur the mind-boggling complexity and legacy baggage of MOOX if I don’t also want to use their very widely used tool.

> And of course, we can also wonder why we, as a community, have no problem to use github.com ;-)

But we do.  It is only acceptable because the core of it is open-source git, and we have convinced ourselves that there is a safety net in regularly backing up all the chrome that github adds to it.

> [*] https://github.com/evyncke/xml2docx and/or the very basic conversion https://www.vyncke.org/xml2docx/, all being proof of concept and not real tools of course

Interesting.  I haven’t looked into this in detail, but at first look it seems to confirm my reservations about the complexity of .docx, which will make it harder to sustain community-based projects that are based on it.

Where I need to interface to .docx (those pesky contracts etc.), I use pandoc for converting that to/from markdown.  That narrow waist would also give one an easy interface to RFCXML (well, OK, I finally need to make that RFCXML to markdown converter ready for prime time).

Grüße, Carsten

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 7 Nov 2020 06:25:49 -0800

> The MOOX (Microsoft open office XML) formats are documented to some extent in an ECMA standard that was fast-tracked as an ISO standard, and the .docx part of the MOOX specification is even almost…

As we are talking about that, I never understood why xml2rfc was not designed as a custom version of DocBook 5.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 7 Nov 2020 06:44:08 -0800

Hello Carsten and all,

IEEE 802 editors usually use Microsoft Word, and their specifications 
are high-quality technical specifications.  So please be careful about that.

However, I hated it the whole time.  My own preference is to use a 
format and tool where features have predictable results (Word fails this 
test miserably).  Even .xml fails this test sometimes, in my experience 
and according to the mailing list discussions on xml2rfc.  I can at 
least understand what text is going to look like when it gets 
published.   And let me once again say thanks for rfcdiff.  Fabulous.

Regards,
Charlie P.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 7 Nov 2020 16:39:11 +0100

> and according to the mailing list discussions on xml2rfc.  I can at

Are you reffering to reference inclusions occasionally failing, or
something else? In the latter case, I'd really like to see a detailed
bug report.

Best regards, Julian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 10 Nov 2020 23:40:00 +0900

Lloyd W wrote:

> I'm becoming convinced that these incidents (losses of experienced
> RFC Editor and tools contract work) are examples of managing for
> short-term overheads and cost savings, rather than for longer-term
> organizational needs and growth.

I disagree.

Those incidents should be caused by people who want to change
perfectly working situations toward worst possible situations,
because they want to say that they have performed some work.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Nov 2020 11:03:36 -0500

The response below misrepresents the situation completely. Henrik was
working on the new RFC tooling for the HTML format. From what I see, most
participants approve of what they see as improvements.

The issue that I see pervasively in IETF is a system in which people have
authority but not accountability. So people insist on being the one to make
a decision that they can never take because there is no clear indication of
what participants want.

There is a reason the IETF approach is not copied by any other
organization: It doesn't work. Organization of RFC tools process is
particularly convoluted because in addition to the usual IETF denial of the
obvious, there is the additional pretense of the RFC system supporting
multiple independent organizations.

This approach is going to be particularly unsuccessful when you are
employing people to work within it. The employees have no clear lines of
reporting. They will naturally feel they should be responsive to the whole
community, not just the IAB or the chair. But there are no mechanisms that
allow the whole community to provide direction.

A good start would be to recognize some obvious facts:

1) IETF participants SHOULD be treated as if they are members. Telling
people they are not members is silly and insulting. If you want an
inclusive organization, you treat people as members. Amex treats me as a
member, why can't IETF?

2) The RFC formats and publications serve the IETF community which includes
participants in IETF, IRTF and everything else. Nothing set the process up
for unnecessary pain so much as the notion that 'because RFCs are published
by more than just the IETF' the process should not be an IETF one.

3) If there is a point to what we are doing here, we are building the
future. Over the past 25 years, this organization has been the vanguard of
political and social changes that have created and destroyed tens of
millions of jobs. A veteran journalist who has lost their job multiple
times as the century old local papers they worked for has closed might have
a rather uncharitable response to people complaining that they can't work
in nroff. You can't build the 2020s living in the 1970s.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 12 Nov 2020 23:59:44 +0900

> participants approve of what they see as improvements.

As usual, you misunderstand my points completely. And, I'm afraid that
is your problem.

 > because they want to say that they have performed some work.

"perfectly working situations" mean tools managed by Henrik,
which is replaced by layers of committees, which is the worst
possible way to perform real works, as you can see recent gotcha
on ftp service by IETF.

> authority but not accountability.

That is certainly a problem to rely on layers of committees but is
a minor problem.

If members of a committee refuse to be responsible to their wrong
decisions, person who organized the committee should be accused.

> So people insist on being the one to make

Wrong.

As most users do not know what they need, it is wrong to modify tools
based on what users want.

Instead, real experts know what users needs. It is sometimes (or,
often) against expressed intentions of users.

That's how good tools have been developed. For example, iPhone was
developed by Steve Jobs before users wanted it.

However, collective stupidity of committees just conclude that
their, often wrong, ideas on what users want are what are necessary
for users, which is the problem of current IETF.

							Masataka Ohta