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
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
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
I haven't been at any IETF recently, but from my previous
experience, I agree with several commenters about these
cities:
* MINNEAPOLIS consistently works well for IETF meetings.
* VANCOUVER consistently works well for IETF meetings.
* DUBLIN has good air transport links, and would have
ra
I support the thoughts expressed by Eliot Lear, Scott Bradner,
Lars Eggert and several others that research often does not
have a crisp conclusion and that not all Experimental RFCs
describe a scientific experiment. For example, Transaction TCP
(T/TCP) research was active in at least two differ
On 23 Feb 2012, at 11:13 , Julian Reschke wrote:
> On 2012-02-22 18:01, RJ Atkinson wrote:
>> Security that works well and is practical to implement
>> needs to be designed-in, not bolted-on later.
>
> I would say: security needs to be orthogonal.
There are at least 2
Earlier, Barry Leiba wrote, in part:
> What we're looking at here is the need for an HTTP authentication
> system that (for example) doesn't send reusable credentials,
> is less susceptible to spoofing attacks, and so on.
+1
More generally, I support the concerns raised by Stephen Farrell,
Wes H
On 17 Jan 2012, at 15:14 , The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Secure PSK Authentication for IKE'
> as an Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final com
Earlier, on 29th October 2011, Mike StJohns wrote, in part:
> With respect to the other four documents (e.g. Milo's baby et al) --
> they aren't IETF documents, they weren't adopted as
> Internet Standards (unlike TCP and IP) and we shouldn't be
> twiddling with their status. They don't belong to
Gentle Folks,
Robin Whittle either hasn't read the ILNP documents
and published papers or he hasn't understood them.
His characterisation of ILNP on this list is
not correct in a wide range of dimensions. Folks
who want to learn more about ILNP might consider
starting at this web site:
On 31st July 2011, Brian Carpenter wrote, in part:
> I believe that the present situation is confusing both to IETF newcomers
> (who may falsely believe that the IETF actually follows the 3 stage process)
> and, worse, confusing to users of IETF standards (who may falsely believe
> that a document
On 24 Jun 2011, at 11:50 , Paul Hoffman wrote:
> And you have now listed so many variables, it begs the question:
Paul,
I disagree that it begs that question.
The IETF processes have always been open to ALL inputs from whatever
source, in all parts of its processes. You write that text abo
Earlier, Paul Hoffman wrote, in part:
> ...the IESG just approved publication of X, even with
> what appears to be a lack of consensus in the comments
> on the ietf@ mailing list.
>
> (some other text elided here.)
>
> For a document such as this, why even ask for IETF consensus
> if the IETF co
Earlier, Ray Bellis wrote:
> The only ... operator into YBQ appears to be Air Transat
> (whoever the heck they are) and they only fly from Marseille and Paris.
I have been told that Air Transat lacks the many comforts,
low & fully-disclosed fees, and general friendliness of Ryan Air.
I've never f
Earlier, John Klensin wrote:
> I favor the publication of this document
> with a minimum of further fuss.
+1
Character set issues are inherently both very complex
and also difficult to reach consensus about.
More discussion is not at all likely to reach any
different conclusion. It is important
On 05 May 2011, at 12:13 , The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Reducing the Standards Track to Two Maturity Levels'
> as a BCP
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final
The last *several* revisions have been perfectly fine.
The most recent edits are also fine.
We're micro-editing this document at this point, meaning that
"perfect" is impeding our ability to deploy "more than good enough"
to replace 3-tier system that most IETF folks agree is broken,
and has
On 04 Mar 2011, at 18:22 , The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)'
> as an Informational RFC
>
> The IESG plans to make a decision in the next few
On 05 Mar 2011, at 01:35 , Mykyta Yevstifeyev wrote:
> I'd like to ask how was it done, what procedures were used.
Existing IETF procedures were used, as best I understand,
which shows that we do NOT need any new procedures.
As I noted, that use happened to have an incorrect result,
because
Earlier, Joel Halpern wrote:
> The first point, to echo Andrew Sullivan, is that even if a protocol
> is in use on the public Internet, it is not always easy to detect.
> It may be used in only some portions of the net. It may be used
> inside some other protocol that makes detection ahrder.
>
>
Earlier, Stuart Chesire wrote:
> In the MHonArc mail archive there are often super-long lines, which would be
> wrapped to the window width when viewing in most mail clients, but when
> viewed in a web browser they appear as long singlelines which take a lot of
> left-to-right scrolling to read
Earlier, Joel Halpern wrote:
> It seems to me that this proposal strikes a good balance in making an effort
> to improve the situation regarding our document track.
>
> Regarding the particular clause:
>
>> On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
>> ...
>>
>> 2. I found this statement to
Before today, Bob Braden wrote:
> Historic might imply that they were once in service,
> but have later been replaced/deprecated. In fact, these
> protocols were always, and are still, *experimental*.
> It would seem logical to assign them the Experimental
> category and be done with it.
+1
Earlier, Paul Hoffman wrote in reply to Rene Struik:
> The changes you propose have serious IPR considerations
> that are not present in the current document. If you want
> to propose IPR-laden optimizations, it is better to do so
> as a separate document so implementers can see the differences
IESG Folks,
The IETF already has taken MUCH MUCH too long handling this document.
Each time this I-D gets revised, new and different issues are raised.
While I am generally OK with the way IETF processes work,
this document is an exception.
Excessive nit-picking is going on with this d
On 28 Oct 2010, at 13:29 , Dave CROCKER wrote:
> On 10/28/2010 9:22 AM, RJ Atkinson wrote:
>> Most times it would be better if IETF WGs initially create
>> an Experimental status RFC, possibly doing so quite rapidly,
>> and then later revise that (based on at experienc
On Weds, 27th October 2010, at 13:56:25 -0700, Bob Braden wrote in part:
> In this environment, the only thing that seems to make sense
> is for WGs to start usually at Experimental (someone else
> suggested this, I apologize for not recalling who it was).
Agreed.
Most times it would be better i
I support advancing this document to BCP and making
these process changes.The changes will simplify
advancement of standards-track documents and be a
good step in the right direction.
Please do seek a sponsor for this draft.
Yours,
Ran Atkinson
_
Earlier, Joel Jaggli wrote:
> The fact of the matter as a vendor, is that if you want
> to get through network equipment requirements for, for example
> the army approved products list (AAPL), ipv6 conformance testing
> is now no longer an annnex, it's simply part of the process.
Interesting to k
Data:
In the most recent round of updates to interior routing
cryptographic authentication, the collective conclusion
was that HMAC-SHA-256 would be best for "mandatory"
implementation, as it likely has the longest lifetime
of the widely available (mode + a
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,
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 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
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
> 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
On 01 Feb 2010, at 08:40 , The IESG wrote:
> The IESG has received a request from the TCP Maintenance and Minor
> Extensions WG (tcpm) to consider the following document:
>
> - 'ICMP attacks against TCP '
>as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks,
On 14 Sep 2009, at 10:00, Polk, William T. wrote:
IMHO, the current text places a responsibility on the IESG to deal
with
"exceptional circumstances" but fails to provide the tools to
execute that
responsibility. After 27 years in government, I have a lot of
experience
with assignment of
Earlier, Tim Polk wrote (in part):
% And are we really helping anyone by not clarifying the
% relationship between the document and other RFCs?
%
% Shouldn't we provide this information as a
% service to the reader?
Tim,
I like you, but your reasoning on this topic comes
across as very confused
All,
I value the independence of the Independent Submission stream and
IRTF Stream from the IETF (including the IESG). Indeed, both the
RFC series and the acceptance of independent RFCs long pre-date
even the existence of the IETF.
I prefer that the IESG NOT have or assert the authority to mand
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
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
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
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
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
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 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
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
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
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
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
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 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
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 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
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 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, 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, 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 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 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,
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 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
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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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 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
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
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
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 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 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 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 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 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 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
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 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]
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 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 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: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 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 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
1 - 100 of 131 matches
Mail list logo
