ietf-openproxy
[Top] [All Lists]

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

2005-09-20 09:55:16
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
<Prev in Thread] Current Thread [Next in Thread>