Hi,

I am an assigned INT directorate reviewer for draft-ietf-dtn-ipn-update-11.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as NO OBJECTION.

The following are other issues I found with this document that SHOULD be corrected/clarified before publication:

3.2.  Allocator Identifiers

<snip>

   If a system does not require interoperable deployment of ipn scheme
   URIs, then the Private Use Node Number range, reserved by the Default
   Allocator (Section 3.2.2) for this purpose SHOULD be used.

<JMC>
IMHO, it should be clearer (1) to have a reference to Section 3.4.3 instead to Section 3.2.2 and (2) to add the following information in text:
- Allocator Identifier SHOULD be set to zero (0)
- Node Number SHOULD be in the “Private Use” range (cf. Section 9.2)
</JMC>

<snip>

3.2.1.  Allocator Identifier Ranges

<snip>

With these assignments, any Allocator Identifier whose most-
   significant 25 bits match 0xEE000 belong to organization A.
   Similarly, any Allocator Identifier whose most-significant 28 bits
   match 0xEE080 belong to organization B, and any Allocator Identifier
   whose most-significant 31 bits are 0xEE090 belong to organization C.
   Organisation D has a single Allocator Identifier, and hence a range
   of bit-length 0.

<JMC>
Sorry, but I don’t understand how you get 25 bits for organization A, 28 bits for organization B and 31 bits for organization B. Is it possible to provide a formula, please?
By the way, are you assuming that Allocator Identifier is based on 32 bits?
</JMC>

<snip>

3.4.  Special Node Numbers

   Some special-case Node Numbers are defined by the Default Allocator,
   see 'ipn' Scheme URI Default Allocator Node Numbers registry
   (Section 9.2).

<JMC>
It seems that you assume that there will no need of special-case node numbers, except for the Default Allocator, in the future: is it correct?
If so, is it not dangerous (i.e., complexity to come back from such a decision)?
</JMC>

<snip>

5.5.  Private Use ipn EIDs

   Bundles destined for EIDs that use an ipn URI with a Fully-qualified
   Node Number (Section 3.3.1) that is within the "Private Use" range of
   the Default Allocator (Section 3.2.2) are not universally unique, and
   therefore are only valid within the scope of the current
   administrative domain.  This means that any bundle using a Private
   Use ipn EID as a bundle source or bundle destination MUST NOT be
   allowed to cross administrative domains.  All implementations that
   could be deployed as a gateway between administrative domains MUST be
   sufficiently configurable to ensure that this is enforced, and
   operators MUST ensure correct configuration.

<JMC>
IMHO, “MUST” use may be too strong: it is possible that 2 administrative domains (e.g., two affiliates in a same company) agree to use ipn URI in the “Private Use” range and to choose different subsets of this last one to ensure uniqueness.
</JMC>

<snip>

8.2.  Malicious construction

   Malicious construction of a conformant ipn URI is limited to the
   malicious selection of Allocator Identifiers, Node Numbers, and
   Service Numbers.  That is, a maliciously constructed ipn EID could be
   used to direct a bundle to an endpoint that might be damaged by the
   arrival of that bundle or, alternatively, to declare a false source
   for a bundle and thereby cause incorrect processing at a node that
   receives the bundle.  In both cases (and indeed in all bundle
   processing), the node that receives a bundle should verify its
   authenticity and validity before operating on it in any way.

<JMC>
There is no reference to any security mechanism to prevent such a threat: no security mechanism – equivalent to IP anti-spoofing, exists regarding this threat?
</JMC>

Thanks in advance for your reply.

Best regards,

JMC.