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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 17 Aug 2016 07:23:25 -0700

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?

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.

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.

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.

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.“

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".

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Aug 2016 15:55:37 +0000

Mirja -

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Mirja
> Kuehlewind
> Sent: Wednesday, August 17, 2016 7:23 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-isis-
> [email-masked]
> Subject: [Isis-wg] Mirja Kühlewind's No Objection on draft-ietf-isis-
> rfc4971bis-03: (with COMMENT)
> 
> 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.)
> 
> 
> 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
>   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.

>    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
[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

>   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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg