>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.
<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
