Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De : tom petch [mailto:daedulus@xxxxxxxxxxxxx] > Envoyé : lundi 1 octobre 2018 13:27 > À : ietf@xxxxxxxx > Cc : softwires@xxxxxxxx; softwire-chairs@xxxxxxxx; draft-ietf-softwire- > yang@xxxxxxxx; jiangsheng@xxxxxxxxxx > Objet : Re: Last Call: <draft-ietf-softwire-yang-06.txt> (YANG Modules for > IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard > > Some more thoughts on this I-D > > No mention of NMDA - I see the IESG asking for such a statement in > Abstract and in the body of an I-D [Med] Added to the introduction: The adopts the Network Management Datastore Architecture (NMDA) [RFC8342]. > > Abbreviations are expanded but on the nth use, not the first use e.g. > BR, PSID; they probably should be expanded on first use within the YANG > module as well. [Med] Will double check this. > > ' Please update the "revision" date of the YANG module.' There are > three of them:-) [Med] OK. > > Terminology is problematic especially as it seems inconsistent with the > Normatively Referenced RFC7596, RFC7597, RFC7599. > > Customer Premises Equipment (CEs .. > CE is a well known abbreviations for Customer Edge, as oppposed to > Provider Edge, and this is not meant here. Indeed, RFC7599 uses CE for > Customer Edge. Customer Premises Equipment is widely abbreviated to > CPE. RFC7596, a Normative Reference, has 'Customer Premises Equipment > (CPE)' which I should be used here. [Med] Added: (a.k.a., CPE). Actually, we just went with CE used in RFC7599. > > In places, it is 'MAP-E, and MAP-T', elsewhere 'MAP-E or MAP-T'. Does > feature 'algorithm' mean both are supported or just one, and if one, how > can the user tell? [Med] Feature 'algorithm' means 'MAP-E and/or MAP-T' is supported. Nevertheless, when it comes to actual configuration, only MAP-E or MAP-T parameters can be conveyed. This is hinted by the data-plane clause. > > The description clause of 'module ietf-softwire-common' is misleading. > The introductory sentence of the section accurately describes the module > as common definitions but the description clause claims to configure > Lw4o6, MAP-E and MAP-T which it seems wrong. [Med] Fixed. > > 'algorithm' is widely (mis?)used in this I-D. The Normative Reference > RFC7597 is much easier to follow since it mostly talks of 'Mapping > Algorithm' or 'Mapping Rule'. [Med] Added: For simplicity, "algorithm" is used to refer to "mapping algorithm" [RFC7599]. I think > case algorithm { > if-feature algorithm; > container algo-instances { > list algo-instance { > with > grouping algorithm-instance { > in softwire-common and > case algorithm { > if-feature algorithm; > container algorithm { > if-feature algorithm; > need a different term or terms. [Med] OK. Went for: case algo { if-feature algorithm-mode; container algo-instances { list algo-instances { Likewise > case binding { > if-feature binding; > container binding { > if-feature binding; > list bind-instance { > for binding. A widely used, and helpful convention is to have a list > the plural - interfaces - and entries singular - interface; that would [Med] Went for list bind-instances. > help here. And what does > if-feature algorithm; > add that > if-feature algorithm; > does not? > [Med] Removed one if-feature statement. > BR is a well known abbreviation for Border Router; here it used for MAP > Border Relay and while RFC7599 says 'A MAP BR may also be referred to as > simply a "BR" within the context of MAP.', I think that the context here > is wider - the modules are not just MAP - and the term should be 'MAP > BR' not just 'BR'. [Med] Added: The document uses BR to refer to MAP BR [RFC7599] or Lightweight 4over6 BR [RFC7596]. > > After my previous message > ietfa.amsl.com. > gave me a bounce message for > yong@xxxxxxxxxxxxxxxxxxxxxxxxx> > > Overall, I get a slight flavour that this is written by those intimately > acquainted with the technology (although not so much with the RFC!) for > similar readers. > > Tom Petch >
