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

[Martin Duke <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]>
> Sent: Tuesday, November 24, 2020 3:10 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Fred Templin <[e-mail]>; [e-mail]
> 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?
>
>
>
>