Re: [Tools-discuss] [Rswg] Single source throughout. (Was creating bis docs automatically)

[Eric Rescorla <[e-mail]>]

On Mon, Mar 6, 2023 at 7:23 AM Joel Halpern <[e-mail]> wrote:

> On the question of disagreement between RPC and Authors, note that both
> sides have authority.  The RPC is the publisher.  And if they conclude
> something is just wrong, they can refuse to publish it as-is.  The authors
> can also kick up a fuss if they disagree.  But remember that if the
> document is a working group document, the authors are not "authors".  They
> are editors responsible for producing what the WG has agreed to.  As I
> understand it, the basis for heir authority in auth48 is essentially "that
> is not what the WG / IETF agreed to" rather than "that is not what I
> want."  Yes, some authors do not understand that.  And the RPC goes to
> great lengths to cooperate with authors over such things.  But in the end,
> our current authority structure resides with the RPC for document
> publishing.  And I for one like it that way.
>
[Again, speaking purely as an individual.]

I think we're getting perhaps a little off topic here, and I agree with
much of what you say above,,
but I don't think I quite agree with your penultimate sentence.
Specifically, I don't think that the
RPC is empowered to publish documents without the approval of the stream
managers, so at
 the end of the day, the authority to publish a given document is shared
between those two
groups.

-Ekr



Yours,
>
> Joel
> On 3/6/2023 10:09 AM, Eric Rescorla wrote:
>
> [Since we are now in RSWG, noting that I am speaking as an individual.]
>
> On Mon, Mar 6, 2023 at 6:56 AM Jay Daley <[e-mail]> wrote:
>
>> Adding in RSWG.
>>
>> On 4 Mar 2023, at 14:54, Eric Rescorla <[e-mail]> wrote:
>>
>> In that vein, I think that we should recognize that traditional
>> publishing is an activity organized
>> for the convenience of the publishers, not for the authors. However, in
>> this case, what we have
>> is more akin to self-publishing, with the RPC being more like a contract
>> publisher, and so matters
>> ought to be arranged for the convenience of the customer, which is to say
>> the IETF, IAB,
>> ISE, etc. That is, of course, not the end of the analysis, but suggests
>> that the question of how
>> things usually happen is not the right test.
>>
>>
>> While there are many who agree with you, a not insignificant proportion
>> of the community consider the RFC Series as somewhat independent and that
>> the RPC is there to serve the series not the current "customers".
>>
>
> Without getting into this question, these process matters seem to be
> precisely those
> on which the streams have the strongest ground to have opinions.
>
>
> To put my point another way - the current working practices assume an
>> implicit model for the editorial/publishing function, which I suspect has a
>> strong foundation in the history of the series.  Some proposed changes to
>> the working practices will inevitably lead to questions about what that
>> means for the model.  For example, if we have a single canonical source
>> controlled by the authors does that mean that they now have to give
>> permission for every change the RPC wants to make and do we now have to see
>> the stream managers adjudicating every disagreement?
>>
>
> This is the way it is now in AUTH48, because the authors need to sign off
> on the
> document.
>
>
>>
>> Some might think that a document can basically re-enter the authoring
>>> phase when someone chooses to write a -bis but again it’s our model that
>>> sets the structure here. Our model does not have versions of RFCs and so
>>> writing a -bis is starting a new document and a new source history, not
>>> continuing the previous one.
>>>
>>
>> Much could be said about books, and yet, as noted above, in many book
>> publishing workflows,
>> the author is left with a copy of the corrected manuscript.
>>
>>
>> I don’t think there is any suggestion that they can’t get that. The
>> discussion as I understood it was about a single draft-to-publication
>> source history. If all the authors wanted was the equivalent of a corrected
>> manuscript then they could clone the RPC repository and go from there.
>>
>
> Putting "clone" aside, the question is whether the output of the RPC
> process is suitable
> for trivially reinserting into the draft preparation process. And the
> point is that it's not
> for those who work in non-XML formats, as they must backport the changes.
>
> -Ekr
>
>
>> Jay
>>
>>
>> -Ekr
>>
>>
>>> Sure, I understand that there is a modern alternative model for
>>> developing technical standards of living documents, no separate publication
>>> role/phase, and a single start-to-finish source history, but what we do is
>>> quite different.
>>>
>>> Jay
>>>
>>> --
>>> Jay Daley
>>> IETF Executive Director
>>> >
>>> > Cheers,
>>> > Martin
>>> >
>>> > [1]  A particularly challenging one, as it turns out.  The breadth of
>>> changes the RPC makes does tend to be quite hard to track.  But it
>>> generally only takes a few hours, even on a very long document.
>>> >
>>> >> On Sat, Mar 4, 2023, at 07:36, Jean Mahoney wrote:
>>> >> Just thinking out loud -- I think it would helpful for author-tools to
>>>
>>> >> provide an option of starting a bis doc.
>>> >>
>>> >> On author-tools, an author could enter the number of the RFC they want
>>>
>>> >> to create a bis draft for, provide a draftname for it, and select a
>>> file
>>> >> format (XML or markdown). author-tools (or whatever is behind the
>>> >> curtain) would then fetch the RFC file from rfc-editor.org, do the
>>> >> necessary updates (e.g., removing the RFC number), and make a file
>>> >> available for download.
>>> >>
>>> >> I've created an enhancement request:
>>> >> https://github.com/ietf-tools/ietf-at-ui/issues/152
>>> >>
>>> >> Thanks!
>>> >> Jean
>>> >>
>>> >>
>>> >>> On 3/3/23 2:07 PM, Jean Mahoney wrote:
>>> >>> Hi Paul,
>>> >>>
>>> >>> On 3/3/23 12:58 PM, Paul Hoffman wrote:
>>> >>>> On 3 Mar 2023, at 10:54, Jean Mahoney wrote:
>>> >>>>
>>> >>>>> Converting the file to v3 will remove the warning about
>>> >>>>> rfc2629-xhtml.ent the next time you run xml2rfc. You don't have to
>>>
>>> >>>>> make any changes to the file before uploading it to
>>> >>>>> author-tools.ietf.org to convert it.
>>> >>>> OK, this is useful. I propose that when authors ask the RPC for the
>>>
>>> >>>> last XML because they're making a -bis, that this be suggested to
>>> them.
>>> >>> [JM] authors.ietf.org could also provide more info, then the RPC
>>> could
>>> >>> provide a pointer to it. I created an issue:
>>> >>> https://github.com/ietf/authors.ietf.org/issues/56
>>> >>>
>>> >>> Thanks!
>>> >>> Jean
>>> >>>
>>> >>>>
>>> >>>> I can handle this easily from here.
>>> >>>>
>>> >>>> --Paul Hoffman
>>> >>>>
>>> >>>
>>> >>> ___________________________________________________________
>>> >>> Tools-discuss mailing list - [e-mail] -
>>> >>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>> >>>
>>> >>
>>> >> ___________________________________________________________
>>> >> Tools-discuss mailing list - [e-mail] -
>>> >> https://www.ietf.org/mailman/listinfo/tools-discuss
>>> >
>>> > ___________________________________________________________
>>> > Tools-discuss mailing list - [e-mail] -
>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>>
>>> ___________________________________________________________
>>> Tools-discuss mailing list - [e-mail] -
>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>
>>
>> --
>> Jay Daley
>> IETF Executive Director
>> [e-mail]
>>
>>
>