YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires
draft-ietf-softwire-yang-16

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Ian Farrer , Mohamed Boucadair , Yong Cui , Sladjana Zechlin , Linhui Sun , Rajiv Asati

[Ballot comment]
Thank you for quickly resolving my Discuss points!  Original COMMENT section preserved below.

Please expand CE on first usage.

Section 4.1

It feels a little strange to put something as generic as
/if:interfaces/if:interface/if:statistics:sent-ipv4-packets in the
ietf-softwire-ce module.  Are these counters likely to be useful for other
(non-softwire?) tunneling techniques?

Section 5.2

  o  softwire-num-max: used to set the maximum number of softwire
      binding rules that can be created on the lw4o6 element
      simultaneously.  This paramter must not be set to zero because
      this is equivalent to disabling the BR instance.

This seems to leave it ambiguous whether a server should reject an attempt
to set it to zero, or accept it but diable the BR instance.

Section 7

            leaf enable-hairpinning {
              type boolean;
              default "true";
              description
                "Enables/disables support for locally forwarding
                (hairpinning) traffic between two CEs.";
              reference "Section 6.2 of RFC7596";

Is a global toggle sufficient or would there be cases where more
fine-grained control would be needed?

Section 8

    container algo-versioning {
[...]
      leaf date {

        type yang:date-and-time;
        description
          "Timestamp when the algorithm instance was activated.

          An algorithm instance may be provided with mapping
          rules that may change in time (for example, increase
          the size of the port set). When an abuse party
          presents an external IP address/port, the version
          of the algorithm is important because depending on
          the version, a distinct customer may be identified.

nit: "abuse party" is probably not a term that everyone is familiar with.
(similarly in br-instances)

Section 9

Is there any possibility of a situation where the
invalid-/added/modified-entry notifications cause a substantial amount of
notification traffic (i.e., a DoS level of traffic)?

[Ballot comment]
Is the derived-from() complexity for statistics counters really required given that the module itself is for softwires, and any tunnel using it would be covered?

[Ballot comment]
I would have thought putting in a prioritization mechanism (like RFC8026 does) for ordering the different mechanisms would have been useful in this YANG module in order to configure the CE. Was this something that was considered?

[Ballot comment]
I support Alissa's discuss.

Further to Benjamin's discuss, I note that the YANG modules in this document
indicate two editors (I. Farrer and M. Bocadair) and five authors. Assuming
this distinction is intentional, RFC 7322 points to a clear resolution:

  If there is a
  request for more than five authors, the stream-approving body needs
  to consider if one or two editors should have primary responsibility
  for this document, with the other individuals listed in the
  Contributors or Acknowledgements section.

Based on the RFC 7322 text, I suspect that the best approach is moving the
five non-editors to a "Contributors" section.

[Ballot comment]
I support Alissa's DISCUSS, as well as Benjamin's "timestamp" issue.

Unfortunately I ran low on time and so wasn't able to do as full a review as I would have liked, so I'm trusting the sponsoring AD.

[Ballot discuss]
The security considerations do not seem to follow the YANG security guidelines . They do not list the specific writeable and readable subtrees/nodes and why they are sensitive. The fact that all the writeable nodes could "negatively affect network operations" seems trivially true for most writeable YANG module nodes. In the case of these modules, there seem to be multiple different threats relevant to different nodes, including exposure of data about individual users/customers, potential for disruption of the operations of the BR or CE, etc.

[Ballot discuss]
This document has 7 listed authors/editors.  Since, per RFC 7322, documents
listing more than five authors are unusaul, and seven is greater than five,
let's talk about the author count.

The binding-table-versioning container's "version" leaf is of type uint64
but the in-module description indicates that it is a timestamp.  If it is
actually supposed to be a timestamp, then the units and zero time need to
be specified, but it seems more likely that this should just be described
as an abstract version number, if I understand the prose text about this
container correctly.

[Ballot comment]
Please expand CE on first usage.

Section 4.1

It feels a little strange to put something as generic as
/if:interfaces/if:interface/if:statistics:sent-ipv4-packets in the
ietf-softwire-ce module.  Are these counters likely to be useful for other
(non-softwire?) tunneling techniques?

Section 5.2

  o  softwire-num-max: used to set the maximum number of softwire
      binding rules that can be created on the lw4o6 element
      simultaneously.  This paramter must not be set to zero because
      this is equivalent to disabling the BR instance.

This seems to leave it ambiguous whether a server should reject an attempt
to set it to zero, or accept it but diable the BR instance.

Section 7

            leaf enable-hairpinning {
              type boolean;
              default "true";
              description
                "Enables/disables support for locally forwarding
                (hairpinning) traffic between two CEs.";
              reference "Section 6.2 of RFC7596";

Is a global toggle sufficient or would there be cases where more
fine-grained control would be needed?

Section 8

    container algo-versioning {
[...]
      leaf date {

        type yang:date-and-time;
        description
          "Timestamp when the algorithm instance was activated.

          An algorithm instance may be provided with mapping
          rules that may change in time (for example, increase
          the size of the port set). When an abuse party
          presents an external IP address/port, the version
          of the algorithm is important because depending on
          the version, a distinct customer may be identified.

nit: "abuse party" is probably not a term that everyone is familiar with.
(similarly in br-instances)

Section 9

Is there any possibility of a situation where the
invalid-/added/modified-entry notifications cause a substantial amount of
notification traffic (i.e., a DoS level of traffic)?

[Ballot comment]
Some minor comments:

1) Sec 4.2:
"softwire-path-mru: optionally used to set the maximum IPv6
      softwire packet size that can be received, including the
      encapsulation/translation overhead.  Needed if the softwire
      implementation is unable to correctly calculate the correct IPv4
      Maximum Receive Unit (MRU) size automatically [RFC4213]."
I guess this should both be IPv6...?

2) Why does the description of "rcvd-ipv4-bytes" say
"IPv4 traffic received for processing, in bytes"..?
Does the "for processing" have any special meaning or why is it only phrased like this for that one entry?

3) Also the description for "sent-ipv4-bytes" and "sent-ipv4-packets" could be unified.

[Ballot comment]
Some minor comments:

1) Sec 4.2:
"softwire-path-mru: optionally used to set the maximum IPv6
      softwire packet size that can be received, including the
      encapsulation/translation overhead.  Needed if the softwire
      implementation is unable to correctly calculate the correct IPv4
      Maximum Receive Unit (MRU) size automatically [RFC4213]."
I guess this should both the IPv6...?

2) Why does the description of "rcvd-ipv4-bytes" say
"IPv4 traffic received for processing, in bytes"..?
Does the "for processing" have any special meaning or why is it only phrased like this for that one entry?

3) Also the description for "sent-ipv4-bytes" and "sent-ipv4-packets" could be unified.

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Ian Farrer , Mohamed Boucadair , Yong Cui , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Ian Farrer , Mohamed Boucadair , Yong Cui , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Ian Farrer , Mohamed Boucadair , Yong Cui , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-softwire-yang-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

three, new namespaces will be registered as follows:

ID: yang:softwire-ce
URI: urn:ietf:params:xml:ns:yang:softwire-ce
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:softwire-br
URI: urn:ietf:params:xml:ns:yang:softwire-br
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:softwire-common
URI: urn:ietf:params:xml:ns:yang:softwire-common
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

three, new YANG modules will be registered as follows:

Name: ietf-softwire-ce
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:softwire-ce
Prefix: softwire-ce
Module:
Reference: [ RFC-to-be ]

Name: ietf-softwire-br
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:softwire-br
Prefix: softwire-br
Module:
Reference: [ RFC-to-be ]

Name: ietf-softwire-common
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:softwire-common
Prefix: softwire-br
Module:
Reference: [ RFC-to-be ]

IANA Question --> For the YANG module named ietf-softwire-common, the authors have specified a prefix of softwire-be. IANA believes that is an error. It would duplicate the prefix for the YANG module ietf-softwire-br. Is a different prefix for ietf-softwire-common intended?

IANA Question --> What should be the entry for the registry value "Maintained by IANA?" for each of these new YANG modules?

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-10-11):

From: The IESG
To: IETF-Announce
CC: softwire-chairs@ietf.org, draft-ietf-softwire-yang@ietf.org, Sheng Jiang , softwires@ietf.org, terry.manderson@icann.org, jiangsheng@huawei.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Modules for IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard


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'
  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@ietf.org mailing lists by 2018-10-11. Exceptionally, comments may be
sent to iesg@ietf.org 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.

Document Writeup, template from IESG area on ietf.org, dated August 21, 2018.

draft-ietf-softwire-06 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Standards Track. The 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.
  The type clearly of RFC is indicated in the title page header.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  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.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-sun-softwire-yang prior to its adoption.
  There was unanimous support for it in favor of adoption and none against,
  so this document was adopted in August 2016. There was interest in this
  work posts since its adoption. There was never any opposition for this work.

  This document went through a relevant long document development
  period (22 months for individual document period, 23 month for WG
  document period). It has been reviewed well.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by multiple participants.
  So far, there is at least two existing implementations. They were
  explosured by the below two emails

  https://www.ietf.org/mail-archive/web/softwires/current/msg06924.html

  https://www.ietf.org/mail-archive/web/softwires/current/msg06928.html

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Terry Manderson is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document thorough once for -04 versions (and had
  other minor comments from time to time):
 
  https://www.ietf.org/mail-archive/web/softwires/current/msg06938.html 
 
  The issues raised in my reviews were promptly addressed by authors
  in -04 and -06 version along with the comments from other ANIMA WG members. 
  This document -06 version is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Yong Cui, Ian Farrer, Mohamed Boucadair, Qi Sun, Linhui
  Sun, Sladjana Zechlin and Rajiv Asati have confirmed in writing that
  they are not aware of any IPR, and that any and all appropriate IPR
  disclosures required for full conformance with the provisions of BCP 78
  and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits free.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this document.
   
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  No. All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  Yes.
 
  IANA is asked to registers three URIs in the IETF XML registry:
  URI: urn:ietf:params:xml:ns:yang:softwire-ce,
  URI: urn:ietf:params:xml:ns:yang:softwire-br,
  URI: urn:ietf:params:xml:ns:yang:softwire-common
 
  IANA is requested to registers three YANG modules in the YANG Module Names
  registry:ietf-softwire-ce, ietf-softwire-br, ietf-softwire-common.

  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  The YANG modules in the draft have both been checked and compile successfully
  without warnings using the 'pyang' tool.

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Linhui Sun , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Hao Wang , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Hao Wang , Rajiv Asati

Request for posting confirmation emailed to previous authors: Qi Sun , softwire-chairs@ietf.org, Yong Cui , Mohamed Boucadair , Ian Farrer , Sladjana Zechlin , Hao Wang , Rajiv Asati

Request for posting confirmation emailed to previous authors: softwire-chairs@ietf.org, Sladjana Zoric , Yong Cui , Mohamed Boucadair , Ian Farrer , Qi Sun , Hao Wang , Rajiv Asati

Request for posting confirmation emailed to previous authors: softwire-chairs@ietf.org, "Rajiv Asati" , "Qi Sun" , "Hao Wang" , "Yong Cui" , "Ian Farrer" , "Mohamed Boucadair" , "Sladjana Zoric"