From hubmib-bounces@ietf.org Thu Jun 16 04:06:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipOY-0000gO-Fm; Thu, 16 Jun 2005 04:06:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipOU-0000g2-Bb for hubmib@megatron.ietf.org; Thu, 16 Jun 2005 04:06:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24074 for ; Thu, 16 Jun 2005 04:06:27 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiplJ-0000N5-Qb for hubmib@ietf.org; Thu, 16 Jun 2005 04:30:10 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5G7sYAK026344 for ; Thu, 16 Jun 2005 03:54:34 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5G7sWAK026272 for ; Thu, 16 Jun 2005 03:54:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Jun 2005 11:06:21 +0300 Message-ID: Thread-Topic: WG Status Thread-Index: AcVySkfXFNklHa+UQOe10rsROQvufQ== From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Hubmib] WG Status X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629597320==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1629597320== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5724A.4857CA5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5724A.4857CA5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I apologize for the delay, but my time was taken over by other company and personal issues. Here is where we are: =20 1. The WG Last Call ended a few weeks ago. I am not aware of major open issues, but there may be a need for another editorial pass at least on some of the documents. I will let the authors know in the next few days. Meantime, if anybody is aware about any serious issue that for some reasons were not aired in the discussions until now, it's your after-the-last-minute opportunity! 2. After we make sure that the drafts are in good editorial shape I need to issue proto documentation to advance them to the IESG, with the recommendation to be published as Proposed Standards. I intent to wrap this up in the next month. I may need some information from the editors and WG members. One very helpful piece of information would be to point to existing 'pre-standard' implementations of the MIB modules defined in the drafts. You may communicate these in private mails to me if you cannot come open on the list for different reasons 3. Unless somebody points to a very serious reason, there will be no WG meeting in Paris =20 Regards, =20 Dan =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5724A.4857CA5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I = apologize for the=20 delay, but my time was taken over by other company and personal issues. = Here is=20 where we are:
 
1. The = WG Last Call=20 ended a few weeks ago. I am not aware of major open issues, but there = may be a=20 need for another editorial pass at least on some of the documents. I = will let=20 the authors know in the next few days. Meantime, if anybody is aware = about any=20 serious issue that for some reasons were not aired in the discussions = until now,=20 it's your after-the-last-minute opportunity!
2. = After we make=20 sure that the drafts are in good editorial shape I need to issue proto=20 documentation to advance them to the IESG, with the recommendation to be = published as Proposed Standards. I intent to wrap this up in the next = month. I=20 may need some information from the editors and WG members. One = very helpful=20 piece of information would be to point to existing = 'pre-standard'=20 implementations of the MIB modules defined in the drafts. You may = communicate=20 these in private mails to me if you cannot come open on the list for = different=20 reasons
3. = Unless somebody=20 points to a very serious reason, there will be no WG meeting in=20 Paris
 
Regards,
 
Dan
 
 
 
 
 
------_=_NextPart_001_01C5724A.4857CA5F-- --===============1629597320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1629597320==-- From hubmib-bounces@ietf.org Fri Jun 17 00:33:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj8Y0-0002Vg-Sq; Fri, 17 Jun 2005 00:33:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj8Xy-0002Va-At for hubmib@megatron.ietf.org; Fri, 17 Jun 2005 00:33:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19165 for ; Fri, 17 Jun 2005 00:33:31 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj8uz-0000V8-6C for hubmib@ietf.org; Fri, 17 Jun 2005 00:57:26 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5H4V3dd001528 for ; Fri, 17 Jun 2005 00:31:03 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5H4V1dd001496 for ; Fri, 17 Jun 2005 00:31:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2005 07:33:29 +0300 Message-ID: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Thread-Index: AcVy8kM0fSy0Z6AtQJusLC9tmuyHRgAA2m9g From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ietf-secretariat@ietf.org Sent: Friday, June 17, 2005 7:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France=20 There are two (2) Internet-Draft cutoff dates for the 63rd IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday, July 11th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Tuesday, July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, August 1st at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or revised Internet-Draft after their respective cutoff deadlines, then your document will be retained and posted when Internet-Draft processing resumes. You will no longer be required to resubmit the document. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Tue Jun 21 19:12:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkruy-0004wN-CN; Tue, 21 Jun 2005 19:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkruv-0004ty-ML for hubmib@megatron.ietf.org; Tue, 21 Jun 2005 19:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25227 for ; Tue, 21 Jun 2005 19:12:26 -0400 (EDT) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DksIv-0002Gx-8s for hubmib@ietf.org; Tue, 21 Jun 2005 19:37:18 -0400 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LPR8PUYTII99M315@vaxh.its.monash.edu.au> for hubmib@ietf.org; Wed, 22 Jun 2005 09:12:01 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EDC4680004; Wed, 22 Jun 2005 09:12:00 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id BDB7E3C010; Wed, 22 Jun 2005 09:12:00 +1000 (EST) Date: Wed, 22 Jun 2005 09:12:00 +1000 From: Greg Daley To: hubmib@ietf.org Message-id: <42B89EC0.4010506@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: 7BIT Cc: Alper Yegin , "Romascanu, Dan \(Dan\)" , Tom Petch Subject: [Hubmib] Request for discussion: proposed 802.3 section for draft-ietf-dna-link-information X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Dear Hubmib working group, In order to complete its milestones, the DNA working group has been developing a document cataloguing possible link-layer indications able to be sent between a host's link-layer and its network layer, upon connection to a new bridge port, or wireless cell. As part of the feedback received for this document, support for 802.3/Ethernet networks was indicated as a "must-have" in order to complete the document. As such here is an 'ethernet' section of the document to be incorporated into the document: http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt Your assistance is greatly desired in order to incorporate further 802 specific knowledge into the section. Please read the below text, to see if it makes sense, or if there are any behaviours claimed which aren't reasonable or possible. Any assistance you can provide will be greatly appreciated. Yours Faithfully, Greg Daley ------------------------------------ Section title: IEEE 802.3 CSMA/CD ------------------------------------ IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most commonly deployed Local Area Network technology in use today. As deployed today, it is specified by both a physical layer/medium access control (MAC) layer specification[802.3]. In order to provide connection of different LANs together into a larger network, 802.3 LANs are often bridged together[802.1D]. In this section, the terms 802.3 and Ethernet are used interchangeably. This section describes some issues in providing link-layer indications on Ethernet networks, and shows how bridging affects these indications. In Ethernet networks, hosts are connected by wires or by optic fibre to a switch (bridge), a bus (e.g. co-axial cable), a repeater (hub), or directly to another ethernet device. Interfaces are symmetric, in that while many different physical laters may be present, medium access control is uniform for all devices. In order to determine whether the physical medium is ready for frame transfer, IEEE 802.3 Ethernet specifies its own link monitoring mechanism, which is defined for some, but not all classes of media. Where available, this Link Integrity Test operation is used to identify when packets are able to be received on an Ethernet segment. It is applicable to both wired and optical physical layers, although details vary between technologies (link pulses in twisted pair copper, light levels in fibre). Subsection: Link Integrity Tests in 802.3 networks. --------------------------------------------------- Link Integrity Tests in 802.3 networks typically occur at initial physical connection time (for example, at the auto-negotiation stage), and periodically afterwards. It makes use of physical-layer specific operations to determine if a medium is able to support link-layer frames [802.3]. The status of the link as determined by the Link Integrity Test is stored in the variable 'link_status'. Changes to the value of link_status (for example due to Link Integrity Test failure) will generate link indications if the technology dependent interface is implemented on an ethernet device [802.3]. The link_status has possible values of FAIL, READY and OK. When an interface is in FAIL state, Link Integrity Tests have failed. Where status is READY, the link segment has passed integrity tests, but autonegotiation has not completed. OK state indicates that the medium is able to send and receive packets. Upon transition to a particular state the Physical Medium Attachment subsystems generates a PMA_LINK.indicate(link_status). Indications of OK state may be used as Link-Up indications for DNA. PMA_LINK.indicate(FAIL) may be used as a Link-Down indication reliably by DNA[802.3]. Such indications do not definitively ensure that packets will be able to be received through the bridge domain, though. Such operations are governed by bridging. Subsection: IEEE 802.1D Bridging and its effects on link indications -------------------------------------------------------------- Ethernet networks commonly consist of LANs joined together by transparent bridges (usually implemented as switches). Tranparent bridges require the active topology to be loop free. The Spanning Tree Protocol (STP) achieves this by the exchange of Bridge Protocol Data Unit (BPDU), as defined in [802.1D], which leads to, where required, the blocking of ports (ie not forwarding). By default, the spanning tree protocol does not know whether a particular newly connected piece of ethernet will cause a loop. Therefore it will block all traffic from and to a newly connected ports with the exception of some unbridged management frames. The STP will determine if the port can be connected to the network in a loop-free environment. For these technologies, even though the link-layer appears available, no forwarding will occur until it is determined that the port can be connected to the network in a loop-free environment. For host which are providing indications to upper layer protocols, even if the host itself does not implement bridging or STP, packet delivery across the network can be affected by the presence of bridges. Where the host is not running STP itself, no explicit indication that forwarding has begun is sent from a bridge. Therefore, a host may not know when STP operations have completed, and when it is safe to inform upper layers to transmit packets. Where it is not known that forwarding operations are available, a host needs to assume that STP is being performed, and may indicate full connectivity only based on timeouts or reception of BPDUs. Most hosts today do not listen to BPDU frames. For these hosts, connectivity to the a port which is potentially bridged (any Ethernet port) carries the potential of frame loss if transmissions occur before any bridges' ForwardDelay timers have expired twice. This timeout defaults to 30 seconds (2 * 15 seconds), but may be as high as 60s[802.1D]. When sending indications to upper layers, the period where frame forwarding is potentially unavailable should be indicated to upper-layer protocols. Alternatively, a host can listen for BPDUs and use them to determine the length of port blockage which will occur in their particular circumstances. Upon learning that an adjacent port is running STP or RSTP, the host may send a Link-Up indication with a 'forwarding available' parameter upon expiry of calculated delays to indicate that general packet transfer is available across the LAN. If no bridge configuration messages are received within the Bridge_Max_Age interval (default 20s), then it is likely that there is no visible bridge whose port is enabled for bridging (S8.4.5 of [802.1D]), since at least two BPDU hello messages would have been lost. It is not easy for a non-STP host to distinguish between Disabled bridge ports and non-bridge ports with no IP nodes on them, as Disabled ports will have no traffic on them, and incur 100% sender loss. Upon this Bridge_Max_Age timeout, a host may (re)-send a link-layer indication showing that packets sent within the prior interval were likely to have traversed the forwarding path (unless the port is disabled). If a BPDU is received, and the adjacent bridge is running the original Spanning Tree Protocol, then host cannot successfully send packets until at least twice the ForwardDelay value in the received BPDU has elapsed. After this time, the host can send a link-layer up indication showing that the previous interval after the PMA_LINK.indicate(OK) event was one of loss. If the bridge is identified as performing Rapid Spanning Tree Protocol (RSTP), it instead waits Bridge_Max_Age after packet reception (advertised in the BPDU's Max Age field), before forwarding. For ports which are known to be point-to-point through autonegotiation, this delay is abbreviated to 3 seconds after autonegotiation completes [802.1D]. After either of these delays, a link-layer indication updating the PMA_LINK.indicate(OK) can show that the interval between indications was a lossy interval. Subsection: IEEE 802.1AB Link-Layer Discovery Protocol. ------------------------------------------------------- The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) provides information to devices which are directly adjacent to them on the local LAN[802.1AB]. LLDP sends information periodically, and at link status change time to indicate the configuration parameters of the device. Devices may either send or receive these messages, or both. The LLDP message may a System Capabilities TLV, which describes the MAC and IP layer functions which a device is currently using. Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the LLDP transmitter, then no delays for STP calculation will be applied to packets sent through this transmitter, if the host does not perform STP itself. This would allow the host's link-layer to indicate that to its knowledge the link is available for packet transfer. Additionally, if a host receives a Systems Capabilities TLV which indicates that the LLDP transmitter is a bridge, the host's advertisement that it is an (end-host) Station-Only, may tell the bridge not to run STP, and immediately allow forwarding. Proprietary extensions may also indicate that data forwarding is already available on such a port. Discussion of such optimizations is out-of-scope for this document. Due to the protocol's newness and lack of deployment, it is unclear how this protocol will eventually affect DNA in IPv4 or IPv6 networks. Subsection: Summary ------------------- Link-Layer indications in Ethernet-like networks are complicated by additional unadvertised delays due to Spanning Tree calculations. This may cause re-indication or retraction of indications previously sent to upper layer protocols. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Wed Jun 22 04:50:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl0wT-00015s-7H; Wed, 22 Jun 2005 04:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl0wR-00013s-Ii for hubmib@megatron.ietf.org; Wed, 22 Jun 2005 04:50:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14434 for ; Wed, 22 Jun 2005 04:50:37 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl1KV-0008BH-Iz for hubmib@ietf.org; Wed, 22 Jun 2005 05:15:33 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5M8cYAK017916 for ; Wed, 22 Jun 2005 04:38:34 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5M8cWAK017867 for ; Wed, 22 Jun 2005 04:38:33 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 22 Jun 2005 11:50:28 +0300 Message-ID: Thread-Topic: rfc3636bis Thread-Index: AcV3B3AJ38JHYWHoRpK+8VmpWSTZ9Q== From: "Romascanu, Dan \(Dan\)" To: "Edward Beili" X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: hubmib@ietf.org Subject: [Hubmib] rfc3636bis X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1467970189==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1467970189== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57707.703F8DEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57707.703F8DEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Edward, =20 Could you please make a list of intended changes based on comments received during the last call period for draft-ietf-hubmib-rfc3636bis and post it to the WG?=20 =20 Thanks and Regards, =20 Dan =20 =20 =20 =20 =20 ------_=_NextPart_001_01C57707.703F8DEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Edward,
 
Could = you please=20 make a list of intended changes based on comments received during the = last call=20 period for draft-ietf-hubmib-rfc3636bis and post it to the WG?=20
 
Thanks = and=20 Regards,
 
Dan
 
 
 
 
 
------_=_NextPart_001_01C57707.703F8DEB-- --===============1467970189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1467970189==-- From hubmib-bounces@ietf.org Thu Jun 23 09:07:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRQu-0006g4-7N; Thu, 23 Jun 2005 09:07:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRQr-0006fw-By for hubmib@megatron.ietf.org; Thu, 23 Jun 2005 09:07:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07494 for ; Thu, 23 Jun 2005 09:07:48 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRpB-0002p7-Ms for hubmib@ietf.org; Thu, 23 Jun 2005 09:32:58 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5ND5Ddd001319 for ; Thu, 23 Jun 2005 09:05:14 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5ND47dd029515 for ; Thu, 23 Jun 2005 09:04:26 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 23 Jun 2005 16:06:32 +0300 Message-ID: Thread-Topic: draft-ietf-hubmib-efm-epon-mib-03.txt almost ready to go Thread-Index: AcV39GDtYUtTMo30SvOMKfh4smW62w== From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Subject: [Hubmib] draft-ietf-hubmib-efm-epon-mib-03.txt almost ready to go X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0822084141==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0822084141== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C577F4.60B8B453" This is a multi-part message in MIME format. ------_=_NextPart_001_01C577F4.60B8B453 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-hubmib-efm-epon-mib-03.txt is almost ready to go. There are several objects with a length exceeding 32 characters that lead to smilit complaining: =20 smilint -m -s -e -m -s -l 6 -I namelength-32 epon-mib-03.txt epon-mib-03.txt:75: [2] {bad-identifier-case} `XXX' should start with a lower case letter epon-mib-03.txt:75: [2] {object-identifier-not-prefix} Object identifier element `XXX' name only allowed as first element epon-mib-03.txt:879: [4] {namelength-32-object} warning: object identifier name `dot3OmpEmulationBroadcastBitNotOnuLlid' longer than 32 characters epon-mib-03.txt:894: [4] {namelength-32-object} warning: object identifier name `dot3OmpEmulationOnuLLIDNotBroadcast' longer than 32 characters epon-mib-03.txt:909: [4] {namelength-32-object} warning: object identifier name `dot3OmpEmulationBroadcastBitPlusOnuLlid' longer than 32 characters epon-mib-03.txt:928: [4] {namelength-32-object} warning: object identifier name `dot3OmpEmulationNotBroadcastBitNotOnuLlid' longer than 32 characters epon-mib-03.txt:1112: [4] {namelength-32-object} warning: object identifier name `dot3EponMauFECUncorrectableBlocks' longer than 32 characters epon-mib-03.txt:1125: [4] {namelength-32-object} warning: object identifier name `dot3EponMauBufferHeadCodingViolation' longer than 32 characters epon-mib-03.txt:1276: [2] {bad-identifier-case} `XXX' should start with a lower case letter epon-mib-03.txt:1276: [2] {object-identifier-not-prefix} Object identifier element `XXX' name only allowed as first element epon-mib-03.txt:1431: [4] {namelength-32-object} warning: object identifier name `eponDeviceObjectReportNumThreshold' longer than 32 characters epon-mib-03.txt:1466: [4] {namelength-32-object} warning: object identifier name `eponDeviceObjectReportMaximumNumThreshold' longer than 32 characters epon-mib-03.txt:1480: [4] {namelength-32-object} warning: object identifier name `eponDeviceObjectReportMaximumNumQueues' longer than 32 characters epon-mib-03.txt:1495: [4] {namelength-32-object} warning: object identifier name `eponDeviceRemoteMACAddressLLIDControl' longer than 32 characters epon-mib-03.txt:1514: [4] {namelength-32-object} warning: object identifier name `eponDeviceRemoteMACAddressLLIDTable' longer than 32 characters epon-mib-03.txt:1540: [4] {namelength-32-object} warning: object identifier name `eponDeviceRemoteMACAddressLLIDEntry' longer than 32 characters epon-mib-03.txt:1552: [4] {namelength-32-type} warning: type name `EponDeviceRemoteMACAddressLLIDEntry' longer than 32 characters epon-mib-03.txt:1563: [4] {namelength-32-object} warning: object identifier name `eponDeviceRemoteMACAddressLLIDName' longer than 32 characters epon-mib-03.txt:1927: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue0' longer than 32 characters epon-mib-03.txt:1941: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue1' longer than 32 characters epon-mib-03.txt:1955: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue2' longer than 32 characters epon-mib-03.txt:1969: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue3' longer than 32 characters epon-mib-03.txt:1983: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue4' longer than 32 characters epon-mib-03.txt:1997: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue5' longer than 32 characters epon-mib-03.txt:2011: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue6' longer than 32 characters epon-mib-03.txt:2025: [4] {namelength-32-object} warning: object identifier name `eponDeviceStatDroppedFramesQueue7' longer than 32 characters =20 Also, idnits complains about the boilerplate not being update - no wonder taking into account that RFC 3978 and 3979 started to be applied after the Internet-Draft was published:=20 =20 =20 idnits 1.74=20 tmp/draft-ietf-hubmib-efm-epon-mib-03.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement.=20 (Expected a match on the following text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.") (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. =20 I would kindly request the document editor to publish an updated draft to fix these editorial issues before I submit the I-D to the IESG. I do not believe that these changes would require a new WGLC, unless somebody feels strongly otherwise. Thanks and Regards, =20 Dan =20 =20 =20 ------_=_NextPart_001_01C577F4.60B8B453 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
draft-ietf-hubmib-efm-epon-mib-03.txt is almost ready to go. There are several = objects with=20 a length exceeding 32 characters that lead to smilit=20 complaining:
 

smilint -m -s -e -m -s -l 6 -I = namelength-32=20 epon-mib-03.txt

epon-mib-03.txt:75: [2] = {bad-identifier-case} `XXX'=20 should start with a lower case letter

epon-mib-03.txt:75: [2]=20 {object-identifier-not-prefix} Object identifier element `XXX' name only = allowed=20 as first element

epon-mib-03.txt:879: [4] = {namelength-32-object}=20 warning: object identifier name `dot3OmpEmulationBroadcastBitNotOnuLlid' = longer=20 than 32 characters

epon-mib-03.txt:894: [4] = {namelength-32-object}=20 warning: object identifier name `dot3OmpEmulationOnuLLIDNotBroadcast' = longer=20 than 32 characters

epon-mib-03.txt:909: [4] = {namelength-32-object}=20 warning: object identifier name = `dot3OmpEmulationBroadcastBitPlusOnuLlid' longer=20 than 32 characters

epon-mib-03.txt:928: [4] = {namelength-32-object}=20 warning: object identifier name = `dot3OmpEmulationNotBroadcastBitNotOnuLlid'=20 longer than 32 characters

epon-mib-03.txt:1112: [4] = {namelength-32-object}=20 warning: object identifier name `dot3EponMauFECUncorrectableBlocks' = longer than=20 32 characters

epon-mib-03.txt:1125: [4] = {namelength-32-object}=20 warning: object identifier name `dot3EponMauBufferHeadCodingViolation' = longer=20 than 32 characters

epon-mib-03.txt:1276: [2] = {bad-identifier-case} `XXX'=20 should start with a lower case letter

epon-mib-03.txt:1276: [2]=20 {object-identifier-not-prefix} Object identifier element `XXX' name only = allowed=20 as first element

epon-mib-03.txt:1431: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceObjectReportNumThreshold' = longer than=20 32 characters

epon-mib-03.txt:1466: [4] = {namelength-32-object}=20 warning: object identifier name = `eponDeviceObjectReportMaximumNumThreshold'=20 longer than 32 characters

epon-mib-03.txt:1480: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceObjectReportMaximumNumQueues' = longer=20 than 32 characters

epon-mib-03.txt:1495: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceRemoteMACAddressLLIDControl' = longer=20 than 32 characters

epon-mib-03.txt:1514: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceRemoteMACAddressLLIDTable' = longer=20 than 32 characters

epon-mib-03.txt:1540: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceRemoteMACAddressLLIDEntry' = longer=20 than 32 characters

epon-mib-03.txt:1552: [4] = {namelength-32-type}=20 warning: type name `EponDeviceRemoteMACAddressLLIDEntry' longer than 32=20 characters

epon-mib-03.txt:1563: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceRemoteMACAddressLLIDName' = longer than=20 32 characters

epon-mib-03.txt:1927: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue0' = longer than=20 32 characters

epon-mib-03.txt:1941: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue1' = longer than=20 32 characters

epon-mib-03.txt:1955: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue2' = longer than=20 32 characters

epon-mib-03.txt:1969: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue3' = longer than=20 32 characters

epon-mib-03.txt:1983: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue4' = longer than=20 32 characters

epon-mib-03.txt:1997: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue5' = longer than=20 32 characters

epon-mib-03.txt:2011: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue6' = longer than=20 32 characters

epon-mib-03.txt:2025: [4] = {namelength-32-object}=20 warning: object identifier name `eponDeviceStatDroppedFramesQueue7' = longer than=20 32 characters

 

Also, = idnits complains=20 about the boilerplate not being update - no wonder taking into account = that RFC=20 3978 and 3979 started to be applied after the Internet-Draft was = published:=20

 

 
idnits 1.74=20

tmp/draft-ietf-hubmib-efm-epon-mib-03.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement.=20

  (Expected a match on the following text:
    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.")

    (The document uses RFC 3667 boilerplate or RFC 3978-like
    boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 May =
2005,
    submission of drafts without verbatim RFC 3978 boilerplate is not
    accepted.)

  Checking nits according to =
http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.
 
I =
would kindly request the document editor to publish an updated draft to =
fix these editorial issues before I submit the I-D to the IESG. I do not =
believe that these changes would require a new WGLC, unless somebody =
feels strongly otherwise.
Thanks and Regards,
 
Dan
 
 
 
------_=_NextPart_001_01C577F4.60B8B453-- --===============0822084141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0822084141==-- From hubmib-bounces@ietf.org Thu Jun 23 16:56:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYkI-000712-5i; Thu, 23 Jun 2005 16:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYkG-00070c-99 for hubmib@megatron.ietf.org; Thu, 23 Jun 2005 16:56:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01051 for ; Thu, 23 Jun 2005 16:56:18 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlZ8d-0004uk-P6 for hubmib@ietf.org; Thu, 23 Jun 2005 17:21:33 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j5NKu5Lb012303 for ; Thu, 23 Jun 2005 13:56:05 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j5NKu15f007489 for ; Thu, 23 Jun 2005 13:56:01 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j5NKtxVb007467 for ; Thu, 23 Jun 2005 13:56:01 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 23 Jun 2005 13:55:58 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Subject: Re: [Hubmib] draft-ietf-hubmib-efm-epon-mib-03.txt almost ready to go In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org On Thu, 23 Jun 2005, Dan Romascanu wrote: > draft-ietf-hubmib-efm-epon-mib-03.txt is almost ready to go. There are > several objects with a length exceeding 32 characters that lead to > smilit complaining: According to section 4.2 of the MIB review guidelines (see http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt) this is not something that needs to be corrected. > smilint -m -s -e -m -s -l 6 -I namelength-32 epon-mib-03.txt __________________________________^ That should be a lower-case 'i' (in which case the directive will mean "ignore names over 32 characters"). When I do that (and put in fake mib-2 numbers in place of XXX) I get this from the smilint e-mail robot: smilint -m -s -e -l 6 -i namelength-32 EPON-DEVICE-MIB no errors found. smilint -m -s -e -l 6 -i namelength-32 DOT3-EFM-EPON-MIB no errors found. So, I don't think there are any purely SMI issues to worry about. For sure it's not necessary to shorten the names. > Also, idnits complains about the boilerplate not being update - no > wonder taking into account that RFC 3978 and 3979 started to be > applied after the Internet-Draft was published: > ... details snipped ... > > I would kindly request the document editor to publish an updated > draft to fix t hese editorial issues before I submit the I-D to > the IESG. I do not believe tha t these changes would require a > new WGLC, unless somebody feels strongly otherwise. I agree with the above. Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Jun 27 02:28:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmn6a-0007zM-Oc; Mon, 27 Jun 2005 02:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmn6Y-0007zH-C3 for hubmib@megatron.ietf.org; Mon, 27 Jun 2005 02:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14247 for ; Mon, 27 Jun 2005 02:28:24 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmnVe-00052A-9G for hubmib@ietf.org; Mon, 27 Jun 2005 02:54:22 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5R6GJAK022468 for ; Mon, 27 Jun 2005 02:16:19 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5R6GHAK022445 for ; Mon, 27 Jun 2005 02:16:17 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Hubmib] draft-ietf-hubmib-efm-epon-mib-03.txt almost ready to go Date: Mon, 27 Jun 2005 09:28:17 +0300 Message-ID: Thread-Topic: [Hubmib] draft-ietf-hubmib-efm-epon-mib-03.txt almost ready to go Thread-Index: AcV4Nk3tfoATl2K0QuOJQreW7OdBcwCqcImw From: "Romascanu, Dan \(Dan\)" To: "C. M. Heard" , "Hub MIB" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Thanks for the advice, Mike.=20 Taking this into account, I believe that the EFM MIB and the EPON MIB are OK to be shipped to the IESG, and I will fill in the necessary recommendations. The boilerplate and formatting problems are tolerable in my opinion, taking into account that the documents were issued before May 2005 when the latest IPR RFCs were issued.=20 The EFM Cu and new MAU MIB are still in works and will need another round of editing and WGLC. Dan > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org] On Behalf Of C. M. Heard > Sent: Thursday, June 23, 2005 11:56 PM > To: Hub MIB > Subject: Re: [Hubmib] draft-ietf-hubmib-efm-epon-mib-03.txt=20 > almost ready to go >=20 > On Thu, 23 Jun 2005, Dan Romascanu wrote: > > draft-ietf-hubmib-efm-epon-mib-03.txt is almost ready to=20 > go. There are > > several objects with a length exceeding 32 characters=20 > that lead to > > smilit complaining: >=20 > According to section 4.2 of the MIB review guidelines (see > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines-04.txt) > this is not something that needs to be corrected. >=20 > > smilint -m -s -e -m -s -l 6 -I namelength-32 epon-mib-03.txt > __________________________________^ >=20 > That should be a lower-case 'i' (in which case the directive=20 > will mean "ignore names over 32 characters"). When I do that=20 > (and put in fake mib-2 numbers in place of XXX) I get this=20 > from the smilint e-mail robot: >=20 > smilint -m -s -e -l 6 -i namelength-32 EPON-DEVICE-MIB >=20 > no errors found. >=20 > smilint -m -s -e -l 6 -i namelength-32 DOT3-EFM-EPON-MIB >=20 > no errors found. >=20 > So, I don't think there are any purely SMI issues to worry about. > For sure it's not necessary to shorten the names.=20 >=20 > > Also, idnits complains about the boilerplate not being=20 > update - no > > wonder taking into account that RFC 3978 and 3979 started to be > > applied after the Internet-Draft was published: > > =20 > ... details snipped ... > >=20 > > I would kindly request the document editor to publish an=20 > updated draft=20 > > to fix t hese editorial issues before I submit the I-D to=20 > the IESG. I=20 > > do not believe tha t these changes would require a new WGLC, unless=20 > > somebody feels strongly otherwise. >=20 > I agree with the above. >=20 > Mike Heard >=20 >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib