On Thu, Aug 05, 2010 at 03:15:40AM +0200, Seiichi Kawamura wrote:
> This is a very nice approach. So 4.2.1 would be like
>
> 4.2.1. Shorten as Much as Possible
>If at least two consecutive 16-bit 0 fields are present, the
>symbol "::" MUST be used, and used to its maximum capacity.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
snip
> This is a less invasive change (and I think the WG had previously some
> concensus on this, but the WG chairs will know). But yes, the formally
> correct procedure is likely the errata approach.
This was bothering me a bit and I went back to p
On 2010-08-05 14:34, Aleksi Suhonen wrote:
> Hi,
>
> Remi Despres a ecrit:
>>> If this this approach is retained, I could contribute on detailed
>>> changes to RFC 3679, with whoever is interested.
>
> Steven Blake wrote:
>> I agree with this in principle, but there are still a few issues:
>>
>>
Hi,
On 08/03/10 23:49, Shane Amante wrote:
OTOH, if you believe the flow-label belongs to hosts and you
potentially want to enable applications like
draft-blake-ipv6-flow-label-nonce-02, which could prevent off-path
attacks, then you (likely) can't have routers messing around with the
flow-labe
Hi,
Remi Despres a ecrit:
If this this approach is retained, I could contribute on detailed
changes to RFC 3679, with whoever is interested.
Steven Blake wrote:
I agree with this in principle, but there are still a few issues:
- If the sending host sets FL=0, and an intermediate router reset
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Juergen Schoenwaelder wrote:
> On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:
>
>> I think this is a mis-use of AUTH48; the working group has
>> considered the draft and said what it wanted to say, and at this
>> point the RFC Editor is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Its 9:00am in the morning in Tokyo
(my excuss for the late response)
and thanks to everyone for their comments.
I really have to appologise for the misuse of the AUTH48.
While most people would think that the original
text is good enough (at least tha
On 2010-08-05 09:15, Suresh Krishnan wrote:
> Hi Brian,
>
> On 10-08-04 03:21 PM, Brian Haberman wrote:
>> Suresh,
>>
>> On 8/4/10 2:46 PM, Suresh Krishnan wrote:
> ...
>>> Not really. The text you quoted does not state whether "::" MUST always
>>> be used if it is possible to do so. It only state
On Wed, Aug 04, 2010 at 08:44:46PM +0200, Fred Baker wrote:
>
> On Aug 4, 2010, at 5:56 PM, Juergen Schoenwaelder wrote:
>
> > On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:
> >
> >> I think this is a mis-use of AUTH48; the working group has
> >> considered the draft and said what i
Hi Brian,
On 10-08-04 03:21 PM, Brian Haberman wrote:
Suresh,
On 8/4/10 2:46 PM, Suresh Krishnan wrote:
...
Not really. The text you quoted does not state whether "::" MUST always
be used if it is possible to do so. It only states that when used, it
must be used to the maximum capability.
I
Suresh,
On 8/4/10 2:46 PM, Suresh Krishnan wrote:
> Hi Tom,
>
> On 10-08-04 01:30 PM, t.petch wrote:
>> e
>>
>> Tom Petch
>>
>> - Original Message -
>> From: "Suresh Krishnan"
>> To: "Brian Haberman"
>> Cc:
>> Sent: Wednesday, August 04, 2010 6:15 PM
>> Subject: Re: draft-ietf-
Hi Tom,
On 10-08-04 01:30 PM, t.petch wrote:
e
Tom Petch
- Original Message -
From: "Suresh Krishnan"
To: "Brian Haberman"
Cc:
Sent: Wednesday, August 04, 2010 6:15 PM
Subject: Re: draft-ietf-6man-text-addr-representation AUTH48 change
...
I am not certain whether this is
On Aug 4, 2010, at 5:56 PM, Juergen Schoenwaelder wrote:
> On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:
>
>> I think this is a mis-use of AUTH48; the working group has
>> considered the draft and said what it wanted to say, and at this
>> point the RFC Editor is asking you whether
e
Tom Petch
- Original Message -
From: "Suresh Krishnan"
To: "Brian Haberman"
Cc:
Sent: Wednesday, August 04, 2010 6:15 PM
Subject: Re: draft-ietf-6man-text-addr-representation AUTH48 change
> Hi Brian,
>
> On 10-08-04 11:58 AM, Brian Haberman wrote:
> > Seiichi,
> >
> >
On 8/4/10 12:15 PM, Suresh Krishnan wrote:
> Hi Brian,
>
> On 10-08-04 11:58 AM, Brian Haberman wrote:
>> Seiichi,
>>
>> First off, this type of change is not appropriate for AUTH48.
>
> I am not certain whether this is appropriate, but I think this issue
> should be fixed before publication
On Wed, 4 Aug 2010 12:23:05 +0200, Rémi Després
wrote:
> Hi Fred,
>
> Le 4 août 2010 à 10:13, Fred Baker a écrit :
>
>> intellectually, end to end signaling might make sense. If so, it
belongs
>> in the end-to-end headers.
> +1
>
>> More importantly, who's using it?
>>
>> If using it end to e
Seiichi,
These changes are out of scope for an AUTH48 change. AUTH48 is only to verify
the edits that the RFC-Editor performed and for other editorial changes.
If you really think these changes are very important, then the document would
need to come back to the working group and restart the p
Hi Brian,
On 10-08-04 11:58 AM, Brian Haberman wrote:
Seiichi,
First off, this type of change is not appropriate for AUTH48.
I am not certain whether this is appropriate, but I think this issue
should be fixed before publication. Otherwise the document fails to
achieve its stated goal.
Hi Chairs,
On 10-07-27 01:14 PM, Brian Haberman wrote:
All,
As noted in today's session of 6MAN, the chairs are soliciting
input on adopting:
Title : Things To Be Considered for RFC 3484 Revision
Author(s) : A. Matsumoto, et al.
Filename : draft-arifumi-6man-rfc3484-rev
Seiichi,
First off, this type of change is not appropriate for AUTH48.
On 8/4/10 7:26 AM, Seiichi Kawamura wrote:
> Hi
>
> This already came up on the list once before,
> and since its in AUTH48 now, I would like to
> make the changes to the document.
>
> Current section 4.2 has 3 parts, a
On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:
> I think this is a mis-use of AUTH48; the working group has
> considered the draft and said what it wanted to say, and at this
> point the RFC Editor is asking you whether they changed the intent
> of the draft in the editing process or
Seiichi Kawamura писал в своём письме Wed, 04 Aug
2010 15:26:09 +0400:
Current section 4.2 has 3 parts, and the first two are
4.2.1. Shorten as Much as Possible
The use of the symbol "::" MUST be used to its maximum capability.
For example, 2001:db8::0:1 is not acceptable, because th
Hi Tom,
The existing text does not make it clear whether "::" MUST
always be used if there are at least two consecutive 16-bit 0 fields.
This leads to ambiguity in address representations. Hence, I support the
modified text that Kawamura-san proposed.
Cheers
Suresh
On 10-08-04 10:04 AM, t.p
I think this is a mis-use of AUTH48; the working group has considered the draft
and said what it wanted to say, and at this point the RFC Editor is asking you
whether they changed the intent of the draft in the editing process or whether
perhaps your address has changed. Changing the draft in a
I object.
I think that the existing text is clearer than the text you want to replace it
with.
Tom Petch
- Original Message -
From: "Seiichi Kawamura"
To:
Sent: Wednesday, August 04, 2010 1:26 PM
Subject: draft-ietf-6man-text-addr-representation AUTH48 change
> -BEGIN PGP SIGNED
I think this is a good document, and that it is ready,
Stig
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
This already came up on the list once before,
and since its in AUTH48 now, I would like to
make the changes to the document.
Current section 4.2 has 3 parts, and the first two are
4.2.1. Shorten as Much as Possible
The use of the symbol "::"
Hi Fred,
Le 4 août 2010 à 10:13, Fred Baker a écrit :
> intellectually, end to end signaling might make sense. If so, it belongs in
> the end-to-end headers.
+1
> More importantly, who's using it?
>
> If using it end to end or end-to-network isn't being useful, either find a
> use, or depreca
intellectually, end to end signaling might make sense. If so, it belongs in the
end-to-end headers. More importantly, who's using it?
If using it end to end or end-to-network isn't being useful, either find a use,
or deprecate it.
On Aug 4, 2010, at 10:00 AM, Randy Bush wrote:
> The flow-l
The flow-label can belong either to the network -or- to the
host(s): pick one[1].
> ++
we have spent over a decade trying to find a home/use for flow-labels.
e2e signaling makes simple sense. let's try to declare victory and move
on.
randy
Le 4 août 2010 à 05:21, Brian E Carpenter a écrit :
> On 2010-08-04 00:49, Rémi Després wrote:
> ...
>> In my understanding, a reason why it is usually set to 0 is that a stateful
>> operation, which is complex, is so far mandatory (because a pseudo-random
>> number has to be assigned to each f
On Aug 4, 2010, at 5:48 AM, Brian E Carpenter wrote:
>>> The flow-label can belong either to the network -or- to the host(s): pick
>>> one[1].
++
Frankly, much of this discussion has been about dividing the flow label into
two parts, one for the host to use to instruct the network on what it
32 matches
Mail list logo
