Re: [dtn] [EXTERNAL] Martin Duke's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

Martin Duke <martin.h.duke@gmail.com> Wed, 25 November 2020 22:41 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B174E3A1F1D; Wed, 25 Nov 2020 14:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 n4OUQrM195R7; Wed, 25 Nov 2020 14:41:27 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 347513A0D17; Wed, 25 Nov 2020 14:41:22 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id k8so121365ilr.4; Wed, 25 Nov 2020 14:41:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cruC8s4GZfMu5vQZNgVsaZKVRIOpKSF0+CPRS8NlDCk=; b=WtbVB+fIDcrTeReeWzqaeNroaSq0jZR8mxIHM3ANr2h5z4TPbmB5BM4hXrUSxyIw9T 0Ytu10ySbUhVKzFrn/9BOjeuOjeu1AH42/lyvsntSKDAAGMTZd10jGWy79SGR2PMol+v R97hA08rIXTQNsnP2HtkHlNSeUh2PItOpUyo8lNCZQSg3LMBc7WBdtuT/vsAepVLtJzz FGXjvQeEEMc5UIoezmMCLEGXTJXpv3/v0yhKSqOKF7BgUCDWrHnGUFfUXXjNBNK/D70i aeTcDsIF/GHO1q7KaOdgWeOXUuNlJ3xpfVvbOh6VDb1LHawd4l6zBdf2WQoWk3viH9dQ r60g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cruC8s4GZfMu5vQZNgVsaZKVRIOpKSF0+CPRS8NlDCk=; b=GplI5WHCQqZdt7vKx6oyiBcDY+DqVdipqU2W1s6mxnxwKxjMcrARyIb81cMDP1Zug9 EzKQWelRzNi1bhfAvJhHVG159tDG5ZUYN1iCqm6EdybRNrm67K++MZrPTpBVdfCK5WCt blOEZQR9J4CAwkMpjXRsInm1HZbWSi33hd1auB5U3keBxwJurngQLgt/e8TxIzZQVQxT cv83nh4+kYk1mDesKWIbWryPEIhEzvEsUnUyZLN6cs3pobYK1VBl7Ola9JeHLCkbPiCJ Ec9B7qG/9AUCpPQWtUkIOu86RcjEIc5NJkAiYtAniM4jVYEzBFZwAnHHQZirXoDUvaxd 6mXQ==
X-Gm-Message-State: AOAM530B1RxKizF9qxWJK7MrxXK975oo1RyBV4A9XA0C6Bt6BAYkf/fN JuATIBQC3E8Czm/BT5SWLTDEAythohrztmAy6Fg=
X-Google-Smtp-Source: ABdhPJxyd2/87d1lvxfYtXPWH6e63IJp1461/y5Y8gWJR93LHKcTrq+liocR13mqaQA5SjjpLVWNtGWElmZkS/CdCRU=
X-Received: by 2002:a92:d251:: with SMTP id v17mr4974611ilg.249.1606344081391; Wed, 25 Nov 2020 14:41:21 -0800 (PST)
MIME-Version: 1.0
References: <160625941309.8306.2346706788736776737@ietfa.amsl.com> <9ed32d2f4ed943a49c0f05ef0a46dc71@jpl.nasa.gov>
In-Reply-To: <9ed32d2f4ed943a49c0f05ef0a46dc71@jpl.nasa.gov>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 25 Nov 2020 14:41:12 -0800
Message-ID: <CAM4esxTLZRoNa_eTfnwYKXbfCJRFr0tQzOmraEii9rGn=ZHPgw@mail.gmail.com>
To: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, Fred Templin <fred.l.templin@boeing.com>
Content-Type: multipart/alternative; boundary="0000000000005bc4f905b4f62028"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/IuHQ1bvVzKKfG9UNVl0nKC9OTXQ>
Subject: Re: [dtn] [EXTERNAL] Martin Duke's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2020 22:41:33 -0000

Whoops! I somehow missed the congestion control text in Section 7. Please
disregard.

4.1.5.1.2. Your reply makes sense. It is a little weird to have that text
sort of out there without any explanation. I might expect either an example
or two, or just striking it entirely: it's not like a GUI designer is going
to display the EID in CBOR notation!

On Wed, Nov 25, 2020 at 2:12 PM Burleigh, Scott C (US 312B) <
scott.c.burleigh@jpl.nasa.gov> wrote:

> Martin, thanks!  Thoughts on your comments:
>
> 4.1.5.1.2 is indeed all about the expression of EIDs that take the form of
> ipn-scheme URIs.  For the purposes of transmitting on-the-wire an endpoint
> ID that is an element of Bundle Protocol, these URIs are encoded as CBOR
> arrays as described here.  The "other purposes" for which these URIs would
> instead be represented as ASCII strings would include display on a
> graphical user interface, citation in the text of a node configuration
> command, discussion in a research paper (including a paper whose text is
> being sent as the payload of a bundle), basically any context in which the
> EID needs to be human-readable.
>
> Certainly we could add congestion control to the list of additional
> services that CLs can provide, but the last paragraph of section 7 already
> goes into this in some detail.
>
> Good catch on the RFC-to-be references, several of those are typos.
>
> Scott
>
> -----Original Message-----
> From: Martin Duke via Datatracker <noreply@ietf.org>
> Sent: Tuesday, November 24, 2020 3:10 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-dtn-bpbis@ietf.org; dtn-chairs@ietf.org; dtn@ietf.org;
> Fred Templin <fred.l.templin@boeing.com>om>; fred.l.templin@boeing.com
> Subject: [EXTERNAL] Martin Duke's No Objection on draft-ietf-dtn-bpbis-29:
> (with COMMENT)
>
> Martin Duke has entered the following ballot position for
> draft-ietf-dtn-bpbis-29: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://urldefense.us/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PvBDto6Hs4WbVuu7!dzDULtd8iHa8p4r0Hs_pPRY6qEd-OQzjJneIkpC1-cRz26Bo2AF13bSsZJ2IhXzDZ_PRWamxc5I$
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://urldefense.us/v3/__https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/__;!!PvBDto6Hs4WbVuu7!dzDULtd8iHa8p4r0Hs_pPRY6qEd-OQzjJneIkpC1-cRz26Bo2AF13bSsZJ2IhXzDZ_PRyS8n3TA$
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Sec 4.1.5.1.2 I though this section was all about endpoint IDs. So what
> are the
> "all other purposes" that involve ASCII representations?
>
> Sec 7. Please add "congestion control" to the list of services the CL
> provides.
>
> Sec 10. There are many instances in these registries of a codepoint only
> applying to Version 6, but including 'RFC-to-be' as a reference. Is this a
> mistake, or am I missing something?
>
>
>
>