Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 27 July 2020 10:06 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4203A1820; Mon, 27 Jul 2020 03:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 iqm8sBZyZC_v; Mon, 27 Jul 2020 03:06:54 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130058.outbound.protection.outlook.com [40.107.13.58]) (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 6C5DD3A181A; Mon, 27 Jul 2020 03:06:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LRHHl6BYlMUBYhAka/w+rGqKNGy78HhNucrTxiZHkRyi3FvhTLEq3NUQA3CCSy2q7iiKcAssp8c0xeL6Y1pp6LdyE3TeNmwqnUnQLsgUZIMpeHi2arQHj0UvPi9FC6d/VMkp2YETdfjQR9UYQy/Ut+r35XtetdU7E5Wyq+1agSqPBNb/bZXi5EaWB1qtFXFbGlS848nngdeAlp3FzrtWb6ed0po3B/xVhcJxCer1ab7etwgEhr6q7F7jey9Wv/jeZHME6uO+ffVQlNFRc/NkSHO85G5ehKjQhel03A60ONPQCVBXRTShouT1ZlqElPkvdmGpAGYqhUhERmK/kInCXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rjzHLhkOVJz5rr+azoAMEpwlEn1klBRBqTNsn9q6Sys=; b=ipMZykUJWYHuWAvrVh1f5IqirNtRErWFS/G7LWSZ//Dacoxgxn9013GWvs+N2OLg8W5/ddYK6btKqFAH6/9UTXWFpr9bzjRg0Q6OHMmv94Epwx1L+qC5RbiTP6z9Xusgx/Zja0czcgVqNgxx9HwXv5oGRtlBmPMK5UEtCUsaecbSyolaCrhdVdrxILZyNS/4RJllNUyd6Snu9D0LB8hKJOIj2yqKc71routd8G3JZTaAxNxa78GNQ5wb87fJVN0GVlSW4/QGGvyaybrCW3qmbCBKFITjQSepvzI18Sx7GyjoWbwe3zMe05PQbNwF3e8dWDQ+1J1k7CGAoofUW5zRtQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rjzHLhkOVJz5rr+azoAMEpwlEn1klBRBqTNsn9q6Sys=; b=vU3EQCsdnScfEla6tlDdJ1WoHjCOWSBesa6Hdy9PQfCe0bfHnYQFvucuatQRVafC/xHdAnZHgPlAx3uWdkF0qezurqoX/mVXJNNviyt6OLs6rnuorkInfBXqcwHeHF0Myt890Q80QydZCd7z9ZdoDcPAOeMCcBzz4MsTAcc6fN0=
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com (2603:10a6:803:10::30) by VI1PR07MB5486.eurprd07.prod.outlook.com (2603:10a6:803:c2::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Mon, 27 Jul 2020 10:06:50 +0000
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::e8db:6218:4bd:1ce7]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::e8db:6218:4bd:1ce7%7]) with mapi id 15.20.3239.011; Mon, 27 Jul 2020 10:06:50 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "fmaino@cisco.com" <fmaino@cisco.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "ggx@gigix.net" <ggx@gigix.net>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
Thread-Index: AQHWVe6VGye2pzSCik2J/VoX/xyzaqj/dpkAgAAQTYCAAAH7AIABTlYAgAUNpwCAAPYoAIAUIiMAgABSQoA=
Date: Mon, 27 Jul 2020 10:06:50 +0000
Message-ID: <0369ce908f17a11e85b3ed9fc50a9d72b92f2380.camel@ericsson.com>
References: <159429861569.12326.4735174452265776723@ietfa.amsl.com> <1464C8A8-747A-45CB-8F62-9E96373C0D67@cisco.com> <54ee2cbb0c528b6c5aa36f88a8cf78d2d7d0ff09.camel@ericsson.com> <f6a3ce17-1033-01c3-2995-089845df1524@joelhalpern.com> <0bf2d991265c7d6db61b9a0493b5911e1bd6190c.camel@ericsson.com> <5D3EC015-D57E-4C39-AF8C-0592C2D72601@cisco.com> <c7b541053c33290d3a0b81d3a6e79bf618bf1e32.camel@ericsson.com> <AF12CC63-D541-4B30-8502-4210E422050D@cisco.com>
In-Reply-To: <AF12CC63-D541-4B30-8502-4210E422050D@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.202]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: daffc9d8-44d0-4301-ace1-08d83214c7e9
x-ms-traffictypediagnostic: VI1PR07MB5486:
x-microsoft-antispam-prvs: <VI1PR07MB54860CE6D8413FF2AFB6D2A195720@VI1PR07MB5486.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iwrXJzRN+NsGMKYTew9OtSV5KIRVC4FxOx/RM7AXArc87WBLRaw9tNTCwZns5kdE/JF9Wn7XGUrzXs1c1hbGBndsy2D2X8PqIAPKTsaemhDPIFVrEXmLf22Ns1GySFdtlmQEJqG9i3sJKmPUW1hUtI6jZiAASBvmNbL7pmdbbuHm0zKEvCufbi4ARuw305pGxJ5SAzvU1h8XOC6qf46p+M30OtTfDDFq1tZWRT7xy+3n4H+IkQb60ICaN3cjN7a8BCem1l2dqL0gPdeA51/Lht1xjfsNS/zpPdh4+PWcfF4tILlCUY96/+p2FAN+UYyXdBR3AUj3Aw/Q3VpUt2UXW2KE3hUWOfhdLDYeYA2pNT2tuwQRsZhhc+lyIFa2X1NE8dYeUzwhhZdJNQc2sN8L5andZZNlG05t8MByMX+fzh3vMcVfRuq4hmHldm+fvMUnRhxIrTBt7kJCIpDVUnq0oQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(39860400002)(396003)(136003)(2616005)(71200400001)(8936002)(5660300002)(44832011)(6512007)(316002)(36756003)(966005)(54906003)(4326008)(6506007)(76116006)(110136005)(2906002)(478600001)(186003)(6486002)(66946007)(86362001)(66556008)(64756008)(26005)(66446008)(91956017)(66476007)(53546011)(8676002)(30864003)(83380400001)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: z5xRlMijx6b48dqpKch0XyiHUTnTc2Z3sch8RoVS7XDNggskC/6/DbHSUyTgpQkhWo6mIhm02Ky7yk6/Xv4CqSatdGDj3xzb3PYAR/gde1Tk5vcv6BbFO78qtN9RAKSr99unlSy4fMnYTGenZHVroG/RbD7w9Wb6hlcIZS1MbpU+KAXmVN8qP+oLkdm2L3K9QB/BnHfFgwD9JB03ToA2KqxCFJocCOjLeW4ZYDjLXUn8bWCiAjnBsTBAbsCaCtQGjzSmR/ou191a10HjUDBAE6bhUbfUWHzCroNzcbecobREKQRBqRpFrJiNFtVciaVIva+xjQxclXOw9ZtyntfxyWwPbjMB+Owb1OqKWFHXHgM9hN9juUPsTl5qBGAXzqgKg41fWiKODO6iVaUEbDU4JnUPkeTpm4torr20KWXawsKiLSzDx3OLSbVkooYOGSPqV9W0H2SomyODFXSi9Idico+535cSFF8rc8RfgJJQxVyMlR1N7L0J50a471115dBIk1BpYE/YCA4c49fURPi0GpDHcX5cejjUdCqbXj1pQ/ZeTiDA5Q0siiOc3UP4ZbIcVvU3JANy1a7Hna9LC/CwTRkeoCYqk9loKy6JzoMQmNOZ8C0DSLfzCKlA1Dy249Xkhe7DATkuzOENhTE2HgSwPQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <BF842DA6C7BC084E91DCF038506AA31D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR0702MB3775.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: daffc9d8-44d0-4301-ace1-08d83214c7e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 10:06:50.6450 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6Tp99ZtU0mXrVhfzDxV0i1gq7Qfz9amjRIgaKTGCSAsSn+6A8ttIM5KemSSk/Vq0O1YGBYYfvSGiwocQ0nAL1gIAOuzyBybdOAntGbfiXRY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5486
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/tfOp1-_Ki2gVOqxbARswSHJkTvQ>
Subject: Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 10:06:57 -0000
On Mon, 2020-07-27 at 05:12 +0000, Fabio Maino (fmaino) wrote: > Hi Magnus, > Here is how we phrased it in rev -19. > > "Keeping in mind the reccomendation above, new encapsulated payloads, > when registered with LISP-GPE, MUST be accompained by a set of > guidelines derived from [I-D.ietf-lisp-rfc6830bis]. Such new > protocols should be designed for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). By following the guidelines in > [I-D.ietf-tsvwg-ecn-encap-guidelines], subnetwork designers can > enable a layer-2 protocol to participate in congestion control > without dropping packets via propagation of explicit congestion > notification (ECN [RFC3168] ) to receivers." > > Let us know if we should do any other change. This works for me. Cheers Magnus Westerlund > > Thanks, > Fabio > > > On 7/14/20, 2:45 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> > wrote: > > Hi, > > From my perspective the below is still a normative reference formulation. > You > have to read the reference to be able to determine if you SHOULD follow > them or > not. > > Maybe adopting the paragraph which draft-ietf-tsvwg-ecn-encap-guidelines > proposes to update RFC 3819 with: > > By following the guidelines in [RFCXXXX], subnetwork designers can > enable a layer-2 protocol to participate in congestion control > without dropping packets via propagation of explicit congestion > notification (ECN [RFC3168]) to receivers. > > Into the below text can make it inforamtive. > > > Keeping in mind the recommendation above, new encapsulated payloads, > when registered with LISP-GPE, should be designed for explicit > congestion signals to propagate consistently from lower layer > protocols into IP. Then the IP internetwork layer can act as a > portability layer to carry congestion notification from non-IP-aware > congested nodes up to the transport layer (L4). Such new > encapsulated payloads, when registered with LISP-GPE, MUST be > accompanied by a set of guidelines derived from [RFC6040]. > Following the guidelines in [I-D.ietf-tsvwg-ecn-encap-guidelines], > designers of new LISP-GPE encapsualtions can enable LISP GPE and the > encapsulated payload to participate in congestion control without > dropping > packets via propagation of explicit congestion notification (ECN > [RFC3168]) > to receivers. > > Please word smith. I still think this is borde line case for a informative > reference but at least it is not directly part of an RFC 2119 language > sentence. > > Cheers > > Magnus > > > On Mon, 2020-07-13 at 19:04 +0000, Fabio Maino (fmaino) wrote: > > Magnus, > > here is how we modified the latest version of the draft trying to > reflect your > > concerns, and to deal with the status of the ecn-encap-guidelines > draft. > > > > 4.2. Congestion Control Functionality > > > > LISP-GPE does not natively provide congestion control functionality > > and relies on the payload protocol traffic for congestion control. > > As such LISP-GPE MUST be used with congestion controlled traffic or > > within a network that is traffic managed to avoid congestion (TMCE). > > An operator of a traffic managed network (TMCE) may avoid congestion > > by careful provisioning of their networks, rate-limiting of user data > > traffic and traffic engineering according to path capacity. > > > > Keeping in mind the recommendation above, new encapsulated payloads, > > when registered with LISP-GPE, should be designed for explicit > > congestion signals to propagate consistently from lower layer > > protocols into IP. Then the IP internetwork layer can act as a > > portability layer to carry congestion notification from non-IP-aware > > congested nodes up to the transport layer (L4). Such new > > encapsulated payloads, when registered with LISP-GPE, MUST be > > accompanied by a set of guidelines derived from [RFC6040] and SHOULD > > follow the guidelines defined in [I-D.ietf-tsvwg-ecn-encap- > guidelines]. > > > > > > Thanks, > > Fabio > > > > On 7/10/20, 6:54 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com > > > > wrote: > > > > On Thu, 2020-07-09 at 13:57 -0400, Joel M. Halpern wrote: > > > Magnus, while it is possible we will still get hold ups on the > LISP > > > documents, I would really prefer to avoid creating a normative > > > dependency on something that at best is 6 months > away. Particularly > > > since the TSVWG has not cared enough to maintain the document. > > > > I can understand that. So then think you need to figure out what > > requirements > > from that document that you thought was relevant to say that they > MUST be > > included in a future specification and include them in the GPE > document so > > that > > the ecn-encap-guidelines would only be inforamtional reference. > > > > Cheers > > > > Magnus > > > > > > > > Yours, > > > Joel > > > > > > On 7/9/2020 1:50 PM, Magnus Westerlund wrote: > > > > Hi, > > > > > > > > No, RFC 3819 is not a good replacement for the draft. I would > note > > that only > > > > a > > > > minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap- > > guidelines. > > > > > > > > So I contacted the TSVWG chairs to try to get an update on when > the > > document > > > > could be ready. The WG has not abandonded it. Actually I found > an > > updated > > > > version from March that simply failed to make it into the public > > archive at > > > > that > > > > point. > > > > > > > > I will also note that the document has gone through one WG last > call > > and > > > > appear > > > > to be in descent shape. The only issue is that the main author > been > > busy > > > > with > > > > L4S that is a hot topic in TSVWG. > > > > > > > > We have requested an estimate for an update from Bob Briscoe so > that > > we can > > > > get > > > > this document going forward. > > > > > > > > So it might be possible to get this document approved before the > end > > of the > > > > year. > > > > > > > > As an alternativ there might be possible that you can > reformulate the > > > > sentence > > > > so that the high level requirement that the reader is expected > to > > derive is > > > > expressed in your document, and then you can get to a state > where the > > > > reference > > > > would only be informative? > > > > > > > > Cheers > > > > > > > > Magnus > > > > > > > > > > > > > > > > On Thu, 2020-07-09 at 16:51 +0000, Fabio Maino (fmaino) wrote: > > > > > Hi Magnus, thanks for your comments. > > > > > > > > > > Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the > draft > > is > > > > > expired, so making it normative might not be an option. > > > > > > > > > > Since it is meant to replace RFC3819, should we refer to > RFC3819 > > instead? > > > > > > > > > > Thanks, > > > > > Fabio > > > > > > > > > > > > > > > > > > > > On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" < > > noreply@ietf.org > > > > > > > > > > > wrote: > > > > > > > > > > Magnus Westerlund has entered the following ballot > position for > > > > > draft-ietf-lisp-gpe-17: No Objection > > > > > > > > > > When responding, please keep the subject line intact and > reply > > to all > > > > > email addresses included in the To and CC lines. (Feel > free to > > cut > > > > > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT > positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be > found > > here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------- > ------ > > ------ > > > > > - > > > > > COMMENT: > > > > > --------------------------------------------------------- > ------ > > ------ > > > > > - > > > > > > > > > > Section 4.2: > > > > > > > > > > To me it looks like this is normative reference: > > > > > > > > > > Such new encapsulated payloads, when registered with > LISP- > > > > > GPE, MUST be accompanied by a set of guidelines > derived from > > > > > [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. > > > > > > > > > > Section 4.3.1: > > > > > > > > > > Thanks for writing relevant guidance on how to mitigate > the > > risks > > > > > with > > > > > zero > > > > > checksum. Especially the one on traffic separation from > other > > traffic > > > > > so > > > > > that > > > > > it can be caught on the boundaries of the network to > prevent > > the risk > > > > > to > > > > > other > > > > > networks from corrupted traffic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Cheers > > > > Magnus Westerlund > > > > > > ------------------------------------------------------------------ > ---- > > Networks, Ericsson Research > > ------------------------------------------------------------------ > ---- > > Ericsson AB | Phone +46 10 7148287 > > Torshamnsgatan 23 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ------------------------------------------------------------------ > ---- > > > > > > > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [lisp] Magnus Westerlund's No Objection on draft-… Magnus Westerlund via Datatracker
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund
- Re: [lisp] Magnus Westerlund's No Objection on dr… Joel M. Halpern
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund