>> 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...

Yep; better.

> 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.

I don't think it's a question of taste.  If there's a long-term reason
to run nodes without encryption, then SHOULD might make sense.  But if
we do expect the stable state to always be encrypted, and avoiding it
is a short-term expedient that we want to have go away as soon as
possible, then the protocol should say MUST, and the exception is
clearly specified as a brief thing that mustn't last.  It's a
substantive difference, not one of writing style.

> 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.

Makes sense to me.  Carry on.

Barry

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to