Mohamed Boucadair via Datatracker <nore...@ietf.org> wrote:
> # Unconditional MUST
> CURRENT:
> The pledge MUST respond to all requests regardless of the
> Host header field provided by the client (i.e., ignore it).
> I don’t think that is safe.
Why?
The Registrar Agent really has *only* the IP address of the pledge.
No virtual hosting is possible. So, **anything** it puts into the Host: header
will be wrong. mDNS may well return IPv6-LL addresses.
> I’m afraid this needs some scoping; as there are other legitimate
conditions
> where the pledge does not have to reply.
Like... what?
> # Compliance with HTTP BCP (RFC9205)
> CURRENT:
> If the pledge is unable to create the PVR, it SHOULD respond with an
> HTTP error status code to the Registrar-Agent. The following client
> error status codes SHOULD be used:
> The use of normative language is IMO not compliant with the guidance in
> RFC9205, about error handling.
okay, we'll review.
> # Cluster with 8366bis
> CURRENT:
> The JSON PVR Data MUST contain the following fields of the “ietf-
> voucher-request” YANG module as defined in
> [I-D.ietf-anima-rfc8366bis];
> I think this spec should be clustered with 8366bis. There are several
structure
> that used in this document and which depends on what is defined in
8366bis.
> Changes to the bis will have implications on this one.
Yes, it's all gonna be in a cluster.
Is there something you think we need to put into the I-D to make that so,
other than a normative reference, which it already has?
> With that in mind, I tend to suggest holding approval of this
specification
> till we finalize the bis spec.
No, because that creates a loop of getting document X done before document Y
can proceed. We already, as a WG, said that rfc8366bis would wait until all
others are done. RFC8366bis could otherwise progress without the others, and
when we discover problems that require updates to two places, would wind up
making us yank it back from the RFC-editor. We went through this with
RFC8995 already, and the WG learnt it's lesson.
> # Requires TLS1.3
> CURRENT:
> As already stated in [RFC8995], the use of TLS 1.3 (or newer) is
> encouraged. TLS 1.2 or newer is REQUIRED on the Registrar-Agent
> side. TLS 1.3 (or newer) SHOULD be available on the registrar, but
> TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the
> MASA, but TLS 1.2 MAY be used.
> Please update to take into to reflect draft-ietf-uta-require-tls13.
The reality that many platforms do not have FIPS-140 appproved TLS 1.3
stacks remains true. It's getting better, but it's just not there yet.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
