[IPv6] Fwd: New Version Notification for draft-iurman-6man-carry-identifier-00.txt

[Justin Iurman <[e-mail]>]

Hello,

This draft replaces [I-D.draft-iurman-6man-generic-id] due to its last 
revision, which involved a title change.

The revision mainly includes the following changes, based on feedback 
received during our last meeting (diff [1]):
  - proposed solutions were renamed to something more explicit
  - pros & cons for each solution
  - IANA section: improve registry (reserved, unassigned and 
experimental code points); strengthen the validation condition for new 
allocation requests
  - some editorial changes

As a first attempt to strengthen the validation, the following paragraph 
was added to describe the additional condition:
""""
    For a new registration request to be accepted, its main purpose MUST
    be to carry an identifier. The aforementioned identifier MUST be the
    centerpiece of the new context.
""""

The goal is obviously to prevent all and nothing from being allocated in 
the registry. This is also why "IETF review" was preferred over FCFS.

Also, Michael mentioned that we might be able to reclaim 01/10/11 (act) 
code points for HBHs/DOs in the future, which would indeed prevent fast 
exhaustion (at least for now).

Regarding Michael's other comment about hardware: it's been listed in 
the cons for solution 2. However, compared to what 
[I-D.draft-ietf-6man-enhanced-vpn-vtn-id] proposes (as an example), I 
don't think it would make a huge difference to match on one or the other 
on the hardware side.

Feedback welcome, thanks!
-Justin

   [1] 
https://author-tools.ietf.org/iddiff?url1=draft-iurman-6man-generic-id-00&url2=draft-iurman-6man-carry-identifier-00&difftype=--html


-------- Forwarded Message --------
Subject: New Version Notification for 
draft-iurman-6man-carry-identifier-00.txt
Date: Wed, 08 Feb 2023 05:44:46 -0800
From: [e-mail]
To: Justin Iurman <[e-mail]>


A new version of I-D, draft-iurman-6man-carry-identifier-00.txt
has been successfully submitted by Justin Iurman and posted to the
IETF repository.

Name:		draft-iurman-6man-carry-identifier
Revision:	00
Title:		Carrying an Identifier in IPv6 packets
Document date:	2023-02-08
Group:		Individual Submission
Pages:		8
URL: 
https://www.ietf.org/archive/id/draft-iurman-6man-carry-identifier-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-iurman-6man-carry-identifier/
Html: 
https://www.ietf.org/archive/id/draft-iurman-6man-carry-identifier-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-iurman-6man-carry-identifier


Abstract:
    Some recent use cases have a need for carrying an identifier in IPv6
    packets.  While those drafts might perfectly make sense on their own,
    each document requires IANA to allocate a new code point for a new
    option, and so for very similar situations, which could quickly
    exhaust the allocation space if similar designs are proposed in the
    future.  As an example, one might need an 8-bit ID, while another one
    might need a 32-bit, 64-bit or 128-bit ID.  Or, even worse, one might
    need a 32-bit ID in a specific context, while someone else might also
    need a 32-bit ID in another context.  Therefore, allocating a new
    code point for each similar option is probably not the way to go.

 


The IETF Secretariat