Hi Ignas, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Ignas Bagdonas [mailto:[email protected]] > Envoyé : jeudi 24 mai 2018 13:58 > À : The IESG > Cc : [email protected]; Ian Farrer; softwire- > [email protected]; [email protected]; [email protected] > Objet : Ignas Bagdonas' No Objection on draft-ietf-softwire-dslite-yang-16: > (with COMMENT) > > Ignas Bagdonas has entered the following ballot position for > draft-ietf-softwire-dslite-yang-16: 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-softwire-dslite-yang/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Nit: model vs module. While there are no strict requirements for terminology, > it appears that dominant term used in YANG documents is model and not module. > The reasoning would be that model defines a module and the logic description > of > it, while module is strictly a formal YANG code. > [Med] As per https://www.ietf.org/mail-archive/web/netmod/current/msg15324.html, both "YANG data model" and "YANG module" are valid terms. I will double check the document to fix any inconsistent use of the terms. > Nit: s/rate-lmite/rate limit [Med] Fixed. > > uint8 max-softwires-per-subscriber: Is the storage space large enough here? [Med] This is implementation- and deployment-specific. > RFC > 7785 recommends 1, but it does not appear to set upper limit. If practical > deployment scenarios will be an order of magnitude lower than 255 then likely > it is not a problem. > [Med] We are not setting any max because this is deployment-specific. > date-and-time last-address-change: Is the granularity of yang:date-and-time > enough for this use? > [Med] Yes. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
