Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-05-09 Thread Lars Eggert
Hi,

On 2022-4-29, at 13:54, Lars Eggert  wrote:
> the IESG is reviewing what has happened.

the IESG discussed this issue. Below is my personal attempt to summarize the 
outcome of this discussion.

We believe that it is permissible under the current rules to include sections 
of text that others have contributed to the IETF standards process - even 
extensive sections of text, as in this case - in a new IETF contribution.

However, we also believe that it is customary to at least acknowledge the 
source of any such copied material, or better, to reach out to inquire whether 
the original authors would like to be involved in a planned derivative of their 
original contribution.

We discussed whether any additional process or tooling was needed, and 
concluded that such instances are rare enough that the delays and overheads 
associated with new measures would be counterproductive overall.

Thanks,
Lars



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-05-03 Thread Stephan Wenger
Hi,

Adding the Trustees.

Speaking as one of the Trustees but not necessarily for the IETF Trust, I don't 
think the IETF Trust has anything to do here.  The IETF may.

What I write INLINE below is written as an analysis of the situation from an 
IETF Trustees viewpoint, and a legalistic viewpoint at that.  To summarize the 
many letters down there, I believe nothing legally wrong happened, and the 
trust has nothing to do in this case or towards similar cases.

Taking off my Trustee hat and getting into the shoes of someone who has spent 
time and energy writing something up, just to watch his name to disappear, I 
don't believe what happened was "right" even if it was legal.  The problem is 
not copyright law or copyright notices, the problem is proper attribution of 
work that was performed by someone else.  Remedies are obviously available, 
circling around proper attribution of substantially all the -00 text to Mukund 
and the other authors of the initial text.  In the order of cleanliness:

1. The perhaps cleanest way would be to follow most SDO policies and remove any 
attribution to individuals.  However, that's not going to fly here in the IETF.

2. The IETF, in my opinion unwisely, decided a long time ago to limit the 
number of listed authors to five, relying on "editors" in the authors' field of 
the I/D/RFC front page and an contributors/acknowledgement section.  That's 
neither fish nor meat when it comes to proper attribution, as many folks, often 
from the academic field, have complained before.  Changing this policy back to 
where it was before 2000 (where an I-D or RFC could have as many listed authors 
as appropriate from a contributing viewpoint) may be the cleanest way forward 
without boiling the ocean, even if in some cases the first page of an RFC would 
basically be an author's list.  However, that's a policy change that would take 
time to make.  Also, the original arguments for limiting the number of listed 
authors on the front page are still around, hence the fate of such a proposal 
would be unclear.  In any case, we have a real problem NOW, which (I guess) 
cannot wait for IETF policy work.

3. I believe that the I-D and RFC editors can make exceptions from the 
five-listed-author policy in justified cases.  Given the controversy at hand, 
this may well be such a justified case.  One justification is Mukund's 
justified (I believe) complaint.  The other is that if his allegations are 
correct, the copyright notice we have today may be unusable for its intended 
purpose.

4. As a last resort, many I-Ds and RFCs include an acknowledgement section, 
which is free form.  Proper acknowledgement to the predecessor draft and its 
authors (including calling them authors and not contributors or something), 
would IMO make the copyright notice stick to them.  Whether that's also an 
adequate attribution, and remedy form Mukund's et. al. viewpoint is, of course, 
for them to decide.

Mukund seems to be aware of most or all of these options, and I hope that a 
pragmatic way out here will be ultimately found.

Assuming Mukund's claim that he and his original co-authors indeed have 
authored most of the text in question and hence may own the copyright (I 
haven't verified that but have no reason to doubt it either, based on the email 
conversation), the current copyright message would likely be rejected by the US 
copyright office if we were trying to register the copyright, which in practice 
is a requirement before enforcing the copyright.   Insofar, I would recommend 
that the eth current authors and/or the WG take action, preferably using 
mechanism 3) above, or if the pushback is too bad, mechanism 4.  

I kicked around the idea of a change in the boilerplate that could adequately 
address this problem (as suggested by Brian) but couldn't come up with one that 
would work.  If interested, please see inline below for details why I think 
nothing was legally wrong, the Trust has nothing to do, and why I don't believe 
a change to the boilerplate copyright notice can be made that addresses the 
problem of non-listed authors.

Stephan


On 5/2/22, 07:04, "ietf on behalf of Brian E Carpenter"  wrote:

[...]
> The copyright notice on the document says:
> 
> Copyright (c) 2022 IETF Trust and the persons identified as the
> document authors.  All rights reserved.
> 
> By way of this, by removing the names of authors, isn't the copyright
> notice attributed to the (original) document authors also being removed?

I am not a lawyer, but I believe it's true that *nobody* can remove the
original authors' copyright (although the details might differ in each
country's laws). 

That is my understanding as well.  Beyond that, the IETF and IETF' Trust's 
legal framework is designed such that authors retain full rights to their work, 
with the exception of the license they grant to the IETF trust.  That's by 
design, and it's different from many other 

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-05-01 Thread Michael StJohns

In line:

On 5/1/2022 1:41 PM, John Levine wrote:

It appears that Mukund Sivaraman   said:

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

By way of this, by removing the names of authors, isn't the copyright
notice attributed to the (original) document authors also being removed?

Clearly the text is not copyright of the new authors in this document: ...


Actually, a derivative work (term of art) has a copyright that is 
distinct from the work from which it is derived.  In this case, the 
authors of the document are the authors for the purposes of copyright 
for the text in the document - regardless of where the text originates, 
and with the caveat for derivative works, that there is an appropriate 
license associated with the original work that allows for derivative 
works.  I could take the original document, change one word and the 
authors, publish it as an ID and, as long as I follow the license terms 
for derivative works, would be considered the author for copyright 
purposes of the new document.



Hi, trustee of the IETF Trust here. With rare exceptions that don't apply here,
when anyone submits an I-D or publishes an RFC, they grant a permanent license
to let anyone use the material in later drafts or RFCs in the IETF process.
There is no requirement for attribution or notice. We made that decision
deliberately, so that new drafts and RFCs can build on old ones. It also happens
that due to a treaty called the Berne Convention, the copyright notice on a
document no longer has any legal meaning at all.


And that's where the license comes in.  For the referenced documents, 
unless the boilerplate explicitly disclaims the right to produce 
derivative works, anyone who wants can do so - as part of the IETF 
process.  So while I could publish an ID as above, I couldn't file off 
the serial numbers completely (i.e., submit this an original work in 
some space other than the IETF).




While taking someone else's draft and putting your name on it as another draft
is legal, that's not the question here. It's whether it's ethical and something
we want to encourage. My impression is that in this case it was a
misunderstanding and I hope it will be sorted out shortly.


The language of the license reads in part "Copyright (c) 2015 IETF Trust 
and persons identified as the document authors." There may be good - 
legal related - reasons to take off authors who didn't participate in 
the current document and remove them to an Acknowledgement section.  
IANAL, but I wonder not only about rights conferred by a copyright, but 
whether there are also responsibilities that someone may want to 
disclaim or at least explicitly agree to upon publication?


I expect that the IETF is going to have to make a "policy" to cover this.

Later, Mike



R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-05-01 Thread John Levine
It appears that Mukund Sivaraman   said:
>   Copyright (c) 2022 IETF Trust and the persons identified as the
>   document authors.  All rights reserved.
>
>By way of this, by removing the names of authors, isn't the copyright
>notice attributed to the (original) document authors also being removed?
>
>Clearly the text is not copyright of the new authors in this document: ...

Hi, trustee of the IETF Trust here. With rare exceptions that don't apply here,
when anyone submits an I-D or publishes an RFC, they grant a permanent license
to let anyone use the material in later drafts or RFCs in the IETF process.
There is no requirement for attribution or notice. We made that decision
deliberately, so that new drafts and RFCs can build on old ones. It also happens
that due to a treaty called the Berne Convention, the copyright notice on a
document no longer has any legal meaning at all.

While taking someone else's draft and putting your name on it as another draft
is legal, that's not the question here. It's whether it's ethical and something
we want to encourage. My impression is that in this case it was a
misunderstanding and I hope it will be sorted out shortly.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-05-01 Thread Mukund Sivaraman
Hi Brian

On Sun, May 01, 2022 at 02:11:11PM +1200, Brian E Carpenter wrote:
[snip]
> > The copyright notice on the document says:
> > 
> > Copyright (c) 2022 IETF Trust and the persons identified as the
> > document authors.  All rights reserved.
> > 
> > By way of this, by removing the names of authors, isn't the copyright
> > notice attributed to the (original) document authors also being removed?
> 
> I am not a lawyer, but I believe it's true that *nobody* can remove the
> original authors' copyright (although the details might differ in each
> country's laws). However, the point here is that when an IETF I-D is
> submitted, it is done so under the IETF's conditions, including the
> IETF's right to produce "derivative works". The details are in BCP98
> (RFC5378) and in the IETF Trust's Legal Provisions, but basically it
> means that the text can be re-used in future IETF drafts and RFCs.

The permission to modify and/or redistribute is not being
questioned. It's the removal of authors, and what appears to be removal
of copyright attribution also. Your draft's text sounds reasonable on
this topic.

> > Clearly the text is not copyright of the new authors in this document:
> 
> I wonder if the conventional sentence "Copyright (c) 2022 IETF Trust and
> the persons identified as the document authors" needs to be tuned to
> also cover previous authors when the authorship team for a draft changes?
> But that question is for the IETF Trust and its lawyer.

Nod, this has to be examined.

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Mukund Sivaraman
On Fri, Apr 29, 2022 at 10:54:13PM +0200, Benno Overeinder wrote:
> Mukund,
> 
> On 29/04/2022 22:27, Mukund Sivaraman wrote:
> > > 
> > > This is indeed how the DNSOP chairs see it and have guided the (new set 
> > > of)
> > > authors in this way.  We have also asked Haisheng to contact the 
> > > secretariat
> > > to correct the situation as we cannot withdraw individual drafts or change
> > > status.
> > 
> > With the way this is worded, is it accepted practice for the names of
> > authors of a document to be removed to make way for another set of
> > authors?
> 
> No, certainly not.  If you interpret it that way, I have chosen the wrong
> words.
> 
> What I meant to say is that we made suggestions or try to guide the
> practical procedure for changing the status of document to indicate that it
> is not an active document.

OK, I think I have misunderstood the last 2 emails in this thread.

> The broader discussion of whether it is an accepted practice or not was not
> the subject of my answer to the list.  As I understand there is a discussion
> in the IESG now, and with the email thread on the list and Brian's draft,
> https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02, we
> can make progress to better define the process and provide guidance to
> authors and IETF participants.

That sounds good. I browsed through Carpenter's draft. Section 7 in it
is about how to fork (which is welcome), and it sounds reasonable.

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Benno Overeinder

Mukund,

On 29/04/2022 22:27, Mukund Sivaraman wrote:


This is indeed how the DNSOP chairs see it and have guided the (new set of)
authors in this way.  We have also asked Haisheng to contact the secretariat
to correct the situation as we cannot withdraw individual drafts or change
status.


With the way this is worded, is it accepted practice for the names of
authors of a document to be removed to make way for another set of
authors?


No, certainly not.  If you interpret it that way, I have chosen the 
wrong words.


What I meant to say is that we made suggestions or try to guide the 
practical procedure for changing the status of document to indicate that 
it is not an active document.


The broader discussion of whether it is an accepted practice or not was 
not the subject of my answer to the list.  As I understand there is a 
discussion in the IESG now, and with the email thread on the list and 
Brian's draft, 
https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02, we 
can make progress to better define the process and provide guidance to 
authors and IETF participants.



-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Mukund Sivaraman
On Fri, Apr 29, 2022 at 10:05:10PM +0200, Benno Overeinder wrote:
> Hi Lars, WG,
> 
> On 29/04/2022 12:54, Lars Eggert wrote:
> > On 2022-4-29, at 0:30, Cindy Morgan  wrote:
> > > The rest of this is a bit of a tangle, and I've referred it to the IESG 
> > > for further guidance on what steps the Secretariat should take next.
> > 
> > the IESG is reviewing what has happened.
> > 
> > (My personal first impression is that this might be a case where a 
> > contributor intended to revive an expired document by a different set of 
> > authors, and was unsure how to best go about this.)
> 
> This is indeed how the DNSOP chairs see it and have guided the (new set of)
> authors in this way.  We have also asked Haisheng to contact the secretariat
> to correct the situation as we cannot withdraw individual drafts or change
> status.

With the way this is worded, is it accepted practice for the names of
authors of a document to be removed to make way for another set of
authors?

The fact that the document is expired or not is a different matter.

The copyright notice on the document says:

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

By way of this, by removing the names of authors, isn't the copyright
notice attributed to the (original) document authors also being removed?

Clearly the text is not copyright of the new authors in this document:

https://www.ietf.org/archive/id/draft-hsyu-message-fragments-00.txt

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Benno Overeinder

Hi Lars, WG,

On 29/04/2022 12:54, Lars Eggert wrote:

On 2022-4-29, at 0:30, Cindy Morgan  wrote:

The rest of this is a bit of a tangle, and I've referred it to the IESG for 
further guidance on what steps the Secretariat should take next.


the IESG is reviewing what has happened.

(My personal first impression is that this might be a case where a contributor 
intended to revive an expired document by a different set of authors, and was 
unsure how to best go about this.)


This is indeed how the DNSOP chairs see it and have guided the (new set 
of) authors in this way.  We have also asked Haisheng to contact the 
secretariat to correct the situation as we cannot withdraw individual 
drafts or change status.



Regards,

--  Benno
DNSOP co-chair

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Johnson







Hi, Mukund,         This is Johnson, I'm very sorry to cause you so much trouble.                   I think the draft of draft-muks-dns-message-fragments that you submitted to the IETF is quite interesting and shows the importance of dns packet fragmentation in the DNS query process. It's a pity to see that this draft has expired. I want to see if it can be reactivated in the working group. Push the work forward and maybe it will become an RFC.                  Linjian Song and Shane Kerr are both my former colleagues.  I talked to them all about this draft and got some of their suggestions for it.              Here's Shane Kerr's thoughts on this draft, which I think is a good suggestion.          “I think it probably makes more sense to understand the behavior of DNS over QUIC:             https://blog.apnic.net/2022/03/29/a-first-look-at-dns-over-quic/              It should resolve the fragmentation issue, as well as working through most middleboxes, and providing authentication and encryption.”         Because I haven't contacted you before, and the draft was accidentally submitted by me, I asked Benno Overeinder to revoke the draft I submitted. But because this is a an individual submission, Benno Overeinder can't revoke the draft.  So I try to submit a draft to cover the previous drafts.          I'm very sorry for causing so much trouble to you because of my mistakes.  I hope we can keep this work going together.          Haisheng Yu (Johnson)









 


Haisheng Yu(Johnson)h...@biigroup.cn


 

On 4/29/2022 05:46,Mukund Sivaraman wrote: 


Hi CindyOn Thu, Apr 28, 2022 at 02:30:07PM -0700, Cindy Morgan wrote: Hi Mukand,  When the Secretariat got the request to review the replacement relationship suggested by haisheng yu, I checked and saw that "haisheng yu" was listed as an author on both draft-hsyu-message-fragments and draft-muks-dnsop-message-fragments, and so I approved the replaced-by information.  The rest of this is a bit of a tangle, and I've referred it to the IESG for further guidance on what steps the Secretariat should take next.Thank you for responding. I don't think you did anything wrong. You tookaction based on what was seen. This name change has taken a peculiartrail:(1) The original draft is "draft-muks-dns-message-fragments" (note the-dns- vs. -dnsop-) where "haisheng yu" is not an author. It is from2015-07-20.https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/(2) "draft-muks-dnsop-message-fragments" (the -dnsop- variant) wasuploaded on 2022-04-20. This lists "haisheng yu" as an additional authoralong with the old authors. Can you check who uploaded it? I didn't,although it contains the name "-muks-".https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/(3) The latest version was uploaded on 2022-04-28, which has removed theoriginal authors from the 2015-07-20 document.https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/		Mukund


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Lars Eggert
Hi,

On 2022-4-29, at 0:30, Cindy Morgan  wrote:
> The rest of this is a bit of a tangle, and I've referred it to the IESG for 
> further guidance on what steps the Secretariat should take next.

the IESG is reviewing what has happened.

(My personal first impression is that this might be a case where a contributor 
intended to revive an expired document by a different set of authors, and was 
unsure how to best go about this.)

Thanks,
Lars



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Mukund Sivaraman
Hi Haisheng Yu / Johnson

On Fri, Apr 29, 2022 at 11:05:34AM +0800, Haisheng Yu wrote:
>Hi, Mukund,
> This is Johnson, I'm very sorry to cause you so much trouble.
> 
> I think the draft of draft-muks-dns-message-fragments that you
>submitted to the IETF is quite interesting and shows the importance of
>dns packet fragmentation in the DNS query process. It's a pity to see
>that this draft has expired. I want to see if it can be reactivated in
>the working group. Push the work forward and maybe it will become an
>RFC.
> 
> Linjian Song and Shane Kerr are both my former colleagues.  I
>talked to them all about this draft and got some of their suggestions
>for it.
> 
> Here's Shane Kerr's thoughts on this draft, which I think is a
>good suggestion.
> “I think it probably makes more sense to understand the
>behavior of DNS over QUIC:
> 
>https://blog.apnic.net/2022/03/29/a-first-look-at-dns-over-quic/
>It should resolve the fragmentation issue, as well as
>working through most middleboxes, and providing authentication and
>encryption.”
> Because I haven't contacted you before, and the draft was
>accidentally submitted by me, I asked Benno Overeinder to revoke the
>draft I submitted. But because this is a an individual submission,
>Benno Overeinder can't revoke the draft.  So I try to submit a draft to
>cover the previous drafts.
> I'm very sorry for causing so much trouble to you because of
>my mistakes.  I hope we can keep this work going together.
> 
>Haisheng Yu (Johnson)

If the author names were removed and it was uploaded to the datatracker
accidentally, I take your word for it.

Internet drafts are asking for review and comments. In most cases, they
are meant to be changed over time until they reach a final satisfactory
form. Discussions usually happen in topic working groups so that
everyone interested in that topic can comment.

All the original authors of this draft have changed affiliation to
companies since the draft was written. If there are changes to be made,
you are welcome to join in. I suggest that you describe them or write
them as diffs and send them either to the dnsop@ mailing list for
comments, or to *all* the authors so we can review them and comment on
them. We'll discuss them, so please feel encouraged to do it.

If the changes are sufficiently large, existing authors would want to
add you as an author or even take over as the primary author if you
start to steer the document. You wouldn't even have to ask or make the
name changes yourself. Your participation should focus mainly on
improving the content.

I'll provide a story as an example. Several years ago, in the BIND team
we received numerous bug reports within a short period in the Response
Policy Zones (RPZ) implementation. It was indeed broken in several
ways. The implementation was magical at that time in that we didn't
fully understand how it worked. I looked for references and found an old
ISC technote (formatted very similar to an IETF internet draft) about
RPZ which was an early specification of the feature. The BIND code had
been updated to do other things though. The BIND ARM (manual) was
another reference, but it was very terse and not written as a
specification. Another source of RPZ documentation was a Zytrax DNS book
with numerous examples. It was clear that the technote was obsolete, and
because Evan Hunt and I were handling the RPZ bugs at that time, I
contacted Paul Vixie (the existing author) on whether I could update it
to match the BIND implementation. Paul responded that he would like to
shepherd it himself. The main reason was that RPZ had spawned an
industry with several parties dependent on a common standard of "RPZ
feeds" - the specification had to be carefully maintained (and of
course, documented). In the BIND project, we went about fixing bugs
using the existing code and whatever we could gather as
references. Brian Conry contributed numerous new system tests to check
things worked. Sometime later, Paul and Vernon Schryver updated and
published an internet draft on datatracker.ietf.org to update the RPZ
specification to match the BIND implementation. It eventually became
"draft-vixie-dnsop-dns-rpz".  I reviewed draft revisions against the
BIND implementation for correctness and provided a list of
changes. There was a RPZ BoF meeting which we attended in Seoul and
discussed ideas. The draft didn't become an RFC due to other reasons,
but I'm happy with the state of the draft in that it accurately
specifies RPZ.

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-28 Thread Mukund Sivaraman
Hi Cindy

On Thu, Apr 28, 2022 at 02:30:07PM -0700, Cindy Morgan wrote:
> Hi Mukand,
> 
> When the Secretariat got the request to review the replacement
> relationship suggested by haisheng yu, I checked and saw that
> "haisheng yu" was listed as an author on both
> draft-hsyu-message-fragments and draft-muks-dnsop-message-fragments,
> and so I approved the replaced-by information.
> 
> The rest of this is a bit of a tangle, and I've referred it to the
> IESG for further guidance on what steps the Secretariat should take
> next.

Thank you for responding. I don't think you did anything wrong. You took
action based on what was seen. This name change has taken a peculiar
trail:

(1) The original draft is "draft-muks-dns-message-fragments" (note the
-dns- vs. -dnsop-) where "haisheng yu" is not an author. It is from
2015-07-20.

https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/

(2) "draft-muks-dnsop-message-fragments" (the -dnsop- variant) was
uploaded on 2022-04-20. This lists "haisheng yu" as an additional author
along with the old authors. Can you check who uploaded it? I didn't,
although it contains the name "-muks-".

https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/

(3) The latest version was uploaded on 2022-04-28, which has removed the
original authors from the 2015-07-20 document.

https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-28 Thread Cindy Morgan
Hi Mukand,

When the Secretariat got the request to review the replacement relationship 
suggested by haisheng yu, I checked and saw that "haisheng yu" was listed as an 
author on both draft-hsyu-message-fragments and 
draft-muks-dnsop-message-fragments, and so I approved the replaced-by 
information. 

The rest of this is a bit of a tangle, and I've referred it to the IESG for 
further guidance on what steps the Secretariat should take next.

Best regards,
Cindy

> On Apr 28, 2022, at 12:05 PM, Mukund Sivaraman  wrote:
> 
> Hi Donald
> 
> On Thu, Apr 28, 2022 at 02:16:16PM -0400, Donald Eastlake wrote:
>> What you describe is completely improper but I'm not sure it's exactly
>> accurate. When you said you were "removed" as an author, I assumed that a
>> new revision of a draft was posted where you were a first page author for
>> version N but not listed as an author for version N+1. That would also be
>> improper if there was no effort to consult with you.
>> 
>> But what seems to have happened is that a new draft was created with you
>> omitted from the author list and (given the reference to Cindy Morgan in
>> the Subject line), the Secretariat was asked to record this new draft as
>> replacing the previous draft where you were an author (indeed, the first
>> listed author). I think this sort of thing is extremely rare. You could
>> certainly ask the Secretariat to reverse the database update so your draft (
>> https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/) is no
>> longer shown as being replaced by any other draft.
> 
> A new draft has been created, the contents of which are:
> 
> https://www.ietf.org/archive/id/draft-hsyu-message-fragments-00.txt
> 
> which is largely identical to the original [see diff below], but mainly
> authorship has been modified:
> 
> https://www.ietf.org/archive/id/draft-muks-dns-message-fragments-00.txt
> 
> The commit history of the contribution to the original draft is here:
> 
> https://github.com/muks/dnsfragments/commits/master
> 
> The draft appears to have gone from:
> 
> [2015-07-20] 
> https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/
> 
> (original draft)
> 
> to:
> 
> [2022-04-20] 
> https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/
> 
> (which included the new author " haisheng yu ", but kept the previous
> authors, but with no intimation to us)
> 
> to:
> 
> [2022-04-28] https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/
> 
> (which deleted the original authors)
> 
> It's not the mechanics, what the new name of the draft is, or what URI
> it is at. I am just disappointed we worked on making something and have
> disappeared from it, even if it is a copy of the text. It seems
> unreasonable, but all things considered (this is not the first time),
> I'll shake my head and move on.
> 
> I don't know if my expectation that authorship should be preserved is
> misplaced - maybe it is. We already co-assign copyright to the IETF.
> 
>   Mukund
> 
> 
> 
> The following is a diff between the two drafts to this email, to
> illustrate that mainly the authorship information has changed and the
> authors who wrote most of it have been removed.
> 
> 
> 
> 
> 5,10c5,8
> < Internet Engineering Task Force M. Sivaraman
> < Internet-Draft   Internet Systems Consortium
> < Intended status: ExperimentalS. Kerr
> < Expires: January 21, 2016L. Song
> <   Beijing Internet Institute
>  ---
>> Internet Engineering Task ForceH. Yu
>> Internet-DraftY. Liu
>> Intended status: Experimental  Guangzhou Genlian
>> Expires: 29 October 2022   27 April 2022
> 14c12
> <   draft-muks-dns-message-fragments-00
> ---
>>draft-hsyu-message-fragments-00
> 32c30
>  ---
>>   Drafts is at https://datatracker.ietf.org/drafts/current/.
> 39c37
>  ---
>>   This Internet-Draft will expire on 29 October 2022.
> 43c41
>  ---
>>   Copyright (c) 2022 IETF Trust and the persons identified as the
> 47,52c45,51
>  <(http://trustee.ietf.org/license-info) in effect on the date of
>     ---
>> 

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-28 Thread Brian E Carpenter

There was 
https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02

My hope is to revive that draft as an RFC Editor policy issue once the RSWG is 
established, because it's broader than just an IETF issue.

Regards
   Brian Carpenter

On 29-Apr-22 06:16, Donald Eastlake wrote:
What you describe is completely improper but I'm not sure it's exactly accurate. When you said you were "removed" as an author, I assumed that a 
new revision of a draft was posted where you were a first page author for 
version N but not listed as an author for version N+1. That would also be 
improper if there was no effort to consult with you.


But what seems to have happened is that a new draft was created with you omitted from 
the author list and (given the reference to Cindy Morgan in the Subject line), the 
Secretariat was asked to record this new draft as replacing the previous draft where 
you were an author (indeed, the first listed author). I think this sort of thing is 
extremely rare. You could certainly ask the Secretariat to reverse the database 
update so your draft 
(https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/ 
) is no 
longer shown as being replaced by any other draft.

Thanks,
Donald
===
  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
  2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com 


On Thu, Apr 28, 2022 at 1:10 PM Mukund Sivaraman mailto:m...@mukund.org>> wrote:

On Thu, Apr 28, 2022 at 09:33:08AM -0700, DraftTracker Mail System wrote:
 >
 > Please DO NOT reply to this email.
 >
 > I-D: 
 > Datatracker URL: 
https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/ 

 >
 > This document now replaces draft-muks-dnsop-message-fragments
 >     draft-hsyu-dnsop-message-fragments instead of 

draft-hsyu-dnsop-message-fragments


This is the second time in recent years that, in a DNS draft I'd
primarily authored, I've noticed my name was removed from the list of
authors with no prior consultation with the document mostly the same.

I understand that we assign co-copyright to the IETF when publishing
drafts, but it feels unreasonable that after effort is put in writing a
draft, the authorship is completely deleted. In the previous case, I was
moved to "Acknowledgements" without consultation, and in this case my
name has been deleted fully.

New author(s) who want to take over could instead:

* Ask to be co-author(s).

* Say that they'd leave the original author(s) as-is, but that they
   would like to have control over the draft's future, and if the old
   author(s) don't like it, they may ask to be deleted.

* If content were significantly modified, they could say "This draft is
   significantly different from your old draft, and so we'd like to claim
   full ownership, is that OK?".

Instead, what happened with both drafts is akin to taking a book that's
mostly written by one author, contributing a few sentences, and deleting
the previous authors' names and calling it your own.

                 Mukund



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-28 Thread Mukund Sivaraman
Hi Donald

On Thu, Apr 28, 2022 at 02:16:16PM -0400, Donald Eastlake wrote:
> What you describe is completely improper but I'm not sure it's exactly
> accurate. When you said you were "removed" as an author, I assumed that a
> new revision of a draft was posted where you were a first page author for
> version N but not listed as an author for version N+1. That would also be
> improper if there was no effort to consult with you.
> 
> But what seems to have happened is that a new draft was created with you
> omitted from the author list and (given the reference to Cindy Morgan in
> the Subject line), the Secretariat was asked to record this new draft as
> replacing the previous draft where you were an author (indeed, the first
> listed author). I think this sort of thing is extremely rare. You could
> certainly ask the Secretariat to reverse the database update so your draft (
> https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/) is no
> longer shown as being replaced by any other draft.

A new draft has been created, the contents of which are:

https://www.ietf.org/archive/id/draft-hsyu-message-fragments-00.txt

which is largely identical to the original [see diff below], but mainly
authorship has been modified:

https://www.ietf.org/archive/id/draft-muks-dns-message-fragments-00.txt

The commit history of the contribution to the original draft is here:

https://github.com/muks/dnsfragments/commits/master

The draft appears to have gone from:

[2015-07-20] https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/

(original draft)

to:

[2022-04-20] 
https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/

(which included the new author " haisheng yu ", but kept the previous
authors, but with no intimation to us)

to:

[2022-04-28] https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/

(which deleted the original authors)

It's not the mechanics, what the new name of the draft is, or what URI
it is at. I am just disappointed we worked on making something and have
disappeared from it, even if it is a copy of the text. It seems
unreasonable, but all things considered (this is not the first time),
I'll shake my head and move on.

I don't know if my expectation that authorship should be preserved is
misplaced - maybe it is. We already co-assign copyright to the IETF.

Mukund



The following is a diff between the two drafts to this email, to
illustrate that mainly the authorship information has changed and the
authors who wrote most of it have been removed.




5,10c5,8
< Internet Engineering Task Force M. Sivaraman
< Internet-Draft   Internet Systems Consortium
< Intended status: ExperimentalS. Kerr
< Expires: January 21, 2016L. Song
<   Beijing Internet Institute
 Internet Engineering Task ForceH. Yu
> Internet-DraftY. Liu
> Intended status: Experimental  Guangzhou Genlian
> Expires: 29 October 2022   27 April 2022
14c12
<   draft-muks-dns-message-fragments-00
---
> draft-hsyu-message-fragments-00
32c30
Drafts is at https://datatracker.ietf.org/drafts/current/.
39c37
This Internet-Draft will expire on 29 October 2022.
43c41
Copyright (c) 2022 IETF Trust and the persons identified as the
47,52c45,51
Provisions Relating to IETF Documents (https://trustee.ietf.org/
>license-info) in effect on the date of publication of this document.
>Please review these documents carefully, as they describe your rights
>and restrictions with respect to this document.  Code Components
>extracted from this document must include Revised BSD License text as
>described in Section 4.e of the Trust Legal Provisions and are
>provided without warranty as described in the Revised BSD License.
56,58d54
< Sivaraman, et al.   Expires January 21, 2016[Page 1]
< 
< Internet-DraftDNS message fragmentsJuly 2015
59a56,58
> Yu & Liu Expires 29 

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-28 Thread Donald Eastlake
What you describe is completely improper but I'm not sure it's exactly
accurate. When you said you were "removed" as an author, I assumed that a
new revision of a draft was posted where you were a first page author for
version N but not listed as an author for version N+1. That would also be
improper if there was no effort to consult with you.

But what seems to have happened is that a new draft was created with you
omitted from the author list and (given the reference to Cindy Morgan in
the Subject line), the Secretariat was asked to record this new draft as
replacing the previous draft where you were an author (indeed, the first
listed author). I think this sort of thing is extremely rare. You could
certainly ask the Secretariat to reverse the database update so your draft (
https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/) is no
longer shown as being replaced by any other draft.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Thu, Apr 28, 2022 at 1:10 PM Mukund Sivaraman  wrote:

> On Thu, Apr 28, 2022 at 09:33:08AM -0700, DraftTracker Mail System wrote:
> >
> > Please DO NOT reply to this email.
> >
> > I-D: 
> > Datatracker URL:
> https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/
> >
> > This document now replaces draft-muks-dnsop-message-fragments
> > draft-hsyu-dnsop-message-fragments instead of
> draft-hsyu-dnsop-message-fragments
>
> This is the second time in recent years that, in a DNS draft I'd
> primarily authored, I've noticed my name was removed from the list of
> authors with no prior consultation with the document mostly the same.
>
> I understand that we assign co-copyright to the IETF when publishing
> drafts, but it feels unreasonable that after effort is put in writing a
> draft, the authorship is completely deleted. In the previous case, I was
> moved to "Acknowledgements" without consultation, and in this case my
> name has been deleted fully.
>
> New author(s) who want to take over could instead:
>
> * Ask to be co-author(s).
>
> * Say that they'd leave the original author(s) as-is, but that they
>   would like to have control over the draft's future, and if the old
>   author(s) don't like it, they may ask to be deleted.
>
> * If content were significantly modified, they could say "This draft is
>   significantly different from your old draft, and so we'd like to claim
>   full ownership, is that OK?".
>
> Instead, what happened with both drafts is akin to taking a book that's
> mostly written by one author, contributing a few sentences, and deleting
> the previous authors' names and calling it your own.
>
> Mukund
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-28 Thread Mukund Sivaraman
On Thu, Apr 28, 2022 at 09:33:08AM -0700, DraftTracker Mail System wrote:
> 
> Please DO NOT reply to this email.
> 
> I-D: 
> Datatracker URL: 
> https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/
> 
> This document now replaces draft-muks-dnsop-message-fragments
> draft-hsyu-dnsop-message-fragments instead of 
> draft-hsyu-dnsop-message-fragments

This is the second time in recent years that, in a DNS draft I'd
primarily authored, I've noticed my name was removed from the list of
authors with no prior consultation with the document mostly the same.

I understand that we assign co-copyright to the IETF when publishing
drafts, but it feels unreasonable that after effort is put in writing a
draft, the authorship is completely deleted. In the previous case, I was
moved to "Acknowledgements" without consultation, and in this case my
name has been deleted fully.

New author(s) who want to take over could instead:

* Ask to be co-author(s).

* Say that they'd leave the original author(s) as-is, but that they
  would like to have control over the draft's future, and if the old
  author(s) don't like it, they may ask to be deleted.

* If content were significantly modified, they could say "This draft is
  significantly different from your old draft, and so we'd like to claim
  full ownership, is that OK?".

Instead, what happened with both drafts is akin to taking a book that's
mostly written by one author, contributing a few sentences, and deleting
the previous authors' names and calling it your own.

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop