On Thu, May 21, 2015 at 5:40 AM, Ladislav Lhotka <[email protected]> wrote:
> 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.
>
I haven't implemented any of YANG 1.1, but that is irrelevant.
I don't ilke standardizing solutions that have never been
tried and have not been proven to be useful.
Changing a MUST NOT to a MAY in any standard is a big deal.
It needs to be done with care and clarity.
> Lada
>
Andy
>>
>>
>> <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
