Re: [Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08

Stewart Bryant <stewart.bryant@gmail.com> Wed, 08 July 2020 12:48 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F443A09E0; Wed, 8 Jul 2020 05:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ahr2InK8iuVy; Wed, 8 Jul 2020 05:48:44 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 C24223A09DF; Wed, 8 Jul 2020 05:48:43 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id r12so48774823wrj.13; Wed, 08 Jul 2020 05:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KFh5B1faOHRFj86xZRD3LI1hF81k8O7qlLXFBcVEx+4=; b=jSCfVZzyB4K28Yx1nWTm/7VjPoijHOA+6rBnrbugoB0AgMcy5aw6+7wafhSZF2GCP6 JD8psouGxXfSgP0NObL4gDak8YiwduwDGd4dJLQaGt8XRIMnVfWI1xCW1KuGSAoUWVFr InADvYrtB9i/XzE/L3pMYUttrK063XlndFmpBUqtpPpBUiv16pwCQu84eK8DpXnO1d2a WuZRIy1vt8397b+CS6oJ4N0gzsE7kjUCeKHaggIJCZlweMr4yTxHQyTNd+lDUy1+kkHv nCV8Ifrms8tpmrnsT4X1lzfNCqhhV1G5In1Ad/X0rj5TF//5S6A98mT0MIjoGzReoqel G7ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KFh5B1faOHRFj86xZRD3LI1hF81k8O7qlLXFBcVEx+4=; b=qTviMf5sOV1AAdWewL7cLsNl3YgYxP4oaYgXBcmlcB48QmacqTEVN8MZeTJT+KJpA9 O8ntb58MPMKCf6SFP0dEuZNto0NW7cYfi5inTvyl192oj1YJVF2oTjmc1gVUlYt37Gej TdqEG+C4VWd6J/FmJG/I9Fwl83FdanTEFlJxM2sxM/fyakEQyYtmqiJiv06INweX6MzY 6sXia4jf2gG2MdvoeLQFJOjkd6bt3UelKfc43yrCcuD/tSeLJuNdZgIGRbprG3IhPZxO 4MJZ277xQ4RZmCBydDlSBGo0pCK148CmXC679kc5s1gxEqww4c+G8RZh6bkgI9Q2X0rQ G6HA==
X-Gm-Message-State: AOAM533vcbQj262lsI6FKcGEVqfIf9Evvu3LQTJKW+E94NiMrHs40v8s AQmF5RG+UZ4BjJxi5/vA+Q1JByTlplk=
X-Google-Smtp-Source: ABdhPJwGt+VqG7+fFmzmqAeUTYw0aTgn/RcNVVG6pFnGn+m2TmL5asDUXlLWu654bV3M32VgJSon7g==
X-Received: by 2002:a5d:4a84:: with SMTP id o4mr16742288wrq.104.1594212522064; Wed, 08 Jul 2020 05:48:42 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id x7sm5999082wrr.72.2020.07.08.05.48.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 05:48:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <B6EA27BB-72F2-4E91-8B90-4D4DC2262E03@episteme.net>
Date: Wed, 08 Jul 2020 13:48:40 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Review Team <gen-art@ietf.org>, mpls <mpls@ietf.org>, draft-ietf-mpls-sfl-framework.all@ietf.org, Last Call <last-call@ietf.org>, rtg-ads@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <29919CCE-2FA8-487C-BFE3-BB38D0766A2B@gmail.com>
References: <159345181106.6204.7060455676708406175@ietfa.amsl.com> <C575861D-0C01-4245-9B36-A3E5B17F6D4F@gmail.com> <B6EA27BB-72F2-4E91-8B90-4D4DC2262E03@episteme.net>
To: Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/jrOddASY1md1zoZhxvtc0DyWOpc>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 12:48:46 -0000


> On 30 Jun 2020, at 17:55, Pete Resnick <resnick@episteme.net> wrote:
> 
> On 30 Jun 2020, at 7:24, Stewart Bryant wrote:
> 
>>> On 29 Jun 2020, at 18:30, Pete Resnick via Datatracker <noreply@ietf.org> wrote:
>>> 
>>> Minor issues:
>>> 
>>> It is not clear to me why this is being sent for Informational instead of
>>> Proposed Standard. The shepherd's writeup does not justify it, and in fact the
>>> writeup refers to the document as a "specification", which is exactly what it
>>> appears to be. It defines the use of SFLs, describes how they are processed by
>>> the endpoints, describes how they are aggregated, etc. While the document may
>>> not be standalone, I don't see how it's really an Informational document. I
>>> suggest restarting the Last Call for Proposed, and if for some reason it needs
>>> to be Informational, it can always be downgraded after Last Call.
>> 
>> Pete - the “tradition”...
> 
> I hear songs from "Fiddler on the Roof" in my head...
> 
>> ...in routing is that such documents are Informational and the detailed protocol specifications are standards (there are a couple of those in progress about to finish baking). I leave it up to our AD to pass judgement on the matter as this is a simple fix, but I don’t think the changed status is REQUIRED.
> 
> Absolutely agreed that it is not required, but given that this does contain specification, and how much less scrutiny is given to Informational document as against Standards Track (see, for example, the IESG balloting rules on each), Standards Track seems more sensible. But the world remains intact either way.

I await judgement of the IESG on the matter.

> 
>>> The Security Considerations section says, "The issue noted in Section 6 is a
>>> security consideration." I'm not sure I understand why that is.
>> 
>> Section 6 explains the privacy considerations, and privacy and security are close friends so I cross referenced the section rather than repeating it. I suggest that we wait to see what SECDIR wants to do before changing any text.

Note removed by popular request

> 
> Yes, glad to defer to SECDIR on this.
> 
>>> Nits/editorial comments:
>>> 
>>> Section 1: "(see Section 3)" seems unnecessary.

Removed

>> 
>> I can take that out on the next version, it was intended as a forward reference to a completely new contract in MPLS.
>> 
>>> Section 3: I thought the "Consider..." construction made those paragraphs
>>> unnecessarily wordy and a bit harder to follow.
>>> 
>> I will reword the first two sentences  para 2 of section 3 to simplify the language.

As an example application of this technology, let us consider a
pseudowire (PW) {{RFC3985}} on which it is desired to make
packet loss measurement. Two labels, synonymous with the PW labels, are obtained
from the egress terminating provider edge (T-PE). By alternating
between these SFLs and using them in place of the PW label, the PW
packets may be batched for counting without any impact on the PW
forwarding behavior (note that strictly only one SFL is needed in
this application, but that is an optimization that is a matter for
the implementor). The method of obtaining these additional
labels is outside the scope of this text, however,
one control protocol that provides a method of obtaining SFLs  is described in
{{I-D.bryant-mpls-sfl-control}}.

Best regards

Stewart