Good responses. Thanks, Les. Cutting down just to a few clarifications. If I left it out, then I am OK with your response. I'm not pushing on things where I think it can be worked out from the text and you prefer to not make any changes. Cheers, Adrian > 4. > > Pedantically... > OLD > In the absence of MP-TLV support, when a router receives an MP-TLV, > it treats the TLVs as replacements for each other i.e., the receiver > chooses which TLV will be processed and which TLV will be ignored. > NEW > In the absence of MP-TLV support, as specified in [ISO10589], when a > router receives an MP-TLV, it treats one of the TLVs as a replacement > for the others, i.e., the receiver chooses which TLV will be > processed and which TLVs will be ignored. > END > [LES:] ISO 10589 is not relevant here. None of the TLVs defined in ISO 10589 are candidates for MP. The potential for MP really came with the introduction of sub-TLVs (RFC 5305). So, I prefer to leave text unchanged. [AF] Ah, that was not my point. 1. What document describes how to process a duplicate TLV and specifies the behaviour you describe? Clearly this document cannot do that because implementations that don't support this document cannot be controlled by it. 2. The current text says "replacements for each other" which is a bit extreme. I am reminded of "An old farmer had three daughters each more beautiful than the others." > 5. > > The contents of a multi-part TLV MUST be processed as if they were > concatenated. > > This is probably the most important sentence in the document! > Combined with: > ...and... > If the internals of the TLV contain key information, > then replication of the key information MUST be taken to indicate > that subsequent data MUST be processed as if the subsequent data were > concatenated after a single copy of the key information. > ...we can deduce a lot. > 1. Information placed in component TLVs must be present such that the > concatenation may be done in any order. That is, you can't just fill > up the 255 bytes and then start a new TLV. [LES:] This is explicitly stated in Section 5: "The receiving node must then process this as having key information K and sub-TLVs A, B, C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, F, A, B, C, or any other permutation." [AF] Yes, but. That example doesn't address my point. Perhaps I should have worded it that the split between component TLVs MUST be done at a sub-TLV or other unit boundary. Again, this can be worked out, so it is not critical. > 2. If a TLV has a fixed part (which may contain a key) it must be > present in each component TLV such that the component TLV is > correctly composed in its own right. > [LES:] Section 5 also says: "If the internals of the TLV contain key information, then replication of the key information MUST be taken to indicate that subsequent data MUST be processed as if the subsequent data were concatenated after a single copy of the key information." [AF] Yes, but I think that is the flip of what I am asking about. That is, that when you extend a TLV into another TLV (i.e., two component TLVs of an MP-TLV) you MUST replicate the key if there is one present. > I looked for this guidance in 8.2, but did not find it. While the text > is acceptable as it stands (after all, this can be worked out) it would > not hurt to make it clear by calling out these points explicitly either > in 5 or 8.2. [LES:] As I have pointed out, Section 5 already has explicit text on these points. 8.2 is talking about "generation". Section 5 and your comments on it are about receive processing. I do not want to confuse the two. I suspect what you are after is that the description of receive processing implies some requirements on how the originator of the TLV encodes it. This is "loosely true" i.e., in a perfect world all MP-TLVs would be generated in strict accordance with rules (mentioned in 8.2). But in the spirit of "be strict in what you send/generous in what you receive" we want receivers to be more forgiving. Sending MP-TLVs when they are not required (less than 255 bytes of info) is sub-optimal and undesirable, but we intentionally stop short of declaring this "illegal". This point was discussed at some length on the list and we (the authors) were/are firm in our commitment to this approach. At this point I am not sure how to address your concerns or if they even need to be addressed. I'll think on this some more, but if after reading my response you have a suggestion, please share. [AF] Hmmm, OK. I take your purpose about the purpose of section 5. So maybe, especially in view of "strict on what you send", a little text in 8.2. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
