Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 21 August 2019 09:34 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600C912080C; Wed, 21 Aug 2019 02:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MHy98NDK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GISyVZxl
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 HgxZ-hnAfYFn; Wed, 21 Aug 2019 02:34:54 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605A7120142; Wed, 21 Aug 2019 02:34:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10080; q=dns/txt; s=iport; t=1566380094; x=1567589694; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HWivKE+/YvFHlsAhQA4dyHALCdO4SAaelz0PLd1q7iA=; b=MHy98NDKAYsAHGU/HB8d9Jr9Am101vSZu4U6yRX4w8+D98SM3e7mLnW5 Ym4kQ/wOPViVxPqPrFHt3RJAyAGDpv894uyiP71x4Qrk64iasw4zBC/pe 69ihKruAjscXG1BnmKpZyso2LaGYlclrdMiIXr49WU/F0F2eh2nqB9CWy 8=;
IronPort-PHdr: 9a23:dvrTJRLQNghXyypEbtmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAABKD11d/5JdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBVgEBAQEBAQsBgURQA4FCIAQLKgqEFYNHA4p9glyJXo4HglIDVAkBAQEMAQEtAgEBhD8CF4JFIzcGDgIFAQEEAQEDAQYEbYUnDIVKAQEBBBIREQwBATcBCwQCAQgOAwEDAQEBAgImAgICHxEVAgMDCAIEDgUIEweEawMdAQKfUgKBOIhhc4EygnsBAQWFGA0LghYJgQwoAYRzhnUYgUA/gRFGgkw+ghqCBCiDCTKCJowvgjcxnAJACQKCHYtlhFuEFIIxhzCEGIYvhB6DL5QJjjECBAIEBQIOAQEFgWYigVhwFTuCbIJCDBcVgzqKU3KBKYktASQHgQQBgSABAQ
X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208";a="315587906"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 09:34:53 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x7L9YrXM026040 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 09:34:53 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 04:34:52 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 05:34:51 -0400
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 04:34:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DYIAfSNWgSmY8LtuuO7Rw9W0cPZ3++uncL8Gzy6FonUpPkO5fyosreayZF/HhYgrl+SRSmaqI1SGwU8k9IFVbrxpeLa1a85vCQR1SDrW8c0RlZrymBJF38HpIh6pTyKZYshu/oqf/DN6TQHC6RLHSGsIIxEM3kqPRewuFWNiB2ffeCl0YZ7uFraqW0Y4CKK4XVK/jW69/hlTJIynIB1nDykJIXoCo7f0tfjGIu/Lr6wA9TyOjNUsdm4RWxGjnEYaYL2E3svNKZph2bYeQlk8Zkl1JsagPMN38Z00BYPxiEwPZ7Ob5gmTAu+0qFTFLniPWQo98xe3z/FD9c8AsNUqnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HWivKE+/YvFHlsAhQA4dyHALCdO4SAaelz0PLd1q7iA=; b=cdLDSyu+th5hEJu5HY35tEqXJMaC55/uRpkO2/zFTXz/7UykPI+3L0UDm9rQtvvOyOy4Wwud9e7IeYQD2Ure4b/b0AwkGuRp4xXGgTp/j2Kk+oGVR6TBoSsHpJ/66cwcB0clj1WCr6mz0eS2Aij/3ZCTYKtSuxXUc/E54X4ZvRWi8XfsTrqQCLgZrsGNgE6FmffzUPLUiJX0TSmdd4qdMK7B/71ZbUDXhlXw3SDlZSaTv26Dtia1l1sPzGQ5BXzaMmSuVVH1rz+5FHaDVnv9C8R+ovuavMBPMUb9+LA/qBCoGmmQVB/B8IANb+j1Twr6DX/NdFx7z9pjDfgmeHKi9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HWivKE+/YvFHlsAhQA4dyHALCdO4SAaelz0PLd1q7iA=; b=GISyVZxl5Zrwh8rS8WM7ZUEPtv3StrpFtoHQRjIPj9g/GYyCwH+QhnHXPflEc18Fg0tvlpMAE85HihYzxMIVMrfcQZHgQOt4nHHXucUH5y4lFKYYPJ2bjQN+m4hiUfW56+A+TLa+GFArmDYrN82CzBSmG98hUwj08K4Im1S40/Y=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4365.namprd11.prod.outlook.com (52.135.38.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Wed, 21 Aug 2019 09:34:50 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 09:34:50 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: Suresh Krishnan <suresh.krishnan@gmail.com>, Shwetha Bhandari <shwetha.bhandari@gmail.com>, "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-6tisch-architecture@ietf.org" <draft-ietf-6tisch-architecture@ietf.org>
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
Thread-Index: AQHVTTeCiwQleGHbhki5mBVADKTIRabv5gYigAADq4CAABiTZIABC4UAgAA7JYCAACLH/IAAAwMAgBLXgFCAASPZMA==
Date: Wed, 21 Aug 2019 09:34:32 +0000
Deferred-Delivery: Wed, 21 Aug 2019 09:33:59 +0000
Message-ID: <MN2PR11MB35654E38257202BB67793CD7D8AA0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <156519288057.8345.12430078423880669840.idtracker@ietfa.amsl.com> <F3D6850F-3223-4A25-A9B3-107D09638544@cisco.com> <D465F896-D8E9-4723-AB38-0E7863A59E35@kuehlewind.net> <7ABEDEAB-9C67-491E-BC14-197C4EF1F12E@cisco.com> <7DF936ED-24E7-40FC-9BB7-8DC411BA83C1@kuehlewind.net> <CA+MHpBrZ7HF+jpEVZfDxZY2gMChBe0SAnH3bW4PqHekjov9GYQ@mail.gmail.com> <E1DD6E00-AE9A-4618-8501-DC774D14C9FE@cisco.com> <CB3E6F95-53DA-4B29-8277-F3423FDD73B2@kuehlewind.net> <MN2PR11MB35650E88DE1D009CA7BB38DCD8AB0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35650E88DE1D009CA7BB38DCD8AB0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [173.38.220.45]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 19dd5296-405a-42ef-086a-08d7261ad06e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4365;
x-ms-traffictypediagnostic: MN2PR11MB4365:
x-microsoft-antispam-prvs: <MN2PR11MB436592B5A0DFF35AB72D3745D8AA0@MN2PR11MB4365.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0136C1DDA4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(136003)(396003)(346002)(199004)(189003)(13464003)(71190400001)(14454004)(86362001)(486006)(74316002)(478600001)(305945005)(229853002)(7696005)(53936002)(446003)(11346002)(6916009)(9686003)(99286004)(6436002)(55016002)(76176011)(6246003)(6506007)(66946007)(66556008)(66476007)(66446008)(64756008)(25786009)(76116006)(66066001)(8936002)(6116002)(3846002)(2906002)(33656002)(6666004)(53546011)(54906003)(186003)(66574012)(5660300002)(102836004)(4326008)(476003)(224303003)(81156014)(81166006)(316002)(52536014)(71200400001)(14444005)(7736002)(256004)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4365; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: xhTJACs4gHurb32rJJxNymMmywk8GDcAsQ374ClLpl6/OqS0Bx/Rl4bKTAtvIs+Dfu1Kv5r2YSFptAjauAeISucRunHskx4VFDU17n5L1QZrszQKuc6H0VZFSs7C9PE3Y6s186FJyh8tCDU/pHnTsEgjCW2GUHluwL9rqEk/Z6fkS6O55umcGPHwLF+D1ObxVQBexkx7MmONAzsbwGqg0d42w+dcJrl/oo8hkfaZWWKxV5qZFmXtXA/uTXMBo6Y/gU0LVU3p18hb92/zQMjWzyT+Lce8fHd80WJKLHO+nwBMsbgyLRZwAgUaJIqVHCkZsxjgHaStYu15ejYzakwD5kbzjQlLI+YfWhFLjmJSBIQmXJ7YHYJgvdOLtitEQ71NH+2xbwBwrFjPOx6fAEUZVD30KVIXgivlXfcCELFfmOs=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19dd5296-405a-42ef-086a-08d7261ad06e
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 09:34:50.2262 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5KzpBPZ7zLIauLpVKM31AOri7RI5ot7pCs+fvSIEG0XjejpLV+tJ1izn99awMaeTZWc9Egku4N/ZUk/ZOa7pIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4365
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/wsa-swFWvMgOpJXX1xZEQjOwglk>
Subject: Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 09:34:59 -0000

Hello again Mirja:

I made the pass. On the one hand one could say that as expected the text is readable as is, and that the references are complement of information on the detailed howto.
I found exceptions that really need to be moved anyway per your description of normative:


      <?rfc include='reference.I-D.ietf-6tisch-minimal-security'?> 
      <?rfc include='reference.I-D.ietf-6lo-backbone-router'?> 
      <?rfc include='reference.I-D.ietf-roll-useofrplinfo'?> 
      <?rfc include='reference.I-D.ietf-roll-unaware-leaves'?>

Another extreme view would say that the reading is only complete if some of the drafts are read as well. Taking that other extreme view and adding it all together I obtained the following list:

      <?rfc include='reference.I-D.ietf-detnet-architecture'?>
      <?rfc include='reference.I-D.ietf-6tisch-minimal-security'?>
      <?rfc include='reference.I-D.ietf-6lo-backbone-router'?>
      <?rfc include='reference.I-D.ietf-6lo-fragment-recovery'?>
      <?rfc include='reference.I-D.ietf-6lo-minimal-fragment'?>
      <?rfc include='reference.I-D.ietf-6lo-ap-nd'?>
      <?rfc include='reference.I-D.ietf-roll-useofrplinfo'?>
      <?rfc include='reference.I-D.ietf-roll-unaware-leaves'?>
      <?rfc include='reference.I-D.ietf-6tisch-enrollment-enhanced-beacon'?> 
      <?rfc include='reference.I-D.ietf-6tisch-msf'?>

These are the document that really give a comprehensive picture of the RPL network. I'm OK to move them in the normative reference section. That will certainly delay the shipping of the RFC for the architecture, but that will allow us to validate at the last minute that the architecture is still a correct reflection of what those drafts specify.

Please let me know if that matches the need that you identified,

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 20 août 2019 18:06
> To: Mirja Kuehlewind <ietf@kuehlewind.net>
> Cc: Suresh Krishnan <suresh.krishnan@gmail.com>; Shwetha Bhandari
> <shwetha.bhandari@gmail.com>; 6tisch@ietf.org; 6tisch-chairs@ietf.org; The
> IESG <iesg@ietf.org>; draft-ietf-6tisch-architecture@ietf.org
> Subject: RE: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with
> DISCUSS and COMMENT)
> 
> Back from vacations : )
> 
> I think I see your point Mirja. What we tried to do here is build a self-sufficient
> document at the architecture level.
> The specs referenced (exception from DetNet and those which have both
> Architecture and specification content such as IPv6) are pointed because they
> implement the architecture, but reading them should not be necessary to
> understand the words in the architecture. I'll need a full pass to check if we did
> that right.
> 
> All the best,
> 
> Pascal
> 
> > -----Original Message-----
> > From: Mirja Kuehlewind <ietf@kuehlewind.net>
> > Sent: jeudi 8 août 2019 18:16
> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > Cc: Suresh Krishnan <suresh.krishnan@gmail.com>; Shwetha Bhandari
> > <shwetha.bhandari@gmail.com>; 6tisch@ietf.org; 6tisch-chairs@ietf.org;
> > The IESG <iesg@ietf.org>; draft-ietf-6tisch-architecture@ietf.org
> > Subject: Re: Mirja Kühlewind's Discuss on
> > draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
> >
> > See below.
> >
> > > On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert)
> > > <pthubert@cisco.com>
> > wrote:
> > >
> > > Hello Suresh and Mirja
> > >
> > > I’m happy to get recommendations on that topic. I understand Mirja’s
> > recommendation on how to use normative refs; it makes sense, more so
> > for std track. For informational, I’m still puzzled: Why call
> > something normative in a document that is not establishing a standard?
> >
> > Let me give you a simple example. An informational document that
> > describes operational practice for protocol X, needs to have the
> > reference to the spec describing protocol X as a normative reference
> > because if you don’t know anything about the protocol X, you will not
> > be able to understand the operational guidance given.
> >
> > This is an easy example and I know that there are many cases where
> > this is less clear, however, it can definitely make sense to have
> > normative references in informational document because it solely
> > indicated which other documents are a MUST read in order to understand this
> document.
> >
> > Mirja
> >
> >
> > >
> > > On the topic of refinement section 4 goes clearly deeper down than section
> 3.
> > This is by design. We did not want to split and have to maintain and
> > keep in sync
> > 2 documents. Also we got hints from you guys that overloading the IESG
> > with many small documents was not the right way.
> > >
> > > Regards,
> > >
> > > Pascal
> > >
> > > Le 8 août 2019 à 16:01, Suresh Krishnan <suresh.krishnan@gmail.com>
> > > a
> > écrit :
> > >
> > >> Hi Mirja,
> > >>
> > >> On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind <ietf@kuehlewind.net>
> > wrote:
> > >> Hi Pascal,
> > >>
> > >> See below.
> > >>
> > >> > On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert)
> > <pthubert@cisco.com> wrote:
> > >> >
> > >> > Hello Mirja
> > >> >
> > >> > It certainly does not hurt to have a second look at how the split
> > >> > was done
> > and why.
> > >> >
> > >> > With one exception - the DetNet Architecture - the references
> > >> > fall in the
> > category of solutions which is a level below this spec in the design cascade.
> > >> >
> > >> > They explain how things are done when this spec tries to limit at
> > >> > what gets
> > done and tries to be complete at it. We can point on the solution
> > specs because we only publish once the work is mostly done as opposed
> > to a as a preamble to the work like in the case of DetNet. Then again
> > that was a conscious decision be the group which is more of an integrator than
> a creator.
> > >> >
> > >> > From that perspective only the DetNet Architecture would be
> > >> > normative,
> > the other specs playing at a different level and not needed for
> > understanding things at Architecture level.
> > >> >
> > >> > OTOH it would be grand for this spec to reference RFCs as opposed
> > >> > to
> > drafts. That would help the reader. But then there are many solution
> > draft and we could keep building new ones forever.
> > >> >
> > >> > I’m unsure what you mean by strongly wrt the fragment drafts.
> > >> > They have
> > a purpose and the Architecture describes that purpose. Since it has an
> > Architecture impact with per packet l’avales and stuff we had to
> > explain it. Did we go too far into explaining the solution?
> > >>
> > >> Yes, I had the feeling that is went too much into details a couple of times.
> > However, as I said, I didn’t read the document in depth and therefore
> > can’t give strong advise.
> > >>
> > >> @Suresh: Can you maybe have another look at the reference. If you
> > >> are okay
> > with the current approach, I’m happy to clear my discuss. Mainly
> > wanted to double-check!
> > >>
> > >> I was fine with the current approach to references but I do see
> > >> your point. I
> > will try to see if I can propose something to simplify this.
> > >>
> > >> Thanks
> > >> Suresh