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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 19 August 2020 14:42 UTC

Return-Path: <ginsberg@cisco.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 4A95F3A0D5D for <rtg-bfd@ietfa.amsl.com>; Wed, 19 Aug 2020 07:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=k3HKDN9J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rfXRaQa9
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 o3tv5c5F0fPH for <rtg-bfd@ietfa.amsl.com>; Wed, 19 Aug 2020 07:42:54 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0FB3A0CE7 for <rtg-bfd@ietf.org>; Wed, 19 Aug 2020 07:42:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11512; q=dns/txt; s=iport; t=1597848166; x=1599057766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LB/m0DpEgOsz51npUylQ+8KC6k2IPiFsVXht2P9ihyw=; b=k3HKDN9JJiJ8e1XCY4GaG8q8yvzxFlRAOYNv2c00LIlQPqUwiCqBIre2 EXS/cqe5Cmx/yZuYGmRlxRcBbAWBVBBcVsBVeEUPW8HEGiqch8KmIayAD FMjFZjf9ug944rx7QOpc9HTKzXzW33LJ+xQIjVM/dtL/YcsJrDAhfeRF0 k=;
IronPort-PHdr: =?us-ascii?q?9a23=3A+KeuRh+4eSKTQP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZhaN7+lmi1nPUI7HrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtfBM35YVvfqWH05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAACnOT1f/5NdJa1fGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgVJRB3BYLywKhC2DRgONXIoKjmKCUwN?= =?us-ascii?q?VCwEBAQwBASMKAgQBAYQIRAIXghoCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIV?= =?us-ascii?q?xAQEBBBILBhEMAQE3AQsEAgEIEQMBAQEBAgIjAwICAh8RFAEICAIEAQ0FCBE?= =?us-ascii?q?CB4MFgksDLgEOpisCgTmIYXaBMoMBAQEFgUdBgz8NC4IOCYEOKoJxg2KBAoE?= =?us-ascii?q?8hA4bgUE/gRFDgk0+gQSBFkICAgEBgV2DFTOCLY9Ygy2iKjdRCoJiiGSMPoU?= =?us-ascii?q?hgwGJXoUyjhaSP4pHgmWEGo1+AgQCBAUCDgEBBYFqI4FXcBWCcAEzCRYxFwI?= =?us-ascii?q?Njh83gzqFFIVCdAIBNAIGAQkBAQMJfI8yAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.76,331,1592870400"; d="scan'208";a="541101523"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Aug 2020 14:42:45 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07JEgj0D007993 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Aug 2020 14:42:45 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Aug 2020 09:42:45 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Aug 2020 09:42:44 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 19 Aug 2020 10:42:44 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOrlxl7qg20wUdo0MgW9xd8lz1JQSwTjaEIsAqOQdY37dbBNv8KHjH1udqzpFAKrWZ+aVcAVByXoCfYQ5gGz/R4AuGg8o0y7HdsI/tDRPGza+IxRAxSZf1rQgszmY1jQqd6MZYhCc2hdphoiZeHYBMpKjZL5qxdzGspdGzX5xWsqRw6HPwlcyT2i0r2qyz8FwEcxqRQnlOLtDaxgmYAn7uBHWaddvIpZ4s3L0AxZTzQns/kefT/3ZPylDsuqgNm1vgR4YlhOijl/ibcR5Fbv/VoKq8WUhbJsNIUX36pSYvr/Mi0PAs1dE/vjSbL4r2wxkE0HuSRebJLPYPeqY+Kieg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LB/m0DpEgOsz51npUylQ+8KC6k2IPiFsVXht2P9ihyw=; b=a+U29RSZuZic9wswcif4P6Fj77WoR2cKesmhznhOtQPgKh4MoQ8ncte7JLp3KKbUiFGbV1HELq2oKM4D8klSlRQMRuWCW37RUhRFR0SlAS/lz1yCZKmXb62vpKs01GWDkFcjlMTOFWMojIbmuPO/XYV+FT7rWpfXtygOuIvitGUkjlSo9PAV6zO0xapwneLUSGP9dS7N8orCizMmEdrIWjgfv12KH93YYuPg6Af+mPfZawjS4UXarULO+FybpHqHx1oHfoc4MN6223hp60e23PwjkPXf7PqeFN+VCT04txSOhRhaHbrtX2a5J62evmZerEl6yRgBedojeioocdbSTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LB/m0DpEgOsz51npUylQ+8KC6k2IPiFsVXht2P9ihyw=; b=rfXRaQa9/SGEdpn6ByAaum0TglXh/LrmpDzfw+7+asU6vljqcxJoXhl0tY+nOFXuUWFMpa/k9qgnNDEuIohHxL8xmRkD3GYpooEYw/4gxAtfrNft3Pe2uv1bzrKEY2OhaUQJtOu+0ePN0lLmj9K/YobBLUrhAg7HvLtvt6IBzgM=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB2742.namprd11.prod.outlook.com (2603:10b6:a02:c1::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25; Wed, 19 Aug 2020 14:42:43 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3283.028; Wed, 19 Aug 2020 14:42:43 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: tom petch <ietfa@btconnect.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.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)
Thread-Topic: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
Thread-Index: AQHWamCvJpW++4Jnl0KOvPQ7lua7YKk82diAgABxu2CAAGfAgIAAHBCAgADkVACAABsIgIAACJiAgAArMwCAADVSAIAAXhZA
Date: Wed, 19 Aug 2020 14:42:43 +0000
Message-ID: <BY5PR11MB4337A64598BAE5D1010C1B49C15D0@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <FF5E0B61-2B8E-4468-847B-0E833DD4536F@cisco.com> <B5F56E39-8A27-4213-AD1E-1A44AA340BB8@gmail.com>, <BY5PR11MB4337F3ED5061E33AB9DABA5BC15D0@BY5PR11MB4337.namprd11.prod.outlook.com> <DB7PR07MB53401B61CE8243FBD5F42A76A25D0@DB7PR07MB5340.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB53401B61CE8243FBD5F42A76A25D0@DB7PR07MB5340.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [99.108.166.100]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7bdd715-82a6-4d8f-cda0-08d8444e2199
x-ms-traffictypediagnostic: BYAPR11MB2742:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB27429592306F033C7C6CB178C15D0@BYAPR11MB2742.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZfvikaYjLqzX4CLaXZATAZNyoOwHTYFUSQC+yAn0oUCMtIiBZhBe1Gt0DdWxbFs3q6CQjflKe/LukDn6CeHt/OsfVRov8P/MRJx5TsW0m00BWUhDU+CbB2kgCzMerjYsLlMbAmK8nFDVgtObzERDkjejXxgdlqZYOestp+GymTJMM2RfteVZ4K2GNZ42kFiYPX7VLCvuokCM3mZ5zDzz3gDQsb3jNSgnjlNsMfl3HQaU1/WZjbzSOoBUmTl4iK2Ls9TrJMGizBE3Fk07GVKwk/7ULyn6Hhzs91ct9a1Uu86jpA9NmvXgM+MmEsnyCOU9DAmKGzxSzjSjA8ul2sjlXZfww2IajFMFbZSEW734eW9gce5SvnZeyh698AkaeNthsVh+QE/rmkgmUUY6vetbcC96x/gOqKZ6+Aun8EnHrlqvvP0cElc3lbyEAIQtIHPkB44AfUD2Ugryj8BK8C3ZxA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(346002)(376002)(366004)(52536014)(53546011)(6506007)(66946007)(966005)(33656002)(478600001)(186003)(76116006)(71200400001)(5660300002)(66446008)(64756008)(66556008)(66476007)(2906002)(26005)(7696005)(316002)(296002)(110136005)(86362001)(83380400001)(6636002)(4326008)(8936002)(9686003)(8676002)(55016002)(21314003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 0Zci30sV4T3K7PxUil+vZ7nHepHt6Bll4IWT1ZYN5aT5OJ2wfH/kg/l432ESi3mH6zH3RSrj6WYE8R/3rxh6uGzK/gg5y83dRMg85gIlrNn/7hom0gw4A9k3nF0qWkVlWbXwnqHoyQ6h49xE4ivLTe34Hg5t+TRC2VQkX70l2QGJOPV0Glnhq2zaIeW5DAG7jqZ2xpMDdE6h4ox8vhGgzJqVTo6GY5SE5Ix7PCZhF/gC0I7GhVxtHfC+wGwvonV1/o7zsrimw/45fSWGPjRJpWz6iKA+HyV0IYPmEIp+Wchzz/u+L6KVQGAVlp2JvD7vqBzB57TkyEcmV6gRsi4WywfKMHhQ9KK0wNtbDcXMDhUtcl9qrpUghJz+DDLDQ4ZdDwUSphTMMRTvCJaB9cBCWJUTTqxKnDPhbjcqPIIJu++g7l8Pg4qP0dhxgcCF2F6qZKJuj4VHeKp3LTGdtHzGXa5A/xHeAK+kXdVGKN9Tx0TxMCjsqlvEpuuwqAJu1ogrn6mo2GA+y8MvXUh92ou+8ImHLCzK0Gd4VTrB8FEJ+g6P6Clkg7iVeuxEFq+Lg8lzZaugMTXDpAwSGjlcEH/Qc1/90Vc8NowErgN+uQyy1sLA914FEjd1UYJ1Al/xdTAwsizpN6Ct8glN90rWZtImYA==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f7bdd715-82a6-4d8f-cda0-08d8444e2199
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 14:42:43.3291 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: m/sJLOLkyAyfrsjFj86Ucup3xJYOcwe8D+1GTtBlMXCOovZGJuwnbPAABD5BkJEPhHl0HocfigjOi9m9cXuoSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2742
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/LhwJ8Ziq3r4UBtV0Bbhf7gKeijc>
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 14:42:56 -0000

Tom -

I defer to chairs/AD in this matter - but here is my understanding of the distinction between Normative and Informative References.
From https://www.rfc-editor.org/policy.html#policy.refs 

" Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC."

To me what this means is that it is the role of the referenced document in the document in which the reference appears which determines its category - not whether the referenced document itself is Informational or Standard.
So an Informational RFC could be necessary to understand a standards track document - in which case it SHOULD be a Normative Reference.
Similarly, a Standards RFC could be merely informational in its role as a reference and therefore be an Informative Reference.

Of course what Jeff and I are suggesting is that there be one document which includes both YANG and the descriptive text of the functionality and that this be Informational.
The more relevant question seems to be whether it is a violation of IETF Policy to have YANG defined in an Informational RFC.

??

   Les


> -----Original Message-----
> From: tom petch <ietfa@btconnect.com>
> Sent: Wednesday, August 19, 2020 1:54 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; Jeff Tantsura
> <jefftant.ietf@gmail.com>om>; Reshad Rahman (rrahman)
> <rrahman@cisco.com>
> Cc: rtg-bfd@ietf.org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Les Ginsberg
> (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>
> Sent: 19 August 2020 06:44
> 
> I would prefer this as well – but if that violates some YANG process in the
> IETF please do make sure the draft clearly states that there are no protocol
> changes.
> 
> <tp>
> The YANG will need a Normative Reference to the other document, AFAICT,
> so making the other document Informative just introduces complications to
> the process,
> 
> Tom Petch
> 
> 
> 
> 
> 
>    Les
> 
> 
> From: Jeff Tantsura <jefftant.ietf@gmail.com>
> Sent: Tuesday, August 18, 2020 8:09 PM
> To: Reshad Rahman (rrahman) <rrahman@cisco.com>
> Cc: Robert Raszuk <robert@raszuk.net>et>; Les Ginsberg (ginsberg)
> <ginsberg@cisco.com>om>; Martin Vigoureux <martin.vigoureux@nokia.com>om>;
> rtg-bfd@ietf.org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> 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<mailto: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<mailto:jefftant.ietf@gmail.com>>
> Date: Tuesday, August 18, 2020 at 9:01 PM
> To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>, "Les
> Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>,
> "Reshad Rahman (rrahman)"
> <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Martin Vigoureux
> <martin.vigoureux@nokia.com<mailto:martin.vigoureux@nokia.com>>
> Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-
> bfd@ietf.org<mailto: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<mailto:rrahman=40cisco.com@dmar
> c.ietf.org>>, 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<mailto:rtg-bfd-
> bounces@ietf.org>> on behalf of Robert Raszuk
> <robert@raszuk.net<mailto:robert@raszuk.net>>
> Date: Tuesday, August 18, 2020 at 5:44 AM
> To: "Les Ginsberg (ginsberg)"
> <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmar
> c.ietf.org>>
> Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-
> bfd@ietf.org<mailto: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<mailto: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<mailto:rtg-bfd-
> bounces@ietf.org>> On Behalf Of Jeffrey Haas
> > Sent: Monday, August 17, 2020 1:45 PM
> > To: rtg-bfd@ietf..org<mailto: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