> On 21 May 2015, at 16:21, Andy Bierman <[email protected]> wrote:
>
> 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.
You once mentioned Yuma already supported XPath extension functions. Is it not
true?
> 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.
RFC 6020 also states that must and when expessions are XPath 1.0, and we are
moving away from it. This is IMO a much bigger change than Y45-04.
Lada
>
>> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
