Kent Watsen <[email protected]> writes:
>>You seem to be suggesting that Kent is an uninformed observer and Y45-04
>>is actually really easy to understand. Neither is true.
>
> I appreciate Andy's vote of confidence, but the reality is that I fell
> into a black hole right at the end of the Dallas meeting and just now
> caught up on the Y45 discussion. That said, my comment was based solely
> on what I read in the YANG 1.1 issue list, which wasn't easy to
> understand, so at least that part is true ;)
>
>
> <chair hat on>
>
> After catching up on the Y45 discussion to date, I was concerned if Andy's
> objection to the removal of the MUST NOT clause might be substantiated by
> the Charter, which currently says:
>
> "The changes to RFC 6020 are restricted in the following ways:
> - All compliant YANG 1.0 modules must be accepted as compliant
> YANG 1.1 modules.
> - All known ambiguities of YANG 1.0 and all reported defects
> and errata will be addressed.
> - YANG 1.1 is not adding fundamentally new data modeling
> concepts to the language.
> - The changes of the specification will be kept to the minimum
> necessary to achieve the previously stated goals."
>
>
> The 1st point was the one I was worried about the most. Had it said
> instead "6020bis must be backwards compatible", then Y45-04 would not be
> allowed. However, as worded, Y45-04 is OK. The 3rd and 4th points are up
> to interpretation, but I don't think Y45-04 steps over the line.
Of course it doesn't, but it is not only this issue where Andy insists
(above the charter) on stricter backward compatitibility - except for new
features that he has already implemented.
I think we would get nowhere with YANG 1.1 if everybody fiercely opposed
changes that need some work on his part.
Lada
>
>
> <chair hat off>
>
> I don't have a strong preference or objection to any of the proposed
> solutions (Juergen, you can mark this statement in your table). That
> said, I wish we could better decouple "imports for typedefs/groupings"
> from "imports for augments/leaf-refs". For instance:
>
> import-declaration mod-a {
> prefix a;
> revision 2001-01-01;
> }
> import-declaration mod-a {
> prefix a2;
> revision 2002-01-01;
> }
> import-runtime mod-a {
> prefix a2;
> min-revision 2002-01-01;
> }
>
>
>
>
> The idea is to give explicit control to the module designer to cherry-pick
> declarations from any module revision *and* specify the min-revision
> needed (if any) in order to resolve protocol accessible nodes. Of course,
> this would break point #1 in the charter above, but it seems better than
> leaving it solely to the discretion of the server...
>
>
> Thanks,
> Kent
>
>
> _______________________________________________
> 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
