Re: [I2nsf] Is there any objection of merging the content from draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?

Yoav Nir <ynir.ietf@gmail.com> Thu, 03 August 2017 11:27 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC288131EA2; Thu, 3 Aug 2017 04:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 puKQSJyL9lIy; Thu, 3 Aug 2017 04:27:34 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 7A9D4131D6B; Thu, 3 Aug 2017 04:27:34 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id s6so5661192qtc.1; Thu, 03 Aug 2017 04:27:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=iQg9x+ZCOGhcevJyHcBt9lFi2fQRv6cdzMS79JQNnQs=; b=ImVNewlNyLzZKCb891cT7+RqTI3dtB9QmZnc7fD2ZGS9Rpg+Qm3JBjFdIkBnvxhQDx ZCsGIyPw6yapiJhRqydtfWdiwtTvifDitzO8HPRw7P14sIDj9Uh00hliYebFhGBBIo/F mke6jmaLUuOWbbeB8A2ci6ja6eAe1gDQT4VbY09gSfaEfqXHwdVz7rA4cFbZQCivvCD/ QtJWhXSvHTmwj4qdAeqqQ1c+4Pl3fIUMyqO4mwBuR/zZiBC0oqJixgfXAJfV6JN7P2aG VW/b2sBG/ZY0WUtCw0IX4F2ZpCQfL4igJdFO+5wl/BoTgRAHxE2LJ5d2F6yMWmLD6hCZ FVSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=iQg9x+ZCOGhcevJyHcBt9lFi2fQRv6cdzMS79JQNnQs=; b=VTpIrJbv4sIq5Myv2OjL+vfI4z6doPpwkC8TqV+9feKwUYI+pvy6CIHkVbz3+S/1WF X4SA1H1rwuNDCY79ZEz8Y6FTwavKqCcpb5najES04L7PKRMwarzQ+p+wzL03tlLpcT8M qdbd1Y074FSsvMLEO9R/uyTrmkEexIgD7aIH8bC987VZ9izZiroiCrdiAAVdG/yxj83w XzLFgGy5cU6TVZP2yghvszVbeox7vMjkZLniUh7bsvo7Q3U+rZ9G9TGV9nOjtHY+CvGB c6OjPTxyIr7Fg/FrZ9vd5IKilRa+QHoX3oaWoCuZ8jkpCUjFRpOrB02bfFKxE5WpnI9y OvIQ==
X-Gm-Message-State: AIVw113S8W8Hbrvjj9FTBoqKNH16M5BSDqqk3V8MjKQ/zWlFNPSHRh62 6k3LvIM59JqTXA==
X-Received: by 10.200.44.212 with SMTP id 20mr1733106qtx.282.1501759653565; Thu, 03 Aug 2017 04:27:33 -0700 (PDT)
Received: from sio_centos_lt ([147.178.6.131]) by smtp.googlemail.com with ESMTPSA id b42sm28374968qkb.17.2017.08.03.04.27.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 04:27:33 -0700 (PDT)
Message-ID: <1501759648.16695.4.camel@gmail.com>
From: Yoav Nir <ynir.ietf@gmail.com>
To: adrian@olddog.co.uk
Cc: "'i2nsf@ietf.org'" <I2nsf@ietf.org>, draft-ietf-i2nsf-terminology@ietf.org, 'Kathleen Moriarty' <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 03 Aug 2017 14:27:28 +0300
In-Reply-To: <017401d30c41$e669d760$b33d8620$@olddog.co.uk>
References: <4A95BA014132FF49AE685FAB4B9F17F65943677F@SJCEML702-CHM.china.huawei.com> <B818037A70EDCC4A86113DA25EC020982209F4E6@SJCEML703-CHM.china.huawei.com> <CAHbuEH6RcEj7HDsM1QXE0pmoHh1yp-gYBy0d09RfuMw5HvSWrA@mail.gmail.com> <017401d30c41$e669d760$b33d8620$@olddog.co.uk>
Organization: Dell-EMC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.11 (3.12.11-22.el7)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/ZHgbK0qKM6j8rJfqcy-u-URD5as>
Subject: Re: [I2nsf] Is there any objection of merging the content from draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2017 11:27:37 -0000

Hi, Adrian.

I tend to agree that splitting the terminology around to several small
documents is not a good way to go.  

I think it should be OK to move the contents into the framework draft,
perhaps as an appendix, with an appropriate paragraph saying that the
terminology in this section is meant for the entire document set of
I2NSF and some of the terms are not used in this (the framework)
document.

There is one potential issue with doing it this way. We intend to get
the framework document published soonish. So if we add the terminology
there, it gets published in an RFC and gets "set in stone". While it's
always possible to add new terms afterwards, it gets messy to change the
meaning of existing terms already defined in the RFC.

Are we willing to accept this risk/constraint of future work?

Yoav

On Thu, 2017-08-03 at 11:18 +0100, Adrian Farrel wrote:
> FWIW, some context.
> 
> As we started to advance a number of I2NSF document we ran into a few problems:
> - Different documents used different terms for similar or identical concepts
> - Different documents used the same terms to mean different things
> - Different documents attempted to define the same terms, but actually introduced
>    discrepancies in the definitions
> - Documents started to acquire circular normative dependencies on each other
> - Documents made best efforts to duplicate definition text but were not kept
>    up-to-date and in synch
> 
> The terminology document was introduced as a way to provide one single point of reference for all terms and to ensure consistency.
> 
> Of course, I don't mind what solution to this purely non-technical issue is used so long as it adequately addresses all of the needs. And if the IESG has cycles to burn to work out how to publish terminology definitions without causing ambiguity or confusion, then it is fine with me that they do that (it will keep them from doing harm in the technical areas where they might not have the expertise to do the right thing :-)
> 
> But there are three concerns that I have:
> 
> 1. Moving *some* of the definitions from the terminology draft to another draft will leave behind other terms. That is to say, not all the terms currently in the terminology draft are currently used in just one other draft. So there will be an annoying and messy period of working out where the terms need to be moved to. Alternatively, the whole of the terminology draft should be subsumed into some other foundational document notwithstanding that that other document does not use those terms - that sounds easy, but I bet there will be review comments that say "delete this term because it is not used in this document."
> 
> 2. When new drafts are written there needs to be a central place to go to find the right term to use to prevent invention of new terms or re-invention of existing terms. 
> 
> 3. When a WG or document authors find themselves doing "whatever is necessary to get a document published" they are making pointless concessions to the arbitrary rules of Discusses placed on them by the IESG which risks over-running community consensus. That is, of course, a socio-political matter, and I don't expect the WG to engage on it, but individuals who care about the IETF might want to think it through.
> 
> I'm not really working on this stuff anymore, so this email really is only for context and to help you understand how we got to where we are.
> 
> Cheers,
> Adrian
> 
> > -----Original Message-----
> > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Kathleen Moriarty
> > Sent: 02 August 2017 20:17
> > To: John Strassner
> > Cc: i2nsf@ietf.org; draft-ietf-i2nsf-terminology@ietf.org; draft-ietf-i2nsf-
> > framework@ietf.org; Yoav Nir; Linda Dunbar
> > Subject: Re: [I2nsf] Is there any objection of merging the content from draft-ietf-
> > i2nsf-terminology to draft-ietf-i2nsf-framework draft?
> > 
> > Hi John,
> > 
> > As a standalone document, the terminology draft is a support document.
> > The IESG issued the following statement on support documents:
> > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html
> > 
> > I have no problem helping a WG to publish support documents, but would
> > like them to think through what they are doing. We typically see
> > terminology as part of a main document for a WG and not a draft by
> > itself.  If it's part of a standards track document (appendix or
> > terminology section), then there is no question on it's value.
> > 
> > You may want to take a look at the ballots for the WG documents that
> > have gone through the IESG to date and you'll see the types of issues.
> > Mainly it is the time/resources spent publishing such documents.  I'd
> > like to see the terminology published in some document, but not
> > necessarily as a stand alone document.
> > 
> > Best regards,
> > Kathleen
> > 
> > On Wed, Aug 2, 2017 at 1:51 PM, John Strassner
> > <John.sc.Strassner@huawei.com> wrote:
> > > I expressed some minor concerns before, and will do so again.
> > >
> > >
> > >
> > > ·         What is the reasoning against publishing an INFORMATIONAL RFC for
> > > terminology?
> > >
> > > ·         Many of the terms in the current terminology draft are not used in
> > > the framework draft
> > >
> > > o   This is because the terminology draft was originally conceived to work
> > > for many diverse subject areas
> > >
> > > o   The framework draft will not cover some of these diverse subjects in
> > > detail, and hence, does not need those terms; including them will make the
> > > reading awkward at best
> > >
> > > ·         Thus, I would recommend
> > >
> > > o   We keep the current terminology draft until these other subject areas
> > > mature and have WG-adopted drafts (a possible alternative is putting them on
> > > the wiki; I am not a big fan of wikis)
> > >
> > > o   We move the appropriate terms into appropriate drafts
> > >
> > > §  Note: this will cause duplication of terms – yet another reason to keep
> > > the terminology draft
> > >
> > >
> > >
> > > Regards,
> > >
> > > John
> > >
> > >
> > >
> > > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
> > > Sent: Wednesday, August 02, 2017 10:31 AM
> > > To: 'i2nsf@ietf.org' <I2nsf@ietf.org>; draft-ietf-i2nsf-framework@ietf.org;
> > > draft-ietf-i2nsf-terminology@ietf.org
> > > Cc: 'Kathleen Moriarty' <kathleen.moriarty.ietf@gmail.com>; Yoav Nir
> > > <ynir.ietf@gmail.com>
> > > Subject: [I2nsf] Is there any objection of merging the content from
> > > draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?
> > >
> > >
> > >
> > > I2NSF participants:
> > >
> > >
> > >
> > > During the IETF99 I2NSF Session, our AD Kathleen said that the current IESG
> > > doesn’t like to have RFC for Terminology only drafts. So we should consider
> > > merging the content of Terminology with other drafts. I2NSF framework draft
> > > would be a nature place to have the terminologies.
> > >
> > >
> > >
> > > If you have any objections or concerns of merging the content from
> > > draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft, please
> > > express them to the I2NSF mailing list.
> > >
> > >
> > >
> > > Thanks, Linda & Yoav.
> > >
> > >
> > 
> > 
> > 
> > --
> > 
> > Best regards,
> > Kathleen
> > 
> > _______________________________________________
> > I2nsf mailing list
> > I2nsf@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2nsf
> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf