OSPF Link-Local Signaling
draft-ietf-ospf-lls-08

Section 2., paragraph 4:
>    The LLS data block MAY be attached to OSPF Hello and DD packets.

  The "MAY" is ambiguous - do you mean "MUST only"?


Section 6.1., paragraph 4:
>    [OSPFV3]   Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
>               RFC 2740, December 1999.

  Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by
  RFC 5340). Please add RFC Editor Note.

I had the same question as Pasi to be sure that this actually gets marked as obsoleting RFC4813.

> 2.4.  Extended Options TLV
>   Bits in the Value field do not have any semantics from the point of
>    view of the LLS mechanism.  This field MAY be used to announce some
>    OSPF capabilities that are link-specific.  Also, other OSPF
>    extensions MAY allocate bits in the bit vector to perform boolean
>    link-local signaling.

This field doesn't seem to scope the LLS options to be link-local in nature, which I would think would be a minimum requirement. Further, it seems that the bits are not even restricted to being "Extended Options" given that there is explicit wording allowing the bits to be used as boolean flags.

I think that at a minimum this needs to be scoped to link-local signaling, and should probably be renamed to "Extended Flags" or some such so that people will not mistake that it is only used for capability option signaling, but also is open for use for any sort of boolean signaling.

> 2.1.  Options Field

I would rename this section to "L-bit in Options Field" so as not to imply that the Options field is being defined in this document, just that the L bit is.

> 2.6.  Private TLVs
All other TLVs come with a picture, except this one.

>    The data included in the LLS block attached to a Hello packet MAY be
>    used for dynamic signaling since Hello packets may be sent at any
>    time in time.

time in time?

The security considerations section would benefit from a few pointers and a bit more text.
I suggest adding the following to the first paragraph:

Security Considerations inherited from OSPFv2 are described in [OSPFV2].

I would suggest adding the following to the second paragraph:

Security considerations inherited from OSPFv3 are described in [OSPFv3] and [OSPFV3AUTH].