-dhc-dhcpv4-vendor-message-01.txt
Reviewer: Elwyn Davies
Review Date: 5 February 2010
IETF LC End Date: 17 February 2010
IESG Telechat date: (if known) -
Summary: Almost ready. I note that (AFAICS) the existing DHCPv4
standards do not specify the behaviour of clients and servers receiving
message
-ipsecme-ikev2bis-08.txt
Reviewer: Elwyn Davies
Review Date: 18 March 2010
IETF LC End Date: 18 March 2010
IESG Telechat date: (if known) -
Summary:
Not ready. The document contains a lot of minor niggles and nits plus a major
item that I am not sure the IETF should support: this is the removal of all
Paul Hoffman wrote:
> At 2:37 PM + 3/19/10, Elwyn Davies wrote:
>
>> Not ready. The document contains a lot of minor niggles and nits plus a
>> major item that I am not sure the IETF should support: this is the removal
>> of all mention of mandatory to implem
: draft-ietf-ipsecme-ikev2bis-10.txt
Reviewer: Elwyn Davies
Review Date: 4 May 2010
IETF LC End Date: 18 March 2010
IESG Telechat date: 6 May 2010
Summary:
When I reviewed this document at IETF Last call, I discovered that compared to
previous documents, it contains no mention of mandatory to
-send-name-type-registry-03.txt
Reviewer: Elwyn Davies
Review Date: 14 May 2010
IETF LC End Date: 14 May 2010
IESG Telechat date: (if known) -
Summary:
Probably not ready. There seems to be a conflict or confusion between the
prescriptive specification of a single algorithm for how the Subject Key
On Tue, 2010-12-14 at 18:19 -0800, Stuart Cheshire wrote:
> On 23 Nov 2010, at 7:15 AM, Elwyn Davies wrote:
>
> > Summary:
> > This document has at least one open issue that I believe needs
> > fixing, either by altering the scope of the applicability of the
&g
On Fri, 2010-12-31 at 12:52 -0500, Marshall Eubanks wrote:
> On Dec 31, 2010, at 1:41 AM, Fred Baker wrote:
>
> >
> > On Dec 30, 2010, at 1:09 PM, Robin Uyeshiro wrote:
> >> The GPS in the rental car (rented in Munich) did not have the street
> >> information for Prague.
> >
> > It's not unusual
-monami6-multiplecoa-10.txt
Reviewer: Elwyn Davies
Review Date: 24 November 2008
IETF LC End Date: 17 November 2008
IESG Telechat date: (if known) -
Summary:
This document is almost ready for the IESG. It has a number of minor
issues plus a fair number of editorial nits.
I am sending the editirial
-monami6-multiplecoa-10.txt
Reviewer: Elwyn Davies
Review Date: 24 November 2008
IETF LC End Date: 17 November 2008
IESG Telechat date: (if known) -
Summary:
This document is almost ready for the IESG. It has a number of minor
issues plus a fair number of editorial nits.
I am sending the editirial
hris Dearlove has this problem. For the rest of us, it
remains a small risk along with the possibility of being mis-identified
or triggering some stupid profiling filter. A general level of paranoia
is probably justified, but I shan't be going over the top . Famous last
words? Of course,
I agree with this point. It would also be good to have 'parent' links
on these sub-pages.
I note that the same problem occurs if you select the 'Brief' option on
the menu.
[Q: will the 'customize view' be something one can select on startup
(e.g. by a ?string in the URL)? - I am not sure how us
Carsten Bormann wrote:
What we need is the ability to write drafts with a standard
issue word processor.
Why? I suppose if there were indeed a *standard* word processor,
this might
be feasible, but I think by "standard issue" you mean "commercially
available".
http://www.xmlmind.com/xmledi
-ipv6-deprecate-rh0-01.txt
Reviewer: Elwyn Davies
Review Date: 21/9/07
IETF LC End Date: 20/9/07
IESG Telechat date: (if known) -
Summary: This document is almost ready for the IESG. I have a couple of
essentially editorial comments below.
Comments:
s3: "IPv6 nodes **MUST NOT process** R
-bb-fec-rs-04.txt
Reviewer: Elwyn Davies
Review Date: 18 October 2007
IETF LC End Date: 25 October 2007
IESG Telechat date: (if known) -
Summary:
Almost ready for IESG. I found one very minor issue and a few editorial nits
(see below). I think a reference to a theoretical and/or algorithmic
-l2vpn-vpls-bridge-interop-02.txt
Reviewer: Elwyn Davies
Review Date: 19 November 2007
IETF LC End Date: 9 November 2007
Summary:
If I understand correctly, this document 'standardizes' the RFC 4464 s2.2
bridge model selection (it chooses #2) and bridge module functionality that
will ens
I also think that we must think positive about this.
We do need to try things out. I think we started our very first
experiments with Wireless LAN at IETF 46 in Washington (I am just trying
to find a museum to take the plug-in card Nortel sold(?) me that was
never any use afterwards (the old
-multidomain-pki-11.txt
Reviewer: Elwyn Davies
Review Date: 28 December 2007
IETF LC End Date: 1 January 2008
IESG Telechat date: (if known) -
Summary:
In general this is a well written and, as far as I can see, comprehensive
document. I have one major problem with it: it far exceeds the scope
scheduled for next weeks telechat, you
should liaise with your AD before making any changes.
Document: draft-ietf-manet-packetbb-11.txt
Reviewer: Elwyn Davies
Review Date: 18 January 2008
IETF LC End Date: 16 January 2008
IESG Telechat date: 24 January 2008
Summary:
This document is not ready for the
The information is available on the RFC Editor's web site at
http://www.rfc-editor.org/
The RFC Database in various forms such as
http://www.rfc-editor.org/rfc-index2.html tells you the status of each
RFC and the RFCs that are associated with it by
obsoletes/obsoleted/updated relationships etc
-netlmm-proxymip6-10.txt
Reviewer: Elwyn Davies
Review Date: 18 Feb 2008
IETF LC End Date: 20 Feb 2008
IESG Telechat date: 21 Feb 2008
Summary:
This document is well written and is in fairly good shape for submission
to the IESG.
There are a number of minor issues which ought to be fixed. I think
: draft-ietf-netlmm-proxymip6-11.txt
Reviewer: Elwyn Davies
Review Date: 29 Feb 2008
IESG Telechat date: 06 March 2008
Summary:
Version 11 resolves almost all of the issues and nits that I raised in the last
call review of version 10. There is one editorial matter to complete the 'eas
-smime-multisig-04.txt
Reviewer: Elwyn Davies
Review Date: 7 March 2008
IETF LC End Date: 7 March 2008
IESG Telechat date: (if known)
Summary:
Mostly fine except for a piece of unclear specification noted below and
a few editorial nits.
Caveat: I am not a security expert and this should not be taken
-rohc-rfc3095bis-rohcv2-profiles-05
Reviewer: Elwyn Davies
Review Date: 7 March 2008
IETF LC End Date: 20 March 2008
IESG Telechat date: (if known)
Summary:
The document is almost ready for the IESG. There are a couple of minor
issues that ought to be resolved as detailed below (especially
Sri Gundavelli wrote:
> Hi Elwyn,
>
> Sorry for the late reply. Thanks for reviewing the updated
> draft. We will address the two remaining issues. Please
> see inline.
>
>
>
No problem.. I am stuck in a hotel in Toronto, nit getting to IETF. :-(((
Snipped the first issue as that should be fi
-rserpool-policies-08.txt
Reviewer: Elwyn Davies
Review Date: 11 April 2008
IETF LC End Date: 14 April 2008
IESG Telechat date: (if known) -
Summary:
Sorry, guys! This document is not in good shape. I know it is, in a
sense, the bottom of the tree and somebody reading it would probably be
expected
-rmt-bb-norm-revised-04.txt
Reviewer: Elwyn Davies
Review Date: 15 April 2008
IETF LC End Date: 17 April 2008
IESG Telechat date: (if known)
Summary:
A well-written document covering some pretty complex ideas. Technically
ready for the IESG but a little up front explanation for the naive
reader
-rmt-bb-fec-basic-schemes-revised-05.txt
Reviewer: Elwyn Davies
Review Date: 18 July 2008
IETF LC End Date: 29 July 2008
IESG Telechat date: n/a
Summary:
Nearly ready for IESG. A few minor issues mainly with failure to
specify encodings and a couple of corner cases. A few editorial nits
noted
-forces-model-14.txt
Reviewer: Elwyn Davies
Review Date: 5 Setember 2008
IETF LC End Date: 8 September 2008
IESG Telechat date: (if known) -
Summary: Nearly ready for IESG. Generally this is a very well
constructed and written document dealing with a very complex problem.
There are quite a number of
-sip-media-security-requirements-07.txt
Reviewer: Elwyn Davies
Review Date: 10 October 2008
IETF LC End Date: 13 October 2008
IESG Telechat date: (if known) -
Summary:
This document is almost ready for the IESG. I have a couple of comments
and queries about the reasoning in a few of the requirements
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: draft-stjohns
se in the -06 draft is below.
Regards,
Mark
On 7/18/08 8:57 AM, "Elwyn Davies" <[EMAIL PROTECTED]> wrote:
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/
Kevin Loch wrote:
Sam Hartman wrote:
"secIETF" == IETF Secretariat <[EMAIL PROTECTED]> writes:
secIETF> *Only HTTP, SMTP, FTP, and DNS traffic are permitted
through an IPv6 secIETF> Native firewall (pings,
traceroutes etc. are dropped)
Please make sure that ICMP messag
Allegedly, if you have a booking in the IETF block, the Internet
connection is included for free.
/Elwyn
At the Delta Hotel there is no wireless in my room. There is a
wired connection for CDN$9.95 per 24 hours which has a reasonable
bandwidth at the current load.
Jeffrey Altman
_
Airport shuttles:
Unfortunately the Delta doesn't seem to qualify for a free shuttle. The
nearest is probably the Queen Elizabeth (900 boulevard Rene-levesque
Ouest) which is about 0.25 mile from the Delta..
Alternatives include riding to the central bus station and taking the
metro (Orange Line
Unfortunately the Delta doesn't seem to qualify for a free shuttle. The
nearest is probably the Queen Elizabeth (900 boulevard Rene-levesque
Ouest) which is about 0.25 mile from the Delta..
Alternatives include riding to the central bus station and taking the
metro (Orange Line, direction Cot
Minor clarification in case your ethics are troubling you...
Elwyn Davies wrote:
Airport shuttles:
Unfortunately the Delta doesn't seem to qualify for a free shuttle. The
nearest is probably the Queen Elizabeth (900 boulevard Rene-levesque
Ouest) which is about 0.25 mile from the Delta..
Hi.
Maybe I wasn't paying attention but I don't recall seeing messages about
this on either the ipv6 or v6ops mailing list. I guess you may have
asked around but I'm sure somebody in the wg's could have helped if a
public request was made (especially the ndproxy authors).
Be that as it may,
A couple of nits:
s3: It might be helpful to make the first three paras into a bulleted
list and add an introductory sentence like:
'There are various ways in which an extension to an IETF can be
introduced into the IETF:'
s3, para 3: If my understanding is correct, a document from the normal
Search for Praha postcode 18600 or the Florenc metro station which is
just nearby (slightly south of hotel).
Link to maps centred on hotel:
http://www.multimap.com/map/browse.cgi?lat=50.0922&lon=14.439&scale=5000&icon=x
(links to some hotels relatively nearby)
www.mappy.com finds about 30 hotel
-webdav-rfc2518bis-17.txt
Reviewer: Elwyn Davies
Review Date: 30/01/2007
IETF LC End Date: 21/01/2007
IESG Telechat date: (if known) -
Summary: Apologies for the late review - I missed the aassignment somehow.
This document is almost ready for the IESG. There are a couple of
issues which need a
-crisp-iris-dchk-06.txt
Reviewer: Elwyn Davies
Review Date: 10 February 2007
IETF LC End Date: 21 February 2007
IESG Telechat date: (if known) -
Summary:
The document itself maybe nearly ready for IESG apart from a few
editorial nits (see below). However there are a couple of issues with
associated
Just to clarify the current situation...
The statement below says that the recommendation is for RFC 2766 to be
reclassified to experimental.. As is implied by the title of the draft,
it actually recommends reclassification to Historic.
This error results form a piece of history ;-) - The dr
Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so lets get rid of
NAT rather than trying to make NAT work.
NAT-PT is not NAT. It does a whole lot more, but it *cannot* do what it
claims to do completely, because the semantics on the two sides are
John C Klensin wrote:
(off list)
--On Tuesday, 06 March, 2007 15:46 -0800 Tony Hain
<[EMAIL PROTECTED]> wrote:
While I agree with Brian that the enterprise draft will be
difficult, I also believe the SOHO one will be virtually
impossible to get agreement over.
I agree, although I t
Fred Baker wrote:
On Mar 7, 2007, at 11:38 AM, Elwyn Davies wrote:
Also this appears to be tied to the US business model where the ISP
supplies you with the box and you don't get to change it (or even own
it).
Do they do that in the US? I'm not aware of it...
Maybe I am jus
Tim Chown wrote:
On Wed, Mar 07, 2007 at 12:23:21PM -0500, Ralph Droms wrote:
I visited Prague about two years ago and had the same experience as Ed. I
traveled via the Metro and on foot, visited all the tourist traps; had no
problems and never felt unsafe.
I second that. The metro
Brian E Carpenter wrote:
On 2007-04-06 08:12, Jari Arkko wrote:
Simon,
Maybe we can lobby for it to become the default.
+1
(I think it would be the right default, even if I agree with John
Klensin's concern.)
Putting symrefs into all the xml2rfc templates would not be a
bad idea.
The 'd
arrival of these comments.
Document: draft-ietf-sip-e2m-sec-05.txt
Reviewer: Elwyn Davies
Review Date: 18 May 2005
IETF LC End Date: 14 May 2005
IESG Telechat date: (if known) -
Summary:
I think this document needs a fair bit of work before it is ready to go to the
IESG.
The request to publish as
Christian Huitema wrote:
From: Noel Chiappa, Monday, July 02, 2007 6:08 AM
> From: [EMAIL PROTECTED] (Jun-ichiro itojun Hagino)
> if NAT-PT is to be made historic due to the claims presented in
the
> draft, all of the NAT related documents have to be made historic
> ...
-ipfix-implementation-guidelines-06
Reviewer: Elwyn Davies
Review Date: 20 July 2007
IETF LC End Date: 18 July 2007
IESG Telechat date: (if known)-
Summary:
Generally in good shape except that the use of RFC 2119 language is generally
inappropriate. In many cases the uses of MUST represent
-ccamp-inter-domain-pd-path-comp-05.txt
Reviewer: Elwyn Davies
Review Date: 16 Aug 2007
IETF LC End Date: 16 Aug 2007
IESG Telechat date: (if known) 23 Aug 2007
Summary:
I think this document needs significant work on the core description of the
algorithm. I found s4 to be difficult to read and it
This is indeed a bizarre thread..
As a near neighbour (UK), I can tell you that 2003 was indeed exceptional
across most of Europe. My home area north east of London was reduced to a
desert by the end of August, and there were some accelerated deaths due to
heat exhaustion.
Things reverted to t
Hi.
Scott Brim is doing the main (gen-art) review of this document but I
started so here is my twopennorth...
I have come to this with relatively fresh eyes since I have stayed out of
the governance discussions since my work on the problem WG a while back and
have only just started following th
At 17:42 24/01/2005, Harald Tveit Alvestrand wrote:
There has apparently been no comments on these I thought I'd make a
pass...
Some thoughts:
S1, para 3: s/Such support includes/The support for current work includes/
this works either way for me - "current" seems to say "the next sentences
<>
> Real serious issues seem to be waved away. To my opinion, one
> threat to the international nature of the IETF are the continuous
> increasing difficulties entering the US. This morning I read in the
> local papers that starting the 25th of october the Visa-Waiver
> program will grind to a
A bit more input on this subject...
It appears that (as one could have predicted) trying to get this piece of
universal technology in place in < 10 years is going to be difficult. It
appears that there is a limited agreement on content (actually a digitized
mugshot) but very little on the nature
FYI I am an ex-Word user, now fully converted to xml2rfc.
I thought Word was a convenient way to conform to Draft style and handle
revision control but was frustrated by the toolchain. The main problem I
found was the badly broken 'Generic Text Printer' driver which has not
worked properly for a
As I had already written to the original enquirer privately, I agree that
the research needs the 'design diary' aspects as well as the output
snapshots.
The lack of a permanent archive for some of the mailing lists will be a
problem for historians and others looking back on the IETF process. Perso
indow closes!
Regards,
Elwyn
> -Original Message-
> From: Stewart Bryant [mailto:[EMAIL PROTECTED]
> Sent: 08 April 2005 14:11
> To: Elwyn davies
> Cc: 'Brian E Carpenter'; [EMAIL PROTECTED]; 'Bruce Lilly'; 'Alex
> Rousskov'; ietf@ietf.
age-
> From: Lars-Erik Jonsson (LU/EAB) [mailto:[EMAIL PROTECTED]
> Sent: 08 April 2005 14:01
> To: Elwyn davies; Stewart Bryant; Brian E Carpenter
> Cc: Alex Rousskov; Bruce Lilly; [EMAIL PROTECTED]; ietf@ietf.org; IETF
> TOOLS discussion
> Subject: RE: Last Call: 'Requirements
Of course with use of SNAP in the last yard, we needed a higher throughput
solution for the backbone and as of yesterday we have it ...
An Airbus 380 full of 4.7GB DVDs... only problem is limited number of
available terminals ;-) 100 yard wingspan... watch where you are turning!
I have started a
Thanks.. certainly seems to work with Mozilla Thunderbird.
Regards,
Elwyn
Eliot Lear wrote:
For the daring, there is http://www.ofcourseimright.com/~lear/ietf63.ics.
I claim no competence in any of this. No responsibility if you miss
your meetings. No promises to update it. But it works fo
Actually to be more precise it works with Mozilla Firefox 1.0.6 with the
calendar plug-in.
Regards,
Elwyn
Eliot Lear wrote:
For the daring, there is http://www.ofcourseimright.com/~lear/ietf63.ics.
I claim no competence in any of this. No responsibility if you miss
your meetings. No promis
It reads in to Thunderbird OK, but the result is less pretty than
Eliot's effort. Eliot's version appears to lay out the multiple events
in a partcular timeslot evenly across the available space, whereas
Bill's results in different sized blocks and in some cases some of the
events appear to be
Absolutely... Be that as it may, I was intrigued as to why Thunderbird
did such a different job on the two files. A quick look at the code did
not help.
Anyway thanks for the effort.. very useful!
Regards,
Elwyn
Eliot Lear wrote:
Bill,
I couldn't agree with you more regarding multiple ov
Hi.
I did a quick read of this document and have a couple of general
comments (plus I spotted a very few trival nits).
It seems to be a very useful survey of what has been done in the area of
Wireless LAN and the interactions of link indications for hosts
connected directly to such links. Th
Johan: I imagine you have seen this paper on the subject of a p2p DNS
substitute based on CHORD, but it is interesting reading for others.
http://www.cs.rice.edu/Conferences/IPTPS02/178.pdf
Regards,
Elwyn Davies
Johan Henriksson wrote:
On Fri, Sep 30, 2005 at 08:45:29AM +0200,
Johan
Ole Jacobsen wrote:
On Thu, 13 Oct 2005, Hallam-Baker, Phillip wrote:
How about adding that the mean outdoor temperature at the time of the
year the meeting is being held should be above 0 degrees Centigrade?
Why?
There is some logic in this.. Participants need to be able to get
Jari Arkko wrote:
Elwyn Davies wrote:
There is some logic in this.. Participants need to be able to get
from airport to hotel to venue on foot/public transport without
needing to bring excessive personal protection gear that they might
not otherwise own, or experiencing heat stroke
Roland
Looking at the RFC Editor queue, it looks as if this is the only
document in the complex web of interdependencies between rfc2401bis and
ikev2 and their related documents that is still in the EDIT state. All
the others appear to be in REF state waiting for it to finish editing.
Why t
but I thought I would ask.
Appendix A: I was somewhat surprised that this section doesn't
explicitly mention any software used as part of the operations and
process. Maybe this is covered by some other part of the IASA agreements?
Regards,
Elwyn Davies
Seconded.
I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.
It is also very helpful for proof reading and commenting (spell checker
provided).
And the standar
Seconded.
I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.
It is also very helpful for proof reading and commenting (spell checker
provided).
And the st
Joe Touch wrote:
Elwyn Davies wrote:
I used to use the Word template but the freedom from hassle of
generating the final documents
I'm not sure what freedom this means; XML still needs to run through a
script, just as Word does.
you can't do it from inside Word
really a very wise way
to go.
Bob Braden
=====
regards,
Elwyn Davies
Marshall Eubanks wrote:
While we are on the subject, in the archives of the IETF there are
proceedings of one Internet Architecture Task Force meeting, in May,
1986.
Can anyone fill me in on this entity a
[EMAIL PROTECTED] wrote:
Can you imagine if during every murder trial they had a debate on the
humanity of capitol punishment?
As a non-US citizen, I am a little hazy about some details of the US
legal system. Do I assume that this punishment requires the malefactor
to sit through a set
Hi.
One additional piece of information relating to drafts that ism't
included in the drafts database is the location of the issue tracker (if
any). They aren't all in one place at the moment which makes life more
difficult than necessary for the casual inspector... for example...
- I was j
Finding out what BOFs are being plotted is not very easy AFAIK. In the
case below there doesn't appear to have been any widespread public
announcement of the start of the mailing list and I suspect that is the
case for many others.
Obviously an announcement of intent to the IETF list or the A
Hi.
Tom.Petch wrote:
The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a
different sense within RFC to that which I see defined elsewhere; and this
could lead to a reduction in security.
Elsewhere - dictionaries, encyclopaedia, text books - I see it
defined so that w
--- Original Message -
From: "Elwyn Davies" <[EMAIL PROTECTED]>
To: "Tom.Petch" <[EMAIL PROTECTED]>
Cc: "ietf"
Sent: Friday, February 17, 2006 8:19 PM
Subject: Re: 'monotonic increasing'
Hi.
Tom.Petch wrote:
The
I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Document: draft-hartman-mailinglist-experiment-01.txt
Intended Status: Experimental (RFC3933 Process Experiment)
Shepherding A
Bill Strahm wrote:
Robert Elz wrote:
I cannot see why there's a debate going on here. If someone, anyone,
can read a spec, and, in good faith, point out a possible ambiguity in
the text, before the doc is finalised, and if fixing it to avoid the
problem is easy, what possible justification ca
alf of para 1 and para 2 of s4.
==
Thoughts?
Regards,
Elwyn
Sam Hartman wrote:
"Elwyn" == Elwyn Davies <[EMAIL PROTECTED]> writes:
Elwyn> I was selected as General Area Review Team reviewer for
Elwyn> this specification (f
Hi.
Sam Hartman wrote:
I am happy to make a change similar to the one you propose in section
1.
I'm happy to split the parts of section 4 dealing with what the IESG
might do into their own section as an example.
That's fine by me.. it should make a self-consistent document.
I do not want
08.txt
Reviewer: Elwyn Davies
Review Date: 22 Jan 2013
IETF LC End Date:25 Jan 2013
IESG Telechat date: (if known) -
Summary: In my opinion, this draft has serious issues as described
below.
Major issues:
General 1: Title vs Abstract vs Section 1 vs actual content:
Here in the UK a well-known br
+1 to Mary's comments.. few words in line..
Elwyn Davies
On Mon, 2013-03-04 at 09:11 -0600, Mary Barnes wrote:
> On Mon, Mar 4, 2013 at 7:39 AM, Eric Burger
> wrote:
> > There is obviously no easy fix. If there was, we would have fixed it,
> > obviously.
> >
&
Hi.
Thanks to Dale for the new search plugins - useful.
I made these other ones that get RFCs and use the tools.ietf.org HTML
page to find sets of drafts from a few words. They were originally
published on the tools discuss list about 19 months ago.
Download the attachments into the searchplu
Submission allowed; publication postponed?
/Elwyn
On Thu, 2013-03-07 at 10:34 +0100, Carsten Bormann wrote:
> Oh, and one more data point:
>
> The Internet-Draft archive also functions as a timestamped signed public
> archival record of our "inventions".
> (Which are often trivial, but triviali
Hi, Russ.
Two points:
On Tue, 2013-03-19 at 22:30 -0500, David Farmer wrote:
>
> Rereading things again, I have another suggestion;
>
> 4) Split the Goals of the Internet registry system out of the
> Introduction. The Intro starts out talking about the document, its
> goals, and what is in s
On Sun, 2013-03-24 at 22:23 -0400, Joel M. Halpern wrote:
> I think I at least partly disagree. The acknowledgements section of
> RFCs was not, and to the best of my knowledge is not, concerned with
> capturing the history of where specific changes or ideas came from. It
> ought to be concerne
Right.. they are mind expanding drugs. Essential for keeping us sane.
/Elwyn
Sent from my ASUS Pad
"Stewart Bryant (stbryant)" wrote:
>
>
>Sent from my iPad
>
>On 6 Apr 2013, at 14:04, "Abdussalam Baryun"
>wrote:
>
>>
>> If the date is
>> special then thoes RFCs SHOULD be *historical*.
>>
On 15/04/13 15:45, Brian E Carpenter wrote:
On 15/04/2013 15:23, Ted Lemon wrote:
...
So in practice, although I feel great sympathy for this position, I think it's
mistaken. I want the other ADs to comment on anything that they notice that
looks like a problem.
There's an important class
On 01/05/13 21:05, Brian E Carpenter wrote:
On 02/05/2013 05:59, Dave Crocker wrote:
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I think t
On 01/05/13 21:05, Brian E Carpenter wrote:
On 02/05/2013 05:59, Dave Crocker wrote:
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I think t
On Fri, 2013-05-03 at 14:27 +0100, Stephen Farrell wrote:
> On 05/03/2013 01:59 PM, Thomas Narten wrote:
> >
> > If you look at the delays documents encounter (both in WG and in IESG
> > review), the killer is long times between document revisions. Focus on
> > understanding the *why* behind that
Both links work just fine from a selection of browsers/os/machines other
than Msoft. (Firefox, Evolution, Chrome) It also works on an old
version of IE8 but reports errors.
Presumably turning off some strict error checking in IE allows it to
display.
Running the page through the W3C HTML validat
Similarly, AFAICS the 'IESG time' includes IETF last call and the
inevitable delay caused by the quantized nature of IESG teleconferenes.
On the average, this will be somewhere around 28-30 days (2 or 4 weeks
in Last call according to document type plus an average of 1 week until
the earliest poss
On 31/05/13 20:18, Scott Brim wrote:
On Friday, May 31, 2013, Dave Crocker wrote:
On 5/31/2013 8:12 PM, Scott Brim wrote:
We'll have multiple airships, one for each set of related
meeting rooms.
is dirigible a new term of endearment for an AD?
Obviously the ADs have
viewer: Elwyn Davies
Review Date: 5 June 2013
IETF LC End Date: 5 JUne 2013
IESG Telechat date: (if known) -
Summary:
Almost ready. Generally this is an excellent and well written document,
particularly given its size. There are a few minor issues to sort out
mainly at the nit level and some consi
an end point and not been explictly paused
and STARTING/PAUSING states in the client while the client waits for
response to PLAY/PAUSE respectively. I think a little bit more
explanation about the dual nature of the columns would solve the
problem.
Appendix C: Pending.
Regards,
Elwyn
>
1 - 100 of 120 matches
Mail list logo
