IETF Logo Mail Archive

Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 31 October 2021 18:47 UTC

Return-Path: <jmh@joelhalpern.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 43A593A11AB for <spring@ietfa.amsl.com>; Sun, 31 Oct 2021 11:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.43
X-Spam-Level:
X-Spam-Status: No, score=-5.43 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 rNuf6Vat-bdB for <spring@ietfa.amsl.com>; Sun, 31 Oct 2021 11:47:22 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436EB3A11AA for <spring@ietf.org>; Sun, 31 Oct 2021 11:47:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Hj4sQ0xqmz6G9Kd; Sun, 31 Oct 2021 11:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635706042; bh=uaUAs5SrdeTcXsNlF5745dPznMWoE55sPcrsy9m/oqM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=o3yZ61dfG1/sBvVN6HTLnm12lpivOsGz+2hdho4RT+c4dh3EHLqIWBALk5AwQmVZM jEubF8QlKROljQwYHiFnw+B+n3ffz+RrFB3ioxiv+DWFYY4w1s6K9IFDa/cDvWbwUv NoHXGlEjPDDnfKdEUbQXWGW82ZnK+ED3h3C3XVsY=
X-Quarantine-ID: <f16-c4Rhb_bM>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Hj4sP4fgvz6G8F6; Sun, 31 Oct 2021 11:47:21 -0700 (PDT)
Message-ID: <de50077f-1e5b-4a07-cdbd-ca4a6d1ef644@joelhalpern.com>
Date: Sun, 31 Oct 2021 14:47:20 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Content-Language: en-US
To: Robert Raszuk <robert@raszuk.net>
Cc: "spring@ietf.org" <spring@ietf.org>
References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> <CAOj+MMF90kp-W9GVgy4Nb1sQpK31pT3LUURTe9_HYU=_nPxs0A@mail.gmail.com> <db597f79-bbd1-be4a-d409-1e5349e9ad5d@joelhalpern.com> <CAOj+MMGkfJCn+rXPCU80hhbt+V-gJKbVuJP_-muaiU4LQZ+uxA@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
In-Reply-To: <CAOj+MMGkfJCn+rXPCU80hhbt+V-gJKbVuJP_-muaiU4LQZ+uxA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/eoU8ceKEsObLKzND3MSQ1eDvY1c>
Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 31 Oct 2021 18:47:27 -0000

 From my perspective the discussions as part of the adoption call in 
SPRING, and the discussions in 6man make it clear that there is an issue 
to be resolved.  It may be that the issue will be resolved in saying 
there is nothing that needs to be specified.  It may be resolved by 
saying that there are differences, and that they are acceptable.  There 
are many other ways that it may be resolved.

It is my job as chair, given the policy, to determine that there is an 
apparent discrepancy that needs to be addressed.  I have done so.

Yours,
Joel

On 10/31/2021 2:31 PM, Robert Raszuk wrote:
> 
>     I am not attempting to revisit the question of whether RFC 8986
>     complies
>     with RFC 4191.
>     This compression documents raises additional issues beyond those in
>     8986
>     in some aspects of the flavors it describes.
> 
> 
> Could you be so kind and enumerate where in the draft you see *anything* 
> crossing the line by defining new semantics for the ARG part of the SID 
> as defined in RFC8986 ?
> 
> Hint: your argument could have been sustainable if RFC8986 would put 
> additional restrictions on the ARG field. But it does not.
> 
> Many thx,
> Robert
>

v2.46.0 | Report a Bug | By Email | System Status