On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka <[email protected]> wrote:
>
>> 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?
>
Within the C code there is an extensible XPath function library.
It would be unreasonable to design a XPath implementation
with a hard-wired function library. The standard is designed
to support the opposite.
>> 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.
>
Show me the "MUST NOT" that is getting reversed and I will agree with you.
I am not objecting to Y45-04. I am objecting to removing a "MUST NOT"
from the standard. Discussion of relative implementation complexity
of other YANG 1.1 changes is irrelevant.
> Lada
>
Andy
>>
>>> 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
