Hi Dan
inline please,
I believe the objection is against non-deterministic translation,
rather than stateful versus stateless. By non-deterministic, I mean
that the subscriber's equipment (e.g., CPE) cannot determine the
mapping it will have on the Internet. A+P mechanisms are
Could you
Emil Ivov wrote:
Hey Alexey,
Hi Emil,
On 27 sept. 2011, at 00:24, Alexey Melnikov alexey.melni...@isode.com
mailto:alexey.melni...@isode.com wrote:
Jonathan Lennox wrote:
Hi, Alexey -- thank you for the Gen-ART review.
Hi Jonathan,
Alexey Melnikov writes:
Question: are the two
--- Original Message -
From: Yoav Nir y...@checkpoint.com
To: Paul Hoffman paul.hoff...@vpnc.org
Cc: Stuart Cheshire chesh...@apple.com; IETF-Discussion list
ietf@ietf.org
Sent: Monday, September 26, 2011 10:11 PM
On Sep 26, 2011, at 5:25 AM, Paul Hoffman wrote:
On Sep 25, 2011, at 7:20
On 9/27/11 12:45 AM, Martin Rex m...@sap.com wrote:
So there seem to be two problems:
- The server (svn.tools.ietf.org) does not seem to be sufficiently
aware of the server names that it is servicing.
If it takes more than a server configuration file change to make it
aware of that
On 27 Sep 2011, at 5:45 , Christian Huitema wrote:
if an address space is somehow set aside, we have no mechanism to enforce
that only ISP use it. So we have to assume it will be used by whoever feels
like it.
How is that different from the current situation? Is there a reason why
The choice of service name for this transport seems unfortunate; having a port
number registry with a service in it called 'port' may be witty but seems like a
source of future confusion.
I notice that IANA currently have a service name of 'pim-port' which seems a
better idea and one that I think
-Original Message-
From: Hui Deng [mailto:denghu...@gmail.com]
Sent: Monday, September 26, 2011 11:01 PM
To: Dan Wing
Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com;
ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org
Subject: Re: [BEHAVE] Last Call:
-Original Message-
From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com]
Sent: Monday, September 26, 2011 11:14 PM
To: dw...@cisco.com; satoru.matsush...@gmail.com; ietf@ietf.org
Cc: softwi...@ietf.org; beh...@ietf.org
Subject: RE: [BEHAVE] Last Call:
On 9/27/11 12:45 AM, Martin Rex m...@sap.com wrote:
- The server (svn.tools.ietf.org) does not seem to be sufficiently
aware of the server names that it is servicing.
If it takes more than a server configuration file change to make it
aware of that additional hostname, then there is a
From: ietf-boun...@ietf.org On Behalf Of Iljitsch van Beijnum
And who cares anyway? If people feel it's a good idea to use addresses in the
240/4 block, more power to them. That saves more usable addresses for other
uses.
WEG] The problem is that people really can't today, because vendors
Hi,
Yoav's tcpdump analysis, together with Martin's observations, helped
me find the problem at the server end. I've changed the config now
(addding a missing 'NameVirtualHost *:443' to Apache's config), and
Stuart's example now works for me on OS X Snow Leopard and Lion:
svn info
-Original Message-
From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com]
Sent: Tuesday, September 27, 2011 7:24 AM
To: dw...@cisco.com; satoru.matsush...@gmail.com; ietf@ietf.org
Cc: softwi...@ietf.org; beh...@ietf.org
Subject: RE: [BEHAVE] Last Call:
Hi, Alexey -- thank you for the Gen-ART review.
Alexey Melnikov writes:
Question: are the two encoding of the audio level indication option specified
in the document really necessary?
Do you mean the one-byte vs. two-byte forms of the header extension (Figure 1
vs. Figure 2)? These are the
Hey Alexey,
On 27 sept. 2011, at 00:24, Alexey Melnikov alexey.melni...@isode.com wrote:
Jonathan Lennox wrote:
Hi, Alexey -- thank you for the Gen-ART review.
Hi Jonathan,
Alexey Melnikov writes:
Question: are the two encoding of the audio level indication option
specified in the
I believe the objection is against non-deterministic translation, rather
than
stateful versus stateless. By non-deterministic, I mean that the
subscriber's
equipment (e.g., CPE) cannot determine the mapping it will have on the
Internet. A+P mechanisms are deterministic (including 4rd,
I don't understand why that is significant enough factor for IETF to
(not)
recommend some double translation variants. I mean does existing
applications work better if double translation is done in
deterministic manner?
Yes, it allows the CPE to implement an ALG -- if an application
--On Monday, September 26, 2011 13:15 -0700 Bob Hinden
bob.hin...@gmail.com wrote:
John,
I don't see how you took what I said and then interpreted it
as suggesting that I was saying proposing an absolute
dictatorship. You do have a good imagination :-)
I didn't take your proposal that
On 2011-09-28 08:03, John C Klensin wrote:
snip
... Interesting it is exactly the
assumption that the IAB Chair will have first hand involvement
in everything that the IAB does that is cited an example of why
it is necessary to have the IAB Chair on the IASA. So, if the
IAB succeeds in
Hi, all,
The IANA considerations in this doc are in error and need updating as
follows. I agree that PORT is a poor acronym choice, FWIW.
Joe
11. IANA Considerations
This specification makes use of a TCP port number and a SCTP port
number for the use of PIM-Over-Reliable-Transport
Please see attached review.
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 27 Sep 2011, at 7:32, Henrik Levkowetz wrote:
Hi,
Yoav's tcpdump analysis, together with Martin's observations, helped
me find the problem at the server end. I've changed the config now
(addding a missing 'NameVirtualHost *:443' to Apache's config), and
Stuart's example now works for
Hi, Roni and Qin
Thank you for your comments!
I'll correspond these issues and update the draft soon.
Best regards,
Kazuhiro
2011/9/27 Qin Wu bill...@huawei.com:
Hi, Roni:
Thank for your replies. Your proposed changes look good to me.
I would like to see the remaining minor issues are
The IESG has approved the following document:
- 'RPL Objective Function Zero'
(draft-ietf-roll-of0-20.txt) as a Proposed Standard
This document is the product of the Routing Over Low power and Lossy
networks Working Group.
The IESG contact persons are Adrian Farrel and Stewart Bryant.
A URL
The IESG has approved the following document:
- 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP'
(draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt) as a Proposed Standard
This document is the product of the Pseudowire Emulation Edge to Edge
Working Group.
The IESG contact persons
The IESG has no problem with the publication of 'Overview of Email DNSBL
Best Practise' draft-irtf-asrg-bcp-blacklists-10.txt as an
Informational RFC.
The IESG wants to make the IRSG aware of its concern that there is
a potential for confusion between the IETF Best Current Practice (BCP)
series
The IESG has no problem with the publication of 'Performance Evaluation
of Routing Protocol for Low Power and Lossy Networks (RPL)'
draft-tripathi-roll-rpl-simulation-07.txt as an Informational RFC.
The IESG would also like the RFC-Editor to review the comments in
the datatracker
The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'A Framework for the Control of Wavelength Switched Optical Networks
(WSON) with Impairments'
draft-ietf-ccamp-wson-impairments-07.txt as an Informational RFC
The
A new IETF working group has been proposed in the Applications
Area. The IESG has not made any determination as yet. The following
draft charter was submitted, and is provided for informational purposes
only. Please send your comments to the IESG mailing list (i...@ietf.org)
by Tuesday,
28 matches
Mail list logo
