Subject: [nfsv4] AD Evaluation of draft-ietf-nfsv4-mv1-msns-update-03

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Feb 2019 19:55:07 -0600

Dear Author and Editor,

The NFSv4 working group tends to produce solid documents - thank you for
that - but since I'm doing AD Evaluation on a 100-page document that
updates a 600-page document, we can't be surprised that I had a few
questions ... please let me know how you'd like to proceed.

I'll mark this as Revised ID Required for now.

Thanks,

Spencer

This popped up from IDnits, and would be worth fixing before Last Call.

-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to
grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can
ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

(This one tends to get Discusses during IESG Evaluation)

The description of "trunking" appears (as best I can tell) appears 7 pages
into the document. Is there a reasonable reference you could provide for
the first use of the term in the Introduction? (Even a forward reference to
Section 3.1 would be an improvement)

Does this text

 o Some confusing text regarding changes in server_owner needs to be

                                                          ^^^^^^^^^^^
     clarified.

mean

 o Some confusing text regarding changes in server_owner has been

                                                          ^^^^^^^^
     clarified.

?

Does this text

 This document contains sections that propose additions to and other

                                      ^^^^^^^
  modifications of [RFC5661] as well as others that explain the reasons
  for modifications but do not directly affect existing specifications.

mean "specify additions", or "provide additions"? If approved, this
specification will no longer be proposing text changes - they'll be in
effect.

I can usually follow passive tense English in IETF specifications, but

 When a file system is present and becomes absent, clients can be

                                                           ^^^^^^
  given the opportunity to have continued access to their data, using a

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  different replica.

is just a bit too hand-wavish. Who/what is giving clients this opportunity?

This is a pretty mundane point, but in text like this (and there are other
similar occurrences):

4.5.1.  New section to be added as the first sub-section of Section 11.4
       of [RFC5661] to be entitled "Combining Multiple Uses in a Single
       Attribute"

it is not clear to me exactly where the added text goes - I'm guessing that
the added text becomes the new 11.4.1, pushing all other subsections of
11.4 down, but I'm not sure if that's what was intended. I just noticed
that
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-mv0-trunking-update-04
shows an explicit renumbering ("this section is now 11.4.1") being added to
similar insertions, which is likely more helpful for the area review teams,
reviewing ADs, the RFC Editor, and the eventual readers. That happened
during a recent IESG Evaluation, so it's especially likely to come up for
another NFSv4 draft ;-) ...

I'm lost in the "it"s in this text:

 o It may fetch the file system location attribute for the filesystem
     which will provide either the name of the server (which can be
     turned into a set of network addresses using DNS), or it will find
     a set of server-trunkable location entries which can provide the
     addresses specified by the server as desirable to use to access
     the file system in question.

I THINK this is (indentation is significant)

o  The client may fetch the file system location attribute for the
filesystem
     which will provide either

         the name of the server (which can be
         turned into a set of network addresses using DNS),

or the client will find a set of server-trunkable location entries which
can

         provide the
         addresses specified by the server as desirable to use to access
         the file system in question.

just following the text, but that's not making a lot of sense to me. Is "or
it will find" garbled? Or am I just lost here?

It's a nit, but

 Fs_locations_info provides a flag, FSLI4TF_RDMA flag.  indicating

                                                     ^ should be a comma.
  that RPC-over-RDMA support is available using the specified location
  entry.

I'm not entirely following

 Fs_locations_info provides a flag, FSLI4TF_RDMA flag.  indicating
  that RPC-over-RDMA support is available using the specified location
  entry.  This flag makes it for a convenient for a client wishing to
  use RDMA, to establish a TCP connection and then convert to use of
  RDMA.  After establishing a TCP connection, the step-up facility, can
  be used, if available, to convert that connection to RDMA mode.
  Otherwise, if RDMA availability is indicated, a new RDMA connection
  can be established and it can be bound to the session already
  established by the TCP connection, allowing the TCP connection to be
  dropped and the session converted to further use in RDMA node.

because I'm trying to guess why you would establish a TCP connection and
then convert that to RDMA mode, instead of establishing an RDMA connection
in the first place. A quick spin through Section 18.16 of [RFC5661] didn't
give me a lot of guidance here (but I did look).

It's a nit, but

 or locations of the file system can be determined by fetching the a
  locations attribute.  attribute.

                        ^^^^^^^^^^ is probably a cut and paste error.

It would be helpful to readers like me, if

 Generally, multi-server namespaces are for the most part uniform, in
  that the same data made available to one client at a given location
  in the namespace is made available to all clients at that location.
  However, as described above, there are facilities provided that allow

           ^^^^^^^^^^^^^^^^^^
  different clients to be directed different sets of data, to enable
  adaptation to such client characteristics as CPU architecture.

this cross-reference was a little more precise (is it "earlier in this
section", or "in Section M.N.O" - something like that).

This text,

 o Whenever a SEQUENCE operation is sent by a client to a server
     which generated state held on that client which is associated with
     a file system that is no longer accessible on the server at which
     it was previously available, a lease-migrated indication, in the

                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     form the SEQ4_STATUS_LEASE_MOVED status bit being set, appears in

     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

     the response.

wasn't easy for me to parse. Perhaps something like

 o Whenever a SEQUENCE operation is sent by a client to a server
     which generated state held on that client which is associated with
     a file system that is no longer accessible on the server at which
     it was previously available, the response will contain a
lease-migrated

                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

     indication, with the SEQ4_STATUS_LEASE_MOVED status bit being set.

     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm guessing

 o In the state merger case, it is possible that the server has not
     attempted Transparent State Migration, in which case state may
     have been lost without it being reflected in the SEQ4_STATUS bits.
     To determine whether this has happened, the client can use
     TEST_STATEID to check whether the stateids created on the source
     server are still accessible on the destination server.  Once a
     single stateid is found to have been successfully transferred, the
     client can conclude that Transparent State Migration was begun and
     any failure to transport all of the stateids will be reflected in
     the SEQ4_STATUS bits.  Otherwise. Transparent State Migration has

                                     ^ should this be a comma?
     not occurred.

but asking now, because there might be something else happening with this
text, if it's not a comma.

I couldn't parse this paragraph. I think the problem is in the first
phrase:

 o If information about the set of clients that have locking state

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     for the transferred file system, the destination server will be

     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     able to terminate the grace period once all such clients have
     reclaimed their locks, allowing normal locking activity to resume
     earlier than it would have otherwise.

It's a nit, but

 o For each lock type there will by type-specific information, such

                                   ^ be
     as share and deny modes for opens and type and byte ranges for
     byte-range locks and layouts.

If this matters,

 o If both EXCHANGE_ID requests were sent with RPCSEC_GSS ([RFC2203],
     [RFC5403], [RFC7861]) authentication and the server principal is
     the same for both targets, the equality of server scope is
     validated.  It is RECOMMENDED that two servers intending to share

                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     the same server scope also share the same principal name.

     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the reader would likely benefit from a sentence or two explaining why this
is RECOMMENDED, and/or what the consequences of not sharing the same
principal name are.

It's a nit, but

 o The cases of change which are very disruptive (e.g. change if

                                           "if" is likely "of" ^
     server scope) are not sufficiently distinguished from those that
     simply involve a change of trunking modes (i.e. change
     server_owner minor id)

---

From: David Noveck <[email-masked]>
Date: Sat, 2 Feb 2019 09:15:19 -0500

> since I'm doing AD Evaluation on a 100-page document that updates a
600-page document, we can't be surprised that
> I had a few questions

Actually, I'm only surprised that it was done so quickly.   Thanks.

> please let me know how you'd like to proceed.

I'll provide initial responses below.   If there turns out to be anything
controversial or difficult to resolve, I'll just note the issue now and
discuss it with my co-author.   Based on my initial scan of your comments,
my expectation is that a revised I-D could be provided in one to two weeks.

> This popped up from IDnits, and would be worth fixing before Last Call.

It seems that not fixing it is not really an option, much as I'd like to
sweep the whole thing under the rug :-(.

>     have contacted all the original authors

I'm not clear about the set of people within "all the original authors".
 If this referring to the authors of RFC5661, then it is just contacting
Spencer S and Mike Eisler, in addition to myself.  On the other hand, some
material from RFC3530 may have migrated to RFC5661, which mkes the poblem
more difficult.

> and they are all willing to grant
ignore
>     this comment.

I looked at BCP78 and it was not very clear what exactly I would be
agreeing to or asking other authors to agree to, beyond what one would
have agreed to before 11/10/2008.   BCP78 does  have a section entitled
"Changes since RFC 3968" but it isn't very helpful.

> If not, you may need to add the pre-RFC5378 disclaimer.

I looked in that document but I couldn't find the text of the needed
disclaimer.

> (This one tends to get Discusses during IESG Evaluation)

I think I can avoid that.

> The description of "trunking" appears (as best I can tell) appears 7
pages into the document. Is there a reasonable
> reference you could provide for the first use of the term in the
Introduction? (Even a forward reference to Section 3.1
> would be an improvement)

What I'm anticipating doing in -04 is prepending the following sentences to
the final paragraph of Section 1:

This document supplements facilities related to trunking, introduced in
[RFC5661].  For some important terminology regarding trunking, see Section
3.1.

Yes.  Will be fixed in -04.

> mean "specify additions", or "provide additions"? If approved, this
specification will no longer be proposing text changes > - they'll be in
effect.

Yes.  Will fix in -04.

>   given the opportunity to have continued access to their data, using a

At one level, it is the protocol that provides the ability  to communicate
the new location.  At another level it is the source and destination
servers that co-operate to effect the necessary handoff.

I anticipate rewriting the sentence as follows in -04:

When a file system is present and becomes absent, the NFSv4 protocol
provides a means by which clients can be given the opportunity to have
continued access to their data, using a different replica.

similar occurrences):
> it is not clear to me exactly where the added text goes - I'm guessing
that the added text becomes the new 11.4.1,
> pushing all other subsections of 11.4 down, but I'm not sure if that's
what was intended. I just noticed that >
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-mv0-trunking-update-04
shows an explicit renumbering ("this section is
> now 11.4.1") being added to similar insertions, which is likely more
helpful for the area review teams, reviewing ADs, the > RFC Editor, and the
eventual readers. That happened during a recent IESG Evaluation, so it's
especially likely to come > up for another NFSv4 draft ;-) ...

I can do something anaogous for this case by adding similar material to
Section 4.4 in -04.

For the othr cases, I can do something similar but I may have to create or
modify sections which describe reoganizations of various pieces of
RFC5661's Section 11.

filesystem
>     or the client will find a set of server-trunkable location entries
which can
> just following the text, but that's not making a lot of sense to me.

:-(

> Is "or it will find" garbled?

I don't think so.

> Or am I just lost here?

I don't think so, but since you feel lost, I'l propose a rewrite and see if
that clarifies things.

How about:

The client may fetch the file system location attribute for the
filesystem.  This will provide either:

   - The name of the server (which can be turned into a set of network
addresses using DNS).

   - A set of server-trunkable location entries specified by the server as
desirable to use to access the file system in      question.

>
>     or the client will find a set of server-trunkable location entries
which can    rewrite and see how that strikes you.

>                                                     ^ should be a comma.

Yes.  Will fix in -04.

>   that RPC-over-RDMA support is available using the specified location

This is true.

>This flag makes it for a convenient for a client wishing to

This would make it convenient, if server implemented it, but it turns out
they generally don't.   Still, they could do so.

> because I'm trying to guess why you would establish a TCP connection and
then convert that to RDMA mode,
> instead of establishing an RDMA connection in the first place.

Although you have been successful in guessing up to now, it is not
surprising that you can't guess this, as it depends on some of the history
of RDMA in the IETF.

> A quick spin through Section 18.16 of [RFC5661] didn't give me a lot of
guidance here (but I did look).

It doesn't explain why this was put in, but I'm guessing that, when it was
written, it seemrd not to require explanation.  At that time, when RDMA was
discussed, it was assumed you were referring to iWarp.  In the contect of
iWarp, stepping a connection from TCP to RDMA is natural, since you are
adding an RDMA facility to an existing TCP connection and there is no point
in tearing down the TCP connection and then establishing a new one.   Now,
given that use of IB and roCE are more common, Inerest in this has waned,
since non-iWarp implementations cannot use this fcility and iplementers may
not want to  invest in an iWarp-only facility.

 >                        ^^^^^^^^^^ is probably a cut and paste error.

Probably.  In any case, it will be fixed in -04.

Actually the reference is wrong rather than being (only) imprecise.  It
should be section 11.10.3 of [RFC5661].  Will fix in -04.

lease-migrated
 >     indication, with the SEQ4_STATUS_LEASE_MOVED status bit being set.

Seems clearer.  Will pick up for -04

>                                     ^ should this be a comma?

It should.  Will fix in -04.

 > o  If information about the set of clients that have locking state

It should be "If information about the set of clients that have locking
state for the transferred file system is made available".  Will fix in -04.

>  o  For each lock type there will by type-specific information, such

In -04, will be "for each lock type, there will be type-specfic
information,".

> the reader would likely benefit from a sentence or two explaining why
this is RECOMMENDED, and/or what the
> consequences of not sharing the same principal name are.

Right now, I'm not sure.  This text was copied over from RFC5661.

>  o  The cases of change which are very disruptive (e.g. change if

It will by "of" in -04.

>      simply involve a change of trunking modes (i.e. change

On Fri, Feb 1, 2019 at 8:55 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> it is not clear to me exactly where the added text goes - I'm guessing
> that the added text becomes the new 11.4.1, pushing all other subsections
> of 11.4 down, but I'm not sure if that's what was intended. I just noticed
> that
> just following the text, but that's not making a lot of sense to me. Is
> "or it will find" garbled? Or am I just lost here?
>
> It's a nit, but
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 2 Feb 2019 12:11:38 -0600

> Right now, I'm not sure.  This text was copied over from RFC5661.

IIUC, this is saying that two physical entities that share the same
Kerberos credentials are clearly identified as being "logically equivalent"
to the client by virtue of the authentication exchange, eliminating any
need for some other "out-of-band" (from the point of view of the first
exchange) way to indicate that the NFS servers have the same scope.  So the
executive summary is "the client logic is simpler this way".

-Ben

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Feb 2019 12:13:02 -0600

So, starting with Benjamin's response (for which, thank you!),

> executive summary is "the client logic is simpler this way".

So, if it is correct to say something like

 o  If both EXCHANGE_ID requests were sent with RPCSEC_GSS ([RFC2203],
   [RFC5403], [RFC7861]) authentication and the server principal is
    the same for both targets, the equality of server scope is
    validated.  It is RECOMMENDED that two servers intending to share
    the same server scope also share the same principal name, <unless
    clients can use some out-of-band mechanism to confirm that the servers
    share the same scope>.

the people who do a -bis revision of this draft at some point in the future
would probably appreciate having that background :-)

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Feb 2019 12:19:38 -0600

Hi, David,

> my expectation is that a revised I-D could be provided in one to two weeks.

I'm not seeing any of your responses that worry me, so please proceed in
that direction, and I'll chase down the details on "pre-RFC5378" work, and
follow up in a separate email, most likely today.

Thanks for the quick response!

Spencer (D)

> What I'm anticipating doing in -04 is prepending the following sentences
> to the final paragraph of Section 1:
>
> >This is a pretty mundane point, but in text like this (and there are
> other similar occurrences):
> >
> I don't think so, but since you feel lost, I'l propose a rewrite and see
> if that clarifies things.
>
> How about:
>
> > but asking now, because there might be something else happening with
> this text, if it's not a comma.
>
>
>> pages into the document. Is there a reasonable reference you could provide
>> for the first use of the term in the Introduction? (Even a forward
>> reference to Section 3.1 would be an improvement)
>>
>> Does this text
>>
>> This is a pretty mundane point, but in text like this (and there are
>> other similar occurrences):
>>
>> this is RECOMMENDED, and/or what the consequences of not sharing the same
>> principal name are.
>>
>> It's a nit, but
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Feb 2019 13:38:17 -0600

Hi, David,

> sweep the whole thing under the rug :-(.

Yeah, I agree. Actual fix is further down, but let's see if you need it,
first.

> material from RFC3530 may have migrated to RFC5661, which mkes the poblem

So, Spencer D's view of the world is, it's good to ask "original authors"
about this sooner, rather than later, because it only gets harder to ask
them as time passes (people change contact information, retire, and even
die, all of which gets in the way of asking).

If you are OK contacting Spencer S and Mike and confirming that they are
willing to grant permission as per BCP 78, and asking if there is material
from previous RFCs with other authors in RFC 5661, that would be great.

> "Changes since RFC 3968" but it isn't very helpful.

For the purposes of this discussion, I'm inclined to agree.

I believe this is the explanation you're asking about, which is about
halfway down the list of changes:

   The right to produce derivative works provided by the Contributor to
   the IETF Trust is not limited to being within the IETF Standards
   Process.

So that, if someone wanted to use material from RFC5661 in a document
that's not produced within the IETF standards process, the original authors
haven't actually given that permission, not least because no one ever asked
them for that permission. The current rights granted by authors would allow
(for instance) an IRTF research group to include this text in an
Experimental RFC.

If it turns out that including the pre-RFC5378 disclaimer is more
tractable, that's fine, too - the intended RFC Status for this draft is
Proposed Standard, which the original authors would have already agreed to.

> I looked in that document but I couldn't find the text of the needed

Somewhat unhelpfully, that's in the various versions of the TLP that exist
as links on that page. What I'm seeing from the 5.0 version (most recent
version) at https://trustee.ietf.org/license-info/IETF-TLP-5.htm, is

If an IETF Contribution contains pre-5378 Material as to which the IETF
Trust has not been granted, or may not have been granted, the necessary
permissions to allow modification of such pre-5378 Material outside the
IETF Standards Process:

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this material may
not have granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an adequate
license from the person(s) controlling the copyright in such materials,
this document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to translate it
into languages other than English.

Does this help?

Spencer D

---

From: David Noveck <[email-masked]>
Date: Tue, 5 Feb 2019 04:54:16 -0500

> Does this help?

Yes, but I've decided I might as well just include The waiver in -04.

Regarding contacting Spencer S and Mike Eisler, it occus to me that thay
have already agreed to the granting of BCP78 rights with regard to RFC5661
since it was published in January 2010 (i.e.way after November 2008).
 With regard to possible contributions by others, this document was
published without the waiver, so it appears that, at least at that time,
there was felt to be sufficient evidence that such permission had been
granted for all contribution included in RFC5661.

I find it hard to conceive of any contribution appearing in
draft-ietf-nfsv4-mv1-msns-update, which was not either:
a) first made publicly available after November 10, 2008, or
b) included in RFC5661.

However, I cannot say definitely that no such contributions exist.

It occurs to me that we have no indication of why, specifically, IDnits
decided that such contributions might exist, and that trying to get that
information is unlikly to be worthwhile.

As a result, I will be including the waiver in -04.  After all, the waiver
says such contributions "may" exist and they indeed might, even though I
have no idea what they might be.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 5 Feb 2019 07:18:24 -0600

Hi, David,

> granted for all contribution included in RFC5661.

Including the waiver works for me, and the working group is copied on our
email, so anyone who has more knowledge about the history than we do has an
opportunity to provide input.

I'm not a copyright genius, but I THINK the key dates aren't when RFC 5661
was published, but when text that appeared in
https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29 was
contributed (potentially as early as 2005). We ask authors to verify that
they are granting rights to create derivative works when drafts are
submitted, and (at least the last time I did AUTH48 on one of my RFCs)
authors aren't asked to verify those grants again during AUTH48.

This would be a bigger issue if someone wanted to create derivative works
outside the IETF standards process, but as long as NFSv4 is chartered and
is producing standards-track versions of NFSv4, the previous version of the
BCP covered those rights.

So, unless someone enlightens us (either during Last Call or IESG
Evaluation), I think we're good.

Thanks for thinking this through.

Spencer

>>> I'll provide initial responses below.   If there turns out to be
>>> anything controversial or difficult to resolve, I'll just note the issue
>>> now and discuss it with my co-author.   Based on my initial scan of your
>>> comments, my expectation is that a revised I-D could be provided in one to
>>> two weeks.
>>>
>>> I'm not clear about the set of people within "all the original
>>> authors".   If this referring to the authors of RFC5661, then it is just
>>> contacting Spencer S and Mike Eisler, in addition to myself.  On the other
>>> hand, some material from RFC3530 may have migrated to RFC5661, which mkes
>>> the poblem more difficult.
>>>
>>
>> Somewhat unhelpfully, that's in the various versions of the TLP that
>> exist as links on that page. What I'm seeing from the 5.0 version (most
>> recent version) at https://trustee.ietf.org/license-info/IETF-TLP-5.htm,
>> is
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 5 Feb 2019 12:09:00 -0600

Hi, David,

I saw that you've submitted -04, and the diffs work for me. Do you have any
other changes, before Last Call?

Thanks,

Spencer

On Tue, Feb 5, 2019 at 7:18 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> As a result, I will be including the waiver in -04.  After all, the
>> waiver says such contributions "may" exist and they indeed might, even
>> though I have no idea what they might be.
>>
>>>> It seems that not fixing it is not really an option, much as I'd like
>>>> to sweep the whole thing under the rug :-(.
>>>>
>>>
>>> So, Spencer D's view of the world is, it's good to ask "original
>>> authors" about this sooner, rather than later, because it only gets harder
>>> to ask them as time passes (people change contact information, retire, and
>>> even die, all of which gets in the way of asking).
>>>
>>>> >     the BCP78 rights to the IETF Trust, then this is fine, and you
>>>> can ignore
>>>> >     this comment.
>>>>

---

From: David Noveck <[email-masked]>
Date: Tue, 5 Feb 2019 13:10:34 -0500

I think it is ready to go.

On Tue, Feb 5, 2019 at 1:09 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Hi, David,
>
> I saw that you've submitted -04, and the diffs work for me. Do you have
> any other changes, before Last Call?
>
> Thanks,
>
> Spencer
>
>> I'm not a copyright genius, but I THINK the key dates aren't when RFC
>> 5661 was published, but when text that appeared in
>>>> Yeah, I agree. Actual fix is further down, but let's see if you need
>>>> it, first.
>>>>
>>>> If you are OK contacting Spencer S and Mike and confirming that they
>>>> are willing to grant permission as per BCP 78, and asking if there is
>>>> material from previous RFCs with other authors in RFC 5661, that would be
>>>> great.
>>>>
>>>>