Re: [yang-doctors] YANG dialects?

Jan Lindblad <> Thu, 19 December 2019 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D268120905 for <>; Thu, 19 Dec 2019 09:36:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mnee9EzyWXoD for <>; Thu, 19 Dec 2019 09:36:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 82533120900 for <>; Thu, 19 Dec 2019 09:36:28 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 22DEF1AE0389; Thu, 19 Dec 2019 18:36:27 +0100 (CET)
From: Jan Lindblad <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1FD4D09-D21C-4919-B845-647C7B9DA795"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 19 Dec 2019 18:36:25 +0100
In-Reply-To: <>
Cc: Martin Bjorklund <>, "" <>, "" <>
To: "Rob Wilton (rwilton)" <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [yang-doctors] YANG dialects?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Dec 2019 17:36:30 -0000

>>>>> Not so easy for all of them.
>>>>> (1)
>>>>> The pattern-stmt disaster cannot be addressed.
>>>> I think the solution is trivial, and it has been proposed to OpenConfig -
>>>> introduce a new extension statement oc:posix-pattern.
>>>> This will make the modules *legal*, and tools can use existing mechanisms
>>>> to deal (or not) with this new statement.
>> I don't think it is legal, because
>> o  extension: An extension attaches non-YANG semantics to statements.
>> This is not the case here, it is only syntactically compatible. If tool A says
>> that some instance data is valid, but tool B says it isn't, then the standard is
>> gone.
>> Lada

Of course it would be legal. It's always legal for a NETCONF server to reject an edit-config for no apparent reason (from a YANG perspective), so all device YANG models would still be legal if all pattern statements were removed, but the same string pattern constraints still enforced by the devices. The OC group could therefore remove their pattern statements and introduce a YANG extension oc:posix-pattern (or oc:go-pattern, or whatever) that gives a hint to some clients what is expected. The clients that don't understand this extension would just se a rejection for no apparent reason (from a YANG perspective).

> But, as I understand it, the regex implementations are not POSIX either.  E.g. I think that they are using RE2 for Go, which is somewhat derived from PCRE which is derived from POSIX regex, but not exactly compatible either.
> So, it would end up replacing one regex language that can't be 100% directly implemented with another regex language that can't be 100% directly implemented.  This seems to make the life more complex not less.
> I still believe that the only solution is to define as subset of XML regex that can easily be translated into common regex engines. Although, as Juergen has stated previously, this effectively defines a new regex language ...

I don't think a subset is possible here. The subset would be the null set, since basically all the posix expressions have caret+dollar ^(...)$ surrounding the actual expression, which are interpreted very differently than intended in the W3C world. So two separate pattern statements will be needed.