> ** Section 4. choice encryption. Per the name of this YANG item and the > description (“Encryption mechanism between TACACS+ client and server”), > please follow the convention of Section 4.5 of RFC8907 of calling this > “obfuscation”. > [Bo]: The reason we define this "encryption" choice is that shared-secret > leaf is mandatory per RFC8907, but future TACACS+ protocol may define > encryption node to replace the shared-secret leaf. Therefore, is it clearer > to change "encryption" to " obfuscation-encryption"? >
Today, we only have the obfuscation-by-shared-secret. In the future, we may have TLS or some other stronger encryption. If we insist on making the module forward-looking, should we rename this something like privacy (similar to how SNMPv3 names this)? I agree with Roman that encryption is a bit strong of an umbrella under which to put shared-secret. Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
