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
>> 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
>> proble
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.
>
> E
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, the
> >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 devel
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 an
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 w
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 imp
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 o
At 11:42 AM +0300 11/27/09, Valery Smyslov wrote:
>In my opinion, that would confuse people even more than now, for the
>following reasons:
>
>1. Magic numbers would become splited between two sources (note, that not
>all of them
>are listed in IANA, for example payload types are, but Proposal
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.
ir
presence must not hurt, just will make implementing of base protocol more
convinient.
Regards,
Smyslov Valery.
- Original Message -
From: "Paul Hoffman"
To: "IPsecme WG"
Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
> At
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 c
, November 26, 2009 19:11
> 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
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
Paul Hoffman writes:
> Based on Tero and Yaron's responses, I have a different idea:
>
> - Leave all the tables in
I think the encryption, hash algorithm etc tables could be removed
completely, i.e. the Transform type n tables in section 3.3.2. Those
tables change quite often, and they are not re
On Wed, Nov 25, 2009 at 08:39:08AM -0800, Paul Hoffman wrote:
> - Add [IKEV2IANA] to the Normative References; it will point to the URL of
> the IANA registry.
Yes, this is better.
Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai
Based on Tero and Yaron's responses, I have a different idea:
- Leave all the tables in
- Remove the numbers from every table
- Removed the "reserved", "reserved to IANA", and "private use" lines
- Precede each table with the following boilerplate paragraph:
The following table only lists th
Paul Hoffman writes:
> Yes, I should have worked this out more fully before posting.
>
> In all cases, I would add a reference to the IANA registry.
>
> Only lists code points: remove the whole table
> 2.22: IPComp Tranform IDs
> 3.3.2: Encryption, PRF, integrity, DH group, ESN
I can agree r
WG
> Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from
> IKEv2bis
>
> Yes, I should have worked this out more fully before posting.
>
> In all cases, I would add a reference to the IANA registry.
>
> Only lists code points: remove the whole table
>
Yes, I should have worked this out more fully before posting.
In all cases, I would add a reference to the IANA registry.
Only lists code points: remove the whole table
2.22: IPComp Tranform IDs
3.1: Exchange types
3.3.1: Protocol ID
3.3.2: Encryption, PRF, integrity, DH group, ESN
3.3.
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
registry")
Best regards,
Pasi
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of ext Paul Hoffman
> Sent: 24 November, 2009 02:37
> To: IPsecme WG
> Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
t.
Thanks,
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
On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote:
> I *really* don't think it is that hard for a developer to resolve a URL and
> read the tables there.
Leave out the table; give the URL and mention 4306. If you have two
more-or-less authoritative sources for the same information, some folks w
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
>>
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:
> 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
https://www.ietf.org/mailman/listinfo/i
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 out-of-date but are here just for refere
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 thes
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 tables from IKEv2bis, and add notes
> pointing to
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 how doing this lookup will
31 matches
Mail list logo
