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
Hi all,
Would it be possible to find another slot for the drip session as it conflicts
with the add slot where both drip chairs have drafts to be discussed there.
==
1410-1550 Session III
Room 2 INT add Adaptive DNS Discovery WG
Room 3 INT
Hi Hannes,
It would be helpful if you can explicit the “wrong message” you are referring
to, and preferably with text from the draft conveying that message.
Thank you.
Cheers,
Med
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Hannes Tschofenig
Envoyé : mardi 30 juin 2020
Tom,
Now that you are on the IANA considerations, I would appreciate if you can
consider updating it to request a codepoint from the tunnel registry available
at:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6.
More rationale can be found in RFC-to-be-8675
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
Hi Tom,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : tom petch [mailto:ie...@btconnect.com]
> Envoyé : mardi 30 octobre 2018 13:07
> À : BOUCADAIR Mohamed TGI/OLN; int-area@ietf.org
> Objet : Re: [Int-area] registering tunnel types
>
> - Original Message -
>
Hi Joe, all,
The various techniques discussed in draft-ietf-softwire-yang were specified in
the softwire WG. This is why we are defining in softwire WG, not in another WG,
a YANG module for these techniques.
Cheers,
Med
> -Message d'origine-
> De : Int-area
Hi Tom, all,
In order to provide a full context, below some precisions:
* draft-ietf-softwire-yang DOES NOT create a new registry for maintaining
tunnel types nor changes the procedure to assign new code points. Such
register does already exist:
Hi Richard,
Thank you for promptly addressing the comments.
This version is stable enough and ready for a hopefully call for adoption.
Cheers,
Med
> -Message d'origine-
> De : Richard Patterson [mailto:rich...@helix.net.nz]
> Envoyé : lundi 2 juillet 2018 22:06
> Cc : BOUCADAIR
Hi Richard,
Thank you for addressing the comments. The -03 looks good to me.
FWIW, I do have some additional comments that you may find at:
* PDF:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-patterson-intarea-ipoe-health-03-rev%20Med.pdf
* DOC:
Hi Richard,
Thank you for writing this document.
FWIW, please find some inputs to this draft:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-patterson-intarea-ipoe-health-02-rev%20Med.pdf
(pdf version)
Hi Joe,
This is a little bit subtle.
RFC6302 is about operating and protecting a server against abuses,
denial-of-service, and all the issues discussed in rfc6269#section-13.1. 6302
does not ask a server to enable logging or not:
The above recommendations apply to current logging
Hi all,
There is no reason to revisit or deprecate RFC6302:
· The root technical issues as documented by intarea (RC6269) are still
valid. Those issues will be experienced by more and more in the future.
· RFC6302 records a valid technical recommendation for servers logging
IP
Hi Rajiv,
What concerns me with this requirement is that it nullifies one of the
motivations for stateless address sharing:
https://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-3.1.3
(Logging - No Need for Dynamic Binding Notifications)
especially, this part:
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"
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 : softwi...@ietf.org; int-area@ietf.org
>
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
Re-,
I don't parse well the comments from you, Amelia.
For example, when you say:
"The proposer of more mandatory logging recommendations appears"
With all due respect, this is a pure fallacy.
Dave's document DOES NOT propose anything new to be logged. He is relaying on
existing RFCs.
Dave,
Your affiliation has nothing to do with this discussion.
We all are contributing as individuals.
Cheers,
Med
> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Dave O'Reilly
> Envoyé : vendredi 27 avril 2018 11:31
> À : Amelia Andersdotter
>
Dear Amelia,
I reiterate there is no RFC which asks a ***server*** to log IP address for a
given time.
All what we have is a simple recommendation, saying if you log IP address (for
whatever reason), then consider logging source port too to ease investigation
in case of abuse, etc.
Source
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Amelia
> Andersdotter
> Envoyé : mercredi 25 avril 2018 14:37
> À : int-area@ietf.org
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
>
Re-,
I think we are in agreement.
Please note there is ** NO RFC ** which mandates logs to be kept 3 days.
I guess you are referring to this text from Amelia’s I-D (which reflects the
author’s opinion):
SHOULD NOT store logs of incoming IP addresses from inbound
traffic for longer
Re-,
Please see inline.
Cheers,
Med
De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
Objet : Re: [Int-area] WG adoption call: Availability of Information in
Criminal Investigations Involving
Dear Povl,
Thank you for sharing your thoughts.
I have one comment and two clarification questions:
- Wouldn’t logging based /20-/22 nullify the interest to log source ports for
investigations? Multiple subscribers may be assigned the same port in the /20
or /22 range.
- GeoIP (whatever that
Thank you Ted for clarifying.
Please see inline.
Cheers,
Med
De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : mardi 24 avril 2018 15:26
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; int-area@ietf.org
Objet : Re: [Int-area] WG adoption call: Availability of Information in
Criminal
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Amelia Andersdotter [mailto:ame...@article19.org]
> Envoyé : mardi 24 avril 2018 08:09
> À : BOUCADAIR Mohamed IMT/OLN; int-area@ietf.org
> Cc : Stephen Farrell
> Objet : Re: draft-andersdotter (was RE: [Int-area] WG
Hi Ted,
Please see inline.
Cheers,
Med
De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : lundi 23 avril 2018 17:55
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; int-area@ietf.org
Objet : Re: [Int-area] WG adoption call: Availability of Information in
Criminal Investigations Involving
Dear Amelia,
Some comments about the main recommendations in draft-andersdotter:
SHOULD only store entire incoming IP addresses for as long as is
necessary to provide the specific service requested by the user.
Med: This is implementation and deployment-specific. Not sure we can
Stephen,
"I hope that we've learned that we need to do more thorough analyses
of the privacy implications of our work."
The discussion about privacy implications for 6302 occurred in the past either
in intarea list or ietf-privacy:
*
Hi Brian,
The issue discussed in this I-D applies each time you have to share an IPv4
address. This covers IPv4 service continuity mechanism with IPv6-only
connectivity such as: NAT64, DS-Lite, MAP-E, MAP-T and lw4o6.
There is IMHO a value in socializing the IETF BCP and help
Hi Stephen,
The scope of this document is aligned with what the IETF has published in the
past in this field. A list is provided below:
1. Identify logging as an issue in address sharing: RFC 6269
2. Require address sharing to enable a logging function: RFC 6269
and RFC 6888
Hi all,
I support this document to be adopted as an informational document.
Cheers,
Med
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Juan Carlos
Zuniga
Envoyé : jeudi 19 avril 2018 17:38
À : int-area
Objet : [Int-area] WG adoption call: Availability of Information in Criminal
Hi Dave,
The proposed text would work.
Cheers,
Med
> -Message d'origine-
> De : Dave O'Reilly [mailto:r...@daveor.com]
> Envoyé : lundi 9 avril 2018 14:43
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : int-area@ietf.org
> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
>
> The
Hi Dave,
What about:
"The entity which owns the server should indicate the required offset to
synchronize with a global time source."
Cheers,
Med
> -Message d'origine-
> De : Dave O'Reilly [mailto:r...@daveor.com]
> Envoyé : samedi 7 avril 2018 16:31
> À : BOUCADAIR Mohamed IMT/OLN
Hi Dave,
I have a comment about the proposed update to RFC 6269 (the same comment
applies for RFC6302, though).
Actually, the proposed NEW text will require an extra effort to align
timestamps among the server which maintains the logs, the authorities that
relay an abuse claim, and the
Good suggestion, Tom.
Thanks.
Cheers,
Med
> -Message d'origine-
> De : Tom Herbert [mailto:t...@herbertland.com]
> Envoyé : jeudi 20 juillet 2017 17:39
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joe Touch; Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area]
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Joe Touch [mailto:to...@isi.edu]
> Envoyé : jeudi 20 juillet 2017 16:37
> À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; tsv-
> a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment
Bob,
You asked during your presentation whether SFC is to be marked as N/A.
I confirm. SFC encapsulation is not a transport encapsulation. ECN should be
managed by the transport encapsulation used within an SFC-enabled domain.
You have a long list of encap protocols; it is actually cool to
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
> Envoyé : mercredi 19 juillet 2017 21:58
> À : Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the
Hi Joe,
The text can always be worked out. This is not an IETF LC :)
The main point is that we are following your suggestion to define the solution
as an application proxy using a dedicated port number.
Cheers,
Med
> -Message d'origine-
> De : Joe Touch [mailto:to...@isi.edu]
>
Re-,
I don't understand your argument here, especially because you are the one who
proposed me the following (check mptcp archives, April 20, 2017) which we
endorsed in the latest version of the specification:
"If that were the case, you'd simply be defining a new application service and
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Joe Touch [mailto:to...@isi.edu]
> Envoyé : mercredi 19 juillet 2017 18:36
> À : BOUCADAIR Mohamed IMT/OLN; Erik Kline
> Cc : Tom Herbert; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the
Joe,
As mentioned in a previous message in this thread, TCP-AO extensions (6978) to
pass NATs will be required otherwise TCP-AO will fail because of:
-Manipulating multiple addresses
-At least one of the source IP addresses will be rewritten.
The proxy design does not induce a new
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Tom Herbert [mailto:t...@herbertland.com]
> Envoyé : mercredi 19 juillet 2017 17:45
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joe Touch; tsv-a...@ietf.org; Internet Area
> Objet : Re: [Int-area] Middleboxes to aid the
Hi Erik,
That's the intuitive approach to follow but unfortunately the situation is not
that obvious to get into.
Network providers do not have a control on the servers and the terminals that
are enabled by customers behind the CPE. So making use of MPTCP to grab more
resources (when
Hi Joe,
Please see inline.
Cheers,
Med
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
Envoyé : mercredi 19 juillet 2017 01:12
À : Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
On 7/18/2017
Hi Tom,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Tom Herbert
> Envoyé : mercredi 19 juillet 2017 00:43
> À : Joe Touch
> Cc : tsv-a...@ietf.org; Internet Area
> Objet : Re: [Int-area] Middleboxes to aid the
Hi Hosnieh,
Please see inline.
Cheers,
Med
De : Hosnieh Rafiee [mailto:i...@rozanak.com]
Envoyé : jeudi 6 juillet 2017 20:09
À : BOUCADAIR Mohamed IMT/OLN; Int-area@ietf.org
Objet : Re: [Int-area] Review> SOCKS 6 Draft
Hi Mohamed,
Thanks for your email. I had two reasons:
1- I was not aware
Hi Vlad,
Please see inline.
Cheers,
Med
De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : vendredi 7 juillet 2017 09:19
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft
Hi Mohamed,
I'm replying
Hi Hosnieh,
Just out of curiosity, is there any particular reason you want to use SOCKS?
Did you consider other protocols such as:
· https://tools.ietf.org/html/rfc6887
· https://tools.ietf.org/html/rfc7652
Thank you.
Cheers,
Med
De : Int-area
Hi Joe,
Please see inline.
Cheers,
Med
De : Joe Touch [mailto:to...@isi.edu]
Envoyé : mercredi 5 juillet 2017 18:59
À : Vladimir Olteanu; BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : multipathtcp; Int-area@ietf.org
Objet : Re: [multipathtcp] [Int-area] SOCKS 6 Draft
On 7/5/2017 9:39 AM,
Hi Vladimir,
Please see inline.
Cheers,
Med
De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : mercredi 5 juillet 2017 18:39
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft
Hi Mohamed,
It's great to talk
Hi Vladimir, all,
(focusing only on this part of the message).
I do fully agree that shortening MPTCP connections setup is key. Having 0-RTT
is an important requirement for this effort. Achieving it without out-of-band
signaling would be even ideal.
Can you please elaborate on the benefits of
Hi Brian,
The purpose is not have this I-D published as an RFC but to follow the
procedure as per bullet 2 of
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html.
Can you take care of creating a status-change document for these RFCs?
Thank you.
Cheers,
Med
> -Message
Hi Alissa, all,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Suresh
Krishnan
Envoyé : vendredi 20 juin 2014 06:42
À : Alissa Cooper; Internet Area
Objet : Re: [Int-area] Call for adoption of
Hi all,
Lars raised a point about draft-boucadair-intarea-host-identifier-scenarios
that is basically to question whether it is worth continuing this effort if no
viable solutions can be designed to solve this problem.
I do agree this is a fair point. I have several comments to make here:
*
Hi SM,
RFC6302 should be positioned in its context: i.e., how to meet regulatory
requirements in some countries when address sharing is in use. A discussion on
the background (with a concise discussion on solution flavors and some hints on
time duration to store log data) is available at:
Hi SM,
Please see inline.
Cheers,
Med
-Message d'origine-
De : S Moonesamy [mailto:sm+i...@elandsys.com]
Envoyé : mercredi 11 juin 2014 21:10
À : BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
a...@ietf.org
Objet : RE: [Int-area] Call for adoption of
Hi SM,
Please see inline.
Cheers,
Med
-Message d'origine-
De : S Moonesamy [mailto:sm+i...@elandsys.com]
Envoyé : vendredi 6 juin 2014 14:56
À : BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
a...@ietf.org
Objet : RE: [Int-area] Call for adoption of
Hi Stephen,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Envoyé : vendredi 6 juin 2014 17:59
À : BOUCADAIR Mohamed IMT/OLN; Ted Lemon
Cc : Brian E Carpenter; ietf-priv...@ietf.org; int-area@ietf.org
Objet : Re: [Int-area]
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de
Stephen Farrell
Envoyé : samedi 7 juin 2014 15:21
À : Dan Wing
Cc : ietf-priv...@ietf.org; Internet Area; Joe Touch
Objet : Re: [ietf-privacy] [Int-area] NAT
Hi SM,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de S Moonesamy
Envoyé : jeudi 5 juin 2014 17:20
À : Tirumaleswar Reddy (tireddy); int-area@ietf.org
Objet : Re: [Int-area] Call for adoption of
Hi Ted,
As far as this document is concerned, we are open to address technical
concerns. It will be helpful if these concerns are specific enough and
hopefully in reference to
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.
Adding a discussion on potential
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Ted Lemon [mailto:ted.le...@nominum.com]
Envoyé : vendredi 6 juin 2014 12:48
À : BOUCADAIR Mohamed IMT/OLN
Cc : Brian E Carpenter; ietf-priv...@ietf.org; int-area@ietf.org; Stephen
Farrell
Objet : Re: [Int-area] [ietf-privacy]
Hi Suresh,
Thank you for initiating this call.
FWIW, the latest version is -05 not -04:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.
Unsurprisingly, I'm supportive to see this work adopted in intarea as a
companion effort to RFC6269 and RFC6967.
Cheers,
Hi Stephen,
You referred in your message to an old version. The latest version of the
document does not include any requirement, it is only an inventory of use cases
when problems are encountered. The latest version is available at:
Re-,
I have two comments:
(1)
If one missed the following sentences in -04 Below is listed as set of
requirements to be used to characterize
each use case (discussed in Section 3): and Once this list is stabilized,
each use case will be checked against
these requirements., then the
Dear all,
The new version of the draft tries to address most of the comments received so
far.
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é : vendredi 11 avril 2014 15:28
À :
Hi Brian,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Brian E
Carpenter
Envoyé : jeudi 6 mars 2014 19:03
À : joel jaeggli
Cc : hi...@ietf.org; Internet Area; draft-boucadair-intarea-host-
Hi Ted,
It is out of scope of the document to specify solutions but to enumerate the
set of cases where issues will be encountered. The use cases identified so far
are not specific to a given administrative domain as captured in
Dear all,
An updated version of this document is available online.
Comments are welcome.
Cheers,
Med
-Message d'origine-
De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la
part de internet-dra...@ietf.org
Envoyé : mardi 8 octobre 2013 11:12
À :
Hi Charles,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Charles Eckel (eckelcu) [mailto:ecke...@cisco.com]
Envoyé : jeudi 18 juillet 2013 22:07
À : BOUCADAIR Mohamed OLNC/OLN; Reinaldo Penno (repenno); int-area@ietf.org
Objet : RE: [Int-area] FW: New Version Notification for
Hi Reinaldo,
IMHO, deployment considerations are key aspects if you want this model to fly.
Having the material in one document is better (at least in early stages to
socialize the proposed framework within IETF).
Cheers,
Med
-Message d'origine-
De : Reinaldo Penno (repenno)
Dear Charles, all,
The idea of an application sending flow characterization messages to the
network is interesting. This is an idea which is worth to be discussed and
challenged. Thank you for writing this document.
The proposed framework makes sense in some contexts but I'm afraid it does not
Hi Reinaldo,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Reinaldo Penno (repenno) [mailto:repe...@cisco.com]
Envoyé : jeudi 18 juillet 2013 12:41
À : BOUCADAIR Mohamed OLNC/OLN; Charles Eckel (eckelcu); int-area@ietf.org
Objet : Re: [Int-area] FW: New Version Notification
Dear Joshua,
Apologies for the delay to answer this message.
I see your point. I will add it to the list of items to be considered for the
next iteration of the document.
BTW, -03 already included some of requirements which cover security aspects
(see for instance REQ#1, REQ#2, REQ#3,
Dear all,
We edited an I-D which proposes a global framework making use of the
Connectivity Provisioning Profile. The document is available here:
http://tools.ietf.org/html/draft-sin-sdnrg-sdn-approach-02
I'm sharing this information as it may be of interest of this working group.
Comments
Dear all,
This version integrates a second set of comments received during the IESG
review. The main changes are as follows:
* Clarify the use of HOST_ID common to all interfaces is out of scope
* Provide more explanation for the Proxy case
* Record two additional limitations for the IP Option
Dear all,
This version integrates the first set of comments received during the IESG
review. The main changes are:
* Add a sentence to clarify why no recommendation is included
* Add a sentence to clarify a host can be any computer located behind a CPE or
directly connected to an
Hi Suresh, all,
A new version incorporating the requested changes is online:
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis
There's also a htmlized version available at:
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Brian Haberman [mailto:br...@innovationslab.net]
Envoyé : mercredi 13 février 2013 16:04
À : BOUCADAIR Mohamed OLNC/OLN
Cc : int-area@ietf.org;
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org
Objet : Re: [Int-area] AD
Hi Behcet,
I have two comments:
* Host identification issue is valid for any address sharing mechanism. This is
why the introduction mentions already the following:
As reported in [RFC6269https://tools.ietf.org/html/rfc6269], several
issues are encountered when an IP
address is shared
Re-,
Please see inline.
Cheers,
Med
De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : mercredi 13 février 2013 18:01
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org;
Dear Brian,
Many thanks for the detailed review.
Please see inline.
Cheers,
Med
-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de Brian Haberman
Envoyé : lundi 11 février 2013 22:12
À : int-area@ietf.org;
Hi Suresh,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Suresh Krishnan [mailto:suresh.krish...@ericsson.com]
Envoyé : mercredi 13 février 2013 07:17
À : Brian Haberman
Cc : int-area@ietf.org;
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org
Objet : Re: [Int-area] AD
Hi Tina,
Thank you for the clarification. I updated the draft with a pointer to SLNAT44.
I prefer to not modify fig.6 (keep it simple + we are not dealing with
signalling flows issued from the UE).
Thanks for the review.
Cheers,
Med
De : Tina TSOU
Dear Wes,
Thank you for your comments.
Please see inline.
Cheers,
Med
-Message d'origine-
De : George, Wes [mailto:wesley.geo...@twcable.com]
Envoyé : mardi 4 décembre 2012 21:09
À : BOUCADAIR Mohamed OLNC/OLN; f...@ietf.org; int-area@ietf.org
Cc :
Dear all,
We submitted an updated version of this draft to list use cases which encounter
the issue of host identification. The following use cases are discussed in the
draft:
(1) Carrier Grade NAT (CGN)
(2) A+P (e.g., MAP )
(3) Application Proxies
(4) Provider Wi-Fi
(5)
Dear Scott,
As currently defined in draft-boucadair-connectivity-provisioning-profile, IRS
level is not in the scope.
IRS does not intervene in the same level as the proposed CPP but some IRS
actions (e.g., tweak RIB entries, add a new routing topology (using MT-ISIS or
MT-OSPF) or adding a
Re-,
If /128 is used to enforce the policies then there is no issue at all.
The point is that using /128 to black list a spammer for instance is not
efficient; that's why it is likely servers will use the first 64 bits (or even
/56) to install a filterthe damage can be restricted to a
Re-,
This version integrates the comments from J. Halpern. Many thanks to Joel for
the review.
A diff is provided below to see the changes.
Cheers,
Med
-Message d'origine-
De : i-d-announce-boun...@ietf.org
[mailto:i-d-announce-boun...@ietf.org] De la part de
Dear Joel,
Thank you for the review.
Please see inline.
Cheers,
Med
-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de Joel M. Halpern
Envoyé : lundi 20 août 2012 22:52
À : Internet Area
Objet : [Int-area] Nat Reveal Analysis
My
Dear all,
The main changes are:
* Remove the recommendation text
* Add a new solution using an out-of-band mechanism (IDENT)
* Add a reference to A+P
* Several editorial changes to integrate the comments received during WGLC
A diff link is provided below.
Cheers,
Med
-Message
Dear SM,
Please see inline.
Cheers,
Med
-Message d'origine-
De : SM [mailto:s...@resistor.net]
Envoyé : mercredi 1 août 2012 00:15
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : int-area@ietf.org
Objet : RE: [Int-area] Comments on
draft-ietf-intarea-nat-reveal-analysis-02
Hi Med,
At 01:17
Hi Behcet,
The argument I heard in Paris meeting for including a recommendation is to help
vendors to select the solution to implement in their devices. They can not
provide the same feature using 8 implementation options. That argument makes
sense to me.
Now, as I said earlier, I will
Dear Joe, all,
Apologies for the delay to answer (I was out of office).
I have no problem to remove Section 3.3 if this is what the WG wants. As a
reminder, I added that section after the Paris meeting in accordance with what
I heard in the meeting: more voices in favour of adding a
Dear Lars,
Please see inline.
Cheers,
Med
-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de Eggert, Lars
Envoyé : vendredi 6 juillet 2012 09:40
À : Alissa Cooper
Cc : Internet Area
Objet : Re: [Int-area] ACTION REQUIRED: Extending
Dear Wes,
Please see inline.
Cheers,
Med
-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de Wesley Eddy
Envoyé : mardi 10 juillet 2012 01:26
À : Tina TSOU
Cc : int-area@ietf.org
Objet : Re: [Int-area] Comments on
Dear SM,
Apologies for the delay to answer.
Please see inline.
Cheers,
Med
-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de SM
Envoyé : samedi 7 juillet 2012 10:41
À : int-area@ietf.org
Objet : [Int-area] Comments on
Dear Suresh, all,
After reading received comments, the major point we need to discuss is whether
the WG wants to remove Section 3.3 or maintain it. I'm waiting for a feedback
from the WG for the direction to take. I will implement any change requested by
the WG.
Cheers,
Med
-Message
1 - 100 of 124 matches
Mail list logo
