Re: [spring] Proposed policy on reporting implementation and interoperability

Robert Raszuk <robert@raszuk.net> Fri, 19 August 2022 15:48 UTC

Return-Path: <robert@raszuk.net>
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 857AFC15948F for <spring@ietfa.amsl.com>; Fri, 19 Aug 2022 08:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 z4r2Bdsr9SJO for <spring@ietfa.amsl.com>; Fri, 19 Aug 2022 08:48:55 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1EDC157903 for <spring@ietf.org>; Fri, 19 Aug 2022 08:48:55 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id t5so6147119edc.11 for <spring@ietf.org>; Fri, 19 Aug 2022 08:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=npbVTPXH1d3k9Wt6r+Zr+jUNiUWskJKXdOL20jrhYLk=; b=fvlKBUsFvgd4iLOq4T3dTnKylAo+8w+xE/F7Me1A2WILijCznwLsDXSa2yrN4vl4bS OFeCnJH3k11X2oo6NSHDzLmK8tn5Y8ZX3+4CnQ1eg8ewyW10Ky/qfN6SnXCIWfpuPnZm isiYjHlDjtUNSzXARCA2fiRNtqE8eUtFXzjz8jaidqsnN+aGXsk3q7ad2So+9HAFmPAS PsU3ssMQTrCiXpyADI5/apYdmZcQv79voOGzw8fgjsj9Q5HLCZUwsB7K5YGN8bvSxViD gVFHHfUq1xyM+rWRSR+NTeE9eS8GrFTpBZngzSXn4l6WyeZEcp0qSW0IrJoCjYb2M41H AUQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=npbVTPXH1d3k9Wt6r+Zr+jUNiUWskJKXdOL20jrhYLk=; b=XWIsDI/KxnUmGz3Kf/4tJiqmlEYvhSu7MuERWiVK1lgiHKQwYthmC+KNlCpIAkb9FD IpebSbSGL79AoqFTfrmRM2qtt5yVKZoDmJ597bmPAJNxq6R4gnrpoAOLNU67wiRb7cOh /wqlQE8ji1NG4mQa8dx9VQ6R8DmbldumqtWQlHKy4debaGyGI9dbEIFC3mMvyG8NjGoC Ic3TnZeJr4yIZMyzTXbmvHfMRhOfUlBWl6ZQ6d6CHZ/+kAnaVi+Dvfs6QJ+YTKVJwyM/ vH3mQ3Bd2Wyj/5pPTXb/vL4/Y92qnJFtDvIGmMhsnTk+ObKXkTs1PGs89d5Tq1MfuwkX RX8A==
X-Gm-Message-State: ACgBeo1VyHjFF7MorzihbOHI+w/sP/zlHd3o4NqMjzlYblW4WxYboo4/ qWVUD1f0EjwCNJXioVeCNmqvT8WFjBJniwG+r08x2g==
X-Google-Smtp-Source: AA6agR7NOt0Y7iRmq0QfDlbYOul+t2zyV7Y/eH51z0Da7iV6mTlm0vJAu8VD7DuvUiXeoT3wrRSTPAtXWFc3AXfTaV4=
X-Received: by 2002:a05:6402:5193:b0:43e:1d52:fd70 with SMTP id q19-20020a056402519300b0043e1d52fd70mr6588520edd.150.1660924133959; Fri, 19 Aug 2022 08:48:53 -0700 (PDT)
MIME-Version: 1.0
References: <9c7ac280-c1f7-956c-cdbb-2b0745aaf2fa@joelhalpern.com> <CAH6gdPzYmxoVbOaAp3waUWFOCJPVoW1R3iN75SoqimyrkY769w@mail.gmail.com> <fe51b706-dac2-1796-4972-9a561c3bd17a@joelhalpern.com> <CAOj+MMEmXRcESZV5AjJOrgFCEF821CPB0ag7rx3OYz4HSp2gbg@mail.gmail.com> <b17cd0b6-0ac4-e41f-854f-0914c7ac53f7@joelhalpern.com> <CAOj+MMFcaOzUe0CEOjsBr4=S8a6Ku=0qHXvaGw0w+hYZY84A2A@mail.gmail.com> <CAH6gdPwkAsWKFdD47=hrbnuHpAP8Ay_szWEc1AuLsSggnsg5cA@mail.gmail.com>
In-Reply-To: <CAH6gdPwkAsWKFdD47=hrbnuHpAP8Ay_szWEc1AuLsSggnsg5cA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 19 Aug 2022 17:48:43 +0200
Message-ID: <CAOj+MMHWbamLg_t6fcC-xYY3CUQmEK=ZW_aDBuc1nYh_kATpRw@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000011c9505e69a09db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/sznMuiStUQj6nCUoUi0D-s_RSHU>
Subject: Re: [spring] Proposed policy on reporting implementation and interoperability
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 15:48:59 -0000

Thx Ketan.

Yes indeed but this is an architecture document ... In such type of
documents it is hard to imagine an implementation report. You implement
protocol specification not an architecture.

I was more curious how many protocol extension RFCs say from IDR or LSR WGs
have such "issue".

Thx,
R.

On Fri, Aug 19, 2022 at 5:43 PM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Hi Robert,
>
> Let us consider RFC8402 which has a whole bunch of MUST clauses. An
> implementation may choose not to support IGP Anycast Segment. The spec does
> not say that any of the Segments are mandatory for SR. However, there are
> some MUST clauses to follow should implementation support it.
>
> I hope that clarifies.
>
> Thanks,
> Ketan
>
>
> On Fri, Aug 19, 2022 at 9:01 PM Robert Raszuk <robert@raszuk.net> wrote:
>
>> Hi Joel,
>>
>> Would you mind providing a few such examples of reality in the published
>> standard track RFCs coming via Routing Area ?
>>
>> Many thx,
>> Robert
>>
>>
>>
>> On Fri, Aug 19, 2022 at 5:23 PM Joel Halpern <jmh@joelhalpern.com> wrote:
>>
>>> While what you propose may be cleaner, what Ketan asked about is a
>>> common practice.  So it seems useful to recognize that reality.
>>>
>>> Yours,
>>>
>>> Joel
>>> On 8/19/2022 10:58 AM, Robert Raszuk wrote:
>>>
>>> Joel,
>>>
>>>> I would be interested in hearing from the WG on this.  My expectations
>>>> is that if someone says they implement optional feature X, and X has MUSTs
>>>> conditioned on it, then they have to explain whether they comply with those
>>>> MUSTs.
>>>>
>>> When I look at BCP-14 or RFC2119 I do not see any distinction for
>>> categorizing MUSTs into main MUSTs or MUSTs under optional features.
>>>
>>>
>>> *1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>>>    definition is an absolute requirement of the specification.*
>>>
>>> While technically sound I am not even sure if any optional feature can
>>> have any mandatory MUSTs which apply only when someone chooses to
>>> implement such a feature.
>>>
>>> In such cases IMO it would be much cleaner to just separate those
>>> features into separate documents and still MUST be a top level normative
>>> clause.
>>>
>>> Many thx,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>