Re: [auth48] [IANA #1284032] [IANA] Re: AUTH48: RFC-to-be 9484 <draft-ietf-masque-connect-ip-13> for your review

[Alanna Paloma <[e-mail]>]

Hi Amanda,

The change looks good. The square brackets are fine as is.

Thank you!
RFC Editor/ap

> On Oct 16, 2023, at 5:50 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi,
> 
> This change is complete:
> 
> On Mon Oct 16 15:57:56 2023, [e-mail] wrote:
>> IANA,
>> 
>> Please make the following update to the “Related Information” field of
>> the “masque” URI Suffix in the "Well-Known URIs” registry
>> <https://www.iana.org/assignments/well-known-uris>.
>> 
>> Old:
>> For sub-suffix allocations, see registry at
>> [https://www.iana.org/assignments/masque].
>> 
>> New (add “the” before “registry”):
>> For sub-suffix allocations, see the registry at
>> <https://www.iana.org/assignments/masque>.
> 
> We've added the "the":
> 
> https://www.iana.org/assignments/well-known-uris
> 
> I don't know whether was meant to include a change from square to angled brackets, but we have to keep the square brackets in place.
> 
> thanks,
> 
> Amanda Baber
> IANA Operations Manager
> 
>> The diff file can be seen here: https://www.rfc-
>> editor.org/authors/rfc9484-diff.html
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>> 
>>> On Oct 16, 2023, at 7:22 AM, Mirja Kuehlewind
>>> <[e-mail]> wrote:
>>> 
>>> Hi Aloma, hi all,
>>> 
>>> thanks for the work and catching these last changes. Sorry for my
>>> late reply. I reviewed the diff and approve for publication!
>>> 
>>> Mirja
>>> 
>>> 
>>> On 06.10.23, 21:26, "Alanna Paloma" <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> Hi Martin,
>>> 
>>> 
>>> Thank you for your reply. Your approval has been noted on the AUTH48
>>> status page:
>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>> editor.org/auth48/rfc9484>
>>> 
>>> 
>>> Best regards,
>>> RFC Editor/ap
>>> 
>>> 
>>>> On Oct 6, 2023, at 11:51 AM, Martin Duke <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>> Changes LGTM
>>>> 
>>>> On Thu, Oct 5, 2023 at 8:35 AM Alanna Paloma <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>> Hi Magnus,
>>>> 
>>>> Thank you for your reply. We have noted your approval on the AUTH48
>>>> status page:
>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>> editor.org/auth48/rfc9484>
>>>> 
>>>> Once we receive approvals from Mirja and Martin (AD), we will move
>>>> this document forward in the publication process.
>>>> 
>>>> Thank you,
>>>> RFC Editor/ap
>>>> 
>>>>> On Oct 5, 2023, at 4:43 AM, Magnus Westerlund
>>>>> <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I approve the publication of this document.
>>>>> 
>>>>> Magnus Westerlund
>>>>> 
>>>>> From: Alanna Paloma <[e-mail] <mailto:[e-mail]>>
>>>>> Date: Friday, 29 September 2023 at 00:39
>>>>> To: David Schinazi <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> Cc: Alex Chernyakhovsky <[e-mail]
>>>>> <mailto:[e-mail]>>, Martin Duke <[e-mail]
>>>>> <mailto:[e-mail]>>, Mirja Kuehlewind
>>>>> <[e-mail]
>>>>> <mailto:[e-mail]>>, Magnus Westerlund
>>>>> <[e-mail]
>>>>> <mailto:[e-mail]>>, Jean Mahoney
>>>>> <[e-mail] <mailto:[e-mail]>>, Tommy Pauly
>>>>> <[e-mail] <mailto:[e-mail]>>, RFC Errata System
>>>>> <[e-mail] <mailto:[e-mail]>>,
>>>>> [e-mail] <mailto:[e-mail]> <masque-
>>>>> [e-mail] <mailto:[e-mail]>>, [e-mail]
>>>>> <mailto:[e-mail]> <[e-mail]
>>>>> <mailto:[e-mail]>>, Christopher Wood
>>>>> <[e-mail] <mailto:[e-mail]>>, auth48archive
>>>>> <[e-mail] <mailto:auth48archive@rfc-
>>>>> editor.org>>
>>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9484 <draft-ietf-masque-
>>>>> connect-ip-13> for your review
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> Thank you for your reply. Your approval has been noted on the
>>>>> AUTH48 status page:
>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>> editor.org/auth48/rfc9484>
>>>>> 
>>>>>> One small point I did notice when comparing our XML with yours is
>>>>>> that yours appears to have UTF-8 character tabulation (&#x9;) in a
>>>>>> bunch of odd places.
>>>>>> As an example, I saw that in the text that you just added today,
>>>>>> "reject the HTTP Upgrade and attempt to parse the IP packets as a
>>>>>> subsequent HTTP request".
>>>>>> In that sentence, it looks like you added whitespace between the
>>>>>> word "and" and the word "attempt".
>>>>>> In our copy of the XML, the only character between those two words
>>>>>> is a space (ASCII 0x20).
>>>>>> In your copy, there is the following hex sequence between them: 0a
>>>>>> 09 20 20 20. The 0x0a is a newline, and it's fine - it makes sense
>>>>>> that your copy has line endings in different places - but it's odd
>>>>>> to me that there's a tabulation character 0x09 followed by three
>>>>>> spaces 0x20. I suspect that was unintentional and done
>>>>>> automatically by whichever editor you've been using to make
>>>>>> changes.
>>>>> 
>>>>> 
>>>>> Those tabulation characters were likely inserted from copying and
>>>>> pasting the new text into in the XML. Apologies for overlooking
>>>>> this. We have cleaned up this extra spacing in the XML.
>>>>> 
>>>>> We will await approvals from Mirja, Magnus, and Martin (AD).
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/ap
>>>>> 
>>>>>> On Sep 28, 2023, at 2:06 PM, David Schinazi
>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>> wrote:
>>>>>> 
>>>>>> Thank you for making the changes Alanna.
>>>>>> 
>>>>>> I approve the document for publication.
>>>>>> 
>>>>>> One small point I did notice when comparing our XML with yours is
>>>>>> that yours appears to have UTF-8 character tabulation (&#x9;) in a
>>>>>> bunch of odd places.
>>>>>> As an example, I saw that in the text that you just added today,
>>>>>> "reject the HTTP Upgrade and attempt to parse the IP packets as a
>>>>>> subsequent HTTP request".
>>>>>> In that sentence, it looks like you added whitespace between the
>>>>>> word "and" and the word "attempt".
>>>>>> In our copy of the XML, the only character between those two words
>>>>>> is a space (ASCII 0x20).
>>>>>> In your copy, there is the following hex sequence between them: 0a
>>>>>> 09 20 20 20. The 0x0a is a newline, and it's fine - it makes sense
>>>>>> that your copy has line endings in different places - but it's odd
>>>>>> to me that there's a tabulation character 0x09 followed by three
>>>>>> spaces 0x20. I suspect that was unintentional and done
>>>>>> automatically by whichever editor you've been using to make
>>>>>> changes.
>>>>>> 
>>>>>> All that said, I really don't feel strongly about it, so if you
>>>>>> think that those tabulations don't matter then that totally works
>>>>>> for me.
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Thu, Sep 28, 2023 at 1:40 PM Alanna Paloma <[e-mail]
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>> Hi David, Alex, and Martin (AD)*,
>>>>>> 
>>>>>> *Martin - As the AD, please review and approve of the added text
>>>>>> at the end of Section 11. This change can be seen in this diff
>>>>>> file:
>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html
>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html>
>>>>>> 
>>>>>> David and Alex - Thank you for your replies. We have updated the
>>>>>> files accordingly and noted Alex’s approval on the AUTH48 status
>>>>>> page:
>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>>> editor.org/auth48/rfc9484>
>>>>>> 
>>>>>> The files have been posted here (please refresh):
>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-
>>>>>> editor.org/authors/rfc9484.txt>
>>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-
>>>>>> editor.org/authors/rfc9448.pdf>
>>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-
>>>>>> editor.org/authors/rfc9484.html>
>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-
>>>>>> editor.org/authors/rfc9484.xml>
>>>>>> 
>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html
>>>>>> <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>> (comprehensive diff)
>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html
>>>>>> <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (all
>>>>>> AUTH48 changes)
>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html
>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html>
>>>>>> (htmlwdiff diff between last version and this)
>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html
>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html>
>>>>>> (rfcdiff between last version and this)
>>>>>> 
>>>>>> We will await approvals from David, Mirja, Magnus, and *Martin
>>>>>> prior to moving this document forward in the publication process.
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/ap
>>>>>> 
>>>>>>> On Sep 28, 2023, at 11:49 AM, Alex Chernyakhovsky
>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> Hi Alanna,
>>>>>>> 
>>>>>>> Assuming the updates David linked above are incorporated, I've
>>>>>>> completed my review and approve the document in this form.
>>>>>>> 
>>>>>>> Sincerely,
>>>>>>> -Alex
>>>>>>> 
>>>>>>> On Thu, Sep 28, 2023 at 2:45 PM David Schinazi
>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>> wrote:
>>>>>>> Thanks Alanna.
>>>>>>> 
>>>>>>> We did resolve the bug, and accumulated a few minor editorial
>>>>>>> tweaks along the way as well. Could you update your copy to match
>>>>>>> ours please? Ours is on the left side of this diff:
>>>>>>> https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-
>>>>>>> masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-
>>>>>>> masque-connect-ip.txt&url2=https://www.rfc-
>>>>>>> editor.org/authors/rfc9484.txt <https://author-
>>>>>>> tools.ietf.org/iddiff?url1=https://ietf-wg-
>>>>>>> masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-
>>>>>>> masque-connect-ip.txt&amp;url2=https://www.rfc-
>>>>>>> editor.org/authors/rfc9484.txt>
>>>>>>> 
>>>>>>> David
>>>>>>> 
>>>>>>> On Wed, Sep 27, 2023 at 4:15 PM Alanna Paloma <[e-mail]
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>> Hi David, Alex, Mirja, and Magnus,
>>>>>>> 
>>>>>>> This is a friendly reminder that we await any further changes you
>>>>>>> may have as well as your reviews and approvals prior to moving
>>>>>>> this document forward in the publication process.
>>>>>>> 
>>>>>>> David - Please let us know if the bug has been fixed so we can
>>>>>>> incorporate that change into the files.
>>>>>>> 
>>>>>>> The files have been posted here (please refresh):
>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-
>>>>>>> editor.org/authors/rfc9484.txt>
>>>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-
>>>>>>> editor.org/authors/rfc9448.pdf>
>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-
>>>>>>> editor.org/authors/rfc9484.html>
>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-
>>>>>>> editor.org/authors/rfc9484.xml>
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html
>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>>> (comprehensive diff)
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html
>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (all
>>>>>>> AUTH48 changes)
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html
>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html>
>>>>>>> (htmlwdiff diff between last version and this)
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html
>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html>
>>>>>>> (rfcdiff between last version and this)
>>>>>>> 
>>>>>>> Please see the AUTH48 status page for this document here:
>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>>>> editor.org/auth48/rfc9484>
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> RFC Editor/ap
>>>>>>> 
>>>>>>>> On Sep 20, 2023, at 12:37 AM, Magnus Westerlund
>>>>>>>> <[e-mail]
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> For your information Mirja is on vacation and not back until the
>>>>>>>> 4th of October. It may take until the second week of October
>>>>>>>> until she can respond to the AUTH48. I will perform my review
>>>>>>>> now.
>>>>>>>> 
>>>>>>>> Cheers
>>>>>>>> 
>>>>>>>> Magnus
>>>>>>>> 
>>>>>>>> From: David Schinazi <[e-mail]
>>>>>>>> <mailto:[e-mail]>>
>>>>>>>> Date: Tuesday, 19 September 2023 at 22:21
>>>>>>>> To: Alanna Paloma <[e-mail] <mailto:[e-mail]>>
>>>>>>>> Cc: Jean Mahoney <[e-mail] <mailto:[e-mail]>>,
>>>>>>>> Tommy Pauly <[e-mail] <mailto:[e-mail]>>, RFC
>>>>>>>> Errata System <[e-mail] <mailto:rfc-editor@rfc-
>>>>>>>> editor.org>>, [e-mail] <mailto:[e-mail]>
>>>>>>>> <[e-mail] <mailto:[e-mail]>>, Mirja
>>>>>>>> Kuehlewind <[e-mail]
>>>>>>>> <mailto:[e-mail]>>, Magnus Westerlund
>>>>>>>> <[e-mail]
>>>>>>>> <mailto:[e-mail]>>, [e-mail]
>>>>>>>> <mailto:[e-mail]> <[e-mail]
>>>>>>>> <mailto:[e-mail]>>, [e-mail]
>>>>>>>> <mailto:[e-mail]> <[e-mail]
>>>>>>>> <mailto:[e-mail]>>, Christopher Wood
>>>>>>>> <[e-mail] <mailto:[e-mail]>>, Martin Duke
>>>>>>>> <[e-mail] <mailto:[e-mail]>>,
>>>>>>>> auth48archive <[e-mail]
>>>>>>>> <mailto:[e-mail]>>
>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9484 <draft-ietf-masque-connect-
>>>>>>>> ip-13> for your review
>>>>>>>> 
>>>>>>>> Thank you Alanna, this is looking great.
>>>>>>>> 
>>>>>>>> To keep you in the loop, we found a last minute bug in the spec
>>>>>>>> that we're also going to fix, but we're discussing it on the
>>>>>>>> masque mailing list to ensure everyone agrees.
>>>>>>>> https://mailarchive.ietf.org/arch/msg/masque/CT7iXultXzjk4IJNkuT7NxtehVY/
>>>>>>>> <https://mailarchive.ietf.org/arch/msg/masque/CT7iXultXzjk4IJNkuT7NxtehVY/>
>>>>>>>> I think we'll be able to merge that change in before the end of
>>>>>>>> the week, but I want to make sure folks on the mailing list have
>>>>>>>> a chance to object before we do.
>>>>>>>> 
>>>>>>>> Once that's done, we'll request a small change to your version
>>>>>>>> of the document to incorporate that fix.
>>>>>>>> I've completed my full readthrough so I'll be ready to approve
>>>>>>>> the document for publication once this is resolved.
>>>>>>>> 
>>>>>>>> David
>>>>>>>> 
>>>>>>>> On Tue, Sep 19, 2023 at 9:32 AM Alanna Paloma <[e-mail]
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>> Hi David,
>>>>>>>> 
>>>>>>>> The files have been updated accordingly.
>>>>>>>> 
>>>>>>>> The files have been posted here (please refresh):
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-
>>>>>>>> editor.org/authors/rfc9484.txt>
>>>>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-
>>>>>>>> editor.org/authors/rfc9448.pdf>
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html
>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-
>>>>>>>> editor.org/authors/rfc9484.xml>
>>>>>>>> 
>>>>>>>> The relevant diff files are posted here:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html
>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>>>> (comprehensive diff)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html
>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html>
>>>>>>>> (all AUTH48 changes)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html
>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html>
>>>>>>>> (htmlwdiff diff between last version and this)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html
>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html>
>>>>>>>> (rfcdiff between last version and this)
>>>>>>>> 
>>>>>>>> We will await any further changes and approvals from David,
>>>>>>>> Alex, Mirja, and Magnus.
>>>>>>>> 
>>>>>>>> Please see the AUTH48 status page for this document here:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>>>>> editor.org/auth48/rfc9484>
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/ap
>>>>>>>> 
>>>>>>>>> On Sep 18, 2023, at 5:27 PM, David Schinazi
>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> I've also made a couple more very minor changes, visible at the
>>>>>>>>> same diff link.
>>>>>>>>> 
>>>>>>>>> + Jean to comment on the nbsp-vs-space in BCP 14 question
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-
>>>>>>>>> 313273af-454445555731-a165b79afa467e1c&q=1&e=1d2ccd24-f948-
>>>>>>>>> 40bc-9bad-
>>>>>>>>> d30817dc1a83&u=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-
>>>>>>>>> rfc%2Fpull%2F204%23issuecomment-1724227942
>>>>>>>>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-
>>>>>>>>> 313273af-454445555731-a165b79afa467e1c&amp;q=1&amp;e=1d2ccd24-
>>>>>>>>> f948-40bc-9bad-
>>>>>>>>> d30817dc1a83&amp;u=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-
>>>>>>>>> rfc%2Fpull%2F204%23issuecomment-1724227942>
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>> 
>>>>>>>>> On Mon, Sep 18, 2023 at 11:18 AM David Schinazi
>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>>>> wrote:
>>>>>>>>> Hi Alanna,
>>>>>>>>> 
>>>>>>>>> Thank you for the edits. From looking at the diff [1], I think
>>>>>>>>> we have two instances of an extra slash at the end of the IANA
>>>>>>>>> link.
>>>>>>>>> 
>>>>>>>>> OLD: https://www.iana.org/assignments/masque/
>>>>>>>>> <https://www.iana.org/assignments/masque/>
>>>>>>>>> NEW: https://www.iana.org/assignments/masque
>>>>>>>>> <https://www.iana.org/assignments/masque>
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [1] https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-
>>>>>>>>> masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-
>>>>>>>>> ietf-masque-connect-ip.txt&url2=https://www.rfc-
>>>>>>>>> editor.org/authors/rfc9484.txt <https://author-
>>>>>>>>> tools.ietf.org/iddiff?url1=https://ietf-wg-
>>>>>>>>> masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-
>>>>>>>>> ietf-masque-connect-ip.txt&amp;url2=https://www.rfc-
>>>>>>>>> editor.org/authors/rfc9484.txt>
>>>>>>>>> 
>>>>>>>>> On Mon, Sep 18, 2023 at 10:03 AM Alanna Paloma
>>>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> Hi David,
>>>>>>>>> 
>>>>>>>>> Thank you for your reply. We have updated the files per the
>>>>>>>>> diff you provided.
>>>>>>>>> 
>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9448.pdf>
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>>>>> 
>>>>>>>>> The relevant diff files are posted here:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>>>>> (comprehensive diff)
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html>
>>>>>>>>> (all AUTH48 changes)
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html>
>>>>>>>>> (htmlwdiff diff between last version and this)
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html
>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html>
>>>>>>>>> (rfcdiff between last version and this)
>>>>>>>>> 
>>>>>>>>> Please see the AUTH48 status page for this document here:
>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>>>>>> editor.org/auth48/rfc9484>
>>>>>>>>> 
>>>>>>>>> Thank you,
>>>>>>>>> RFC Editor/ap
>>>>>>>>> 
>>>>>>>>>> On Sep 15, 2023, at 6:52 PM, David Schinazi
>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Thanks Alanna,
>>>>>>>>>> 
>>>>>>>>>> I've gone through the edits and would like to make a few minor
>>>>>>>>>> changes. Please see them in the following diff:
>>>>>>>>>> https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-
>>>>>>>>>> masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-
>>>>>>>>>> ietf-masque-connect-ip.txt&url2=https://www.rfc-
>>>>>>>>>> editor.org/authors/rfc9484.txt <https://author-
>>>>>>>>>> tools.ietf.org/iddiff?url1=https://ietf-wg-
>>>>>>>>>> masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-
>>>>>>>>>> ietf-masque-connect-ip.txt&amp;url2=https://www.rfc-
>>>>>>>>>> editor.org/authors/rfc9484.txt>
>>>>>>>>>> (The author version is on the left and the RFC editor's
>>>>>>>>>> version is on the right, please switch to the author's
>>>>>>>>>> version)
>>>>>>>>>> 
>>>>>>>>>> You can ignore the diffs in the BCP 14 boilerplate and in the
>>>>>>>>>> references (/info/ vs /rfc/) - those are tooling issues
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>> 
>>>>>>>>>> On Fri, Sep 15, 2023 at 1:12 PM Alanna Paloma
>>>>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>> Hi Tommy,
>>>>>>>>>> 
>>>>>>>>>> Thank you for your quick response. We have noted your approval
>>>>>>>>>> on the AUTH48 status page:
>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>>>>>>> editor.org/auth48/rfc9484>
>>>>>>>>>> 
>>>>>>>>>> Thank you,
>>>>>>>>>> RFC Editor/ap
>>>>>>>>>> 
>>>>>>>>>>> On Sep 15, 2023, at 12:53 PM, Tommy Pauly <[e-mail]
>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Alanna,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for making those updates! I’ve review the doc and I
>>>>>>>>>>> approve it in this form.
>>>>>>>>>>> 
>>>>>>>>>>> Best,
>>>>>>>>>>> Tommy
>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 15, 2023, at 12:34 PM, Alanna Paloma
>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Tommy and David,
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you for your replies. We have updated the files
>>>>>>>>>>>> accordingly.
>>>>>>>>>>>> 
>>>>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml
>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt
>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html
>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.pdf
>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.pdf>
>>>>>>>>>>>> 
>>>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html
>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>>>>>>>> (comprehensive diff)
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html
>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html>
>>>>>>>>>>>> (AUTH48 changes)
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the document carefully and contact us with any
>>>>>>>>>>>> further updates you may have. Note that we do not make
>>>>>>>>>>>> changes once a document is published as an RFC.
>>>>>>>>>>>> 
>>>>>>>>>>>> We will await approvals from each party listed on the AUTH48
>>>>>>>>>>>> status page below prior to moving this document forward in
>>>>>>>>>>>> the publication process.
>>>>>>>>>>>> 
>>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-
>>>>>>>>>>>> editor.org/auth48/rfc9484>
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sep 15, 2023, at 9:10 AM, David Schinazi
>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks everyone! Really excited to see this in AUTH48.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For some reason I never received the original AUTH48 email
>>>>>>>>>>>>> (it's not even in my spam folder) but I did receive Tommy's
>>>>>>>>>>>>> reply. Maybe the [e-mail]
>>>>>>>>>>>>> <mailto:[e-mail]> alias is
>>>>>>>>>>>>> broken?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> More responses to individual questions inline.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'll do a full readthrough of the RFC editor edits once
>>>>>>>>>>>>> these responses have been incorporated.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Sep 14, 2023 at 8:27 PM Tommy Pauly
>>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>> Hello RFC Editor,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for your work on this! My comments are inline.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Tommy
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Sep 14, 2023, at 6:19 PM, [e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]> 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 review the "type" attribute of each
>>>>>>>>>>>>>> sourcecode element
>>>>>>>>>>>>>> in the XML file to ensure correctness. If the current list
>>>>>>>>>>>>>> of preferred
>>>>>>>>>>>>>> values for "type" (https://www.rfc-
>>>>>>>>>>>>>> editor.org/materials/sourcecode-types.txt
>>>>>>>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-
>>>>>>>>>>>>>> types.txt>)
>>>>>>>>>>>>>> does not contain an applicable type, then feel free to let
>>>>>>>>>>>>>> us
>>>>>>>>>>>>>> know. Also, it is acceptable to leave the "type" attribute
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> set.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> In addition, review each artwork element. Specifically,
>>>>>>>>>>>>>> should any artwork element be tagged as sourcecode or
>>>>>>>>>>>>>> another
>>>>>>>>>>>>>> element?
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> These types seem correct to me, and I have no issues with
>>>>>>>>>>>>> these. I’ll let the others chime in as well.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1, looks good to me
>>>>>>>>>>>>>> 2) <!--[rfced] Is "Internet Protocol Number" the same as
>>>>>>>>>>>>>> "IP protocol number"? May
>>>>>>>>>>>>>> we update as follows to reflect usage throughout the rest
>>>>>>>>>>>>>> of the document?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>> IP Protocol: The Internet Protocol Number for traffic that
>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>> sent to this range, encoded as an unsigned 8-bit integer.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>> IP Protocol: The IP protocol number for traffic that can
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> sent to this range, encoded as an unsigned 8-bit integer.
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, an Internet Protocol Number is the same as an IP
>>>>>>>>>>>>> protocol number in this usage. I’m happy to see this
>>>>>>>>>>>>> standardized on “IP protocol number”.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I disagree. "IP Protocol Number" expands to "Internet
>>>>>>>>>>>>> Protocol Protocol Number" which is silly (cf PIN number and
>>>>>>>>>>>>> ATM machine). The IANA registry is called "Assigned
>>>>>>>>>>>>> Internet Protocol Numbers" so I would prefer to standardize
>>>>>>>>>>>>> on "Internet Protocol Numbers".
>>>>>>>>>>>>> https://www.iana.org/assignments/protocol-numbers/protocol-
>>>>>>>>>>>>> numbers.xhtml <https://www.iana.org/assignments/protocol-
>>>>>>>>>>>>> numbers/protocol-numbers.xhtml>
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 3) <!--[rfced] The SVG figures in Sections 8.1, 8.2, 8.3,
>>>>>>>>>>>>>> and 8.4 have
>>>>>>>>>>>>>> width or height specified, which will make the artwork not
>>>>>>>>>>>>>> scale.
>>>>>>>>>>>>>> Please consider whether scaling should be enabled. Scaling
>>>>>>>>>>>>>> will allow
>>>>>>>>>>>>>> the figure to be resized when it is viewed on a mobile
>>>>>>>>>>>>>> device; however,
>>>>>>>>>>>>>> there may be aesthetic trade-offs (e.g., image may appear
>>>>>>>>>>>>>> too large
>>>>>>>>>>>>>> on a desktop screen or different figures may scale
>>>>>>>>>>>>>> differently based
>>>>>>>>>>>>>> on their relative sizes). Please review the HTML and PDF
>>>>>>>>>>>>>> outputs and
>>>>>>>>>>>>>> let us know how to proceed.
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> I don’t have any particular opinion on this. I’ll defer to
>>>>>>>>>>>>> the others.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Similarly, I have no opinion on the details here as long as
>>>>>>>>>>>>> the output looks reasonable. The width/height are only
>>>>>>>>>>>>> specified because the tool we used made them this way, it
>>>>>>>>>>>>> wasn't intentional.
>>>>>>>>>>>>>> 4) <!-- [rfced] We have included specific questions about
>>>>>>>>>>>>>> the IANA
>>>>>>>>>>>>>> text below. In addition to responding to these questions,
>>>>>>>>>>>>>> please
>>>>>>>>>>>>>> review all of the IANA-related updates carefully and let
>>>>>>>>>>>>>> us know
>>>>>>>>>>>>>> if any further updates are needed.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> a) We have updated the section titles for consistency.
>>>>>>>>>>>>>> Please review
>>>>>>>>>>>>>> and let us know if these are agreeable or if you prefer
>>>>>>>>>>>>>> otherwise.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>> 12.1. HTTP Upgrade Token
>>>>>>>>>>>>>> 12.2. Creation of the MASQUE URI Suffixes Registry
>>>>>>>>>>>>>> 12.3 Updates to masque Well-Known URI
>>>>>>>>>>>>>> 12.4 Capsule Type Registrations
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>> 12.1. HTTP Upgrade Token Registration
>>>>>>>>>>>>>> 12.2. MASQUE URI Suffixes Registry Creation
>>>>>>>>>>>>>> 12.3 Well-Known URIs Updates
>>>>>>>>>>>>>> 12.4 HTTP Capsule Types Registrations
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think 12.3 should still describe in the title that it is
>>>>>>>>>>>>> updating the particular well-known URI registration for
>>>>>>>>>>>>> “masque”. I would prefer to see that one stay as it was.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The changes for 12.1, 12.2, and 12.4 seem fine.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1, maybe switch 12.3 to "Updates to masque Well-Known URI
>>>>>>>>>>>>> Registration" ?
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> b) In Section 12.4, Table 2 contains a "Description"
>>>>>>>>>>>>>> column, but the
>>>>>>>>>>>>>> "HTTP Capsule Types" registry does not (see
>>>>>>>>>>>>>> <https://www.iana.org/assignments/masque/>
>>>>>>>>>>>>>> <https://www.iana.org/assignments/masque/&gt;>). Should
>>>>>>>>>>>>>> IANA add
>>>>>>>>>>>>>> this column to their registry?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I don’t think we should add a “description” column. These
>>>>>>>>>>>>> descriptions are particularly useful. There is a “notes”
>>>>>>>>>>>>> column that we could fill out, but I think we should just
>>>>>>>>>>>>> drop the description column.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1, we should just remove the description column from the
>>>>>>>>>>>>> document
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> c) In Section 12.4, we updated the URL from
>>>>>>>>>>>>>> "https://www.iana.org/assignments/http-capsule-protocol"
>>>>>>>>>>>>>> <https://www.iana.org/assignments/http-capsule-
>>>>>>>>>>>>>> protocol&quot;> to
>>>>>>>>>>>>>> "https://www.iana.org/assignments/masque"
>>>>>>>>>>>>>> <https://www.iana.org/assignments/masque&quot;> since the
>>>>>>>>>>>>>> "HTTP Capsule
>>>>>>>>>>>>>> Types" registry has moved. Please let us know if this is
>>>>>>>>>>>>>> agreeable
>>>>>>>>>>>>>> or if you prefer otherwise.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>> This document requests IANA to add the following values to
>>>>>>>>>>>>>> the "HTTP Capsule Types" registry maintained at
>>>>>>>>>>>>>> <https://www.iana.org/assignments/http-capsule-protocol>
>>>>>>>>>>>>>> <https://www.iana.org/assignments/http-capsule-
>>>>>>>>>>>>>> protocol&gt;>.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>> IANA has added the following values to the "HTTP Capsule
>>>>>>>>>>>>>> Types"
>>>>>>>>>>>>>> registry maintained at
>>>>>>>>>>>>>> <https://www.iana.org/assignments/masque>
>>>>>>>>>>>>>> <https://www.iana.org/assignments/masque&gt;>.
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That looks fine to me, thanks!
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>> 5) <!--[rfced] Should RFC 6874 be tagged like the other
>>>>>>>>>>>>>> RFC references for consistency?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>> [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden,
>>>>>>>>>>>>>> "Representing
>>>>>>>>>>>>>> IPv6 Zone Identifiers in Address Literals and Uniform
>>>>>>>>>>>>>> Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
>>>>>>>>>>>>>> February 2013, <https://www.rfc-editor.org/rfc/rfc6874>
>>>>>>>>>>>>>> <https://www.rfc-editor.org/rfc/rfc6874&gt;>.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>> [ZONE-ID] Carpenter, B., Cheshire, S., and R. Hinden,
>>>>>>>>>>>>>> "Representing
>>>>>>>>>>>>>> IPv6 Zone Identifiers in Address Literals and Uniform
>>>>>>>>>>>>>> Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
>>>>>>>>>>>>>> February 2013, <https://www.rfc-editor.org/rfc/rfc6874>
>>>>>>>>>>>>>> <https://www.rfc-editor.org/rfc/rfc6874&gt;>.
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sure, that’s a good call-out. Perhaps the tag could be
>>>>>>>>>>>>> [IPV6-ZONES]?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sounds good. Slight preference for [IPv6-ZONE-ID] for
>>>>>>>>>>>>> consistency with [IPv6-ADDR]
>>>>>>>>>>>>>> 6) <!--[rfced] Throughout the text, the following terms
>>>>>>>>>>>>>> appear to be used
>>>>>>>>>>>>>> inconsistently. Please review.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> a) May we capitalize these terms throughout for
>>>>>>>>>>>>>> consistency?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> HTTP Datagram vs. HTTP datagram
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, please make “HTTP Datagram” capitalized throughout, to
>>>>>>>>>>>>> match RFC 9298.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> IP Address vs. IP address
>>>>>>>>>>>>>> IP Address Range vs. IP address range
>>>>>>>>>>>>>> IP Prefix Length vs. IP prefix length
>>>>>>>>>>>>> 
>>>>>>>>>>>>> All three of these instances should remain as they are, I
>>>>>>>>>>>>> believe. When we capitalize “Address”, “Address Range”, and
>>>>>>>>>>>>> “Prefix Length”, we refer to specific fields in a
>>>>>>>>>>>>> structure. Otherwise, the phrases are colloquial.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Quarter Stream ID vs. quarter stream ID
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please do capitalize the one lowercase instance here.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Requested Address vs. requested address
>>>>>>>>>>>>>> Start IP Address, End IP Address vs. start and end IP
>>>>>>>>>>>>>> address
>>>>>>>>>>>>> 
>>>>>>>>>>>>> These should be left as-is, as they either refer to a
>>>>>>>>>>>>> structure field (capitalized) or a concept (not
>>>>>>>>>>>>> capitalized).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> b) We notice 60 instances of "IP proxying" vs. 2 instances
>>>>>>>>>>>>>> of "IP
>>>>>>>>>>>>>> Proxying" in the running text. May we make these
>>>>>>>>>>>>>> instances
>>>>>>>>>>>>>> lowercase for consistency?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>> The IP Proxying HTTP Datagram Payload contains the
>>>>>>>>>>>>>> following fields:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This instance should remain capitalized.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1, this is the definition of a field whereas the others
>>>>>>>>>>>>> are colloquial
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> If an IP proxying endpoint with a connection containing an
>>>>>>>>>>>>>> IP Proxying request stream disables congestion control,
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> cannot signal Explicit Congestion Notification (ECN)
>>>>>>>>>>>>>> [ECN]
>>>>>>>>>>>>>> support on that outer connection.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This instance can be lowercased.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 7) <!-- [rfced] FYI: We have added expansions for the
>>>>>>>>>>>>>> following abbreviations
>>>>>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
>>>>>>>>>>>>>> review each
>>>>>>>>>>>>>> expansion in the document carefully to ensure correctness.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Authenticated Encryption with Associated Data (AEAD)
>>>>>>>>>>>>>> ECN-Echo (ECE)
>>>>>>>>>>>>>> Encapsulating Security Payload (ESP)
>>>>>>>>>>>>>> Not ECN-Capable Transport (Not-ECT)
>>>>>>>>>>>>>> Stream Control Transmission Protocol (SCTP)
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> These look fine.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 8) <!-- [rfced] Please review the "Inclusive Language"
>>>>>>>>>>>>>> portion of the online
>>>>>>>>>>>>>> Style Guide <https://www.rfc-
>>>>>>>>>>>>>> editor.org/styleguide/part2/#inclusive_language>
>>>>>>>>>>>>>> <https://www.rfc-
>>>>>>>>>>>>>> editor.org/styleguide/part2/#inclusive_language&gt;>
>>>>>>>>>>>>>> and let us know if any changes are needed.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Note that our script did not flag any words in particular,
>>>>>>>>>>>>>> but this should still
>>>>>>>>>>>>>> be reviewed as a best practice.
>>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We have checked this, thank you!
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> RFC Editor/ap/kc
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Sep 14, 2023, at 6:16 PM, [e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Updated 2023/09/14
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>>>>> --------------
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been
>>>>>>>>>>>>>> reviewed and
>>>>>>>>>>>>>> approved by you and all coauthors, it will be published as
>>>>>>>>>>>>>> an RFC.
>>>>>>>>>>>>>> If an author is no longer available, there are several
>>>>>>>>>>>>>> remedies
>>>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-
>>>>>>>>>>>>>> editor.org/faq/ <https://www.rfc-editor.org/faq/>).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You and you coauthors are responsible for engaging other
>>>>>>>>>>>>>> parties
>>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before
>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>> your approval.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Planning your review
>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * RFC Editor questions
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review and resolve any questions raised by the RFC
>>>>>>>>>>>>>> Editor
>>>>>>>>>>>>>> that have been included in the XML file as comments marked
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>> follows:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * Changes submitted by coauthors
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please ensure that you review any changes submitted by
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you
>>>>>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * Content
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review the full content of the document, as this
>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>> change once the RFC is published. Please pay particular
>>>>>>>>>>>>>> attention to:
>>>>>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>>>>>> - contact information
>>>>>>>>>>>>>> - references
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * Copyright notices and legends
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review the copyright notice and legends as defined
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/
>>>>>>>>>>>>>> <https://trustee.ietf.org/license-info/>).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * Semantic markup
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review the markup in the XML file to ensure that
>>>>>>>>>>>>>> elements of
>>>>>>>>>>>>>> content are correctly tagged. For example, ensure that
>>>>>>>>>>>>>> <sourcecode>
>>>>>>>>>>>>>> and <artwork> are set correctly. See details at
>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>
>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * Formatted output
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> formatted output, as generated from the markup in the XML
>>>>>>>>>>>>>> file, is
>>>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting
>>>>>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Submitting changes
>>>>>>>>>>>>>> ------------------
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY
>>>>>>>>>>>>>> ALL’ as all
>>>>>>>>>>>>>> the parties CCed on this message need to see your changes.
>>>>>>>>>>>>>> The parties
>>>>>>>>>>>>>> include:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * your coauthors
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * [e-mail] <mailto:rfc-editor@rfc-
>>>>>>>>>>>>>> editor.org> (the RPC team)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * other document participants, depending on the stream
>>>>>>>>>>>>>> (e.g.,
>>>>>>>>>>>>>> IETF Stream participants are your working group chairs,
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * [e-mail] <mailto:auth48archive@rfc-
>>>>>>>>>>>>>> editor.org>, which is a new archival mailing list
>>>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active
>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>> list:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * More info:
>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-
>>>>>>>>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-
>>>>>>>>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * The archive itself:
>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily
>>>>>>>>>>>>>> opt out
>>>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive
>>>>>>>>>>>>>> matter).
>>>>>>>>>>>>>> If needed, please add a note at the top of the message
>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>> have dropped the address. When the discussion is
>>>>>>>>>>>>>> concluded,
>>>>>>>>>>>>>> [e-mail] <mailto:auth48archive@rfc-
>>>>>>>>>>>>>> editor.org> will be re-added to the CC list and
>>>>>>>>>>>>>> its addition will be noted at the top of the message.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> An update to the provided XML file
>>>>>>>>>>>>>> — OR —
>>>>>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> OLD:
>>>>>>>>>>>>>> old text
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> NEW:
>>>>>>>>>>>>>> new text
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You do not need to reply with both an updated XML file and
>>>>>>>>>>>>>> an explicit
>>>>>>>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> We will ask a stream manager to review and approve any
>>>>>>>>>>>>>> changes that seem
>>>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text,
>>>>>>>>>>>>>> deletion of text,
>>>>>>>>>>>>>> and technical changes. Information about stream managers
>>>>>>>>>>>>>> can be found in
>>>>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a
>>>>>>>>>>>>>> stream manager.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Approving for publication
>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> To approve your RFC for publication, please reply to this
>>>>>>>>>>>>>> email stating
>>>>>>>>>>>>>> that you approve this RFC for publication. Please use
>>>>>>>>>>>>>> ‘REPLY ALL’,
>>>>>>>>>>>>>> as all the parties CCed on this message need to see your
>>>>>>>>>>>>>> approval.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Files
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The files are available here:
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.pdf
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.pdf>
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-rfcdiff.html
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-rfcdiff.html>
>>>>>>>>>>>>>> (side by side)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-xmldiff1.html
>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9484-xmldiff1.html>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The details of the AUTH48 status of your document are
>>>>>>>>>>>>>> here:
>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484
>>>>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9484>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>> RFC9484 (draft-ietf-masque-connect-ip-13)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Title : Proxying IP in HTTP
>>>>>>>>>>>>>> Author(s) : T. Pauly, Ed., D. Schinazi, A. Chernyakhovsky,
>>>>>>>>>>>>>> M. Kühlewind, M. Westerlund
>>>>>>>>>>>>>> WG Chair(s) : Christopher A. Wood, Eric Kinnear
>>>>>>>>>>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
>