<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:53:45 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[YANGTOOLS-608] Mandatory leaf enforcement is not correct with presence container</title>
                <link>https://jira.opendaylight.org/browse/YANGTOOLS-608</link>
                <project id="10188" key="YANGTOOLS">yangtools</project>
                    <description>&lt;p&gt;Given the following schema:&lt;/p&gt;

&lt;p&gt;   container task-container {&lt;br/&gt;
      list task {&lt;br/&gt;
        key &quot;task-id&quot;;&lt;/p&gt;

&lt;p&gt;        leaf task-id &lt;/p&gt;
{
          type string;
        }

&lt;p&gt;        container task-data {&lt;br/&gt;
            presence &quot;Task data&quot;;&lt;br/&gt;
            leaf mandatory-data &lt;/p&gt;
{
                type string;
                mandatory true;
            }
&lt;p&gt;            leaf other-data &lt;/p&gt;
{
                type string;
            }
&lt;p&gt;        }&lt;br/&gt;
      }&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;If one PUTs:&lt;/p&gt;

&lt;p&gt;  task: &lt;/p&gt;
{ 
    task-id: &quot;123&quot;
  }

&lt;p&gt;it succeeds as expected without specifying the mandatory descendant leaf &quot;mandatory-data&quot; because its immediate ancestor, &quot;task-data&quot;, is a presence container and it wasn&apos;t specified. This conforms to &lt;a href=&quot;https://tools.ietf.org/html/rfc6020#section-7.6.5&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://tools.ietf.org/html/rfc6020#section-7.6.5&lt;/a&gt; (the 3rd constraint bullet below):&lt;/p&gt;

&lt;p&gt;   If &quot;mandatory&quot; is &quot;true&quot;, the behavior of the constraint depends on&lt;br/&gt;
   the type of the leaf&apos;s closest ancestor node in the schema tree that&lt;br/&gt;
   is not a non-presence container (see Section 7.5.1):&lt;/p&gt;

&lt;p&gt;   o  If no such ancestor exists in the schema tree, the leaf MUST&lt;br/&gt;
      exist.&lt;/p&gt;

&lt;p&gt;   o  Otherwise, if this ancestor is a case node, the leaf MUST exist if&lt;br/&gt;
      any node from the case exists in the data tree.&lt;/p&gt;

&lt;p&gt;   o  Otherwise, the leaf MUST exist if the ancestor node exists in the&lt;br/&gt;
      data tree.&lt;/p&gt;

&lt;p&gt;Therefore &quot;mandatory-data&quot; doesn&apos;t need to exist b/c &quot;task-data&quot; doesn&apos;t exist.&lt;/p&gt;

&lt;p&gt;If one PUTs:&lt;/p&gt;

&lt;p&gt;  task: { &lt;br/&gt;
    task-id: &quot;123&quot;,&lt;br/&gt;
    task-data: &lt;/p&gt;
{
      other-data: &quot;foo&quot;
    }
&lt;p&gt;  }&lt;/p&gt;

&lt;p&gt;it also succeeds. However, in this case, &quot;task-data&quot; is present so this seems to violate the 3rd constraint above, i.e. it should&apos;ve failed b/c &quot;mandatory-data&quot; was not specified.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="23028">YANGTOOLS-608</key>
            <summary>Mandatory leaf enforcement is not correct with presence container</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="pkajsa">Peter Kajsa</assignee>
                                    <reporter username="tpantelis">Tom Pantelis</reporter>
                        <labels>
                    </labels>
                <created>Mon, 2 May 2016 22:31:32 +0000</created>
                <updated>Sun, 10 Apr 2022 18:35:46 +0000</updated>
                            <resolved>Tue, 7 Jun 2016 16:54:24 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>5</watches>
                                                                                                                <comments>
                            <comment id="43872" author="tpantelis" created="Tue, 3 May 2016 04:09:11 +0000"  >&lt;p&gt;I found another case which looks like a bug. If container &quot;task-data&quot; in the schema above is not a presence container the writing:&lt;/p&gt;

&lt;p&gt;  task: { &lt;br/&gt;
    task-id: &quot;123&quot;,&lt;br/&gt;
    task-data: &lt;/p&gt;
{
      other-data: &quot;foo&quot;
    }
&lt;p&gt;  }&lt;/p&gt;

&lt;p&gt;fails as expected b/c &quot;mandatory-data&quot; was not specified.&lt;/p&gt;

&lt;p&gt;However if the &quot;task&quot; list is removed from the schema, i.e.:&lt;/p&gt;

&lt;p&gt;   container task-container {&lt;br/&gt;
       leaf task-id &lt;/p&gt;
{
           type string;
       }

&lt;p&gt;       container task-data {           &lt;br/&gt;
           leaf mandatory-data &lt;/p&gt;
{
               type string;
               mandatory true;
           }
&lt;p&gt;           leaf other-data &lt;/p&gt;
{
               type string;
           }
&lt;p&gt;       }&lt;br/&gt;
   }&lt;/p&gt;

&lt;p&gt;writing:&lt;/p&gt;

&lt;p&gt;  task-container: { &lt;br/&gt;
     task-id: &quot;123&quot;,&lt;br/&gt;
     task-data: &lt;/p&gt;
{
        other-data: &quot;foo&quot;
     }
&lt;p&gt;  }&lt;/p&gt;

&lt;p&gt;succeeds. This also seems to violate the RFC. Mandatory leafs are only enforced when descendants of a list.&lt;/p&gt;</comment>
                            <comment id="43873" author="tpantelis" created="Tue, 3 May 2016 04:18:47 +0000"  >&lt;p&gt;Another inconsistency. Given the original schema with the &quot;task&quot; list but &quot;task-data&quot; non-presence, writing&lt;/p&gt;

&lt;p&gt;task-container: {&lt;br/&gt;
  task: { &lt;br/&gt;
    task-id: &quot;123&quot;,&lt;br/&gt;
    task-data: &lt;/p&gt;
{
      other-data: &quot;foo&quot;
    }
&lt;p&gt;  }&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;succeeds but it should fail.&lt;/p&gt;</comment>
                            <comment id="43874" author="rovarga" created="Tue, 3 May 2016 08:29:56 +0000"  >&lt;p&gt;The two later cases are expected, as mandatory leaf enforcement is not performing validation based on RFC6020 Section 7.6.5 bullet 1, as that would require all mandatory leaves to be introduced in the first transaction that occurs &amp;#8211; any other transactions would fail.&lt;/p&gt;

&lt;p&gt;We do not have a mechanism which could reliably satisfy that requirement.&lt;/p&gt;</comment>
                            <comment id="43875" author="colin@colindixon.com" created="Tue, 3 May 2016 17:29:04 +0000"  >&lt;p&gt;Should we open an enhancement bug to allow people to voluntarily enable mandatory enforcement per the RFC 6020 on some basis. For example, could somebody turn it on a per-module basis sometime after boot?&lt;/p&gt;</comment>
                            <comment id="43876" author="colin@colindixon.com" created="Tue, 3 May 2016 17:37:04 +0000"  >&lt;p&gt;During the MD-SAL call today, we confirmed that at least the first part here is a real bug. That is if a presence container exists, its mandatory child leaves  must also exist.&lt;/p&gt;</comment>
                            <comment id="43877" author="pkajsa" created="Wed, 25 May 2016 13:16:49 +0000"  >&lt;p&gt;(In reply to Colin Dixon from comment #5)&lt;br/&gt;
&amp;gt; During the MD-SAL call today, we confirmed that at least the first part here&lt;br/&gt;
&amp;gt; is a real bug. That is if a presence container exists, its mandatory child&lt;br/&gt;
&amp;gt; leaves  must also exist.&lt;/p&gt;

&lt;p&gt;fix: &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/39313/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/39313/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="43878" author="rovarga" created="Tue, 7 Jun 2016 11:31:00 +0000"  >&lt;p&gt;Be: &lt;a href=&quot;https://git.opendaylight.org/gerrit/39942&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/39942&lt;/a&gt;&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>5830</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=5830]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Bug]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10204" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>ODL SR Target Milestone</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10341"><![CDATA[Beryllium-3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10202" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Priority</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10301"><![CDATA[Normal]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i0289z:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>