Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Bob Hinden <bob.hinden@gmail.com> Wed, 13 May 2020 23:13 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4B23A07AA; Wed, 13 May 2020 16:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDADebR2UCI8; Wed, 13 May 2020 16:13:53 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C743A0791; Wed, 13 May 2020 16:13:52 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id w7so1475458wre.13; Wed, 13 May 2020 16:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YYf3jbuwibufffK5HuJsmGYK0KWrq6svCo/qEe8lnK0=; b=qR+Q52Mp+mqNMSNN1haP5tTtNwNO45jC//9Oi2b0OdmAmKvUSWnEEb3WpU556onqd6 BacGxpqyncXiBgGG/VRAAutWfH+n2pTb6+0AbwnzeIvGHB+EUSvQx/OOuhHkcBNV8EkX 1C6O2+8YL7hv52zYTewDQ7ZTfCZj3cGMKhcCVtLWHoazNgd9k1lV5AHq4VYy1nID18zq kXBPN2DL9Tz+EklNgds0mhtbeIn36tcA3lDGi4CAnaj+uRKB325QG96zXJss7K4RVkEG FqgJmsEipwQjs/yK4WBvXj4uu7zw/Of9rAvfb8k1ADQ7n2/USYlffjwrrKUE+2/MHxDm A82Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YYf3jbuwibufffK5HuJsmGYK0KWrq6svCo/qEe8lnK0=; b=av5BvpokmI/r8lpQqj+r/ip/L08wAuLVYsrb+CLFM+JJo6UAXMBgwkBa/JeWvglIr/ 0cjx7bxwwE3qGQtfkpiYb/qxSimaxcJ+x0KQDBJXFlSt6KWBnI2zIucVK9ftTGXXNw32 nUbV8cOHRrbvo2C1oelX6NCliZYOMU+C/l0F8CKtS3hg1Bn4XRdr4/bwpVbXF4scaHgr Zd+krc0XqT1MNzuCn7t5xfrX0diO5FLYM3WZW6EE6jtrerO6vCzGWNdv7cJ82BCRQXZ6 G34DpOTUwIhdtz3TzwD5Bxvz9NFXs1qvrKi8ObsRLrSZdq6OlevF/EvgCihPnAnquSlL +D+w==
X-Gm-Message-State: AOAM530rLP+DEun+SC/w5zJptT7OGeaza47nlSDcC00LPk1Ij7uD6b+p l4HtbmSCibMq9CDyKUoCkzE=
X-Google-Smtp-Source: ABdhPJxYJPqFrq1TUcXxrBXm3eb0hCaVJHzC+C2HYHmuqEEm4UnMQX0AnEm6uXk3+CRdddplfmManw==
X-Received: by 2002:adf:f907:: with SMTP id b7mr1882964wrr.203.1589411630850; Wed, 13 May 2020 16:13:50 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:a8ee:1611:4a33:248? ([2601:647:5a00:ef0b:a8ee:1611:4a33:248]) by smtp.gmail.com with ESMTPSA id r11sm1528748wro.15.2020.05.13.16.13.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 16:13:50 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <A591E0CD-C4DC-4598-866A-74581E1F1338@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C8EF8CA8-E899-46B1-BC2D-F6FD116B9FE4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Date: Wed, 13 May 2020 16:13:45 -0700
In-Reply-To: <21E9A957-1A31-4A11-8E78-5F7E382866D4@juniper.net>
Cc: Bob Hinden <bob.hinden@gmail.com>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "6man@ietf.org" <6man@ietf.org>
To: John Scudder <jgs@juniper.net>
References: <DM6PR05MB6348E9AD1E088792C2F10BB4AEBF0@DM6PR05MB6348.namprd05.prod.outlook.com> <8CC3F837-B4D6-4570-AF2F-37041839F391@employees.org> <21E9A957-1A31-4A11-8E78-5F7E382866D4@juniper.net>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/om420e7EBf-vrfFlb5zq7P9CWw0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 23:13:55 -0000

John,

> On May 13, 2020, at 12:59 PM, John Scudder <jgs@juniper.net> wrote:
> 
> I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and (2) what criteria are the chairs using to decide when an adoption call is OK?
> 
> It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”?
> 
> I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:
> 
>> Bob: Thank you Ron. I think it's too early for adoption call.
>> 
>> Ron: What is needed to get to adoption call.
>> 
>> Bob: I can't answer right now.
>> 
>> Ron: Can I ask on list?
>> 
>> Bob: OK.
>> 
>> Ole: Related to what's going on in spring.
> 
> Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this answered on list yet, so I’m asking again.
> 
> Regarding the SPRING-related process stuff:
> 
> I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter, god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF, the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch is a sandwich. [1]

Good to know.

> 
> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?

In my view, the general answer to that is no, we don’t need the Spring w.g. permission to consider adopting a new routing header.   If a draft came along that was proposing to update SRH (RFC 8754) we would want to discuss it with the Spring w.g.

In my reading of the current version of CRH, it is not proposing to update RFC 8754.

> 
> Regarding the more general “what is CRH for anyway” stuff:
> 
> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too early?

Seems like we are having this discussion now even without a formal adoption call.

Ole and I are discussing this tomorrow.

Bob



> 
> Thanks,
> 
> —John
> 
> [1] https://cuberule.com