Re: IESG discussion of draft-ietf-opes-smtp-use-cases-03
jfcm <[email protected]> Tue, 20 Sep 2005 12:40:48 +0200
| Newsgroups | gmane.ietf.opes |
|---|---|
| Message-ID | <[email protected]> |
--=====================_36631473==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
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
--=====================_36631473==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
Martin,<br>
As you note it IESG is discussing the SMTP use cases draft. There have
been some comments and the current status is "IESG Evaluation<br>
- Defer". See
<a href="https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12800&rfc_flag=0" eudora="autourl">
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12800&rfc_flag=0</a>
. You reviewed some of the comments I agree with you. <br><br>
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. <br><br>
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.<br><br>
On can summarise it as:<br>
<font face="Courier, Courier">
+------+<br>
+-------+__OCP Link __| ones |__ OCP optional
links __ +------+<br>
end -| opes
|
+------+----+------+ +------+ | opes |- end<br>
+-------+ -------------- standard | opes |--|
smtp |-- +------+<br>
+------+ +------+<br>
</font>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). <br><br>
This fully supports:<br>
- the end to end principles<br>
- the protocol on the wire<br>
- the dumb network approach<br>
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.<br><br>
- when using class IN it resolves the standard link path (here MX)<br>
- when using class ONES it resolves the concerned ONES IP
address.<br><br>
Sam is right. Another document is needed.<br>
jfc<br>
</body>
</html>
--=====================_36631473==.ALT--