Subject: [Gen-art] Assignments and spreadsheet for 15 Sept. 2005 now available

From: "Mary Barnes" <[email-masked]>
Date: Thu, 8 Sep 2005 19:56:20 -0500

Hi all,

The assignments for the Sept. 15th telechat are now available:
http://www.alvestrand.no/ietf/gen/art/reviewers-050915.html

with the updated spreadsheets available:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

This is a fairly light agenda, but just a warning that I will also be
doing some new LC assignments tomorrow to keep those from getting too
near deadlines. 

Let me know if there are any issues. 

Mary. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Sep 2005 21:58:33 -0400

[Copying the authors since they need to figure out the answers.  This is a 
gen-art review done for the IETF Chair]

This document is close to ready for publication as a Proposed Standard.
If the question below is that there is no substantive missing text, then 
the issues below need to be addressed.
However, if substantive text is missing, then that needs to be examined to 
see if it answers the issues.

Question:  Did some text disappear in editing?  There is the odd trailing 
text in section 2?  There is the absence of the usual section describing 
the structure / functioning of the MIB.  And there is the fact that section 
4 references sections 6 and 7 when the correct reference is sections 5 and 
6?  It is possible that the section two text is vestigial, and that the 
section 4 text needs correcting.  But the absence of the usual structural 
description makes me wonder if something is simply missing?

Issue:  There is no explanation of the fields for describing the usage of 
the mplsLcAtmStdUnlabTrafVpi and mplsLcAtmStdUnlabTrafVci.  RFC 3035 
indicates that ranges need to be partiitioned.  Obviously, this document is 
making some assumption about that partioning.  However, the combination of 
field descriptions in the MIB is insufficient to allow this reader to 
understand the intent.

Issue:  The text for mplsLcAtmVcDirectlyConnected and mplsLcAtmLcAtmVPI 
seems to assume that indirectly connected LC-ATM switches will always be 
connected by only one VP.  That is not required by 3035, and does not seem 
a necessary assumption.  It may be explained in the missing text.

Issue:  RFC 3034 calls out support for devices which support both labelled 
and unlabelled traffic on separated DLCIs.  Unlike the ATM tables earlier 
in the document, the FR tables do not have provision for indicating which 
DLCI ranges are supporting which mode.  Is there an assumption that the 
ranges here are for labelled traffic, and that some other MIB identifies 
the ranges for labelled traffic.

Minor / Editorial:  The "label switching controlled Frame Relay) referenced 
in the first part of the introduction is the same as the LC-FR in the 
latter part of the introduction.  Similarly for the ATM interface and 
LC-ATM.  Could a parenthetical (LC-FR) and (LC-ATM) be inserted between the 
full term and the RFC references?  (I know this is spelled out in the 
terminology.  The earlier insertion seems a good idea to meet the guideline 
of presenting an acronym before using it.)

Minor: Section 2, after the last period, has the text "Specifically," for 
no apparent reason.

Minor: An OID is reserved for LC ATM Notications, but none are defined.  Is 
it usually to reserve the OID in that case?  The same question applies to 
the LC FR Notifications OID as well.

Nit: idnits reports that some (10) of the pages are 1 line too long (59 
instead of 58) ?
----

RTG Multiprotocol Label Switching (MPLS) Label-Controlled ATM and 
Frame-Relay Management Interface Definition
         (Proposed Standard)
     <http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-06.txt>draft-ietf-mpls-lc-if-mib-06.txt

Token: <mailto:[email-masked]>Alex Zinin
Reviewer: Joel Halpern