Subject: [rtcweb] Call for comment on document split

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Jun 2011 21:30:50 -0700

Hi Folks,

In order to allow folks time to submit draft-ietf-rtcweb versions in time
for the upcoming 00 deadline, the chairs would like to first outline our
theory of the document splits to meet our chartered milestones (to refresh
you self on them: http://datatracker.ietf.org/wg/rtcweb/charter/) in the
August time frame.

We'd like to have one document which describes the use cases.
We'd like to have one document that gives a system overview and outlines the
overall model.
We'd like to have one document that describes the privacy and security
model.
We'd like to have one document that  describes the connectivity model (for
NAT traversal etc.).

Later documents will be: signaling and negotiation methods, media
transports, datagram transport for non-media data, and one or more documents
on media processing and codecs.

Note that this set of "documents we'd like" is missing one that says
"requirements".  Discussion among the chairs has come to consensus that we
have at least three different kinds of requirements being discussed and the
the use of the term "requirement" is hindering both our internal discussion
and the balance of work between us and the W3C at the moment.  So, we'd like
to have the focus be on what the parts of the system *do* within the context
of a system overview, rather than on a discussion of requirements or, even
worse, a meta discussion of what the word "requirements" means in particular
contexts.

If folks our okay with this document set, the chairs will then appoint
editors from among those who have contributed text so far.  This may mean
that the initial -00 versions have a strong resemblance to the individual
submissions they'd already presented; it also may not.  We'd like to remind
everyone that taking on the role of document editor in an IETF context means
accepting the responsibility to make the document reflect the consensus of
the group.  If a WG -00 is missing items or needs revision to meet the needs
of the group, in other words, that's normal--send text.

Ted, Magnus, and Cullen

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 16 Jun 2011 22:21:21 -0700

On 6/16/2011 9:30 PM, Ted Hardie wrote:
> We'd like to have one document that describes the privacy and security model.
> We'd like to have one document that  describes the connectivity model (for NAT
> traversal etc.).
>
> Later documents will be: signaling and negotiation methods, media transports,
> datagram transport for non-media data, and one or more documents on media
> processing and codecs.

If someone wants to implement the simplest, core capability that is useful 
within this context of service, how many docs are they going to have to read?

Which ones? How long before they will be written?

For classic Web, I think it is still just 2.  Same for email.

My question is motivated by the usual concern about barriers to adoption that 
can stymie new services.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2011 09:15:56 +0200

Hi,

I think the proposed document split looks very good.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 17. kesäkuuta 2011 7:31
To: [email-masked]
Subject: [rtcweb] Call for comment on document split

Hi Folks,

In order to allow folks time to submit draft-ietf-rtcweb versions in time for the upcoming 00 deadline, the chairs would like to first outline our theory of the document splits to meet our chartered milestones (to refresh you self on them: http://datatracker.ietf.org/wg/rtcweb/charter/) in the August time frame.

We'd like to have one document which describes the use cases.
We'd like to have one document that gives a system overview and outlines the overall model.
We'd like to have one document that describes the privacy and security model.
We'd like to have one document that  describes the connectivity model (for NAT traversal etc.).

Later documents will be: signaling and negotiation methods, media transports, datagram transport for non-media data, and one or more documents on media processing and codecs.

Note that this set of "documents we'd like" is missing one that says "requirements".  Discussion among the chairs has come to consensus that we have at least three different kinds of requirements being discussed and the the use of the term "requirement" is hindering both our internal discussion and the balance of work between us and the W3C at the moment.  So, we'd like to have the focus be on what the parts of the system *do* within the context of a system overview, rather than on a discussion of requirements or, even worse, a meta discussion of what the word "requirements" means in particular contexts.

If folks our okay with this document set, the chairs will then appoint editors from among those who have contributed text so far.  This may mean that the initial -00 versions have a strong resemblance to the individual submissions they'd already presented; it also may not.  We'd like to remind everyone that taking on the role of document editor in an IETF context means accepting the responsibility to make the document reflect the consensus of the group.  If a WG -00 is missing items or needs revision to meet the needs of the group, in other words, that's normal--send text.

Ted, Magnus, and Cullen

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Jun 2011 09:55:37 +0200

> within this context of service, how many docs are they going to have to read?

That will likely be the full set of standards track documents, and the
overview to know how they fit together

> Which ones? How long before they will be written?

The point of getting them written is exactly why we have this split. We
try to distribute the editing load over a number of people and people
expertise to get high quality documents.

> My question is motivated by the usual concern about barriers to adoption that 

Well, RTCWEB is primarily umbrella standardization. Something we rarely
do in IETF. This is actually about gluing together some 20-30 or more
specifications into a service.

Thus I think comparing it with basic HTTP service is not that relevant,
which by the way still requires you to read a bit more than 2 specs.
Even if I assume you have a working TCP/IP with DNS system to build on,
you still need the HTTP, the URI, the MIME spec and likely a few small
pieces more before you even can fetch an referenced object.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Jun 2011 11:11:38 -0600

On Jun 16, 2011, at 11:21 PM, Dave CROCKER wrote:

> 
> 
> If someone wants to implement the simplest, core capability that is useful within this context of service, how many docs are they going to have to read?

Just as a random guess, probably around 20 to 50. This is a bit more complicated that email. There's not consensus on what the set would be yet but I would guess that in the end we will end up with a list of docs a browser would need to implement (beyond what they already implement) that is roughly along the lines of:  the docs on RTP, SRTP and various keying approach, various audio and video codecs, various offer answer schemes, the whole ICE family of docs including STUN and TURN families, a bunch of docs on SDP and various offer answer schemes.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Jun 2011 11:13:02 -0600

> Later documents will be: signaling and negotiation methods, media transports, datagram transport for non-media data, and one or more documents on media processing and codecs.

With my individual contributor hat on ... 

I don't see the reason to wait for "later" on these other docs.  I think some of them are as ready now as the connectivity model stuff is. Let's get moving with this stuff.

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 17 Jun 2011 13:14:22 -0400

Ted,

I think the proposed split is well in line with the Internet 
Architecture principle, "Modularity is always good."

It is well thought through.

Igor

On 6/17/2011 12:30 AM, Ted Hardie wrote:
> Hi Folks,
>
> In order to allow folks time to submit draft-ietf-rtcweb versions in 
> time for the upcoming 00 deadline, the chairs would like to first 
> outline our theory of the document splits to meet our chartered 
> milestones (to refresh you self on them: 
> http://datatracker.ietf.org/wg/rtcweb/charter/) in the August time frame.
>
> transports, datagram transport for non-media data, and one or more 
> documents on media processing and codecs.
>
> "requirements".  Discussion among the chairs has come to consensus 
> that we have at least three different kinds of requirements being 
> discussed and the the use of the term "requirement" is hindering both 
> our internal discussion and the balance of work between us and the W3C 
> at the moment.  So, we'd like to have the focus be on what the parts 
> of the system *do* within the context of a system overview, rather 
> than on a discussion of requirements or, even worse, a meta discussion 
> of what the word "requirements" means in particular contexts.
>
> editors from among those who have contributed text so far.  This may 
> mean that the initial -00 versions have a strong resemblance to the 
> individual submissions they'd already presented; it also may not. 
>  We'd like to remind everyone that taking on the role of document 
> editor in an IETF context means accepting the responsibility to make 
> the document reflect the consensus of the group.  If a WG -00 is 
> missing items or needs revision to meet the needs of the group, in 
> other words, that's normal--send text.
>
> Ted, Magnus, and Cullen
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 17 Jun 2011 13:24:35 -0400

I share the concern, but yet no matter how humble the beginning was 
(e.g., SIP), things ended up with far too many specifications for anyone 
to grasp (e.g., ...SIP).  don't think we will get away with two 
specifications no matter what (but I am a registered pessimist).I

This is why I think that modularity thought through in the beginning 
(vs. ad-hoc additions) will ensure order in the future.  In addition, 
with the controlled break-up, we could know in advance whether (and how) 
change in one document would affect others.

It is true though that a short Informational describing the structure of 
the project and references to other documents would be helpful.

Igor

On 6/17/2011 1:21 AM, Dave CROCKER wrote:
>> transports,
> If someone wants to implement the simplest, core capability that is 
> useful within this context of service, how many docs are they going to 
> have to read?
>
> My question is motivated by the usual concern about barriers to 
> adoption that can stymie new services.
>
> d/

---

From: Kundan Singh <[email-masked]>
Date: Fri, 17 Jun 2011 12:47:47 -0700 (PDT)

From a software developer's point of view, I feel the following will be most productive:

1. One or two complete document that are necessary and sufficient to implement RTC-Web/WebRTC. 
Everything else that is not covered by this document must be an existing popular standard with existing popular libraries/APIs.

2. Create the documents based on actual implementation, rather than the reverse. 

Perhaps include pseudo-code in Internet drafts to avoid ambiguity.

If interaction with external standards are needed, pseudo-code could show how it is done based on interfaces of existing popular libraries/APIs for that external standard.

Having to read and implement many documents to do one thing  is a recipe for disaster, e.g., (non) interoperability matrix, frustration, ...

If we manage to create tens of documents that cover all corner cases, all features, all authors, all existing extensions, but scare away actual developers, then we haven't learned from our mistakes...

Just a thought.

--
Kundan Singh

----- Original Message -----
> From: Igor Faynberg <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, June 17, 2011 10:24 AM
> Subject: Re: [rtcweb] Call for comment on document split
> 
> I share the concern, but yet no matter how humble the beginning was (e.g., SIP), 
> things ended up with far too many specifications for anyone to grasp (e.g., 
> ...SIP).  don't think we will get away with two specifications no matter 
> what (but I am a registered pessimist).I
> 
> This is why I think that modularity thought through in the beginning (vs. ad-hoc 
> additions) will ensure order in the future.  In addition, with the controlled 
> break-up, we could know in advance whether (and how) change in one document 
> would affect others.
> 
> It is true though that a short Informational describing the structure of the 
> project and references to other documents would be helpful.
> 
> Igor
> 
>>  My question is motivated by the usual concern about barriers to adoption 
> that can stymie new services.
>> 
>>  d/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 17 Jun 2011 13:11:44 -0700

As a software developer myself, I believe that this approach is wrong.  The goal
of the IETF is to make the Internet work better, not to make the developers life
better.

Implementers should contribute running code to help the IETF make the Internet
work better, by having multiple implementations of the same protocol and find
any interoperability, security and extensibility issue as soon as possible.
Documenting one implementation as protocol creates monoculture, and everybody
should know better by now than encouraging this.

And BTW, I do not think that "scaring away" developers is a bad thing.

> If we manage to create tens of documents that cover all corner cases, all features, all authors, all existing extensions, but scare away actual developers, then we haven't learned from our mistakes…

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org