Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

[Alia Atlas <[e-mail]>]

Minor correction:

On Tue, Sep 22, 2015 at 6:00 PM, Alia Atlas <[e-mail]> wrote:

> As is customary, I have done my AD review
> of draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on
> this draft.
>
> I have two major concerns before asking for an IETF Last Call.  I would
> like to have them
> resolved by this Thursday so that the draft can make the Oct 15 IESG
> telechat.
>
> First, from a process concern, I do not see any active discussion on the
> OSPF mailing list - even to simply say "yes - go forward".  I don't see
> anything about this draft or discussion in minutes for IETF 92 or IETF 93.
>   I'd prefer some indication besides silence and lack of opposition.  I do
> realize that there are some process or protocol-tidying drafts where there
> isn't
> much interest.  However, I am particularly concerned because this is
> changing RFC4970 is a way that should be backwards compatible but might
> trigger issues.   I would encourage WG participants to PLEASE RESPOND!
>

In IETF 91 minutes, I see a presentation and question from Shraddha about
making it MT capable.  There was no
answer except take it to the list and no follow-up discussion.

Am I missing anything?

Regards,
Alia



> Second, I can see the intent that by creating an Opaque ID and creating a
> special meaning for 0, the draft is making efforts to preserve backwards
> compatibility.  Please add a paragraph or subsection that articulates how
> and why backwards compatibility isn't an issue.  For extra credit, what
> happens if the same TLV information is advertised in multiple RI LSAs (as
> part of moving it from one RI LSA to another)?
>
> Are there any implementations of this draft?  Has backwards compatibility
> been verified at all?
>
> My minor issue is around the IANA considerations; I have detailed comments
> below.
>
> Here are additional comments.
>
> 1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the
> Router
>    Informational Capabilities TLV and, if advertised, the Router
>    Functional Capabilities TLV."  and Sec 2.2 "The first instance ID,
> i.e., 0,
>    should always contain the Router Informational Capabilities TLV and,
>    if advertised, the Router Functional Capabilities TLV."
>
>    Since I assume this is important for backwards compatibility, should
> those
>    be SHOULD instead of should?
>
> 2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the
> Router
>    Informational Capabilities TLV."
>
>    Surely that is only for the first Opaque ID=0?  Does each subsequent RI
> LSA
>    also need to contain a Router Informational Capabilities TLV??
>
> 3) In Sec 4 IANA Considerations:  This section is defining the different
> IANA policies;
> when RFC4970 was written, RFC5226 didn't exist.  But since you're doing a
> bis,
> perhaps you can align to the policies in RFC5226 and remove the
> unnecessary text??
>
> 4) In Sec 4 IANA Considerations:  The registry for OSPFv3 LSA Function
> Codes can
> be found at
> http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-3
> and what is in the draft doesn't match up.  I'd settle for defining the
> ranges, and value 12 - but it's up to you and IANA on the preferences.
> Would it make sense to change the policy from Standards Action to IETF
> Review here also?
>
> Same thing applies to the OSPF RI TLVS (
> http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-9
> )   Also here, I think there
> was agreement among the 4 of us who commented on the WG mailing list to
> change this
> from Standards Action to IETF Review.
>
> 5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV
>        additions are to be assigned through standards action."   Given the
> discussion
> about IETF Review vs. Standards Action for other registries, are you sure
> you want
> Standards Action?
>
> I'm sure that we'll get this moving along quickly.
>
> Thanks again!
> Alia
>