Actually Wes, it was absolutely bad for me making the poor assumption on
the choices aligned between the email and the slide.
You are correct the preferred option we hear as the 16 bit value.
On Wed, Nov 15, 2017 at 8:40 AM, Wes Hardaker wrote:
> Geoff Huston writes:
>
> >> I think the number
Geoff Huston writes:
>> I think the number 4 on the slide was different from the one in the mail.
>
>
> I thought so too, but I wasn’t sure if it was me not paying attention
> in the WG meeting or not!
Yes, you're both right. And absolutely my bad for writing the
presentation without looking at
> On 14 Nov 2017, at 12:48 pm, Joe Abley wrote:
>
> On Nov 14, 2017, at 09:37, George Michaelson wrote:
>
>> Stephane, I don't entirely understand your response. old systems can
>> never understand new code point assignments, or know what to do with
>> it, no proposed change can alter this. Mi
On Tue, Nov 14, 2017 at 09:48:28AM +0800,
Joe Abley wrote
a message of 24 lines which said:
> The implication is, I think, that some new code points are more
> likely to survive the attention of Sauron's Middleware than others.
...
> it seems intuitively true that the impact of each is probabl
On Nov 14, 2017, at 09:37, George Michaelson wrote:
> Stephane, I don't entirely understand your response. old systems can
> never understand new code point assignments, or know what to do with
> it, no proposed change can alter this. Middleboxes dropping unexpected
> things will hit almost any p
Stephane, I don't entirely understand your response. old systems can
never understand new code point assignments, or know what to do with
it, no proposed change can alter this. Middleboxes dropping unexpected
things will hit almost any proposed modification of packets in flight.
Basically, I don't
On Mon, Nov 13, 2017 at 08:54:16PM +0800,
Ray Bellis wrote
a message of 29 lines which said:
> Would it be feasible to reserve a standard RCODE value in the header
> that just means "see extended error"?
First reaction: no. Middleboxes would block these responses, or old
clients would not kno
> On 14 Nov 2017, at 8:19 am, Joe Abley wrote:
>
> Hi Geoff,
>
> I think the number 4 on the slide was different from the one in the mail.
I thought so too, but I wasn’t sure if it was me not paying attention in the WG
meeting or not!
>
> The option on the slide that I mentioned I liked th
Hi Geoff,
I think the number 4 on the slide was different from the one in the mail.
The option on the slide that I mentioned I liked the most was the one that
didn't copy the RCODE value from the header, but in effect provided a
16/32/whatever-bit sub-code for whatever the RCODE happened to be.
On 13/11/2017 21:13, Tony Finch wrote:
> Ray Bellis wrote:
>>
>> Would it be feasible to reserve a standard RCODE value in the
>> header that just means "see extended error"?
>
> That would require client-to-server signalling,
It would. Perhaps the *request* RCODE could contain the same valu
Ray Bellis wrote:
>
> Would it be feasible to reserve a standard RCODE value in the header
> that just means "see extended error"?
That would require client-to-server signalling, and the server would be
unable to simply unconditionally include the extended error in the OPT
record.
> It has alway
On 13/11/2017 19:01, Geoff Huston wrote:
> errr - what would it mean if the rcode in the error code header differed
> from the rcode value in the extended-error component?
>
> The issue with duplicated information in a packet is that you then have
> add even further consideration to cope with t
> On 13 Nov 2017, at 9:43 pm, tjw ietf wrote:
>
> To follow up from the meeting this morning, it sounded from the room that in
> the case of these
> four options, #4 was the one which makes the most sense.
>
>
…..
>
> 4. 32 bit code field, repeating rcode from elsewhere in the packet
To follow up from the meeting this morning, it sounded from the room that
in the case of these
four options, #4 was the one which makes the most sense.
tim
On Tue, Oct 17, 2017 at 6:39 AM, Wes Hardaker wrote:
>
> Folks,
>
> We were given feedback during the call for adoption to "use numeric
>
Folks,
We were given feedback during the call for adoption to "use numeric
range codes like those in HTTP". Following that, Warren and I sat down
and came up with some possibilities and would like your feedback about
which of these options you would prefer:
1. Individual codes assigned one at
15 matches
Mail list logo
