On 10/03/2017 05:53, Barry Leiba wrote:
>> > Personal opinion: encryption should be a MUST.
>>
>> I believe that we will have situations where we have a secured ACP into a NOC
>> (to an edge router or VM hypervisor), and then we will have some unencrypted,
>> but secured links to platforms in transition.
>>
>> It will be easy to add the GRASP daemon to answer resource requests to the
>> platform, but hard to add the ACP to that platform without a forklift
>> upgrade.
>>
>> This is why I think it is a SHOULD, as much as I want it to transition to
>> being a MUST.
>
> This brings up a common rant that I have:
> We should be putting into our protocol specs what we want the protocol
> to be, not some compromise that comes from knowing that not everyone
> will comply with everything from the start.
>
> If the right thing is to say "MUST encrypt", but we know there'll be a
> transition period during which that's not fully practical, then we
> should say that. Something like this added to Section 3.5.1:
>
> NEW
> In some cases there will be a transition period, in which it might not
> be practical to run with strong encryption right away. It's important
> to keep this period as short as possible, and to upgrade to a fully
> encrypted setup as soon as possible.
> END
or perhaps more precisely:
During initialization of nodes there will be a transition period...
Whether this is phrased as an exception to the MUST or as the justification
for ignoring the SHOULD is a matter of taste, I think.
>
>> > Once we specify byte-by-byte comparison, do we need to worry about this
>> > in a protocol document? If someone is silly enough to specify an
>>
>> It matters, when humans have to confirm things. I think that objectives
>> will be mostly baked into code. So, I agree with you, but I would rather
>> exclude all that UTF stuff too.
>
> That's true: if these really are protocol elements and there's no need
> to have them Internationalized for human consumption, perhaps limiting
> them to US-ASCII makes sense and avoids issues with odd character
> effects (code that breaks if certain characters appear in strings, or
> humans debugging things and being confused by characters that look the
> same but are encoded differently). On the other hand, if it really
> would be handy to be able to define objective names in Chinese, Hindi,
> or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the
> possibilities are understood and folks are OK with it.
My thought was that these names will sometimes be visible to humans so why
not allow localized names? If GRASP succeeds it might be used for local
applications, not just generic applications. So I'd rather allow it
from the start, and if we have to add character-set restrictions later,
so be it.
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
