On Jan 12, 2012, at 23:16 , Roni Even wrote: > Hi, > I looked at the 08 version and the major issues are addressed. > What about minor issue number 3? Good point! I will fix (as Stewart suggests, maybe just remove the reference). To your minor issue (2), I've clarified the structure. Do you still want to see how it fits into the NLRI? Thanks, Kireeti. > Roni Even > >> -----Original Message----- >> From: Kireeti Kompella [mailto:kireeti@xxxxxxxxxxx] >> Sent: Friday, September 16, 2011 10:23 PM >> To: Roni Even >> Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@xxxxxxxxxxxxxx; >> gen-art@xxxxxxxx; IETF-Discussion list >> Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 >> >> Hi Roni, >> >> On Sep 7, 2011, at 4:37 , Roni Even wrote: >> >>> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Thanks! >> >>> Please resolve these comments along with any other Last Call comments >> you may receive. >>> >>> Document: draft-kompella-l2vpn-l2vpn-07 >>> Reviewer: Roni Even >>> Review Date: 2011-9-7 >>> IETF LC End Date: 2011-9-27 >>> IESG Telechat date: >>> >>> Summary: This draft is not ready for publication as an informational >> RFC. >>> >>> Major issues: >>> >>> The IANA considerations section says: >>> "the values already allocated are in Table 1 of Section 4. The >> allocation policy for new entries up to and including value 127 is >> "Standards Action". The allocation policy for values 128 through 251 >> is "First Come First Served". The values from 252 through 255 are for >> "Experimental Use"." >> >> Standards Action will be changed to Expert Review. >> >>> Yet this is document is intended for Informational status which >> contradict the standard action. This is also true for the second >> registry defined. >>> >>> Is this document really an Informational one? >> >> My only comment is that it is not Historic. >> >>> Minor issues: >>> >>> 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., >> real Frame Relay circuits connecting sites) are indistinguishable from >> tunnel-based VPNs from the customer's point-of-view, migrating from >> one to the other raises few issues." What are the few issues? >> >> A subtlety: "few issues" means not many, not deep; it's a careful way >> of saying, "just about no issues". "A few issues" would require >> elaboration. >> >>> 2. In section 4 "L2VPN TLVs can be added to extend the >> information carried in the NLRI, using the format shown in Figure 2". >> How is the TLV carried in the NLRI, in which field, section 4.1 only >> talk about the structure of the TLV. >> >> I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. >> >>> 3. Section 4.2 refers to section 4 but I am not sure where this >> mechanism in section 4 is. >> >> Will clarify. >> >>> >>> >>> >>> >>> >>> Nits/editorial comments: >>> >>> 1. Section 3.1 is called network topology but the whole text is >> an example of a network topology. Maybe the title should be "Example of >> a network toplogy". >> >> Sure. >> >>> 2. Section 5 starts with "As defined so far in the document .." >> But the using IP only is already discussed in previous sections. >> >> Do you have a suggestion for rewording? >> >> Thanks, >> Kireeti. >> >> >>> >>> >>> <ATT00001..txt> > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf