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

[Alanna Paloma <[e-mail]>]

Authors,

IANA has updated its registry accordingly. We now consider AUTH48 complete:
https://www.rfc-editor.org/auth48/rfc9484

Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time.

Best regards,
RFC Editor/ap

> On Oct 17, 2023, at 8:44 AM, Alanna Paloma <[e-mail]> wrote:
> 
> 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
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>