Vince, Dino,
I wrote:
I'd still like to understand the ICMP message situation better. I realize
that the traffic is supposed to be unidirectional, but how would, say,
lower MTU somewhere along the path be dealt with? I'm not necessarily
asking for a change in what the spec does, but it should
I have reviewed this specification. I think it is ready to move forward, and I
have sent it to IETF Last Call. I did see a couple of minor editorial issues,
however (see below). You may fix those either by issuing a new draft or wait
until further issues are brought up in directorate or other
Vince,
I'm looking at the Map-Request message format and cannot quite convince
myself that there would never be a situation where MTU would be exceeded.
99.999% of the time it would be fine, but I think we need to describe (if
not fix) what happens when its not. How about adding the following
Yes, this text is great. Thank you. Put it in the draft and lets move forward.
Jari
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
I am reviewing this draft. Here's the first part of my review. So far I like
what I've seen, but there are a few small observations below. I'm at the
beginning of Section 4, and will continue tomorrow with the rest.
Technical:
2. Introduction
I liked how this section was written. I would
Continuing with my review. Many of the observations below are questions. I may
understand most of these better once I finish the whole document, but I wanted
to send out my notes already now.
Technical:
o End-systems (hosts) only send to addresses which are EIDs. They
don't know
This is the last part of my review, as far as the actual document contents go.
I will send another summary e-mail.
Technical:
14.1. LISP Address Type Codes
Instance ID type codes have a range from 0 to 15, of which 0 and 1
have been allocated [LCAF]. New Type Codes MUST be allocated
Yes, but setting up the entire system so that this works would be challenging
(how names resolve to addresses, how applications know about this, etc). But it
probably doesn't matter, it is of course true that it could be done. My point
was that this is probably not the usual configuration, and
,
and given that this is experimental,
it seems sufficient to leave the text the way it is.
Yours,
Joel
On 10/27/2011 1:04 PM, Dino Farinacci wrote:
On Oct 23, 2011, at 5:13 AM, Jari Arkko wrote:
...
Second, I wish you would have specified the source address checks better. Are
there situations
Dino,
Technical:
Overall, the security considerations section is a bit thin. I don't think we
need a lot of additional text, but there are some additional pieces of
information that need to be added. Some suggested text below.
The nonce, coupled
with the ITR accepting only solicited
Dino,
It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work
best.
Yes, but I think we should also acknowledge that defending against cache
trashing attacks is
Iana sect looks good (but i will review lcaf parts in another email). One nit
though: Sect 14, change ietf consensus to ietf review. The term changed in rfc
5226.
Jari
Dino Farinacci d...@cisco.com wrote:
I'm not sure if we have seen a response, but I also don't think it is hard
to develop
Yakov,
Furthermore, as John Scudder asked in his e-mail on 9/28, the base
spec calls out a number of areas that require more experimentation.
A simple grep will find these. These experiments and what has been
learned from them should be documented. The same applies if other
specs have similar
Copying the WG list as well on the results of the IESG review of
draft-ietf-lisp:
We discussed this draft on our IESG call tonight. The draft (as well as other
Lisp drafts) has been very carefully reviewed by everyone on the IESG, and I
think the feedback is useful. Of course there are
Internet Area Directors:
Ralph Droms rdroms.i...@gmail.com
Jari Arkko jari.ar...@piuha.net
Internet Area Advisor:
Jari Arkko jari.ar...@piuha.net
Secretaries:
Wassim Haddad wassim.had...@ericsson.com
Luigi Iannone lu...@net.t-labs.tu-berlin.de
Mailing Lists
I have reviewed this document.
In general, it is well written and almost ready to go forward. There are a
couple of areas that need further text, however. The main issue is a clear
description of the to-experiment and problematic areas of LISP interworking.
(Making those is also needed in
Was there a response on this, and a new document version, or did I miss
something? I'd like to take this document forward but we need those changes
first.
I realize that you have many documents still in the IESG discussion, but part
of the criticism that we've gotten in IESG review is that
On 03.02.2012 20:21, Darrel Lewis wrote:
Jari,
Sorry for taking so long to respond to your review. Please find suggested text
below as well as a proposed -03 draft attached.
On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote:
I have reviewed this document.
In general, it is well written
That also works for me.
Jari
On 03.02.2012 22:14, Joel M. Halpern wrote:
Removing option 1 would solve my concern very nicely. Thanks.
Joel
On 2/3/2012 3:10 PM, Darrel Lewis wrote:
On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote:
I am a bit concerned that the description of the cases
On 15.02.2012 00:48, Dino Farinacci wrote:
I have some news for you. The LISP base specification has just been approved
yesterday, joining the three other documents from this working group that had
already been approved earlier. We'll be working with the remaining two in the
coming weeks.
I
On 15.02.2012 23:31, Thomas Narten wrote:
A WG Review message for this WG already went out a month ago.
What has changed to necessitate another Last Call?
Could the-powers-that-be please make it easier for those who might
care to understand if there is something here that we should know and
I hear what you are saying. But I think the opinion in the IESG at least was,
however, that those three really are high priority, and that other documents
before them are not so useful before they are completed. I guess it is a
different perspective, whether you do things top-down or
Thanks for your review, Alexey!
On 11 Feb 2015, at 13:55, Alexey Melnikov alexey.melni...@isode.com wrote:
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
Joel,
> There have beeen some comments that we should make clearer that the top
> priority (although not preventing the WG from working on other topics) is
> moving the needed core documents from Experimental to PS. That change is one
> we can and should make.
That is ok.
> Beyond that, I
Jari Arkko has entered the following ballot position for
charter-ietf-lisp-03-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along
Jari Arkko has entered the following ballot position for
draft-ietf-lisp-ddt-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Many thanks for your review, Pete.
I have balloted no-objection for this document in today’s IESG telechat.
Authors, please note Pete’s editorial suggestion.
Jari
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lisp mailing
Jari Arkko has entered the following ballot position for
draft-ietf-lisp-lcaf-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
28 matches
Mail list logo
