I am surprised at the lack of comment on this I-D on its use of terminology. I
have seen and learnt from many discussions on this list that have teased out
what concept it is we are really talking about (e.g. identity v identifier) and
this I-D seems somewhat weak in that regard.
Thus the
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:
Hi,
here are my substantive comments
Look for [eric].
Eric
7.3.1. Timer Expiration Event
EVE_ENTRY_EXPIRE: The lifetime of an entry expires
[eric] 2 minutes sounds very long. DHCP client timeout is 1 sec for the
first
message. Then multiplied by 2, etc. What is the rational behind this
On 2012-03-12 18:48, Peter Saint-Andre wrote:
...
hat type='AD'/
Julian, I think it would be helpful for you to submit your latest copy
before the deadline today, so that we don't need to wait until March 26.
Done; I usually avoid changing drafts during LC; but I think it makes
sense in this
Dear All,
Please consider my comments for the LC:
* I'm concerned with the very title of the document, Methodology for
benchmarking MPLS protection mechanisms, even though only MPLS-TE FRR being
considered while LSP end-to-end and segment protection implicitly being kept
out of the scope.
I agree that the allocation of a code point should be to a specific version of
8113.1, and specifically should be to the final version that is approved by the
ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T).
This would imply that draft-betts-itu-oam-ach-code-point
Actually John, I would have to disagree with your assertion about what
it takes to describe the archtiecture.
It may take engineering and evaluating some cache management schemes
before one can decide whether the archtiecture is a good one. But that
is very different from being able to
Ross,
i am afraid that you missed the point. There will not be a final version since
as written in draft-betts, all ITU recommendations are subject to revisions,
and the code point will also be used for future revisions of the document. New
messages/protocols can be defined in future revisions
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-melnikov-smtp-priority-09
John,
On 3/13/12 8:23 PM, John Scudder wrote:
Re cache management schemes, I think that depends on whether you mean system
level behavior of a small-scale system, or one operating at large scale or
under some kind of stress. The earlier discussion notwithstanding, for
practical purposes
From: John Scudder j...@juniper.net
Re cache management schemes, I think that depends on whether you
mean system level behavior of a small-scale system, or one
operating at large scale or under some kind of stress. The earlier
discussion notwithstanding, for practical
On 3/13/12 3:37 AM, t.petch wrote:
I am surprised at the lack of comment on this I-D on its use of terminology.
I
have seen and learnt from many discussions on this list that have teased out
what concept it is we are really talking about (e.g. identity v identifier)
and
this I-D seems
On 3/13/12 4:19 PM, Peter Saint-Andre wrote:
On 3/13/12 3:37 AM, t.petch wrote:
I am surprised at the lack of comment on this I-D on its use of terminology.
I
have seen and learnt from many discussions on this list that have teased out
what concept it is we are really talking about (e.g.
A new IETF non-working group email list has been created.
List address: i...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/its/
To subscribe: https://www.ietf.org/mailman/listinfo/its
Purpose: This list is for discussions relative to the use of Internet
communication protocols in
14 matches
Mail list logo
