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
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.
' Please update the "revision" date of the YANG module.' There are
three of them:-)
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.
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?
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.
'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'. 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. 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
help here. And what does
if-feature algorithm;
add that
if-feature algorithm;
does not?
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'.
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
----- Original Message -----
From: "tom petch" <daedulus@xxxxxxxxxxxxx>
Sent: Friday, September 28, 2018 5:12 PM
> I believe that this I-D needs some admin-type changes to make it
usable.
>
> All three modules import some or all of
>
> ietf-inet-types
> ietf-interfaces
> iana-if-type
> ietf-softwire-common
>
> These imports should have YANG reference statements identifying the
> relevant RFC, probably
> 6991
> 8343
> 7244
> XXXX
>
> and these need to be Normative References for the I-D; 8343 is, 6991
is
> not.
>
> The first two modules have a sentence mentioning the use of RFC6991;
> this should mention all the modules referenced, those above and
> RFC7596
> RFC7597
> RFC7599:
> these last are already Normative References. A similar sentence is
> needed for the third module for the RFC that it references.
>
> The third module is a bit light on references - I cannot see any!
>
> There are three references to RFC XXX- I suspect that RFC XXXX is
> intended.
>
> IANA Considerations references RFC7950 - this is a poor reference
since
> all it says is 'Go look at RFC6020' which thus should be the reference
> here.
>
> Security Considerations starts "The YANG module defined in this
document
> ...
> Give us a clue - there are three of them:-)
>
> Appendix A. Configutation Examples
>
> Tom Petch
>
> ----- Original Message -----
> From: "The IESG" <iesg-secretary@xxxxxxxx>
> To: "IETF-Announce" <ietf-announce@xxxxxxxx>
> Cc: <softwires@xxxxxxxx>; <softwire-chairs@xxxxxxxx>;
> <jiangsheng@xxxxxxxxxx>; <terry.manderson@xxxxxxxxx>;
> <draft-ietf-softwire-yang@xxxxxxxx>
> Sent: Thursday, September 27, 2018 1:06 PM
>
> >
> > The IESG has received a request from the Softwires WG (softwire) to
> consider
> > the following document: - 'YANG Modules for IPv4-in-IPv6 Address
plus
> Port
> > Softwires'
> > <draft-ietf-softwire-yang-06.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> final
> > comments on this action. Please send substantive comments to the
> > ietf@xxxxxxxx mailing lists by 2018-10-11. Exceptionally, comments
may
> be
> > sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> > This document defines YANG modules for the configuration and
> > operation of IPv4-in-IPv6 softwire Border Relays and Customer
> > Premises Equipment for the Lightweight 4over6, MAP-E, and MAP-T
> > softwire mechanisms.
> >
> > Editorial Note (To be removed by RFC Editor)
> >
> > Please update these statements within this document with the RFC
> > number to be assigned to this document:
> >
> > o "This version of this YANG module is part of RFC XXXX;"
> >
> > o "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port
> > Softwires";
> >
> > o "reference: RFC XXXX"
> >
> > Please update the "revision" date of the YANG module.
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ballot/
> >
> > No IPR declarations have been submitted directly on this I-D.
