On Fri, 28 Mar 2008, Keith Moore wrote:
If there were some serious technical consequence for lack of the MX record
I would be
all for specifying its use. Operational practice with A records shows that
there is no real issue,
only if you ignore the problems that have been observed and
David Morris wrote:
On Fri, 28 Mar 2008, Keith Moore wrote:
If there were some serious technical consequence for lack of the MX record
I would be
all for specifying its use. Operational practice with A records shows that
there is no real issue,
only if you ignore the problems that
On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents.
Those being ietf-stream exclusively or implicitly also covering the
iab-stream?
Personally, I think it makes
Thanks for your review, Pekka. A few notes:
it doesn't go into much detail on how they solved
difficult and more interesting issues, for example:
- how they solved MTU problems caused by adding hop-by-hop header
- given their deployment model, why didn't they try inserting a destination
Regarding -outbound section 4.3:
IETF contributions often include components intended to be directly
processed by a computer. Examples of these include ABNF definitions,
XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
MIBs, ASN.1, or classical programming code.
On Fri, 28 Mar 2008, Jari Arkko wrote:
This would be very useful addition to the document. Authors?
But note that the overall experience from the specific approach chosen
here was that yes, its possible get it to working, but there are
significant issues both for deployment and for the way
For issues noted, for each I'd like to ask quostions such as:
- was this noticed in the testbed? how?
- was the issue relevant in that context; if not, why not?
- if the issue was noticed, how was it worked around? which
approaches worked (in that restricted context), which did not?
OTOH, I think standardizing this convention makes all
sorts of sense,
but not, of course, in 2821bis.
Why not in 2821bis? Is 2821bis really that time critical?
It is on its way to Draft Standard. This would be a
sufficiently new feature to force recycle at Proposed, which,
On Mar 27, 2008, at 8:31 PM, Keith Moore wrote:
David Morris wrote:
Perhaps you could help us out and share a reference to
documentation of such problems. I for one have not personally
observed any problems related to using the A record to locate a
mail server when there is no MX.
Simon Josefsson wrote:
To give the Trust something concrete to work with I propose to add the
following:
To make sure the granted rights are usable in practice, they need to
at least meet the requirements of the Open Source Definition [OSD],
the Free Software Definition [FSD], and the
My suggestion is to rewrite section 4 a bit to call out that this
document does not cover the incoming rights for the independent and
irtf stream and to use the terms ietf-stream and possibly iab-
stream in the definitions.
thats all well good for the independent stream since they have
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or free software is or
becomes. The intention is to grant anyone to do anything with the code
segments. That's what we ask the trust to do. Further in line.
Simon Josefsson wrote:
--On Wednesday, 26 March, 2008 17:09 + Tony Finch
[EMAIL PROTECTED] wrote:
With that change to address record, if no MX record is
found, the SMTP client is required to look for DNS names with
either A or RRs, rather than A RRs only.
There's also RFC 3974 (Jan 2005, informational)
Joel M. Halpern [EMAIL PROTECTED] writes:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or free software is or
becomes. The intention is to grant anyone to do anything with the code
segments. That's what we ask the trust
and the dummy SMTP server works, but it consumes resources on the
host and eats bandwidth on the network. having a way to say don't
send this host any mail in DNS seems like a useful thing. and we
simply don't need the fallback to because we don't have the
backward
At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
Joel M. Halpern [EMAIL PROTECTED] writes:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or free software is or
becomes. The intention is to grant anyone to do anything with the
In an IETF that believes the potential recursion of URNs and
NAPTR records is reasonable, it is really hard for me to get
excited about that one possible extra lookup. YMMD, of course.
I can't get excited about this either.
Doug's issue, which sparked off this latest
On Thu, 27 Mar 2008, Matti Aarnio wrote:
There will be lots of legacy codes using legacy APIs for long future.
I do use getaddrinfo() API myself, and permit it do all queries to
get addresses. Thus it will also query for A in addition to .
It can even be ordered to ignore IPv4
Joel M. Halpern wrote:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or free software is or
becomes. The intention is to grant anyone to do anything with the code
segments. That's what we ask the trust to do. Further in
Peter Saint-Andre wrote:
Joel M. Halpern wrote:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or free software is or
becomes. The intention is to grant anyone to do anything with the code
segments. That's what we ask the
Ned Freed wrote:
this entire exercise is focused on a move to draft with this revision
In this case I'm a part of the rough, my focus is on get it right
before the staus. For 2822upd I'd be upset if it is no STD in 2010,
2821bis is different.
a move to draft is not the time to introduce
Ray Pelletier wrote:
The Trustees adopted the Non-Profit Open Software License 3.0 in
September 2007 as the license it would use for open sourcing
software done as work-for-hire and that contributed to it, at that
time thinking of code contributed by IETF volunteers. See: http://
At 03:01 28-03-2008, Simon Josefsson wrote:
Regarding -outbound section 4.3:
As such, the rough consensus is that the IETF Trust is to grant
rights such that code components of IETF contributions can be
extracted, modified, and used by anyone in any way desired. To
enable the
Ray Pelletier wrote:
Peter Saint-Andre wrote:
Joel M. Halpern wrote:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or free software is or
becomes. The intention is to grant anyone to do anything with the
code
SM wrote:
At 03:01 28-03-2008, Simon Josefsson wrote:
To give the Trust something concrete to work with I propose to add the
following:
To make sure the granted rights are usable in practice, they need to
at least meet the requirements of the Open Source Definition [OSD],
the Free
I would think that any license for RFC code should meet two
requirements:
1) It should be usable by anyone in the open source community
(compatible
with any open source/free software license).
2) It should be usable by anyone in any corporation who sells a closed
source product.
That way,
--On Friday, 28 March, 2008 19:20 +0100 Frank Ellermann
[EMAIL PROTECTED] wrote:
a move to draft is not the time to introduce new features.
It's a trick to keep wild and wonderful new features out. For
the IPv6-fallback discussed in this thread getting it right
is more important than the
Ray Pelletier wrote:
The Trustees adopted the Non-Profit Open Software License 3.0 in
September 2007 as the license it would use for open sourcing software
done as work-for-hire and that contributed to it, at that time thinking
of code contributed by IETF volunteers. See:
[EMAIL PROTECTED] wrote:
Let me throw another idea into the mix. What if we were to
recommend a transition architecture in which an MTA host
ran two instances of the MTA software, one binding only to
IPv4 addresses, and the other binding to only IPv6 addresses.
Assume that there will be some
c) to distribute or communicate copies of the Original Work
and Derivative Works to the public, with the proviso that
copies of Original Work or Derivative Works that You
distribute or communicate shall be licensed under this
Non-Profit Open Software License or as provided in section
The agreement was to let the trust work out the legal details. This
document is intended to tell the trust what we want, clearly and
unambiguously. The current text is unambiguous. If we start trying to
say that this or that specific license is a good starting point, then
they have to
Ned Freed wrote:
this entire exercise is focused on a move to draft with this revision
In this case I'm a part of the rough, my focus is on get it right
before the staus. For 2822upd I'd be upset if it is no STD in 2010,
2821bis is different.
I completely and categorically disagree.
+1. I couldn't express it better.
Brian
On 2008-03-29 04:54, Ted Hardie wrote:
At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
Joel M. Halpern [EMAIL PROTECTED] writes:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what open source or
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 2008-03-28 20:14, Olaf Kolkman wrote:
On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents.
Those being ietf-stream exclusively or implicitly also covering the
On 2008-03-28 18:49 Ray Pelletier said the following:
The Trustees adopted the Non-Profit Open Software License 3.0 in
September 2007 as the license it would use for open sourcing software
done as work-for-hire and that contributed to it, at that time thinking
of code contributed by IETF
John C Klensin wrote:
if you have wild and wonderful new features, write drafts,
introduce them as separate, Proposed Standard, updates to
2821 that stand on their own, with their own justifications.
For one of the two discussed proposals, nullmx, that would be
easy enough, an old I-D exists.
A new Request for Comments is now available in online RFC libraries.
RFC 5224
Title: Diameter Policy Processing Application
Author: M. Brenner
Status: Informational
Date: March 2008
Mailbox:[EMAIL PROTECTED]
A new Request for Comments is now available in online RFC libraries.
RFC 5172
Title: Negotiation for IPv6 Datagram Compression
Using IPv6 Control Protocol
Author: S. Varada, Ed.
Status: Standards Track
Date:
39 matches
Mail list logo
