Re: [babel] proposed info model change

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 12 February 2021 05:55 UTC

Return-Path: <mjethanandani@gmail.com>
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 C955E3A12A2 for <babel@ietfa.amsl.com>; Thu, 11 Feb 2021 21:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 r46R_0iVnFf3 for <babel@ietfa.amsl.com>; Thu, 11 Feb 2021 21:55:54 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 2A1A63A129F for <babel@ietf.org>; Thu, 11 Feb 2021 21:55:54 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id b8so4545453plh.12 for <babel@ietf.org>; Thu, 11 Feb 2021 21:55:54 -0800 (PST)
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=JjHeK4TgZKErwwVgg4YuVZc+jvxEpWc4/tzmDOUCxzM=; b=g1aB0vbMdPEf+CAng6px8Zd2stLaRIRHANzLCEIeqdgYYm6BgiZGvp98istWmFQrC+ jv5xXDPYFU4RS8AYTc2TaP60wi3rFs5wLPkPvTNRkJyqC7qd0za064O4e94USFLyLjOq 22UjzTT5C1V8UyspctlkbalQNB3zBIFIjSS3BbOis+pLLF98AtSykPqKPeFzevZLQBhi LYcl3h+g5ivvl0n6m236Gdtk5l8cawGxkTInfpyeBdByD+RZ/XxOc0mhuL1RAXbzqVfy m7rTRn75pM3P0ti2lWfmP3jaPYCoFPLGcjQopYNAi2tvYmXW0gQcEhtRNf3rbDEPmJl2 w8vg==
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=JjHeK4TgZKErwwVgg4YuVZc+jvxEpWc4/tzmDOUCxzM=; b=igFk2vSpDCYExpkRc0AkWMcAe8tHE3yAZ7GGfLDP4JLM+5ed/JZm2Upz9rufARUMf9 Hnodi/F2Brg30Xvsa/8NlEGJNSkNvwltiZVSM7sP6lIWcG1IJ592NubxXBC0oWn3brgA uvjmxgcX1VeSjsYeIMlTjzkkOT0Hoo1wQW4CnFXRpsBnC422dmaqDJmH0WgoO3RVNr4O gWs3RQW/mcTrGn7xQAFru8paEP5phz8y6t5EV4J01zBJ1thtkA554tJt1mpdfWezkqJ2 /mW4nnsQP7kT4Q8CV4I6G/tA4AWFrrU5V2mEKXlN0nLlZAAi1VyTuCpZLBZIlc9rEJPj Sg6w==
X-Gm-Message-State: AOAM533BYrJ23f2LtAXcg3clqXaQmD/9fGgjF5RJgh8DdxJIFJstU5e8 S6daVPBX0mGli+rKq5fGgF0=
X-Google-Smtp-Source: ABdhPJzMwC8hvRRhSKcGOTLT+aEm+stK1M3i2jfJjgkSlURGMFmie2gycWAyI+T/sd9E3EEfFpFQvA==
X-Received: by 2002:a17:902:561:b029:e3:e69:ba16 with SMTP id 88-20020a1709020561b02900e30e69ba16mr1594894plf.14.1613109353730; Thu, 11 Feb 2021 21:55:53 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:a5c3:54a4:b4f8:7b28? ([2601:647:5600:5020:a5c3:54a4:b4f8:7b28]) by smtp.gmail.com with ESMTPSA id t21sm8171146pfc.92.2021.02.11.21.55.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 21:55:52 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <DBBE09E1-F407-4B5A-A096-669E74F25FB4@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F5BA935-52BA-46CD-9661-8A24CB67E7DA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 11 Feb 2021 21:55:51 -0800
In-Reply-To: <CAPDSy+6YWPr81uKHrWYoY=TZ0A18A_Ui3=CyLP=1K-ezwmgF-g@mail.gmail.com>
Cc: Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org>, "STARK, BARBARA H" <bs7652@att.com>, "babel@ietf.org" <babel@ietf.org>
To: David Schinazi <dschinazi.ietf@gmail.com>
References: <DM6PR02MB6924E3E2DD5568E247859E18C38C9@DM6PR02MB6924.namprd02.prod.outlook.com> <87blcqpau7.fsf@toke.dk> <E5F69D0C-7130-42D3-9080-C2EE5786D917@gmail.com> <878s7up8n0.fsf@toke.dk> <CAPDSy+6YWPr81uKHrWYoY=TZ0A18A_Ui3=CyLP=1K-ezwmgF-g@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/z2DAmlY7CXfWEPiSD2ttaUfyZO0>
Subject: Re: [babel] proposed info model change
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 05:55:56 -0000

Hi David,

> On Feb 11, 2021, at 7:09 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
> 
> We banned all-zeroes and all-ones between draft-ietf-babel-rfc6126bis-00 and draft-ietf-babel-rfc6126bis-01. If memory serves, the idea was to reserve them for future extensibility. Also, banning all-zeroes allows using that as a sentinel value in software.
> 
> Adding the uniqueness requirement sounds good to me, but removing the ban on all-zeroes/all-ones could lead to problems. If the core protocol doesn't allow it, why should the informational model allow it?

If the protocol banned it, that is a different question, and info model can reflect that. I just wanted to point out that it is not because of the data model.

Cheers.

> 
> David
> 
> On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org <mailto:40toke.dk@dmarc.ietf.org>> wrote:
> Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> writes:
> 
> > Hi Toke,
> >
> > The rational has to do with what a data model like YANG does with
> > router-id. To it the router-id is a key, in the form of a string. That
> > string has to be unique. YANG does not prevent it being a string of
> > zeros or ones, provided that string is unique. Thus the dropping of
> > the "MUST NOT” and the addition of “MUST”.
> 
> Right. I seem to recall there being some other reason why it shouldn't
> be 0, but can't find the discussion now, and looking at the code that
> doesn't seem to care. So no objection from me I guess :)
> 
> -Toke
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org <mailto:babel@ietf.org>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>

Mahesh Jethanandani
mjethanandani@gmail.com