Re: [Rats] Call for adoption (after draft rename) for Yang module draft
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 18 November 2019 12:46 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36249120853 for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 04:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qKFe0T73hrgW for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 04:46:53 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 35D261200EB for <rats@ietf.org>; Mon, 18 Nov 2019 04:46:53 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id u13so14378677ote.0 for <rats@ietf.org>; Mon, 18 Nov 2019 04:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jDnMlqL0eF7mI68Qby0n4nye8kN0h2M+oB2giVPVIyg=; b=e/rMGfxZXSElKNNllOnScD2iuvlNw1TlpFAXnuS8mACn9ZsK3pFg1a6jZKJsIyUZgm KHfnbEpGGShvsf2sfZr+4xxC2S6Urlv7UBK8x9k8C98jKweljxfr/e0XKDjUYOO913JK 6EUu1LCVbwVi0HqXLN1YCqUlFiXUw28b3JZIxeSIYyetceaFSsnWtnZiavJ9H1dZBH3u POhPqEOh5/jWBlR7JX5IY8mqYX0F9TLZHxH5BIkqILFKbBzyo3j2CYsSV8UjdUONv7It TBSdZIR8H9v/bSBC0mn5jpcCrIYe8LeIykvfANGManLruHibaGqKoRVUaYR/czYrDlK9 FRpg==
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=jDnMlqL0eF7mI68Qby0n4nye8kN0h2M+oB2giVPVIyg=; b=TGqVHfRcYswYbJbzV+NYzGE7IjipTRw6bnjdosWyBbTExuoNo3IoYu4JLx8IdPk8oO 840KZzEP5GNXkSBeltzny2wztuU2o7E+swU2/YbgfuIec9gHPeuhFtCOJEk0ZVn+pxRx OKyVDgao5LyIIFipFoGAheNnDp0szSptlH/gSBmQwjx235aS7R6FPy00vitJnMc2gjLT xSgklk3dhhVgaP2/lP8RfQchfwXkdPsBlUYnATMEeAlT9TmoKvKiZ0auVeyQWJ1rHFT/ PNeeoaI2abaLIQH39aQzGT1di3WB1oQY7GWVFKDuJ0U5EFagNUPPOOMDGSgli3hPVBa5 sFwA==
X-Gm-Message-State: APjAAAUWTZ3DiWGOxwN9C//CUzqfp4my+5FQB7P4XJ1XUWJTRfmFNigr At9uINFmsU04bVT7XDWcUXyvn0yKxyi28czUXXMv1F0D
X-Google-Smtp-Source: APXvYqxVA0c0naJ9T95MGhOrHdwt+zd8qd/yAODq/0hun19gehBiMrFc8hddsHkk19ND/Raf0UxNxi5dJU5CVuvpe9U=
X-Received: by 2002:a9d:5902:: with SMTP id t2mr2648069oth.151.1574081212516; Mon, 18 Nov 2019 04:46:52 -0800 (PST)
MIME-Version: 1.0
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <6E7D64B4-2049-4D0A-ADC5-CA3F0647779B@island-resort.com> <MWHPR21MB07840B6CF7BEE0A11ABE54BFA3700@MWHPR21MB0784.namprd21.prod.outlook.com> <DM6PR11MB4154BB7B7BA4A9CFAEDE1506A1700@DM6PR11MB4154.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB4154BB7B7BA4A9CFAEDE1506A1700@DM6PR11MB4154.namprd11.prod.outlook.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 18 Nov 2019 07:46:15 -0500
Message-ID: <CAHbuEH5cFi8yJ99OSNKD+ws5hGf14gDGcb3hoqrBO7++FmABzQ@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, Laurence Lundblade <lgl@island-resort.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000850e5e05979e5772"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Ijorw5edVlmWabpUisPg-VwHUFg>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 12:46:57 -0000
On Fri, Nov 15, 2019 at 9:38 AM Eric Voit (evoit) <evoit@cisco.com> wrote: > *From:* Dave Thaler, November 15, 2019 2:39 AM > > Netconf is not the only protocol supported by routers. > > Routers also support IPv4, IPv6, link-layer protocols such as Ethernet, > routing protocols, often things like DHCP relay, RADIUS, etc. > > <Eric> Below I would have said " Router/YANG" below rather than > "Router/NETCONF". > > > > I have not yet seen a compelling reason to use a pull-based mechanism > instead of a push-based mechanism via another protocol the routers already > support. > > <Eric> Router vendors want push-based mechanisms too. And NETCONF does > push. See RFC-8640 and RFC-5277. > > > > The only reason I’ve heard so far is “because they support netconf and > we’re used to it”, to which the counter argument is as above: > > they support other things too and we’re used to them too. > > <Eric> There is piles of documentation in the IETF and beyond detailing > the reasoning and extent of consolidation on YANG for network management. > IETF, IEEE, MEF, OpenConfig, and others forums are defining these. I > wouldn't expect another anytime soon. > > > > NETCONF can support YANG. Other transports can support YANG. The current > draft under an adoption call does not specifically reference NETCONF. > > > > In order to know who to pull data from, the Verifier has to have some > indication from the Attester that triggers the attestation request > > indicated as Step 1 in draft-fedorkow-rats-network-device-attestation. So > in reality, there has to be a step before step 1, > > whereby the Attester does something that makes the Attester discoverable > by the Verifier. That step could have included the EAT or the TPM data > > expressed in the YANG draft, or whatever else, and then you’ve avoided the > need for netconf, and reduced the number of round trips, > > improving latency and bandwidth. > > <Eric> It is already possible to subscribe to existing proprietary YANG > attestation models. This requires zero extra round-trips. The push can > be leave the Attester in <1 sec. > > > > If there is a compelling reason to support a pull-based mechanism, and we > get consensus that we need it, then great. > > But so far I haven’t heard one. > > <Eric> A YANG model supports both push and pull. Application vendors want > a standard attestation model. That is why you have many network vendors > authoring this YANG draft under the adoption call. > > > > Honestly I don't understand the push-back. This should be a no-brainer. > Agreed, seems like an unnecessary rat hole. The conversation should move on. Thanks, Kathleen > > > /Eric > > > > Dave > > > > *From:* Laurence Lundblade <lgl@island-resort.com> > *Sent:* Wednesday, November 13, 2019 10:07 AM > *To:* Dave Thaler <dthaler@microsoft.com> > *Cc:* Smith, Ned <ned.smith@intel.com>; Oliver, Ian (Nokia - FI/Espoo) < > ian.oliver@nokia-bell-labs..com <ian.oliver@nokia-bell-labs.com>>; Nancy > Cam-Winget (ncamwing) <ncamwing@cisco.com>; rats@ietf.org; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang > module draft > > > > My version of technology bases for attestation is something like this: > > > > *Router/Netconf World* > > Millions of devices. Currently TPM oriented. Long possible transition to > EAT. YANG used to create very specific fine-grained interactions. No > privacy issues. > > > > *Web Browser World* > > Billions of devices. Current attestation use is primarily WebAuthN / FIDO. > JWT is used heavily for authentication so would be more EAT oriented, but > TPM attestation is supported in FIDO. Larger use of attestation may evolve. > Fine-grained interactions are with WebAPIs (Javascript) (sort of parallel > to YANG for routers). Big privacy issues. > > > > *Mobile App World* > > Billions of devices. Main attestation use is Android’s Keystore. This is > EAT-like, but based on X.509. Fine grained interactions are Android APIs. I > may be out of date, but so far IoS doesn’t do attestation. Privacy issues > vary by app. > > > > *IoT World* > > Billions of devices most likely going to trillions. Attestation is a > critical enabling feature in this world. There are lots of protocols and > formats involved. TPMs are too expensive for many of these, but are > probably in use somewhere. No privacy issues for a large portion of this > world. > > > > The router world is the smallest, but it is “well represented” because > this is the IETF. > > > > I see EAT as applicable to all these worlds, where the YANG module is just > for the smallish router world. So I mostly agree with Dave about > proportions, however this is the IETF where YANG modules are created. > (Maybe I should go join the W3C world and work on attestations APIs for > browsers after RATS is done). > > > > LL > > > > > > > > On Nov 11, 2019, at 5:43 PM, Dave Thaler <dthaler@microsoft.com> wrote: > > > > As far as I can understand from draft-birkholz-rats-basic-yang-module-01 > and > > draft-fedorkow-rats-network-device-attestation-01, they break down the use > case > > space as follows: > > > > Requirements? > > +--------------+---------------+---------++--------------- > > | RoT | Host Firewall | Privacy || Solution > > | Type | Enabled | Needed || Pieces > > +--------------+---------------+---------++--------------- > > 1 | SGX | No | No || > > 2 | SGX | No | Yes || > > 3 | SGX | Yes | No || > > 4 | SGX | Yes | Yes || > > 5 | TrustZone | No | No || > > 6 | TrustZone | No | Yes || > > 7 | TrustZone | Yes | No || > > 8 | TrustZone | Yes | Yes || > > 9 | TPM | No | No || > draft-birkholz-rats-basic-yang-module-01 > > 10 | TPM | No | Yes || > > 11 | TPM | Yes | No || > > 12 | TPM | Yes | Yes || > > 13 |SecureElement | No | No || > > 14 |SecureElement | No | Yes || > > 15 |SecureElement | Yes | No || > > 16 |SecureElement | Yes | Yes || > > 17 | Firmware | No | No || > > 18 | Firmware | No | Yes || > > 19 | Firmware | Yes | No || > > 20 | Firmware | Yes | Yes || > > .... | ... | | || > > > > And draft-fedorkow-rats-network-device-attestation-01 further scopes > itself down > > by only being applicable to cases with "embedded" apps only = Yes, and > where > > the security policy is only an Exact match against reference values = Yes. > > I believe that the yang draft doesn't have those two restrictions, from my > reading. > > However, the point is that both drafts are VERY narrow, and in the table > shown above, > > only address 1 out of 20 possibilies in that space. > > > > In contrast, the TEEP WG decided that it was not interested in narrow > scopings > > (specifically something Global Platform specific), but instead wanted one > general solution. > > > > If the RATS WG spends effort on something that only addresses a single row > out of 20+ rows, > > then do we expect 19+ other solutions to also be done in the WG? Or could > we work on things > > that are broader and happen to also work for row 9? > > > > I've seen others commenting on the fact that the YANG module only supports > TPMs and not > > other things (EATs etc), which would just add support for a couple more > rows, but still not > > be general. > > > > Personally, I would much rather see the WG spend effort on things that > really are generic, > > i.e., work with or without host firewalls, work with multiple RoT/TEE > types, etc., rather > > than seeing an explosion of point solutions. > > > > Dave > > > > *From:* RATS <rats-bounces@ietf.org> *On Behalf Of *Smith, Ned > *Sent:* Monday, November 11, 2019 10:12 AM > *To:* Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs..com > <ian.oliver@nokia-bell-labs.com>>; Laurence Lundblade < > lgl@island-resort.com>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com> > *Cc:* rats@ietf.org; Henk Birkholz <henk.birkholz@sit.fraunhofer.de> > *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang > module draft > > > > Right. This implies the RATS “token” should support existing “binary” > formats as an encapsulation (signed by a second TA where the TPM is a first > TA) or as a conveyance (unsigned?) token. Possibly, the only added value of > the latter is a tag that identifies it as a TPM binary format? > > > > > > On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - FI/Espoo)" < > rats-bounces@ietf.org on behalf of ian.oliver@nokia-bell-labs..com > <ian.oliver@nokia-bell-labs.com>> wrote: > > > > > Remote TPM attestations are useful and necessary the short run, but are > of very limited capability. I believe that > EAT will replace TPM > attestations in the long run (maybe decades) because they are far more > expressive. I know > others believe that too. > > > > I would disagree with the statement of "short run" ... TPM is practically > the only existing standardised (hardware, software, firmware, measurement - > x86 only etc) hardware root of trust in common use, ie: practically all x86 > machines, The attestation mechanisms provided are going to be around for a > very long time. > > > > From telco experience, 30 years ago we said SS7 would only be around in > the short term. > > > > > Thus, I am opposed to adoption with the current TPM-only draft. I’d be > OK with the current draft and a promise > to add EAT to it. > > > > Agree > > > > Ian > > > > -- > > Dr. Ian Oliver > > Cybersecurity Research > > Distinguished Member of Technical Staff > > Nokia Bell Labs > > +358 50 483 6237 > > > ------------------------------ > > *From:* Laurence Lundblade <lgl@island-resort.com> > *Sent:* 11 November 2019 00:44 > *To:* Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com> > *Cc:* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; rats@ietf..org < > rats@ietf.org> > *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang > module draft > > > > > > On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) < > ncamwing@cisco.com> wrote: > > > > So, Laurence, are you still OK with the adoption of the current draft with > a rename for now? > Thanks, Nancy > > > > I think the value add to the larger RATS effort of adding EAT support to > this YANG protocol is really high. It a core thing to do that helps bring > together the two attestation worlds and make the TPM and EAT work here less > like ships in the night. > > > > Remote TPM attestations are useful and necessary the short run, but are of > very limited capability. I believe that EAT will replace TPM attestations > in the long run (maybe decades) because they are far more expressive. I > know others believe that too. > > > > If we don’t include EAT in the YANG mode it is sort of like defining HTTP > to only convey HTML to the exclusion of PDF. We’re defining an attestation > protocol that can only move one kind of attestation even though we have > consensus on what the other one looks like. > > > > It seems relatively simple to add EAT support (or promise to add EAT > support). Pretty sure I heard Henk agree to add it. > > > > Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK > with the current draft and a promise to add EAT to it. > > > > LL > > > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > -- Best regards, Kathleen
- [Rats] Call for adoption (after draft rename) for… Nancy Cam-Winget (ncamwing)
- Re: [Rats] Call for adoption (after draft rename)… Guy Fedorkow
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Nancy Cam-Winget (ncamwing)
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- [Rats] clarity on JWT vs YANG-serialization: base… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Nancy Cam-Winget (ncamwing)
- Re: [Rats] Call for adoption (after draft rename)… Oliver, Ian (Nokia - FI/Espoo)
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] clarity on JWT vs YANG-serialization: … Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] clarity on JWT vs YANG-serialization: … Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] clarity on JWT vs YANG-serialization: … Henk Birkholz
- Re: [Rats] clarity on JWT vs YANG-serialization: … Anders Rundgren
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- [Rats] 答复: Call for adoption (after draft rename)… Xialiang (Frank, Network Standard & Patent Dept)
- [Rats] 答复: Call for adoption (after draft rename)… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Eric Voit (evoit)
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Laurence Lundblade
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Schönwälder
- Re: [Rats] Call for adoption (after draft rename)… Henk Birkholz
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- [Rats] 答复: Call for adoption (after draft rename)… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Dave Thaler
- Re: [Rats] Call for adoption (after draft rename)… Kathleen Moriarty
- Re: [Rats] Call for adoption (after draft rename)… Kathleen Moriarty
- Re: [Rats] Call for adoption (after draft rename)… Guy Fedorkow
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] 答复: Call for adoption (after draft ren… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Guy Fedorkow
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson
- Re: [Rats] Call for adoption (after draft rename)… Smith, Ned
- Re: [Rats] Call for adoption (after draft rename)… Michael Richardson