Hi Tom, On 8/4/15, 7:57 AM, "t.petch" <[email protected]> wrote:
>Acee > >On the IANA question, you might find 5226bis of value, particularly >sections 7 and 8. > >That I-D also introduces a clarification to the terminology so that >Open Shortest Path First v2 (OSPFv2) Parameters >is a Group and >OSPFv2 Link State (LS) Type >is a registry, something which you might incorporate. > >'existing OSPF IANA registry' I find ambiguous. I agree - this will be clarified for all 4 of the new registries in the 08 version of the draft. Thanks, Acee > > Tom Petch > >----- Original Message ----- >From: "Acee Lindem (acee)" <[email protected]> >To: "Alia Atlas" <[email protected]>; ><[email protected]>; "OSPF List" ><[email protected]>; "shraddha" <[email protected]> >Sent: Saturday, August 01, 2015 10:54 PM >Subject: Re: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06 > > >> Hi Alia, >> Thanks for the review. >> >> From: Alia Atlas <[email protected]<mailto:[email protected]>> >> Date: Thursday, July 30, 2015 at 2:22 PM >> To: >"[email protected]<mailto:draft-ietf-ospf-prefix >[email protected]>" ><[email protected]<mailto:draft-ietf-ospf-prefix >[email protected]>>, OSPF WG List ><[email protected]<mailto:[email protected]>>, shraddha ><[email protected]<mailto:[email protected]>> >> Subject: AD review of draft-ietf-ospf-prefix-link-attr-06 >> >> As is customary, I have done my AD review of >draft-ietf-ospf-prefix-link-attr-06 before asking for IETF Last Call. >First, thank you very much for your hard work on this draft. It is >lovely to see needed work move quickly and have numerous interoperable >implementations. >> >> I do have a number of minor issues on the draft - but all on the level >of clarifications. Therefore, I have requested that IETF Last Call be >started. Assuming good responsiveness on the part of the authors, a >revised version that addresses my concerns can be on the IESG telechat >on August 20. >> >> I do note that there are 6 authors on this draft. Please provide >input - since I know that you all well aware that the limit is normally >at most 5. One can identify a primary editor or two. This isn't pure >process; the more authors listed on a draft, the longer it takes to >handle AUTH48 - particularly when some are not as involved and do not >respond rapidly and with full context. I make no judgement about the >authors of this draft - who have clearly moved from pulling out the idea >into a stand-alone draft and had a number of different implementations. >> >> We’ve already made one pass on pruning the authors and since we are >only one over, I’d like to leave it as is. >> >> >> >> My review comments are below. Thanks again for your hard work in >getting this far! >> >> Minor issues: >> >> 1) On p. 6, it says " AF Address family for the prefix. Currently, >the >> only supported value is 0 for IPv4 unicast." Please clarify VERY >> CLEARLY why this restriction exists. Not everyone reading this will >> be familiar with support for IPv6 in various protocols and we are >really >> finally heading towards lots more IPv6. >> >> I will clarify. There are basically two reasons. The first is that we >really didn’t want to specify more than was necessary in this base >document. The second is that we have OSPFv3 for IPv6. So, you may ask >why we have this at all. The reason is that we didn’t want to rule out >extension of OSPFv2 completely. >> >> >> >> >> 2) On p. 6 and 8.: >> "The Instance field is an arbitrary value used to maintain multiple >> Extended Prefix Opaque LSAs. A maximum of 16777216 Extended Prefix >> Opaque LSAs may be sourced by a single OSPF instance.": This doesn't >> really give normative behavior. I assume that what you mean is that >> the advertising router has a number space for the Instance which has >> no significance outside of that advertising router and can have >> arbitrary values allocated from it. Each of these LSAs is identified >> uniquely by its Instance number. Please provide good text for what >> MUST be done and indicate that the value may be used for tie-breaking >> ("In this case, the Extended-Prefix-TLV in the Extended Prefix Opaque >> LSA with the smallest Instance is used by receiving OSPFv2 Routers. ") >> and there's an assumption that the values will be allocated from >> smallest to largest. >> >> I will clarify this. However, I don’t want to specify any assumption >about allocation. >> >> >> >> 3) On p. 6 for the Route Type, it would be useful to have a reference >to >> where these type values are pulled from. I'd also like to see some >> text about whether other values could be valid in the future and how >> so. For instance, I'm assuming that you are basically pulling the >> values from the OSPFv2 Link State (LS) Type >> >(http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xht >ml#ospfv2-parameters-5) >> - so perhaps you could simply say so or clarify for what are valid >> values. >> >> Is there an example of referencing an IANA directory? I could also >reference RFC 2823 and RFC 3101 directly. >> >> >> >> 4) On p. 9: For Link-Type, could you also put a reference to the IANA >> registry? I'd prefer it to be clear that if (unlikely as it seems) >> there were a new Link-Type added, it would apply here too. >> >> Sure. We’ll do the same. >> >> >> >> 5) In Sec 5, pleaes add an RFC Editor note that Section 5 will be >removed >> upon publication. That's the intent wtih RFC 6982. Thanks for >> including this section in the draft. If the information wants to move >> to the OSPF WG wiki, that would give it a place to survive after this >> draft is submitted to the RFC Editor. >> >> Ok - I need to hunt down this OSPF Wiki we talked about in Prague as >well. >> >> >> >> Nits: >> >> 6) In Sec 2, there's an "e.g., mapping server deployment". Could you >add >> a reference? This tells me nothing... >> >> Sure - it is the segment routing architecture document. >> >> >> >> 7) In Sec 2, In the packet format, could you clarify Opaque type = 7? >Same >> for on p.8 for opaque type = 8 ? >> >> Sure. >> >> >> 8) Since you are creating the registry for the TLVs, please clearly >state >> that value 1 is being used earlier - instead of "suggested value" as >> on p.9 >> >> Sure. >> >> Thanks, >> Acee >> >> >> >> Regards, >> Alia >> > > >------------------------------------------------------------------------ >-------- > > >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
