On Thu, Jul 28, 2016 at 9:00 AM, Balazs Lengyel <[email protected] > wrote:
> > > On 2016-07-28 17:13, Robert Wilton wrote: > >> On 28/07/2016 15:51, Juergen Schoenwaelder wrote: >> >> One issue I see is that extensions are effectively required to be >> optional, allowing tooling to ignore them if they wish. This seems to >> hamper their usefulness in some scenarios. >> > BALAZS: Any better ideas? IMHO if you want to support yang-mount you will > support the needed extensions. > >> >> For the example given here, I feel that something stronger would be >> useful, i.e. an extension that must be implemented by the tooling for the >> particular YANG module to make sense. >> >> Perhaps when a module includes an extension it could indicate whether >> support for that extension is regarded as required for the module to be >> useful, or conversely if the module is still sane even if support for the >> extension isn't implemented. >> > BALAZS: Agree, in the RFC text or in the extension's description we could > indicate whether it is mandatory to support the extension in order to > support the module. > Or we could add a formal statement, but no updates to YANG, so add an > extension to indicate this, and we are back in to step one. > By the way we already have IETF-defined extensions in nacm. Is it > mandatory to support those? IMHO no. > >> >> Actually we have been over this issue many times already with YANG 1.1. An implementation that claims conformance to NACM MUST implement the extensions defined for NACM (default-deny-write, default-deny-all). A generic tool that claims to support YANG does not need to claim conformance to NACM and therefore does not need to implement the NACM extensions. > Thanks, >> Rob >> > > Andy > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: [email protected] > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
