Re: [Isis-wg] Mirja Kühlewind's No Objection on draft-ietf-isis-rfc4971bis-03: (with COMMENT)

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

Mirja -

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Mirja
> Kuehlewind
> Sent: Wednesday, August 17, 2016 7:23 AM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-isis-
> [e-mail]
> Subject: [Isis-wg] Mirja Kühlewind's No Objection on draft-ietf-isis-
> rfc4971bis-03: (with COMMENT)
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-isis-rfc4971bis-03: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I know this is a bis doc that mainly clarifies one point. However, as there were
> also other smaller updates, here are some additional comments that could
> be considered:
> 
> 1) To me the text in section 2 reads like: if S is not set D should be ignored. Is
> this correct? If so, it could be spelled out like this. If not, what happens if S is
> not set but D is?
>
[Les:] The text is very clear about what the S bit means and what the D bit means. It says:

" S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV
   MUST be flooded across the entire routing domain.  If the S bit is
   not set(0), the TLV MUST NOT be leaked between levels.  This bit MUST
   NOT be altered during the TLV leaking."

Since leaking is forbidden unless S bit is set, there is never a reason to set the D bit if S bit is clear. An implementation which did this would be in violation of the specification. However, if such a violation did occur, ignoring the D bit would only have the potential to make things worse as it would mean an implementation might choose to leak the content back into Level 2 (even though it MUST NOT do that). So your suggestion to change the text isn’t helpful.
 
> 2) The text says: „Where a receiving system has two copies of a CAPABILITY
> TLV from the
>    same system that have different settings for a given attribute, the
>    procedure used to choose which copy shall be used is undefined.“
>   Why is there no default given here? Not defining something like this can
> lead to problems. I would strongly recommend to define a default behavior.
> 
[Les:] There is no way to define a meaningful behavior. The semantics of each sub-TLV are different - and outside the scope of this specification. So saying "take the higher value" (for example) isn’t meaningful.
It is also not possible to know which value was the first to be advertised as the order in which LSP updates are received is not guaranteed by the protocol.

> 3) Further it says: „How partial support may impact the operation of the
>    capabilities advertised within the Router CAPABILITY TLV is outside
>    the scope of this document.“
>    While it might be true that this is specific to the capability, I would put a
> MUST requirement in here for future specifiactions: Partial suport MUST be
> defined in the document that describes the subTLV.
> 
[Les:] The statement which is made (which the BIS version does not alter) is appropriate given that this document does not define any of the sub-TLVs. Further, as multiple sub-TLVs have been defined by other documents in the years since RFC 4971 was published, introducing a change here which REQUIRES these documents to make statements about partial support runs the risk of making existing RFCs non-compliant. This isn't something we should do here.

While your concern has merit, the way to address this - if it is to be addressed at all - would be to review the documents which define sub-TLVs and file errata against them if you feel it is warranted.

All of this is out of scope for this document however.

> 4) On this sentence: „Routers that do not support the Router CAPABILITY TLV
> MUST silently
>    ignore the TLV(s) and continue processing other TLVs in the same LSP.“
>    What does "silently" mean here? Is it not allowed to log such an event? I
> would recommend to either clarify that "silently" means here or remove that
> word.
>
[Les:] "Silently" refers to the base protocol behavior [ISO 10589] of ignoring TLVs which are not understood but flooding them unaltered. 
Systems could log occurrences of TLVs they don’t understand, but doing so IMO would simply clutter system logs with useless information. The fact that the protocol can be extended w/o requiring a forklift upgrade is a strength and has served us well.

 
> 5) In this sentence: "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.“
>   I would recomend to use the normative language differently to be clear
> about what it applies to:
> "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
>    TLV MUST NOT change sub-TLVs which are unsupported by the Router
> doing
>    the leaking.“
> 
[Les:] Please review the latest update to the draft. This text was rewritten based on comments during GenART review.

https://www.ietf.org/id/draft-ietf-isis-rfc4971bis-03.txt

> 6) In section 5: „Note that an integrity mechanism, such as the one
>    defined in [RFC5304] or [RFC5310], should be applied if there is high
>    risk resulting from modification of capability information.“
>   Why is that a SHOULD and what's a „high risk“?  It should me either "MUST
> be applied at high risk" and defining what a high risk is, or it should be
> "SHOULD be applied at (any) risk".
> 
[Les:] The risks associated with Capability advertisements depend upon the nature of the information in the sub-TLVs - so the document quite correctly defers this to the specifications that define the sub-TLVs:

" Specifications based on this mechanism need to describe the security
   considerations around the disclosure and modification of their
   information."

I think this is both sufficient and appropriate.

   Les

> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg