Pekka Savola: > - Pad length being unnecessary. The pad lengths are explicit since > there are variable length fields. For instance, the Trust Anchor > option has a name which may end at an 8-octet boundary. We could pad > with zero bytes, but I feel better about an explicit pad length > field. Similarly, the Signature and Certificate options have > complicated ASN.1 data, and it may be easier to have an explicit > field than to determine it from the encoding of a field. I'm not sure if I understand your reasoning. You seem to be saying that it's important to get the exact length of the ASN.1 encoded data, before decoding the data. Note that you can already get the rough estimate -- which is enough e.g. for buffer allocation purposes, I'd guess -- from Length field; this will include 0-7 bytes of zero padding at the end. I certainly don't see problems with implicit zero padding when the data falls on alignment boundaries; I think using such is extremely commonplace in IETF specs. So, I still think that Pad Length appears to be unnecessary. On the other hand, it MIGHT be necessary if you would have to be able to allocate the exact size of memory for storing the data before decoding the data. But 0-7 bytes of overhead here doesn't seem to be worth the trouble.. > - Nonces being required for senders but the lack of a nonce can in > some cases be ignored by receivers. I was unsure about this > one. Perhaps Pekka N can explain as this part of the text came from > him, I think. But I would classify this under "be conservative what > you send, liberal what you accept". Fine with me. > - IPR notices applying to an old draft version and name. I know. I > can not speak for others but I like to avoid going to the IPR > department more often than really necessary . Since we are about > to finish the SEND protocol and there are no more draft renamings (I > hope!) I now go and ask for an update of the IPR notice too. OK. Note that I'm actually hoping that there would NOT be IPR claims anymore -- as CGA stuff has been moved to a separate document, there shouldn't be any, right? If there is, it would be helpful to know which sections these pertain to (CGA parts or something else). So, this is IMHO actually a pretty important thing to do. ------------- Jari Arkko: My thinking was not based on buffer allocations. I agree that those are a non-issue. I was mainly thinking of how to find the end of a field followed by implicit padding. For instance, I'm was sure if the zero byte appears in some international character set schemes. But I guess not, that would break all C programs ;-) Anyway, zeros can appear in ASN.1 and binary encoded data. The question is thefore which of the following cases we have: (1) Variable length field has no length indication, explicitly or implicitly. In this case we must provide the length field either for this or for the padding that cames after it. (2) There is length information embedded in e.g. the ASN.1 encoding. In this case we can have either (a) length in the ASN.1 level only or (b) length in both the ASN.1 and our packet level. I think you are saying that you'd prefer (2a) over (2b). I think I agree on that now. I just would like to be assured that we don't have case (1) anywhere. Anyone familiar with the encoding of digital signatures care to comment? ------------- James Kempf: Two issues coming out of WG Last Call need to be resolved prior to sending draft-ietf-send-ndopt-04.txt to the IESG. Issue 68: Explicit padding length field v.s. implicit padding length as a result of message and field length. Suggested resolution: The draft currently has an explicit padding length, so remain with that. ------------- Pekka Savola: Well, having raised the issue, I'm again repeating that it seems obvious to use implicit padding length. This is what AFAIR all ND-related specifications use, and is very common case to deal with padding as well. Quite simply "Pad Length" seems to be redundant information, and any unnecessary information complicates the specification. (We could change it to an "MBZ" Reserved field, and reuse it later on if needed.) But if there's strong consensus otherwise, I can live with explicit padding as well. ------------- Pekka Nikander: If we had a comment from an implementor (Jon?), that would be great. I'm willing to go either way, and this seems mostly like an issue of which way is easier to implement. ------------- Jon Wood: I found that I never used explicit pad lengths (and since I implemented draft-arkko-send-ndopt-00 only the certificate option had a pad length). ASN.1 encoded data proved easy enough to parse with just the length information in the encoding. The signature length was a bit trickier - OpenSSL has a function that provides the signature length based on the key. However, if this function cannot be applied to all key types, then perhaps the pad length (or an explicit signature length) field might be needed. A crypto expert can address this better than I. When the trust anchor name type is 1 (DER Encoded X.501 Name), the length is in the DER encoding. However, this is not true for FQDNs. Processing FQDNs without an explicit pad or length field is harder, since if the name does not end on an 8 byte boundary, the receiver will need to walk though the padding to find the end of the name. This would also be an (unusual) instance of requiring a receiver to interpret pad values (since it would need to find a non-zero value to infer the boundary between the end of the name and the start of the padding). Perhaps it would be better to go back to an explicit name length for this option... ------------- Pekka Nikander: Jon, Do I read this correctly if I assume that you prefer the current explicit padding length? That is, even though it is not strictly needed for DER encoded ANS.1, you see other cases where it would be useful? ------------- Jon Wood: I think it's necessary only in one case - trust anchor options, for FQDNs. Elsewhere is seems to be useless mechanism. Would is be reasonable to just include a length for trust anchor options? ------------- James Kempf: So based on Jon's input, I'd like to propose the following specific revisions to the current draft text to resolve Issue 68: Section 5.2: Remove Pad Length field from message diagram, make Reserved. Remove Pad Length description in following text. Section 6.2.4: Remove Pad Length field from message diagram, make part of Reserved field. Remove Pad Length description in following text. Comments? ------------- Pekka Nikander: Ok to me. How about the explicit length for FQDN? Does it require any changes? (Don't have time to check the draft now, sorry about that.) ------------- James Kempf: John's recommendation if I understand correctly was to keep the pad length for the trust anchor option. Between the pad length, total option length, and fixed field sizes it should be possible to calculate the FQDN size. ------------- Jari Arkko: I have edited the suggested issue resolution to the draft. Furthermore, I added the actual Padding fields explicitly to the pictures for the certificate and trust anchor options, as they had been missing. For the diffs and text, see http://www.arkko.com/publications/send/issues/issue68diff.html http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt -------------