[Softwires] RFC 8513 on A YANG Data Model for Dual-Stack Lite (DS-Lite)

2019-01-15 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8513

Title:  A YANG Data Model for 
Dual-Stack Lite (DS-Lite) 
Author: M. Boucadair,
C. Jacquenet,
S. Sivakumar
Status: Standards Track
Stream: IETF
Date:   January 2019
Mailbox:mohamed.boucad...@orange.com, 
christian.jacque...@orange.com, 
ssent...@cisco.com
Pages:  21
Characters: 36615
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-softwire-dslite-yang-17.txt

URL:https://www.rfc-editor.org/info/rfc8513

DOI:10.17487/RFC8513

This document defines a YANG module for the Dual-Stack Lite (DS-Lite)
Address Family Transition Router (AFTR) and Basic Bridging BroadBand
(B4) elements.

This document is a product of the Softwires Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] I-D Action: draft-ietf-softwire-iftunnel-02.txt

2019-01-15 Thread mohamed.boucadair 
Hi all,

This version integrates the comments received during the WG, mainly:
* Update the security considerations
* Update the pointers to point to the document defining the tunneling 
techniques instead of RFC4087.

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de internet-
> dra...@ietf.org
> Envoyé : mardi 15 janvier 2019 16:34
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] I-D Action: draft-ietf-softwire-iftunnel-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Softwires WG of the IETF.
> 
> Title   : Tunnel Interface Types YANG Module
> Authors : Mohamed Boucadair
>   Ian Farrer
>   Rajiv Asati
>   Filename: draft-ietf-softwire-iftunnel-02.txt
>   Pages   : 15
>   Date: 2019-01-15
> 
> Abstract:
>This document specifies a YANG module containing a collection of IANA
>maintained YANG identities, used as interface types for tunnel
>interfaces.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-iftunnel-02
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-iftunnel-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-iftunnel-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] I-D Action: draft-ietf-softwire-iftunnel-02.txt

2019-01-15 Thread internet-drafts 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires WG of the IETF.

Title   : Tunnel Interface Types YANG Module
Authors : Mohamed Boucadair
  Ian Farrer
  Rajiv Asati
Filename: draft-ietf-softwire-iftunnel-02.txt
Pages   : 15
Date: 2019-01-15

Abstract:
   This document specifies a YANG module containing a collection of IANA
   maintained YANG identities, used as interface types for tunnel
   interfaces.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-softwire-iftunnel-02
https://datatracker.ietf.org/doc/html/draft-ietf-softwire-iftunnel-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-iftunnel-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] draft-ietf-softwire-yang-15 posted incorporating IESG eval. (and area review) comments

2019-01-15 Thread ianfarrer 
Hi

We’ve just posted -15 of this draft incorporating the IESG evaluation 
DISCUSSes/comments and the Secdir/Genart review comments. Many thanks for those.

Thanks,
Ian

Below is the log of DISCUSS/Comments received during the review and the changes 
that have been incorporated to address them.


---

DISCUSS Points:

Alissa Cooper (Supported by Adam Roach, Ben Campbell, Warren Kumari and Alexey 
Melnikov)

The security considerations do not seem to follow the YANG security guidelines
https://trac.ietf.org/trac/ops/wiki/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.

The Security Considerations section has been rewritten expressly describing
the threats associated to the relevant nodes.

--

Benjamin Kaduk (supported by Adam Roach, Benjamin Campbell and Alexey Melnikov)
Discuss 1

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 document follow’s Adam Roach’s suggestion (in support of Benjamin’s DISCUSS)
above, and now lists 2 editors and a Contributors section.

—

Benjamin Kaduk (Supported by Warren Kumari)
Discuss 2 

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.

Description text changed to match the leaf’s type:
Version number for this binding table.

-

Comments:

Alissa Cooper
Comment 1
I think "external party" would make more sense than "abuse party.”

Sentence reworded (in both instances) to:
When a party who is the victim of abuse presents an external IP address/port,


—-

Benjamin Kaduk
Comment 1
Please expand CE on first usage.

The abstract gives the full name and the abbreviation is explained in the 
Introduction.

Comment 2
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?

The counters can be re-used bu other modules. No change is needed.

---

Comment 3
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.

The text is clear.
range "1..max".

No change is needed.

---

Comment 4
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?

A+P is designed to reduce as much as possible the per-subscriber state at the 
network/BR. Requiring fine-grained control would require some extra state to be 
maintained, which is not desired. Having the general parameter is sufficient.

---

Comment 5
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)

Sentence reworded to:
When a party who is the victim of abuse presents an external IP address/port,

---

Comment 6
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)?

Added some text among those lines:

This is in theory possible if the BR i

[Softwires] I-D Action: draft-ietf-softwire-yang-15.txt

2019-01-15 Thread internet-drafts 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires WG of the IETF.

Title   : YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) 
Softwires
Authors : Ian Farrer
  Mohamed Boucadair
Filename: draft-ietf-softwire-yang-15.txt
Pages   : 52
Date: 2019-01-15

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, Mapping of Address and
   Port with Encapsulation (MAP-E), and Mapping of Address and Port
   using Translation (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 ;"

   o  "RFC : YANG Modules for IPv4-in-IPv6 Address plus Port
  Softwires";

   o  "reference: RFC "

   Please update the "revision" date of the YANG modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-softwire-yang-15
https://datatracker.ietf.org/doc/html/draft-ietf-softwire-yang-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-yang-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires