Re: [Rift] AD Review of draft-ietf-rift-rift-12 (Part 2a)

[Tony Przygienda <[e-mail]>]

Alvaro, inline


> ...
> > > MD5 won't pass the Security scrutiny. I just did a quick scan and
> > > found the Security Envelope, but no details on what is MTI in terms of
> > > algorithms, etc.
> >
> > OK, I will cut out any reference to any specific algorithm. I just
> mention
> > that the key id is basically also indicating the authentication schema
> used.
>
> I actually meant it the other way around: there should be
> mandatory-to-implement security.  The "limited domain" arguments don't
> always work.  We can of course try...
>

well, two observations why I think this is futile

a) RIFT's big appeal is ZTP. ZTP (full, true ZTP) does not work with
security (unless you pre-configure a key e'where or something but that's
already not ZTP). We have a _very_ extensive section explaining the
security models and implications and trade-offs.

b) whatever we standardize as "must have" algorithm will be laughably weak
in 20 years.

No limited domain argument here, argument is rather "By default, it's ZTP
and that means no security, the more security you want the more you
configure, RIFT supports e'thing up to port security model and the key ID
will give you newest flavor of algorithm"

otherwise pls suggest the "specific" algorithm we have to refer to and
standardize you think makes sense.


>
>
>
>
> ...
> > Is there some kind of precedence case where a base protocol spec
> > has been held by its applicability draft? Sounds extremely new to me.
>
> All kinds!  If it is not clear what the tradeoffs of the options are
> -- that is the reason I keep pointing at rfc5706.
>
> Again, let's settle the "What is being standardized in the base spec?"
> discussion first.  I want to make sure that we're all on the same page
> and that we agree on exactly what is needed.   This includes making
> sure the rest of the IESG are in the loop and don't ask for things
> later.
>

ack, agreed.


>
> As I said at the top, my comments are made with one set of
> expectations -- you're answering with a different set.  I know we had
> talked (including the Chairs): we all heard the same words, but we
> interpreted them differently.
>

okey, point taken.

I am all for operational & management considerations/documewntaitons of a
protocol but for me, that has nothing to do with base spec.

And as I said, full spec open source implementatyion is there, interop
done, day one book, yang model in flight, applicability in flight. That
seems to me a pretty good plate for IETF standards as to protocol work.
Each of those things have to progress but why any of them should gate the
other (well, man and app is probably waiting for rift rfc to quote) is not
easily comprehensible to me (unless I misunderstood again).


>
>
>
> ...
> > > > > 1454 2. the neighboring node is running the same MAJOR schema
> version
> > > > > AND
> > > ...
> > > > > [minor] Are there any requirements related to the minor version?
> > > >
> > > > the schema versioning does describe that in excruciating details @
> > > > beginning of appendix B. I'll fwd reference
> > >
> > > Sorry, I meant: for this step, does the minor version matter? Or is
> > > it ok if just the major version is the same?
>


> >
> > I quote the spec:
> >
> > "
> > 2. the neighboring node is running the same MAJOR schema version AND
> >
> > "
> > The spec does explicitly NOT say anything about minor and this is
> intended
> > exactly like this.
>
> Great!  I wouldn't be doing my job if I didn't ask. ;-)
>

understood. yes, the Art of Carving Away. I know that sometimes it leaves
the reader taking assumptions they should not and leaves questions open. I
still prefer it to overspecify or repeat excessively. Mostly because
repetitions are hard to maintain and start to contradict each other
quickly.

-- tony