OSPFv2 Prefix/Link Attribute Advertisement
draft-ietf-ospf-prefix-link-attr-13
Yes
(Alia Atlas)
No Objection
(Alissa Cooper)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 06 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -06)
Unknown
Alvaro Retana Former IESG member
Yes
Yes
(2015-08-13 for -10)
Unknown
This is a good document, but I have some comments (and nits) that I would really like to see addressed before publication. I don't think my comments raise to the level of a DISCUSS, but I am specially interested in the actions when errors are detected. 1. Sections 2 and 3. a. RFC5250 used the name Opaque ID instead of Instance. Please be consistent. If there’s a really good reason to not use the “official” name, please at least write in the description of Instance that rfc5250 calls it Opaque ID. b. “…the attributes from the Opaque LSA with the lowest Instance will be used.” This sounds to me like a good place to be a little bit more prescriptive and s/will/MUST 2. Section 2.1. (OSPFv2 Extended Prefix TLV) a. For the Route Type, are those the only allowed values? What happens if something else is used? b. Flags - What are the defined flags used for? Since (according to Section 5) they are not supported in all implementations then I’m assuming there’s a specific application in mind. [I know there are other ID’s in progress that use the TLVs defined here. Is the use of these bits general to those applications?] - How should the rest of the flags be assigned? The IANA section says nothing about that. c. "Address Prefix The prefix itself encoded as a 32-bit value.” It is variable, not fixed. I know that only IPv4 is currently supported, but as explained in the AF section, there may be future extensions. 3. Section 3.1. (OSPFv2 Extended Link TLV) What should happen if an unknown/incorrect Link-Type/Link-ID/Link Data value is received? 4. Section 6. (Security Considerations) a. I think you should also point the readers at the considerations in rfc5250. b. “…implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors that cause hard OSPF failures.” What does that mean? That the software should be resilient? Or are you pointing at just ignoring the information if there is a malformed TLV/sub-TLV (that is somehow salvageable)? It would be vey nice is this draft set the example by specifying what to do in some cases (maybe not malformed, but incorrect/unknown as mentioned above). 5. Section 7. (IANA Considerations) Is there a significant reason why in all cases the assignment policy for the 33024-65535 range is not being defined upfront? Nits: 1. In Sections 2 and 3 s/differential/differentiate 2. In Section 2. (OSPFv2 Extended Prefix Opaque LSA), the figure that shows the TLV format seems to show a Value field of only 32 bits. The description (below the figure), which looks like an exact copy from rfc3630, describes the field correctly. It would be nice to either copy over the whole text from rfc3630 (including the figure that shows that the Value may be longer) or just leave out that text completely (which is my preference). The text saying that the TLV format is the same as in rfc3630 is enough. - In Section 3 you write: "The format of the TLVs within the body of the OSPFv2 Extended Link Opaque LSA is the same as described in Section 2.” One more level of indirection.. 3. 2.1. (OSPFv2 Extended Prefix TLV) a. The description of “Flags” is misaligned (it looks like a sub-paragraph of AF). b. s/originated by the different/originated by different
Alissa Cooper Former IESG member
No Objection
No Objection
(for -12)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-08-14 for -10)
Unknown
Some minor comments, just some clarifications... and a question about the registries. -- Section 2 -- There is no explanation of the "length" field in the OSPFv2 Extended Prefix Opaque LSA. I guess it's the total size, in bytes, of all the TLV data that follows, including any alignment bytes. But you should make that clear. -- Section 3 -- The same comment as for Section 2 applies here for the OSPFv2 Extended Link Opaque LSA. -- Section 7.1 -- Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that covers the range being assigned. A question here (I'm not hoping for any particular answer, just asking the question): When you say "an IETF specification", I take that to mean an RFC in the IETF stream, which can be Standards Track *or* Informational *or* Experimental. Is that what you want? The same question applies to the registries in the subsequent sections (7.2, 7.3, 7.4).
Ben Campbell Former IESG member
No Objection
No Objection
(2015-08-17 for -10)
Unknown
I concur with Kathleen's DISCUSS and Alvaro's comment about the security considerations. Other comments: -- 2.1, definition of N-Flag There are a couple of occurrences of "NOT" in caps that are not combined with other 2119 keywords. I assume those are not intentional? -- 2.1, 4th paragraph from end, last sentence (also occurs in 3.1): The 2119 MAY here doesn’t seem helpful, since this is internal to a router and does not impact seem interoperability. I suggest it be restated without 2119 language, unless you want to make it a SHOULD or stronger. (I am not a stickler that 2119 keywords never be used for things that are not observable by a peer, but MAYs seem especially useless in that context. I did not object to the SHOULD in the prior paragraph, since that might have operational value.)
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(2015-08-19 for -12)
Unknown
More a comment for IESG discussion, this draft has six authors (exceeds five author limit). I didn't see any notes in the shepherd writeup to support the need to exceed the limit (my former AD required a strong argument for exceeding). What guidelines are we following? I have many drafts coming along which exceed the limit and wondering what to do.
Jari Arkko Former IESG member
No Objection
No Objection
(for -12)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-08-16 for -10)
Unknown
Ron Bonica did the opsdir review.
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2015-08-20)
Unknown
Thanks for addressing my prior discuss point with some text. It should be helpful to developers.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -10)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-08-19 for -12)
Unknown
- The opaque ID field descriptions in sections 2 and 3 read a little oddly to me. What happens if someone decides to use up ID=0? Does that mean they can't overwrite that value until much later maybe? And what if a whole bunch of routers choose the same value (because it's configured or hard-coded)? I think you need a bit more text on that. And with only 24 bits the probability of a collision if you just pick randomly isn't that low, so I'm not sure if random selection is a good plan here either. (How often will a new one of these be seen?) - Do these opaque values get forwarded widely? If so, then I guess they may provide a covert channel. I didn't see that mentioned in the security considerations of RFC5250. Is it mentioned elsewhere? If not, is it worth a mention here? (Probably not, but thought I'd ask.) - Thanks for section 5. Nice to see. (Makes me wonder what those implementations do with the opaque ID though:-)
Terry Manderson Former IESG member
No Objection
No Objection
(for -12)
Unknown