On 8/1/11 12:11 PM, Paul Hoffman wrote:
On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote:
As we have seen from the ipsec list the community does not seem to
care too much, but I myself as a member of the community and also the
person responsible for the IANA registries do care.
WRT who is responsible ...
Technically, IANA is responsible for maintaining the registries in
accordance with the registration rules documented in the RFC that
creates/defines the registry.
The IANA experts (who are appointed by the IESG) are responsible for
reviewing requests for additions and modifications in the registries
that they are designated for.
The IETF/IESG is ultimately responsible for the registry as (most of
them) are a product of the IETF process.
You are *not* responsible for the IANA registries. RFC 5226 says:
It should be noted that a key motivation for having designated
experts is for the IETF to provide IANA with a subject matter expert
to whom the evaluation process can be delegated. IANA forwards
requests for an assignment to the expert for evaluation, and the
expert (after performing the evaluation) informs IANA as to whether
or not to make the assignment or registration.
. . .
Designated experts are expected to be able to defend their decisions
to the IETF community, and the evaluation process is not intended to
be secretive or bestow unquestioned power on the expert. Experts are
expected to apply applicable documented review or vetting procedures,
or in the absence of documented criteria, follow generally accepted
norms, e.g., those in Section 3.3.
I do not believe that you can defend a decision to reject registrations based
on what is in RFC 4306. If you disagree, please show which text you are
referring to.
My understanding is that Tero is stating early that he would deny the
requests based scarcity of code points, which is allowed per RFC 5226:
Possible reasons to deny a request include:
- scarcity of code points, where the finite remaining code points
should be prudently managed, or when a request for a large
number of code points is made, when a single code point is the
norm.
I have stated my reasons why I consider allocating multiple payload
numbers etc for exactly same thing a bad thing.
The three proposals do not do "exactly the same thing": they each have
different cryptographic and administrative properties. This has been widely discussed in
the WG.
But, they're for the same "thing": extension(s) to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared
secrets.
spt
As it seems that IKEv2 might be used with other things than IPsec too
in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in
the IKEv2 IANA registries.
Even if those use cases are not IPsec they most likely will reuse most
of the registries from the IPsec. We could overlap their numbers with
each other, but on the other hand that can cause confusion, so it
might be better to make sure they do not have overlapping numbers,
i.e. use of unique numbers for different things and mark those as
reserved in the registries which do not use them.
This is bit what IKEv1 and IKEv2 did, for example we are not using
payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1
used them. Same way our exchange numbers 0-33 are reserved etc.
I am not sure whether we are doing that in the future or not. I want
to think more about this and see the actual protocols before deciding.
This should be a WG/IETF decision, not that of a single person.
But on the other hand I want to keep our options open, which means I
do not want to fill our registries with multiple registrations for the
exactly same thing.
See above.
Can you explain me what problems will it cause if the
draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the
draft-kivinen-ipsecme-secure-password-framework framework just like
other secure password method drafts have already done?
In my understanding there will be 2 extra bytes in the IKE_SA_INIT
notification phase to indicate the PACE inside
N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two
depending how you do it) in the ENONCE and PKEi/PKEr payloads.
So in total the technical differences will be 7 extra bytes. Is there
anything else?
Regardless of what the authors of this document do, that question is not
relevant to whether or not you, as the designated expert, give them a codepoint.
--Paul Hoffman
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
