Hi Suresh,
please see inline:
On 8/14/15 05:41 , Suresh Krishnan wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the General Area director. Document editors and WG chairs
should treat these comments just like any other last call comments.
Document: draft-ietf-ospf-prefix-link-attr-10.txt
Reviewer: Suresh Krishnan
Review Date: 2015-08-13
IETF LC End Date: 2015-08-13
Summary: The draft is almost ready for publication as Proposed Standard
but there are some minor issues that need to be addressed.
* 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.
"9, 10 and 11" is used by RFC 4970, we took it from there. Do you still
want us to change?
s/differential/differentiate/
* Padding of TLVs. I am assuming that the TLVs are padded using zero
octets. If so, please state it explicitly.
again, we took the wording from RFC 4970.
RFC2370/RFC5250 that specifies the base Opaque LSA, does not specify
what values should be used for padding. I believe we should not mandate
it in the ospf-prefix-link-attr specification.
* 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.
Address Prefix is a variable length field - it is an encoding of the
prefix itself as an even multiple of 32-bit words, padding with zero
bits as necessary. The encoding as such supports IPv4 and IPv6
addresses, based on the "AF" field, so it can be extended for IPv6 if
needed later.
* 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?
Flags field can be extended. Agree that it is a good idea to add it to
IANA section.
* 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.
they point to the old OSPF SR draft which was split later and from which
the ospf-prefix-link-attr was carved. Once the RFC is published IANA
registry will be updated accordingly.
thanks,
Peter
Thanks
Suresh
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
