Minor correction: On Tue, Sep 22, 2015 at 6:00 PM, Alia Atlas <[email protected]> wrote:
> As is customary, I have done my AD review > of draft-ietf-ospf-rfc4970bis-02. First, let me thank Acee for his work on > this draft. > > I have two major concerns before asking for an IETF Last Call. I would > like to have them > resolved by this Thursday so that the draft can make the Oct 15 IESG > telechat. > > First, from a process concern, I do not see any active discussion on the > OSPF mailing list - even to simply say "yes - go forward". I don't see > anything about this draft or discussion in minutes for IETF 92 or IETF 93. > I'd prefer some indication besides silence and lack of opposition. I do > realize that there are some process or protocol-tidying drafts where there > isn't > much interest. However, I am particularly concerned because this is > changing RFC4970 is a way that should be backwards compatible but might > trigger issues. I would encourage WG participants to PLEASE RESPOND! > In IETF 91 minutes, I see a presentation and question from Shraddha about making it MT capable. There was no answer except take it to the list and no follow-up discussion. Am I missing anything? Regards, Alia > Second, I can see the intent that by creating an Opaque ID and creating a > special meaning for 0, the draft is making efforts to preserve backwards > compatibility. Please add a paragraph or subsection that articulates how > and why backwards compatibility isn't an issue. For extra credit, what > happens if the same TLV information is advertised in multiple RI LSAs (as > part of moving it from one RI LSA to another)? > > Are there any implementations of this draft? Has backwards compatibility > been verified at all? > > My minor issue is around the IANA considerations; I have detailed comments > below. > > Here are additional comments. > > 1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the > Router > Informational Capabilities TLV and, if advertised, the Router > Functional Capabilities TLV." and Sec 2.2 "The first instance ID, > i.e., 0, > should always contain the Router Informational Capabilities TLV and, > if advertised, the Router Functional Capabilities TLV." > > Since I assume this is important for backwards compatibility, should > those > be SHOULD instead of should? > > 2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the > Router > Informational Capabilities TLV." > > Surely that is only for the first Opaque ID=0? Does each subsequent RI > LSA > also need to contain a Router Informational Capabilities TLV?? > > 3) In Sec 4 IANA Considerations: This section is defining the different > IANA policies; > when RFC4970 was written, RFC5226 didn't exist. But since you're doing a > bis, > perhaps you can align to the policies in RFC5226 and remove the > unnecessary text?? > > 4) In Sec 4 IANA Considerations: The registry for OSPFv3 LSA Function > Codes can > be found at > http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-3 > and what is in the draft doesn't match up. I'd settle for defining the > ranges, and value 12 - but it's up to you and IANA on the preferences. > Would it make sense to change the policy from Standards Action to IETF > Review here also? > > Same thing applies to the OSPF RI TLVS ( > http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-9 > ) Also here, I think there > was agreement among the 4 of us who commented on the WG mailing list to > change this > from Standards Action to IETF Review. > > 5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV > additions are to be assigned through standards action." Given the > discussion > about IETF Review vs. Standards Action for other registries, are you sure > you want > Standards Action? > > I'm sure that we'll get this moving along quickly. > > Thanks again! > Alia >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
