Subject: RE: [netlmm] RE: Comments on draft-krishnan-netlmm-pmip-sel-00

From: "John.zhao" <[email-masked]>
Date: Mon, 06 Aug 2007 10:27:02 +0800

Hi, kuntal

	See comments inline.

Best Rgds,
Thanks,

John.zhao
Huawei Technologies Co.,LTD
-----邮件原件-----
发件人: Chowdhury, Kuntal [mailto:[email-masked]] 
发送时间: 2007年8月3日 22:39
收件人: [email-masked]; Basavaraj Patil; Suresh Krishnan; Premec,
Domagoj
抄送: Damic, Damjan; [email-masked]
主题: RE: [netlmm] RE: Comments on draft-krishnan-netlmm-pmip-sel-00

> -----Original Message-----
> From: John.zhao [mailto:[email-masked]]
> Sent: Thursday, August 02, 2007 10:31 PM
> To: 'Basavaraj Patil'; 'Suresh Krishnan'; 'Premec, Domagoj'; Chowdhury,
> Kuntal
> Cc: 'Damic, Damjan'; [email-masked]
> Subject: RE: [netlmm] RE: Comments on draft-krishnan-netlmm-pmip-sel-00
> 
> Hi,folks
> 
> 	So from the both sides of network and terminal. Either side to do
> this decision can't cover all of scenarios. We can learn that the key
> point
> to make a full and enough decision need to be based on the negotiation
> between network and terminal.
> 
[KC>] I think we should stay away from the term "negotiation". MN can send a
hint to the network about its desired mobility mode. The network has the
prerogative to satisfy this hint (if it can) or not. It is not negotiation.
[John.zhao] The network has the ability to decide if this hint will be taken
care by itself. That is the prerogative. But to MN, even the network didn't
accepted its request, it still hope can get the response or indication from
network if it has sent the hint before. So , from this perspective , it is
negotiation.
Although we use this term, that not mean we must use the complete features
of it. We can treat the prerogative of network as a specific example of this
general progress. Otherwise, which term you think is more better?

> 	Best Rgds,
> Thanks,
> 
> John.zhao
> Huawei Technologies Co.,LTD
> 
> -----邮件原件-----
> 发件人: Basavaraj Patil [mailto:[email-masked]]
> 发送时间: 2007年8月1日 0:19
> 收件人: Suresh Krishnan; Premec, Domagoj
> 抄送: Damic, Damjan; [email-masked]
> 主题: Re: [netlmm] RE: Comments on draft-krishnan-netlmm-pmip-sel-00
> 
> 
> I agree with Suresh.
> The MN can utilize the information about the network capability or feature
> enabled in terms of making a decision about network selection, mode of
> operation etc.
> So I do believe it is necessary to provide the MN enough information or
> indication about PMIP6 service or capability in the network.
> 
> -Raj
> 
> 
> On 7/31/07 11:08 AM, "ext Suresh Krishnan" <[email-masked]>
> wrote:
> 
> > Hi Folks,
> >    Sorry for jumping in late in this discussion. I am in agreement with
> > both Kuntal and Domagoj that the selection is just a hint. But I do not
> > agree with the contention that it is NOT NECESSARY to have this
> > mechanism. From a purely network point of view this may seem useless,
> > but from a MN point of view, I can see why it will be necessary. e.g. MN
> > wants to use RO.
> >
> > Cheers
> > Suresh
> >
> > Premec, Domagoj wrote:
> >> Kuntal,
> >>
> >> OK, in the next revision of the draft we'll make it clear that the
> proposed
> >> mobility mode negotiation is just a hint for the network and that the
> final
> >> decision about the mobility mode is always done by the network. My
> >> understanding is that such clarification would address your concerns,
> if
> >> there is something else that I missed, please let me know.
> >>
> >> thanks
> >> domagoj
> >>
> >>
> >>> -----Original Message-----
> >>> From: Chowdhury, Kuntal [mailto:[email-masked]]
> >>> Sent: 30. srpanj 2007 16:01
> >>> To: Premec, Domagoj; [email-masked];
> >>> [email-masked]
> >>> Cc: Damic, Damjan; [email-masked]
> >>> Subject: RE: [netlmm] RE: Comments on
> >>> draft-krishnan-netlmm-pmip-sel-00
> >>>
> >>> Hi Domagoj,
> >>>
> >>> Please see inline....
> >>>
> >>> Thanks,
> >>> Kuntal
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Premec, Domagoj [mailto:[email-masked]]
> >>>> Sent: Monday, July 30, 2007 8:05 AM
> >>>> To: Chowdhury, Kuntal; [email-masked];
> >>>> [email-masked]
> >>>> Cc: Damic, Damjan; [email-masked]
> >>>> Subject: RE: [netlmm] RE: Comments on
> >>> draft-krishnan-netlmm-pmip-sel-00
> >>>> Hi Kuntal,
> >>>>
> >>>> It seems we're discussing different use cases here. The draft was
> >>> written
> >>>> with an idea to enable negotiation of the mobility mode (PMIP/CMIP)
> >>> during
> >>>> inital network attachment. You seem to bring up the case of changing
> >>> the
> >>>> access network and moving in/out of a PMIP domain.
> >>>>
> >>> [KC>] This is because the discussion was about _necessity_ to
> >>> define this expression-of-preference by the host. After this
> >>> email exchange, it appears that this expression-of-preference
> >>> by the host about CMIP or PMIP is merely an FYI for the
> >>> network and NOT necessary for proper operation. Basically I
> >>> have not encountered anything that breaks if this is not used.
> >>>
> >>>
> >>>>> [KC>] It is not _necessary_ for the network to know
> >>> whether the MN
> >>>>> _wants_ PMIP6 or MIP6 during initial attachment.
> >>>> I agree, it is not necessary. If the network doesn't know
> >>> the MN's MIP
> >>>> capabilities, it will default to the PMIP mode, and everything will
> >>> work
> >>>> fine. IMO, if the MN is MIP6 capable, it should be allowed
> >>> to run its
> >>> own
> >>>> mobility management and not be forced into PMIP. At least MN should
> >>> have a
> >>>> means to tell the network that it would like to run MIP by itself.
> >>>>
> >>> [KC>] the network operator has a heavy say on what mobility
> >>> protocol will be used by the hosts. Having said that, I am OK
> >>> with your last statement...the MIP6 capable host may like to
> >>> send a hint to the network. Please make this clear in your I-D.
> >>>
> >>>>> The
> >>>>> issue of assigning the same HoA to two different
> >>> interfaces does not
> >>>>> arise at this time since this is the initial attachment.
> >>>> The draft was not written with this particular problem in mind.
> >>>>
> >>>>>> ASA could authorize PMIP service within the access
> >>> network (LMA in
> >>>>> ASP),
> >>>>>> right? However, if the MS is MIP6 capable, it does not need
> >>>>> the PMIP
> >>>>>> service and needs to be able to tell that to the access network.
> >>>>>>
> >>>>> [KC>] The MN has MIP6 service with its MSP. If the ASA authorizes
> >>>>> PMIP6 to be used for mobility within the ASP, there is no
> >>> scope of
> >>>>> interference between the PMIP6 session in the ASP and the MIP6
> >>>>> session that the MN has with the MSP.
> >>>>> So, there is no issue at all.
> >>>> Yes, except that the PMIP service with the ASP is not needed at all.
> >>>> Technicaly it will work flawlessly, but what is the benefit of using
> >>> PMIP
> >>>> in such configuration?
> >>>>
> >>> [KC>] Hmmm...I was merely responding to your "PMIP in ASP"
> >>> problem scenario. Please read your statement about that
> >>> (above). BTW, PMIP in ASP is indeed a valid scenario in some
> >>> deployments.
> >>>
> >>>
> >>>>> [KC>] At the initial attach, there is no need to negotiate which
> >>>>> mode will be used for rendering mobility service to the MN.
> >>>> PMIP was meant to provide mobility for simple IP hosts, not for MIP
> >>>> capable hosts. Only problem is, at the time when the PMIP
> >>> service must
> >>> be
> >>>> started the network is not able to tell the simple IP from the MIP
> >>> capable
> >>>> host. So it will blindly provide PMIP to all hosts. PMIP
> >>> doesn't come
> >>> for
> >>>> free: it installs additional state in the network and is
> >>> not exactly
> >>>> supporting the end-to-end principle.
> >>>>
> >>> [KC>] An operator may choose to use PMIP for mobility
> >>> management of ALL hosts. BTW, I would prefer to stay away
> >>> from CMIP vs. PMIP comparison debate here. There are other
> >>> I-Ds on that topic. Please note that CMIP requires OTA
> >>> signaling overhead and per MN IPsec/IKE state maintenance in
> >>> the network (no free lunch anywhere :-)
> >>>
> >>>
> >>>
> >>>>> This negotiation (rather expression of *preference* by the MN) is
> >>>>> merely a FYI for the network.
> >>>> I agree that this is just expression of preference. If the network
> >>> decides
> >>>> to run PMIP service for this host, there is nothing the host can do
> >>> about
> >>>> it.
> >>>>
> >>> [KC>] Yep, I think this should be made pretty clear in your I-D.
> >>>
> >>>> regards
> >>>> domagoj
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Chowdhury, Kuntal [mailto:[email-masked]]
> >>>>> Sent: 27. srpanj 2007 17:53
> >>>>> To: Premec, Domagoj; [email-masked];
> >>>>> [email-masked]
> >>>>> Cc: Damic, Damjan; [email-masked]
> >>>>> Subject: RE: [netlmm] RE: Comments on
> >>>>> draft-krishnan-netlmm-pmip-sel-00
> >>>>>
> >>>>> Hi Domagoj,
> >>>>>
> >>>>> Please see my comments inline....
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Premec, Domagoj [mailto:[email-masked]]
> >>>>>> Sent: Friday, July 27, 2007 6:39 AM
> >>>>>> To: Chowdhury, Kuntal; [email-masked];
> >>>>>> [email-masked]
> >>>>>> Cc: Damic, Damjan; [email-masked]
> >>>>>> Subject: RE: [netlmm] RE: Comments on
> >>>>> draft-krishnan-netlmm-pmip-sel-00
> >>>>>> Hi Kuntal,
> >>>>>>
> >>>>>> Please see inline...
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Chowdhury, Kuntal
> >>> [mailto:[email-masked]]
> >>>>>>> Sent: 26. srpanj 2007 22:43
> >>>>>>> To: Premec, Domagoj; [email-masked];
> >>>>>>> [email-masked]
> >>>>>>> Cc: Damic, Damjan; [email-masked]
> >>>>>>> Subject: RE: [netlmm] RE: Comments on
> >>>>>>> draft-krishnan-netlmm-pmip-sel-00
> >>>>>>>
> >>>>>>> Hi Domagoj,
> >>>>>>>
> >>>>>>> Say, the MN has a MIP6 session i.e. there is a MSA/MSP for the
> >>> MN
> >>>>>>> and it has a mip6 binding at a given HA in the MSP.
> >>>>>>> Now the MN hands over to a different access network where it
> >>>>>>> performs access authentication with the ASA.
> >>>>>> The draft covers the case before the MIP6 session is even
> >>>>> established.
> >>>>>> During the initial attachment to the network, how will
> >>> the network
> >>>>> detect
> >>>>>> whether the MN wants PMIP service or preferes to run its
> >>>>> own mobility
> >>>>>> management? Draft makes it possible for the MN to express its
> >>>>> preference.
> >>>>> [KC>] It is not _necessary_ for the network to know
> >>> whether the MN
> >>>>> _wants_ PMIP6 or MIP6 during initial attachment. The issue of
> >>>>> assigning the same HoA to two different interfaces does
> >>> not arise at
> >>>>> this time since this is the initial attachment.
> >>>>>
> >>>>>
> >>>>>>> In the split scenario, the ASA has no idea about MSA/MSP...so
> >>> the
> >>>>>>> question of the ASA authorizing PMIP6 to be run from an AR/MAG
> >>> in
> >>>>>>> the access network to the MN's HA in the MSP does not
> >>>>> arise at this
> >>>>>>> point (when the MN seeks an address from the AR).
> >>>>>>>
> >>>>>> ASA could authorize PMIP service within the access
> >>> network (LMA in
> >>>>> ASP),
> >>>>>> right? However, if the MS is MIP6 capable, it does not need
> >>>>> the PMIP
> >>>>>> service and needs to be able to tell that to the access network.
> >>>>>>
> >>>>> [KC>] The MN has MIP6 service with its MSP. If the ASA authorizes
> >>>>> PMIP6 to be used for mobility within the ASP, there is no
> >>> scope of
> >>>>> interference between the PMIP6 session in the ASP and the MIP6
> >>>>> session that the MN has with the MSP.
> >>>>> So, there is no issue at all.
> >>>>>
> >>>>>
> >>>>>> In my mind, if ASP can provide PMIP service, then the ASA is the
> >>>>> policy
> >>>>>> store from the PMIP draft and it may be able to talk to the MSA.
> >>> MAG
> >>>>> is
> >>>>>> always in the ASP, but the LMA could be either in the ASP or in
> >>> the
> >>>>> MSP.
> >>>>>> Maybe the PMIP draft should have a couple of words about
> >>>>> policy store,
> >>>>>> ASA, ASP, MSA, LMA and their relationship?
> >>>>>>
> >>>>> [KC>] Hmmm....in the split mode, the ASA has no knowledge of the
> >>> MSA.
> >>>>> Since the LMA can be in the ASP (IMHO) for mobility management
> >>>>> within the ASP, we perhaps need a sentence or two to
> >>> explain that in
> >>>>> the pmip6 base I-D.
> >>>>>
> >>>>>
> >>>>>>> In the integrated case (i.e. ASA is the MSA), the ASA/MSA
> >>>>> will know
> >>>>>>> about the mobility state of the MN. It will know that the
> >>>>> MN has an
> >>>>>>> ongoing MIP6 session.
> >>>>>> Yes, but only after the MIP6 session is already
> >>>>> established. We need a
> >>>>>> mechanism to negotiate the type of the session
> >>> (PMIP/CMIP) before
> >>> it
> >>>>> is
> >>>>>> established.
> >>>>>>
> >>>>> [KC>] At the initial attach, there is no need to negotiate which
> >>>>> mode will be used for rendering mobility service to the MN. This
> >>>>> negotiation (rather expression of *preference* by the MN)
> >>> is merely
> >>>>> a FYI for the network.
> >>>>>
> >>>>>
> >>>>>>  Hence the ASA/MSA
> >>>>>>> will select MIP6 as the mobility mode and let the MN run
> >>>>> MIP6 with
> >>>>>>> the HA in the MSP.
> >>>>>>>
> >>>>>>> So, I don't see the reason for the MN to express it's
> >>>>> preference for
> >>>>>>> continuing IP mobility service with MIP6.
> >>>>>> Yes, it is not needed for continuing of the mobility
> >>>>> service, but for
> >>>>> the
> >>>>>> initial establishment.
> >>>>>>
> >>>>> [KC>] As I explained, it is not needed for initial attach at all.
> >>>>>
> >>>>>
> >>>>>>  The
> >>>>>>> network has full knowledge of the MN's mobility state;
> >>>>> hence it can
> >>>>>>> take appropriate decision about the mobility mode.
> >>>>>>>
> >>>>>>> BR,
> >>>>>>> Kuntal
> >>>>>> domagoj
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Premec, Domagoj [mailto:[email-masked]]
> >>>>>>>> Sent: Thursday, July 26, 2007 5:15 AM
> >>>>>>>> To: [email-masked];
> >>> [email-masked]
> >>>>>>>> Cc: Damic, Damjan; [email-masked]
> >>>>>>>> Subject: RE: [netlmm] RE: Comments on
> >>>>>>> draft-krishnan-netlmm-pmip-sel-00
> >>>>>>>> Hi Jouni,
> >>>>>>>>
> >>>>>>>> [Damjan is out of the office] The intention of draft-damic
> >>>>>>> is to give
> >>>>>>> the
> >>>>>>>> mobile nodes some means to tell the network that they
> >>>>> would like /
> >>>>>>> would
> >>>>>>>> not like the network to run the PMIP service. Static
> >>>>> provisioning
> >>>>> of
> >>>>>>> the
> >>>>>>>> mobility mode for a MN in the policy store has its
> >>> issues, the
> >>>>>>> subscriber
> >>>>>>>> can switch to a terminal with different capabiliteis and the
> >>>>> policy
> >>>>>>> store
> >>>>>>>> wouldn't know it. There might be mobile nodes
> >>> implementing MIP
> >>>>> that
> >>>>>>> would
> >>>>>>>> prefere to do their own mobility management. Yes, they
> >>>>> would need
> >>>>> to
> >>>>>>> be
> >>>>>>>> enhanced to become PMIP aware :-( But the draft-damic and
> >>>>>>> draft-krishnan
> >>>>>>>> give such MNs at least an oportunity to express their
> >>>>> preference.
> >>>>>>>> Some additional comments inline...
> >>>>>>>>
> >>>>>>>> thanks
> >>>>>>>> domagoj
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: [email-masked]
> >>>>>>>>> [mailto:[email-masked]]
> >>>>>>>>> Sent: 24. srpanj 2007 18:27
> >>>>>>>>> To: [email-masked]
> >>>>>>>>> Cc: Damic, Damjan; [email-masked]
> >>>>>>>>> Subject: RE: [netlmm] RE: Comments on
> >>>>>>>>> draft-krishnan-netlmm-pmip-sel-00
> >>>>>>>>>
> >>>>>>>>> Hi Suresh,
> >>>>>>>>>
> >>>>>>>>>> Hi Jouni,
> >>>>>>>>>>    I see your point and I can empathize with you. I
> >>>>>>> just want to
> >>>>>>>>>> clarify a few things. The mechanism I proposed DOES NOT
> >>>>> require
> >>>>>>> any
> >>>>>>>>>> changes on mobility unaware nodes (classic PMIP) and
> >>>>>>>>> everything works
> >>>>>>>>>> as expected.
> >>>>>>>>> Yes, but then a MAG needs to be prepared to handle
> >>>>> two different
> >>>>>>>>> kinds of mobile nodes. Those that are vanilla IPv6 hosts
> >>>>>>> and those
> >>>>>>>>> that are PMIP6 aware. How does MAG know the difference?
> >>>>>>>>> Based on the -proxymip6-01 when a MAG sends a RA the
> >>>>> binding is
> >>>>>>>>> already in process or completed. The MAG does not need to
> >>>>>>> wait for a
> >>>>>>>>> mobile to send a RS.
> >>>>>>>> MAG can wait for an RS, although it doesn't need to.
> >>>>>>>>
> >>>>>>>>>> As far as using mobility signaling instead of using
> >>> NDP/DHCP
> >>>>>>> hacks,
> >>>>>>>>>> this becomes impossible because PMIP makes the
> >>> MN believe
> >>>>>>>>> that it has
> >>>>>>>>>> NOT MOVED and hence results in no mobility
> >>> signaling from
> >>>>>>>>> the MN. So I
> >>>>>>>>>> do not see any other way
> >>>>>>>>> Didn't get this. These prefix & mobility mode selections
> >>>>>>> are mostly
> >>>>>>>>> an issue durign the initial entry to the network.. afaik.
> >>>>>>>> Before mobility signalling can be used the MN needs to
> >>> configure
> >>>>> its
> >>>>>>> CoA,
> >>>>>>>> and for that it needs RA containing on-link prefix.
> >>>>> Besides, MIP6
> >>>>>>>> signalling is transparent to MAG, the MAG will never know if
> >>> the
> >>>>> MN
> >>>>>>> sent
> >>>>>>>> BU or not.
> >>>>>>>>
> >>>>>>>>>> out of this. If there is such a way, I would be
> >>> very happy
> >>>>>>>>> to follow
> >>>>>>>>>> it.
> >>>>>>>>> Cheers,
> >>>>>>>>> Jouni
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> Suresh
> >>>>>>>>>>
> >>>>>>>>>> [email-masked] wrote:
> >>>>>>>>>>> Hi Damic, Suresh, all,
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Suresh,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I agree with your comments, PMIP6 indication is
> >>>>>>> exactly what we
> >>>>>>>>>>>> wanted to describe in the draft.
> >>>>>>>>>>>> The MN does not explictly request PMIP6 /
> >>> MIP6 service,
> >>>>>>>>>> and neither
> >>>>>>>>>>>> MAG has to make that decision.
> >>>>>>>>>>>>
> >>>>>>>>>>>> As we see it, the goal is to minimize the impact on
> >>>>>>> the legacy
> >>>>>>>>>>>> terminal e.g. nodes that are not MIP-capable.
> >>>>>>>>>>> I have this issue with enhancing PMIP6 awareness in
> >>>>>>>>> mobile nodes at
> >>>>>>>>>>> layer-3. The nice idea of PMIP was that it is
> >>>>>>>>> transparent, working
> >>>>>>>>>>> without mobile node involvement in mobility signaling
> >>> and
> >>>>>>>>> requires
> >>>>>>>>>>> minimal if any changes (i.e. no new client or stack
> >>>>>>>>>>> modifications) in the mobile node. Why we now try
> >>>>> to change
> >>>>>>> these
> >>>>>>>>>>> assumptions and try to add 'mobility client' like
> >>>>>>>>> functionality to
> >>>>>>>>>>> mobile nodes? Instead of calling the new
> >>>>> functionality as a
> >>>>>>> 'host
> >>>>>>>>>>> mobility client' we extend address
> >>> configuration phase,
> >>>>>>>>> ultimately
> >>>>>>>>>>> moving some of the unwanted 'client' functionality
> >>> there.
> >>>>>>>>>> Also instead
> >>>>>>>>>>> of doing separate mobility signaling we bloat NDP
> >>>>> and DHCP.
> >>>>>>>>>>> I find this slightly controversial in PMIP6 context.
> >>>>>>>>>> Though, I am well
> >>>>>>>>>>> aware of the uses cases that would benefit from
> >>>>> the proposed
> >>>>>>>>>>> functionality, but still..
> >>>>>>>>>>>
> >>>>>>>>>>> [snip]
> >>>>>>>>>>>
> >>>>>>>>>>> Sorry for the rant ;-)
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Jouni
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> netlmm mailing list
> >>>>>>>>> [email-masked]
> >>>>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> netlmm mailing list
> >>>>>>>> [email-masked]
> >>>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>>>>>>
> >>>>>>> "This email message and any attachments are confidential
> >>>>> information
> >>>>>>> of Starent Networks, Corp. The information transmitted may not
> >>> be
> >>>>>>> used to create or change any contractual obligations
> >>> of Starent
> >>>>>>> Networks, Corp.  Any review, retransmission,
> >>>>> dissemination or other
> >>>>>>> use of, or taking of any action in reliance upon this
> >>>>> e-mail and its
> >>>>>>> attachments by persons or entities other than the
> >>>>> intended recipient
> >>>>>>> is prohibited. If you are not the intended recipient,
> >>>>> please notify
> >>>>>>> the sender immediately -- by replying to this message or
> >>>>> by sending
> >>>>>>> an email to [email-masked] -- and destroy
> >>>>> all copies
> >>>>>>> of this message and any attachments without reading or
> >>> disclosing
> >>>>>>> their contents. Thank you."
> >>>>>>>
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm