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

[Benoit Claise <[e-mail]>]

Dear all,

I was about the click the "IETF LC" call button, but I understand from 
Qin that a new document version will be produced.
I'll then click this button when the next version is posted.

Regards, B.
>
> 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]>