On Fri, Mar 2, 2018 at 2:50 PM, Kent Watsen <kwat...@juniper.net> wrote:

> From RFC 7950, Section 7.20.2, first sentence:
>
>    The "if-feature" statement makes its parent statement conditional.
>
> Thus:
>
>    feature aaa {
>      if-feature bbb;
>      ...
>    }
>
> means that feature "aaa" depends on feature "bbb".
> The current text is correct.
>
> Kent
>
>
>
>
> The following errata report has been submitted for RFC6020,
> "YANG - A Data Modeling Language for the Network Configuration Protocol
> (NETCONF)".
>
> --------------------------------------
> You may review the report below and at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-
> 2Deditor.org_errata_eid5272&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=m81-
> POMTB6oNRwO6oCG0H-5zqx1ntFjTc5LvGH3ETOk&s=I5ryVQtWDHP54-
> T1LaDmrDjZLlw8N1QThO5OoVQM2RI&e=
>
> --------------------------------------
> Type: Technical
> Reported by: Bob Harold <rharo...@umich.edu>
>
> Section: 7.18.1
>
> Original Text
> -------------
>    In order for a device to implement a feature that is dependent on any
>    other features (i.e., the feature has one or more "if-feature" sub-
>    statements), the device MUST also implement all the dependant
>    features.
>
> Corrected Text
> --------------
>    In order for a device to implement a feature that is dependent on any
>    other features (i.e. the feature is a sub-statement of another
>    "if-feature" statement), the device MUST also implement all the
>    dependent features.
>
> Notes
> -----
> The direction of the dependency is stated backwards.
> Consider for example:
>
> if-feature aaa;
>     statements ...;
>     if-feature bbb;
>
> This should allow feature aaa to exist without feature bbb.
> bbb should depend on aaa, but aaa should not depend on bbb
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6020 (draft-ietf-netmod-yang-13)
> --------------------------------------
> Title               : YANG - A Data Modeling Language for the Network
> Configuration Protocol (NETCONF)
> Publication Date    : October 2010
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : Network Modeling
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>
>
> My apologies, I misunderstood.  Please cancel.

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

Reply via email to