Hi Spencer,

> On 21 Oct 2015, at 18:42, Spencer Dawkins <[email protected]> 
> wrote:
> 

[snip]
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> "RLOC" is spelled out on second use, but not on first use.
> 

Thanks for pointing this out. We have to fix this and a few other acronyms that 
we use first and define later.


> "Addresses are semantically separated in two:" was a bit rough for me.
> Perhaps something like "Addresses have two components with different
> semantic meanings:”?

I fear it could be misinterpreted. Is not the address that has two 
“components”, is the addressing space that is split in two semantically 
different sub spaces.

What is we out the following text:

        “Addresses are separated in two sets that have different semantics 
meanings”

Would that work?


> 

> In this text:
> 
>   Middle boxes/filters:  because of encapsulation, the middle boxes may
>         not understand the traffic, which can cause a firewall to drop
>         legitimate packets.  In addition, LISP allows triangular or
>         even rectangular routing, so it is difficult to maintain a
>         correct state even if the middle box understands LISP.
>         Finally, filtering may also have problems because they may
>         think only one host is generating the traffic (the ITR), as
>         long as it is not de-encapsulated.  To deal with LISP
>         encapsulation, LISP aware firewalls that inspect inner LISP
>         packets are proposed [lispfirewall].
> 
> I wonder if we're far enough along with RFC 7258/BCP 188 that we expect
> middleboxes may not understand traffic, whether it's encapsulated or not,
> because of encryption. Perhaps that's worth a thought, if not a mention.
> 

May be modifying the first sentence as follows:

 Middle boxes/filters:  because of encapsulation or encryption, the middle 
boxes may
        not understand the traffic, which can cause them to drop
        legitimate packets ([RFC7258]).

Would that work?


thanks

ciao

Luigi

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to