Reviewer: Brian Haberman
Review result: Not Ready
This is an early review request for draft-ietf-dmm-ondemand-mobility.
I am having a hard time with the thrust of this document. The following issues
really need to be addressed in some form...
1. Where is the concept of an IP session defined
I had intended to bring this up during the session, but we are/were
pressed for time...
On 10/26/15 9:22 PM, Peter McCann wrote:
> I don't understand why you think it needs to be so complicated. It
> seems much simpler than the other prefix coloring approaches I have
> seen being suggested, and
Hi Fred,
On 7/14/15 10:54 AM, Templin, Fred L wrote:
Hi Sri,
Reason for the X.509 certificate is that, in some environments, an
attacker can
spoof a DHCP Client Identifier and receive services that were intended
for the
authentic client. With X.509 certificate, the certificate
On 7/14/15 12:19 PM, Templin, Fred L wrote:
Hi Brian,
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman
Sent: Tuesday, July 14, 2015 8:37 AM
To: dmm@ietf.org
Subject: Re: [DMM] RFC4283bis progress..
Hi Fred,
On 7/14/15 10:54 AM, Templin
On 4/22/15 12:51 PM, Templin, Fred L wrote:
Hi Alex,
-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Sent: Tuesday, April 21, 2015 12:42 PM
To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org
Subject: Re: [DMM] Mobility Exposure and Selection WT
On 4/27/15 12:30 PM, Templin, Fred L wrote:
Hi Brian,
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman
Sent: Monday, April 27, 2015 9:22 AM
To: dmm@ietf.org
Subject: Re: [DMM] Mobility Exposure and Selection WT call
On 4/27/15 11:53 AM
On 4/27/15 11:53 AM, Templin, Fred L wrote:
So, it is not actually a link-local address per the IPv6 Addressing
Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6).
Just because the AERO address Interface ID is not formed via EUI-64
does not mean that it is not a link-local
DMM WG,
I want to, once again, clarify the guiding principles for the DMM
work teams. Hopefully, this will make it clear to all participants how
the work teams will influence the WG. The guiding principles are:
1. All work teams are open to input from anyone
2. Any work team holding a
, Brian Haberman a écrit :
Alex (and others),
On 10/24/14 11:00 AM, Alexandru Petrescu wrote:
But under no circumstances should they become unaccountable
with respect to the WG at large.
Please (re-)read what I posted about these teams a little while
ago.
http://www.ietf.org/mail-archive/web
Alex (and others),
On 10/24/14 11:00 AM, Alexandru Petrescu wrote:
But under no circumstances should they become unaccountable with
respect to the WG at large.
Please (re-)read what I posted about these teams a little while ago.
http://www.ietf.org/mail-archive/web/dmm/current/msg01627.html
Something for you to be aware of...
Brian
Original Message
Subject: New Liaison Statement, Broadband Forum Work on “Hybrid Access
for Broadband Networks” (WT-348)
Date: Tue, 21 Oct 2014 09:06:52 -0700
From: Liaison Statement Management Tool l...@ietf.org
To: The IETF Chair
Just for clarification...
On 9/3/14 12:22 PM, Behcet Sarikaya wrote:
I am also concerned on the time DMM is taking on dressing up the
charter text. I remind you on what Jari Arkko who is founding AD for
DMM said in Toronto admin plenary:
WGs should have solution work from day 1.
Not
On 9/3/14 12:50 PM, Behcet Sarikaya wrote:
Hi Brian,
On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman
br...@innovationslab.net wrote:
Just for clarification...
On 9/3/14 12:22 PM, Behcet Sarikaya wrote:
I am also concerned on the time DMM is taking on dressing up the
charter text. I
Behcet,
On 9/3/14 2:33 PM, Behcet Sarikaya wrote:
You don't seem to understand my points.
That is quite possible. Your comment on the list was I am against any
deployment work before we decide on a solution...
I read that as an objection to having the deployment models work item on
the
All,
I have reviewed draft-ietf-dmm-best-practices-gap-analysis as a
part of the publication process. The document is well-written and easy
to follow. I only have a few points I would like to see
addressed/discussed before I move the draft to IETF Last Call.
1. I would suggest making the
On 7/23/14 10:16 AM, Behcet Sarikaya wrote:
So my question is what guarantees that is the DT is going to produce
the right solution and why repeat the history again?
Who said that *if* a DT is formed that its output is considered special?
http://www.ietf.org/iesg/statement/design-team.html
On 7/23/14 10:49 AM, Behcet Sarikaya wrote:
On Wed, Jul 23, 2014 at 9:36 AM, Brian Haberman
br...@innovationslab.net wrote:
On 7/23/14 10:16 AM, Behcet Sarikaya wrote:
So my question is what guarantees that is the DT is going to produce
the right solution and why repeat the history again
On 7/22/14 10:49 AM, Jouni Korhonen wrote:
Folks,
The agenda has been slightly updated (shuffling around the slots and
arranging more time to the charter/next steps discussion). Some
presenters are affected slightly (-5 minutes). see
http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm
All,
It wasn't a false alarm. The original request from the chairs was
for a single session. The chairs contacted me today and asked about the
possibility of a second slot. I was able to work that out with the
Secretariat before most of you reviewed the schedule. Thank the
Secretariat
Hi Fred,
On 6/18/14 11:25 AM, Templin, Fred L wrote:
Hi Jouni,
-Original Message-
From: Jouni Korhonen [mailto:jouni.nos...@gmail.com]
Sent: Wednesday, June 18, 2014 3:00 AM
To: Templin, Fred L; dmm@ietf.org
Subject: Re: [DMM] draft charter text updates in github..
Fred,
It is
Hi Jouni,
On 1/30/14 7:40 PM, Jouni Korhonen wrote:
On Jan 29, 2014, at 6:01 AM, Brian Haberman br...@innovationslab.net wrote:
[snip]
We can change to:
REQ5: Co-existence with deployed networks and hosts
The DMM solution MUST be able to co-exist with existing
Hi Anthony,
On 1/29/14 1:51 PM, h chan wrote:
Brian,
The requirement is intended to include a capability of not using
network-layer mobility management, as opposed to using it by default.
I think it is sufficient to leave to the explanation (the sentences
after the first sentence) to
-Original Message-
From: Brian Haberman [mailto:br...@innovationslab.net]
Sent: Wednesday, January 29, 2014 8:01 AM
To: h chan; draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; Peter
McCann
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
On 1/28/14 4:33 PM, h
already deployed in the field.
H Anthony Chan
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; Peter McCann
Subject: [DMM] AD
...@ietf.org]
On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM
To: h chan; draft-ietf-dmm-requireme...@tools.ietf.org;
dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation:
draft-ietf-dmm-requirements
On 1/24/14 7:38 PM, h chan wrote:
4. Section 4: - I am not sure
Hi Pete,
Speaking with no hat on...
On 11/12/13 4:29 PM, Peter McCann wrote:
Hi, Sri,
Even if we agree that those services are necessary (and I would point out
once again that most of them are not beneficial to the end-user) I don't
think we should be architecting the network in such a
Rather than sink into a re-chartering discussion, I would like the WG to
focus on completing the existing work items. It was suggested that an
interim (or 2) get set up to work on these items. Please focus on this
rather than re-chartering.
Regards,
Your friendly AD
On 11/13/13 3:43 PM, Behcet
. Most of us already have a heavy travel
schedule, squeezing another trip seems not so reasonable.
Regards,
Behcet
On Wed, Nov 13, 2013 at 2:53 PM, Brian Haberman
br...@innovationslab.netwrote:
Rather than sink into a re-chartering discussion, I would like the WG to
focus on completing
On 4/9/13 6:10 PM, Behcet Sarikaya wrote:
I believe multicast is a distraction to dmm at this moment.
I am curious as to why you call it a distraction. It seems to me that
having multicast support considered at the beginning of the process is
much better than trying to bolt it on after
All,
As per the note below, the IEEE has approved the OmniRAN study
group. There is potential for significant interactions between OmniRAN
and the IETF on mobility-related work.
Regards,
Brian
Original Message
Subject: [new-work] Status of Study Groups per November
30 matches
Mail list logo
