Subject: Re: [rfc-i] [IAB] [Rsoc] Archival format to rfc-interest and the IAB

From: Wes Hardaker <[email-masked]>
Date: Mon, 2 Mar 2020 10:19:20 -0800

>
>
>
> FWIW, the fact that *you* do not know the answer is kind of scary.
>

I expect that one of the things to come out of the upcoming discussions for
the future of the RSE roll will be where decisions are formally held and
what the right level of independence is with respect to the RSE role.

It's now something like 9 months since I tried to draw attention to the
> current mess, and there seems absolutely no measurable progress on this
> issue since

 I, for one, am happy you're pushing forward in bringing these issues
forward.  Unfortunately, the timing of needed v3 changes and the need for
this discussion pretty much collided at the same time.  I do think it's
important that we document these questions to ensure they're addressed in
due course.  One question left in my mind is the urgency of the problems:
if we have what seems like split-track v3 specs for a while due to
operational issues, how does the pain level grow with that timeline if not
resolved by time X?

-- 
Wes Hardaker
USC/ISI
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Mar 2020 19:46:16 +0100

On 02.03.2020 19:19, Wes Hardaker wrote:
> I expect that one of the things to come out of the upcoming discussions
> for the future of the RSE roll will be where decisions are formally held
> and what the right level of independence is with respect to the RSE role.
>
> forward.  Unfortunately, the timing of needed v3 changes and the need
> for  this discussion pretty much collided at the same time.  I do think
> it's important that we document these questions to ensure they're
> addressed in due course.  One question left in my mind is the urgency of
> the problems: if we have what seems like split-track v3 specs for a
> while due to operational issues, how does the pain level grow with that
> timeline if not resolved by time X?

Well, we have a growing number of documents published in a "canonical"
XML format that is not canonical and has no documentation.

The more we have of these, the more we'll have to fix later on.

And *if* we decide to actually back out changes to the vocabulary, the
longer it takes, the more painful it will be.

Best regards, Julian

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2020 14:28:46 -0500

> The more we have of these, the more we'll have to fix later on.

Henrik says, I believe correctly, that the changes have been backward 
compatible so the current grammar is a superset of the original, and all 
of the XML RFCs published to date are valid with the current grammar and 
render with the current version of xml2rfc.

Having said that, I also agree that the situation is not great.  The RSOC 
has tasked me with documenting the changes (starting with the deltas to 
the grammar which I do have) and coming up with a process to control 
future changes.

I think there are changes we'll want to back out so later this year we'll 
need to consider what's the best way to retroactively adjust the XML 
coding (not the text) and make it clear what we did.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Mar 2020 20:56:47 +0100

> render with the current version of xml2rfc.

That is probably true.

> Having said that, I also agree that the situation is not great.  The
> RSOC has tasked me with documenting the changes (starting with the
> deltas to the grammar which I do have) and coming up with a process to
> control future changes.

Note that the changes are not constrained to the grammar. For instance,
xml2rfc added support for special line break characters, and then later
on for <br>. Is the other thing going to backed out?

> I think there are changes we'll want to back out so later this year
> we'll need to consider what's the best way to retroactively adjust the
> XML coding (not the text) and make it clear what we did.

Absolutely.

And to get there, we have to work on rfc7991bis.

Best regards, Julian

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2020 15:07:48 -0500

> on for <br>. Is the other thing going to backed out?

I sure hope we back out the break entity.  It's an obvious kludge.

Regards,

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 2 Mar 2020 21:20:19 +0100

Given the number of lists copied here, I'd like to make just one
observation, in reply to Julian's assertion, so that people who haven't
been following the discussions on the xml2rfc-dev list in the last half
of 2018 have a bit more data to work with:

>> current mess, and there seems absolutely no measurable progress on this

At this point, people should be aware that the reason we haven't made progress
in determining a revised specification is that when I started to feed back
issues to the discussion list, Julian was sufficiently obstructionist in
his responses to many proposed adjustments that there was absolutely no hope
of both having that extended conversation and at the same time producing a
tool release that would let the RPC carry out their planned transition.

I deplore the situation we have, but the primary reason we are in this
situation is that sensible discussion and progress in resolving proposed
changes was killed by an Not-Invented-Here attitude from the v3 design team
members active on the discussion list in the autumn of 2018, with Julian
the most active in preventing any progress at all from taking place on some
issues.

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 3 Mar 2020 05:48:03 +0100

> the most active in preventing any progress at all from taking place on some

If that was true, how do you explain that I supported roughly half of
the proposed changes? And even for the changes I believe to be bad, I
implemented (and test-cased) most in my implementation so to be able to
provide useful feedback (see
<https://trac.tools.ietf.org/tools/xml2rfc/trac/report/1?asc=0&sort=ticket>
and <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues>).

...having a different opinion is not necessarily "obstructionist".

Best regards, Julian

---

From: Ronald Tse <[email-masked]>
Date: Tue, 3 Mar 2020 05:21:36 +0000

I have been tracking this list since we first implemented AsciiRFC for RFC XML v2, the draft v3, and now the “official" v3.

(As we speak, the "draft-ribose-asciirfc” document has already been stuck in AUTH for over 2 years).

To be fair, I concur with many of Julian’s comments and they are true concerns, especially since we’re dealing with “standardized documents” that need to be interoperable by different tools. The draft v3 and the current v3 are sufficiently incompatible that we consider them as different implementations — files that comply with draft v3 grammar crashes today's official toolset.

I understand the frustration. But as Julian has mentioned a couple times, there are practices and assumptions in the existing toolset that are not documented in spec. This is more likely the cause for stagnated progress.

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Mar 3, 2020, at 4:20 AM, Henrik Levkowetz <[email-masked]<mailto:[email-masked]>> wrote:

Henrik

_______________________________________________
rfc-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Mar 2020 06:35:22 +0100

> obstructionist

I think this was a matter of perceived tone as much as content.

Maybe because I’m a Northern German, too, I did not perceive the tone as obstructionist, more like as the way we tend to do work in this part of the world.

I was surprised to learn that several participants in the discussion had a different perception.  

I am no longer surprised by such surprises; I have long since learned that these differences in perception need to be managed to maintain a functional (and pleasant) working environment.  That may include being more careful in communicating with people from different cultures (both in sending and in receiving messages).

Why we didn’t yet manage to do this here, I don’t know.

Grüße, Carsten