Re: [lisp] Update Proposed CHarter

Hello Chairs,

Thanks for the text. One minor comment: in addition to Fabio's suggestion,
perhaps we can also include a wording that explicitly includes control
plane protocol extensions needed to accommodate the new mapping functions.
I have captures both additions in << >> below.

- Alternative Mapping System Design. By extending LISP with  new protocols
support it is also necessary to develop the required mapping function <<
and control plane >> extensions to operate LISP map-assisted  networks
(which might include Hierarchical Pull, Publish/Subscribe, or Push models
and related security extensions, << or alternative transports of the LISP
control protocol >>).

Regarding the ordering of the list, I believe we should stay away from
officially prioritizing the list in the charter. Therefore I think we
should avoid numbering the list. I have no objection to re-arranging the
list in any order as long as it does not imply prioritization.

Best,
Vina

On 1/4/16 3:09 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

>And this is why I tend to prefer an un-ordered list.  But if the WG
>wants to try to agree on a prioritized list, go for it.
>
>Yours,
>Joel
>
>On 1/4/16 5:42 PM, Sharon wrote:
>> I agree with Dino, will pull up (1) though, it allows carriers to
>>anchor access services in POPs where the MAO operations are based.
>> Cloud RAN, NFV, VPN .. type services.
>>
>> --szb
>>
>> On Jan 4, 2016, at 11:49 AM, Dino Farinacci <farinacci@gmail.com> wrote:
>>
>>>> If the text looks good for you, please state so in the mailing list.
>>>
>>> I am fine with the text. But I have one comment about sequencing the
>>>list below. Can we sequence the list in order of generality or
>>>importance?
>>>
>>> See inline comment below.
>>>
>>>> Beside this main focus, the LISP WG work on the following items:
>>>>
>>>> -       NAT-Traversal
>>>>
>>>> -       Mobility
>>>>
>>>> -       Data-Plane Encryption
>>>>
>>>> -       Multicast: Support for overlay multicast by means of
>>>>        replication as well as interfacing with existing
>>>>        underlay multicast support.
>>>>
>>>> -       Models for managing the LISP protocol and deployments
>>>>        that include data models, as well as allowing for
>>>>        programmable management interfaces. These managament
>>>>        methods should be considered for both the data-plane,
>>>>        control-plane, and mapping system components
>>>>
>>>> -       Multi-protocol support: Specifying the required
>>>>        extensions to support multi-protocol encapsulation
>>>>        (e.g.,   L2 or NSH  Network Service Headers). Rather
>>>>        than developing new encapsulations the work will aim
>>>>        at using existing well-established encapsulations or
>>>>        emerging from other Working Grops such as  NVO3 and SFC.
>>>>
>>>> -       Alternative Mapping System Design. By extenting LISP
>>>>        with  new protocols support it is also necessary to
>>>>        develop the required mapping function extensions to
>>>>        operate LISP map-assisted  networks (which might
>>>>        include Hierarchical Pull, Publish/Subscribe, or Push
>>>>        models and related security extension).
>>>
>>> I will number the above as 1 - 7 and feel they should be ordered in
>>>sequence:
>>>
>>> 6, 7, 2, 4, 3, 1, 5
>>>
>>> Dino
>>>
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>
>_______________________________________________
>lisp mailing list
>lisp@ietf.org
>https://www.ietf.org/mailman/listinfo/lisp