Subject: [codec] 3 week WGLC on draft-ietf-codec-requirements-02

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 22 Jan 2011 08:08:58 -0500

The authors believe that the requirements document is complete. The 
chairs would like to now issue a 3 week working group last call for 
draft-ietf-codec-requirements-02. At the end of 3 weeks, if no comments 
have been received, we will pass the document to the IESG for approval.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: "Christian Hoene" <[email-masked]>
Date: Sun, 23 Jan 2011 09:19:27 +0100

> The authors believe that the requirements document is complete. 

[Christian Hoene] Which authors? So far this document has only two selected
editors.

>The chairs
> would like to now issue a 3 week working group last call for
draft-ietf-codec-
> requirements-02. At the end of 3 weeks, if no comments have been
> received, we will pass the document to the IESG for approval.

[Christian Hoene] Despite hundreds of emails, what were exchanged on this
mailing list on issues regarding requirements, the editors have been
reluctant to update the requirements document according to the consensus
process on this mailing list. 

If I compare draft-ietf-codec-requirement-02 with
draft-valin-codec-requirements-02, I only see editorial changes.
https://tools.ietf.org/rfcdiff?url1=draft-ietf-codec-requirements-02&difftyp
e=--html&submit=Go!&url2=draft-valin-codec-requirements-02

Sorry guys, if I see this I become very cynical on the standardization
process at the IETF.   The editors have not done their job and the chairs do
not care. At the end, it all looks like rubberstamping with a little bit of
theater.

Christian

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 24 Jan 2011 13:49:58 -0500

Christian - perhaps you could post a list of the issues you see that haven't
been addressed?

Stephen Botzko

On Sun, Jan 23, 2011 at 3:19 AM, Christian Hoene <[email-masked]>wrote:

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 24 Jan 2011 21:10:35 +0100

[Christian Hoene] No Stephen, these issues have been written down in
previous emails, drafts and issues in the Trac. They can be read by anybody
anytime. Thus, I do not see any benefit of repeating them again if the
editors continue to ignore any input. Indeed, they did not improve the draft
despite sound technical reasons. 

Even if somebody is not fully involved in the technical details: It is very
odd that despite many hundreds emails and many discussions since starting
this WG the editors have not updated the draft beside minor changes such as
the boilerplate and typos. 

Even if the lack of any update was not intentionally, the editors missed to
do their job because they were too lazy or rather too busy doing other
thinks.

I would be sad if all the fruitful discussions here and all the good
contributions of many industry experts should have been in vain. Even if not
all requirements can be met by Opus, a proper requirements document may be
relevant for future solutions or other SDOs.

CH

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 24 Jan 2011 12:36:06 -0800

Hi Christian:
I can understand your frustration, and to some extent I share it.  However,
the purpose of a WGLC is to bring up issues that the editors have missed or
not acted upon.  So let's bring them up.

All:
The tracker is supposed to be one organized form of keeping issues alive and
make sure that they have been addressed adequately.  The tracker can be
found at http://trac.tools.ietf.org/wg/codec/trac/report.  I believe that
most requirements-related issues have been entered into the tracker in some
form, although, in order to see whether an issue has been addressed
according to the WG consensus or to get a full picture of all issues, one
would have to review the mailing list as well.  But the tracker is a good
starting point.

Thanks,
Stephan

From:  Christian Hoene <[email-masked]>
Organization:  Universitat Tubingen
Date:  Mon, 24 Jan 2011 21:10:35 +0100
To:  'Stephen Botzko' <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02

_______________________________________________ codec mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/codec

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 24 Jan 2011 18:08:38 -0500

Christian,

I actually responded to the last comments you made a while ago (oct 2010). 
One issue I pointed out was your use of RFC2119 keywords, which (AFAIK) 
aren't appropriate for a requirements draft (the requirements aren't a 
standard). So statements like "Any codec specified by the IETF MUST be well 
specified", besides stating the obvious, are inappropriate.

There were also comments that just did not belong to this draft, such as 
the section on collaboration with other WGs. Collaboration is not a 
characteristic of a codec. So essentially, I merged the uncontroversial 
suggestion, but that's all I could do. As far as I'm aware, there's nothing 
in the current draft that goes against the consensus of the WG. If there 
are, please point to specific issues and to statements made by others (not 
just you) asking for the change.

Cheers,

	Jean-Marc

On 11-01-24 03:10 PM, Christian Hoene wrote:
> Christian - perhaps you could post a list of the issues you see that
> haven't been addressed?
>
> */[Christian Hoene] No Stephen, these issues have been written down in
> editors continue to ignore any input. Indeed, they did not improve the
> draft despite sound technical reasons. /*
>
> */Even if somebody is not fully involved in the technical details: It is
> very odd that despite many hundreds emails and many discussions since
> starting this WG the editors have not updated the draft beside minor
> changes such as the boilerplate and typos. /*
>
> */Even if the lack of any update was not intentionally, the editors missed
> to do their job because they were too lazy or rather too busy doing other
> thinks./*
>
> */I would be sad if all the fruitful discussions here and all the good
> contributions of many industry experts should have been in vain. Even if
> not all requirements can be met by Opus, a proper requirements document may
> be relevant for future solutions or other SDOs./*
>
> */CH/*
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 24 Jan 2011 17:24:30 -0600

The document is currently specified as Standards Track, thus the use of RFC
2119 language is entirely appropriate.  However, ISTM that the document
should really just be Informational, in particular given the language in the
introduction that this document defines a "suggested process", as opposed to
a process that is required for codec development.

Regards,
Mary.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jan 2011 16:26:02 -0700

I agree with Mary here.

On 1/24/11 4:24 PM, Mary Barnes wrote:
> The document is currently specified as Standards Track, thus the use of
> RFC 2119 language is entirely appropriate.  However, ISTM that the
> document should really just be Informational, in particular given the
> language in the introduction that this document defines a "suggested
> process", as opposed to a process that is required for codec development.  
> 
> Regards,
> Mary.
> 
> On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Christian,
> 
>     I actually responded to the last comments you made a while ago (oct
>     2010). One issue I pointed out was your use of RFC2119 keywords,
>     which (AFAIK) aren't appropriate for a requirements draft (the
>     requirements aren't a standard). So statements like "Any codec
>     specified by the IETF MUST be well specified", besides stating the
>     obvious, are inappropriate.
> 
>     There were also comments that just did not belong to this draft,
>     such as the section on collaboration with other WGs. Collaboration
>     is not a characteristic of a codec. So essentially, I merged the
>     uncontroversial suggestion, but that's all I could do. As far as I'm
>     aware, there's nothing in the current draft that goes against the
>     consensus of the WG. If there are, please point to specific issues
>     and to statements made by others (not just you) asking for the change.
> 
>     Cheers,
> 
>            Jean-Marc
> 
> 
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 24 Jan 2011 18:27:08 -0500

Sorry, this was indeed intended to be informational (probably bad 
copy/paste). Let me fix that.

	Jean-Marc

On 11-01-24 06:26 PM, Peter Saint-Andre wrote:
>> <[email-masked]<mailto:[email-masked]>>  wrote:
>>
>>      Christian,
>>
>>          [email-masked]<mailto:[email-masked]>
>>      [email-masked]<mailto:[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Jan 2011 11:02:04 +0100

Mary,

I am confused which document we are talking about. The subject indicates the requirements document, but your quoted text "suggested process" seems to come from the guidelines document.

The situation with the requirements document (draft-ietf-codec-requirements-02) is that it is intended as Standards Track but contains no RFC 2119 language (as far as I can see, e.g., no "MUST" statements, and no reference to RFC 2119).

I think it should indeed be Informational, but this does not prevent us having normative statements in which the codec specification that this WG produces is the subject, e.g., "The codec MUST ..." This would make it much easier to pick out the actual requirements and to measure the resulting codec specification against those requirements. Some WGs adopt the practice of numbering requirements, for easy reference.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mary Barnes
> Sent: 24 January 2011 23:25
> To: Jean-Marc Valin
> Cc: [email-masked]; Stephen Botzko
> The document is currently specified as Standards Track, thus 
> the use of RFC 2119 language is entirely appropriate.  
> However, ISTM that the document should really just be 
> Informational, in particular given the language in the 
> introduction that this document defines a "suggested 
> <[email-masked]> wrote:
> 
> 
> 	Christian,
> 	
> 	I actually responded to the last comments you made a 
> while ago (oct 2010). One issue I pointed out was your use of 
> RFC2119 keywords, which (AFAIK) aren't appropriate for a 
> requirements draft (the requirements aren't a standard). So 
> statements like "Any codec specified by the IETF MUST be well 
> 	There were also comments that just did not belong to 
> this draft, such as the section on collaboration with other 
> WGs. Collaboration is not a characteristic of a codec. So 
> essentially, I merged the uncontroversial suggestion, but 
> that's all I could do. As far as I'm aware, there's nothing 
> in the current draft that goes against the consensus of the 
> WG. If there are, please point to specific issues and to 
> statements made by others (not just you) asking for the change.
> 	
> 	Cheers,
> 	
> 	       Jean-Marc 
> 
>

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 25 Jan 2011 14:12:54 +0100

Hi Jean-Marc Valin,

you are referring to the changes in the guideline doc? 

Thank you for considering my comments from October last year. I have to
admit that I have not read the latest version of the guidelines document so
far. I will give you updated comments (with any) well before the next
deadline.

With best regards,

 Christian 

> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2011 12:09 AM
> To: Christian Hoene
> Cc: 'Stephen Botzko'; [email-masked]
the
> section on collaboration with other WGs. Collaboration is not a
characteristic
> of a codec. So essentially, I merged the uncontroversial suggestion, but
that's
> all I could do. As far as I'm aware, there's nothing in the current draft
that
> goes against the consensus of the WG. If there are, please point to
specific
> issues and to statements made by others (not just you) asking for the
> change.
> 
> Cheers,
> 
> 	Jean-Marc
> 
> > previous emails, drafts and issues in the Trac. They can be read by
> > anybody anytime. Thus, I do not see any benefit of repeating them
> > again if the editors continue to ignore any input. Indeed, they did
> > not improve the draft despite sound technical reasons. /*
> >
> > */Even if somebody is not fully involved in the technical details: It
> > is very odd that despite many hundreds emails and many discussions
> > since starting this WG the editors have not updated the draft beside
> > minor changes such as the boilerplate and typos. /*
> >
> > */Even if the lack of any update was not intentionally, the editors
> > missed to do their job because they were too lazy or rather too busy
> > doing other
> > thinks./*
> >
> > contributions of many industry experts should have been in vain. Even
> > if not all requirements can be met by Opus, a proper requirements
> > document may be relevant for future solutions or other SDOs./*
> >
> > */CH/*
> >
> >
> >

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 25 Jan 2011 14:06:45 -0700

I followed up with Christian on a separate thread and I hope we will sort out whatever is needed to fix this document. 

I just want to say the chairs certainly want this document to reflect rough consensus of the WG. Please, help us get there - review this document and provide suggested text for any technical changes that you think need to be made to the draft. 

Thanks, Cullen <CODEC co-chair>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 25 Jan 2011 18:11:03 -0600

John,

Sorry for the confusion - yes the one document I noted was the guidelines.
(There was no link to the doc in the Last call announcement, so I went to WG
page and was looking at the other documents as well).

However, the same comment does apply to the requirements - i.e., it should
be informational. There is a perenniel debate as to whether RFC 2119
language applies to informational documents - the RFC 2119 abstract
references only standards track documents and notes that the language (i.e.,
the words in CAPS) should be used sparingly as required for interoperability
or to limit behavior that has the potential to cause problems.  I interpret
that to mean that it does not apply to requirements.

I agree with you that clearly enumerating requirements is a good idea and
should be standard practice.

Thanks,
Mary.

On Tue, Jan 25, 2011 at 4:02 AM, Elwell, John <
[email-masked]> wrote:

> Mary,
>
> I am confused which document we are talking about. The subject indicates
> the requirements document, but your quoted text "suggested process" seems to
> come from the guidelines document.
>
> The situation with the requirements document
> (draft-ietf-codec-requirements-02) is that it is intended as Standards Track
> but contains no RFC 2119 language (as far as I can see, e.g., no "MUST"
> statements, and no reference to RFC 2119).
>
> I think it should indeed be Informational, but this does not prevent us
> having normative statements in which the codec specification that this WG
> produces is the subject, e.g., "The codec MUST ..." This would make it much
> easier to pick out the actual requirements and to measure the resulting
> codec specification against those requirements. Some WGs adopt the practice
> of numbering requirements, for easy reference.
>
> John
>