>
>
>
>Summary: This document is very close to ready for publication as a Proposed
>Standard. I have two technical comments below, but both are minor issues
>that could resolved in AUTH48 if you think they have merit.
An aside: The purpose of AUTH48 state is not (should not be) to resolve
even m
At 9:16 AM -0700 9/2/08, Bob Braden wrote:
>An aside: The purpose of AUTH48 state is not (should not be) to resolve
>even minor issues. Ideally, no issues should arise in AUTH48, but the
>world is not a perfect place. But let's not get in the habit of sweeping
>minor changes to the every end of t
OK...
>>Summary: This document is very close to ready for publication as a
>>Proposed
>>Standard. I have two technical comments below, but both are minor issues
>>that could resolved in AUTH48 if you think they have merit.
>
> An aside: The purpose of AUTH48 state is not (should not be) to resolv
--On Tuesday, 02 September, 2008 14:28 -0500 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:
> OK...
>
>>> Summary: This document is very close to ready for
>>> publication as a Proposed
>>> Standard. I have two technical comments below, but both are
>>> minor issues that could resolved in AUTH48 i
On Tue, 02 Sep 2008 16:48:43 -0400
John C Klensin <[EMAIL PROTECTED]> wrote:
> It occurs to me that people may have been saying "could be
> resolved in AUTH48" when they really meant "could be resolved in
> an RFC Editor note". While, like Paul, I tend to prefer that
> the RFC Editor get clean c
To John and Steve,
>> It occurs to me that people may have been saying "could be
>> resolved in AUTH48" when they really meant "could be resolved in
>> an RFC Editor note".
I would not be a bit surprised if I meant that ;-)
> Personally, I don't even like RFC Editor notes for things that can and
Steven M. Bellovin wrote:
> ...
> Personally, I don't even like RFC Editor notes for things that can and
> should be corrected by the author. As both an author and an AD, I much
> preferred clean new copies.
> ...
Absolutely.
The more edits need to be done in AUTH48, the more likely it is that
--On Tuesday, 02 September, 2008 16:08 -0500 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:
> To John and Steve,
>
>>> It occurs to me that people may have been saying "could be
>>> resolved in AUTH48" when they really meant "could be
>>> resolved in an RFC Editor note".
>
> I would not be a bit s
Essentially, this note is another me too.
On Sep 2, 2008, at 11:56 PM, John C Klensin wrote:
(iv) If that note is acceptable to the authors/ editors/
WG/ etc., generation of a document that incorporates the
changes. That version is, or is not, posted at the
dis
Olaf Kolkman rote:
> Personally I would like to see that whatever document enters into
> the RFC-Production function (to use the terminology from the RFC
> Editor model[*]) has a clean copy in the repository. That allows for
> a very clean interface between the streams and the RFC-producer. So,
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, September 03, 2008 3:03 PM
> To: [EMAIL PROTECTED]
> Cc: ietf@ietf.org
> Subject: RE: Gen-ART Review of draft-ietf-forces-mib-07
&
[EMAIL PROTECTED] wrote:
> Olaf Kolkman rote:
>
>> Personally I would like to see that whatever document enters into
>> the RFC-Production function (to use the terminology from the RFC
>> Editor model[*]) has a clean copy in the repository. That allows for
>> a very clean interface between the str
At 2:09 PM +0200 9/3/08, Julian Reschke wrote:
>I'm tempted to say that if it takes the authors months to update the
>document with the suggested change, then, well, a publication delay of
>several months is what they deserve :-).
+1
Given that the great majority of documents in the "authors are
Hi, Robert,
Thanks for the quick response on all the comments - to be explicit, version 8
addresses all my comments, except for one question (below).
It actually could be OK to retain the OtherMsg name and definition, if there is
a reason to do so (one reason might be "deployed systems use this
Julian Reschke wrote:
> I'm tempted to say that if it takes the authors months to update the
> document with the suggested change, then, well, a publication delay of
> several months is what they deserve :-).
The only problem with this comment is that some readers might think the smiley
mean
Dave CROCKER wrote:
>
>
> Julian Reschke wrote:
>> I'm tempted to say that if it takes the authors months to update the
>> document with the suggested change, then, well, a publication delay of
>> several months is what they deserve :-).
>
>
> The only problem with this comment is that some r
Spencer, thanks for the comments. See below for the details. I reissued a
draft with the editorial changes:
http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-08.txt
Regards,
-Robert
"Spencer Dawkins" <[EMAIL PROTECTED]> wrote on 09/01/2008 04:07:03
PM:
>
> Gen-ART Review of draft-ietf
r 09, 2008 8:47 AM
Subject: Re: Gen-ART Review of draft-ietf-forces-mib-07
Hi Spencer,
I released a new version of the draft to change to ZeroBasedCounters and
took the opportunity to rename the counters as you suggested. Now they are
called *Oper* instead of *Other*:
http://www.ietf.org/inter
wkins" <[EMAIL PROTECTED]> wrote on 09/03/2008 05:02:54
PM:
> [image removed]
>
> Re: Gen-ART Review of draft-ietf-forces-mib-07
>
> Spencer Dawkins
>
> to:
>
> Robert Haas
>
> 09/03/2008 05:06 PM
>
> Cc:
>
> "Patrick Droz"
19 matches
Mail list logo
