Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 19 August 2020 03:08 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01743A10E3 for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Aug 2020 20:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 48-YR54x4JI0 for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Aug 2020 20:08:52 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 406313A10E4 for <rtg-bfd@ietf.org>; Tue, 18 Aug 2020 20:08:48 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id m34so10679286pgl.11 for <rtg-bfd@ietf.org>; Tue, 18 Aug 2020 20:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=o8oZyZ94H0SveF+Shjw9YiHigGGWaNwfT9Rapk6H87o=; b=Bg96Sv8sANDnIQxGLHMN/5jO4DJyMQ48wUu5teDyUh5ajYKRUwN/1vtFTSDtdLfEmp QTo+Hr+TGLtxOWvT7A0fNhSz66ifS1UuVsvUSNkfQ9MHAKoC97iAlKI2f5BoBFMhScxu RoD4fqRD5q3zCOVWl/YzeVm9e6x2p/tb/RiTbhL0mKfL2pBi/xvNyJCPEvhs5ihUoVJz OvS54hU1KgWv2DJbUHnKHshnQyFvGaB+ra+f8MVGDBnwkc8Bd66AWEuiNLQyv5mTdS7Q 8qxbEqAP6px9bai75jDeMXYoW4ToyYpEEfajvSqHKP78q5TqBEFAsqME+IAUEFI5rPtI w9JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=o8oZyZ94H0SveF+Shjw9YiHigGGWaNwfT9Rapk6H87o=; b=qnvsWbcwo4POQo2PUsDHtfqvlIMnC30aWdQAfnNSWw7KtVXIrwaqKm8lAba/QNqeVL aN0yJUcUFfR4K+pnxXKrM4CB5zmOYPWNqWBDC7BNtl2yUZP72CQewDmZCVK6dYXT/ayf VCMNdh6zqA1hMWhgbCfCjgrpUi0ozvF+K7HUg3USGTYJVKiCCM+PXqH4BHziTQ25PzbJ CpG57HDWyi2H/joy/Rokp0sTf5nzWNknp/Lt+gnvyZ/MPoM4dDLKN08ACkkE+dmc/j/g A2GlcDnrAqQLWPcxGakypOa8+JWKqgOVZJ9CwM3xmzHsqr81ODL61kYBJ2VfjUC3Ak4P Z6aA==
X-Gm-Message-State: AOAM533kxK4zDCxDrssAVTixvwy9ZZk7bl07YqgMufV51thaChTdeBxY h3Qnb060uzaABod7R0W1fYQ=
X-Google-Smtp-Source: ABdhPJwjVyIrTJzUrQxElR0B2SeJVZBGW8jfbRN2cB2JHpIO0dikG6kpkMRMq14F5FlSf8bM+u7AGw==
X-Received: by 2002:a63:c910:: with SMTP id o16mr15638912pgg.334.1597806527699; Tue, 18 Aug 2020 20:08:47 -0700 (PDT)
Received: from [192.168.1.12] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id k23sm23176323pgb.92.2020.08.18.20.08.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2020 20:08:46 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-C72A0C7B-E4C1-417B-BB9C-9054A6B01D07
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
Date: Tue, 18 Aug 2020 20:08:45 -0700
Message-Id: <B5F56E39-8A27-4213-AD1E-1A44AA340BB8@gmail.com>
References: <FF5E0B61-2B8E-4468-847B-0E833DD4536F@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
In-Reply-To: <FF5E0B61-2B8E-4468-847B-0E833DD4536F@cisco.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
X-Mailer: iPhone Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/tytglq5aQAZgZySCjp_p2YJCcAA>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2020 03:08:55 -0000

An informational document that also has a  management/YANG part included would IMHO be the right outcome.

Regards,
Jeff

> On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
> 
> 
> Hi Jeff and Les,
>  
> In general I  prefer to have the 2 together (here’s the protocol details and here’s how it’s managed), IMHO there’s benefit in having the 2 together since the YANG discussions are happening while we’re in the thick of the protocol discussions. I am actually not keen to end up with 2 docs, RFC XXX and RFC YYYY: YANG for XXXX with 2 different lifecycles, by the time the YANG is done people aren’t interested anymore because the protocol spec is done.  I brought this up some time ago with RTG AD and OPS AD, but I don’t think there was any conclusion.
>  
> In this specific case, I agree that there’s no protocol changes. So with 2 documents, are you proposing that the BFD spec should be informational and the YANG standards track? Or both informational? If it’s the latter, I’d rather they be in the same doc.
>  
> Regards,
> Reshad ( no hat).
> From: Jeff Tantsura <jefftant.ietf@gmail.com>
> Date: Tuesday, August 18, 2020 at 9:01 PM
> To: Robert Raszuk <robert@raszuk.net>et>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>om>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>om>, Martin Vigoureux <martin.vigoureux@nokia.com>
> Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
>  
> IMHO - It isn’t right that presence of YANG defines document’  designation track. The common practice is that if the draft in question doesn’t require any protocol changes it should aim for Informational track (or BCP). 
> https://ietf.org/standards/process/informational-vs-experimental/
> 
> I’d rather have 2 separate documents. In general, given that YANG documents life cycle is quite different from that of protocol ones, it is perhaps a good practice to keep them separate. 
> I have included Martin (Routing AD for BFD)
>  
> Cheers,
> Jeff
> On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman) <rrahman=40cisco.com@dmarc.ietf.org>rg>, wrote:
> 
> Indeed, draft-chen-bfd-unsolicited was informational and with the addition of the YANG module draft-ietf-bfd-unsolicted was changed to standards track.
>  
> Regards,
> Reshad (no hat).
>  
> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
> Date: Tuesday, August 18, 2020 at 5:44 AM
> To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
> Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
>  
> Hi Les,
>  
> While shifting to Informational would be perhaps ok protocol wise - isn't it common practice in IETF that any draft (or at least most of them) which define a YANG model is a Standards Track document ? 
>  
> I hope you are not suggesting to split this one into two :). 
>  
> Thx,
> R.
>  
> On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote:
> Sorry to be tardy in responding...
> 
> As I stated almost 2 years ago when this draft was introduced:
> 
> a)The problem the draft is addressing is real and the solution useful
> 
> b)There are implementations which have already addressed this problem with no interoperability issues
> 
> c)I do not see that any changes have been made to the BFD protocol (e.g.. RFC 5881)
> 
> Therefore, I think this should go forward - but as Informational.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Rtg-bfd <rtg-bfd-bounces@ietf.org> On Behalf Of Jeffrey Haas
> > Sent: Monday, August 17, 2020 1:45 PM
> > To: rtg-bfd@ietf..org
> > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> > August, 2020)
> >
> > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > > Working Group,
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
> > >
> > > With apologies to the authors of BFD unsolicited, this document is past due
> > > for Working Group Last Call.  The primary holdup on the document had
> > been
> > > last minute interaction with the RFC Editor with regard to its impact on the
> > > BFD Yang model.  That work had completed some time ago..  (The Yang
> > model,
> > > however, is still lingering in MISREF state.)
> > >
> > > This begins a last call period ending on 16 August.
> >
> > The last call period has ended with a few comments from Greg and Raj that
> > should be addressed before we continue.
> >
> > It'd also be helpful to hear from additional reviewers before we advance
> > this document.
> >
> > -- Jeff