All,
Why section 5.1 is an author's impression:
Statement:
SONET and SDH were defined as competing standards
Fact:
SONET was developed first by ANSI based on the 24 channel PDH hierarchy
existing in North America and Japan. The basic rate based on DS3.
Some time later ETSI developed SDH based
At 12:42 26-09-2011, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational
RFC
The IESG plans to make
On Sep 29, 2011, at 1:06 AM, Huub van Helvoort wrote:
All,
I propose to completely remove section 5 of this draft.
The reason:
The IETF should *NOT* document any comment on any multiple standards
developed by other SDOs which are outside of the IETF's scope.
Especially standards
A few more thoughts on this thread.
All,
I propose to completely remove section 5 of this draft.
The reason:
The IETF should *NOT* document any comment on any multiple standards
developed by other SDOs which are outside of the IETF's scope.
Especially standards like like
On 09/29/2011 09:18 AM, Thomas Nadeau wrote:
A few more thoughts on this thread.
All,
I propose to completely remove section 5 of this draft.
The reason:
The IETF should *NOT* document any comment on any multiple standards
developed by other SDOs which are outside of the IETF's
All,
From my personal knowledge, the comments from Huub are accurate. (I was
an active participant at the 1988 ITU meeting in Seoul where the SDH frame
format was agreed).
The IETF should not publish a consensus approved draft that contains
inaccurate information about a standard that was
Tom,
Please see in line below.
Regards,
Malcolm
Thomas Nadeau tnad...@lucidvision.com
Sent by: ietf-boun...@ietf.org
29/09/2011 07:48 AM
To
huubatw...@gmail.com
cc
The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce
ietf-annou...@ietf.org
Subject
Re: Last Call:
Tom,
Please see in line below.
Regards,
Malcolm
Thomas Nadeau tnad...@lucidvision.com
Sent by: ietf-boun...@ietf.org
29/09/2011 09:18 AM
To
huubatw...@gmail.com
cc
The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce
ietf-annou...@ietf.org
Subject
Re: Last Call:
All,
First, let me say I have no absolutely desire to enter into debate into the
substantive matter of this draft.
If the purpose of the draft is to be 'Informational' then the reader would have
a reasonable expectation for the information to be correct, especially if it is
referencing
Dear all,
As also being one of the participants directly involved in the SONET/SDH
standardization process from its inception, I would like to echo Andy's
sentiments.
Best regards,
Eve
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
-Original Message-
From: Rémi Després [mailto:remi.desp...@free.fr]
Sent: Thursday, September 29, 2011 5:14 AM
To: Softwires-wg
Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion
list; Behave WG
Subject: Re: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host
Hello Dan,
Can you run an FTP server on the BIH host, and have it do active mode
transfers and passive mode transfers?
Could you elaborate the scenario? You assume BIH host taking FTP sever.
I'm not sure whether following scenarios are correct
There are two possibilities
Option 1:
-Original Message-
From: Rémi Després [mailto:remi.desp...@free.fr]
Sent: Thursday, September 29, 2011 3:13 AM
To: Dan Wing
Cc: 'Softwires-wg'; 'Behave WG'; 'IETF discussion list'; 'Teemu
Savolainen'
Subject: Re: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host
(BIH))
Le
-Original Message-
From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On
Behalf Of GangChen
Sent: Thursday, September 29, 2011 9:09 AM
To: Dan Wing
Cc: Hui Deng; beh...@ietf.org; ietf@ietf.org; softwi...@ietf.org;
Cameron Byrne
Subject: Re: [BEHAVE] Last Call:
If a host has several interfaces, each interface must have its own
private IPv4 address (case b) at this interface), or its own IPv4
address, possibly with a restricted port set (case a)).
The host must handle ports according to what applies to its chosen
interface.
Agreed. But it's not
On Thu, Sep 29, 2011 at 9:46 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote:
Hi Cameron,
If the application itself delivers an IPv4 literal via protocols like
MSN or Skype, there is a path and socket made available, that is what
this NAT46 code does.
Is there a dependency on the existence
Hi Cameron,
Very interesting ( clever indeed).
How does this clever code ensure that all but a few (pesky apps)
continue to use IPv6 interface instead of the NAT46 interface?
Cheers,
Rajiv
-Original Message-
From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On
Behalf
On Sep 28, 2011, at 8:12 PM, Cameron Byrne wrote:
On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote:
+1 ... since the alternative is that apps that require ipv4 sockets and
pass ipv4 literals are stranded on ipv6 only networks.
Running code on the n900 shows that
Le 28 sept. 2011 à 23:16, Cameron Byrne a écrit :
...
It can't determine the public IP address and port of a mapping on the
NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because
the CGN is going to make a dynamic mapping when it sees a UDP, TCP,
or ICMP packet from
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: draft-ietf-drinks-usecases-requirements-06
Hi Cameron,
If the application itself delivers an IPv4 literal via protocols like
MSN or Skype, there is a path and socket made available, that is what
this NAT46 code does.
Is there a dependency on the existence of IPv4 literal so as to use the
v4-interface provided by NAT46 code? IOW, does
I'm having a hard time understanding just what this document is trying to do
I understand from the title that it is supposed to be telling the reader why a
single OAM
solution is a good idea for MPLS-TP
if that is the case I'm not all that sure what the purpose of sections 4 and 5
are for -
Scott,
On 2011-09-30 05:30, Scott O Bradner wrote:
I'm having a hard time understanding just what this document is trying to do
I understand from the title that it is supposed to be telling the reader why
a single OAM
solution is a good idea for MPLS-TP
if that is the case I'm not all
On Sep 29, 2011, at 3:52 PM, Brian E Carpenter wrote:
Scott,
On 2011-09-30 05:30, Scott O Bradner wrote:
I'm having a hard time understanding just what this document is trying to do
I understand from the title that it is supposed to be telling the reader why
a single OAM
solution is
Total of 142 messages in the last 7 days.
script run at: Fri Sep 30 00:53:02 EDT 2011
Messages | Bytes| Who
+--++--+
6.34% |9 | 7.42% | 108321 | cb.li...@gmail.com
7.04% | 10 | 5.92% |86425 |
Best is no ALG. Worse is one ALG. Even worse is two ALGs.
-d
OK, I have see that there is two solutions for just one ALG.
-Hui
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
inline please,
+1 ... since the alternative is that apps that require ipv4 sockets and
pass ipv4 literals are stranded on ipv6 only networks.
Running code on the n900 shows that nat464 provides real user and
network benefit
Can you run an FTP server on the BIH host, and have it do active
The IESG has received a request from the Call Control UUI Service for SIP
WG (cuss) to consider the following document:
- 'Problem Statement and Requirements for Transporting User to User Call
Control Information in SIP'
draft-ietf-cuss-sip-uui-reqs-06.txt as an Informational RFC
The IESG
The IESG has approved the following document:
- 'MPLS On-demand Connectivity Verification and Route Tracing'
(draft-ietf-mpls-tp-on-demand-cv-07.txt) as a Proposed Standard
This document is the product of the Multiprotocol Label Switching Working
Group.
The IESG contact persons are Adrian
A new IETF non-working group email list has been created.
List address: d...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/dcon/
To subscribe: https://www.ietf.org/mailman/listinfo/dcon
Purpose: This list is for discussions relating to the potential setup of a new
IETF working group
A new IETF non-working group email list has been created.
List address: n...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/nvo3/current/maillist.html
To subscribe: https://www.ietf.org/mailman/listinfo/nvo3
Purpose: This list is to discuss potential IETF work related to providing L2
31 matches
Mail list logo
