Re: [netmod] Implicit case statementa

[tom petch <[e-mail]>]

_____________________________________
From: netmod <[e-mail]> on behalf of Rob Wilton (rwilton) <[e-mail]>
Sent: 14 February 2020 10:14
To: Kent Watsen; [e-mail]
My interpretation matches the one that Martin gives in https://github.com/mbj4668/pyang/issues/559

<tp>

I was looking at 
draft-boydseda- ipfix-psamp-bulk-data-yang-model
and see nine choice statements of which six have no case, two have a single case and one has multiple case.  The single case have a note to the effect that they may be augmented, the others have no note.  The no case do have multiple container or leaf statements.  It does make me curious.

Tom Petch


I.e. the short hand notation …

    choice test {
      container foo {
        if-feature disabled-feature;
          ...
      }
    }

is equivalent to:

    choice test {
      case foo {
        container foo {
          if-feature disabled-feature;
            ...
        }
      }
    }

Filing an issue in YANG.Next to clarify, or further discuss, this seems helpful to me.

Thanks,
Rob


From: netmod <[e-mail]> On Behalf Of Kent Watsen
Sent: 13 February 2020 14:49
To: [e-mail]
Subject: [netmod] Implicit case statementa


RFC 7950 says:

   As a shorthand, the "case" statement can be omitted if the branch

   contains a single "anydata", "anyxml", "choice", "container", "leaf",

   "list", or "leaf-list" statement.  In this case, the case node still

   exists in the schema tree, and its identifier is the same as the

   identifier of the child node.

This seems clear, albeit incomplete, as inconsistencies [1] exist amongst `pyang`and `yanglint` (I did not test with `yangson`) in how the “if-feature” statement is handled, though I imagine other statements (e.g., “when”) may also fall into this discussion as well.

Ultimately, the question is what Errata and/or YANG-next issue should be filed.   I’m okay either way, so long as it’s clear and can be implemented consistently across tooling.

In the meanwhile, I recommend module designers avoid using the shorthand notation, as there are no known issues with the “longhand” notation.

[1] https://github.com/mbj4668/pyang/issues/559

Kent // contributor