On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote:
I've already indicated this in previous occasions, but may be not in ppml
...
We are proceeding in parallel, with the ID and the PDP at the same time.
Nothing in the PDP precludes doing so.
The RIRs don't depend on IETF at all, they can define
On 2007-05-11 16:14, Fred Baker wrote:
...
One technical question I would ask. What does a Central Authority and
IANA Assignment have to do with a Local address of any type? It
seems in context that the major issue is an address prefix that is not
advertised to neighboring ISPs and can be
On 2007-05-14 16:08, Shane Kerr wrote:
Brian,
On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote:
On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote:
The RIRs don't depend on IETF at all, they can define global
policies for things that the IETF failed to complete if that's
I don't see any reference to the reports to Plenary at each IETF meeting
(both the short report presented on stage and the longer reports posted
to the wiki).
I liked it at the beginning when the IAOC also put out a short monthly
email to the community. Even though the pace of events may be less
On 2007-04-20 23:58, Theodore Tso wrote:
On Fri, Apr 20, 2007 at 04:56:38PM -0400, Jeffrey I. Schiller wrote:
But the more serious case involved IPSEC. The situation was thus:
~20 people for one proposal.
~20 people for a different proposal
~150 people for someone please decide so we can go
On 2007-04-20 12:07, Frank Ellermann wrote:
Spencer Dawkins wrote:
- what we tell the WG chairs is that ADs have the power to make a decision
for the working group, in order to break a deadlock. Jeff Schiller (one of
the ADs who did the WG chair training for several years) was very clear
that
On 2007-04-20 14:44, Scott W Brim wrote:
On 04/20/2007 08:35 AM, Brian E Carpenter wrote:
It seems fairly clear in RFC 2418 section 6.1:
The Chair has the responsibility and the authority to make decisions,
on behalf of the working group, regarding all matters of working
group process
On 2007-04-20 09:21, Hannes Tschofenig wrote:
DHCP is not a great choice in a mobile environment and also not when it
comes to more complex location representations.
Why can't a mobile system have a locally valid DHCP record (+/- the length
of a wireless link)? For that matter, why couldn't a
I want to make three peripheral comments.
1. I congratulate the ADs for bringing this to the general list.
If we habitually resolve such difficulties openly, we strengthen
the IETF going forward.
2. I think we have a general problem of assuming that issues
decided in the meeting room and
Simon,
Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having sent a postcard for the
style of RF license you are objecting to?
Brian
___
Ietf mailing list
Ietf@ietf.org
On 2007-04-11 10:08, Simon Josefsson wrote:
Brian E Carpenter [EMAIL PROTECTED] writes:
Simon,
Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having sent a postcard for the
style of RF license you are objecting to?
Brian, two responses:
1
Simon,
4.3. Example License Text
Here is a simplistic patent license that would grant third parties
the necessary rights in order to use it in free software.
X grants a worldwide, non-exclusive, fully-paid,
perpetual, royaltee-free patent license to
On 2007-04-11 11:34, Arnt Gulbrandsen wrote:
Just one comment:
Brian E Carpenter writes:
On 2007-04-11 10:08, Simon Josefsson wrote:
What typically happens in practice, among good-faith
practitioners, is that there won't be any GPL (or Apache, or
Mozilla, or ...) implementation
Ted,
Well, if IPR owners don't actually care, why are they asking people to
send a postcard? It would seem to be an unnecessary administrative
burden for the IPR owners, yes?
My assumption is that they care if the party that fails to send
a postcard is one of their competitors. That's what
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. If you want to suggest a change in
On 2007-03-31 17:15, Eliot Lear wrote:
Jeff,
As for informational vs an independent submission, I think there is a
factor to be considered. It seems to me that an informational IETF
document is a fine way to say this is a good idea, and we think this
is the right way to do FOO, but we can't
Who else is here from Nokia?
The final version in the Proceedings does have affiliations:
http://www3.ietf.org/proceedings/06nov/index.html
but I agree that is a bit late for finding people on-site.
Taking this one step further, perhaps we could get the ICANNwiki folks
to create a photo
My personal opinion is that IETF would be taking a large risk
by doing anything like this. Certification carries serious
legal implications and therefore creates serious potential
legal risks for the certifier. That needs a completely different
type of organization than the IETF. I think we
On 2007-03-14 04:29, David Kessens wrote:
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
On 2007-03-13 20:43, Cyrus Daboo wrote:
Hi Robert,
--On March 13, 2007 3:23:22 PM -0400 Robert Sayre [EMAIL PROTECTED]
wrote:
This text is actively misleading, because it suggests RFC 4346 is
included for informational purposes. The text should read:
At a minimum, client and server
On 2007-03-14 15:17, Pekka Savola wrote:
On Wed, 14 Mar 2007, Brian E Carpenter wrote:
Just to confirm: 2818 has already been downrefed so it can be used in
this way without further formality.
http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
There appear to have been two kinds
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
It is reported by The Economist dated March 10 that if you buy duty free liquids outside Europe, carry them on the plane with
you, and have to go through airport security while changing planes in Europe, your liquids will be confiscated, assuming they
exceed 100 ccs.
Europe in this case means
When considering the Last Call comments, the IESG finally
concluded that this document should be published as an ION.
Other Last Call comments will result in editorial changes.
Brian
___
Ietf mailing list
Ietf@ietf.org
think that this architecture is a lot more disciplined than what we have
today. It observes the encapsulation property / layering principle much better.
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 9:57 AM
To: Hallam-Baker, Phillip
On 2007-03-08 02:06, Hallam-Baker, Phillip wrote:
OK I will restate.
All connection initiation should be exclusively mediated through the DNS and
only the DNS.
Would that include connections to one's DHCP server, SLP server, default
gateway,
and DNS server?
Hmm...
Brian
I won't ask how many we have in the Czech Republic :-)
But we have a few hundred for whom it's a short flight
and part of the same political and socio-economic block.
Brian
___
Ietf mailing list
Ietf@ietf.org
Hi folks,
North America changes to Daylight Savings Time this weekend 10/11 March.
Europe changes two weeks later, 24/25 March, immediately after the IETF.
This has consequences.
1. During those two weeks, the time difference between North America
and Europe will be one hour less than usual.
On 2007-03-07 16:58, Marshall Eubanks wrote:
I have been to Prague 3 times in the last 5 years. It is quite survivable.
However, the taxi's are ... unregulated. I would suggest that IETFers
never take a cab on
the street. You may pay 50 Euros to go 1 km. Get the hotel, store,
restaurant,
Noel,
On 2007-03-04 22:36, Noel Chiappa wrote:
From: Brian E Carpenter [EMAIL PROTECTED]
the problems that NAT causes, and that having suffcient address space
(a.k.a. IPv6) solves
This comment seems to posit that insufficient address space is the only thing
driving deployment
in both cases. Even draft-ietf-v6ops-nap took many moons
and several major editing passes, and it only starts the work.
Brian
On 2007-03-04 22:39, John C Klensin wrote:
--On Sunday, 04 March, 2007 20:05 +0100 Brian E Carpenter
[EMAIL PROTECTED] wrote:
Michael,
On 2007-03-02 16:19, [EMAIL
Michael,
On 2007-03-02 16:19, [EMAIL PROTECTED] wrote:
...
No real disagreement here but I do see a way forward. First, clarify the
terminology. Second publish a pair of RFCs rather like 1009 entitled
Requirements for Consumer Internet Gateways and Requirements for
Enterprise Internet Gateways.
On 2007-03-02 17:09, Hallam-Baker, Phillip wrote:
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
This is of course one of the major motivations for
draft-ietf-v6ops-nap-06.txt, which is now in the RFC Editor's
queue. While it doesn't tell SOHO gateway vendors exactly
what to do, it does
On 2007-03-01 18:57, John C Klensin wrote:
...
I continue to believe that, until and unless we come up with
models that can satisfy the underlying problems that NATs
address in the above two cases and implementations of those
models in mass-market hardware, NATs are here to stay, even if
we
On 2007-02-28 17:02, 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.
This is startlingly irrelevant to the present document. We have a large corpus
of documents about the issues caused by NAT
I think it's important to publish this document, to make it
clear why NAT-PT is a solution of very dubious value.
Brian
On 2007-02-27 20:14, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Reasons to Move NAT-PT
in recommendation has been necessitated because it appears that RFC 2026
does not allow the transition to experimental. In the meantime it has
become ever more clear that NAT-PT is of dubious value and could limit
the development of IPv6 over time.
Regards,
Elwyn
Brian E Carpenter wrote:
I think it's
On 2007-02-26 07:51, Eliot Lear wrote:
Sam Hartman wrote:
My strong preference as an individual is to approve this document as
is. I think there's a good split between RFC 3967 and this document.
RFC 3967 will cover informational documents; this document will cover
standards track.
I'm not in
I believe that if we follow the authors' suggestion
to proceed rapidly, Tom's concern could be met by
a simple informational note summarizing how to deal
with downrefs in practice. Such a note could be input to
an eventual combined document after some experience,
as John suggests.
Brian
On
On 2007-02-21 17:07, Tony Finch wrote:
On Wed, 21 Feb 2007, Brian E Carpenter wrote:
Blacklists at the level of sending domains (or reputation systems
that function like blacklists) are a failure.
I was talking about IP address blacklists.
Right. That can work, of course.
Perhaps 90
The level of bulk unsolicited messages exceed more than 90% of the volume in
many cases
I estimate 95% of moderated non-member mail that hits the IESG list to be b.u.m.
Brian
___
Ietf mailing list
Ietf@ietf.org
On 2007-02-20 15:31, Fred Baker wrote:
On Feb 20, 2007, at 8:15 AM, Georgios Karagiannis wrote:
I assume that you also have no objection on using the DSCP fields for
this purpose.
actually, I do, at least in some ways that they might be used. The AF
service (RFC 2597) is specifically
On 2007-02-19 00:57, Michael StJohns wrote:
At 06:29 PM 2/18/2007, Janet P Gunn wrote:
My guidebook says 6 months.
Feel free to argue with the US State Dept.. :-)
The US State Dept web info is inconsistent with the Czech Embassy
web info. We are trying to get definite confirmation from
On 2007-02-18 13:46, Tony Finch wrote:
On Sun, 18 Feb 2007, Harald Tveit Alvestrand wrote:
If this was effective, blacklists would have solved the spam problem.
They are 90% effective
You what? Which Internet would that be?
Blacklists at the level of sending domains (or reputation systems
Hi,
As devoted readers may have noticed, quite a few Gen-ART reviews
have been copied to this list recently, with follow-up postings
in some cases.
Is this a good or a bad thing?
Comments welcome.
Brian (as General AD)
___
Ietf mailing list
Frank,
Don't they also set the pubreq bit in the I-D tracker ?
Very possibly, but that is just a progress tracking issue.
I agree we need a progress tracking mechanism, but that
isn't the underlying point here, which IMHO is to get the
author in discussion with the appropriate AD.
Brian
Frank
On 2007-02-10 01:07, Frank Ellermann wrote:
... I don't like this draft, send publication
request to secretariat is more attractive than spamming ADs.
You probably need to understand what happens when someone
does that. The Secretariat simply forwards the note to the
IESG. After a
- I'm lost about why we would continue to publish Informational process
RFCs (ignoring any existing pipeline of process documents remaining to
be published as RFCs).
To me the argument for making this one an RFC is mainly that it
fits together with the two other drafts mentioned previously,
Frank,
On 2007-02-09 17:04, Frank Ellermann wrote:
Jari Arkko wrote:
I would be happy to sponsor a ternary bit draft, but only on
April 1 :-)
What I don't like in your draft is the (apparent) personal veto
right for the AD. Authors (hopefully) have an idea about their
topic, but they
On 2007-02-08 01:25, Frank Ellermann wrote:
John C Klensin wrote:
If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION
John,
On 2007-02-08 00:02, John C Klensin wrote:
Hi.
I will get to substance in a separate note, and hope others will
also. In the interim, two procedural remarks...
(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the how a document that does not
originate
John,
On 2007-02-08 13:16, John C Klensin wrote:
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
[EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because
On 2007-02-08 14:05, Scott O. Bradner wrote:
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no
On 2007-02-01 20:06, Frank Ellermann wrote:
Brian Carpenter wrote:
http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html
I liked the I-D better, the xml2rfc HTML output is hard to read.
Really? I find the links in the HTML version invaluable.
For an ION you could probably remove
I'm going to No Objection and I suppose you'll do an RFC Editor note.
Brian
On 2007-01-30 16:39, Mark Townsley wrote:
On second look, this is rather small. Vipin, I can do either. If you
wish to provide me text in OLD NEW format, or a new document.
- Mark
Suresh Krishnan wrote:
I am
On 2007-01-31 18:47, John C Klensin wrote:
--On Wednesday, 31 January, 2007 17:02 + Steven M.
Bellovin [EMAIL PROTECTED] wrote:
On Wed, 31 Jan 2007 11:54:26 -0500
John C Klensin [EMAIL PROTECTED] wrote:
Except for the fact that the material being cited contains the
specifics of license
On 2007-01-31 00:35, Ned Freed wrote:
...
More generally, I have a problem with normative cituations to BCP and STD
numbers since the underlying document can change. That's arguably OK for an
informational citation, but IMO normative references may have version
dependencies that need to be taken
I also noticed providessuggestions as a typo, which does make me
wonder - we rely on the RFC Editor for proof-reading, but we're not
sending IONs to the RFC Editor. Is there a plan?
IONs are less formal, so I think the honest answer is no. And
we are certainly not going to apply any style
On 2007-01-29 18:08, Spencer Dawkins wrote:
I should begin by thanking Brian for producing this document, both
originally and in ION format.
An ION (IETF Operational Note, see RFC 4693) is open for public comment
on the ietf@ietf.org list. Comments should be sent by 2007-02-12.
Please see
On 2007-01-30 13:59, Spencer Dawkins wrote:
snip
What I'm talking about is that if you type in BCP 9 in the RFC Editor
search engine, the only RFC that pops up as part of BCP 9 is 2026, but
the RFC Index says Updated by RFC3667, RFC3668, RFC3932, RFC3979,
RFC3978.
This is a special case,
When I was in school, I was taught to quote multiple paragraphs with
quotes at the start of each and a closing quote only at the end of the
final paragraph.
So was I, but whether or not this is a typo doesn't affect what you
put in an I-D, which doesn't have the quotation marks anyway,
except
On 2007-01-18 09:49, Tom.Petch wrote:
Who is shepherd for an individual submission?
The sponsoring AD. However, draft-iesg-sponsoring-guidelines
(which will be updated shortly, so don't worry about
its terminology issues) adds:
Once the AD has agreed to sponsor a document, the authors need
We're rapidly approaching diminishing returns here...
On 2007-01-16 21:17, Michael Thomas wrote:
Brian E Carpenter wrote:
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
On 2007-01-17 16:41, Dave Crocker wrote:
Brian E Carpenter wrote:
I think you are deeply misunderstanding how PROTO shepherding is
supposed to work.
That's a pretty basic disconnect.
Perhaps you can summarize how it is supposed to work?
The way it's described in draft-ietf-proto-wgchair
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 answer
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
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
On 2007-01-13 12:32, Adrian Farrel wrote:
Hey, I had promised to keep out of this having already used my quota of
emails for the months, but then Fred said...
That said, I _do_ wish the tracker would maintain history of DISCUSS
and COMMENT comments, instead of only showing the latest ballot
On 2007-01-12 09:54, Pekka Savola wrote:
Well, it seems rather common that IETF LC comments (especially if not
copied to ietf@ietf.org list) are not responded.
Firstly, this is the reason we recently made some minor changes
in the text of the IETF Last Call messages, and why you will see a
I haven't seen an announcement of the new-style Last Call text, only its
use on specific recent last calls (I saw it on 12/22 Last Calls, so it's
pretty recent). If you have also seen so many Last Call e-mails that you
no longer actually read them, you might not have noticed the new text
While more information is always good, I'll note that it's linked to
from the WG Chairs page; it, in turn, is listed on the IETF home page.
There's also a link from each WG's charter page to the status page
which lists every document from the WG and its status. The status
field, in turn, is a
Cutting to the chase:
How about allowing PROTO shepherds to post to the I-D tracker?
See whether draft-ietf-proto-wgchair-tracker-ext-01.txt
covers what you want. If not, immediately would be
a very good time to tell the PROTO team.
Brian
___
On 2007-01-09 14:03, Hallam-Baker, Phillip wrote:
...
The tracker is not mentioned in any of the process documents
That is normal; it's a tool used in support of the process,
and we could in theory use papyrus rolls instead.
I agree we need procedural documents too; that is
what IONs are for
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 answer.
Sometimes it can be quickly resolved (for
On 2007-01-05 20:55, John C Klensin wrote:
...
I have two questions...
(1) Do you have evidence of actual situations in which an AD
behaved in this way, kept concerns to him or herself, and then
raised them only, and for the first time, via a DISCUSS after
Last Call?
How about a case where an
On 2007-01-08 12:03, Adrian Farrel wrote:
Brian,
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.
Brian, I am not suggesting that IESG has to do anything different. Let
them continue to
Could we drop the personal comments and rude words please?
The delete key is by far the easiest way to deal with drivel.
This is so clearly drivel that I hereby ask the sergeants at
arms to consider action against [EMAIL PROTECTED]
Brian
___
Ietf
On 2007-01-04 07:56, Robert Sayre wrote:
On 1/3/07, Brian E Carpenter [EMAIL PROTECTED] wrote:
...
It's always open to the WG to propose a resolution of the DISCUSS
that is radically different from what the discussing AD suggests,
too.
Yes, any group is free to try anything in the IETF
On 2007-01-04 14:32, John Leslie wrote:
I should be ashamed of myself -- letting myself get ensnared in a
flamewar with Keith...
First, let's restore some context. We're talking about
http://www.ietf.org/u/ietfchair/discuss-criteria.html
specifically section 3.1; and I was taking
I think we should give credit to Carl Malamud and Tony Rutkowski,
whe spent many months in Geneva at least ten years ago, sowing the
seeds for this move by the ITU.
Brian
On 2006-12-25 18:41, Marshall Eubanks wrote:
Since my Narten number has been rather low of late, and since
this
Is draft-iesg-discuss-criteria-02.txt a statement from the IESG of what
it is doing?
I think it is slightly more accurate to say it's a statement of
what we aspire to do.
If it is, what I would ask first is that the IESG commit to updating
this whenever they change the procedures.
On a
On 2006-12-29 17:44, Dave Crocker wrote:
Dave is probably correct that the specific criteria are of broader
interest than just ADs, WG chairs, editors, and process wonks, and
might become even more perfect with broader review, but that's another
issue.
And, since the criteria are public,
Michael,
On 2006-12-31 03:00, Michael Thomas wrote:
John C Klensin wrote:
If an AD who was responsible for a WG came up with an issue about that
WG's work and raised it only during or after Last Call, I'd expect
either a really good explanation or a resignation. I certainly would
not
-discuss-criteria
They have the same date.
On Dec 26, 2006, at 9:12 AM, Dave Crocker wrote:
Brian E Carpenter wrote:
But, Brian, the concern for costs ought to extend much farther, such
as to the kinds of issues raised by an IESG Discuss so that the AD
provides an explanation of the benefit
Dave,
Dave Crocker wrote:
Brian E Carpenter wrote:
In other words, Brian, by running the experiment, in its current
form, you are
ensuring that meaningful changes can't be made without disruption.
I truly don't get your concern. We have mechanisms today to get
operational material onto
I happened to choose the particular example of Discuss simply because it
is of immediate concern to me, but my point was intended, of course, to
be more general.
That's why your raising the 'cost' issue for the current discussion came
as such a confusing surprise.
Sorry to confuse: let me
BTW, www.mappy.com is pretty good for maps and itineraries in Europe.
Brian
John Levine wrote:
I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic
with online maps.
I believe hotel is toward the west end of the street, near the bridge
to the island in the river:
Henrik Levkowetz wrote:
Hi Dave,
on 2006-12-18 19:18 Dave Crocker said the following:
I assume that the nominee sub-section labeled GEN is really for the IETF
Chair?
Yes. I'll fix that in a moment.
Regardless of that fix, and as a non-candidate, I'll remind everybody
that my personal
Dave Crocker wrote:
...
So my suggestions are:
1. Move these Status pages out of the tools development area and make
them an official part of a working group's official pages.
That isn't simply a matter of wishing it to be so. It actually
involves work (to make the tools that generate these
Dave Crocker wrote:
Brian E Carpenter wrote:
As for you last sentence, perhaps it should give some pause. The
idea that we do not already have a pretty clear idea of what should
distinguish an I-D from an ION ought to engender concern. Like any
other project consuming significant
Dave Crocker wrote:
Brian E Carpenter wrote:
If this sort of experiment is successful, then there will be significant
disruption to the user base if the mechanism is moved to a new hosting
mechanism.
As stated in 4693, we'd simply keep them as web pages at www.ietf.org.
This
isn't
Dave Crocker wrote:
Brian E Carpenter wrote:
So internet drafts, however ephemeral we claim them to be, are
versioned and referenceable. I don't know that the final step (the
RFC) is any less permanent than the history we maintain of the
drafts leading up to it.
That's beside
Frank Ellermann wrote:
Brian Carpenter wrote:
Please see
http://www.ietf.org/IESG/content/ions/drafts/ion-ion-format.txt
It says text or html, but ion-ion-store is perfectly valid XHTML.
Is that a problem ?
I don't think so, do you?
The HTML output of xml2rfc is rather ugly with my
Fred Baker wrote:
This document describes a process for managing a set of documents.
IMHO, it is a bit onerous; I may be ignorant, but I don't know how to
get an account on tools.ietf.org,
Really? I thought most WG chairs had one by now. There is a button to
click on the tools web site.
John L wrote:
ICANN has not to date dealt very effectively with these issues, but
they are real issues that will have a great effect on people who use
the DNS every day, and they're not technical issues, since all of the
alternatives are equally feasible technically.
At its base, IDN is a
Fred Baker wrote:
On Nov 30, 2006, at 2:29 PM, Sam Hartman wrote:
There was very little support outside of those involved in the ieprep
working group for the ieprep work.
I'd have to say that there wasn't really a clear consensus in either
direction about much of anything.
I guess I'm
Eliot Lear wrote:
Brian,
1. There's a presumption that precedence and preemption are the
mechanisms - but those aren't requirements, they are solutions, and
it isn't clear to me that they can ever be appropriate solutions
in the upper layers of the Internet. The requirement is presumably
that
when it comes to the DNS.
Actually, no. It is always IANA. However, RFC 2860 section 4.3
specifically excludes the IETF giving IANA guidance in certain areas.
Brian
Carl
Brian E Carpenter wrote, On 29/11/2006 10:43:
your question is linked to whether we treat the namespace as a public
Emin Gun Sirer wrote:
Stephane Phillip,
I'm thinking of writing a short report that summarizes the invaluable
discussion here and beefing up the system sketch. I think we now agree
that it is possible to have multiple operators manage names in a single,
shared namespace without recourse to a
801 - 900 of 1719 matches
Mail list logo
