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

Alvaro Retana <aretana@yahoo.com> Fri, 18 September 2020 18:46 UTC

Return-Path: <aretana@yahoo.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 177243A09C9 for <roll@ietfa.amsl.com>; Fri, 18 Sep 2020 11:46:05 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 nh4cGiVho6yB for <roll@ietfa.amsl.com>; Fri, 18 Sep 2020 11:46:02 -0700 (PDT)
Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (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 3B27D3A0A21 for <roll@ietf.org>; Fri, 18 Sep 2020 11:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1600454761; bh=k/AOeQkE4giHMFEYdkeoohzIx1HNsoHRIDeng8txjoo=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Lea7oXNydhH1QNZez5Yqtj1Y493gHAG4jeXICYkWWvg1PRRBtESxwGYCceYGYdQ2wsjKRm6RO5YGLHa3QHHj5HaN9NIPtDaY3zLJcEfuDFyVCUJfKCeLW7QHb1GGmW26ceEq6dxesFY2tuypfedNYrvNVHPTDb+ULxEFpOnebLgozwsxWPeUlVVkYRc/mVMmHnbRWlWQh5vOu/7gj560tTG4XmRZ/p1Z5ItVIn/qkJUsFVJKLUb6S09QE9xfv2kQXFHgQoYQnahBm9dm1XzL281wjq/UOM3DcTEspGmGw8zK6ZtemqTMmqgX34B0FAfRs51a0bz40w5qp2vn1E49AA==
X-YMail-OSG: 2Gc.Qy0VM1mSxos.7uepFXzZ_69RA5blAd0JVFUlp7M53QKkIZI1QggUH3YyFjM kIFEY5kpy_8T9sU7rY5ICerKIlmuxQFNjcgf7hLPuURq7dfCiPvYIMEeOgXirnRaYc8UPhqn3HBb YK9WCCSc2mF4avH3vtIkJ_O9YqzmF9B1H8wbON.avP2HDhvrlUftDxlgCxRDSkjnuy4N3kiveU9. RaiPOpJo3M_YxKs11fLaLt.juPa1M7vN7GLH5wQwuT5C0PmXIJmF7ybf8pscoWVj5UHD4Gbe1dto JuInCkscrQ_cIXP4.Wnf7gdZq4S_lv3hkNL.QKFe_0.9GCwucto66sGd8flwnsZ45lTsh10nLPzz i2sOFVXrWdjkqRlwRtqs9sDUVcQj69P5ulG1MNZUxuMlsAy7GH1nstHOmhHtqF95B5YoEn0lCnNv zoNCcBhjBClFhMpm13ImklI2Y7k_1kospwMG4fC43mtyz393fiuiKyyr47Mt4TxVL7KJ20jzwz.H 70Fco99spK6MZwO.eVv.DvcbypncPD3ydDePBbBuastkg0GzGvY_a1fE7GXWCu0ZaqDba1xLP8hU OLLWHuvRB5I0qdnDWsptXakWhiojE_QF.q62QqqirnYdVdXiX9N.kLM8VqvP_o65xwd2NTXwMDaa OxDqVov4kEJdjg4AJgluhjeuqLtYkpD82jleM7gpnrGhkivjF_5xrnW4WsZOTqnVKLHWK_Z67bNt _2IGD7ZoU8J2XQI36kW2MviUlM_vMxf1TormJNQbnk9mJ_fM7PDxTOpW5IAfid9iv7FhXGpY6mfx JIRCYs4Dri1IgXW6E88pcFyVeSsS82rLIu3MoFyc8hgns2XQfDffWBsrRYN9y47bBNPaSlQfP0LK pm3b.gs1ILYHqRffTvdhPjA9hrX4iC23e7g3AXJaxFBfm80fQGDCUaMUwvcnqIGJXvuik4d6w6nM QcaLu8T0q9zW7HxvAxPATOcBCtSa54J_R4xWkvuB_LDRyZEr1GVZdCpNmlD0oCQIgRbBsgO7KSHc SfCJzzXtVFyLDAg6xXYe23NzPhkkKQbjfPf3I_Imo2J59dZ.DHwH8fkRGpz8pbEw4wAdJPM1cv_x qOGKMUY_dWfZNdy_6zXaD0SwrjYEFzSA03PDMOnZ1TWs6K1M7bJEURdJE_RxZxQ24vw.ZgM9jMCU OpGNcEv2g.6rMKJTNkCxrKIwtlruP783NCpLh8gmYTXm7ipt39O2IqMtngLY5Ht5mE4f_JZSOfHr _nCUIEJpPPAW.DBDbaBGSTQWQKv0Ol_8E4D.3jFTVwpbD1vSFBy4WiktzsROVDR_dqXLQH5vKnfD YlSx67gWCHGo9zKUFCwo7jYFls9wgarngie.QgFgbIXoggQzGxBQSAOx1CUbKH0f6Ovnh8A7S5DC e0Om65bLNk1hfY2jusvgQ2wF3291RWH9PmnsEQ12hqSn9b9A9g.YPw5Qj36m6EJL3LRO9uBad8ZE BVb3OIZGVz.C.A4WZFZS2xeIKFG4fsuQkGaBoOKjfZNxMWxqNiH63QKA7tb.SyQptmwvqo0D2Rgj RFY0-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 18 Sep 2020 18:46:01 +0000
Received: by smtp402.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7cb8902125ecf2aa1f4fad5e68ef70e9; Fri, 18 Sep 2020 18:45:57 +0000 (UTC)
Date: Fri, 18 Sep 2020 14:45:51 -0400
From: Alvaro Retana <aretana@yahoo.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, "=?utf-8?Q?draft-ietf-roll-turnon-rfc8138=40ietf.org?=" <draft-ietf-roll-turnon-rfc8138@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "=?utf-8?Q?roll-chairs=40ietf.org?=" <roll-chairs@ietf.org>, Alvaro Retana <aretana.ietf@yahoo.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <etPan.5f650064.2b2a6a08.faf8@yahoo.com>
In-Reply-To: <CAM4esxQBL+4wNzJTZ_+QKMCGuo4fgyxZKxr3xmFDVEAn9J7HLQ@mail.gmail.com>
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> <CAM4esxQBL+4wNzJTZ_+QKMCGuo4fgyxZKxr3xmFDVEAn9J7HLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5f650064_548a17cc_faf8"
X-Mailer: WebService/1.1.16583 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/rO9QxdkwVO0-IehXI-FRdSs25xc>
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 18:46:05 -0000

Martin:

Hi!

We (the authors and me) are having a live discussion about this next week.  I don’t think this is the final version.  Please hold tight.

The WG has an interim programmed for Sep/30, where we may discuss the overall direction as well.

Thanks!

Alvaro.

On September 18, 2020 at 1:44:04 PM, Martin Duke (martin.h.duke@gmail.com) wrote:

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
> >>
> >
> >