Marc == Marc Petit-Huguenin petit...@acm.org writes:
Marc No, I was serious. I think that the best response to this
Marc kind of stuff is to do what they ask to the letter. If we can
Marc convince the senders that annotating their notice with an
Marc header will permit us to
On 7/12/2011 2:36 PM, Jorge Contreras wrote:
You may want to refer to Section 5.2 of RFC 5378, which addresses this issue:
Each Contributor agrees that any statement in a Contribution, whether generated
automatically or otherwise, that states or implies that the Contribution is
confidential
Dave == Dave CROCKER d...@dcrocker.net writes:
You may want to refer to Section 5.2 of RFC 5378, which addresses
this issue:
Each Contributor agrees that any statement in a Contribution,
whether generated automatically or otherwise, that states or
implies that the
While these notices have very little to no legal weight whatsoever, I firmly
believe that allowing their presence on our mailing list invites frivolous
lawsuits whose purpose is to cost the IETF money in the case that an
individual does not like what we are doing. One does not need to look
Francis,
Ok, It shouldn't be a negotiation but an indication to accommodate
communication to each party.
Fair point.
Ok, it is important to note the peer is limiting max frame
size not the
message size which may be still infinite in practical terms (63
bits)and we have fragmentation
However this is a consequence of adapting an existing technology to a new
application. I do not see any way around that. And the entire joint project was
based on the premise of engineering re-use not greenfield design. That is what
it said on the tin up front, and IMO why when the IETF started
Do you mean that ITU-T comments were discussed and resolution agreed during the
ITU-T meeting?
If this is the case, why the LS just provides the comments and not the agreed
resolution?
Why some ITU-T comments have been then rejected?
Messaggio originale
Da: david.i.al...@ericsson.com
The technical concern raised during the WG poll has not been resolved so the
history definetely matters.
Quoting RFC5921:
There are thus two objectives for MPLS-TP:
1. To enable MPLS to be deployed in a transport network and operated
in a similar manner to existing transport
I would not go so far as to say similar to 1731, there is actually a lot of
difference under the hood. As for uni-directional BFD, that is a BFD WG problem
at the moment.
The fact that the BFD WG has not defined a solution for unidirectional p2p and
p2mp transport paths does not make BFD a
Backwards compatibility
This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a
better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment
plus coherence with SDH, OTN, as defended by ITU-T.
For reasons like the above, however, MPLS-TP BFD won't be
It looks like this draft does not define a single solution for CC, CV and RDI
function
Messaggio originale
Da: alessandro.dalessan...@telecomitalia.it
Data: 13-lug-2011 15.02
A: IETF-Announceietf-annou...@ietf.org
Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org
Ogg: [mpls] R:
The Internet Engineering Task Force is seeking an RFC Series Editor (RSE). The
RSE has overall responsibility
for the quality, continuity, and evolution of the Request for Comments (RFC)
Series, the Internet's seminal
technical standards and publications series. The position has operational
HI Erminio:
The comments that were raised during the day long discussion with the editors
at the SG15 plenary resulted in those comments appearing in the liasion IMO in
an actionable form and resulted in a constructive outcome. I enjoyed that level
of cooperation.
The comments that were
Dear Erminio,
even though I'm not an operator but I think that you've went bit too far in
your first generalization.
Every generalization is wrong, including this one
Regards,
Greg
On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it
erminio.ottone...@libero.it wrote:
The technical
Dear Erminio,
I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even
more narrow then of the document being discussed. The G.8113.1 addresses
only bi-directional co-routed LSP and has no model to handle bi-directional
associated LSP in independent mode. And unidirectional p2p
Sorry for resending.
The changes in this version have massive impact for CC/CV/RDI implementation.
We, venders, have kept making efforts on interoperability test again and again.
These changes spoil this effort.
Especially, revival of Poll/Final sequence doesn't make sense.
Originally, in my
On Jul 14, 2011, at 6:24 AM, Dave CROCKER wrote:
On 7/12/2011 2:36 PM, Jorge Contreras wrote:
You may want to refer to Section 5.2 of RFC 5378, which addresses this issue:
Each Contributor agrees that any statement in a Contribution, whether
generated
automatically or otherwise, that
On 14/Jul/11 03:48, John Levine wrote:
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to make automatic processing
easier so receivers of this kind of notice (mailing-list or other)
can respect the wishes of the sender.
That respect would of
The JWT report is aligned with my statement.
The decision at IETF75 has been taken by the MPLS WG after the JWT and has
never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he
later removed his name because the other editors of the OAM Analysis draft were
not
They don't have legal value, period.
Sent from my iPhone
On Jul 14, 2011, at 11:28 AM, Alessandro Vesely ves...@tana.it wrote:
On 14/Jul/11 03:48, John Levine wrote:
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to make automatic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2011 08:28 AM, Alessandro Vesely wrote:
On 14/Jul/11 03:48, John Levine wrote:
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to make automatic processing
easier so receivers of this
Mark, I will work with the authors on proposed wording to describe the
context in which this technology is most applicable, and post again once
we've done that.
On 7/13/11 5:35 AM, Mark Nottingham wrote:
Personally, I think Informational is most appropriate (and probably easier),
but a
David,
T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the
simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in
T-MPLS or MPLS-TP would be rather pointless.
ITU-T was historically the right place to define such OAM. So, our interest
started with
Rui,
I kindly propose not to refer in this context to the Feb2011 WP3 and
SG15 plenary meetings
Very unfortunately, it was far away from being a technical
discussion.or technical poll.
Therefore it cannot be a reference to any argument in this context.
Regards,
Nurit
-Original
At 6:19 PM -0400 7/13/11, John C Klensin wrote:
Content-type: text/noise; noise-type=bogus-legal-disclaimer,
charset=...
Ooh, I like this proposal. We can also have noise-types for
exhortations to not print the email.
--
Randall Gellens
Opinions are personal;facts are suspect;
--On Thursday, July 14, 2011 11:00 -0700 Randall Gellens
ra...@qualcomm.com wrote:
At 6:19 PM -0400 7/13/11, John C Klensin wrote:
Content-type: text/noise;
noise-type=bogus-legal-disclaimer, charset=...
Ooh, I like this proposal. We can also have noise-types for
exhortations to
To the extent that this particular debate (that of the nature scope and success
or failure of the liaison effort) has been going on for some time:
* it's not going to be resolved.
* rehashing the history of how we came to this point it advances what agenda?
It would seems timely in the IETF
Content-type: text/noise;
noise-type=bogus-legal-disclaimer, charset=...
Ooh, I like this proposal. We can also have noise-types for
exhortations to not print the email.
If one starts down that path, there is a real possibility for a
semantically-rich environment. For example,
From: John C Klensin [john-i...@jck.com]
Randall Gellens ra...@qualcomm.com wrote:
At 6:19 PM -0400 7/13/11, John C Klensin wrote:
Content-type: text/noise;
noise-type=bogus-legal-disclaimer, charset=...
Ooh, I like this proposal. We can also have noise-types for
Total of 166 messages in the last 7 days.
script run at: Fri Jul 15 00:53:01 EDT 2011
Messages | Bytes| Who
+--++--+
3.01% |5 | 8.90% | 127627 | neil.2.harri...@bt.com
5.42% |9 | 5.11% |73305 |
However this is a consequence of adapting an existing technology to a new
application. I do not see any way around that. And the entire joint project was
based on the premise of engineering re-use not greenfield design. That is what
it said on the tin up front, and IMO why when the IETF started
Do you mean that ITU-T comments were discussed and resolution agreed during the
ITU-T meeting?
If this is the case, why the LS just provides the comments and not the agreed
resolution?
Why some ITU-T comments have been then rejected?
Messaggio originale
Da: david.i.al...@ericsson.com
The technical concern raised during the WG poll has not been resolved so the
history definetely matters.
Quoting RFC5921:
There are thus two objectives for MPLS-TP:
1. To enable MPLS to be deployed in a transport network and operated
in a similar manner to existing transport
I would not go so far as to say similar to 1731, there is actually a lot of
difference under the hood. As for uni-directional BFD, that is a BFD WG problem
at the moment.
The fact that the BFD WG has not defined a solution for unidirectional p2p and
p2mp transport paths does not make BFD a
Backwards compatibility
This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a
better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment
plus coherence with SDH, OTN, as defended by ITU-T.
For reasons like the above, however, MPLS-TP BFD won't be
It looks like this draft does not define a single solution for CC, CV and RDI
function
Messaggio originale
Da: alessandro.dalessan...@telecomitalia.it
Data: 13-lug-2011 15.02
A: IETF-Announceietf-announce@ietf.org
Cc: m...@ietf.orgm...@ietf.org, i...@ietf.orgi...@ietf.org
Ogg: [mpls] R:
The JWT report is aligned with my statement.
The decision at IETF75 has been taken by the MPLS WG after the JWT and has
never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he
later removed his name because the other editors of the OAM Analysis draft were
not
Italo,
Comments inline.
Thanks,
John
Sent from my iPhone
-Original Message-
From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it]
Sent: Wednesday, July 13, 2011 2:04 PM
To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt;
i...@ietf.org;
Dear Erminio,
even though I'm not an operator but I think that you've went bit too far in
your first generalization.
Every generalization is wrong, including this one
Regards,
Greg
On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it
erminio.ottone...@libero.it wrote:
The technical
Dear Erminio,
I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even
more narrow then of the document being discussed. The G.8113.1 addresses
only bi-directional co-routed LSP and has no model to handle bi-directional
associated LSP in independent mode. And unidirectional p2p
40 matches
Mail list logo
