-08 for this section. A
diff of the latest rev with rev -08 used in the LC is available here:
http://www.erg.abdn.ac.uk/~gorry/ietf/draft-ietf-6man-diff-08-10.html
We think this includes the work needed for this draft after the Last Call.
Best wishes,
Gorry Magnus
On 21/01/2013 13:37
My thoughts are: This moves to clash with TCPM, where I have a draft and
is a busy meeting for me.
Gorry
All,
there is a suggestion by our AD to move the 6man session from Monday
morning to Tuesday morning.
this is to allow Apps people to participate in the discussion on the URI
draft
That is helpful. There's obviously a few details to be sorted in this
rearrangement of text (and some other people's comments still to
incorporate), we now need to affirm we are on the correct path. Magnus and
I will liaise and work with the 6man chairs.
Thanks for the feedback,
Gorry
Barry
See comments in-line.
Gorry
On 10/10/2012 09:59, Magnus Westerlund wrote:
On 2012-10-09 20:57, Ronald Bonica wrote:
Ronald Bonica has entered the following ballot position for
draft-ietf-6man-udpzero-06: Discuss
When responding, please keep the subject line intact and reply to all
email
See in-line:
On Tue, 13 Mar 2012, Marshall Eubanks wrote:
Dear Gorry;
Thanks for the read.
On Tue, Mar 13, 2012 at 4:47 PM, Gorry Fairhurst go...@erg.abdn.ac.uk wrote:
Marshall Philip, I've read the new draft, and have a few new comments.
Hope these are helpful - happy to discuss
This all sounds good to me. I like the idea of a new rev. next week,
thanks Marshall,
Gorry
On Wed, 14 Mar 2012, Marshall Eubanks wrote:
Dear Gorry;
A few matters in-line.
On Wed, Mar 14, 2012 at 4:31 AM, go...@erg.abdn.ac.uk wrote:
See in-line:
On Tue, 13 Mar 2012, Marshall Eubanks
Marshall Philip, I've read the new draft, and have a few new
comments. Hope these are helpful - happy to discuss if this seems useful.
Best wishes,
Gorry
BOILER PLATE:
- Please an Updates line:goprry
Updates RFC2460 (if approved)
Section 3:
there is no additional
benefit
a
different topic.
The note mentions normal stacks: Normal stacks do not keep state when
the IP packet has been resembled (forwarded), but do keep it while the IP
packet is not complete. Hence, if the packet did not reassemble, the
overlap state would be kept.
Gorry
The following errata report
on this,
best wishes,
Gorry
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
, or a good idea for some
future work: There have been other initiatives in the IETF that have
looked at the pros and cons of separating the endpoint and routing
functions.
I'd be most happy to do a detailed review of a new version.
Gorry
On 14/04/2011 13:09, Chimento, Philip F. wrote:
Hi Magnus
OK. We'll revise draft-fairhurst-tsvwg-6man-udpzero accordingly.
Do let us know if you are inspired to progress with an I-D on this topic
- to me this seems like a more general network issue, rather than being
transport-related, so a separate I-D could be a good idea.
Gorry
Brian E
preferable to recommending the IETF
design a new transport protocol variant/mechanism to solve this
particular problem. Does this seem within the spirit of RFC ?
Best wishes,
Gorry
P.S. I now have a marker in the draft to update this in the next rev.
Brian E Carpenter wrote:
I may have
Using UDP-Lite would be fine. I'm not sure how a transition to UDP with
no checksum would help the transport concerns with mis-delivery, etc.
Gorry
Margaret Wasserman wrote:
I had a thought on the use of zero UDP checksums in IPv6...
What if we allowed the use of zero checksums for UDP
.
Gorry
Margaret Wasserman wrote:
On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
We intend to rev this shortly and comments would be appreciated.
If you do rev this document, I would like to see:
(1) An explanation
NAT boxes
too.)
SNIP
UDP-Lite spec: RFC 3828.
UDP-Lite MIB: RFC 5097.
Unicast UDP Usage Guidelines (for UDP and UDP-Lite): RFC 5405.
UDP-Lite has been part of the Linux kernel since version 2.6.20.
Gorry
IETF IPv6 working
views here and it would be good to get to the bottom of this.
A few other comments in-line,
Gorry
Gorry Fairhurst wrote:
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento
Rémi Denis-Courmont wrote:
Hello,
I take the freedom to move this to 6man mailing list...
Thanks, please see below.
On Thu, 02 Jul 2009 19:30:54 +0100, Gorry Fairhurst go...@erg.abdn.ac.uk
wrote:
Have you any comments on:
draft-fairhurst-6man-tsvwg-udptt-01
I am trying to figure-out
OK, so the action I take is that I think there should be some text added
to explain this case. When I get to making the next revision, I'll send
you the text to make sure this is covered.
Thanks,
Gorry
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
Gorry Fairhurst wrote
in Stockholm, but would
appreciate feedback before the meeting from anyone with comments or
thoughts on this topic.
Best wishes,
gorry
The UDP Tunnel Transport mode
draft-fairhurst-6man-tsvwg-udptt-01
Independent Submission
Number_of_pages: 16
http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points
IETF meeting (or even converge
on a combined draft). All comments welcome, - on or off list.
Best wishes,
Gorry
Begin forwarded message:
From: Pekka Savola pek...@netcore.fi
Date: June 4, 2009 8:50:43 GMT+02:00
To: Brian Haberman br...@innovationslab.net
Cc: mboned-cha...@tools.ietf.org
-designed
application too.
- Incremental updating of checksums is allowed with UDP-Lite, so
middleboxes can process as per UDP. A middlebox that recalculates or
verifies the checksum would require an IPv6 NAT update to revise the cksum.
Thoughts?
Gorry Fairhurst
of such a change also raises transport-layer
issues. I have some comments from this perspective on the draft (below).
Best wishes,
Gorry
---
1) Page 2, 1.2
- While it is true that a UDP over IPv4 session can disable the
checksum, this is not recommended (e.g. RFC 5405). So, although
23 matches
Mail list logo
