[Netconf] Shepherd review of draft-ietf-netconf-zerotouch-22

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 21 August 2018 20:32 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5844B130DF7 for <netconf@ietfa.amsl.com>; Tue, 21 Aug 2018 13:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4xL3STujF6lj for <netconf@ietfa.amsl.com>; Tue, 21 Aug 2018 13:32:35 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 AA801128CB7 for <netconf@ietf.org>; Tue, 21 Aug 2018 13:32:35 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id z4-v6so3988776pgv.2 for <netconf@ietf.org>; Tue, 21 Aug 2018 13:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=mDNgSds0qnxkeEes8z0aPWq/dCnKzLPAum+pI673q1g=; b=N6vfnTL0BKRw4TMaIKebkgs8VYmLSw8Iz7AbdlLxrNLjb2fCQmy6p1et+x8EwJLd5n Y9vMKWWIYEOlNRZvUiAMK3MHfVRmhACl6lpkzOaCyFatpNtFaj1Vz6gszyEHGQsPjoDg YLJc+swUIU0CVGKO0mOnJapzZCmKzhkmyAVpRpk6AyGdmRZLw9SyOs72nGI7jzIq0sl9 EsU9dNvEs1Xz+NdzY7FfFD6+wS7KzD5/PGzlWjh09rg/bRfJ5WtwEdpqXS0AHvbu+5k3 EaH7bFbKWt7reO7vl2W0LW5+q62/xC0qdKKdsSTJQI1ZSCbzPSZCE0PWZTnQ3RFpV/iN CXMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=mDNgSds0qnxkeEes8z0aPWq/dCnKzLPAum+pI673q1g=; b=ZU+HQML5ETi7EquU5PVUePOu4OxBgb41qB7atuaIqGbvhaHPa66o8HCyzabaZE0JBT xDBS1oOVZ8DQKvrzXqulV0O2eiwOPdUjdPJhowGuQSmYRaYaE/JTPqLe3fAdYeZVWqwg CJp9KQh+DFxEb3gppahz42zM7fPhVAAdDX5jmtuxnUtXccRT8V5c0l8NaH8+R+RlcOBY YA4SDoABYHOsjfjjLthCRnQD/f5G579KSOzVFApg8DiecXVDLrCZhbWSHFaSbtrmw8bt I+i+2c4zaI5Bh4A0q8oPG8ITMQksRgOQjT/9bVZZUpI0T1p0n2r2DHii8XkzxXWU0gLd Whhg==
X-Gm-Message-State: AOUpUlHXnOx4XnOQit7BfnU8zR5zJL1nz9ve4jgwJsEjkHRl1NznQ28G J3g7V8suJjbFvv/C09Lpiog=
X-Google-Smtp-Source: AA+uWPx6QczOI2pfthy/J3P5xWpU/srfZY+SCkPDSTdHOJPTfjQ7N9LdcozByE/fIk1aju+2gMDyJA==
X-Received: by 2002:a65:4b87:: with SMTP id t7-v6mr48143259pgq.391.1534883555098; Tue, 21 Aug 2018 13:32:35 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:50a0:4d4:47a:4158? ([2601:647:4700:1280:50a0:4d4:47a:4158]) by smtp.gmail.com with ESMTPSA id r18-v6sm1335588pgo.27.2018.08.21.13.32.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 13:32:34 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <AFAF8A86-ED41-4055-A001-43A24679A310@gmail.com>
Date: Tue, 21 Aug 2018 13:33:20 -0700
Cc: Netconf <netconf@ietf.org>
To: Kent Watsen <kwatsen@juniper.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/T3R1zA0InMv_K1R9vFXnmHY7sgI>
Subject: [Netconf] Shepherd review of draft-ietf-netconf-zerotouch-22
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 20:32:38 -0000

Hi Kent,

I am aware that you just published another version of the document. Most of this review was done for -22 version of the document. 

In Section 5.6, in paragraph 6 the document talks about initial configuration being applied. If an error occurs, is that initial configuration removed? If so, how? It also says that the device may not (did you mean RFC 2119’s MAY NOT?) reset itself in order to wipe out any state the preconfigure script may have left behind. That means in case of an error not only will there be initial configuration left on the device, but any state left behind by the preconfigured script. With post-configured script, the device is supposed to reset itself, removing any pre-configured state and also any initial configuration. I do not understand why with initial configuration this exception is being made (of not resetting the device and clearing any state left behind by the current or previous step).

Section 6.3. You need to add references to the RFCs that you import or reference in the YANG model, e.g. RFC 6991.

leaf-list download-uri:

I am confused by the last sentence in the description. “If a secure scheme (e.g. https) is provided, a device may (again, did you mean RFC 2119’s MAY) establish an untrusted connection to the remote server to obtain the boot-image.” Are you suggesting that the device (client) does not need to authenticate itself to the server? Most of the draft talks about the need for the device to authenticate itself for the server to validate the device-id of the requestor. Also, are you suggesting that a untrusted connection is fine because the image returned will be a signed image only? This was made somewhat clear only after seeing Appendix B diagram.

s/This doesn’t affect Security so much as Privacy/This doesn’t affect security as much as privacy/
s/the device is being directed/the device is being directed to/
s/server tis time/server this time/

Appendix C.3:

In the diagram, step 3, it says that “only if source is a bootstrap server, send progress updates”. Shouldn’t it be a “trusted bootstrap server”? The description for step 3 clarifies it.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com