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

Hi, As another data point on this topic, the storing of A+P data is also mandated in Hungary. From the Hungary paragraph of the 2016 EU report into implementation of the Data Retention Directive (http://fra.europa.eu/en/theme/information-society-privacy-and-data-protection/data-retention):

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

Hi Bernie, Thanks. I’ll still with 3315bis for now then. BTW - I’ve added another paragraph to the Sec. Considerations section reading: A client may attempt to overload the server by sending multiple source address update messages (see Section 7.2.1) in a short time frame. This risk

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

Hi Jordan, Please see inline below. Thanks, Ian > On 9. May 2018, at 21:38, Gottlieb, Jordan J > wrote: > > If I understand this correctly it appears that requirement #1 would dictate > the capability must be deployed on the CE. The way I read it you are >

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

Hi Bernie, Many thanks for the review. I’ve had a look through your comments and they all look straightforward enough. They will be in the next version with Tomek’s comments. Here’s my suggestions in response to a couple of your comments: SECTION 9: - More of a question – do the

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

[Softwires] Review of draft-ietf-softwire-mesh-multicast-20

Hi, I’ve just done a final review of -v20 of the draft. There’s still a few linguistic points and some clean ups that I think are needed. There’s also a couple of comments regarding points I would expect to get raised in later review phases, so it would be good if we could resolve these in

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

Hi, Thanks for the update. There’s one of the review comments that got missed. Can you fix? Thanks, Ian 6.4. Inter-AFBR Signalling s/Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT of (S,G)/Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT of (S,G)/

[Softwires] IPR Poll for draft-ietf-softwire-mesh-multicast

Hi Authors, Please reply to this email including the mailing list indicating whether you are aware of any IPR related to draft-ietf-softwire-mesh-multicast. Thanks, Ian ___ Softwires mailing list Softwires@ietf.org

[Softwires] Further draft-ietf-softwire-mesh-multicast

Hi Authors, I’m currently in the process of doing the write up for the draft. Please can you tell me if there are there any implementations in existence? Also, I have run v21 through ID-Nits. The important output is below. For the downref, to RFC4925, does this need to be a normative

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

Hi Sheng, Thank you for the summary below. I believe that -06 addresses all of the comments received during the WGLC. Please let me know if there is anything outstanding. Best regards, Ian > On 2. Jul 2018, at 03:43, Sheng Jiang wrote: > > Hi, all, > > We received no negative response to

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

[Softwires] Fwd: I-D Action: draft-ietf-softwire-map-radius-16.txt

Forwarding to the list. Hi Yu, Thanks for the update. I think the changes that you have made have improved the document significantly, but there’s still a few things that need to be addressed. Please see below. Also, Jordi asked a question about this draft, which I don’t think has been

Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 2 of 2

Hi, Review part 2. Cheers, Ian - 4. Attributes 4.a) 'sub options' is used. Conventionally, this is hypenated as 'sub-options'. Please change throughout. 4.b) It would be more accurate to say: Different combinations of sub-options are required for each type of S46 Container... 4.c) "

Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

Hi, Here’s my review of the draft. It’s rather long so I’ve had to submit it as two emails. It’s based on -15. Cheers, Ian Title T.a) RADIUS Attribute for Softwire Address plus Port based Mechanisms To improve readability and as this defines 3 new RADIUS attributes, 'RADIUS Attributes

Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

Hi, I only saw comments on the first part of my review. Have you also seen the second part? Please see below. Thanks, Ian > > > 1.i) > Last paragraph: It would also be worth saying how the structure of the > DHCP options and field namings are preserved so they can > easily be mapped

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

Hi, I’ve just posted v06 with the changes proposed below incorporated. Thanks, Ian > On 29. Jun 2018, at 10:20, > wrote: > > Hi Ian, > > Works for me. Thanks. > > Cheers, > Med > > De : ianfar...@gmx.com [mailto:ianfar...@gmx.com] > Envoyé : vendredi 29 juin 2018 09:59 > À :

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

Hi, This version contains a few small language changes and cleanups. Thanks, Ian > On 4. Nov 2018, at 15:00, 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. >

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

Hi Roni, I’ll add that for the next version. Thanks, Ian > On 9. Oct 2018, at 09:02, Roni Even wrote: > > Reviewer: Roni Even > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being

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

Hi We’ve just posted -15 of this draft incorporating the IESG evaluation DISCUSSes/comments and the Secdir/Genart review comments. Many thanks for those. Thanks, Ian Below is the log of DISCUSS/Comments received during the review and the changes that have been incorporated to address them.

Re: [Softwires] Secdir last call review of draft-ietf-softwire-yang-14

Hi Phillip, Thank you for your review and comment. We’ve re-written the Security Guidelines section following the guidance here: https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and Section 3.7.1 of RFC8407. The

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:

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

Hi Suresh, Please see inline below. Thanks, Ian > On 10. Jan 2019, at 15:05, Suresh Krishnan wrote: > > 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

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

Hi Roni, My apologies for the oversight. I’ve just posted -14 which includes the RESTCONF reference in the Introduction. Thanks, Ian > On 9. Oct 2018, at 09:02, Roni Even wrote: > > Reviewer: Roni Even > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft.

Re: [Softwires] Mirja Kühlewind's No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

Hi Mirja, Thanks for your comments. Please see inline below. Regards, Ian > On 7. Jan 2019, at 18:06, Mirja Kühlewind wrote: > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-softwire-yang-14: No Objection > > When responding, please keep the subject line intact

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

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

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

Hi Yu, Please see inline below. Thanks, Ian > On 17. Aug 2018, at 11:48, Yu Fu wrote: > > Hi Ian > > > > Thanks for your thorough comments. Please see my reply below: > > > > BR > > Yu > > > > Hi Yu, > > Thanks for the update. I think the changes that you have made have

Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi, My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as an IPv6 address: The BGP speaker receiving the advertisement MUST use the Length of Next Hop Address field to determine which network-layer protocol the next hop address belongs to. When the Length of Next

Re: [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

Re: [Softwires] DS-Lite address

Hi, Your email got held up the the spam filters. In order to post directly to the email list, you need to register at: https://www.ietf.org/mailman/listinfo/softwires To your question, I’m not familiar with the specifics of your operator’s network or service, but hopefully the following