On Wed, Jun 06, 2018 at 07:32:13PM -0400, Michael Richardson wrote: > > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. > > We write: > The mandatory cipher suite for DTLS in EST-coaps is > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the > mandatory-to-implement cipher suite in CoAP. > > Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve > is equivalent to the NIST P-256 curve. > > And this is fine for now, but we'd like to signal that Curve25519 should be > considered as an alternative, but we don't want to make it a MUST *today*, > and we don't want to force implementations 15 years down the road that have > it to include secp256r1. > > IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc8247/ > which include language like: > > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. > > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. > > MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level.
Unfortunately, I'm not a big fan of the "+/-" variants of RFC 2119 keywords. It seems more clear to me to actually write out in prose the current situation and future expectations. So, if you do end up going this route, please ensure that the shepherd writeup includes a justification of why it was chosen. -Ben
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
