Return-Path: 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 AFC2F1208E9; Wed, 21 Aug 2019 03:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=X2wyKQBL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pmQkMp/P 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 oGvijjXHxQXo; Wed, 21 Aug 2019 03:11:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3EC120288; Wed, 21 Aug 2019 03:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23075; q=dns/txt; s=iport; t=1566382290; x=1567591890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ksCDMr/gpFv91ZEUyvyYYCidPjUQll37Ws0vOH//Xfs=; b=X2wyKQBLSYRnAzqYiZGHLRNV94oX2ibA9akvj5W8pMXTKYL7hxkRrilh es5jc4G4WL9ZdrxrNMruK34eidyoRpf2FRAjnIuTz0g2//2D1U9dFk+Ur ASbLDhe1pwzfIhKxOX5bu7aWuCJSIAYtwhhfJ0C7YSQL9qM3Mn7whlbu7 E=; IronPort-PHdr: =?us-ascii?q?9a23=3AlloeZRTTBrGNFrDxtc1egDxU9dpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABrGF1d/5NdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVQIBAQEBAQsBgRUvUANtVSAECyqHZgOKfIJciV6OB4E?= =?us-ascii?q?ugSQDVAkBAQEMAQEtAgEBhD8CglwjNgcOAgUBAQQBAQMBBgRthScMhUoBAQE?= =?us-ascii?q?DARIuAQEpDgEEBwQCAQgOAwEDAQEBJwchERQDBggCBA4FCBMHgwGBHU0DDg8?= =?us-ascii?q?BAp9LAoE4iGGCJYJ7AQEFhRANC4IWCYE0AYRzhnUYgUA/gRFGgkw+ghqCBCg?= =?us-ascii?q?0gweCJowvgjeFQJZzQAkCgh2LZYRbhBSCMYcwhBiGL4QejxGIJ44xAgQCBAU?= =?us-ascii?q?CDgEBBYFXDCWBWHAVO4JsgkIMFxWDOopTcoEpiS0BJAeCJQEB?= X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208,217";a="613679407" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 10:11:16 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x7LABGkK003913 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 10:11:16 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 05:11:15 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 05:11:14 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 06:11:14 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HQhntPcWFhUFURDxKbGjVTrurQs7794SQ8zn9hYYAAwykKnxMGTh5UVCy9lzZ2uj5UeeBIBrMoEaL5FPMUzoeO8NGgXHqcskP2xap22hu36SU/DyjFZRqDLYDRU7x4QXmZ98Osg/3aH0VhThki3H8zu3xwVCMVpxPkAX1gHBFQ/mJEoeNbzNgaOaggo7tA3d1sNythu3106Uka6Pn4DrtbqEyBbs9CNJybn4z4pyFdhsZSugFLO22jkYCUKPasJAwBh6BV7jV1PFacrpUqmI07zbNW4xdYDdBsym6QyMfxsYBXz3Vf4jkFQ3Zmrzrf+xwb2yHpoYNbO0aKtanqFMjw== 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=m4vhxV/lxbe3o5d0U2akd5IbhkZjJF6pmWDcBgHute4=; b=YSDG7Oq00nXnxsFUTnnUMZeG7fqA9vYR7dHIkS+ycXfSDBdwBOgf+ybjYXAzlWH9YqqH6w2E/MECBD02Cx7Z3zZ05q1+9H4dMYZ8HLx3OzXC5ucFpDUQ01VtfKQcVfwz0WjywGK358zisRNohZt7H6KJeAI+UdViNuzsfJvIPEptcotrnlZESCL1aIz0bvQNfMnL8SsFqfTa9LmeYAml8i/RjYSEV2Q/CgQWQCFfyefHLRInmPbFY5OEcR5yvbeQ5PkSiFZuq+/TDermEgYsfYBWhj8pdQUrHrgS7uK1qaXfvfceUjJGJtH+MEvFbS51HUd8fK/weifbK1A6s1J3Ag== 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=m4vhxV/lxbe3o5d0U2akd5IbhkZjJF6pmWDcBgHute4=; b=pmQkMp/P269oFX5t0XCJ0wEYPa6pFEUkoUuYrE/3Kx3Pa64CTLHHKSJUb8WLxZKP7DGQbUQPcpwyuXc2l1mYZqboIcs63JkEfANi0GrxtFDZVgDcylW/VncV92LLuSQqtSMUw8/Sqkml3xt+yrZcgvRsLsl+HWbbMIqEBwCdG7A= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3774.namprd11.prod.outlook.com (20.178.254.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.22; Wed, 21 Aug 2019 10:11:13 +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 10:11:13 +0000 From: "Pascal Thubert (pthubert)" To: Mirja Kuehlewind CC: Suresh Krishnan , Shwetha Bhandari , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>, The IESG , "draft-ietf-6tisch-architecture@ietf.org" Thread-Topic: =?Windows-1252?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-6tisch-archite?= =?Windows-1252?Q?cture-24:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVTTeCiwQleGHbhki5mBVADKTIRabv5gYigAADq4CAABiTZIABC4UAgAA7JYCAACLH/IAAAwMAgBLXgFCAASPZMIAACcCAgAACht8= Date: Wed, 21 Aug 2019 10:11:13 +0000 Message-ID: References: <156519288057.8345.12430078423880669840.idtracker@ietfa.amsl.com> <7ABEDEAB-9C67-491E-BC14-197C4EF1F12E@cisco.com> <7DF936ED-24E7-40FC-9BB7-8DC411BA83C1@kuehlewind.net> , <61F571E5-52A3-42FE-8357-32DC48742F64@kuehlewind.net> In-Reply-To: <61F571E5-52A3-42FE-8357-32DC48742F64@kuehlewind.net> 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: [2001:420:44f3:1300:8170:98a7:7988:d19d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d6e03222-bc40-4903-4e0c-08d7261fe5d5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3774; x-ms-traffictypediagnostic: MN2PR11MB3774: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(13464003)(199004)(189003)(186003)(6116002)(11346002)(476003)(236005)(64756008)(66574012)(91956017)(478600001)(66556008)(14444005)(446003)(53936002)(33656002)(7736002)(486006)(5660300002)(52536014)(224303003)(76116006)(6246003)(4326008)(8936002)(86362001)(6306002)(71200400001)(6506007)(81156014)(66946007)(256004)(71190400001)(25786009)(66446008)(81166006)(316002)(74316002)(14454004)(6436002)(46003)(229853002)(54896002)(6916009)(7696005)(55016002)(53546011)(9686003)(66476007)(99286004)(76176011)(54906003)(2906002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3774; 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: F9aYhEnSkubpkaRbPh+0KIB/1y8itY0bTjuKIQZn5IJcblf+l6xKiDzcIbKMBC4VbLuMS4Pn0l97+2yKIoc+ux1zlDkBFLe0TY5Y9DAQuLV3UUhKqCLZnFXV1uqM0nt8jdaL1/iAV1q11WlM6v9T5XQH2bVTfNFeSboqEVXO/rIugyMlRzaLSVwE/lNl3v8SCV0AzXd3P6EWWyT7aM7MjfcV8A+wezpERZyt8vKib9E80FukuIUbyZjtiWeixb3fUAm5lhiLCn3K4naWDjMKU4sAvsz7QXUP70XwmuOLE2oqirFq68mKGQoFz9Y0Tq/cLxjWfpGHoffoO6jmdxwnVp185MTm7siabki3+XfEFqfm1iZBkHTQRijq+4LlqCzZKQbPIMJsxfynC9wCAOqIsPTdPEtguqKel6kds4pbcc4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565441E2BCFBB455F59A681D8AA0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d6e03222-bc40-4903-4e0c-08d7261fe5d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 10:11:13.5769 (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: grsHXBGbjDzBYZOmK2TkRa6JMfyuCRFcZuCvhgMwzQobpDxbCM03DMthVk4QbdVz2S10iyIKS2BnBpC5oS2hrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3774 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [6tisch] =?windows-1252?q?Mirja_K=FChlewind=27s_Discuss_on_draft?= =?windows-1252?q?-ietf-6tisch-architecture-24=3A_=28with_DISCUSS_and_COMM?= =?windows-1252?q?ENT=29?= 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 10:11:34 -0000 --_000_MN2PR11MB3565441E2BCFBB455F59A681D8AA0MN2PR11MB3565namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree, Mirja; By default I=92ll move the most comprehensive list to the normative section= and from there will wait for Suresh to propose an update if he thinks a co= rrection is needed. Many thanks for your patience : ) Pascal De : Mirja Kuehlewind Envoy=E9 le :mercredi 21 ao=FBt 2019 11:59 =C0 : Pascal Thubert (pthubert) Cc : Suresh Krishnan; Shwetha Bhandari; 6tisch@ietf.org; = 6tisch-chairs@ietf.org; The IESG; draft-ietf-6tisch-architecture@ietf.org Objet :Re: Mirja K=FChlewind's Discuss on draft-ietf-6tisch-architecture-24= : (with DISCUSS and COMMENT) Hi Pascal, Thanks for doing this pass. Please see below. > On 21. Aug 2019, at 11:34, Pascal Thubert (pthubert) = wrote: > > 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 descripti= on of normative: > > > > > > > > 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 i= t all together I obtained the following list: > > > > > > > > > > > > > These are the document that really give a comprehensive picture of the RP= L network. I'm OK to move them in the normative reference section. That wil= l certainly delay the shipping of the RFC for the architecture, but that wi= ll allow us to validate at the last minute that the architecture is still a= correct reflection of what those drafts specify. I personally think that having this ability to check at the end is a plus, = however, as I=92m not the expert here, so I will reply on Suresh making a f= inal call. Mirja > > Please let me know if that matches the need that you identified, > > Pascal > >> -----Original Message----- >> From: Pascal Thubert (pthubert) >> Sent: mardi 20 ao=FBt 2019 18:06 >> To: Mirja Kuehlewind >> Cc: Suresh Krishnan ; Shwetha Bhandari >> ; 6tisch@ietf.org; 6tisch-chairs@ietf.org; T= he >> IESG ; draft-ietf-6tisch-architecture@ietf.org >> Subject: RE: Mirja K=FChlewind's Discuss on draft-ietf-6tisch-architectu= re-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 >>> Sent: jeudi 8 ao=FBt 2019 18:16 >>> To: Pascal Thubert (pthubert) >>> Cc: Suresh Krishnan ; Shwetha Bhandari >>> ; 6tisch@ietf.org; 6tisch-chairs@ietf.org; >>> The IESG ; draft-ietf-6tisch-architecture@ietf.org >>> Subject: Re: Mirja K=FChlewind's Discuss on >>> draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT) >>> >>> See below. >>> >>>> On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert) >>>> >>> wrote: >>>> >>>> Hello Suresh and Mirja >>>> >>>> I=92m happy to get recommendations on that topic. I understand Mirja= =92s >>> recommendation on how to use normative refs; it makes sense, more so >>> for std track. For informational, I=92m 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=92t 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 sec= tion >> 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=FBt 2019 =E0 16:01, Suresh Krishnan >>>> a >>> =E9crit : >>>> >>>>> Hi Mirja, >>>>> >>>>> On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind >>> wrote: >>>>> Hi Pascal, >>>>> >>>>> See below. >>>>> >>>>>> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) >>> 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 ca= scade. >>>>>> >>>>>> 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 integrat= or 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=92m 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=92avales 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=92t read the document in depth and therefore >>> can=92t give strong advise. >>>>> >>>>> @Suresh: Can you maybe have another look at the reference. If you >>>>> are okay >>> with the current approach, I=92m 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 > --_000_MN2PR11MB3565441E2BCFBB455F59A681D8AA0MN2PR11MB3565namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I agree, Mirja;

 

By default I=92ll move the most= comprehensive list to the normative section and from there will wait for S= uresh to propose an update if he thinks a correction is needed.<= /span>

 

Many thanks for your patience&n= bsp;: )

 

Pascal

De : Mirja Kuehl= ewind
Envoy=E9 le :mercredi 21 ao=FBt 2019 11:59
=C0 : Pascal Thubert (pth= ubert)
Cc : Suresh Krishn= an; Shwetha Bhandari; 6tisch@ietf.org; 6tisch-chairs@ietf.org; The IESG; = draft-ietf-6tisch-architecture@ietf.org
Objet :Re: Mirja K=FChlewind's Discuss on draft-ietf-6tisch-arc= hitecture-24: (with DISCUSS and COMMENT)

 

= Hi Pascal,

Thanks for doing this pass. Please see below.

> On 21. Aug 2019, at 11:34, Pascal Thubert (pthubert) <pthubert@cisc= o.com> wrote:
>
> Hello again Mirja:
>
> I made the pass. On the one hand one could say that as expected the te= xt 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 descri= ption of normative:
>
>
>      <?rfc include=3D'reference.I-D.ietf-6= tisch-minimal-security'?>
>      <?rfc include=3D'reference.I-D.ietf-6= lo-backbone-router'?>
>      <?rfc include=3D'reference.I-D.ietf-r= oll-useofrplinfo'?>
>      <?rfc include=3D'reference.I-D.ietf-r= oll-unaware-leaves'?>
>
> Another extreme view would say that the reading is only complete if so= me of the drafts are read as well. Taking that other extreme view and addin= g it all together I obtained the following list:
>
>      <?rfc include=3D'reference.I-D.ietf-d= etnet-architecture'?>
>      <?rfc include=3D'reference.I-D.ietf-6= tisch-minimal-security'?>
>      <?rfc include=3D'reference.I-D.ietf-6= lo-backbone-router'?>
>      <?rfc include=3D'reference.I-D.ietf-6= lo-fragment-recovery'?>
>      <?rfc include=3D'reference.I-D.ietf-6= lo-minimal-fragment'?>
>      <?rfc include=3D'reference.I-D.ietf-6= lo-ap-nd'?>
>      <?rfc include=3D'reference.I-D.ietf-r= oll-useofrplinfo'?>
>      <?rfc include=3D'reference.I-D.ietf-r= oll-unaware-leaves'?>
>      <?rfc include=3D'reference.I-D.ietf-6= tisch-enrollment-enhanced-beacon'?>
>      <?rfc include=3D'reference.I-D.ietf-6= tisch-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 d= rafts specify.

I personally think that having this ability to check at the end is a plus, = however, as I=92m not the expert here, so I will reply on Suresh making a f= inal call.

Mirja


>
> Please let me know if that matches the need that you identified,
>
> Pascal
>
>> -----Original Message-----
>> From: Pascal Thubert (pthubert)
>> Sent: mardi 20 ao=FBt 2019 18:06
>> To: Mirja Kuehlewind <ietf@kuehlewind.net>
>> Cc: Suresh Krishnan <suresh.krishnan@gmail.com>; Shwetha Bha= ndari
>> <shwetha.bhandari@gmail.com>; 6tisch@ietf.org; 6tisch-chairs= @ietf.org; The
>> IESG <iesg@ietf.org>; draft-ietf-6tisch-architecture@ietf.or= g
>> Subject: RE: Mirja K=FChlewind's Discuss on draft-ietf-6tisch-arch= itecture-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 b= oth
>> Architecture and specification content such as IPv6) are pointed b= ecause they
>> implement the architecture, but reading them should not be necessa= ry 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=FBt 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-ch= airs@ietf.org;
>>> The IESG <iesg@ietf.org>; draft-ietf-6tisch-architecture= @ietf.org
>>> Subject: Re: Mirja K=FChlewind's Discuss on
>>> draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)<= br> >>>
>>> See below.
>>>
>>>> On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert)
>>>> <pthubert@cisco.com>
>>> wrote:
>>>>
>>>> Hello Suresh and Mirja
>>>>
>>>> I=92m happy to get recommendations on that topic. I unders= tand Mirja=92s
>>> recommendation on how to use normative refs; it makes sense, m= ore so
>>> for std track. For informational, I=92m still puzzled: Why cal= l
>>> something normative in a document that is not establishing a s= tandard?
>>>
>>> Let me give you a simple example. An informational document th= at
>>> describes operational practice for protocol X, needs to have t= he
>>> reference to the spec describing protocol X as a normative ref= erence
>>> because if you don=92t 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 w= here
>>> this is less clear, however, it can definitely make sense to h= ave
>>> normative references in informational document because it sole= ly
>>> indicated which other documents are a MUST read in order to un= derstand this
>> document.
>>>
>>> Mirja
>>>
>>>
>>>>
>>>> On the topic of refinement section 4 goes clearly deeper d= own than section
>> 3.
>>> This is by design. We did not want to split and have to mainta= in 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=FBt 2019 =E0 16:01, Suresh Krishnan <suresh.kri= shnan@gmail.com>
>>>> a
>>> =E9crit :
>>>>
>>>>> 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 a= t 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 tr= ies to limit at
>>>>>> what gets
>>> done and tries to be complete at it. We can point on the solut= ion
>>> 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. The= n 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 fo= r
>>> 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 so= lution
>>> draft and we could keep building new ones forever.
>>>>>>
>>>>>> I=92m unsure what you mean by strongly wrt the fra= gment drafts.
>>>>>> They have
>>> a purpose and the Architecture describes that purpose. Since i= t has an
>>> Architecture impact with per packet l=92avales and stuff we ha= d to
>>> explain it. Did we go too far into explaining the solution? >>>>>
>>>>> Yes, I had the feeling that is went too much into deta= ils a couple of times.
>>> However, as I said, I didn=92t read the document in depth and = therefore
>>> can=92t give strong advise.
>>>>>
>>>>> @Suresh: Can you maybe have another look at the refere= nce. If you
>>>>> are okay
>>> with the current approach, I=92m happy to clear my discuss. Ma= inly
>>> 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
>

 

--_000_MN2PR11MB3565441E2BCFBB455F59A681D8AA0MN2PR11MB3565namp_--