>>>>> "Richard" == Richard Barnes writes:
Richard> The security considerations in this document are difficult
Richard> to evaluate because the general architecture is unclear to
Richard> me, e.g., who attaches these names to things and who reads
> "Richard" == Richard Barnes writes:
Richard> I have reviewed this document as part of the security
Richard> directorate's ongoing effort to review all IETF documents
Richard> being processed by the IESG. These comments were written
Richard> primarily for the benefit of the
to me, e.g., who attaches these names to
things and who reads them. (The naming scheme itself seems well defined.) The
text that causes me concern is the following:
"
These names MUST NOT be used for attributes issued by a party other than one
closely associated with the source of credenti
tf.org [mailto:ietf-boun...@ietf.org] On Behalf Of "Martin
J. Dürst"
Sent: Montag, 2. Juli 2012 13:07
To: Stephen Farrell
Cc: Graham Klyne; ietf@ietf.org
Subject: Re: Last Call: (Naming Things with
Hashes) to Proposed Standard
Hello Stephen,
On 2012/06/26 20:26, Stephen Farrell wrote:
Hi Martin,
On 07/02/2012 12:07 PM, "Martin J. Dürst" wrote:
> Hello Stephen,
>
> On 2012/06/26 20:26, Stephen Farrell wrote:
>>
>> Hi again Martin,
>>
>> On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
>>> So the question is really, what's the use case, and what's just a
>>> consequence of that
Hello Stephen,
On 2012/06/26 20:26, Stephen Farrell wrote:
Hi again Martin,
On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
So the question is really, what's the use case, and what's just a
consequence of that use case. If confirmation of already available
resources (e.g. like a fingerprint)
Hi Stephen,
At 14:20 22-06-2012, Stephen Farrell wrote:
The issues raised but not so far obviously resolved on the
list were I think:
1) inclusion of content type
2) nih as a URI scheme or not
[snip]
For (2) we've left nih in as a URI scheme in this version.
We're still in favour of keeping
Hi again Martin,
On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
> So the question is really, what's the use case, and what's just a
> consequence of that use case. If confirmation of already available
> resources (e.g. like a fingerprint) is the (main?) use case, and the
> greater weight on "sp
Hello Stephen,
On 2012/06/25 21:05, Stephen Farrell wrote:
On 06/25/2012 11:35 AM, "Martin J. Dürst" wrote:
Unfortunately, what I find is the following:
The justification for using a URI scheme for this is that that might
help a user agent for the speaker to better display the value, or
pe
heck-digit,
>> which'd be plain odd IMO, the uri scheme is the right idea
>> really:-)
>>
>> Please let me know if I've missed addressing anything else
>> or if you have any other comments.
>>
>> Cheers,
>> S.
>>
>> [1] http://tools.i
[1] http://tools.ietf.org/html/draft-farrell-decade-ni
[2] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params
(Note: only [1] is in IETF LC...just in case someone's
confused about that:-)
On 06/04/2012 03:18 PM, The IESG wrote:
The IESG has received a request from an individu
:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Naming Things with Hashes'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Ple
On Fri, Jun 8, 2012 at 9:45 PM, Stephen Farrell
wrote:
>
> Hi Sam,
>
> On 06/09/2012 01:43 AM, Sam Hartman wrote:
>> Add me as a +1 for the idea that content-type is important for this.
>> I tend to agree with the arguments given so far. Namely, for some
>> important use cases you're going to want
On 06/13/2012 07:28 AM, "Martin J. Dürst" wrote:
> Hello Stephen,
>
> On 2012/06/12 20:08, Stephen Farrell wrote:
>>
>> So would it work to add this:
>>
>> "
>> Note that relative ni URIs can occur, for example as shown in
>> Figure 5. In such cases, user agents MUST construct the absol
Hello Stephen,
On 2012/06/12 20:08, Stephen Farrell wrote:
So would it work to add this:
"
Note that relative ni URIs can occur, for example as shown in
Figure 5. In such cases, user agents MUST construct the absolute URI
as they would in the case of an HTTP URL, that is, in the e
> From: Stephen Farrell [stephen.farr...@cs.tcd.ie]
>
> > For example, in section 3, the syntax of the "ni" URI scheme is
> > spelled out with admirable clarity and exactness, including:
> >
> >Digest Value [Required] The digest value MUST be encoded using the
> > base64url [RFC4648] en
Hi Dale,
On 06/12/2012 03:04 PM, Worley, Dale R (Dale) wrote:
> Having never heard of this proposal before, I found the concept
> interesting, but the exposition in the draft was difficult to grasp in
> certain places. I believe that it is because the text assumes that
> the reader already knows
Having never heard of this proposal before, I found the concept
interesting, but the exposition in the draft was difficult to grasp in
certain places. I believe that it is because the text assumes that
the reader already knows the underlying theory of what the process is
intended to accomplish.
F
HTML with relative ni URI
"
Better suggestions welcome.
Ta,
S.
On 06/12/2012 11:43 AM, "Martin J. Dürst" wrote:
> Hello Stephen,
>
> On 2012/06/09 10:45, Stephen Farrell wrote:
>
>> On 06/09/2012 01:43 AM, Sam Hartman wrote:
>
>>> It's
Hiya,
Ah, ok I get it now. I'll look back at that again,
Ta,
S
On 06/12/2012 11:43 AM, "Martin J. Dürst" wrote:
> Hello Stephen,
>
> On 2012/06/09 10:45, Stephen Farrell wrote:
>
>> On 06/09/2012 01:43 AM, Sam Hartman wrote:
>
>>> It's a nam
Hello Stephen,
On 2012/06/09 10:45, Stephen Farrell wrote:
On 06/09/2012 01:43 AM, Sam Hartman wrote:
It's a naming
hierarchy. My main concern is whether the relative reference algorithm
described in section 5/4.2 of RFC 3986. In particular take a look at the
last part of section 1
other than a hint? That would seem to defeat
>>>>> the purpose.)
>>>>
>>>> I think we could argue this (and we did already between the authors;-)
>>>> and it'd come down to "pick a way." We did already and wrote code
>>>&
to change this later but not true
IMO that any fix is needed, now or later.
Using // is contrary to RFC 3986, which very clearly says
"governance of the name space defined by the remainder of the URI is
delegated to that authority". This is certainly not what this URI
scheme doe
On Thu, Jun 7, 2012 at 3:15 PM, Stephen Farrell
wrote:
>
> On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
>> As requested I am sending comments on this last call draft to
>> ietf@ietf.org. I sent them to the authors on 6 May but received no
>> reply.
>
> Once again, sorry about that. No idea why I
On 06/11/2012 01:30 PM, SM wrote:
> At 07:18 04-06-2012, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Naming Things with Hashes'
>>as Proposed Standard
>>
>>
At 07:18 04-06-2012, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Naming Things with Hashes'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this acti
ng no MUST/SHOULD with which we're in conflict afaik)
but the authority field here is not identical to that for HTTP
URLs. And that's ok.
> The authority separates the
> namespace exactly the way it doesn't in your scheme.
Yes there are differences and maybe we ought
which we're in conflict afaik)
but the authority field here is not identical to that for HTTP
URLs. And that's ok.
> The authority separates the
> namespace exactly the way it doesn't in your scheme.
Yes there are differences and maybe we ought try describe that
somehow.
arates the
namespace exactly the way it doesn't in your scheme. It's a naming
hierarchy. My main concern is whether the relative reference algorithm
described in section 5/4.2 of RFC 3986. In particular take a look at the
last part of section 1.2 of RFC 3986 regarding the disallowing of
/.
Hi Martin,
On 06/08/2012 10:54 PM, Martin Thomson wrote:
> One small comment, that I know the authors are aware of...
>
> On 6 June 2012 13:33, Jonathan A Rees wrote:
>> I think using .well-known is a good idea.
>
> I think that using .well-known is a bad idea.
Ok. Opinions vary.
> This impo
One small comment, that I know the authors are aware of...
On 6 June 2012 13:33, Jonathan A Rees wrote:
> I think using .well-known is a good idea.
I think that using .well-known is a bad idea.
This imposes an unnecessary restriction on the deployment of
resources. /.well-known/ is a space tha
arts (i.e. hash and content type) first, and the less important
>>> location hints parts all together after the identification. The various
>>> location hints (whether primary or secondary) would go together and
>>> their similarity would be clearer.
>>>
>&g
On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
> As requested I am sending comments on this last call draft to
> ietf@ietf.org. I sent them to the authors on 6 May but received no
> reply.
Once again, sorry about that. No idea why I missed responding,
your mail is in my client even. Ah well.
>
On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
> As requested I am sending comments on this last call draft to
> ietf@ietf.org. I sent them to the authors on 6 May but received no
> reply.
Oh crap - so you did. Apologies for missing that. In the
middle of something now but will get back soon,
As requested I am sending comments on this last call draft to
ietf@ietf.org. I sent them to the authors on 6 May but received no
reply.
Jonathan Rees
-- Forwarded message --
From: Jonathan A Rees
Date: Sun, May 6, 2012 at 7:57 PM
Subject: comments on http://tools.ietf.org/html/d
On Mon, Jul 12, 2010 at 05:23:16PM -0400, Sam Hartman wrote:
> Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the
> design of a GSS-API mechanism.
> I think this is a good start but is not quite done yet.
I agree. I'm not sure whether it's best to pro
Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the
design of a GSS-API mechanism.
I think this is a good start but is not quite done yet.
draft-hartman-gss-eap-naming-00 discusses a couple of problems with
naming extensions:
* The format of attribute names proposed in
The IESG writes:
> The IESG has received a request from the Kitten (GSS-API Next Generation)
> WG (kitten) to consider the following document:
>
> - 'GSS-API Naming Extensions '
> as a Proposed Standard
>
> The IESG plans to make a decision in the next
Hallam-Baker, Phillip wrote:
10.1.2.3 is simply a string litteral that may be used in place of a
DNS name. In neither case should the application require knowledge of
the IP address itself. In fact you don't want that as at some point in
the distant future, 10.1.2.3 is actually going to map to
orm to use as a
Web Service descriptor.
From: Melinda Shore [mailto:melinda.sh...@gmail.com]
Sent: Tue 12/16/2008 11:59 AM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; Keith Moore; t...@ietf.org; ietf@ietf.org
Subject: Re: [tae] The Great Naming Debate (
you're trying
to build a system that's even more broken than what we have now.
we're a very long way from knowing how to build a naming system that
works so reliably and transparently that we can completely hide IP
addresses from users.
Keith
[*] and yeah, I know about LLMNR and
ng to map to an IPv6 address, not an IPv4 address.
From: ietf-boun...@ietf.org on behalf of Bryan Ford
Sent: Sun 12/14/2008 2:51 PM
To: Keith Moore
Cc: t...@ietf.org; ietf@ietf.org
Subject: The Great Naming Debate (was Re: The internet architecture)
So, after
I absolutly agree with brians posting and recomment all people
reading this paper , IMHO, it solves some
known problems , even when they don´t exist in real world yet . ;)
http://pdos.csail.mit.edu/papers/uia:osdi06.pdf
(e.g., via DNS-based load balancers that take end-to-end IP
multiple address families, its design
> forces the application to have code specific to each family in order to
> support that family at all, which is the key problem.
>
> 2. ALL applications MUST use only DNS names for all operations, and never
> provide or see IP addresses for any reason.
;m suggesting (i.e., where you say "...by trying
to get apps and other things to use DNS names >>exclusively<<").
That's a world we might hold up as an ideal to strive for eventually,
but it's indeed not realistic in the short term, and it's not what
Bryan Ford wrote:
> You seem to be assuming that my proposal was to disallow such
> "visibility into the network" entirely, but that wasn't my intent at
> all. I just would like it to become no longer _mandatory_ for every
> application to know about the structure IP addresses in order to
> accomp
The proposed text looks good.
--larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman
Sent: Thursday, March 20, 2008 7:57 AM
To: ietf@ietf.org
Cc: [EMAIL PROTECTED]
Subject: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04
-naming-04.txt
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors should treat these comments just like any
other comments.
This document defines conventions for well-known Kerberos prin
: 'IETF Discussion'
> Subject: Re: RFC 5241 on Naming Rights in IETF Protocols
>
> Just publish an RFC that contains the names of popular celebrities,
> and use Google ads. The IETF site should do well in link-rankings...
>
> A number of non-IETF sites already
ded to WG naming rights as well. :-)
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> ]
> On Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, April 01, 2008 12:58 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject
Richard Shockey wrote:
> Can this be extended to WG naming rights as well. :-)
Hmm, those cost more. But the really expensive items are Areas. ;)
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signat
Can this be extended to WG naming rights as well. :-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 12:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RFC 5241 on Naming
I think there is a minor ambiguity in the naming draft:
>Consequently, unless otherwise
> specified, a well-known Kerberos realm name MUST NOT be present in
> transited encoding
Who enforces this requirement? That's an important question because
it controls who needs
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors should treat these comments just like any
other comments.
This document defines conventions for well-known Kerberos principal
names and we
> Lynn St.Amour wrote:
> At 1:25 PM +0100 1/26/05, Wijnen, Bert (Bert) wrote:
> >Having seen some more reactions... I think we can solve
> >the "general Ledger Accounts" issue with a very simple
> >addition as follows:
> >
> >
> >
> > As discussed w
At 1:25 PM +0100 1/26/05, Wijnen, Bert (Bert) wrote:
Having seen some more reactions... I think we can solve
the "general Ledger Accounts" issue with a very simple
addition as follows:
As discussed with ISOC, funds managed by IASA shall
Yes, still ok, I am still seeing those four words
Tom Petch
- Original Message -
From: "Wijnen, Bert (Bert)" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, January 26, 2005 1:34 PM
Subject: FW: Resolution? #787 terminology and issue 794 - naming of accounts
>> 5.1
roduce what is wanted.
Tom Petch
- Original Message -
From: "Wijnen, Bert (Bert)" <[EMAIL PROTECTED]>
Sent: Wednesday, January 26, 2005 1:25 PM
Subject: RE: Resolution? #787 terminology and issue 794 - naming of accounts
> Having seen some more reactions... I think we can solve
>
Bert resuggests:
5.1 Cost Center Accounting
Funds managed by the IASA shall be accounted for in a separate set of
general ledger accounts within the IASA Cost Center. In the remainder
of this document, these general ledger accounts are termed "IASA
accounts". A periodic summary of
Bert suggests:
As discussed with ISOC, funds managed by IASA shall
be accounted for in a separate set of general ledger
accounts within the Cost Center IASA.
In the remainder of this docum
7.
Bert
-Original Message-
From: Wijnen, Bert (Bert)
Sent: Wednesday, January 26, 2005 13:25
To: Lynn St.Amour; Carl Malamud; Tom Petch; Margaret Wasserman
Cc: Harald Tveit Alvestrand; Lynn DuVal; ietf@ietf.org
Subject: RE: Resolution? #787 terminology and issue 794 - naming of
account
Having seen some more reactions... I think we can solve
the "general Ledger Accounts" issue with a very simple
addition as follows:
As discussed with ISOC, funds managed by IASA shall
be accounted for in a separate set of genera
level of detail
on which to itemize and keep track of cost and revenue.
Lynn, pls correct me if I have not worded things correctly yet.
I think that meets our principle for transparency.
Kurtis (from the Transition Team) also agreed on that.
So I propose that I change the wording/naming of "Di
itemize and keep track of cost and revenue.
Lynn, pls correct me if I have not worded things correctly yet.
I think that meets our principle for transparency.
Kurtis (from the Transition Team) also agreed on that.
So I propose that I change the wording/naming of "Divisional Accounting"
aff to define which General Ledger Accounts we
want to see. So that means IAD and IAOC can specify the level of detail
on which to itemize and keep track of cost and revenue.
Lynn, pls correct me if I have not worded things correctly yet.
I think that meets our principle fo
At 1:57 PM +0100 1/17/05, Harald Tveit Alvestrand wrote:
The mind-picture I think we want to establish through using
"accounts" is "rows of numbers that can be added up to get totals" -
we want to know what it's costing, and where the money goes.
I'm worried we're getting too detailed but in the
--On 16. januar 2005 19:34 -0500 "Lynn St.Amour" <[EMAIL PROTECTED]> wrote:
The following three terms are used in this document, and it is not
clear if there is intended to be any difference between them:
- IASA accounts (or IASA budget)
For "IASA accounts" in most instances it would be more help
Title: Converted from Rich Text
> I don't know whether stopping "manyfolks" is right or not.
A note about manyfolks, a few IETF's ago, there were 3 or 4 drafts submitted into the WG I chair that were on the same topic. I felt it would be best if the authors got together and submitted a
On Sat, 31 Jul 2004 09:10:24 EDT, Sal Mangiapane said:
> > Thank you. I was also looking for an RFC - if any -which documents why.
> >
> There is RFC3552 which is the Security Considerations Best Practices but
> it doesn't answer the WHY question.
At the risk of stating the obvious
Anybody
> I don't know whether stopping "manyfolks" is right or not.
Sigh. Are there Internet Drafts that matter, that *don't* have inputs
from "many folks"? and if so, why?
I could never decide whether this was more likely a pure-hearted
attempt at modesty or an evil-hearted attempt to demonstrate that
--On 31. juli 2004 11:19 +0200 "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]>
wrote:
What about an information draft reporting on the results of the work of
an existing organization or project? Can it use the name of the
organization and only quote as authors the actual writers?
that would require gi
Thank you. I was also looking for an RFC - if any -which documents why.
There is RFC3552 which is the Security Considerations Best Practices but
it doesn't answer the WHY question.
Sal
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailm
At 13:03 31/07/2004, Sal Mangiapane wrote:
PS. Can someone tell me which RFC says that a draft must include a
security part?. thank you;
RFC2223 section 9
Sal
Thank you. I was also looking for an RFC - if any -which documents why. To
know what would be the proper process to introduce a comparable
PS. Can someone tell me which RFC says that a draft must include a
security part?. thank you;
RFC2223 section 9
Sal
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
What about an information draft reporting on the results of the work of an
existing organization or project? Can it use the name of the organization
and only quote as authors the actual writers? where/holw should the
organization be introduced? Is there any difference if the draft is not for
in
hm do you think Olaf Kolkman has misspelled his name, or what?
and draft-ietf-sip-manyfolks is *formally* correct.
draft-ymbk has tradition, but it's likely to be crushed under the wheel of
procedural correctness once the present batch is gone.
I don't know whether stopping "manyfolks" is rig
Bill,
At 03:46 AM 7/30/2004, Bill Manning wrote:
clearly different rules apply, depending on whom makes the submission.
for example, several individual submissions were made before this
IETF and we (the authors) were told that we -MUST- use the name of
one of th eauthors in the draft name... howeve
clearly different rules apply, depending on whom makes the submission.
for example, several individual submissions were made before this
IETF and we (the authors) were told that we -MUST- use the name of
one of th eauthors in the draft name... however, we see that other
individual submissions are
akes a lot of sense: many thanks for the piece of advice :-)
Florent
P.S:
1) My original concern was that if a WG I-D has been abandoned, having
it keep its draft-mybelovedWG-something name could be confusing.
Indeed, people aware of the IETF naming convention for I-Ds but not
of the hi
43 +0200 Florent
<[EMAIL PROTECTED]> wrote:
Hi all,
I am looking for procedural guidance on the naming convention to be
followed for an Internet-Draft that has been adopted as a WG item and
that has therefore been granted a name like
draft-mybelovedwg-blabla-XX.txt but that is now returni
Florent,
F> Thus, this Internet-Draft should probably revert to a filename similar
F> to draft-myfavoriteauthor-blibli-YY.txt, shouldn't it?
I don't recall seeing any guidance for choosing the full details of a
private I-D's name.
blibli-YY is chosen at the author's discretion. Having blibli be
Hi all,
I am looking for procedural guidance on the naming convention to be
followed for an Internet-Draft that has been adopted as a WG item and
that has therefore been granted a name like
draft-mybelovedwg-blabla-XX.txt but that is now returning to the
individual submission status - be it
--On 28. mars 2004 05:03 + Paul Vixie <[EMAIL PROTECTED]> wrote:
and at least some opinion that publishing it was better for the Internet
than not publishing it - certainly, for every standards-track RFC, there
was at one time a majority view in the IESG that such was the case.
well, no. the
Far too obvious!
jfc
At 09:17 29/03/04, David Morris wrote:
On Sun, 28 Mar 2004, Donald Eastlake 3rd wrote:
> There is clearly no way to do what you want with printed books, which
> are what RFCs are modelled after. To get the effect you want, people
> would need to go to a web resource or the lik
On 29-mrt-04, at 6:16, Donald Eastlake 3rd wrote:
To me it seems that the IETF can't make up its mind: are RFCs just
drafts that don't expire, or are they hugely important documents that
must be absolutely perfect before they are published?
Why does it have to be one of your two alternatives?
Abo
On Sun, 28 Mar 2004, Donald Eastlake 3rd wrote:
>
> There is clearly no way to do what you want with printed books, which
> are what RFCs are modelled after. To get the effect you want, people
> would need to go to a web resource or the like. But if they are willing
> to do that, then they can a
On Sun, 28 Mar 2004, Iljitsch van Beijnum wrote:
> Date: Sun, 28 Mar 2004 13:38:13 +0200
> From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
> Cc: IETF Discussion <[EMAIL PROTECTED]>
>
> ...
>
> To me it seems that the IETF can't make up its mind: are RFCs just
> drafts that don't expire, or are they
From: "Dassa" <[EMAIL PROTECTED]>
To: "'Iljitsch van Beijnum'" <[EMAIL PROTECTED]>; "'Harald Tveit
Alvestrand'" <[EMAIL PROTECTED]>
Cc: "'IETF Discussion'" <[EMAIL PROTECTED]>
Sent: Sunday, March 28, 2004
|> -Original Message-
|> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
|> Behalf Of Iljitsch van Beijnum
|> Sent: Sunday, March 28, 2004 9:38 PM
|> To: Harald Tveit Alvestrand
|> Cc: IETF Discussion
|> Subject: Re: Naming crap (Re: IESG review of RFC Editor d
In the spirit of "well, if highlighting a difference of opinion is the first step
toward
resolving it, then we're on our way.":
Can we can ask Amazon to include RFCs in their product listings, and then let
reviewers, consumers, proponents and objectors to use product rating mechanisms to
help
On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote:
If we are to change the process that produces this stuff, we HAVE to
understand what the reasons are that reasonable, competent people
produce things that are sub-par, broken or "crap". And IMHO, we can't
do that without saying what these u
[EMAIL PROTECTED] (Harald Tveit Alvestrand) writes:
> ...
> permit me to disagree. not with your core statement, but with the
> statement that citing examples would be counterproductive.
>
> The statement that "a fair amount of crap is published as RFCs" has been
> repeated for so long that
At 05:32 PM 3/27/2004, grenville armitage wrote:
>"Kurt D. Zeilenga" wrote:
>> The problem I see with being specific here is that what's crap to me
>> is not necessarily the same as to you, and we'll just end up arguing
>> over wether something is crap or not, and that will overshadow the
>> key as
"Kurt D. Zeilenga" wrote:
[..]
> The problem I see with being specific here is that what's crap to me
> is not necessarily the same as to you, and we'll just end up arguing
> over wether something is crap or not, and that will overshadow the
> key aspect of my argument that we should each
..
-James Seng
- Original Message -
From: "Kurt D. Zeilenga" <[EMAIL PROTECTED]>
To: "James Seng" <[EMAIL PROTECTED]>
Cc: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>; "IETF Discussion"
<[EMAIL PROTECTED]>
Sent: Sunday, Marc
Sound nice but isn't this go against the "rough consensus" principle?
You are free to doc your opinion (even if it is not rough consensus) in the
mailing list.
-James Seng
> What I personally view as "crap" has no bearing in regards to these
> points, excepting that where I feel strong enough to
At 03:49 PM 3/27/2004, James Seng wrote:
>Sound nice but isn't this go against the "rough consensus" principle?
The "rough consensus" principle applies to IETF documents,
not to RFCs in general.
>You are free to doc your opinion (even if it is not rough consensus) in the
>mailing list.
>
>-James
At 09:36 AM 3/27/2004, Harald Tveit Alvestrand wrote:
>>That, I think, would be counter productive. I think it fairly
>>apparent that there is a fair amount of crap (by mine, your, or
>>anyone's opinion) published as RFCs. I content that much of
>>that crap was produced by the IETF.
>
>permit me
Kurt,
--On 26. mars 2004 18:14 -0800 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote:
At 05:35 PM 3/26/2004, Eliot Lear wrote:
Personally, I'm more concerned by WGs demanding their right to
have their half-baked specifications published as RFCs, and the
for IESG to approve them without any IETF revi
"It's just that IETF has discussed this periodically for
many years."
Understood and valid. And this will be my last post to the main page on
this subject. What I would like to point out as that the change to the
root, that ICANN has described "as never been before", has now been done.
If there w
1 - 100 of 117 matches
Mail list logo
