Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 5 Jan 2019 21:45:57 -0800

Here's what I've come up with.  This is a diff between RFC7601 as published
and what I propose as RFC7601bis to resolve all of the DISCUSSes and most
of the COMMENTs from IESG review.  Please let me know if I've missed
anything.  I'll post it at the end of the coming week if there are no
issues raised.

http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.html

-MSK

On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov <[email-masked]>
wrote:

> On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote:
> > Murray, would you please copy the relevant IANA Considerations
> > sections from RFC 7601 into 7601bis and change the tenses
> > appropriately (perhaps just with a sentence in each subsection that
> > says, "The following was done in the previous edition of this
> > document, RFC 7601:", or some such
>
> Even better if you say something like "the following is unchanged from RFC
> 7601:".
>
> >), and then let's have a quick
> > working group review of the result?  (And, of course, change it back
> > to "obsoletes" rather than "updates".)
> >
> > As it's editorial, I'm sure we don't need to go back through any
> > approval process, and we can get the DISCUSS cleared and move forward.
>
> I agree. I think this is purely editorial, albeit an important issue for
> the final document.
>
> > Thanks,
> > Barry
> > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <[email-masked]>
> wrote:
> > >
> > > Hi all,
> > >
> > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> > > > I actually agree with this: I think the better answer is to go back
> to
> > > > "obsoletes" and to have this document include the details of what was
> > > > put in the registries before.  But the working group decided to do it
> > > > the other way, and there's been criticism in the past of ADs (and,
> so,
> > > > by extension, chairs) picking on this sort of stuff, so I decided to
> > > > let it go.  I'll let the IESG sort this one out, but I'll go on
> record
> > > > as saying what I think the better way to handle it is.
> > >
> > > I think incorporating older registrations is the cleaner way of
> dealing with Ben's & Benjamin's DISCUSSes, as then the document is self
> contained and there is no need for readers to see obsoleted RFCs. So this
> would be my preference.
> > >
> > > If the WG doesn't want to do this, then the document needs editing to
> be correct as per Benjamin's DISCUSS.
> > >
> > > Best Regards,
> > > Alexey
> > >
> > > > That said, I don't think it's a huge deal either way.
> > > >
> > > > Barry
> > > >
> > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <[email-masked]>
> wrote:
> > > > >
> > > > > Ben Campbell has entered the following ballot position for
> > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss
> > > > >
> > > > > When responding, please keep the subject line intact and reply to
> all
> > > > > email addresses included in the To and CC lines. (Feel free to cut
> this
> > > > > introductory paragraph, however.)
> > > > >
> > > > >
> > > > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > >
> > > > >
> > > > > The document, along with other ballot positions, can be found here:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/
> > > > >
> > > > >
> > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > DISCUSS:
> > > > >
> ----------------------------------------------------------------------
> > > > >
> > > > > This is mainly a process discuss. I share Alvaro's concern about
> this being
> > > > > marked as "updating" RFC7601, when it seem like a full
> replacement. I'm
> > > > > promoting it to a DISCUSS because I think this needs to be
> resolved before
> > > > > publication.
> > > > >
> > > > > The current structure will make it very difficult for readers to
> figure out
> > > > > which parts of each doc they need to worry about. I think it needs
> to either go
> > > > > back to "obsoleting" 7601, or it needs to be recast to just talk
> about the
> > > > > changes. Note that if the former path is chosen, the IANA
> considerations in
> > > > > 7601 will need to be copied forward.
> > > > >
> > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > COMMENT:
> > > > >
> ----------------------------------------------------------------------
> > > > >
> > > > > I mostly just reviewed the diff. Thank you for mostly avoiding
> unnecessary
> > > > > changes. That makes the diff tools much more useful than they are
> for bis
> > > > > drafts that make wholesale organization and stylistic changes.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Barry
> > > > --
> > > > Barry Leiba  ([email-masked])
> > > > http://internetmessagingtechnology.org/
> > > >
>

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 06 Jan 2019 02:27:24 -0500

I think this is generally good.  I, of course, have a few comments.

Hunk at "page 17, line 44":

Perhaps another sentence (more for completeness than anything) at the end of 
the new paragraph.  Something like, "Additionally, [RFC8463] added a new 
signing algorithm in DKIM, ed25519-sha256 and it is also useful to be able to 
distinguish such signatures to identify cryptographic algorithm specific 
failures."

That would also need a new informative reference to RFC 8463.

Hunk at "page 18, line 32":

"Note that in an EAI-formatted message, the "mailfrom" value can be expressed 
in UTF-8."

Isn't it more correct to say that the local part of the "mailfrom" value can 
be expressed in UTF-8?  The domain part is still a U-label as I understand it.  
The text as written is literally correct since the entire mailfrom is valid 
UTF-8, but I'm afraid it may be misleading.  As written, I could see it 
causing confusion relative to the guidance in Section 5.

Hunk at "page 21, line 21":

Same comment re UTF-8.

Hunk at "page 22, line 4":

Someone who has read the VBR RFC recently enough to remember should check and 
see if my UTF-8 comment applies here nor not.  I'm not sure either way.

Scott K

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Jan 2019 11:09:39 +0000

On Sun, Jan 6, 2019, at 5:45 AM, Murray S. Kucherawy wrote:
> Here's what I've come up with.  This is a diff between RFC7601 as
> published and what I propose as RFC7601bis to resolve all of the
> DISCUSSes and most of the COMMENTs from IESG review.  Please let me
> know if I've missed anything.  I'll post it at the end of the coming
> week if there are no issues raised.> 
> http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.htmlThis is looks good to me. One small ABNF glitch introduced:

>authres-header-field  = "Authentication-Results:" authres-payload
>
>authres-payload = "Authentication-Results:" [CFWS] authserv-id

You have "Authentication-Results:" twice now. I think you want to delete
it from authres-payload.
> 
> -MSK
> 
> On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov
> <[email-masked]> wrote:>> On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote:
>>  > appropriately (perhaps just with a sentence in each subsection
>>  > that>>  > says, "The following was done in the previous edition of this
>>  Even better if you say something like "the following is unchanged
>>  from RFC 7601:".>> 
>>  > working group review of the result?  (And, of course, change it
>>  > back>>  > to "obsoletes" rather than "updates".)
>>  > 
>>  > approval process, and we can get the DISCUSS cleared and move
>>  > forward.>> 
>>  I agree. I think this is purely editorial, albeit an important issue
>>  for the final document.>> 
>>  > Thanks,
>>  > Barry
>>  > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov
>>  > <[email-masked]> wrote:>>  > >
>>  > > Hi all,
>>  > >
>>  > > > I actually agree with this: I think the better answer is to go
>>  > > > back to>>  > > > "obsoletes" and to have this document include the details of
>>  > > > what was>>  > > > put in the registries before.  But the working group decided
>>  > > > to do it>>  > > > the other way, and there's been criticism in the past of ADs
>>  > > > (and, so,>>  > > > by extension, chairs) picking on this sort of stuff, so I
>>  > > > decided to>>  > > > let it go.  I'll let the IESG sort this one out, but I'll go
>>  > > > on record>>  > > > as saying what I think the better way to handle it is.
>>  > >
>>  > > dealing with Ben's & Benjamin's DISCUSSes, as then the document
>>  > > is self contained and there is no need for readers to see
>>  > > obsoleted RFCs. So this would be my preference.>>  > >
>>  > > If the WG doesn't want to do this, then the document needs
>>  > > editing to be correct as per Benjamin's DISCUSS.>>  > >
>>  > > Best Regards,
>>  > > Alexey
>>  > >
>>  > > > wrote:>>  > > > >
>>  > > > > When responding, please keep the subject line intact and
>>  > > > > reply to all>>  > > > > email addresses included in the To and CC lines. (Feel free
>>  > > > > to cut this>>  > > > > introductory paragraph, however.)
>>  > > > >
>>  > > > >
>>  > > > > Please refer to
>>  > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html>>  > > > > for more information about IESG DISCUSS and COMMENT
>>  > > > > positions.>>  > > > >
>>  > > > >
>>  > > > > The document, along with other ballot positions, can be
>>  > > > > found here:>>  > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/>>  > > > >
>>  > > > >
>>  > > > >
>>  > > > > ------------------------------------------------------------
>>  > > > > ---------->>  > > > > DISCUSS:
>>  > > > > ------------------------------------------------------------
>>  > > > > ---------->>  > > > >
>>  > > > > This is mainly a process discuss. I share Alvaro's concern
>>  > > > > about this being>>  > > > > marked as "updating" RFC7601, when it seem like a full
>>  > > > > replacement. I'm>>  > > > > promoting it to a DISCUSS because I think this needs to be
>>  > > > > resolved before>>  > > > > publication.
>>  > > > >
>>  > > > > The current structure will make it very difficult for
>>  > > > > readers to figure out>>  > > > > which parts of each doc they need to worry about. I think it
>>  > > > > needs to either go>>  > > > > back to "obsoleting" 7601, or it needs to be recast to just
>>  > > > > talk about the>>  > > > > changes. Note that if the former path is chosen, the IANA
>>  > > > > considerations in>>  > > > > 7601 will need to be copied forward.
>>  > > > >
>>  > > > >
>>  > > > > ------------------------------------------------------------
>>  > > > > ---------->>  > > > > COMMENT:
>>  > > > > ------------------------------------------------------------
>>  > > > > ---------->>  > > > >
>>  > > > > I mostly just reviewed the diff. Thank you for mostly
>>  > > > > avoiding unnecessary>>  > > > > changes. That makes the diff tools much more useful than
>>  > > > > they are for bis>>  > > > > drafts that make wholesale organization and stylistic
>>  > > > > changes.>>  > > > >
>>  > > > >
>>  > > >
>>  > > >
>>  > > > --
>>  > > > Barry
>>  > > > --

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 Jan 2019 10:54:37 +0100

On Sun 06/Jan/2019 06:45:57 +0100 Murray S. Kucherawy wrote:

> Here's what I've come up with.  This is a diff between RFC7601 as published and
> what I propose as RFC7601bis to resolve all of the DISCUSSes and most of the
> COMMENTs from IESG review.  Please let me know if I've missed anything.  I'll
> post it at the end of the coming week if there are no issues raised.
> 

I see sender-id still has full citizenship.  Now I'm not clear which will be
first, but my feeling is that rfc7601bis and
status-change-change-sender-id-to-historic are going to be published more or
less at the same time.

When a method is moved to historic, are the corresponding parameters in the
IANA registry moved to deprecated?  If yes, should the move be stated by which
document?

Thank you
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jan 2019 05:03:41 -0500

On Monday, January 14, 2019 10:54:37 AM Alessandro Vesely wrote:
> > DISCUSSes and most of the COMMENTs from IESG review.  Please let me know
> > if I've missed anything.  I'll post it at the end of the coming week if
> > there are no issues raised.
> > 
> IANA registry moved to deprecated?  If yes, should the move be stated by
> which document?

A quick look at Domainkeys in the registry and RFC 7601 will answer that 
question for you.  Let's not hold this up.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Jan 2019 09:16:16 -0500

> question for you.  Let's not hold this up.

+1.  This was not identified in IESG Review as something that needs fixing
so I'd just as soon not make more changes now.  If we keep changing it,
it's going to need another cycle through the working group.

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 14 Jan 2019 07:02:01 -0800

> it's going to need another cycle through the working group.

I had flagged the lack of deprecating Sender ID in my notes to Murray.
Since he did not comment back on that, I had assumed he was good with
ripping it all out (or marking it as obsolete).

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jan 2019 17:38:59 +0000

On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" <[email-masked]> wrote:
>>> > I see sender-id still has full citizenship.  Now I'm not clear
>which
>>> will be
>>> > status-change-change-sender-id-to-historic are going to be
>published
>>> more or
>>> > less at the same time.
>>> >
>>> > When a method is moved to historic, are the corresponding
>parameters in
>>> the

The registry update policy is expert review.  We won't need another RFC to deprecate Sender ID when the time comes.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 14 Jan 2019 10:06:02 -0800

> deprecate Sender ID when the time comes.

Understood, but I was thinking that cutting Sender ID mostly out of 7601bis
would be appropriate.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jan 2019 13:32:56 -0500

On Monday, January 14, 2019 10:06:02 AM Kurt Andersen wrote:
> > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" <[email-masked]>
> > 
> > wrote:
> > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman
> > >
> > ><[email-masked]>
> > >
> > >> wrote:
> > >>> > IANA registry moved to deprecated?  If yes, should the move be
> > >
> > >stated by
> > >
> > >>> > which document?
> > >>> 
> > >>> A quick look at Domainkeys in the registry and RFC 7601 will answer
> > >
> > >that
> > >
> > >> +1.  This was not identified in IESG Review as something that needs
> > >
> > >fixing
> > >
> > >> so I'd just as soon not make more changes now.  If we keep changing
> > >
> > >it,
> > >

So far we have not removed any registry entries, only marked them deprecated 
(domainkeys for example).  I don't think there's any particular rush to start 
now.

Scott K

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Jan 2019 18:40:09 +0000

> > Understood, but I was thinking that cutting Sender ID mostly out of 7601bis

I think removing them from 7601bis != removing them from the IANA registry.

> (domainkeys for example).  I don't think there's any particular rush to start 

Entries should never be removed from an IANA registry, as this would defeat one purpose of having a registry. They can only be marked historic/deprecated/obsolete, as appropriate for the registry.

Best Regards,
Alexey

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jan 2019 13:43:01 -0500

On Monday, January 14, 2019 06:40:09 PM Alexey Melnikov wrote:
> > > > The registry update policy is expert review.  We won't need another
> > > > RFC to
> > > > deprecate Sender ID when the time comes.
> > > 
> > So far we have not removed any registry entries, only marked them
> > deprecated (domainkeys for example).  I don't think there's any
> > particular rush to start now.
> 
> Entries should never be removed from an IANA registry, as this would defeat
> one purpose of having a registry. They can only be marked
> historic/deprecated/obsolete, as appropriate for the registry.

Right, but taking it out of 7601bis would leave the problem then of what's the 
appropriate reference in the registry, which, more generally, is how we got to 
the full text replacement of 7601.  Leaving it out of 7601bis would just 
replicate the problem that the latest update was created to fix.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 14 Jan 2019 16:20:05 -0800

> replicate the problem that the latest update was created to fix.

That depends on how it is done. I was proposing moving all the Sender ID
related content to an Appendix which documents it for posterity as
historical and otherwise removing all references elsewhere in the document
to Sender ID. That both obsoletes 7601 and deals with the deprecation.

--Kurt

---

From: Ben Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 21:51:39 -0600

Am I correct to assume the header and boilerplate changes are just artifacts of this being a temporary “draft-kucherawy...” draft rather than an actual revision to rfc7601bis?

Otherwise, this would address my DISCUSS.

Thanks!

Ben.

> On Jan 5, 2019, at 11:45 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Here's what I've come up with.  This is a diff between RFC7601 as published and what I propose as RFC7601bis to resolve all of the DISCUSSes and most of the COMMENTs from IESG review.  Please let me know if I've missed anything.  I'll post it at the end of the coming week if there are no issues raised.
> 
> http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.html <http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.html>
> 
> -MSK
> 
> On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
> Even better if you say something like "the following is unchanged from RFC 7601:".
> 
> I agree. I think this is purely editorial, albeit an important issue for the final document.
> 
> > Thanks,
> > Barry
> > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > > Hi all,
> > >
> > > > I actually agree with this: I think the better answer is to go back to
> > > > the other way, and there's been criticism in the past of ADs (and, so,
> > > > let it go.  I'll let the IESG sort this one out, but I'll go on record
> > > I think incorporating older registrations is the cleaner way of dealing with Ben's & Benjamin's DISCUSSes, as then the document is self contained and there is no need for readers to see obsoleted RFCs. So this would be my preference.
> > >
> > > If the WG doesn't want to do this, then the document needs editing to be correct as per Benjamin's DISCUSS.
> > >
> > > Best Regards,
> > > Alexey
> > >
> > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> > > > >
> > > > > When responding, please keep the subject line intact and reply to all
> > > > > email addresses included in the To and CC lines. (Feel free to cut this
> > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ <https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/>
> > > > >
> > > > >
> > > > >
> > > > > This is mainly a process discuss. I share Alvaro's concern about this being
> > > > > marked as "updating" RFC7601, when it seem like a full replacement. I'm
> > > > > promoting it to a DISCUSS because I think this needs to be resolved before
> > > > > publication.
> > > > >
> > > > > The current structure will make it very difficult for readers to figure out
> > > > > which parts of each doc they need to worry about. I think it needs to either go
> > > > > back to "obsoleting" 7601, or it needs to be recast to just talk about the
> > > > > changes. Note that if the former path is chosen, the IANA considerations in
> > > > > I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary
> > > > > changes. That makes the diff tools much more useful than they are for bis
> > > > Barry Leiba  ([email-masked] <mailto:[email-masked]>)
> > > > http://internetmessagingtechnology.org/ <http://internetmessagingtechnology.org/>
> > > >

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jan 2019 15:50:44 +0000

On Tue, Jan 15, 2019, at 3:51 AM, Ben Campbell wrote:
> Am I correct to assume the header and boilerplate changes are just
> artifacts of this being a temporary “draft-kucherawy...” draft rather
> than an actual revision to rfc7601bis?I believe so.
> 
>> On Jan 5, 2019, at 11:45 PM, Murray S. Kucherawy
>> <[email-masked]> wrote:>> 
>> week if there are no issues raised.>> 
>> http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.html>> 
>> -MSK
>> 
>> <[email-masked]> wrote:>>> On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote:
>>>  > that>>>  > says, "The following was done in the previous edition of this
>>>  from RFC 7601:".>>> 
>>>  > back>>>  > to "obsoletes" rather than "updates".)
>>>  > 
>>>  > As it's editorial, I'm sure we don't need to go back through any>>>  > approval process, and we can get the DISCUSS cleared and move
>>>  > forward.>>> 
>>>  I agree. I think this is purely editorial, albeit an important
>>>  issue for the final document.>>> 
>>>  > Thanks,
>>>  > Barry
>>>  > <[email-masked]> wrote:>>>  > >
>>>  > > Hi all,
>>>  > >
>>>  > > > I actually agree with this: I think the better answer is to
>>>  > > > go back to>>>  > > > "obsoletes" and to have this document include the details of
>>>  > > > what was>>>  > > > put in the registries before.  But the working group decided
>>>  > > > to do it>>>  > > > the other way, and there's been criticism in the past of ADs
>>>  > > > (and, so,>>>  > > > by extension, chairs) picking on this sort of stuff, so I
>>>  > > > decided to>>>  > > > let it go.  I'll let the IESG sort this one out, but I'll go
>>>  > > > on record>>>  > > > as saying what I think the better way to handle it is.
>>>  > >
>>>  > > obsoleted RFCs. So this would be my preference.>>>  > >
>>>  > > editing to be correct as per Benjamin's DISCUSS.>>>  > >
>>>  > > Best Regards,
>>>  > > Alexey
>>>  > >
>>>  > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell
>>>  > > > <[email-masked]> wrote:>>>  > > > >
>>>  > > > > Ben Campbell has entered the following ballot position for>>>  > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss
>>>  > > > >
>>>  > > > > reply to all>>>  > > > > email addresses included in the To and CC lines. (Feel free
>>>  > > > > to cut this>>>  > > > > introductory paragraph, however.)
>>>  > > > >
>>>  > > > >
>>>  > > > > Please refer to
>>>  > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html>>>  > > > > for more information about IESG DISCUSS and COMMENT
>>>  > > > > positions.>>>  > > > >
>>>  > > > >
>>>  > > > > found here:>>>  > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/>>>  > > > >
>>>  > > > >
>>>  > > > >
>>>  > > > > -----------------------------------------------------------
>>>  > > > > ----------->>>  > > > > DISCUSS:
>>>  > > > > -----------------------------------------------------------
>>>  > > > > ----------->>>  > > > >
>>>  > > > > about this being>>>  > > > > marked as "updating" RFC7601, when it seem like a full
>>>  > > > > replacement. I'm>>>  > > > > promoting it to a DISCUSS because I think this needs to be
>>>  > > > > resolved before>>>  > > > > publication.
>>>  > > > >
>>>  > > > > readers to figure out>>>  > > > > which parts of each doc they need to worry about. I think
>>>  > > > > it needs to either go>>>  > > > > back to "obsoleting" 7601, or it needs to be recast to just
>>>  > > > > talk about the>>>  > > > > changes. Note that if the former path is chosen, the IANA
>>>  > > > > considerations in>>>  > > > > 7601 will need to be copied forward.
>>>  > > > >
>>>  > > > >
>>>  > > > > -----------------------------------------------------------
>>>  > > > > ----------->>>  > > > > COMMENT:
>>>  > > > > -----------------------------------------------------------
>>>  > > > > ----------->>>  > > > >
>>>  > > > > avoiding unnecessary>>>  > > > > changes. That makes the diff tools much more useful than
>>>  > > > > they are for bis>>>  > > > > drafts that make wholesale organization and stylistic
>>>  > > > > changes.>>>  > > > >
>>>  > > > >
>>>  > > >
>>>  > > >
>>>  > > > --
>>>  > > > Barry
>>>  > > > --
> Email had 1 attachment:

>  * signature.asc 1k (application/pgp-signature)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Jan 2019 02:41:58 -0500

> That would also need a new informative reference to RFC 8463.

I'll take Alexey's direction here, but I'm uneasy adding new references and
text like this after IESG Review.

> see if my UTF-8 comment applies here nor not.  I'm not sure either way.

I'm less concerned about making these adjustments since they're just
refinements, so, done.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Jan 2019 03:20:11 -0500

> I'm less concerned about making these adjustments since they're just

Thanks.  This update addresses my concerns.

In the area of the tiniest of nits possible, in Section 2.2, did you really 
mean to add the second space after authres-header-field and before = in the 
ABNF?

Scott K