Re: [Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

[Dale R. Worley]

"Les Ginsberg (ginsberg)"  writes:
> Attached please find an updated version and diffs from previous.
> Please let me know if this adequately addresses your comments.

It looks good to me.  (nit:  Section 4 ends with two successive
periods.)

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

[Les Ginsberg (ginsberg)]

Dale -

Attached please find an updated version and diffs from previous.
Please let me know if this adequately addresses your comments.

Les


> -Original Message-
> From: Dale R. Worley [mailto:wor...@ariadne.com]
> Sent: Monday, August 08, 2016 8:26 AM
> To: Les Ginsberg (ginsberg)
> Cc: gen-art@ietf.org; i...@ietf.org; draft-ietf-isis-rfc4971bis@ietf.org; 
> isis-
> w...@ietf.org
> Subject: Re: IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01
> 
> "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
> > Thanx for your detailed review. I have elected to copy the WG on my
> > reply as you also sent a copy of your review to the WG.
> 
> I'm not sure if it is formally specified, but it seems to me that a Gen-Art
> review really should be copied to the WG.
> 
> > It therefore has to be considered whether making many of the changes
> > you suggest might unintentionally suggest a substantive change where
> > none is intended.
> 
> Of course, my comments are only a review.  Looking over them again, none
> seem to technically critical; the ones with technical content are improving 
> the
> explanations of features that people (seem to be) implementing correctly
> now.  So I don't see any reason to object to minimizing changes from RFC
> 4971.
> 
> > [Les:] You refer here to the extended TLVs defined in RFC 7356 (pretty
> > good find for someone who is not supposed to be an IS-IS expert :-) ).
> 
> I looked at the type codepoint registry, and there were values over 255
> (though unassigned), which was inconsistent with the text of draft-ietf-isis-
> rfc4971bis.  So it was just a matter of tracking down what defined the
> alternative format.
> 
> Dale




Networking Working Group L. Ginsberg
Internet-DraftS. Previdi
Intended status: Standards Track   Cisco Systems
Expires: February 9, 2017M. Chen
Huawei Technologies Co., Ltd
  August 8, 2016


  IS-IS Extensions for Advertising Router Info
   draft-ietf-isis-rfc4971bis-02.txt

Abstract

   This document defines a new optional Intermediate System to
   Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
   sub-TLVs, which allows a router to announce its capabilities within
   an IS-IS level or the entire routing domain.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 9, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Ginsberg, et al.Expires February 9, 2017[Page 1]

Internet-Draft   isis-rfc4971bis August 2016


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IS-IS Router CAPABILITY TLV . . . . . . . . . . . . . . . . .   3
   3.  Elements of Procedure . . . . . . . . . . . . . . . . . . . .   4
   4.  Interoperability with Routers Not Supporting the Capability
   TLV . . . . . . . . . . . . . . . . . . . . . .

Re: [Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

[Dale R. Worley]

"Les Ginsberg (ginsberg)"  writes:
> Thanx for your detailed review. I have elected to copy the WG on my
> reply as you also sent a copy of your review to the WG.

I'm not sure if it is formally specified, but it seems to me that a
Gen-Art review really should be copied to the WG.

> It therefore has to be considered whether making many of the
> changes you suggest might unintentionally suggest a substantive change
> where none is intended.

Of course, my comments are only a review.  Looking over them again, none
seem to technically critical; the ones with technical content are
improving the explanations of features that people (seem to be)
implementing correctly now.  So I don't see any reason to object to
minimizing changes from RFC 4971.

> [Les:] You refer here to the extended TLVs defined in RFC 7356
> (pretty good find for someone who is not supposed to be an IS-IS
> expert :-) ).

I looked at the type codepoint registry, and there were values over 255
(though unassigned), which was inconsistent with the text of
draft-ietf-isis-rfc4971bis.  So it was just a matter of tracking down
what defined the alternative format.

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

[Les Ginsberg (ginsberg)]

Dale -

Thanx for your detailed review. I have elected to copy the WG on my reply as 
you also sent a copy of your review to the WG.

Overall, while I either agree with or have no objection to many of your 
comments, most of them could be applied to RFC 4971 itself. When generating the 
bis version we elected NOT to modify the original RFC except where it was 
necessary to address the issue of an IPv6-only router. It certainly can be 
argued that your suggestions improve the consistency and readability of the 
document, but they also make it deviate from RFC 4971 where no intent to define 
a functional change is intended. It therefore has to be considered whether 
making many of the changes you suggest might unintentionally suggest a 
substantive change where none is intended.

Be interested in your thoughts on this.

After we reach agreement on the above point I will spin a new version 
addressing your comments.

Specific responses inline.

> -Original Message-
> From: Dale R. Worley [mailto:wor...@ariadne.com]
> Sent: Thursday, August 04, 2016 1:00 PM
> To: gen-art@ietf.org; i...@ietf.org; draft-ietf-isis-rfc4971bis@ietf.org
> Subject: IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-isis-rfc4971bis-01
> Reviewer: Dale R. Worley
> Review Date: 4 August 2016
> IETF LC End Date: 15 August 2016
> IESG Telechat date: 18 August 2016
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that should be 
> fixed
> before publication.
> 
> * Editorial items
> 
> How is "capability TLV" to be capitalized?  I count the following occurrences 
> of
> the different capitalizations:
> 
> 24 CAPABILITY(IES) TLV(s)
>  5 Capability(ies) TLV(s)
>  4 capability(ies) TLV(s)
> 
> The practice in other RFCs seems to be "Capability TLV".
> 
> This also affects two occurrences of "TLV named CAPABILITY".

[Les:] As "CAPABILITY" was the dominant form in RFC 4971 I would be inclined to 
use that. Also this is the form used in 
http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

   " IS-IS Router CAPABILITY TLV"

But I agree consistency is desirable no matter what form we choose.

> 
> Abstract
> 
>This document defines a new optional Intermediate System to
>Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
>sub-TLVs, which allows a router to announce its capabilities within
>an IS-IS level or the entire routing domain.
> 
> I think s/formed of/containing/ -- the TLV also contains the Router ID and
> Flags fields.
> 

[Les:] This text is unchanged from RFC 4971.

> 2.  IS-IS Router CAPABILITY TLV
> 
>The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
>1 octet that specifies the number of bytes in the value field, and a
>variable length value field that starts with 4 octets of Router ID,
>indicating the source of the TLV, and followed by 1 octet of flags.
> 
> Should some note be put here that if Capability is used as an extended TLV,
> the type and length are increased to 2 bytes?  That is a general fact about
> TLVs, of course, but strictly, the above sentence isn't always correct.  (Or 
> is
> the "extended" version available only for TLVs at some higher level of the
> hierarchy?)
>

[Les:] You refer here to the extended TLVs defined in RFC 7356  (pretty good 
find for someone who is not supposed to be an IS-IS expert :-) ).
I am reluctant to require IS-IS RFCs in general to have to define both formats. 
That seems unnecessary. I am even more reluctant to do so in a bis version of 
an existing RFC.

 
> I think s/and followed by/followed by/.  The subject of "followed" is
> "4 octets of Router ID", leaving "and" to join "indicating the source of the
> TLV" with "followed by 1 octet of flags", which is not a parallel 
> construction.
> Instead, omit "and" to make the construction "... value field that starts 
> with 4
> octets ... followed by ..."
> 

[Les:] No objection - though again this is the original text from RFC 4971 
which the RFC editor seemed happy with at the time.

> 3.  Elements of Procedure
> 
>Router ID sub-TLV [RFC5316] MUST be present in the TLV.  Router
>CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the
>IPv6 TE Router ID sub-TLV present MUST be ignored.
> 
> Given that "ignored" is used later to describe processing of unknown sub-
> TLVs, which must not be interpreted but which may need to be leaked,
> perhaps "ignored" here should be amplified.  Perhaps "ignored, including not
> leaked".

[Les:] Later in the same section where the draft discusses