[spring] Re: Shepherd review for draft-ietf-spring-bfd-10

Alvaro Retana <aretana.ietf@gmail.com> Mon, 02 December 2024 22:03 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C921C180B6E; Mon, 2 Dec 2024 14:03:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWCWyPfW3lp7; Mon, 2 Dec 2024 14:03:12 -0800 (PST)
Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com [IPv6:2001:4860:4864:20::29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851A2C165518; Mon, 2 Dec 2024 14:03:12 -0800 (PST)
Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-29e65257182so833522fac.2; Mon, 02 Dec 2024 14:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733176992; x=1733781792; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=Z7AYyFtw7Ha2Nlp0JU8965XBulmw1ktPAQYRlu+K/HY=; b=OfRpXj7hBhZQSSrTq6m6yw7vQIMAoj4HPPFKS2d1tDAKue+z6ijxucQfK+laN518Pg jReYISgyEA1wE2uodn6A9xdIgYjflAYKgLGVzzqSwp4XhCTV3BquCTbb7Y5PNqNsGdIj rFMhDpKeyWhs+C+vS6O2ssPebvYcnpysVaYDFpOoJvwn+vV0s4TYJCjNAIMqYT0EariF bel1Ptc5RfF1r2KOA6bfJXrsHcY0P1WsVuBGv6mAv9+95Yo2eNPji3EowW6XDI5jy5uU lUliYF3nVUDgCK3fiWXPu59vpXbGSS9GHitxNpLd/n/FdyV4PKmOr3qfktAY7DmQKquU e3/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733176992; x=1733781792; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Z7AYyFtw7Ha2Nlp0JU8965XBulmw1ktPAQYRlu+K/HY=; b=mCKoZ7q3GkZ2CJMTtYGNzBE9O26lZDrV9Yc1gWHA0aTm5oFtfuy/JZi3YUhC5ecOHf KLwBgWJVSkGwwpDo/J+3Vooa6U3OUAlNP2XWh/Mmdjg1FVQ8dZYEOFHTzIZmebmFOJ9/ iG6QgvijnesObzYS0uYZ0GbvGO9E4ET9sZcuhrqAlPybYIIC1ANMDdCIcVsO87oQ1f42 kxJlZIT8oBxlclKNOvvk/uSHcFrQi3rL6az0PN5TLmoRvodIRRFxbq/tQyy7B+tP9Z5b /5a2auQLrduCqKQnv08TH2i0bWA7HSOpzbbkh5Y56VBw+o4qdU+Al5SetG0q3Qg6oXam qy3w==
X-Forwarded-Encrypted: i=1; AJvYcCU7q5kLQoGN8MNEmXOwfnBPpr2AbrJXmLkPJclCk0oDtTnDvqG6XnNSMq9pjpNy0Rg+EQalliyFsnJhoQBFDBBBi8ggqnE=@ietf.org, AJvYcCUlzvDSlfhHq593PVPr7z7dEfyqTBUUFTfaVpjG7lkWtyrjo/xPEPRqtMvf6cw95DGTvgJHAwfI@ietf.org
X-Gm-Message-State: AOJu0YzIcN5LbO9FC9D8rxk/zyjiVnY8dgDp5/dZE9XzLW+POHcniH0Q f3V6pHM+vdjIVeBtuTiuytv1b7Tu4ITgAIqLli90ylgWtCk6tEEIKFvIHTbut7o2YtyG0zbOnJR +i/iYRw/ZRzXEHJHZDLy56L1hpG2fAQ==
X-Gm-Gg: ASbGncuuDZ7IBNtZVoeq6jWQd/G61cQTTeUzrz27W2i6KEnQku1xa2JGXMQ3hlJ6JJ9 Awmmzeg0FOBQuPbemA/S56TAyO62sKeSrxGs5YfLsTc7WCRbfP21V0yrq9ZI7m9QVXQ==
X-Google-Smtp-Source: AGHT+IFTwT8CLAKq8mxAF7iWlJTFnDu51LbtqcgCCMQCINlTXS9UOhiFpYE0oYhTeSn9NWnwi1r4gZYdde/HGob+tUE=
X-Received: by 2002:a05:6870:e38f:b0:29e:7c10:1afe with SMTP id 586e51a60fabf-29e8883249dmr17972fac.30.1733176990257; Mon, 02 Dec 2024 14:03:10 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 2 Dec 2024 16:03:09 -0600
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAH6gdPzOh3ZwbJj_HMVzCxS2QucR_mQB6tc18ZPXgnWg2LuNcg@mail.gmail.com>
References: <CAH6gdPyNGPnpsHp=YBfmHQfaO24anrLgT__55SDbULz=-7_=sQ@mail.gmail.com> <CA+RyBmX33Shp7V+zpyC7Ht6PB=mBDXvjr5KdsAG9tsMzEZk_Fg@mail.gmail.com> <CAH6gdPzOh3ZwbJj_HMVzCxS2QucR_mQB6tc18ZPXgnWg2LuNcg@mail.gmail.com>
MIME-Version: 1.0
Date: Mon, 02 Dec 2024 16:03:09 -0600
Message-ID: <CAMMESswMYgrsFfL10wed844pwiwSXMF=hXUkOZY7FXE5H+q+Mg@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>, draft-ietf-spring-bfd@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 2KA54DEXUAZYC3WNAAEA7DLQCNYRZ2AQ
X-Message-ID-Hash: 2KA54DEXUAZYC3WNAAEA7DLQCNYRZ2AQ
X-MailFrom: aretana.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: spring Chairs <spring-chairs@ietf.org>, SPRING WG <spring@ietf.org>, Ketan Talaulikar <ketant.ietf@gmail.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Re: Shepherd review for draft-ietf-spring-bfd-10
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Sb20C-gjvYlCAJ_DmxT-NU3p1Gs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

On October 21, 2024 at 12:40:55 PM, Ketan Talaulikar
wrote:Greg/authors:...> Since this document has not yet gone through a
WGLC, I will leave some> of the open points below for the WG Chairs to
determine which of those> are perhaps more appropriate to consider as
part of the WGLC so as to> seek WG inputs.>> Please check inline below
for responses with KT.>> One new concern (not previously reported):
The document was turned> into experimental status because one part in
there was using an> experimental BFD extension. However, the IANA
section is asking for> creation of a new registry that has allocations
from standards action.> Even the allocation from Return Codes registry
is from the standards> action block - perhaps it should be from the
other two blocks?I have several points triggered by this
comment:(1)The new registry (Table 2) is created in §8.1, and the
allocations are made in Table 3. Although Table 3 contains three
values, only one (TBD2) is an allocation; the other two are
reservations (see §2.2/rfc8126).Table 2 should be updated to reflect
the 2 "Reserved" values (which are not part of any other range).Table
3 should contain only the TBD2 value. Because this document creates
the registry, IANA doesn't need to be asked to allocate a value; the
document can allocate it.(2)Table 2 contains several Notes on how the
values are to be assigned. Please keep in mind that IANA will be
making the allocations and that it may not be evident to them (as they
may not be subject matter experts) if "optional TLVs...require an
error message if not recognized", for example.Is there a technical
reason to divide the “Standards Action" ranges like they are?The other
two ranges (both "Specification Required") include a note that reads
"Experimental RFC needed". However, that is not congruent with the
definition of "Specification Required" [rfc8126]. This policy includes
the allocation review by a designated expert, so any instructions
should be included as instructions to the DEs and not as notes in the
registry.Why is an "Experimental RFC needed"? Note that the language
is not related to rfc2119 -- is the expectation a requirement or a
recommendation? Any instructions to the DEs should be clear.Note that
the current ranges/Notes would leave Informational RFCs without the
possibility of having a value assigned. Is that the intent? Why?"RFC
Required" may be a more appropriate policy (instead of "Specification
Required").Given the registration policies and the notes, consider
adding an Expert Review to all the allocations.(3)As Ketan points out,
the TBD3 value (§8.2) cannot come from the "Standards Action" range.
Instead, it should come from the "RFC Required" range....> > > 513 -
The date when information about this particular implementation was> >
> 514 last updated: 12/16/2019> >> > < minor > The implementation
reference is to a very old document version> > that has gone through
several changes. Is the "complete" coverage accurate?> > Please
consider polling the WG to get an updated implementation status for> >
the various BFD flavors/sections in this document.>> > GIM>> The
Implementation Status section conveys information about the> >
deployment the Non-FEC TLV:> > - Implementation experience: Appreciate
Early Allocation of values> > for Non-FEC TLV and SR Policy's Segment
List sub-TLV (using Private> > Use code points).> > Other flavors of
BFD are outside the scope of this section.>> KT> The implementation
section should cover the entire document and> not specific sections. I
would assume that the WG chairs will poll the> WG for implementation
status of individual features and this gets> updated in the document
per SPRING WG policy (even if it says - "no> known
implementation").Ketan is right. The policy is that the Implementation
Description should cover the whole draft, including specifics about
the MUST/SHOULD clauses. It is up to the authors to collect this
information.https://wiki.ietf.org/en/group/spring/WG_Policies
Thanks!Alvaro.