Re: [Softwires] Alissa Cooper's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Hi Alissa, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Alissa Cooper [mailto:ali...@cooperw.in]
> Envoyé : mardi 8 janvier 2019 23:03
> À : The IESG
> Cc : draft-ietf-softwire-y...@ietf.org; Sheng Jiang; softwire-
> cha...@ietf.org; jiangsh...@huawei.com; softwires@ietf.org
> Objet : Alissa Cooper's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS
> and COMMENT)
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-softwire-yang-14: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
> 
> 
> 
> --
> 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.
> 

[Med] This is fair. We can elaborate as follows: 

   All data nodes defined in the YANG modules which can be created,
   modified, and deleted (i.e., config true, which is the default) are
   considered sensitive.  Write operations (e.g., edit-config) applied
   to these data nodes without proper protection can negatively affect
   network operations.  An attacker who is able to access the BR can
   undertake various attacks, such as:

   o  Setting the value of 'br-ipv6-addr' on the CE to point to an
  illegitimate BR so that it can intercept all the traffic sent by a
  CE.  Illegitimately intercepting users' traffic is an attack with
  severe implications on privacy.

   o  Setting the MTU to a low value, which may increase the number of
  fragments ('softwire-payload-mtu').

   o  Disabling hairpinning (i.e., setting 'enable-hairpinning' to 'false')
  to prevent communications between CEs.

   o  Setting 'softwire-num-max' to an arbitrary high value, which may
  be exploited by a misbehaving user to perform a DoS on the binding
  BR by mounting a massive number of softwires.

   o  Setting 'icmpv4-rate' or 'icmpv6-rate' to a low value, which may
  lead to the deactivation of ICMP messages handling.

   o  Accessing to privacy data maintained by the BR (e.g., the binding
  table or the algorithm configuration).  Such data can be misused
  to track the activity of a host.

   o  Instructing the BR to install entries which in turn will induce a
  DDoS attack by means of the notifications generated by the BR.
  This DDoS can be softened by defining a notification interval, but
  given that this interval parameter can be disabled or set to a low
  value by the misbehaving entity, the same problem will be
  observed.

> 
> --
> COMMENT:
> --
> 
> I think "external party" would make more sense than "abuse party."
> 

[Med] This information is not revealed to every "external" party but only under 
some regulatory restrictions when an abuse is reported (check Section 13.1 of 
RFC6269). 

I changed the text to "a party victim of an abuse". Hope this is better.


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

Re: [Softwires] Yangdoctors early review of draft-ietf-softwire-iftunnel-03

[mohamed.boucadair]

Hi Andy,

Good catch.

I updated the draft to take into account your review: 
https://tools.ietf.org/html/draft-ietf-softwire-iftunnel-04 

Thank you. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Andy Bierman
> via Datatracker
> Envoyé : mercredi 3 avril 2019 20:53
> À : yang-doct...@ietf.org
> Cc : softwires@ietf.org; draft-ietf-softwire-iftunnel@ietf.org
> Objet : [Softwires] Yangdoctors early review of draft-ietf-softwire-iftunnel-
> 03
> 
> Reviewer: Andy Bierman
> Review result: Ready with Nits
> 
> The iana-tunnel-type module has no errors or nits of any kind.
> The ietf-extension-example module has no errors of any kind, and 1 nit.
> The document appears to follow all YANG usage guidelines (but 1) correctly.
> 
> I have a minor comment about the example module. I guess it has to use  BEGINS>. (The  discussion did not go anywhere).
> 
> This module looks a little too real to average users, especially after tools
> extract it from the RFC and put it in the YangModels repo under the
> standard/ietf/RFC directory.
> 
> You should rename the ietf-extension-example module to
> example-iftunnel-extension (or anything starting with "example-"). The module
> should not begin with "ietf-" unless it is a real module.
> 
> 
> ___
> 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

Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

[mohamed.boucadair]

Hi Yu,

The answer to your question is: Yes.

Cheers,
Med

De : Yu Tianpeng [mailto:yutianpeng.i...@gmail.com]
Envoyé : mardi 12 février 2019 14:52
À : BOUCADAIR Mohamed TGI/OLN
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Thanks a lot Mohamed.
It answers my questions.
Inline below.
Regards,
Tim
On Mon, 11 Feb 2019, 12:42 
mailto:mohamed.boucad...@orange.com> wrote:
Hi Yu,

Please see inline.

Cheers,
Med

De : Softwires 
[mailto:softwires-boun...@ietf.org] De la 
part de Yu Tianpeng
Envoyé : lundi 11 février 2019 12:27
À : softwires@ietf.org
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Dear authors,
Thanks for the new version.
I had a quick read on latest version. I find some nits and also some questions 
along the way as we meet a scenario when deploying MAP that need s46 radius 
attributes.

Nits:
Section 7.1 should be referring section 3.x not 4.x
[Med] Thank you for catching the bug in Section 7.1.

Question:
1. How is the status of this document? This draft has last called long time 
ago, but still not standard yet. What is the reason? Any plans to move further? 
As I mentioned we meet requirement when deploying map, we may need to make a 
decision if we follow this draft or define a vendor specific one.

[Med] The document passed the WGLC + addressed the reviews from radext wg. We 
do think that the document is ready to be sent to the IESG.
 [Tim] glad to know. Thanks
2. This draft seems haven't consider conflicts between subscribers. E.g.  EA 
length conflict between subscribers with in one MAP domain? And EA length from 
radius conflict with BNG within same MAP domain?
As this draft enables the capability to maintain MAP rule logic in radius, 
conflict mechanisn should be investigated in my POV.

[Med] Which conflict mechanism do you have in mind?

I’m afraid this is deployment and implementation-specific. FWIW, the draft 
includes the following to warrant that some consistency checks is needed:

   In some deployments, the DHCP server may use the Accounting-Request
   to report to a AAA server the softwire configuration returned to a
   requesting host.  It is the responsibility of the DHCP server to
   ensure the consistency of the configuration provided to requesting
   hosts.
 [Tim] yes, it solves one of the scenario I mentioned.
I believe if dhcp server use access request to get s46 info from AAA, then AAA 
server is response to enrue the consistency I suppose. Am I right?

Appreciate your feedback.
Thanks in advance
Tim
On Mon, 11 Feb 2019, 08:26 
mailto:internet-dra...@ietf.org> wrote:

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   : RADIUS Attributes for Address plus Port (A+P) based 
Softwire Mechanisms
Authors : Sheng Jiang
  Yu Fu
  Bing Liu
  Peter Deacon
  Chongfeng Xie
  Tianxiang Li
  Mohamed Boucadair
Filename: draft-ietf-softwire-map-radius-19.txt
Pages   : 39
Date: 2019-02-11

Abstract:
   IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity
   services over IPv6 native networks during the IPv4/IPv6 co-existence
   period.  DHCPv6 options have been defined for configuring clients for
   Lightweight 4over6, Mapping of Address and Port with Encapsulation,
   and Mapping of Address and Port using Translation unicast softwire
   mechanisms, and also multicast softwires.  However, in many networks,
   configuration information is stored in an Authentication,
   Authorization, and Accounting server which utilizes the RADIUS
   protocol to provide centralized management for users.  When a new
   transition mechanism is developed, new RADIUS attributes need to be
   defined correspondingly.

   This document defines new RADIUS attributes to carry Address plus
   Port based softwire configuration parameters from an Authentication,
   Authorization, and Accounting server to a Broadband Network Gateway.
   Both unicast and multicast attributes are covered.


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

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

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


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:

Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

[mohamed.boucadair]

Hi Yu,

Great!

Uploaded -20 which fixes the reference issue you pointed out + includes a 
mention that configuration consistency check is also the responsibility of the 
AAA server.

Cheers,
Med

De : Yu Tianpeng [mailto:yutianpeng.i...@gmail.com]
Envoyé : mardi 12 février 2019 15:10
À : BOUCADAIR Mohamed TGI/OLN
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Thanks
Cheers.

On Tue, 12 Feb 2019, 14:07 
mailto:mohamed.boucad...@orange.com> wrote:
Hi Yu,

The answer to your question is: Yes.

Cheers,
Med

De : Yu Tianpeng 
[mailto:yutianpeng.i...@gmail.com]
Envoyé : mardi 12 février 2019 14:52
À : BOUCADAIR Mohamed TGI/OLN
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Thanks a lot Mohamed.
It answers my questions.
Inline below.
Regards,
Tim
On Mon, 11 Feb 2019, 12:42 
mailto:mohamed.boucad...@orange.com> wrote:
Hi Yu,

Please see inline.

Cheers,
Med

De : Softwires 
[mailto:softwires-boun...@ietf.org] De la 
part de Yu Tianpeng
Envoyé : lundi 11 février 2019 12:27
À : softwires@ietf.org
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Dear authors,
Thanks for the new version.
I had a quick read on latest version. I find some nits and also some questions 
along the way as we meet a scenario when deploying MAP that need s46 radius 
attributes.

Nits:
Section 7.1 should be referring section 3.x not 4.x
[Med] Thank you for catching the bug in Section 7.1.

Question:
1. How is the status of this document? This draft has last called long time 
ago, but still not standard yet. What is the reason? Any plans to move further? 
As I mentioned we meet requirement when deploying map, we may need to make a 
decision if we follow this draft or define a vendor specific one.

[Med] The document passed the WGLC + addressed the reviews from radext wg. We 
do think that the document is ready to be sent to the IESG.
 [Tim] glad to know. Thanks
2. This draft seems haven't consider conflicts between subscribers. E.g.  EA 
length conflict between subscribers with in one MAP domain? And EA length from 
radius conflict with BNG within same MAP domain?
As this draft enables the capability to maintain MAP rule logic in radius, 
conflict mechanisn should be investigated in my POV.

[Med] Which conflict mechanism do you have in mind?

I’m afraid this is deployment and implementation-specific. FWIW, the draft 
includes the following to warrant that some consistency checks is needed:

   In some deployments, the DHCP server may use the Accounting-Request
   to report to a AAA server the softwire configuration returned to a
   requesting host.  It is the responsibility of the DHCP server to
   ensure the consistency of the configuration provided to requesting
   hosts.
 [Tim] yes, it solves one of the scenario I mentioned.
I believe if dhcp server use access request to get s46 info from AAA, then AAA 
server is response to enrue the consistency I suppose. Am I right?

Appreciate your feedback.
Thanks in advance
Tim
On Mon, 11 Feb 2019, 08:26 
mailto:internet-dra...@ietf.org> wrote:

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   : RADIUS Attributes for Address plus Port (A+P) based 
Softwire Mechanisms
Authors : Sheng Jiang
  Yu Fu
  Bing Liu
  Peter Deacon
  Chongfeng Xie
  Tianxiang Li
  Mohamed Boucadair
Filename: draft-ietf-softwire-map-radius-19.txt
Pages   : 39
Date: 2019-02-11

Abstract:
   IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity
   services over IPv6 native networks during the IPv4/IPv6 co-existence
   period.  DHCPv6 options have been defined for configuring clients for
   Lightweight 4over6, Mapping of Address and Port with Encapsulation,
   and Mapping of Address and Port using Translation unicast softwire
   mechanisms, and also multicast softwires.  However, in many networks,
   configuration information is stored in an Authentication,
   Authorization, and Accounting server which utilizes the RADIUS
   protocol to provide centralized management for users.  When a new
   transition mechanism is developed, new RADIUS attributes need to be
   defined correspondingly.

   This document defines new RADIUS attributes to carry Address plus
   Port based softwire configuration parameters from an Authentication,
   Authorization, and Accounting server to a Broadband Network Gateway.
   Both unicast and multicast attributes are covered.


The IETF datatracker status page for this draft is:

Re: [Softwires] Mail regarding draft-ietf-softwire-map-radius

[mohamed.boucadair]

Chairs, 

I'm not aware of any IPR which applies directly to this document. 

Cheers,
Med

> -Message d'origine-
> De : Yong Cui [mailto:cuiy...@tsinghua.edu.cn]
> Envoyé : mercredi 20 février 2019 10:21
> À : draft-ietf-softwire-map-rad...@ietf.org
> Cc : Softwires-wg; Yong Cui; Ian Farrer
> Objet : Mail regarding draft-ietf-softwire-map-radius
> 
> Hi authors,
> 
> Before we submit this doc to IESG, we would like to ask the following
> two questions on this doc:
> 
> 1) Are you aware any IPR issues required for full conformance with the
> provisions of BCP 78 and BCP 79?
> 
> 2) Do you know any implementations?
> 
> Thanks,
> 
> Ian & Yong

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

Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

[mohamed.boucadair]

Hi Yu,

Please see inline.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Yu Tianpeng
Envoyé : lundi 11 février 2019 12:27
À : softwires@ietf.org
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Dear authors,
Thanks for the new version.
I had a quick read on latest version. I find some nits and also some questions 
along the way as we meet a scenario when deploying MAP that need s46 radius 
attributes.

Nits:
Section 7.1 should be referring section 3.x not 4.x
[Med] Thank you for catching the bug in Section 7.1.

Question:
1. How is the status of this document? This draft has last called long time 
ago, but still not standard yet. What is the reason? Any plans to move further? 
As I mentioned we meet requirement when deploying map, we may need to make a 
decision if we follow this draft or define a vendor specific one.

[Med] The document passed the WGLC + addressed the reviews from radext wg. We 
do think that the document is ready to be sent to the IESG.

2. This draft seems haven't consider conflicts between subscribers. E.g.  EA 
length conflict between subscribers with in one MAP domain? And EA length from 
radius conflict with BNG within same MAP domain?
As this draft enables the capability to maintain MAP rule logic in radius, 
conflict mechanisn should be investigated in my POV.

[Med] Which conflict mechanism do you have in mind?

I’m afraid this is deployment and implementation-specific. FWIW, the draft 
includes the following to warrant that some consistency checks is needed:

   In some deployments, the DHCP server may use the Accounting-Request
   to report to a AAA server the softwire configuration returned to a
   requesting host.  It is the responsibility of the DHCP server to
   ensure the consistency of the configuration provided to requesting
   hosts.


Appreciate your feedback.
Thanks in advance
Tim
On Mon, 11 Feb 2019, 08:26 
mailto:internet-dra...@ietf.org> wrote:

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   : RADIUS Attributes for Address plus Port (A+P) based 
Softwire Mechanisms
Authors : Sheng Jiang
  Yu Fu
  Bing Liu
  Peter Deacon
  Chongfeng Xie
  Tianxiang Li
  Mohamed Boucadair
Filename: draft-ietf-softwire-map-radius-19.txt
Pages   : 39
Date: 2019-02-11

Abstract:
   IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity
   services over IPv6 native networks during the IPv4/IPv6 co-existence
   period.  DHCPv6 options have been defined for configuring clients for
   Lightweight 4over6, Mapping of Address and Port with Encapsulation,
   and Mapping of Address and Port using Translation unicast softwire
   mechanisms, and also multicast softwires.  However, in many networks,
   configuration information is stored in an Authentication,
   Authorization, and Accounting server which utilizes the RADIUS
   protocol to provide centralized management for users.  When a new
   transition mechanism is developed, new RADIUS attributes need to be
   defined correspondingly.

   This document defines new RADIUS attributes to carry Address plus
   Port based softwire configuration parameters from an Authentication,
   Authorization, and Accounting server to a Broadband Network Gateway.
   Both unicast and multicast attributes are covered.


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

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

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


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

Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

[mohamed.boucadair]

Hi Shu, all,

Please see inline.

Cheers,
Med


De : Softwires [mailto:softwires-boun...@ietf.org] De la part de ??
Envoyé : dimanche 2 juin 2019 17:30
À : Benjamin Kaduk; The IESG
Cc : softwires; draft-ietf-softwire-mesh-multicast; softwire-chairs
Objet : Re: [Softwires] Benjamin Kaduk's No Objection on 
draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

Dear Benjamin,

Thank you for your helpful and detailed comments, we reply as following,




> Section 5.4



>To achieve this, every AFBR MUST announce the address of one of its

>E-IPv4 interfaces in the "v4" field alongside the corresponding

>uPreifx64.  The announcement MUST be sent to the other AFBRs through

>MBGP [RFC4760].  Every uPrefix46 that an AFBR announces MUST be

>unique.  "uPrefix46" is an IPv6 prefix, and the distribution

>mechanism is the same as the traditional mesh unicast scenario.



> I am not very familiar with this space, and just wanted to check that both

> "uPrefix46" and "uPrefix64" are defined things (as opposed to "uPrefix64"

> being a typo).



We have modified the typo.



[Med] Given that this document relies on RFC8114 to construct multicast 
prefixes (and other matters), I suggest to use the same terms as those defined 
in RFC8114:



   mPrefix64:  a dedicated multicast IPv6 prefix for constructing

  IPv4-embedded IPv6 multicast addresses. mPrefix64 can be of two

  types: ASM_mPrefix64 used in Any-Source Multicast (ASM) mode or

  SSM_mPrefix64 used in Source-Specific Multicast (SSM) mode

  [RFC4607].  The size of this prefix 
is /96.



 Note: "64" is used as an abbreviation for IPv6-IPv4

 interconnection.



   uPrefix64:  a dedicated IPv6 unicast prefix for constructing

  IPv4-embedded IPv6 unicast addresses 
[RFC6052].  This prefix may

  be either the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-

  Specific Prefix (NSP).





…



> Section 9



> "MUST [...] follow the requirements mentioned in

> [I-D.ietf-intarea-tunnels]" seems like it needs a normative reference.

> "MUST [...] allow the use of encapsulation mechanisms mentioned in

> [RFC4925]" would seem to do the same.



We change these references to be normative.



[Med] I’m not sure this is the right approach. Do you really need 
draft-ietf-intarea-tunnels? IMHO, that section can be replaced with a sentence 
pointing to rfc5565#section-8.






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

Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-map-radius-24: (with COMMENT)

[mohamed.boucadair]

Hi Ben, 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk [mailto:ka...@mit.edu]
> Envoyé : vendredi 14 juin 2019 01:58
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : The IESG; draft-ietf-softwire-map-rad...@ietf.org; Yong Cui; Ian
> Farrer; softwire-cha...@ietf.org; softwires@ietf.org
> Objet : Re: Benjamin Kaduk's No Objection on draft-ietf-softwire-map-
> radius-24: (with COMMENT)
> 
> On Thu, Jun 13, 2019 at 07:21:38AM +, mohamed.boucad...@orange.com
> wrote:
> > Re-,
> >
> > Thank you for the detailed review. Much appreciated, as usual!
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> > > Envoyé : jeudi 13 juin 2019 06:03
> > > À : The IESG
> > > Cc : draft-ietf-softwire-map-rad...@ietf.org; Yong Cui; Ian Farrer;
> > > softwire-cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> > > Objet : Benjamin Kaduk's No Objection on draft-ietf-softwire-map-
> radius-
> > > 24: (with COMMENT)
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-softwire-map-radius-24: No Objection
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut
> this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
> > >
> > >
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > It might be worth a brief note somewhere about why attributes of this
> > > sort can be included in Accounting-Request packets
> >
> > [Med] This is already covered by this text:
> >
> >In some deployments, the DHCP server may use the Accounting-Request
> >to report to a AAA server the softwire configuration returned to a
> >requesting host.  It is the responsibility of the DHCP server to
> >ensure the consistency of the configuration provided to requesting
> >hosts.  Reported data to a AAA server may be required for various
> >operational purposes (e.g., regulatory).
> 
> So it is; thanks for pointing it out.  (I guess I would have expected to
> see something earlier in the document, but this is up to your discretion.)
> 
> >
> >  (and, to a lesser
> > > extent, CoA-Request packets).
> 
> What about CoA-Request, though?
> 

[Med] Added this NEW text: 

 A configuration change (e.g., BR address) may result in an exchange
 of CoA-Requests between the BNG and the AAA server as shown in
 Figure 3.  Concretely, when the BNG receives a CoA-Request message
 containing Softwire46 attributes, it sends a DHCPv6 Reconfigure
 message to the appropriate CE to inform that CE that an updated
 configuration is available.  Upon receipt of such message, the CE
 sends a DHCPv6 Renew or Information-Request in order to receive the
 updated Softwire46 configuration.  In deployments where the BNG
 embeds a DHCPv6 relay, CoA-Requests can be used following the
 procedure specified in [RFC6977].

> > > Section 1
> > >
> > >Since IPv4-in-IPv6 softwire configuration information is stored in
> an
> > >AAA server, and user configuration information is mainly
> transmitted
> > >through DHCPv6 between the BNGs and Customer Premises Equipment
> (CEs,
> > >a.k.a., CPE), new RADIUS attributes are needed to propagate the
> > >information from the AAA servers to BNGs.
> > >
> > > nit: maybe "from the AAA servers to BNGs so that they can be
> propagated
> > > to CPE over the existing DHCPv6 options."?
> > >
> >
> > [Med] Updated as follows:
> >
> > "from the AAA servers to BNGs so that they can be provided to CEs using
> the existing DHCPv6 options."
> 
> Thanks
> 
> > > Section 2
> > >
> > > Please use the boilerplate text from RFC 8174 (including BCP 14
> > > mention).
> > >
> >
> > [Med] Added to BCP 14 mention.
> >
> > > Section 3.1
> > >
> > >   The Softwire46-Configuration Attribute conveys the configuration
> > >   information for MAP-E, MAP-T, or Lightweight 4over6.  The BNG
> > >   SHALL use the configuration information returned in the RADIUS
> > >   attribute to populate the DHCPv6 Softwire46 Container Option
> > >   defined in Section 5 of [RFC7598].
> > >
> > > nit: "Option(s)" seems more appropriate, since that section defines
> > > separate options for MAP-E and MAP-T.
> >
> > [Med] OK.
> >
> > >
> > > Section 3.1.1.1
> > >
> > > Just to double-check my understanding: since this is an "attribute",
> >
> > [Med] This is a sub-attribute that appears under Softwire46-
> Configuration. This is discussed in 

Re: [Softwires] Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

[mohamed.boucadair]

Hi Martin,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> [mailto:martin.vigour...@nokia.com]
> Envoyé : jeudi 13 juin 2019 09:44
> À : BOUCADAIR Mohamed TGI/OLN; The IESG
> Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire-
> cha...@ietf.org; softwires@ietf.org
> Objet : Re: Martin Vigoureux's No Objection on draft-ietf-softwire-
> iftunnel-06: (with COMMENT)
> 
> Hi Med,
> 
> please see inline
> 
> -m
> 
> Le 2019-06-12 à 7:31, mohamed.boucad...@orange.com a écrit :
> > Hi Martin,
> >
> > Thank you for the comment.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Martin Vigoureux via Datatracker [mailto:nore...@ietf.org]
> >> Envoyé : mardi 11 juin 2019 18:58
> >> À : The IESG
> >> Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire-
> >> cha...@ietf.org; cuiy...@tsinghua.edu.cn; softwires@ietf.org
> >> Objet : Martin Vigoureux's No Objection on draft-ietf-softwire-
> iftunnel-
> >> 06: (with COMMENT)
> >>
> >> Martin Vigoureux has entered the following ballot position for
> >> draft-ietf-softwire-iftunnel-06: No Objection
> >>
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut this
> >> introductory paragraph, however.)
> >>
> >>
> >> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> >>
> >>
> >>
> >> --
> >> COMMENT:
> >> --
> >>
> >> Hello,
> >>
> >> I am a bit puzzled because the Abstract recognizes that the document is
> >> built
> >> onto an incomplete data-set and that makes me wonder whether the model
> >> will be
> >> usable until the data-set is completed.
> >
> > [Med] The registry does not need to be comprehensive to be
> useful/usable. For example, this module is already used by a document
> which is in the RFC Editor queue: draft-ietf-softwire-yang.
> >
> >>
> >> Also, I really do not understand the update you propose to the
> registry.
> >> It
> >> seems that you point to the technology spec rather than to the original
> >> mib
> >> module definition, but I quickly looked and none of the specs I parsed
> >> define
> >> the mib entry/value
> >
> > [Med] This update was requested by the Designated Experts. They want the
> technology spec to be cited, not the RFC defining the MIB or YANG. Please
> note that registering a code does not require a MIB or a YANG.
> That is exactly my point.
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
> numbers-6
> is the MIB module registration so it should reference the RFCs which
> created the module and asked for the registration of the codes.

[Med] This is the kind of clarification in draft-thaler. The registry should 
not be understood as tied to MIBs. It isn't. 

 As an
> illustrative example, 7856 is the RFC which asked for the registration
> of softwireMesh(16). I couldn't find any such request in 5565. So I
> really don't think you should remove 7856 from the references, but it is
> definitly good to add 5565.
> After a quick glance, this seems to be the case for all changes you are
> proposing.

[Med] That is on purpose. The agreement we had with the Designed expert is: 
reference the documents that define the actual encapsulation, not the MIB 
module RFCs.

> 
> >
> > , so getting rid of the existing reference appears to
> >> me as
> >> a clear loss of information. I think you should keep the original
> >> reference and
> >> add a new one if needed, but not simply replace.
> >>
> >> And if you have undertaken this effort of tidying the registry, why not
> >> complete it with the missing values?
> >>
> >
> > [Med] We used to have this discussion as part of the tsv directorate
> review. We don't think it is the job of this document to register new
> tunnel techniques to an existing registry. Nevertheless, we tried to get
> in touch with the authors of draft-ietf-lisp-rfc6830bis, draft-ietf-nvo3-
> vxlan-gpe, draft-ietf-nvo3-geneve, and draft-ietf-intarea-gue to invite
> them to register their tunnel technology.
> >
> > The I-D is mirroring the content of an * existing * registry. The
> corresponding YANG module will be updated by IANA upon assignment of a new
> code.
> >
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Roman Danyliw's No Objection on draft-ietf-softwire-map-radius-24: (with COMMENT)

[mohamed.boucadair]

Hi Roman, 

Fixed those in my local copy. Thank you. 

Cheers,
Med

> -Message d'origine-
> De : Roman Danyliw via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 12 juin 2019 03:26
> À : The IESG
> Cc : draft-ietf-softwire-map-rad...@ietf.org; Yong Cui; Ian Farrer;
> softwire-cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Roman Danyliw's No Objection on draft-ietf-softwire-map-radius-24:
> (with COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-softwire-map-radius-24: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
> 
> 
> 
> --
> COMMENT:
> --
> 
> A few editorial nits:
> 
> -- Section 3.  Per “Depending on the deployment scenario …”, this sentence
> doesn’t parse for me.  I think s/so// would address it.
> 
> -- Section 3.1.4.2.  Typo.  s/pecifies/specifies/
> 

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

Re: [Softwires] Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

[mohamed.boucadair]

Hi Martin,

Thank you for the comment. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Martin Vigoureux via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mardi 11 juin 2019 18:58
> À : The IESG
> Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire-
> cha...@ietf.org; cuiy...@tsinghua.edu.cn; softwires@ietf.org
> Objet : Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-
> 06: (with COMMENT)
> 
> Martin Vigoureux has entered the following ballot position for
> draft-ietf-softwire-iftunnel-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hello,
> 
> I am a bit puzzled because the Abstract recognizes that the document is
> built
> onto an incomplete data-set and that makes me wonder whether the model
> will be
> usable until the data-set is completed.

[Med] The registry does not need to be comprehensive to be useful/usable. For 
example, this module is already used by a document which is in the RFC Editor 
queue: draft-ietf-softwire-yang. 

> 
> Also, I really do not understand the update you propose to the registry.
> It
> seems that you point to the technology spec rather than to the original
> mib
> module definition, but I quickly looked and none of the specs I parsed
> define
> the mib entry/value

[Med] This update was requested by the Designated Experts. They want the 
technology spec to be cited, not the RFC defining the MIB or YANG. Please note 
that registering a code does not require a MIB or a YANG. 

, so getting rid of the existing reference appears to
> me as
> a clear loss of information. I think you should keep the original
> reference and
> add a new one if needed, but not simply replace.
> 
> And if you have undertaken this effort of tidying the registry, why not
> complete it with the missing values?
> 

[Med] We used to have this discussion as part of the tsv directorate review. We 
don't think it is the job of this document to register new tunnel techniques to 
an existing registry. Nevertheless, we tried to get in touch with the authors 
of draft-ietf-lisp-rfc6830bis, draft-ietf-nvo3-vxlan-gpe, 
draft-ietf-nvo3-geneve, and draft-ietf-intarea-gue to invite them to register 
their tunnel technology. 

The I-D is mirroring the content of an * existing * registry. The corresponding 
YANG module will be updated by IANA upon assignment of a new code. 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Alexey Melnikov's No Objection on draft-ietf-softwire-map-radius-24: (with COMMENT)

[mohamed.boucadair]

Hi Alexey, 

Thank you for the comment. 

Softwire46-Configuration is designed to cover MAP-E, MAP-T, and lw4o6. So, only 
the attributes defined in this document are allowed to be included. 

That's said, there are some future extensions that we anticipate such as 
allowing new codes (e.g., NAT64 radius attribute if defined in future) to be 
returned in Softwire46-Priority. A registry is created to ease such future 
extension. 

Cheers,
Med

> -Message d'origine-
> De : Alexey Melnikov via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mardi 11 juin 2019 09:51
> À : The IESG
> Cc : draft-ietf-softwire-map-rad...@ietf.org; Yong Cui; Ian Farrer;
> softwire-cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Alexey Melnikov's No Objection on draft-ietf-softwire-map-radius-
> 24: (with COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-softwire-map-radius-24: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This is a fine document. I have one small question:
> 
> In 3.1:
> 
>   The Softwire46-Configuration Attribute MUST only encapsulate one
>   or more of the Softwire46 attributes defined in this document.
> 
> This reads to me that only attributes defined in this document can be
> encapsulated. Does this make this attribute deliberately non extensible?
> You
> have created various IANA registries, which makes me wonder whether this
> was
> intentional.
> 

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

Re: [Softwires] AD sponsoring draft-thaler-iftype-reg-02

[mohamed.boucadair]

Hi Suresh, all,

I fully support this effort.

I hope the authors can address two comments we received as part of 
draft-ietf-softwire-iftunnel that I do think belong to this I-D:

* Add a clear mention under 
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6 to 
indicate this is about "tunnelType Registry".

* Add some text to encourage UDP-based tunnel protocol designers to register 
their own code instead of reusing the one currently assigned to generic UDP 
encap (8).



Thank you.



Cheers,

Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Suresh Krishnan
Envoyé : mercredi 12 juin 2019 20:23
À : int-area; 6man; dhcwg; V6 Ops List; ops...@ietf.org; softwires@ietf.org
Objet : [Int-area] AD sponsoring draft-thaler-iftype-reg-02

Hi all,
  I would like to AD sponsor the following draft that provides guidelines for 
definition of new interface types in the IANA IfType registries

https://tools.ietf.org/html/draft-thaler-iftype-reg-02

If you have any concerns either with the contents of the draft, or about me AD 
sponsoring it please let me know before 2019/06/26.

Thanks
Suresh

NOTE: I have CCed: all the working groups that I thought could be potentially
interested in this work. If you think I have missed out some WG(s) please let
me know.
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-map-radius-24: (with COMMENT)

[mohamed.boucadair]

Re-,

Thank you for the detailed review. Much appreciated, as usual!

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> Envoyé : jeudi 13 juin 2019 06:03
> À : The IESG
> Cc : draft-ietf-softwire-map-rad...@ietf.org; Yong Cui; Ian Farrer;
> softwire-cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Benjamin Kaduk's No Objection on draft-ietf-softwire-map-radius-
> 24: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-softwire-map-radius-24: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
> 
> 
> 
> --
> COMMENT:
> --
> 
> It might be worth a brief note somewhere about why attributes of this
> sort can be included in Accounting-Request packets

[Med] This is already covered by this text: 

   In some deployments, the DHCP server may use the Accounting-Request
   to report to a AAA server the softwire configuration returned to a
   requesting host.  It is the responsibility of the DHCP server to
   ensure the consistency of the configuration provided to requesting
   hosts.  Reported data to a AAA server may be required for various
   operational purposes (e.g., regulatory).


 (and, to a lesser
> extent, CoA-Request packets).
> 
> Section 1
> 
>Since IPv4-in-IPv6 softwire configuration information is stored in an
>AAA server, and user configuration information is mainly transmitted
>through DHCPv6 between the BNGs and Customer Premises Equipment (CEs,
>a.k.a., CPE), new RADIUS attributes are needed to propagate the
>information from the AAA servers to BNGs.
> 
> nit: maybe "from the AAA servers to BNGs so that they can be propagated
> to CPE over the existing DHCPv6 options."?
> 

[Med] Updated as follows:

"from the AAA servers to BNGs so that they can be provided to CEs using the 
existing DHCPv6 options."

> Section 2
> 
> Please use the boilerplate text from RFC 8174 (including BCP 14
> mention).
> 

[Med] Added to BCP 14 mention. 

> Section 3.1
> 
>   The Softwire46-Configuration Attribute conveys the configuration
>   information for MAP-E, MAP-T, or Lightweight 4over6.  The BNG
>   SHALL use the configuration information returned in the RADIUS
>   attribute to populate the DHCPv6 Softwire46 Container Option
>   defined in Section 5 of [RFC7598].
> 
> nit: "Option(s)" seems more appropriate, since that section defines
> separate options for MAP-E and MAP-T.

[Med] OK.

> 
> Section 3.1.1.1
> 
> Just to double-check my understanding: since this is an "attribute",

[Med] This is a sub-attribute that appears under Softwire46-Configuration. This 
is discussed in the introduction text of Section 3.1.1.

> it's a top-level container with the 'type' value bearing universal
> semantics for all RADIUS packets, as opposed to a "tlv" that appears
> within a given attribute and whose 'type' values only have meaning in
> the context of that attribute?  But this interpretation doesn't hold up
> for (e.g.) Section 3.3.3, which defines an "attribute" but uses a
> "TLV-Type" that is in the range of values scoped only to the structures
> defined in this document.
> 
> Section 3.1.3.2
> 
>There MUST be at least one Softwire46-BR included in each
>Softwire46-MAP-E or Softwire46-Lightweight-4over6.
> 
> This seems to be in conflict with Table 2, which says that exactly one
> Softwire-BR is included in each MAP-E or Lightweight-4over6 attribute.

[Med] Good catch. Updated the table: s/1/1+.

> 
> Section 3.1.6.1
> 
>  This field that specifies the
>  numeric value for the Softwire46 algorithm's excluded
>  port range/offset bits (a bits), as per Section 5.1
>  of [RFC7597]. Allowed values are between 0 and 15.
> 
> nit: "This field that specifies" is redundant; just "This field
> specifies" would be  fine.

[Med] OK.

> 
> I'm also not sure I understand the range being between 0 and 15, when we
> previously talk about this being an 8-bit value ("right justified").

[Med] We used to have a 8-bit field that we then updated to 32-bit to be 
aligned with radext reco. Fixed.

> 
> Section 3.1.6.3
> 
> This format seems needlessly confusing.  We encode as an integer (32-bit
> unsigned), but then state that this 32-bit integer contains a 16-bit
> value, right justified.  And then we only interpret the f irst 'k' bits
> on the left of 

Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

[mohamed.boucadair]

Hi Ben, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 12 juin 2019 21:58
> À : The IESG
> Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire-
> cha...@ietf.org; cuiy...@tsinghua.edu.cn; softwires@ietf.org
> Objet : Benjamin Kaduk's No Objection on draft-ietf-softwire-iftunnel-06:
> (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-softwire-iftunnel-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I agree with Tom Petch that adding "tunnelType Registry" or "tunnelType
> Definitions" more prominently on the IANA website is advisable.

[Med] I agree but I didn't include any note into this I-D because this is the 
kind of clarification that is better covered in draft-thaler-iftype-reg (to be 
sponsored by Suresh).

> 
> On a more general note, it's pretty weird to me to go and create a

[Med] There is a disconnect here. This I-D is not creating a new registry, it 
is mirroring an existing one. 

> registry with a fairly long list of initial population but then claim
> that it is not intended to be complete and should be supplemented by
> additional registrations for existing protocols.  Either it should be
> complete, or we can just have a small sample of initial registrations to
> "get a feel" for what they look like and what needs to be included.
> Then, most registrations would be done as standalone registrations and
> it would not feel like the outliers were getting rejected.
> 
> Appendix A
> 
> The example module's namespace was not changed to reflect the move away
> from ietf-*.
> 

Med] Will be updated.

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

Re: [Softwires] Suresh Krishnan's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

[mohamed.boucadair]

Hi Suresh, 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Suresh Krishnan via Datatracker [mailto:nore...@ietf.org]
> Envoyé : jeudi 13 juin 2019 06:01
> À : The IESG
> Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire-
> cha...@ietf.org; cuiy...@tsinghua.edu.cn; softwires@ietf.org
> Objet : Suresh Krishnan's No Objection on draft-ietf-softwire-iftunnel-06:
> (with COMMENT)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-softwire-iftunnel-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I have a hard time seeing the need for a generic UDP tunnel type (8) and
> also
> specific instances of UDP tunneling such as Teredo (14). I think it is
> better
> to go one way or another but not do both to avoid any confusion.

[Med] These codes are already in the registry. This I-D is just echoing what is 
recorded in the current authoritative registry. 
If one of these codes is relaxed, the YANG module will be updated by IANA to 
reflect that. 

I do think that draft-thaler-iftype-reg is the right place to include a 
recommendation to encourage tunnel protocol designers to register their tunnel 
types rather than to reuse the generic UDP type. 

 In any
> case I
> think RFC8085 *should not* be the sole reference for UDP tunneling as it
> does
> not specify UDP tunneling but provides guidelines for designers of UDP
> based
> tunneling mechanisms.

[Med] That is the best reference we have for UDP. It is certainly better than 
4087. 

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

Re: [Softwires] Suresh Krishnan's Discuss on draft-ietf-softwire-map-radius-24: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Suresh Krishnan via Datatracker [mailto:nore...@ietf.org]
> Envoyé : jeudi 13 juin 2019 05:14
> À : The IESG
> Cc : draft-ietf-softwire-map-rad...@ietf.org; Yong Cui; Ian Farrer;
> softwire-cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Suresh Krishnan's Discuss on draft-ietf-softwire-map-radius-24:
> (with DISCUSS and COMMENT)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-softwire-map-radius-24: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I am really glad to see this document getting published. It has been a
> long
> while in the making.
> 
> This should be easy to clear but I would like to make sure that the
> calculation
> used here to determine TLV lengths is accurate.
> 
> * In Sections 3.1.3.3., 3.1.4.1., 3.1.4.2., 3.1.5.2, 3.3.3. the TLV-Length
> is
> shown to be 4+length of the contents of the TLV-Data (either the ipv6pref
> or
> the ipv4pref). Maybe I am missing something, but I think this should be
> 2+length of the contents of the TLV-Data instead.
> 
> Can you please clarify how you arrived at 4+x instead of 2+x?

[Med] 1 octet (TLV-Type) +  1 octet (TLV-Length) + 1 octet (Reserved) + 1 octet 
(Prefix Length) + Length of the prefix.   

I suspect you were confused with the prefix names provided in the tlv 
description. These should not be interpreted as referring to "Reserved+Prefix 
Length+Prefix", but to the prefix.

I reordered slightly the description text to avoid such confusion. 

> 
> 
> --
> COMMENT:
> --
> 
> * Section 3.1.3.3.
> 
> The datatype for Softwire46-DMR is misspelt.
> 
> OLD:
> The attribute Softwire46-DMR is of type ip6pref
> 
> NEW:
> The attribute Softwire46-DMR is of type ipv6pref

[Med] Fixed. Thank you. 

> 
> * Not a strong opinion but I think RFC7596, RFC7597 and RFC7599 should
> probably
> be normative instead of informative.

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

Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04

[mohamed.boucadair]

Re-,

I agree with you that many tunneling schemes are not present in the IANA 
registry but is that a problem? I don't think so because registrations are for 
a reason. 

The natural way from where I sit is that any specification that, for example, 
defines a specific YANG module for a tunneling scheme not currently in the IANA 
registry, and needs a specific interface type, will make a request for a code 
assignment.

FWIW, we are making this work because we had a concrete case 
(draft-ietf-softwire-yang) which needs to augment the YANG interface module for 
a specific tunnel scheme. To that aim, we requested IANA to assign a new type 
and designed this module to access to tunnel types maintained by IANA.

When a new registration is made, the module defined in 
draft-ietf-softwire-iftunnel will be updated automatically by IANA.  

I fail to see why the "best course of action" for this document is to register 
new types without defining the usage.  

Cheers,
Med

> -Message d'origine-
> De : Black, David [mailto:david.bl...@dell.com]
> Envoyé : jeudi 9 mai 2019 15:46
> À : BOUCADAIR Mohamed TGI/OLN; tsv-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> iftunnel@ietf.org; Black, David
> Objet : RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> > [Med] The intent of the draft is to reflect the current registered
> tunnels types.
> ...
> > [Med] Registering new tunnel types is not in the scope set for this
> draft.
> 
> I understand that, but as stated in the review, I don't think that it's
> the best course of action.  The email below appears to reject all of the
> IETF Last Call comments in the review and in particular presents the scope
> of the draft as fixed and unchangeable; that's unfortunate.  On that
> basis, I will agree to disagree and leave these IETF Last Call concerns to
> the ADs to sort out.
> 
> Thanks, --David
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > 
> > Sent: Thursday, May 9, 2019 3:50 AM
> > To: Black, David; tsv-...@ietf.org
> > Cc: softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> iftunnel@ietf.org
> > Subject: RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hi David,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : David Black via Datatracker [mailto:nore...@ietf.org]
> > > Envoyé : mercredi 8 mai 2019 00:46
> > > À : tsv-...@ietf.org
> > > Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> > > iftunnel@ietf.org
> > > Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> > >
> > > Reviewer: David Black
> > > Review result: Not Ready
> > >
> > > This document has been reviewed as part of the transport area review
> > team's
> > > ongoing effort to review key IETF documents. These comments were
> > written
> > > primarily for the transport area directors, but are copied to the
> document's
> > > authors and WG to allow them to address any issues raised and also to
> the
> > > IETF discussion list for information.
> > >
> > > When done at the time of IETF Last Call, the authors should consider
> this
> > > review as part of the last-call comments they receive. Please always
> CC
> > > tsv-...@ietf.org if you reply to or forward this review.
> > >
> > > This draft defines a YANG module for tunnel types based on the MIB-2
> > > tunnel type registry maintained by IANA.
> > >
> > > My fundamental concern with this draft is that the MIB-2 tunnel type
> > > registry is seriously incomplete and out of date, as there are a large
> > > number of tunnel types that aren't included in that registry, e.g.,
> IPsec
> > > tunnel-mode AMT tunneling.  In its current form, that registry does
> not
> > > appear to be a good starting point for specifying YANG management of
> > > tunnels.
> > >
> > > A limited justification that I could envision for defining this YANG
> module
> > > would be to use it for mechanical translations to YANG of existing
> MIBs
> > > that use MIB-2 tunnel types - if that's the justification, then it
> would need
> > > to be clearly stated in an applicability statement within this draft,
> >
> > [Med] The intent of the draft is to reflect the current registered
> tunnels
> > types. This is mentioned in the introduction:
> >
> >This document specifies the initial version of the iana-tunnel-type
> >^^
> >YANG module identifying tunnel interface types.  The module reflects
> >
> >IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  The latest
> >
> >revision of this module can be obtained from the IANA web site.
> >
> >  and the
> > > discussion of extension of this YANG module would need to be aligned
> > with
> > > that limited applicability.
> >

Re: [Softwires] intdir Telechat Review requested: draft-ietf-softwire-map-radius

[mohamed.boucadair]

Hi Bernie, 

Good catches and suggestions. Thank you. 

Fixed those (and other minor nits) in -23. FWIW, a diff is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-23 

Cheers,
Med 

> -Message d'origine-
> De : Bernie Volz (volz) [mailto:v...@cisco.com]
> Envoyé : mardi 14 mai 2019 03:21
> À : int-...@ietf.org; int-...@ietf.org; draft-ietf-softwire-map-
> rad...@ietf.org
> Cc : softwires@ietf.org
> Objet : RE: intdir Telechat Review requested: draft-ietf-softwire-map-
> radius
> 
> I am an assigned INT directorate reviewer for draft-ietf-softwire-map-
> radius-22. These comments were written primarily for the benefit of the
> Internet Area Directors. Document editors and shepherd(s) should treat
> these comments just like they would treat comments from any other IETF
> contributors and resolve them along with any other Last Call comments that
> have been received. For more details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
> 
> This draft looks pretty good but there are a few quickly fixed issues and
> a bunch of minor nits. But, otherwise the draft looks ready to move
> forward.
> 
> Issues:
> 
> Section 3.1.3.1
> 
> I think the following text is in error:
>Defining multiple TLV-types achieves the same design goals as the
>"Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598].  Using
>TLV-type set to 4 is equivalent to setting the F-flag in the
>OPTION_S46_RULE S46 Rule Flags field.
> It should say (s/ 4 / 5 /):
>Defining multiple TLV-types achieves the same design goals as the
>"Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598].  Using
>TLV-type set to 5 is equivalent to setting the F-flag in the
>OPTION_S46_RULE S46 Rule Flags field.
> (I assume that "setting the F-flag" means setting it to 1.)
> 
> I'm also not sure what the following means:
>5 Forwarding Permitted Mapping Rule (may be used for
>   forwarding. Can also be a Basic Mapping Rule)
> Shouldn't this just be:
>5 Forwarding Permitted Mapping Rule
> 
> FYI - The text in RFC7598 is:
>o  F-flag: 1-bit field that specifies whether the rule is to be used
>   for forwarding (FMR).  If set, this rule is used as an FMR; if not
>   set, this rule is a BMR only and MUST NOT be used for forwarding.
>   Note: A BMR can also be used as an FMR for forwarding if the
>   F-flag is set.  The BMR is determined by a longest-prefix match of
>   the Rule IPv6 prefix against the End-user IPv6 prefix(es).
> 
> Section 5:
> The "CoA-Request" message is not mentioned in this table, but was
> mentioned in 3.1:
>   The Softwire46-Configuration Attribute MAY appear in a CoA-Request
>   packet.
> It may also be appropriate to include a table number/title?
> 
> 
> Minor Nits:
> 
> Section 3.1:
>   s/ efer / refer /
> 
> Section 3.1.2:
>   Remove the 0+ definition under Table 2 as it is not used and
> therefore not needed.
> 
> Section 3.2:
>   s/ orderd / ordered /
>   s/ attribute include one or / attributes includes one or /
>   (use includes)
> 
> Section 3.3: Suggestion
>   It may be more consistent and shorter to combine "MAY appear", "MAY
> contain" rules? For example:
> 
>   The Softwire46-Multicast Attribute MAY appear in an Access-Request,
>   Access-Accept, CoA-Request, and Accounting-Request packet.
> 
>   The Softwire46-Multicast Attribute MAY contain ASM-Prefix64 (see
>   Section 3.3.1), SSM-Prefix64 (see Section 3.3.2), and U-Prefix64
> (see
>   Section 3.3.3) attributes.
> 
> Section 4:
>   In 4, s/Theses are/These are/
>   In 5, s/CE send a/CE sends a/
> 
> Appendix A.7:
>   The "TLV Field" column is a bit odd since these are really subfields
> from RFC8044.
>   So, rename "TLV Subfield"? And, the fields are "Prefix-Length" and
> "Prefix" from
>   the TLV attribute.
> 
> - Bernie
> 
> -Original Message-
> From: Éric Vyncke via Datatracker 
> Sent: Tuesday, April 23, 2019 1:20 PM
> To: Bernie Volz (volz) ; Carlos Bernardos
> 
> Subject: intdir Telechat Review requested: draft-ietf-softwire-map-radius
> 
> 
> Telechat review of: draft-ietf-softwire-map-radius (no specific version)
> Deadline: 2019-05-15
> Requested by: Éric Vyncke
> 
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-
> radius/reviewrequest/11924/login/
> 
> intdir Telechat Review requested: draft-ietf-softwire-map-radius
> 

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

Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04

[mohamed.boucadair]

Hi Eric, all,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
> Envoyé : vendredi 17 mai 2019 17:29
> À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> iftunnel@ietf.org; draft-thaler-iftype-reg.auth...@ietf.org
> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> Dan and David, I took the liberty to add you to the discussion as draft-
> thaler-iftype-reg could be a way forward.
> 
> David, thank you for your review and the raised point.
> 
> Tom, and Magnus, thank you as well for being part of the discussion.
> 
> David, I see your point about referring to an 'outdated hence invalid'
> reference. I think we all agree that we need to have a IANA registry of
> ifTypes per draft-thaler-iftype-reg.
> 
> Nevertheless, I do not want to delay this document until that registry is
> created by the IANA as at least one other document depends on this one.

[Med] draft-thaler-iftype-reg does not create any new registry.

> Furthermore, I am unsure about the will of Dave & Dan to push forward
> their I-D.
> 
> Med, can you have a -06 revision with:
> - clearer abstract (basically  copy & paste of the 1st paragraph of the
> introduction) with the specific limitations / restrictions pointed by the
> reviews (for example "... containing the limited and incomplete collection
> of IANA...")

[Med] I can update the abstract as follows: 

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

NEW:
   This document specifies the initial version of a YANG module
   containing a collection of IANA maintained YANG identities, used as
   interface types for tunnel interfaces.  The module reflects the
   "ifType definitions: tunnelType" registry maintained by IANA.  The
   latest revision of this module can be obtained from the IANA web
   site.

> - what about adding some text about "Upon the create of a IANA registry of
> ifType, then an update of this document will be required". Unsure whether
> it has ever been used in a RFC though.

[Med] I'm not sure about this one. As mentioned above, there is no current plan 
to create another yet iftype registry.

If the point is how the module will be updated if new entries are registered? 
Then, this is not a concern because the module is maintained by IANA; that is, 
any change to the register will be systematically reflected by IANA in the IANA 
module.

For example, registration requests for new tunnel types can made following the 
rules in draft-thaler-iftype-reg. Once granted, the iftunnel module be updated 
by IANA following the rules defined in draft-ietf-softwire-iftunnel. No RFC 
update is required. 

> 
> But, at least fix the abstract and be more restrictive on the 'value' of
> the current ifType MIB
> 
> Hope this will allow the document to progress
> 
> -éric
> 
> On 09/05/2019, 15:46, "Black, David"  wrote:
> 
> > [Med] The intent of the draft is to reflect the current registered
> tunnels types.
> ...
> > [Med] Registering new tunnel types is not in the scope set for this
> draft.
> 
> I understand that, but as stated in the review, I don't think that
> it's the best course of action.  The email below appears to reject all of
> the IETF Last Call comments in the review and in particular presents the
> scope of the draft as fixed and unchangeable; that's unfortunate.  On that
> basis, I will agree to disagree and leave these IETF Last Call concerns to
> the ADs to sort out.
> 
> Thanks, --David
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > 
> > Sent: Thursday, May 9, 2019 3:50 AM
> > To: Black, David; tsv-...@ietf.org
> > Cc: softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> iftunnel@ietf.org
> > Subject: RE: Tsvart last call review of draft-ietf-softwire-
> iftunnel-04
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hi David,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : David Black via Datatracker [mailto:nore...@ietf.org]
> > > Envoyé : mercredi 8 mai 2019 00:46
> > > À : tsv-...@ietf.org
> > > Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> > > iftunnel@ietf.org
> > > Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> > >
> > > Reviewer: David Black
> > > Review result: Not Ready
> > >
> > > This document has been reviewed as part of the transport area
> review
> > team's
> > > ongoing effort to review key IETF documents. These comments were
> > written
> > > primarily for the transport area directors, but are copied to the
> document's
> > > authors and WG to allow 

Re: [Softwires] Genart last call review of draft-ietf-softwire-map-radius-23

[mohamed.boucadair]

Hi Joel, 

Good points. 

All your technical comments were implemented in my local copy. You may track 
the changes at: 
https://github.com/boucadair/draft-ietf-softwire-map-radius/blob/master/wdiff%20draft-ietf-softwire-map-radius-23.txt%20draft-ietf-softwire-map-radius-23.pdf
 

Thank you for the review.

Cheers,
Med

> -Message d'origine-
> De : Joel Halpern via Datatracker [mailto:nore...@ietf.org]
> Envoyé : samedi 18 mai 2019 01:10
> À : gen-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-map-
> radius@ietf.org
> Objet : Genart last call review of draft-ietf-softwire-map-radius-23
> 
> Reviewer: Joel Halpern
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-softwire-map-radius-??
> Reviewer: Joel Halpern
> Review Date: 2019-05-17
> IETF LC End Date: 2019-05-31
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Major issues:
> Figure 1 of section 3.1.1 and section 3.1.1.3 do not match.   It
> appears
> from later text that the problem is simple.  Figure 3.1.1 needs to
> include,
> in the portion for the Softwire46-Lightweight-4over6 Attribute, the
> fact
> that the Softwire46-BR attribute is permitted there.  Particularly
> since it
> is required. Section 3.1.4.1 states that the IPv6 prefix is 128 bits.
> It
> also points to RFC 8044 section 3.10.  Section 3.10 is quite clear
> that in
> order to include the prefix length, the TLV may be longer that 128
> bits.
> (Section 3.1.5.2 correctly uses the ipv6pref type.) Thus, it also
> appears
> that the stated TLV length is wrong.
>  Section 3.1.4.2 states that the IPv4 prefix is 32 bits.  It also
> points to
>  RFC 8044 section 3.11.  Section 3.11 states that the TLV is 48 bits.
>  Thus, it also appears that the stated TLV length is wrong.
> 
> Minor issues:
> I trust that the WG Chairs and document shepherd will work with the
> authors
> to reduce the number of front page authors?  I looked in the shepherd
> writeup to see if there was an explanation of the large number of
> authors,
> but did not see one.
> 
> Section 3.1 states that the Softwire46-Configuration Attribute may
> appear
> in an Access Request message.  Unlike the later material on multicast,
> there is no further explanation here of why it might appear, and how
> it
> should be processed if it does appear.  It would seem sensible to
> include
> this material.
> 
> Nits/editorial comments:
> In the description of the entries in table 2 (in section 3.1.2) should
> the
> entry for "1" read "1 Mandatory, may occur only once" rather than
> simply
> "Mandatory"?
> 

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

Re: [Softwires] [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04

[mohamed.boucadair]

Hi Magnus,

The context and the need for draft-ietf-softwire-iftunnel are indicated in the 
write-up:

"During the publication process and IANA review of draft-ietf-
softwire-yang (which has been approved by IESG recently), IANA 
requested that the YANG module for the iana-iftunnel registry
was put into a separate document from softwire-yang.
draft-ietf-softwire-iftunnel was published containing just 
the module."

draft-ietf-softwire-yang is in the RFC editor queue with a normative dependency 
on draft-ietf-softwire-iftunnel.

Below some excerpts from the I-D to answer your other questions:

Scope: 
   == 
   This document specifies the initial version of the iana-tunnel-type
   YANG module containing a collection of IANA maintained YANG
   identities identifying tunnel interface types.  The module reflects
   IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  

  Tunnel type values must not be directly added to the iana-tunnel-
  type YANG module.  They must instead be respectively added to the
  "tunnelType" sub-registry (under the "ifType definitions"
  registry).

  When this registry is modified, the YANG module iana-tunnel-type
  must be updated as defined in RFC.
   ==

Out of Scope:
   ==
   It is not the intention of this document to
   define tunnel-specific extensions for every tunnel encapsulation
   technology; those are discussed in dedicated documents such as
   [I-D.ietf-softwire-yang].  Likewise, it is out of the scope of this
   document to update the existing IANA registry   
   [TUNNELTYPE-IANA-REGISTRY] with a comprehensive list of tunnel
   technologies.
   ==

How it can be used? 
   ==
   Tunnel-specific extensions may be added to the Interface module
   [RFC8343] as a function of the tunnel type.  An example of this is
   provided in Appendix A.
   ==

   e.g., if I want to define a GRE YANG module, I need to import the module 
defined in draft-ietf-softwire-iftunnel:  

 import iana-tunnel-type  {
   prefix iana-tunnel-type;
 }

   And then indicate the following to augment the Interface module with GRE 
specifics: 

 augment "/if:interfaces/if:interface" {
   when "derived-from(if:type, 'iana-tunnel-type:gre')";

Cheers,
Med

> -Message d'origine-
> De : Magnus Westerlund [mailto:magnus.westerl...@ericsson.com]
> Envoyé : vendredi 10 mai 2019 09:53
> À : BOUCADAIR Mohamed TGI/OLN; tom petch; Black, David; tsv-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> iftunnel@ietf.org
> Objet : Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-
> iftunnel-04
> 
> Hi,
> 
> Based on Tom's comment about the issues or discrepancies in purpose, I
> would like to request that the purpose of the iftunnel document is made
> clear at least in a email response. As not being active and being thrown
> under the bus of having to do an IESG review of this document it would
> be really good if you could provide some summary of the context and the
> need for this particular document. Especially in light of how it uses
> the IANA registry.
> 
> Thanks
> 
> Magnus Westerlund
> 
> 
> On 2019-05-10 08:20, mohamed.boucad...@orange.com wrote:
> > Hi Tom,
> >
> > Thanks for sharing your thoughts.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : tom petch [mailto:daedu...@btconnect.com]
> >> Envoyé : jeudi 9 mai 2019 18:13
> >> À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-...@ietf.org
> >> Cc : softwires@ietf.org; Black, David; i...@ietf.org; draft-ietf-
> softwire-
> >> iftunnel@ietf.org
> >> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >>
> >> - Original Message -
> >> From: "Black, David" 
> >> Sent: Thursday, May 09, 2019 2:45 PM
> >>
>  [Med] The intent of the draft is to reflect the current registered
> >> tunnels types.
> >>> ...
>  [Med] Registering new tunnel types is not in the scope set for this
> >> draft.
> >>> I understand that, but as stated in the review, I don't think that
> >> it's the best course of action.  The email below appears to reject all
> >> of the IETF Last Call comments in the review and in particular presents
> >> the scope of the draft as fixed and unchangeable; that's unfortunate.
> >> On that basis, I will agree to disagree and leave these IETF Last Call
> >> concerns to the ADs to sort out.
> >> David
> >>
> >> I think that the concerns that you raise need addressing.
> > [Med] It is an easy fix to update the draft with a table asking codes
> for the following example list:
> >
> >o  CAPWAP [RFC5415]
> >o  AMT [RFC7450]
> >o  TCP Encapsulation of IKE and IPsec Packets [RFC8229]
> >o  NSH [RFC8300]
> >o  VXLAN [RFC7348]
> >o  LISP [RFC6830bis]
> >o  VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe]
> >o  Geneve [I-D.ietf-nvo3-geneve]
> >o  GUE [I-D.ietf-intarea-gue]
> >
> > but I'm struggling with the rationale for doing this 

Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04

[mohamed.boucadair]

Hi Tom,

Thanks for sharing your thoughts. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : tom petch [mailto:daedu...@btconnect.com]
> Envoyé : jeudi 9 mai 2019 18:13
> À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-...@ietf.org
> Cc : softwires@ietf.org; Black, David; i...@ietf.org; draft-ietf-softwire-
> iftunnel@ietf.org
> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> - Original Message -
> From: "Black, David" 
> Sent: Thursday, May 09, 2019 2:45 PM
> 
> > > [Med] The intent of the draft is to reflect the current registered
> tunnels types.
> > ...
> > > [Med] Registering new tunnel types is not in the scope set for this
> draft.
> >
> > I understand that, but as stated in the review, I don't think that
> it's the best course of action.  The email below appears to reject all
> of the IETF Last Call comments in the review and in particular presents
> the scope of the draft as fixed and unchangeable; that's unfortunate.
> On that basis, I will agree to disagree and leave these IETF Last Call
> concerns to the ADs to sort out.
> >
> 
> David
> 
> I think that the concerns that you raise need addressing.  

[Med] It is an easy fix to update the draft with a table asking codes for the 
following example list:

   o  CAPWAP [RFC5415]
   o  AMT [RFC7450]
   o  TCP Encapsulation of IKE and IPsec Packets [RFC8229]
   o  NSH [RFC8300]
   o  VXLAN [RFC7348]
   o  LISP [RFC6830bis]
   o  VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe]
   o  Geneve [I-D.ietf-nvo3-geneve]
   o  GUE [I-D.ietf-intarea-gue]

but I'm struggling with the rationale for doing this in 
draft-ietf-softwire-iftunnel. 

Can you please help me understand the following:

* Why such request wasn't made earlier for the following? 

   o  CAPWAP [RFC5415]
   o  AMT [RFC7450]
   o  TCP Encapsulation of IKE and IPsec Packets [RFC8229]
   o  NSH [RFC8300]
   o  VXLAN [RFC7348]

* Why working in progress specifications can't make this request directly to 
IANA if such code is needed? 

   o  LISP [RFC6830bis]
   o  VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe]
   o  Geneve [I-D.ietf-nvo3-geneve]
   o  GUE [I-D.ietf-intarea-gue]

* What is the point in having a codepoint but no actual usage is defined for 
it?  


I also think
> that there is another consideration that might be of greater impact.
> 
> The definition of interface types has long been an IANA registry which
> has been incorporated into MIB modules and, latterly, YANG modules.
> Recently, there has been an I-D
> Guidelines and Registration Procedures for Interface Types
> with Authors : David Thaler   Dan Romascanu
> which, if I read it aright, is saying that the process has gone off the
> rails and that the IANA registry should be of Interface Types and
> nothing to do with MIB modules or YANG modules, although the YANG and
> MIB modules will most likely be derived from it.  I see it as a question
> of who owns the registry, and that it should be those concerned with
> interfaces and their specification and that those concerned with OAM
> should take second place to that.
> 
> If that logic is correct, then I would apply it to tunnels, that the
> registration of tunnels belongs to those concerned with tunnels,
> int-area perhaps, where I see drafts on tunnels being discussed, with
> those concerned with OAM building on that work but not being the
> drivers, controllers, thereof.
> 
> Tom Petch
> 
> > Thanks, --David
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: Thursday, May 9, 2019 3:50 AM
> > > To: Black, David; tsv-...@ietf.org
> > > Cc: softwires@ietf.org; i...@ietf.org;
> draft-ietf-softwire-iftunnel@ietf.org
> > > Subject: RE: Tsvart last call review of
> draft-ietf-softwire-iftunnel-04
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hi David,
> > >
> > > Thank you for the review.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : David Black via Datatracker [mailto:nore...@ietf.org]
> > > > Envoyé : mercredi 8 mai 2019 00:46
> > > > À : tsv-...@ietf.org
> > > > Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
> > > > iftunnel@ietf.org
> > > > Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> > > >
> > > > Reviewer: David Black
> > > > Review result: Not Ready
> > > >
> > > > This document has been reviewed as part of the transport area
> review
> > > team's
> > > > ongoing effort to review key IETF documents. These comments were
> > > written
> > > > primarily for the transport area directors, but are copied to the
> document's
> > > > authors and WG to allow them to address any issues raised and also
> to the
> > > > IETF discussion list for information.
> > > >
> > > > When done at the time of IETF Last Call, the authors should
> consider this
> > > > review as part of the last-call comments they receive. Please
> always CC
> > > > tsv-...@ietf.org if you reply to or forward this 

Re: [Softwires] [Int-area] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

[mohamed.boucadair]

Hi all,

I agree with Ian.

Actually, the document should use a similar wording in both the section 
mentioned in the errata report and the one in of 6.3. I’m afraid editorial 
changes are also needed for 6.3 to avoid any confusion.


(1) 5.3:

OLD:

   However, as not all service providers will be able to increase their

   link MTU, the B4 element MUST perform fragmentation and reassembly if

   the outgoing link MTU cannot accommodate the extra IPv6 header.  The

   original IPv4 packet is not oversized.  The packet is oversized after

   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be

   fragmented.  Fragmentation MUST happen after the encapsulation of the

  ^^

   IPv6 packet.  Reassembly MUST happen before the decapsulation of the

   ^^

   IPv4 packet.  A detailed procedure has been specified in [RFC2473]

   

   Section 7.2.

NEW:

   However, as not all service providers will be able to increase their

   link MTU, the B4 element MUST perform fragmentation and reassembly if

   the outgoing link MTU cannot accommodate the extra IPv6 header.  The

   original IPv4 packet is not oversized.  The packet is oversized after

   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be

   fragmented.  Fragmentation MUST happen after the IPv6 encapsulation.



   Reassembly MUST happen before the decapsulation of the

   of the IPv6 header.  A detailed procedure has been specified in [RFC2473]

   ^^

   Section 7.2.


(2) 6.3



OLD:

   As noted previously, fragmentation and reassembly need to be taken

   care of by the tunnel endpoints.  As such, the AFTR MUST perform

   fragmentation and reassembly if the underlying link MTU cannot

   accommodate the encapsulation overhead.  Fragmentation MUST happen

   after the encapsulation on the IPv6 packet.  Reassembly MUST happen

   ^^

   before the decapsulation of the IPv6 header.  A detailed procedure

   has been specified in [RFC2473] Section 
7.2.

NEW:

   As noted previously, fragmentation and reassembly need to be taken

   care of by the tunnel endpoints.  As such, the AFTR MUST perform

   fragmentation and reassembly if the underlying link MTU cannot

   accommodate the encapsulation overhead.  Fragmentation MUST happen

   after the IPv6 encapsulation.  Reassembly MUST happen^

 

   before the decapsulation of the IPv6 header.  A detailed procedure

   has been specified in [RFC2473] Section 
7.2.

Cheers,
Med


De : Int-area [mailto:int-area-boun...@ietf.org] De la part de ianfar...@gmx.com
Envoyé : lundi 10 mai 2021 16:40
À : Eric Vyncke (evyncke) 
Cc : softwires@ietf.org; int-a...@ietf.org
Objet : Re: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite 
Broadband Deployments Following IPv4 Exhaustion"

Hi Éric,

My reading of the current RFC6333 text is that it is trying to highlight the 
importance of not fragmenting the IPv4 packet before encapsulation as this will 
break things. This, combined with ‘… after the encapsulation of the IPv6 
packet.’ which should certainly be ‘… of the IPv4 packet.’ Is where the 
confusion is from.

So, as a minimum, the errata is correct regarding the encapsulated IP version.

Beyond that, I don’t find the remaining text to conflict with RFC2743 section 
7.2. The text is only covering how to deal with packets that you will 
encapsulate and forward (DF=0) - case (b) in the RFC2473 text. Case (a) - DF=1 
for received packet, so drop and send ICMP error isn’t discussed as these 
packets will not be encapsulated and need to be fragmented.

I do agree that this is open to misreading. How about the following wording to 
preserve (what I think is) the authors intention:

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  For packets forwarded by the B4 element, fragmentation
  MUST happen after the encapsulation of the IPv4 packet.  Reassembly
MUST happen before the decapsulation of the IPv4 packet.  A detailed
procedure has been specified in [RFC2473]
   Section 7.2.


From Mikael’s comment:
"RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or 
drop+send ICMP error."

I can’t find anything in the Section 7.2 text that would result in inner 
fragmentation.

Thanks,
Ian


_

Ce message et ses