Is there strong rationale for maintaining production of the CDs?
No.
IMO, free online retrieval of IETF proceedings is sufficient.
Spend the time and money on something more important.
I agree.
- Stewart
___
Ietf mailing list
Ietf@ietf.org
My attention has recently been drawn to this set of documents:
- draft-legg-xed-asd
- draft-legg-xed-asd-gserei
- draft-legg-xed-asd-xerei
- draft-legg-xed-rxer
- draft-legg-xed-rxer-ei
It's, as far as I can tell, an attempt at a complete reimplementation of
ASN.1 using XML.
I was very
On Feb 19, 2007, at 1:55 AM, Harald Alvestrand wrote:
My attention has recently been drawn to this set of documents:
- draft-legg-xed-asd
- draft-legg-xed-asd-gserei
- draft-legg-xed-asd-xerei
- draft-legg-xed-rxer
- draft-legg-xed-rxer-ei
It's, as far as I can tell, an attempt at a complete
--On 19. februar 2007 02:40 -0800 Fred Baker [EMAIL PROTECTED] wrote:
On Feb 19, 2007, at 1:55 AM, Harald Alvestrand wrote:
My attention has recently been drawn to this set of documents:
- draft-legg-xed-asd
- draft-legg-xed-asd-gserei
- draft-legg-xed-asd-xerei
- draft-legg-xed-rxer
-
Please find below my comments:
1. The IETF LC mentions only the DOWNREF for RFC 3576. However, there is
another DOWNREF for RFC 2866 which is not mentioned in the LC.
2. Reference [1] fails to name the RFC number (2119)
3. It would be useful to include expansion of the acronyms at first
- Original Message -
From: David Harrington [EMAIL PROTECTED]
To: 'Tom.Petch' [EMAIL PROTECTED]; 'ietf' ietf@ietf.org
Sent: Saturday, February 17, 2007 12:10 AM
Subject: RE: Last Call: draft-harrington-text-mib-doc-template (A Template
Yup.
Trying to figure out how to publish this in
On Tue, 13 Feb 2007, IESG Secretary wrote:
Given the wide acceptance of the media server, we need a standard
way to control them.
This, and taking a look at draft-boulton-sip-control-framework-05.txt
which seems to be relevant here, seems to imply this group is about to
build a management
On Tue, 13 Feb 2007, IESG Secretary wrote:
[logical components being:] encoding and transport along forward
path from marker to egress, metering of congestion information at
the egress, and transport of congestion information back to the
controlling ingress.
I'd like to see it explicitly
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
Lakshminath Dan, We are discussing the case of the authenticator
Lakshminath providing a different identity to the peer and the
Lakshminath server here. Sam raised that issue.
This is probably the last message you'll hear
Vidya,
On Sun, Feb 18, 2007 at 11:20:54PM -0800, Narayanan, Vidya wrote:
(snip)
Going back to your proposed text:
It is RECOMMENDED that the key transport protocol be able to detect
impersonation. When it is not feasible to guarantee that, every key
handed out from the server
--On Monday, February 19, 2007 11:45 +0100 Harald Tveit
Alvestrand [EMAIL PROTECTED] wrote:
Having not read the above and not really caring much what
happens in the layers up in the stratosphere as long as its
designers don't by its sheer weight make the application
unusable, is it a bad
On Feb 19, 2007, at 5:19 AM, Pekka Savola wrote:
I'd like to see it explicitly stated that transporting congestion
information in the (metered) IP packets themselves is out of scope.
This should exclude designs such as adding IP options en-route,
defining new extension headers, or modifying
On Sun, 2007-02-18 at 13:20 -0800, Douglas Otis wrote:
---
The safe way forward would be to demand that security be considered
first and foremost. In a store and forward scheme, start the chain of
identification from the transmitting entity, where the originating
entity is then able to
On 2/19/07, John C Klensin [EMAIL PROTECTED] wrote:
For the record, I would have no problems with Informational or
Experimental publication of this collection -- it is the
proposed decision to standardize that bothers me.
Exactly. Under no circumstances should it ever be OK to use IETF
Fred Baker wrote:
is it a bad thing to provide
the expressive nature of ASN.1 in a human-readable and popular data
representation?
The one thing IETF standardization certainly ought to imply is that there is a
real constituency interesting in using the specification in the near-term.
The one thing IETF standardization certainly ought to imply is that there
is a real constituency interesting in using the specification in the near-term.
Dave,
Why is near term an essential requirement? If the Internet designers had
opted for the
near term, we would all be running some
I am the assigned Gen-ART reviewer for
draft-ietf-imss-fc-fcs-mib-02.txt
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other Last Call comments
you may receive.
Summary: This draft is
I am the assigned Gen-ART reviewer for
draft-ietf-imss-fc-fcs-mib-02.txt
Thanks for your review.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other Last Call comments
you may
Hi Keith,
Please find comments inline.
Thanks
Suresh
Without this sentence, the boilerplate implies that all of the listed
keywords are present in the document. Since the boilerplate cannot be
changed, the sentence was included to avoid the erroneous implication.
I do not know of any
Bob Braden wrote:
Why is near term an essential requirement? If the Internet designers
had opted for the
near term, we would all be running some flavor of X.25 today.
Research vs. engineering.
Standards are for engineering. When they don't solve near-term problems they
tend not to
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
Sam,
Please read the thread again and make a convincing case as to why my
message -- and please consider the entire message -- is disgusting, and
I shall apologize.
Some notes inline:
Sam Hartman wrote:
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
Lakshminath Dan, We
Dave Crocker wrote:
Fred Baker wrote:
is it a bad thing to provide
the expressive nature of ASN.1 in a human-readable and popular data
representation?
The one thing IETF standardization certainly ought to imply is that
there is a real constituency interesting in using the specification
Hi Bernard,
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 18, 2007 6:49 AM
To: Narayanan, Vidya; Dondeti, Lakshminath; Sam Hartman
Cc: Dan Harkins; ietf@ietf.org
Subject: RE: comments on
24 matches
Mail list logo
