John,
You are absolutely right. Time should be spent developing "good
algorithms" which is common "good architecture". What NAT does is just
another form of the same thing that X.25, ATM, and MPLS do with different
identifiers. It is not bad algorithm there nor bad architecture.
This is
It is not the case that few WGs are holding meetings. The published agenda
just isn't complete yet; it never is at this stage.
This is very true. Looking at the Internet Area, I expect all but one
of the WGs that normally have face-to-face meetings to meet in
Adelaide. Plus, there are three
Oh, goody, another round of wasted time and energy arguing about
IPv6 and NAT boxes on the IETF list
So it seems. Too bad you couldn't just leave it at that without adding
another dose of gasoline to the mix.
Meanwhile, those of us who believe IPv6 is the best and most promising
way out of
John Stracke [EMAIL PROTECTED] writes:
Wasn't one of the design goals of IPv6 to make renumbering easier,
so that people could move from small assignments to large ones?
Yes. IPv6's primary tool in this regard is that it supports multiple
addresses simultaneously. To renumber, you add a new
Sean Doran [EMAIL PROTECTED] writes:
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA.
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the number of routing
It seems to me that the decision to just use NATv6 rather than
do a site-wide runumber will be a very easy decision to make.
Actually, if your assumption is that NATv6 is better than IPv6 with
renumbering, then IPv4 and NATv4 was good enough to start with and
there was need to move to IPv6 in
Sean,
Spamming the ietf list is bad form.
Trolling is no more appropriate.
Please take this elsewhere.
Thomas
[EMAIL PROTECTED] (Sean Doran) writes:
Brian Carpenter writes -
| Please, please, nobody ever pick a prefix at random.
Why not? The chances of collision are quite small.
On the other hand, some IPv6 advocates never stop beating the drums
for IPv6 QoS, multi-homing, and so forth and how the Millennium will
arrive with IPv6. I think the truth in both cases is not so simple
as either minor enhancment or dawning of a new age.
It is certainly regretful that
Sean does have a habit of asking questions that highlight the fact that
IPv6 isn't ready for wide-spread production deployment.
While I welcome Sean's input as a backbone operator, his long-running
disdain for IPv6 is also well known. Perhaps my previous response was
a bit hasty from this
Well, not really just the enlarged address space!
The enlarged address space is the *primary* benefit. While there are
certainly numerous other benefits, they are arguably secondary.
There do exist certain other definite benefits of IPv6 like possible
use of Flow Specifications in the Flow
Lloyd,
Just to be clear:
If you object to how the midcom elist is operating you need to take that
up with the midcom-admin and the relevant AD.
done. on cc. On open IETF lists, I have the right to post what you
deem to be rubbish, and you have the right to choose to ignore me (and
the
Are you refering to RFC 2563 (DHCP Option to Disable Stateless
Auto-Configuration in IPv4 Clients) or something else? We are looking at
using this mechanism and if there are issues with it, I want to make sure I
understand them...
You should look at
J. Noel Chiappa [EMAIL PROTECTED] writes:
From: TOMSON ERIC [EMAIL PROTECTED]
do you really think that the IETF people (et al.) built IPv6 without a
preliminary good consideration?
There are a lot of people in the IETF who think exactly that,
actually.
And there are a lot
To clarify a bit futher and explain the bigger picture...
How can this be issued with as a Proposed Standard RFC with a
field labeled TBD?
If the ID is approved to be published as a PS, the RFC editor will
work with IANA during the final stages of publication to ensure that
the TBD value
I am working on a distributed router and i want to run my own
proprietary protocol inside over the IP layer.
I'd first ask the question of why running directly over IP is
necessary. In most cases, running over UDP instead of IP is quite
satisfactory in practice, and doesn't require the
It might be worthwhile to investigate if 826 should be updated.
Somewhat related, there was a SEND BOF last week on securing IPv6's
Neighbor Discovery.
This AD has been asked to advance the individual submission
draft-cheshire-ipv4-acd-01.txt on the standards track. That document
proposes
.
These messages were direct responses to recent namedroppers
messages, the first by Thomas Narten, the second by Bush. Bush
sent both messages back to me, without saying explicitly what he
had done with them.
* 2000-02-20: I pointed out
namedroppers/2220195445-21265
To clarify a bit, based on followup mail.
AD hat was on in previous message, same here. I am not speaking for
the full IESG, however.
It was not my intent to imply that if messages did not get forwarded
to one list, but did on another, that this somehow was OK and couldn't
be censorship. It is
Aaron Swartz [EMAIL PROTECTED] writes:
4) Any held message that is later approved for distribution on the
mailing list should appear on the list as a normal posting (e.g.,
with the proper sender in the From address, etc.).
Later, however, you write:
[...] However, in
RJ Atkinson [EMAIL PROTECTED] writes:
On Thursday, Jan 23, 2003, at 17:54 America/Montreal, Bob Braden wrote:
I interpret IETF consensus as meaning that at least a Last
Call was conducted. To use any other interpretation seems to me to
be dishonest. I guess I am agreeing with Kireeti.
It would seem quite simple for you to take the text of RFC-2434,
edit the text appropriately to pick a more clear and accurate
term, then run it past the community for BCP.
Sure, this is easy. The harder part is that there are many many RFCs
that use the IETF Consensus terminology in their
John,
Thomas, not to be splitting hairs, but the intent --at least in
SMTP-EXT (STD10/RFC1869), which was cited as an example-- was
somewhat more than simple publication as an RFC (or, in your
words, a document that gets published as an RFC).
Agreed, now that I have gone and looked at RFC
Absolutely. Otherwise, this discussion wouldn't be worth the
trouble. But, if you are going to define IETF Consensus as
Publication as an RFC then
Since I don't seem to be able to make this clear enough, once again, I
do not and have never intended IETF Consensus, in the literal sense,
to
Michel,
There many people, including some that actually _wrote_ the procedures,
that disagree with you.
This is FUD. If there are people that agree with Tony's appeal, let
them speak for themselves. In all the email on this thread (and the
many conversations I have had with folk), I have had a
One reminder for those who may not know...
For those mirroring IDs and/or RFCs, both the Secretariat and RFC
Editor support rsync. If you are still using ftp for the mirroring,
rsync has a lot to offer.
http://www.ietf.org/rsync-help.html
http://www.rfc-editor.org/rsync-help.html
Thomas
Hi Danny.
IESG members whose terms are up are:
Thomas Narten -- Internet Area
As I have been telling folk informally for a while now, I am stepping
down as Internet AD with the ending of the current term.
I would like to encourage the community to look around and help the
nomcom find a good
Harald Tveit Alvestrand wrote:
But on mobility, I think we blew it.
Not sure if you are referring to the mobile IP technology in
particular, but because I suspect that the following is a bit of a
secret to the larger community, mobile IPv4 is actually deployed and
used. And end users mostly
Jeroen Massar [EMAIL PROTECTED] writes:
Just like the above, except that the chairs can see the email addresses
that people gave when they voted. They could then check this list
against the list that has actually been signed up on the wg's
mailinglist and filter out discrepancies, might
/\
Consensus: / \___
/\
Rough Consensus / \___/\___
Badly phrased question: ___/\/\/\/\___
Right. Like most techniques, voting is a tool. And like any tool, it
can be misused, or ineffective.
Voting breaks down when it is
[EMAIL PROTECTED] (Scott Bradner) writes:
But we *often* take straw polls in f2f meetings,
but we do not count hands - we look to see if there is a clear
difference between hands one way and or the other
I agree that this is exactly how we should be using hums/polls.
But I'm sure many of
I have one new root cause issue that I don't believe was included
in the original Problem Statement:
It takes too long to publish an RFC after final approval.
I agree with this. Over the last year especially, I'm seeing a
significant number of cases where it is taking much more time to
Eric A. Hall [EMAIL PROTECTED] writes:
On 5/10/2005 12:45 PM, Thomas Narten wrote:
One example (and I'm just using it because it was it comes to mind,
and one that I think is symptomatic of the broader problem):
October 15, 2004: IESG approves 4-document set.
Within one week: authors
Playing a bit of catch-up on this thread...
Alia Atlas [EMAIL PROTECTED] writes:
There is a difference between having participants who are interested in
providing feedback ask for a copy of the list, with a promise of
confidentiality, and give feedback - versus having that information
Well, there are always going to be judgement calls about whether something
is or isn't an end-run, which is where I would expect discuss
positions to come from on such documents.
Process-wise, this isn't right, IMO (which is where I suspect John is
coming from). Process-wise, the thing to do
Maybe it would be useful to talk about *necessary* slowness, also.
Indeed.
When I step back and ask what leads to the best specifications (and
indeed, documents in general), it is all rather simple:
1) produce a document.
2) get a small number of quality reviews.
3) revise in response to
Dave Crocker [EMAIL PROTECTED] writes:
So, what sort of support?
1. Much, much better charters. For example, we do not even try to
enforce the requirements specified in the Working Group Guidelines
RFC.
2. Much better oversight of new working group chairs, to ensure that
the group gets
Brian E Carpenter [EMAIL PROTECTED] writes:
Dave Crocker wrote:
...
The only way to make sure deliveries of product -- in this case, IETF
documents -- are timely is to decide when they are needed by and set firm
deadlines. The IETF currently does not do that. Instead, we leave
Dave Crocker [EMAIL PROTECTED] writes:
The only way to make sure deliveries of product -- in this case,
IETF documents -- are timely is to decide when they are needed by
and set firm deadlines. The IETF currently does not do that.
Instead, we leave everything open-ended.
We should do better
Ned Freed [EMAIL PROTECTED] writes:
Like it or not, careful reviews and review checklists, while quited
flawed in their own right, are the best tool we have. When I was on
the IESG I had my own private review checklist; it was the only
thing I found that worked.
I agree careful reviews are
| The IESG declines Dr. Roberts's request for a hop-by-hop option for
| QOS purposes.
I have no idea whether the option is actually any good or not, nor whether
it should be approved, so don't consider this a message in support of
the option.
However, the IESG's stated reasons for
On one point (since it was mentioned in other thread as well):
(ii) For the reasons above and in my earlier note, I think the
IESG, and the IETF more broadly, must exert great caution in
rejecting a registration request and must exert that caution in
public. For example, the language of
My biggest concern here is not the IESG itself, it's the folk who
presume to speak on its behalf.
This is a valid concern, and one that has made me cringe multiple
times. I've too often heard of reports where someone says but the
IESG will never accept this, or that's not what AD foo says, etc.
Bruce Lilly [EMAIL PROTECTED] writes:
Unless I misunderstood your earlier comments, Ned, you suggested that the
requirement should be dropped. Which would presumably mean that the idnits
check against that requirement would be dropped, and then there would be
the very real possibility, nay
Brian E Carpenter [EMAIL PROTECTED] writes:
I don't see any discussion of the RFC Editor retaining null IANA
sections in RFC2434bis, which is good. It is a completely silly idea. An
RFC should contain useful, long-lasting information. The fact that a
particular document didn't require
As Spencer says, if you haven't looked recently, you really should.
Let me just give a big Thanks to Henrik and the tools team for the
work that has gone into tools.ietf.org. It is an incredibly useful
resource.
That is the first place I go when I want to see what the status of
something is in a
Scott W Brim sbrim@cisco.com writes:
The metaphor I'm trying to use this week is that the IETF is
landscapers and we provide a fertile, beautiful area for people to go
wild and create excellent gardens.
Exactly. The beauty of TCP/IP (and indeed many protocols when done
well) is that they are
There is a new relationship between ISOC and the IETF for administrative
support as defined by BCP 101 (RFC 4071). Given these changes in our
ties to ISOC, the IAB has been discussing (without coming to any
conclusion on the matter) whether it is any longer appropriate for
someone to
FWIW, I fully support creation of this new area. This is based both on
the contents of Brian's note (though I agree with some of the followup
about naming and what really goes in), and on private discussions I
had with some of the ADs in Paris when the idea was still a proposal.
I firmly believe
[note: I find this type of summary to be a useful tool for
highlighting certain aspects of list traffic. With Brian Carpenter's
blessing, I plan on making this a regular feature for the ietf list.]
Total of 312 messages in the last 7 days ending midnight January 25.
Messages | Bytes
Total of 122 messages in the last 7 days ending midnight January 25.
Messages | Bytes| Who
+--++--+
10.66% | 13 | 8.86% |48108 | [EMAIL PROTECTED]
7.38% |9 | 9.40% |51030 | [EMAIL PROTECTED]
6.56% |8 |
For any document, you can always send comments to the author(s)... and
so far, I believe I've been quite responsive to comments...
But if you want to post publically, here (the ietf list) is as good a
place as any, since the document isn't associated with any WG.
i.e., for
Total of 131 messages in the last 7 days through midnight EST,
Thursday, February 23.
Messages | Bytes| Who
+--++--+
8.40% | 11 | 8.21% |66509 | [EMAIL PROTECTED]
5.34% |7 | 4.80% |38846 | [EMAIL PROTECTED]
Adrian Farrel [EMAIL PROTECTED] writes:
Thomas,
Fascinating though I find these summaries to be, I wonder:
- what relevance is there to the ordering in the list?
As Rob says,
rank[user] = messages[user]/total_messages + bytes[user]/total_bytes.
BTW, the script that does this can be found
Total of 71 messages in the last 7 days through midnight, Thursday,
March 2 EST.
Messages | Bytes| Who
+--++--+
7.04% |5 | 9.23% |38893 | [EMAIL PROTECTED]
7.04% |5 | 5.86% |24683 | [EMAIL PROTECTED]
Total of 355 messages in the last 7 days through midnight, Thursday
March 30, EST.
Messages | Bytes| Who
+--++--+
9.58% | 34 | 8.54% | 185628 | moore@cs.utk.edu
5.35% | 19 | 12.43% | 270074 | [EMAIL PROTECTED]
Total of 65 messages in the last 7 days through midnight,
Thursday, April 6, 2006 EST.
Messages | Bytes| Who
+--++--+
10.77% |7 | 9.17% |40843 | [EMAIL PROTECTED]
9.23% |6 | 10.16% |45261 | [EMAIL
Carl Malamud [EMAIL PROTECTED] writes:
I thought that wide replication of the series was the whole
point. If there are issues, I thought they had to do with derivative
works. For example, a particularly risk-averse author of a new
book might query whether publication of 3 random pages from
Total of 66 messages in the last 7 days through midnight,
Thursday, April 13 EST.
Messages | Bytes| Who
+--++--+
9.09% |6 | 8.04% |32205 | [EMAIL PROTECTED]
6.06% |4 | 8.98% |35985 | [EMAIL PROTECTED]
Total of 116 messages in the last 7 days through midnight,
Thursday, April 20, EDT.
Messages | Bytes| Who
+--++--+
6.03% |7 | 5.69% |34886 | [EMAIL PROTECTED]
6.03% |7 | 5.15% |31576 | [EMAIL PROTECTED]
More than 1,250 of you attended IETF 65 in Dallas and many others
attended sessions remotely. Yet only 155 of you have responded to a
survey intended to make future meeting experiences more successful.
Maybe we need to provide more incentive. ARIN enters those that
complete their survey in
Total of 39 messages in the last 7 days through midnight,
Thursday, April 27, EDT.
Messages | Bytes| Who
+--++--+
7.69% |3 | 5.64% |14637 | [EMAIL PROTECTED]
7.69% |3 | 5.37% |13924 | [EMAIL PROTECTED]
Total of 20 messages in the last 7 days through midnight, Thursday May
4, EDT.
Messages | Bytes| Who
+--++--+
35.00% |7 | 33.10% |38995 | [EMAIL PROTECTED]
5.00% |1 | 9.76% |11494 | [EMAIL PROTECTED]
Total of 16 messages in the last 7 days through midnight,
Thursday, May 11 EDT.
script run at: Fri May 12 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
25.00% |4 | 28.58% |35393 | [EMAIL PROTECTED]
12.50% |2
Total of 120 messages in the last 7 days.
script run at: Fri May 26 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
11.67% | 14 | 11.45% |87948 | [EMAIL PROTECTED]
6.67% |8 | 5.90% |45306 | [EMAIL
I think it is our collective responsiblity not to make false claims
when moving our agenda forward. This is true with any group.
Very much in agreement.
Liaison should not be used for fact checking.
Speaking as a liaison, this sort of fact checking (what is the real
status of WG X or
Total of 133 messages in the last 7 days.
script run at: Fri Jun 2 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
6.77% |9 | 7.40% |62599 | [EMAIL PROTECTED]
6.77% |9 | 7.05% |59588 | [EMAIL
It is quite reasonable to last call this draft at this point. It has
been reviewed for ~6 months. This version posted to the list for
comments more than 3 weeks ago, plenty of time for more comments, but no
comments were posted to the list on this version.
Maybe reviewer fatigue?
One thing
Total of 110 messages in the last 7 days.
script run at: Fri Jun 16 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
9.09% | 10 | 8.88% |61612 | [EMAIL PROTECTED]
6.36% |7 | 10.74% |74511 | [EMAIL
Total of 27 messages in the last 7 days.
script run at: Fri Jul 7 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
14.81% |4 | 14.91% |22127 | [EMAIL PROTECTED]
7.41% |2 | 13.72% |20349 | [EMAIL
Total of 120 messages in the last 7 days.
script run at: Fri Jul 14 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
5.00% |6 | 6.22% |43119 | [EMAIL PROTECTED]
5.00% |6 | 5.23% |36256 | [EMAIL
Ok. So I'm not sure what you propose here - should we not require
rsync and ftp mirroring capability, or should we ask for it, and not
specify chapter and verse regarding version etc.? I'd certainly be
very unhappy completely abandoning the rsync capability.
IMO, the SOW should have some
Speaking only for myself, I have always read the words
Further recourse is available... at the beginning of
section 6.5.3 of RFC 2026 to mean that an appeal to the
ISOC Board can only follow rejection of an appeal by both
the IESG and IAB.
I think this is essentially right. That is, it makes
Folks interested in the topic of minutes may want to go find a copy of
(the expired) draft-meyer-agendas-and-minutes-00.txt
And if they think this is a good direction to go, encourage the
authors to update the document and push it forward through the system.
Thomas
Total of 122 messages in the last 7 days.
script run at: Fri Jul 28 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
26.23% | 32 | 26.08% | 250016 | [EMAIL PROTECTED]
10.66% | 13 | 10.48% | 100481 | [EMAIL
Total of 36 messages in the last 7 days.
script run at: Fri Aug 11 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
16.67% |6 | 16.71% |32127 | [EMAIL PROTECTED]
11.11% |4 | 10.61% |20394 | [EMAIL
Total of 87 messages in the last 7 days.
script run at: Fri Aug 18 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
10.34% |9 | 15.24% |78348 | [EMAIL PROTECTED]
5.75% |5 | 8.33% |42814 | [EMAIL
Total of 16 messages in the last 7 days.
script run at: Fri Aug 25 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
18.75% |3 | 28.84% |36511 | [EMAIL PROTECTED]
18.75% |3 | 17.66% |22358 |
Total of 92 messages in the last 7 days.
script run at: Fri Sep 1 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
1.09% |1 | 23.75% | 188337 | [EMAIL PROTECTED]
7.61% |7 | 11.07% |87736 | [EMAIL
The IESG also seeks comments from interested document editors and
working group chairs pointing to instances where the second part of
the experiment would be useful.
In the past, it was rather common for there to be a not insignificant
number of documents in the RFC editor queue, whose
Let's be clear that the experiment wouldn't automatically release
all of those 25 documents. It would only allow ones to be released
that refer (normatively) to
o Internet-Drafts of Standards Track documents for which IESG review
has been completed and Protocol Action or Document
Total of 194 messages in the last 7 days.
script run at: Fri Sep 8 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
8.76% | 17 | 11.29% | 135589 | [EMAIL PROTECTED]
8.25% | 16 | 8.89% | 106786 | [EMAIL
Total of 80 messages in the last 7 days.
script run at: Fri Sep 15 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
18.75% | 15 | 20.69% |97613 | [EMAIL PROTECTED]
8.75% |7 | 9.14% |43139 | [EMAIL
Total of 81 messages in the last 7 days.
script run at: Fri Sep 22 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
11.11% |9 | 23.31% | 128475 | [EMAIL PROTECTED]
8.64% |7 | 9.00% |49624 | [EMAIL
Total of 92 messages in the last 7 days.
script run at: Fri Sep 29 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
10.87% | 10 | 13.19% |73236 | [EMAIL PROTECTED]
8.70% |8 | 6.89% |38257 | [EMAIL
Eliot Lear [EMAIL PROTECTED] writes:
What it requires is that people who want all their pet changes to go
into a draft to simply show some discipline and accept that not
everything will be fixed at once. Current practice is a ONE STEP
process that is NOT documented. Your and others'
Any commentary?
I'll give you the standard answer. Take a look at
draft-narten-successful-bof-01.txt and start building up support the
old fashioned way. I.e., write a clear problem statement, get other
people who agree with you to collaborate, set up a mailing list, etc.
Thomas
Total of 60 messages in the last 7 days.
script run at: Fri Oct 6 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
11.67% |7 | 11.46% |44144 | [EMAIL PROTECTED]
8.33% |5 | 11.35% |43733 | [EMAIL
Total of 125 messages in the last 7 days.
script run at: Fri Oct 13 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
16.80% | 21 | 16.80% | 128654 | [EMAIL PROTECTED]
6.40% |8 | 10.25% |78494 | [EMAIL
Total of 115 messages in the last 7 days.
script run at: Fri Oct 20 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
8.70% | 10 | 7.96% |53526 | [EMAIL PROTECTED]
7.83% |9 | 6.56% |44090 | [EMAIL
Total of 93 messages in the last 7 days.
script run at: Fri Oct 27 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
13.98% | 13 | 12.42% |68856 | moore@cs.utk.edu
11.83% | 11 | 11.50% |63760 | [EMAIL
Total of 51 messages in the last 7 days.
script run at: Fri Nov 3 00:03:02 EST 2006
Messages | Bytes| Who
+--++--+
7.84% |4 | 6.32% |17922 | [EMAIL PROTECTED]
5.88% |3 | 5.62% |15958 | [EMAIL
Total of 112 messages in the last 7 days.
script run at: Fri Nov 10 00:03:01 EST 2006
Messages | Bytes| Who
+--++--+
8.04% |9 | 9.60% |64198 | [EMAIL PROTECTED]
8.04% |9 | 5.74% |38388 | [EMAIL
Total of 63 messages in the last 7 days.
script run at: Fri Nov 17 00:03:01 EST 2006
Messages | Bytes| Who
+--++--+
1.59% |1 | 63.41% | 646925 | [EMAIL PROTECTED]
9.52% |6 | 3.62% |36927 | [EMAIL
Total of 90 messages in the last 7 days.
script run at: Fri Nov 24 00:03:01 EST 2006
Messages | Bytes| Who
+--++--+
23.33% | 21 | 26.50% | 143311 | [EMAIL PROTECTED]
8.89% |8 | 7.95% |43004 |
I believe that this note should have been CCed to this mail list. I
believe this action is of general interest.
Do you want me to forward this to the NANOG list?
I don't see that as necessary (though certainly not harmful). I don't
think anyone is chomping at the bit for these...
To get
Total of 116 messages in the last 7 days.
script run at: Fri Dec 1 00:03:01 EST 2006
Messages | Bytes| Who
+--++--+
11.21% | 13 | 12.70% |81616 | [EMAIL PROTECTED]
6.90% |8 | 7.53% |48396 | [EMAIL
Soliman, Hesham [EMAIL PROTECTED] writes:
I'll start with my protocol question:
7.2.7 Anycast neighbor announcements
- Second, the Override flag in Neighbor Advertisements SHOULD be
set to 0, so that when multiple advertisements are
received, the
Scott W Brim [EMAIL PROTECTED] writes:
I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very important.
For the sake of new implementors I have a number of suggestions for
clarity. Many of them have to do with the use
Total of 57 messages in the last 7 days.
script run at: Fri Dec 8 00:03:01 EST 2006
Messages | Bytes| Who
+--++--+
8.77% |5 | 17.98% |70375 | [EMAIL PROTECTED]
12.28% |7 | 9.14% |35795 | [EMAIL
Total of 16 messages in the last 7 days.
script run at: Fri Dec 15 00:03:01 EST 2006
Messages | Bytes| Who
+--++--+
31.25% |5 | 36.79% |31789 | [EMAIL PROTECTED]
6.25% |1 | 7.58% | 6551 | [EMAIL
1 - 100 of 545 matches
Mail list logo
