Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)

Kent Watsen <> Tue, 11 December 2018 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80D5F128D68; Mon, 10 Dec 2018 17:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.161
X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S2yYLXUihE09; Mon, 10 Dec 2018 17:27:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 795BC126CB6; Mon, 10 Dec 2018 17:27:29 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id wBB1NmUn025043; Mon, 10 Dec 2018 17:27:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=nPaIHzfGauEmKDlJRxuILQHWYk8tYM3dG9zjTZ6WNqY=; b=VhPBQgXZPRoNgPV2E15+BKdzDAwnUZGkiOA0I33h6LRLByaqNMKa/qlpL3C7a99y4eXh FWFk07Bx6YpgpGrO+Oj2a/Q2xX1se+xc1/wC4bR3YLRMckZ8PnpS8go0dwlEweuCJFyF SMxL7Bt5BeoeatmD7mxUVM0p8vfS4gWHtWHEpGsVGb0JOCq72zVsr8ylmXMI3BLnhgjc zX8fHhKatwVF35xwxVLfHgp2KR8BIm1CNcNLx4fTw+U1+/T0I3Ug4bnHl46fIcoFdf4b kDmb3pMGnLfoEP7TEk3Xxm7jeiRo8Ww6QbJN56LzbvaL9iCANIwXk88SDjGjjqd5knSj dw==
Received: from ( []) by with ESMTP id 2p9nrmsgev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Dec 2018 17:27:28 -0800
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.12; Tue, 11 Dec 2018 01:27:26 +0000
Received: from ([fe80::f0f3:20f0:2104:638c]) by ([fe80::f0f3:20f0:2104:638c%2]) with mapi id 15.20.1425.016; Tue, 11 Dec 2018 01:26:33 +0000
From: Kent Watsen <>
To: Ben Campbell <>, The IESG <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)
Thread-Index: AQHUjST3SSYN/oShh02tzZPXCtM1H6V4cvwA
Date: Tue, 11 Dec 2018 01:26:33 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4619; 6:57lgVJh6Ep0oTvUYut9NJBMX0xGYXaoU+54Kl02dL6ghVlMgJqpJyjIeFFOa2CvR+0bT2PxzHFSw2IQo2MYLNo70frrjfdDZ89W/ME2Gtw8dLxwuy1qXcv2OFry0IuFD2c1RJBa9TwwknKQQo4jr0bX5igGwUF8NEjJ7kjRwXRM+Ax4u7Sx2HH7zEcyF/A/MoQgly3YSTnR+GXpi2lts+dvV9vFldhUajPzqb0Uem2GtWDMsNZHYbvYQA0LclTzJCrEU5ikTQS7gYXkMmf+MfKcKoIN2OJ7LOFy9/SalK7WX9utBP1HFvDIOuw/tggdIN0luy7FTasXlEMGitbWlRYG7a74IBj4JsIWfjH8ae8xeS3YNjEv5KHWgVNQ8KvDXY/CS50YPhQV/7r3Yt/WwEkHiixZR/xhP273GX7sP9GlheAoM2jZzTBjcCZyqiw8DnaraPIkE7RxwPHy8vMM+gA==; 5:xI56CmHeJJiQjAqFKO3IxaljCUnD8XML52pcne0HM6vApspNQ/MKvElLEx2BpB5ngXyw7kPae7M6WMh/AOkkzmBy2Qhvq7BMEfSAL9oKQ1y4Ru//eQfpkqg8KgyF7WP4zQOAdN02PBSU7jKN7d+rmChPFFc8anenCvCLrDb58ko=; 7:dou3V4zD89otsUulf3tpwc8En1emgLxIAIvnEdsf6cJViqDAWbf/bqTIKGbaYSx0nH5cE5wKhf3Q/sXsvj0VgaSSb7/joT+RJ77wdUmVXDR9SGaghmbQ+Us7ZQd0fLZTj8itQz0MfNI0/gXNOUCg6A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c7ad618d-fd19-47f4-66ea-08d65f07afc2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4619;
x-ms-traffictypediagnostic: DM6PR05MB4619:
x-microsoft-antispam-prvs: <>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231472)(944501520)(52105112)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4619; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4619;
x-forefront-prvs: 08831F51DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(39860400002)(366004)(189003)(199004)(486006)(6436002)(316002)(71200400001)(14454004)(71190400001)(58126008)(229853002)(7736002)(5660300001)(476003)(2616005)(256004)(14444005)(6246003)(6506007)(8936002)(110136005)(6486002)(6116002)(3846002)(54906003)(86362001)(97736004)(2906002)(83716004)(53936002)(6512007)(25786009)(36756003)(478600001)(4326008)(82746002)(33656002)(66066001)(99286004)(68736007)(76176011)(106356001)(102836004)(11346002)(446003)(305945005)(8676002)(105586002)(81156014)(186003)(26005)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4619;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ML+WjNAs1hPlUK4OSoRa+qjEWWgHMzmCJyFVDhsSriveRXXnVnx1JISO/SN23MwErsf2+zij2tElmxzWpPW43QPHr2clhj11EC4HWay4ZzH+rww0CzfK1QWvOV0O7/iwQ1YGWJHHqtHzu270O93NsTcVEogtepic/asFpn66+Wut5Zoh3Y7gRYCCCKR7c7Ed3RI5302/M71ezEEQ12wYqYjNvMlTEqxgcVrUqjkIqdCy9KSauStEr5NVO/RTciZW9vHQu4FOHm1HGAJMsVyU5SGmnhMqz9hDLSS4pTVg2Gl6evA5FvP+rWtSYqbU2lwU
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c7ad618d-fd19-47f4-66ea-08d65f07afc2
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2018 01:26:33.6145 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4619
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-11_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812110012
Archived-At: <>
Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Dec 2018 01:27:31 -0000

Hi Ben,

Thanks for your review!
See below for responses.

Kent // coauthor

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I support Adam's and Alexey's DISCUSS points.

I've responded to them both separately.

> §1.2: I have a bit of discomfort in how the manufacturer/owner business model
> is encoded into this. In particular, is there any possibility of anonymous
> owners? How about secondary markets (i.e. transfer of a device between owners)
> without mediation by the manufacturer.)? But I see this is actually mentioned
> in the security considerations, so I don't really expect a change.

First, I don't believe the draft ever says that there is such an integration.
The draft does say that devices must be manufactured with some default trust
anchors, but the trust anchors could be delegated to 3rd-parties.  Similarly,
the draft never states how the, e.g, 3rd parties come to be know *who* is the
rightful owner of a device.  

That said, I believe the document does imply this as a possibility, as it is
by far the easiest to implement, at least initially, for the manufacturer to
themselves stand-up an instance of a trusted bootstrap server and/or a trusted
ownership-voucher issuing service and, of course, integrate both these into
some backend sales channel database.  

Regarding transfer of ownership, the manufacturer may implement some mechanism
outside the scope of this document to facilitate a transfer.  Perhaps it could
be mediated by a sales representative in the field, or perhaps via some action
performed by the previous owner, or perhaps (assuming the manufacturer keys 
"ownership" off support contracts) by the previous owner first cancelling 
their support contract followed by the successor owner initiating a new 
support contract.

Regarding anonymity, it is unnecessary for the manufacturer, or trusted
delegates, to know the actual identity of the rightful owner; they only
need to ensure that the rightful owner can claim ownership unambiguously.
Thinking out loud here, perhaps, at the time of sale, the owner is 
provided a some random credentials that they can use when interacting
with the manufacturer or its delegates - presumably, only the purchaser
(and manufacturer or delegate) would know the credentials for the device.

Of course, a lot of this has to do with the class of device (enterprise
versus consumer) and how paranoid the security dial is set.  The draft
defines just the bits-on-the-wire part of the solution, leaving it to
the vendors to determine what backend parts makes sense for their markets.

> §3.1, 4th paragraph: The first sentence is convoluted; please consider
> breaking it into multiple simpler sentences.
>  - 6th paragraph: The first sentence is even more convoluted.

Okay, I broke the sentence up a bit (in my local copy).  I also did the
same to the similar sentences in §3.3.

> §5.6, 10th paragraph: I'm not sure how to interpret "MUST try". That doesn't
> seem verifiable. 

I'm open to wording suggestions, but what is trying to be conveyed is more
than a SHOULD, and yet not quite a MUST, in the sense that if, for any reason,
the device is unable to deliver the progress report (e.g., remote server down),
it is okay for the device to proceed.  I don't know, maybe "SHOULD" conveys
this just right, thoughts?

> -- first bullet under "implementation notes": is "roll out of"
> the same things as "roll back"?

Yes, replaced (in my local copy).

> §9.8:
> - 4th paragraph: Can the "best practices" be cited or described? Otherwise, the
> normative "RECOMMENDED" seems pretty vague. (Or are the next few sentences
> intended to define those practices?

I'm unaware of any great references.  RFC 5280, §8, 5th paragraph touches on 
it, but not to any great affect.  I added a "For example," (in my local copy) 
to clarify that the following sentences provide some suggestions.

> -5th paragraph: Paragraph is hard to parse.

Agreed. Simplified.

Thanks again!