Steven Blake | 29 Jan 04:48 2012

[Fwd: I-D Action: draft-blake-nptv6-icmp-01.txt]

Terry Moes and I have submitted this draft (actually version -01) which
describes how NPTv6 translators need to process ICMPv6 error messages.
We believe that this issue was first discovered when Terry built an
NPTv6 implementation for Linux.

We intend to request publication as an individual submission, but first
we would really appreciate your review comments.

Regards,

// Steve
Picon
From: Terry Moes and I have submitted this draft (actually version -01) which describes how NPTv6 translators need to process ICMPv6 error messages. We believe that this issue was first discovered when Terry built an NPTv6 implementation for Linux. We intend to request publication as an individual submission, but first we would really appreciate your review comments. Regards, // Steve <internet-drafts@...>
Subject: I-D Action: draft-blake-nptv6-icmp-01.txt
Date: 2012-01-29 03:37:38 GMT
(Continue reading)

Fred Baker | 3 May 22:31 2011
Picon

Re: NPTv6 deals with "packets", not with "datagrams" - to be corrected after draft-14


On May 3, 2011, at 11:02 AM, Rémi Després wrote:

>> I refer you to the definition of the term. A datagram is self-addressed and contains all of the
information necessary to deliver it from its source to its destination.
> 
> In hosts, which perform datagram reassembly, that's correct.

You really don't understand. The distinction is between datagram networks and virtual circuit (in
context, SNA and X.25) networks. A transport PDU could be carried by a virtual circuit from here to there,
or it could be carried in a datagram over a connectionless network. TCP data is carried in datagrams, and
UDP data is carried in datagrams. NFS routinely used fragmented UDP packets to carry its data, but when UDP
was designed, that was not the intended model; anyone who has done very much UDP-with-fragmentation will
tell you that it operationally doesn't work very well either if there is any kind of bottleneck in the path.

I found a formal definition of the term in RFC 1594:

Datagram
        A self-contained, independent entity of data carrying
        sufficient information to be routed from the source
        to the destination computer without reliance on earlier
        exchanges between this source and destination computer and
        the transporting network.

Is this really worth arguing about? I use the term "datagram" because the meaning is important in the
context; I'm playing with the prefixes in the addresses in the datagram header. I don't use the term
"packet" because it's an empty word; it can be applied at any layer (an ATM "cell" is a packet with a certain
format, an IP datagram is a packet with a certain format, a LAPB or Frame Relay "frame" is a packet with a
certain format, and a TCP segment is a packet with a certain format). A packet is a quantum of data moving as a
single unit in the network at the layer of interest. I'm sorry it bothers you. What NPTv6 deals with is IP
(Continue reading)

Fred Baker | 3 May 17:03 2011
Picon

Re: NPTv6 deals with "packets", not with "datagrams" - to be corrected after draft-14


On May 3, 2011, at 1:38 AM, Rémi Després wrote:
>> I also am confused by your use of the term "datagram". A datagram is not a transport layer construct,
> 
> Isn't User Datagram Protocol a transport layer protocol?

Yes, and unless the datagram is carried in IP, it's not actually a datagram. I refer you to the definition of
the term. A datagram is self-addressed and contains all of the information necessary to deliver it from
its source to its destination.

>> it's a network layer construct. http://dictionary.reference.com/browse/datagram
> 
> To know what a datagram is in IETF, RFC's are IMHO better than an online dictionary

If you want to play that game, so be it. The word "datagram" (along with "catenet", which has largely been
replaced by the term "internet", in lwer case) was common in the 1970's and 1980's, and the definition was
well known to those present. So I don't find a place that says "when I say 'datagram' I mean '...'" in the RFC
series - that was in published conference papers circa 1972 when the datagram model was first being
proposed as an alternative to virtual circuits. What I do find, however, is this in IEN #48. The Internet
Engineering Notes (IENs) were  a parallel document track used in the 1970's. IEN #48 is "The Catenet Model
for Internetworking", written by Vint Cerf. It says, among its assumptions, that 

	it is assumed that the
	participating network allows switched access so that any source
	computer can quickly enter datagrams for successive and different
	destination computers with little or no delay (i.e., on the order
	of tens of milliseconds or less switching time).

	Under these assumptions, we can readily include networks which
	offer "datagram" interfaces to subscribing host computers.  That
(Continue reading)

Fred Baker | 2 May 18:54 2011
Picon

Re: NPTv6 deals with "packets", not with "datagrams" - to be corrected after draft-14


On May 2, 2011, at 5:22 AM, Rémi Després wrote:

> Fred.
> 
> On March 11, 2011 Rémi Després wrote (about the draft -12 in which "datagram" is used interchangeably
with "packet"):
>> ...
>> 3.2 and remainder of the document.
>> The word datagram seems to be used instead of packet:
>> - RFC 2460 doesn't use the word datagram for IPv6, even in case of fragmentation 
>> - In any case, NPTv6 operates individually on packets without concern with reassembling fragments.
> 
> As draft -14 has replaced all occurrences of "packet" by "datagram", there must have been a misunderstanding.
> 
> Since NPTv6 isn't concerned about reassembling transport-layer datagrams (a significant advantage
over NAPT66 whose advantages are on a different ground), the word to be used throughout in the draft  is
"packet". 
> In my understanding, this needs to be fixed in a next version. 

I'm not planning on a next version.

I also am confused by your use of the term "datagram". A datagram is not a transport layer construct, it's a
network layer construct. http://dictionary.reference.com/browse/datagram

We are absolutely discussing datagrams here. Every IP packet is a datagram.
Fred Baker | 22 Apr 00:49 2011
Picon

Re: New Version Notification - draft-mrw-nat66-13.txt

I believe that this addresses the outstanding issues raised by the IESG. I never did get Jari's promised
text suggestion, so I'm hoping that what I put in addresses his concern.

On Apr 21, 2011, at 3:45 PM, Internet-Draft@... wrote:

> New version (-13) has been submitted for draft-mrw-nat66-13.txt.
> http://www.ietf.org/internet-drafts/draft-mrw-nat66-13.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-13
> 
> IETF Secretariat.
Rémi Després | 16 Mar 17:54 2011
Picon

The checksum-neutral mapping and modified EUI-64 IID's

Hi, Fred,

One more remark about the draft:

If I understand correctly the mapping of section 3.5 (/49 or longer prefixes), the external IID may no
comply with the modified IID format. (If the checksum adjustment is done in bits 64..79, the u and g bits may
be changed arbitrarily).

In practice, this shouldn't be a problem  because only internal IID's are involved in link-layer
protocols, but a note about it would IMHO improve the draft.

Regards,
RD 
Fred Baker | 14 Mar 13:54 2011
Picon

Fwd: New Version Notification - draft-mrw-nat66-12.txt

In discussion with Dave Thaler, I came up with an additional consideration in response to the Transport
Directorate review. One of their concerns was that the TCP Authentication Option assumes it has an
end-to-end address; Dave pointed out that any such assumption above the network layer is an UNSAF (RFC
3424) practice. So I added the reference. 

Begin forwarded message:

> From: Internet-Draft@...
> Date: March 13, 2011 11:30:02 PM PDT
> To: mrw@...,
fred@...,
draft-mrw-nat66@..., rbonica@...
> Subject: New Version Notification - draft-mrw-nat66-12.txt
> 
> New version (-12) has been submitted for draft-mrw-nat66-12.txt.
> http://www.ietf.org/internet-drafts/draft-mrw-nat66-12.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-12
> 
> IETF Secretariat.
Fred Baker | 10 Mar 18:03 2011
Picon

Fwd: New Version Notification - draft-mrw-nat66-10.txt

This responds to the Transport Directorate review posted last night.

Begin forwarded message:

> From: Internet-Draft@...
> Date: March 10, 2011 9:00:05 AM PST
> To: mrw@...,
fred@...,
draft-mrw-nat66@..., rbonica@...
> Subject: New Version Notification - draft-mrw-nat66-10.txt
> 
> New version (-10) has been submitted for draft-mrw-nat66-10.txt.
> http://www.ietf.org/internet-drafts/draft-mrw-nat66-10.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-10
> 
> IETF Secretariat.
Fred Baker | 2 Mar 06:04 2011
Picon

Fwd: New Version Notification - draft-mrw-nat66-09.txt

This responds to gen-art comments

Begin forwarded message:

> From: Internet-Draft@...
> Date: March 1, 2011 9:00:01 PM PST
> To: mrw@...,
fred@...,
draft-mrw-nat66@..., rbonica@...
> Subject: New Version Notification - draft-mrw-nat66-09.txt
> 
> New version (-09) has been submitted for draft-mrw-nat66-09.txt.
> http://www.ietf.org/internet-drafts/draft-mrw-nat66-09.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-09
> 
> IETF Secretariat.
Fred Baker | 28 Feb 23:39 2011
Picon

Fwd: New Version Notification - draft-mrw-nat66-08.txt


Begin forwarded message:

> From: Internet-Draft@...
> Date: February 28, 2011 2:30:03 PM PST
> To: mrw@...,
fred@...,
draft-mrw-nat66@..., rbonica@...
> Subject: New Version Notification - draft-mrw-nat66-08.txt
> 
> New version (-08) has been submitted for draft-mrw-nat66-08.txt.
> http://www.ietf.org/internet-drafts/draft-mrw-nat66-08.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-08
> 
> IETF Secretariat.
JFC Morfin | 3 Feb 18:43 2011

Re: -07 intends experimental status Re: New Version Notification for draft-mrw-nat66-06

At 12:27 03/02/2011, Margaret Wasserman wrote:
>operational use

Margaret,

I think this is exactly the right point of view (I would only add 
"optional" to show it is not alternative to anything but 
"subsiderative", a word we should work on to better understand the 
way the existing Internet supports divesities, as the linguistic 
diversity support has taught us). If the proposition fits an 
intelligent use (IUse) of the internet, the emerging small IUse 
community (for exemple, there may/should be others) will select it in 
its "How to Intelligently Use the Internet" part of the "How to 
sustainly develop in the digital ecosystem" documentation hopefully 
to come some day.

Best
jfc

Gmane