Huub sed:
Section 6 focusses on the interworking between two toolsets
In transport networks we *never* have peer-2-peer OAM interworking.
If it was required it would have explicitly been mentioned in
the MPLS-TP requirements RFC.
Can I just ask for some clarification of this.
We have
Yuxia wrote:
I also agree with Huub.
As a consensus reached in Beijing meeting, mechanism using the tools defined
for MPLS is a default tool set and another using the tools defined in
G.8013/Y.1731
is an optional one.
That is a an interesting and helpful statement. Obviously, most IETF
Original Message -
From: Julian Reschke julian.resc...@gmx.de
To: t.petch daedu...@btconnect.com
Cc: Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com; ietf@
ietf.org
Sent: Saturday, October 08, 2011 3:07 PM
On 2011-10-08 09:20, t.petch wrote:
If I'm looking for an internet
Adrian,
A similar statement is already included in draft-tsb-mpls-tp-ach-ptn-01
5.3. LSP or PW originating in a PTN network and terminating in a PSN
network
In this case the PW (or LSP) originates (or terminates) in a PTN and
terminates (or originates) in a PSN. The default OAM for
Are we now going to be subject to daily updates?
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Huub van Helvoort
Sent: Sunday, October 09, 2011 7:42 AM
To: IETF Discussion
Subject: Re: Last Call:
Hi.
I don't know who was responsible for the Watersprings archive, but I
think we should send whoever it was a vote of thanks for providing this
(free) resource during all the years that the IETF was not able or
willing to provide it.
So THANK YOU! It was extremely useful.
But I am now
As a consensus reached in Beijing meeting, mechanism using the tools defined
for MPLS is a default tool set and another using the tools defined in
G.8013/Y.1731 is an optional one.
This document is about the consequences of there being an optional OAM solution
if it is implemented by
The Gen-ART review of the -08 version raised two significant open issues.
I will defer to the DNS experts in the INT area to determine whether the changes
in the -09 version resolve the issues around the format of the service name in
the
DNS SRV records [1], although based on IESG Evaluation
On 2011-10-10 11:23, t.petch wrote:
Julian
On a thread on this list some time ago, IANA reported progress in converting
their web site to XML and at the same time, apologised for how long it now takes
to access the Port Registry. Having accessed it - a good chance to complete The
Times
Hello Malcolm,
A similar statement is already included in draft-tsb-mpls-tp-ach-ptn-01
The statement I found interesting was about consensus reached in an ITU-T
meeting. I don't find this recorded in the Internet-Draft you pointed to.
I asked whether there is a possibility that this message
On 10/10/2011 07:17, Elwyn Davies wrote:
But I am now quite happy with the IETF draft archive and I have a couple
of customized Firefox search entries that minimize the amount of typing
needed.
https://addons.mozilla.org/en-US/firefox/addon/ietf-doc-fetch-73306/
You can type in an RFC number,
Very nice, thanks!!
On Mon, Oct 10, 2011 at 2:46 PM, Doug Barton do...@dougbarton.us wrote:
On 10/10/2011 07:17, Elwyn Davies wrote:
But I am now quite happy with the IETF draft archive and I have a couple
of customized Firefox search entries that minimize the amount of typing
needed.
I support this doc, and concur with Stewart's comments.
Contrary to what some have suggested, we sometimes (ofttimes?) have more than
one standard for no good technical reason. Sometimes very large,
competing companies back different standards for parochial reasons,
to the detriment of
Hello Adrian,
You typed:
Yuxia wrote:
I also agree with Huub.
As a consensus reached in Beijing meeting, mechanism using the tools defined
for MPLS is a default tool set and another using the tools defined in
G.8013/Y.1731
is an optional one.
That is a an interesting and helpful
Huub,
You say
The liaison informs the IETF that on September 16 recommendation
G.8113.2 was consented in a WP3 plenary meeting. In both the Beijing Q10
expert meeting where the consent was proposed and the WP3 plenary
meeting where the consent took place, there were no objections.
My
On 10/10/2011 20:25, Andrew G. Malis wrote:
Very nice, thanks!!
On Mon, Oct 10, 2011 at 2:46 PM, Doug Bartondo...@dougbarton.us wrote:
On 10/10/2011 07:17, Elwyn Davies wrote:
But I am now quite happy with the IETF draft archive and I have a couple
of customized Firefox search entries
On 10/10/2011 08:41 PM, Stephen Kent wrote:
As the co-chair of PKIX, which has two standards for cert management
(CMC and CMP), for exactly the bad reasons I cite above, I am intimately
familiar with this sort of problem. I failed, in my role as PKIX
co-chair, to prevent this in that WG. Let's
Not used to send replies on the IETF ML but clearly for this one: +1 :)
watersprings.org was a real great help for me! Thanks!!!
Best regards.
JMC.
2011/10/10 Elwyn Davies elw...@dial.pipex.com:
Hi.
I don't know who was responsible for the Watersprings archive, but I think
we should send
On 2011-10-11 10:18, Stephen Farrell wrote:
...
(What's the relevant plural
for mea cupla I wonder? ;-)
Nostra culpa, if you want a single fault owned by us.
It's nostrae culpae for multiple faults by all of us.
Perhaps it should be added to the Note Well.
Brian
The IESG has approved the following document:
- 'Carrying Q.850 Codes in Reason Header Fields in SIP (Session
Initiation Protocol) Responses'
(draft-jesske-dispatch-update3326-reason-responses-05.txt) as a
Proposed Standard
This document has been reviewed in the IETF but is not the product
The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'IPPM standard advancement testing'
draft-ietf-ippm-metrictest-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Reserved IPv4 Prefix for Shared CGN Space'
draft-weil-shared-transition-space-request-09.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has approved the following document:
- 'IPv6 in 3GPP Evolved Packet System'
(draft-ietf-v6ops-3gpp-eps-08.txt) as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are Ron Bonica and Dan Romascanu.
A URL of this Internet
A new Request for Comments is now available in online RFC libraries.
RFC 6395
Title: An Interface Identifier (ID) Hello
Option for PIM
Author: S. Gulrajani, S. Venaas
Status: Standards Track
Stream: IETF
A new Request for Comments is now available in online RFC libraries.
BCP 9
RFC 6410
Title: Reducing the Standards Track to
Two Maturity Levels
Author: R. Housley, D. Crocker,
E. Burger
Status:
25 matches
Mail list logo
