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

Alissa Cooper <alissa@cooperw.in> Thu, 24 September 2020 14:15 UTC

Return-Path: <alissa@cooperw.in>
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 582D13A0D3D; Thu, 24 Sep 2020 07:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cooperw.in header.b=L3BmkV+k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OizcA9dh
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 p2lwIqwq6VXP; Thu, 24 Sep 2020 07:15:45 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A863A09DA; Thu, 24 Sep 2020 07:15:41 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 377855C01D0; Thu, 24 Sep 2020 10:15:41 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 24 Sep 2020 10:15:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=o 04B76I+bDHWgaASG4Q0ORhdgFpW+u8H1toeHGcWbl0=; b=L3BmkV+kfs9YrjLxQ +jL3G0CmmIrQD7cqvUyx6cPbZob6TFooM4M1309JQ3NQrs4rooPrs4nseKU8XrVI RbiEoNDyQgw3AI2Uv+jN04Vq1RCzYuyX+rx6NLpNBlXW1Wl4SsZ3EgYikyR4p6cv rKmll44ggTfaiHL1pJrsI8zgv3qlHSWFzvrrZNPoaL78uDPU8IfjXqkcY9OZ6w0x 2Wmwk9NqFBvLytloaRQUoGsOHWvIXCaT+eCqCNh95j42L8WBjdoc60HsieGBiPq+ Q7+v4LWT2P7yhk+g8fsHuSYQrsYnTohq4AiSZK2EWdHXT1dvXi6xGEELSdPm55BB QN5eA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=o04B76I+bDHWgaASG4Q0ORhdgFpW+u8H1toeHGcWb l0=; b=OizcA9dh4rS1uylb3mwDUv/59cYwRKX/oVaZ0qiCezsAoJ88RVRIHJ3CZ ImZt85lrw1EqrudgHWuyozypdV9KY/G6w7QOwr+02pmShJXXVR8rCyg1yu1fgoj+ sRcevupZ2uL6B1Vdj9w4b9EnRy4zAGQiwp4WxAERhzohbJlHoN2l3oLkZl8NLGL8 XICv2eP7gI4/mtsz8HUxI7X1j3uKHtJTpvjqyZyKuRQVc1XjL3leRIcSzkqide+f IPNH43tuI98diqN9aWRVjHhX9zIrNRp4HW5temEdBwCGl7PLuzMTggbJml/B8Cyg pT67JKIJradu55bWNyTRy26g/rhrQ==
X-ME-Sender: <xms:DKpsX0QUL-5RcVoeQ14kGKiJYjo2jKF-cfhUoEhdR13InMROBjXHUA> <xme:DKpsXxzV5qThO5O4WjUlT23sdQD-AdctEUQljmxMxbREmGhrmkuEM1ifGUXh1LKy- 2R6ZaH1SyGXZF-IPA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepveeuudejueejvedvffehjedtgfffieeklefhkeefueduffetieetfeektefg lefhnecuffhomhgrihhnpegsrhihrghnthdqmhhplhhsqdhsfhhlqdgtohhnthhrohhlrd gsvghsthdpihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeeinecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrse gtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:DKpsXx098E45zKNtntLglbHBPDIDFw-g_QLtV2Gvu7_sh9RtuFu73g> <xmx:DKpsX4B_0TQS9mw2f81Io2FcPJy4gOzY0Rn9lApNkAMggugn1Fc5zA> <xmx:DKpsX9gNBHx59JWaichcp6u8994URBKGMk4J5qKHo1-LCuISDohZfg> <xmx:DapsX9ex_dtTgkTvD9SM0hSE6dhVQb4GQAJXuy49m1M2jwdUz_Uvuw>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.86]) by mail.messagingengine.com (Postfix) with ESMTPA id 3EEF53064686; Thu, 24 Sep 2020 10:15:40 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <29919CCE-2FA8-487C-BFE3-BB38D0766A2B@gmail.com>
Date: Thu, 24 Sep 2020 10:15:39 -0400
Cc: mpls <mpls@ietf.org>, rtg-ads@ietf.org, Review Team <gen-art@ietf.org>, Last Call <last-call@ietf.org>, draft-ietf-mpls-sfl-framework.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <17CD3819-A5C8-4BCA-902B-2284B67C2D06@cooperw.in>
References: <159345181106.6204.7060455676708406175@ietfa.amsl.com> <C575861D-0C01-4245-9B36-A3E5B17F6D4F@gmail.com> <B6EA27BB-72F2-4E91-8B90-4D4DC2262E03@episteme.net> <29919CCE-2FA8-487C-BFE3-BB38D0766A2B@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/CrzHkifM3XNm23n9k4FhYQVVEqc>
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: Thu, 24 Sep 2020 14:15:47 -0000

Pete, thanks for your review. Stewart, thanks for your response. I ran out of time to ballot on this document unfortunately.

Alissa


> On Jul 8, 2020, at 8:48 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> 
> 
> 
>> 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
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art