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
|
----
|
Hi Valery,
I would like to hear other people's opinion on this issue. At the very least,
the text I'm citing should be clarified.
BTW, Vendor ID payloads can appear anywhere in the message (per Appendix C), so
you can just put them first and you're fine.
Thanks,
Yaron
> -Original
Hi Yaron,
Hi Tero,
I was ready to accept your answer, until I came across the following
sentence in -07.
"Payloads are processed in the order in which they appear in an IKE
message by invoking the appropriate processing routine according to the
"Next Payload" field in the IKE header and su
Paul Hoffman wrote:
First off, thank you for bringing the topic to the WG. As the Designated
Expert, you are certainly allowed to make decisions without asking, so it is
extra nice that you ask on decisions that might be controversial.
On this particular topic, I would note that RFC 4753 is In
Hi Tero,
I was ready to accept your answer, until I came across the following sentence
in -07.
"Payloads are processed in the order in which they appear in an IKE message by
invoking the appropriate processing routine according to the "Next Payload"
field in the IKE header and subsequently acc
Raj Singh writes:
> > Not really. Not all requirements needs to be in one place. One place
> > can say that XXX is required and another place can say that also YYY
> > is required, but only if doing ZZZ.
> >
> > > 1. Section 4 mandates certificates but section 3.5 doesn't.
> >
> > Section 3.5 does
On Fri, Jan 22, 2010 at 5:15 PM, Tero Kivinen wrote:
>
> Raj Singh writes:
> > I agree with Tero explanation and Valery objection as well.
> > There is discrepancy between 3.5 and 4.
>
> Not really. Not all requirements needs to be in one place. One place
> can say that XXX is required and another
Raj Singh writes:
> I agree with Tero explanation and Valery objection as well.
> There is discrepancy between 3.5 and 4.
Not really. Not all requirements needs to be in one place. One place
can say that XXX is required and another place can say that also YYY
is required, but only if doing ZZZ.
Hi Team,
I agree with Tero explanation and Valery objection as well.
There is discrepancy between 3.5 and 4.
1. Section 4 mandates certificates but section 3.5 doesn't.
2. Its seen in practice that some implementation uses IP addresses as
default ID even though they are
using certificate based aut
Paul Hoffman writes:
> At 9:17 PM -0500 1/21/10, wrote:
> >Paul,
> >
> >> What does "Implementations SHOULD be capable of generating and
> >accepting all of these types" mean?
> >
> >It's hair-splitting time ...
> >
> >> To assure maximum interoperability, implementations MUST be
> >configurable t
11 matches
Mail list logo
