Re: [tsvwg] Francesca Palombini's No Objection on draft-ietf-tsvwg-ecn-encap-guidelines-21: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Francesca, (and adding [e-mail])

On 29/11/2023 16:49, Francesca Palombini via Datatracker wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-tsvwg-ecn-encap-guidelines-21: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document.
>
> Many thanks to Paul Kyzivat for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/jJEK_HJPd3THXWsbRlEjPiP9lEA/.
>
> Running the id-nits tool on this document
> (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tsvwg-ecn-encap-guidelines-21.txt),
> I was warned of the following:
>
>    -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
>       have content which was first submitted before 10 November 2008.  The
>       disclaimer is necessary when there are original authors that you have
>       been unable to contact, or if some do not wish to grant the BCP78 rights
>       to the IETF Trust.  If you are able to get all authors (current and
>       original) to grant those rights, you can and should remove the
>       disclaimer; otherwise, the disclaimer is needed and you can ignore this
>       comment. (See the Legal Provisions document at
>       https://trustee.ietf.org/license-info for more information.)
>
> But I saw no hint of why that is in the shepherd write-up. Is it because this
> is an update to 3819? I would understand better if this was an "obsolete"... Is
> it common practice? (This is more a question to the responsible AD and the rest
> of the IESG than to the authors).

[BB] I'll answer it as the author who decided to pick that legal 
provision, and I'll answer for both drafts here.

ecn-encap-guidelines: Yes, the quote from RFC3819 was one potential 
reason. More problematic were quotes (or paraphrasings) from RFC3168 and 
RFC4774, where one of the authors (Sally Floyd) is no longer with us, so 
I couldn't check for permission. Also, one of the early authors, Pat 
Thaler, retired part way through the very long gestation of this draft. 
So I couldn't check with her whether any of her text had its origins in 
earlier documents.

rfc6040update-shim: updates a number of very old RFCs, e.g. L2TP v2, v3, 
GRE. Altho I hadn't intentionally quoted any of them, I thought it 
better to play on the safe side and use the pre-5378 disclaimer, in case 
I had.

If the IESG thinks differently, pls just tell me what I should have done.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/