[Ediint] Re: Document Structure Discussion Summary - draft-ietf-ediint-rfc4130bis-01

[Marc Blanchet <[e-mail]>]

> Le 12 juin 2026 à 02:47, Erik Wramner <[e-mail]> a écrit :
> 
> Marc, I feel that your comparison with DHCP is halting at best.

Comparisons are always not best...

> 
> Given that the new standard removes key pillars of the old, we are not talking about how to get an IP with or without manual configuration. A better example might be to try to communicate when one side is running only IPv6 and the other only IPv4 and you are trying to figure out how to make it work. Mandating that a product MUST use IPv6 in such a situation, but still be fully backwards compatible, is tricky and is more like what we are doing.

I was trying to illustrate the manual vs autodiscovery differences, not different protocols. A manual configuration does not have to be specified in an RFC, an auto-discovery mechanism has to. Full stop.

Marc.

> 
> -Erik
> 
> -----Original Message-----
> From: Marc Blanchet <[e-mail]> 
> Sent: Thursday, 11 June 2026 20:53
> To: Erik Wramner <[e-mail]>
> Cc: [e-mail]; [e-mail]; Debra Petta <[e-mail]>
> Subject: Re: Document Structure Discussion Summary - draft-ietf-ediint-rfc4130bis-01
> 
> 
> 
>> Le 5 juin 2026 à 03:15, Erik Wramner <[e-mail]> a écrit :
>> 
>> Hi,
>> I thought I should try to answer to the questions as well.
> 
> ...
> 
>> 3. What discovery or negotiation mechanisms would help implementations determine which algorithms a trading partner supports?
>> I’m in favor of adding a well-known configuration page for automatic 
>> detection,
> 
> Good. Then we shall define it. 
> 
> Our current AS2 setup with many partners is just a nightmare to manage, given the number of partners and that it is all done manually. This ecosystem should move to something more modern devops: a discovery mechanism is small step towards that.
> 
>> BUT I still think this will be done ahead of time manually based on written instructions most of the time. In the real world, there will always be partners with old products, so the onboarding process needs to support them… which means it will be manual.
> 
> Sure, that is a choice of a user. This has nothing to do with a protocol specification. For example, I can decide to statically configure my IP address on my computer or use DHCP. DHCP is the protocol and it has a specification. There is no IETF specification how to configure an IP address on my computer for my OS.
> 
> So there is no point in discussing a manual configuration, unless it has an impact on the protocol, which I don't think there is any.
> 
>> Making it smoother when both products implement the new standard would still be good.
>> 4. Should legacy-only implementations that don't support modern algorithms be expected to remain on RFC 4130, or should the new specification accommodate them normatively?
>> Given the discussions in the working group, I don’t think we have a choice. They need to remain on 4130. Which is not a bad thing, necessarily – if they don’t implement any of the new things, they are on the old version, which gives modern products an edge sales-wise.
> 
> An implementation is free to add all kinds of bells and whistles. The key discussion here is what is in the new protocol specification. 
> 
>> 5. Are there specific implementation or deployment scenarios we need to consider that haven't been addressed?
>> Not necessarily, but again I want to stress that most customers where AS/2 is important are likely to have many partners with a wide range of products, including homegrown and legacy. They are also likely to have at least some partners with strict firewalls, including content based, that can make automatic configuration more difficult. If upgrading means not being able to communicate with some of these partners, it is a no go. We really need to support legacy in a good way.
> 
> The discovery mechanism (hopefully) will be specified. If a user is not able to discover the info of its future partner through the discovery mechanism, then he will have to revert to some out of band communication. If there is no DHCP mechanism on a visiting network, then to properly access the network, I will need to contact the network manager to get an IP address/subnetmask/dns server IP address to get it running. That out of band process is not discussed in the DHCP specification.
> 
> Regards, Marc.
> 
>> -Erik
>> From: Debra Petta <[e-mail]>
>> Sent: Tuesday, 2 June 2026 16:03
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [Ediint] Document Structure Discussion Summary - 
>> draft-ietf-ediint-rfc4130bis-01  Dear EDIINT Working Group,  Thank you 
>> to everyone who attended yesterday's interim meeting to review the changes between version -00 and version -01 of draft-ietf-ediint-rfc4130bis.
>> With approximately 14 attendees, we had valuable discussion on the technical changes, but I want to bring the document structure question to the broader working group for input.
>> During the technical review, a fundamental question was raised about how we structure backward compatibility in the specification.
>> The issue is that our current approach defines both modern security requirements (SHA-256, TLS 1.3) AND legacy compatibility (SHA-1, 3DES, TLS 1.2) in the same normative sections, which creates ambiguity about what conformance means.
>> Three possible approaches were presented for discussion:
>> Option A: Clean Modern Spec with Non-Normative Legacy Appendix
>>    • Normative sections contain only modern requirements (SHA-256 MUST, 3DES forbidden)
>>    • Legacy interoperability guidance moves to a non-normative appendix
>>    • Clear specification, likely to pass IESG security review
>>    • May affect conformance status of legacy-only implementations  
>> Option B: Normative Legacy Support (Current Approach)
>>    • Normative sections include both modern AND legacy algorithms
>>    • SHA-256 MUST, SHA-1 MAY (deprecated), 3DES MAY (deprecated)
>>    • True backward compatibility, existing implementations remain conformant
>>    • May face IESG security review pushback, creates "two-tier" 
>> conformance  Option C: Two-Document Approach
>>    • Document 1: RFC4130bis with minimal errata/clarifications
>>    • Document 2: AS2 v2.0 as clean modern protocol with new version number
>>    • Cleanest separation of concerns
>>    • More work, longer timeline, potential adoption challenges  
>> Summary of Discussion Themes During yesterday's meeting, several 
>> important themes emerged:
>> 
>>    • Support for Modern Requirements: There was strong support for a specification with high cryptographic standards in the normative sections. Multiple participants expressed that SHA-1 should not appear in normative requirements, with concerns raised about whether "SHA-1 MAY" would pass IESG review.
>> 
>>    • Pragmatic Implementation Reality: Participants noted that real-world implementations will be pragmatic - they'll support both old and new algorithms regardless of what the specification says, because trading partner requirements demand it. The question is how the specification should document this reality.
>> 
>>    • Need for Transition Guidance: There was discussion about the need for normative text that clearly documents what implementations should do when choosing between old and new algorithms, including discovery mechanisms and transition strategies. The specification needs to provide clear guidance on how modern implementations interoperate with legacy partners.
>> 
>>    • Legacy System Path: Some discussion suggested that legacy systems that only support deprecated algorithms could remain on RFC 4130 rather than claiming conformance to the updated specification.
>> 
>>    • Convergence Toward Option A: While no formal consensus was reached, the discussion seemed to lean toward Option A (modern normative requirements with non-normative legacy guidance), with some interest in elements of Option C if the AS2 v1.3 specification can properly document how to support AS2 v1.2 interoperability.
>>  Request for Working Group Input
>> Given the limited attendance at yesterday's interim meeting, we need broader working group input on this fundamental document structure question.
>> This decision affects not just the current revision, but how we structure all future versions of the AS2 specification.
>> Please consider the following questions and share your perspective on the mailing list:
>> 1. Which document structure approach (A, B, or C) best serves the AS2 community?
>> 2. If we pursue Option A (modern normative requirements), what transition and interoperability guidance is essential to include in non-normative sections?
>> 3. What discovery or negotiation mechanisms would help implementations determine which algorithms a trading partner supports?
>> 4. Should legacy-only implementations that don't support modern algorithms be expected to remain on RFC 4130, or should the new specification accommodate them normatively?
>> 5. Are there specific implementation or deployment scenarios we need to consider that haven't been addressed?
>>  Next Steps
>> I'll plan to compile the mailing list feedback and, if we achieve rough consensus on an approach, prepare a document revision that reflects that consensus.
>> If there are divergent views that still need more discussion, we can schedule additional time at the next IETF meeting in July.
>> The presentation slides and the recording from yesterday's meeting 
>> are available at  
>> https://datatracker.ietf.org/meeting/interim-2026-ediint-03/session/ed
>> iint  for those who want to review the full technical changes in 
>> version -01 and this discussion.
>> Let me know if you have any questions or concerns about the document structure question or any other aspect of the draft.
>> Best regards,
>> Debra Petta
> 
>