Hello Pete, Many thanks for your review. Please see inline.
On 6/15/2009 1:57 PM, McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-l2tpext-circuit-status-extensions-04 > Reviewer: Pete McCann > Review Date: 15 June 2009 > IETF LC End Date: 16 June 2009 > IESG Telechat date: unknown > > Summary: Basically ready, one minor question > > Major issues: none > > Minor issues: > > Section 2: > setting of in the > Did you mean: > setting of the N bit in the > ? Yes, thanks; fixed. > > In deprecating this N bit, will there be compatibility problems if an > implementation sends ICRQ, ICRP, OCRQ, or OCRP with the N bit clear? > Is it possible that older implementations would treat this as an invalid > message? There shouldn't be; as long as an implementation includes the Circuit Status AVP (because it is a "MUST be present" AVP for those four messages), it would not be invalid because of the value of the N bit field. Note that from its definition in S5.4.5 of RFC3931 at <http://tools.ietf.org/html/rfc3931#section-5.4.5>, it says: Otherwise, the New bit SHOULD still be set the first time the L2TP session is established after provisioning. so there is potential room for dealing with not setting it; similar language exists on the other RFCs being updated ("the New bit indicates ..." or "the New bit SHOULD be set ..."), so there would not be compatibility problems. > > Nits/editorial comments: none > Hopefully this reply clarifies, thanks again for your review ! -- Carlos. > > > _______________________________________________ > L2tpext mailing list > l2tp...@ietf.org > https://www.ietf.org/mailman/listinfo/l2tpext > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
