On Sat, Jan 13, 2007 at 10:05:35PM -0500,
Steven M. Bellovin [EMAIL PROTECTED] wrote
a message of 34 lines which said:
And as you very well know, the IPR working group is fixing the
problem.
Is working on the problem. It is not the same thing. Nothing indicate
that it will be fixed,
On Sat, Jan 13, 2007 at 04:10:40PM -0800,
Randy Presuhn [EMAIL PROTECTED] wrote
a message of 31 lines which said:
Section 5.2 of RFC 3978 addresses the issue, giving the necessary
incantation and using MIBs and PIBs as an example.
You really need to be more specific because I'm hopelessly
On 2007-01-08 11:08, Brian E Carpenter wrote:
The I-D tracker provides a handy button for the DISCUSSing AD
to forward the DISCUSS to parties outside the IESG - normally
by default it's the WG Chairs. I'm not convinced personally
that sending the raw DISCUSS to the whole WG is the correct
On Mon, 15 Jan 2007 09:47:06 +0100
Stephane Bortzmeyer [EMAIL PROTECTED] wrote:
On Sat, Jan 13, 2007 at 10:05:35PM -0500,
Steven M. Bellovin [EMAIL PROTECTED] wrote
a message of 34 lines which said:
And as you very well know, the IPR working group is fixing the
problem.
Is working
Thank you for informing me of the re-write. A few obvious editorial
corrections:
EMail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
The former machine hasn't existed since circa 1994, and the latter since
circa 1998. Easy Googling has given reviewers one of my half dozen
active emails
Me encontraré de vacaciones desde el Lunes 15 de Enero hasta el Viernes 2 de
Febrero inclusive. Saludos, Sergio.
ietf 01/12/07 19:15
The IESG has received a request from an individual submitter to consider
the following documents:
- 'Abstract Syntax Notation X (ASN.X) Representation of
Hi Brian,
If an AD modifies their DISCUSS text, or moves a DISCUSS to a COMMENT,
all that is in the tracker.
Yes. I agree. *If*.
Some ADs are very good about this. (Shall I name names? ;-)
But some are less good.
Often a Discuss is just cleared.
What isn't there is the email trail.
Are you
Why not simply:
- copy all Comments and Discusses to the WG mailing list
- hold all discussions on the WG mailing list until resolution
Why would we do this for technical typos and other things that
are essentially trivial? I'd expect an AD to enter WG discussion
when raising fundamental
I would refer you to the IETF Trust FAQ on RFC copyright,
http://trustee.ietf.org/24.html, point 6 and point 9.
Brian
On 2007-01-14 12:31, Simon Josefsson wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
And as you very well know, the IPR working group is fixing the
problem. I think
Brian E Carpenter [EMAIL PROTECTED] writes:
I would refer you to the IETF Trust FAQ on RFC copyright,
http://trustee.ietf.org/24.html, point 6 and point 9.
Interesting. Point 6 seem incorrect to me, as there is nothing in BCP
78 that permits computer code extracts from RFC for third parties.
Hi -
From: Stephane Bortzmeyer [EMAIL PROTECTED]
To: Randy Presuhn [EMAIL PROTECTED]
Cc: ietf@ietf.org
Sent: Monday, January 15, 2007 12:57 AM
Subject: Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation
X(ASN.X)) to Proposed Standard
...
Section 5.2 of RFC 3978 addresses the
--On Sunday, 14 January, 2007 09:31 +0100 Brian E Carpenter
[EMAIL PROTECTED] wrote:
Maybe we should be clearer on what the expectation for
processing IETF LC comments is. Unless we do, it is not
obvious how we could evaluate whether the procedure has been
carried out properly or not.
On 2007-01-15 17:11, Michael Thomas wrote:
Michael Thomas, Cisco Systems
On Mon, 15 Jan 2007, Brian E Carpenter wrote:
Why not simply:
- copy all Comments and Discusses to the WG mailing list
- hold all discussions on the WG mailing list until resolution
Why would we do this for
Why would we do this for technical typos and other things that
are essentially trivial? I'd expect an AD to enter WG discussion
when raising fundamental issues, but not for straightforward
points.
This is what should, IMHO, be the PROTO shepherd's job to decide
about, as well as
The IESG schrieb:
The IESG has received a request from the WWW Distributed Authoring and
Versioning WG (webdav) to consider the following document:
- 'HTTP Extensions for Distributed Authoring - WebDAV '
draft-ietf-webdav-rfc2518bis-17.txt as a Proposed Standard
...
The short answer:
Brian E Carpenter wrote:
On 2007-01-08 11:08, Brian E Carpenter wrote:
a) we believe that it is indeed the document shepherd's
job to summarise issues and take them back to the WG, as
stated in section 3.3 of draft-ietf-proto-wgchair-doc-shepherding.
This certainly seems reasonable.
John C Klensin wrote:
The IESG may well have made the right decision here
s/may well have/certainly has/ I think it's a bug that
I-D.iab-publication-00.txt offers no list for public
Last Call comments. IMO the rare Last Calls for I-Ds
published by the IAB could also use this list here for
Hi David,
Thanks for taking on the drudge work to make something useful and
beneficial.
Comments below.
Adrian
===
Abstract
I think it would be useful if the abstract of this I-D was the abstract
*for* this I-D. That means that you should move the template abstract into
its own section.
At 5:42 PM +0100 1/15/07, Julian Reschke wrote:
(2) Compatibility with RFC2518
The Last Call announcement states:
While the WEBDAV working group was originally chartered to produce a
draft standard update to RFC 2518, this documented is being targeted
as a replacement Proposed Standard
--On Monday, 15 January, 2007 09:26 -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
In the current model, any follow-on discussion really is
between the Design Team and Chairs, with the AD. This
introduces the possibility of significant late-stage changes
that are agreed to by a smaller set
On Mon, 15 Jan 2007 14:26:33 -0500
John C Klensin [EMAIL PROTECTED] wrote:
Perhaps we should make it a requirement that any document that
is Last Called must be associated with a mailing list, perhaps
one whose duration is limited to the Last Call period and any
follow-ups until the document
Following up on that, I suggest a requirement that any DISCUSSes be posted
to that mailing list, along with conversation/resolution of the DISCUSSes.
I would very much like to see those last steps out in the open.
Only drawback to separate mailing list is that it requires active
involvement to
Good issues are being raised. Certainly there needs to be openness
about any substantive changes in drafts during the IESG review process.
I'm not enamored of the idea of yet more mailing lists to subscribe to,
however. Why can't we rely on the PROTO Shepherds to do the right thing
with regard
Nelson, David wrote:
Good issues are being raised. Certainly there needs to be openness
about any substantive changes in drafts during the IESG review process.
I'm not enamored of the idea of yet more mailing lists to subscribe to,
however. Why can't we rely on the PROTO Shepherds to do the
Steven M. Bellovin wrote:
On Mon, 15 Jan 2007 14:26:33 -0500
John C Klensin [EMAIL PROTECTED] wrote:
Perhaps we should make it a requirement that any document that
is Last Called must be associated with a mailing list, perhaps
one whose duration is limited to the Last Call period and any
Harald Alvestrand wrote:
I think all I-Ds should have this - both the first ones and the last ones.
Ideally the announcement would be also sent to this list, if it's a known
IETF list (including the other lists), and the submitter identified a
list for this purpose. Just mentioning a list in a
On Jan 15, 2007, at 1:46 PM, Harald Alvestrand wrote:
I have argued for years that an I-D that doesn't say in its status
of this memo section which mailing list it is to be discussed on
is incomplete, but I don't seem to have achieved much success for
that.
100% agree. On many of my
Hi Folks,
as a slight counter to that:
I have had feedback in the past from WGs that it is unwise to include
the
WG's ML inside a draft intended (eventually) to be an RFC.
The rationale was that the WG (and its ML) will disappear, whilst an
RFC is forever.
However, an unprocessed/not
While not harmful, I'm not sure this is necessary if the more-or-less
standard naming convention for drafts is followed for non-WG drafts:
draft-conroy-sipping-foo-bar
indicates that the author Conroy believes the sipping WG to be the
appropriate place for discussion, just like
Henning Schulzrinne wrote:
While not harmful, I'm not sure this is necessary if the more-or-less
standard naming convention for drafts is followed for non-WG drafts:
draft-conroy-sipping-foo-bar
indicates that the author Conroy believes the sipping WG to be the
appropriate place for
WIth my WebDAV WG Chair hat on I would like to make a few comments.
On Jan 15, 2007, at 8:42 AM, Julian Reschke wrote:
... snip...
(4) Examples for open issues
(4a) One of the things RFC2518bis was supposed to fix was the
confusion around locking. Right now, it fails big time. For
lconroy wrote:
Hi Folks,
as a slight counter to that:
I have had feedback in the past from WGs that it is unwise to include the
WG's ML inside a draft intended (eventually) to be an RFC.
The rationale was that the WG (and its ML) will disappear, whilst an
RFC is forever.
However, an
Henning Schulzrinne wrote:
While not harmful, I'm not sure this is necessary if the more-or-less
standard naming convention for drafts is followed for non-WG drafts:
draft-conroy-sipping-foo-bar
indicates that the author Conroy believes the sipping WG to be the
appropriate place for
Two IETF Operational Notes have been approved and posted:
http://www.ietf.org/IESG/content/ions/ion-ion-format.txt
http://www.ietf.org/IESG/content/ions/ion-ion-store.html
For the general ION page, see
http://www.ietf.org/IESG/content/ions.html
___
This message is to remind you that as of February 1, 2007 the IETF
Secretariat will no longer accept Internet-Drafts with the old
(i.e. pre RFC 4748) boilerplate. For your convenience, below is
the text of the message that was sent to the IETF Announcement
List by the IETF Chair on October 26,
The IESG has received a request from the Host Identity Protocol WG (hip)
to consider the following document:
- 'Host Identity Protocol (HIP) Registration Extension '
draft-ietf-hip-registration-02.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the Host Identity Protocol WG (hip)
to consider the following document:
- 'Host Identity Protocol (HIP) Rendezvous Extension '
draft-ietf-hip-rvs-05.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has approved the following document:
- 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol
Label Switching (GMPLS) Recovery '
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt as a Proposed Standard
This document is the product of the Common Control and
The IESG has approved the following document:
- 'Clarification of the 3rd Party Disclosure procedure in RFC 3979 '
draft-narten-ipr-3979-3rd-party-fix-00.txt as a BCP
This document is the product of the Intellectual Property Rights Working
Group.
The IESG contact person is Brian Carpenter.
The IESG has approved the following document:
- 'Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture '
draft-ietf-mip6-ikev2-ipsec-08.txt as a Proposed Standard
This document is the product of the Mobility for IPv6 Working Group.
The IESG contact persons are Jari Arkko and
The IESG has approved the following document:
- 'GMPLS Based Segment Recovery '
draft-ietf-ccamp-gmpls-segment-recovery-03.txt as a Proposed Standard
This document is the product of the Common Control and Measurement Plane
Working Group.
The IESG contact persons are Ross Callon and Bill
The IESG has approved the following document:
- 'A Uniform Resource Name (URN) Namespace for the International
Organization for Standardization (ISO) '
draft-goodwin-iso-urn-01.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF
The IESG has received a request from the Layer Two Tunneling Protocol
Extensions WG (l2tpext) to consider the following document:
- 'Fail Over extensions for L2TP failover '
draft-ietf-l2tpext-failover-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area Area. The IESG has not made any determination as
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list
A new IETF working group has been proposed in the Security Area.
The IESG has not made any determination as yet. The following draft
charter was submitted, and is provided for informational purposes only.
Please send your comments to the IESG mailing list (iesg@ietf.org) by
January 22nd.
45 matches
Mail list logo