On 4/27/21 11:57, tom petch wrote:
> From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Joe Clarke (jclarke)
> <jclarke=40cisco....@dmarc.ietf.org>
> Sent: 27 April 2021 15:48
>
> Thanks, Bo. On your description for the renamed "security" choice, I
> think it is overly descriptive in this case. When a new secure T+
> protocol comes out, this future proofing language will be obsolete.
> What about:
>
> choice security {
> ...
> description
> "Security mechanism between TACACS+ client and server.";
> ...
> leaf shared-secret {
> ...
> description
> "...Note this security mechanism is best described as
> 'obfuscation' and not 'encryption' as it does not provide any meaningful
> integrity, privacy, or reply protection.";
>
> Thoughts from others?
>
> <tp>
>
> Under descriptive! I think that you need to explain why this is a choice
> rather then expecting the reader to know the BC/NBC rules off pat at the time
> of writing. Perhaps
I'm not convinced that they need to know that in the module itself (vs.
the document reference), but I accept more context is needed.
>
> 'This is modelled as a YANG 'choice' so that it can be augmented by a future
> YANG module in a backwards compatible manner.'
>
> Note I say 'can be' not 'will be'
Maybe drop the word "future".
Joe
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
