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
On 10/08/2013 11:01, Dave Thaler wrote:
> I will observe that Alissa's term "random per-network" isn't in any of the
> possibilities
> below and the reasons given wouldn't apply if that term were used. Perhaps
> that
> could be used in a title?
Nah. Too complex for a title, and "random" is a ba
I will observe that Alissa's term "random per-network" isn't in any of the
possibilities
below and the reasons given wouldn't apply if that term were used. Perhaps that
could be used in a title?
-Dave
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On B
> > 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
Folks,
I has been suggested to me that we might want to change the title of
this document, and the chairs have suggested that I comment on this one
on-list.
The arguemtn, as far as I can tell, is that the current title might be
confusing (mostly because of the confusion there is with different
te
>
> 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
Hi Ron,
Glad to hear you have had a look at SEAL, and see below for
a few follow-up comments:
> -Original Message-
> From: Ronald Bonica [mailto:rbon...@juniper.net]
> Sent: Friday, August 09, 2013 4:32 AM
> To: Templin, Fred L; C. M. Heard; IPv6
> Subject: RE: UDP+Fragmentation (was: "De
Fred,
Quite to the contrary, I have spent a good deal of time reviewing the SEAL
draft. (Although I am now one version behind. The document is now in version
61.)
SEAL attempts to solve many problems. These include:
- source address authentication
- detection of packet duplication and reorderi
15 matches
Mail list logo
