[core] Review of draft-ietf-core-sid-04

Robert Wilton <rwilton@cisco.com> Mon, 09 July 2018 10:48 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9D130F83; Mon, 9 Jul 2018 03:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 sfj5al-Kr7sj; Mon, 9 Jul 2018 03:48:19 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219A6130E62; Mon, 9 Jul 2018 03:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1598; q=dns/txt; s=iport; t=1531133299; x=1532342899; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=ILYlwdQ82g9tv3hMJWeay+NKZP3+kU3+uUpVCskpIdg=; b=JUcOQPdc+TT5JYYYRv0n2yTJJWR9NMH8OOl4JkmbNi1tzKjM3s3uHqiW KuAyyMvOdONPIEbjGSIjGZTYY3UKFLALOox0EJZ7+JmpGo1LrxQpNLRWx awEr1NSQnZCMPxcyvsvaxau+BqCxIlv87d6buVQm3S+mwAMDXWkx6m3Ps g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BzAQBgPENb/xbLJq1bGQEBAQEBAQEBAQEBAQcBAQEBAYMfgXkShCKIY40ylVyBeguHUTYWAQIBAQIBAQJtKIVgDwEFdgImAmAMCAEBF4MFggCpA4IchFuDaoE6gQuJOT+BDyeCaId7glUCmU8JgUCHLIYyBoFChlQlhSKMPIVUgUgKJyaBLDMaCBsVO4JqgiMXegEOjQ8+jwEBAQ
X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="scan'208";a="5002223"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 10:48:17 +0000
Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w69AmGib005562; Mon, 9 Jul 2018 10:48:16 GMT
To: core@ietf.org, draft-ietf-core-sid@ietf.org
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <d729bb7e-7e50-77c0-04bc-d2d44e875e68@cisco.com>
Date: Mon, 09 Jul 2018 11:48:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FTo86sfr2G947xoWz7dznqvF9tI>
Subject: [core] Review of draft-ietf-core-sid-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 10:48:22 -0000

Hi,

I've read this draft.  I think that it is well written, and is fairly 
easy to follow, and I generally like the solution of SIDs.

Some comments:

1) Section 1. I think that it may be better if SIDs are only allocated 
from the range 0 to int64 max (i.e. 2^63 - 1).  This would still seem to 
make huge numbers of SIDs available, but makes it easier to generate 64 
bit SID deltas without having to worry about sign overflow.

2) In the YANG model .sid file format (section 4):

(i) It might be nice if this could use YANG instance-data 
(draft-lengyel-netmod-yang-instance-data-02), although I don't think 
that it is worth waiting for.

(ii) Rather than the enum of namespace types, and 2 key list, I would 
prefer that there are separate lists (each with a single key) for each 
namespace.  I think that this would probably make it slightly easier to 
process, since implementations could then easily choose which order to 
process the namespaces in.  It also avoids the need for the union type, 
and corresponding MUST statements.

(iii) If you are going to use RFC 2119/8174 language in the YANG module, 
then I think that the module should include the boilerplate from RFC 8174.

3) Section 6.1:

In the first sentence, I think that you should include "private 
enterprise" (or equivalent) in the list of examples.

Section 6 isn't particularly clear about allocating blocks of SIDs to 
private enterprises or individuals.  I presume that this is allowed, and 
possibly it would help if the draft was a bit more explicit on this.

Thanks,
Rob