The IESG has received a request from the Atom Publishing Format and
Protocol WG (atompub) to consider the following document:
- 'The Atom Publishing Protocol '
draft-ietf-atompub-protocol-14.txt as a Proposed Standard
By my count, draft-ietf-atompub-protocol-14.txt has generated over 250
Robert Sayre schrieb:
The IESG has received a request from the Atom Publishing Format and
Protocol WG (atompub) to consider the following document:
- 'The Atom Publishing Protocol '
draft-ietf-atompub-protocol-14.txt as a Proposed Standard
By my count, draft-ietf-atompub-protocol-14.txt
I'd feel uncomfortable approving this draft until the authors indicate
that any IPR disclosures required by our process have been filed.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
--On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola
[EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007, The IESG wrote:
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
...
Working Group Summary
This document set was not produced by an IETF
I saw almost no technical comments on the documents. Most of
the last call comments I saw were on a side track about
copyright issues.
The one somewhat technical comment that I logged, from Tom Yu,
didn't result in any changes but was certainly influential on
me in agreeing to the documents
Comment to the draft received from Tim Polk during review:
I thought I might follow up on the first unaddressed comment:
I notice that the phrase the Initial Archive Timestamp frequently
appears in the text with a capitalized 'I' in word initial. This
seems
to indicate that there *is*
Hello,
A slightly revised version of the I-D is now available at:
http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
This revision incorporates changes based on some of the comments made by the
directorate. It will be submitted to the ID repository as soon as the gates
Hi!
I started a review by going through the reference section. There
seems to be some editing left to do...
There are reference to old documents, including:
RFC 2279 - RFC 3629
RFC 1750 - RFC 4086
There are normative reference to non-standards track RFCs, including:
RFC 1641
RFC 1951
See https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751
At 08:43 AM 3/13/2007, Sam Hartman wrote:
I'd feel uncomfortable approving this draft until the authors indicate
that any IPR disclosures required by our process have been filed.
While it is definitely true that there has been a lot of good feedback,
it would still be good to at least start broadening the net and get
feedback from the larger IETF community.
- James
Julian Reschke wrote:
[snip]
+ 0,5.
The document got lots of constructive feedback in the previous
Pekka Savola [EMAIL PROTECTED] writes:
On Mon, 12 Mar 2007, The IESG wrote:
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
...
Working Group Summary
This document set was not produced by an IETF working group, but by an
individual. IETF
I agree that there were no technical comments but the summary states 'no
comments'.
Arguments on complexity are too easy to make. Every time a proposal is made I
hear the complexity argument used against it. Everything we do is complex.
Computers are complex. Committee process usually
On Tue, Mar 13, 2007 at 08:09:35AM -0700,
Hallam-Baker, Phillip [EMAIL PROTECTED] wrote
a message of 76 lines which said:
Everything we do is complex.
There are degrees in complexity. Compare RFC 3912 with 3981, both
written by your co-workers :-)
So, I do not think that the complexity
At 7:47 AM +0200 3/13/07, Pekka Savola wrote:
On Mon, 12 Mar 2007, The IESG wrote:
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
...
Working Group Summary
This document set was not produced by an IETF working group, but by an
individual. IETF Last
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Arguments on complexity are too easy to make. Every time a proposal
is made I hear the complexity argument used against it. Everything
we do is complex. Computers are complex. Committee process usually
increases complexity somewhat.
If an
Russ == Russ Housley [EMAIL PROTECTED] writes:
Russ See
Russ https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751
Russ At 08:43 AM 3/13/2007, Sam Hartman wrote:
*Sigh* I searched on the draft before sending the last call comment
and when the search tool is used no
Absolutely there are degrees in complexity. But there are no objective measures.
PKIX is certainly not a simple specification. It got that way for one simple
reason - people used it enough to care about it. So over fifteen years it has
grown.
My point here is that if you look at an
From: Simon Josefsson [mailto:[EMAIL PROTECTED]
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Arguments on complexity are too easy to make. Every time a
proposal is
made I hear the complexity argument used against it.
Everything we do
is complex. Computers are complex.
From the draft:
At a minimum, client and server implementations MUST be capable of
being configured to use HTTP Basic Authentication [RFC2617] in
conjunction with a TLS connection as specified by [RFC2818]. See
[RFC4346] for more information on TLS.
I've discovered a small but potentially
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert From the draft:
At a minimum, client and server implementations MUST be capable
of being configured to use HTTP Basic Authentication [RFC2617]
in conjunction with a TLS connection as specified by [RFC2818].
See
Sam Hartman wrote:
My preference is to resolve this by making 2818 normative; I believe
we've already 3967'd 2818 so we don't need an additional last call on
this one.
Is RFC 2818 sufficient to ensure interoperability? It would be quite
easy for two implementations to claim to implement
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert Sam Hartman wrote:
My preference is to resolve this by making 2818 normative; I
believe we've already 3967'd 2818 so we don't need an
additional last call on this one.
Robert Is RFC 2818 sufficient to ensure
pbaker == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
pbaker I agree that there were no technical comments but the summary
pbaker states 'no comments'. Arguments on complexity are too easy to
pbaker make. Every time a proposal is made I hear the complexity
pbaker argument used against it.
Sam Hartman wrote:
I think both 2818 and 4346 contain important details and need to be
normative.
That makes sense to me. However, I initially thought the references had
been mistakenly switched around.
From the draft:
At a minimum, client and server implementations MUST be capable of
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
[EMAIL PROTECTED] wrote:
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Arguments on complexity are too easy to make. Every time a
proposal is made I hear the complexity argument used against
it. Everything we do is complex.
John C Klensin wrote:
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
[EMAIL PROTECTED] wrote:
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Arguments on complexity are too easy to make. Every time a
proposal is made I hear the complexity argument used against
it. Everything we
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
[EMAIL PROTECTED] wrote:
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Arguments on complexity are too easy to make. Every time a
proposal is made I hear the complexity argument used against
it. Everything we do is complex.
Ned == Ned Freed [EMAIL PROTECTED] writes:
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
[EMAIL PROTECTED] wrote:
And it was a suggestion/ request that, before
this document was published in _any_ form, that it at least
acquire a clear discussion as to when one would select this
Options are not necessarily complications.
The only point to having XER that I can see is if you intend to allow an
orderly transition from use of ASN.1 to use of XML. Both standards do their job
fine, both are somewhat more complex than they should be. One of these choices
is surplus to
--On Tuesday, 13 March, 2007 16:01 -0700 Andy Bierman
[EMAIL PROTECTED] wrote:
I was going to raise this issue, but I deleted the mail when I
realized
this is going to be an Experimental RFC (according to the
subject line).
I don't think it harms interoperability to introduce an
John,
On Tue, Mar 13, 2007 at 09:04:52AM -0400, John C Klensin wrote:
If the IESG is going to claim a silent majority in favor of
approving this document, so be it. But to claim that there were
no Last Call comments and that those that were solicited were
positive is deeply problematic.
--On Tuesday, 13 March, 2007 17:30 -0700 Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
Options are not necessarily complications.
The only point to having XER that I can see is if you intend
to allow an orderly transition from use of ASN.1 to use of
XML. Both standards do their job fine,
The WWW Distributed Authoring and Versioning (webdav) in the Applications
Area has concluded.
The IESG contact persons are Ted Hardie and Lisa Dusseault.
The work on WebDAV began in the summer of 1996, and the working
group was officially chartered on March 20th of 1997. During the
10 years of
The following changes have been made since the agenda was printed. The
web version of the agenda is up to date:
CANCELLED
msec - was scheduled on Tuesday at 1520-1720
SECOND SESSION
krb-wg - second session on Tuesday at 1520-1720
Room: Karlin II
MOVED
mobopts - moved from Tuesday at 0900 to
The IESG has received a request from the An Open Specification for
Pretty Good Privacy WG (openpgp) to consider the following document:
- 'OpenPGP Message Format '
draft-ietf-openpgp-rfc2440bis-19.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
We have received the following information from the Hilton Prague
regarding transporation from the airport to the Hotel. If you are not
staying at the Hilton, contact the concierge at your hotel to inquire
about their taxi service from the airport to hotel, most hotels offer this
service.
You
36 matches
Mail list logo
