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 

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [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] 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] 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] 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,

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] 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,

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] I-D Action: draft-ietf-softwire-iftunnel-02.txt

[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

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] Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Hi Ben, 

Great!

I added this NEW text to cover your DDoS comment:

   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.

Thank you for the review. 

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk [mailto:ka...@mit.edu]
> Envoyé : jeudi 10 janvier 2019 20:07
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : The IESG; draft-ietf-softwire-y...@ietf.org; Sheng Jiang; softwire-
> cha...@ietf.org; softwires@ietf.org
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with
> DISCUSS and COMMENT)
> 
> Hi Med,
> 
> On Thu, Jan 10, 2019 at 02:08:02PM +, mohamed.boucad...@orange.com wrote:
> > Hi Benjamin,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Benjamin Kaduk [mailto:ka...@mit.edu]
> > > Envoyé : mardi 8 janvier 2019 20:38
> > > À : The IESG
> > > Cc : draft-ietf-softwire-y...@ietf.org; Sheng Jiang; softwire-
> > > cha...@ietf.org; jiangsh...@huawei.com; softwires@ietf.org
> > > Objet : Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with
> > > DISCUSS and COMMENT)
> > >
> > > Benjamin Kaduk 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:
> > > --
> > >
> > > 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.
> > >
> >
> > [Med] Will leave this one to our AD.
> 
> And he has done a fine job with it!
> 
> >
> > > 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.
> > >
> >
> > [Med] Thank you for catching this one.
> >
> > There is a copy/paste bug:
> >
> > OLD:
> >
> > container binding-table-versioning {
> >   description
> > "binding table's version";
> >   leaf version {
> > type uint64;
> > description
> >   "Timestamp when the binding table was activated.
> >
> >A binding instance may be provided with binding
> >entries that may change in time (e.g., increase
> >the size of the port set). When an abuse party
> >presents an external IP address/port, the version
> >of the binding table is important because, depending
> >on the version, a distinct customer may be
> >identified.
> >
> >The timestamp is used as a key to find the
> >appropriate binding table that was put into effect
> >when an abuse occurred. ";
> >   }
> >   leaf date {
> > type yang:date-and-time;
> > description
> >   "Timestamp of the binding table";
> > reference
> >   "RFC7422: Deterministic Address Mapping to Reduce
> > Logging in Carrier-Grade NAT Deployments";
> >   }
> > }
> >
> >
> > NEW:
> >
> > container binding-table-versioning {
> >   description
> > "binding table's version";
> >   leaf version {
> > type uint64;
> > description
> >   "A version number for the binding table.";
> >   }
> >   leaf date {
> > type yang:date-and-time;
> > description
> >   "Timestamp when the binding table was activated.
> >
> >A binding instance 

Re: [Softwires] Ignas Bagdonas' No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

[mohamed.boucadair]

Ignas,

Because these counters are applicable to some interface/tunnel schemes, the 
augment must be anyway subject to a "when derived-from()" clause (as a function 
of the tunnel type).   

The counters are designed so that other modules can reuse them, if needed. This 
can be done by using this statement:  

uses softwire-common:traffic-stat;

Cheers,
Med

> -Message d'origine-
> De : Ignas Bagdonas [mailto:ibagd...@gmail.com]
> Envoyé : jeudi 10 janvier 2019 15:36
> À : The IESG
> Cc : draft-ietf-softwire-y...@ietf.org; Sheng Jiang; softwire-
> cha...@ietf.org; jiangsh...@huawei.com; softwires@ietf.org
> Objet : Ignas Bagdonas' No Objection on draft-ietf-softwire-yang-14: (with
> COMMENT)
> 
> Ignas Bagdonas has entered the following ballot position for
> draft-ietf-softwire-yang-14: 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-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Is the derived-from() complexity for statistics counters really required
> given
> that the module itself is for softwires, and any tunnel using it would be
> covered?
> 

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

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

[mohamed.boucadair]

Hi Suresh, 

We didn't consider 8026-like prioritization at the CE because that feature is 
not specific to A+P but applies to a bunch of IPv4 service continuity 
mechanisms including DS-Lite and 464xlat. That feature has to be defined, if 
needed, in a separate module. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Suresh
> Krishnan
> Envoyé : jeudi 10 janvier 2019 15:05
> À : The IESG
> Cc : softwires@ietf.org; softwire-cha...@ietf.org; draft-ietf-softwire-
> y...@ietf.org
> Objet : [Softwires] Suresh Krishnan's No Objection on draft-ietf-softwire-
> yang-14: (with COMMENT)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-softwire-yang-14: 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-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I would have thought putting in a prioritization mechanism (like RFC8026
> does)
> for ordering the different mechanisms would have been useful in this YANG
> module in order to configure the CE. Was this something that was considered?
> 
> 
> ___
> 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 Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Hi Benjamin, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk [mailto:ka...@mit.edu]
> Envoyé : mardi 8 janvier 2019 20:38
> À : The IESG
> Cc : draft-ietf-softwire-y...@ietf.org; Sheng Jiang; softwire-
> cha...@ietf.org; jiangsh...@huawei.com; softwires@ietf.org
> Objet : Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with
> DISCUSS and COMMENT)
> 
> Benjamin Kaduk 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:
> --
> 
> 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.
> 

[Med] Will leave this one to our AD. 


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

[Med] Thank you for catching this one. 

There is a copy/paste bug: 

OLD: 

container binding-table-versioning {
  description
"binding table's version";
  leaf version {
type uint64;
description
  "Timestamp when the binding table was activated.

   A binding instance may be provided with binding
   entries that may change in time (e.g., increase
   the size of the port set). When an abuse party
   presents an external IP address/port, the version
   of the binding table is important because, depending
   on the version, a distinct customer may be
   identified.

   The timestamp is used as a key to find the
   appropriate binding table that was put into effect
   when an abuse occurred. ";
  }
  leaf date {
type yang:date-and-time;
description
  "Timestamp of the binding table";
reference
  "RFC7422: Deterministic Address Mapping to Reduce
Logging in Carrier-Grade NAT Deployments";
  }
}


NEW:

container binding-table-versioning {
  description
"binding table's version";
  leaf version {
type uint64;
description
  "A version number for the binding table.";
  }
  leaf date {
type yang:date-and-time;
description
  "Timestamp when the binding table was activated.

   A binding instance may be provided with binding
   entries that may change in time (e.g., increase
   the size of the port set). When an abuse party
   presents an external IP address/port, the version
   of the binding table is important because, depending
   on the version, a distinct customer may be
   identified.

   The timestamp is used as a key to find the
   appropriate binding table that was put into effect
   when an abuse occurred. ";
reference
  "RFC7422: Deterministic Address Mapping to Reduce
Logging in Carrier-Grade NAT Deployments";
  }
}

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

[Med] Some of these counters may be applicable to some other tunneling 
techniques, but not all of them. As such, these counters cannot be 

Re: [Softwires] WGLC for draft-ietf-softwire-iftunnel-01

[mohamed.boucadair]

Hi all,

-02 will also implement a change requested by the smi expert to cite the RFCs 
defining the tunneling techniques instead of pointing to 4087. An action will 
be requested to IANA to update the table available at 
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de 
ianfar...@gmx.com
Envoyé : jeudi 10 janvier 2019 09:14
À : Yong Cui
Cc : Softwires-wg
Objet : Re: [Softwires] WGLC for draft-ietf-softwire-iftunnel-01

Hi Yong,

Further to my previous email.

During the review of draft-ietf-softwire-yang, there is a comment about 
following the published format for the Security Considerations section of a 
document containing a YANG module. I wasn’t previously aware of this:

https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

As this comment will also be applicable to draft-ietf-softwire-iftunnel, I 
think we need to rewrite the Security Considerations section accordingly.

Thanks,
Ian


On 8. Jan 2019, at 17:48, ianfar...@gmx.com wrote:

HI Yong,

Sorry for the late response. I’m still catching up after the holidays…

As a co-author, I support this document progressing. As you mention below, 
separating out the iftunnels module from draft-ietf-softwire-yang into a new 
draft was requested during the IANA review.  meaning that 
draft-ietf-softwire-yang (currently with the IESG) now has a normative 
reference to this draft.

Regarding the draft itself, the iftunnel module itself has already been through 
the final WGLC for draft-ietf-softwire-yang. As it models the IANA tunnelType 
Definitions registry 
(https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6), 
we’ve tried to keep the format in line with other, similar documents with YANG 
modules for other IANA registries (e.g. RFC7224).

Thanks,
Ian


On 19. Dec 2018, at 08:26, Yong Cui 
mailto:cuiy...@tsinghua.edu.cn>> wrote:

Dear all,

There were the following progress on Softwire YANG and related work during the 
past couple of months:
  • draft-ietf-softwire-yang completed WGLC
  • During expert review, a YANG module for the iana-iftunnel registry 
was requested as the softwire module needs to reference it.
  • draft-ietf-softwire-yang was updated to include this module and 
Sheng ran a WGLC on the new content. This passed without comment.
  • During IANA review, it was requested that the iana-iftunnel YANG 
module was put into a separate document.
  • draft-ietf-softwire-yang was updated, removing the iana-iftunnel 
YANG module, and draft-ietf-softwire-iftunnel was published containing just the 
module (it was posted as a WG doc as the content etc. is already under the 
scope of draft-ietf-softwire-yang)

So now, we’d like to issue a WGLC for draft-ietf-softwire-iftunnel-01.
https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/

Considering the coming Christmas and New Year, I would extend the WGLC to 3 
weeks, i.e. Dec. 19, 2018 - Jan. 9, 2019. Please send your comments to our 
softwire mailing list, including your support or concerns.


Merry Christmas and Happy New Year!

Yong & Ian

___
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] Yangdoctors last call review of draft-ietf-softwire-yang-06

[mohamed.boucadair]

Hi Martin,

FWIW, a new revision which implements the last edits we discussed is available 
online: https://tools.ietf.org/html/draft-ietf-softwire-yang-12. Also, this 
version fixes the "id" thing. 

Cheers,
Med

> -Message d'origine-
> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
> Envoyé : mercredi 24 octobre 2018 08:51
> À : Martin Bjorklund
> Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> yang@ietf.org; i...@ietf.org
> Objet : RE: Yangdoctors last call review of draft-ietf-softwire-yang-06
> 
> Hi Martin,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Bjorklund [mailto:m...@tail-f.com]
> > Envoyé : mercredi 24 octobre 2018 08:32
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> > yang@ietf.org; i...@ietf.org
> > Objet : Re: Yangdoctors last call review of draft-ietf-softwire-yang-06
> >
> > Hi,
> >
> >  wrote:
> > > Re-,
> > >
> > > Fixed the first two ones in my local copy.
> > >
> > > id is optional. I'm maintaining it because it is already used by some
> > > implementations.
> >
> > Ok, but these implementations propably need to change anyway since the
> > "id" is no longer the key.
> 
> [Med] Yes.
> 
> >
> > I will just point out that having one key and another integer based
> > identifier that doesn't serve any purpose looks a bit odd.  But if the
> > WG thinks that it is needed then that's fine (although in this case I
> > suggest you add some text to the descriptions of these leafs that
> > explain what the purpose is).
> >
> >
> > I had a closer look at the iana-tunnel-type module and the
> > instructions to IANA, and I think that you could make some minor
> > clarificiations:
> >
> > In the module description, you have:
> >
> > This module contains a collection of YANG data types defined
> > by IANA and used for tunnel types.
> >
> > perhaps write:
> >
> > This module contains a collection of YANG identities defined
> > by IANA and used as interface types for tunnel interfaces.
> >
> 
> [Med] Works for me.
> 
> > And in the IANA Considerations section you have:
> >
> >
> >"base":Contains the value of the tunnel type in lowercase.
> >
> > maybe instead
> >
> >"base":Contains the string "ift:tunnel".
> >
> >
> >
> 
> [Med] That text is referring to the table in
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6.
> 
> We can change the text for better clarity to:
> 
> "base":Contains the name assigned to the tunnel type, in lowercase.
> 
> >
> > /martin
> >
> >
> >
> > >
> > > Thank you again for the review. Much appreciated!
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Martin Bjorklund [mailto:m...@tail-f.com]
> > > > Envoyé : mardi 23 octobre 2018 15:30
> > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> > > > yang@ietf.org; i...@ietf.org
> > > > Objet : Re: Yangdoctors last call review of
> > > > draft-ietf-softwire-yang-06
> > > >
> > > > Hi,
> > > >
> > > > Thanks for the quick update!
> > > >
> > > > I have looked at -11, and have just a few minor comments.
> > > >
> > > > o  Section 5.1
> > > >
> > > >   Maybe the tree diagram needs to be re-generated; at least:
> > > >
> > > >| +--rw bind-instance* [id]
> > > >
> > > >   should be
> > > >
> > > >| +--rw bind-instance* [name]
> > > >
> > > >
> > > >
> > > > o  Section 8
> > > >
> > > >
> > > > leaf softwire-num-max {
> > > >   type uint32;
> > > >   must ". >= 1";
> > > >
> > > >   This should be:
> > > >
> > > > leaf softwire-num-max {
> > > >   type uint32 {
> > > > range "1..max";
> > > >   }
> > > >
> > > >
> > > > o  Section 8
> > > >
> > > >   Since you now have "name" as key in the lists, is the leaf "id"
> > > >   still needed?
> > > >
> > > >
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > >
> > > >  wrote:
> > > > > Re-,
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > -Message d'origine-
> > > > > > De : Martin Bjorklund [mailto:m...@tail-f.com]
> > > > > > Envoyé : mardi 23 octobre 2018 10:05
> > > > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > > > Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-
> softwire-
> > > > > > yang@ietf.org; i...@ietf.org
> > > > > > Objet : Re: Yangdoctors last call review of
> > > > > > draft-ietf-softwire-yang-06
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > >  wrote:
> > > > > > > Hi Martin,
> > > > > > >
> > > > > > > Thank you for the review.
> > > > > > >
> > > > > > > We released a new revision -08 to address your comments. We will
> > > > > > > double check the formatting and issue another iteration if
> needed.
> > > > > >

Re: [Softwires] Yangdoctors last call review of draft-ietf-softwire-yang-06

[mohamed.boucadair]

Hi Martin,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Martin Bjorklund [mailto:m...@tail-f.com]
> Envoyé : mercredi 24 octobre 2018 08:32
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> yang@ietf.org; i...@ietf.org
> Objet : Re: Yangdoctors last call review of draft-ietf-softwire-yang-06
> 
> Hi,
> 
>  wrote:
> > Re-,
> >
> > Fixed the first two ones in my local copy.
> >
> > id is optional. I'm maintaining it because it is already used by some
> > implementations.
> 
> Ok, but these implementations propably need to change anyway since the
> "id" is no longer the key.

[Med] Yes.  

> 
> I will just point out that having one key and another integer based
> identifier that doesn't serve any purpose looks a bit odd.  But if the
> WG thinks that it is needed then that's fine (although in this case I
> suggest you add some text to the descriptions of these leafs that
> explain what the purpose is).
> 
> 
> I had a closer look at the iana-tunnel-type module and the
> instructions to IANA, and I think that you could make some minor
> clarificiations:
> 
> In the module description, you have:
> 
> This module contains a collection of YANG data types defined
> by IANA and used for tunnel types.
> 
> perhaps write:
> 
> This module contains a collection of YANG identities defined
> by IANA and used as interface types for tunnel interfaces.
> 

[Med] Works for me. 

> And in the IANA Considerations section you have:
> 
> 
>"base":Contains the value of the tunnel type in lowercase.
> 
> maybe instead
> 
>"base":Contains the string "ift:tunnel".
> 
> 
> 

[Med] That text is referring to the table in 
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6. 

We can change the text for better clarity to: 

"base":Contains the name assigned to the tunnel type, in lowercase.

> 
> /martin
> 
> 
> 
> >
> > Thank you again for the review. Much appreciated!
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Martin Bjorklund [mailto:m...@tail-f.com]
> > > Envoyé : mardi 23 octobre 2018 15:30
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> > > yang@ietf.org; i...@ietf.org
> > > Objet : Re: Yangdoctors last call review of
> > > draft-ietf-softwire-yang-06
> > >
> > > Hi,
> > >
> > > Thanks for the quick update!
> > >
> > > I have looked at -11, and have just a few minor comments.
> > >
> > > o  Section 5.1
> > >
> > >   Maybe the tree diagram needs to be re-generated; at least:
> > >
> > >| +--rw bind-instance* [id]
> > >
> > >   should be
> > >
> > >| +--rw bind-instance* [name]
> > >
> > >
> > >
> > > o  Section 8
> > >
> > >
> > > leaf softwire-num-max {
> > >   type uint32;
> > >   must ". >= 1";
> > >
> > >   This should be:
> > >
> > > leaf softwire-num-max {
> > >   type uint32 {
> > > range "1..max";
> > >   }
> > >
> > >
> > > o  Section 8
> > >
> > >   Since you now have "name" as key in the lists, is the leaf "id"
> > >   still needed?
> > >
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >  wrote:
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -Message d'origine-
> > > > > De : Martin Bjorklund [mailto:m...@tail-f.com]
> > > > > Envoyé : mardi 23 octobre 2018 10:05
> > > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > > Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> > > > > yang@ietf.org; i...@ietf.org
> > > > > Objet : Re: Yangdoctors last call review of
> > > > > draft-ietf-softwire-yang-06
> > > > >
> > > > > Hi,
> > > > >
> > > > >  wrote:
> > > > > > Hi Martin,
> > > > > >
> > > > > > Thank you for the review.
> > > > > >
> > > > > > We released a new revision -08 to address your comments. We will
> > > > > > double check the formatting and issue another iteration if needed.
> > > > >
> > > > > Thank's for addressing my comments.  See inline and at the end for
> > > > > some new comments on -08.
> > > > >
> > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -Message d'origine-
> > > > > > > De : Martin Björklund [mailto:m...@tail-f.com]
> > > > > > > Envoyé : lundi 15 octobre 2018 11:00
> > > > > > > À : yang-doct...@ietf.org
> > > > > > > Cc : softwires@ietf.org; draft-ietf-softwire-yang@ietf.org;
> > > > > i...@ietf.org
> > > > > > > Objet : Yangdoctors last call review of draft-ietf-softwire-yang-
> 06
> > > > > > >
> > > > > > > Reviewer: Martin Björklund
> > > > > > > Review result: Ready with Issues
> > > > > > >
> > > > > > > This is my YANG doctor review of draft-ietf-softwire-yang-06.
> The
> > > > > > > review focuses on YANG-specifics only, since I am not 

Re: [Softwires] Yangdoctors last call review of draft-ietf-softwire-yang-06

[mohamed.boucadair]

Re-,

Fixed the first two ones in my local copy. 

id is optional. I'm maintaining it because it is already used by some 
implementations. 

Thank you again for the review. Much appreciated!

Cheers,
Med

> -Message d'origine-
> De : Martin Bjorklund [mailto:m...@tail-f.com]
> Envoyé : mardi 23 octobre 2018 15:30
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> yang@ietf.org; i...@ietf.org
> Objet : Re: Yangdoctors last call review of draft-ietf-softwire-yang-06
> 
> Hi,
> 
> Thanks for the quick update!
> 
> I have looked at -11, and have just a few minor comments.
> 
> o  Section 5.1
> 
>   Maybe the tree diagram needs to be re-generated; at least:
> 
>| +--rw bind-instance* [id]
> 
>   should be
> 
>| +--rw bind-instance* [name]
> 
> 
> 
> o  Section 8
> 
> 
> leaf softwire-num-max {
>   type uint32;
>   must ". >= 1";
> 
>   This should be:
> 
> leaf softwire-num-max {
>   type uint32 {
> range "1..max";
>   }
> 
> 
> o  Section 8
> 
>   Since you now have "name" as key in the lists, is the leaf "id"
>   still needed?
> 
> 
> 
> 
> /martin
> 
> 
> 
>  wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Martin Bjorklund [mailto:m...@tail-f.com]
> > > Envoyé : mardi 23 octobre 2018 10:05
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> > > yang@ietf.org; i...@ietf.org
> > > Objet : Re: Yangdoctors last call review of draft-ietf-softwire-yang-06
> > >
> > > Hi,
> > >
> > >  wrote:
> > > > Hi Martin,
> > > >
> > > > Thank you for the review.
> > > >
> > > > We released a new revision -08 to address your comments. We will
> > > > double check the formatting and issue another iteration if needed.
> > >
> > > Thank's for addressing my comments.  See inline and at the end for
> > > some new comments on -08.
> > >
> > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -Message d'origine-
> > > > > De : Martin Björklund [mailto:m...@tail-f.com]
> > > > > Envoyé : lundi 15 octobre 2018 11:00
> > > > > À : yang-doct...@ietf.org
> > > > > Cc : softwires@ietf.org; draft-ietf-softwire-yang@ietf.org;
> > > i...@ietf.org
> > > > > Objet : Yangdoctors last call review of draft-ietf-softwire-yang-06
> > > > >
> > > > > Reviewer: Martin Björklund
> > > > > Review result: Ready with Issues
> > > > >
> > > > > This is my YANG doctor review of draft-ietf-softwire-yang-06.  The
> > > > > review focuses on YANG-specifics only, since I am not familiar with
> > > > > the technology that is modelled.
> > > > >
> > > > > o  I would like to see all Tom Petch's comments in his three replies
> > > > >to the IETF LC for this document addressed.  Especially his
> comment
> > > > >about using ianatf:tunnel.
> > > > >
> > > >
> > > > [Med] This is fixed in -07. A new tunnel-type parameter is defined
> > > > to handle this.
> > >
> > > I think that the addition of identities for various tunnel types that
> > > derive from ift:tunnel is the right thing to do.
> >
> > [Med] OK, thanks
> >
> > >
> > > However, since these identities derive from ift:tunnel, the
> > > augmentation of ietf-interfaces in ietf-interface-tunnel is not
> > > needed.
> >
> > [Med] ietf-interface-tunnel tries to preserve a similar structure as in
> https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, but you are
> right we can get rid of it.
> >
> >  Instead, the new identities should be used as if:type
> > > directly.  For example, instead of:
> > >
> > >   
> > > lw4o6-wan
> > > ianaift:tunnel
> > >  > >   xmlns:iana-tunnel-type="urn:ietf:params:xml:ns:yang:iana-tunnel-
> type">
> > >   iana-tunnel-type:aplusp
> > > 
> > > ...
> > >   
> > >
> > > you should do:
> > >
> > >   
> > >   xmlns:iana-tunnel-type="urn:ietf:params:xml:ns:yang:iana-tunnel-
> type">
> > > lw4o6-wan
> > > iana-tunnel-type:aplusp
> > > ...
> > >   
> > >
> > > So, I think you should remove the ietf-tunnel-type module.
> > >
> >
> > [Med] OK.
> >
> > >
> > > An additional comment on the identities in iana-tunnel-type; for each
> > > identity, I think you should add a "reference" statement that points
> > > to the RFC(s) that define the tunnel.  (available in the IANA registry
> > > at
> > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
> numbers-5)
> > >
> >
> > [Med] I guess you meant https://www.iana.org/assignments/smi-numbers/smi-
> numbers.xhtml#smi-numbers-6. Fixed in my local copy, except form IPHTTPS for
> which we don't have an RFC.
> >
> > >
> > >
> > > > > o  The term "instance" is used to mean - I think - the "device".
> > > >
> > > > [Med] It is used to mean function rather than device. A device may
> > > > enable multiple instances of the 

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

[mohamed.boucadair]

Re-,

This version implements the changes as discussed in the thread with Martin. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 23 octobre 2018 13:57
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-yang-10.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   : YANG Modules for IPv4-in-IPv6 Address plus Port
> Softwires
> Authors : Yong Cui
>   Ian Farrer
>   Mohamed Boucadair
>   Qi Sun
>   Linhui Sun
>   Sladjana Zechlin
>   Rajiv Asati
>   Filename: draft-ietf-softwire-yang-10.txt
>   Pages   : 57
>   Date: 2018-10-23
> 
> 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 module.
> 
> 
> 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-10
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-yang-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-yang-10
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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

[mohamed.boucadair]

Hi all, 

-09 fixes mainly formatting nits. I made many other minor edits. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 23 octobre 2018 09:04
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-yang-09.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   : YANG Modules for IPv4-in-IPv6 Address plus Port
> Softwires
> Authors : Yong Cui
>   Ian Farrer
>   Mohamed Boucadair
>   Qi Sun
>   Linhui Sun
>   Sladjana Zechlin
>   Rajiv Asati
>   Filename: draft-ietf-softwire-yang-09.txt
>   Pages   : 57
>   Date: 2018-10-23
> 
> 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 module.
> 
> 
> 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-09
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-yang-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-yang-09
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Softwires] Yangdoctors last call review of draft-ietf-softwire-yang-06

[mohamed.boucadair]

Hi Martin,

Thank you for the review. 

We released a new revision -08 to address your comments. We will double check 
the formatting and issue another iteration if needed. 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund [mailto:m...@tail-f.com]
> Envoyé : lundi 15 octobre 2018 11:00
> À : yang-doct...@ietf.org
> Cc : softwires@ietf.org; draft-ietf-softwire-yang@ietf.org; i...@ietf.org
> Objet : Yangdoctors last call review of draft-ietf-softwire-yang-06
> 
> Reviewer: Martin Björklund
> Review result: Ready with Issues
> 
> This is my YANG doctor review of draft-ietf-softwire-yang-06.  The
> review focuses on YANG-specifics only, since I am not familiar with
> the technology that is modelled.
> 
> o  I would like to see all Tom Petch's comments in his three replies
>to the IETF LC for this document addressed.  Especially his comment
>about using ianatf:tunnel.
> 

[Med] This is fixed in -07. A new tunnel-type parameter is defined to handle 
this. 

> 
> o  All three YANG modules should follow the common template for IETF
>YANG modules found in
>https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis.
> 
>Specifically, fix the authors list and copyright text.
> 

[Med] Done. 

> 
> o  The term "instance" is used to mean - I think - the "device".

[Med] It is used to mean function rather than device. A device may enable 
multiple instances of the same function. 

  I
>didn't find this term in the RFCs 7596, 7597 or 7599.  I suggest
>you use some other term, since "instance" is quite generic, and is
>often used to refer to instances of YANG data nodes.
> 
>Also, does the term "instance" mean the same thing in
>"algo-instance"?  And in "br-instances"?  "bind-instance"?
> 
> 
[Med] algo-instance means an instance of type algorithm. br-instances denotes a 
set of br instances, and bind-instance means an instance of type binding. 

> 
> o  In ietf-softwire-common:
> 
>   grouping algorithm-instance {
> description
>   "Indicates that the instance supports the MAP-E and MAP-T
>   function. The instance advertises the MAP-E/MAP-T feature
>   through the capability exchange mechanism when a NETCONF
>   session is established.";
> 
>   This description does not seem right.  A grouping can't indicate
>   anything.  Also, what is "the MAP-E/MAP-T feature"?
> 

[Med] Fixed.

> 
> o  In ietf-softwire-ce:
> 
>   A similar description is found here:
> 
> container algo-instances {
>   description
> "Indicates that the instances supports the MAP-E and MAP-T
> function. The instances advertise the MAP-E/MAP-T
> feature through the capability exchange mechanism
> when a NETCONF session is established.";
> 
>   same comments apply.
> 

[Med] Fixed. 

> 
> o  In ietf-softwire-common:
> 
> container algo-versioning {
>   description "algorithm's version";
>   leaf version {
> type uint64;
> description "Incremental version number for the algorithm";
>   }
>   leaf date {
> type yang:date-and-time;
> description "Timestamp to the algorithm";
>   }
> }
> 
>   Maybe these descriptions are crystal clear to someone who knows the
>   technology.  If so, perhaps add a reference to help the rest of us?
> 

[Med] This is used for logging purposes. A reference to RFC7422 is added. 

> 
> o  In general, it would help if the definitions had "reference"
>statements to the relevant sections in the underlying RFCs.
> 
> 
> o  In ietf-softwire-ce:
> 
>   notification softwire-ce-event {
> if-feature binding;
> description "CE notification";
> leaf ce-binding-ipv6-addr-change {
>   type inet:ipv6-address;
>   mandatory true;
>   description
> "If the CE's binding IPv6 address changes for any reason,
> it should notify the NETCONF client.";
> }
> 
>   Perhaps rewrite the description to:
> 
> This notification is generated whenever the CE's binding IPv6
> address changes for any reason.
> 

[Med] OK.

> 
> o  In ietf-softwire-br:
> 
>   You have:
> 
> leaf softwire-num-max
> leaf softwires-payload-mtu
> leaf softwire-path-mru
> 
>Any reason it isn't "softwire-payload-mtu"?
> 

[Med] No. Fixed already in -07.

> 
> o  In ietf-softwire-br:
> 
>   list bind-instance {
> key "id";
> [...]
> container binding-table-versioning { ... }
> leaf id { ... }
> 
>   I suggest you put the leaf "id" before the container; it is common
>   practise to put the key leafs first.
> 

[Med] Fixed. 

>   Also, the leaf id has the description:
> 
>   description "An instance identifier.";
> 
>   This again can be confused with YANG's "instance-identifier".
> 

[Med] chnaged to:  

  "A binding instance identifier.

   This identifier can be automatically assigned

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

[mohamed.boucadair]

Hi all, 

This version integrates almost all the comments raised by Tom. Many thanks to 
him! 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : lundi 22 octobre 2018 16:54
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-yang-07.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   : YANG Modules for IPv4-in-IPv6 Address plus Port
> Softwires
> Authors : Yong Cui
>   Ian Farrer
>   Mohamed Boucadair
>   Qi Sun
>   Linhui Sun
>   Sladjana Zechlin
>   Rajiv Asati
>   Filename: draft-ietf-softwire-yang-07.txt
>   Pages   : 55
>   Date: 2018-10-22
> 
> Abstract:
>This document defines YANG modules for the configuration and
>operation of IPv4-in-IPv6 softwire Border Relays and Customer
>Premises Equipment for the Lightweight 4over6, MAP-E, and MAP-T
>softwire mechanisms.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update these statements within this document with the RFC
>number to be assigned to this document:
> 
>o  "This version of this YANG module is part of RFC ;"
> 
>o  "RFC : YANG Modules for IPv4-in-IPv6 Address plus Port
>   Softwires";
> 
>o  "reference: RFC "
> 
>Please update the "revision" date of the YANG module.
> 
> 
> 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-07
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-yang-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-yang-07
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Softwires] Last Call: (YANG Modules for IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard

[mohamed.boucadair]

Re-,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : tom petch [mailto:daedu...@btconnect.com]
> Envoyé : mercredi 3 octobre 2018 13:57
> À : tom petch; ietf
> Cc : softwires@ietf.org; softwire-cha...@ietf.org; jiangsh...@huawei.com;
> draft-ietf-softwire-y...@ietf.org
> Objet : Re: Last Call:  (YANG Modules for
> IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard
> 
> And some technical comments on this I-D as a result of which, I do not
> think this is ready to progress; perhaps no show stoppers, just a lot of
> changes are needed IMHO.  The more I look into this I-D, the less I
> understand (which may be my ignorance of YANG).
> 
> This I-D is concerned with three tunnel types (Lw4o6, MAP-E, MAP-T).  In
> several places, you have
>   augment "/if:interfaces/if:interface" {
> when "if:type = 'ianaift:tunnel'";
> This will augment for all tunnel types, not just those of this I-D.  I
> think you should have your own three (?) derived identities for the
> three specific tunnels described here, all in the common module.

[Med] Good point. A new parameter called tunnel-type is now added to the 
interface YANG module (augments 8343). 

> 
> The three YANG modules are for Customer Premises Equipment, Border Relay
> and a common module. Both the first two define two features, binding and
> algorithm, binding for Lw4o6 and algorithm for MAP-E/MAP-T - I do not
> know if/how this duplication of features will work (and as I said
> before, I am confused about support for 'MAP-E and MAP-T' versus 'MAP-E
> or
> MAP-T' both of which phrases appear in the I-D).  As with tunnel types,
> should
> there be three features, should they be in the common module?  (yes, and
> yes)

[Med] The feature indicates the support of MAP-E and/or MAP-T. the data plane 
clause is supposed to hint whether this is about MAP-E (encapsulation) or MAP-T 
(transaltion). I do agree that defining features for each of these two may be 
more simple. 


> 
> 2.2
> 'they should be imported here, as needed. '
> import is a YANG technical term as used in this I-D so I think the use
> of it here wrong

[Med] Fixed. 

> 
> '   The CE must already have minimal IPv6 configuration'
> Could that also be IPv4 which, by definition, is going to be widespread
> in the deployment?

[Med] A+P mechanisms assumes that no IPv4 configuration is provided because A+P 
is meant to provide IPv4 service continuity over IPv6. 

> 
> 3.2
> softwire-path-mru:
> what is the point of this field?  I looked at RFC7596, RFC7597 and
> RFC7599
> and could find no reference thereto.  I went back to their references,
> such as RFC4821, RFC2473, RFC1981, RFC6346 ... - no joy.  I had thought
> to suggest a reference was called for but seeing the complete absence of
> any connection, I think that a substantial explanation is called for.
> 

[Med] I completely lost the context why the document ended to have this in. I'm 
sure Ian has a record about this. 

> Likewise, I note that references to MTU are qualified with IPv4 but
> references to MRU are not; rather, this object
> 'set the maximum IPv6 softwire packet size that can be received ...'
> when
> 'the implementation is unable to calculate the correct IPv4  size  '
> Really?
> 
> 'IPv6 prefix type' or ''IPv6 address type'.
> Well, no It can be
> type  ipv6-prefix or ipv6-address
> 

[Med] Yeah!


> This description of the  ietf-softwire-ce module describes objects that
> are not in the  ietf-softwire-ce module, which confuses me.  Rather they
> are in the ietf-softwire-common module.  I think you need a description
> of the objects in the ietf-softwire-common module first and then moving
> on to the two specific modules.  The sense I get is that while splitting
> into three makes sense, the consequences have not been thought through.

[Med] Not sure which part you are referring to. Can you please explicit your 
comment? Thank you.

> 
> The descriptions of objects here are (mostly) good, but do not appear in
> the YANG module.  Those in the YANG module are shallow by comparison and
> should be at least as comprehensive as those in the body of the I-D; the
> YANG module has to be able to survive on its own.
> 
> 'The version number is  incremented  '
> Any constraints on the increment?  one, a hundred, a million...?

[Med] This is implementation-specific. As indicated in this example, a 
timestamp would be sufficient. 

> 
> 4.2
> As with 3.2, the descriptions here of the objects look fine, those in
> the description clauses of the YANG module do not; they are thin by
> comparison.
> 
> 5
> leaf br-ipv6-addr {
>  mandatory true;
> "The IPv6 address for of the binding BR.";
> This is not quite English.

[Med] Fixed. 


> And since this object is MAP-E only, should it be, can it be, mandatory?

[Med] this is of lw4over6. Hence, the mandatory clause. 

> 
>   leaf id {
>   type uint32;
>   mandatory true;
>   

Re: [Softwires] Last Call: (YANG Modules for IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard

[mohamed.boucadair]

Hi Tom,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : tom petch [mailto:daedu...@btconnect.com]
> Envoyé : vendredi 28 septembre 2018 18:13
> À : i...@ietf.org
> Cc : softwires@ietf.org; softwire-cha...@ietf.org; jiangsh...@huawei.com;
> terry.mander...@icann.org; draft-ietf-softwire-y...@ietf.org
> Objet : Re: Last Call:  (YANG Modules for
> IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard
> 
> I believe that this I-D needs some admin-type changes to make it usable.
> 
> All three modules import some or all of
> 
> ietf-inet-types
> ietf-interfaces
> iana-if-type
> ietf-softwire-common
> 
> These imports should have YANG reference statements identifying the
> relevant RFC, probably
>   6991
>   8343
>   7244
>   

[Med] Added reference statements for those. 

> 
> and these need to be Normative References for the I-D; 8343 is, 6991 is
> not.
> 
> The first two modules have a sentence mentioning the use of RFC6991;
> this should mention all the modules referenced, those above and
> RFC7596
> RFC7597
> RFC7599:
> these last are already Normative References.  A similar sentence is
> needed for the third module for the RFC that it references.

[Med] Done. 

> 
> The third module is a bit light on references - I cannot see any!
> 
> There are three references to RFC XXX- I suspect that RFC  is
> intended.
> 

[Med] Yes. 

> IANA Considerations references RFC7950 - this is a poor reference since
> all it says is 'Go look at RFC6020' which thus should be the reference
> here.

[Med] OK.

> 
> Security Considerations starts "The YANG module defined in this document
> ...
> Give us a clue - there are three of them:-)
> 
> Appendix A.  Configutation Examples
> 

[Med] Fixed. 

> Tom Petch
> 
> - Original Message -
> From: "The IESG" 
> To: "IETF-Announce" 
> Cc: ; ;
> ; ;
> 
> Sent: Thursday, September 27, 2018 1:06 PM
> 
> >
> > The IESG has received a request from the Softwires WG (softwire) to
> consider
> > the following document: - 'YANG Modules for IPv4-in-IPv6 Address plus
> Port
> > Softwires'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> final
> > comments on this action. Please send substantive comments to the
> > i...@ietf.org mailing lists by 2018-10-11. Exceptionally, comments may
> be
> > sent to i...@ietf.org instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >This document defines YANG modules for the configuration and
> >operation of IPv4-in-IPv6 softwire Border Relays and Customer
> >Premises Equipment for the Lightweight 4over6, MAP-E, and MAP-T
> >softwire mechanisms.
> >
> > Editorial Note (To be removed by RFC Editor)
> >
> >Please update these statements within this document with the RFC
> >number to be assigned to this document:
> >
> >o  "This version of this YANG module is part of RFC ;"
> >
> >o  "RFC : YANG Modules for IPv4-in-IPv6 Address plus Port
> >   Softwires";
> >
> >o  "reference: RFC "
> >
> >Please update the "revision" date of the YANG module.
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ballot/
> >
> > No IPR declarations have been submitted directly on this I-D.

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

Re: [Softwires] Last Call: (YANG Modules for IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard

[mohamed.boucadair]

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : tom petch [mailto:daedu...@btconnect.com]
> Envoyé : lundi 1 octobre 2018 13:27
> À : i...@ietf.org
> Cc : softwires@ietf.org; softwire-cha...@ietf.org; draft-ietf-softwire-
> y...@ietf.org; jiangsh...@huawei.com
> Objet : Re: Last Call:  (YANG Modules for
> IPv4-in-IPv6 Address plus Port Softwires) to Proposed Standard
> 
> Some more thoughts on this I-D
> 
> No mention of NMDA - I see the IESG asking for such a statement in
> Abstract and in the body of an I-D

[Med] Added to the introduction:

   The adopts the Network Management Datastore Architecture (NMDA)
   [RFC8342].

> 
> Abbreviations are expanded but on the nth use, not the first use e.g.
> BR, PSID; they probably should be expanded on first use within the YANG
> module as well.

[Med] Will double check this. 

> 
> '   Please update the "revision" date of the YANG module.'  There are
> three of them:-)

[Med] OK.

> 
> Terminology is problematic especially as it seems inconsistent with the
> Normatively Referenced RFC7596, RFC7597, RFC7599.
> 
>  Customer Premises Equipment (CEs ..
> CE is a well known abbreviations for Customer Edge, as oppposed to
> Provider Edge, and this is not meant here.   Indeed, RFC7599 uses CE for
> Customer Edge.  Customer Premises Equipment is widely abbreviated to
> CPE.  RFC7596, a  Normative Reference, has 'Customer Premises Equipment
> (CPE)' which I should be used here.

[Med] Added: (a.k.a., CPE). 

Actually, we just went with CE used in RFC7599. 

> 
> In places, it is 'MAP-E, and MAP-T', elsewhere 'MAP-E or MAP-T'. Does
> feature 'algorithm' mean both are supported or just one, and if one, how
> can the user tell?

[Med] Feature 'algorithm' means 'MAP-E and/or MAP-T' is supported. 
Nevertheless, when it comes to actual configuration, only MAP-E or MAP-T 
parameters can be conveyed. This is hinted by the data-plane clause. 

> 
> The description clause of 'module ietf-softwire-common' is misleading.
> The introductory sentence of the section accurately describes the module
> as common definitions but the description clause claims to configure
> Lw4o6, MAP-E and MAP-T which it seems wrong.

[Med] Fixed. 

> 
> 'algorithm' is widely (mis?)used in this I-D.  The Normative Reference
> RFC7597 is much easier to follow since it mostly talks of 'Mapping
> Algorithm' or 'Mapping Rule'.

[Med] Added: 

For simplicity, "algorithm" is used to refer to "mapping algorithm" [RFC7599].


  I think
>   case algorithm {
> if-feature algorithm;
> container algo-instances {
>   list algo-instance {
> with
>   grouping algorithm-instance {
> in softwire-common and
>   case algorithm {
> if-feature algorithm;
> container algorithm {
>   if-feature algorithm;
> need a different term or terms.  

[Med] OK. Went for:


   case algo {
 if-feature algorithm-mode;
 container algo-instances {
   list algo-instances {

Likewise
>   case binding {
> if-feature binding;
> container binding {
>   if-feature binding;
>   list bind-instance {
> for binding.  A widely used, and helpful convention is to have a list
> the plural - interfaces - and entries singular - interface; that would

[Med] Went for list bind-instances.

> help here.  And what does
>   if-feature algorithm;
> add that
> if-feature algorithm;
> does not?
> 

[Med] Removed one if-feature statement. 


> BR is a well known abbreviation for Border Router; here it used for MAP
> Border Relay and while RFC7599 says 'A MAP BR may also be referred to as
> simply a "BR" within the context of MAP.', I think that the context here
> is wider - the modules are not just MAP - and the term should be 'MAP
> BR' not just 'BR'.

[Med] Added:

   The document uses BR to refer to MAP BR [RFC7599] or Lightweight
   4over6 BR [RFC7596].

> 
> After my previous message
> ietfa.amsl.com.
> gave me a bounce message for
> y...@csnet1.cs.tsinghua.edu.cn>
> 
> Overall, I get a slight flavour that this is written by those intimately
> acquainted with the technology (although not so much with the RFC!) for
> similar readers.
> 
> Tom Petch
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] TR: New Version Notification for draft-boucadair-netmod-softwire-iftunnel-00.txt

[mohamed.boucadair]

Dear all,

This draft adds an extension to the interface module to identify the tunnel 
type. 

Comments are more than welcome. 

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Envoyé : vendredi 19 octobre 2018 14:41
> À : BOUCADAIR Mohamed TGI/OLN
> Objet : New Version Notification for draft-boucadair-netmod-softwire-
> iftunnel-00.txt
> 
> 
> A new version of I-D, draft-boucadair-netmod-softwire-iftunnel-00.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> 
> Name: draft-boucadair-netmod-softwire-iftunnel
> Revision: 00
> Title:A Tunnel Extension to the Interface Management YANG 
> Module
> Document date:2018-10-19
> Group:Individual Submission
> Pages:13
> URL:https://www.ietf.org/internet-drafts/draft-boucadair-netmod-
> softwire-iftunnel-00.txt
> Status: https://datatracker.ietf.org/doc/draft-boucadair-netmod-
> softwire-iftunnel/
> Htmlized:   https://tools.ietf.org/html/draft-boucadair-netmod-softwire-
> iftunnel-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-
> softwire-iftunnel
> 
> 
> Abstract:
>This document specifies an extension the Interface Management YANG
>module.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update these statements in the document with the RFC number to
>be assigned to this document:
> 
>o  "This version of this YANG module is part of RFC ;"
> 
>o  "RFC : A Tunnel Extension to the Interface Management YANG
>   Module";
> 
>o  "reference: RFC "
> 
>Please update the "revision" date of the YANG module.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

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

Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

[mohamed.boucadair]

Hi Ian,

Works for me. Thanks.

Cheers,
Med

De : ianfar...@gmx.com [mailto:ianfar...@gmx.com]
Envoyé : vendredi 29 juin 2018 09:59
À : BOUCADAIR Mohamed IMT/OLN; Sheng Jiang
Cc : Softwires WG; softwire-cha...@ietf.org; Andy Wingo
Objet : Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, 
closed by 27 June 2018

Hi Sheng /Med,

@Sheng, Thanks for the review.
@Med, Thanks for the quick update.

A couple of other things:

There’s an outstanding comment on model element descriptions given as “…”. 
Proposed new text:

notification softwire-binding-instance-event description: "The ID of the 
binding-instance that generated the notification.";

leaf-list modified-entry description "The ID of the the binding-table entry 
that has been modified.";

--
I just did a quick read through of -05. There are a few small language cleanups 
that I would like to make:

Section 2.1
s/Provides configuration and monitoring for softwire CE element/Provides 
configuration and monitoring for the softwire CE element/

s/Provides configuration and monitoring for softwire BR element/Provides 
configuration and monitoring for the softwire BR element/

Section 2.2
s/be imported here, as needed/be imported, as needed/

ietf-softwire-ce:binding-entry/br-ipv6-addr
description
s/The IPv6 address for of the binding BR./The IPv6 address for the binding BR./

ietf-softwire-br:br-instances/algorithm
description
s/Indicate that the instance supports the MAP-E and MAP-T functions./Indicate 
that the instance supports the MAP-E and MAP-T functions./

If there’s no objection to the above changes, I’ll update and post later on 
today.

Cheers,
Ian


On 27. Jun 2018, at 10:54, 
mohamed.boucad...@orange.com wrote:

Hi Sheng,

Many thanks for the careful review.

An updated version which integrates your comments is available 
online:https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1

See more inline.

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

Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

[mohamed.boucadair]

Hi Sheng,

Many thanks for the careful review.

An updated version which integrates your comments is available online: 
https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1

See more inline.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Sheng Jiang
Envoyé : mercredi 27 juin 2018 06:00
À : Softwires WG
Cc : softwire-cha...@ietf.org
Objet : Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, 
closed by 27 June 2018

As the document shepherd, I have reviewed this document. Document editors and 
WG chairs should treat these comments just like any other last call comments. 
In general, I think this document is in a good shape. The YANG model is well 
defined and clearly described.
Here are some minor issues, mostly editorial, although there is 1 error report 
by the IETF Yang validation tool. It should be easy to be fixed, I believe

[Med] As you can see in 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/softwire-yang-validation.pdf,
 the module passes validation. The issue displayed by the tracker is related to 
iana-if-t...@2018-06-22.yang.

There are some minor comments below, most of them are editorial.

Section 2.1
It may be better to add the statement names in the description of choice 
statement:
  a choice statement 'ce-type' is included for ...
  a choice statement 'data-plane' is included to ...

[Med] Fixed.

"For each module, a choice statement is included for either 'binding' or 
'algorithmic'."
But in Table 1 it is 'algorithm'. Maybe 'algorithmic' should be changed to 
'algorithm'.

[Med] Good catch. Fixed.


Section 2.2
The reference to Appendix A.3 should be Appendix A

[Med] Citing Appendix A.3 is on purpose. It is where NAT and RFC8349 examples 
are provided.


Section 3.1
"for all of the softwire mechanisms listed in Section 1"
It may be bette to avoid self citation and just list the mechanisms here.

[Med] OK.


"Figure 1 describes the tree structure of the CE softwire YANG module"
It's better to unify the terminology as "Softwire CE YANG Module"

[Med] OK.


Section 3.2
In the paragraph of "softwire-path-mru:":
It's confusing here whether the MRU is for IPv4 or IPv6.

[Med] The text indicates "to set the maximum IPv6 softwire packet size". 
Furthermore, the description "The path MRU for the softwire (payload + 
encapsulation
overhead)" is also clear about the usage. I don't think a change is 
required.

There are two "br-ipv6-addr" defined. It may be better to add different 
prefixes or suffixes into the names, but I'm also OK with the current names..
[Med] We could add map or lw prefixes, but as you know adding prefixes is not 
helpful (and it even not recommended) as a leaf is identified by its parent. I 
suggest to leave those unmodified.

In the paragraph of "ce-binding-ipv6-addr-change:":
"binding-ipv6-address" is not defined in the whole document. It should be 
explained.

[Med] changed to "binding IPv6 address"

Section 4.2
"in Figure 1"
should be "in Section 3.2"

[Med] OK.


"for logging/data retention purposes" -> "for logging or data retention 
purposes"
[Med] OK.

"between 3-tuples, which contains the lwB4's IPv6 address..." -> "between 
3-tuples: the lwB4's IPv6 address..."
[Med] Changed to "3-tuples {lwB4's IPv6 address/prefix, the allocated IPv4 
address, restricted port-set}"


"softwire-num-threshold"
>From the description, I think it may be better to rename it to 
>"softwire-num-max".
[Med] Makes sense.

In the paratraph of "invalid-entry, added-entry, modified-entry:":
"the client" -> "the NETCONF client"

[Med] OK.

Appendix A.1
"lwB4 IPv6 Address:  123"
What's the "lwB4 IPv6 Address" here?
[Med] Oops. This should be PSID.


Appendix A.2
"for the clients" -> "for the CEs"
[Med] Done.


Appendix A.3
The same "lwB4 IPv6 Address" issue
And the PSID and PSID offset should be provided in the example.
[Med] Idem as above. Should s/lwB4 IPv6 Address/PSID.


Cheers,

Sheng

From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of Sheng Jiang
Sent: Wednesday, June 13, 2018 5:44 PM
To: Softwires WG 
Cc: softwire-cha...@ietf.org
Subject: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, 
closed by 27 June 2018


This email announces a Softwire Working Group Last Call (WGLC) on:



Since both chairs of softwire WG are the co-authors of this document. I am now 
acting as the document shepherd for this draft.



YANG Modules for IPv4-in-IPv6 Address plus Port Softwires

draft-ietf-softwire-yang-04

https://tools.ietf.org/html/draft-ietf-softwire-yang-04



This draft is intended to become a Standard Track RFC.



This WGLC will run through the end of the day on Wednesday, June 27, 2018.



Comments should be sent to the softwires@ietf.org 
list, although purely

editorial comments may be sent directly to the author.



No IPR disclosures have been submitted directly on

Re: [Softwires] Ignas Bagdonas' No Objection on draft-ietf-softwire-dslite-yang-16: (with COMMENT)

[mohamed.boucadair]

Hi Ignas, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Ignas Bagdonas [mailto:ibagd...@gmail.com]
> Envoyé : jeudi 24 mai 2018 13:58
> À : The IESG
> Cc : draft-ietf-softwire-dslite-y...@ietf.org; Ian Farrer; softwire-
> cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Ignas Bagdonas' No Objection on draft-ietf-softwire-dslite-yang-16:
> (with COMMENT)
> 
> Ignas Bagdonas has entered the following ballot position for
> draft-ietf-softwire-dslite-yang-16: 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-dslite-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Nit: model vs module. While there are no strict requirements for terminology,
> it appears that dominant term used in YANG documents is model and not module.
> The reasoning would be that model defines a module and the logic description
> of
> it, while module is strictly a formal YANG code.
> 

[Med] As per 
https://www.ietf.org/mail-archive/web/netmod/current/msg15324.html, both "YANG 
data model" and "YANG module" are valid terms. I will double check the document 
to fix any inconsistent use of the terms.  

> Nit: s/rate-lmite/rate limit

[Med] Fixed. 

> 
> uint8 max-softwires-per-subscriber: Is the storage space large enough here?

[Med] This is implementation- and deployment-specific. 

> RFC
> 7785 recommends 1, but it does not appear to set upper limit. If practical
> deployment scenarios will be an order of magnitude lower than 255 then likely
> it is not a problem.
> 

[Med] We are not setting any max because this is deployment-specific. 

> date-and-time last-address-change: Is the granularity of yang:date-and-time
> enough for this use?
> 

[Med] Yes.

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

Re: [Softwires] Ben Campbell's No Objection on draft-ietf-softwire-dslite-yang-15: (with COMMENT)

[mohamed.boucadair]

Hi Ben, 

Thank you. 

I updated the editorial note to make clear this is about changes into the 
document. 

I also updated the document to take into account the comments from: Mirja, 
Benjamin, and Adam.

An updated version with the changes is available online

Cheers,
Med

> -Message d'origine-
> De : Ben Campbell [mailto:b...@nostrum.com]
> Envoyé : mercredi 23 mai 2018 19:18
> À : The IESG
> Cc : draft-ietf-softwire-dslite-y...@ietf.org; Ian Farrer; softwire-
> cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Ben Campbell's No Objection on draft-ietf-softwire-dslite-yang-15:
> (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-softwire-dslite-yang-15: 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-dslite-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This is well-written overall, but I was confused by the RFC editor note after
> the abstract. I assume you mean for these updates to be done on matching text
> throughout the document, but I originally read it to mean update the text in
> the note itself, which is labeled for deletion.
> 

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

Re: [Softwires] ISP CGN logging inc. Destination ??

[mohamed.boucadair]

Hi Yiu, 

This may help but this is not sufficient if supplying "Destination IP + Port 
(public)" is required. 

Technically the BR may extract and record the destination IPv4 address/port and 
source IPv6 prefix when doing its stateless decapsulation/translation, but this 
is not a "native" feature of a BR/lwAFTR. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Lee, Yiu
> Envoyé : lundi 7 mai 2018 13:16
> À : ramesh.r.chan...@ril.com
> Cc : softwires@ietf.org; int-a...@ietf.org; ianfar...@gmx.com
> Objet : Re: [Int-area] [EXTERNAL] Re: [Softwires] ISP CGN logging inc.
> Destination ??
> 
> Just a quick thought. Will the dhcpv6 logs help?
> 
> Sent from mobile device, pardon possible typo.
> 
> > On May 7, 2018, at 7:06 AM, "ramesh.r.chan...@ril.com"
>  wrote:
> >
> > Dear Ian,  thanks for clarifications.
> >
> > Regulator in India mandated to preserve the following details for each
> flow.
> > 1.Source IP + Port (private for end subscriber device)
> > 2.Destination IP + Port (public)
> > 3.Translated IP + port (public)
> > 4.Date and time
> >
> > There is no brainer and all this is available in NAT44. MAP being
> stateless, no such data available from MAP-BR. We are exploring alternate
> option on BR to create this data in MAP.
> >
> > Pls advise.
> >
> > Regds
> > ramesh
> > -Original Message-
> > From: ianfar...@gmx.com [mailto:ianfar...@gmx.com]
> > Sent: 04 May 2018 17:28
> > To: Rajiv Asati (rajiva)
> > Cc: Softwires-wg list; int-a...@ietf.org; Ramesh R Chandra
> > Subject: Re: [Softwires] ISP CGN logging inc. Destination ??
> >
> > Hi Rajiv,
> >
> > Please see inline.
> >
> > Cheers,
> > Ian
> >
> >> On 4. May 2018, at 12:01, Rajiv Asati (rajiva)  wrote:
> >>
> >> Ian,
> >>
> >> Thanks for sharing the URL. While not explicit, “all metadata” would
> include both source and destination A+P. Is that the right interpretation?
> >
> > [if - My understanding is that per-flow logging is necessary to meet the
> requirement, but I’m not familiar enough with the legislation to know what
> exactly needs to be stored.]
> >
> >>
> >> If an ISP were to use “binding” mode on the BR, then without using net
> flow/IPFIX, How could the compliance be achieved ?
> >
> > [if - If there’s address sharing and the requirement is to provide an exact
> match to a data retention request (in some countries, a list of e.g. 16 users
> is OK), then AFAICS, you have to use IPFIX.
> >
> > The implementation problem for this is compounded by the lack of state
> table on most BR implementations (e.g. how do you know when a UDP session has
> completed without state for that flow?)]
> >
> >
> > "Confidentiality Warning: This message and any attachments are intended
> only for the use of the intended recipient(s).
> > are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
> > review. re-transmission. conversion to hard copy. copying. circulation or
> other use of this message and any attachments is
> > strictly prohibited. If you are not the intended recipient. please notify
> the sender immediately by return email.
> > and delete this message and any attachments from your system.
> >
> > Virus Warning: Although the company has taken reasonable precautions to
> ensure no viruses are present in this email.
> > The company cannot accept responsibility for any loss or damage arising
> from the use of this email or attachment."
> > ___
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> ___
> Int-area mailing list
> int-a...@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] ISP CGN logging inc. Destination ??

[mohamed.boucadair]

Dear Ramesh,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de
> ramesh.r.chan...@ril.com
> Envoyé : vendredi 4 mai 2018 17:26
> À : ianfar...@gmx.com; raj...@cisco.com
> Cc : softwires@ietf.org; int-a...@ietf.org
> Objet : Re: [Softwires] ISP CGN logging inc. Destination ??
> 
> Dear Ian,  thanks for clarifications.
> 
> Regulator in India mandated to preserve the following details for each flow.
> 1.Source IP + Port (private for end subscriber device)

[Med] Please note that this one may be overlapping among multiple subscribers 
if DS-Lite is used. 

> 2.Destination IP + Port (public)

[Med] Does the regulator require to preserve "Destination IP + Port" even if a 
public IP address is assigned to a subscriber?

> 3.Translated IP + port (public)
> 4.Date and time
> 
> There is no brainer and all this is available in NAT44. MAP being stateless,
> no such data available from MAP-BR. We are exploring alternate option on BR
> to create this data in MAP.
> 
> Pls advise.
> 
> Regds
> ramesh
> -Original Message-
> From: ianfar...@gmx.com [mailto:ianfar...@gmx.com]
> Sent: 04 May 2018 17:28
> To: Rajiv Asati (rajiva)
> Cc: Softwires-wg list; int-a...@ietf.org; Ramesh R Chandra
> Subject: Re: [Softwires] ISP CGN logging inc. Destination ??
> 
> Hi Rajiv,
> 
> Please see inline.
> 
> Cheers,
> Ian
> 
> > On 4. May 2018, at 12:01, Rajiv Asati (rajiva)  wrote:
> >
> > Ian,
> >
> > Thanks for sharing the URL. While not explicit, “all metadata” would
> include both source and destination A+P. Is that the right interpretation?
> 
> [if - My understanding is that per-flow logging is necessary to meet the
> requirement, but I’m not familiar enough with the legislation to know what
> exactly needs to be stored.]
> 
> >
> > If an ISP were to use “binding” mode on the BR, then without using net
> flow/IPFIX, How could the compliance be achieved ?
> 
> [if - If there’s address sharing and the requirement is to provide an exact
> match to a data retention request (in some countries, a list of e.g. 16 users
> is OK), then AFAICS, you have to use IPFIX.
> 
> The implementation problem for this is compounded by the lack of state table
> on most BR implementations (e.g. how do you know when a UDP session has
> completed without state for that flow?)]
> 
> 
> "Confidentiality Warning: This message and any attachments are intended only
> for the use of the intended recipient(s).
> are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
> review. re-transmission. conversion to hard copy. copying. circulation or
> other use of this message and any attachments is
> strictly prohibited. If you are not the intended recipient. please notify the
> sender immediately by return email.
> and delete this message and any attachments from your system.
> 
> Virus Warning: Although the company has taken reasonable precautions to
> ensure no viruses are present in this email.
> The company cannot accept responsibility for any loss or damage arising from
> the use of this email or attachment."
> ___
> 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] ISP CGN logging inc. Destination ??

[mohamed.boucadair]

Hi Rajiv,

Please check RFC6888 which says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati 
(rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-a...@ietf.org
Cc : ramesh.r.chan...@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??

Is there an RFC (besides 6269) that encourages / discourages CGN logging of 
destination IP+Port if source IP+port is already logged?

RFC6269 does mention the below, as compared to the server side logging of 
source IP+port -

// logging the destination address on the NAT is inferior
   to logging the source port at the server.
https://tools.ietf.org/html/rfc6269
//

(BTW, having both source+destination in the NAT log implicitly means no bulk 
allocation of source ports possible)

Separately, this prohibits using stateless NAT based solutions such as MAP or 
using deterministic NAT, since there is no logging in such solutions. If such a 
guideline was also mandated for native IPv6, then it would pose an interesting 
deployment issue.

--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

PS: Few may be aware of Govt. of India’s mandate* to log both source and 
destination IP+port pair.
Click on “Parameter to be stored in SYS Log of Network Address Translation 
(NAT) for Internet Access” on this page - 
https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/

PS:
https://tools.ietf.org/html/rfc6302
https://tools.ietf.org/html/rfc7422


Session and service continuity
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Last Call: (A YANG Data Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard

[mohamed.boucadair]

Re-,

Thank you for double checking. Much appreciated!

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : tom p. [mailto:daedu...@btconnect.com]
> Envoyé : mardi 27 février 2018 13:37
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : softwires@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org; softwire-
> cha...@ietf.org; ianfar...@gmx.com; terry.mander...@icann.org; ietf
> Objet : Re: Last Call:  (A YANG Data
> Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard
> 
> Med
> 
> Two thoughts.
> 
> You have a reference clause for RFC8343 which is good, but it does not
> appear in the Reference section of the I-D which I think it should.

[Med] Hmm. We do have such entry: 

   [I-D.ietf-netmod-rfc7223bis]
  Bjorklund, M., "A YANG Data Model for Interface
  Management", draft-ietf-netmod-rfc7223bis-03 (work in
  progress), January 2018.

  It
> then needs to appear in the text part of the I-D lest you get a unused
> reference warning, perhaps at the start of section 3, or else in section
> 2. (I like the approach of rfc7227bis which lists all the imports
> together).
> 
> Second, when you say
> "  Also, update this sentence with the RFC number to be assigned to this
>document:
>o  "RFC : A YANG Module for Network Address Translation (NAT) and
> Network Prefix Translation (NPT)"
> 'this document' could be misread as
>  draft-ietf-softwire-dslite-yang
> rather than
>  I-D.ietf-opsawg-nat-yang
> I suggest replacing 'this document' by  ' ietf-opsawg-nat-yang'
> I know, picky, but I like the RFC Editor to have to think as little as
> possible so they can concentrate on what they do so well.

[Med] If you think this can be misinterpreted, I'm happy to change it. I will 
fix it in my local copy but will wait for other comments from the IESG review 
before releasing a new version. 

> 
> Tom Petch
> 
> - Original Message -
> From: 
> Sent: Tuesday, February 27, 2018 7:13 AM
> 
> > Hi Tom,
> >
> > FWIW, an updated version which takes into account your review is
> available online.
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-15
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> > > Envoyé : mardi 20 février 2018 14:34
> > > À : tom p.
> > > Cc : softwires@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org;
> softwire-
> > > cha...@ietf.org; ianfar...@gmx.com; terry.mander...@icann.org;
> i...@ietf.org
> > > Objet : RE: Last Call:  (A
> YANG Data
> > > Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard
> > >
> > > Hi Tom,
> > >
> > > Thank you for the review and comments.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : tom p. [mailto:daedu...@btconnect.com]
> > > > Envoyé : mardi 20 février 2018 12:07
> > > > À : i...@ietf.org
> > > > Cc : softwires@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org;
> > > softwire-
> > > > cha...@ietf.org; ianfar...@gmx.com; terry.mander...@icann.org
> > > > Objet : Re: Last Call:  (A
> YANG
> > > Data
> > > > Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard
> > > >
> > > > Some minor, mostly administrative, details
> > > >
> > > > - The note to the RFC Editor asking them to replace  is good.
> I
> > > > suggest  another asking them to update the dates in the file and
> > > > revision clauses of the YANG module with the date of publication..
> > >
> > > [Med] Fixed in my local copy.
> > >
> > > >
> > > > - Copyright is 2017
> > >
> > > [Med] Updated to 2018 in my local copy.
> > >
> > > >
> > > > - the YANG module has six imports but no reference to where they
> can be
> > > > found.  I suggest adding a reference clause to each import, as in
> e.g.
> > > > draft-ietf-netmod-syslog-model,
> > >
> > > [Med] Happily. Done.
> > >
> > >
> > >  and, since the reference clause cannot
> > > > contain a XML style reference to the Reference section of the I-D,
> a
> > > > further mention of these I-D/RFC in the body of the I-D, again as
> in
> > > > e.g.
> > > > draft-ietf-netmod-syslog-model
> > >
> > > [Med] Given that almost all these pointers are already mentioned in
> the core
> > > text, I added only a sentence to refer to RFC7224.
> > >
> > > >
> > > > - RFC7223 now has a bis version which I think you should use as it
> is
> > > > the NMDA version - this might affect your augments, I have not
> delved
> > > > into that yet.
> > >
> > > [Med] Now that the 7223bis is in the RFC Editor queue, I updated the
> text.
> > >
> > > >
> > > > - RFC5246 is being obsoleted and ... perhaps not:-)
> > >
> > > [Med] Yeah, but RFC5246 is part of the recommended security text for
> YANG
> > > modules
> 

Re: [Softwires] Last Call: (A YANG Data Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard

[mohamed.boucadair]

Hi Tom,

FWIW, an updated version which takes into account your review is available 
online. 

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

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

Cheers,
Med

> -Message d'origine-
> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
> Envoyé : mardi 20 février 2018 14:34
> À : tom p.
> Cc : softwires@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org; softwire-
> cha...@ietf.org; ianfar...@gmx.com; terry.mander...@icann.org; i...@ietf.org
> Objet : RE: Last Call:  (A YANG Data
> Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard
> 
> Hi Tom,
> 
> Thank you for the review and comments.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : tom p. [mailto:daedu...@btconnect.com]
> > Envoyé : mardi 20 février 2018 12:07
> > À : i...@ietf.org
> > Cc : softwires@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org;
> softwire-
> > cha...@ietf.org; ianfar...@gmx.com; terry.mander...@icann.org
> > Objet : Re: Last Call:  (A YANG
> Data
> > Module for Dual-Stack Lite (DS-Lite)) to Proposed Standard
> >
> > Some minor, mostly administrative, details
> >
> > - The note to the RFC Editor asking them to replace  is good.  I
> > suggest  another asking them to update the dates in the file and
> > revision clauses of the YANG module with the date of publication..
> 
> [Med] Fixed in my local copy.
> 
> >
> > - Copyright is 2017
> 
> [Med] Updated to 2018 in my local copy.
> 
> >
> > - the YANG module has six imports but no reference to where they can be
> > found.  I suggest adding a reference clause to each import, as in e.g.
> > draft-ietf-netmod-syslog-model,
> 
> [Med] Happily. Done.
> 
> 
>  and, since the reference clause cannot
> > contain a XML style reference to the Reference section of the I-D, a
> > further mention of these I-D/RFC in the body of the I-D, again as in
> > e.g.
> > draft-ietf-netmod-syslog-model
> 
> [Med] Given that almost all these pointers are already mentioned in the core
> text, I added only a sentence to refer to RFC7224.
> 
> >
> > - RFC7223 now has a bis version which I think you should use as it is
> > the NMDA version - this might affect your augments, I have not delved
> > into that yet.
> 
> [Med] Now that the 7223bis is in the RFC Editor queue, I updated the text.
> 
> >
> > - RFC5246 is being obsoleted and ... perhaps not:-)
> 
> [Med] Yeah, but RFC5246 is part of the recommended security text for YANG
> modules (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines).
> RFC5246 will be maintained till that reco is updated.
> 
> >
> > - RFC 6536 is being revised and will soon be in IETF Last Call
> 
> [Med] Actually, it will be published as RFC8341. I updated the text
> accordingly.
> 
> >
> > Tom Petch
> >
> > - Original Message -
> > From: "The IESG" 
> > Sent: Monday, February 12, 2018 2:28 PM
> >
> >
> > >
> > > The IESG has received a request from the Softwires WG (softwire) to
> > consider
> > > the following document: - 'A YANG Data Module for Dual-Stack Lite
> > (DS-Lite)'
> > >as Proposed Standard
> > >
> > > The IESG plans to make a decision in the next few weeks, and solicits
> > final
> > > comments on this action. Please send substantive comments to the
> > > i...@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may
> > be
> > > sent to i...@ietf.org instead. In either case, please retain the
> > beginning of
> > > the Subject line to allow automated sorting.
> > >
> > > Abstract
> > >
> > >
> > >This document defines a YANG module for the DS-Lite Address Family
> > >Transition Router (AFTR) and Basic Bridging BroadBand (B4)
> > elements.
> > >
> > > Editorial Note (To be removed by RFC Editor)
> > >
> > >Please update these statements with the RFC number to be assigned
> > to
> > >this document:
> > >
> > >o  "This version of this YANG module is part of RFC ;"
> > >
> > >o  "RFC : A YANG Data Module for Dual-Stack Lite (DS-Lite)";
> > >
> > >o  "reference: RFC "
> > >
> > >
> > >
> > >
> > > The file can be obtained via
> > > https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> > >
> > > IESG discussion can be tracked via
> > >
> > https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/ballot/
> > >
> > >
> > > No IPR declarations have been submitted directly on this I-D.
> > >
> > >
> > > The document contains these normative downward references.
> > > See RFC 3967 for additional information:
> > > draft-ietf-opsawg-nat-yang: A YANG Module for Network Address
> > Translation (NAT) (None - IETF stream)
> > >
> > >
> > >

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

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-14.txt

[mohamed.boucadair]

Re-,

Ian asked to fix some long lines to make idnits happy :) 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : mercredi 10 janvier 2018 10:59
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-dslite-yang-14.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   : A YANG Data Module for Dual-Stack Lite (DS-Lite)
> Authors : Mohamed Boucadair
>   Christian Jacquenet
>   Senthil Sivakumar
>   Filename: draft-ietf-softwire-dslite-yang-14.txt
>   Pages   : 20
>   Date: 2018-01-10
> 
> Abstract:
>This document defines a YANG module for the DS-Lite Address Family
>Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update these statements with the RFC number to be assigned to
>this document:
> 
>o  "This version of this YANG module is part of RFC ;"
> 
>o  "RFC : A YANG Data Module for Dual-Stack Lite (DS-Lite)";
> 
>o  "reference: RFC "
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-14
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-14
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-13.txt

[mohamed.boucadair]

Hi all, 

This version addresses this comment from Mahesh: 

==
Med, in the meantime, for the dslite model, can you replace the = expression in 
the 'when' statement with 'derived-from'. Thanks.
==

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de internet-
> dra...@ietf.org
> Envoyé : mercredi 10 janvier 2018 08:06
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-13.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   : A YANG Data Module for Dual-Stack Lite (DS-Lite)
> Authors : Mohamed Boucadair
>   Christian Jacquenet
>   Senthil Sivakumar
>   Filename: draft-ietf-softwire-dslite-yang-13.txt
>   Pages   : 20
>   Date: 2018-01-09
> 
> Abstract:
>This document defines a YANG module for the DS-Lite Address Family
>Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update these statements with the RFC number to be assigned to
>this document:
> 
>o  "This version of this YANG module is part of RFC ;"
> 
>o  "RFC : A YANG Data Module for Dual-Stack Lite (DS-Lite)";
> 
>o  "reference: RFC "
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-13
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-13
> 
> 
> 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] Issue with ietf-dsl...@2017-11-15.yang and yangdump-pro

[mohamed.boucadair]

Hi Andy, Benoit,

Thank you for investigating this.

A new version which fixes this issue is available online. A diff is available 
at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-11

Cheers,
Med

De : Andy Bierman [mailto:a...@yumaworks.com]
Envoyé : samedi 18 novembre 2017 22:23
À : Benoit Claise
Cc : draft-ietf-softwire-dslite-y...@ietf.org; Mahesh Jethanandani
Objet : Re: Issue with ietf-dsl...@2017-11-15.yang and yangdump-pro

Hi,

yangdump-pro is correct. Every other compiler missed it...


9.10.2.  The identityref's "base" Statement



   The "base" statement, which is a substatement to the "type"

   statement, MUST be present at least once if the type is

   "identityref".  The argument is the name of an identity, as defined

   by an "identity" statement.  If a prefix is present on the identity

   name, it refers to an identity defined in the module that was

   imported with that prefix.  Otherwise, an identity with the matching

   name MUST be defined in the current module or an included submodule.

Using ietf-dsl...@2017-11-15.yang and 
ietf-...@2017-11-15.yang

When I change 'natp44' to 'nat:natp44' in both when-stmts:

andy@andy-homedev:~/Desktop/FD1289/IETF$ yangdump-pro 
ietf-dsl...@2017-11-15.yang modpath=.

*** 
/home/andy/Desktop/FD1289/IETF/ietf-dsl...@2017-11-15.yang
*** 0 Errors, 0 Warnings

andy@andy-homedev:~/Desktop/FD1289/IETF$


Andy


On Sat, Nov 18, 2017 at 11:07 AM, Benoit Claise 
> wrote:
Hi Andy,

Can you please have a look at 
ietf-dsl...@2017-11-15.yang at 
http://www.claise.be/IETFYANGPageCompilation.html .
yangdump-pro reports a new error, while the other validators are fine.

Copying Mahesh, as YANG doctor.

Regards, Benoit


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

Re: [Softwires] Yangdoctors early review of draft-ietf-softwire-dslite-yang-02

[mohamed.boucadair]

Hi Mahesh,

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani [mailto:mjethanand...@gmail.com]
Envoyé : jeudi 16 novembre 2017 00:59
À : BOUCADAIR Mohamed IMT/OLN
Cc : yang-doct...@ietf.org; softwires@ietf.org; 
draft-ietf-softwire-dslite-yang@ietf.org; NetMod WG Chairs; Benoit Claise
Objet : Re: Yangdoctors early review of draft-ietf-softwire-dslite-yang-02

Med,

See inline.

On Nov 15, 2017, at 8:50 PM, 
mohamed.boucad...@orange.com wrote:

Hi Mahesh,

Thank you for the feedback.

Please see inline.

Cheers,
Med


-Message d'origine-
De : Mahesh Jethanandani [mailto:mjethanand...@gmail.com]
Envoyé : mardi 14 novembre 2017 23:59
À : BOUCADAIR Mohamed IMT/OLN
Cc : yang-doct...@ietf.org; 
softwires@ietf.org; draft-ietf-softwire-
dslite-yang@ietf.org; NetMod WG Chairs; 
Benoit Claise
Objet : Re: Yangdoctors early review of draft-ietf-softwire-dslite-yang-02

Mohamed,

I realize that I am responding to an earlier thread than the one you asked
your question on, so let me address the question that you asked on that
thread first.

Yes, the netmod tree diagrams draft is not an RFC, and yang-doctors do
recommend that authors of drafts with YANG module reference the netmod
tree diagram draft rather than cut and paste description of the tree
symbols into their drafts. To the question of whether that reference can
be informative or does it have to be normative, I would agree that it has
to be normative. I realize that might impact the publication of the draft,
so I am including the chairs of NETMOD WG(and one of the authors) to get
an idea of when they think the draft could be published as an RFC.

[Med] We need guidance how to proceed given that we do have two drafts in the 
softwire WG that are impacted (this one passed the WGLC, while the second one 
will be on the WGLC soon). BTW, an argument I heard recently is that the netmod 
document can be cited as informative given that the tree structure itself is 
not normative.

I did bring up the question yesterday in NETMOD, and yes the consensus in 
NETMOD is to move the tree diagram document from Standards Track to 
Informational, where it can then be cited as informational.

[Med] Thank you.


But before you rush into publication, I took another look at the -08
version of the draft, and I have additional concerns about the draft and
the YANG module in it, that I believe warrant another look.

Minor comments

- Please remove reference to chairs in the YANG module. All we recommend
are the authors/editors.

[Med] Done.


- Please add a note for the RFC editor to replace “RFC ” with the RFC
number when the draft is published.

[Med] There is already this note in the draft:

===
Editorial Note (To be removed by RFC Editor)

  Please update these statements with the RFC number to be assigned to
  this document:

  o  "This version of this YANG module is part of RFC ;"

  o  "RFC : YANG Data Modules for Dual-Stack Lite (DS-Lite)";

  o  "reference: RFC "
===


- The indentations in the YANG module are still not consistent. Please fix
them.

[Med] OK.



Additional comments:
- The YANG module makes multiple references to subscriber-mask as a way to
uniquely identity a subscriber. That, as you say is derived from the NAT
module. But the NAT module has no subscriber-mask. It has subscriber-mask-
v6. Is that what you meant to refer to?

[Med] Yes.

Please update the model/draft in that case.
[Med] Done in my local copy.



Does it mean you need a

subscriber-mask for v6 only?

[Med] Yes. The two use cases for this mask are DS-Lite and NAT64, which involve 
IPv6 addresses.

The NAT YANG modules includes the following:

   "The subscriber mask is an integer that indicates
the length of significant bits to be applied on
the source IPv6 address (internal side) to
   
unambiguously identify a user device (e.g., CPE).



- Also, you augment the NAT module at the node nat:policy. But subscriber-
mask-v6 is a child of nat:nat-policy.

[Med] Is there any problem with this?

Yes. To the extent that you cannot augment a node that does not exist in the 
tree.
[Med] Not sure to understand this one. The augmented node is nat:policy.

What is more troubling to me is that you say none of the tools have caught it. 
In the output you show below, it is not clear which NAT module you are using, 
and where it was fetched from.
[Med] The datatracker shows all these details. Please check at: 
https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/

- And, nat:nat-policy is a list with a key of policy-id. But you have no
policy-id defined in your module. How do you reference the particular
nat:nat-policy without a key? Was this model compiled/validated against
the latest NAT module?

[Med] This is derived from the nat:napt44, which is augmented with 

Re: [Softwires] Fw: I-D Action: draft-ietf-softwire-mesh-multicast-19.txt

[mohamed.boucadair]

Dear Shu,

This version is much better.

Thank you for considering my comments.

Cheers,
Med

De : 杨术 [mailto:yang...@oudmon.com]
Envoyé : mercredi 15 novembre 2017 09:22
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mingwei Xu; softwires@ietf.org
Objet : Fw:[Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-19.txt


Dear Med,

Thank you for the great advices, and we revised and updated the document 
according to them.

RFC 8114 is an important reference for our document, and we list it where 
needed.

According to RFC4925, supporting multicast is important for both hub-and-spoke 
and mesh scenario. While RFC 8114 focuses on supporting hub-and-spoke, ours 
focuses on supporting mesh. Thus we maintain this draft since Oct,2010 
(actually Sep,2006 considering draft-xu-softwire-4over6multicast-00).   
Although there are some parts in common, softwire mesh is quite different. For 
example, the basic routing mechanism in control plane between AFBR is different 
from AFTR.  Thus, we found a new standard is needed when implementing multicast 
in the mesh scenario, e.g.,CERNET2.

Best Regards,

Shu Yang

Tsinghua University





--
[https://exmail.qq.com/cgi-bin/viewfile?type=logo=oudmon.com]
杨术

欧德蒙科技有限公司

This message may contain privileged and confidential information only for the 
use of the addressee named above. If you are not the intended recipient of this 
message you are hereby notified that any use, distribution or reproduction of 
this message is prohibited. If you have received this message in error please 
notify the sender immediately.



-- Original --
From:  
"internet-drafts">;
Date:  Wed, Nov 15, 2017 04:13 PM
To:  "i-d-announce">;
Cc:  "softwires">;
Subject:  [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-19.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   : IPv4 Multicast over an IPv6 Multicast in Softwire 
Mesh Network
Authors : Mingwei Xu
  Yong Cui
  Jianping Wu
  Shu Yang
  Chris Metz
  Greg Shepherd
Filename: draft-ietf-softwire-mesh-multicast-19.txt
Pages   : 19
Date: 2017-11-15

Abstract:
   During IPv6 transition, there will be scenarios where a backbone
   network running one IP address family internally (referred to as
   internal IP or I-IP), while the attached client networks running
   another IP address family (referred to as external IP or E-IP).  The
   I-IP backbone should offer both unicast and multicast transit
   services to the client E-IP networks.

   This document describes the mechanism for supporting multicast across
   a set of E-IP and I-IP networks supporting softwire mesh.  The
   document focuses on IPv4-over-IPv6 scenario, due to lack of real-
   world use cases for IPv6-over-IPv4 scenario.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-mesh-multicast-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] Yangdoctors early review of draft-ietf-softwire-dslite-yang-02

[mohamed.boucadair]

Hi Mahesh, 

Thank you for the feedback. 

Please see inline. 

Cheers,
Med 

> -Message d'origine-
> De : Mahesh Jethanandani [mailto:mjethanand...@gmail.com]
> Envoyé : mardi 14 novembre 2017 23:59
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : yang-doct...@ietf.org; softwires@ietf.org; draft-ietf-softwire-
> dslite-yang@ietf.org; NetMod WG Chairs; Benoit Claise
> Objet : Re: Yangdoctors early review of draft-ietf-softwire-dslite-yang-02
> 
> Mohamed,
> 
> I realize that I am responding to an earlier thread than the one you asked
> your question on, so let me address the question that you asked on that
> thread first.
> 
> Yes, the netmod tree diagrams draft is not an RFC, and yang-doctors do
> recommend that authors of drafts with YANG module reference the netmod
> tree diagram draft rather than cut and paste description of the tree
> symbols into their drafts. To the question of whether that reference can
> be informative or does it have to be normative, I would agree that it has
> to be normative. I realize that might impact the publication of the draft,
> so I am including the chairs of NETMOD WG(and one of the authors) to get
> an idea of when they think the draft could be published as an RFC.
> 

[Med] We need guidance how to proceed given that we do have two drafts in the 
softwire WG that are impacted (this one passed the WGLC, while the second one 
will be on the WGLC soon). BTW, an argument I heard recently is that the netmod 
document can be cited as informative given that the tree structure itself is 
not normative. 

> But before you rush into publication, I took another look at the -08
> version of the draft, and I have additional concerns about the draft and
> the YANG module in it, that I believe warrant another look.
> 
> Minor comments
> 
> - Please remove reference to chairs in the YANG module. All we recommend
> are the authors/editors.

[Med] Done.

> - Please add a note for the RFC editor to replace “RFC ” with the RFC
> number when the draft is published.

[Med] There is already this note in the draft: 

===
Editorial Note (To be removed by RFC Editor)

   Please update these statements with the RFC number to be assigned to
   this document:

   o  "This version of this YANG module is part of RFC ;"

   o  "RFC : YANG Data Modules for Dual-Stack Lite (DS-Lite)";

   o  "reference: RFC " 
===

> - The indentations in the YANG module are still not consistent. Please fix
> them.

[Med] OK.

> 
> Additional comments:
> - The YANG module makes multiple references to subscriber-mask as a way to
> uniquely identity a subscriber. That, as you say is derived from the NAT
> module. But the NAT module has no subscriber-mask. It has subscriber-mask-
> v6. Is that what you meant to refer to?

[Med] Yes. 

 Does it mean you need a
> subscriber-mask for v6 only?

[Med] Yes. The two use cases for this mask are DS-Lite and NAT64, which involve 
IPv6 addresses.

The NAT YANG modules includes the following: 

"The subscriber mask is an integer that indicates
 the length of significant bits to be applied on
 the source IPv6 address (internal side) to

 unambiguously identify a user device (e.g., CPE).


> - Also, you augment the NAT module at the node nat:policy. But subscriber-
> mask-v6 is a child of nat:nat-policy.

[Med] Is there any problem with this? 

> - And, nat:nat-policy is a list with a key of policy-id. But you have no
> policy-id defined in your module. How do you reference the particular
> nat:nat-policy without a key? Was this model compiled/validated against
> the latest NAT module?

[Med] This is derived from the nat:napt44, which is augmented with DS-Lite 
specifics. 

I confirm that the module was successfully validated:

=
xym 0.4:
Extracting 'ietf-dslite-a...@2017-11-14.yang'
   Removed 0 empty lines
Extracting 'ietf-dslite...@2017-11-13.yang'
   Removed 0 empty lines


ietf-dslite...@2017-11-13.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.13.79: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} 
{model} -i:
No validation errors


ietf-dslite-a...@2017-11-14.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.13.79: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} 
{model} -i:
No validation errors
===

I can add an explicit "when" statement that will look like:

when "/nat:nat/nat:instances/nat:instance/nat:type='napt44'";

This will require updating the NAT YANG module to specify explicitly a NAT 
Type. 

> - You augment nat:mapping-entry, which is also a list with a key of
> ‘index’. Where are you deriving ‘index’ from?

[Med] Idem as above.

> - b4-ipv4-address has a default value of 192.0.0.2, and you have a note
> that the mask is /29. Are all ipv4 addresses configured with /29 mask? If
> not, how is netmask indicated to the device?

[Med] This is 

Re: [Softwires] Tags changed for draft-ietf-softwire-dslite-yang

[mohamed.boucadair]

Ian,

I fixed both points in -09.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : lundi 13 novembre 2017 13:16
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwire-cha...@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org; 
Softwires list
Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang

Hi Med,

Please see inline.

Cheers,
Ian

On 13. Nov 2017, at 18:28, 
> 
> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : lundi 13 novembre 2017 10:00
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwire-cha...@ietf.org; 
draft-ietf-softwire-dslite-y...@ietf.org;
 Softwires list
Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang

Hi Med,

Thanks for the update. I’ve just checked through this version. For some reason, 
section 1.2 has reverted to an earlier version with explicit instructions for 
the tree diagram (this wasn’t the case in 07). This was from Mahesh’s YANG 
doctor review, and your response from 9th October:

[Med] I have implemented the change because I thought that document is advanced 
in the publication process. But when I recently checked, I found the document 
is not that advanced in the process. I removed citing that document to avoid a 
normative dependency which can be avoided by explicitly inserting the 
appropriate text.

[if - It was only cited as an informative reference in 07, so there shouldn’t 
be a dependency problem]



---
Section 1.2 Tree Diagram

Please refer to
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01
instead of
defining the nomenclature for tree diagram in the document.

[Med] Done. Thanks.
—

For my comment about rate limiting changes to the b4-ipv6-address. There is now 
a node for setting the permitted change interval, but I don’t see how I can use 
the model to check if a new address offered by a client is allowable.
My thinking is that if there was a ‘last-address-change yang:date-and-time’ 
leaf under leaf b4-ipv6-address, then it is easy to use the model to see if an 
address change is permitted, or even raise a notification if it is not.

[Med] Are you asking for something similar to: 
https://github.com/boucadair/draft-ietf-softwire-dslite-yang/commit/5f37cf90ddadeec544e8087c1643d3bf923e7d5d?

My point is, if a client is trying to change its address more regularly than 
the policy allows, then they probably don’t have IPv4 service from when their 
address has changed until the AFTR policy allows the source address change. If 
this is happening en-masse (either from a single or many clients) for any 
reason, an operator probably wants to know about it.


[if - Yes. Looks good. Can I propose the following change to the name and 
description:

Old:
 notification too-fast-b4-address-change-event {
   description
 "Notifications must be generated when a B4's IPv6 address change
  is discarded because of b4-address-change-limit.";

New:
 notification  b4-address-change-limit-policy-violation {
   description
 “Generates notifications when a B4 unsuccessfully attempts to change IPv6 
address
  in a time shorter than the value of 'b4-address-change-limit.";

]



Cheers,
Ian

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

Re: [Softwires] IPR Poll for draft-ietf-softwire-dslite-yang

[mohamed.boucadair]

Hi Ian,

I have no IPR nor I'm aware of any related to this draft.

Thank you.

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Ian
> Farrer
> Envoyé : mardi 14 novembre 2017 02:57
> À : draft-ietf-softwire-dslite-y...@ietf.org
> Cc : Softwires list
> Objet : [Softwires] IPR Poll for draft-ietf-softwire-dslite-yang
> 
> Hi Authors,
> 
> Please reply to this email including the mailing list indicating whether
> you are aware of any IPR related to draft-ietf-softwire-dslite-yang.
> 
> Thanks,
> Ian
> 
> ___
> 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] Tags changed for draft-ietf-softwire-dslite-yang

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : lundi 13 novembre 2017 13:16
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwire-cha...@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org; 
Softwires list
Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang

Hi Med,

Please see inline.

Cheers,
Ian

On 13. Nov 2017, at 18:28, 
> 
> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : lundi 13 novembre 2017 10:00
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwire-cha...@ietf.org; 
draft-ietf-softwire-dslite-y...@ietf.org;
 Softwires list
Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang

Hi Med,

Thanks for the update. I’ve just checked through this version. For some reason, 
section 1.2 has reverted to an earlier version with explicit instructions for 
the tree diagram (this wasn’t the case in 07). This was from Mahesh’s YANG 
doctor review, and your response from 9th October:

[Med] I have implemented the change because I thought that document is advanced 
in the publication process. But when I recently checked, I found the document 
is not that advanced in the process. I removed citing that document to avoid a 
normative dependency which can be avoided by explicitly inserting the 
appropriate text.

[if - It was only cited as an informative reference in 07, so there shouldn’t 
be a dependency problem]
[Med] The point is that I’m questioning that citation as an informative 
reference. Because a reader must look at that document to understand the 
meaning of the symbols, it should be cited as a normative reference. Unless you 
have a strong objection, I suggest to maintain the current text.



---
Section 1.2 Tree Diagram

Please refer to
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01
instead of
defining the nomenclature for tree diagram in the document.

[Med] Done. Thanks.
—

For my comment about rate limiting changes to the b4-ipv6-address. There is now 
a node for setting the permitted change interval, but I don’t see how I can use 
the model to check if a new address offered by a client is allowable.
My thinking is that if there was a ‘last-address-change yang:date-and-time’ 
leaf under leaf b4-ipv6-address, then it is easy to use the model to see if an 
address change is permitted, or even raise a notification if it is not.

[Med] Are you asking for something similar to: 
https://github.com/boucadair/draft-ietf-softwire-dslite-yang/commit/5f37cf90ddadeec544e8087c1643d3bf923e7d5d?

My point is, if a client is trying to change its address more regularly than 
the policy allows, then they probably don’t have IPv4 service from when their 
address has changed until the AFTR policy allows the source address change. If 
this is happening en-masse (either from a single or many clients) for any 
reason, an operator probably wants to know about it.


[if - Yes. Looks good. Can I propose the following change to the name and 
description:

Old:
 notification too-fast-b4-address-change-event {
   description
 "Notifications must be generated when a B4's IPv6 address change
  is discarded because of b4-address-change-limit.";

New:
 notification  b4-address-change-limit-policy-violation {
   description
 “Generates notifications when a B4 unsuccessfully attempts to change IPv6 
address
  in a time shorter than the value of 'b4-address-change-limit.";

]

[Med] Looks good to me. Thanks.




Cheers,
Ian

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

Re: [Softwires] Tags changed for draft-ietf-softwire-dslite-yang

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : lundi 13 novembre 2017 10:00
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwire-cha...@ietf.org; draft-ietf-softwire-dslite-y...@ietf.org; 
Softwires list
Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang

Hi Med,

Thanks for the update. I’ve just checked through this version. For some reason, 
section 1.2 has reverted to an earlier version with explicit instructions for 
the tree diagram (this wasn’t the case in 07). This was from Mahesh’s YANG 
doctor review, and your response from 9th October:

[Med] I have implemented the change because I thought that document is advanced 
in the publication process. But when I recently checked, I found the document 
is not that advanced in the process. I removed citing that document to avoid a 
normative dependency which can be avoided by explicitly inserting the 
appropriate text.

---
Section 1.2 Tree Diagram

Please refer to
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01
instead of
defining the nomenclature for tree diagram in the document.

[Med] Done. Thanks.
—

For my comment about rate limiting changes to the b4-ipv6-address. There is now 
a node for setting the permitted change interval, but I don’t see how I can use 
the model to check if a new address offered by a client is allowable.
My thinking is that if there was a ‘last-address-change yang:date-and-time’ 
leaf under leaf b4-ipv6-address, then it is easy to use the model to see if an 
address change is permitted, or even raise a notification if it is not.

[Med] Are you asking for something similar to: 
https://github.com/boucadair/draft-ietf-softwire-dslite-yang/commit/5f37cf90ddadeec544e8087c1643d3bf923e7d5d?

My point is, if a client is trying to change its address more regularly than 
the policy allows, then they probably don’t have IPv4 service from when their 
address has changed until the AFTR policy allows the source address change. If 
this is happening en-masse (either from a single or many clients) for any 
reason, an operator probably wants to know about it.

Cheers,
Ian





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

Re: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

[mohamed.boucadair]

Hi Ian,

Fixed.

Thanks.
Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : lundi 13 novembre 2017 04:35
À : BOUCADAIR Mohamed IMT/OLN
Cc : Softwires list; draft-ietf-softwire-dslite-y...@ietf.org
Objet : Re: [Softwires] Work Group Last call for 
draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

Hi Med,

One small additional change (I don’t know why I haven’t seen this before) - 
Please can you rename the document 'YANG Data Modules for Dual-Stack Lite’ to 
be inline with the naming of other related RFCs.

Thanks,
Ian

On 10. Nov 2017, at 20:17, 
> 
> wrote:

Re-,

OK. The updated version with your comments will be submitted next Monday.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : vendredi 10 novembre 2017 12:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : Softwires list; 
draft-ietf-softwire-dslite-y...@ietf.org
Objet : Re: [Softwires] Work Group Last call for 
draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

Hi Med,




Model comments:
m1. v6-v4-dscp-preservation - deals with whether the DCSP of the incoming
packet will be copied to the header of the outgoing packet or not.
Would this be better implemented as a feature in the model, as this would
allow the use in the mapping entry to be made conditional (with if-
feature) under the mapping-entry augment.

[Med] This is better handled by adding this statement:

   when 
"/if:interfaces/if:interface/dslite-aftr:v6-v4-dscp-preservation='true'";



Yes, that works.

Cheers,
Ian

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

Re: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

[mohamed.boucadair]

Re-,

OK. The updated version with your comments will be submitted next Monday.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : vendredi 10 novembre 2017 12:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : Softwires list; draft-ietf-softwire-dslite-y...@ietf.org
Objet : Re: [Softwires] Work Group Last call for 
draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

Hi Med,



Model comments:
m1. v6-v4-dscp-preservation - deals with whether the DCSP of the incoming
packet will be copied to the header of the outgoing packet or not.
Would this be better implemented as a feature in the model, as this would
allow the use in the mapping entry to be made conditional (with if-
feature) under the mapping-entry augment.

[Med] This is better handled by adding this statement:

   when 
"/if:interfaces/if:interface/dslite-aftr:v6-v4-dscp-preservation='true'";


Yes, that works.

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

Re: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

[mohamed.boucadair]

Hi Ian, 

Thank you for the review. 

All your comments are addressed. Please check the version available at: 
https://github.com/boucadair/draft-ietf-softwire-dslite-yang 

See inline.

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Ian
> Farrer
> Envoyé : vendredi 10 novembre 2017 10:16
> À : Softwires list
> Cc : draft-ietf-softwire-dslite-y...@ietf.org
> Objet : Re: [Softwires] Work Group Last call for draft-ietf-softwire-
> dslite-yang-07 - Ends 9th Nov
> 
> Hi,
> 
> Here’s my review of v07 of the draft.
> 
> Cheers,
> Ian
> 
> Overall comments:
> o1. There is a lot of duplication of text between the descriptions given
> in Section 2 and the YANG model’s description fields. This makes the
> document less readable, and I don’t see it adds anything.
> As much of the text in section 2 is taken directly from the RFCs that
> originally defined the functions, it would be better to remove the section
> 2 descriptions where not necessary (i.e. only described/enumerate the
> important nodes in reference to how they are used/relate to other models,
> and have pointers to the original RFC/section where more detail is
> necessary).
> Keeping the more verbose descriptions in the model make sense as these are
> the ones that most users will actually see once published.

[Med] Done. 

> 
> 
> Model comments:
> m1. v6-v4-dscp-preservation - deals with whether the DCSP of the incoming
> packet will be copied to the header of the outgoing packet or not.
> Would this be better implemented as a feature in the model, as this would
> allow the use in the mapping entry to be made conditional (with if-
> feature) under the mapping-entry augment.

[Med] This is better handled by adding this statement:

when 
"/if:interfaces/if:interface/dslite-aftr:v6-v4-dscp-preservation='true'";

> 
> m2. Recommendation 3 of RFC7785 describes a rate limit for how often a
> source address can be migrated. The model doesn’t give any way of
> configuring this. Also, if there is a rate limit on the source address
> change rate, a timestamp as to when the b4-ipv6-address was updated would
> be useful.
> 

[Med] Good point. Updated accordingly. 

> 
> Gramatical Comments:
> Section 1
> g1. s/and adopts Network Management Datastore Architecture (NMDA)./and
> adopts the Network Management Datastore Architecture (NMDA)./
> 
> 
> Section 2
> g2. s/ The tunnel MTU to avoid fragmentation/The tunnel MTU, used to avoid
> fragmentation/
> 
> g3. The bullet point starting ‘The IPv4 DSCP marking of the IPv4 packet’
> finishes with the following sentence
> ' This information can be used by the AFTR fro enforcing the poi’. Unsure
> what this is meant to say.
> 
> 
> Section 7
> g4. s/eraly ynagdoctors/early yangdoctors/
> 
> g5. s/comments/comments./
> 

[Med] Fixed all those. 

> 
> 
> > On 26. Oct 2017, at 09:09, Ian Farrer  wrote:
> >
> > Hi,
> >
> > The authors believe that draft-ietf-softwire-dslite-yang-07 is now ready
> for advancement. This email marks the start of a 2 week work group last
> call for the draft.
> >
> > Please send your comments, either for or against, to the softwire WG
> mailing list. The WGLC will end on Nov. 9, 2017.
> >
> > Thanks,
> >
> > Yong & Ian
> > ___
> > 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 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-18.txt

[mohamed.boucadair]

Dear all, 

FWIW, you may find some comments 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-softwire-mesh-multicast-18-rev%20Med.doc
 

I do still think that this document should be positioned as an applicability 
statement of RFC8114 for the full mesh scenario.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : lundi 25 septembre 2017 08:15
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-mesh-multicast-18.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   : Softwire Mesh Multicast
> Authors : Mingwei Xu
>   Yong Cui
>   Jianping Wu
>   Shu Yang
>   Chris Metz
>   Greg Shepherd
>   Filename: draft-ietf-softwire-mesh-multicast-18.txt
>   Pages   : 19
>   Date: 2017-09-24
> 
> Abstract:
>The Internet needs to support IPv4 and IPv6 packets.  Both address
>families and their related protocol suites support multicast of the
>single-source and any-source varieties.  During IPv6 transition,
>there will be scenarios where a backbone network running one IP
>address family internally (referred to as internal IP or I-IP), while
>the attached client networks running another IP address family
>(referred to as external IP or E-IP).  The I-IP backbone should offer
>both unicast and multicast transit services to the client E-IP
>networks.
> 
>Softwire Mesh is a solution providing E-IP unicast and multicast
>support across an I-IP backbone.  This document describes the
>mechanism for supporting Internet-style multicast across a set of
>E-IP and I-IP networks supporting softwire mesh.  We focus on IPv4-
>over-IPv6 scenario in this document, due to lack of real-world use
>cases for IPv6-over-IPv4 scenario.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-18
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-
> 18
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-mesh-multicast-18
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-07.txt

[mohamed.boucadair]

Dear all,

This version integrates some of the comments received from the yangdoctors. 

The document is IMO ready for a WG LC.

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de internet-
> dra...@ietf.org
> Envoyé : mardi 10 octobre 2017 14:31
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-07.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   : YANG Data Modules for the DS-Lite
> Authors : Mohamed Boucadair
>   Christian Jacquenet
>   Senthil Sivakumar
>   Filename: draft-ietf-softwire-dslite-yang-07.txt
>   Pages   : 22
>   Date: 2017-10-10
> 
> Abstract:
>This document defines YANG modules for the DS-Lite Address Family
>Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements .
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-07
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-07
> 
> 
> 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] Yangdoctors early review of draft-ietf-softwire-dslite-yang-02

[mohamed.boucadair]

Dear Mahesh, 

Thank you very much for the detailed review. Much appreciated. 

It seems that you reviewed -02 of the draft, while the latest version is -06 
(https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/).

As you can see below, almost all the comments do not apply for -06.

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Mahesh Jethanandani [mailto:mjethanand...@gmail.com]
> Envoyé : samedi 7 octobre 2017 02:17
> À : yang-doct...@ietf.org
> Cc : softwires@ietf.org; draft-ietf-softwire-dslite-yang@ietf.org;
> i...@ietf.org
> Objet : Yangdoctors early review of draft-ietf-softwire-dslite-yang-02
> 
> Reviewer: Mahesh Jethanandani
> Review result: On the Right Track
> 
> Document reviewed: draft-ietf-softwire-dslite-yang-02. Do not know why I
> was
> assigned -02 version when I now notice that there are several 03 versions
> submitted all the way up to -06.
> 
> Status: On the Right Track.
> 
> I am not an expert in DS-Lite. This review is looking at the draft from a
> YANG
> perspective. With that said, I have marked it as “On the Right Track”
> because
> of some of the points discussed below. The authors are encouraged to spend
> time
> looking at other models for examples on how to write the model, read
> RFC6087,
> Guidelines for YANG documents.
> 
> Summary:
> 
> This document defines a YANG data model for the DS-Lite Address Family
> Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements .
> 
> Overall Comments:
> 
> The draft should refer to YANG 1.1 (RFC 7950) instead of RFC6020.

[Med] Can fix this one. 

> 
> The draft is not NMDA compliant. It carries a separate -state container
> that
> needs to be collapsed into one single container. For example, it carries
> containers such as aftr-current-config which seems to be carrying state
> information for the leafs in dslite-config.

[Med] There are no such containers in -06.

> 
> Is it given that a server will implement both AFTR and B4?
[Med] No.

 If not, then
> please
> define feature statements and use if-feature for each part (AFTR and B4),
> so
> implementors can choose what part of the model is implemented.
> 
> Section 1.1 Terminology
> 
> What terms are defined in RFC 6333 that are being used in this draft.
> Please be
> explicit.

[Med] Actually, all the terms defined in Section 3 of RFC 6333 are used in this 
document. I added an explicit pointer to Section 3.

> 
> Section 1.2 Tree Diagram
> 
> Please refer to
> https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01
> instead of
> defining the nomenclature for tree diagram in the document.

[Med] Done. Thanks.

> 
> Section 2.
> 
> s/can:/can

[Med] There is no such occurrence in -06.

> s/provisioned to the AFTR/provisioned on the AFTR/

[Med] There is no such occurrence in -06.

> 
> The document is very light in the architectural description of the YANG
> model
> itself. Statements like “model supports enabling one or more instances of
> the
> AFTR function on a device” are obvious looking at the model. A more
> reasonable
> description would be why multiple instances need to be supported. The same
> is
> true for “AFTR instance”. The fact that the instance has been defined as a
> list
> assure that each instance can be provisioned with dedicated configuration
> data,
> and maintain its own data table. Again why the multiple instances need to
> be
> maintained, what purpose do they serve, and the fact that they maintain
> their
> own data table is not clear.
> 
> The document “assumes [RFC4787] [RFC5382][RFC 5508] are enabled”. What
> particular aspects of those documents is the draft assuming? Note, RFC4787
> is
> NAT Behavioral Requirements for Unicast UDP, and outlines some seven
> behaviors,
> all the way from NAT and Port Translation, Filtering, Hairpinning to
> Fragmentation of Outgoing Packets. Even if all the behaviors are assumed,
> it
> would be good to know how they impact this particular model.

[Med] What it meant is that all the recommendations are supported + all 
recommended values are the ones defined in those RFCs.

> 
> Section 3
> 
> General Comments.
> 
> Please follow [RFC6087], Guidelines for YANG documents, on how to write a
> YANG
> model. For example, the organization in the model should be IETF Softwire
> WG,
> not just Softwire WG.
> 
> The indentation in the model is off in a few places (reference is a
> keyword
> that should be at the same indentation as description in all revision
> statements). Most models follow an indentation of 2 characters for every
> subsequent depth in the model. I see anywhere between 2 to 10 characters
> of
> indentation.
> 

[Med] Will double check. Thanks.


> As far as naming conventions go, there is little value repeating names in
> a
> given hierarchy. For example, if the grouping is aftr-parameters, then it
> is a
> given that parameters inside the grouping are aftr parameters. No need to
> say
> dslite-aftr-ipv6-address, where both dslite and aftr 

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-06.txt

[mohamed.boucadair]

Dear all, 

Given that the NAT YANG modules is now adopted in OPSAWG, this draft is updated 
accordingly. 

Further, some examples to illustrate the use of the DS-Lite YANG module are 
included as an appendix.

Chairs, can you please arrange for an early YANG doctors review of the 
document? Thank you. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de internet-
> dra...@ietf.org
> Envoyé : lundi 21 août 2017 15:12
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-06.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   : YANG Data Models for the DS-Lite
> Authors : Mohamed Boucadair
>   Christian Jacquenet
>   Senthil Sivakumar
>   Filename: draft-ietf-softwire-dslite-yang-06.txt
>   Pages   : 20
>   Date: 2017-08-21
> 
> Abstract:
>This document defines YANG data models for the DS-Lite Address Family
>Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements .
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-06
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-06
> 
> 
> 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] YANG validation issue with draft-ietf-softwire-dslite-yang-05.txt

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

De : Benoit Claise [mailto:bcla...@cisco.com]
Envoyé : vendredi 11 août 2017 14:50
À : BOUCADAIR Mohamed IMT/OLN; draft-ietf-softwire-dslite-y...@ietf.org; 
softwires@ietf.org; draft-sivakumar-yang-...@ietf.org
Objet : Re: YANG validation issue with draft-ietf-softwire-dslite-yang-05.txt

Hi Med,

That's very good that you are NMDA compliant.

I didn't pay much attention and thought that both ietf-dslite-aftr@2017-08-10 
and ietf-...@2017-07-03.yang were part of 
draft-ietf-softwire-dslite-yang-05.txt

[Med] We used to have both NAT and softwire aspects covered in the same module, 
but that design is not clean. We need to separate both.

Actually ietf-...@2017-07-03.yang comes from 
https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/
Since ietf-dslite-aftr@2017-08-10 imports 
ietf-...@2017-07-03.yang, the next step is to 
modify ietf-...@2017-07-03.yang to be NMDA 
compliant, right?

[Med] Yes, we will publish the new NAT module soon.

Also, how can draft-ietf-softwire-dslite-yang progress without progressing this 
normative reference?

[Med] There is a call for adoption of the NAT YANG in OPSAWG : 
https://www.ietf.org/mail-archive/web/opsawg/current/msg04975.html.


8.1.  Normative references



   [I-D.sivakumar-yang-nat]

  Sivakumar, S., Boucadair, M., and S. Vinapamula, "YANG

  Data Model for Network Address Translation (NAT)", draft-

  sivakumar-yang-nat-07 (work in progress), July 2017.
Regards, Benoit


Hi Benoit,



Please see inline.



Cheers,

Med



-Message d'origine-

De : Benoit Claise [mailto:bcla...@cisco.com]

Envoyé : vendredi 11 août 2017 11:01

À : 
draft-ietf-softwire-dslite-y...@ietf.org;
 softwires@ietf.org

Objet : YANG validation issue with draft-ietf-softwire-dslite-yang-05.txt



Dear authors,



I see that you posted a new version, but there are still some errors

See http://www.claise.be/IETFYANGPageCompilation.html

See https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/ =>

YANG validation



OLD:

augment "/nat:nat-module/nat:nat-instances/nat:nat-instance" {



NEW: I guess this should be

augment "/nat:nat-config/nat:nat-instances/nat:nat-instance" {





[Med] Actually, the OLD one is correct. We changed the NAT module to be aligned 
with the NDMA recommendation (so, we don't have any more nat-config)









OLD:

augment

"/nat:nat-module/nat:nat-instances/nat:nat-instance/nat:mapping-

table/nat:mapping-entry"{



NEW: I guess this should be

augment

"/nat:nat-state/nat:nat-instances/nat:nat-instance/nat:mapping-

table/nat:mapping-entry"{





[Med] Idem as above. We don't have anymore a nat-state in the new NAT module.





Attached is the updated YANG module that validates.





[Med] Thank you.



Regards, Benoit







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

Re: [Softwires] YANG validation issue with draft-ietf-softwire-dslite-yang-05.txt

[mohamed.boucadair]

Hi Benoit, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Benoit Claise [mailto:bcla...@cisco.com]
> Envoyé : vendredi 11 août 2017 11:01
> À : draft-ietf-softwire-dslite-y...@ietf.org; softwires@ietf.org
> Objet : YANG validation issue with draft-ietf-softwire-dslite-yang-05.txt
> 
> Dear authors,
> 
> I see that you posted a new version, but there are still some errors
> See http://www.claise.be/IETFYANGPageCompilation.html
> See https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/ =>
> YANG validation
> 
> OLD:
> augment "/nat:nat-module/nat:nat-instances/nat:nat-instance" {
> 
> NEW: I guess this should be
> augment "/nat:nat-config/nat:nat-instances/nat:nat-instance" {
> 

[Med] Actually, the OLD one is correct. We changed the NAT module to be aligned 
with the NDMA recommendation (so, we don't have any more nat-config)

> 
> 
> OLD:
> augment
> "/nat:nat-module/nat:nat-instances/nat:nat-instance/nat:mapping-
> table/nat:mapping-entry"{
> 
> NEW: I guess this should be
> augment
> "/nat:nat-state/nat:nat-instances/nat:nat-instance/nat:mapping-
> table/nat:mapping-entry"{
> 

[Med] Idem as above. We don't have anymore a nat-state in the new NAT module. 

> 
> Attached is the updated YANG module that validates.
> 

[Med] Thank you.

> Regards, Benoit
> 
> 

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

Re: [Softwires] Fwd: Re: I-D Action: draft-ietf-softwire-lightweight-4over6-deployment-01.txt

[mohamed.boucadair]

Hi Yannis,

Please see inline.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Yannis 
Nikolopoulos
Envoyé : mercredi 9 août 2017 16:33
À : Softwires WG
Objet : [Softwires] Fwd: Re: I-D Action: 
draft-ietf-softwire-lightweight-4over6-deployment-01.txt


forwarding this to the list also, in case anyone cares to comment
regards,
Yannis

 Forwarded Message 
Subject:

Re: [Softwires] I-D Action: 
draft-ietf-softwire-lightweight-4over6-deployment-01.txt

Date:

Sat, 8 Jul 2017 23:13:29 +0300

From:

Yannis Nikolopoulos 

To:

yiu_...@cable.comcast.com, 
xie...@ctbri.com.cn, 
fib...@gmail.com, tianxiang li 
, Farrer, Ian (DTAG) 


CC:

Nikolopoulos Yannis 



Dear authors ,



as I said in the past, I believe that this is a very useful draft. We,

at OTE Greece are also deploying LW4o6 so if

you need to enrich the draft's test cases let me know.



Also, please find a few comments below:



"1. intro



 The logging requirements to meet regulatory requirements may be

  reduced as it is only necessary to log when a subscriber is

  provisioned or de-provisioned in the lwAFTR.  This relaxes the

  need for logging on a per-session, or per port block allocation."



[YN]: One still cannot comply with regulatory requirements because of

the A+P model (and because most servers on the internet do not log the

client's port number).So, how are the regulatory requirements reduced?



[Med] You are right. That text you quoted should explicitly mention that it 
assume that source port logging is used or that authorities in a given country 
are OK with reveal all the subscribers that are sharing a given address. This 
may be acceptable if a low address sharing ratio is used.



BTW, these considerations are not unique to A+P, but are the same for DS-Lite 
when port ranges are in used. In a DS-Lite context, logging the destination 
address + timestamping may be adequate, but there are trade-offs there: see 
https://tools.ietf.org/html/rfc6908#section-2.3



This following text should be updated:



OLD:


   This can bring a number of advantages when compared to DS-Lite:

   o  Per-subscriber configuration allows for the operator to provision
  each subscriber according to their specific service requirements.

  o  The logging requirements to meet regulatory requirements may be
  reduced as it is only necessary to log when a subscriber is
  provisioned or de-provisioned in the lwAFTR.  This relaxes the
  need for logging on a per-session, or per port block allocation.

   o  In some lw4o6 deployment topologies, the removal of per-session
  state means that it is possible to have very large parallelisation
  of lwAFTR elements.  This offers excellent scaling and resilience.

   o  This mechanism preserves the dynamic feature of IPv4/IPv6 address
  binding as in DS-Lite, so it has no coupling between IPv6 address
  and IPv4 address/port-set as any full stateless solution
  ([RFC6052] or 
[RFC7597]) requires.



NEW:


   This can bring a number of advantages when compared to DS-Lite:

   o  In some lw4o6 deployment topologies, the removal of per-session
  state means that it is possible to have very large parallelisation
  of lwAFTR elements.  This offers excellent scaling and resilience.



All other items are also valid for DS-Lite.





"3.1.  IP Addressing and Routing



   In Lightweight 4over6, there is no inter-dependency between the IPv4

   and IPv6 addressing schemes.  This allows for complete flexibilty in

   addressing architecture."



[YN]: although true, the above statement can be a bit misleading. I

believe that it should be mentioned that a proper addressing scheme for

IPv6 (lw4o6 esp.) should already be in place and ideally, IPv4 ranges

should be predefined (for routing efficienncy, e.g contiguous ranges)



[Med] I do think the text you quoted is accurate. There is no inter-dependency 
between IPv6 addressing and IPv4 one.



"3.1.1.  IPv4 Routing



   The IPv4 addresses/prefixes that are allocated to customer's lwB4s

   are advertised to the IPv4 Internet as being reachable via the

   lwAFTR(s).  If multiple lwAFTRs are all serving the same set of

   lwB4s, all will advertise the same IPv4 reachable routes."



YN: if multiple lwAFTRs, IPv4 prefixes could also be split, for routing

efficiency. That all depends on operator's and operator's upstream

topology and PoPs



[Med] Agree.





best regards,



Yannis





On 07/03/2017 06:58 PM, 
internet-dra...@ietf.org wrote:

> A New Internet-Draft is available from 

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-04.txt

[mohamed.boucadair]

Dear all 

The module is updated to be designed as an augment of the NAT YANG module 
(which is being discussed in OPSAWG). This design is much more cleaner.

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de internet-
> dra...@ietf.org
> Envoyé : mercredi 2 août 2017 16:28
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-04.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   : YANG Data Models for the DS-Lite
> Authors : Mohamed Boucadair
>   Christian Jacquenet
>   Senthil Sivakumar
>   Filename: draft-ietf-softwire-dslite-yang-04.txt
>   Pages   : 16
>   Date: 2017-08-02
> 
> Abstract:
>This document defines a YANG data model for the DS-Lite Address
>Family Transition Router (AFTR) and Basic Bridging BroadBand (B4)
>elements .
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-04
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-04
> 
> 
> 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] WGLC For draft-ietf-softwire-mesh-multicast - Please respond by 23rd March

[mohamed.boucadair]

Hi Ian, all,

The comments I have about this document are the following:

* Instead of (re)specifying the behavior it would be more appropriate to refer 
to draft-ietf-softwire-dslite-multicast (RFC8114) when it makes sense (e.g., 
AFBR behavior, address mapping, CP, DP, etc.). 

* The document says the following:

   The mPrefix46 for SSM mode is also defined in Section 4.1 of
   [RFC7371]

This is not true. RFC7371 is about flag bits not MPREFIX64. 

Instead of referring to RFC7371, adding a pointer to Section 5 of 
draft-ietf-softwire-dslite-multicast would make sense. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Ian
> Farrer
> Envoyé : jeudi 9 mars 2017 17:22
> À : Softwires-wg
> Objet : [Softwires] WGLC For draft-ietf-softwire-mesh-multicast - Please
> respond by 23rd March
> 
> Hi,
> 
> The authors of draft-ietf-softwire-mesh-multicast-15 believe this document
> is ready for advancement. We would like to issue a two week working group
> last call finishing on 23rd March.
> 
> Please send any substantive comments to the list and express your opinion
> on whether this draft is ready for publication. You are also welcome to
> send your editorial comments directly to the authors.
> 
> Thanks,
> Yong & Ian
> 
> ___
> 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] Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix-option-12: (with DISCUSS)

[mohamed.boucadair]

Hi Suresh,

Please see inline.

Cheers,
Med

De : Suresh Krishnan [mailto:suresh.krish...@ericsson.com]
Envoyé : jeudi 2 février 2017 15:00
À : BOUCADAIR Mohamed IMT/OLN
Cc : The IESG; draft-ietf-softwire-multicast-prefix-opt...@ietf.org; 
softwire-cha...@ietf.org; Ian Farrer; softwires@ietf.org
Objet : Re: Suresh Krishnan's Discuss on 
draft-ietf-softwire-multicast-prefix-option-12: (with DISCUSS)

Hi Med,

On Feb 1, 2017, at 7:26 AM, 
mohamed.boucad...@orange.com wrote:

Hi Suresh,

Thank you for the review.

Please see inline.

Cheers,
Med


-Message d'origine-
De : Suresh Krishnan [mailto:suresh.krish...@ericsson.com]
Envoyé : mercredi 1 février 2017 00:44
À : The IESG
Cc : 
draft-ietf-softwire-multicast-prefix-opt...@ietf.org;
 softwire-
cha...@ietf.org; 
ianfar...@gmx.com; 
softwires@ietf.org
Objet : Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix-
option-12: (with DISCUSS)

Suresh Krishnan has entered the following ballot position for
draft-ietf-softwire-multicast-prefix-option-12: 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-multicast-prefix-
option/



--
DISCUSS:
--

* Section 3:

How can the ASM_mPrefix64 and SSM_mPrefix64 be (variable) as described in
the packet format when the asm-length and the ssm-length MUST be set to
96? Not sure which of these is correct and which is wrong but one of
these things (either the fixed length or the variable prefix) needs to be
fixed.

[Med] The text is correct. The "(variable)" mention in the figure is removed 
from my local copy.

Sounds good.





* Section 4:

This section contains a bunch of must and may level requirements but
contains the following "disclaimer" text.

"This section is not normative but specifies a set of configuration
guidelines."

Not sure what the intent behind this is. Can you clarify?

[Med] We are not using normative language on purpose because of previous 
comments we received from some DHC experts (T. Lemon). The use of normative 
text for the server behavior would mean that we are updating RFC 3315, which we 
do not want to do. This is why we are defining this section as configuration 
guidelines.

That reasoning does not help me understand the impacts. What happens when these 
“guidelines” are not respected by the servers?
[Med] If the server does not follow the guidelines, this will be detected by 
the client and behave accordingly (covered in Section 5). Let’s consider same 
sample examples:

· If the server return an SSM prefix instead of an ASM one, this will 
be rejected by the IPv4/IPv6 mapping algorithm.

· If multiple instance of the option having the same scope are returned 
to the client, the client will ignore the option.

Will the mechanism in the draft still work?
[Med] Yes…because the client (and underlying multicast library) is designed to 
catch these cases.

Can such a server interoperate with a client that expects the server to follow 
these guidelines?
[Med] The client DOES NOT expect to always be facing a server that follow the 
guidelines. The client is designed to cover both cases: “good” servers and 
badly configured ones. The configuration that is received from a well behaving 
server will be validated by the client (and underlying multicast library) while 
mis-configuration will be rejected.

Thanks
Suresh

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

Re: [Softwires] Stephen Farrell's No Objection on draft-ietf-softwire-dslite-multicast-16: (with COMMENT)

[mohamed.boucadair]

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Envoyé : mardi 31 janvier 2017 14:45
> À : The IESG
> Cc : draft-ietf-softwire-dslite-multic...@ietf.org; softwire-
> cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Stephen Farrell's No Objection on draft-ietf-softwire-dslite-
> multicast-16: (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-softwire-dslite-multicast-16: 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-dslite-multicast/
> 
> 
> 
> --
> COMMENT:
> --
> 
> - IPR: so we have a late IPR declaration that sys
> RAND+royalty but yet the filing refers to the I-D
> that preceded the application and there's a common
> author/inventor. Sheesh. But the WG did consider it
> and were ok going ahead from a look at the list.
> (So there's no need to reply to my whining here:-)
> 
> - 6.3: Is RFC7739 worth a mention here?  Not sure
> myself.
> 
[Med] Given that the document does not discuss how the identification field is 
valued and that RFC7739 provides algo EXAMPLES, I tend to not cite it here. 

> - section 9: I'd have thought that this solution
> reduced the potential for a DoS compared to the
> previous situation where multicast traffic is
> mapped to unicast? If so, worth a mention?
> 
[Med] What about?

"Unlike solutions that map IPv4 multicast flows to IPv6 unicast flows, this 
document does not exacerbate Denial-of-Service (DoS) attacks."


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

Re: [Softwires] Stephen Farrell's No Objection on draft-ietf-softwire-multicast-prefix-option-12: (with COMMENT)

[mohamed.boucadair]

Hi Stephen, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Envoyé : mardi 31 janvier 2017 13:45
> À : The IESG
> Cc : draft-ietf-softwire-multicast-prefix-opt...@ietf.org; softwire-
> cha...@ietf.org; ianfar...@gmx.com; softwires@ietf.org
> Objet : Stephen Farrell's No Objection on draft-ietf-softwire-multicast-
> prefix-option-12: (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-softwire-multicast-prefix-option-12: 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-multicast-prefix-
> option/
> 
> 
> 
> --
> COMMENT:
> --
> 
> - (nit) section 3: it seems odd to say in the
> figure that the prefixes are variable length but to
> then say the lengths of two of them MUST be 96
> bits. (I do think having the fields as is is good
> for futureproofing, but would suggest changing the
> figure.)
> 

[Med] Good catch. Fixed in my local copy. 

> - (non-nit:-) section 3: I'm not getting why the
> unicast-length can be >96? And what if the prefix
> length is not one of those given in RFC6052? Don't
> you need to say it needs to be?

[Med] Good catch (again). As per RFC6052, the length values can be 32, 48, 56, 
64, or 96. I updated the text accordingly:

NEW: 

"As specified in [RFC6052], the unicast-length MUST be one of 32, 48, 56, 64, 
or 96."

> 
> - (not sure about nittyness:-) section 5: 1st
> bullet: I'm not following what "matches" means
> here. Probably my ignorance but is it clear?
>

[Med] As you can read at https://tools.ietf.org/html/rfc2365#section-8, there 
is a mapping between the IPv6 multicast scope and IPv4 multicast prefixes. 
"Matches" is used to denote that.  


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

Re: [Softwires] RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt

[mohamed.boucadair]

Hi Stig, 

Works for me. 

The changes are implemented copy. I will wait for other reviews before 
submitting a new revision.

Thank you.

Cheers,
Med

> -Message d'origine-
> De : Stig Venaas [mailto:s...@venaas.com]
> Envoyé : mardi 24 janvier 2017 05:56
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Lee, Yiu; rtg-...@ietf.org; draft-ietf-softwire-dslite-
> multicast@ietf.org; rtg-...@ietf.org; softwires@ietf.org
> Objet : Re: RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
> 
> Hi
> 
> On Mon, Jan 23, 2017 at 2:51 AM,   wrote:
> > Hi Stig,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Stig Venaas [mailto:s...@venaas.com]
> >> Envoyé : mercredi 18 janvier 2017 19:27
> >> À : Lee, Yiu
> >> Cc : BOUCADAIR Mohamed IMT/OLN; rtg-...@ietf.org; draft-ietf-softwire-
> >> dslite-multicast@ietf.org; rtg-...@ietf.org; softwires@ietf.org
> >> Objet : Re: RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
> >>
> >> Hi
> >>
> >> The good version looks pretty good. But I noticed one more thing that
> >> you might want to change. I'll leave it to you.
> >>
> >> 8.1.1.  The MLD Querier is Co-Located with the mAFTR
> >>
> >>The mAFTR can embed the MLD Querier function (as well as the PIMv6
> >>DR) for optimization purposes.
> >>
> >> I'm wondering if you should say IPv6 DR or PIMv6 DR instead. As you
> >> write after the heading, it must be co-located with the DR as well.
> >> Normally the querier would be the same router, but the querier could
> >> be another router on the link.
> >
> > [Med] Do you suggest to replace in the title "MLD Querier" with "PIMv6
> DR"?
> 
> Yes, or I guess IPv6 DR is better. You used the term IPv4 DR below.
> 
> I'm not sure if you have it in your document, I know I should check,
> but it would be good somewhere to say that DR is the Designated Router
> as defined in RFC 7761.
> 
> Stig
> 
> >>
> >> Then we have this section:
> >>
> >> 8.1.2. The DR is Co-Located with the mAFTR
> >>
> >> In the text you talk about the DR connected to the IPv4 source. Hence
> >> it is the first hop DR, and IPv4 DR. I'm wondering if it is worth
> >> saying IPv4 DR or something in the title to distinguish it from the
> >> other DR. Basically we have first hop DR and last hop DR, or if you
> >> like IPv4 DR and IPv6 DR.
> >>
> >
> > [Med] Makes sense to be explicit here. I changed DR to IPv4 DR.
> >
> >> I'm leaving it to you to decide. This is the only remaining issue I
> >> can find. There is a typo at the end of Appendix B though. It say
> >> "Noet".
> >
> > [Med] Fixed it. Thanks.
> >
> >>
> >> Stig
> >>
> >>
> >> On Fri, Jan 13, 2017 at 12:33 PM, Stig Venaas  wrote:
> >> > Sounds good, I'll still try to have another look when you post the
> >> > next revision.
> >> >
> >> > Stig
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt

[mohamed.boucadair]

Hi Stig, 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Stig Venaas [mailto:s...@venaas.com]
> Envoyé : mercredi 18 janvier 2017 19:27
> À : Lee, Yiu
> Cc : BOUCADAIR Mohamed IMT/OLN; rtg-...@ietf.org; draft-ietf-softwire-
> dslite-multicast@ietf.org; rtg-...@ietf.org; softwires@ietf.org
> Objet : Re: RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
> 
> Hi
> 
> The good version looks pretty good. But I noticed one more thing that
> you might want to change. I'll leave it to you.
> 
> 8.1.1.  The MLD Querier is Co-Located with the mAFTR
> 
>The mAFTR can embed the MLD Querier function (as well as the PIMv6
>DR) for optimization purposes.
> 
> I'm wondering if you should say IPv6 DR or PIMv6 DR instead. As you
> write after the heading, it must be co-located with the DR as well.
> Normally the querier would be the same router, but the querier could
> be another router on the link.

[Med] Do you suggest to replace in the title "MLD Querier" with "PIMv6 DR"?

> 
> Then we have this section:
> 
> 8.1.2. The DR is Co-Located with the mAFTR
> 
> In the text you talk about the DR connected to the IPv4 source. Hence
> it is the first hop DR, and IPv4 DR. I'm wondering if it is worth
> saying IPv4 DR or something in the title to distinguish it from the
> other DR. Basically we have first hop DR and last hop DR, or if you
> like IPv4 DR and IPv6 DR.
> 

[Med] Makes sense to be explicit here. I changed DR to IPv4 DR.

> I'm leaving it to you to decide. This is the only remaining issue I
> can find. There is a typo at the end of Appendix B though. It say
> "Noet".

[Med] Fixed it. Thanks.

> 
> Stig
> 
> 
> On Fri, Jan 13, 2017 at 12:33 PM, Stig Venaas  wrote:
> > Sounds good, I'll still try to have another look when you post the
> > next revision.
> >
> > Stig
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] TR: New Version Notification for draft-ietf-softwire-dslite-multicast-15.txt

[mohamed.boucadair]

Dear all,

This new version integrates the comments received during the IETF LC. 
Particularly, it takes into account the comments from Stig. 

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Envoyé : jeudi 12 janvier 2017 14:14
> À : softwire-cha...@ietf.org; BOUCADAIR Mohamed IMT/OLN; Yiu Lee; Jacni
> Qin; JACQUENET Christian IMT/OLN; Yiu L. Lee; Qian Wang
> Objet : New Version Notification for draft-ietf-softwire-dslite-multicast-
> 15.txt
> 
> 
> A new version of I-D, draft-ietf-softwire-dslite-multicast-15.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> 
> Name: draft-ietf-softwire-dslite-multicast
> Revision: 15
> Title:Delivery of IPv4 Multicast Services to IPv4 Clients 
> over an
> IPv6 Multicast Network
> Document date:2017-01-12
> Group:softwire
> Pages:21
> URL:https://www.ietf.org/internet-drafts/draft-ietf-softwire-
> dslite-multicast-15.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-softwire-
> dslite-multicast/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-softwire-dslite-
> multicast-15
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-
> dslite-multicast-15
> 
> Abstract:
>This document specifies a solution for the delivery of IPv4 multicast
>services to IPv4 clients over an IPv6 multicast network.  The
>solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
>and uses an IPv6 multicast distribution tree to deliver IPv4
>multicast traffic.  The solution is particularly useful for the
>delivery of multicast service offerings to DS-Lite serviced
>customers.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

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

Re: [Softwires] Review of draft-ietf-softwire-dslite-multicast-14

[mohamed.boucadair]

Hi Jouni,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Jouni Korhonen [mailto:jouni...@gmail.com]
> Envoyé : mardi 10 janvier 2017 21:05
> À : ops-...@ietf.org
> Cc : softwires@ietf.org; draft-ietf-softwire-dslite-
> multicast@ietf.org; i...@ietf.org
> Objet : Review of draft-ietf-softwire-dslite-multicast-14
> 
> Reviewer: Jouni Korhonen
> Review result: Ready
> 
> I found no issues in this specification (not that I would be an expert
> in multicast).
> IDnits complain about one instance of lines with non-rfc3849-compliant
> IPv6 addresses. That should be verified whether it actually is an
> issue.

[Med] We are using the documentation prefixes when appropriate:

   IPv4 and IPv6 addresses used in this example are derived from the
   IPv4 and IPv6 blocks reserved for documentation, as per [RFC6676].
   The unicast IPv4 address of the above example is derived from the
   documentation address block defined in [RFC6890].

The instance idnit is complaining about is related to: 64:ff9b::/96. This one 
is not an issue.

> 
> On the operations side, I am happy with the current deployment
> considerations section content, and in general how some of the
> deployment/operational aspects have been laid out in the document.
> 
[Med] Thank you.


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

Re: [Softwires] Review of draft-ietf-softwire-multicast-prefix-option-11

[mohamed.boucadair]

Re-,

OK, thanks. 

If you prefer one sentence, then I can reword it to: 

   Such side effect conflicts with the recommendation to support the
   Well-Known DNS Name heuristic discovery-based method for unicast-only
   environments (Section 6 of [RFC7051]).

Cheers,
Med

> -Message d'origine-
> De : Sheng Jiang [mailto:jiangsh...@huawei.com]
> Envoyé : mardi 10 janvier 2017 07:48
> À : BOUCADAIR Mohamed IMT/OLN; ops-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-multicast-
> prefix-option@ietf.org
> Objet : RE: Review of draft-ietf-softwire-multicast-prefix-option-11
> 
> Hi, Med,
> 
> Thanks for reply. The content looks clear now. Reword into one sentence.
> 
> Such side effect conflicts with the recommendation documented in
> Section 6 of [RFC7051], in which
>^^^
> to support the Well-Known DNS Name heuristic discovery-based method
>  ^^
> for unicast-only environments is recommended.
>  ^^^
> 
> Cheers,
> 
> Sheng
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > [mailto:mohamed.boucad...@orange.com]
> > Sent: Tuesday, January 10, 2017 2:44 PM
> > To: Sheng Jiang; ops-...@ietf.org
> > Cc: softwires@ietf.org; i...@ietf.org;
> > draft-ietf-softwire-multicast-prefix-option@ietf.org
> > Subject: RE: Review of draft-ietf-softwire-multicast-prefix-option-11
> >
> > Hi Sheng,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Sheng Jiang [mailto:jiangsh...@huawei.com] Envoyé : mardi 10
> > > janvier 2017 04:55 À : ops-...@ietf.org Cc : softwires@ietf.org;
> > > i...@ietf.org; draft-ietf-softwire-multicast-
> > > prefix-option@ietf.org Objet : Review of
> > > draft-ietf-softwire-multicast-prefix-option-11
> > >
> > > Reviewer: Sheng Jiang
> > > Review result: Has Nits
> > >
> > > Summary: This draft is almost ready for publication as a standard
> > > track RFC.
> > >
> > > Major issues:
> > >
> > > Minor issues:
> > >
> > > “the specification of a DHCPv6 option that could be used to discover
> > >unicast PREFIX64s in environments where multicast is not enabled.
> > >Such side effect conflicts with the recommendation documented in
> > >Section 6 of [RFC7051].”
> > >
> > > It is unclear how the Section 6 of RFC7051 relevant with the content
> > > above. It would be necessary to quote particular content of RFC7051
> > > and give necessary analysis.
> > >
> >
> > [Med] What about:
> >
> > OLD:
> >
> >Note that it was tempting to define three distinct DHCPv6 options,
> >but that approach was not adopted because it has a side effect: the
> >specification of a DHCPv6 option that could be used to discover
> >unicast PREFIX64s in environments where multicast is not enabled.
> >Such side effect conflicts with the recommendation documented in
> >Section 6 of [RFC7051].
> >
> > NEW:
> >Note that it was tempting to define three distinct DHCPv6 options,
> >but that approach was not adopted because it has a side effect: the
> >specification of a DHCPv6 option that could be used to discover
> >unicast PREFIX64s in environments where multicast is not enabled.
> >Such side effect conflicts with the recommendation documented in
> >Section 6 of [RFC7051]. As a reminder, that recommendation is to
> >
> > 
> >to support the Well-Known DNS Name heuristic discovery-based method
> >
> > 
> > ^^
> >for unicast-only environments.
> >^^
> >
> > Better?
> >
> > > Nits:
> > >
> > > “the Pv4 multicast address is inserted in the last 32 bits of the
> > > IPv4-embedded IPv6
> > >multicast address.”
> > >
> > > Pv4//IPv4
> > [Med] Fixed.
> >

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

Re: [Softwires] Review of draft-ietf-softwire-multicast-prefix-option-11

[mohamed.boucadair]

Hi Sheng, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Sheng Jiang [mailto:jiangsh...@huawei.com]
> Envoyé : mardi 10 janvier 2017 04:55
> À : ops-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-multicast-
> prefix-option@ietf.org
> Objet : Review of draft-ietf-softwire-multicast-prefix-option-11
> 
> Reviewer: Sheng Jiang
> Review result: Has Nits
> 
> Summary: This draft is almost ready for publication as a standard
> track RFC.
> 
> Major issues:
> 
> Minor issues:
> 
> “the specification of a DHCPv6 option that could be used to discover
>unicast PREFIX64s in environments where multicast is not enabled.
>Such side effect conflicts with the recommendation documented in
>Section 6 of [RFC7051].”
> 
> It is unclear how the Section 6 of RFC7051 relevant with the content
> above. It would be necessary to quote particular content of RFC7051
> and give necessary analysis.
> 

[Med] What about:  

OLD: 

   Note that it was tempting to define three distinct DHCPv6 options,
   but that approach was not adopted because it has a side effect: the
   specification of a DHCPv6 option that could be used to discover
   unicast PREFIX64s in environments where multicast is not enabled.
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051].

NEW: 
   Note that it was tempting to define three distinct DHCPv6 options,
   but that approach was not adopted because it has a side effect: the
   specification of a DHCPv6 option that could be used to discover
   unicast PREFIX64s in environments where multicast is not enabled.
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051]. As a reminder, that recommendation is to
   
   to support the Well-Known DNS Name heuristic discovery-based method
   ^^
   for unicast-only environments.
   ^^ 

Better?

> Nits:
> 
> “the Pv4 multicast address is inserted in the last 32 bits of the
> IPv4-embedded IPv6
>multicast address.”
> 
> Pv4//IPv4
[Med] Fixed.


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

Re: [Softwires] [Gen-art] Review of draft-ietf-softwire-multicast-prefix-option-11

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Roni Even [mailto:roni.e...@huawei.com]
> Envoyé : lundi 9 janvier 2017 11:36
> À : BOUCADAIR Mohamed IMT/OLN; Roni Even; gen-...@ietf.org
> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-multicast-
> prefix-option@ietf.org
> Objet : RE: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-
> option-11
> 
> Hi Med,
> Inline
> Roni
> 
> -Original Message-
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of
> mohamed.boucad...@orange.com
> Sent: יום ב 09 ינואר 2017 09:43
> To: Roni Even; gen-...@ietf.org
> Cc: softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-multicast-
> prefix-option@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-
> option-11
> 
> Dear Roni,
> 
> Thank you for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Roni Even [mailto:roni.e...@mail01.huawei.com]
> > Envoyé : lundi 9 janvier 2017 07:52
> > À : gen-...@ietf.org
> > Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-multicast-
> > prefix-option@ietf.org Objet : Review of
> > draft-ietf-softwire-multicast-prefix-option-11
> >
> > Reviewer: Roni Even
> > Review result: Almost Ready
> >
> > I am the assigned Gen-ART reviewer for this draft. For background on
> > Gen-ART, please see the FAQ at
> > .
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> > Document:  draft-ietf-softwire-multicast-prefix-option-11
> > Reviewer: Roni Even
> > Review Date:2017-1-9
> > IETF LC End Date: 2017–1-12
> > IESG Telechat date:
> >
> > Summary: This draft is almost  ready for publication as a standard
> > track RFC.
> >
> >
> > Major issues:
> >
> > Minor issues:
> >
> > 1.  In section 4 first paragraph say “DHCP servers supporting
> > OPTION_V6_PREFIX64 should be configured with U_PREFIX64 and at least
> > one multicast PREFIX64 (i.e., ASM_PREFIX64 and/or SSM_PREFIX64).” From
> > the rest of the section I understand that for SSM deployments both
> > U_PREFIX64 and SSM_PREFIX64 MUST be configured.
> 
> [Med] Yes. If you prefer, I can change the text to make this more clear:
> 
> OLD:
>   DHCP servers supporting OPTION_V6_PREFIX64 should be configured with
>U_PREFIX64 and at least one multicast PREFIX64 (i.e., ASM_PREFIX64
>and/or SSM_PREFIX64).
> 
> NEW:
>DHCP servers supporting OPTION_V6_PREFIX64 must be configured with
>ASM_PREFIX64 or SSM_PREFIX64, and may be configured with both.
>U_PREFIX64 must also be configured when SSM_PREFIX64 is provided.
>U_PREFIX64 may be configured when only ASM_PREFIX64 is provided.
> 
> Roni: OK
> 

[Med] I implemented the change in my local copy. 

> > What is the reason for “should” in the first paragraph? Are there
> > cases where ASM_PREFIX64 or ASM_PREFIX64 and SSM_PREFIX64 are
> > specified and there is no need to specify U_PREFIX64, maybe these
> > cases should be described.
> >
> 
> [Med] The presence of the unicast address is mandatory for the SSM case
> because it is required to form an IPv6 address from an IPv4 address to
> subscribe to a multicast content from a particular source. For the ASM
> case, the configuration of the U_PREFIX64 is not mandatory in the
> following cases: (1) a local mapping algorithm is enabled by the function
> that grafts the IPv4 multicast host side with an IPv6 multicast tree or
> (2) in deployments that make use of the WKP (64:ff9b::/96, RFC6052).
> 
> I can add this NEW text:
> 
>Note that U_PREFIX64 is not mandatory for the ASM case if, for
>example, a local address mapping algorithm is supported or the Well-
>Know Prefix (64:ff9b::/96) is used.
> 
> Roni:OK
> 

[Med] I made the change in my local copy. 

> >
> > Nits/editorial comments:
> > 1.  RFC2119 keywords in the document are sometime capitalized and
> > sometime not. I think it will be good to have consistency and if they
> > do not intend to have RFC2119 semantics some other words should be
> > used
> >
> 
> [Med] I guess you are referring to Section 4. We are not using normative
> language on purpose because of previous comments we received from some DHC
> experts (T. Lemon). The use of normative text for the server behavior
> would mean that we are updating RFC 3315, which we do not want to do. This
> is why we are defining this section as configuration guidelines.
> 
> Roni: maybe add to section 4 text saying that this section is not
> normative and serves as guidelines, since this is a standard track
> document and usage of RFC2119 keywords may be confusing
> 
> 
[Med] Works for me. I added this NEW text to Section 4:

"This section is not normative but specifies a set of configuration guidelines."

> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Re: [Softwires] draft-ietf-softwire-yang: YANG compilation issue

[mohamed.boucadair]

Hi Benoit, all,

I guess you meant an error in ** draft-ietf-softwire-dslite-yang ** not ** 
draft-ietf-softwire-yang **. 

The error will be fixed in the next revision of 
draft-ietf-softwire-dslite-yang. Thank you. 

Cheers,
Med

> -Message d'origine-
> De : Benoit Claise [mailto:bcla...@cisco.com]
> Envoyé : mardi 3 janvier 2017 14:26
> À : draft-ietf-softwire-y...@ietf.org; softwires@ietf.org
> Cc : Joe Clarke (jclarke)
> Objet : draft-ietf-softwire-yang: YANG compilation issue
> 
> Dear authors,
> 
> Even if not flagged by pyang (but flagged by yanglint), we found a
> mistake in your YANG module.
> See http://www.claise.be/IETFYANGPageCompilation.html
> 
> In a nutshell.
> OLD:
> ietf-dslite@2016-11.14
> 
> NEW:
> ietf-dslite@2016-11-14
> 
> I opened a new issue for pyang:
> https://github.com/mbj4668/pyang/issues/296
> Correct versioning becomes more and more important in our tool chain, so
> please correct this mistake.
> 
> Regards, Benoit
> 

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

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-13.txt

[mohamed.boucadair]

Dear all, 

This updated version integrates the reviews received from the INT directorate. 
FWIW, you may access these reviews at:
* 
https://datatracker.ietf.org/doc/review-ietf-softwire-dslite-multicast-12-intdir-early-cao-2016-12-14/
 
* 
https://datatracker.ietf.org/doc/review-ietf-softwire-dslite-multicast-12-intdir-early-chown-2016-12-14/
 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : jeudi 15 décembre 2016 10:03
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-dslite-multicast-13.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Softwires of the IETF.
> 
> Title   : Delivery of IPv4 Multicast Services to IPv4
> Clients over an IPv6 Multicast Network
> Authors : Mohamed Boucadair
>   Jacni Qin
>   Christian Jacquenet
>   Yiu L. Lee
>   Qian Wang
>   Filename: draft-ietf-softwire-dslite-multicast-13.txt
>   Pages   : 20
>   Date: 2016-12-15
> 
> Abstract:
>This document specifies a solution for the delivery of IPv4 multicast
>services to IPv4 clients over an IPv6 multicast network.  The
>solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
>and uses the IPv6 multicast distribution tree to deliver IPv4
>multicast traffic.  The solution is particularly useful for the
>delivery of multicast service offerings to DS-Lite serviced
>customers.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-multicast-13
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-01.txt

[mohamed.boucadair]

Dear all,

This version integrates the comments received from Ian. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de internet-
> dra...@ietf.org
> Envoyé : lundi 14 novembre 2016 17:02
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Softwires of the IETF.
> 
> Title   : A YANG Data Model for the DS-Lite
> Authors : Mohamed Boucadair
>   Christian Jacquenet
>   Senthil Sivakumar
>   Filename: draft-ietf-softwire-dslite-yang-01.txt
>   Pages   : 43
>   Date: 2016-11-14
> 
> Abstract:
>This document defines a YANG data model for the DS-Lite Address
>Family Transition Router (AFTR) and Basic Bridging BroadBand (B4)
>elements .
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-01
> 
> 
> 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] Volunteers to review draft-ietf-softwire-dslite-yang?

[mohamed.boucadair]

Hi Ian,

Many thanks for the prompt review. Much appreciated!

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : mardi 8 novembre 2016 12:24
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwires; draft-ietf-softwire-dslite-y...@ietf.org
Objet : Re: [Softwires] Volunteers to review draft-ietf-softwire-dslite-yang?

Hi Med,

Thanks for the reminder. I’ve been meaning to review this for a while.

Cheers,
Ian


General Comments:
1, How does this draft relate to the model in draft-sivakumar-yang-nat? There 
seems to be a lot of redundancy between them, which is understandable given the 
respective functions of a CGN and an AFTR. Wouldn’t it be better to reference 
the ietf-nat model for the nat specific functionality?

[Med] This is fair point, but given the current progress of 
draft-sivakumar-yang-nat I prefer to avoid that dependency and build the 
DS-Lite as self-contained modules.

Section 1
2, It would be useful to include a YANG model for B4 configuration as well to 
be inline with what is covered by the softwire-yang draft. Operators that are 
planning on moving to configuring CPEs with Netconf would also find this useful 
and given that there is a  fairly small amount of confiig necessary for the B4, 
it would be neater to include this here rather than another draft.

[Med] The B4 module will be quite simple. I don’t have objection to include 
that module, but this will require to change the scope of the draft.


Section 2
3, "A device can enable multiple AFTR instances”
I’m only familiar with one vendor’s DSLite AFTR implementation and I believe 
this only supports a single instance. Suggest something like - "The model 
supports enabling one or more instances of the AFTR function on a device”
[Med] OK with this change. FWIW, there are vendors who support the activation 
of multiple instances on the same AFTR.


4, The tree model needs a clean up for the data type column positioning
[Med] This will be fixed.


Model comments:
5, aftr-parameters/ipv4-address - You could use 192.0.0.1 as a default value 
here.
[Med] Agree.

6, aftr-parameters/leaf-mss-clamping-enable - Does this need an option to 
configure the MSS size to be used for clamping?
[Med] thank you for catching this. When it clamping is enabled, a value should 
be provided.

7, aftr-parameters/max-softwire-per-subscriber - the description could 
reference the subscriber-mask leaf to clear up how a ‘subscriber’ is defined.
[Med] Makes sense.

8, Should it be possible to configure an IPv6 range(s) for clients that the 
AFTR instance will service? If so, then the subscriber mask should be a child 
of this object.
[Med] The base AFTR behavior does not require explicit configuration of the 
IPv6 prefix to service. I’m hesitating to add that.

9, container logging-info - Can this be extended to contain timestamping 
information for the start/endtime of an active translation? I’m aware of a 
large commercial CGN deployment which requires these timestamps for regulatory 
compliance.
[Med] I agree that timestamping is needed, but this model assumes that the 
structure of the logging entries are fixed. Because there is no recommendation 
about such entries (except a discussion in RFC6888 and RFC6269), we avoided to 
zoom more on that part.

9, Also, I’ve seen several different logging/ protocol options that are 
implemented by vendors (local, syslog, netflow/ipfix, proprietary). Should a 
way of configuring these be available in this model?
[Med] May make sense to be added.

11, mapping-entry/lifetime - what is the unit for this leaf?
[Med] Seconds ; the module will be updated.

12, statistics/traffic-statistics - are there any useful sent ICMP set error 
messages that could be included here for e.g. to identify MTU problems?
[Med] Will be happy to align with lw4o6/MAP-E.

13, The notifications section seems quite light given then number of 
configurable threshold values that are available. e.g. 
max-softwire-per-subscriber (would be useful to know how often this is 
exceeded), no. of exceeded port-quota or port-set-size.
[Med] This section focuses only on critical events.

What about a counter for drops of packets received with unsupported transport 
protocols?
[Med] We can but this may be just logged locally.


Grammatical comments:
Section 2:
s/each responsible to service a group of B4s/each responsible for serving a 
group of B4s/
s/with a dedicated configuration data/with dedicated configuration data/

leaf hold-down-timeout
s/not reassigned till this timer/not reassigned until this timer/

[Med] Fixed. Thanks

On 08 Nov 2016, at 10:04, 
> 
> wrote:

Dear WG,

We are seeking for volunteers to review draft-ietf-softwire-dslite-yang.

If you are willing to review, please send a note to the list.

Thank you.

Cheers,
Med
___
Softwires mailing list

Re: [Softwires] Fwd: New Version Notification for draft-ietf-softwire-map-radius-08.txt

[mohamed.boucadair]

Dear authors, all,

I reiterate my comment to include multicast-related attributes as part of this 
specification.

Further, I invite the authors to double check 
https://tools.ietf.org/html/rfc6158#section-3.4. Also, you may follow the 
template defined in https://tools.ietf.org/html/draft-ietf-radext-datatypes-08.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de tianxiang li
Envoyé : vendredi 28 octobre 2016 05:39
À : softwires@ietf.org
Objet : [Softwires] Fwd: New Version Notification for 
draft-ietf-softwire-map-radius-08.txt

Hi all,

We've just updated a new version of draft-ietf-softwire-map-radius, we've 
changed the title from "RADIUS Attribute for Softwire" to “RADIUS Attribute for 
Softwire Address plus Port based Mechanisms”, as we only included the Map-T, 
Map-E, and Lightweight 4over6 solutions in the document. This was previously 
commented on the mailing list.

There was also a comment about merging the Multicast Radius draft 
(draft-hu-softwire-multicast-radius-ext) into this document. The current 
Softwire Radius draft already contains radius attributes for Map-E, Map-T, and 
Lightweight 4over6, we are not sure how merging would affect its overall 
structure, so we would like to receive more consensus from the working group on 
whether this should be done.

Thanks,
Tianxiang

-- Forwarded message --
From: >
Date: 2016-10-28 11:15 GMT+08:00
Subject: New Version Notification for draft-ietf-softwire-map-radius-08.txt
To: Bing Liu >, Sheng 
Jiang >, Peter Deacon 
>, Yu Fu 
>, Tianxiang Li 
>, Chongfeng Xie 
>



A new version of I-D, draft-ietf-softwire-map-radius-08.txt
has been successfully submitted by Tianxiang Li and posted to the
IETF repository.

Name:   draft-ietf-softwire-map-radius
Revision:   08
Title:  RADIUS Attribute for Softwire Address plus Port based Mechanisms
Document date:  2016-10-27
Group:  softwire
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-softwire-map-radius-08.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
Htmlized:   https://tools.ietf.org/html/draft-ietf-softwire-map-radius-08
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-08

Abstract:
   IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
   connectivity services simultaneously during the IPv4/IPv6 co-existing
   period.  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   options have been defined to configure Customer Edge (CE) in MAP-E,
   MAP-T, and Lightweight 4over6.  However, in many networks, the
   configuration information may be stored in Authentication
   Authorization and Accounting (AAA) servers while user configuration
   is mainly from Broadband Network Gateway (BNG) through DHCPv6
   protocol.  This document defines a Remote Authentication Dial In User
   Service (RADIUS) attribute that carries CE configuration information
   from AAA server to BNG.




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.

The IETF Secretariat

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

[Softwires] Volunteers to review draft-ietf-softwire-dslite-yang?

[mohamed.boucadair]

Dear WG,

We are seeking for volunteers to review draft-ietf-softwire-dslite-yang.

If you are willing to review, please send a note to the list.

Thank you.

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

Re: [Softwires] PLEASE READ - IPR Disclosure question on draft-ietf-softwire-dslite-multicast - Respond by 18/10/16

[mohamed.boucadair]

Re-,

As mentioned in another message, I don't see how this IPR applies to the draft 
given that the patent itself cites the softwire draft in the prior art!

I support the draft to advance in the publication process.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Ian Farrer
Envoyé : mardi 4 octobre 2016 09:39
À : softwires
Cc : draft-ietf-softwire-dslite-multic...@ietf.org
Objet : [Softwires] PLEASE READ - IPR Disclosure question on 
draft-ietf-softwire-dslite-multicast - Respond by 18/10/16

Hi,

A few weeks back, we sent out an question asking the WG their opinion on how to 
proceed with draft-ietf-softwire-dslite-multicast in light of the IPR 
disclosure. No responses to this question were received.

According to RFC3669, in order for a draft with an IPR disclosure to advance 
there needs to be consensus of the WG. No response is not consensus to proceed.

In light of this, we ask the WG again for their opinions on how to proceed. If 
insufficient support is shown, then work on the draft will cease.

Please respond by 18th October.

thanks,
Yong & Ian

Details of the IPR Disclosure are at:
https://datatracker.ietf.org/ipr/2873/

United States Patent # 9,014,189
Date Granted: April 21, 2015






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

Re: [Softwires] IPR Claim on draft-ietf-softwire-dslite-multicast

[mohamed.boucadair]

Hi Ian, 

(Apologies for the delay to reply to this message. I was out of office)

Despite I mentioned it offline, I want to add the following about this 
disclosure so that it is recorded in the archives: 

* The softwire draft was there before the disclosed patent is submitted.
* The patent itself cites the softwire draft as a prior art.

I don't see how the patent applies to this draft given what I mentioned above.

I hope the multicast draft can progress soon in the publication process. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Ian
> Farrer
> Envoyé : mercredi 7 septembre 2016 17:43
> À : softwires
> Cc : Yong Cui; draft-ietf-softwire-dslite-multic...@ietf.org
> Objet : [Softwires] IPR Claim on draft-ietf-softwire-dslite-multicast
> 
> Hi,
> 
> Please be aware that an IPR disclosure has been submitted related to this
> draft:
> 
> https://datatracker.ietf.org/ipr/2873/
> 
> In light of this, our AD would like to ask the WG’s opinion regarding
> the advancement of this I-D.
> 
> Please can you respond by Friday 16th September.
> 
> Thanks,
> Yong & Ian
> 
> ___
> 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] Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)

[mohamed.boucadair]

Re-,

>From where I stand, I don't see NEW issues that are specific to the priority 
>option.

I updated the text to record this:

NEW:

   Misbehaving intermediate nodes may alter the content of the S46
   Priority Option.  This may lead to setting a different IPv4 service
   continuity mechanism than the one initially preferred by the network
   side.  Also, a misbehaving node may alter the content of the S46
   Priority Option and other DHCPv6 options (e.g., DHCPv6 Option #64 or
   #90) so that the traffic is intercepted by an illegitimate node.
   Those attacks are not unique to the S46 Priority Option but are
   applicable to any DHCPv6 option that can be altered by a misbehaving
   intermediate node.

Cheers,
Med

De : Ben Campbell [mailto:b...@nostrum.com]
Envoyé : mardi 27 septembre 2016 16:37
À : BOUCADAIR Mohamed IMT/OLN
Cc : The IESG; draft-ietf-softwire-unified-...@ietf.org; Yong Cui; 
softwire-cha...@ietf.org; softwires@ietf.org
Objet : Re: Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: 
(with COMMENT)


Hi, thanks for the quick response! One comment below.

Ben.

On 27 Sep 2016, at 4:44, 
mohamed.boucad...@orange.com wrote:
- section 3: "This may lead to setting a different IPv4 service
continuity mechanism than the one initially preferred by the network
side"
Are there consequences of that that should be discussed? E.g. bid-down
attacks, ability to direct packets via a compromised path, etc? (I'm not
saying there are; I'm just asking.)
[Med] We didn't include examples of such consequences because those attacks 
depend on the modification of other DHCPv6 options that are not defined in this 
document. For example, the ability to direct packets via a compromised path 
will require the modification of the content of DHCPv6 Option #64 or #90 to 
redirect packets to an illegitimate AFTR/BR.
What about the following change:
OLD:
Misbehaving intermediate nodes may alter the content of the S46
Priority Option. This may lead to setting a different IPv4 service
continuity mechanism than the one initially preferred by the network
side.
NEW:
Misbehaving intermediate nodes may alter the content of the S46
Priority Option. This may lead to setting a different IPv4 service
continuity mechanism than the one initially preferred by the network
side. For example, a misbehaving node may alter the context of the S46
Priority Option and other DHCPv6 options (e.g., DHCPv6 Option #64 or #90)
so that the traffic is intercepted by an illegitimate node.

That helps. I was thinking more in terms of the S46 priority option 
specifically, but I guess it doesn't hurt to mention others. If one can modify 
the DHCPv6 options in general, one can do plenty of mischief without S46 
Priority. Does adding S46 priority add any new issues to that? I suspect the 
answer is "no", but if so it would be worth saying that.
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)

[mohamed.boucadair]

Dear Ben, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Ben Campbell [mailto:b...@nostrum.com]
> Envoyé : lundi 26 septembre 2016 23:58
> À : The IESG
> Cc : draft-ietf-softwire-unified-...@ietf.org; Yong Cui; softwire-
> cha...@ietf.org; cuiy...@tsinghua.edu.cn; softwires@ietf.org
> Objet : Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06:
> (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-softwire-unified-cpe-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-unified-cpe/
> 
> 
> 
> --
> COMMENT:
> --
> 
> - Abstract and Title: Neither the Abstract or Title seem to describe the
> contents of the draft. It seems to be about prioritization among multiple
> s46 mechanisms. It might be worth mentioning that in the abstract. 

[Med] Mirja raised a similar comment. This will be updated.

(Also,
> the title header for pages 2+ does not match the title page title)

[Med] Thank you for catching this. Will be fixed.

> 
> - section 3: "This may lead to setting a different IPv4 service
>continuity mechanism than the one initially preferred by the network
>side"
> 
> Are there consequences of that that should be discussed? E.g. bid-down
> attacks, ability to direct packets via a compromised path, etc? (I'm not
> saying there are; I'm just asking.)
> 
[Med] We didn't include examples of such consequences because those attacks 
depend on the modification of other DHCPv6 options that are not defined in this 
document. For example, the ability to direct packets via a compromised path 
will require the modification of the content of DHCPv6 Option #64 or #90 to 
redirect packets to an illegitimate AFTR/BR. 

What about the following change: 

OLD: 

   Misbehaving intermediate nodes may alter the content of the S46
   Priority Option.  This may lead to setting a different IPv4 service
   continuity mechanism than the one initially preferred by the network
   side.

NEW:

   Misbehaving intermediate nodes may alter the content of the S46
   Priority Option.  This may lead to setting a different IPv4 service
   continuity mechanism than the one initially preferred by the network
   side. For example, a misbehaving node may alter the context of the S46
   Priority Option and other DHCPv6 options (e.g., DHCPv6 Option #64 or #90)
   so that the traffic is intercepted by an illegitimate node. 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] I-D Action: draft-ietf-softwire-unified-cpe-05.txt

[mohamed.boucadair]

Dear all, 

This new version integrates the comments received during the IETF Last Call. 

Many thanks to John, Fred, and Paul for the review. Please feel free to double 
check the changes.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> internet-dra...@ietf.org
> Envoyé : jeudi 25 août 2016 10:59
> À : i-d-annou...@ietf.org
> Cc : softwires@ietf.org
> Objet : I-D Action: draft-ietf-softwire-unified-cpe-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Softwires of the IETF.
> 
> Title   : Unified IPv4-in-IPv6 Softwire CPE
> Authors : Mohamed Boucadair
>   Ian Farrer
>   Filename: draft-ietf-softwire-unified-cpe-05.txt
>   Pages   : 10
>   Date: 2016-08-25
> 
> Abstract:
>In IPv6-only provider networks, transporting IPv4 packets
>encapsulated in IPv6 is a common solution to the problem of IPv4
>service continuity.  A number of differing functional approaches have
>been developed for this, each having their own specific
>characteristics.  As these approaches share a similar functional
>architecture and use the same data plane mechanisms, this memo
>specifies a DHCPv6 option whereby a single CPE can interwork with all
>of the standardized and proposed approaches to providing encapsulated
>IPv4 in IPv6 services.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-unified-cpe/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-softwire-unified-cpe-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-unified-cpe-05
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Softwires] ietf-softwire: IPv4 + PSID primary key for lw4over6 binding

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Andy Wingo [mailto:wi...@igalia.com]
> Envoyé : mardi 12 juillet 2016 14:49
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : softwires@ietf.org
> Objet : Re: [Softwires] ietf-softwire: IPv4 + PSID primary key for
> lw4over6 binding
> 
> Hi Mohamed,
> 
> Thank you for your response.
> 
> On Tue 12 Jul 2016 13:46,  writes:
> 
> > [Med] Actually, the data model allows to map a B4 to one or multiple
> > softwires.
> >
> > The rationale for using binding-ipv6info as an index is to ease
> > enforcing per-subscriber policies (e.g., limit the number of softwires
> > per B4).
> 
> I am new to YANG; apologies in advance for making all of the beginner
> mistakes.  My understanding of the specification
> 
>   list binding-entry {
> key "binding-ipv6info";
> description "binding entry";
> uses binding-entry;
>   }
> 
> was that "binding-ipv6info" uniquely identifies the B4 (because it's a
> key within the binding-entry list).  Is that not the case?

[Med] "binding-ipv6info" uniquely identifies an entry, ** not ** a B4. The B4 
is identified by applying, for example, a subscriber-mask 
(https://tools.ietf.org/html/rfc7785#section-3). That is, a filter on all 
"binding-ipv6info" that belong, e.g., to the same /56. 

  If it is the
> case, how is it possible for one B4 to have multiple softwires?
> 
> >> It seems to me that one CPE could very well have multiple slices of
> >> IPv4 addresses.
> >
> > [Med] That's possible with the current data model: distinct binding
> > entries that belong to the same B4 may have distinct IPv4
> > addresses. Whether the same or distinct IPv4 addresses are bound to the
> > same B4 is deployment-specific. IMHO, this should be considered with
> > caution as it may lead to some applications failures e.g., RTP using
> > IPv4@1 while companion RTCP flows are bound to another IPv4@2.
> 
> Indeed.  Happily for me though this complexity is on the B4 side of
> things ;-)  By the time it gets to the AFTR I don't have any sort of
> policy decisions to make there.  It is a very pleasant standard in that
> regard :)

[Med] Glad to hear that it is pleasant.

> 
> Regards,
> 
> Andy

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

Re: [Softwires] ietf-softwire: IPv4 + PSID primary key for lw4over6 binding

[mohamed.boucadair]

Dear Andy,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Andy
> Wingo
> Envoyé : mardi 12 juillet 2016 12:32
> À : softwires@ietf.org
> Objet : [Softwires] ietf-softwire: IPv4 + PSID primary key for lw4over6
> binding
> 
> Hello list,
> 
> I have a change request for the draft-sun-softwire-yang-05 Internet
> Draft that defines a standard YANG model for lightweight 4-over-6
> binding tables.
> 
> This is my first post here, so allow me to introduce myself.  Together
> with some colleagues at Igalia we have made an open source
> implementation of the AFTR component of a lightweight 4-over-6
> deployment based on the Snabb toolkit for building software switches and
> other network functions.  This lwAFTR implementation is gradually
> wending its way upstream to https://github.com/snabbco/snabb.
> 
> To take a packet and look up a softwire in the binding table, the AFTR
> only has to look at one thing: the combination of the IPv4 address and
> port.  In the encapsulation direction you get this directly from the L3
> header.  In the decapsulation direction you get it from the encapsulated
> payload.  When decapsulating you also have to check that the B4 and BR
> addresses match the entries in the table, but you don't have to maintain
> a separate table that maps IPv6 B4 address to softwire: you just have
> the one IPv4+PSID-to-softwire table, along with a little side table that
> can map IPv4+port to PSID.
> 
> OK, cool.  Just one table, great.  However, draft-sun-softwire-yang-05
> specifies a different hierarchy:
> 
>   module: ietf-softwire
>  +--rw softwire-config
> +--...
> +--rw binding {binding}?
>+--rw br {br}?
>   +--rw enable?  boolean
>   +--rw br-instances
>  +--rw br-instance* [id]
> +--rw binding-table-versioning
> |  +--rw binding-table-version?  uint64
> |  +--rw binding-table-date? yang:date-and-time
> +--rw id uint32
> +--rw name?  string
> +--rw softwire-num-threshold uint32
> +--rw tunnel-payload-mtu uint16
> +--rw tunnel-path-mruuint16
> +--rw binding-table
>+--rw binding-entry* [binding-ipv6info]
>   +--rw binding-ipv6info union
>   +--rw binding-ipv4-addrinet:ipv4-address
>   +--rw port-set
>   |  +--rw psid-offset   uint8
>   |  +--rw psid-len  uint8
>   |  +--rw psid  uint16
>   +--rw br-ipv6-addr inet:ipv6-address
>   +--rw lifetime?uint32
> 
> This is figure 2 from section 5.2 (Lightweight 4over6 Tree Diagrams).
> This YANG schema would make it necessary to map from B4 address to
> softwire in some cases, which would be inefficient and not necessary
> from a data-plane point of view.

[Med] Actually, the data model allows to map a B4 to one or multiple softwires. 

The rationale for using binding-ipv6info as an index is to ease enforcing 
per-subscriber policies (e.g., limit the number of softwires per B4).

> 
> Additionally, this mapping prevents one B4 from having multiple
> softwires.

[Med] The data model in -05 allows for multiple softwires per B4 (distinct IPv6 
addresses). This can even be controlled using softwire-num-threshold 

 +--rw softwire-num-threshold uint32

This design is relaxing the following restriction from RFC7596:

   Although it would be possible to extend lw4o6 to have more than one
   active lw4o6 tunnel configured simultaneously, this document is only
   concerned with the use of a single tunnel.

  It seems to me that one CPE could very well have multiple
> slices of IPv4 addresses.

[Med] That's possible with the current data model: distinct binding entries 
that belong to the same B4 may have distinct IPv4 addresses. Whether the same 
or distinct IPv4 addresses are bound to the same B4 is deployment-specific. 
IMHO, this should be considered with caution as it may lead to some 
applications failures e.g., RTP using IPv4@1 while companion RTCP flows are 
bound to another IPv4@2.

> 
> Lightweight 4-over-6 maps a part of the IPv4 space to a set of B4s in
> such a way that one IPv4+port pair will map to one B4, but the reverse
> of that is not necessarily true: one B4 may map to many IPv4+port
> pairs.  The natural way (to my mind) to implement a lwAFTR is to key
> your table by IPv4+PSID or IPv4+port, and I think that's probably the
> most natural way to manage it too -- IPv4 is after all the scarce
> resource.  Allowing one CPE to have 

Re: [Softwires] Fwd: New Version Notification for draft-ietf-softwire-map-radius-07.txt

[mohamed.boucadair]

Hi Tianxiang,

Please see inline.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de tianxiang li
Envoyé : jeudi 7 juillet 2016 13:54
À : softwires@ietf.org
Objet : [Softwires] Fwd: New Version Notification for 
draft-ietf-softwire-map-radius-07.txt

Hi all,

We've submitted a new version of draft-ietf-softwire-map-radius (version-07) 
according to comments from the mailing list.

The main changes are listed below:

1. Changed draft title to "RADIUS Attribute for Softwire"
[Med] This title may be misleading given that DS-Lite RADIUS attributes are not 
defined in this document but in RFC6519. Please consider adding a note to 
describe the scope of the document (that is “softwire – dslite”).

2. Separated the use of terms MAP and S46
3. Numbered the messages in Figure 1 and numbered the supporting text
4. Removed Figure 2 in section 3 and added text explaining the difference
5. Removed text about caching of S46 configuration on BNG from section 3
6. Added a table in section 4.5 showing the valid combination of sub options 
supplied for each Softwire mechanism
7. Added reference to RFC7678 in section 7 Diameter Considerations

We really appreciate your comments.
[Med] I have two comments:
* I reiterate my request to include multicast-related attributes into the 
document.
* The format/specification of the attributes should adhere to RFC6929 and 
https://tools.ietf.org/html/draft-ietf-radext-datatypes-04#section-2.

Thanks,
Tianxiang

-- Forwarded message --
From: >
Date: 2016-07-07 19:21 GMT+08:00
Subject: New Version Notification for draft-ietf-softwire-map-radius-07.txt
To: Bing Liu >, Sheng 
Jiang >, Peter Deacon 
>, Yu Fu 
>, Tianxiang Li 
>, Chongfeng Xie 
>



A new version of I-D, draft-ietf-softwire-map-radius-07.txt
has been successfully submitted by Tianxiang Li and posted to the
IETF repository.

Name:   draft-ietf-softwire-map-radius
Revision:   07
Title:  RADIUS Attribute for Softwire
Document date:  2016-07-07
Group:  softwire
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-softwire-map-radius-07.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/
Htmlized:   https://tools.ietf.org/html/draft-ietf-softwire-map-radius-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-07

Abstract:
   IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
   connectivity services simultaneously during the IPv4/IPv6 co-existing
   period.  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   options have been defined to configure Customer Edge (CE) in MAP-E,
   MAP-T, and Lightweight 4over6.  However, in many networks, the
   configuration information may be stored in Authentication
   Authorization and Accounting (AAA) servers while user configuration
   is mainly from Broadband Network Gateway (BNG) through DHCPv6
   protocol.  This document defines a Remote Authentication Dial In User
   Service (RADIUS) attribute that carries CE configuration information
   from AAA server to BNG.




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.

The IETF Secretariat

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

[Softwires] draft-ietf-softwire-map-radius

[mohamed.boucadair]

Dear authors,

I have a question about this text:

==
5.  
Diameter Considerations

   This attribute is usable within either RADIUS or Diameter 
[RFC6733].
   Since the Attributes defined in this document will be allocated from
   the standard RADIUS type space, no special handling is required by
   Diameter entities.
==

What is the purpose of this section? FWIW, you can check 
https://tools.ietf.org/html/rfc7678

Would it be possible to include multicast-related attributes to be aligned with 
RFC7678? (https://tools.ietf.org/html/draft-wang-radext-multicast-radius-ext-00)

Thank you.

Cheers,
Med

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

Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

[mohamed.boucadair]

Hi Ted, Ian,

What I understand from Ted’s comment is he is objecting to add restrictions to 
the server’s behavior proposed by Ian.

In order to address the initial comment from Ian, I suggest this text:

   If distinct multicast PREFIX64s per scope are configured, the DHCP
   server returns multiple OPTION_V6_PREFIX64s; each instance is
   enclosing distinct ASM_PREFIX64 and SSM_PREFIX64 per scope.  Refer to
   Section 8 of [RFC2365] for a mapping between IPv4 multicast prefixes
   to IPv6 multicast address scopes [RFC7346].

Comments?

Cheers,
Med

De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : jeudi 9 juin 2016 15:37
À : Ian Farrer
Cc : BOUCADAIR Mohamed IMT/OLN; Softwires WG; dhcwg-cha...@ietf.org
Objet : Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

I would suggest:

  *   Two options, with different semantics
  *   Option format is one IP address per option
  *   This means that servers can't send two IP addresses, because that's not 
the format of the option
  *   Clients silently discard malformed options (don't need to specify 
this--it's just what clients should do in general)
  *   Define the semantics for the case where the client receives both options.

On Thu, Jun 9, 2016 at 9:08 AM, Ian Farrer 
> wrote:
HI Ted,

Cheers,
Ian

On 9 Jun 2016, at 14:34, Ted Lemon > 
wrote:

Actually, this is a classic example of what we try to avoid: special server 
behavior for options.   Options are just payload, not protocol, unless they are 
intended to affect the flow of the protocol.   It should not be necessary for 
the server to have special code to support a different payload, any more than 
the TCP stack should have to be modified in order to support new extensions to 
HTTP.

So you could make an operational note about how servers ought to be configured, 
but you should not require that the server check to make sure it is configured 
that way.   You should not require that the server understand the semantics of 
the option--what it means for there to be two of them, or what order they 
should occur in, or what meaning that ordering has.

[if - So, for the original reason that the point was raised, do you suggest 
that enforcing this only in the client (i.e. if it receives an invalid option 
combination/content then drop all instances) in addition to the operation 
guidance for server config?]




If you have two different uses for an option, with different semantics, you 
should define two different options, each of which has only one semantics.

On Thu, Jun 9, 2016 at 3:44 AM, Ian Farrer 
> wrote:
Hi Med,

To be clear, both of the suggestions include the modification to the Section 5 
client text? I think this is necessary. But is the error condition that all of 
the enclosed options are the same scope, or that two or more are?

Between the two, I would prefer (1) - a MUST NOT with an exception is a SHOULD 
NOT. An alternative wording that tries to get the best of both:

A server MUST NOT send more than on one instance of OPTION_V6_PREFIX64 per 
scope. Servers MAY send one instance of OPTION_V6_PREFIX64 for each distinct 
IPv6 multicast prefix with a distinct scope.

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

Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

[mohamed.boucadair]

Hi Ian,

There are two options:

(1)

Maintain the current text in the draft but add the following text to Section 4:

   Servers SHOULD NOT send more than one instance of OPTION_V6_PREFIX64,
   except if distinct IPv6 multicast prefixes with distinct scopes are
   configured.

This is the behavior defined in https://tools.ietf.org/html/rfc6334#section-5/.

(2)

Add this text in Section 4:

   Servers MUST NOT send more than one instance of OPTION_V6_PREFIX64,
   except if distinct IPv6 multicast prefixes with distinct scopes are
   configured.

And modify the text in Section 5 to indicate that the client must discard the 
options if all enclosed addresses are of the same scope.

I agree with you that (2) will help to identify a server error, but with a risk 
to induce service disruptions.

Which one do you prefer to be implemented in the draft?

Thank you.

Cheers,
Med

De : Ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : mercredi 8 juin 2016 19:10
À : BOUCADAIR Mohamed IMT/OLN; Softwires WG
Cc : dhcwg-cha...@ietf.org
Objet : Fwd: Problem in draft-ietf-softwire-multicast-prefix-option

Hi Med,

Forwarding this to the list (the left group mailing addresses were not working 
earlier).

Please see inline below.

Thanks,
Ian


Begin forwarded message:

From: >
Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option
Date: 8 June 2016 16:50:51 CEST
To: ian Farrer >, 
"softwires@ietf.org" 
>, Jacni Qin 
>, 
"dxhb...@gmail.com" 
>
Cc: "dhcwg-cha...@ietf.org" 
>

Hi Ian,

Please see inline.

Cheers,
Med

De : ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : mercredi 8 juin 2016 16:11
À : softwires@ietf.org; BOUCADAIR Mohamed IMT/OLN; 
Jacni Qin; dxhb...@gmail.com
Cc : dhcwg-cha...@ietf.org
Objet : Problem in draft-ietf-softwire-multicast-prefix-option

Hi,

On reviewing this draft I would like to raise a problem with section 5 of the 
draft. The text is:

"If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same scope, 
the first instance of the option MUST be used."

The problem is that this contravenes section 17 of RFC7227:

Option order, either the order among many DHCPv6 options or the order

   of multiple instances of the same option, SHOULD NOT be significant.

   New documents MUST NOT assume any specific option processing order.



[Med] That sentence does not assume any (preference) order. It does only 
provide one way to select one instance among that list. As a reminder, the 
server is supposed to return one instance (per scope).

[if - If the client is taking the first occurrence within the option and 
attempting to configure it, then it is preferring this option over other 
instances based on the order in which it occurs in the message.

The current text which describes the server behaviour (section 4) does not 
mention scope at all and does not specify any limitations on the number of 
instances or criteria for which they may be included - see RFC7227 sec 16.

If the server is meant to only return a single instance of the option per 
scope, but it is sending more than one, then this is a server configuration 
error. A quasi-random mechanism for the client to try and work around this just 
means that the configuration error may get masked.

As a suggestion, wouldn’t it be better to specify what the valid cases for the 
server including multiple option instances are and are not (with normative 
language). The client’s behaviour can then be defined to discard the options if 
they do not meet this criteria?]






I raised this with the DHC WG chairs, and they have a couple of suggestions:

1. Define an encapsulating option - as the data inside an option can be order 
dependent.
2. Add a “preference” (octet?) and then a client can sort them based on this 
preference.

Thanks,
Ian

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

Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

[mohamed.boucadair]

Hi Ian,

Please see inline.

Cheers,
Med

De : ian Farrer [mailto:ianfar...@gmx.com]
Envoyé : mercredi 8 juin 2016 16:11
À : softwires@ietf.org; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; dxhb...@gmail.com
Cc : dhcwg-cha...@ietf.org
Objet : Problem in draft-ietf-softwire-multicast-prefix-option

Hi,

On reviewing this draft I would like to raise a problem with section 5 of the 
draft. The text is:

"If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same scope, 
the first instance of the option MUST be used."

The problem is that this contravenes section 17 of RFC7227:

Option order, either the order among many DHCPv6 options or the order

   of multiple instances of the same option, SHOULD NOT be significant.

   New documents MUST NOT assume any specific option processing order.



[Med] That sentence does not assume any (preference) order. It does only 
provide one way to select one instance among that list. As a reminder, the 
server is supposed to return one instance (per scope).


I raised this with the DHC WG chairs, and they have a couple of suggestions:

1. Define an encapsulating option - as the data inside an option can be order 
dependent.
2. Add a “preference” (octet?) and then a client can sort them based on this 
preference.

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