On Wed, 26 Feb 2003, The IESG wrote:
> A new working group has been formed in the Internet Area of the IETF.
> For additional information, contact the Area Directors or the Working
> Group Chairs.
Uhh.. "a new working group"? What's this old "dhc" working group been,
then, which has operated fo
On Thu, 27 Feb 2003, Theodore Ts'o wrote:
> On Wed, Feb 26, 2003 at 07:49:15PM -0800, [EMAIL PROTECTED] wrote:
> > Other widely deployed but similarly misguided anti-spam mechanisms
> > include blanket blocks on incoming or outgoing TCP connections to port
> > 25. I've even encountered on ISP tha
On Wed, Feb 26, 2003 at 07:49:15PM -0800, [EMAIL PROTECTED] wrote:
> Other widely deployed but similarly misguided anti-spam mechanisms
> include blanket blocks on incoming or outgoing TCP connections to port
> 25. I've even encountered on ISP that transparently and silently
> redirected my outboun
I would like to propose that the IAB consider drafting and adopting a
position statement on the highly deleterious effect that certain
anti-spam mechanisms have on legitimate, efficient uses of the
Internet.
I am thinking mainly of the MAPS DUL (Dialup User List), a remarkably
ill-conceived mechan
Tomson Eric (Yahoo.fr) wrote:
Just three questions :
1/does the IETF support or contest the "Inclusive Name Space" (the one
operated by NewRoot instead of the ICANN)?
RFC-2826 answers this.
--
/===\
|John Stracke |[EMAIL PROTECTED]
On Sat, 15 Feb 2003, Andre Hedrick wrote:
> This would not logically include ignoring the rule about everything put to
> the wire must be "BIG ENDIAN"? Obviously everyone knows to ignore this
> ruleset when dealing with CRC32C; however, if you are a "BIG ENDIAN" box
> you must conform to make you
Date:Tue, 18 Feb 2003 14:30:51 +0100
From:Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Given that a large portion of the IETF does not in fact subscribe to the
| ietf-announce list,
That's irrelevant, anyone who cares can subscrib
on ethernet,
If all ports were DTE pin configured (same pair everywhere for rx and tx)
and all cables were cross
life would be simpler.
-JS
This would not logically include ignoring the rule about everything put to
the wire must be "BIG ENDIAN"? Obviously everyone knows to ignore this
ruleset when dealing with CRC32C; however, if you are a "BIG ENDIAN" box
you must conform to make your CRC32C put on the wire in "LITTLE ENDIAN".
Of
Interesting. So, they knew that standardization was necessary, the
proposed a standard, the standard wasn't accepted, so they distributed
code to users anyway, and wrote a book anyway.
I find that even more worthy of criticism.
Did they think they would force this through later? Never mind, it do
On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote:
>
> > On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote:
> >
> > > > You haven't shown any proof of that. The "proof" you showed, was the
> > > > result of a misconfiguration.
> > >
> > > No. It is the result of operational reality. Whenever you
> > >
On 21 Feb 2003, D. J. Bernstein wrote:
> [EMAIL PROTECTED] writes:
> > Whenever you have a parent and child zones under different administrative
> > controls it is impossible to change both zones simultaniously.
>
> False.
>
> Set the clocks correctly, and schedule the change on all the servers
On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote:
> > You haven't shown any proof of that. The "proof" you showed, was the
> > result of a misconfiguration.
>
> No. It is the result of operational reality. Whenever you
> have a parent and child zones under different administrative
>
On Wed, 19 Feb 2003 [EMAIL PROTECTED] wrote:
> > All the IXFR server needs to do is determine (by some implementation
> > dependent, administrator maintained method) what has changed between one
> > zone version and another. How it does this is nobody's business but the
> > administrator and the
On Fri, 14 Feb 2003, Andreas Gustafsson wrote:
> Dean Anderson writes:
> > I don't think they can be dismissed so easilly. Indeed, I think the
> > proposed changes are rather "oddball", and are actually unncessary in
> > order to implement IXFR (which was the original claimed justification).
>
> T
As you note, they didn't conform to a BCP. There is no requirement (or
implication even) that one should conform to a Best Common Practice.
These serve to distribute helpful advice to the community and document
practices that have worked for others, in situations that may be
different.
The AXFR is
Good. You found a bug in an implementation. I thought such things were
off-topic for this list. This bug doesn't mean that AXFR is broken.
Bind 8 did not have this bug, yet it has the common understanding of AXFR.
Let me summarize the discussion:
Everyone agrees that AXFR specification in RFC 10
On Wed, 19 Feb 2003 [EMAIL PROTECTED] wrote:
> > Good. You found a bug in an implementation. I thought such things were
> > off-topic for this list. This bug doesn't mean that AXFR is broken.
> > Bind 8 did not have this bug, yet it has the common understanding of AXFR.
> >
> > Let me summarize t
> > > > The IXFR client must simply make the changes (again, by some
> > > > implementation dependent, administrator maintained method) to the zone by
> > > > deleting RRs and adding RR's in each sequence. The original version of th
> > e
> > > > zone might have been obtained by FTP (or quantum int
Howdy,
Dave Crocker wrote:
I gather that the IAB is frankly dictating the current wording of the
opening paragraph.
I don't know how you gathered this, but you'll be relieved
to know it isn't true.
There were concerns raised within the IAB and IESG with the
original phrasing of the charter, and t
20 matches
Mail list logo
