Le 2012-04-03 à 14:43, guoliang han a écrit :
Hi, Remi:
I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:
2012/4/3 Rémi Després despres.r...@laposte.net
Hi, Guoliang,
Interesting enough, the example you give illustrates that MAP-T
2012-04-03 18:32, Marc Blanchet :
I don't see a way out of this thread.
my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.
+1
RD
Above all, I think having a stable specification (i.e. RFC) that
Here's the situation. There was no clear consensus in the WG meeting in Paris.
But the IETF conducts its business on the mailing list, so - as we always do -
the chairs asked for feedback on the two questions asked in Paris. We'll use
the responses to assess if there is consensus for the
Hi, Remi:
Pls read my comments below.
2012/4/3 Rémi Després despres.r...@laposte.net
2012-04-03 14:43, guoliang han :
Hi, Remi:
I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:
2012/4/3 Rémi Després despres.r...@laposte.net
Hi, Guoliang,
Le 2012-04-03 à 15:41, Guoliang a écrit :
Hi, Remi:
Pls read my comments below.
2012/4/3 Rémi Després despres.r...@laposte.net
Le 2012-04-03 à 14:43, guoliang han a écrit :
Hi, Remi:
I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:
Dear Softwires WG chairs.
For how long will you leave this useless cockfight go on instead of
steering the working group into a direction, that may enable us to
decide on something and chose the direction?
We are running in circles here and just amplificating the noise, coming
from certain
I don't see a way out of this thread.
my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.
Above all, I think having a stable specification (i.e. RFC) that implementers
can code against and providers to require is
The irony is that this is an apples and oranges comparison, and throwing
away ripe apples into some box with raw oranges looks rather unfair.
Some of the of the indicators are:
- MAP is not only the result of a consensus of a broad WG design team, but
also that of numerous authors of the merged
well, i cannot help but send out this late Apr-1 joke: let's see what is
the problem publishing the two document plus an informational doc analysing
what problems 4rd-u introduces to architecture and real operation, with
them all stable and having an RFC number for each? if this is fine, we all
Fully agree with Maoke!
This is not just the issue of publishing two documents...To accormodate
with 4rd-U, many existing RFCs should be updated, like RFC
4291,RFC6052,etc. There is no evidence to show that we need to do that
because 4rd-U havn't been shown that it is workable in today's
10 matches
Mail list logo
