Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
David Ball <daviball@cisco.com> Fri, 25 August 2017 10:53 UTC
Return-Path: <daviball@cisco.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F0C132B9F for <l3sm@ietfa.amsl.com>; Fri, 25 Aug 2017 03:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.489
X-Spam-Level:
X-Spam-Status: No, score=-14.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6BeaxqzsG-zX for <l3sm@ietfa.amsl.com>; Fri, 25 Aug 2017 03:53:49 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E23132AA6 for <l3sm@ietf.org>; Fri, 25 Aug 2017 03:53:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78182; q=dns/txt; s=iport; t=1503658427; x=1504868027; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=X2T7zyyDlo+qY4IytS7K7oAP6QacFkyouf3Kv2jjcio=; b=BOJMh9dvhKFaxc1hNlJQBP3cJEPefUiVn5IE5Ph/Xi/sFaKAMAwz26LB dlG+AxNrXJpIpatBciMnJT89z3FqPwGyPCUG9z5Z7u1JHb66wmfEs32Hx lipQwIchdL05FB4wRYSQrqoMCiZrgWB24PR+iFGxVYKqeYu037O/U+vJg E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CMAABnAKBZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBgm+BT4EVjhR0kRR3lS4OggEDIQEKhRsChCwYAQIBAQEBAQEBayiFGAEBAQECAQEBGAEICjoHBAUCBQsJAg4KIAEGAwICJx8RBgEMBgIBAReKDggQkAGdZoInJ4MuiAsBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyqDT4FjK4JINIMmgRMVEUyCXYJhBYoKhxWPP4dWjHCCElqFCoNZhxeJcoNViHAfOIENMiEIHBUfKoUYBReBZgI/NgGHS4FFfAEBAQ
X-IronPort-AV: E=Sophos;i="5.41,425,1498521600"; d="scan'208,217";a="654182661"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2017 10:53:42 +0000
Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7PArfJC025133; Fri, 25 Aug 2017 10:53:42 GMT
To: Qin Wu <bill.wu@huawei.com>, "l3sm@ietf.org" <l3sm@ietf.org>
Cc: Stephane Litkowski <stephane.litkowski@orange.com>, Kenichi Ogaki <ke-oogaki@kddi.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
References: <B8F9A780D330094D99AF023C5877DABA9AA5D7A2@nkgeml513-mbx.china.huawei.com> <c76328ad-b71e-b2a3-92a4-b02beac2be7d@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAB78D5@nkgeml513-mbx.china.huawei.com> <e3289dda-b54f-6001-d4df-4ad6f43cbc91@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AACC436@nkgeml513-mbx.china.huawei.com> <6acab373-d50e-674e-1f8a-b95363ae7e4b@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAD04B2@nkgeml513-mbx.china.huawei.com>
From: David Ball <daviball@cisco.com>
Message-ID: <bbb82618-18c6-70d1-9a3d-a4cade93535f@cisco.com>
Date: Fri, 25 Aug 2017 11:53:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AAD04B2@nkgeml513-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------1490E7E15CA658A37CFC6956"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/cVWgkPlYW5bHacCeRoLvbUEAVEI>
Subject: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Aug 2017 10:53:55 -0000
Thanks - a couple more comments inline with [DB3]: On 25/08/2017 07:18, Qin Wu wrote: > > *发件人:*L3sm [mailto:l3sm-bounces@ietf.org] *代表 *David Ball > *发送时间:*2017年8月24日17:52 > *收件人:*Qin Wu; l3sm@ietf.org > *抄送:*Stephane Litkowski; Kenichi Ogaki; adrian@olddog.co.uk > *主题:*Re: [L3sm] New Version Notification for > draft-wu-l3sm-rfc8049bis-02.txt > > Thanks - more inline with [DB2]: > > On 24/08/2017 04:26, Qin Wu wrote: > > Thank David for follow up comments. See my reply inline below > marked with [Qin-1]. > > *发件人:*David Ball [mailto:daviball@cisco.com] > *发送时间:*2017年8月23日20:22 > *收件人:*Qin Wu; l3sm@ietf.org <mailto:l3sm@ietf.org> > *抄送:*Stephane Litkowski; Kenichi Ogaki; adrian@olddog.co.uk > <mailto:adrian@olddog.co.uk> > *主题:*Re: [L3sm] New Version Notification for > draft-wu-l3sm-rfc8049bis-02.txt > > Thanks Qin, I think most of the comments are being addressed. > Some responses below, I've snipped out the ones where we have > agreement. > > On 21/08/2017 07:47, Qin Wu wrote: > > > 2. In section 6.3, I think we can add a statement like: "Multiple > locations can be associated > > > with a single site, but a particular location cannot be associated > with more than one site." > > > (Personally I don't see the need for this restriction, but > this sentence is based on the > > > previous discussion). > > We will not be making this change (which seems consistent with > your view). A location is a description of a physical > location, while a site is part of a service (i.e., a CE). > There is no reason to prohibit a service having two co-located > CEs. And, of course, two different services could have sites > at a single location. > > > [DB] > Ok - in that case, for clarity, can we make the opposite > statement: "Multiple locations can be associated with a single > site; similarly, a particular location can be associated with more > than one site." > > > [Qin-1]:The statement we like to put is: Each site is associated > with one location or more locations. > > > [DB2] I think we already say that; but it is the converse I would like > to add, i.e. each location can have one or more sites. > > [Qin-2]:I think the text MUST be consistent with the model. In the > model, the site and location are organized as: > > One site can have one or more location. Not the other way around, in > the text, we can see multi-location site is one typical example that > is discussed in the draft. > > “ > > +--rw sites > > +--rw site* [site-id] > > +--rw site-id svc-id > > +--rw requested-site-start? yang:date-and-time > > +--rw requested-site-stop? yang:date-and-time > > +--rw locations > > | +--rw location* [location-id] > > ” > > Considering consistency and clarity, I think we should use statement I > mentioned above previously. > [DB3] Ok, but I think that's just a phrasing issue. Would you be happier adding "Two or more sites can be associated with the same location, by referencing the same location ID"? > [Note: I came to the conclusion above based on the previous discussion > about SubVPN, where you said site-network-accesses in different sites > couldn't share physical components because different sites would be > associated with different locations. If multiple sites are allowed to > be associated with the same location, then they could also share some > physical components, right?] > > [Qin]: Sure, you can use " same-bearer" attribute to express that > constraint the relationship between source site-network-access and > target site-network-access. > > > > > > 9. In section 6.12.2.2, the second paragraph needs to be updated (or > > > deleted?) now that you have added the "direction" leaf. > > We don't believe there is anything actually incorrect about the > current text. > > > [DB] > Ok, in that case I don't understand it. :) Suppose there is a > provider-managed connection with a qos-profile, and the direction in > the qos profile is set to Site-to-WAN. The second paragraph says: > "the provider should ensure scheduling according to the requested > policy in both traffic directions", but the description of the > direction says: "used to specify the direction which qos profile is > applied to". Since the direction is Site-to-WAN in this example, this > means the profile would only be applied in that direction, not in both > directions. That seems to contradict the previous text that says it > should be applied in both directions? > > > [Qin-1]: I see your point. I think in case of provider-managed or > co-managed connection, QoS profile are applied to both direction based > on the second paragraph of section 6.12.2.2, that means the parameter > “direction” is set to “both”. > > In case of customer-managed connection, QoS profile is applied to the > direction from SP network to the customer site, that means the > parameter “direction” should be set to “WAN-to-Site”. > > That’ why we think there is actually incorrect about the current text. > Note that “direction” is just optional parameter in this model. > > On the other hand, if we want to enhance the current text, we might > consider: > > 1.allow direction at network access level to override the parameter in > the site level. > > 2.Use “direction” condition to replace “provider-managed, co-managed, > customer-managed” condition in the text and allow more flexibility to > apply QoS profile to appropriate traffic direction. > > But I like to talk to the design team for this first. > > > [DB2] Ok - option 2 would be my preference but lets see what others think. > > [Qin-2]:ok, I have asked design team to express on the list if they > have different opinion. > > > > > 12. The value carried in the svc-mtu leaf is now described more > clearly, but its intended > > > use is still unclear, at least to me. Would something like the following be > correct? If > > > not, what is the correct expression of how to interpret this leaf? > > > "For a given VPN service, the service provider may discard (or for IPv4, may fragment) > > > packets that are longer than the smallest svc-mtu across all > site-network-accesses for > > > all sites in the VPN." > > We think that SPs are used to the concept of link MTU. svc-mtu > modifies the link MTU for the site-access links within the scope of a > particular service. We think that an SP will know exactly how to > handle packets that exceed MTU values > > > [DB] > Ok, so the intent is that this is just local to the > site-network-access. I.e. we could say: "Packets transmitted over the > site-network-access that are longer than the svc-mtu may be discarded > (or for IPv4, fragmented)." > > [Qin-1]: I would prefer to leave this up to SP to determine how to > deal with MTU exceeding, we can not limited only to discard or > fragmented, does this make sense? > > > [DB2] Yes - that is why I said "may be discarded" instead of "must be > discarded". With my suggested text, it is still up to SP to determine > how to handle it, but we are providing some warning for the customer. > > [Qin-2]:I still feel this model is just a service model which is not > directly code implemented on the network device to control the network > operation. I am reluctant to add this lower layer constraint to the > service parameter in the service model. SP may instruct the management > system to provision the network device with appropriate policy. > [DB3] I completely agree; my point is to provide some information to the customer about how the service might behave if they request a particular value for the MTU. David > > 13. In the new filters container, there is a list of filters indexed by type (ipv4, > ipv6, > > > lan-tag, or vpn-policy-filter-type). Each filter contains a leaf-list of IPv4 > prefixes, > > > a leaf-list of ipv6 prefixes and a leaf-list of lan-tags. Is the intent that the > contents > > > of the filter matches the type? There is nothing to enforce that currently > - should > > > there be a "when" statement for each leaf-list, to restrict it to only the case > > > where the type is appropriate (e.g. the ipv4-lan-prefix leaf-list would have > > > "when ../type = ipv4")? > > > I don't really understand what this new filter list achieves over having a single > > > filter that could contain a mix of ipv4 prefixes, ipv6 prefixes and lan-tags. What's > > > the advantage of 3 filters each containing a single type over one filter > containing > > > all three types? > > RFC 8049 allowed multiple filters of any one type, but not a mix of > filters of different types. That's now fixed. > > > [DB] > Right, I was comparing to the previous version of 8049bis rather than > to RFC8049 (which I agree did not allow a mix of prefixes and LAN tags). > > > [Qin-1]With the old version of RFC8049, you still can have a mix of > prefixes and LAN tags, with two entries instead of single entry > > “ > > <entries> > > <id>ENTRY1</id> > > <filter> > > <lan-tag>LAN1</lan-tag> > > </filter> > > <vpn> > > <vpn-id>VPN2</vpn-id> > > <site-role>hub-role</site-role> > > </vpn> > > </entries> > > <entries> > > <id>ENTRY2</id> > > <filter> > > <ipv4-lan-prefix>LAN2</ipv4-lan-prefix> > > </filter> > > <vpn> > > <vpn-id>VPN2</vpn-id> > > <site-role>any-to-any-role</site-role> > > </vpn> > > </entries> > > ” > > > With the new version, you could have data like this: > > <filters> > <filter> > <type>lan</type> > <ipv4-lan-prefix>10.0.0.0/24</ipv4-lan-prefix> // IPv4 prefix > specified even though type is lan > </filter> > <filter> > <type>ipv4</type> > <ipv6-lan-prefix>10::0/64</ipv6-lan-prefix> // IPv6 prefix and lan tag > specified even though type is ipv4 > <lan-tag>foo</lan-tag> > </filter> > </filters> > > [Qin-1]: This can be easily fixed by add when statement, e.g., > > when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" { > > description > > "Only applies when vpn policy filter is ipv4-lan-prefix."; > > } > > > [DB2] Yes, adding 'when' statements would also work. > > [Qin-2]: Thanks. > > > I think the aim could be achieved with a single filter that contains > leaf-lists for IPv4, Ipv6 and lan tags, i.e.: > > container filter { > leaf-list ipv4-lan-prefix { type inet:ipv4-prefix; } > leaf-list ipv6-lan-prefix { type inet:ipv6-prefix; } > leaf-list lan-tag { type string; } > } > > This allows full flexibility, i.e. a filter can have zero or more IPv4 > prefixes, zero or more IPv6 prefixes and zero or more LAN tags. > > [Qin]: Similar to our design team's proposal in the new version, but > ipv4 and ipv6 and lan-tag are not of the same type. put them in the > same container seems weird,J. > > Our proposal follow similar construct proposed for " routing-protocol" > list in this model. > > > 15. For the site-network-access connection addressing, ip-connection/ipv4/address- > > > allocation-type is optional with no default, but > ip-connection/ipv6/address-allocation- > > > type has a default defined (static-addressing). This means it's impossible to > have a > > > site-network-access that only uses IPv4 addressing. I think the > default should be > > > deleted in the IPv6 case, so that an IPv4-only site-network-access could be > > > represented by simply not setting the IPv6 address-allocation-type. > > Good catch, to get consistent with original RFC8049, I would propose > to add the default for ipv4-only site-network-access as well. > > Note that we use "feature" for both ipv4 case and ipv6 case. > > > [DB] > Using "feature" doesn't solve the problem, since that turns IPv4 or > IPv6 on or off for every service. However, the SP might have some > IPv4-only services and some IPv6-only services. So, they need to > advertise both features, but they also need a way to not specify an > IPv6 connection address for the IPv4-only services, and to not specify > an IPv4 connection address for the IPv6-only services. > So, I believe the best solution is to delete the default for the > address-allocation-type in both cases. > > [Qin-1]: I am fine to delete both default values, but > > RFC7950 section 7.6.1 said: > > " > > Note that if the leaf or any of its ancestors has a "when" condition > > or "if-feature" expression that evaluates to "false", then the > > default value is not in use. > > " > > To my understanding, if the server doesn’t support one feature or > advertise one feature, the default value will not in use. > > If the server advertise both features, it doesn’t say default value > for each feature MUST be specified. > > So if both features can be supported, is there any reason we only > specify only IPv6 connection or IPv4 connection? > > > [DB2] The difference is that features apply across the whole server - > if the ipv4 feature is disabled, then the server cannot support IPv4 > at all, and there can be *no* services with IPv4. However, the case I > was describing is different - in this case, there are some services > that support IPv4 and some that do not. For example, the SP might > offer an IPv4 product, and IPv6 product and a dual-stack product, > where the dual-stack product is more expensive. So some customers > might choose IPv4-only or IPv6-only - or a particular customer might > choose a mix of ipv4-only and ipv6-only services. This is why I think > the default should be deleted in both cases. > > [Qin-2]:Sounds reasonable to me, I will delete default if there is no > one against it. > David > > > > > David > > > > > Thanks for your time and effort. > > Qin > > On 09/08/2017 11:40, Qin Wu wrote: > > Here is the update to draft-wu-l3sm-rfc8049bis-02 based on > additional discussion on the list. > > https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt > > Thank David for additional comments. Thank Design team to help > address these comments. > > The main changes include: > > 1.Clarify the rational of the model in the section 5 based on > David's comment. > > 2.Add multi-filter and multi-VPN per entry support for VPN policy. > > 3.Modify description for svc-input-bandwidth leaf and svc-output- > > Bandwidth leaf to address inconsistency issue with the text in > section 6.12.1. > > 4. Add text to clarify the way to achieve Per-VPN QoS policy. > > 5. Remove address-scope-type since there is no common > understanding on this. > > 6. Modify the description of autonomous-system under container “BGP”to address David's comment on AS. > > Regarding provider address and mask to the model for the DHCP and > DHCP relay cases, talking with design team members, > > We believe these parameters are the one requested by Customer to > Provider and therefore we keep it in the model. > > Regarding Number of BGP sessions, eBGP multihop between loopbacks > and other similar issue, The design team agreed that it is not > > reasonable to enumerate all the cases this models doesn't support. > The current text has been clear about this. > > We believe that we have address all the comments. Thanks! > > -Qin > > -----邮件原件----- > > 发件人: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> > [mailto:internet-drafts@ietf.org] > > 发送时间: 2017年8月9日18:20 > > 收件人: Qin Wu; Luis Tomotaki; Kenichi Ogaki; Stephane Litkowski > > 主题: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt > > A new version of I-D, draft-wu-l3sm-rfc8049bis-02.txt has been > successfully submitted by Qin Wu and posted to the IETF repository. > > Name: draft-wu-l3sm-rfc8049bis > > Revision: 02 > > Title: YANG Data Model for L3VPN Service Delivery > > Document date: 2017-08-09 > > Group: Individual Submission > > Pages: 181 > > URL: > https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt > > Status: https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ > > Htmlized: https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-02 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-02 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-02 > > Abstract: > > This document defines a YANG data model that can be used for > > communication between customers and network operators and to > deliver > > a Layer 3 provider-provisioned VPN service. This document is > limited > > to BGP PE-based VPNs as described in RFCs 4026, 4110, and > 4364. This > > model is intended to be instantiated at the management system to > > deliver the overall service. It is not a configuration model to be > > used directly on network elements. This model provides an > abstracted > > view of the Layer 3 IP VPN service configuration components. > It will > > be up to the management system to take this model as input and use > > specific configuration models to configure the different network > > elements to deliver the service. How the configuration of network > > elements is done is out of scope for this document. > > If approved, this document obsoletes RFC 8049. The changes are a > > series of small fixes to the YANG module, and some > clarifications to > > the text. > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > > L3sm mailing list > > L3sm@ietf.org <mailto:L3sm@ietf.org> > > https://www.ietf.org/mailman/listinfo/l3sm > > > > > > -- > David Ball > <daviball@cisco.com> <mailto:daviball@cisco.com> > > > > > -- > David Ball > <daviball@cisco.com> <mailto:daviball@cisco.com> > > > > -- > David Ball > <daviball@cisco.com> <mailto:daviball@cisco.com> -- David Ball <daviball@cisco.com>
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… Ogaki, Kenichi
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- [L3sm] 答复: New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… Jan Lindblad (jlindbla)
- Re: [L3sm] New Version Notification for draft-wu-… ke-oogaki@kddi.com
- Re: [L3sm] New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- Re: [L3sm] New Version Notification for draft-wu-… David Ball
- [L3sm] 答复: New Version Notification for draft-wu-… Qin Wu
- Re: [L3sm] 答复: New Version Notification for draft… David Ball
- [L3sm] 答复: 答复: New Version Notification for draft… Qin Wu
- Re: [L3sm] 答复: 答复: New Version Notification for d… David Ball
- [L3sm] R: RE: RE: New Version Notification for dr… Qin Wu