Re: [Softwires] Last Call: <draft-ietf-softwire-yang-06.txt> (YANG Modules for IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tom petch [mailto:[e-mail]]
> Envoyé : lundi 1 octobre 2018 13:27
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; draft-ietf-softwire-
> [e-mail]; [e-mail]
> 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
> [e-mail]>
> 
> 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
>