Subject: [Mip6] rfc4285bis

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Sep 2007 13:14:44 +0300

What is the scope of RFC4285bis? Is it limited to fixing the key length and
some editorials, or other fixes and improvements are eligible for
consideration?

Alper 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Sep 2007 13:51:30 +0200

Alper Yegin wrote:
> What is the scope of RFC4285bis? Is it limited to fixing the key 
> length and some editorials, or other fixes and improvements are 
> eligible for consideration?

IMHO there are more issues than simple editorials with this draft and
with the companion "why authopt" draft.

I'm talking from implementation perspective.  For example the timestamp
option and the MN-AAA option and the interactions with IPsec are all
very unclear.  I've already posted technicals why, but no feedback yet.

Are you talking from SDO perspective?  I know some SDOs do require the
use of AuthOpt for MIP6, because they consider migration from MIP4 to
MIP6 to be eased when AuthOpt is used instead of IPsec.  I think SDOs
need implementations for this to fly and we can offer implementation.
But this doesn't make it StdsTrack IMHO, because we have no
interoperability until now.  We have not had any interoperability
experience between two different implementations of AuthOpt, right?

Alex

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Sep 2007 14:01:38 +0200

Hi Alex,

> with the companion "why authopt" draft.
The "Why Auth.Option" draft is an independent story. I would not put it 
in relationship to this document.

I have sent a couple of comments and I hope that the authors are working 
on them; I haven't heard that my comments are misguided.

> very unclear.  I've already posted technicals why, but no feedback yet.

I have proposed to concrete text to fix this issue. It is a minor 
clarification, in my view.

> need implementations for this to fly and we can offer implementation.

What do you mean by "we can offer implementation"? Who is "we"?

> experience between two different implementations of AuthOpt, right?
see RFC 2026

Ciao
Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Sep 2007 14:17:15 +0200

Hi Hannes,

Hannes Tschofenig wrote:
>> IMHO there are more issues than simple editorials with this draft 
>> and with the companion "why authopt" draft.
>> 
> The "Why Auth.Option" draft is an independent story. I would not put 
> it in relationship to this document.

Strange... they talk same topic, the former motivates the latter, I
don't see why you see them independent story.  If there are fallacies in
the former there'll obviously be fallacies in the latter.

> I have sent a couple of comments and I hope that the authors are 
> working on them; I haven't heard that my comments are misguided.

I have also sent several public comments and I haven't heard back.

>> I'm talking from implementation perspective.  For example the 
>> timestamp option and the MN-AAA option and the interactions with 
>> IPsec are all very unclear.  I've already posted technicals why, 
>> but no feedback yet.
> 

I have read your comments, and whereas you do talk about timestamps you
don't talk about authopt for brr for example.  You don't talk authopt
interactions with IPsec either.  These are comments I've raised
previously and aren't addressed.

>> Are you talking from SDO perspective?  I know some SDOs do require 
>> the use of AuthOpt for MIP6, because they consider migration from 
>> MIP4 to MIP6 to be eased when AuthOpt is used instead of IPsec.  I 
>> think SDOs need implementations for this to fly and we can offer 
>> implementation.
> 

I have the same question, who do you think can offer implementation?  I
think you don't need personally an implementation but I know who needs
an implementation.  Who do you think can offer an implementation?

Which part of it?  The one that says this?:
> Usually, neither implementation nor operational experience is 
> required for the designation of a specification as a Proposed 
> Standard.  However, such experience is highly desirable, and will 
> usually represent a strong argument in favor of a Proposed Standard 
> designation.

Here is my experience with implementaiton of rfc4285: (1) no timestamps,
(2) no mn-aaa options and (3) authopt for all MIP6 messages, not only
bu/back.  All these 3 would require large modifications to rfc4285bis
draft.

Is this a strong enough argument?  Is it negligible?

Alex

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Sep 2007 14:42:46 +0200

Hi Alex,

> the former there'll obviously be fallacies in the latter.
RFC4285bis is a revision of RFC 4285.
http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-04.txt 
is just provides a history lesson. I am not sure what dependency you 
would like to create. There is no formal dependency from a reference 
point of view.

http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-04.txt 
has received a detailed review by Jari and I suspect that Raj will 
update the draft very soon.

> I have also sent several public comments and I haven't heard back.
Hmmm. I got a response :-)
More responses and a guided discussion would, however, not hurt...

I am not the the editor of the document, the chair of the group, nor the 
area director responsible for the work. Hence, I cannot tell other 
people how they should progress work.

>>> IPsec are all very unclear.  I've already posted technicals why, but 
>>> no feedback yet.
>>

I am not sure what you mean. Would did I miss in my review?

> an implementation.  Who do you think can offer an implementation?

It would be good to have an implementation of all the protocols we 
develop but there is no mandate todo so for this type of RFC (from a 
formal point of view). I am sure there are implementations available; 
just not open source.

> bu/back.  All these 3 would require large modifications to rfc4285bis
I am not sure that this simplified statement is correct.
I found a need for clarifying the timestamp when used in context of the 
MN<->AAA server interaction.
That's all.

> Is this a strong enough argument?  Is it negligible?
Three issues:

* What type of document is "RFC4285bis"?
RFC 4285 was just an "Informational" document.

* As the text above indicates even for a "Proposed Standard" there is no 
mandate to have interoperable implementations.

* There are most likely implementation available; I just haven't done a 
survey.
I haven't seen interops being organized for the other protocols being 
developed in the group either.

Ciao
Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Sep 2007 17:45:56 +0200

Hi Hannes, I do value some of the ideas in your mails.  The 4285bis
issues are not between you and me, but between you and authors, or
between me and authors.

I tend to agree with some of the issues you raised.

Coming back to the original question "what is the scope of rfc4285bis?
limited to fixing keylen and some  edits or other fixes and improvements
are eligible?" - I think the question is open.

Alex

Hannes Tschofenig wrote:
[...]
>>>>> What is the scope of RFC4285bis? Is it limited to fixing the
>>>>>  key length and some editorials, or other fixes and 
>>>>> improvements are eligible for consideration?
>>>> 
>>>> IMHO there are more issues than simple editorials with this 
>>>> draft and with the companion "why authopt" draft.
>>>> 
>>> The "Why Auth.Option" draft is an independent story. I would not
>>>  put it in relationship to this document.
>> 
>>  don't see why you see them independent story.  If there are 
>> fallacies in the former there'll obviously be fallacies in the 
>> latter.
> 
>  is just provides a history lesson.

Strange...I thought it helps motivating moving it from informational to
stds track.

> I am not sure what dependency you would like to create. There is no 
> formal dependency from a reference point of view.

People are supposed to read the "why authopt" and be convinced authopt
is needed.  It's all in the title.

> Hmmm. I got a response :-) More responses and a guided discussion 
> would, however, not hurt...

I agree.

> I am not the the editor of the document, the chair of the group, nor
>  the area director responsible for the work. Hence, I cannot tell 
> other people how they should progress work.

That's why I don't understand Alper's question.

>>>> timestamp option and the MN-AAA option and the interactions 
>>>> with IPsec are all very unclear.  I've already posted 
>>>> technicals why, but no feedback yet.
>>> 
>> I have read your comments, and whereas you do talk about timestamps
>>  you don't talk about authopt for brr for example.  You don't talk
>>  authopt interactions with IPsec either.  These are comments I've 
>> raised previously and aren't addressed.
>> 
> 

I think your review touches on important aspects of the draft.  It
obviously doesn't cover my points because different people read
different specs differently and there's no wrong in that.

For example, if one sits down with a group of people and wonder what are
you going to code in C, starting from a certain base, with some time
requirements and some stringent customer needs, then you read it in a
certain way.

On the other hand, if one reads it as a stringent need from SDO to
progress here and now, and with stringent requirements on the image of
some validity of some technical arguments, then one reads it completely
differently.

These are two ways to read a spec, at least, none is better than other,
but completely different perspective.s

>>>> Are you talking from SDO perspective?  I know some SDOs do 
>>>> require the use of AuthOpt for MIP6, because they consider 
>>>> migration from MIP4 to MIP6 to be eased when AuthOpt is used 
>>>> instead of IPsec.  I think SDOs need implementations for this 
>>>> to fly and we can offer implementation.
>>> 
>> I have the same question, who do you think can offer 
>> implementation?  I think you don't need personally an 
>> implementation but I know who needs an implementation.  Who do you
>>  think can offer an implementation?
> 
>  formal point of view). I am sure there are implementations
> available; just not open source.

I'm not talking open source either.

>>>> interoperability until now.  We have not had any 
>>>> interoperability experience between two different 
>>>> implementations of AuthOpt, right?
>>>> 
>>>> 
>>> 
>>> see RFC 2026
>> 
>>>  usually represent a strong argument in favor of a Proposed 
>>> Standard designation.
>> 
>> Here is my experience with implementaiton of rfc4285: (1) no 
>> timestamps, (2) no mn-aaa options and (3) authopt for all MIP6 
>> messages, not only bu/back.  All these 3 would require large 
>> modifications to rfc4285bis draft.
> 
> I am not sure that this simplified statement is correct. I found a 
> need for clarifying the timestamp when used in context of the 
> MN<->AAA server interaction. That's all.
> 
>> 
> * What type of document is "RFC4285bis"? RFC 4285 was just an 
> "Informational" document.

The draft.

> * As the text above indicates even for a "Proposed Standard" there is
>  no mandate to have interoperable implementations.

HAve you read the text I cited?  Especially following the "however" part.

> * There are most likely implementation available; I just haven't done
>  a survey. I haven't seen interops being organized for the other 
> protocols being developed in the group either.

Implementations of authopt for mip6?  Or authopt for MIP4?

I can say that there is no publicly available implementation of
authopt for mip6.

Alex

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 27 Sep 2007 20:10:52 +0200

I might have joined the discussion regarding RFC 4285bis a bit late and hence I don't know what the agreed approach for that document is. 

In any case, this is more or less a question to the working group chairs. The opinion of the draft authors is in this case not more worth than the opinion of any other working group member since this is a working group document.

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 17:45:56 +0200
> Von: Alexandru Petrescu <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: Alper Yegin <[email-masked]>, "\'Mobile IPv6 Mailing List\'" <[email-masked]>
> Betreff: Re: [Mip6] rfc4285bis