> > 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 > > 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. Barry _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
