Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 21 Mar 2008 15:37:59 +0000

I think the SHOULD is OK. Some clarification about what happens if the
dereg BU is not sent may be useful but I do no have time to provide
text right now. I will draft somerthing early next week.

Regards
George

On 3/21/08, Ahmad Muhanna <[email-masked]> wrote:
> George,
>
> I wanted to thank you for the summary on the other email but after
> reading your response to Domagoj, I believe my question become more
> relevant here. Please see inline.
>
> Regards,
> Ahmad
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of George Tsirtsis
> > Sent: Friday, March 21, 2008 9:35 AM
> > To: Premec, Domagoj
> > Cc: [email-masked]
> > Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775
> > changes]De-registration when returning home
> >
> > Domagoj,
> >
> > Each MIPv6 session at the mobile side presents an IP
> > interface associated with the HoA (hiding the multiple CoAs
> > underneith). If the same interface presents additional IP
> > addresses then this is no different with multiple IP
> > addresses associated with the same Ethernet Interface.I guess
> > this can also be regarded as multihoming but we are in danger
> > of getting into a philosophical discussion.
> >
> > The "tutorial" was to explain why it does not make sense to
> > require that the MN sends a dereg BU when it connects to its
> > home link.
> > Instead this is a MIPv6 layer decision that has nothing to do
> > with whether the MN has connection only to the home link or
> > to one or more other links at the same time.
>
> [Ahmad]
>
> I am still not sure where you stand on the original proposed change!
> After all of this tutorial and summary, Do you still see a need to
> change "SHOULD" to "MUST"?
>
> Thanks!
>
> >
> > I hope we can make some progress understanding this basic
> > point...and of course then we can also ponder the
> > complexities of multi-homing applied to different layers at
> > the same time.
> >
> > Regards
> > George
> >
> >
> > On Fri, Mar 21, 2008 at 2:22 PM, Premec, Domagoj
> > <[email-masked]> wrote:
> > > Hi George,
> > >
> > >  I find it very interesting... let me ask for some more
> > clarifications.
> > >
> > >  Would you consider a regular IPv6 host with a single
> > interface card to be multihomed (at the IP layer), given that
> > it has a link-local address and a global address?
> > >
> > >  I would relate multihoming at the MIP layer to the number
> > of HoAs, not to the number of (simultaneously registered)
> > CoAs. Looking at this from the perspective of an application
> > running on the MN, it has at its disposal IP addresses
> > assigned to the network interface cards (IP layer
> > multihoming) and the HoAs (MIP multihoming). It doesn't
> > matter if the addresses assigned to the interfaces are
> > registered as CoAs with the HA or not. The registration
> > status of a (potential, or secondary) CoA does not affect the
> > number of addresses the application has at its disposal.
> > >
> > >  domagoj
> > >
> > >
> > >
> > >
> > >  > -----Original Message-----
> > >  > From: [email-masked] [mailto:[email-masked]] On  >
> > > Behalf Of George Tsirtsis  > Sent: 21. ozujak 2008 12:50  > To:
> > > [email-masked]  > Subject: [MEXT] Remarkable Misconceptions! Re:
> > > [RFC3775  > changes]De-registration when returning home  >
> > > Hi all,
> > > >  > This thread, that became too long too quick, contains
> > a  > rather
> > > remarkable misconception regarding multihoming. It is  > rather
> > > strange that I have to explain the concept of layers  > to
> > a bunch of
> > > IETF old-timers >sigh< but here it is anyway.
> > >  >
> > >  > The Internet Protocol operates at the network layer.
> > >  > - IP is usually placed over a link layer (i.e., a link
> > of specific
> > > > technology) and thus, it provides basic inter-networking
> > > between
> > > many such technology specific links.
> > >  > - Tunneling and indeed MIPv6 Tunneling is used as an additional
> > > layer  > (overlay) between the link layer and IP. The
> > purpose of MIPv6
> > > > tunneling "layer" is to link multiple IP layer segments that  >
> > > happen to use different address (i.e., different CoAs).
> > >  >
> > >  > Now everyone should understand that the concept of  >
> > *multihoming*
> > > can be applied in every and all layers  > *separately* and
> > > *independently* from any other layer. For  > example a node
> > can have
> > > multiple physical layer channels to  > the same or different link
> > > layer technologies; multiple links  > to the same or different IP
> > > interfaces; several IP interfaces  > to the same or different
> > > transport layers etc.
> > >  >
> > >  > MIPv6 as the different layer that it is (!) also has its own  >
> > > multihoming capability. RFC3775 defines a single CoA per
> > MIPv6 session
> > > > (MIPv6 single-homing), while MCoA draft describes how  > multiple
> > > CoAs can be registered at the same time (MIPv6  >
> > Multi-homing). This
> > > has NOTHING to do with IP layer  > multihoming; it can be combined
> > > with IP layer multi-homing or  > not but operates
> > separately from it
> > > (think layers!!!).
> > >  >
> > >  > Lets examine some relevant (non exhaustive) scenarios  >
> >  > Assume
> > > an MN that at the MIPv6 tunneling layer is useing  > basic RFC3775.
> > >  > - Multihoming at IP Layer: Such an MN can have two IP  >
> > interface
> > > e.g., WLAN and 3G. The MN gets two different IP  > address,
> > for each
> > > IP Interface i.e., the MN is multihomed at  > the IP layer.
> > >  > - Singlehoming at MIPv6 Layer: And yet according to
> > RFC37775  > the
> > > MN can only register one of the two IP addresses as a CoA  > to the
> > > HA!
> > >  > i.e., the MN is single-homed at the MIPv6 Layer.
> > >  >
> > >  > Assume now a different case where the MN at the MIPv6  >
> > tunneling
> > > layer is useing basic RFC3775 + MCoA.
> > >  > - Multihoming at IP Layer: Such an MN can have two IP  >
> > interface
> > > e.g., WLAN and 3G. The MN gets two different IP  > address,
> > for each
> > > IP Interface i.e., the MN is multihomed at  > the IP layer.
> > >  > - Multihoming at MIPv6 Layer: In this case according to MCoA,  >
> > > the MN can register both CoAs at the same time to the HA!
> > >  > i.e., the MN is multihomed at the MIPv6 Layer  >  > As
> > homework :-)
> > > put together other scenarios to prove that  > single-homing and
> > > multi-homing can operate at different  > layers entirely
> > independently
> > > from any other layer!
> > >  >
> > >  > Once the difference between IP layer and MIPv6 layer  >
> > multihoming
> > > is understood, it should also be possible to  > understand that a
> > > "home link" and a "foreign link" are all  > the same thing to IP
> > > layer, and the terms only have  > significance at the MIPv6
> > layer. It
> > > should also then be  > possible to understand that for an IP layer
> > > multihomed MN,  > one of its links may be a home link and
> > the other a
> > > foreign  > link, or both can be foreign links, at the MIPv6
> > layer. The
> > > > MN should then be able to use either RFC3775 to enable
> > the  > use of
> > > just one of the two links  > (MIPv6 single-homing) or to
> > use MCoA to
> > > enable the use of  > both links at the same time (MIPv6
> > multi-homing).
> > >  >
> > >  > Regards (and sorry for the tutorial style of this
> > e-mail) George  >
> > > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu  >
> > > <[email-masked]> wrote:
> > >  > > Hi Ahmad, at first read I agreed with you but then I
> > > thought
> > > hmmm...
> > >  > > see  below.
> > >  > >
> > >  > >
> > >  > >  Ahmad Muhanna wrote:
> > >  > >  > Hi All,
> > >  > >  >
> > >  > >  > I hope that you view this as an attempt to resolve the  >
> > > issue rather  > > than  > I am changing my mind. But here
> > the details.
> > > I may be  > > repeating myself  > here but please bear with me:
> > >  > >  >
> > >  > >  > My understanding of "SHOULD" STILL did not change which in
> > > this  > > specific  > case means the following:
> > >  > >  >
> > >  > >  > "The MN MUST send de-registration UNLESS the MN has
> > a  > valid
> > > reason  > > NOT  > to send de-registration"
> > >  > >  >
> > >  > >  > Initially when we discussed this sometimes back offline, I
> > > only  > > gave two  > examples why this has to stay "SHOULD":
> > >  > >  >
> > >  > >  > A. What happens if the MN as soon as it moves to
> > the  > home
> > > link lost  > > > coverage, MN will not be able to send
> > > de-registration.
> > >  > >  >
> > >  > >  > B. What happens if the MN as soon as it moves to
> > the  > home
> > > link, the  > > MN  > lost power.
> > >  > >
> > >  > >  But this two cases are accidental cases.  I think the spec  >
> > > should say  > > what MN is about to do when links are
> > deterministic,
> > > the spec  > > shouldn't  describe observed behaviours in accidental
> > > cases  > but rather  > > suggest how  we'd like MN to act.
> > >  > >
> > >  > >  Just some observation,
> > >  > >
> > >  > >  Alex
> > >  > >
> > >  > >
> > >  > >
> > >  > >
> > >  > >  > I guess these two examples were probably NOT enough for  >
> > > people to  > > > believe in the above definition and my stand for
> > > keeping  > "SHOULD" vs.
> > >  > >  > changing it to "MUST". However, the scenario which
> > > Gerardo
> > > and Sri  > > are  > referring to makes me believe more
> > strongly that
> > > the base  > > RFC3775 need  > to keep "SHOULD" and NOT to
> > be replaced
> > > with "MUST"
> > >  > >  >
> > >  > >  > Here is why?
> > >  > >  > ============
> > >  > >  > My understanding of the scenario at hand, is the
> > following  >
> > > > (Gerardo's  > and Sri's)  >  > 1. Let us assume that the
> > MN has two
> > > > > interfaces, if1 connected to WLAN  > and if2 to something else.
> > >  > >  > 2. MN is connected to WLAN via if1 and have a BCE
> > with  > its
> > > HA as ,  > > CoA1  > and HoA1.
> > >  > >  >
> > >  > >  > 3. MN for a reason or another starts if2 and finds
> > out  > that
> > > if2 is  > > on  > its home link where HoA1 belongs.
> > >  > >  > 4. However, the MN probably still would like to use
> > if1 for  >
> > > > whatever  > reason.
> > >  > >  > 5. The MN does not want to use its HoA1 on if2 YET.
> > >  > >  >
> > >  > >  > 6. IMO, at this point, the MN has a valid reason
> > NOT to send
> > > >  > > de-registration yet to the HA. Then the rule of "SHOULD"
> > >  > give the MN
> > >  > > the  > choice of doing so.
> > >  > >  >
> > >  > >  > 7. After a certain period of time, the MN decides
> > to use its
> > > if2  > > and  > probably HoA1 on if2.
> > >  > >  > 8. Therefore, the MN has no longer has a valid
> > REASON  > NOT
> > > to send  > > > de-registration to its HA.
> > >  > >  > 9. In this case the MN and according to the rule of  >
> > > "SHOULD" MUST  > > send a  > de-registration message to the
> > HA to stop
> > > > defending the HoA.
> > >  > >  >
> > >  > >  >
> > >  > >  > NOW: The above scenario constitute example NO. C on
> > my list to
> > > > > support  > "SHOULD" rather than "MUST" list above.
> > >  > >  >
> > >  > >  > The fact that we now know of this scenario proves
> > one thing,
> > > we  > > probably  > will have another scenario in the future where
> > > Client  > > MIPv6 protocol  > will be better served by
> > keeping "SHOULD"
> > >  > rather than "MUST"
> > >  > >  >
> > >  > >  > Finally:
> > >  > >  > ========
> > >  > >  > I strongly believe that we need to keep the base
> > Client MIP6
> > > > > protocol,  > RFC3775, RFC3775bis, as generic and general  > and
> > > valid to  > > any future  > scenario that we are not aware
> > of at this
> > > > time. Adding a  > > clause and  > coupling that with a "MUST" is
> > > restricting the base  > > protocol behavior to  > a very
> > limited and
> > > specific case.
> > >  > On the other
> > >  > > hand, whenever, we  > identify another scenario like the  >
> > > above, we can  > > always specify the  > respected behavior in the
> > > respective document  > > where that scenario is  > captured without
> > > contradicting nor  > > overruling the base Client MIP6  > protocol.
> > >  > >  >
> > >  > >  > Hope this helps. Cheers to you ALL!
> > >  > >  >
> > >  > >  > Regards,
> > >  > >  > Ahmad
> > >  > >  >
> > >  > >  >
> > >  > >  >> -----Original Message-----
> > >  > >  >> From: Muhanna, Ahmad (RICH1:2H10)  > >  >> Sent: Thursday,
> > > March 20, 2008 3:34 PM  >> To: Muhanna, Ahmad  > > (RICH1:2H10);
> > > 'Vijay Devarapalli';  >> 'Giaretta, Gerardo'
> > >  > >  >> Cc: [email-masked]'
> > >  > >  >> Subject: RE: [MEXT] [RFC3775 changes]
> > De-registration when
> > > >>  > > returning home  >>  >>  >> I just would like to make one  >
> > > thing clear  > > here. So far  >> everyone said that from
> > IOT, etc. MN
> > > > always sends  >>  > > de-registration when returns home. IMO,
> > > "SHOULD" is working  >  >> as it  > > should:)  >>  >>
> > However, I do
> > > not mind if the original text is  > > changed by  >> replacing the
> > > respected "SHOULD" by a "MUST" as per  > > Vijay's  >> initial
> > > proposal.
> > >  > >  >>
> > >  > >  >> Regards,
> > >  > >  >> Ahmad
> > >  > >  >>
> > >  > >  >>
> > >  > >  >>> Subject: Re: [MEXT] [RFC3775 changes]
> > De-registration when
> > > >>  > > returning  >>> home  >>>  >>>>> Can we improve the
> > text to  >
> > > take this  > > into account?
> > >  > >  >>>> Agree.
> > >  > >  >>>>
> > >  > >  >>>> How about the following?
> > >  > >  >>>>
> > >  > >  >>>> OLD:
> > >  > >  >>>>
> > >  > >  >>>>     A mobile node detects that it has returned to its
> > >  > home link
> > >  > >  >>>> through
> > >  > >  >>>>     the movement detection algorithm in use (Section
> > >  > >  >>> 11.5.1), when the
> > >  > >  >>>>     mobile node detects that its home subnet prefix is
> > >  > >  >>> again on-link.
> > >  > >  >>>>     The mobile node SHOULD then send a Binding Update
> > >  > to its home
> > >  > >  >>>> agent,
> > >  > >  >>>>     to instruct its home agent to no longer intercept
> > >  > or tunnel
> > >  > >  >>>> packets
> > >  > >  >>>>     for it.  In this home registration, the mobile node
> > >  > >  >> MUST set the
> > >  > >  >>>>     Acknowledge (A) and Home Registration (H) bits, set
> > >  > >  >> the Lifetime
> > >  > >  >>>>     field to zero, and set the care-of address for the
> > >  > >  >>> binding to the
> > >  > >  >>>>     mobile node's own home address.  The mobile node MUST
> > >  > >  >>> use its home
> > >  > >  >>>>     address as the source address in the Binding Updat
> > >  > >  >>>>
> > >  > >  >>>> NEW:
> > >  > >  >>>>
> > >  > >  >>>>     A mobile node detects that it has returned to its
> > >  > home link
> > >  > >  >>>> through
> > >  > >  >>>>     the movement detection algorithm in use (Section
> > >  > >  >>> 11.5.1), when the
> > >  > >  >>>>     mobile node detects that its home subnet prefix is
> > >  > >  >>> again on-link.
> > >  > >  >>>>     If the mobile node wants the home agent to stop
> > >  > >  >> intercepting the
> > >  > >  >>>>     packets meant for its home address, the mobile node
> > >  > >  >> MUST send a
> > >  > >  >>>>     de-registration Binding Update to its home
> > agent. In this
> > >  > >  >>>>     Binding Update, the mobile node MUST set the
> > Acknowledge
> > >  > >  >>>> (A) and Home
> > >  > >  >>>>     Registration (H) bits, set the Lifetime
> > field to zero,
> > >  > >  >>> and set the
> > >  > >  >>>>     care-of address for the binding to the mobile
> > >  > node's own home
> > >  > >  >>>>     address.  The mobile node MUST use its home
> > address as
> > >  > >  >>> the source
> > >  > >  >>>>     address in the Binding Update.
> > >  > >  >>>>
> > >  > >  >>>> Please feel free to modify the text.
> > >  > >  >>> [Ahmad]
> > >  > >  >>> Hi Vijay,
> > >  > >  >>>
> > >  > >  >>> Let me understand the proposed change here.
> > >  > >  >>>
> > >  > >  >>> It seems to me that we just went from "SHOULD" to "MUST"
> > >  > >  >> and now back
> > >  > >  >>> to "OPTIONAL".
> > >  > >  >>>
> > >  > >  >>> IMO, the best for RFC3775 and RFC3775bis is to  >
> > maintain
> > > "SHOULD"
> > >  > >  >>> because my understanding of "SHOULD" is that the MN MUST
> > > send  > > >>> de-registration UNLESS there is a condition
> > that makes
> > > it  >>  > > impossible  >>> on the MN to send de-registration, e.g.
> > >  > >  >>> MN lost coverage, or lost power, etc.
> > >  > >  >>>
> > >  > >  >>> The usefulness of SHOULD in base RFC3775 that it
> > can be  >>
> > > > > become "MUST"
> > >  > >  >>> in a specific scenario where that is possibly  >
> > described
> > > in  >> a  > > different  >>> doc, like the case that Gerardo
> > > mentioned. IMO, that  > > "MUST"
> > >  > >  >> should be
> > >  > >  >>> captured in the Multi-CoA doc not in RFC3775bis.
> > >  > >  >>>
> > >  > >  >>> On the other hand, the latest change defeats the
> > original
> > > >>  > > purpose of  >>> RFC3775, because RFC3775 mandates
> > on the MN  >
> > > to send  > > >> de-registration,  >>> however, the last change,
> > > proposed here,  > > makes it based on the MN  >>>
> > discretion and that
> > > is very dangerous.
> > >  > >  >>>
> > >  > >  >>> I disagree with this change and I favor
> > maintaining "SHOULD"
> > >  > >  >>> in the base document and if "MUST" is needed in a
> > specific
> > > >>  > > scenarios  >>> let us capture that in the respected
> > document.
> > >  > >  >>>
> > >  > >  >>> One final note: Any where we mandate that the MN
> > > "MUST"
> > > send  >>>  > > de-registration, we probably need to have a
> > clause that
> > > >>  > "whenever  > > it  >>> is possible for the MN to do
> > so" i.e. if
> > > the MN moves to an  > > area  >>> without coverage, then
> > the MN wont
> > > comply anyway.
> > >  > >  >>>
> > >  > >  >>>
> > >  > >  >>>> Vijay
> > >  > >  >>>> _______________________________________________
> > >  > >  >>>> MEXT mailing list
> > >  > >  >>>> [email-masked]
> > >  > >  >>>> https://www.ietf.org/mailman/listinfo/mext
> > >  > >  >>>>
> > >  > >  >>> _______________________________________________
> > >  > >  >>> MEXT mailing list
> > >  > >  >>> [email-masked]
> > >  > >  >>> https://www.ietf.org/mailman/listinfo/mext
> > >  > >  >>>
> > >  > >  > _______________________________________________
> > >  > >  > MEXT mailing list
> > >  > >  > [email-masked]
> > >  > >  > https://www.ietf.org/mailman/listinfo/mext
> > >  > >  >
> > >  > >
> > >  > >
> > >  > >
> > >  > >
> > >  >
> > >
> > ______________________________________________________________________
> > >  > >  This email has been scanned by the MessageLabs Email
> > > Security
> > > System.
> > >  > >  For more information please visit  >
> > > http://www.messagelabs.com/email  > >  >
> > >
> > ______________________________________________________________________
> > >  > >  _______________________________________________
> > >  > >
> > >  > >
> > >  > > MEXT mailing list
> > >  > >  [email-masked]
> > >  > >  https://www.ietf.org/mailman/listinfo/mext
> > >  > >
> > >  > _______________________________________________
> > >  > MEXT mailing list
> > >  > [email-masked]
> > >  > https://www.ietf.org/mailman/listinfo/mext
> > >  >
> > >
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mext
> >
>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Mar 2008 10:44:56 -0500

That is good. That is not a bad idea.
I did not search RFC3775 lately, BUT If RFC3775 does not have
clarification text to what happened in case MN comes home and did not
send de-registration, then that text should be added.

Regards,
Ahmad

> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Friday, March 21, 2008 10:38 AM
> To: Muhanna, Ahmad (RICH1:2H10); Premec, Domagoj; [email-masked]
> changes] De-registration when returning home
> 
> I think the SHOULD is OK. Some clarification about what 
> happens if the dereg BU is not sent may be useful but I do no 
> have time to provide text right now. I will draft somerthing 
> early next week.
> 
> Regards
> George
> 
> 
> 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of George Tsirtsis
> > > Each MIPv6 session at the mobile side presents an IP interface 
> > > associated with the HoA (hiding the multiple CoAs underneith). If 
> > > the same interface presents additional IP addresses then 
> this is no 
> > > different with multiple IP addresses associated with the same 
> > > Ethernet Interface.I guess this can also be regarded as 
> multihoming 
> > > but we are in danger of getting into a philosophical discussion.
> > >
> > > The "tutorial" was to explain why it does not make sense 
> to require 
> > > that the MN sends a dereg BU when it connects to its home link.
> > > Instead this is a MIPv6 layer decision that has nothing 
> to do with 
> > > whether the MN has connection only to the home link or to one or 
> > > more other links at the same time.
> >
> > [Ahmad]
> >
> > > point...and of course then we can also ponder the complexities of 
> > > multi-homing applied to different layers at the same time.
> > >
> > > Regards
> > > George
> > >
> > >
> > > interface card to be multihomed (at the IP layer), given 
> that it has 
> > > a link-local address and a global address?
> > > >
> > > of HoAs, not to the number of (simultaneously registered) CoAs. 
> > > Looking at this from the perspective of an application running on 
> > > the MN, it has at its disposal IP addresses assigned to 
> the network 
> > > interface cards (IP layer
> > > multihoming) and the HoAs (MIP multihoming). It doesn't matter if 
> > > the addresses assigned to the interfaces are registered 
> as CoAs with 
> > > the HA or not. The registration status of a (potential, or 
> > > secondary) CoA does not affect the number of addresses the 
> > > application has at its disposal.
> > > >
> > > >  domagoj
> > > >
> > > >
> > > >
> > > >
> > > > [RFC3775  > changes]De-registration when returning home 
>  > Hi all,
> > > > MN can only register one of the two IP addresses as a CoA  > to 
> > > > the HA!
> > > >  > - Multihoming at MIPv6 Layer: In this case according 
> to MCoA,  
> > > >  > > Hi Ahmad, at first read I agreed with you but then 
> I thought 
> > > > hmmm...
> > > >  > > see  below.
> > > >  > >
> > > >  > >
> > > >  > >  Ahmad Muhanna wrote:
> > > >  > >  > Hi All,
> > > >  > >  >
> > > >  > >  But this two cases are accidental cases.  I think 
> the spec  
> > > > the spec  > > shouldn't  describe observed behaviours in 
> > > > accidental cases  > but rather  > > suggest how  we'd 
> like MN to act.
> > > >  > >
> > > >  > >  Just some observation,
> > > >  > >
> > > >  > >  Alex
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > >  > changing it to "MUST". However, the scenario 
> which Gerardo 
> > > > respective document  > > where that scenario is  > captured 
> > > > without contradicting nor  > > overruling the base 
> Client MIP6  > protocol.
> > > >  > >  >
> > > >  > >  >> -----Original Message-----  > >  >> From: 
> Muhanna, Ahmad 
> > > > (RICH1:2H10)  > >  >> Sent: Thursday, March 20, 2008 
> 3:34 PM  >> 
> > > > To: Muhanna, Ahmad  > > (RICH1:2H10); 'Vijay Devarapalli';  >> 
> > > > 'Giaretta, Gerardo'
> > > >  > >  >> Cc: [email-masked]'
> > > > >>  > > returning home  >>  >>  >> I just would like to 
> make one  
> > > > >> >
> > > >  > >  >>> One final note: Any where we mandate that the 
> MN "MUST"
> > > > Security System.