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

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 19 August 2020 01:01 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 EE1FE3A107D for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Aug 2020 18:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 h4u7wB7EOoGK for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Aug 2020 18:01:26 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 13B8D3A107E for <rtg-bfd@ietf.org>; Tue, 18 Aug 2020 18:01:26 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id f5so10005574plr.9 for <rtg-bfd@ietf.org>; Tue, 18 Aug 2020 18:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=8GvW6dyg8MDKnumdfYhjSE72ErfJSqKOFu6LfO54VWk=; b=sCb4o90hu3dAjK3LJ9azemOe/EZRaPAiteiR3OxizRHRt07e0lCPqrSLZrcnQxxNA6 /+fYxjJ35X96N8t95SZfiFziFlhp8tRk7OquoUuQUNVTMnNqsbaYFUWXPW5MbbmRMRl+ 9TkU44sOhWMPeRDigmaoAcpFs5i8qCbvrWXXA2cWDbiruyDDRwlcnfihoSzoqwh/aOeB UOgrmSe3dJafxNY1LAroHhU28oQHiXiYwmQjlTOulBpBEh22ym3RCOjJ2g/IC/PdNs1H kyaTq6Dn2OA2v0zRaq4QmM6otUhYWz7vzOE16CKwf6SiD01jI24Omwskc1nZ3gOiz5jY obgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=8GvW6dyg8MDKnumdfYhjSE72ErfJSqKOFu6LfO54VWk=; b=HEtP+6y+tMqRibGp+qKErb5feOassuD57O/d2TBD3Q5XwN5QayM0ipHDp2QYBMdWxy ZrYKUGMBzm8T2aevxO6RZCJyM4ikjfNVFxkYIHL2dDgsMTrJzARwaNvbPOWkCPjJmcGV M1zD3Q2eU18MvXmwVCPROIVipJ/Q7WLKaBqWefxPTcS7pcN+5pMIbA/FjQMRXpOcSDLs nbGbvb3K4SKPOOtz3kZ+9yvJsYuaYEU9GsrKyg2AD+8hdrJqn2KmPLswEcnXrmzFnts5 vWqEjwN/7md+j5+aDRoNB52ujWm8CyG13KT7DfKeUubJeasJgujGdQoJfYLiUtBfcxJm nQ5g==
X-Gm-Message-State: AOAM530RNgsFhVVxo7wxB4kVgNukl64qz4KE6Xet4Fa6tw8qlXjnm0ei J5y0SDgHO1PlyvEmshvyETA=
X-Google-Smtp-Source: ABdhPJyggg0aBsgwTVZ8a424iXsobBIGqx4H6Ay0/lFhGFu9Sb+Yt6MUW5MutLSqJPtpZDlNsBGKvg==
X-Received: by 2002:a17:90b:378d:: with SMTP id mz13mr2061959pjb.98.1597798885495; Tue, 18 Aug 2020 18:01:25 -0700 (PDT)
Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id g129sm25529510pfb.33.2020.08.18.18.01.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 18:01:24 -0700 (PDT)
Date: Tue, 18 Aug 2020 18:01:14 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Robert Raszuk <robert@raszuk.net>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Reshad Rahman (rrahman)" <rrahman=40cisco.com@dmarc.ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>
Cc: "=?utf-8?Q?rtg-bfd=40ietf.org?=" <rtg-bfd@ietf.org>
Message-ID: <12c142a4-4bc4-4853-8a9a-e9c3056c4deb@Spark>
In-Reply-To: <47FF05FC-A124-482F-9354-F9CD8644D620@cisco.com>
References: <20200804132122.GC31729@pfrc.org> <20200817204510.GC1696@pfrc.org> <BY5PR11MB4337DB9D4836800F9F91906CC15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMH8UYF-b+Y2jUBSS2oCL2L_FPnLFaZ4fAMin7g0TfeUYg@mail.gmail.com> <47FF05FC-A124-482F-9354-F9CD8644D620@cisco.com>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
X-Readdle-Message-ID: 12c142a4-4bc4-4853-8a9a-e9c3056c4deb@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5f3c79e3_180115be_65d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/l9ENdOEYyJPrKsJckSmeWdLA7dU>
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 01:01:29 -0000

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:
> > quote_type
> > 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