K.Kawaguchi | 2 Oct 2006 08:15
Picon

Re: About Test Specification in IPv6 Ready Logo

Hi all,

We E-mails again for confirmation though there is no opinion.
The IPv6 Ready Logo NEMO will begin within one month if it is unquestionable.

NEMO allows to generates HoA either from home network prefix or mobile
network prefix. We treats the first configuration as a basic function
and the second one as the advanced function.
Does anybody comments on this?

Best regards
---
Kiyoaki KAWAGUCHI

In message <200609281458.IIE26588.HUVJBBXL <at> ysknet.co.jp>
"[nemo] About Test Specification in IPv6 Ready Logo"
""K.Kawaguchi" <kawaguti <at> ysknet.co.jp>" wrote:

> Hi,
> 
> We will begin IPv6 Ready Logo of RFC3963 (NEMO basic support).
> This is a program of the confidence to the NEMO product based
> on RFC3963. We want to hear your opinion in regard to the test
> condition in this test specification.
> 
> We have opened the preparation version of the test specification
> to the public.
> 
>   http://www.ipv6ready.org/announcement/public_review20060621_nemo.html
> 
(Continue reading)

Alexandru Petrescu | 2 Oct 2006 09:08

Re: About Test Specification in IPv6 Ready Logo

K.Kawaguchi wrote:
> Hi all,
> 
> We E-mails again for confirmation though there is no opinion. The 
> IPv6 Ready Logo NEMO will begin within one month if it is 
> unquestionable.
> 
> NEMO allows to generates HoA either from home network prefix or 
> mobile network prefix. We treats the first configuration as a basic 
> function and the second one as the advanced function. Does anybody 
> comments on this?

Hi Kiyoaki,

It is difficult for me to make comments towards supporting or not
supporting a certain logo.  An IETF RFC is the expression of striving to
interoperate.  The purpose of the logo seems to be different.

Technically speaking, the implementation with which I work uses a Home
Address derived from the home link prefix, and thus I find your decision
to support this as a basic configuration ok.

Alex

> 
> 
> Best regards --- Kiyoaki KAWAGUCHI
> 
> 
> 
(Continue reading)

Picon

CfP WWIC 2007

Our apologies for duplicate postings.

-------------------------------------------------------------------------
CALL FOR PAPERS

WWIC 2007
5th International Conference on Wired / Wireless Internet Communications
May 23-25 2007, Coimbra, Portugal
http://wwic2007.dei.uc.pt   

Next generation mobile networks will be based on Internet core networks
and wireless access networks. The need for efficient merging of the
wired and wireless infrastructure as well as the new multimedia services
and applications of next generation networks call for novel network
architectures, protocols and traffic-related mechanisms. WWIC addresses
research topics such as the design and evaluation of protocols, the
dynamics of the integration, the performance tradeoffs, the need for new
performance metrics, and cross-layer interactions.

The goal of the conference is to present high-quality results in the
field, and to provide a framework for research collaboration through
focused discussions that will designate future research efforts and
directions. In this context, the program committee will accept only a
limited number of papers that meet the criteria of originality,
presentation quality and topic relevance.

Important dates:
Submission deadline: December 8, 2006   
Notification of acceptance: February 19, 2007           
Camera ready papers: February 28, 2007
(Continue reading)

Masafumi Watari | 2 Oct 2006 11:39
Picon
Favicon

Re: Re: RO for geographically dist'd HAs

Hi Marcelo,

On Fri, 29 Sep 2006 15:31:16 +0200
marcelo bagnulo braun <marcelo <at> it.uc3m.es> wrote:

> > If we consider the solution as more like an enhancement to NEMO BS, 
> > then
> > we would probably want to leave those MNNs untouched - RO would be to
> > bypass those HAs and make it MR to MR (Vehicle to vehicle, plane to
> > plane).
> >
> 
> two comments:
> - first, i agree that MR to MR (or MNN and MNN of different nemos) RO 
> makes sense, but don't you think that RO between MNN and a fixed node 
> in the internet is also required? and what about MNN and a mobile Node 
> RO, does is this required?

I would agree if RO is provided between MR and a CR of the CN, and not
MR and CN - unless CN is a MIP6 CN.  Global HAHA might be a candidate
solution for this I guess.

> -second, of course not having to modify the MNN is useful, specially in 
> terms of deployment. But these type of solutions have their own 
> drawbacks also (no solution has all the pros, i guess) so deciding that 
> we will keep the MNN unmodified fits some unstated requirements and 
> probably fits some unstated requirements. Again, this may be exactly 
> what we are looking for, but it is extremely hard imho to be able to 
> evaluate the different solutions and the different tradeoffs until the 
> exact requirements for the use case that we have in mind have been 
(Continue reading)

K.Kawaguchi | 2 Oct 2006 11:48
Picon

Re: About Test Specification in IPv6 Ready Logo

Hi Alex,

Thank you for the answer.

> It is difficult for me to make comments towards supporting or not
> supporting a certain logo.  An IETF RFC is the expression of striving to
> interoperate.  The purpose of the logo seems to be different.

Yes.
Logo also aims at Interoperability. However, there might be some
differences though Logo followed RFC.

Logo aims to be able to connect all equipment under the Logo.
Only one common specification and procedure are necessary for it.
But, there is a selective part in RFC. Therefore, the only one is
selected from a selective part of RFC. And the only one is defined
as the basic in Logo.

> Technically speaking, the implementation with which I work uses a Home
> Address derived from the home link prefix, and thus I find your decision
> to support this as a basic configuration ok.

Thank you for information.
It is the basic that we defined.

Best regards
---
Kiyoaki KAWAGUCHI

"Re: [nemo] About Test Specification in IPv6 Ready Logo"
(Continue reading)

marcelo bagnulo braun | 2 Oct 2006 15:23
Picon

Re: Re: RO for geographically dist'd HAs


El 02/10/2006, a las 11:39, Masafumi Watari escribió:
> I see what you are trying to say and I think we documented such
> tradeoffs in the RO analysis draft while going through the various
> proposals.

yes, the question is which tradeoffs are the ones we choose

>  My point was that one policy we could follow is to leave
> those MNNs unmodified and work on those first.

yes, this is one possible approach, but why should we choose this  
approach and not another one?

My point is that when deciding this we are making some assumption about  
the use cases. I would like to make this decision explicitly.

>   I also believe that such
> requirement is quite reasonable after seeing a few NEMO like services.

could you provide some examples?
I mean, imho use cases (i.e. nemo like services used or to be used)  
should be the main driver of which solutions we should standarize,

> A side note, that was one reason why Netlmm was chartered too, right?
>
> As I mentioned above, providing RO for fixed nodes is still possible by
> deploying CRs over the Internet.

i guess it is possible in several ways, but the first thing we need to  
(Continue reading)

Greg Woodhouse | 2 Oct 2006 19:02
Picon
Favicon

Re: About Test Specification in IPv6 Ready Logo

It isn't hard to see two (or more) "sides" of the issue. On the one
hand, IPv6 should be universally adopted, and providing a logo for
people to use, seems to imply that adoption of IPv6 is something
special, and not the norm. Still, it provides a small incentive to
vendors, open source team, and so forth to incorporate IPv6
functionality in their products. I can't help but wonder if the snail
on the cover of the O'Reilly book on IPv6 isn't there as a kind of
commentary on the rate of IPv6 adoption!

Then again, are applications really the big issue? I know OS X, at
leasst supports IPv6, and I'd expect that other major operating
systemsx would do the same. What I don't know is whether "consumer"
ISPs even route IPv6 (though I don't expect this to be an issue on
enterprise networks), and I wonder hos many web sites and other serices
even advertise IPv6 addreses. I don't recall ever happening upon an A4
or AAAA record in dig or nslookup. That stikes me as odd because the
cost of advertising IPv6 addresses certainly seems small (assuming the
network supports them, of course).

===
Gregory Woodhouse  <gregory.woodhouse <at> sbcglobal.net>

"Mathematics is the science of patterns."
--Lynn Arthur Steen, 1988

Masafumi Watari | 3 Oct 2006 04:11
Picon
Favicon

Re: Re: RO for geographically dist'd HAs

On Mon, 2 Oct 2006 15:23:14 +0200
marcelo bagnulo braun <marcelo <at> it.uc3m.es> wrote:

> 
> El 02/10/2006, a las 11:39, Masafumi Watari escribi
> > I see what you are trying to say and I think we documented such
> > tradeoffs in the RO analysis draft while going through the various
> > proposals.
> 
> yes, the question is which tradeoffs are the ones we choose
> 
> >  My point was that one policy we could follow is to leave
> > those MNNs unmodified and work on those first.
> 
> yes, this is one possible approach, but why should we choose this  
> approach and not another one?

As I said, by considering the solution as an enhancement to NEMO BS. 
BTW, I'm not saying that we should work only on this and not others.

> My point is that when deciding this we are making some assumption about  
> the use cases. I would like to make this decision explicitly.
> 
> >   I also believe that such
> > requirement is quite reasonable after seeing a few NEMO like services.
> 
> could you provide some examples?
> I mean, imho use cases (i.e. nemo like services used or to be used)  
> should be the main driver of which solutions we should standarize,

(Continue reading)

Thierry Ernst | 3 Oct 2006 10:35
Picon
Picon
Favicon

Re: About Test Specification in IPv6 Ready Logo


Dear all,

There are a bulk of ISPs and vendors supporting IPv6 services, and all
major OS do have an IPv6 stack. This is not the issue of this
discussion.

Regarding the adoption of the NEMO logo, I would favor 2 slides on this
to show at the next IETF if Kawaguchi-san attend it. We could then reach
a reasonable conclusion there. So far, it's not clear to me if a
NEMO-compliant implementation should allow the configuration of  the
MR's HoA either from home network prefix or the mobile network prefix.  

Whether it happens on the ML or at the NEMO session in San Diego,, it
would be nice to obtain more feedback from those who have implemented
RFC 3963 and those who are considering selling products based on it.

Thierry

On Mon, 2 Oct 2006 10:02:47 -0700 (PDT)
Greg Woodhouse <gregory.woodhouse <at> sbcglobal.net> wrote:

> It isn't hard to see two (or more) "sides" of the issue. On the one
> hand, IPv6 should be universally adopted, and providing a logo for
> people to use, seems to imply that adoption of IPv6 is something
> special, and not the norm. Still, it provides a small incentive to
> vendors, open source team, and so forth to incorporate IPv6
> functionality in their products. I can't help but wonder if the snail
> on the cover of the O'Reilly book on IPv6 isn't there as a kind of
> commentary on the rate of IPv6 adoption!
(Continue reading)

Alexandru Petrescu | 3 Oct 2006 20:34

Re: About Test Specification in IPv6 Ready Logo

Thierry Ernst wrote:
> Dear all,
> 
> 
> There are a bulk of ISPs and vendors supporting IPv6 services, and 
> all major OS do have an IPv6 stack. This is not the issue of this 
> discussion.
> 
> Regarding the adoption of the NEMO logo, I would favor 2 slides on 
> this to show at the next IETF if Kawaguchi-san attend it. We could 
> then reach a reasonable conclusion there.

Discussing ok, reaching a conclusion is probably impossible.  The logo
issue has indeed at least two facets.  Many IPv6 implementers currently
turn to "logo" type of claims in order to boast features understandable
by higher level speakers - TAHI comes to mind: how many times I've seen
IPv6 implementation projects targetting TAHI compliance; it's a good
motivator for implementers.  However, a logo is usually neglected in the
IETF talk, in that RFCs are often just that, _trying_ to interoperate.

A WiFi logoed equipment is supposed to give me compliance insurance
about two manufacturer's products.  But in practice it sometimes fails:
I came across two WiFi logoed equipments failing to interoperate
in the detail, or too inefficient.  We don't want that to happen
with NEMOv6.

A logo vision gives insurance to buyers about interoperability.  But it
often turns into monetary interests to get "labelized" - you pay
enough you get the label, neglecting technical intricacies.  Check ISO
9001 and successors, guaranteeing the "quality" of a product or process;
(Continue reading)


Gmane