[dtn] Re: [EXT] Re: I-D Action: draft-ietf-dtn-eid-pattern-08.txt

["Sipos, Brian J." <[e-mail]>]

Erik,

Thanks for these. I’ve captured them as an issue ticket and can work them for a later version. I have some responses inline with “BS1>” prefix.

 

From: Erik Kline <[e-mail]> 
Sent: Sunday, June 14, 2026 8:24 PM
To: Brian Sipos <[e-mail]>
Cc: [e-mail]
Subject: [EXT] [dtn] Re: I-D Action: draft-ietf-dtn-eid-pattern-08.txt

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Brian,

 

Thanks for this; sorry for the late review; and I think this is ready for WGLC.

 

# Independent reviewer comments for draft-ietf-dtn-eid-pattern-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* Overall: ready, with nits, for WGLC

## Comments

### S2.1.1

* "all other characters ... can be part of a scheme-specific pattern"

  Do we need to exclude NUL, and various control or unattached combining
  characters, etc?

  Would RFC 5198 be helpful here? Section 2 has some good constraining
  text, but it's likely that item 2 and/or item 3 could be problematic.

 

BS1> Probably yes… This does require UTF-8 only, which is a starting point for narrowing, and excludes the item separator “|”. It is probably fair to also exclude null for compatibility. I would very much rather not try to define a (speculative) envelope of valid characters unless there is some strong justification from implementation. The reason being that we don’t know what future schemes might be or what their SSP patterns might need to look like. Another way of expressing this would be a new Ops Consideration subsection just for text form explaining that “Implementations SHALL handle the text form of EID Patterns as complete opaque text strings. They MUST NOT rely on specific characters to be present or absent from an encoded EID Pattern.”

### S2.4

* Some ADs like to ask that "SHOULD" and "SHOULD NOT" be accompanied by
  an explanation of the impact of violating the SHOULD/SHOULD NOT.

  I think in this case one consequence might be that a text to internal
  representation back to text cycle could produce logically equivalent
  but different text representations.

 

BS1> This makes sense and I agree with having an explanation. In this case I think it is as simple as “make it more clear for a human to read and understand it.”

### S2.4.3

* I think this was discussed at some point, but since the final
  paragraph says "[t]he canonical text form SHALL encode all intervals
  with the lower bound before the upper bound" do we need to keep the
  earlier relaxation that "decoders SHALL handle both possible orderings
  of interval bounds"?

  I guess this is really a question about the utility of non-canonical
  forms.

 

BS1> Similar to the last one, the canonical form is easier to read but I think the machine parsing should accept the alternate one.

## Nits

### S1

* "not be able to express of exact numeric ranges"

  Something awkward in here; I'm guessing a missing word/phrase?

### S2

* "an pattern-using" -> "a pattern-using"

### S7.1

* RFC 4632 is given as a Normative reference but my reading of where it's
  referenced in this document suggests it's actually Informative.

  Similarly, RFC 9525 seems mostly to be used to define analogous
  processing/interpretation and may also be Informative.

 

BS1> Yes I think these are just typos of which section they are in.

### S7.2

* RFC 5912 is used in a normative section (Appendix A) and should
  probably be in the Normative section.

 

BS1> There seems to be quite a mix of references both ways in https://datatracker.ietf.org/doc/rfc5912/referencedby/ and I don’t feel strongly either way so will defer to any consensus opinion in the WG or other reviewers (which at this point is one in favor of normative).

 

On Wed, Jun 10, 2026 at 12:24 PM Brian Sipos <[e-mail] <mailto:[e-mail]> > wrote:

All,

This small update of the EID Patterns draft expands a full Operational Considerations section to add to the enveloping explanations (which were already present in the previous version). This does not make any technical change to the document, but does add new interop topics under that section. There are no outstanding issues known on this draft.

 

Brian S.

 

On Wed, Jun 10, 2026 at 10:46 AM <[e-mail] <mailto:[e-mail]> > wrote:

Internet-Draft draft-ietf-dtn-eid-pattern-08.txt is now available. It is a
work item of the Delay/Disruption Tolerant Networking (DTN) WG of the IETF.

   Title:   Bundle Protocol Endpoint ID Patterns
   Author:  Brian Sipos
   Name:    draft-ietf-dtn-eid-pattern-08.txt
   Pages:   34
   Dates:   2026-06-10

Abstract:

   This document extends the Bundle Protocol Endpoint ID (EID) concept
   into an EID Pattern, which is used to categorize any EID as matching
   a specific pattern or not.  EID Patterns are suitable for expressing
   configuration, for being used on-the-wire by protocols, and for being
   easily understandable by a layperson.  EID Patterns include scheme-
   specific optimizations for expressing set membership and each scheme
   pattern includes text and binary encoding forms; the pattern for the
   "ipn" EID scheme being designed to be highly compressible in its
   binary form.  This document also defines a Public Key Infrastructure
   Using X.509 (PKIX) Other Name form to contain an EID Pattern and a
   handling rule to use a pattern to match an EID.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dtn-eid-pattern/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dtn-eid-pattern-08.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dtn-eid-pattern-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
dtn mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
dtn mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>