Hi,

I have reviewed draft-ietf-netext-logical-interface-support-12 as part
of the Operational directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This is an Informational document. It primarily discusses how
different wireless protocols below the IP layer deal with mobility
issues and how multiple protocols can be utilized concurrently.

I find the definition of SIF a bit quirky because it first talks about
physical interfaces but laters says they may also be logical interfaces.
Why not simply say:

   SIF  (Sub Interface) - It is a physical or logical interface that
      is part of a logical interface construct.  For example, a logical
      interface may have been created abstracting two physical
      interfaces, LTE and WLAN.  These physical interfaces, LTE and WLAN
      are referred to as sub-interfaces of that logical interface.  In
      some cases, a sub-interface can also be another logical interface,
      such as an IPsec tunnel interface.

You are restricting 'logical interfaces' to IP layer interfaces. This
may be sufficient for your purposes but I think in general logical
interfaces are not necessarily restricted to be IP interfaces. Perhaps
it makes sense to carefully make a distinction between "Logical
Interface" and "Logical IP Interface" in the document.

The 'grandfather' model for interfaces in the OPS world is RFC 2863
and RFC 7223 builds on that. I think your definitions are reasonably
compatible (except that the other models do not restrict a logical
interface to an IP interface). Perhaps it makes sense to discuss this
related work or at least provide pointers, e.g., add a paragraph at
the end of section 2 explaining how the terminology introduced here
relates to RFC 2863 and RFC 7223?

In the models described in section 5, I am a bit confused how IP
addresses are deal with. Is there silently some NAT function or is the
idea that there is always some sort of encapsulation? I assume it is
the later but I just was not sure while reading the I-D.

There are a few typos and missing articles, which the RFC editor will
most likely take care of.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <

http://www.jacobs-university.de/

>