Hi Roman, Thanks for the review! > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 4.4. Per “When a host retrieves the PvD Additional Information, it > MUST verify that the TLS server certificate is valid for the performed request > (e.g., that the Subject Alternative Name is equal to the PvD ID expressed as > an > FQDN). This authentication creates a secure binding between the information > provided by the trusted Router Advertisement, and the HTTPS server.”, what is > the trust anchor the client is supposed to use to valid the server certificate > is valid? How is that trust anchor provisioned?
There isn't any assumption that a non-default trust anchor needs to be used by the client for this validation. By default, a client would use its system TLS trust anchors to validate the server. This leaves open the possibility for enterprise scenarios to configure custom trust anchor settings, but that is currently beyond the scope of this document. Is there anything you'd like to see specifically covered in this text? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Ben Kaduk and Adam Roach’s DISCUSS positions. > > Section 4.1. Per “If the HTTP status of the answer is between 200 and 299, > inclusive, the host MAY get a file containing a single JSON object”, what > should be the behavior of a host that gets 200 status code but no JSON object > – should it try again, conclude (like in a 4xx status code) that there is not > further information, etc.? > > Yes, I agree that this should be clarified—that will be covered as part of the discuss from Adam. Thanks, Tommy _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
