Keith Moore wrote:
>> if you are coming from outside the network, you do not get
>> to "relay" through the network. You can post/submit from
>> within, you can deliver into the net or you can post/submit
>> from outside.
> This is wrong. "outside the network" is irrelevant. What
> matters is w
On Friday, June 03, 2005 05:27:55 PM -0700 Dave Crocker <[EMAIL PROTECTED]>
wrote:
In other words, if you are coming from outside the network, you do not
get to "relay" through the network. You can post/submit from within,
you can deliver into the net or you can post/submit from outside.
Alex, sometimes 'SIR' can be used by someone to show his/her sincerity
and loyalty when in need of assistance. It was simple to tell Prasanna
to subscribe at http://www.isi.edu/nsnam/ns/ns-lists.html
Joe.
On Fri, 2005-06-10 at 01:04, Alexandru Petrescu wrote:
> Prasanna S.J wrote:
> > hello sir,
>
Sam is correct here - the text as written is incorrect, even if it
accurately reflects the authors' intent.
You mean that you disagree with the authors' intent. That is quite
different from the document being "incorrect".
I meant what I said. You may infer that it is my opinion, and tak
The current document purports to be a candidate for BCP and yet it
recommends a practice which is clearly no longer appropriate.
clearly?
please provide a citation to any sort of official consensus
statement that
establishes this clarity.
you seem to be confusing two things - technical q
> The current document purports to be a candidate for BCP and yet it
> recommends a practice which is clearly no longer appropriate.
clearly?
please provide a citation to any sort of official consensus statement that
establishes this clarity.
an ietf formal publication would be preferred for t
> > > Sam is correct here - the text as written is incorrect, even if it
> > > accurately reflects the authors' intent.
> > >
> > You mean that you disagree with the authors' intent. That is quite
> > different from the document being "incorrect".
> >
> I meant what I said. You may infer tha
The line of discussion about a particular algorithm reflects the
rather
unfortunately tendency to have every system-level effort involving
security get dragged into low-level debates about basic algorithms and
about the current views of various experts in the security community.
That's no way t
The implications you are drawing are exactly what is intended.
When the
document said "treat as a submission" it meant exactly that.
Sam is correct here - the text as written is incorrect, even if it
accurately reflects the authors' intent.
You mean that you disagree with the authors'
> The environment has changed a great deal. I don't know why people
> thought MITM attacks weren't feasible in 1996 -- Joncheray published a
> paper on how to carry them out in 1995 -- but they're now trivial.
There are some meta-problems with this thread.
(Aside: John K has raised his own
"Kurt D. Zeilenga" <[EMAIL PROTECTED]> writes:
> It is my recommendation that the mandatory-to-implement
> "strong" authentication mechanism for this protocol be either:
> DIGEST-MD5 (with a mandate that implementations
> support its data security layers)
> TLS+PLAI
Keith,
> > The implications you are drawing are exactly what is intended. When the
> > document said "treat as a submission" it meant exactly that.
> >
> Sam is correct here - the text as written is incorrect, even if it
> accurately reflects the authors' intent.
You mean that you disagree
> > The good part of this requirement seems to be to subject such mail to
> > authorization (and in many cases authentication). However I think
> > that saying mail must be treated as submission rather than relaying
> > may have effects significantly beyond authorization/authentication.
> > F
Hi Frank,
On 2005-06-09 20:29 Frank Ellermann said the following:
> Brian E Carpenter wrote:
>
>> See http://ietf.levkowetz.com/tools/idnits/idnits.pyht
>
> I never got the idnits webservice version to do anything else
> but show its 'usage' info. No idea what's wrong, maybe it's
> only my brow
In message <[EMAIL PROTECTED]>, Ned Freed writes:
>> From where I sat, the problem was trying to ensure that a WG thought
>> about an issue. Neither mandatory material nor checkoff boxes
>> accomplish that, but I think the former is often more useful because
>> material in an I-D is visible to the
> From where I sat, the problem was trying to ensure that a WG thought
> about an issue. Neither mandatory material nor checkoff boxes
> accomplish that, but I think the former is often more useful because
> material in an I-D is visible to the entire WG.
I disagree completely and think you have
In message <[EMAIL PROTECTED]>, John C Klensin writes:
>The claims about man-in-the-middle attacks are another matter.
>When the analysis was done in 1996, the conclusion was that such
>attacks were not possible unless either the secrets were already
>known to the attacker or there was a plausible
Kurt and Sam,
I hope someone else will pick up this discussion, as I'm not the
right person to lead it. I would encourage you to read and
react to Simon's comments as a start. However, let me make a
couple of additional observations:
* CRAM-MD5 was caused because folks in the security area said
Brian E Carpenter wrote:
> See http://ietf.levkowetz.com/tools/idnits/idnits.pyht
I never got the idnits webservice version to do anything else
but show its 'usage' info. No idea what's wrong, maybe it's
only my browser. But ml2rfc and Bill's validator work online,
his ABNF checker is also very
On Wed June 8 2005 14:30, Ned Freed wrote:
> > The IETF Internet-Drafts page notes that "All Internet-Drafts that are
> > submitted to the IESG for consideration as RFCs must conform to the
> > requirements specified in the I-D Checklist". The current version of
> > the ID-Checklist clearly state
Prasanna S.J wrote:
> hello sir,
>
> this is prasanna research student in SERC,IISc,Banglore.
Hey Prasanna.
> sir i am working on bandwidth utilization and power control in adhoc
> n/ws. if it is possible to give some idea regarding basic power
> control i.e. Pmax for control packets such as r
Someone suggested that I repeat this post I made to namedroppers on
the main list. The reference to "wayne" refers to the message
archived at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00864.html
oo The forwarded message oo
Date: Thu, 9 Jun 2005 10:51:49 -0400
To: namedro
Nice list. How about adding:
- Be very suspicious of centralized solutions that encourage monopolies
and may introduce single points of failure.
Bob Braden
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
At 15:38 09/06/2005, Brian E Carpenter wrote:
Please see RFC 2434 = BCP 26
Dear Brian,
I was probably not clear enough. Bruce quoted RFCs, and others points
postdate RFC 2434. Current http://www.iana.org site is not the best
documentation site I saw. It said two things:
1. a IANA related ob
In message <[EMAIL PROTECTED]>, John C Klensin writes:
>Brian,
>
>We agree about the desirability of making sure than some things
>are explicitly documented and explicitly part of what gets
>reviewed. But I continue to believe, as I have believed for
>years, that adding more and more mandatory mat
At 8:15 PM +0200 6/8/05, Jacob Palme wrote:
>
>Do not comment on the draft in ietf@ietf.org or
>[EMAIL PROTECTED], use the new mailing list.
There goes your first rule...
--
+---+
|"Minds are like parachutes - they
Brian,
We agree about the desirability of making sure than some things
are explicitly documented and explicitly part of what gets
reviewed. But I continue to believe, as I have believed for
years, that adding more and more mandatory material to RFCs or
I-Ds is not the best solution to that partic
I have written an Internet Draft on the IETF Golden Rules
which may be very controversial.
Abstract:
This memo presents the following rules, which to some
extend can be regarded as the golden rules of IETF, even
though there are exceptions when these rules should not be
adhered to.
- Be liberal
Please see RFC 2434 = BCP 26
Brian
JFC (Jefsey) Morfin wrote:
Dear Bruce,
you know what? I think it would be great to write a IANA obligations
RFC. It would say that the IANA MUST maintain a list of all the
obligations RFC authors should respect when writting the IANA
considerations, and
My personal view (e.g., SASL chair hat off) is that CRAM-MD5
use on the Internet should be limited. It fails to provide
any form of data security itself. The lack of integrity
protection means sessions are subject to hijacking. While
this inadequacy can be addressed by protecting the session
wit
On 6/9/05, Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> It's not illogical - if your source file says
> you get exactly what you asked for, i.e. the
> obsolete boilerplate. The id-nits tool will warn you - it is
> well worth running that before submitting *any* I-D, whether produced
> by xml2rfc
Ned Freed <[EMAIL PROTECTED]> wrote:
> [Pekka Savola <[EMAIL PROTECTED]> wrote:]
>> On Wed, 8 Jun 2005, Ned Freed wrote:
>>> [Pekka Savola <[EMAIL PROTECTED]> wrote:]
>>>
A practical issue I have with this doc is that the recommendations are
relatively few, and most of them are rather gen
Dear Bruce,
you know what? I think it would be great to write a IANA obligations RFC.
It would say that the IANA MUST maintain a list of all the obligations RFC
authors should respect when writting the IANA considerations, and to
document whatever additional information IANA may need (for examp
Ned Freed wrote:
...
The IETF Internet-Drafts page notes that "All Internet-Drafts that are
submitted to the IESG for consideration as RFCs must conform to the
requirements specified in the I-D Checklist". The current version of
the ID-Checklist clearly states:
That's most unfortunate. What d
Carl Malamud wrote:
Randall's method works, or you can do what the readme suggests:
see:
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr
A number of us, including the IETF Chair, have discovered this
experimentally. It's not illogical - if your source file says
you get
35 matches
Mail list logo
