Re: [lisp] Distinguished Name comments

Dino Farinacci <farinacci@gmail.com> Wed, 13 December 2023 22:11 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40F7C14F617 for <lisp@ietfa.amsl.com>; Wed, 13 Dec 2023 14:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQEBcJsjaqHh for <lisp@ietfa.amsl.com>; Wed, 13 Dec 2023 14:11:39 -0800 (PST)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6264C14F604 for <lisp@ietf.org>; Wed, 13 Dec 2023 14:11:30 -0800 (PST)
Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-286b45c5a8dso7852893a91.1 for <lisp@ietf.org>; Wed, 13 Dec 2023 14:11:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702505490; x=1703110290; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=A3KBI+Oaktrsf9GpQHgwS56lBl3ZCpW0ZZJCwDUZDjk=; b=R+y5AoXMV44C80FIo/zzDOxj+eYo+01jUZASe8MUa0zJ0V1Ml1OlDNhpXdXvAg9uFd rODcHxpB3UsGAIZZSdA7mpPo216bT9oNMD6jT/ngsp5B3pNXFcTQBvAo+b7dZmSpz5WJ cYVDNDNHTWYGf5/VlkqBjlBAmQNfpyxvP6AYMBtvTFBkZufDDT8/sptyH6ffYrgXc53L 7+rX7fTsCHfR1CSEMdHktGBX1hacWnGnHU1ImjYVQcDTDJRsyufy/ggGFSYL2OB1/3EM lT8CmZsH0k85Q8Da6Ey/MKViJ6NUJIxitbGLUk2aw5l+MGfU3kzE5kMPRgV4d/m8R0n0 qDtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702505490; x=1703110290; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A3KBI+Oaktrsf9GpQHgwS56lBl3ZCpW0ZZJCwDUZDjk=; b=qe2AacqlZF9iqTtEYrWJpf/e/bWo8cKOA3HJoa99fPLxSwyljGjf95XrhIvVTHI8x7 eFI1QeLiGSH31tGTHSkiChDbRBeGPqno5rFkV9DvYx226JIwm8poscYu4gLmWf3pHJ/R fbdAD8+tX+r52hF/osk+pEkOlO+BlvrC/kvgJMoOglEezQffoD9HUUqtW1QOAWMmxuDF TTIV8w1C0oomGFnogy7ryhNPzpg1oeL7vZejh6aRXy0P0oOlkAZ8Mv/j/VPnHeriezbE 0CMqJ/wOjiKc0RAvcb6EzDBBOmp9h/WAd8sRwToyh/HVCoHX9tFtBwN3iyYyJJHElXDC B+Bw==
X-Gm-Message-State: AOJu0Yyo9II3lmbqmM2/wJgUcK5i13PnrDoAwNLpNOzV94R8T5kZwEq/ ID10PCd8DUdKKUU3IKG8dA8=
X-Google-Smtp-Source: AGHT+IFSqxHixqGgODEOCQE5YsMf2ZbLONXosw9vFiLthohJoeREF3JLtcVwLR8QIrxXneqeoXkK4g==
X-Received: by 2002:a17:90a:9f8d:b0:28a:c760:218 with SMTP id o13-20020a17090a9f8d00b0028ac7600218mr2360590pjp.28.1702505490221; Wed, 13 Dec 2023 14:11:30 -0800 (PST)
Received: from smtpclient.apple ([2603:3024:1563:e5a8:3940:aba2:6c79:5094]) by smtp.gmail.com with ESMTPSA id v5-20020a17090a778500b0028098225450sm12881088pjk.1.2023.12.13.14.11.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2023 14:11:29 -0800 (PST)
From: Dino Farinacci <farinacci@gmail.com>
Message-Id: <D02D4E4A-915D-424C-AADE-632780D7FCC6@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_B966DBFB-06AB-4366-8DAD-276176D80C9B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Wed, 13 Dec 2023 14:11:18 -0800
In-Reply-To: <BYAPR11MB3591BE3135A54FF5F3193675B68FA@BYAPR11MB3591.namprd11.prod.outlook.com>
Cc: "lisp@ietf.org" <lisp@ietf.org>
To: "Alberto Rodriguez-Natal (natal)" <natal@cisco.com>
References: <BYAPR11MB3591BE3135A54FF5F3193675B68FA@BYAPR11MB3591.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/pHK6Z8H3LeWvGB5wzxL5qNasjp8>
Subject: Re: [lisp] Distinguished Name comments
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2023 22:11:43 -0000

Thanks for the comments Roberto. See comments inline. 

> First my apologies, this is long overdue. I’m trying to catch up with my shepherd’s review of draft-ietf-lisp-name-encoding and I have some comments/suggestions on the current draft.

I have submitted draft-ietf-lisp-name-encoding-03 to reflect your comments with a diff file attached.

> >    • Sec 3: You describe that when a DN is used as an EID, an exact match is performed (which is correct). However, this is described in the format section of the document, shouldn’t this be discussed somewhere else (maybe on its own section)? I know this is a very short document, but having that behavior described in the format section seems odd to me. No strong opinion though.

I have added a new section.

>     • Sec 4: You say it in the title of the section already, but it might be interesting that on the body of the section you mention that the listed use-cases are examples and more importantly that we explicitly say that that other use-cases not listed are possible as well. Typo: s/ascii/ASCII

Made the change.

>     • Sec. 5: I think that this section should talk about unique Instance-IDs (IIDs), not VPNs, so that the text is more general while preserving the considerations about name collisions. We can point to the VPN draft to mention one example of how a particular use-case is registering DNs in unique IIDs, see also the next point on this.

Made the change.

>    • Sec. 8: If we talk about IIDs in Section 5, there is no need to keep the VPN draft as a Normative Reference and could be moved to Informative, easing the RFC process.

Fixed.

Thanks again,
Dino