Hi all,
below are comments to a subset of not yet concluded review exchanges.
Peter
_______________________________________________________
The serverkeygen endpoints could perhaps have some notation to indicate
that the private key is always returned, in addition to the PKCS#7 vs.
pkix-cert question that distinguishes skg and skc.
<pvds>after ".....an /skc request.", the following text is added:
"In both cases a private key MUST be returned."
I was thinking we could have something in the table, though we may be too
short on horizontal space for that to actually work.
</pvds>
<pvds3>
The tables seem to be full, so I left them as they were
</pvds3>
Clients and servers MUST support the short resource EST-coaps URIs.
Are they expected to also support the long EST URIs over CoAP?
<pvds> It was undecided whether we should add:
"The corresponding longer URIs from <xref target="RFC7030"/> MAY be
supported."
I have no strong preference here, but would not be surprised if we got a
question on it from the IESG. (Which I guess means a weak preference for
adding the above text.)
<pvds3>
slightly preferred text has been added
</pvds3>
Hmm, I think I was not very clear about what I meant: for the given
resources, the only defined content types for that resource are the ones
listed in the example request. If a server tries to advertise anything
else, it seems like that would be out of spec (and maybe a client should
bail on seeing it?). But maybe I'm misinterpreting things and we should
leave open space for future expansions to other content formats.
<pvds3>
I added the text:
"This approach allows future servers to incorporate currently not specified
content-formats and resources."
Section 5.2
While [RFC7030] permits a number of these functions to be used
without authentication, this specification requires that the client
MUST be authenticated for all functions.
Perhaps this divergence from 7030 should be noted more prominently,
perhaps in the section title or a dedicated "Differences from RFC 7030"
section?
<pvds>
Suggestion to move this phrase to section 5 just before section 5.1?
That would be a big help, thanks..
</pvds>
<pvds3>
done
</pvds3>
</pvds>
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
