Subject: [nemo] LFN terminology

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Apr 2007 22:05:27 +0200

I've been pointed out recently that the term LFN (Local Fixed Node
defined in draft-ietf-nemo-terminology-06.txt) has actually been used
previously, at least in a TCP document RFC 1323 standing for a Network
containing Long Fat pipes.  The RFC precisely defines that LFN so.

This is disappointing to me personally because I'm using this LFN term
extensively in many communications.

I think though the abbreviation should change from LFN (Local Fixed
Node) to something else, maybe LFO (Local Fixed nOde) or something even
else.

The NEMO terminology draft should at least mention this previous
definition of 'LFN' in RFC 1323, if not get rid of 'LFN' altogether.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Apr 2007 21:10:17 -0700

I think its ok to have LFN in the context of NEMO to point to
a Local Fixed Node. For any document, the terminology section
should clearly point out what a particular term means in the
context of the document.

If we want to ensure terminology uniqueness among the nearly
5000 RFCs in the IETF, it would be really painful.

If it is causing confusion, then we should change it, but I
doubt it in this case.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 24 Apr 2007 21:23:21 -0700

Absolutely. A protocol is always discussed in a certain context.
I do not think the use of the term LFN in NEMO will create any
ambiguity. The terms are used in two different protocols and in
different documents. In general, it makes sense to ensure
uniqueness in very closely related protocols or documents and
not across the whole RFC set.

Sri

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2007 9:10 PM
To: Alexandru Petrescu
Cc: IETF NEMO WG
Subject: Re: [nemo] LFN terminology

Vijay

---

From: Teco Boot <[email-masked]>
Date: Wed, 25 Apr 2007 08:29:32 +0200

Hi all,

I think the abbreviation MR is confusing. In a NEMO context it stands for
Mobile Router, where in MANET context is stands for MANET Router. Those two
are very different. 

RFC 3753 Mobility Related Terminology & draft-ietf-nemo-terminology-06:

   Mobile Router (MR)

      A router capable of changing its point of attachment to the
      network, moving from one link to another link.  The MR is capable
      of forwarding packets between two or more interfaces, and possibly
      running a dynamic routing protocol modifying the state by which it
      does packet forwarding.

      A MR acting as a gateway between an entire mobile network and the
      rest of the Internet has one or more egress interface(s)  and one
      or more ingress interface(s).  Packets forwarded upstream to the
      rest of the Internet are transmitted through one of the MR's
      egress interface; packets forwarded downstream to the mobile
      network are transmitted through one of the MR's ingress interface.

draft-ietf-autoconf-manetarch-01:

   MANET Router (MR)
      an entity that has one or more MANET interfaces and that engages
      in a MANET routing protocol.  A MANET router may also have zero or
      more classic IP interfaces to which hosts may connect.

So a router could be no MR, a MR, a MR or a MR and MR.

Also publish on MANET ML?

Regards, Teco

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 25 Apr 2007 10:55:26 +0200

Oh guys, please hold out ! The time window to comments on the
terminology has expired. The document lived a long life enough for
everyone to comment. It has been approved by the WG and the IESG. It is
in the RFC queue. It is in the AUTH48 state right now.

Of course a MR in the MANET and NEMO context are a bit different, but
conceptually they are still mobile routers. If you need, just add NEMO
MR or MANET MR when things are not clear.

I guess people find this mailing list too silent and this is why the
terminology is brought back again ? Please preserve your energy to make advancements in line with the new charter.

Thanks all for your understanding and remaining focused.
Thierry.

On Wed, 25 Apr 2007 08:29:32 +0200

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 25 Apr 2007 10:57:37 +0200

>Also publish on MANET ML?

I personaly find cross-postings very annoying. It's fine for announcing
something, but once the discussion is forking out most people don't
follow all the mailing lists, so you better keep things separate or
discussed on 1 single ML. This is my personal view.

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Apr 2007 11:56:38 +0200

Vijay Devarapalli wrote:
> I think its ok to have LFN in the context of NEMO to point to a Local
> Fixed Node. For any document, the terminology section should clearly
> point out what a particular term means in the context of the
> document.

Sounds good for RFC3963, which expands the meaning of LFN at first use.

> If we want to ensure terminology uniqueness among the nearly 5000
> RFCs in the IETF, it would be really painful.

I think it is necessary to do one's best to have a common terminology
across not only 5000 rfcs but even 10000 or 100000 rfcs.

There are always similarities in terminology that pop-up in contexts
outside IETF discussion.

"The MR is connected to LFN, and the LFN is not" has a strong meaning
for someone working on TCP optimizations for NEMO and who means "The MR
is connected to a network of long-fat pipes, and the Local Fixed Node is
not", because then s/he decides to do TCP optimizations on MR thus
breaking end-to-end principles.  So I better understand what s/he means
by that ambiguous first phrase so I can talk to him/her.

I've seen similar confusions with the following ambiguous terms: MR,
mobile network, MH and RR.  Each time it was necessary to clarify
terminology in the respective contexts.

> If it is causing confusion, then we should change it, but I doubt it
> in this case.

Sometimes it may cause confusion, depends on who one talks to.

We could at least acknowledge the double meaning of LFN in the
terminology document (current or future version of it).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Apr 2007 12:00:29 +0200

Sri Gundavelli wrote:
> ambiguity.

If one talks to people working on TCP optimizations for NEMO then one 
may hit this ambiguity for LFN term (Network of Long Fat pipes vs Local 
Fixed Node).

> The terms are used in two different protocols and in

I have a completely different point of view than the above :-)

I think the reason we have only one IETF is that protocols must be able 
to work together.

Then I agree too that it may be too much effort to disambiguate all 
defined terms.  At the very least we can mention the potential ambiguities.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Apr 2007 12:11:57 +0200

Thierry Ernst wrote:
> everyone to comment. It has been approved by the WG and the IESG. It 
> is in the RFC queue. It is in the AUTH48 state right now.

For LFN, AUTHors can still add 4 words of text: "(different than RFC1323
LFN)".

If too complicated then maybe in future versions of this document.

>  conceptually they are still mobile routers. If you need, just add 
> NEMO MR or MANET MR when things are not clear.

Remark that in a MANET context (more precisely a MANET protocol running
on a sensor network) the MRs (MANET Routers) aren't mobile at all,
because the sensors are most often implanted in an area to sense data
and send to a central entity.  An agriculture-related sensor network
I've seen was staying fixed (non-mobile) for years.

So I think very many MRs (MANET Routers) aren't MRs (mobile routers) at all.

>  terminology is brought back again ? Please preserve your energy to 
> make advancements in line with the new charter.

Sorry, no, it's not because I find the list too silent.  I think the
list has the adequate type and volume of traffic.

The current Charter has an item on gathering requirements for NEMO in
Automotive industry.  This is related to what MANEMO effort is
proposing, among which protocols similar to MANET; when talking to MANET
people both the LFN and MR terms ambiguities were made apparent.

Thanks,

Alex

> Thanks all for your understanding and remaining focused. Thierry.
> 
> On Wed, 25 Apr 2007 08:29:32 +0200 Teco Boot <[email-masked]> wrote:
> 
> 
> 
>> Hi all,
>> 
>> I think the abbreviation MR is confusing. In a NEMO context it 
>> stands for Mobile Router, where in MANET context is stands for 
>> MANET Router. Those two are very different.
>> 
>> 
>> rest of the Internet are transmitted through one of the MR's egress
>>  interface; packets forwarded downstream to the mobile network are 
>> transmitted through one of the MR's ingress interface.
>> 
>> 
>> MANET Router (MR) an entity that has one or more MANET interfaces 
>> and that engages in a MANET routing protocol.  A MANET router may 
>> also have zero or more classic IP interfaces to which hosts may 
>> connect.
>> 
>>

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 25 Apr 2007 12:18:41 +0200

>For LFN, AUTHors can still add 4 words of text: "(different than RFC1323

They can but I won't because the context is obvious in the document
itself.

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Apr 2007 12:20:38 +0200

Thierry Ernst wrote:
> I personaly find cross-postings very annoying. It's fine for
> announcing something, but once the discussion is forking out most
> people don't follow all the mailing lists, so you better keep things
> separate or discussed on 1 single ML. This is my personal view.

I agree cross-posting is often annoying and very difficult to follow for
readers.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Apr 2007 13:06:07 +0300

I tend to agree with Thierry on this. There are only
so many two- or three letter acronyms, and yes, there
are collisions even in the IETF documents on these.
Please be careful in pointing out what term you are
actually talking about, if the context allows ambiguity.

Also, instead of editing already approved RFCs I
would suggest that we start talking about our
future RFCs. For instance, I'd like to see agreed
requirements for RO from the airline industry.
Or solution proposals. Or requirements for the
other two RO charter items. Lets start those
discussions, submit your drafts, etc.

Jari