Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

Martin Duke <martin.h.duke@gmail.com> Fri, 18 September 2020 17:44 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDBB3A1219; Fri, 18 Sep 2020 10:44:06 -0700 (PDT)
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 h7kEJjQuFJgi; Fri, 18 Sep 2020 10:44:04 -0700 (PDT)
Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 A91C23A10D0; Fri, 18 Sep 2020 10:44:04 -0700 (PDT)
Received: by mail-il1-x144.google.com with SMTP id f82so7012858ilh.8; Fri, 18 Sep 2020 10:44:04 -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=GhaWpIL74mwvcU1GbQZbAOGwp9OruPf9px3Iif2q9zQ=; b=q5x+PRGUn4O7dr9PW+S1hurz1x+Rmeoe8OQ5Bc/+hBsrARoXhHYHZUBDsMQZPLsdHV EFrfNFEl3CFMtxm57D5f/T5vtxsq9VNfD2nh+vuaX+KWoFmHW2qYbf2IlMYxWcIqDyFl 9XjqFYUl6QQrTOj7DCqQu58vX+l0ec3f2jgIFxRA7XbeKq38t0nf7UjUvhkiCsFzkUfI byL1UGxoTSnjaAPapBlw1wl4FneGPx//TweyGw80Vzq61n6ZYvkAx4QHFwcPwqPREOdV tJwtjvkJo+/+WKWDFSvB8jaNVa0pm1OiMVfbFk/BsvayMhsB2aWV+5ESJ3zAgYRFWzB3 rP0g==
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=GhaWpIL74mwvcU1GbQZbAOGwp9OruPf9px3Iif2q9zQ=; b=JcrjZ/VM23jq1jQBpaXHFDWwVHsB/kefAfSqcccnKkqgwRL4wffTtki70dqjB8aAWT aXO4OfAszghwttmGHxiQHspD0emFprMgjI6ihhCKXVSmr/rSLENqn9saLSzICbu2E2xi HcU/SyxsBRRJm+wUr48oIXWZe3yVf3bjmcL3E6Jc6kX4qI3JBgDjTip7qXqACTxio2u2 WJFowIK8RBik2VWwDvrlkSw202HrajyUkcv4Fq14NT4PYtesPO3Qfa4IfTXbD2iwUgFB 6Lfgkke+N6CCAyHDMFfSIdGgzBPX+vS0QejppUvoZ9cjKU2IAdzgfGidhgrrbzlYK9yM 3KnA==
X-Gm-Message-State: AOAM530+3IH5U/HnRo0QP4kFKVMkEHcl4Kc1MCXfXUvxmi+GBq5H32OT nLWu9CMU1mLb2x+mGMc2S5gvOGJ/Th6xUCZZ7ZQ=
X-Google-Smtp-Source: ABdhPJxMG0mm+57qE28PlCA/DyquMlQkLBUpgoyUzB9GV/SgrIh66tnHu/z35H2pmTrDL3vWzp5hwxAo4yG6BvlsUHE=
X-Received: by 2002:a92:d30e:: with SMTP id x14mr2283710ila.303.1600451043689; Fri, 18 Sep 2020 10:44:03 -0700 (PDT)
MIME-Version: 1.0
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <17053.1599841430@localhost> <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 18 Sep 2020 10:43:52 -0700
Message-ID: <CAM4esxQBL+4wNzJTZ_+QKMCGuo4fgyxZKxr3xmFDVEAn9J7HLQ@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, The IESG <iesg@ietf.org>, Alvaro Retana <aretana.ietf@yahoo.com>
Content-Type: multipart/alternative; boundary="000000000000f089f305af9a0bc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/3m68gvM_A69nlHF3MWq9KmAXTe4>
X-Mailman-Approved-At: Fri, 18 Sep 2020 22:32:26 -0700
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2020 17:44:07 -0000

So I think this update somewhat clarifies the meaning of the original text,
but I am still somewhat concerned about that meaning. Perhaps I just don't
understand how DIO versioning works.

Are the MOP codepoints meant to represent different ways of parsing the DIO
base object? It seems very odd to me that this document is describing
behavior in any way for MOP 5 and up, as there is no IETF consensus on what
these codepoints are going to represent. Is the intent of this language to
avoid having to write in every future specification "nodes using this MOP
MUST use RFC 8138 and the T bit is reserved."?

On Fri, Sep 18, 2020 at 7:15 AM Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> Hello Benjamin and Alvaro
>
> I published the latest to have a fresh reference point.
>
> There seems to be an agreement that
> 1) we need to tell the implementer what to do when MOP ==7
> 2) The changes are updating RFC 6550 formally.
>
> This is reflected in draft 15 as published.
>
> Please let me know if I mossed something!
>
> Take care,
>
> Pascal
>
> Pascal
>
> > -----Original Message-----
> > From: Pascal Thubert (pthubert)
> > Sent: vendredi 11 septembre 2020 21:17
> > To: Benjamin Kaduk <kaduk@mit.edu>
> > Cc: Michael Richardson <mcr+ietf@sandelman.ca>ca>; Routing Over Low power
> > and Lossy networks <roll@ietf.org>rg>; roll-chairs@ietf.org; Alvaro Retana
> > <aretana.ietf@yahoo.com>om>; Ines Robles <mariainesrobles@googlemail.com>om>;
> > draft-ietf-roll-turnon-rfc8138@ietf.org; The IESG <iesg@ietf.org>
> > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> draft-ietf-roll-turnon-rfc8138-
> > 14: (with DISCUSS and COMMENT)
> >
> > Now I’m unsure Michael and I agree anymore.
> >
> > What will today’s developer code?
> >
> > We ask him to test if mop is < 7
> >
> > What value will the developer place in his code if the test returns
> false?
> >
> > If there is no code the Boolean will be uninitialized and the result
> will depend
> > on the type of variable and the compiler.
> >
> > Whatever the developer does the code will end up having a behavior,
> > compression or not.
> >
> >  Leaving it to the implementation will have some people choose true and
> > others false. This is not what we want.
> >
> > We want to control what the code does so we can expect it in the future
> and
> > build our backward compatibility based on that sure knowledge.
> >
> > Before the draft the default was no compression. Quite naturally since
> initially
> > it did not exist.
> >
> > Also we discussed on the ML that for RPLv2 all implementations MUST
> support
> > the compression.
> >
> > In which case it is a better default for a coder today to decide to use
> the
> > compression for mop 7, isn’t it?
> >
> > I hope I make the case right. Just think you’re coding it!
> >
> > Take care,
> >
> > Pascal
> >
> > > Le 11 sept. 2020 à 18:26, Benjamin Kaduk <kaduk@mit.edu> a écrit :
> > >
> > > On Fri, Sep 11, 2020 at 12:23:50PM -0400, Michael Richardson wrote:
> > >>
> > >> Benjamin Kaduk <kaduk@mit.edu> wrote:
> > >>> to MOPs 0..6; but the situation for MOP 7 seems slightly different.
> > >>> If we were *just* leaving the bit undefined/free for reuse in that
> > >>> situation, that is probably also something that we can do in a
> > >>> normal "allocate a bit from an IANA registry" document without need
> for
> > Updates.
> > >>
> > >> Up to here, we agree.
> > >>
> > >>> But that's not
> > >>> all we're doing; we're also saying that if you see MOP==7, then you
> > >>> have to use the 8138
> > >>> header/compression/whatever-we-end-up-calling-it.  Yet we are
> > >>> *not* allocating MOP==7.
> > >>
> > >> Tthat's exactly what we don't want to do.
> > >>
> > >> We are saying NOTHING about rfc8138 when MOP==7.
> > >> Nor are we saying that the T-bit exists (or doesn't exist).
> > >
> > > That's not how I read:
> > >
> > >       For a MOP value of 7, the compression MUST be used by default
> > >   regardless of the setting of the "T" flag.
> > >
> > >
> > >> What behaviour is default and what behaviour is negotiated, and how
> > >> it it negotiated, and how the results are turned on, would be up to a
> > >> document that specifies MOP=7 (or larger mopex)
> > >
> > > What you describe here is more along the lines of what I expected.
> > >
> > > -Ben
> > >
> > >> As an analogy, when we did the ToS->DSCP + bits-that-became-ECN
> > >> change, we did this for IP_version==4 and IP_version==6.
> > >> We specifically did not change it for IP_version==7 or 8.
> > >>
> > >> --
> > >> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting )
> > >>           Sandelman Software Works Inc, Ottawa and Worldwide
> > >>
> > >
> > >
>