On Thu, Mar 3, 2022 at 1:25 AM William Lupton <[email protected]> wrote:
> Thanks Andy. What is the next step? Should I (or someone else) email > [email protected], or can we assume that the relevant IANA person will > already have seen this discussion? > > It seems that RFC 8407 already says what to do (use a different revision-date). We combine the revision-stmt so there is only 1 revision entry instead of 2. It is too late to do anything about this module. I am interested in the OPS issues: The client MUST be able to produce the same[*] schema tree as the server in order to have an accurate model of the server's YANG API. 1) server uses implementation-specific mechanisms (e.g. search path) to select the modules it will advertise in its yang-library 2) client reads the yang-library, which provides all the [name,date] tuples and other info needed 3a) client can use cached yang-library data and locally obtained YANG files 3b) client can use <get-schema> (IFF supported by the server) to retrieve the YANG files [*] same can mean a later revision if specific schema definitions have not changed Issues: 1) Is there ANY uniqueness guarantee that [name, date] is GLOBALLY unique. A: Yes according to RFC 7950, but not really in implementations. A: No, if revision-label is added and the same revision-date is used in multiple release trains. So if a client cannot rely on [name, date] uniqueness, then it does not really know if step 3a or step 3b is required. This is currently a solved problem using proprietary means (e.g., client hacked to know which one, based on server testing). But now there are more system components, not just a server, such as YANG Data Instance Files and YANG SID Files. If the [name, date] tuples are not globally unique here, then these standards do not work. Andy > On Tue, 1 Mar 2022 at 14:49, Andy Bierman <[email protected]> wrote: > >> >> I think that this should be fixed. What's the best way to achieve this? >>> >> >> I think this issue should be resolved as well. >> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
