Paul Hoffman wrote:
- Add [IKEV2IANA] to the Normative References; it will point to the
URL of the IANA registry.
I don't like the idea of splitting the normative content of RFC 4306
to two different places.
An informative reference would be very useful (and probably some of
the tables may
You probably speaks about ideal developers. I speak about real people.
I've seen a few cases when people implemented a bunch of really
unnecessary things just because it was in standard.
We still agree, and your answer is still inconsistent. If you worry about
those type of developers, then
Paul Hoffman writes:
If a developer does not know how to read the IANA tables, we are all
in trouble. Nothing in the tables says you must implement every
thing in these tables, of course.
Then we are already in trouble. There is lots of developers who do not
know about the IANA tables, they
Valery Smyslov writes:
What about EAP Message format and magic numbers? Remove and just
reference RFC3748 (or IANA entry for EAP)?
No, those were left in because they came from an RFC, not from a
particular IANA registry where the names match what we have in IKEv2bis.
EAP numbers
I don't agree with you. Remember, when IKEv2 was being developed,
one of the motivations for single self-contained document was complaint
from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
was very inconvinient and provoked confusions that led to
interoperability
problems. Now
For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I
think,
a newcomer could be confused by a long list of all possible numbers.
This answer is inconsistent, and that's the crux of the issue I have
At 12:19 AM +0300 11/30/09, Valery Smyslov wrote:
For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I
think,
a newcomer could be confused by a long list of all possible numbers.
This answer is
At 11:11 PM +0300 11/27/09, Valery Smyslov wrote:
Hi Paul,
please, see inline.
2. IANA registry already contains some very specific entries (like, for
example,
those that came from RFC4595) and their number will be increasing. I
think,
those numbers would confuse some implementers, who
Paul Hoffman writes:
At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote:
Given the amount of interest on the list, I prefer the do nothing
approach.
That makes no sense. People seem interested in fixing the problem of
the lists being confusing.
I agree that we should do something.
There
Hi Paul,
please, see inline.
2. IANA registry already contains some very specific entries (like, for
example,
those that came from RFC4595) and their number will be increasing. I
think,
those numbers would confuse some implementers, who might be thinking
that they need to support all
At 1:25 PM +0200 11/26/09, Tero Kivinen wrote:
Paul Hoffman writes:
- Remove the numbers from every table
I would rather keep the numbers for those tables which are really
needed for implementing the protocol.
And here we disagree completely.
I hate when I am implementing something and
To: Tero Kivinen
Cc: IPsecme WG
Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from
IKEv2bis
At 1:25 PM +0200 11/26/09, Tero Kivinen wrote:
Paul Hoffman writes:
- Remove the numbers from every table
I would rather keep the numbers for those tables which are really
needed
At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote:
Given the amount of interest on the list, I prefer the do nothing approach.
That makes no sense. People seem interested in fixing the problem of the lists
being confusing.
There is nothing confusing about removing the assigned numbers: it only
Paul Hoffman writes:
This has flummoxed a few reviewers. Tables such as those in section
3.3.2 are already out of date because things have been added since
RFC 4306. I propose that we remove all these tables from IKEv2bis,
and add notes pointing to the current IANA registries. I cannot see
At 8:12 PM -0500 11/23/09, Dan McDonald wrote:
On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote:
This has flummoxed a few reviewers. Tables such as those in section 3.3.2
are already out of date because things have been added since RFC 4306. I
propose that we remove all these
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:
SNIP!
The warning and URL is the critical part.
are the critical part, - uggh, mustn't press Send so quickly.
Dan
___
IPsec mailing list
IPsec@ietf.org
At 8:37 PM -0500 11/23/09, Dan McDonald wrote:
On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
Can you move 'em to an appendix, with a permanent URL reference to the IANA
up-to-date versions?
As long as you mean an appendix that clearly says 'these were in RFC 4306
but are now
,
Yaron
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Steven Bellovin
Sent: Tuesday, November 24, 2009 5:20
To: Paul Hoffman
Cc: ipsec@ietf.org; Dan McDonald
Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from
IKEv2bis
18 matches
Mail list logo
