At 7:44 PM +0200 2/8/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Tero's proposed tree structure would not fit in an RFC without
>> trimming even more, making it even less readable. I have used
>> Alfred's proposed layout, but I changed the example to match it.
>
>I think we could add some grap
Paul Hoffman writes:
> Tero's proposed tree structure would not fit in an RFC without
> trimming even more, making it even less readable. I have used
> Alfred's proposed layout, but I changed the example to match it.
I think we could add some graphic lines to make it even more easier,
and if we us
Tero's proposed tree structure would not fit in an RFC without trimming even
more, making it even less readable. I have used Alfred's proposed layout, but I
changed the example to match it. Please: read the example and make sure that
the illustration is correct:
For example, one such proposa
e: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
>
> Yoav Nir writes:
> > I'm sorry I just noticed this, but is this even allowed? Can you
> > include multiple key length attributes in the same transform?
>
> Yes, you are right, you cannot include multiple
Yoav Nir writes:
> I'm sorry I just noticed this, but is this even allowed? Can you
> include multiple key length attributes in the same transform?
Yes, you are right, you cannot include multiple key length attributes,
as they would be AND for all of them. So yes, they need to be separate
transfo
On Jan 22, 2010, at 11:57 PM, Yaron Sheffer wrote:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
> be helpful.
>
> Here's a first shot (we'll need to add some descriptive text):
>
>SA Payload
>|
>
Paul Hoffman writes:
> Ditto for Proposal #2: is there a good reason for you to not have
> included an INTEG transform?
Proposal #2 is the combined mode cipher, thus it cannot have INTEG
other than none, and I though we agreed that it would be better to
leave the whole INTEG transform out in those
Yaron Sheffer writes:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
> be helpful.
>
> Here's a first shot (we'll need to add some descriptive text):
>
> SA Payload
> |
> ---...
e; however, other proposals in the same
SA payload are processed as usual."
Thanks,
Yaron
> -Original Message-
> From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
> Sent: Saturday, January 23, 2010 21:19
> To: Yaron Sheffer; ipsec@ietf.org
> Subject: RE: [IPsec]
Hi Paul,
Paul Hoffman writes:
> > > Ditto for Proposal #2: is there a good reason for you to not have
> >> included an INTEG transform?
> >I was trying to illustrate a combined mode algorithm. May have got it
wrong...
>
> That would be INTEG = NULL.
Omitting it completely is also allowed (section
At 8:06 PM +0200 1/23/10, Yaron Sheffer wrote:
> > Further, is there a good reason for you to have not included an ESN
>> transform on Proposal #1? Section 3.3 says "The number of different
>> transforms is generally determined by the Protocol. ... ESP generally
>> has three: ESN, an encryption alg
Hi Paul,
Please see below.
> -Original Message-
> From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
> Sent: Saturday, January 23, 2010 3:28
> To: Yaron Sheffer; ipsec@ietf.org
> Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
>
> A
At 11:57 PM +0200 1/22/10, Yaron Sheffer wrote:
>The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
>be helpful.
>
>Here's a first shot (we'll need to add some descriptive text):
>
>SA Payload
>|
>
The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
be helpful.
Here's a first shot (we'll need to add some descriptive text):
SA Payload
|
----
|
14 matches
Mail list logo
