Hi Bruno, Thanks for the changes. > On Sep 18, 2017, at 11:20 AM, <bruno.decra...@orange.com> > <bruno.decra...@orange.com> wrote: > > Suresh, > > Thanks for the review and comments. > Please see inline [Bruno] > >> From: Suresh Krishnan [mailto:suresh.krish...@gmail.com] >> Sent: Thursday, August 31, 2017 4:50 AM >> >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-ospf-encapsulation-cap-06: Discuss >> >> 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-encapsulation-cap/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> * There seems to be an difference between this document's definition of >> sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with 1 octet >> types and lengths). So I am surprised to see the document point to the >> RFC5512 >> based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) . Can >> you >> please explain how these sub-TLVs are encoded on the wire to be compatible >> with >> this draft? > > [Bruno] Would the following change works for you? > > OLD: > This Sub-TLV of type 2 is defined in Section 3.4.1 "Protocol Type > sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/> from a > syntactic, semantic, and usage standpoint. > > NEW: > This Sub-TLV type is 2. The syntax, semantic, and usage of its value > field is defined in Section 3.4.1 "Protocol Type > sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/>.
Excellent. That would address my concerns. I checked the new version of the draft and this fix addresses all of the instances of this issue. I will clear. > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> * IANA considerations >> >> Looks like the value 65535 is included both as experimental and reserved. >> Suggest changing >> >> OLD: >> 65500-65535 Experimental This document >> >> NEW: >> 65500-65534 Experimental This document >> > > [Bruno] Good catch. Thanks for the careful review. Fixed as per you > suggestion in -07 > https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-07.txt > <https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-07.txt> Great. Regards Suresh
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
