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

[Joel Halpern <[e-mail]>]

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.

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 fromrfc-editor.org
>>         <http://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 <http://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 <http://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]
>
>