On Wed, May 18, 2022 at 10:52 PM Jan Lindblad <j...@tail-f.com> wrote:
> Andy wrote: > > A server can support a module without any protocol-accessible objects in 3 > ways > - implement the module with no features supported > - implement the module with features supported > - import the module without implementing it > > To Martin's point, it is not clear that a client is harmed because a > server lists a module in > the 'module' list instead of the 'import-only-module' list. > > > Andy > > > I just want to attest to the real world harm it causes when a server lists > a module M in the modules list when it doesn't actually support it. > > The client then has to believe it is reasonable to issue a get-config > request for the contents of module M. But when it does, the server then > responds with an error, and the automation breaks down. The problem is > cured by the server listing the non-implemented module M as an > import-only-module. > > GET operations silently skip filters that do not match. There is no error returned. Modules are not required to contain config data nodes, so issuing a get-config request for every module does not seem like a good idea. A client should be able to determine that M does not have any configuration data nodes. If the client does not have the correct set of server features, then evaluation of if-feature statements by the client may be wrong. This causes real harm to interoperability, Our server implements the crypt-hash data type and implements the 3 features. The module is (correctly) listed in the 'module' list, because it is NOT used as an import-only module in our server. It is an implemented module. Still not sure what real problem exists here. > /Jan > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
