My explanation was clear and covered all concerns about my algorithm (as it
is not the CGA at all and so no IPR), so I also don't think there is any
need to explain more. Otherwise somebody else still has a problem and not
convinced.
> >> IPRs *are* a problem. If you think you know better, talk to
Hosnieh,
We have already been down this road where I feel you don't seem to
listen/read what I say. I won't comment any further, except for one
small comment.
On 08/10/2013 04:43 AM, Hosnieh Rafiee wrote:
>> On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote:
> Check here please:
>
> http:/
Added key pair to the CGA as well :-)
> On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote:
> >>> Check here please:
> >>>
> >>> http://datatracker.ietf.org/ipr/138/
> >>>
> >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to
> >>> All Implementers
> >>
> >> This is a non-starter f
> On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote:
> >>> Check here please:
> >>>
> >>> http://datatracker.ietf.org/ipr/138/
> >>>
> >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to
> >>> All Implementers
> >>
> >> This is a non-starter for many free-software projects.
> >
> > A
On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote:
>>> Check here please:
>>>
>>> http://datatracker.ietf.org/ipr/138/
>>>
>>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All
>>> Implementers
>>
>> This is a non-starter for many free-software projects.
>
> As I explained before
Hosjieh,
Of three problems that the draft aims to solve, 1st (EUI64 addresses) does not
really seem to be much of a problem as everyone does privacy addresses today
(you saw stats yourself at ipv6-hackers meeting), the second (not changing the
address) is an implementation choice, so the third
> > Check here please:
> >
> > http://datatracker.ietf.org/ipr/138/
> >
> > b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All
> > Implementers
>
> This is a non-starter for many free-software projects.
As I explained before my algorithm is not CGA anyway.
But, what I know a
Hi Andrew,
Thanks for your comments.
>Of three problems that the draft aims to solve, 1st (EUI64 addresses) does not
>really seem to be much of a problem as everyone does privacy addresses today
>(you saw stats yourself at >ipv6-hackers meeting), the second (not changing
>the address) is an imp
On 08/09/2013 06:57 PM, Hosnieh Rafiee wrote:
>> I won't fight this one with you, Hosnieh. You have received my input.
>> It's up to you what you do with it.
>>
> Check here please:
>
> http://datatracker.ietf.org/ipr/138/
>
> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to Al
>
> I believe your underestimating IPRs, and also think that introduing an IPR
to
> RFC4941 (as this document is indirectly doing) is an extremely bad idea.
There is no IPR for my algorithm. You can name it Pseudo CGA or xxx. I only
used a hash function, i.e., SHA256 that anyone can use a hash f
On 08/09/2013 06:25 PM, Hosnieh Rafiee wrote:
>> Besides, there are IPRs on the CGA algorithm... but RFC4941 itself doesn't
> have
>> any. SO this document would essentially IPR-encumber
>> RFC4941 -- the farther that you can get from that, the better, I'd say.
> :-)
>
> CGA has IPR but it does no
Hi there,
> Just focus on the problem you're trying to solve, and provide references
where
> necessary.
>
Ok :-)
>
>
> IMO, reason "1" is void: If an implementer is going through the effort of
> implementing this document, he/she'd rather implement a god PRNG.
>
> Regarding "2", do you realy
On 08/09/2013 05:34 PM, Hosnieh Rafiee wrote:
>
>> * In Section 1, you should probably remove some of the general discussion
> on
>> security and privacy here. For instance, some of your definitions seem
>> incomplete.
>
> Ok, I think I just did not want to jump to the topic and have a kind of
>
Fernando, Thanks for your comments.
> * In Section 1, you should probably remove some of the general discussion
on
> security and privacy here. For instance, some of your definitions seem
> incomplete.
Ok, I think I just did not want to jump to the topic and have a kind of
introduction. Maybe I
Hosnieh,
Some comments:
* In Section 1, you should probably remove some of the general
discussion on security and privacy here. For instance, some of your
definitions seem incomplete.
* Section 6 is fine... but I don't think the rest of the stuff is needed.
* Section 7 should probably be remove
Hello and thank you so much for your comments.
I applied your comments and submitted a new version of the ra-privacy draft.
I also removed the text concerning the application layer based lifetime from
this draft. This draft, thus, just focuses on a few updates to RFC 4941 that
address some defi
16 matches
Mail list logo
