Frank Ellermann wrote:
> Brian E Carpenter wrote:
>
>
>> That's my opinion; I'm not asserting that it's an IETF
>> consensus or that it necessarily applies to 2821bis.
>>
>
> +1
>
> Some things I'd consider:
>
> RFC 821 used foo.arpa and similar examples, and it won't
> surprise me if the a
John C Klensin wrote:
> (1) The tracker categories are a matter of IESG decisions, not
> of anything on which the community has ever reached consensus or
> been asked to do so (something I actually consider a good
> thing). The IESG can change them as needed. If the current
> state of the tool
Brian E Carpenter wrote:
> I think one can make a case that in some documents, use of non-RFC2606
> names as examples is a purely stylistic matter, and that in others,
> it would potentially cause technical confusion. I'm not asserting which
> applies to 2821bis, but I do assert that there is sco
Brian E Carpenter wrote:
> However, I'm arguing that
> there is scope on this particular point for concluding that there is
> a *technical* issue (a source of confusion, i.e. a lack of clarity).
If would be fascinating to see someone attempt to defend such a claim
seriously and with pragmat
Brian E Carpenter wrote:
> That's my opinion; I'm not asserting that it's an IETF
> consensus or that it necessarily applies to 2821bis.
+1
Some things I'd consider:
RFC 821 used foo.arpa and similar examples, and it won't
surprise me if the author knew precisely why this can
never have any und
Eric, Brian, and others...
Since this has turned into a general discussion about DISCUSS,
etc., a few comments. With regard to the specific appeal,
everyone should remember that, under our procedures, the focus
of an appeal in the first instance is "please reconsider this
and decide whether you r
Pete (and Dave Crocker),
On 2008-06-17 03:20, Pete Resnick wrote:
> On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
>
>> I think one can make a case that in some documents, use of non-RFC2606
>> names as examples is a purely stylistic matter, and that in others, it
>> would potentially cau
- Original Message -
From: "Robert Elz" <[EMAIL PROTECTED]>
To: "Brian E Carpenter" <[EMAIL PROTECTED]>
Cc: "John C Klensin" <[EMAIL PROTECTED]>; ;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, June 16, 2008 12:51 AM
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-kl
FYI - ALL of the commentary submitted to the IESG must be done so through a
process which includes it in the archive of that IP initiative or the IETF
will see itself in a world of hurt the first time it is litigated against
and it cannot produce documentation showing all of that material happen
Date:Mon, 16 Jun 2008 13:23:28 +1200
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Which, in fairness, the IESG has documented, in the DISCUSS criteria
| document and generally in practice, over the last several years.
The IESG is f
--On Saturday, 14 June, 2008 10:44 -0400 Eastlake III
Donald-LDE008 <[EMAIL PROTECTED]> wrote:
> Standards track RFC 4343 was issued within the past five years
> (January 2006 to be precise). It contains some example domain
> names that do not follow the suggestions in RFC 2606 as well
> as some
+1. Does "this is a discuss discuss question" mean that "I just want to
discuss this, it's a nit, don't worry" or does it mean "we ABSOLUTELY
MUST DISCUSS this and nothing's moving until we do!" Without other
context, you don't know.
Tony Hansen
[EMAIL PROTECTED]
Eric Gray wrot
On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
>I think one can make a case that in some documents, use of
>non-RFC2606 names as examples is a purely stylistic matter, and that
>in others, it would potentially cause technical confusion.
Please make that case if you would, because the ex
Brian,
As a matter of personal preference, I would very much
prefer not to see process constructions that require repeated
use of the status in order to disambiguate the meaning of the
status. In other words, having to clarify that a DISCUSS is
(really) a discuss (and presumably not som
14 matches
Mail list logo