Re: [Isis-wg] AD Review of draft-ietf-isis-prefix-attributes-09

[Alia Atlas <[e-mail]>]

Les,

Thanks for the prompt reply.  Responses in-line as always.

Regards,
Alia

On Thu, Dec 3, 2015 at 6:17 PM, Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> Alia -
>
>
>
> *From:* Alia Atlas [mailto:[e-mail]]
> *Sent:* Thursday, December 03, 2015 1:14 PM
> *To:* [e-mail]; [e-mail]
> *Subject:* AD Review of draft-ietf-isis-prefix-attributes-09
>
>
>
> Hi,
>
>
>
> As is customary, I have done my AD review of this draft before progressing
> it.
>
> First, let me thank you for a well-written draft and the work you have put
> into it.
>
>
>
> Next, I believe that a revised version is needed.
>
>
>
> 1)  This draft has 7 authors.  The limit is 5; you can pick an editor if
> you can't trim
>
> down to 5.  I can, of course, listen to a clear write-up of contributions
> made by each
>
> author of this 7 page draft, if you feel that an exception is truly
> warranted.   Until this
>
> issue is addressed, I will not progress this draft.
>
>
>
> *[Les:] I will revise with myself as editor.*
>

[Alia]  Thanks


>
>
> 2) The Security Considerations section is completely empty.  You know that
> this
>
> needs to be filled in - if only as a reference to the existing ISIS
> security and a bit
>
> on why sending additional information isn't a concern.
>
>
>
> *[Les:] Sigh…*
>
> *If we had not thought about Security issues we would have put TBD in the
> section. The statement “none” represents a thoughtful consideration of the
> security issues and a conclusion that there are “none”.*
>
> *I am willing to put a statement in that says that – but allow me to
> “sigh” because Security seems to be the only Section where even if you have
> nothing to say you are required to say something anyway. **J*
>

[Alia] Because they are reviewed by folks who aren't intimately familiar
with all the existing security aspects of every protocol
that the IETF does or has ever done.  It's useful to have a pointer saying
"this adds no additional security issues and ISIS has security handled by
...."
It may be the same boiler-plate that isis puts in every draft, but the
repeated pointer is still useful for those coming a bit new to the topic.

3)  As a minor kvetch (meaning that you don't have to agree), I'd prefer to
> see
>
> a bit of motivation or how this is expected to be used.  There's a very
> small amount
>
> of motivation from SR - but that doesn't really explain the need to send
> the originating
>
> Router ID.
>
>
>
> *[Les:] Your “kvetch” is about how this should/could be used in the
> future? *
>
> *I believe Section 1 clearly states the motivation for the bits which are
> currently defined – as well as router-id.*
>
> *It is hard to anticipate what additional bits might be defined in the
> future – though clearly they all need to be an attribute of a prefix.*
>

[Alia] From reading Section 1, I can see that the motivation is SR - but
don't actually have enough context (without crawling through reading the
associated SR drafts) to fully see the problem.  In particular, the example
given doesn't clarify for me the router-id need.  That said, if the real
answer is to go read the SR draft in detail, that's fair enough.



>  4) Clarifying question:  When a prefix has the external prefix flag set
> and the Router ID is sent, is that the Router ID of the router that is
> doing the redistribution or of the original advertising router (if it were
> available)?
>
>
>
> *[Les:] The routerid is always the ID of the originator of the IS-IS
> advertisement- not the router-id of the external protocol instance from
> which IS-IS might have learned the route.*
>
> *That said, I don’t see any need to advertise the router-id when the
> prefix is an eXternal prefix. It would not do any harm to do so – it just
> isn’t useful. We could add some text to that effect.*
>
>
I think that'd be useful - just your usual brief phrasing is fine :-)


>
>
> If you can address these issues quickly, then I can issue an IETF Last
> Call and we can have
>
> it on the agenda for the Jan 7, 2016 telechat.  That means that I can
> issue the IETF Last Call no later than Dec 17.
>
>
>
> *[Les:] We will try to get a new version out by early next week.*
>

Thanks!  Sorry to have taken so long on the review.

Alia


>    Les
>
>
>
> Thanks,
>
> Alia
>