Subject: Re: IETF technical plenary: the end of application protocols

From: Henry Sinnreich <[email-masked]>
Date: Wed, 23 Mar 2011 15:52:28 -0500

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" <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Mar 2011 18:03:52 -0400

On Wed, Mar 23, 2011 at 4:52 PM, Henry Sinnreich
<[email-masked]>wrote:

>  It is really hard to avoid this discussion, but one cannot let such
> nonsense stand, especially in the IETF.
>

I have no idea which nonsense is being referred to of if it is actually
nonsense.

Remember the first law of the Internet: You are so not in charge (for all
values of 'you')

Web Services/Applications/Whatevers (WSAWs) are going to impact the
standards community through their sheer number and variety.

I expect the real problem we are going to see is people being turned away
from the standards process because there is just not time. People know the
costs/benefits of open network standards already.

Having deployed a successful proprietary protocol is already becoming a de
facto requirement for getting space in many standards organizations. Usually
the request is for either the IETF/W3C to take change control or for a
common protocol to be agreed from multiple deployed systems.

If we want to get a handle on this we need to look at the standards process
and make it easier to transition from proprietary to standard.

For example, every Web Service effort I have been in has had the same set of
arguments over use of XML, identifiers, SOAP etc. And every time we start
from scratch because we can't remember what the arguments were.

Another big problem in the Web Services world is discovery. The original
design for the SOAP scheme had UDDI as the central hub keeping the system
together. We lost that part because the design of UDDI started from the ever
popular 'we are going to replace the DNS'. Yeah, right, have fun with that.

In short, I think the IETF probably needs to forget being in the Web
Services Applications space completely, there is simply not the bandwidth
here and the structure of the IETF is just not set up to succeed there.

If I am designing a Web Service Application I am generally working with
10-100 people whose sole focus and interest is that one issue. They have
zero interest in a standards process where they will have F2F meetings three
times a year lasting one or two hours each. When we do that type of work we
want to meet for two days at a place convenient for that specific community
and work on the Web service we are working on and nothing else.

The IETF is set up for developing platforms and infrastructure, these
protocols are built on top of the platforms and infrastructure.

-- 
Website: http://hallambaker.com/