Re: [Isis-wg] Suresh Krishnan's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS)

["Les Ginsberg (ginsberg)" <[e-mail]>]

Suresh -

> -----Original Message-----
> From: Suresh Krishnan [mailto:[e-mail]]
> Sent: Tuesday, August 16, 2016 7:34 PM
> To: The IESG
> Cc: [e-mail]; Christian Hopps; [e-mail];
> [e-mail]; [e-mail]
> Subject: Suresh Krishnan's Discuss on draft-ietf-isis-rfc4971bis-03: (with
> DISCUSS)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-isis-rfc4971bis-03: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-isis-rfc4971bis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> * Section 4 requires the CAPABILITY TLV to be leaked without any change
> based on the text below
> 
> "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV
> MUST be leaked into another level without change even though it may
> contain some sub-TLVs which are unsupported by the Router doing the
> leaking. "
> 
> but Section 2 requires a router leaking the TLV from level-2 to level-1 to set
> the D bit and this violates the "without change" requirement.
> 
> I think this inconsistency needs to be resolved somehow.
> 
[Les:] I have trouble seeing this as an inconsistency.
The text in Section 2 defines the use of the D bit as a means to prevent looping of advertised information. Clearly the setting of the D bit has no impact on the meaning of any of the sub-TLVs in the encapsulating TLV so it is hard for me to see that this is in any way contradictory to the text in Section 4.

> P.S.: One possible way would be to add some exception text for the D bit
> into the above text in Section 4. Another would be to remove the restriction
> against change (I noticed that this restriction did not exist in RFC4971 - was
> this check added to fix some issue identified during deployment?).
> 
[Les:] The text in RFC 4971 is:

"If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
   TLV MUST be leaked into another level even though it may contain some
   of the unsupported sub-TLVs."

This was revised in the most recent BIS draft version based on GenArt review comments from Dale Worley to be:

"If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
   TLV MUST be leaked into another level without change even though it
   may contain some sub-TLVs which are unsupported by the Router doing
   the leaking."

We both felt that the revised wording was  more grammatically correct - but it certainly is not any different in intent from the original RFC 4971 text. So I do not see that we have made any substantive change here.

The prohibition against change of content when leaking is essential to correct operation - which is why a normative MUST is present. 

   Les
> 
>