Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’
Andy Bierman <andy@yumaworks.com> Wed, 25 September 2019 16:00 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCCA1200C5 for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 09:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 rjW59rNP9Ycp for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 09:00:32 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C611200A1 for <netmod@ietf.org>; Wed, 25 Sep 2019 09:00:31 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id j19so6249124lja.1 for <netmod@ietf.org>; Wed, 25 Sep 2019 09:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z0PaCz/PsYCuIq3tM3T1DDbwhTdYZ0t6HubzcZFyWyU=; b=I86n5lHK8gjIQowh1KNpsaOaZ/vg/eTFpoMR01N46ighLkheFusy4q0MNct9lAX+IP FnIQz1MdF02V43ZdNlinPlzhYzU9KRAOpzUxQCEwQmBJrkeVr/xR7vmUZthURGDliDz/ UFfqkKnIHOHfOT2Cnfa4hsion2r5zowa7DopRXkpdL0BZq7vwTMbFJOpyvwBhAXVpHFE ajxs3NjbZRThpZ8qri+ORZiRIOy0akVSOVqxIOsb9eKTYuWnsdZE50+Q0X+mFXdvVnSp w1tgE50y9h6jxJMhVRtCFoCB3YhMFC46nOjyY/wytbPM0WVquBT35JHl7wRkC6Lx5+fp Ip6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z0PaCz/PsYCuIq3tM3T1DDbwhTdYZ0t6HubzcZFyWyU=; b=CEP+xfqZiaM0xCxE2YNfZrX0ENWzRz5OIxhiSp1kbfHTpsKGhE9QqyLyE6UEZ7mmgb /tXR+pv7zXL7SaM+AN0+SJ1ld4TxxONgIC31EzEmJ6C4yxyDl6OKuvizBAIcGSF7OmKu 7TT4/frQqGzpRoo3qW9ER2NGA8vznzT8tqtrm4iphn0rGYQbC2CS3GLsVo5lMDOvikMM Uto698rGCPZ/w5X6/kqhgtVCeHBF8SFE6oKnJsOKbHZUpN2G1AyydXUk6ChvKZ2OgYms gqFAjVj+GLuHvVuQ/a/HYEeeFiz+TbneQvNs4sg4j5dJroc4SYJRlo2rhOSqbRNEeui9 6qKQ==
X-Gm-Message-State: APjAAAV3DbsN0m4rN7XxQZuRXYLJ8lJ+EKnSfTo5c+ZFoSWV3ntR5j5I 6jjfixo8yTKe4Dw/j3BI9W+NyPraDQ+QO8R59mwhVA==
X-Google-Smtp-Source: APXvYqwicq8a6eSnYizdDIfmClBZWfYD1xyQahpDwHHO+Mtd5+EHZDV77TiNRkby8AOjHfLPUir6HbwdBcyhaJp+bcQ=
X-Received: by 2002:a05:651c:283:: with SMTP id b3mr7027520ljo.25.1569427229233; Wed, 25 Sep 2019 09:00:29 -0700 (PDT)
MIME-Version: 1.0
References: <5756FB984666AD4BB8E1D63E2E3AA3D001F20F2C@dggemm513-mbs.china.huawei.com> <MN2PR11MB4366224F81AD9884FA130B37B5B70@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHRc2R0ZBV25LRO6-FxV4GOf6HfN2NWzk9dEeNby3XVdUw@mail.gmail.com> <5756FB984666AD4BB8E1D63E2E3AA3D001F2CBA8@dggemm513-mbx.china.huawei.com> <CABCOCHQCs093B0j6XpGvNH+idrs+PZHAcOhe=KYDN3RpccqgZw@mail.gmail.com> <5756FB984666AD4BB8E1D63E2E3AA3D001F2CBE4@dggemm513-mbx.china.huawei.com> <CABCOCHRGzVpSOLue5bOx=5-ONWE=d1Hcn4RZ1=ZRAOx_sRqQLg@mail.gmail.com> <5756FB984666AD4BB8E1D63E2E3AA3D001F2D325@dggemm513-mbx.china.huawei.com> <B8F9A780D330094D99AF023C5877DABAA92F70D5@dggeml511-mbx.china.huawei.com> <VI1PR07MB398192BDD1C0BD1212FA15A69B870@VI1PR07MB3981.eurprd07.prod.outlook.com> <CABCOCHQRReksw-TWqdVLPEpuB05Un4bHts7asHxQtb9YKcvMMg@mail.gmail.com>
In-Reply-To: <CABCOCHQRReksw-TWqdVLPEpuB05Un4bHts7asHxQtb9YKcvMMg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 Sep 2019 09:00:17 -0700
Message-ID: <CABCOCHQcdz-5eNm+WZyFw7++XBtgk1xomuxKindsLavrpy3fGQ@mail.gmail.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: Qin Wu <bill.wu@huawei.com>, "Fengchong (frank)" <frank.fengchong@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Content-Type: multipart/related; boundary="000000000000800585059362c0b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7SAWj4tkSBQnO4Zl8lpM5h4SaTU>
Subject: Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 16:00:38 -0000
On Wed, Sep 25, 2019 at 8:59 AM Andy Bierman <andy@yumaworks.com> wrote: > > > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > >> Processing order should not matter. The evaluation of the 'when' >> statement should be done assuming an atomic application of the edit-config. >> >> >> >> I agree that a standards compliant server should do as Rob said: >> >> >> >> - For “scene 1”, the config change is accepted because the result of the >> config datastore after the edit-config has been applied is valid. >> >> - For “scene 2”, the config change is rejected because the result of the >> config datastore after the edit-config has been applied is invalid. >> >> >> >> From an implementation that may indeed mean processing the 'when' after a >> first pass that sets the various leafs to tentative values. But that's >> implementation detail. >> >> >> >> IMO the auto-clearing behavior of 'when' may be complicated but that is >> how it is defined (same with 'choice'). Clients can and should depend on >> things being automatically deleted. If you want validation errors (i.e. >> force the client to clear all the dependant leafs instead of auto-clearing) >> then use a 'must' statement. >> >> >> > > +1 > > YANG clearly defines "must" and "when" with different behavior. > A server that does not implement the auto-delete aspects of when-stmt is > not compliant to the RFC. > > oops -- s/must-stmt/when-stmt/ > Jason >> > > Andy > > >> >> >> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Qin Wu >> *Sent:* Tuesday, September 10, 2019 10:33 PM >> *To:* Fengchong (frank) <frank.fengchong@huawei.com>; Andy Bierman < >> andy@yumaworks.com> >> *Cc:* netmod@ietf.org; Yangang <yangang@huawei.com> >> *Subject:* [netmod] 答复: 答复: Please clarify implementation about ‘when’ >> >> >> >> Why processing order matter? My interpretation is both leaf node values >> (i.e.,leaf a, leaf b) should be validated together and commit as a whole, >> >> RFC6241 said: >> >> “ >> >> If the device is unable to commit all of the changes in the >> >> candidate configuration datastore, then the running >> >> configuration MUST remain unchanged. >> >> ” >> >> So validate the leaf node value in the edit-config request (message >> content validation) is not important, validate the leaf node value that is >> applied to <running> (datastore validation) is the key. >> >> >> >> I think what you want to raise is the server should hold on to send reply with an "unknown-element" <error-tag> in the <rpc-error> during payload parsing phase and NETCONF <edit-config> >> >> Processing until all validation complete, otherwise it seems server will >> >> Send multiple rply with "unknown-element" <error-tag> in the <rpc-error> which seems not reasonable. >> >> >> >> -Qin >> >> *发件人**:* netmod [mailto:netmod-bounces@ietf.org <netmod-bounces@ietf.org>] >> *代表 *Fengchong (frank) >> *发送时间**:* 2019年9月11日 9:29 >> *收件人**:* Andy Bierman <andy@yumaworks.com> >> *抄送**:* netmod@ietf.org; Yangang <yangang@huawei.com> >> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’ >> >> >> >> Andy, >> >> >> >> Whether different result would occur according different process order? >> >> According 8.3.2 >> >> if server process ‘a= 3’ firstly, b will be deleted by system and becomes >> a non-exist schema node, and then when ‘b=5’ is processed , server will >> report a ‘unknown-element’ error. >> >> But if server process ‘b=5’ firstly, it will be accepted by server, and >> then when ‘a=3’ is processed, b will be deleted by system, but report OK. >> >> >> >> If sec 8.3.2 is not right. What is the right? >> >> When node a and node b in the same request, and b tagged when condition, >> a’s value will cause b’s condition is evaluated to false, which is more >> prior? >> >> According you and Rob’s interpretation , maybe node ’a’ is more prior? If >> yes, why node ‘b’ should be processed later? >> >> >> >> I think whether in edit-config processing phase the configuration tagged >> when should not be evaluated and be delayed to commit or validate? >> >> When commit or validate operation is issued, the data node tagged when >> will be evaluated, and if it’s evaluated to false, this data will be >> deleted by system immediately, server should not report any error. >> >> >> >> >> ------------------------------ >> >> 华为技术有限公司 Huawei Technologies Co., Ltd. >> >> [image: Company_logo] >> >> 个人签名：冯冲 >> 手 机：13776612983 >> 电子邮件：frank.fengchong@huawei.com >> 公司网址：www.huawei.com >> ------------------------------ >> >> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 >> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 >> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed above. >> Any use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender by >> phone or email immediately and delete it! >> >> >> >> *发件人**:* Andy Bierman [mailto:andy@yumaworks.com <andy@yumaworks.com>] >> *发送时间**:* 2019年9月10日 10:56 >> *收件人**:* Fengchong (frank) <frank.fengchong@huawei.com> >> *抄送**:* Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org; >> Yangang <yangang@huawei.com> >> *主题**:* Re: [netmod] Please clarify implementation about ‘when’ >> >> >> >> >> >> >> >> On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) < >> frank.fengchong@huawei.com> wrote: >> >> Andy, >> >> Whether all constraints on content in <config> parameter will not be >> evaluated in payload parsing phase, for example, a leaf’s value exceed >> range? >> >> Netconf server should treat it as a block data? >> >> >> >> >> >> Field validation and datastore validation are 2 different things. >> >> when-stmt processing is neither. It is by far the hardest part of an >> automated server to get right. >> >> >> >> Another question: >> >> >> >> In edit-config processing phase, whether constraints on content in >> <config> parameter needs be evaluated? >> >> If yes, when configuration modification cause when condition is >> evaluated to false, the node tagged when will be automatically deleted by >> system. >> >> Then, in scene 2, whether different result would occur according >> different process order? >> >> >> >> >> >> Since the <config> parameter is anyxml, the YANG constraints defined on >> datastore contents >> >> are not enforced as part of RPC input validation. >> >> >> >> It would be nice if NETCONF defined behavior for providing <config> data >> that will get deleted >> >> immediately by the server. We have a CLI parameter for this since some >> vendors want to >> >> treat this as an error and other just silently delete nodes. Note that >> when-stmt can silently >> >> delete existing nodes not included in the edit. (Lada does not agree this >> is how it should work, >> >> so we need yang-next to decide. Maybe NETCONF needs a --force parameter >> for this purpose.) >> >> >> >> >> >> Andy >> >> >> >> >> >> >> ------------------------------ >> >> 华为技术有限公司 Huawei Technologies Co., Ltd. >> >> [image: Company_logo] >> >> 个人签名：冯冲 >> 手 机：13776612983 >> 电子邮件：frank.fengchong@huawei.com >> 公司网址：www.huawei.com >> ------------------------------ >> >> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 >> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 >> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed above. >> Any use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender by >> phone or email immediately and delete it! >> >> >> >> *发件人**:* Andy Bierman [mailto:andy@yumaworks.com] >> *发送时间**:* 2019年9月10日 10:19 >> *收件人**:* Fengchong (frank) <frank.fengchong@huawei.com> >> *抄送**:* Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org; >> Yangang <yangang@huawei.com> >> *主题**:* Re: [netmod] Please clarify implementation about ‘when’ >> >> >> >> >> >> >> >> On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) < >> frank.fengchong@huawei.com> wrote: >> >> Hi andy, >> >> >> >> You only talk about the constraints on rpc operation’s parameter? >> >> >> >> Do you have any opinion about my question? >> >> >> >> 8.3.1 does not apply to leaf 'b'. >> >> The RPC parameter is called 'config'. >> >> It has no when-stmts to evaluate. >> >> Rob is correct. >> >> His example shows what 8.3.1 would cover. >> >> >> >> Andy >> >> >> >> >> >> >> ------------------------------ >> >> 华为技术有限公司 Huawei Technologies Co., Ltd. >> >> [image: Company_logo] >> >> 个人签名：冯冲 >> 手 机：13776612983 >> 电子邮件：frank.fengchong@huawei.com >> 公司网址：www.huawei.com >> ------------------------------ >> >> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 >> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 >> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed above. >> Any use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender by >> phone or email immediately and delete it! >> >> >> >> *发件人**:* Andy Bierman [mailto:andy@yumaworks.com] >> *发送时间**:* 2019年9月10日 1:14 >> *收件人**:* Rob Wilton (rwilton) <rwilton@cisco.com> >> *抄送**:* Fengchong (frank) <frank.fengchong@huawei.com>; netmod@ietf.org; >> Yangang <yangang@huawei.com> >> *主题**:* Re: [netmod] Please clarify implementation about ‘when’ >> >> >> >> Hi, >> >> >> >> None of the operations that accept or return datastore contents expose >> the datastore objects >> >> in the RPC parameters. They are always anyxml or anydata. This means that >> >> there are no descendant data nodes defined at all according to the RPC >> operation >> >> and therefore the constraints on those nodes do not exist in the RPC >> operation either. >> >> >> >> >> >> >> >> On Mon, Sep 9, 2019 at 6:41 AM Rob Wilton (rwilton) <rwilton@cisco.com> >> wrote: >> >> Hi Frank, >> >> >> >> My interpretation of what the expected behaviour is as follows. >> >> >> >> For “scene 1”, the config change is accepted because the result of the >> config datastore after the edit-config has been applied is valid. >> >> >> >> For “scene 2”, the config change is rejected because the result of the >> config datastore after the edit-config has been applied is invalid. >> >> >> >> My interpretation is that the block of text in 8.3.1 payload parsing is >> primary intended to refer to RFC input. E.g. if the RPC was defined >> something like below, then the ‘when’ rule in 8.3.1 would enforce that a >> zip-code can only be provided if the country is the USA. >> >> >> >> rpc rock-the-house { >> >> input { >> >> leaf country { >> >> type string; >> >> } >> >> leaf zip-code { >> >> when “../country = ‘usa’”; >> >> type string; >> >> } >> >> } >> >> } >> >> >> >> Thanks, >> >> Rob >> >> >> >> >> >> >> >> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Fengchong (frank) >> *Sent:* 06 September 2019 08:19 >> *To:* netmod@ietf.org >> *Cc:* Yangang <yangang@huawei.com> >> *Subject:* [netmod] Please clarify implementation about ‘when’ >> >> >> >> Hi all, >> >> >> >> In RFC7950 secton 8, several description about when： >> In section 8.2 <https://tools.ietf.org/html/rfc7950#section-8.2>. >> Configuration Data Modifications >> >> o If a request modifies a configuration data node such that any >> >> node's "when" expression becomes false, then the node in the data >> >> tree with the "when" expression is deleted by the server. >> In 8.3.1 <https://tools.ietf.org/html/rfc7950#section-8.3.1>. Payload >> Parsing >> >> o If data for a node tagged with "when" is present and the "when" >> >> condition evaluates to "false", the server MUST reply with an >> >> "unknown-element" <error-tag> in the <rpc-error>. >> >> In 8.3.2 <https://tools.ietf.org/html/rfc7950#section-8.3.2>. NETCONF >> <edit-config> Processing >> >> Modification requests for nodes tagged with "when", and the "when" >> >> condition evaluates to "false". In this case, the server MUST >> >> reply with an "unknown-element" <error-tag> in the <rpc-error>. >> >> >> >> YANG module： >> >> module foo { >> >> namespace “http://foo.com”; >> >> prefix “foo”; >> >> Leaf a {…} >> >> Leaf b { >> >> When “a = 10”; >> >> } >> >> } >> Scene 1: >> >> The first edit-config request: >> >> <edit-config> >> >> <target> >> >> <candidate/> >> >> </target> >> >> <config> >> >> <a xmlns= “http://foo.com”>3</a> >> >> </config> >> >> </edit-config> >> >> This request will set a = 3. >> >> >> >> The second request: >> >> <edit-config> >> >> <target> >> >> <candidate/> >> >> </target> >> >> <config> >> >> <a xmlns= “http://foo.com”>10</a> >> >> <b xmlns= “http://foo.com”>5</b> >> >> </config> >> >> </edit-config> >> >> >> >> According 8.3.1, in rpc payload parsing phase, the a’s value in >> candidate datastore is 3,so leaf b’s when condition is evaluated to >> false, server will report ‘unknown-element’ error. >> >> Is it expected by user? >> Scene 2: >> >> The first edit-config request: >> >> <edit-config> >> >> <target> >> >> <candidate/> >> >> </target> >> >> <config> >> >> <a xmlns= “http://foo.com”>10</a> >> >> </config> >> >> </edit-config> >> >> This request will set a = 10. >> >> >> >> The second request: >> >> <edit-config> >> >> <target> >> >> <candidate/> >> >> </target> >> >> <config> >> >> <a xmlns= “http://foo.com”>3</a> >> >> <b xmlns= “http://foo.com”>5</b> >> >> </config> >> >> </edit-config> >> >> According 8.3.1, in rpc payload parsing phase, the a’s value in >> candidate datastore is 10, so leaf b’s when condition is evaluated to >> true, server will accept this request in payload parsing phase. >> >> >> >> In edit-config request processing phase, if leaf a’s modification is >> processed firstly, the a’s value will be changed to 3, so the b’s when >> condition will be false, when server process b’s modification, b will be >> treated as unknown-element, the edit-config request will fail. >> >> If leaf b’s modification is processed firstly, server will accept this >> modification ,because b’s when condition is true, and when server >> process a’s modification , this modification will be accepted, and b’s >> when condition will be evaluated to false, leaf b will be deleted >> automatically, the edit-config request will be OK. >> >> >> >> How server should process this situation? >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >>
- [netmod] Please clarify implementation about ‘whe… Fengchong (frank)
- [netmod] FW: Please clarify implementation about … Fengchong (frank)
- Re: [netmod] Please clarify implementation about … Rob Wilton (rwilton)
- Re: [netmod] Please clarify implementation about … Andy Bierman
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- Re: [netmod] Please clarify implementation about … Andy Bierman
- Re: [netmod] Please clarify implementation about … Andy Bierman
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- Re: [netmod] Please clarify implementation about … Andy Bierman
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- [netmod] 答复: 答复: Please clarify implementation ab… Qin Wu
- Re: [netmod] 答复: 答复: Please clarify implementatio… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- [netmod] 答复: 答复: 答复: Please clarify implementatio… Qin Wu
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Martin Bjorklund
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Martin Bjorklund
- Re: [netmod] 答复: 答复: Please clarify implementatio… Schönwälder
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Rob Wilton (rwilton)
- Re: [netmod] 答复: 答复: Please clarify implementatio… Schönwälder
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Martin Bjorklund
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- [netmod] What's the problem with NMDA? was Re: 答复… tom petch
- Re: [netmod] What's the problem with NMDA? was Re… Andy Bierman
- Re: [netmod] What's the problem with NMDA? was Re… Schönwälder
- Re: [netmod] What's the problem with NMDA? was Re… Andy Bierman
- Re: [netmod] What's the problem with NMDA? was Re… tom petch
- Re: [netmod] What's the problem with NMDA? was Re… Rob Wilton (rwilton)
- Re: [netmod] What's the problem with NMDA? was Re… Andy Bierman