Subject: [mile] AD Review of draft-ietf-mile-rolie

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 25 Sep 2017 15:52:35 -0400

Hello,

Thank you for your work on:

The draft has come a long way and the effort that went into it shows!
I found a ew cobwebs in my review that should be easy to fix with as I
tried to give the updated equivalent solutions.

Please let me know if you have any questions about my review.

Introduction:

Last paragraph, first sentence:
S/In for new types/For new types/
This first sentence is a run-on, so please fix that as well.

Section 5.3:

This text may have been written before RFC7525 was written, but that
can and should be referenced for best practices in implementing TLS
1.2.  If you mention TLS 1.3, you may want to recommend that 0-RTT is
not used as there is a replay attack that is possible with that
option.

Section 5.4
If you keep SAML as your example federated authentication system, you
will need a reference.  Is that the most likely option to be used?  I
would say yes a few years ago, but I’m not sure at the moment.

Section 7.1, Last paragraph, first sentence, there’s a typo:
OLD:
   “This document does not specific any information types.”
NEW:
    This document does not specify any information types.

IANA Considerations:

RFC8126 obsoleted RFC5226, the specification required is basically the
same.  I also think it’s prudent to get a few people on the hook for
DE so there is an answer.  As such a tweak to the wording would be
helpful.  I do think it’s a good idea to route the request to the
mailing list, so I’m not suggesting any changes there (to be clear).
We can name a few people to cover vacations or busy periods.

Security Considerations Section:
There are 3 experimental HTTPAuth types that are more secure than
Basic and digest.  HOBA and SCRAM to name 2 of them.  Here’s the link
to the registry with them listed and the RFCs:
https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml.
reworking the text in paragraph 3 to mention these as options would be
good.

You might be asked for a reference to HTTP Auth and there’s no
specific document to cover all the types, just the registry.  HTTP
Basic and Digest were updated with considerably expanded security
considerations sections, so you could point to those two and then pick
one of the experimental ones perhaps before naming other types?

For the federated authentication, could OAuth/JWT be used?  It would
be a more current solution.

Third to last paragraph, if JSON and other data formats are to be
supported (which I believe is the case), then you should also mention
one other option like what JOSE offers for encryption and signing.
JWE - RFC7516, JWS - RFC7515, JWK - RFC7517, and JWA- RFC7518.  You
probably don’t need to mention the last 2 in an example style
sentence.

In the privacy considerations, the requirement for TLS is also a
mitigator for the problems listed in the second and third paragraph.
It’s worth mentioning that as I’m sure questions will be raised if
it’s not stated again.

Ack section: Do you need to add packs for recent reviews too?

IDNITS:

Please check the idnits and clear up issues.  RFC2141 is referenced,
is that correct as it's been obsoleted?  It was recently replaced by
RFC8141, so this was likely a timing issue.

I am tentatively putting this in the telechat for 10/26/17, if this is
an issue, we can bump it out until after Singapore.  If it's not,
getting the updates done by end of this week will give a good amount
of time for you to address last call comments before the IESG review
starts.

Thanks again!
-- 

Best regards,
Kathleen

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Tue, 26 Sep 2017 17:24:22 +0000

Kathleen,

Thanks for the review and the prepared solutions for the comments, it helps save a ton of time. All comments were addressed and there were no questions, I'm posting the new version now. I've put my responses inline with descriptions of how the issues were dealt with.

Thanks,
Stephen

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Kathleen 
> Moriarty
> Sent: Monday, September 25, 2017 3:53 PM
> To: MILE IETF <[email-masked]>
> Subject: [mile] AD Review of draft-ietf-mile-rolie
> 
> Hello,
> 

Typo fixed and sentence split into two.

> not used as there is a replay attack that is possible with that option.

RFC 7525 referenced for TLS 1.2 implementation, recommendation made to avoid 0-RTT if TLS 1.3 is being used.

> would say yes a few years ago, but I’m not sure at the moment.

Removed explicit reference to SAML, a more explicit discussion on SAML already exists in the Security Consideration section and fits better there.

>     This document does not specify any information types.

Changed.

> IANA Considerations:
> 
> RFC8126 obsoleted RFC5226, the specification required is basically the same.
> I also think it’s prudent to get a few people on the hook for DE so 
> there is an answer.  As such a tweak to the wording would be helpful.  
> I do think it’s a good idea to route the request to the mailing list, 
> so I’m not suggesting any changes there (to be clear).

All RFC5226 references changed to RFC8126. Added explicit names for people to be assigned to DE status if need be.

> one of the experimental ones perhaps before naming other types?

References added to the Authentication Scheme Registry as well as for HTTP basic, digest, HOBA, and SCRAM. Some text was added to mention the additional options.

> be a more current solution.

Reference to OAuth added to security considerations.

> probably don’t need to mention the last 2 in an example style sentence.

Reference to JWE, JWS, and XMLDSig added in security considerations.

> It’s worth mentioning that as I’m sure questions will be raised if 

Noted that proper use of TLS would mitigate these issues.

> RFC8141, so this was likely a timing issue.

Reference updated to RFC8141. Document ran through XML2RFC and IDNITS and cleared of issues. Two warnings are present in XML2RFC, one is due to a IANA comment that will be removed, and the other is a non-issue formatting warning. In IDNITs, there are a number of comments that are also non-issues regarding including additional text alongside the 2119 boilerplate.

> of time for you to address last call comments before the IESG review starts.
> 
> Thanks again!
> --
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Sep 2017 14:47:29 -0400

Hi Stephen,

Thanks for the quick update!  I have a couple more nits, thanks.

> RFC 7525 referenced for TLS 1.2 implementation, recommendation made to avoid 0-RTT if TLS 1.3 is being used.

Great, thanks. Please add a reference to TLS 1.3 draft-ietf-tls-tls13

> Removed explicit reference to SAML, a more explicit discussion on SAML already exists in the Security Consideration section and fits better there.

Good, thanks!

> All RFC5226 references changed to RFC8126. Added explicit names for people to be assigned to DE status if need be.

DE names should be removed from the draft as these can change over
time.  I'll confirm the names with the chairs and add them into the
ballot text for it to be a management item on the telechat.

> References added to the Authentication Scheme Registry as well as for HTTP basic, digest, HOBA, and SCRAM. Some text was added to mention the additional options.

Looks good, thanks.

> Reference to OAuth added to security considerations.

This should be OAuth and JWT as OAuth by itself is just authorization.

> Reference to JWE, JWS, and XMLDSig added in security considerations.

Great, thanks!

> Noted that proper use of TLS would mitigate these issues.

Thanks!

>> Ack section: Do you need to add packs for recent reviews too?

Didn't see I had a typo there.  Should any recent reviewers be added
to the acknowledgment section?

> Reference updated to RFC8141. Document ran through XML2RFC and IDNITS and cleared of issues. Two warnings are present in XML2RFC, one is due to a IANA comment that will be removed, and the other is…

Thank you!

Kathleen

-- 

Best regards,
Kathleen

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Wed, 27 Sep 2017 14:58:24 +0000

Kathleen,

I've put my responses inline, thanks for catching these nits. I've attached the new -10 version XML with the compiled HTML format, I'll upload this version to datatracker by the end of the week if there are no more changes. 

Thanks,
Stephen

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Tuesday, September 26, 2017 2:47 PM
> To: Banghart, Stephen A. (Fed) <[email-masked]>
> Cc: MILE IETF <[email-masked]>
> Subject: Re: [mile] AD Review of draft-ietf-mile-rolie
> 
> Hi Stephen,
> 
> > Thanks for the review and the prepared solutions for the comments, it
> helps save a ton of time. All comments were addressed and there were no
> questions, I'm posting the new version now. I've put my responses inline
> with descriptions of how the issues were dealt with.
> >
> > Thanks,
> > Stephen
> >
> >> I found a ew cobwebs in my review that should be easy to fix with as
> >> I tried to give the updated equivalent solutions.
> >>

Added reference to the TLS 1.3 draft.

> > Removed explicit reference to SAML, a more explicit discussion on SAML
> already exists in the Security Consideration section and fits better there.
> 
> Good, thanks!
> 
> >
> same.
> > All RFC5226 references changed to RFC8126. Added explicit names for
> people to be assigned to DE status if need be.
> 
> DE names should be removed from the draft as these can change over time.
> I'll confirm the names with the chairs and add them into the ballot text for it
> to be a management item on the telechat.

Names removed from draft, and text regarding the suggestion of any particular people removed. Let us know what needs to be done when the time comes (if anything) for the DE process, I'm regrettably ignorant on how it works.

> >> reworking the text in paragraph 3 to mention these as options would
> >> be good.
> >>
> >> considerations sections, so you could point to those two and then
> >> pick one of the experimental ones perhaps before naming other types?
> >>
> >
> > References added to the Authentication Scheme Registry as well as for
> HTTP basic, digest, HOBA, and SCRAM. Some text was added to mention the
> additional options.
> 
> Looks good, thanks.
> 
> >
> >

Added reference (and text) for JWT alongside OAuth, thanks for catching this.

> Didn't see I had a typo there.  Should any recent reviewers be added to the
> acknowledgment section?

The original names here were added by John Fields during the original work on the draft, we've had such great review from both within the WG and outside of it since then that naming anyone in particular would leave out the wealth of people that made this draft what it is today.

> > Reference updated to RFC8141. Document ran through XML2RFC and
> IDNITS and cleared of issues. Two warnings are present in XML2RFC, one is
> due to a IANA comment that will be removed, and the other is a non-issue
> formatting warning. In IDNITs, there are a number of comments that are also
> non-issues regarding including additional text alongside the 2119 boilerplate.
> 
> Thank you!
> 
> Kathleen
> 
> >
> >> I am tentatively putting this in the telechat for 10/26/17, if this
> >> is an issue, we can bump it out until after Singapore.  If it's not,

---

From: John Field <[email-masked]>
Date: Wed, 27 Sep 2017 12:53:56 -0400

Hi all,

Thanks, Stephen.  I reviewed the -10 and found a few nits:

4.  Background and motivation

"ROLIE seeks to address this need by providing three major information
sharing benefits:"

The subsequent list actually contains four items.

The last item in the list is:

Information discovery and navigation:ROLIE provides a number of mechanisms
to allow clients to programmtically discover

typo:  programmtically -> "programmatically"

8.2  and 8.3

occurrences of   [TO BE REMOVED....]

Otherwise it looks good.

Agreed on the Acknowledgements section. At this point there have been so
many additional people who have made valuable contributions, it may be
infeasible to list them. Best to remove, in fairness to all.

Regards,
John

On Wed, Sep 27, 2017 at 10:58 AM, Banghart, Stephen A. (Fed) <
[email-masked]> wrote:

> Kathleen,
>
> I've put my responses inline, thanks for catching these nits. I've
> attached the new -10 version XML with the compiled HTML format, I'll upload
> this version to datatracker by the end of the week if there are no more
> changes.
>
> Thanks,
> Stephen
>
> Names removed from draft, and text regarding the suggestion of any
> particular people removed. Let us know what needs to be done when the time
> comes (if anything) for the DE process, I'm regrettably ignorant on how it
> works.
>
> > >
> > >>
> The original names here were added by John Fields during the original work
> on the draft, we've had such great review from both within the WG and
> outside of it since then that naming anyone in particular would leave out
> the wealth of people that made this draft what it is today.
>
> > >>
> > >> IDNITS:
> > >>

-- 

John P. Field | Security PM | Pivotal

Direct: (908) 962-3394 | jfield@ <[email-masked]>pivotal.io

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Sep 2017 12:58:28 -0400

Thanks for the additional review, John.  Inline.

> infeasible to list them. Best to remove, in fairness to all.

A broad statement should be made IMO, I wouldn't leave it blank.

Best regards,
Kathleen

>
> Regards,
> John
>
> On Wed, Sep 27, 2017 at 10:58 AM, Banghart, Stephen A. (Fed)
> Direct: (908) 962-3394 | [email-masked]

-- 

Best regards,
Kathleen

---

From: John Field <[email-masked]>
Date: Wed, 27 Sep 2017 14:22:35 -0400

>>A broad statement should be made IMO, I wouldn't leave it blank.

No problem. A general acknowledgement is a great to recognize that this was
a genuine community effort.

John

On Wed, Sep 27, 2017 at 12:58 PM, Kathleen Moriarty <
[email-masked]> wrote:

> >> > > RFC 7525 referenced for TLS 1.2 implementation, recommendation made
> to
> >> > avoid 0-RTT if TLS 1.3 is being used.
> >> >
> time.
> >> > I'll confirm the names with the chairs and add them into the ballot
> text
> >> > for it
> to
> >> > the

--

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 28 Sep 2017 14:58:40 +0000

John,

Thanks for the additional nits review! I’ve changed “three” to “four” on the first issue and fixed the misspelling for the second issue. The “[TO BE REMOVED]” parts of the IANA considerations are to be removed by IANA once they complete their setup process for the registries.

I’ve added a general statement of thanks to the acknowledgment section, take a look and let me know if this is acceptable to you.

I’ve attached the update -10 version.

Thanks,
Stephen

From: John Field [mailto:[email-masked]]
Sent: Wednesday, September 27, 2017 2:23 PM
To: Kathleen Moriarty <[email-masked]>
Cc: Banghart, Stephen A. (Fed) <[email-masked]>; MILE IETF <[email-masked]>
Subject: Re: [mile] AD Review of draft-ietf-mile-rolie

>>A broad statement should be made IMO, I wouldn't leave it blank.

No problem. A general acknowledgement is a great to recognize that this was a genuine community effort.

John

On Wed, Sep 27, 2017 at 12:58 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the additional review, John.  Inline.

Best regards,
Kathleen

> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Kathleen,
>>
>> > From: Kathleen Moriarty [mailto:[email-masked]<mailto:[email-masked]>]
>> > To: Banghart, Stephen A. (Fed) <[email-masked]<mailto:[email-masked]>>
>> > Cc: MILE IETF <[email-masked]<mailto:[email-masked]>>
>> > <[email-masked]<mailto:[email-masked]>> wrote:
>> > > Kathleen,
>> > >
>> > >> From: mile [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kathleen
>> > >> Moriarty
>> > >> To: MILE IETF <[email-masked]<mailto:[email-masked]>>
>> > >> https://www.iana.org/assignments/http-authschemes/http-<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fhttp-authschemes%2Fhttp-&data=02%7C01%7Cstephen.banghart%40nist.gov%7C0cb0295be08c48c6166b08d505d4bb3d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636421333604149006&sdata=1WEH1ev%2FAe%2FlD8qYfJc1MXbWDUN4%2F%2B3uJTVjxuKCMOU%3D&reserved=0>
>> > >> authschemes.xhtml.
>> > >> [email-masked]<mailto:[email-masked]>
>> > >> https://www.ietf.org/mailman/listinfo/mile<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghart%40nist.gov%7C0cb0295be08c48c6166b08d505d4bb3d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636421333604149006&sdata=cJL53TUarWUfFxLz2AsgpFczRYrDxcyvQXyb613hODY%3D&reserved=0>
>> >
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Kathleen
>>
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/mile<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghart%40nist.gov%7C0cb0295be08c48c6166b08d505d4bb3d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636421333604159015&sdata=m6ZslRRpTai0k0LDi7ijH%2Be381iiDJ8BhczsBWc5o5M%3D&reserved=0>
>>
>
>
>
> --
>
> Direct: (908) 962-3394<tel:%28908%29%20962-3394> | [email-masked]<mailto:[email-masked]>

--

Best regards,
Kathleen

--

Direct: (908) 962-3394 | jfield@<mailto:[email-masked]>pivotal.io<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpivotal.io&data=02%7C01%7Cstephen.banghart%40nist.gov%7C0cb0295be08c48c6166b08d505d4bb3d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636421333604159015&sdata=1z%2FYONxsGBzFUvBoLevvnow%2BdSpzW%2BLI02gvbwMt%2FR4%3D&reserved=0>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Sep 2017 11:03:25 -0400

Please let me know when it is posted and ready and I'll kick off IETF last call.

Thank you,
Kathleen

On Thu, Sep 28, 2017 at 10:58 AM, Banghart, Stephen A. (Fed)
<[email-masked]> wrote:
> John,
>
>
>
> Thanks for the additional nits review! I’ve changed “three” to “four” on the
> first issue and fixed the misspelling for the second issue. The “[TO BE
> REMOVED]” parts of the IANA considerations are to be removed by IANA once
> they complete their setup process for the registries.
>
>
>
> I’ve added a general statement of thanks to the acknowledgment section, take
> a look and let me know if this is acceptable to you.
>
>
>
> On Wed, Sep 27, 2017 at 12:58 PM, Kathleen Moriarty
> <[email-masked]> wrote:
>

-- 

Best regards,
Kathleen

---

From: John Field <[email-masked]>
Date: Thu, 28 Sep 2017 11:32:09 -0400

"Acknowledgements" Looks good to me.  Nicely done.

John

On Thu, Sep 28, 2017 at 11:03 AM, Kathleen Moriarty <
[email-masked]> wrote:

> >>> > IDNITS and cleared of issues. Two warnings are present in XML2RFC,
> one
> >>> > is
> >>> > formatting warning. In IDNITs, there are a number of comments that
> are
> >>> > also

--

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 29 Sep 2017 14:32:50 +0000

Kathleen,

The final version (-10) has been posted. Thanks again to you (and John) for catching those nits.

Thanks,
Stephen

> Sent: Thursday, September 28, 2017 11:03 AM
> Cc: John Field <[email-masked]>; MILE IETF <[email-masked]>
> > Thanks for the additional nits review! I’ve changed “three” to “four”
> > on the first issue and fixed the misspelling for the second issue. The
> > “[TO BE REMOVED]” parts of the IANA considerations are to be removed
> > by IANA once they complete their setup process for the registries.
> >
> >
> >
> > I’ve added a general statement of thanks to the acknowledgment
> > section, take a look and let me know if this is acceptable to you.
> >
> >
> >
> >> "ROLIE seeks to address this need by providing three major
> >> information sharing benefits:"
> >>
> >> Information discovery and navigation:ROLIE provides a number of
> >> mechanisms to allow clients to programmtically discover
> >>
> >> Agreed on the Acknowledgements section. At this point there have been
> >> so many additional people who have made valuable contributions, it
> >> may be infeasible to list them. Best to remove, in fairness to all.
> >
> >>> attached the new -10 version XML with the compiled HTML format, I'll
> >>> upload this version to datatracker by the end of the week if there
> >>> are no more changes.
> >>>
> >>> Thanks,
> >>> Stephen
> >>>
> >>> > helps save a ton of time. All comments were addressed and there
> >>> > were no questions, I'm posting the new version now. I've put my
> >>> > responses inline with descriptions of how the issues were dealt
> >>> > with.
> >>> > >
> >>> > > Thanks,
> >>> > > Stephen
> >>> > >
> >>> > >> I found a ew cobwebs in my review that should be easy to fix
> >>> > >> with as I tried to give the updated equivalent solutions.
> >>> > >>
> >>> > >> S/In for new types/For new types/ This first sentence is a
> >>> > >> run-on, so please fix that as well.
> >>> > >>
> >>> > >
> >>> > >> This text may have been written before RFC7525 was written, but
> >>> > >> that can and should be referenced for best practices in
> >>> > >> implementing TLS 1.2.  If you mention TLS 1.3, you may want to
> >>> > >> recommend that 0-RTT is not used as there is a replay attack
> >>> > >> that is possible with that option.
> >>> > >
> >>> > > RFC 7525 referenced for TLS 1.2 implementation, recommendation
> >>> > > made to
> >>> > >> If you keep SAML as your example federated authentication
> >>> > >> system, you will need a reference.  Is that the most likely
> >>> > >> option to be used?
> >>> > >> I
> >>> > >> I also think it’s prudent to get a few people on the hook for
> >>> > >> DE so there is an answer.  As such a tweak to the wording would
> >>> > >> be helpful.
> >>> > >> I do think it’s a good idea to route the request to the mailing
> >>> > >> list, so I’m not suggesting any changes there (to be clear).
> >>> > I'll confirm the names with the chairs and add them into the
> >>> particular people removed. Let us know what needs to be done when
> >>> the time comes (if anything) for the DE process, I'm regrettably
> >>> ignorant on how it works.
> >>>
> >>> > >
> >>> > >>
> >>> > >> There are 3 experimental HTTPAuth types that are more secure
> >>> > >> than Basic and digest.  HOBA and SCRAM to name 2 of them.
> >>> > >> Here’s the link to the registry with them listed and the RFCs:
> >>> > >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%
> >>> > >> 2Fwww.iana.org%2Fassignments%2Fhttp-authschemes%2Fhttp-
> &data=02
> >>> > >>
> %7C01%7Cstephen.banghart%40nist.gov%7Cfc553686533a4321bded08d50
> >>> > >>
> 6822a8a%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C6364220784
> >>> > >>
> 80216159&sdata=sqvo4v0v3FZiBOUme%2B4yp3rQAZguEOqwmf6PjP9aRHs%
> 3D
> >>> > >> &reserved=0
> >>> > >> authschemes.xhtml.
> >>> > >> reworking the text in paragraph 3 to mention these as options
> >>> > >> would be good.
> >>> > >>
> >>> > >> specific document to cover all the types, just the registry.
> >>> > >> HTTP Basic and Digest were updated with considerably expanded
> >>> > >> security considerations sections, so you could point to those
> >>> > >> two and then pick one of the experimental ones perhaps before
> naming other types?
> >>> > >>
> >>> > >
> >>> > HTTP basic, digest, HOBA, and SCRAM. Some text was added to
> >>> > mention the additional options.
> >>> >
> >>> > Looks good, thanks.
> >>> >
> >>> > >
> >>> > >
> >>> > >> For the federated authentication, could OAuth/JWT be used?  It
> >>> > >> would be a more current solution.
> >>> > >
> >>> > >> Third to last paragraph, if JSON and other data formats are to
> >>> > >> be supported (which I believe is the case), then you should
> >>> > >> also mention one other option like what JOSE offers for
> >>> > >> encryption and signing.
> >>> > >> JWE - RFC7516, JWS - RFC7515, JWK - RFC7517, and JWA- RFC7518.
> >>> > >> You probably don’t need to mention the last 2 in an example
> >>> > >> style sentence.
> >>> > >
> >>> > >> In the privacy considerations, the requirement for TLS is also
> >>> > >> a mitigator for the problems listed in the second and third
> paragraph.
> >>> > >> It’s worth mentioning that as I’m sure questions will be raised
> >>> > >> if it’s not stated again.
> >>> > >
> >>> > Didn't see I had a typo there.  Should any recent reviewers be
> >>> > added to the acknowledgment section?
> >>>
> >>> The original names here were added by John Fields during the
> >>> original work on the draft, we've had such great review from both
> >>> within the WG and outside of it since then that naming anyone in
> >>> particular would leave out the wealth of people that made this draft
> >>> what it is today.
> >>>
> >>> > >>
> >>> > >> IDNITS:
> >>> > >>
> >>> > >> Please check the idnits and clear up issues.  RFC2141 is
> >>> > >> referenced, is that correct as it's been obsoleted?  It was
> >>> > >> recently replaced by RFC8141, so this was likely a timing issue.
> >>> > >
> >>> > one is due to a IANA comment that will be removed, and the other
> >>> > is a non-issue formatting warning. In IDNITs, there are a number
> >>> > of comments that are also non-issues regarding including
> >>> > additional text alongside the 2119 boilerplate.
> >>> >
> >>> > Thank you!
> >>> >
> >>> > Kathleen
> >>> >
> >>> > >
> >>> > >> I am tentatively putting this in the telechat for 10/26/17, if
> >>> > >> this is an issue, we can bump it out until after Singapore.  If
> >>> > >> it's not, getting the updates done by end of this week will
> >>> > >> give a good amount of time for you to address last call
> >>> > >> comments before the IESG review
> >>> > starts.
> >>> > >>
> >>> > >> Thanks again!
> >>> > >> --
> >>> > >>
> >>> > >> Best regards,
> >>> > >> Kathleen
> >>> > >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%
> >>> > >>
> 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Csteph
> >>> > >>
> en.banghart%40nist.gov%7Cfc553686533a4321bded08d506822a8a%7C2ab
> >>> > >>
> 5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636422078480216159&sdat
> >>> > >>
> a=0gPdUnxysXqjlLXL9pGL5XnPWNhT%2Fri0vyFt4xGOXJM%3D&reserved=0
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> >
> >>> > Best regards,
> >>> > Kathleen
> >>>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >>>
> .ietf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.bangha
> r
> >>>
> t%40nist.gov%7Cfc553686533a4321bded08d506822a8a%7C2ab5d82fd8fa4797
> a9
> >>>
> 3e054655c61dec%7C1%7C0%7C636422078480216159&sdata=0gPdUnxysXqjlL
> XL9p
> >>> GL5XnPWNhT%2Fri0vyFt4xGOXJM%3D&reserved=0
> >>>
> >>
> >>
> >>
> >> --
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> >
> etf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghar
> t%40
> >
> nist.gov%7Cfc553686533a4321bded08d506822a8a%7C2ab5d82fd8fa4797a93e
> 0546
> >
> 55c61dec%7C1%7C0%7C636422078480216159&sdata=0gPdUnxysXqjlLXL9pGL
> 5XnPWN
> > hT%2Fri0vyFt4xGOXJM%3D&reserved=0
> >
> 
> 
> 
> --
> 
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 Sep 2017 11:10:33 -0400

Thank you, all!  I'll start IETF last call right after a quick pass of
the document.

Best,
Kathleen

-- 

Best regards,
Kathleen