Linda,
On Jun 25, 2013, at 5:04 PM, Linda Dunbar wrote:
> Ron,
>
> Your draft recommends that the ingress node discards the frame and sends ICMP
> msg to the source node when the size of GRE encapsulated frame exceeds link
> MTU.
> We experienced that Window XP doesn't adjust frame size aft
This was discussed in the 6man session at IETF96. See:
https://www.ietf.org/proceedings/96/slides/slides-96-6man-4.pdf
Minutes, audio, video:
https://www.ietf.org/proceedings/96/6man.html
Bob
> On Nov 29, 2016, at 8:36 PM, Suresh Krishnan
> wrote:
>
> Hi all,
>I am considering AD spo
>
>>
>>> Finally, how do you know when you can even use this? Legacy devices
>>> could choke on such packets - whether routers or endpoints.
>> That is a real concern, yes. For the same reason that new transports
>> like SCTP and DCCP have been proven difficult to deploy. With this
>> proposal,
Hi,
I read the document and have some comments.
Overall I think working on Provisioning Domains is fine in Int-Area, but I
think the document has issues that need to be resolved. I will leave it for
the w.g. chairs to decide if they need to be fixed before or after adoption.
Specific comments
Brian,
> On Sep 28, 2017, at 12:44 PM, Brian E Carpenter
> wrote:
>
> Commenting on a few of Bob's comments:
>
> On 28/09/2017 11:04, Bob Hinden wrote:
> ...
>>> L-flag : (1 bit) Whether the router is also providing IPv4
>>> access u
> On Oct 1, 2017, at 10:10 PM, Suresh Krishnan
> wrote:
>
>
>> On Oct 2, 2017, at 12:38 AM, Melinda Shore wrote:
>>
>> On 10/1/17 8:13 PM, Andrew Sullivan wrote:
>>> I have a proposal for the chairs: solicit interest in pursuing the
>>> topic by asking for prospective subscribers to a mailin
Hi Eric,
> On Oct 2, 2017, at 7:04 AM, Eric Vyncke (evyncke) wrote:
>
> Bob,
>
> Thanks for your support and more important for your review!
Happy to help.
>
> [Would I dare to say that it was hard to spot your email inside the IPv10
> flood? ;-) ]
I didn’t notice yours right away for the
6man as well, depending on what is in the actual document.
Bob
> On Oct 3, 2017, at 1:42 AM, Samita Chakrabarti wrote:
>
> Thanks Suresh, for sharing the information. It looks quite relevant to 6lo WG
> workarea. We, 6lo-chairs will contact Scott and the ITU-T contact person
> provided in the
>>
>> If you are interested in participating in the work mentioned above, please
>> respond to this mail expressing your support by October 17, 2017.
>>
> The draft and the concept have been thoroughly discussed on int-area
> list (twice). I don't see that the problem is worth solving, the
> prop
Jinmei,
> On Oct 11, 2017, at 10:29 AM, 神明達哉 wrote:
>
> At Wed, 11 Oct 2017 13:57:57 +,
> "Eric Vyncke (evyncke)" wrote:
>
>> Regarding the way to represent the FQDN, the authors do not have any
>> hard position. It seems to us that plain ASCII is easier and
>> shorter.
>
> "Shorter" is c
Xiaohu,
This document should refer to the new versions of the IPv6 and IPv6 PMTU RFCs
specifications (RFC8200 and RFC8201). Please check if you need to change any
text in your draft to be consistent with these.
Thanks,
Bob
> On Oct 17, 2017, at 6:42 PM, Xuxiaohu wrote:
>
> Hi all,
>
> I j
Joe,
> On Mar 5, 2018, at 7:01 AM, Joe Touch wrote:
>
> This doc completely overlooks the role of fragmentation in IP over IP
> tunneling and the reason fragmentation is critical (IP has a maximum packet
> size, not just a minimum).
>
> See draft-ietf-intarea-tunnels.
Good point. We will ta
Mirja,
I don’t see an abstract for "Privacy and Security Issues in IPv6 Deployment”
talk on the agenda page you linked. Is that available?
Bob
> On Oct 31, 2018, at 5:09 AM, Mirja Kühlewind
> wrote:
>
> Hi int floks,
>
> we will have a short heads-up talk on Privacy and Security Issues in
>
>
>> Am 31.10.2018 um 16:52 schrieb Bob Hinden :
>>
>> Mirja,
>>
>> I don’t see an abstract for "Privacy and Security Issues in IPv6 Deployment”
>> talk on the agenda page you linked. Is that available?
>>
>> Bob
>>
>&g
Tom,
> On Apr 8, 2019, at 11:01 AM, Tom Herbert wrote:
>
> Hello,
>
> I have posted a draft describing IPv4 extension headers an flow
> labels. Previously this was in draft-herbert-ipv4-udpencap-eh-01, but
> it seems like this is an important topic in its own right.
>
> I would like to request
Tom,
> On Aug 9, 2019, at 7:47 AM, Tom Herbert wrote:
>
>
> As the document highlights the problems of fragmentation are caused by
> nonconformant middlebox implementations. There is nothing inherently
> wrong with the fragmentation and end hosts don't a problem with it.
> IMO, this is just one
Joel,
> On Aug 15, 2019, at 7:00 AM, Joel Halpern wrote:
>
> Bob was going to engage Alissa in a conversation. Bob, have you gotten
> anywhere? I think she may be on vacation.
I sent Alissa some proposed text, but got back what I interpreted as a vacation
email. I note there is an IESG ca
Manoj,
> On Aug 17, 2019, at 8:05 AM, Manoj Nayak
> wrote:
>
>
> Folks,
>
> We have posted 01 version of the draft “Probing IP Interfaces By Vendor
> Specific Identifiers”.
> This draft is extension to PROBE [RFC8335] diagnostic tool. The tool is
> extended so that the
> tool can identify
Fred,
> On Sep 3, 2019, at 7:33 AM, Templin (US), Fred L
> wrote:
>
> Why was this section taken out:
>
>> 1.1. IP-in-IP Tunnels
>>
>> This document acknowledges that in some cases, packets must be
>> fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels].
>> Therefore, this doc
Fred,
> On Sep 3, 2019, at 12:45 PM, Templin (US), Fred L
> wrote:
>
> Bob,
>
>> -Original Message-
>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>> Sent: Tuesday, September 03, 2019 9:10 AM
>> To: Templin (US), Fred L
>> Cc: Bob
that is mentioned in
> the introduction.
I am serving as document editor. This to my understanding has been through
w.g. last call and now IESG review.
>
> Tom
>
>
>
> Tom
>
>
>
>
>
> On Tue, Sep 3, 2019 at 1:01 PM Bob Hinden wrote:
>>
Joe,
> On Aug 30, 2019, at 4:36 PM, Joe Touch wrote:
>
> Hi, all,
>
> I disagree with the changes indicated in this version.
>
> The new text is both incorrect does not IMO reflect WG consensus.
>
> It is simply false that "it WILL break" or "new protocols can't possibly know
> whether fragm
Fred,
> On Sep 3, 2019, at 2:10 PM, Templin (US), Fred L
> wrote:
>
> Bob,
>
>> -Original Message-
>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>> Sent: Tuesday, September 03, 2019 1:57 PM
>> To: Tom Herbert
>> Cc: Bob Hinden ; Templ
Tom,
> On Sep 3, 2019, at 2:20 PM, Tom Herbert wrote:
>>
>> The relevant text in -16 is:
>>
>> 6.1. For Application and Protocol Developers
>>
>> Developers SHOULD NOT develop new protocols or applications that rely
>> on IP fragmentation. When a new protocol or application is deployed
>>
Fred,
> On Sep 4, 2019, at 7:23 AM, Templin (US), Fred L
> wrote:
>
> Bob,
>
>> -Original Message-
>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>> Sent: Tuesday, September 03, 2019 5:08 PM
>> To: Templin (US), Fred L
>> Cc: Bob Hinde
Hi,
Based on the discussion, I would like to propose to see if this will resolve
the issues raised. It attempts to cover the issues raised.
The full section 6.1 is included below, but only the last sentence in the
second paragraph changed.
Please review and comment.
Thanks,
Bob
6.1. For
here are others.
Bob
>
> Thanks - Fred
>
>> -Original Message-
>> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Bob Hinden
>> Sent: Thursday, September 05, 2019 11:29 AM
>> To: int-area@ietf.org
>> Cc: IESG ; Joel Halpern ;
&g
Fred,
> On Sep 5, 2019, at 12:57 PM, Templin (US), Fred L
> wrote:
>
>>>
>>> Your effort is appreciated, but IMHO does not quite go far enough. Here is
>>> a proposed edit:
>>
>> Thanks!
>>
>>>
>>> OLD:
>>> Protocols and applications that rely on IP
>>> fragmentation will work less reliab
Tom,
> On Sep 5, 2019, at 12:53 PM, Tom Herbert wrote:
>
> On Thu, Sep 5, 2019 at 11:29 AM Bob Hinden wrote:
>>
>> Hi,
>>
>> Based on the discussion, I would like to propose to see if this will resolve
>> the issues raised. It attempts to cover the
;> Ron
>>
>>
>> Juniper Business Use Only
>>
>> -Original Message-
>> From: Bob Hinden
>> Sent: Thursday, September 5, 2019 2:29 PM
>> To: int-area@ietf.org
>> Cc: Bob Hinden ; Alissa C
Ole,
> On Sep 6, 2019, at 9:03 AM, Ole Troan wrote:
>
>
> This document should not recommend IP in UDP in IP encapsulation to achieve
> end to end IP fragmentation for new applications.
The document doesn’t say that, nor is the document recommending this. The
current text Joe and I proposed
Ole,
> On Sep 6, 2019, at 9:03 AM, Ole Troan wrote:
>
>
> This document should not recommend IP in UDP in IP encapsulation to achieve
> end to end IP fragmentation for new applications.
The document doesn’t say that, nor is the document recommending this. The
current text Joe and I proposed
Fred,
> On Sep 11, 2019, at 7:48 AM, Templin (US), Fred L
> wrote:
>
> Geoff, the 1280 MTU came from Steve Deering's November 13, 1997 proposal to
> the ipngwg. The exact message from the ipng archives is reproduced below.
>
> 1280 isn't just a recommendation - it's *the law*. Any link that ca
Andy,
> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis wrote:
>
> Behcet,
>
> That was a historical list. The current assignments are in
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml ..
> If you want to go garbage collecting, that's the place to start.
It's diffic
Brian, Joe,
> On Sep 20, 2019, at 8:23 PM, Brian E Carpenter
> wrote:
>
> On 21-Sep-19 14:11, Joe Touch wrote:
>> FWIW, there are many registries with such “dead” entries.
>
> 114 is a bit special. By definition, all our normal traffic monitoring
> techniques will *never* see protocol 114 unl
Adrian,
> On Sep 22, 2019, at 8:20 AM, Adrian Farrel wrote:
>
> Hi Bob,
>
>> I think it would be fine for this draft to request a new one that accurately
>> described its usage.
>
> For what it's worth, the assignment policy for the registry is IESG Approval
> or Standards Action.
>
> The d
Joe,
> On Sep 28, 2019, at 8:05 AM, Joe Touch wrote:
>
> Hi, David,
>
> Although I appreciate new interest in trying this experiment, that’s not what
> I was asking.
>
> My understanding of the logic is as follows:
> - IPv4 in-header options aren’t supported
> - so let’s make a ve
Greg,
> On Oct 23, 2019, at 6:44 AM, Greg Mirsky wrote:
>
> Dear Authors, et al.,
> I have a rather benign question the new registry requested in Section 8.3.
> The draft states that the whole 1-127 range is "RFC required" per RFC 5226.
> Firstly, a nit - RFC 5226 has been obsoleted by RFC 812
Ron,
A few comments on your draft.
Naming the draft "Lossless Path MTU Discovery (PMTUD)” seems to be very
aspirational, and is an oxymoron. ICMP message can be rate limited and dropped
in the network. Hardly “lossless”. A different title might be better.
I do like the idea of the destinat
Rob,
What exactly do you mean by GPS over wifi?
Do you mean sending location/course/speed/etc. data over wifi? Or somehow
replicating the actual GPS satellite data?
I don’t see how the latter would work giving the timing requirements.
There are lots of current practice in sending NMEA senten
Is there going to be an Int Area interim meeting scheduled? Or did I miss it?
Bob
signature.asc
Description: Message signed with OpenPGP
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
; be cancelling the IntArea WG session for IETF 107.
> We are sorry about the inconvenience.
> If you are interested in presenting at a future virtual or physical (IETF
> 108) meeting, please contact Wassim and myself.
>
>
> Regards,
>
> Wassim H.
>
>
> On 3/27/20,
Fred,
> On Apr 16, 2020, at 2:36 PM, Templin (US), Fred L
> wrote:
>
> Hi, two important documents in this wg have been sitting idle for a long time
> and
> perhaps it is time to start moving them forward again. The documents are: "IP
> Fragmentation Considered Fragile", and "IP Tunnels in the
Fred,
> On Apr 17, 2020, at 10:23 AM, Templin (US), Fred L
> wrote:
>
> Hi Bob,
>
>> -Original Message-
>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>> Sent: Friday, April 17, 2020 9:38 AM
>> To: Templin (US), Fred L
>> Cc: Bob Hi
HI,
Why is the intended status Experimental?
RFC1928 was standards track, nor do I see any mention of experiments in the
draft.
Bob
> On Aug 26, 2020, at 12:33 PM, Juan Carlos Zuniga
> wrote:
>
> Dear IntArea WG,
>
> Now with the summer almost over and following the strong support shown a
Good, thanks.
Bob
> On Aug 27, 2020, at 12:19 PM, Vladimir Olteanu
> wrote:
>
> Hi,
>
> Oops, it should be "Standards Track". I'll fix it in the next version.
>
> Thanks for pointing that out.
>
> Vlad
>
> On 8/27/20 10:15 PM, Bob Hin
I have read the emails and the draft . I
am not clear what the goal of the BOF is.
Could the proponents state it clearly?
From the agenda, Use Cases:
• LAN gateway NAPT forwarding - (PRESENTER TBD)
• Static NAPT policies - (PRESENTER TBD)
• Persistent DHCP IP address a
Hi Shuping,
> On Mar 12, 2021, at 7:34 AM, Pengshuping (Peng Shuping)
> wrote:
>
> Hi Folks,
>
> Please find below the FAQs I listed in the slides but did not get time to
> present. Your comments and feedback are very much welcomed. Thank you!
>
> You can also find the slides here. There are
g?
Bob
>
> Thank you!
>
> Best regards,
> Shuping
>
>
>> -Original Message-
>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>> Sent: Friday, March 12, 2021 11:49 PM
>> To: Pengshuping (Peng Shuping)
>> Cc: Bob Hinden ; int-area@
Seth,
Do I understand correctly, that you are proposing that all hosts, routers,
firewalls, middle boxes, etc. on the Internet, be updated in order to get a
single extra IP address per subnet? Plus then having to deal with the
complexities of mixed implementations for a very long transition pe
Seth,
> On Aug 2, 2021, at 5:14 PM, Seth David Schoen wrote:
>
> Bob Hinden writes:
>
>> Seth,
>>
>> Do I understand correctly, that you are proposing that all hosts, routers,
>> firewalls, middle boxes, etc. on the Internet, be updated in order to g
> On Mar 15, 2022, at 3:31 PM, to...@strayalpha.com wrote:
>
>> On Mar 15, 2022, at 1:04 PM, Brian E Carpenter
>> wrote:
>>
>> FWIW I do not consider the minor wastage of IPv4 addresses that
>> the same authors are concerned about to be serious enough to need
>> fixing.
>
> +1 on that, espec
Hi,
I agree with the other comments that this shouldn’t be adopted at this point.
Another point is that what I understand this is proposing would appear to have
non-trivial effect on current transport protocols, as it will add delay to
create the “parcels”. I don’t see this issue discussed in
I support the adoption of this document. Good to have this all written down
in one place.
Bob
> On Aug 31, 2022, at 10:42 AM, Juan Carlos Zuniga (juzuniga)
> wrote:
>
> Dear IntArea WG,
>
> We are starting a 2-week call for adoption of IANA Considerations and IETF
> Protocol and Document
Bob,
Once there is an adoption call, I will support it.
I did a quick read of the draft and have a few suggestions, mostly editorial.
Please be careful with the terminology. The registry where you are asking for
an assignment is called “Internet Protocol Numbers”. I was confused by the
use
h. Or just leave it as TBD, unless you care about what number
is assigned.
>
> I look forward to your response, then I will push out a new ver.
Hope this is helpful.
>
> Bob M. (are there as many 'Bobs' as "Steves" here ;) )
:-)
Bob
>
>
>
&g
raft-moskowitz-intarea-schc-ip-protocol-number
>
>
> As was discussed at the INTAREA meeting at IETF 114,
>
> I request that a call for WG adoption of this draft.
>
> I have made draft name change and edits per Bob Hinden.
>
> As I said earlier, there is a lot of work
t; On 9/7/22 15:15, Carsten Bormann wrote:
>> On 2022-09-07, at 18:36, Bob Hinden wrote:
>>> Is this an IPv6 extension header?Does SCHC include a next header field
>>> so it can point to a header that follows?
>> If you haven’t seen RFC 5856 to 5858: This is a mi
Bob,
> On Sep 7, 2022, at 1:53 PM, Robert Moskowitz wrote:
>
>
>
> On 9/7/22 16:04, Bob Hinden wrote:
>> Bob,
>>
>> To clarify my question, it only relates to if SCHC should be added to the
>> IPv6 Extension Header Types registry. I continue to thin
t-header field. (AH does). But if we are going to pretend that some
> headers are extensions headers and some are not, we should try to be
> consistent with the description in 8200 (and 2460).
>
> On 9/7/2022 4:57 PM, Robert Moskowitz wrote:
>>
>>
>> On 9/7/22 16:3
Much like IPv6 (in
>>>> IPv6). Or UDP (with carrying an application protocol or carrying
>>>> some routing header like GRE, LISP, ...) or ...
>>>>
>>>> Yours,
>>>>
>>>> Joel
>>>>
>>>> PS: I grant we
I support adoption. I have reviewed the draft and think it is reasonable to
assign an IP Protocol Number for SCHC.
Bob
> On Sep 13, 2022, at 7:15 PM, Wassim Haddad
> wrote:
>
> Dear IntArea WG,
>
> We are starting a 2-week call for adoption of “Internet Protocol Number for
> SCHC” draft:
Don,
Adding a procedure describing how to obtain an Ethertype for IETF work seems
reasonable to me as well.
Bob
> On Nov 10, 2022, at 12:24 PM, Donald Eastlake wrote:
>
> During the INTAREA WG meeting yesterday, there was a desire expressed
> to include in the rfc7042bis draft an explicit pr
Bob,
It’s only the draft file name, you can change the title of the document and
keep the same file number. That would make it easier to see the evolution of
the work.
Chag Sameach!
Bob
> On Apr 5, 2023, at 10:58 AM, Robert Moskowitz
> wrote:
>
> The origin draft only was discussing S
Hi,
I generally support advancing this document, but I noticed an issue that should
be resolved.
In Section 2.2.1. "IPv6 Use of Modified EUI‑64 Identifiers”.The contents is
technically correct, but it should also mention that this type of IPv6
Interface Identifiers are no longer recommende
Donald,
> On May 9, 2023, at 6:37 PM, Donald Eastlake wrote:
>
> Hi Bob,
>
> On Tue, May 9, 2023 at 11:29 AM Bob Hinden <mailto:bob.hin...@gmail.com>> wrote:
> >
> > Hi,
> >
> > I generally support advancing this document, but I noticed a
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> d3e...@gmail.com <mailto:d3e...@gmail.com>
>
> On Tue, May 9, 2023 at 11:42 PM Bob Hinden <mailto:bob.hin...@gmail.com>> wrote:
> Donald,
>
>> On May 9, 2023, at
Donald,
I looked at the diff. This resolves all of the issues I raised.
Thanks!
Bob
> On May 12, 2023, at 9:38 AM, Donald Eastlake wrote:
>
> This revision includes the improvements suggested by Bob Hinden and
> has updated author info.
>
>
Lin,
I did a quick read of this draft.It doesn’t appear to discuss several
important issues related to MAC address and IP address binding. These includes:
Random Mac address assignments (there is an IETF w.g. MADINAS working in this
area)
IPv6 Interface ID assignments (see RFC7217 , RFC 80
Tal,
I did a quick read of your draft.
As noted in the draft this seems to be very similar to ICMPv6 Echo/Echo Reply.
The change is to include the request packet in the response, not just the
payload.
While I don’t have any real opinion on the need for this, I do think it would
be a lot si
Tal.
>>
>> On Tue, Jun 6, 2023 at 8:33 PM Eric Vyncke (evyncke)
>> wrote:
>>> Without any hat, I agree with Bob.
>>>
>>> This I-D should eventually go to 6MAN WG though (with my AD hat)
>>>
>>> -éric
>>>
>>>
Warren,
Just to confirm, this is:
https://datatracker.ietf.org/doc/draft-chroboczek-int-v4-via-v6/
currently at -02. Correct?
I think this is a good idea and support it. I will try to review it and
provide more comments. The ICMP behavior is an interesting problem.
Bob
> On Jan 22, 20
Tom,
> On Mar 21, 2024, at 2:20 PM, Tom Herbert
> wrote:
>
> On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert wrote:
>>
>> Btw: When i asked on of the 6MAN chairs, about the meaning of an Internet
>> Protocol
>> Number being an "IPv6 Extension Header" or not, the answer was that in his
>> int
Tom,
> On Jun 20, 2024, at 3:49 AM, tom petch wrote:
>
> From: Ron Bonica
> Sent: 20 June 2024 01:25
>
> Folks,
>
> Please take a look at this draft. There is nothing new or shocking in it. It
> is mostly an annotated bibliography regarding ICMP.
>
> I prepared this document so that it can
Rolf,
> On Jul 21, 2024, at 11:41 PM, Rolf Winter wrote:
>
> Dear Eric,
>
> thank you for your comments. I inlined my replies.
>
> Am 21.07.24 um 16:51 schrieb Eric Vyncke (evyncke):
>> Dear authors,
>> Without any hat (i.e., feel free to ignore), in preparation for the IETF-120
>> I have rea
On Nov 9, 2009, at 1:34 PM, Brian E Carpenter wrote:
Hi Jari,
On behalf of 3GPP, 3GPP SA would like to propose a joint workshop on
IPv6 migration with IETF, sharing the understanding of requirements
and
solutions on IPv6 migration. SA2, CT1, CT3 and CT4 are the main
related
working group
Marla,
On Feb 4, 2010, at 3:27 PM, Azinger, Marla wrote:
> Hello-
>
> We have produced a draft document that summarizes the IPv4 Private IP Address
> issues and alternatives that we face today. We believe this document belongs
> in OPSAWG however we would like input from more of the communit
On Aug 31, 2010, at 11:33 AM, Dan Wing wrote:
> A paper was published in 2004 which analyzed the success of new IP options
> and new TCP options,
>
> "Measuring Interactions Between Transport Protocols and Middleboxes"
> Alberto Medina, Mark Allman, Sally Floyd
> http://conferences.sigcomm.or
Dan,
>>> No. It's very likely only gotten work since the 2004 paper.
>
> Off list, someone else suggested it had gotten better. So I tested
> the top sites from Alexa's list using NMAP, and results were:
>
> TCP 3-way handshake without IP option: 99% success
> TCP 3-way handshake with IP o
Scott,
On May 2, 2011, at 4:17 PM, Scott Brim wrote:
> Folks, the IntArea WG meeting in Prague was frustrating for some
> because there was not enough discussion time among the presentations.
> We have been talking about ways to do better, and how to make it easier
> for the WG to be productive.
Scott,
On May 5, 2011, at 5:28 AM, Scott Brim wrote:
> On Wed, May 4, 2011 at 14:51, Bob Hinden wrote:
>>
>> I am generally supportive of this approach. It's the approach all working
>> groups should use.
>>
>> My only concern is that I wonder if
On Jun 4, 2011, at 10:36 AM, Joel Jaeggli wrote:
> I think it's a little sad that we have to state the painfully obvious but I
> support the sentiment unequivocally.
+6
Bob
>
> joel
>
> On Jun 2, 2011, at 4:53 PM, Jared Mauch wrote:
>
>> I support adoption of this draft as well.
>>
>>
>
Fred,
This sounds a lot like Mobile IPv6 with the extension that the client can
change home agents if the client get's too far away from where the the home
agent is. I am sure the details are different, but the functionality sounds
similar.
Bob
On Jun 14, 2011, at 5:12 AM, Templin, Fred L w
Support.
Bob
On Dec 18, 2012, at 4:45 AM, Suresh Krishnan wrote:
> Hi all,
> This draft has been presented at intarea face to face meetings and has
> received a bit of discussion. It has been difficult to gauge whether the
> wg is interested in this work or not. This call is being initiated to
84 matches
Mail list logo
