Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-09 Thread Dhruv Dhody 
Ack.

https://github.com/dhruvdhody-huawei/ietf/commit/995e1a51964a8a6ac33d5e1e0cc1e40d41cd01ea

Thanks!
Dhruv

Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
master/draft-ietf-pce-pcep-exp-codepoints-05.txt
Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-
pcep-exp-codepoints-04=https://raw.githubusercontent.
com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-codepoints-05.txt




On Wed, Jan 10, 2018 at 12:15 AM, Eric Rescorla <e...@rtfm.com> wrote:

>
>
>
> On Tue, Jan 9, 2018 at 10:34 AM, Dhruv Dhody <dhruv.i...@gmail.com> wrote:
>
>> Hi EKR,
>>
>> Here is the text that has been added in the working copy -
>>
>> As stated in [RFC3692], experiments
>>>using these code points are not intended to be used in general
>>>deployments and due care taken while assigning the correct
>>>codepoints.
>>
>>
>
> This doesn't quite seem grammatical. Maybe
>
> "are not intended to be used in general deployments and due care must be
> taken
> to ensure that two experiments with the same code points are not run in
> the same environment".
>
> -Ekr
>
>
> "
>
>>   See [RFC3692] for further discussion of the use of
>>>experimental codepoints.
>>
>>
>> Also RFC3692 is made normative.
>>
>> Working Copy: https://raw.githubusercontent.
>> com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-
>> codepoints-05.txt
>> Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-exp-
>> codepoints-04=https://raw.githubusercontent.com/
>> dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-codepoints-05.txt
>>
>> Thanks!
>> Dhruv
>>
>> On Mon, Jan 8, 2018 at 7:15 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 8, 2018 at 5:38 AM, Adrian Farrel <adr...@olddog.co.uk>
>>> wrote:
>>>>
>>>> But so what? You are not supposed to expect anything other than a
>>>> crash! You are not supposed to run conflicting experiments and failure does
>>>> not need to be graceful.
>>>>
>>>
>>> But as I noted in my original review, your document does not say that.
>>> You might argue that RFC 3692 says that (though it's not clear to me that
>>> it precisely does), but as you don't cite it as a normative reference, you
>>> can't rely on that either. If you'd like to modify the document to state
>>> that (or point me to the text in your document which does so), I'll remove
>>> my DISCUSS.
>>>
>>> -Ekr
>>>
>>>
>>>>
>>>> There is nothing new here! Nothing new in this document. Nothing to
>>>> see, move along now.
>>>>
>>>>
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>> *From:* Eric Rescorla [mailto:e...@rtfm.com]
>>>> *Sent:* 08 January 2018 13:19
>>>> *To:* Adrian Farrel
>>>> *Cc:* The IESG; draft-ietf-pce-pcep-exp-codepoi...@ietf.org;
>>>> pce@ietf.org; pce-cha...@ietf.org
>>>> *Subject:* Re: [Pce] Eric Rescorla's Discuss on
>>>> draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi Adrian,
>>>>
>>>>
>>>>
>>>> Thanks for your thoughts.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jan 8, 2018 at 4:58 AM, Adrian Farrel <adr...@olddog.co.uk>
>>>> wrote:
>>>>
>>>> The purpose of this document is to adjust the registries to allow
>>>>
>>>> experimentation, not to redefine or refine the meaning of Experimental
>>>> codepoints.
>>>>
>>>> We do draw out the security concern that we think 3692 glossed over,
>>>> but this is
>>>> a reminder to protocol specs or implementers that they must watch out.
>>>> This is
>>>> not a protocol spec and doesn't need to describe how implementations
>>>> handle
>>>> conflicts.
>>>>
>>>>
>>>>
>>>> No, but it does need to describe the impact of what happens when there
>>>> is confusion, which it presently does not. This is not solely a security
>>>> concern but also an interoperability and correctness concern.
>>>>
>>>>
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>> Ciao,
>>>> Adrian
>>>>
>>>>
>>>>
>>>
>>>
>>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-09 Thread Eric Rescorla 
On Tue, Jan 9, 2018 at 10:34 AM, Dhruv Dhody <dhruv.i...@gmail.com> wrote:

> Hi EKR,
>
> Here is the text that has been added in the working copy -
>
> As stated in [RFC3692], experiments
>>using these code points are not intended to be used in general
>>deployments and due care taken while assigning the correct
>>codepoints.
>
>

This doesn't quite seem grammatical. Maybe

"are not intended to be used in general deployments and due care must be
taken
to ensure that two experiments with the same code points are not run in
the same environment".

-Ekr


"

>   See [RFC3692] for further discussion of the use of
>>experimental codepoints.
>
>
> Also RFC3692 is made normative.
>
> Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
> master/draft-ietf-pce-pcep-exp-codepoints-05.txt
> Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-
> pcep-exp-codepoints-04=https://raw.githubusercontent.
> com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-
> exp-codepoints-05.txt
>
> Thanks!
> Dhruv
>
> On Mon, Jan 8, 2018 at 7:15 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 5:38 AM, Adrian Farrel <adr...@olddog.co.uk>
>> wrote:
>>>
>>> But so what? You are not supposed to expect anything other than a crash!
>>> You are not supposed to run conflicting experiments and failure does not
>>> need to be graceful.
>>>
>>
>> But as I noted in my original review, your document does not say that.
>> You might argue that RFC 3692 says that (though it's not clear to me that
>> it precisely does), but as you don't cite it as a normative reference, you
>> can't rely on that either. If you'd like to modify the document to state
>> that (or point me to the text in your document which does so), I'll remove
>> my DISCUSS.
>>
>> -Ekr
>>
>>
>>>
>>> There is nothing new here! Nothing new in this document. Nothing to see,
>>> move along now.
>>>
>>>
>>>
>>> Adrian
>>>
>>>
>>>
>>> *From:* Eric Rescorla [mailto:e...@rtfm.com]
>>> *Sent:* 08 January 2018 13:19
>>> *To:* Adrian Farrel
>>> *Cc:* The IESG; draft-ietf-pce-pcep-exp-codepoi...@ietf.org;
>>> pce@ietf.org; pce-cha...@ietf.org
>>> *Subject:* Re: [Pce] Eric Rescorla's Discuss on
>>> draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)
>>>
>>>
>>>
>>>
>>>
>>> Hi Adrian,
>>>
>>>
>>>
>>> Thanks for your thoughts.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jan 8, 2018 at 4:58 AM, Adrian Farrel <adr...@olddog.co.uk>
>>> wrote:
>>>
>>> The purpose of this document is to adjust the registries to allow
>>>
>>> experimentation, not to redefine or refine the meaning of Experimental
>>> codepoints.
>>>
>>> We do draw out the security concern that we think 3692 glossed over, but
>>> this is
>>> a reminder to protocol specs or implementers that they must watch out.
>>> This is
>>> not a protocol spec and doesn't need to describe how implementations
>>> handle
>>> conflicts.
>>>
>>>
>>>
>>> No, but it does need to describe the impact of what happens when there
>>> is confusion, which it presently does not. This is not solely a security
>>> concern but also an interoperability and correctness concern.
>>>
>>>
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>> Ciao,
>>> Adrian
>>>
>>>
>>>
>>
>>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-09 Thread Dhruv Dhody 
Hi EKR,

Here is the text that has been added in the working copy -

As stated in [RFC3692], experiments
>using these code points are not intended to be used in general
>deployments and due care taken while assigning the correct
>codepoints.  See [RFC3692] for further discussion of the use of
>experimental codepoints.


Also RFC3692 is made normative.

Working Copy:
https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-codepoints-05.txt
Diff:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-exp-codepoints-04=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-codepoints-05.txt

Thanks!
Dhruv

On Mon, Jan 8, 2018 at 7:15 PM, Eric Rescorla <e...@rtfm.com> wrote:

>
>
> On Mon, Jan 8, 2018 at 5:38 AM, Adrian Farrel <adr...@olddog.co.uk> wrote:
>
>>
>> But so what? You are not supposed to expect anything other than a crash!
>> You are not supposed to run conflicting experiments and failure does not
>> need to be graceful.
>>
>
> But as I noted in my original review, your document does not say that. You
> might argue that RFC 3692 says that (though it's not clear to me that it
> precisely does), but as you don't cite it as a normative reference, you
> can't rely on that either. If you'd like to modify the document to state
> that (or point me to the text in your document which does so), I'll remove
> my DISCUSS.
>
> -Ekr
>
>
>>
>> There is nothing new here! Nothing new in this document. Nothing to see,
>> move along now.
>>
>>
>>
>> Adrian
>>
>>
>>
>> *From:* Eric Rescorla [mailto:e...@rtfm.com]
>> *Sent:* 08 January 2018 13:19
>> *To:* Adrian Farrel
>> *Cc:* The IESG; draft-ietf-pce-pcep-exp-codepoi...@ietf.org; pce@ietf.org;
>> pce-cha...@ietf.org
>> *Subject:* Re: [Pce] Eric Rescorla's Discuss on
>> draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)
>>
>>
>>
>>
>>
>> Hi Adrian,
>>
>>
>>
>> Thanks for your thoughts.
>>
>>
>>
>>
>>
>> On Mon, Jan 8, 2018 at 4:58 AM, Adrian Farrel <adr...@olddog.co.uk>
>> wrote:
>>
>> The purpose of this document is to adjust the registries to allow
>>
>> experimentation, not to redefine or refine the meaning of Experimental
>> codepoints.
>>
>> We do draw out the security concern that we think 3692 glossed over, but
>> this is
>> a reminder to protocol specs or implementers that they must watch out.
>> This is
>> not a protocol spec and doesn't need to describe how implementations
>> handle
>> conflicts.
>>
>>
>>
>> No, but it does need to describe the impact of what happens when there is
>> confusion, which it presently does not. This is not solely a security
>> concern but also an interoperability and correctness concern.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>> Ciao,
>> Adrian
>>
>>
>>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-08 Thread Eric Rescorla 
On Mon, Jan 8, 2018 at 5:38 AM, Adrian Farrel <adr...@olddog.co.uk> wrote:
>
> But so what? You are not supposed to expect anything other than a crash!
> You are not supposed to run conflicting experiments and failure does not
> need to be graceful.
>

But as I noted in my original review, your document does not say that. You
might argue that RFC 3692 says that (though it's not clear to me that it
precisely does), but as you don't cite it as a normative reference, you
can't rely on that either. If you'd like to modify the document to state
that (or point me to the text in your document which does so), I'll remove
my DISCUSS.

-Ekr


>
> There is nothing new here! Nothing new in this document. Nothing to see,
> move along now.
>
>
>
> Adrian
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
> *Sent:* 08 January 2018 13:19
> *To:* Adrian Farrel
> *Cc:* The IESG; draft-ietf-pce-pcep-exp-codepoi...@ietf.org; pce@ietf.org;
> pce-cha...@ietf.org
> *Subject:* Re: [Pce] Eric Rescorla's Discuss on
> draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)
>
>
>
>
>
> Hi Adrian,
>
>
>
> Thanks for your thoughts.
>
>
>
>
>
> On Mon, Jan 8, 2018 at 4:58 AM, Adrian Farrel <adr...@olddog.co.uk> wrote:
>
> The purpose of this document is to adjust the registries to allow
>
> experimentation, not to redefine or refine the meaning of Experimental
> codepoints.
>
> We do draw out the security concern that we think 3692 glossed over, but
> this is
> a reminder to protocol specs or implementers that they must watch out.
> This is
> not a protocol spec and doesn't need to describe how implementations handle
> conflicts.
>
>
>
> No, but it does need to describe the impact of what happens when there is
> confusion, which it presently does not. This is not solely a security
> concern but also an interoperability and correctness concern.
>
>
>
> -Ekr
>
>
>
>
> Ciao,
> Adrian
>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-08 Thread Adrian Farrel 
Hmmm, how about a bis for 3692?
 
Seriously, you think every document that defines an Experimental protocol range 
must describe the processing that an implementation must do if someone is 
ill-advised enough to run two experiments with overlapping experiments in the 
same network?
 
Presumably, at some level the PDUs will be considered malformed and an alert 
raised. Possibly (although it seems highly unlikely) the PDUs will be 
interpreted as valid and cause entertaining results.
 
But so what? You are not supposed to expect anything other than a crash! You 
are not supposed to run conflicting experiments and failure does not need to be 
graceful.
 
There is nothing new here! Nothing new in this document. Nothing to see, move 
along now.
 
Adrian
 
From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: 08 January 2018 13:19
To: Adrian Farrel
Cc: The IESG; draft-ietf-pce-pcep-exp-codepoi...@ietf.org; pce@ietf.org; 
pce-cha...@ietf.org
Subject: Re: [Pce] Eric Rescorla's Discuss on 
draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)
 
 
Hi Adrian,
 
Thanks for your thoughts.
 
 
On Mon, Jan 8, 2018 at 4:58 AM, Adrian Farrel <adr...@olddog.co.uk> wrote:
The purpose of this document is to adjust the registries to allow
experimentation, not to redefine or refine the meaning of Experimental
codepoints.

We do draw out the security concern that we think 3692 glossed over, but this is
a reminder to protocol specs or implementers that they must watch out. This is
not a protocol spec and doesn't need to describe how implementations handle
conflicts.
 
No, but it does need to describe the impact of what happens when there is 
confusion, which it presently does not. This is not solely a security concern 
but also an interoperability and correctness concern.
 
-Ekr
 

Ciao,
Adrian
 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-08 Thread Eric Rescorla 
Hi Adrian,

Thanks for your thoughts.


On Mon, Jan 8, 2018 at 4:58 AM, Adrian Farrel  wrote:

> The purpose of this document is to adjust the registries to allow
>
experimentation, not to redefine or refine the meaning of Experimental
> codepoints.
>
> We do draw out the security concern that we think 3692 glossed over, but
> this is
> a reminder to protocol specs or implementers that they must watch out.
> This is
> not a protocol spec and doesn't need to describe how implementations handle
> conflicts.
>

No, but it does need to describe the impact of what happens when there is
confusion, which it presently does not. This is not solely a security
concern but also an interoperability and correctness concern.

-Ekr


>
> Ciao,
> Adrian
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pcep-exp-codepoints-04: (with DISCUSS)

2018-01-08 Thread Adrian Farrel 
Hi Eric,

> What happens when two deployments independently select the same
> experiment code point with different semantics? Is there some way to
> detect that, or do they just get confused? This seems like it it's fine in a
> closed environment, but unless I'm missing something, there's nothing
> in this text that actually requires that.

You might spend some time reading about experimental codepoints and the
experiments they are used for in BCP 82 (specifically RFC 3692).

There it says...

   Numbers in the experimentation range are similar to those called
   "Private Use" in RFC 2434 [IANA-CONSIDERATIONS].  They are not
   intended to be used in general deployments or be enabled by default
   in products or other general releases.  In those cases where a
   product or release makes use of an experimental number, the end user
   must be required to explicitly enable the experimental feature and
   likewise have the ability to chose [sic] and assign which number from the
   experimental range will be used for a specific purpose (i.e., so the
   end user can ensure that use of a particular number doesn't conflict
   with other on-going uses).  Shipping a product with a specific value
   pre-enabled would be inappropriate and can lead to interoperability
   problems when the chosen value collides with a different usage, as it
   someday surely will.

...and further...

   By definition, experimental numbers are not guaranteed to be
   unique in any environment other than one where the local system
   administrator has chosen to use a particular number for a particular
   purpose and can ensure that a particular value is not already in use
   for some other purpose.

This document makes clear reference to 3692 from the introduction suggesting
that readers look there for an explanation of Experimental codepoints.

The purpose of this document is to adjust the registries to allow
experimentation, not to redefine or refine the meaning of Experimental
codepoints.

We do draw out the security concern that we think 3692 glossed over, but this is
a reminder to protocol specs or implementers that they must watch out. This is
not a protocol spec and doesn't need to describe how implementations handle
conflicts.

Ciao,
Adrian 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce