> On 19 May 2015, at 17:00, Andy Bierman <[email protected]> wrote: > > On Tue, May 19, 2015 at 6:16 AM, Ladislav Lhotka <[email protected]> wrote: >> >>> On 19 May 2015, at 14:55, Andy Bierman <[email protected]> wrote: >>> >>> Hi, >>> >>> RFC 6020, sec. 7.1.5 has this sentence: >>> >>> Multiple revisions of the same module MUST NOT be imported. >>> >>> I expect the new RFC will contain a complete explanation why >>> this MUST NOT is wrong and needs to be changed. >> >> It’s not wrong but without this restriction a data modeller can use some >> typedefs/groupings from a new revision and isn’t forced to upgrade >> everything to the new revision at the same time. It was you who advocated >> this option in Dallas: >> >> AB: I agree with Martin that the ripple effect is a problem. When >> you want to use a new version of a module, you have to update >> everything else that you use from the same module. >> > > > The updating of import revision dates is not "fixed" by adding multiple > import-by-revision statements to a module.
It is - you can import a new revision with a different prefix and update only selected groupings or typedefs. > > The MUST NOT is correct but it is being removed anyway? > I would expect the sentence to be replaced by a thorough > explanation of why it was incorrectly placed in RFC 6020. It’s not about correct-incorrect but rather about better-worse. Lada > > >>> I would expect that multiple implementation examples of this >>> approach can be cited, as proof that the new solution already works >>> (before it is standardized). >> >> It will be implemented in pyang, including the mapping to DSDL schemas. >> > > So no existing designs that would validate this approach > before it is standardized? Didn't think so. > > >> Lada >> > > Andy > >>> >>> >>> Andy >>> >>> >>> >>> On Tue, May 19, 2015 at 2:59 AM, Juergen Schoenwaelder >>> <[email protected]> wrote: >>>> Hi, >>>> >>>> after long discussions in physical meetings, virtual meetings, and on >>>> the mailing list, I believe we have reached rough consensus to adopt >>>> Y45-04 in order to resolve import ambiguities (aka typedef drift and >>>> grouping drift) and we will leave it to YANG extensions (to be worked >>>> on in the future) to provide means to define explicit conformance >>>> requirements (instead of trying to derive conformance requirements >>>> from import relationships alone). A recent poll of core contributors >>>> on this issue can be found here: >>>> >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html >>>> >>>> Please speak up by Monday 2015-05-25 if you disagree with this >>>> proposal and your position is not yet included in the email message >>>> pointed to above. >>>> >>>> For more details, see the issues list available here: >>>> >>>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
