On May 7, 2013, at 1:08 AM, SM s...@resistor.net wrote:
At 13:23 06-05-2013, Brian E Carpenter wrote:
I don't that is quite right. The problem in this case is not to do
with linguistic quality. It's due to a lack of formal verification
Quoting from the detective story:
At [censored] we
Hi Samuel,
the authors of this draft have reviewed it in order to address your
comments:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18
Could you please have a look at this revision and let them know whether
you are happy with it?
Thanks,
Gonzalo
On 04/02/2013 9:08 PM, Samuel Weiler
On 5/7/13 12:07 PM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
802 Parameters'
draft-eastlake-rfc5342bis-02.txt as Best Current Practice
Maybe things have changed, but, if one actually believes the
robustness principle, then, in the case Geoff cites, Exchange is
simply non-conforming -- not because the spec prohibits
rejecting on the basis of a fine distinction about IPv6 formats,
but because doing so is unnecessary,
--On Tuesday, May 07, 2013 08:08 -0700 Ned Freed
ned.fr...@mrochek.com wrote:
Maybe things have changed, but, if one actually believes the
robustness principle, then, in the case Geoff cites, Exchange
is simply non-conforming -- not because the spec prohibits
rejecting on the basis of a
On 08/05/2013 03:28, John C Klensin wrote:
...
I'll also point out that this has diddley-squat to do with
formal verification processes. Again as Mark Anrdrews points
out, we deployed something with a restriction that
subsequently turned out to be unnecessary, and now we're stuck
with it.
On 08/05/2013 03:28, John C Klensin wrote:
...
I'll also point out that this has diddley-squat to do with
formal verification processes. Again as Mark Anrdrews points
out, we deployed something with a restriction that
subsequently turned out to be unnecessary, and now we're stuck
with
On 5/2/13 4:58 PM, Dave Crocker wrote:
On 5/2/2013 3:25 PM, Jari Arkko wrote:
But the delay was really not my main concern. Primarily because I
think other issues such as transparency to the working group or late
surprises are more fundamental issues than mere timing. But also
because I
On 08/05/2013 08:33, Ned Freed wrote:
On 08/05/2013 03:28, John C Klensin wrote:
...
I'll also point out that this has diddley-squat to do with
formal verification processes. Again as Mark Anrdrews points
out, we deployed something with a restriction that
subsequently turned out to be
Hi -
From: Brian E Carpenter brian.e.carpen...@gmail.com
To: Ned Freed ned.fr...@mrochek.com
Cc: John C Klensin john-i...@jck.com; yaronf.i...@gmail.com;
ietf@ietf.org
Sent: Tuesday, May 07, 2013 2:19 PM
Subject: Re: Language editing
...
You are correct if only considering the mail
On 08/05/2013 08:33, Ned Freed wrote:
On 08/05/2013 03:28, John C Klensin wrote:
...
I'll also point out that this has diddley-squat to do with
formal verification processes. Again as Mark Anrdrews points
out, we deployed something with a restriction that
subsequently turned out to be
The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
802 Parameters'
draft-eastlake-rfc5342bis-02.txt as Best Current Practice
The IESG plans to make a decision in the next
The IESG has approved the following document:
- 'RTP Control Protocol(RTCP) Extended Report (XR) Block for Burst/Gap
Discard metric Reporting'
(draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14.txt) as Proposed
Standard
This document is the product of the Metric Blocks for use with RTCP's
13 matches
Mail list logo
