Re: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Acee,
  Sounds good to me.

Thanks
Suresh

> On Jan 25, 2018, at 5:33 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> Working on too many things at one time. Actually this is already cover in section 6.3 so I will reference that section. 
> 
>      If a TLV or Sub-TLV is recognized but the length is less than the
>       minimum, then the LSA should be considered malformed and it
>       SHOULD NOT be acknowledged.  Additionally, the occurrence SHOULD
>       be logged with enough information to identify the LSA by type,
>       originator, and sequence number and the TLV or Sub-TLV in error.
>       Ideally, the log entry would include the hexadecimal or binary
>       representation of the LSA including the malformed TLS or Sub-TLV.
> 
> For example:
> 
> The sub-TLV length must meet minimum length constraints as specified in section 6.3.  
> 
> Thanks
> Acee 
> 
> On 1/24/18, 3:11 PM, "Acee Lindem (acee)" <[e-mail]> wrote:
> 
>    Hi Suresh, 
> 
>    On 1/24/18, 10:20 AM, "Suresh Krishnan" <[e-mail]> wrote:
> 
>        Suresh Krishnan has entered the following ballot position for
>        draft-ietf-ospf-ospfv3-lsa-extend-21: 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-ospfv3-lsa-extend/
> 
> 
> 
>        ----------------------------------------------------------------------
>        COMMENT:
>        ----------------------------------------------------------------------
> 
>        * Section 3.10 and 3.11
> 
>        What does the sub-TLV length mean here? Are values other than 4 and 16
>        permitted? If not, how is the packet treated (sub TLV is ignored?)
> 
>    My thought was to allow for further sub-TLVs defined recursively. However, one would still need a minimum length of 4 or 16 for the forwarding address TLVs. I will add this constraint and will indicate that the TLV is treated as malformed if it is not at least 4 or 16 octets respectively. Similarly, for the Route Tag sub-TLV, I'll indicate that the length must be at least 4 octets. 
> 
>    Thanks,
>    Acee
> 
> 
> 
> 
> 
> 
> 
> 
>