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

["Burleigh, Scott C (US 312B)" <[e-mail]>]

I’m fine with losing that sentence (and in the dtn scheme specification as well), but I would suggest that there is a little bit rationale for including it: it excludes representation in ECBDIC or (for better or worse) in non-Latin alphabets.  I am happy to be guided by the WG and ADs on this.

Scott

From: Martin Duke <[e-mail]>
Sent: Wednesday, November 25, 2020 2:41 PM
To: Burleigh, Scott C (US 312B) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Fred Templin <[e-mail]>
Subject: Re: [EXTERNAL] Martin Duke's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

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