Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ospf-prefix-link-attr-10.txt

["Acee Lindem (acee)" <[e-mail]>]

Hi Suresh, 
I thought Peter had addressed your comments. See inline.

On 8/18/15, 10:14 PM, "Suresh Krishnan" <[e-mail]>
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
>
>