Session Date/Time: 17 Oct 2023 14:00

SATP

Summary

The SATP Working Group held an interim meeting to discuss upcoming IETF 118 logistics, the schedule for future interim meetings, and receive an update from the Identification Design Team. The primary technical discussion focused on the Identification Design Team's proposal for a TLV-based network identification scheme, including its structure, types, length implications, and the trade-offs between machine-parseable identifiers and human-readable names. Ongoing work for all three SATP draft documents was also noted.

Key Discussion Points

IETF 118 and Interim Meeting Schedule
- The SATP WG meeting at IETF 118 in Prague is scheduled for Thursday at noon, a new time slot.
- Discussion about the utility of continuing interim meetings through winter break (December, January, February).
- A sense of those present indicated a preference for continuing interim meetings if they are useful for making progress.
- It was suggested that the readiness of the three existing draft documents for Last Call should be assessed at the Prague meeting, as this would influence the need for interims.
- The Co-chair and Claire agreed to schedule future interims with a policy to cancel if no agenda items are submitted.
- Prague IETF 118 Agenda: Topics proposed include a recap of outstanding issues with the three documents, an updated Identification Design Team report, a discussion on the timetable for concluding existing documents, and items potentially tabled for future rechartering.
Identification Design Team Report (Thomas)
- The design team held three independent meetings.
- Key Recognition: Any identification scheme must support systems that are not blockchain-based or DLT-based (e.g., traditional RTGS, monolithic databases).
- Goals/Requirements for Identification:
  - Internal identification of different paths in a ledger fork (e.g., via Genesis block).
  - Inclusion of the identifier in transactions for intended network targeting.
  - A method for legal claim or registration of a network to prevent numbering/technical conflicts.
- Proposed TLV-Based Model:
  - Structure: Type (8 bits) | Length (8 bits, specifies bytes) | Value (N bits, variable)
  - Initial Types Identified:
    - Type 1: Public Permissionless (DLT/Blockchain)
    - Type 2: Private Closed (DLT/Blockchain)
    - Type 3: Non-DLT (e.g., RTGS, monolithic database endpoint)
  - Value Field Options:
    - Option A: Direct 32-byte number (e.g., derived from draft-jang Genesis block hash).
    - Option B (Dennis's Suggestion): Humanly readable name followed by hex bytes (e.g., "ethereum rinkeby", then hex ID). Requires a separator.
- Discussion Points on TLV Model:
  - Wager:
    - Suggested pre-defining specific lengths for specific types (e.g., L=32 for a particular format, L=8 for EIP 155, L=1 for BIP 44) to guide parsing and make the identifier less open-ended.
    - Expressed concern about variable-length human-readable names in Option B causing parsing and storage issues (especially for hardware wallets).
    - Preferred Option A, emphasizing machine-parseable, fixed, unique, self-verifiable identities that can be mapped to human-readable names externally (like MAC addresses to DNS).
  - Wes:
    - Noted that the Type field should distinctly specify the format of the Value field for parsing.
    - Cautioned against overloading the Length field to also imply Type (e.g., "a length of 32 means a Genesis block format"). This would likely face strong pushback in IETF review.
    - Stressed the need for hashing agility: if a hash of a Genesis block is used, the scheme must allow for indicating the hashing algorithm (e.g., SHA256 vs. SHA3) to accommodate future changes if algorithms are broken.
  - Alexandre:
    - Counter-argued for Option B, suggesting that clients/routers would implement network ID lists as enums, making variable length less of an issue for parsing.
    - Also suggested storage might not be a major problem given modern hardware capabilities.
  - Rama: Questioned if a readable identifier needs to be inside the TLV, or if it could be a separate mapping.
  - Type Field Capacity: Confirmation that 7 bits (allowing for 128 types) provides sufficient room for future types beyond the initial three.
  - Length Field Necessity: Thomas argued for keeping the Length field as the Value portion might vary for future, unknown monolithic endpoints or other systems.
  - Applicability to All Types: Clarification sought on whether the 32-byte format (e.g., 16-byte Genesis block + other) is suitable for all identified types, including non-DLT. Wager suggested it could be adapted by defining a computed/defined identity for legacy databases.
DNS Use Case Discussion (Rama)
- Rama followed up on Victor's DNS use case, noting that it is currently incompletely defined and not ready for inclusion in the use case document.
- The Co-chair agreed to reach out to Victor to discuss refining the use case, recognizing its potential value for demonstrating protocol diversity.

Decisions and Action Items

Interim Meetings:
- Decision: Claire and the Co-chair will schedule future interim meetings.
- Action Item: Co-chair and Claire to communicate offline to set up interim meeting schedule, with a policy to cancel if no agenda items are submitted.
IETF 118 Prague Agenda:
- Decision: The Prague meeting will include discussions on the status of the three draft documents, the Identification Design Team report, a timetable for concluding existing documents, and potential future work items.
- Action Item: Working group members to submit any additional agenda topics for IETF 118 to the mailing list.
Identification Design Team:
- Decision: Continue work on the network identification scheme.
- Action Item: Design Team (Thomas, Wager, Alex, Rama, etc.) to address the raised concerns, including:
  - Clarity on how the Type field dictates the Value format.
  - Re-evaluating the necessity and interpretation of the Length field to avoid overloading.
  - Addressing hashing agility requirements for any cryptographic hash identifiers.
  - Further refining the applicability of the proposed format across all identified network types (DLT and non-DLT).
  - Deciding between Option A (machine-only ID) and Option B (human-readable + machine ID), or a strategy to combine them.
- Action Item: Design Team to aim for a more final presentation of their findings and proposals to the working group by IETF 119 (March).
DNS Use Case:
- Action Item: Co-chair to follow up with Victor regarding the need for further definition and clarity for the DNS use case before it can be incorporated into the use case document.

Next Steps

Working Group chairs will organize additional interim meetings as needed, with a flexible schedule.
The Identification Design Team will continue its work, focusing on resolving the detailed design questions raised, and prepare for a more comprehensive presentation at a future IETF meeting.
The Co-chair will engage with Victor to refine the DNS use case for potential future inclusion.
All working group members are encouraged to review the existing draft documents and prepare for discussions at IETF 118 in Prague.

Session Date/Time: 17 Oct 2023 14:00

SATP

Summary

Key Discussion Points

IETF 118 and Interim Meeting Schedule
- The SATP WG meeting at IETF 118 in Prague is scheduled for Thursday at noon, a new time slot.
- Discussion about the utility of continuing interim meetings through winter break (December, January, February).
- A sense of those present indicated a preference for continuing interim meetings if they are useful for making progress.
- It was suggested that the readiness of the three existing draft documents for Last Call should be assessed at the Prague meeting, as this would influence the need for interims.
- The Co-chair and Claire agreed to schedule future interims with a policy to cancel if no agenda items are submitted.
- Prague IETF 118 Agenda: Topics proposed include a recap of outstanding issues with the three documents, an updated Identification Design Team report, a discussion on the timetable for concluding existing documents, and items potentially tabled for future rechartering.
Identification Design Team Report (Thomas)
- The design team held three independent meetings.
- Key Recognition: Any identification scheme must support systems that are not blockchain-based or DLT-based (e.g., traditional RTGS, monolithic databases).
- Goals/Requirements for Identification:
  - Internal identification of different paths in a ledger fork (e.g., via Genesis block).
  - Inclusion of the identifier in transactions for intended network targeting.
  - A method for legal claim or registration of a network to prevent numbering/technical conflicts.
- Proposed TLV-Based Model:
  - Structure: Type (8 bits) | Length (8 bits, specifies bytes) | Value (N bits, variable)
  - Initial Types Identified:
    - Type 1: Public Permissionless (DLT/Blockchain)
    - Type 2: Private Closed (DLT/Blockchain)
    - Type 3: Non-DLT (e.g., RTGS, monolithic database endpoint)
  - Value Field Options:
    - Option A: Direct 32-byte number (e.g., derived from draft-jang Genesis block hash).
    - Option B (Dennis's Suggestion): Humanly readable name followed by hex bytes (e.g., "ethereum rinkeby", then hex ID). Requires a separator.
- Discussion Points on TLV Model:
  - Wager:
    - Suggested pre-defining specific lengths for specific types (e.g., L=32 for a particular format, L=8 for EIP 155, L=1 for BIP 44) to guide parsing and make the identifier less open-ended.
    - Expressed concern about variable-length human-readable names in Option B causing parsing and storage issues (especially for hardware wallets).
    - Preferred Option A, emphasizing machine-parseable, fixed, unique, self-verifiable identities that can be mapped to human-readable names externally (like MAC addresses to DNS).
  - Wes:
    - Noted that the Type field should distinctly specify the format of the Value field for parsing.
    - Cautioned against overloading the Length field to also imply Type (e.g., "a length of 32 means a Genesis block format"). This would likely face strong pushback in IETF review.
    - Stressed the need for hashing agility: if a hash of a Genesis block is used, the scheme must allow for indicating the hashing algorithm (e.g., SHA256 vs. SHA3) to accommodate future changes if algorithms are broken.
  - Alexandre:
    - Counter-argued for Option B, suggesting that clients/routers would implement network ID lists as enums, making variable length less of an issue for parsing.
    - Also suggested storage might not be a major problem given modern hardware capabilities.
  - Rama: Questioned if a readable identifier needs to be inside the TLV, or if it could be a separate mapping.
  - Type Field Capacity: Confirmation that 7 bits (allowing for 128 types) provides sufficient room for future types beyond the initial three.
  - Length Field Necessity: Thomas argued for keeping the Length field as the Value portion might vary for future, unknown monolithic endpoints or other systems.
  - Applicability to All Types: Clarification sought on whether the 32-byte format (e.g., 16-byte Genesis block + other) is suitable for all identified types, including non-DLT. Wager suggested it could be adapted by defining a computed/defined identity for legacy databases.
DNS Use Case Discussion (Rama)
- Rama followed up on Victor's DNS use case, noting that it is currently incompletely defined and not ready for inclusion in the use case document.
- The Co-chair agreed to reach out to Victor to discuss refining the use case, recognizing its potential value for demonstrating protocol diversity.

Decisions and Action Items

Interim Meetings:
- Decision: Claire and the Co-chair will schedule future interim meetings.
- Action Item: Co-chair and Claire to communicate offline to set up interim meeting schedule, with a policy to cancel if no agenda items are submitted.
IETF 118 Prague Agenda:
- Decision: The Prague meeting will include discussions on the status of the three draft documents, the Identification Design Team report, a timetable for concluding existing documents, and potential future work items.
- Action Item: Working group members to submit any additional agenda topics for IETF 118 to the mailing list.
Identification Design Team:
- Decision: Continue work on the network identification scheme.
- Action Item: Design Team (Thomas, Wager, Alex, Rama, etc.) to address the raised concerns, including:
  - Clarity on how the Type field dictates the Value format.
  - Re-evaluating the necessity and interpretation of the Length field to avoid overloading.
  - Addressing hashing agility requirements for any cryptographic hash identifiers.
  - Further refining the applicability of the proposed format across all identified network types (DLT and non-DLT).
  - Deciding between Option A (machine-only ID) and Option B (human-readable + machine ID), or a strategy to combine them.
- Action Item: Design Team to aim for a more final presentation of their findings and proposals to the working group by IETF 119 (March).
DNS Use Case:
- Action Item: Co-chair to follow up with Victor regarding the need for further definition and clarity for the DNS use case before it can be incorporated into the use case document.

Next Steps

Working Group chairs will organize additional interim meetings as needed, with a flexible schedule.
The Identification Design Team will continue its work, focusing on resolving the detailed design questions raised, and prepare for a more comprehensive presentation at a future IETF meeting.
The Co-chair will engage with Victor to refine the DNS use case for potential future inclusion.
All working group members are encouraged to review the existing draft documents and prepare for discussions at IETF 118 in Prague.

Session Date/Time: 17 Oct 2023 14:00

SATP

Summary

Key Discussion Points

IETF 118 and Interim Meeting Schedule
- The SATP WG meeting at IETF 118 in Prague is scheduled for Thursday at noon, a new time slot.
- Discussion about the utility of continuing interim meetings through winter break (December, January, February).
- A sense of those present indicated a preference for continuing interim meetings if they are useful for making progress.
- It was suggested that the readiness of the three existing draft documents for Last Call should be assessed at the Prague meeting, as this would influence the need for interims.
- The Co-chair and Claire agreed to schedule future interims with a policy to cancel if no agenda items are submitted.
- Prague IETF 118 Agenda: Topics proposed include a recap of outstanding issues with the three documents, an updated Identification Design Team report, a discussion on the timetable for concluding existing documents, and items potentially tabled for future rechartering.
Identification Design Team Report (Thomas)
- The design team held three independent meetings.
- Key Recognition: Any identification scheme must support systems that are not blockchain-based or DLT-based (e.g., traditional RTGS, monolithic databases).
- Goals/Requirements for Identification:
  - Internal identification of different paths in a ledger fork (e.g., via Genesis block).
  - Inclusion of the identifier in transactions for intended network targeting.
  - A method for legal claim or registration of a network to prevent numbering/technical conflicts.
- Proposed TLV-Based Model:
  - Structure: Type (8 bits) | Length (8 bits, specifies bytes) | Value (N bits, variable)
  - Initial Types Identified:
    - Type 1: Public Permissionless (DLT/Blockchain)
    - Type 2: Private Closed (DLT/Blockchain)
    - Type 3: Non-DLT (e.g., RTGS, monolithic database endpoint)
  - Value Field Options:
    - Option A: Direct 32-byte number (e.g., derived from draft-jang Genesis block hash).
    - Option B (Dennis's Suggestion): Humanly readable name followed by hex bytes (e.g., "ethereum rinkeby", then hex ID). Requires a separator.
- Discussion Points on TLV Model:
  - Wager:
    - Suggested pre-defining specific lengths for specific types (e.g., L=32 for a particular format, L=8 for EIP 155, L=1 for BIP 44) to guide parsing and make the identifier less open-ended.
    - Expressed concern about variable-length human-readable names in Option B causing parsing and storage issues (especially for hardware wallets).
    - Preferred Option A, emphasizing machine-parseable, fixed, unique, self-verifiable identities that can be mapped to human-readable names externally (like MAC addresses to DNS).
  - Wes:
    - Noted that the Type field should distinctly specify the format of the Value field for parsing.
    - Cautioned against overloading the Length field to also imply Type (e.g., "a length of 32 means a Genesis block format"). This would likely face strong pushback in IETF review.
    - Stressed the need for hashing agility: if a hash of a Genesis block is used, the scheme must allow for indicating the hashing algorithm (e.g., SHA256 vs. SHA3) to accommodate future changes if algorithms are broken.
  - Alexandre:
    - Counter-argued for Option B, suggesting that clients/routers would implement network ID lists as enums, making variable length less of an issue for parsing.
    - Also suggested storage might not be a major problem given modern hardware capabilities.
  - Rama: Questioned if a readable identifier needs to be inside the TLV, or if it could be a separate mapping.
  - Type Field Capacity: Confirmation that 7 bits (allowing for 128 types) provides sufficient room for future types beyond the initial three.
  - Length Field Necessity: Thomas argued for keeping the Length field as the Value portion might vary for future, unknown monolithic endpoints or other systems.
  - Applicability to All Types: Clarification sought on whether the 32-byte format (e.g., 16-byte Genesis block + other) is suitable for all identified types, including non-DLT. Wager suggested it could be adapted by defining a computed/defined identity for legacy databases.
DNS Use Case Discussion (Rama)
- Rama followed up on Victor's DNS use case, noting that it is currently incompletely defined and not ready for inclusion in the use case document.
- The Co-chair agreed to reach out to Victor to discuss refining the use case, recognizing its potential value for demonstrating protocol diversity.

Decisions and Action Items

Interim Meetings:
- Decision: Claire and the Co-chair will schedule future interim meetings.
- Action Item: Co-chair and Claire to communicate offline to set up interim meeting schedule, with a policy to cancel if no agenda items are submitted.
IETF 118 Prague Agenda:
- Decision: The Prague meeting will include discussions on the status of the three draft documents, the Identification Design Team report, a timetable for concluding existing documents, and potential future work items.
- Action Item: Working group members to submit any additional agenda topics for IETF 118 to the mailing list.
Identification Design Team:
- Decision: Continue work on the network identification scheme.
- Action Item: Design Team (Thomas, Wager, Alex, Rama, etc.) to address the raised concerns, including:
  - Clarity on how the Type field dictates the Value format.
  - Re-evaluating the necessity and interpretation of the Length field to avoid overloading.
  - Addressing hashing agility requirements for any cryptographic hash identifiers.
  - Further refining the applicability of the proposed format across all identified network types (DLT and non-DLT).
  - Deciding between Option A (machine-only ID) and Option B (human-readable + machine ID), or a strategy to combine them.
- Action Item: Design Team to aim for a more final presentation of their findings and proposals to the working group by IETF 119 (March).
DNS Use Case:
- Action Item: Co-chair to follow up with Victor regarding the need for further definition and clarity for the DNS use case before it can be incorporated into the use case document.

Next Steps

Working Group chairs will organize additional interim meetings as needed, with a flexible schedule.
The Identification Design Team will continue its work, focusing on resolving the detailed design questions raised, and prepare for a more comprehensive presentation at a future IETF meeting.
The Co-chair will engage with Victor to refine the DNS use case for potential future inclusion.
All working group members are encouraged to review the existing draft documents and prepare for discussions at IETF 118 in Prague.

Session Date/Time: 17 Oct 2023 14:00

SATP

Summary

Key Discussion Points

IETF 118 and Interim Meeting Schedule
- The SATP WG meeting at IETF 118 in Prague is scheduled for Thursday at noon, a new time slot.
- Discussion about the utility of continuing interim meetings through winter break (December, January, February).
- A sense of those present indicated a preference for continuing interim meetings if they are useful for making progress.
- It was suggested that the readiness of the three existing draft documents for Last Call should be assessed at the Prague meeting, as this would influence the need for interims.
- The Co-chair and Claire agreed to schedule future interims with a policy to cancel if no agenda items are submitted.
- Prague IETF 118 Agenda: Topics proposed include a recap of outstanding issues with the three documents, an updated Identification Design Team report, a discussion on the timetable for concluding existing documents, and items potentially tabled for future rechartering.
Identification Design Team Report (Thomas)
- The design team held three independent meetings.
- Key Recognition: Any identification scheme must support systems that are not blockchain-based or DLT-based (e.g., traditional RTGS, monolithic databases).
- Goals/Requirements for Identification:
  - Internal identification of different paths in a ledger fork (e.g., via Genesis block).
  - Inclusion of the identifier in transactions for intended network targeting.
  - A method for legal claim or registration of a network to prevent numbering/technical conflicts.
- Proposed TLV-Based Model:
  - Structure: Type (8 bits) | Length (8 bits, specifies bytes) | Value (N bits, variable)
  - Initial Types Identified:
    - Type 1: Public Permissionless (DLT/Blockchain)
    - Type 2: Private Closed (DLT/Blockchain)
    - Type 3: Non-DLT (e.g., RTGS, monolithic database endpoint)
  - Value Field Options:
    - Option A: Direct 32-byte number (e.g., derived from draft-jang Genesis block hash).
    - Option B (Dennis's Suggestion): Humanly readable name followed by hex bytes (e.g., "ethereum rinkeby", then hex ID). Requires a separator.
- Discussion Points on TLV Model:
  - Wager:
    - Suggested pre-defining specific lengths for specific types (e.g., L=32 for a particular format, L=8 for EIP 155, L=1 for BIP 44) to guide parsing and make the identifier less open-ended.
    - Expressed concern about variable-length human-readable names in Option B causing parsing and storage issues (especially for hardware wallets).
    - Preferred Option A, emphasizing machine-parseable, fixed, unique, self-verifiable identities that can be mapped to human-readable names externally (like MAC addresses to DNS).
  - Wes:
    - Noted that the Type field should distinctly specify the format of the Value field for parsing.
    - Cautioned against overloading the Length field to also imply Type (e.g., "a length of 32 means a Genesis block format"). This would likely face strong pushback in IETF review.
    - Stressed the need for hashing agility: if a hash of a Genesis block is used, the scheme must allow for indicating the hashing algorithm (e.g., SHA256 vs. SHA3) to accommodate future changes if algorithms are broken.
  - Alexandre:
    - Counter-argued for Option B, suggesting that clients/routers would implement network ID lists as enums, making variable length less of an issue for parsing.
    - Also suggested storage might not be a major problem given modern hardware capabilities.
  - Rama: Questioned if a readable identifier needs to be inside the TLV, or if it could be a separate mapping.
  - Type Field Capacity: Confirmation that 7 bits (allowing for 128 types) provides sufficient room for future types beyond the initial three.
  - Length Field Necessity: Thomas argued for keeping the Length field as the Value portion might vary for future, unknown monolithic endpoints or other systems.
  - Applicability to All Types: Clarification sought on whether the 32-byte format (e.g., 16-byte Genesis block + other) is suitable for all identified types, including non-DLT. Wager suggested it could be adapted by defining a computed/defined identity for legacy databases.
DNS Use Case Discussion (Rama)
- Rama followed up on Victor's DNS use case, noting that it is currently incompletely defined and not ready for inclusion in the use case document.
- The Co-chair agreed to reach out to Victor to discuss refining the use case, recognizing its potential value for demonstrating protocol diversity.

Decisions and Action Items

Interim Meetings:
- Decision: Claire and the Co-chair will schedule future interim meetings.
- Action Item: Co-chair and Claire to communicate offline to set up interim meeting schedule, with a policy to cancel if no agenda items are submitted.
IETF 118 Prague Agenda:
- Decision: The Prague meeting will include discussions on the status of the three draft documents, the Identification Design Team report, a timetable for concluding existing documents, and potential future work items.
- Action Item: Working group members to submit any additional agenda topics for IETF 118 to the mailing list.
Identification Design Team:
- Decision: Continue work on the network identification scheme.
- Action Item: Design Team (Thomas, Wager, Alex, Rama, etc.) to address the raised concerns, including:
  - Clarity on how the Type field dictates the Value format.
  - Re-evaluating the necessity and interpretation of the Length field to avoid overloading.
  - Addressing hashing agility requirements for any cryptographic hash identifiers.
  - Further refining the applicability of the proposed format across all identified network types (DLT and non-DLT).
  - Deciding between Option A (machine-only ID) and Option B (human-readable + machine ID), or a strategy to combine them.
- Action Item: Design Team to aim for a more final presentation of their findings and proposals to the working group by IETF 119 (March).
DNS Use Case:
- Action Item: Co-chair to follow up with Victor regarding the need for further definition and clarity for the DNS use case before it can be incorporated into the use case document.

Next Steps

Working Group chairs will organize additional interim meetings as needed, with a flexible schedule.
The Identification Design Team will continue its work, focusing on resolving the detailed design questions raised, and prepare for a more comprehensive presentation at a future IETF meeting.
The Co-chair will engage with Victor to refine the DNS use case for potential future inclusion.
All working group members are encouraged to review the existing draft documents and prepare for discussions at IETF 118 in Prague.

Session Date/Time: 17 Oct 2023 14:00

SATP

Summary

Key Discussion Points

IETF 118 and Interim Meeting Schedule
- The SATP WG meeting at IETF 118 in Prague is scheduled for Thursday at noon, a new time slot.
- Discussion about the utility of continuing interim meetings through winter break (December, January, February).
- A sense of those present indicated a preference for continuing interim meetings if they are useful for making progress.
- It was suggested that the readiness of the three existing draft documents for Last Call should be assessed at the Prague meeting, as this would influence the need for interims.
- The Co-chair and Claire agreed to schedule future interims with a policy to cancel if no agenda items are submitted.
- Prague IETF 118 Agenda: Topics proposed include a recap of outstanding issues with the three documents, an updated Identification Design Team report, a discussion on the timetable for concluding existing documents, and items potentially tabled for future rechartering.
Identification Design Team Report (Thomas)
- The design team held three independent meetings.
- Key Recognition: Any identification scheme must support systems that are not blockchain-based or DLT-based (e.g., traditional RTGS, monolithic databases).
- Goals/Requirements for Identification:
  - Internal identification of different paths in a ledger fork (e.g., via Genesis block).
  - Inclusion of the identifier in transactions for intended network targeting.
  - A method for legal claim or registration of a network to prevent numbering/technical conflicts.
- Proposed TLV-Based Model:
  - Structure: Type (8 bits) | Length (8 bits, specifies bytes) | Value (N bits, variable)
  - Initial Types Identified:
    - Type 1: Public Permissionless (DLT/Blockchain)
    - Type 2: Private Closed (DLT/Blockchain)
    - Type 3: Non-DLT (e.g., RTGS, monolithic database endpoint)
  - Value Field Options:
    - Option A: Direct 32-byte number (e.g., derived from draft-jang Genesis block hash).
    - Option B (Dennis's Suggestion): Humanly readable name followed by hex bytes (e.g., "ethereum rinkeby", then hex ID). Requires a separator.
- Discussion Points on TLV Model:
  - Wager:
    - Suggested pre-defining specific lengths for specific types (e.g., L=32 for a particular format, L=8 for EIP 155, L=1 for BIP 44) to guide parsing and make the identifier less open-ended.
    - Expressed concern about variable-length human-readable names in Option B causing parsing and storage issues (especially for hardware wallets).
    - Preferred Option A, emphasizing machine-parseable, fixed, unique, self-verifiable identities that can be mapped to human-readable names externally (like MAC addresses to DNS).
  - Wes:
    - Noted that the Type field should distinctly specify the format of the Value field for parsing.
    - Cautioned against overloading the Length field to also imply Type (e.g., "a length of 32 means a Genesis block format"). This would likely face strong pushback in IETF review.
    - Stressed the need for hashing agility: if a hash of a Genesis block is used, the scheme must allow for indicating the hashing algorithm (e.g., SHA256 vs. SHA3) to accommodate future changes if algorithms are broken.
  - Alexandre:
    - Counter-argued for Option B, suggesting that clients/routers would implement network ID lists as enums, making variable length less of an issue for parsing.
    - Also suggested storage might not be a major problem given modern hardware capabilities.
  - Rama: Questioned if a readable identifier needs to be inside the TLV, or if it could be a separate mapping.
  - Type Field Capacity: Confirmation that 7 bits (allowing for 128 types) provides sufficient room for future types beyond the initial three.
  - Length Field Necessity: Thomas argued for keeping the Length field as the Value portion might vary for future, unknown monolithic endpoints or other systems.
  - Applicability to All Types: Clarification sought on whether the 32-byte format (e.g., 16-byte Genesis block + other) is suitable for all identified types, including non-DLT. Wager suggested it could be adapted by defining a computed/defined identity for legacy databases.
DNS Use Case Discussion (Rama)
- Rama followed up on Victor's DNS use case, noting that it is currently incompletely defined and not ready for inclusion in the use case document.
- The Co-chair agreed to reach out to Victor to discuss refining the use case, recognizing its potential value for demonstrating protocol diversity.

Decisions and Action Items

Interim Meetings:
- Decision: Claire and the Co-chair will schedule future interim meetings.
- Action Item: Co-chair and Claire to communicate offline to set up interim meeting schedule, with a policy to cancel if no agenda items are submitted.
IETF 118 Prague Agenda:
- Decision: The Prague meeting will include discussions on the status of the three draft documents, the Identification Design Team report, a timetable for concluding existing documents, and potential future work items.
- Action Item: Working group members to submit any additional agenda topics for IETF 118 to the mailing list.
Identification Design Team:
- Decision: Continue work on the network identification scheme.
- Action Item: Design Team (Thomas, Wager, Alex, Rama, etc.) to address the raised concerns, including:
  - Clarity on how the Type field dictates the Value format.
  - Re-evaluating the necessity and interpretation of the Length field to avoid overloading.
  - Addressing hashing agility requirements for any cryptographic hash identifiers.
  - Further refining the applicability of the proposed format across all identified network types (DLT and non-DLT).
  - Deciding between Option A (machine-only ID) and Option B (human-readable + machine ID), or a strategy to combine them.
- Action Item: Design Team to aim for a more final presentation of their findings and proposals to the working group by IETF 119 (March).
DNS Use Case:
- Action Item: Co-chair to follow up with Victor regarding the need for further definition and clarity for the DNS use case before it can be incorporated into the use case document.

Next Steps

Working Group chairs will organize additional interim meetings as needed, with a flexible schedule.
The Identification Design Team will continue its work, focusing on resolving the detailed design questions raised, and prepare for a more comprehensive presentation at a future IETF meeting.
The Co-chair will engage with Victor to refine the DNS use case for potential future inclusion.
All working group members are encouraged to review the existing draft documents and prepare for discussions at IETF 118 in Prague.