Hi Suresh, I thought Peter had addressed your comments. See inline. On 8/18/15, 10:14 PM, "Suresh Krishnan" <[email protected]> wrote:
>I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> > >Please wait for direction from your document shepherd or AD before >posting a new version of the draft. > >Document: draft-ietf-ospf-prefix-link-attr-10.txt >Reviewer: Suresh Krishnan >Review Date: 2015/08/18 >IESG Telechat date: 2015/08/20 > > >Summary: The draft is almost ready for publication as Proposed Standard >but there are some minor issues that need to be addressed as stated in >my last call review. We are on the process of converging on the fixes by >email. > >* Section 2 > >* In the packet format described in Figure "OSPFv2 Extended Prefix >Opaque LSA" the numbers 9, 10 and 11 are shown in a field. I think it >would be better if these are replaced by the text "LS type" as it is the >actual field. This will provide consistency with the rest of the figure. >The following text can then describe the allowed LS types as 9,10, and 11. I do agree that it is not consistent. However, this is inherited from RFC 5250 which is a BIS of 2370. Anyway, I can fix it. > >s/differential/differentiate/ Already fixed in -11 version. > >* Padding of TLVs. I am assuming that the TLVs are padded using zero >octets. If so, please state it explicitly. This text regarding OSPF TLVs has been in at least 1/2 dozen RFCs without confusion (starting with RFC 3630). I think the concept of padding is well understood in the OSPF community. “The padding is composed of zeros.” has been added. > >* Section 2.1. > >* In the packet format the "Address Prefix" field is marked as variable >length when it actually *is not*. It is always encoded as 32 bits long, >right? If so please the "(variable)" designation needs to be removed >for the Address Prefix. Already fixed in -11 version. > >* Shouldn't there be some IANA instructions for further extensions to >the Flags field in the OSPFv2 Extended Prefix TLV? Or is this field not >expected to be extended? Already fixed in -11 version. Need to re-open the IANA actions for the draft though. > >* IANA Considerations > >* The Opaque LSA Options types used by this document (7 & 8) seem to be >wrongly entered into the IANA registry and are pointing to >[draft-ietf-ospf-segment-routing-extensions] instead of this draft. It >is probably worth taking this up during the IANA check. No - these values do correspond to segment routing. This draft is a prerequisite that defines the OSPF extension mechanisms and creates the registry. Thanks, Acee > >Thanks >Suresh > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
