Re: IESG discussion of draft-ietf-opes-smtp-use-cases-03

[jfcm <info@xxxxxxxx>]

Martin,
As you note it IESG is discussing the SMTP use cases draft. There have
been some comments and the current status is "IESG Evaluation
- Defer". See

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12800&rfc_flag=0
. You reviewed some of the comments I agree with you. 

However you may guess that my position on Sam's comment is obviously
totally different. I think Sam is right. But I stick to my compromise:
the WG also follows more or less the IAB recommendations. The confusion
is with IAB. The IAB recommendations tris to protect the current
"mono-Internet" architecture when to support OPES, instead of
documenting a "multi-Internet" architecture (architectural
parameters switched from "mono" to "multi") actually
based upon OPES and killing the middlebox patch. 

The document Sam wants is therefore not to be asked to an Engineering WG
but to an Architectural team. There is no problem to write such a
document for the OPES case. But a global consistency is necessary and
this is where it becomes a problem, because it is a new Internet
version.

On can summarise it as:
                          
+------+
     +-------+__OCP Link __| ones |__ OCP optional
links __ +------+
end -| opes 
|            
+------+----+------+  +------+   | opes |- end
     +-------+ -------------- standard | opes |--|
smtp |-- +------+
                                      
+------+  +------+
Where ONES stands for my fancy pet Open Network(ed) Extended
Services, i.e. the services to the end to end relations (protocol and
content).  

This fully supports:
- the end to end principles
- the protocol on the wire
- the dumb network approach
and replaces middleboxes with the power of a _parallel_ specialised
protocol. Instead of using a single (mono-Internet) link the end to end
process only uses multiples (multi-Internet) links. To show this is not a
phenomena related to SMTP etc. but proper to OPES/ONES, the establishment
of the OCP link needs an IP address: it can be found via the standard DNS
using a dedicated ONES Class. The Domain Name being used _can_ be
multi-class.

- when using class IN it resolves the standard link path (here MX)
- when using class ONES it resolves the concerned ONES IP
address.

Sam is right. Another document is needed.
jfc