On 20 aug 2013, at 07:21, Dave Crocker d...@dcrocker.net wrote:
The first is that there now a number of other apps using TXT records,
with no problems, because they are stored under scoping nodes
(underscore-prefaced names). This approach might be aesthetically
displeasing, but it
Hi,
When relying on S-NAPTR (RFC3958), redirection is only possible inside
sub-domains of the original domain name.
I don't think that's true. RFC3958 has exactly this use case in it's
first example section (2.2): a domain example.com redirects service
EM:protA to another domain, namely
On 8/19/2013 11:33 PM, Patrik Fältström wrote:
Reason for this is that the RR with an underscored prefix MIGHT end up in a
different zone than the record without.
Patrik,
Please clarify. I don't know what you mean by the 'with' and 'without'
references.
And as long as I'm asking for
On 20 aug 2013, at 09:14, Dave Crocker d...@dcrocker.net wrote:
On 8/19/2013 11:33 PM, Patrik Fältström wrote:
Reason for this is that the RR with an underscored prefix MIGHT end up in a
different zone than the record without.
Patrik,
Please clarify. I don't know what you mean by the
On Mon, Aug 19, 2013 at 11:48 AM, SM s...@resistor.net wrote:
Hola Arturo,
At 07:34 19-08-2013, Arturo Servin wrote:
Academic might work. Open source not so much as other
mentioned. Does
Big Corporation doing Open Source apply?
I was tempted to propose non-profit, but
Hi,
Thank you for quick feedback.
I agree with your analysis. I think that we should provide more info on the
possible use of S-NAPTR for realm-based redirection.
Taking into account your proposal, what do you think of the following
proposed changes:
The new text reads pretty well.
One
On 16/08/13 20:07, Joe Touch wrote:
On 8/15/2013 10:38 PM, Martin Sustrik wrote:
On 16/08/13 03:23, Wesley Eddy wrote:
There are semantics issues to; see draft-touch-tcp-portnames-00 for
information (this is being revised for resubmission shortly, FWIW).
I totally agree. In fact, in the
On 8/19/2013 7:42 PM, S Moonesamy wrote:
At 14:10 19-08-2013, Hector Santos wrote:
I'm having a hard time with both sides of the argument, especially
the supposed existence of an interop problem which seems to only
highlight how to procedurally stump the SPF type advocates with a
error
On 8/20/2013 1:12 AM, S Moonesamy wrote:
There is a message from the Responsible Area Director at
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which
might shine some light about that part of the charter.
Both RR Type 16 and RR Type 99 are in use on the Internet. Tony
Newsgroups: iecc.lists.ietf.ietf
From: John Levine jo...@iecc.com
Subject: Re: [spfbis] prefixed names, was Last Call:
draft-ietf-spfbis-4408bis-19.txt
Summary:
Expires:
References: 5212fcef.80...@dcrocker.net
55459829-933f-4157-893a-f90552d44...@frobbit.se
5213174d.7080...@dcrocker.net
On Tue, Aug 20, 2013 at 12:14:21AM -0700, Dave Crocker wrote:
And as long as I'm asking for more explanation, given the number of
years of use the construct has had and for the number of different
applications, where has the problem (whatever you mean specifically)
been seen?
Quite apart
On 8/20/2013 5:35 AM, Martin Sustrik wrote:
If you want a multiplexer to serve different connections from a single
service port, you need a multiplexer server (tcpmux daemon, websockets,
whatever you want to call it).
Ack. The web server is a problem though, because you typically don't
have
The issue Måns Nilsson raises was discussed extensively on the SPFbis
list prior to as well as during last call on the list and I believe
the appropriate decision was reached by the working group. If there is
any doubt in the minds of the IESG regarding whether the working group
reached the
Could anyone tell me how to remove my email from this distrubution?
-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org]
On Behalf Of The IESG
Sent: Monday, August 19, 2013 6:07 PM
To: IETF-Announce
Cc: dhc mailing list; dhc chair; RFC Editor
On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.org wrote:
This document specifies an IPv6 profile for 3GPP mobile devices. It
lists the set of features a 3GPP mobile device is to be compliant
with to connect to an IPv6-only or dual-stack wireless network
Hi Stephan,
When relying on S-NAPTR (RFC3958), redirection is only possible inside
sub-domains of the original domain name. This is a restriction compared to the
use of normal NAPTR and REGEXP. The following recommendations can be also found
in the RFC6733: The domain suffixes in the NAPTR
Works for me.
Regards,
Lionel
-Message d'origine-
De : Stefan Winter [mailto:stefan.win...@restena.lu]
Envoyé : mardi 20 août 2013 13:37
À : MORAND Lionel OLNC/OLN
Cc : d...@ietf.org; 'IETF Discussion Mailing List'
Objet : Re: [Dime] Last Call:
Hi Stephan,
Thank you for quick feedback.
I agree with your analysis. I think that we should provide more info on the
possible use of S-NAPTR for realm-based redirection.
Taking into account your proposal, what do you think of the following proposed
changes:
Abstract:
OLD:
However, in
In message 20130820144548.73129.qm...@joyce.lan, John Levine writes:
Newsgroups: iecc.lists.ietf.ietf
From: John Levine jo...@iecc.com
Subject: Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408b
is-19.txt
Summary:
Expires:
References: 5212fcef.80...@dcrocker.net
On 8/20/2013 8:12 AM, Mark Andrews wrote:
In message 20130820144548.73129.qm...@joyce.lan, John Levine writes:
...
The two following MIGHT NOT be in the same zone:
foo.example. IN X RDATAX
_bar.foo.example. IN TXT RDATAY
Since prefixed names have never been used for anything other than
On Tue, Aug 20, 2013 at 08:54:02AM -0700, Dave Crocker wrote:
In other words, the specific technical limitations being noted are
unfortunate but (so far) not serious.
You should explain that to my employer's support department.
In any case, I don't think this topic is directly relevant to the
Hi Hector,
At 06:30 20-08-2013, Hector Santos wrote:
I have a few questions and points:
May I ask why was the above was not an area for clarification as
oppose as the presumed stated technical reason for removal?
The SPFBIS WG had a session at IETF 83. The minutes for that session
is at
Hi Hector,
At 07:16 20-08-2013, Hector Santos wrote:
This doesn't seem to be correct. My apology if I don't follow or see
the logic. The only real issue as it was since day zero in MARID
was the infrastructure support for recursive passthru queries which
is what RFC 3597 (Handling of Unknown
Hi Patrik,
I am copying the message to ieft@ as there is an ongoing Last Call.
At 08:28 20-08-2013, Patrik Fältström wrote:
The consensus related to how to fix RFC 4408
will be very rough. That is clear. And I feel
sorry for responsible AD and IESG to be forced
to make a decision that such a
On 20 aug 2013, at 20:36, S Moonesamy sm+i...@elandsys.com wrote:
It would be better to have the discussion on the ietf@ mailing list as that's
the venue which the IESG identified for last Call comments.
Understood, and thanks.
The reason why I did not post there at first was that a) I did
As sponsoring AD I have the following last call comments I hope you will take on
board.
Thanks,
Adrian
Please fix the two lines that are too long (see idnits)
---
Please expand OTN on first use in the main text.
Please expand TS on its first use.
---
6.2
The ingress node of an LSP MAY
As the bottle is opened, I hereby state my objection to Section 3.1 of
draft-ietf-spfbis-4408bis-19 for the reasons explained below. I do agree (as
stated below) that the section of RFC 4408 that specify how to use both SPF and
TXT resource record types include an error as it does not lead to
On 8/15/13 2:06 PM, SM wrote:
At 11:48 14-08-2013, IAB Chair wrote:
This is a call for review of List of Internet Official Protocol
Standards: Replaced by an Online Database prior to potential
approval as an IAB stream RFC.
My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026.
Hi Patrik,
At 11:45 20-08-2013, Patrik Fältström wrote:
The reason why I did not post there at first was
that a) I did not feel I had followed the rules
laid out for discussions [read all messages in
the mailing list archives] and b) the discussion
on the dnsext list was more general on
I am having trouble understanding this discussion.
If the data is in a database then surely the production of RFC xx00
standards series is simply running an automated query on the database and
emitting the result as an RFC?
--On Tuesday, August 20, 2013 14:01 -0500 Pete Resnick
presn...@qti.qualcomm.com wrote:
On 8/15/13 2:06 PM, SM wrote:
At 11:48 14-08-2013, IAB Chair wrote:
This is a call for review of List of Internet Official
Protocol Standards: Replaced by an Online Database prior
to potential
Hi Pete,
At 12:01 20-08-2013, Pete Resnick wrote:
The IESG and the IAB had an email exchange about these two points.
Moving a document from Standard to Historic is really an IETF thing
to do. And it would be quite simple for the IETF to say, We are no
longer asking for the 'Official Protocol
On 8/20/13 3:26 PM, Phillip Hallam-Baker wrote:
If the data is in a database then surely the production of RFC xx00
standards series is simply running an automated query on the database
and emitting the result as an RFC?
I'm sure that such a tool could be created. To date, I believe the
From a pure protocol point of view the SPF record does have one major
advantage over TXT and that is in the use of wildcard records.
In short a wildcard on a TXT record for SPF is going to have impact on
every other scheme that overloads TXT, of which there are many. SPF does
have a mechanism to
On 8/20/2013 3:01 PM, Pete Resnick wrote:
On 8/15/13 2:06 PM, SM wrote:
At 11:48 14-08-2013, IAB Chair wrote:
This is a call for review of List of Internet Official Protocol
Standards: Replaced by an Online Database prior to potential
approval as an IAB stream RFC.
My guess is that
On 8/20/13 4:21 PM, Tony Hansen wrote:
I support this. But it also raises a couple other questions.
What about rfcxx99 series, published along with the rfcxx00 series? Were
they ever formally retired?
That's not an IETF matter. There's no STD on this. There's nothing
(AFAICT) in a BCP
On Aug 20, 2013, at 02:39 , Lorenzo Colitti lore...@google.com wrote:
[...] It seems to me that the sheer length of the list, and the fact that is
not prioritized, create a real risk that implementors will simply write it
off as wishful thinking or even shy away in terror. [...]
My views
On 8/20/2013 9:08 AM, Andrew Sullivan wrote:
On Tue, Aug 20, 2013 at 08:54:02AM -0700, Dave Crocker wrote:
In other words, the specific technical limitations being noted are
unfortunate but (so far) not serious.
You should explain that to my employer's support department.
In any case, I
No hat.
On Tue, Aug 20, 2013 at 05:16:56PM -0400, Phillip Hallam-Baker wrote:
From a pure protocol point of view the SPF record does have one major
advantage over TXT and that is in the use of wildcard records.
This is an extremely interesting point, and I'm ashamed to admit I
hadn't really
Martin
Further to our conversation on this topic in Berlin I now respond formerly on
the list.
3GPP has defined the mobile terminal as performing the UA role since the very
beginning of IMS. Therefore the mapping between the terminal and the instance
ID in IMS is a one to one relationship.
The IESG has received a request from the Media Server Control WG
(mediactrl) to consider the following document:
- 'Media Control Channel Framework (CFW) Call Flow Examples'
draft-ietf-mediactrl-call-flows-13.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and
41 matches
Mail list logo
