RE: Last call review of draft-ietf-mpls-tp-linear-protection-mib
"Adrian Farrel" <adrian@olddog.co.uk> Mon, 16 January 2017 18:20 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA43129603; Mon, 16 Jan 2017 10:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.313
X-Spam-Level:
X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, TRACKER_ID=1.306] 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 lWM8HfwZVxsg; Mon, 16 Jan 2017 10:20:16 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AF61295FF; Mon, 16 Jan 2017 10:20:15 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0GIK0u3019614; Mon, 16 Jan 2017 18:20:00 GMT
Received: from 950129200 ([65.119.211.164]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0GIInZu019367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2017 18:19:07 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Ryoo, Jeong-dong '" <ryoo@etri.re.kr>, ietf@ietf.org
References: <004201d26e88$c37e07f0$4a7a17d0$@olddog.co.uk> <5B4A6CBE3924BB41A3BEE462A8E0B75A29294F21@SMTP2.etri.info>
In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A29294F21@SMTP2.etri.info>
Subject: RE: Last call review of draft-ietf-mpls-tp-linear-protection-mib
Date: Mon, 16 Jan 2017 18:18:49 -0000
Message-ID: <010c01d27025$0faa3700$2efea500$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_010D_01D27025.0FBA63A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGA2ZCxbEF3YBCnx+OEvwEWJkmzNgGEVFABodJzl7A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22828.002
X-TM-AS-Result: No--18.594-10.0-31-10
X-imss-scan-details: No--18.594-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtE/qb5kBiifDhMMmcrjEONdR0SX1OwlZFr2UNhppzjER9Jx FyBvUX1X7+ykLzh4xShkG+By0KzAPUndsLjTlFHfma6DzXaohvML8TGleseLPDdnd59Af7CPdL9 U2Dbek1oJeC/LTkzef2ZjopFngc7Op7qMPMjvW3mOjIrMSa2sR3r6Rt++Qv1aOGCgDN6Ebfb+Q9 nyo6+tcEuTYzkZpCwjpRp3UfpA0aOrmmW6xY+ZmPv+//lqU1h61Ga2L87qPQKo+b+yOP0oGPWw4 jomxW69aLUo8jWbLpfERCDuxnh9ZDsCUsD7lL24U+OjsPhIWDgIjen4m7yaqglbhF7ZTanLVOCa 07mHB9gM1uAoS31c857dfsriGbVxRVwKIRfLzSbcWo5Vvs8MQlt06oMfzUpKRQ0dAChl/ly9aLl 7HSMJ0pgWdhIFEp4zJ6DAUS6kdvaRpHdNEA6HcaOuVibdZNTvB2Px0PWnGrtzXwu+EY2dZNAOOS AF0cTNmuPiXafpzwuGDtnwAy09qLqUgEs+NGTph2VzUlo4HVN51GakW92m5qB81nGQQJDplqx8D xj9EIVOmlU9SUbASOrFhCVn6Ze0mlLXzDiDGEMG1NkcAmdR4FxIyn/X4SmnHFSQk97VYGrzE7iK wulloTfXUO8XguJLmBRWdpJxiuRehll0JtAbYRIRh9wkXSlFWtDhCHcVAp74JyR+b5tvoCAOg9E 37d4vrgz/7WLQK47Rnd327aTojEdb73gUDwkXQr2qXCJMSV+uiAW0p38/t9KWShEsIp8TSMSu/N 2qjWzQcSTo5VI+43HG2qFsD3+pni0W1YoG9GmeAiCmPx4NwGmRqNBHmBve5C4nAKZioQFPWo7lc UlIVAPb516tYfF1TsZZ6BisvQjaL3GEFJ/JwUX+HYmvSKdkRfHjZTMEO2pt/4ntXGT3pA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xK7eNtce1WU4Ql8PoNvQeHFyoeA>
Cc: mpls@ietf.org, draft-ietf-mpls-tp-linear-protection-mib@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2017 18:20:20 -0000
Hi Jeong-dong. Perfect answers. Thank you. Adrian From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr] Sent: 16 January 2017 09:44 To: adrian@olddog.co.uk; ietf@ietf.org Cc: draft-ietf-mpls-tp-linear-protection-mib@ietf.org; mpls@ietf.org Subject: RE: Last call review of draft-ietf-mpls-tp-linear-protection-mib Adrian, thank you so much for the detailed review. Please, see my response (starting with [JR]) to your comments below. Best regards, Jeong-dong _____ 보낸 사람 : "Adrian Farrel" <adrian@olddog.co.uk> 보낸 날짜 : 2017-01-15 02:08:15 ( +09:00 ) 받는 사람 : ietf@ietf.org <ietf@ietf.org> 참조 : draft-ietf-mpls-tp-linear-protection-mib@ietf.org <draft-ietf-mpls-tp-linear-protection-mib@ietf.org>, mpls@ietf.org <mpls@ietf.org> 제목 : Last call review of draft-ietf-mpls-tp-linear-protection-mib > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'MPLS Transport Profile Linear Protection MIB' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-01-26. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. I have reviewed the -11 version of this document. It is well written and clear to read. I particularly welcome the explanations of the various objects. Here are a very few minor points and some nits. I think the document is ready to proceed to publication. Thanks, Adrian === Section 1 concludes with Although the example described in Section 7 specify means to configure OAM identifiers for MPLS-TP tunnels, this should be seen as indicating how the MIB values would be returned in the specified circumstances having been configured by alternative means. Two thoughts: 1. This text needs to be repeated in Section 7 2. This would read better as: Although the example described in Section 7 shows a way to configure OAM identifiers for MPLS-TP tunnels, this also indicates how the MIB values would be returned if they had been configured by alternative means. [JR] OK, those two points will be reflected to the revision. --- Section 4. The first sentence is a little hard to read... RFC 6378 [RFC6378] defines the protocol to provide a linear protection switching mechanism for MPLS-TP with protection domain as a point-to-point LSP. Looking at section 1.1. of RFC 6378, I think you could write... RFC 6378 [RFC6378] defines the protocol to provide a linear protection switching mechanism for MPLS-TP for a point-to-point LSP within the protection domain bounded by the end points of the LSP. [JR] OK. --- Is Section 5.1 too terse? Maybe a two line explanation of each new TC? [JR] Would the following text be ok? The following new textual conventions are defined in this document: o MplsLpsReq: This Textual Convention describes an object that stores the PSC Request field of the PSC control packet. o MplsLpsFpathPath: This Textual Convention describes an object that stores the Fault Path (FPath) field and Data Path (Path) field of the PSC control packet. o MplsLpsCommand: This Textual Convention describes an object that allows a user to perform any action over a protection domain. o MplsLpsState: This Textual Convention describes an object that stores the current state of the PSC state machine. --- Please have a quick check to see whether sometimes when you say "this MIB" you mean "this MIB module" (etc., for other uses of "MIB"). For example the Description clause of mplsLpsNotificationEnable "Provides the ability to enable and disable notifications defined in this MIB. [JR] I checked the whole document, and that was the only place to add the word, “module”. --- It is a little odd that MplsLpsReq has a syntax of OCTET STRING (SIZE (2)), a display hint of "1d", and you list the potential values in binary. I should think that the values should be listed in decimal as they are shown in RFC6378 and RFC7271. Then it is just a question of whether this should be a text string or an integer, which probably doesn't matter, but if your keep it as a octet string, you do need to say how the numbers are encoded (presumably ASCII?). [JR] I will change it to an integer. --- For MplsLpsFpathPath why do you say... Bits are numbered from left to right. ...I don't see any reference to bits. [JR] The notion of left/right was intended to indicate that FPath (the first octet, which is in left) is followed by Path (the second octet, which is in right). But, you are right and there is no reference to bits. Would it be ok to remove the sentence, “Bits are numbered from left to right.” ? --- mplsLpsConfigSdBadSeconds and mplsLpsConfigSdGoodSeconds could use a Units clause (although it should be pretty obvious from the name and description!) [JR] UNITS “seconds” will be added. --- Is there a reason why you used SYNTAX INTEGER {true (1), false (2)} instead of TruthValue in mplsLpsStatusRevertiveMismatch mplsLpsStatusProtecTypeMismatch mplsLpsStatusCapabilitiesMismatch mplsLpsStatusPathConfigMismatch OBJECT-TYPE [JR] No reason. TruthValue will be used in the revision. --- mplsLpsStatusPathConfigMismatch OBJECT-TYPE SYNTAX INTEGER {true (1), falsmplsOamIdMeMpIndexNexte (2)} Looks like a typo although it will compile :-) [JR] Once TruthValue is in place, this mistake will go away. === Nits --- Section 1 s/read- write/read-write/ s/document is consistent/document are consistent/ --- Section 4 s/alternate/alternative/ --- Section 5.3 s/failures of linear protection/failures of the linear protection/ --- mplsLpsMeStatusTable s/liear/linear/ [JR] All the nits will be fixed. Thank you.
- Last call review of draft-ietf-mpls-tp-linear-pro… Adrian Farrel
- RE: Last call review of draft-ietf-mpls-tp-linear… Ryoo, Jeong-dong
- RE: Last call review of draft-ietf-mpls-tp-linear… Adrian Farrel