Subject: [OSPF] Barry Leiba's No Objection on draft-ietf-ospf-prefix-link-attr-10: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Fri, 14 Aug 2015 10:13:25 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-ospf-prefix-link-attr-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some minor comments, just some clarifications... and a question about the
registries.

-- Section 2 --
There is no explanation of the "length" field in the OSPFv2 Extended
Prefix Opaque LSA.  I guess it's the total size, in bytes, of all the TLV
data that follows, including any alignment bytes.  But you should make
that clear.

-- Section 3 --
The same comment as for Section 2 applies here for the OSPFv2 Extended
Link Opaque LSA.

-- Section 7.1 --

   Types in the range 33024-65535 are not to be assigned at this time.
   Before any assignments can be made in the 33024-65535 range, there
   MUST be an IETF specification that specifies IANA Considerations that
   covers the range being assigned.

A question here (I'm not hoping for any particular answer, just asking
the question): When you say "an IETF specification", I take that to mean
an RFC in the IETF stream, which can be Standards Track *or*
Informational *or* Experimental.  Is that what you want?

The same question applies to the registries in the subsequent sections
(7.2, 7.3, 7.4).

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Aug 2015 01:57:23 +0000

Hi Barry,

Thanks for the review.

>https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/

The LSA header length, as defined in RFC 2328, is pretty standard.
However, this can be succinctly clarified. How about?

  The LSA “Length” field [RFC2328] represents the total length (in octets)
of the Opaque LSA including the LSA header and all TLVs (including
padding). 

>The same comment as for Section 2 applies here for the OSPFv2 Extended

Same answer. 

>Informational *or* Experimental.  Is that what you want?

Yes. I’d like to leave this open. I’d hope we’d do the right thing when
the time comes to assign this space.

Thanks,
Acee

---

From: Barry Leiba <[email-masked]>
Date: Mon, 17 Aug 2015 22:33:42 -0400

Hi, Acee, and thanks for the response.

> of the Opaque LSA including the LSA header and all TLVs (including

That sounds good to me.  And if you really think it's sufficiently
well known already as not to need that, I'm OK with it as it is.
Thanks for considering the comment.

> the time comes to assign this space.

OK; quite fine.  Carry on....

Barry