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

Greg Mirsky <gregimirsky@gmail.com> Mon, 02 December 2024 22:38 UTC

Return-Path: <gregimirsky@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 2097FC14F5ED; Mon, 2 Dec 2024 14:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.103
X-Spam-Level:
X-Spam-Status: No, score=-1.103 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, FREEMAIL_REPLY=1, HTML_MESSAGE=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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 6Q2KWbKefhWM; Mon, 2 Dec 2024 14:38:40 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 C5156C14F5EC; Mon, 2 Dec 2024 14:38:39 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-385d7f19f20so2129643f8f.1; Mon, 02 Dec 2024 14:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733179118; x=1733783918; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3tUHCsvm0A2NX0qQG/Mg9O111CgpFbjDdo40pj1tH/Y=; b=kfWZ/dRXJXcYOS+6zjFVY+5LUTyF+fHlM1YFGIPoor0cVcYFLAArMrYY3QKNYBzZOH fDpj/Ebi6Z96x8tWJJABcztqcnOEjwKcMxpBIHtA9QOmeFR0yfg8JpTZnIfKOBEsArWa FB8cA+M8PNVilaH9HPweNNSEl+uyNnMHnEXFiwzzjbdshX0dPRNmjCUzW4VWr9/YjXE5 nyBJwur+bOSV2MA1PauUgk26VZfT+AHGpw4JecnGDAG/RCYprvelbKx0JFytlN/Az2/J 0PyNO907HfBECAy1KTLBQjHq4c3HPPEE3qpL0FljL2tzNkaLRiBRyNpcqWPpQBIJlREs 0CwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733179118; x=1733783918; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3tUHCsvm0A2NX0qQG/Mg9O111CgpFbjDdo40pj1tH/Y=; b=YinC5WmHQrFZS4M4ucakoICOJ8M3guHL9ItHANDZet4m9A4FAjY7rLLX1TG+24ZOu1 oZ4g2ZAKQEMqavZG9pHlRqO97u/HqXeuHz+UfTD6fXhOUbiF5aqT4UNPuMs9ohEeQX/0 kLg3wGSfezZqk5e7YBeyIEiIhpXbRmtJoMvch33H6toSHYwsfhEvC9jF74g1k0LPSgtB yskrlZzZcUJo3zW0gUVTbgFCJf5aLimNcRyiqPL/XKuVNW6EUGXnOBXAW8cJ5q0hN4Yb Ip31i8v+zxBjQQYd3/ZSauLYxI5m+/iR+RLso9AQi2rS6htstgCRLMSa5PA2mjJ9CfuH ZzPA==
X-Forwarded-Encrypted: i=1; AJvYcCXJ/o9i8GujwiM6VtuTgHjlrDCxGYLpwe/uXRo1zMdLhbW23caR3tGf/Vh+QYioPIfA0D36qhtw@ietf.org, AJvYcCXapf+uncpC87ucxVFJCvyDZ92GkY6C5ai8TVinylfsnf3KC/yyr35/c2Qq+zoDiJmJe+LL9gSbSWFc3xCm@ietf.org
X-Gm-Message-State: AOJu0YzKkEtAZYP8Pq8exJZB0p0aVp7blOJk19DOo7ijeo1agzpx68qL mmOqm+Yl4zVMYPazpJKmTlGFokvRk6ALImSwYRSdfEZOgmdHKZxKxdw72QV9LD031IscaJ4PLba 2/yUsRLv+lJvuMvSsDDGyus+yctk=
X-Gm-Gg: ASbGncuHAUS4ugApvXc8vdlu7GL2glFvEljr6jarhkM8v5SkhJOeU1DUvyeXFTfBJCL r6gW/MvfaUFfSEySdw4gUEb2q8W3RvLz5
X-Google-Smtp-Source: AGHT+IG0D9nI9u6jJO6pfQGGt1/5eDhRP8kX+aON5tDKC5p2+vHwgaMzmcEoI2LIO06jO6ALT7IRHKBtHBGYHYHhd1E=
X-Received: by 2002:a5d:6da8:0:b0:385:e17a:ce61 with SMTP id ffacd0b85a97d-385fd424c75mr142868f8f.53.1733179117973; Mon, 02 Dec 2024 14:38:37 -0800 (PST)
MIME-Version: 1.0
References: <CAH6gdPyNGPnpsHp=YBfmHQfaO24anrLgT__55SDbULz=-7_=sQ@mail.gmail.com> <CA+RyBmX33Shp7V+zpyC7Ht6PB=mBDXvjr5KdsAG9tsMzEZk_Fg@mail.gmail.com> <CAH6gdPzOh3ZwbJj_HMVzCxS2QucR_mQB6tc18ZPXgnWg2LuNcg@mail.gmail.com> <CAMMESswMYgrsFfL10wed844pwiwSXMF=hXUkOZY7FXE5H+q+Mg@mail.gmail.com> <CAMMESszCTa08cM-xWj5U566adxas+0QuFdxUjYTvmfW2+zZdrw@mail.gmail.com>
In-Reply-To: <CAMMESszCTa08cM-xWj5U566adxas+0QuFdxUjYTvmfW2+zZdrw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 02 Dec 2024 14:38:27 -0800
Message-ID: <CA+RyBmWqkk7kw7y3UnMfJsH5p7jbjGWAunX0APUjHOb50EoSsw@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a8b9770628513507"
Message-ID-Hash: BJZDLAI67ITDHRYTJI4LQUETVXXRQPIG
X-Message-ID-Hash: BJZDLAI67ITDHRYTJI4LQUETVXXRQPIG
X-MailFrom: gregimirsky@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: draft-ietf-spring-bfd@ietf.org, Ketan Talaulikar <ketant.ietf@gmail.com>, spring Chairs <spring-chairs@ietf.org>, SPRING WG <spring@ietf.org>
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/dcYZRSdarS2CBjcJ-DtuvVaC58M>
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>

Hi Alvaro,
thank you for your comments and suggestions. I will work on updating the
draft and share the working version.

Regards,
Greg

On Mon, Dec 2, 2024 at 2:12 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:

> [I recently updated my email client and the formatting seems to be
> broken…. <sigh>]
>
>
> 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.  Even though there are 3 values in Table 3, 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 itself.
>
>
> (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 obvious 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 for the "Standards Action" ranges to be
> divided 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
> review of the allocation 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.  It should come from the "RFC Required" range instead.
>
>
>
> ...
> > > > 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 for the Implementation Description to 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.
>
> On December 2, 2024 at 5:03:09 PM, Alvaro Retana (aretana.ietf@gmail.com)
> wrote:
>
> 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.
>
>