Re: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14

[Benjamin Kaduk <[e-mail]>]

On Wed, Mar 01, 2017 at 09:39:55PM -0800, Greg Mirsky wrote:
> Hi Ben,
> sincerely appreciate your thorough review and the most helpful comments.
> Please fine my answers in-line and tagged GIM>>.
> 
> Regards,
> Greg
> 
> On Wed, Mar 1, 2017 at 2:21 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> >
> > On page 16, second paragraph:
> >
> >    The ingress node MAY inspect the I bit flag received in each RTM_SET
> >    TLV contained in the LSP_ATTRIBUTES object of a received Resv
> >    message.  Presence of the RTM_SET TLV with I bit field set to 1
> >    indicates that some RTM nodes along the LSP could be included in the
> >    calculation of the residence time.  An ingress node MAY choose to
> >    resignal the LSP to include all RTM nodes or simply notify the user
> >    via a management interface.
> >
> > Is that supposed to be "included" or "excluded"?  My reading of the
> > previous paragraph was that the I bit would be set when a node
> > failed to compute the next RTM-capable node along the path, and of
> > course, we expect normal operation to include the residence time for
> > all RTM-capable nodes, so signalling potential inclusion is odd.
> >
> GIM>> I think that I've missed 'not' in that sentence. So it should be
> Presence of the RTM_SET TLV with I bit field set to 1
>    indicates that some RTM nodes along the LSP could *not *be included in
> the
>    calculation of the residence time.
> I've made the change in -15. Would you agree that it makes text logical?

Yes, that seems much more logical.

> >
> >
> > I'll close off this review by noting that sections 4.3 through 4.6
> > seem to all talk about how to use other protocols to indicate that
> > RTM may be used and could perhaps be grouped into an intermediate
> > subsection,
> 
> GIM>> Would sub-section with title be acceptable?
> RTM Capability Advertisement in Routing Protocols

Yes, that sounds good.

> 
> > wondering whether the "Type" and "Length" fields in
> > Figure 2 are the same octets of the packet as in Figure 1,
> 
> GIM>> Yes indeed. Figure 1 displays generic TLV while Figure 2 displays
> particular TLV, PTP.

Ah, good to have that confirmed.

> > and
> > repeating my as-yet unfulfilled intention to send further minor
> > editorial patches to the authors.

(I am about halfway through typing them up.)

-Ben