Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09
Ladislav Lhotka <lhotka@nic.cz> Mon, 15 January 2018 09:38 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E19126CD6 for <yang-doctors@ietfa.amsl.com>; Mon, 15 Jan 2018 01:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpoZisL73lVR for <yang-doctors@ietfa.amsl.com>; Mon, 15 Jan 2018 01:38:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E5C12D86B for <yang-doctors@ietf.org>; Mon, 15 Jan 2018 01:38:21 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:68c6:92ff:fe01:2298]) by mail.nic.cz (Postfix) with ESMTPSA id 6616663F3A; Mon, 15 Jan 2018 10:38:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516009099; bh=XqQJ88Mi6rDMqap3fJljjhrR8jHBmJJOv2XNWoAqrkU=; h=From:To:Date; b=pgS/kauGglZc5OMlyu4mYQebQpGcqrMZCLzmslsI0PuNDFXPG8bI7IELTMCV+ShFu 9VtqBGn+cn2LttTsUloDNkyibaZmyh/IxMcQiR3Of3tyV+HIxdLP/2H0hQQImO9tFG kpuZuuo04HXVaK6c1efruLWSoeW5u5ZT27ODPDhc=
Message-ID: <1516009099.5426.13.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: andy@yumaworks.com, yang-doctors@ietf.org
Date: Mon, 15 Jan 2018 10:38:19 +0100
In-Reply-To: <20180115.095941.341257692373089671.mbj@tail-f.com>
References: <87po6fmlkn.fsf@nic.cz> <CABCOCHSFfgjVS58S0po-9yEUZw=cjzG6k_LY8V9NSdy+kHQvLg@mail.gmail.com> <1516006155.5426.3.camel@nic.cz> <20180115.095941.341257692373089671.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/VMiUJzP2HxH94UmQfd4DAqSX1OQ>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 09:38:26 -0000
On Mon, 2018-01-15 at 09:59 +0100, Martin Bjorklund wrote: > Ladislav Lhotka <lhotka@nic.cz> wrote: > > On Fri, 2018-01-12 at 09:45 -0800, Andy Bierman wrote: > > > > > > > > > On Fri, Jan 12, 2018 at 2:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > Martin Bjorklund <mbj@tail-f.com> writes: > > > > > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > >> On Wed, 2018-01-10 at 12:58 +0100, Martin Bjorklund wrote: > > > > >> > Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > >> > > On Wed, 2018-01-10 at 10:35 +0100, Martin Bjorklund wrote: > > > > >> > > > Hi, > > > > >> > > > > > > > >> > > > Replying to this only on yang-doctors, since this is mostly a > > > > >> > > > discussion about the interpretation of RFC 7950. > > > > >> > > > > > > > >> > > > > > > > >> > > > Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > >> > > > > On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote: > > > > >> > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > >> > > > > > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund > wrote: > > > > >> > > > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > >> > > > > > > > > On Mon, 2018-01-08 at 19:28 +0000, Acee Lindem (acee) > > > > wrote: > > > > >> > > > > > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lhotka@nic. > cz> > > > > wrote: > > > > >> > > > > > > > >> > > > [...] > > > > >> > > > > > > > >> > > > > > > > > > > 4. In "when" expressions, the module uses literal > > > > strings > > > > >> > > > > > >> > for > > > > >> > > > > > > > > > > identities. This is known to be problematic, > the > > > > XPath > > > > >> > > > > > > > >> > > > functions > > > > >> > > > > > > > > > > derived-from() or derived-from-or-self() should > be > > > > used > > > > >> > > > > > > > >> > > > instead. > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > Why is this problematic? Is it because the types > can be > > > > >> > > > > > >> > extended? > > > > >> > > > > > > > > > > > > >> > > > > > > > > That's one reason: derived identities should often > also > > > > satisfy > > > > >> > > > > > >> > the > > > > >> > > > > > > > > constraint. > > > > >> > > > > > > > > > > > > >> > > > > > > > > But the more serious problem is that things like > > > > >> > > > > > > > > > > > > >> > > > > > > > > when "../../../../../../../rt:type = > 'ospf:ospfv3'" > > > > >> > > > > > > > > > > > > >> > > > > > > > > rely on plain string comparison that depends od the > > > > actual > > > > >> > > > > > >> > prefix > > > > >> > > > used > > > > >> > > > > > > > > > > > >> > > > > > > > > "rt:type" value. For one, according to RFC 7951 the > JSON > > > > >> > > > > > >> > encoding of > > > > >> > > > > > > > > this value > > > > >> > > > > > > > > would be "ietf-ospf:ospfv3" so the above expression > is > > > > always > > > > >> > > > > > > > >> > > > false. > > > > >> > > > > > > > > > > > >> > > > > > > > This is not correct; the when expression is not > evaluated > > > > on the > > > > >> > > > > > >> > JSON > > > > >> > > > > > > > encoding. See the last paragraph of section 9.10.3 in > RFC > > > > 7950: > > > > >> > > > > > > > > > > > >> > > > > > > > The string value of a node of type "identityref" in > a > > > > "must" or > > > > >> > > > > > > > "when" XPath expression is the referred identity's > > > > qualified > > > > >> > > > > > >> > name > > > > >> > > > > > > > with the prefix present. If the referred identity > is > > > > defined > > > > >> > > > > > >> > in an > > > > >> > > > > > > > imported module, the prefix in the string value is > the > > > > prefix > > > > >> > > > > > > > >> > > > defined > > > > >> > > > > > > > in the corresponding "import" statement. Otherwise, > the > > > > prefix > > > > >> > > > > > >> > in > > > > >> > > > > > > > the string value is the prefix for the current > module. > > > > >> > > > > > > > > > > >> > > > > > > This is weird, to say the least. The leafref instance may > > > > have an > > > > >> > > > > > > > >> > > > identity > > > > >> > > > > > > value > > > > >> > > > > > > that is defined in a module that (has to be implemented > by > > > > the > > > > >> > > > > > >> > server > > > > >> > > > but) > > > > >> > > > > > > needn't be imported in the module that contains the XPath > > > > >> > > > > > >> > expression. So > > > > >> > > > I > > > > >> > > > > > > don't > > > > >> > > > > > > know what 'corresponding "import" statement' this > paragraph > > > > is > > > > >> > > > > > >> > talking > > > > >> > > > > > > about. > > > > >> > > > > > > > > > >> > > > > > It has to import the module in order to give a prefix, > which > > > > then can > > > > >> > > > > > be used in the XPath expression. > > > > >> > > > > > > > > >> > > > > In the XPath expression above, do you mean the "rt" prefix of > > > > >> > > > > "rt:type"? > > > > >> > > > > > > > >> > > > No, I meant the "ospf" prefix for the module "ietf-ospf". > > > > >> > > > > > > > >> > > > > If so, > > > > >> > > > > it is irrelevant for the string comparison, what's important > is > > > > the > > > > >> > > > > > >> > *value* > > > > >> > > > of > > > > >> > > > > the "rt:type" instance, which can be an identity defined in a > > > > module > > > > >> > > > > > >> > that > > > > >> > > > > needn't be imported by ietf-routing, ietf-ospf or whatever. > Sec. > > > > 9.10.2: > > > > >> > > > > > > > > >> > > > > On a particular server, the valid values are further > > > > restricted > > > > >> > > > > to the set of identities defined in the modules > implemented by > > > > >> > > > > the server. > > > > >> > > > > > > > >> > > > Because of the way the representation of identities work in > > > > must/when > > > > >> > > > expressions, you *must* import the module where the identity is > > > > >> > > > define, if you want to use the identity for equality > comparision > > > > like > > > > >> > > > in the example. > > > > >> > > > > > > > >> > > > You may have: > > > > >> > > > > > > > >> > > > module a { > > > > >> > > > ... > > > > >> > > > import ietf-ospf { > > > > >> > > > prefix x; > > > > >> > > > } > > > > >> > > > ... > > > > >> > > > leaf foo { > > > > >> > > > when "../type = 'x:ospfv3'"; > > > > >> > > > ... > > > > >> > > > } > > > > >> > > > } > > > > >> > > > > > > >> > > The problem here is not with the literal 'x:ospf' but rather with > the > > > > string > > > > >> > > value of the leafref node instance ("../type" here), and clearly > it > > > > is what > > > > >> > > > > > >> > sec. > > > > >> > > 9.10.3 talks about ("string value of a [leafref] node"). > > > > >> > > > > > > >> > > I can define a module like > > > > >> > > > > > > >> > > module foo-ospf { > > > > >> > > namespace "http://example.com/foo-ospf"; > > > > >> > > prefix ospf; > > > > >> > > import ietf-routing { > > > > >> > > prefix rt; > > > > >> > > } > > > > >> > > identity ospfv3 { > > > > >> > > base "rt:routing-protocol"; > > > > >> > > } > > > > >> > > ... > > > > >> > > } > > > > >> > > > > > > >> > > Now, if the server advertizes both ietf-ospf and foo-ospf as > > > > implemented > > > > >> > > > > > >> > (which > > > > >> > > is legal), the module foo-ospf needn't be imported anywhere and > still > > > > the > > > > >> > > > > > >> > "type" > > > > >> > > leaf instance can have both values "ietf-ospf:ospfv3" and "foo- > > > > ospf:ospfv3", > > > > >> > > provided that it is defined as > > > > >> > > > > > > >> > > leaf type { > > > > >> > > type identityref { > > > > >> > > base rt:routing-protocol; > > > > >> > > } > > > > >> > > } > > > > >> > > > > > > >> > > And I wonder what the last paragraph in sec. 9.10.3 means in this > > > > situation, > > > > >> > > i.e. what string value of "type" is used in the evaluation of the > > > > XPath > > > > >> > > expression in your module "a", if the value-space value of 'type' > > > > instance > > > > >> > > > > > >> > in a > > > > >> > > datastore is either of the two '...:ospfv3' identities. > > > > >> > > > > > > >> > > Do you see what I mean? > > > > >> > > > > > >> > Do you mean that the problem is that the spec does not define what > the > > > > >> > string value is if the module where the identity is defined is not > > > > >> > imported? > > > > >> > > > > > >> > I agree that this is an issue. > > > > >> > > > > > >> > BUT, actually, if you look the text in the spec: > > > > >> > > > > > >> > The string value of a node of type "identityref" in a "must" or > > > > >> > "when" XPath expression is the referred identity's qualified > name > > > > >> > with the prefix present. If the referred identity is defined in > an > > > > >> > imported module, the prefix in the string value is the prefix > > > > defined > > > > >> > in the corresponding "import" statement. Otherwise, the prefix > in > > > > >> > the string value is the prefix for the current module. > > > > >> > > > > > >> > If you blindly follow this, the last sentence would have to apply, > and > > > > >> > the string would be "a:ospfv3", which clearly is broken. > > > > >> > > > > >> It depends on what "current module" means. > > > > > > > > > > "current module" and "local module" means the module where the "must" > > > > > or "when" expression is defined. There was a separate thread about > > > > > this as well. > > > > > > > > OK, then it really makes no sense to add the local prefix. > > > > > > > > > > > > > >> It could also be interpreted as the > > > > >> module in which the identity is defined, but then we can get the > > > > collision of > > > > >> prefixes as in my example. > > > > >> > > > > >> > > > > > >> > For all practical purposes, I think the string value can be "" if > the > > > > >> > identity is defined in a module that is not imported, and is not > > > > >> > defined in the current module. > > > > >> > > > > >> I think a better solution would be to avoid prefixes in lexical-space > > > > identity > > > > >> values altogether and use the same string as in JSON encoding (RFC > 7951). > > > > The > > > > >> XPath expression from your example would become > > > > >> > > > > >> "../type = 'ietf-ospf:ospfv3'" > > > > >> > > > > >> Everything would then be straightforward and non-ambiguous. > > > > > > > > > > Yes, as I wrote in my previous email, I agree, this would be better. > > > > > But that's for YANG 2.0, unfortunately. > > > > > > > > Maybe not. If we agree that the last paragraph in 9.10.3 is wrong ang > > > > needs an erratum, then I think instead of saying that the XPath string > > > > value is the empty string as you suggested (which is weird and > > > > non-intuitive), this paragraph can say that the value (only for XPath!) > > > > is as in RFC 7951. > > > > > > > > In fact, after re-reading sec. 9.10, I believe it is even not required > > > > to import the module in order to be able to use the prefix in a string > > > > literal, as "x" in > > > > > > > > "../type = 'x:ospfv3'" > > > > > > > > because it is just an XPath 1.0 string with no additional semantics, so > > > > module authors can equally well write > > > > > > > > "../type = 'ietf-ospf:ospfv3'" > > > > > > > > without importing "ietf-ospf". > > > > > > > > Of course, we could also replace the paragraph with a statement that the > > > > result of using bare identityref string values in XPath is undefined and > > > > thus force everybody to use the XPath functions. > > > > > > > > > > > > > I do not agree with this interpretation. > > > The term "prefix" is used 10 times in that section. > > > It is clear that the WG meant "prefix" not "module name". > > > This cannot be changed by an errata. > > > > So what do you suggest? The last paragraph in sec. 9.10.3 is clearly wrong. > > I agree it is wrong, but only for identityref values that are defined > in a module that has not been imported. I stronlgy agree w/ Andy that > this does NOT mean that we should change *working* and defined > behaviour in an errata. A more serious problem is that this text mixes up the prefix as defined in the YANG module with the prefix that applies to instance values. A newcomer that reads this text may wonder why an identity value is combined with a prefix of a module in which the identity is NOT defined. > > The intention (for better or worse) was that the value would use the > prefix used in imports. This means that if you want to do any kind of > comparision of the string value to some known identities, then you > must import that module so that there is a prefix defined. This was This is IMO not true. As I already wrote, for using a when expression like when "../type = 'ospf:ospfv3'" it is not necessary to import the "ietf-ospf" module and thus have the "ospf" prefix defined. If you think it is necessary, then point me to the relevant text. Lada > the intention. > > From this follows that (for all practical matters), the string value > of an identity defined in a module that is not imported doesn't really > matter. > > > Note also that this paragraphs tries to define the string value of an > > identityref node instance for any XPath expression, which needn't > necessarily be > > a simple EqualityExpr. > > > > /martin > > > > > > > Lada > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > >> Lada > > > > >> > > > > >> > > > > > >> > > > > > >> > /martin > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > Lada > > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > and > > > > >> > > > > > > > >> > > > module b { > > > > >> > > > ... > > > > >> > > > import ietf-ospf { > > > > >> > > > prefix y; > > > > >> > > > } > > > > >> > > > ... > > > > >> > > > leaf bar { > > > > >> > > > when "../type = 'y:ospfv3'"; > > > > >> > > > ... > > > > >> > > > } > > > > >> > > > } > > > > >> > > > > > > > >> > > > You may not like it, but these two modules are both correct > > > > according > > > > >> > > > to the rules defined in RFC 7950. The string value of the > "type" > > > > leaf > > > > >> > > > *when evaluating the when expression* is different in the > different > > > > >> > > > modules. See the last paragraph of section 9.10.3 in RFC 7950. > > > > >> > > > > > > > >> > > > > > > Also, potentially there can be a collision in prefixes > and > > > > then this > > > > >> > > > > > > > >> > > > also > > > > >> > > > > > > breaks down. > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > No, two modules cannot be imported with the same prefix. > > > > >> > > > > > > > > >> > > > > I have to disagree. An identity derived from the > > > > >> > > > > "ietf-routing:control-protocol-type" base identity can be > defined > > > > >> > > > > in a module that is not imported anywhere. If a server > declares > > > > such > > > > >> > > > > a module as implemented, then "rt:type" may have this value > per > > > > >> > > > > sec. 9.10.2. > > > > >> > > > > > > > > >> > > > > And, consequently, there may be two different modules with > > > > >> > > > > conflicting prefixes defining identities that are derived > from > > > > >> > > > > "ietf-routing:control-protocol-type". > > > > >> > > > > > > > >> > > > Sure, but this is not the point. > > > > >> > > > > > > > >> > > > > > > A moral of the namespace/prefix story in XML was that > relying > > > > of > > > > >> > > > > > > namespace prefixes having a particular value is a really > bad > > > > >> > > > > > > idea. I know that the cited paragraph was intended to > make > > > > such > > > > >> > > > > > > XPath string comparisons more deterministic, but it is > also > > > > >> > > > > > > problematic and should be avoided if possible. > > > > >> > > > > > > > > > >> > > > > > Note that this prefix is under the control of the module > > > > designer > > > > >> > > > > > writing the XPath expression. The same identityref value > might > > > > use a > > > > >> > > > > > > > > >> > > > > No, it is not. The prefixes appear in instance data. > > > > >> > > > > > > > >> > > > The prefix *in the when expression* is under the control of the > > > > module > > > > >> > > > designer, as explained above. > > > > >> > > > > > > > >> > > > You are correct that the prefix in an XML encoding is not under > > > > >> > > > control of the module designer, but noone has claimed that. > > > > >> > > > > > > > >> > > > I agree that it is unfortunate that context-specific prefixes > are > > > > used > > > > >> > > > for the identityref values. It would have been better if we > used a > > > > >> > > > context free representation, e.g. "<module-name>:<identity>". > But > > > > >> > > > that's another discussion. > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > /martin > > > > >> > > > > > > >> > > -- > > > > >> > > Ladislav Lhotka > > > > >> > > Head, CZ.NIC Labs > > > > >> > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > >> > > > > > > >> -- > > > > >> Ladislav Lhotka > > > > >> Head, CZ.NIC Labs > > > > >> PGP Key ID: 0xB8F92B08A9F76C67 > > > > >> > > > > >> _______________________________________________ > > > > >> yang-doctors mailing list > > > > >> yang-doctors@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/yang-doctors > > > > >> > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > yang-doctors mailing list > > > > yang-doctors@ietf.org > > > > https://www.ietf.org/mailman/listinfo/yang-doctors > > > > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- [yang-doctors] Yangdoctors last call review of dr… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Andy Bierman
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Juergen Schoenwaelder
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Juergen Schoenwaelder
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Andy Bierman
- Re: [yang-doctors] Yangdoctors last call review o… Ladislav Lhotka
- Re: [yang-doctors] Yangdoctors last call review o… Andy Bierman
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Martin Bjorklund
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem (acee)
- Re: [yang-doctors] [Lsr] Yangdoctors last call re… Rob Shakir
- Re: [yang-doctors] [Lsr] Yangdoctors last call re… Acee Lindem (acee)
- Re: [yang-doctors] Yangdoctors last call review o… Christian Hopps