[netmod] 6087bis shepherd writeup issues

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

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
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.10]
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:

OLD

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

NEW

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

OLD

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.

NEW

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

Thanks,
Kent (as document shepherd)

[netmod] 6087bis shepherd writeup issues Kent Watsen
Re: [netmod] 6087bis shepherd writeup issues Andy Bierman
Re: [netmod] 6087bis shepherd writeup issues Kent Watsen