Here are some quick initial responses to your comments.
Thanks much for the review and I'll follow up with more detail in a
while.
"Black," == Black, David <david(_dot_)black(_at_)emc(_dot_)com> writes:
Black,> Major issues:
Black,> (Section 2)
Black,> [1] LocalKeyName and PeerKeyName are strings. What
Black,> character set? If Unicode (e.g., UTF-8?), add text on
Black,> Unicode considerations (e.g., normalization). Finding a
Black,> Unicode expert will help in getting this done quickly. I
Black,> have similar concerns for other strings, and in particular,
Black,> IANA should be told what a "string" is for any registry
Black,> field that contains one.
They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
Character set, to the extent it is specified will be specified by the
individual protocol.
In practice the protocol will say that it's an integer represented as
an ASCII string.
We needed to add the entire complexity of making these fields be strings
not integers because of some non-IETF protocols that use key names.
I'm reasonably confident I can sell Pete on the concept of a binary
identifier for this field from an i18n standpoint.
But issues, of length, format, etc are all specified by the protocol
spec.
Black,> [2] I'm not sure that I understand what a KDF really is from
Black,> its high level description in this draft. At the least, I'm
Black,> surprised that the importance of non-invertibility of a KDF
Black,> is not mentioned - beyond that, a functional description of
Black,> inputs and outputs would help, including a strong
Black,> recommendation to inject unpredictable nonce material. This
Black,> could be handled by referencing material on what a KDF is
Black,> that exists elsewhere.
I'm open to text either proposed on the IETF list from one of the other
authors.
Some protocols have a KDF input some do not.
If they do, it will be drawn from a set of allowable valuable for that
protocol.
Black,> (Section 4)
Black,> [3] It's important that this section cover all the fields
Black,> involved in the database lookups in Section 3 whose format
Black,> may be protocol-specific (the Direction and various time
Black,> fields aren't). Protocol should be covered by the IANA
Black,> registry, peers and key names are covered here, but
Black,> interface appears to be missing - item (9) covers presence
Black,> vs. absence of interface information, but not its format.
The interface is implementation-specific not protocol specific. We
mandate that you must be able to tie things to interface. However the
format of an interface is quite specific to the routing platform in
questino. I don't think there's a way that an IETF document can go into
useful detail on that. SNMP and Netconf have models of how interfaces
are represented. If we ever put together a Netconf schema for this
database, we'd specify the interface there.
Black,> --- Lots of issues with the IANA Considerations (Section 8)
Black,> (Section 8.1.1)
Black,> [5] No field format information for the fields in a registry
Black,> entry. IANA should be told what formats to expect/use.
Thanks, agreed.
Black,> [6] "Protocol Specific Values" is not the same as
Black,> "ProtocolSpecificInfo" in section 2; the same name should be
Black,> used, but whitespace differences are ok.
Good catch.
Black,> [7] Should some sort of formats for Peers and Interfaces be
Black,> included in registering a Protocol? If not, the lookups in
Black,> section 3 may be implementation-dependent (strings that work
Black,> w/one implementation may not work w/other implementations of
Black,> the same protocol). The specification reference may suffice
Black,> based on the requirements in section 4 for what has to be in
Black,> each referenced specification.
When you register a protocol you need to point to a specification that
gives details on this sort of thing.
Black,> (Sections 8.2 and 8.3)
Black,> [8] No registry entry content descriptions. Need to supply
Black,> information on what to register and the formats of the
Black,> elements of a registry entry.
Thanks.
Black,> [9] I suggest Expert Review for these registries, not just
Black,> First Come First Served, so that someone with a security
Black,> "clue" can check that the proposed registrations are
Black,> reasonable.
As an individual, I support FCFS, because I think getting expert
approval for some of the uses that have been proposed for these
registries will be challenging.