Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

Alan DeKok <aland@deployingradius.com> Tue, 07 January 2020 02:59 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F253112013F; Mon, 6 Jan 2020 18:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4km2E6KLhR85; Mon, 6 Jan 2020 18:59:44 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5439412013A; Mon, 6 Jan 2020 18:59:44 -0800 (PST)
Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 4E6E564E; Tue, 7 Jan 2020 02:59:41 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <BYAPR13MB2485D2334C37A021659426039A3F0@BYAPR13MB2485.namprd13.prod.outlook.com>
Date: Mon, 06 Jan 2020 21:59:39 -0500
Cc: Warren Kumari <warren@kumari.net>, Tianran Zhou <zhoutianran@huawei.com>, "opsawg@ietf.org" <opsawg@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AFE0893-4AFD-48C1-B4E9-D11421601A68@deployingradius.com>
References: <BBA82579FD347748BEADC4C445EA0F21BF16C13D@NKGEML515-MBX.china.huawei.com> <CAHw9_iKEEO69L=0mbVfCN3_-R_X1_aeF2Yy2bpuwOmHJFW2JLA@mail.gmail.com> <BYAPR13MB2485C86E32F0DA658C144E2F9A3C0@BYAPR13MB2485.namprd13.prod.outlook.com> <0534493D-3285-4945-B293-419BAC2B640E@deployingradius.com> <BYAPR13MB2485D2334C37A021659426039A3F0@BYAPR13MB2485.namprd13.prod.outlook.com>
To: Haoyu Song <haoyu.song@futurewei.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/uNm5tBPPXGYfIPizmK-TXQnoGmo>
Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 02:59:47 -0000

On Jan 6, 2020, at 9:29 PM, Haoyu Song <haoyu.song@futurewei.com> wrote:
> [HS] Indeed I tried to describe some practical problems on applying a specific set of techniques and then to propose an architecture (we call it a framework). A solution can be based on it, but itself cannot be used as a solution directly. 

  Then this document describes an architecture, not a solution.  Which is fine.  There are many IETF architecture documents.  But they are rather less enthusiastic.

> [HS] What I want to express here is that, as far as I know, no other OAM technique provides the same capability as this new type of technique such as IOAM. I can change the word if it sounds improper. 

  Then say "no existing technology solves this problem".  That is a statement of fact.  Engineering is done on facts, not on enthusiasm,

> [HS] I'm fully aware of the existence of ForCES, I just didn't see its wide application in real products.

  Irrelevant.  The programmable data plane was being standardized going back to 2000.  So this document is entirely wrong when it says "with the advent of the programmable data plane".

  What would be factual would be to say "existing technologies do not fix this problem".

> [HS] Fair enough. I would use simple words instead. After reading the document, I hope the reader can recognize the issues and agree that our proposed framework or architecture makes sense for practical deployments, and start to think about how to fill the standard gaps to make it happen. I think this is the core value of this draft.  

  I reiterate my objection that this draft says essentially nothing.  And as such, does not belong in the IETF.

  Alan DeKok.