[i2rs] WG LC on draft-ietf-i2rs-yang-l2-network-topology-11.txt - use of IEEE 802.1Qcp-2018 in document -AD and WGChair/shepherd feedback - Comment period until 9/20/2019

"Susan Hares" <shares@ndzh.com> Fri, 13 September 2019 16:55 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C131200D5 for <i2rs@ietfa.amsl.com>; Fri, 13 Sep 2019 09:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.348
X-Spam-Level: *
X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7JfnBZmwX0H for <i2rs@ietfa.amsl.com>; Fri, 13 Sep 2019 09:55:21 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B2F12008F for <i2rs@ietf.org>; Fri, 13 Sep 2019 09:55:21 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=97.112.17.31;
From: Susan Hares <shares@ndzh.com>
To: i2rs@ietf.org
Cc: 'tom petch' <ietfc@btconnect.com>, "'Vigoureux, Martin (Nokia - FR/Paris-Saclay)'" <martin.vigoureux@nokia.com>, 'Warren Kumari' <warren@kumari.net>, 'Suresh Krishnan' <suresh@kaloom.com>
Date: Fri, 13 Sep 2019 12:55:07 -0400
Message-ID: <007d01d56a53$ffe33d90$ffa9b8b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01D56A32.78D3E780"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdVqUvbZvsAni1ANRhqp0UTRPvHwbA==
Content-Language: en-us
X-Antivirus: AVG (VPS 190913-2, 09/13/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/KKCx7Zr-voPwSAFscWMrBRP9E_Y>
Subject: [i2rs] WG LC on draft-ietf-i2rs-yang-l2-network-topology-11.txt - use of IEEE 802.1Qcp-2018 in document -AD and WGChair/shepherd feedback - Comment period until 9/20/2019
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 16:55:24 -0000

Tom and Qin: 

 

I've received input from the Routing AD (Martin Vigoureux),

NM/OPS ADS, and Suresh Krishnan (IEEE liaison) 

on Tom's question regard the use of  IEEE References as 

informative references in 

 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/>
draft-ietf-i2rs-yang-l2-network-topology-11.txt 

 

and as imported references in: 

 

     import ieee802-dot1q-types {

      prefix dot1q-type;

      reference

        "IEEE Std 802.1Qcp-2018: Bridges and Bridged

         Networks - Amendment: YANG Data Model.";

     }

 

The question is whether this import is a normative reference even though 

It is listed as informative. 

 

The yang doctors can determine whether IEEE 802.1Qcp-2018 

Should or should not be a normative references for

 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/>
draft-ietf-i2rs-yang-l2-network-topology-11.txt.

 

In the case the IEEE 802.1Cp-208 is consider a normative reference, 

the following RFC2026  Section 7.1  (described below) might apply

that requires the WG LC to clearly indicate that a portion of the 

specification depends on  an external standard that exists behind 

a "paywall".   However,  RFC7241 section 3.2 specifies that any 

IEEE 802 published standard  and any IEEE 802 working group 

documents, are available for this  type of review at no charge.

  

Therefore, the "paywall" argument does not currently apply. 

 

It is the opinion of this WG chair that the 

dependence of this specification on IEEE 802.1Qcp definitions 

has been adequately discussed in the three WG LCs 

this document has gone through. 

 

My conclusion as shepherd/chair is that the "paywall" 

restriction does not exist even if  the Yang Doctors should decide 

the 802.1Qcp-2018 Yang reference needs to be informative. 

 

I am grateful to Tom Petch and Qin Wu for raising these issues. 

I believe it has fulfilled the discussion requirements for this 3rd WG LC. 

 

I will include this information in my shepherd's write-up early next week. 

I will hold this WG LC open for comments on this until 9/20/2019. 

If no other issues come in, it appears this WG LC is heading toward 

Consensus on this document.  

 

The ADs have been apprised that they will need to reference this discussion 

In the IETF LC. 

 

Susan Hares 

 

=======================

Discussion from ADS [Suresh, Warren, Martin, Alvaro]

 

Alvaro points out that the IEEE interactions are governed by 

RFC7241. 

--------------------- 

 

Suresh Krishnan and Warren Kumari discussion of section 7.1 

 

As described in Section 7.1 of RFC 2026, RFCs may have normative 

 references on external standards.

 In some cases, however, those references are themselves not generally 

 available (for instance, they might be accessible only after paying a 

 fee). This can interfere both with the ability of implementers to 

 implement the protocol as well as with the ability of the IETF 

 community to review it. 

 In such cases:

 1. The WG MUST be explicitly informed of any such normative reference 

 and the WG MUST reach consensus that it is acceptable. The document 

 shepherd MUST include this information in the shepherd writeup.

 2. The reference MUST be explicitly noted as part of the IETF Last 

 Call. If such a note is omitted, the last call MUST be repeated after 

 including it.