On 16 Mar 2006, at 18:06, Leslie Daigle wrote:
Following the note just sent about the proposed timeline for
reviewing the RFC Editor contract this year, here is the
STRAW proposal RFC Editor charter proposed by the IAB.
It is a modest extension of the RFC Editor paragraph as found
in RFC 2850
On 17 Mar 2006, at 04:47, Brian E Carpenter wrote:
Leslie Daigle wrote:
I want to speak to one facet of comment that I believe
is going to be a common thread:
[Ran Atkinson wrote:]
Similarly, it is a bug that the IETF process would govern the
publication of non-IETF documents. The IETF proce
On 17 Mar 2006, at 22:53, Leslie Daigle wrote:
Suggestion? Are they independent submissions, or RFC Editor
contributions? They are clearly not currently IAB, IETF
or IRTF docs...
The crisp distinction between "independent submission" and
"RFC Editor contribution" has so far eluded me. If t
Previously, someone wrote:
I finished reading the RFC editor document and have one major concern.
Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.
Incorrect. As I pointed out some weeks ago, and Leslie has
recently repeate
On 5 Jun 2006, at 02:54, Brian E Carpenter wrote:
Earlier, Ran Atkinson wrote:
It has NOT been the case in the past that IETF was the community
in control of RFC-Editor. In fact, that would represent a major,
and in many people's view highly undesirable, change.
Historically, RFC-Editor has se
On 7 Jun 2006, at 04:52, Brian E Carpenter wrote:
I wouldn't want to exclude the operational and implementer community
either. I think the phrase used in draft-iab-rfc-editor is probably
the best short form: "the Internet research and engineering
community." Note of course that there is no way
This seems quite reasonable. If anything, it is about 10 years
overdue -- better late than never. :-)
Ran
On 1 Mar 2007, at 11:37, The IESG wrote:
The IESG has received a request from an individual submitter to
consider
the following document:
- 'CableLabs - IETF Standardization Collabora
Originally, someone asked:
% How does adding a downref to a dead document add more
% integrity to the RFC process?
On Mon, 05 Mar 2007 12:39:35 -0500
John C Klensin wrote:
> Independent of the merits in this particular case, it provides
> history and context. We have learned, or should have
I am quite startled by this thread, both in its emotion
and in the apparent oversight of multiple approaches
to the issue of having LOTS of connected user devices
at a house/site/office when an IPv6 /64 prefix has been
provided by one's upstream network provider.
First, giving each end user a /6
On 20 Aug 2007, at 14:35, Jun-ichiro itojun Hagino wrote:
that's true, but when link MTU is different, it gets very nasty.
IEEE 802 standards do not permit variation in the link MTU
for Ethernet. Attempts to persuade IEEE 802 to approve use
of jumbo-MTUs (e.g. 9180 bytes + Ethernet f
On 21 Aug 2007, at 22:54, Jun-ichiro itojun Hagino wrote:
IEEE 802 standards do not permit variation in the link MTU
for Ethernet. Attempts to persuade IEEE 802 to approve use
of jumbo-MTUs (e.g. 9180 bytes + Ethernet framing) have
consistently failed within the IEEE 802.
ok, then pl
On 20 Aug 2007, at 15:25, Iljitsch van Beijnum wrote:
On 18-aug-2007, at 16:27, RJ Atkinson wrote:
Second, Ethernet bridging is a well understood technology
and it works just fine even with very large numbers of devices.
That's a meaningless statement. Yes, it works well if you
I have been unhappy with RFC-1345 for many years,
primarily because it purports to be accurate about which letter
is at which code point in which character set encoding (sadly
the document isn't accurate in various details), which has misled
some number of implementers through the years a
Some important things that the FSF folks seem NOT to understand,
and frankly seem to aggressively NOT want to understand, are:
- Many RFCs are *not* on the IETF standards track.
- Any "Experimental RFC" is *not* on the IETF standards track.
So there is no "endorsement" by IETF in publishing s
NAT, NAPT, and NAT-PT have been used for some while now to refer
to various sorts of address/port translation within an IPv4-only
network.
Recently, there has been some discussion of network address with
IPv6::IPv4 protocol translation. Some have referred to that as
NAT-PT also, which can be co
Given that the IESG ignored inputs from some number of
people noting that the RFC in question was actually deployed [1],
it seems doubtful that it would be worthwhile for any of the
operators who have deployed NAT+PT to travel to an IETF for
the purpose of commenting in person.
M
On 15 Nov 2007, at 04:37, Iljitsch van Beijnum wrote:
On 15 nov 2007, at 8:27, David Kessens wrote:
PS as my personal opinion on NAT-PT, as long as we define it as
middlebox as opposed to a protocol that has strong interoperation
needs, I am not convinced that it actually even needs to be
s
On 15 Nov 2007, at 02:27, David Kessens wrote:
On Wed, Nov 14, 2007 at 08:19:56AM -0500, RJ Atkinson wrote:
Given that the IESG ignored inputs from some number of
people noting that the RFC in question was actually deployed [1],
it seems doubtful that it would be worthwhile for any
If the SUB-IP Area is to continue after the Spring 2003 IETF,
then it should have its own Area Directors appointed by the Nomcom.
I'll note that the IESG is free to re-organise itself at any time
and that the IESG has done so on occasion. This means that even
if SUB-IP ADs were appointed by Nomc
On Wednesday, Dec 4, 2002, at 12:09 America/Montreal, Marshall Rose
wrote:
may i humbly ask harold to start dropping folks from ietf-general who
continue to post on this topic?
Concur. This is just a DDOS attack on the list and its well nigh
time to to act to clean up the list and improve the
I concur with StJohns. This is a better phrased way of saying the same
thing that I was trying to say.
If SUB-IP Area is to continue past March 2003, then its AD(s) need to be
appointed specifically for that by Nomcom (and ought not be responsible
for more than one area). If the IESG believes t
On Thursday, Dec 19, 2002, at 06:12 America/Montreal, 'Stephane
Bortzmeyer' wrote:
Valdis did not suggest that we *forbid* people to work for companies
involved in the work of the WG they chair. Just that we ask them to
*disclose* such "potential conflicts of interest". (BTW, in the
present case,
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.
[IAB hat off]
I agree with the above. IE
On Wednesday, Jan 29, 2003, at 20:20 America/Montreal, Thomas Narten
wrote:
I don't know what can be done a this point to change the terminology
in 2434. It's been in use for some 4 years now...
It would seem quite simple for you to take the text of RFC-2434,
edit the text appropriately to pick
On Friday, Jan 31, 2003, at 16:06 America/Montreal, someone wrote:
What this points out is that the relationship between IESG review,
IANA assignments and RFC editor independence is both complex and
subtle. Not suprisingly, it has evolved over time in a way that no
longer matches the exact words
On Wednesday, Feb 12, 2003, at 13:24 America/Montreal, Mallikarjun C.
wrote:
All the Internet documentation with which I am familiar, as well as
the
I think we have a case of overlapping vocabulary from two different
domains.
Per SCSI Architecture Model (SAM-2, SAM-3), iSCSI is very clearly
On Friday, Mar 7, 2003, at 08:59 America/Montreal, Keith Moore wrote:
We need to stop calling this a charter, and start calling it
documentation
of current practice. It's clearly useful to document current practice,
and the justification for current practice, especially when a lot of
the
critici
On Friday, Mar 7, 2003, at 12:07 America/Montreal, Keith Moore wrote:
I think it is useful to document current practice and the
justification for
that practice.
I do not think it's a good idea to call it a charter, at least not at
this
stage, because the work of documenting current practice need
I'm uncomfortable with the tone of some of the responses on
this thread. I don't think there is a need for anyone to
be adversarial about this issue.
Steve Kent's point that we in the Internet community need to work
on other better mechanisms besides RPF checks is well taken.
It is also the ca
At 03:37 15-02-00 , Vernon Schryver wrote:
>Could Civil Service employees find it hard to get travel requests approved
>for attending meetings of an outfit that gets carried away in its rules
>and regulations on who can talk to whom?
No. Been there, done that. Lots of pain being part of the US
At 21:22 15-02-00 , Tim Salo wrote:
>The original poster may, in a very real sense, actually be representing a
>company, whether the IETF wants to believe it or not.
>
>Of course, that leads to the rather interesting dilemma that we don't know
>whether an individual is speaking on behalf or his or
At 02:20 17-02-00 , Phil Karn wrote:
>It's not because fixed addresses actually cost them more. Indeed,
>another cable modem provider in the other part of town allocates fixed
>addresses in an otherwise identical service that's $5/mo cheaper. No,
>my provider does it simply because they can. They
At 02:31 04-03-00 , Randall Gellens wrote:
>At 12:57 PM 2/15/00 +1030, Mark Prior wrote:
>
>>The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for
>>AU$276.36 (approx US$175). Drivers are available from Lucent for (at
>>least) Windows 95, 98, NT, CE, 2000, MacOS and Linux.
>
>Searc
At 16:09 09-04-00 , Peter Deutsch in Mountain View wrote:
>Well put. As Dave has pointed out earlier this weekend, there is a burning need
>for better, permanent access to the Drafts collection. If we had that, perhaps
>much of this discussion might become moot, since some of the out-on-a-limb
>s
Hi,
Lack of SNMPv3 availability in networking products is a serious
operational problem in the Internet today, IMHO.
A large number of networking vendors are telling @Home that the
vendor has difficulty in offering SNMPv3 because WindRiver won't take the
Epilogue SNMP Agent softw
At 02:12 16-05-00 , Theodore Y. Ts'o wrote:
>It seems to be usually the case, for most messages that I've seen, that
>there's *no* added value to the HTML version. I.e., other than adding
> at the end of lines, and using microsoft-specific font settings at
>the beginning of each paragraph (usual
At 11:10 25-05-00 , Ravichandran M wrote:
>Hi,
>If its only IP address, use RARP mechanism to get the IP address (this
>requires a rarp server to be in place in the same network). RARP server can
>be enabled in the Linux server. If RARP fails(after some timeout), then go
>ahead to use Bootp to get
At 22:52 25-05-00 , Jon William Toigo wrote:
>c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which is
>too slow to support storage I/O operations.
Provably false. In fact TCP throughput above 768 Mbps over 1518-byte GE
has been demonstrated publicly in the past in several dif
At 15:40 26-05-00 , [EMAIL PROTECTED] wrote:
>It will run over incredibly fast Packet over SONET Wide Area
>Networks--behind firewalls. OC-192 and soon-to-come OC-768 (terrabit)
>switches will be the backbone of WANs and MANs of large networks in a few
>years.
I'll note that at least on
If someone could send me a unicast reply email with a pointer
to the SMI for the private MIBs implemented by the Apple Airport and/or
the Lucent WaveLAN Access Point, that would be much appreciated.
If the reply mail is unicast to me, I'll package up a summary
and send the summar
At 18:02 29-05-00 , Dawson, Peter D wrote:
>is vulnerability and threat analysis part of the
>standardization process ??
YES (shouting intentional).
The "Security Considerations" section of every RFC ought to
contain vulnerability, threat analysis, risk mitigation,
and residual risk information.
At 15:21 26/06/00 , Vernon Schryver wrote:
> - persistently, unbendingly claiming that 14000 bit/sec is a bit rate
>that is radically lower than anything ever before used for TCP/IP.
Those of us who have run voice over IP over 9600 bps HF radio
find the above claim particularly am
At 09:54 29/06/00 , Dan Kohn wrote:
>I will bite regarding one issue near and dear to IETF hearts -- which is the
>seeming need to buy yet another 802.11 card for each IETF meeting. And yes,
>I am actually suggesting an approach that would require one more purchase:
Actually, IETF has m
At 16:15 29/06/00 , Joe Touch wrote:
>DS appears to be better for large, flat spaces (largely 2-dimensional,
>under 3 stories tall, since transcievers on the middle floor largely
>cover the upper and lower).
>
>FH is better for more spherical spaces (largely 3-dimensional).
These optimisations d
At 05:03 23/08/00, Rahul Banerjee wrote:
>Well, not really just the enlarged address space! There do exist certain
>other definite benefits of IPv6 like possible use of Flow Specifications in
>the Flow Label, decreased processing delay at routers, greater flexibility
>etc. This is not to say tha
At 15:04 30/08/00, Kurt D. Zeilenga wrote:
>I post to ietf-discuss because two of the referenced
>Informational RFCs, RFC 1321 (MD5) and RFC 2104 (HMAC),
>are also normative references for numerous other
>Standard Track protocols.
Neither of those are protocols. Instead, they specify
mathematic
At 09:52 31/08/00, Brian E Carpenter wrote:
>I don't see any need to tweak the wording or the interpretation.
>
> Brian
All,
I agree with Brian and Harald and others. There is no
need to tweak things. Nothing is broken. There is no real
process problem with having LDAP depend on M
At 15:44 22/09/00, Pete Loshin wrote:
>IMO, it's not helpful to publish an RFC that points to a
>"work-in-progress" as the source for explanatory or background
>information about that RFC, if those documents disappear within months
>of publication. It makes the RFCs less useful.
Do such RFCs act
At 12:07 27/09/00, Melinda Shore wrote:
>Archival material is *extremely* important for
>future research.
The archival material is the RFC --*only*--.
>Just because the document isn't
>for publication and cannot be used normatively
>doesn't mean that it should be obliterated.
I would not w
At 21:09 27/09/00, Beth Shaw wrote:
>It has been brought to our attention that there has been
>an issue raised on this alias that the alias has been
>spammed by Nexsi. Nexsi takes spamming very seriously and
>does not condone nor authorize it. If you have any questions
>or further concerns, pleas
At 23:43 27/09/00, Danny McPherson wrote:
>Ran, does your company make it routine practice while working on behalf of
>recruiters?
AFAIK none have used IETF data inappropriately and ALL of
my current/past employers do have a practice of telling
recruiters explicitly not to violate AUPs (e.g.
At 03:03 03/12/00, Graham Klyne wrote:
>I guess one of the first questions should be; "Is some partitioning of the Internet
>community such a bad thing?"
A partioning based on nationality, which is of course
different than language group, would be harmful. Lack of
interoperability of s
At 02:53 05/12/00, Martin J. Duerst wrote:
>At 00/12/04 10:42 -0800, Christian Huitema wrote:
>>So, at a minimum, we need an IETF
>>specification on how to detect that a domain name part is using a non ascii
>>encoding, so that DNS servers don't get lost.
>
>Why not just use UTF-8? It is an encodi
At 13:32 17/12/00, Perry E. Metzger wrote:
>It is true that v6 qua v6 does not solve the route explosion
>problem. It is also true that the route explosion problem is
>a real problem. However, it doesn't make it worse, either.
From an operator perspective, supporting *2* IP protocols
is
At 13:44 15/12/00, Sean Doran wrote:
>Surely the "much pain" is because, as Melinda Shore indicates,
>some "anti-NAT fanatics" cannot understand the distinction
>between "who" and "where"?
I fancy that I know one or two things about ESP
and AH. Your analysis is Wrong. The pain has
At 17:39 18/12/00, John Collis wrote:
>This is true. To do this though really requires some re-architecting
>of the current Internet model, based on "first principles".
Yes.
>In particular, there is not a sufficient "name space" for what we are
>often currently trying to do - hence the
At 22:54 18/12/00, Donald E. Eastlake 3rd wrote:
>If DNSSEC were deployed, I see no reason why SAs
>could not be bound to domain names.
The semantics of an FQDN is not crisp and clear
these days as is once was.
For example, www.cnn.com names a set of content
(served by an arr
Folks,
Some compare/contrast about then and now, followed by
some (perhaps radical) thoughts to ponder. I'm NOT interested
in quibbles about the timeframe for THEN or minor differences
in perception about either THEN or NOW, so I'll ignore any
troll-like responses. This is intended as a
Someone else noted:
>Participation by mail before participation in person.
EXAMPLE
I was an active participant (e.g. ask folks in Denmark
who were involved with early MIME stuff) via email long
before I showed up in person. To this day, I don't make
every meeting. Before ever showing u
At 19:07 03/01/01, Lloyd Wood wrote:
>I'd just bounce all emails with non-text attachments with a message
>requesting that attachments not be sent to the list, and that the
>message be resent as text. Simple. sufficient.
Fully agree. There is no need to use any thing that
isn't text/plai
At 07:44 13/02/01, Lloyd Wood wrote:
>You just can't do members-only on IETF WG lists. See recent discussion
>on poisson. I'd suggest moving the list elsewhere...
I'm not sure what "members-only" means in your usage.
Self-moderated[1] lists have been permitted for some years in
IETF busi
At 12:07 15/03/01, Melinda Shore wrote:
> I reformatted it with nroff under
>UWIN, which really worked very well and held no
>surprises whatsoever. So, it's not even necessary
>to have access to a Unix or Unix-ish OS to use
>nroff for document production.
Good point, but one doesn't eve
At 12:52 22/03/01, William Allen Simpson wrote:
>This is a rare case where I disagree with Phil. This is a good
>location. Unfortunately, it wasn't cold enough to discourage the
>usual gaggle of folks that haven't read the charter or the drafts
I thought the host folk and hotel di
At 12:12 30/03/01, Joel Jaeggli wrote:
>With h.261/pcm and mpeg-1 you should be able to implement a client for
>your platform of choice without stomping on someone elses IP to hard, in
>practice clients are already available for most platforms, or can be built
>there with a modicum of effort.
>
>
At 03:58 04/04/01, dark dark wrote:
>hi,
>Does any one have any idea if we can use IPSec with
>multicast address.
Where "IPsec" means "AH" and/or "ESP",
the answer is quite clearly yes and always has been.
>In RFC-2401 I have read
>"In principle, the Destination Address may be a
>unica
At 05:05 15/05/01, Rahmat M. Samik-Ibrahim wrote:
>Why?
It isn't an IETF standards discussion. It is
advertising for a commercial product.
>- Too late: after more than 10 years, why stop it now?
Better late than never.
>- That message, "was passed through [EMAIL PROTECTED]
It appears that IEEE 802 is now making many of their
standards available online at no cost in PDF format. Details
and limitations of this are available online at:
http://standards.ieee.org/getieee802/
Please don't ask me any further questions, because
the above is all t
At 00:01 23/10/01, Edward Lewis wrote:
>I am hearing that international travel will be problematic
>for the time being.
It is not clear to me how your firm's international travel rules
impact the IETF meeting in Salt Lake City, since TIS Labs is in Maryland,
which is a domestic flight fro
At 07:45 23/10/01, Lloyd Wood wrote:
>I think remote participation in live WG meets isn't a worthwhile goal,
>given cost and difficulties of interactive networking (never mind
>timezones); encouraging it when more than half the people in a WG
>meeting have their faces buried in a laptop and are ta
At 11:06 23/10/01, Francis Dupont wrote:
> In your previous mail you wrote:
>
> >Including the people showing slides; at least
> >with printed acetate technology you don't have people stopping to
> >answer their Instant Messages.
Francis got the quoting above wrong. I didn't say the above.
At 22:14 30/10/01, Michael Richardson wrote:
>The major obstucle is the "IPtelcos"/CableCos
>who aren't being very retinscent to actually let people being peers rather
>than just client-consumers. There is, with dynamic DNS update no reason why
>they should not permit people with "always-on" IPs t
At 18:35 13/11/01, April Marine wrote:
>The IETF list itself was split from one list to "discussion" and
>"announcements." I don't see why "announcements" can't be split to "IDs"
>and "all other announcements." People would still get ID announcements to
>their WG lists of the particular ones the
At 02:15 29/11/01, Jeffrey Altman wrote:
>I have Cable Modem service from Time Warner Road Runner in NYC.
>The way they work it you get up to 5 IP addresses for each cable
>modem you have.
This is typical of most {NB: not all, most} currently deployed
residential IP/Cable Modem networks in at
At 23:18 13/10/01, Robert Elz wrote:
>The IESG needs to agree to the charter, that's clear, and the AD needs to
>agree to any milestone updates, etc - but for work that falls within the
>charter, the WG decides just what it wants to do.
Robert,
I don't think that has ever been the way IE
At 11:18 07/12/01, Ostap Monkewich wrote:
<>
At IETF-52 in Salt
Lake City,
Sending email in fancy text, rather than plain-text,
and sending proprietary format binary attachments
(in this case MS-Word)...sigh.
Those are two clear indicators that the sender of the email
doesn't understand the IE
If one has a personal wireless AP in Salt Lake City
this week, PLEASE make double sure that your personal AP
is not using the network name/SSID string of the official
wireless network (i.e. NOT "IETF").
And there are still some "rogue" (i.e. unofficial)
access points claiming
On Friday, February 22, 2002, at 09:51 , [EMAIL PROTECTED] wrote:
>
> I am trying to convince myself that the IEEE 802.3ah working group
> working on FTTH should not consider a proposal to increase the MTU
> size of Ethernet beyond 1500 bytes. There is a strong likelyhood
> that 802.3ah may req
On some day, someone wrote:
> Well, I haven't been around all that many years, but I don't recall
> a single case in a few WG's I'm participating that an unpresented
> work would have been adopted.. sure, it's not written down anywhere, but
> sometimes custom is stronger than law...
The OTP WG
On Wednesday, March 13, 2002, at 06:49 , William Allen Simpson wrote:
> 10 years ago on Tuesday, Phil Karn sprawled out across my hotel
> room bed and drew the packet header that became ESP.
Actually, that packet header wasn't directly related to ESP,
though there aren't but so many ways a secur
On Saturday, March 16, 2002, at 08:01 , William Allen Simpson wrote:
>> ... I didn't happen to be at that ad-hoc meeting
>> in San Diego, so I wasn't influenced by it
>
> No, but you were at the meetings where swIPe was demonstrated --
> ACTUALLY DEMONSTRATED -- and where the the packet headers w
On Tuesday, April 16, 2002, at 10:46 , todd glassey wrote:
>> - In the OSPF vs IS-IS discussions, we decided to pursue two
>> approaches.
>> Both survive, with little apparent harm to the community.
>
> And they both offer cricital boundry routhing capabilities - and most
> Router
> manufactu
On Tuesday, April 16, 2002, at 01:23 , Randy Bush wrote:
> puhleeze! is-is worked at scale. ospf did not. heck, when most
> large isps were starting (late '80s and early '90s), ospf barely
> worked at all.
Randy,
Your statement is true for at least one vendor's OSPF, but clearly
not
On Tuesday, April 16, 2002, at 01:01 , todd glassey wrote:
> The problem James is that this is just not the case. What is the case is
> that each WG Chair gets to decide what concensus is for their WG and
> that is
> wrong.
It is the role of the WG chair(s) to determine rough consensus. If on
On Tuesday, April 16, 2002, at 02:43 , Christian Huitema wrote:
> Fine, but Randy is also right when he points out that just because a
> spec is not an IETF standard does not mean that the spec is proprietary.
Christian,
As deployed IS-IS is not fully documented *anyplace*. What is
act
On Tuesday, April 16, 2002, at 04:39 , todd glassey wrote:
> Ran you hit it on the head - "Your milages varies..." - this is a
> standards
> organization and not a place where we decide who we like and which of
> their
> projects we are going to allow to come through us today and not.
On Friday, April 19, 2002, at 04:00 , Liao Wei wrote:
> Each IEEE standards give out PICS proforma for Protocol Implementation
> Conformance Statement. The supplier of an implementation that is claimed
> to conform to the standard should complete the PICS document and provide
> the information
On Thursday, May 30, 2002, at 09:48 , Melinda Shore wrote:
> Here's one for starters: there's no guidance on how or whether to
> treat differences in licensing terms for competing proposals. It
> would be nice to be able to say that all other things being more-or-
> less equal we should prefer t
On Thursday, May 30, 2002, at 01:27 , Bill Strahm wrote:
> I don't think the IETF can afford to keep a staff of
> lawyers working on determining the licencing statements of all of the
> standards being churned out.
Interesting, but actually no one suggested that.
I said that I
On Thursday, June 13, 2002, at 08:17 , Chandra Shekar Reddy Challagonda
wrote:
> What my question was that, where I can register that ?
Check with IANA. You are looking for an OID in the Enterprises
area of the MIB heirarchy. See the IANA Web page (http://www.iana.org)
for the proced
On Wednesday, June 12, 2002, at 01:15 , Bill Strahm wrote:
> Can't say about other maillist software, but the software that runs the
> @ietf.org lists allows this, you can subscribe from as many addresses as
> you want, and only get mail sent to a single address...
Hi,
Someone here sho
On Sunday, Nov 17, 2002, at 00:34 America/Montreal, Ross Finlayson
wrote:
I thought there was consensus to try not to hold IETF meetings in the
Bay Area?
Agree, because they are over-run with local tourists and it was
impossible to get work done.
However, IETF Chair has the authority to approv
On Thursday, Nov 21, 2002, at 09:05 America/Montreal,
[EMAIL PROTECTED] wrote:
I can't help thinking that the spastic wireless network experienced at
IETF55 could have been avoided if lessons learned at previous IETF
meetings
had not been repeated. Maybe these lessons need to be captured
somewh
On 26 Oct 2012, at 12:04 , The IESG wrote:
> The IESG has received a request from the IPv6 Operations WG (v6ops)
> to consider the following document:
> - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
>
> as Best Current Practice
>
> The IESG plans to make a decision i
On 26 Oct 2012, at 14:01 , Ronald Bonica wrote:
> I agree that the references to I-D.gont-6man-oversized-header-chain
> and gont-6man-nd-extension-headers should both be NORMATIVE,
> and not INFORMATIVE. Sorry for having missed this.
Thank you.
> If Fernando were to post an updated version tha
Earlier, Eliot Lear wrote:
% Put simply, you are over-specifying the RID
% and derive no benefit from doing so.
There is benefit to implementers in having a specific
example that is known to meet the requirements of
this specification. This benefit also accrues to users,
as implementers are mor
> Our process may be complicated, but a deviation from due process
> that requires 145 pages of description is simply not possible.
> We have specific rules in RFC 2026 and RFC 2418 (and various updates)
> and it should be possible to describe specific alleged deviations
> from those rules in a pag
All,
I support this change, as written in Russ's draft.
This is not a surprise, as I've proposed this kind
of change myself in the past (as have several other
folks).
I see various people quibbling about aspects of this
proposal, but I haven't seen any serious defence of
the obviously broken (i.e
On 22nd June 2010, at 10:12:13 CET, Eliot Lear wrote:
> This then leads to a question of motivations. What are the motivations
> for the IESG, the IETF, and for individual implementers? Traditionally
> for the IETF and IESG, the motivation was meant to be a signal to the
> market that a standard
Earlier, Mike StJohns wrote:
> One side note - MIBs.
>
> MIBs by their nature are actually collections of mini-standards
> - the objects. Once an object is defined and published in a
> non-transitional document (RFC), the OID associated with that
> object is pretty much stuck with that defin
On 23 Jun 2010, at 08:45 , Eliot Lear wrote:
> And now as to your specifics, you have placed a lot of weight on one
> example, seemingly extrapolating from it, the Joint Interoperability
> Test Command. I have no experience working with them, and defer to
> yours. However, when you say,
Again,
1 - 100 of 131 matches
Mail list logo
