Juergen Schoenwaelder je 30.7.2015 ob 13:38 napisal:
On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tuljak wrote:
Ladislav Lhotka je 30.7.2015 ob 11:30 napisal:
On 30 Jul 2015, at 01:12, Andy Bierman <[email protected]> wrote:
On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <[email protected]> wrote:
Andy Bierman <[email protected]> wrote:
Hi,
I understand the intent is that an implementation of NACM
has to understand these NACM extensions. I agree with Lada
that the YANG text about MAY ignore extensions casts doubt whether
this sort of NACM rule is enforceable or specified correctly.
So do you agree that it would be a good idea to clarify this
according to Juergen's suggestion?
Not really.
Pretending the extension is just another description-stmt
does not really fix anything.
In fact, generic tools like pyang ignore what’s written in descriptions.
Where does RFC6020 say that description-stmt may be used for defining
additional semantics? The only instance where I can find "description"
and "semantics" or "meaning" in the same sentence, is in the section
that describes module updates. This is what a YANG description is:
The "description" statement takes as an argument a string that
contains a human-readable textual description of this definition.
The text is provided in a language (or languages) chosen by the
module developer; for the sake of interoperability, it is RECOMMENDED
to choose a language that is widely understood among the community of
network administrators who will use the module.
A textual description for humans. A docstring. I don't see semantics
being mentioned anywhere, so where is all this coming from?
Seriously? Perhaps we have a different understanding of the word
'semantics'. Anyway, description statements (or DESCRIPTION clauses
back in SMIv2) have always been used to provide semantics that are not
expressable in machine readable form.
Example: The ietf-yang-types:counter32 definition defines a counter
type because of the text in the description statement. I would say
there is lots of semantics in the description statement. Without
the description statement, the ietf-yang-types:counter32 would not
at all be a counter.
This does not change "semantics" as I understand them or as Ladislav
implied them. I was thinking "YANG language semantics", which is what
extensions are used for - extending YANG language with new keywords that
hold special meaning for a YANG processor (humans included).
In a NETCONF message, ietf-yang-types:counter32 value will always be an
integer on the wire, regardless of what the description text says,
right? I also cannot magically turn all containers into leaves using
text in a module description, saying "All container definitions in this
module are actually leaf definitions", right? An extension could,
however, be used for such a thing - a sort of YANG pre-processor
directive (which any sensible YANG tool would ignore).
I disagree with the interpretation that an extension is just a
formalized description statement.
I also disagree with the notion that a description text may alter,
augment or define YANG language semantics, unless it describes an
extension keyword. This is of key importance for generic tools, so that
at the very least they can support standard extensions, such as
"annotation". Having to parse human text would render such tools
completely useless.
Jernej
I am absolutely surprised lately how little we seem to have a common
understanding about basic YANG concepts.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
