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. 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. >> 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 > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
