From nobody Thu Apr 8 08:55:05 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F753A0CBE; Thu, 8 Apr 2021 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 7cu9eNI7HRXV; Thu, 8 Apr 2021 08:54:57 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 0E21D3A0C56; Thu, 8 Apr 2021 08:54:56 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id c17so2142912pfn.6; Thu, 08 Apr 2021 08:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y2aS+wjsrCAi0FST+g+c/X/Uk2r4aF4Y+ccZFAzYMig=; b=Qye2y47IlUEvxoh9Jw4WuGF/Xa5tkNI8jnnOqHs70F8ZS3ywKfsp4jMwhDdSZQYU3Z sl2Toj9VRY5C4/xPNNe3q/lO3iCaSsrP40x2IsiMogIJaiwRgbEbJ5PdH6NZCb1nGiO1 mIUrfbn3StFVfxkOjY6mTvdEicAHi98M7aK+68H9Pe2VtvVDHjL336EMJvTlWfr6qAqN SS+0eMlwq+Iz1qvwrF33TlcsMQIgBOxMuyXQLHv1CZ3chSXG78GnGI+yu+zo7Bh+hP6c rmDoBMAh/Vxj0s7QDPaU77LLQEQQ4IwOgwZ7F080FG132aZsyobVcUqjmMUPFjqMFyG6 UwFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y2aS+wjsrCAi0FST+g+c/X/Uk2r4aF4Y+ccZFAzYMig=; b=sVbQ0BCJW+DEJJVmG+x4GLBVwgHoh6+xVsRxgtL49fJ/H8Nw1qtvazoLYcX6sY1Ogo rJsfoTwWx154eLPe8KErt9cCQx6FQwvQwb6RY58SybAyJYnJhzvoxBIJtdai4Tu4DgN2 0xDITK+GbLfSIm4MH1VWIHCmDQ4K5WjXQoTu/S/W5FMq5lilfQVilwl4jJ3b41GnEEVe APQPxwNES9RkZa3bdSIUGm38meUX3fIl08iNf3b9Frkhvj1xZWveC6HH1/1uXnpfEDnI quMHQCjXdWMDvjaod66iV4hyuwshPqNiJAcjOoR6vgs8jjSTHIZGTBNsdvZidLnupMXj dGUw== X-Gm-Message-State: AOAM530o25O8ln39rUEjH/rFs3/RL9cUOGlSxq68RR/ls8tlq7Xhsnqt Yyl4tMM8mjnSWH1LIgKhdFcBR6rftg3InMGYKyU= X-Google-Smtp-Source: ABdhPJzAOHXEMrW12ipRH5aIRZ6/00HpN943Y0WJBLQpM98qIDZMeZOlc1DMVzfTcUu4YTKi6JE8cG19pLmrwXAcd/8= X-Received: by 2002:a63:1d18:: with SMTP id d24mr8912887pgd.402.1617897295470; Thu, 08 Apr 2021 08:54:55 -0700 (PDT) MIME-Version: 1.0 References: <160321741182.20077.1775706618101177377@ietfa.amsl.com> <42028b97-c2ff-6a25-e8ac-c77129caac73@ens.fr> <87eeflm0do.wl-jch@irif.fr> <87mtu8zwk6.fsf@toke.dk> In-Reply-To: <87mtu8zwk6.fsf@toke.dk> From: David Schinazi Date: Thu, 8 Apr 2021 08:54:44 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000094653605bf7811fa" Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-00.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 15:55:04 -0000 --00000000000094653605bf7811fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On the topic of the ICMP IPv4 source address, I agree with Juliusz. The specific value of that field is not required for interop, so in the spirit of Babel specs we shouldn't over-constrain implementations. Saying that routers need to be able to send ICMPv4 seems like the right choice here. I would suggest adding some implementation advice saying that using the same address (e.g. the dummy address ) on all routers is simplest but using different addresses can simplify debugging. On the topic of standards/experimental, I think that this specification matches the maturity required of a proposed standard as defined in RFC 2026 Section 4.1.1 . When RFC 188= 3 was published in 1995, I don't think that IPv6 had a lot of implementation and deployment experience. But I don't feel too strongly here, as the consumers of RFCs generally don't look at the track/category when deciding what or how to implement. David On Thu, Apr 8, 2021 at 7:22 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Juliusz Chroboczek writes: > > >> There is one other question in my mind. Does this draft really need to > >> be Experimental? I would be inclined to target it to Proposed Standard= . > > > > I'm a little uneasy on this subject. My personal feeling is that we > > haven't done our homework on this extension (admittedly my fault), and > > that we don't have enough implementation and deployment experience to > > propose it as a standard right now. > > > > I'd be delighted if people could disagree. > > Isn't that just a matter of time? I.e., we could adopt it as PS, with > the expectation that by the time it gets published we will have built > that experience? Or does there even need to be a final decision about > the status at adoption time? > > -Toke > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --00000000000094653605bf7811fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the topic of the ICMP IPv4 source address, I agree with= Juliusz.
The specific value of that field is not required=C2=A0for int= erop, so in the
spirit of Babel specs we shouldn't over-const= rain implementations.
Saying that routers need to be able to send= ICMPv4 seems like the
right choice here. I would suggest adding = some implementation
advice saying that using the same address (e.= g. the dummy address)
on=C2=A0all routers is simplest but using di= fferent addresses can simplify
debugging.

On the topic of standards/experimental, I think that this specification
matches the maturity required of a proposed standard as defined in=
RFC 2026 Section 4.1.1. When=C2=A0RFC 1883=C2=A0was published in 1995,
I don't think that IPv6 had a=C2=A0lot of implementation and d= eployment
experience. But I don't feel too strongly here, as = the consumers of
RFCs generally don't look at the track/categ= ory when deciding what
or how to implement.

<= div>David

On Thu, Apr 8, 2021 at 7:22 AM Toke H=C3=B8iland-J=C3=B8rge= nsen <toke=3D40toke.dk@dmarc= .ietf.org> wrote:
Juliusz Chroboczek <jch@irif.fr> writes:

>> There is one other question in my mind. Does this draft really nee= d to
>> be Experimental? I would be inclined to target it to Proposed Stan= dard.
>
> I'm a little uneasy on this subject.=C2=A0 My personal feeling is = that we
> haven't done our homework on this extension (admittedly my fault),= and
> that we don't have enough implementation and deployment experience= to
> propose it as a standard right now.
>
> I'd be delighted if people could disagree.

Isn't that just a matter of time? I.e., we could adopt it as PS, with the expectation that by the time it gets published we will have built
that experience? Or does there even need to be a final decision about
the status at adoption time?

-Toke

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--00000000000094653605bf7811fa--