[netmod] 6087bis shepherd writeup issues

Kent Watsen <kwatsen@juniper.net> Sat, 22 October 2016 13:01 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6CFBE129427 for <netmod@ietfa.amsl.com>; Sat, 22 Oct 2016 06:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id m9Xoq5M3CoFX for <netmod@ietfa.amsl.com>; Sat, 22 Oct 2016 06:01:44 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0095.outbound.protection.outlook.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FD5129420 for <netmod@ietf.org>; Sat, 22 Oct 2016 06:01:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/itirJooNRM49JEymM64VmbGPoZDozEdggIzV1sM+4I=; b=DZNxNzvnKwL840b0VTP+zAeI4gspz19GaHABv8OzLxpQn+CJbrEs3WITzEb/hOhmSK7w7iaps5dAW3STv2TMXRPxZdILrcWJTM90LcqaGp5171LBphFax87TyA8Uq9tj4vI13VC+W4bO1tchAETl7PuV00sE8X7Kc5ncLU0pr74=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ( by BN3PR0501MB1444.namprd05.prod.outlook.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Sat, 22 Oct 2016 13:01:42 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([]) with mapi id 15.01.0539.025; Sat, 22 Oct 2016 13:01:42 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: 6087bis shepherd writeup issues
Thread-Index: AQHSLGRvsirXWAD5AUuYg2jQ6nDWew==
Date: Sat, 22 Oct 2016 13:01:42 +0000
Message-ID: <DB1EC6C0-43E8-4540-97D1-0A275685C027@juniper.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1b.0.161010
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 7891fad7-47d2-4306-a41b-08d3fa7b91f7
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:lTxMJKcP5iPDd5ES6gbulhAhzTO/deNLgaHdWmwMvC+qzBAAKKIs9OwTiF96Pajsi7yypZL/mCHVccm65jWAbbh4+sR8d347brfczUunyignqjnI4gbQO9O1uuhLKIo7FXR82xWaIS5NoZMQGGK525pxhZkwOvG0pQaQAwb8LsA0BP1VwKfCAbimYJDK2c+acwut0te5ox76TmN6mGBCesNSNqkJMod5jnNDGOLbM0w7HD1Fnx3epEABMcZCQhMwLVxbEI1m6Fo8wD0BgScgnZ63FAoH5VeiPSY5dtG0dUZj0865Fhao9mt8jFsQXwQNTW3lsbUsfGxTwHPCTpVCviMQfzhrzS1Eb/VIvkK/DMk=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444;
x-microsoft-antispam-prvs: <BN3PR0501MB1444E44EA834CEACD8D34F1AA5D70@BN3PR0501MB1444.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(51444003)(189002)(107886002)(189998001)(97736004)(4001350100001)(122556002)(66066001)(5640700001)(5002640100001)(2501003)(83716003)(50986999)(87936001)(101416001)(54356999)(68736007)(106116001)(99286002)(106356001)(105586002)(2351001)(229853001)(19300405004)(3660700001)(3280700002)(11100500001)(19580395003)(2900100001)(92566002)(6916009)(36756003)(16236675004)(10400500002)(19625215002)(33656002)(586003)(6116002)(102836003)(3846002)(2906002)(7736002)(77096005)(450100001)(7846002)(15975445007)(5660300001)(81166006)(81156014)(8676002)(1730700003)(110136003)(86362001)(83506001)(8936002)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB1EC6C043E8454097D10A275685C027junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2016 13:01:42.3436 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZJGGuW5HPS5tS-g_FmT89KIvY9s>
Subject: [netmod] 6087bis shepherd writeup issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Oct 2016 13:01:46 -0000

Andy, all,

In reviewing the draft for Shepherd writeup, I found the following issues that I think need to be addressed before the document can be sent to Benoit for AD review:

1. Idnits found the following:

  == Missing Reference: 'RFC6242' is mentioned on line 2233, but not defined
  == Outdated reference: draft-ietf-netmod-rfc6020bis has been published as RFC 7950
  ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322)
  ** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841)

2. the intended status is “Standards Track”, but RFC 6087 is “Informational”.  Please change to the bis to be Information as well.

3. The Abstract and Introduction both call out NETCONF, but say nothing about RESTCONF.  Should they at least refer to both equally?

4. Currently there is a Normative reference to NETCONF, but I believe that it should it be Informative, right?

5. RESTCONF is mentioned in the draft, but there is no reference for RESTCONF. There should be an Informative reference for RESTCONF as well.

6. Section 4.1 regards “Module Copyright”, but after the first paragraph it starts talking about "<CODE BEGINS>" and "<CODE ENDS>".  I’m thinking this must be a mistake, that the CODE BEGIN/END stuff was meant to be in another section (a new 4.2?).  [BTW, that an issue like this got through suggests to me that folks haven’t been reading this document, I’ll discuss with my co-chair if we need to do Last Call again.]

7. I think that 6087bis needs to obsolete RFC 6087, but it’s not labeled as such yet.

8. Related to #7 above, the IANA Considerations section registers a URI in the IETF XML registry, but this was done in RFC 6087, so it can’t be done again, right?  I suggest updating the IANA Considerations section to say that 1) this document continues to empower registry entry’s existence (given that the document obsoletes RFC 6087) and 2) IANA should update their records to point to this RFC for the one that empowers the registry entry.  Make sense?

9. Regarding section 5.23, per extensive discussion with the AD, co-chair, and the datastore design team, we believe that Section 5.23 can be improved to more precisely describe the guidance.  As such, we recommend something along the lines of the following two changes be made:


     Placing operational data within
     the configuration subtree is appropriate if the operational values
     can only exist if the configuration exists.


     Placing operational data within
     the configuration subtree is appropriate if the operational values
     can only exist if the configuration exists.  Placing operational data
     outside the configuration subtree is appropriate if the operational
    values can exist without corresponding configuration (e.g., system
    generated interfaces).


    Sometimes the configured value represents some sort of procedure to
    be followed, in which the system will select an actual value, based
    on protocol negotiation.


     Sometimes the configured value represents some sort of procedure to
    be followed, in which the system will select an actual value, based
     on protocol negotiation.  In this case it is RECOMMENDED to have a
     separate config false value to represented the resulting state.  For

Kent  (as document shepherd)