Update to the ipn URI scheme
draft-ietf-dtn-ipn-update-13

# Orie Steele, ART AD, comments for draft-ietf-dtn-ipn-update-11 
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-11.txt&submitcheck=True

Thanks for Marco Tiloca for the ART ART Review, and to the authors for addressing his comments.

## Comments

### Cross domain private use

```
441	   Because of this lack of uniqueness, any implementation of a protocol
442	   using ipn URIs that resides on the border between administrative
443	   domains must have suitable mechanisms in place to prevent protocol
444	   units using such "Private Use" Node Numbers to cross between
445	   different administrative domains.
```

Should this "must" be normative MUST or SHOULD?

Later we see:

```
563	   administrative domain.  This means that any bundle using a Private
564	   Use ipn EID as a bundle source or bundle destination MUST NOT be
565	   allowed to cross administrative domains.  All implementations that
566	   could be deployed as a gateway between administrative domains MUST be
567	   sufficiently configurable to ensure that this is enforced, and
568	   operators MUST ensure correct configuration.

570	   Private Use ipn EIDs SHOULD NOT be present in any other part of a
571	   bundle that is destined for another administrative domain when the
572	   lack of uniqueness prevents correct operation.  For example, a
573	   Private Use ipn EID SHOULD NOT be used as a Bundle Protocol Security
574	   [RFC9172] security source EID for a bundle, when the bundle is
575	   destined for a different administrative domain.
```

Why not MUST, or when can this SHOULD be ignored.

### ! clarity 

```
472	   3.  If the Allocator Identifier is zero (0), and the Node Number is
473	       2^32-1, i.e., the URI is a LocalNode ipn URI (Section 3.4.2),
474	       then the character '!'  MAY be used instead of the digits
475	       4294967295, although both forms are valid encodings.
```

Can this be made a SHOULD? Is there really no preferred text encoding for this case?

### 538	5.4.  LocalNode ipn EIDs

```
550	   LocalNode ipn EIDs SHOULD NOT be present in any other part of a
551	   bundle that is transmitted off of the local node.  For example, a
552	   LocalNode ipn EID SHOULD NOT be used as a Bundle Protocol Security
553	   [RFC9172] security source EID for a bundle transmitted from the local
554	   bundle node, because such a source EID would have no meaning at a
555	   downstream bundle node.
```

Why not MUST NOT?


### Consider promoting examples from appendix for readability

```
659	   For example the ipn EID of ipn:977000.100.1 has an FQNN of
660	   (977000,100) which would be encoded as 0xEE86800000064.  The
661	   resulting two-element array [0xEE86800000064, 0x01] would be encoded
662	   in CBOR as the 11 octet value 0x821B000EE8680000006401.
```

Consider a commented hex representation of this value:

```
82                     # array(2)
   1B 000EE86800000064 # unsigned(4196183048192100)
   01                  # unsigned(1)
```

Same comment for the 3 element example that follows:

```
83             # array(3)
   1A 000EE868 # unsigned(977000)
   18 64       # unsigned(100)
   01          # unsigned(1)
```

I was initially expecting to see a tagged example based on:

```
618	   URI text string.  Alternatively, Section 3.4.5.3 of [RFC8949] allows
619	   for the encoding of URIs as CBOR text strings identified with a CBOR
620	   tag value of 32.
```

I think it might be worth recommending against the text encoded representation, similar to the recommendation:

```
689	   value zero (0).  In this case using the two-element encoding will
690	   result in a more concise CBOR representation, and it is RECOMMENDED
691	   that implementations do so.
```

### When SHOULD they?

```
817	   The concept of "late binding" is preserved in this ipn URI scheme.
818	   Elements of an ipn URI SHOULD NOT be regarded as carrying information
819	   relating to location, reachability, or other addressing/routing
820	   concern.
```

Consider making this a MUST?

### define limited expressiveness

```
858	   The limited expressiveness of URIs of the ipn scheme effectively
859	   eliminates the possibility of threat due to errors in back-end
860	   transcoding.
```

Do you mean that they lack path or query components?

Is there any backend transcoding that is expected here?


### convergence layer examples

```
879	   interception of these URIs is minimal.  Examination of ipn URIs could
880	   be used to support traffic analysis; where traffic analysis is a
881	   plausible danger, bundles should be conveyed by secure convergence-
882	   layer protocols that do not expose endpoint IDs.
```

Are there any protocols that could be recommended or provided as an example here?


### Is this sentence needed?

```
1064	   Services that are specific to a particular deployment or co-operation
1065	   may require a registry to reduce administrative burden, but do not
1066	   require an entry in this registry.
```

I don't understand why this is here, consider removing it.

## Nits

### DTNs expand on first use

```
157	   environments behind a shared administrative domain.  The growth in
158	   the number and scale of deployments of BPv7 DTNs has been accompanied
159	   by a growth in the usage of the ipn URI scheme which has highlighted
160	   areas to improve the structure, moderation, and management of this
161	   scheme.
```

### follow -> following

```
465	   To keep the text representation concise, the follow rules apply:
```

### is -> in

```
894	   IANA is requested to update the reference to the 'ipn' scheme is the
```

Thanks for working on this document.