On April 26, 2020 at 4:28:18 PM, Theresa Enghardt wrote:
Theresa: Hi! Thanks you for the review!
John: Please make the changes below before the document is discussed
by the IESG.
Thanks!!
Alvaro.
...
> Regarding the code points that are now assigned as "First Come First Serve"
> in Secti
Reviewer: Ines Robles
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more i
Thanks for your review, Ines. Reasonable comments, and we'll consider
them as we go into IESG Evaluation. (On comment 3, I'm just going to
make the necessary change myself, and remove the CREF, so it's moot.)
Barry
On Thu, Apr 30, 2020 at 8:35 AM Ines Robles via Datatracker
wrote:
>
> Reviewer
Hi Barry,
Thank you for the fast response and addressing the comments.
Have a nice day,
Ines.
On Thu, Apr 30, 2020 at 5:13 PM Barry Leiba wrote:
> Thanks for your review, Ines. Reasonable comments, and we'll consider
> them as we go into IESG Evaluation. (On comment 3, I'm just going to
> m
RFC 8615 (and RFC 5785 before it) says that .well-known should be at the
root of the URI local-part. Appendix A explains the rationale.
However, I'm seeing multi-tenancy in OpenID, with URI local-parts of the
form /${tenant}/.well-known/openid-configuration, which is not the
intended usage. /.we
Hi Alvaro,
I’ve just uploaded -08 with your requested changes, also with the extra
explanatory introduction text Theresa suggested (thanks!).
—John
> On Apr 30, 2020, at 6:54 AM, Alvaro Retana wrote:
>
> [External Email. Be cautious of content]
>
>
> On April 26, 2020 at 4:28:18 PM, Theresa
Hi all,
The following reviewers have assignments:
For telechat 2020-05-07
Reviewer Type LC end Draft
Suhas Nandakumar Last Call 2020-04-09 draft-ietf-sfc-oam-framework-13
Last calls:
Reviewer Type LC end Draft
Stewart Bryant Last Call
Hi Nico.
(a) (b) Appendix A already talks about it some:
"""
Why aren't per-directory well-known locations defined?
Allowing every URI path segment to have a well-known location
(e.g., "/images/.well-known/") would increase the risks of
colliding with a preexisting URI on a s
On Fri, May 01, 2020 at 09:32:27AM +1000, Mark Nottingham wrote:
> (a) (b) Appendix A already talks about it some:
>
> """
>Why aren't per-directory well-known locations defined?
> Allowing every URI path segment to have a well-known location
> (e.g., "/images/.well-known/") would
