Re: [C430] AUTH48 [LB]: RFC 8999 <draft-ietf-quic-invariants-13.txt> NOW AVAILABLE

Hi, Martin.  

Thanks for the notes below.  We'll look forward to seeing your updated XML file when it's finished; thanks also for making the updates!

RFC Editor/lb

> On Apr 28, 2021, at 6:03 PM, Martin Thomson via C430 <c430@rfc-editor.org> wrote:
> 
> Thanks for the work on this document.
> 
> I've staged a bunch of changes in our source repository for review.  I will provide updated XML once that process is complete.  For now, I will try to note differences so that there are no surprises.
> 
> The complete set of outstanding changes to this document are in progress, so they are either in our working copy:
>  https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-invariants.md
> or they are in open pull requests that affect that document:
>  https://github.com/quicwg/base-drafts/pulls?q=is%3Apr+is%3Aopen+label%3A-invariants
> 
> 
> I've partially reverted a change in the introduction:
> 
>    The functionality of all of these invariants is independent of the IP version.
> 
> I think that this can just be:
> 
>    All of these invariants are independent of the IP version.
> 
> "Functionality" is not appropriate in this context.  I've staged this change along with the others.
> 
> I noticed that nesting of a single <t> element in <dd> for the definitions was removed so that the text is directly in the <dd> element.  This is fine, but I don't have an easy way to perform the same transformation, so the XML that I will ultimately provide probably won't have this change.  I note that RFC-to-be 9000 doesn't include the same change.
> 
> I noticed that <artwork> elements have been modified so that the trailing end-of-line character has been removed.  This doesn't appear to alter rendering and it is similarly hard for me to reproduce consistently (sometimes trailing space is relevant), so I haven't made any changes to ensure that this change is preserved.  Again, RFC-to-be 9000 doesn't include the same change, so I'm banking on this being acceptable.
> 
> I have removed non-breaking whitespace.  This appeared in just one place in this document (between "BCP" and "14" in the boilerplate from RFC 8174), but there was one instance added as part of the edits to the notation section in RFC-to-be 9000.  I don't think that was a good change, but I wanted to note that here.
> 
> I have removed all comments; this is partly a consequence of tooling constraints and partly to ensure that we haven't smuggled in anything unwanted.
> 
> Answers to questions inline.
> 
> On Tue, Apr 27, 2021, at 17:31, rfc-editor@rfc-editor.org wrote:
>> Authors,
>> 
>> While reviewing this document during AUTH48, please resolve 
>> (as necessary) the following questions, which are also in the XML file.
>> 
>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear 
>> in the title) for use on https://www.rfc-editor.org/search -->
> 
> "invariants" is fine, in addition to what is in the title.
> 
>> 2) <!-- [rfced] Section 4:  We see that the meanings for the notation
>> definitions appear to be the same as those for the notation
>> definitions in [QUIC-TRANSPORT], but some of the wordings are
>> different.  Please let us know if you would like the wordings to
>> match in both documents (and if yes, which document's wordings
>> should we use?).
> 
> I have changes that reconcile these in https://github.com/quicwg/base-drafts/pull/4876
> 
>> 3) <!-- [rfced] Section 5.2:  This document uses "Connection ID Lengths",
>> but draft-ietf-quic-transport uses "Connection ID lengths".  Would
>> you like to make usage of this term in these two documents consistent?
> 
> Your suggestions here were excellent.  I've staged those changes along with others.
> -- 
> C430 mailing list
> C430@rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/c430
> 