Thanks for the quick response - most of your message looks reasonable to me. I have a few additional comments. [1] Character set for key names, etc. > They are strings that can be compared using binary comparison. > I agree we need to state that in the draft. That's certainly a reasonable goal, and there are plenty of examples of protocols that do that. OTOH, when the character set is Unicode, generating strings for which that binary comparison for equality works as expected has a number of subtleties when the strings are input by humans. Pete Resnick and yours truly are among the people familiar with the "dragons" that lurk here (and the precis WG is grappling with). > 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. I have no problem with the field being a binary identifier, but I think implementers should be put on notice that binary comparison of human input Unicode strings doesn't work as expected unless some things are done to make it work (this used to be known as string preparation). A warning to that effect, perhaps citing a reference for details on what can go awry, accompanied by making the protocol spec responsible for getting this right ought to suffice. [3] Protocol responsibility to specify interface format > 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 > question. Ok, I suggest explaining that as part of a statement that a protocol cannot in general be expected to specify interface formats that apply across all implementations due to implementation diversity. [7] Additional format information in registry > 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. That makes sense, and section 4's requirements on the specifications cover this area, but I thought I'd ask. [9] Registry policy > 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. The two registries involved are for KDFs and cryptographic algorithm identifiers. This feels like something that the security area ought to weigh in on, as it looks like it includes the "vanity crypto" discussion tarpit ;-). At a minimum, I would think that there ought to be some means of prohibiting registration of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13). Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@xxxxxxx] > Sent: Thursday, April 25, 2013 12:47 PM > To: Black, David > Cc: Russ Housley; tim.polk@xxxxxxxx; zhangdacheng@xxxxxxxxxx; gen- > art@xxxxxxxx; karp@xxxxxxxx; ietf@xxxxxxxx; <stbryant@xxxxxxxxx> > Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07 > > 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.black@xxxxxxx> 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. > >