Mike Bishop via Datatracker <nore...@ietf.org> wrote:
> RFC 8995 predates draft-ietf-uta-require-tls13, obviously, since the
latter is
> also with the IESG now. This document only restates 8995's TLS
requirements on
> the registrar and the MASA, so those don't have to change here. However,
in
> Section 7.3, should the REQUIRED/SHOULD alignment of TLS versions be
swapped at
> least for the Registrar-Agent to match the new guidance? For new
> protocols, TLS
No.
There are **deployment considerations** from RFC8995, which continue to
apply. This is more particularly true for the Registrar, which is usually in an
on-prem container/VM, behind an HTTPS/TLS terminator that the OT people do
not control/own. Again, we tried hard to suggest TLS 1.3 in RFC8995.
Registrars may also need to support DTLS (draft-ietf-anima-constrained-voucher),
and DTLS 1.3 is not yet common.
> Can you give me a quick overview of the thinking between when you use the
HTTP
> status codes 401 vs. 403? This document seems to use both 401 and 403 for
> various forms of failed authentication. In general, 401 means "I don't
> know who
Yes, I agree that 401 is wrong in section 7.4, section 7.7, and section 7.11
and we should
use 403 for both situations.
https://github.com/anima-wg/anima-brski-prm/pull/148
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
