Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

Joel Halpern <jmh@joelhalpern.com> Sun, 17 May 2020 16:07 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14E3A086E; Sun, 17 May 2020 09:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 u4y_G8ALIaWJ; Sun, 17 May 2020 09:07:47 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 162683A0864; Sun, 17 May 2020 09:07:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49Q6Vp5b4lz1p4wn; Sun, 17 May 2020 09:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1589731666; bh=l1QUWc1lagyDpUNAxXOCIA2+k2b4CRFJEz3TSwJmx/I=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=YDKeh3QE+U8jGeJegrHqKMZ7bGrWJpyetYI6/5S/BcUzUkKY48xdeQR3Tf+b3ATJl ZFCa04DdU9n2T+Dv66b6lur8Ps+2PIKbGgOC7qsWAzE66xgMxrtNZM3a2Oy7RUmLhh P9X6sgARtbWWZ7uq2GuR0qnH4R21P0p1KzHegC4I=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49Q6Vn3sGRz1p2py; Sun, 17 May 2020 09:07:45 -0700 (PDT)
From: Joel Halpern <jmh@joelhalpern.com>
To: "Nagendra Kumar Nainar (naikumar)" <naikumar=40cisco.com@dmarc.ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-sfc-oam-framework@ietf.org" <draft-ietf-sfc-oam-framework@ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
References: <158885879619.21045.4121183716505139454@ietfa.amsl.com> <E44E9C8C-3ABA-4723-91F8-4F51E2EF7672@cisco.com> <9f34e226-9edf-0801-4d22-56d85e970d2a@joelhalpern.com>
Message-ID: <fbdc127b-8666-e205-c2c7-1e78f3278a72@joelhalpern.com>
Date: Sun, 17 May 2020 12:07:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <9f34e226-9edf-0801-4d22-56d85e970d2a@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/YaTbFIUmRjQcHS7PHh6slWwCIJc>
Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 May 2020 16:07:49 -0000

Alvaro, Murray no longer has a Discuss.  So I am not sure what your 
stance is.

And the particular change the authors have proposed seems to me to go 
too far, apparently promising that SFC OAM will validity SF 
functionality.  That is out of scope for the document.

Can you please clarify whether you feel there is still a discuss level 
issue here?  And if you can live without this change?

Thank you,
Joel

On 5/16/2020 12:44 PM, Joel M. Halpern wrote:
> Can we please be careful not to get too far into monitoring the 
> functioning of the SF.  That is explicitly out of scope for the 
> document.  This modification seems to move dangerously in that direction.
> 
> Yours,
> Joel
> 
> On 5/16/2020 10:36 AM, Nagendra Kumar Nainar (naikumar) wrote:
>> Hi Alvaro,
>>
>> Thank you for the comments. Please see inline for the response.
>>
>>
>>      Alvaro Retana has entered the following ballot position for
>>      draft-ietf-sfc-oam-framework-13: 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-sfc-oam-framework/
>>      
>> ----------------------------------------------------------------------
>>      COMMENT:
>>      
>> ----------------------------------------------------------------------
>>      I support Murray's DISCUSS.
>> <Nagendra> We will address the DISCUSS comments from Murray.
>>
>>      I appreciate the fact that "More specifics on the mechanism to 
>> characterize
>>      SF-specific OAM to validate the service offering are outside the 
>> scope of this
>>      document." (§3.1.1)
>>      The issue I want to point out, which I believe is a significant 
>> omission in
>>      this document, is the lack of mention in §4 and §5 of the 
>> validation of the
>>      service offering as an SFC OAM function or in the gap analysis.  
>> IOW, the
>>      availability of the SF from the point of view of its ability to 
>> provide the
>>      service is pointed out as important in §3.1.1, but there is no 
>> further
>>      consideration later in the document.
>>      [I believe that this issue borders on a DISCUSS -- and while I 
>> would really
>>      like to see further consideration in the text, I decided to trust 
>> that the
>>      authors and the responsible AD will take care of it.]
>>      <Nagendra> I think, this can be addressed by adding the below 
>> bullet point in Section 4.1
>>
>> "Ability to validate the service functionality of an SF."
>>
>> Please let me know if this address your concern. Please feel free to 
>> suggest any text improvement.
>>
>> Thanks,
>> Nagendra
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc