Thanks Juergen and Lada for the explanation. I now understand the motivations not to obsolete.
Regards Suresh On 05/18/2016 08:49 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder <[email protected]> writes: > >> On Tue, May 17, 2016 at 08:59:20PM -0700, Suresh Krishnan wrote: >>> Suresh Krishnan has entered the following ballot position for >>> draft-ietf-netmod-rfc6020bis-12: 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-netmod-rfc6020bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Meta comment: >>> >>> Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in >>> the draft >> >> I guess this is because there are a couple of RFCs that depend on >> RFC6020 and so we can't retire RFC6020 right now. >> >>> Section 4.2.4: >>> >>> s/A reference a data tree node/A reference to a data tree node >>> >>> Section 9.4.7: >>> >>> It is not clear why the following refinement is illegal. Can you >>> clarify? >>> >>> type my-base-str-type { >>> // illegal length refinement >>> length "1..999"; >>> } >>> >> >> Because my-base-str-type is restricted to length "1..255" and you >> can't enlarge the length restriction in a refinement. >> >>> IANA considerations: >>> >>> Not sure what is the correct method for doing this in -bis documents, but >>> I would have expected a note that instructs IANA to switch references to >>> RFC6020 in IANA registries over to this one. >> >> This is what the WG originally thought but then we got advice that the >> original IANA allocation should stay in force... > > Right, and this is also, I believe, a specific reason why 6020 cannot be > obsoleted. > > Lada > >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
