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

[David Ball <[e-mail]>]

Looks good, thanks Qin.


     David


On 13/09/2017 11:18, Qin Wu wrote:
>
> Update done now.
>
> https://www.ietf.org/rfcdiff?url1=draft-wu-l3sm-rfc8049bis-03&url2=draft-wu-l3sm-rfc8049bis-04
>
> -Qin
>
> *发件人:*Benoit Claise [mailto:[e-mail]]
> *发送时间:*2017年9月12日21:13
> *收件人:*David Ball; Jan Lindblad (jlindbla); Qin Wu
> *抄送:*l3sm; adrian
> *主题:*Re: [L3sm] New Version Notification for 
> draft-wu-l3sm-rfc8049bis-03.txt
>
> 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]> <mailto:[e-mail]>
>

-- 
David Ball
<[e-mail]>