Subject: [Tools-discuss] Author detection (Fwd: I-D Action: draft-normington-jsonpath-00.txt)

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Dec 2020 17:38:35 +0100

That didn’t quite work (maybe because of the Umlaut in Stefan Gössner’s name?).

Grüße, Carsten

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-normington-jsonpath-00.txt
> Date: 2020-12-07 at 15:14:43 CET
> To: <[email-masked]>
> Reply-To: [email-masked]
> Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/L7c7k-dRJ80ug5CVzfUAu_R3fnQ>
> Message-Id: <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : JavaScript Object Notation (JSON) Path
>        Authors         : Glyn Normington
>                          Edward Surov
>                          Marko Mikulicic
>                          Fachhochschule Dortmund
> 	Filename        : draft-normington-jsonpath-00.txt
> 	Pages           : 21
> 	Date            : 2020-12-07

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2020 11:00:22 -0600

The relevant code (for extracting authors from a .txt submission) is at

<https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/utils/draft.py#L511>

An xml submission shouldn't have this issue (I think).

RjS

On 12/7/20 10:38 AM, Carsten Bormann wrote:
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D Action: draft-normington-jsonpath-00.txt*
>> *Date: *2020-12-07 at 15:14:43 CET
>> *To: *<[email-masked] <mailto:[email-masked]>>
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>> *Archived-At: 
>> *<https://mailarchive.ietf.org/arch/msg/i-d-announce/L7c7k-dRJ80ug5CVzfUAu_R3fnQ 
>> <https://mailarchive.ietf.org/arch/msg/i-d-announce/L7c7k-dRJ80ug5CVzfUAu_R3fnQ>>
>> *Message-Id: *<[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Dec 2020 14:56:52 -0500

1. Robert: Why do I have to log in to access that page?  This code should
not be secret.

2. Related: https://twitter.com/mikewest/status/1335857840028790784

On Mon, Dec 7, 2020 at 12:00 PM Robert Sparks <[email-masked]> wrote:

> *From: [email-masked]
> *To: *<[email-masked]>
> *Reply-To: [email-masked]
> *Archived-At: *<
> https://mailarchive.ietf.org/arch/msg/i-d-announce/L7c7k-dRJ80ug5CVzfUAu_R3fnQ
> >
> *Message-Id: *<[email-masked]>
>
>
> Tools-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report tools.ietf.org bugs athttp://tools.ietf.org/tools/issues

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2020 14:06:53 -0600

On 12/7/20 1:56 PM, Richard Barnes wrote:
> 1. Robert: Why do I have to log in to access that page? This code 
> should not be secret.

It is not secret. But bots have been overwhelming that site - asking 
real people to login cut that load by orders of magnitude.

We will move this sourcebase, but for now setting up a tools.ietf.org 
account is not an impossible hurdle.

> <https://twitter.com/mikewest/status/1335857840028790784>

What we allow in the txt documents changed. It is unsurprising that 
code, especially code that has to operate on heuristics, would need to 
be touched to align with those changes.

>
> On Mon, Dec 7, 2020 at 12:00 PM Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>>     <mailto:[email-masked]>
>>>     *Archived-At:
>>>     *Message-Id:
>>>     *<[email-masked]
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/tools-discuss  <https://www.ietf.org/mailman/listinfo/tools-discuss>
>>
>>     Please reportdatatracker.ietf.org  <http://datatracker.ietf.org>  andmailarchive.ietf.org  <http://mailarchive.ietf.org>
>>     bugs athttp://tools.ietf.org/tools/ietfdb  <http://tools.ietf.org/tools/ietfdb>
>>     or send email [email-masked]  <mailto:[email-masked]>
>>
>>     Please reporttools.ietf.org  <http://tools.ietf.org>  bugs at
>>     http://tools.ietf.org/tools/issues  <http://tools.ietf.org/tools/issues>
>>     or send email [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tools-discuss>
>
>     Please report datatracker.ietf.org <http://datatracker.ietf.org>
>     and mailarchive.ietf.org <http://mailarchive.ietf.org>
>     <http://tools.ietf.org/tools/ietfdb>
>     <mailto:[email-masked]>
>
>     Please report tools.ietf.org <http://tools.ietf.org> bugs at
>     <http://tools.ietf.org/tools/issues>
>     <mailto:[email-masked]>
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Dec 2020 15:06:50 -0500

It seems likely that the bug is in these name regexes, which use `A-Z` and
`a-z` instead of Unicode-tolerant constructions like `\w` and `[:upper:]`

https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/utils/draft.py#L519

https://docs.python.org/3/howto/unicode.html
https://stackoverflow.com/questions/36187349/python-regex-for-unicode-capitalized-words

If this were in a proper repo and had proper testing in CI to confirm the
fix, I would submit a patch, but 🤷‍♂️

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Dec 2020 15:10:49 -0500

On Mon, Dec 7, 2020 at 3:07 PM Robert Sparks <[email-masked]> wrote:

> It is not secret. But bots have been overwhelming that site - asking real
> people to login cut that load by orders of magnitude.
>
This seems like a problem that Cloudflare or any other CDN) would be
well-suited to address.  Pretty amazed that this was not already in place.

--Richard

> What we allow in the txt documents changed. It is unsurprising that code,
> especially code that has to operate on heuristics, would need to be touched
> to align with those changes.
>
>
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2020 14:15:27 -0600

On 12/7/20 2:06 PM, Richard Barnes wrote:
> It seems likely that the bug is in these name regexes, which use `A-Z` 
> and `a-z` instead of Unicode-tolerant constructions like `\w` and 
> `[:upper:]`
>
> <https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/utils/draft.py#L519>
>
> <https://docs.python.org/3/howto/unicode.html>
> <https://stackoverflow.com/questions/36187349/python-regex-for-unicode-capitalized-words>
>
> If this were in a proper repo and had proper testing in CI to confirm 
> the fix, I would submit a patch, but 🤷‍♂️

Please restrain your tone.

The older subversion repository _is_ a proper repository, and the 
codebase has a testsuite that is run through automated testing on commit.

I understand that you are not happy with subversion, and not happy with 
the level of interaction required to get to the point where you can 
commit to a branch. I'm working on addressing that.

In the meantime, if you are willing to also add a test to the test in 
the submission app, send me a patch directly and I'll deal with 
wrangling the tool.

RjS

>
> On Mon, Dec 7, 2020 at 2:56 PM Richard Barnes 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     2. Related:
>     https://twitter.com/mikewest/status/1335857840028790784
>     On Mon, Dec 7, 2020 at 12:00 PM Robert Sparks
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Please report datatracker.ietf.org
>         <http://datatracker.ietf.org> and mailarchive.ietf.org
>         <http://mailarchive.ietf.org>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Dec 2020 15:26:39 -0500

Sorry if the "proper" language is a bit sharp.  The point is that I would
have to google "how to install SVN", "how to clone an SVN repo", "how to
generate a patch from SVN", ... and it would take hours longer than it
ought to.  Not worth it for a volunteer, drive-by contribution.  And if I,
a crusty old-timer, am deterred...

To be clear, I know that there are reasons and I know some work is being
done.  But it's still important to name the problem, at the very least to
highlight the importance and urgency of getting that work done.

--RLB

On Mon, Dec 7, 2020 at 3:15 PM Robert Sparks <[email-masked]> wrote:

> The older subversion repository _is_ a proper repository, and the codebase
> has a testsuite that is run through automated testing on commit.
>
> the level of interaction required to get to the point where you can commit
> to a branch. I'm working on addressing that.
>
> In the meantime, if you are willing to also add a test to the test in the
> submission app, send me a patch directly and I'll deal with wrangling the
> tool.
>
> RjS
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Dec 2020 20:41:05 +0000

*   Sorry if the "proper" language is a bit sharp.  The point is that I would have to google "how to install SVN", "how to clone an SVN repo", "how to generate a patch from SVN", ... and it would take hours longer than it ought to.  Not worth it for a volunteer, drive-by contribution.  And if I, a crusty old-timer, am deterred...

A couple of points.  First, tools.ietf.org is not behind a CDN.  Whether or not it should be is a separate question.  But the rationale for requiring a login now makes sense. Second, the tools community is small and has years of source control and workflow experience.  It’s not clear that moving to Git is worth much, even if it means putting in a slight barrier to contributions from others.

I don’t consider your language to be sharp, but rather coming from a place of ignorance.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Dec 2020 12:49:41 -0800

On Mon, Dec 7, 2020 at 12:41 PM Salz, Rich <rsalz=
[email-masked]> wrote:

>
>    - Sorry if the "proper" language is a bit sharp.  The point is that I
>    would have to google "how to install SVN", "how to clone an SVN repo", "how
>    to generate a patch from SVN", ... and it would take hours longer than it
> A couple of points.  First, tools.ietf.org is not behind a CDN.  Whether
> or not it should be is a separate question.
>

I don't think we should be in a position where we need to require login for
access to non-sensitive static data. There are a number of solutions to
this problem, so I think that the question of a CDN or not is probably the
wrong level of abstraction to be discussing.

  But the rationale for requiring a login now makes sense. Second, the
> tools community is small and has years of source control and workflow
> experience.  It’s not clear that moving to Git is worth much, even if it
> means putting in a slight barrier to contributions from others.
>
>
>

The point that I take Richard to be making -- which I agree with -- is that
part of the reason for that community being small is a workflow that
creates barriers to entry for small contributions. FWIW, it's not just him.
I recently found a minor defect in xml2rfc [0] which I probably could have
fixed quickly, but then I looked at the overhead involved and decided IO
had better things to do.

-Ekr

[0] https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/575

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Dec 2020 21:02:02 +0000

I guess my key point is that I don’t think SVN->GIT should be the most important priority of the team.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 7 Dec 2020 16:25:38 -0500

> On Dec 7, 2020, at 4:02 PM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

I appreciate the dedication the tools team puts into the infrastructure. I couldn’t have written my mobile app without their help and support. But they do seem to be spread thin.

There will always be another version control system out there that is better than the last one that was better than the last one (see pijul), but I think the workflow is probably even more important.

The reason people like github is how easy it is to contribute. You can identify a problem, you can submit a fix, you can see how the tests run on your proposed fix, you can see the other contributors and have a conversation about a fix, you can fork and try some new ideas, etc.

This isn’t about SVN->GIT.  Trac is woefully inadequate at this point.

Tom

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 17:01:34 -0500

>fixed quickly, but then I looked at the overhead involved and decided IO

I have to agree. I've been using source control since SCCS and RCS and
my brain just isn't big enough to remember umpteen different source
control systems, particularly ones I almost never use. For whatever
reason git has won the battle and it would be a good idea for us to
figure out how to move there. Dunno if it'd be github or a locally
hosted gitlab or something else but that's a detail.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Dec 2020 23:46:31 +0100

git svn is your friend :-)

I used to co-chair a WG that was very slow moving from SVN to git for some of its older documents, and I think it was good that we took our time, but it also was good when we finally had finished converting to git.

But more generally, I apologize for having brought up the author detection issue.

(I would love if I could bring up issues here with less fear of the discussion degenerating.)

And thanks Robert for pointing out that this happens for TXT submissions and pointing to the place to fix.

I don’t think I had run into this before -- we have mostly switched to XML submissions; this draft was submitted by a recently recruited editor without much help from the old-timers.

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Dec 2020 12:58:50 +0100

Responding to the last post in the thread that was on-subject:

A long time ago, as it seems now; probably a year or so, I actually
went to the regex in question and considered updating it; but then I
decided that as a general principle, I was _not_ going to spend too
much time making the legacy submission paths equivalent to the XML
paths with respect to unicode support.

This was an intentional choice of working to make the XML features,
and in particular the v3 schema features, more capable in general,
without worrying too much about the legacy code paths, in order to
entice people to move forwards.

This is also the reason why submitting an XML v3 schema draft will
trigger generation of a HTML rendering, while a v2 XML submission
will not.  It would have been possible to generate the old flawed
v2 HTML output; it would also have been possible to do a v2-v3 conversion
and generate a v3 HTML output (with the chance that the HTML would not
match the .txt due to conversion issues), but neither seemed obviously
right.  So again the choice was to not spend time on the legacy code
paths, but instead present a small advantage to those who move forward
to use the XML v3 schema.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Dec 2020 13:01:41 +0100

On 2020-12-08, at 12:58, Henrik Levkowetz <[email-masked]> wrote:
> _not_ going to spend too

Is .TXT submission legacy?
I was thinking that will be available in the indefinite future.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Tue, 8 Dec 2020 13:03:35 +0100

Am 08.12.2020 um 12:58 schrieb Henrik Levkowetz:
> ...

FWIW (and looking how complex the existing code for plain text already
is): that seems to be the right approch to me.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Dec 2020 13:09:45 +0100

> I was thinking that will be available in the indefinite future.

I expect so, too.  But it's never had unicode support, and until recently
not needed it.  With not enough hours to do everything that's wanted,
something has to get second priority.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Dec 2020 14:08:53 +0100

> <https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/utils/draft.py#L511>

My Python-fu is not strong, and all Web resources I can find are terminally confused about Python 2 vs. Python 3.

Is my assumption correct that mechanically substituting

\p{L}  for A-Za-z
and then
\p{Lu} for A-Z

in the function extract_authors should solve this problem?

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Dec 2020 14:21:50 +0100

Hi Carsten,

> in the function extract_authors should solve this problem?

No.  This is the reference for the 're' (regular expression) library that
comes with a python installation:

	https://docs.python.org/3.6/library/re.html

In order to use \p{L} and \p{Lu} the code also has to be changed to use
the external 'regex' module.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Dec 2020 15:18:23 +0100

Hi Henrik,

> On 2020-12-08, at 14:21, Henrik Levkowetz <[email-masked]> wrote:
> 

Thanks, I didn’t know that.
I thought I knew a bit about regexes and their support in various platforms;
I’m seriously stunned.

So, would adding a mechanical substitution of

regex.  for  re.

within extract_authors (plus adding the import) to the set I gave solve the problem?

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Dec 2020 15:52:05 +0100

Hi Carsten,

> within extract_authors (plus adding the import) to the set I gave

Probably, yes; but one would want to run a comprehensive test round to
be sure that there are no side effects of the change.

	Henrik

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2020 20:30:06 -0500

>I was thinking that will be available in the indefinite future.

It's not going away but we're going to give people much stronger hints
to submit XML if you have it.

In Jay's recent survey, a remarkable number of people said they edit
in markdown or directly in XML, then render into text and submit that.
Huh?

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Dec 2020 19:28:51 -0800

I wonder if this is just habit. I used to submit .txt and then I started
submitting .txt and .txml and now I usually submit .xml -- though note that
the latter is slower because it needs to generate the .txt. Perhaps some
gentle nudging through the UI would help?

-Ekr

---

From: Jay Daley <[email-masked]>
Date: Wed, 9 Dec 2020 16:33:03 +1300

> On 9/12/2020, at 4:29 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> I wonder if this is just habit. I used to submit .txt and then I started submitting .txt and .txml and now I usually submit .xml -- though note that the latter is slower because it needs to generate the .txt. Perhaps some gentle nudging through the UI would help?

Yes indeed! -  that’s exactly what we’re discussing. John and I are part way through writing up an analysis of the survey results and what responses might be appropriate. 

(sent from my phone)

-- 
Jay Daley
IETF Executive Director
+64 21 678840

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Dec 2020 22:33:53 -0500

> in markdown or directly in XML, then render into text and submit that.

My XML has lots of internal comments, candidate / scratch text, etc.;
it's not always ready for sharing...
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Jay Daley <[email-masked]>
Date: Wed, 9 Dec 2020 16:48:03 +1300

> On 9/12/2020, at 4:34 PM, Warren Kumari <[email-masked]> wrote:
> 

So I’m clear - are those comments etc stripped out automatically in the conversion to TXT or do you do it by hand?

(sent from my phone)

-- 
Jay Daley
IETF Executive Director
+64 21 678840

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Dec 2020 23:05:53 -0500

On Tue, Dec 8, 2020 at 10:48 PM Jay Daley <[email-masked]> wrote:

> So I’m clear - are those comments etc stripped out automatically in the
> conversion to TXT or do you do it by hand?
>
> (sent from my phone)

Stripped out when converting. I also run xml2rfc to confirm that the XML is
correct, and so just submit the text version. I *do* send the XML to the
RFC Ed once all approved though...

W

Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

---

From: "John R Levine" <[email-masked]>
Date: 8 Dec 2020 23:28:24 -0500

> gentle nudging through the UI would help?

Jay and I had the same thought.  In fact you need only submit one of txt 
or xml but the submission web site wouldn't lead you to assume that.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Dec 2020 06:24:14 +0100

> On 2020-12-08, at 15:52, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Carsten,
> 

Indeed.  (A feature that doesn’t have tests doesn’t exist.)
Doing that (and writing some additional tests for beyond-ASCII author/org names) sounds like a great little Codesprint project.

Grüße, Carsten

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Dec 2020 14:33:44 +0000

> it's not always ready for sharing...

Do we know of anyone else who does this?  My inclination is to say that this is not a workflow that should be prioritized.

---

From: "John R Levine" <[email-masked]>
Date: 9 Dec 2020 09:45:07 -0500

> Do we know of anyone else who does this?  My inclination is to say that this is not a workflow that should be prioritized.

Agreed.  In this rather odd case it'd be OK to send txt until the 
embarassing comments are edited out and then send the XML.

At this point we're interested in what the RPC gets once the document is 
thrown over the wall for publication.

Regards,

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 09 Dec 2020 06:51:56 -0800

On 9 Dec 2020, at 6:33, Salz, Rich wrote:

> Do we know of anyone else who does this?  My inclination is to say 
> that this is not a workflow that should be prioritized.

I absolutely do this, and I know that others do as well. Near the top of 
my XML is often a list of things yet to do, sometimes with snarky 
comments. There are sometimes comments in the middle of the doc with 
<!-- ##### do this ##### -->.

Having said that, I agree with Rich that we should not prioritize for 
that case. It would still be better for people to submit XML, and those 
of us who want to hide comments might need to take an extra tooling step 
to remove it from temporary XML that we submit.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Dec 2020 07:48:27 -0800

On Wed, Dec 9, 2020 at 6:52 AM Paul Hoffman <[email-masked]> wrote:

> Do we know of anyone else who does this?  My inclination is to say that
> this is not a workflow that should be prioritized.
>
> my XML is often a list of things yet to do, sometimes with snarky comments.
> There are sometimes comments in the middle of the doc with <!-- ##### do
> this ##### -->.
>
> Having said that, I agree with Rich that we should not prioritize for that
> case. It would still be better for people to submit XML, and those of us
> who want to hide comments might need to take an extra tooling step to
> remove it from temporary XML that we submit.
>
I used to leave comments in my docs when I worked in XML but my documents
are generally in some kind of open source code repo, so I expected the
comments to be public even if I (lazily) submitted txt. So, my sense is
this is a niche workflow.

-Ekr

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Dec 2020 17:27:56 +0100

On 2020-12-09, at 15:45, John R Levine <[email-masked]> wrote:
> 
> At this point we're interested in what the RPC gets once the document is thrown over the wall for publication.

Some of us.

Some of us are actually very interested in what happens to an I-D during its long journey through the system.  The RFC editor queue is one high-activity step at the end that we have to get right, but the overall quality of the IETF’s output highly depends on a productive I-D-stage process(*).

I believe that, now that the worst parts of the V3 transition are over at the RPC side, we slowly need to direct more of our attention to that aspect as well.

Grüße, Carsten

(*) Obviously, that was what Marshal Rose and the cast of thousands had in mind for RFC 2629.  That aspect has never been neglected, but the RPC needs of course dominated them during the transition.  Time to re-focus.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 9 Dec 2020 18:28:11 +0100

On 2020-12-09 17:27, Carsten Bormann wrote:
>> At this point we're interested in what the RPC gets once the
>> document is thrown over the wall for publication.
> 
> Some of us.
> 
> Some of us are actually very interested in what happens to an I-D
> during its long journey through the system.  The RFC editor queue is
> one high-activity step at the end that we have to get right, but the
> overall quality of the IETF’s output highly depends on a productive
> I-D-stage process(*).
> 
> I believe that, now that the worst parts of the V3 transition are
> over at the RPC side, we slowly need to direct more of our attention
> to that aspect as well.

I strongly agree.

> Grüße, Carsten
> 
> (*) Obviously, that was what Marshal Rose and the cast of thousands
> had in mind for RFC 2629.  That aspect has never been neglected, but
> the RPC needs of course dominated them during the transition.  Time
> to re-focus.

Ditto.

	Henrik

---

From: Bob Hinden <[email-masked]>
Date: Wed, 9 Dec 2020 09:43:17 -0800

> On Dec 8, 2020, at 8:28 PM, John R Levine <[email-masked]> wrote:
> 
> Jay and I had the same thought.  In fact you need only submit one of txt or xml but the submission web site wouldn't lead you to assume that.

I have gotten into the habit of submitting the XML and TXT.   I do usually have things commented out, but nothing I wouldn’t want to be public :-)

Bob

---

From: "John R Levine" <[email-masked]>
Date: 9 Dec 2020 12:55:12 -0500

> I believe that, now that the worst parts of the V3 transition are over at the RPC side, we slowly need to direct more of our attention to that aspect as well.

I agree but I am trying to drain the swamp one polder at a time.  I'm 
starting by trying to get good quality v3 drafts to the RPC, and we can 
work backward from there.

Regards,