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

[Amanda Baber via RT <[e-mail]>]

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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
> >
> >
> >
> >
> >