Le 2012-11-05 19:10, Carlos M. martinez a écrit :
Other than the CGN-mib we discussed today in sunset4, I wondered whether
is there ongoing work on this topic.
What do you mean exactly? Because there is nothing IPv6-specific in the
CGN MIB (or NAT MIB), it's all address-family agnostic...
Si
On 2010-04-06 13:56, Andrew Sullivan wrote:
I thought we didn't have members? I've always liked to refer to
people doing work here as "participants" for exactly that reason.
There are exactly 2003 members of the IETF! ;)
http://www.linkedin.com/groups?viewMembers=&gid=83669
Simon
--
NAT64/DN
Please also refer to the results of the DNS64/NAT64 experiment that we
ran at IETF 77. Users of the service encountered a bug due to parallel
resolving in one particular operating system. We believe the bug is due
to that particular implementation. Parallel resolving is still a Good
Idea(TM), but t
On 2010-06-17 12:55, David Conrad wrote:
> Well, yes. However, applications already have to be modified to deal with
> IPv6. I'd agree that modifying applications from a simple synchronous path
> to dealing with parallel asynchronous connections would not be a good idea.
> Personally, I'm of t
On 2011-05-20 09:37, Julian Reschke wrote:
> Fun aside, "ASCII" is the wrong encoding to declare, either use
> "US-ASCII", or just drop the declaration (the default being the right
> thing anyway).
The intent is to use UTF-8. We'll fix that.
Thanks,
Simon
--
DTN made easy, lean, and smart --> ht
On 2011-05-24 04:56, Julian Reschke wrote:
-> to IANA: please fix the pages; XML parsers are not required to
understand that encoding name
IANA fixed it yesterday.
Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server--> http://numb.viagenie.ca
vCard 4.0
We wrote these instructions for those who want to fly to Montréal
instead of Québec:
http://ietf81.ca/?page_id=423
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server --> http://n
On 2011-06-20 13:32, Michael Richardson wrote:
> I'm staying at Laval University resident for $61/night. Hotwire did
> find a few places equal in distance for ~$108, but the trip was harder
> in my opinion. I might bring my folding bike, or not (I'm coming by
> train). There are apparently dozen
On 2011-06-20 23:52, John Levine wrote:
> * There is no usable bus from the airport (it runs only at commuter
> hours) and a taxi costs C$32.50
You're absolutely right about this. The people of Québec are not happy
about this situation and often complain in the media. It makes for a bad
first im
On 2011-06-21 01:06, Randall Gellens wrote:
> San Diego is much easier to get to than Quebec City, since multiple air
> carriers serve it.
Not going to argue about "San Diego vs Québec", but just going to point
out that multiple carriers do serve Québec. Among them are Air Canada,
United, Continen
Mykyta Yevstifeyev wrote, on 09/14/2011 01:10 PM:
> Of course, you should have changed all references to vCard 4 to vCard 5, and
> reference to VCARDDAV WG draft to RFC 6350.
vCard 4 is the latest version, specified in RFC 6350. We'll make a note to the
RFC Editor to update the references.
Simon
On 2011-10-12 12:57, Joe Touch wrote:
> I suspect that the delay is because it may be generated on-the-fly, but
> haven't been able to confirm that. It may just be network transfer delay.
As Julian said, what's slow is the browser rendering the HTML. More
precisely, it's two things:
1. HTML parsin
On 2011-10-12 13:44, Joe Touch wrote:
> Emperically:
>
> opening the file from disk = 30 seconds
>
> downloading the file from the net = 33 seconds
>
> I.e., they're both part of the problem.
Turning on gzip transfer encoding in the web server config would reduce
download time by a factor of ~1
On 2011-10-20 08:41, George, Wes wrote:
> I'm also completely mystified as to why IPv6 support for all
> proposed/requested features is not an explicitly stated requirement,
> even at this phase.
And more generally, this should be considered an opportunity for
dogfooding the protocols we create. I
On Saturday 19 September 2009 15:55:55 Steve Crocker wrote:
> The choice is between engaging and not engaging. Engaging is better.
> Not engaging isn't constructive.
Thank you. I wanted to say this, but could not find the right words.
I fully agree with Steve Crocker.
In the long run, exposure
On 2011-12-06 22:06, Benson Schliesser wrote:
ISPs need to use addressing within this scope that does not cause (additional)
problems for their existing customers (and their customers' equipment). And in
the event of an addressing conflict, operators (on both sides) need a common
reference to det
On 2012-03-06 08:51, Julian Reschke wrote:
On 2012-03-06 14:41, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
vers
On 2012-05-16 10:56, Andrew Sullivan wrote:
Because, after all, technical specification language is already such
elegant prose, maintaining that elegance is more important than
robustly encoding the semantic of being normative in a way that
avoids ambiguity?
One dreams of a period in which prec
On 2012-05-25 18:30, Cullen Jennings wrote:
WIll the IPFIX and MIB work also be usable by v4 to v4 NATs?
Speaking as an author of draft-ietf-behave-nat-mib, our intent is to
support all kinds of NAT, but it isn't clear yet whether it will be done
in multiple drafts or a single one. There is
On 2012-05-31 04:58, Stephen Farrell wrote:
I'm with Brian and Yoav on this. I don't see a need
to change here. And I do think we might lose something
if we become too PC. If a bunch of non-native speakers
did say "yes, I found that made the document less
useful" then I'd be more convinced that a
On 07/03/12 05:51, Eggert, Lars wrote:
On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
I found it is to be odd to have a requirements document as a BCP, but I am sure
you can sort the right status out with IESG.
+1
I fail to see why Informational wouldn't be the better status.
I don't care
Wes,
Here's my take on this...
CGN as defined in this document does not only include NAT444. It is more
generic than that: it really means "multi-user NAT". Dave Thaler came up
with the example use case of the NAT in a wifi hotspot. It's just NAT44,
but it still fits with the draft's definiti
On 2012-07-09 11:03, George, Wes wrote:
While the NAT specified by this
document itself may only act on IPv4 traffic, as you note above it's
not limited to just NAT444 or even an IPv4-only *network*. The
recommendations in this doc will work for an IPv4 NAT associated with
DSLite just as easily
On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
I found the justification for REQ-6 hard to read/understand. Why does
access to
servers being on the internal network need to go through CGN at all?
Here's the thing: the server is not on the internal network. It's on the
external network, but it
(adding p...@ietf.org to the recipients list...)
Sam,
Thanks for the review, comments inline...
On 07/10/2012 02:16 PM, Sam Hartman wrote:
Requirement 9 requires a Port Control Protocol (PCP) server. I think we
need to say somewhat more about that in order for PCP to be secure on a
CGN. In thi
On 07/10/2012 04:03 PM, Sam Hartman wrote:
>> and MUST NOT support the third-party option.
Simon> I think pcp-base-26 added restrictions to THIRD_PARTY so that it
could
Simon> be used in CGN scenarios. If that is right, wouldn't it then make
Simon> sense to allow THIRD_PARTY
On 07/10/2012 10:43 PM, Tina TSOU wrote:
First, the port numbers to be allocated to CPE. Excluding Well known
port numbers should be mentioned.
As draft editor, I would ask for a justification. I can't add a
requirement without a justification.
Moreover if port numbers are allocated
to each
Le 2012-07-19 14:20, David Harrington a écrit :
The IETF could mandate a specific protocol to try to ensure
interoperability, but doing this takes the decision out of the
responsibility of the deployer to choose the best solution for the
deployment environment, and out of the responsibility of th
Le 2012-07-24 03:06, Stephane Bortzmeyer a écrit :
And since when Microsoft software is required for IETF work?
Even though I replied to the survey, this also irritated me. And I sense
a trend here. It seems that the number of non-plain-text files coming
from IAB has been increasing.
Sugges
Le 2012-08-08 12:34, Geoff Mulligan a écrit :
I also would vote to return to Minneapolis again and again even permanently.
Does nobody care about going to new places so that new people are
exposed to the IETF and may start getting involved?
We've seen this positive effect many times when we
Le 2012-09-05 09:12, Michael Richardson {quigon} a écrit :
Let me suggest that at the IETF, where the mailing list is king, you can't join
the Elite if you can't quote email properly.
Maybe we should *state* this.
Maybe I'm also concerned because many in the former "elite" have moved to Apple
M
Le 2012-09-07 14:36, Scott Brim a écrit :
Maybe I'm also concerned because many in the former "elite" have
moved to Apple Mail, and it seems that it is bug compatible with
Outlook in it's assumption that format=flowed is the default, an act
which destroys email quoting, and therefore discussion.
Le 2012-09-07 15:15, Melinda Shore a écrit :
On 9/7/12 10:53 AM, Simon Perreault wrote:
Thunderbird is correct by default AFAIK.
Unfortunately not on Mac OS. It's become automatic for me to
hit command-R when replying, but that doesn't solve the basic
problem.
That's what we
Le 2012-09-10 06:46, Dearlove, Christopher (UK) a écrit :
If someone wants to provide guidance on how to do a least bad job
with Outlook, that will be gratefully received.
Found this using the Google:
http://home.in.tum.de/~jain/software/outlook-quotefix/
No idea if it's any good as I don't ha
Le 2012-09-26 05:31, Stephen Farrell a écrit :
stuff that's utterly incompressible
Oops - let's see if the phone spell checker gets incomprehensible right this
time:-)
I understood "incompressible" as equivalent to "pure random noise", and
it made sense! :)
Simon
--
DTN made easy, lean, a
Le 2013-07-11 02:04, Hui Deng a écrit :
> We submitted two drafts to help people here to correctly call chinese
> people names:
>
> http://tools.ietf.org/html/draft-deng-call-chinese-names-00
>http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00
Very cool! Thanks for writing this!
I h
Le 2013-07-11 16:22, Cyrus Daboo a écrit :
> So, from a technical standpoint, it seems better to always represent
> user names using components (last, first, middle)? vCard does have an
> "N" property where individual components of a name can be broken out.
I'm nowhere near an expert on this topic
Le 2013-07-11 17:44, John C KLENSIN a écrit :
>> Hence the common practise in some academic circles of giving
>> the family name in all capitals, to show which it is. So
>> whether you see Junichiro KOIZUMI or KOIZUMI Junichiro, you
>> know what you're seeing.
>
> Not just in academic circles but
Le 2013-07-22 13:55, Philipp Kewisch a écrit :
>> -- 3.2.1.1:
>>
>> What happens for future versions of vCard? Do you simply use the new version
>> number, or would we need a new version of this spec? I suspect the latter.
>> If true, it might be worth mentioning that, or somewhere early in the d
This draft's premise is interesting, but the implementation leaves to be
desired. That is, I like the idea of fragment identifiers for CSV, but
row/column/cell-based selection doesn't address my need.
My need is based on the CSV files generated from IANA registries. Here's
one:
https://www.iana.o
Le 2013-10-11 17:52, Barry Leiba a écrit :
> This is an Independent stream document, and the IETF doesn't have
> change control of the document.
>
> The authors can certainly accept your comments at their discretion.
> But this last call isn't for comments on the *document*. It's only to
> assess
41 matches
Mail list logo
