Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt

[Qin Wu <[e-mail]>]

Thank Jan and David for discussing this, I will go with this proposal in the update.

-Qin
发件人: David Ball [mailto:[e-mail]]
发送时间: 2017年9月12日 15:38
收件人: Jan Lindblad (jlindbla); Qin Wu
抄送: l3sm; Benoit Claise (bclaise); adrian
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt


Completely agree.  In the case in question (address-allocation-type leaves), no value means "IPv4/IPv6 is not enabled for this site-network-access".



    David

On 12/09/2017 07:54, Jan Lindblad (jlindbla) wrote:
Qin, team,


  *
For the address-allocation-type leaves, I saw you removed the default (as agreed) but also added 'mandatory true' (which was not discussed).  Making these leaves mandatory does not address the problem - if anything, it makes it worse.  (Issue 15 from draft-02)
[Qin]: Fine to me, it looks we need to seek balance between making all parameters mandatory and making all parameters optional. I hope Jan will be happy with these changes.

Sometimes mandatory true is needed to make a sane model, but mandatory elements also tend to make a model clunky, examples large etc. So I generally like optional elements. The problem with optional elements is people tend to forget that it may not be obvious what a system is supposed to do when there is no value specified. Adding a default or text in the description is therefore important. At the end of the day, we're writing a contract. For interoperability to happen, there must be no holes in the contract that are open to (differing) interpretation.

So sure, you can have optional elements (this should even be the normal case), and they don't need to have a default statement. But if so, *describe* what it means; what the system is supposed to do. No value is also a value.

Best,
/jan




--

David Ball

<[e-mail]><mailto:[e-mail]>