> Okay with me, too. I just tried to make the document clear in the 03
> draft, but in fact I don't see practical usage of receiving the
> optional information on TCP sockets. If we can reach a consensus of
> leaving it unspecified (by removing the text), it's just fine.
At one level I don't h
> On Tue, 18 Dec 2001 10:06:11 +0900 (JST),
> Atsushi Onoe <[EMAIL PROTECTED]> said:
>> If not then both mechanisms should
>> be excised from the document.
> Actually, it is acceptable for me.
Okay with me, too. I just tried to make the document clear in the 03
draft, but in fact I do
> If not then both mechanisms should
> be excised from the document.
Actually, it is acceptable for me.
> We have wasted enough time on a facility of
> dubious value.
Agreed.
Atsushi Onoe
IETF IPng Working Group Mailing List
>
> > Simplest is in the eye of the beholder. We have implemented the -02
> > behavior and the -03 behavior in the past. I would not agree that the -03
> > behavior is simpler is any respect.
>
> So we all have implemented the -03 behavior. Why changes are needed?
> The -03 behavior, which
> Simplest is in the eye of the beholder. We have implemented the -02
> behavior and the -03 behavior in the past. I would not agree that the -03
> behavior is simpler is any respect.
So we all have implemented the -03 behavior. Why changes are needed?
The -03 behavior, which is almost same as
>> the major problem I'm seeing for -02 definition is that there's no
>> relationship defined (impossible) between the normal TCP data stream
>> and ancillary data segments. I personally in favor of -03 definition.
>So? I didn't realize that having such a relationship had become a
Itojun,
>
> >> So I prefer simplest definition to implement such feature if it is
> >> included in the specification. That's why I think current specification
> >> (-03 draft) is better.
> >Simplest is in the eye of the beholder. We have implemented the -02
> >behavior and the -03 behavio
I've had some problems getting the ND right, especially the IS ROUTER
bit handling in some cases. The RFC has some long winded convoluted
english statements with and's and or's, that I have hard time
parsing. The state table in the appendix is also somewhat hard to
read, and does not cover all co
>> So I prefer simplest definition to implement such feature if it is
>> included in the specification. That's why I think current specification
>> (-03 draft) is better.
>Simplest is in the eye of the beholder. We have implemented the -02
>behavior and the -03 behavior in the past. I would not
Vlad,
>
> Since you are soliciting comments from implementors, here are my
> opionions about the change ( I was going to wait until I got to work).
>
> I beleave the the 2292bis-02 definition and TCP implications were
> fine. I was curious about the reasons this was put in the draft.
>
I a
>
> > As I said in the today's meeting, please speak up about your opinions,
> > if you're interested in implementing the API. I'd like to collect the
> > opinions, and will soon revise the draft based on consensus.
>
> I think the current (-03, and RFC 2292) definition is fine. For 2292
>
On Tue, 11 Dec 2001, Bob Hinden wrote:
> This is a IPv6 working group last call for comments on advancing the
> following document as an Informational RFC:
>
> Title : Basic Socket Interface Extensions for IPv6
> Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Steven
At the plenary last week, Christian asked about getting IANA to assign
an IPv6 multicast address. Poking around a bit, I can't find the
process under which IANA assigns IPv6 multicast addresses documented.
RFC 2780 says:
> 5.4.3 IPv6 Multicast Addresses
>
>IPv6 multicast addresses are defin
Tangent:
Does "readable when encrypted" extend to "modifiable when authenticated" or
are some policies required about what "recommended" uses are for the field?
This may be covered nicely by the phrase in a previous message that "...the
IPv6 flow label is *not* a routing label.".
Craig.
-
Mike,
You forgot a third:
3) Readable when the packet is encrypted
Thus, QoS can be accomplished even if the
rest of the packet is encrypted.
jak
- Original Message -
From: "Michael Thomas" <[EMAIL PROTECTED]>
To: "Margaret Wasserman" <[EMAIL PROTECTED]>
Cc: "Brian E Carpe
Margaret Wasserman writes:
> If I seem to be missing an important point or concept, please send
> some hints or pointers.
Margaret,
I don't think you're alone wondering what all the
fuss is about with the flow label since it's
fairly obvious that normal Intserv classifiers
function equivalentl
Margaret Wasserman wrote:
>
> Thanks for the response, Brian.
>
> > > Are there reasons for preferring to put a flow label inside the
> > > IPv6 header? Is this being done on the advice of folks who are
> > > standardizing label switching technologies?
> > >
> >No, because it has nothing to do
[Please apologize cross-posting]
Hi,
At the end of the bar bof on Mobile Networks at Salt Lake it was
suggested to re-send the information on how to join the monet mailing
list.
In order to join, please send mail to [EMAIL PROTECTED] with
subscribe in the body.
An archive fi
Thanks for the response, Brian.
> > Are there reasons for preferring to put a flow label inside the
> > IPv6 header? Is this being done on the advice of folks who are
> > standardizing label switching technologies?
> >
>No, because it has nothing to do with label switching. It's much
>more to
Hi, folks,
I am newbie to this list. I apologize if my question causes problem to
this list.
First of all, I understand that IETF has it's own way and pace, so, my
idea is just an idea (mean nothing):
I recently come up with an idea about extending ICMPv6. I wonder if it
is possible to add some
Margaret Wasserman wrote:
>
> I have a few comments/questions on the general flow label topic.
> They are not specific to draft-rajahalame-ipv6-flow-label-00.txt,
> but they do apply to this proposal, as well as others.
>
> I've hesitated to raise this issue for fear of being publicly
> stoned,
21 matches
Mail list logo
