It is really hard to avoid this discussion, but one cannot let such nonsense
stand, especially in the IETF.
With the work on SIP participants very early on realized that there are other
organizations interested in real-time communication.
....
This was not really seen as a problem given that a number of IETF participants
believe anyway that the
purpose of the standards development in the IETF is on "building blocks" that
can be used in many different architectures.
Internet protocols cannot be taken out of the Internet context, such as
open, e2e and more.
The long story of failures when trying to find alternatives starting from
(remember?) OSI to ATM, etc.
or perverting open Internet engineering for closed networks deserves at
least to be be told for the
Newcomer¹s Training, though no doubt books can be written about it.
Btw, even if my description is focused on the RTCWeb and the RAI area the
situation is not so different in other areas either.
See the work on QoS in the transport area.
Oops! Here comes QoS again. Why not add QoE since we are at it?
I am now wondering on what side you are really on.
Do you or do you not stand for the Internet architectural principles and for
the open e2e Internet and the Web?
This answer requires only one bit. At least in the IETF.
Thanks, Henry
On 3/23/11 5:35 AM, "Hannes Tschofenig"
<hannes(_dot_)tschofenig(_at_)nsn(_dot_)com> wrote:
Thank you for reading the draft.
Only a few minor notes below:
On Mar 23, 2011, at 9:01 AM, SM wrote:
The technical plenary could be moved to Friday. :-)
.... because many people leave early and so they wouldn't see the plenary :-)
Instead of an emergency course-correction, I suggest that the IAB publishes
its minutes.
We actually try our best...
In Section 2:
"This attitude is not particularly surprising given that many
standardization participants in the real-time communication area look
back to a regime that exactly follows a highly standardised eco-
system, namely the telecommunication business."
Does the IAB have an opinion about adopting such a model?
You need to quote the entire paragraph:
While many standardization efforts in the IETF have considered the
possibility for using proprietary protocols along the end host to
application service provider leg, this has usually been considered as
exception or a transition case. With few exceptions it was assumed
that the desired end state is to move from a proprietary protocol to
the standardized alternative in the long run, which allows client
software vendors to interact with all forms of application service
providers. Such an approach increases the need for standardization
considerably and requires far more interoperable network elements to
exist. This attitude is not particularly surprising given that many
standardization participants in the real-time communication area look
back to a regime that exactly follows a highly standardised eco-
system, namely the telecommunication business.
Two answers:
1) Architecture
I don't know if you have been working in the RAI area but let me summarize the
work there very briefly.
With the work on SIP participants very early on realized that there are other
organizations interested in real-time communication. These organizations, such
as 3GPP and OMA, decided to also use SIP but their architecture was different
to what most IETF people had in mind. This was not really seen as a problem
given that a number of IETF participants believe anyway that the purpose of
the standards development in the IETF is on "building blocks" that can be used
in many different architectures. While that's a great idea it does not always
work. There are cases where certain architectural choices demand specific
protocols to be defined that are pretty useless in other architectures. We
regularly ran into this issue when it came to security. The 3GPP IMS security
architecture, for example, is very different to the security architecture that
many IETF RAI participants would like to see.
If we now look at the architecture that is being brought forward in the RTCWeb
debate then you will notice that many of the protocol building blocks that
have been standardized are not really necessary. They may be used but it is
more likely that they will not.
So, you have to understand the background of where folks come from to
understand why a certain approach has been chosen.
Btw, even if my description is focused on the RTCWeb and the RAI area the
situation is not so different in other areas either. See the work on QoS in
the transport area.
What do we as draft authors want? In Section 4 of
draft-tschofenig-post-standardization-00 I collected a few questions I thought
would be useful to ask.
It is not about saying what other people in the IETF must do but rather to
initiate a thought process.
If you design a new protocol today you have a couple of design choices to
make. "Should my protocol run on top of HTTP/HTTPS?" may be one of the
questions you run into.
If you come to the conclusion that this Web stuff is not relevant to your
effort then that's perfectly fine. You have thought about it and you have
reasons why your own approach is more appropriate.
2) IAB's opinion
At the moment the IAB does not have a consensus on this topic. The document
you are referencing, draft-tschofenig-post-standardization-00, is an
individual submission (as the filename indicates).
We had discussions about these Web architectural topics in the IAB but since
this document has not been accepted as an IAB document (which would only mean
that the IAB indicates interest to work on the topic) it is a bit premature to
say what the opinion of the entire IAB could be. On top of that the Nomcom
selects IAB members in a way that they cover a wide range of expertise - not
everyone in the IAB is looking at the application or the real-time area.
Hence, it is fair to say that some IAB members do not yet have a (strong)
opinion about these Web related topics. There was, however, enough consensus
to schedule a plenary discussion about it.
I hope my response helps to clarify.
Ciao
Hannes
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf