Hi Kent,

thanks for reviewing the document.

Kent Watsen <kwat...@juniper.net> writes:

> [As an individual contributor]
>
> Already many comments have been made, hopefully he below comments are new:
>
>
> 1. In Section 3, it says:
>
>   "By advertising a YANG module in which metadata annotation A is
>    defined using the "md:annotation" statement, a server specifies
>    support for the syntax of annotation A.  This means that
>    configuration or state data, RPC messages and notifications will be
>    considered syntactically valid if annotation A is attached to any
>    data node instance, provided that all rules stated in this document
>    are observed."
>
>
>   Does this mean that the annotation A can be used by *any* module
>   the server advertises, or just the modules that define/import
>   annotation A?

For all modules implemented by the server, no import is needed.

>  
>   For example, could a YANG module be defined like this:
>
>    module example-color-text {
>      namespace "http://example.org/example-color-text";;
>      prefix "rgb";
>      import ietf-yang-metadata { prefix "md"; }
>      description
>        "Text is black, unless colored otherwise";
>      md:annotation color {
>        type enumeration {
>          enum red;
>          enum green;
>          enum blue;
>        }
>        description
>          "This annotation only makes sense within this module.
>           Application of this annotation to any data node
>           Recursively applies to all its descendent nodes.";
>      }
>      container document {
>        list paragraph {
>          list sentence {
>            leaf-list word {
>              type string;
>            }
>          }
>        }
>      }
>    }

>
>
>
>   I assume that the intent is for the annotation to apply to
>   the server as a whole, not any specific module.  It might

Yes. The description can also say that the annotation is ignored
elsewhere.

>   help enforce this if annotations can only be defined in
>   modules that don't define any data-nodes and it is required
>   that the server advertises this module explicitly (not via
>   an import)...

I expect this will be the normal way of defining annotations, and it
could appear in the document as a guideline. I don't think though it is
necessary to state it as a hard rule.

>
>
>
> 2. Also in Section 3, s/conditional:/conditional;/
>

OK.

>
>
>
> 3. In Section 4.2.2, adding metadata to the first entry in a list doesn't
> seem elegant.  Can we instead create a special list element like the
> following?

Maybe I don't understand but the idea is that a separate metadata objects
can be attached to any or all entries of a list. In the example it is
added only to the first entry but another metadata object could be added
to the second entry as well.

It is not possible to add an annotation to the whole list, also because
this cannot be represented in XML encoding (via attributes).

>
>    "seq": [
>      {
>        "@": {
>            "example-inactive:inactive": true
>
>        }
>      },
>      {
>        "name": "two",
>        ...
>      }
>    ]
>
>   I don't think that '@' is a valid identifier string, so it's
>   syntactically OK, right?

Right.

>
>
>
> 4. Also in Section 4.2.2, an anydata example would complete this section...
>
>
>
> 5. In Section 4.2.3, an anyxml example would complete this section...
>

OK, will add these examples.

Thanks, Lada

>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to