Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-te-mib-09

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 11 Dec 2014 12:41:40 -0800

Hi Elwyn,

Thanks for the review and comments.
Please find the responses inline.
> On Dec 11, 2014, at 10:36 AM, Elwyn Davies <[email-masked]> wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-mpls-tp-te-mib-09.txt
> Reviewer: Elwyn Davies
> Review Date: 10 December 2014
> IETF LC End Date: 8 December 2014
> IESG Telechat date: (if known) -
> 
> 
> Summary:
> Not  ready.  I am not a MIB expert nor an MPLS(-TP) configuration expert, so I have
> assumed that the details of the MIB specification have been addressed by
> Joan's MIB Doctor review and the configuration examples have been checked by an
> MPLS-TP expert.  However, the introductory text needs significant work to make it
> easier for people who are not MPLS-TP experts to come to grips with the document.
This MIB is intended to be used for MPLS-TP tunnels and is done by the way of extending existing MPLS-TE MIB. The assumption is that reader is already aware of MPLS-TP. Hence we didn’t provide a primer for MPLS-TP in this MIB and I am not sure if it is the right place either. 
> 
> The major issue with this document is that it appears to go against the current IETF view
> that SNMP is not a satisfactory solution for configuring networks. The document has
> effectively reiterated the RFC 3812 situation from 10 years ago when the IETF held its nose
> and said that SNMP  was the only game in town even if security sucked.  As I mention below, this was extensively discussed a year ago but I couldn't determine whether this draft was given
> a special dispensation even though consensus seemed to be that writeable MIBs were
> considered inappropriate.  If this is the case, it will be sufficient to adapt the end of s1.
We have deliberated over this topic for more than two years and after multiple discussions along with Routing AD and OPS AD, we decided to go forward with the writable objects for this MIB. Additionally we added a small paragraph at the end of s1,  as recommended, the reason for doing so.
> 
> AFAICS this draft has not had the 'grammar review' recommended by its AD about a year
> ago and there are a number of areas in the object descriptions where language
> improvements would be desirable in addition to notes given here. That is it still needs
> the grammar review.
We could take help of English reviewers and request WG chairs to help us out in this regard.
> 
> There are some more minor issues, particularly as regards the description of the types
> of tunnel in s1, the discussion of the contents of the MIBs in s6 and possibly in regard to
> the interaction with the standard interface table.
> 
> 
> Major issues:
> 
> Support for configuration:
> The issue of SNMPset (write) support was discussed at length in the context of
> the MIB doctors' review of v-05 of this draft. The consensus at that time appeared
> to be that provision of write support in new MIBs should be strongly discouraged.
> I am unclear what the outcome of that discussion in the context of this draft was,
> but it is clear that the draft is very much written from the point of using the MIB
> as a configuration tool, especially in s9 (examples of usage). Whilst this technique
> reflects the equivalent section is RFC 3813, that document was written over 10 years
> ago and considerable effort has been devoted to providing alternative and more secure
> ways of configuring networks in the intervening time. The body of the document has not
> been altered to reflect the discussion that occurred.
Whether SNMP write should exist or not discussion is not within the scope of this document. Whether this MIB should support writable MIB objects was discussed and the conclusion was yes. The text at end of s1 was added as recommended by AD’s. On the contrary, if this MIB were to change the way RFC3813 is to implemented/interpreted along with the MIB i.e. from writable for TE but read-only for non MPLS-TE tunnels, then it should be documented. 

> "Lip service" is paid to the discouragement of the use of SNMPset by the addition of
> para 3 of s1:
>> It is understood that SNMP SET is not used for MPLS configuration these
>> days, however the read-write and read-create option is still specified
>> for some objects as a way to provide the information model.
> It is not clear to me why providing read-write or read-create options enhance the
> MIB or are "a way to provide the information model".
> 
> I note that despite the extensive discussion of this topic by WG members and MIB specialists
> back in December 2013, this issue was not flagged up in the Shepherd's write up.
> 
> If it has now been agreed that the configuration "flavour" is to be accepted as WG consensus
> in spite of being contrary to current practice, it appears to me that the word "configuration"
> should be removed from the last sentence of para 2 of s1 and the last para of s1 rewritten to
> explain why write capabilities are used in a more convincing manner.
As noted above, the write option was retained after discussing at length, both at the WG sessions and over emails. The statement in last part of s1 was added as per the advice we received to move forward with the writable objects [ref: email from OPS AD dated Mar 11 on MPLS mailing list]. The main reason for writable objects, is because the MPLS-TE had writable objects and MPLS-TP extensions leverage this existing MIB and also few vendors have implemented them.

Having said that, we are open to any suggested text, in addition to the one, which you already did below, in regards to ‘writable’ objects.
> 
> Minor issues:
> Abstract/s1: Needs to be clear in both places that is is intended for MPLS-TP, this:
> -- Abstract and s1: s/transport networks./MPLS networks conforming to the MPLS Transport Profile (MPLS-TP)./
> 
> s1: What is a Non-MPLS-TP (transport) network?
MPLS-TE and other MPLS networks which is not constrained by transport requirements. Assuming some new tunnel type comes up into the future like bi-directional TE. :D
> 
> s1: The explanation of what the MIB extensions in this document actually do is not clear to the
> general reader. I suggest replacing para 2 completely:
> 
> OLD:
> The existing MPLS Traffic Engineering (TE) Management Information Base
> (MIB) [RFC3812] and Generalized Multiprotocol Label Switching (GMPLS)
> Traffic Engineering Management Information Base [RFC4802] do not support
> the management of transport network requirements of Tunnel end points
> with non-IP based identifiers and static bidirectional tunnels. This
> document focuses on static bidirectional MIB modules that should be used
> in conjunction with [RFC3812] and companion document [RFC3813] for MPLS
> Transport Profile (MPLS-TP) path configuration and management.
> 
> NEW:
> As described in the MPLS Traffic Engineering (TE) Management Information Base (MIB) definition [RFC3812], MPLS traffic engineering is concerned with the
> creation and management of MPLS tunnels. This term is a shorthand for a
> combination of one or one or explicitly routed LSPs (ERLSPs) linking an ingress
> and an egress LSR. Several types of point-to-point MPLS tunnels may be constructed
> between a pair of LSRs A and B:
> 
> - Unidirectional with a single LSP (say) from A to B.
> 
> - Associated bidirectional consisting of two separately routed ERLSPs, one linking
> A to B and the other linking B to A. Together the pair provide a single logical
> bidirectional transport path.
> 
> - Corouted bidirectional consisting of an associated bidirectional tunnel but with
> the second ERLSP from B to A following the reverse of the path of the ERLSP
> from A to B, in terms of both nodes and links.
> 
> Tunnels may be either statically configured by management action or dynamically created using
> a LSP management protocol.
what is ‘LSP management protocol’?
> 
> The existing MPLS TE MIB [RFC3812] and the Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [RFC4802] address only a subset of the
> combinations of statically and dynamically configured tunnel types, catering for statically
> configured unidirectional tunnels together with dynamically configured unidirectional and
> corouted bidirectional tunnels. They are alsorestricted to to end point LSRs identified
> by IP addresses.
> 
> The MPLS-TP TE MIB defined in this document extends the MIB defined in [RFC3812] to cover
> all six combinations (that is adding support for statically configured associated and
> corouted bidirectional plus dynamically configured associated bidirectional tunnels). It also
> extends support to end points that are identified other than with IP addresses.
> 
> This support is provided by a suite of four MIB modules that are to be used in conjunction
> with the MIBS defined in [RFC3812] and the companion document [RFC3813] for MPLS
> Transport Profile (MPLS-TP) TE path [configuration and]* management.
> 
> END NEW
Thank you. Will go through the text again and replace as suggested.
> 
> * Note: Using the term 'configuration' is inconsistent with the discussion in para 3.
> See Major Issues above
> 
> s5, bullet 1: s8 in RFC 3812 discusses the use of the Interface Table with MPLS. It should be
> made clear here:
> 1. Whether, if the MPLS-TP Tunnel is treated as an interface, there is any difference in the usage
> of the ifTable fields as compared with standard MPLS. In particular if a different interface type
> should be applicable.
> 2. Are there any issues if all or (more especially) a subset of the tunnels are not treated as
> interfaces
Haven’t come across any different types as such. Do you see any specific type which is of contrary to RFC 3812, that MPLS-TP defines? Will ask my co-authors as well.
> 
> Row pointer usage: s9 of RFC 3812 considers Row Pointer usage - are there any differences or
> additional considerations for these MIBs?
None that we are aware off.
> 
> s6: Sections 6.1 to 6.4 are not MIBs (as indicated by the title and prologue) but MIB objects in
> the MPLS-TE-EXT-STD-MIB MIB. Please reorganize s6 accordingly. Looking back at RFC3812, the
> structure of the document in sections 5 and 6 appears to be more helpful to the new reader with a
> summary of the four MIB modules in one section (expanded from ss6.5 - 6.7) followed by notes on
> the key MIB objects in each MIB as necessary. It would also be helpful to clarify where objects in
> this MIB are expected to parallel those in the basic (RFC 3812) and note that they are indexed
> equivalently (notably in the case of mplsTunnelTable and mplsTunnelExtTable).
> Nits/editorial comments:
Nod.
> General: Consistent use of bi-directional or bidirectional: Please choose one and use it throughout.
Nod.
> 
> General: The qualifier "sparse" is used incorrectly in several places (e.g., sparsely extended).
> Presumably the intention is that the extensions are "slight" or "limited" . In most cases the term
> can be deleted: The degree of extension will ultimately be in the eyes of the implementer!
> (s5 - 2 cases, s6.4, s7 - 2 cases, s8, s9.1.6, s9.2.9, s9.3.6, s12 - 3 cases)
> General: The figures need number and captions. The numbers should be used to refer to the figures.
Will review and edit as suggested.
> 
> s4, para 1: s/unidirectional tunnel/unidirectional tunnels/
Nod.
> 
> s4, para 1, last sentence: s/re-use/re-use and extend/
Nod.
> 
> s4, para 2:
> OLD:
> retained in the same document, instead of a separate document.
> NEW:
> all defined in this document, rather than split over several documents.
> 
> s5, para 1: s/This document identifies/The MIBs in this document satisfy/
> 
> s5, para 2: s/The MIB module supports/The MIB modules, taken together, support/
> 
> s5, para 2: s/static and signaled/statically configured and dynamically signaled/
> 
> s5, bullet 4: s/sparsely extended/extended/
> 
> s9.1.6, s9.2.9, s9.3.6: s/a sparse augmentation/a limited augmentation/
Nod for all the above.
> 
> s5, bullet 5: It would be helpful to explain how node identification differs from
> standard MPLS to understand why this mapping is needed. There appears to be text in s6.1 that might help
> but it is too late to make it easy to understand this section.
Will add reference to s6.1.
> 
> ss10-13: It is conventional to give the RFCs used as references in the docuement s/RFC 3812/[RFC3812]/ etc.
Nod.
> 
> s14: This is a near duplicate of the security considerations in RFC 3812. It might be easier to reference
> that section and add a note that extra tables may provide further sensitive information.
Nod.
> 
> A brief discussion of whether the non-IP case makes any difference would be useful.
I do not think there is a difference as such. We have provided example for non-ip case anyway.
> 
> s16: At the very least RFC 3811, RFC 3812 and RFC 3813 are normative. RFC 6923 probably is.
> RFC 6370 and RFC 4802 may also be.
Nod.

thanks again
-sam

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Dec 2014 22:11:45 -0500

I suppose I could have a look at the grammar. What format would I use to 
convey suggested changes?

Tom Taylor

On 11/12/2014 3:41 PM, Sam K. Aldrin wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 11 Dec 2014 19:24:35 -0800

Hi Tom,

That would be very much appreciated.
Text or word with embedded comments or suggestions is good. 
If you prefer other way, that is fine as well.

cheers
-sam
> On Dec 11, 2014, at 7:11 PM, Tom Taylor <[email-masked]> wrote:
> 
> I suppose I could have a look at the grammar. What format would I use to convey suggested changes?
> 
> Tom Taylor
>

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 12 Dec 2014 14:40:13 +0000

Hi, Sam.

Thanks for the responses.

On the subject of SNMP write, I understand that agreement has been 
reached that the
the MIB should effectively adopt the same position as RFC 3812, i.e. 
having read/write etc.
objects and describing the use of the MIB for configuration in the 
examples.  I suggest that
para 3 of s1 is rewritten to make this a bit clearer what the position 
is and also to explain
what the phrase "as a way to provide the information model" means.  My 
suggestion...

OLD:

NEW:
At the time of writing, SNMP SET is no longer recommended as a way to 
configure MPLS networks
as was described in [RFC3812].  However, since the MIBs specified in 
this document extend
and are intended to work in parallel with the MIB for MPLS specified in 
[RFC3812], certain objects
defined here are specified with MAX-ACCESS of read-write or read-create 
so that specifications
of the base tables in [RFC3812] and the extensions in this document are 
consistent. Although the
examples described in Section 9 specify means to configure MPLS-TP 
tunnels in a similar way to
the examples in [RFC3812], this should be seen as indicating how the MIB 
values would be returned
in the specified circumstances having been configured by alternative means.

Further responses are embedded below.

I see this draft has appeared on next week's IESG agenda.  If you can 
get me an updated snapshot
asap it would be helpful so I can do the telechat review as I am 
travelling next week.

Cheers,
Elwyn

> This MIB is intended to be used for MPLS-TP tunnels and is done by the way of extending existing MPLS-TE MIB. The assumption is that reader is already aware of MPLS-TP. Hence we didn’t provide a pr…
Sure.. Reading some of the earlier reviews there were some terms which 
were not very well defined.
The text below for para 2 of s1 gives enough background to help I think.
> We have deliberated over this topic for more than two years and after multiple discussions along with Routing AD and OPS AD, we decided to go forward with the writable objects for this MIB. Additio…
OK.. see notes at start.
> We could take help of English reviewers and request WG chairs to help us out in this regard.

Thanks Tom.. sorry I am a bit pushed for time as NFSv4 took up lots of 
tiem last week :-(
> Having said that, we are open to any suggested text, in addition to the one, which you already did below, in regards to ‘writable’ objects.
See above.
> MPLS-TE and other MPLS networks which is not constrained by transport requirements. Assuming some new tunnel type comes up into the future like bi-directional TE. :D
In that case I would just call it a "basic MPLS" network or some such.  
non-MPLS-TP is rather ambiguous.
> what is ‘LSP management protocol’?
I meant either RSVP or LDP or anything else that might be used 
dynamically.  Not sure what the generic term is these days.
> Thank you. Will go through the text again and replace as suggested.
OK.
> Haven’t come across any different types as such. Do you see any specific type which is of contrary to RFC 3812, that MPLS-TP defines? Will ask my co-authors as well.
I don't see anything obvious except that there might be some reason to 
declare a different
interface type rather than using type 150 defined in RFC 3812 especially 
for non-IP interfaces.
I am not sure how the ifSpeed field is used on bidirectional tunnels 
(that is also a point for RFC 3812).
Also whether the operational status could take on other values if one 
direction of the tunnel is
not working but the other is.

Otherwise it would be worth a statement that the interface table can be 
used as in RFC 3812 (or not) as appropriate.
> None that we are aware off.

There are three RowPointer type objects: mplsTunnelExtOppositeDirPtr and two in MplsXCExtEntry. Notes about consistent
use with the corresponding entries in the base tables would be desirable perhaps.

> I do not think there is a difference as such. We have provided example for non-ip case anyway.
For security???

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 12 Dec 2014 10:26:30 -0800

Hi Elwyn,

Appreciate your comments response to various questions or comments from me.

Will try to get them incorporated by today and send a version across to you. Will reply to comments, if any, later in the day.

Once Tom provides English review comments could incorporate them, later.

Thanks for your patience and much appreciated.

Cheers
Sam

Sent from my iPhone

> On Dec 12, 2014, at 6:40 AM, Elwyn Davies <[email-masked]> wrote:
> 
> Hi, Sam.
> 
> On the subject of SNMP write, I understand that agreement has been reached that the
> the MIB should effectively adopt the same position as RFC 3812, i.e. having read/write etc.
> objects and describing the use of the MIB for configuration in the examples.  I suggest that
> para 3 of s1 is rewritten to make this a bit clearer what the position is and also to explain
> what the phrase "as a way to provide the information model" means.  My suggestion...
> 
> OLD:
> It is understood that SNMP SET is not used for MPLS configuration these days, however the read-write and read-create option is still specified for some objects as a way to provide the information model.
> 
> NEW:
> At the time of writing, SNMP SET is no longer recommended as a way to configure MPLS networks
> as was described in [RFC3812].  However, since the MIBs specified in this document extend
> and are intended to work in parallel with the MIB for MPLS specified in [RFC3812], certain objects
> defined here are specified with MAX-ACCESS of read-write or read-create so that specifications
> of the base tables in [RFC3812] and the extensions in this document are consistent. Although the
> examples described in Section 9 specify means to configure MPLS-TP tunnels in a similar way to
> the examples in [RFC3812], this should be seen as indicating how the MIB values would be returned
> I see this draft has appeared on next week's IESG agenda.  If you can get me an updated snapshot
> asap it would be helpful so I can do the telechat review as I am travelling next week.
> 
> Cheers,
> Elwyn
> 
> 
> Sure.. Reading some of the earlier reviews there were some terms which were not very well defined.
> Thanks Tom.. sorry I am a bit pushed for time as NFSv4 took up lots of tiem last week :-(
> In that case I would just call it a "basic MPLS" network or some such.  non-MPLS-TP is rather ambiguous.
> I meant either RSVP or LDP or anything else that might be used dynamically.  Not sure what the generic term is these days.
> I don't see anything obvious except that there might be some reason to declare a different
> interface type rather than using type 150 defined in RFC 3812 especially for non-IP interfaces.
> I am not sure how the ifSpeed field is used on bidirectional tunnels (that is also a point for RFC 3812).
> Also whether the operational status could take on other values if one direction of the tunnel is
> Otherwise it would be worth a statement that the interface table can be used as in RFC 3812 (or not) as appropriate.

---

From: Tom Taylor <[email-masked]>
Date: Sat, 13 Dec 2014 23:42:50 -0500

Here's my markup. Not a lot of it, but scattered throughout the document 
including the MIB modules. I use LibreOffice, so the .docx file is a 
conversion. I trust it converted properly.

Tom Taylor

On 12/12/2014 9:40 AM, Elwyn Davies wrote:
>> This MIB is intended to be used for MPLS-TP tunnels and is done by the
>> way of extending existing MPLS-TE MIB. The assumption is that reader
>> is already aware of MPLS-TP. Hence we didn’t provide a primer for
>> MPLS-TP in this MIB and I am not sure if it is the right place either.
>>> and said that SNMP  was the only game in town even if security
>>> sucked.  As I mention below, this was extensively discussed a year
>>> ago but I couldn't determine whether this draft was given
>> We have deliberated over this topic for more than two years and after
>> multiple discussions along with Routing AD and OPS AD, we decided to
>> go forward with the writable objects for this MIB. Additionally we
>> added a small paragraph at the end of s1,  as recommended, the reason
>> for doing so.
> OK.. see notes at start.
>> Whether SNMP write should exist or not discussion is not within the
>> scope of this document. Whether this MIB should support writable MIB
>> objects was discussed and the conclusion was yes. The text at end of
>> s1 was added as recommended by AD’s. On the contrary, if this MIB were
>> to change the way RFC3813 is to implemented/interpreted along with the
>> MIB i.e. from writable for TE but read-only for non MPLS-TE tunnels,
>> then it should be documented.
>>
>> As noted above, the write option was retained after discussing at
>> length, both at the WG sessions and over emails. The statement in last
>> part of s1 was added as per the advice we received to move forward
>> with the writable objects [ref: email from OPS AD dated Mar 11 on MPLS
>> mailing list]. The main reason for writable objects, is because the
>> MPLS-TE had writable objects and MPLS-TP extensions leverage this
>> existing MIB and also few vendors have implemented them.
>>
>> Having said that, we are open to any suggested text, in addition to
>> the one, which you already did below, in regards to ‘writable’ objects.
> See above.
>>> Minor issues:
>> MPLS-TE and other MPLS networks which is not constrained by transport
>> requirements. Assuming some new tunnel type comes up into the future
>> like bi-directional TE. :D
>>> As described in the MPLS Traffic Engineering (TE) Management
>>> Information Base (MIB) definition [RFC3812], MPLS traffic engineering
>>> is concerned with the
>>> The existing MPLS TE MIB [RFC3812] and the Generalized Multiprotocol
>>> Label Switching (GMPLS) Traffic Engineering Management Information
>>> Base [RFC4802] address only a subset of the
>> Haven’t come across any different types as such. Do you see any
>> specific type which is of contrary to RFC 3812, that MPLS-TP defines?
>> Will ask my co-authors as well.
> There are three RowPointer type objects: mplsTunnelExtOppositeDirPtr and
> two in MplsXCExtEntry. Notes about consistent

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 14 Dec 2014 08:50:00 -0800

Hi Elwyn and Tom,

Thank you so much for you kind review and comments. 
I have included almost all of them, except for few. For the comments which couldn’t be addressed, reason is provided as below.
Sending it as attachment for now. If I do not hear any major concerns, will check this version later in the day.

 Sorry for the top post. Here are some comments.

1. In the text provided by Elwyn, there was the usage of term ERLSP. As this was not really used in the context of MPLS-TP, specifically in the RFC’s, we did’t want to include in this draft. Hence, just retained the text as ‘lsp’.
2. Comment regarding iftype, it was retained as 150 itself. This was done along the lines of GMPLS. ifspeed and operational state could be considered per direction of interface/tunnel.
3. ’Sparse’ is very much used in MIB and is explicitly identified. We also added this after we received the comment as part of AD review (Ref: Dec 28 2013) that, we didn’t clearly identify ‘sparse’ auguments.
4. Regard ‘non-ip’ security, which in this case could be ICC type. Not sure of what could be added and the identifier RFC 6923 left it for protocol implementers, which in this case will be SNMP and should be covered as part of its security, correct?
5. Edited ‘security’ section, referenced RFC3812 and removed duplicated text.
6. Changed structure to reflect RFC3812. i.e. sec 6.
6. Incorporated English review comments from Tom.

Hope these addresses all the received comments. If I have overlooked any, kindly let me know.

Thank you again and appreciate your help very much.

-sam

> On Dec 13, 2014, at 8:42 PM, Tom Taylor <[email-masked]> wrote:
> 
> Here's my markup. Not a lot of it, but scattered throughout the document including the MIB modules. I use LibreOffice, so the .docx file is a conversion. I trust it converted properly.
> 
> Tom Taylor
> 
> <Marked-up mpls-tp-te-mib.docx>

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 14 Dec 2014 19:29:21 +0000

> 1. In the text provided by Elwyn, there was the usage of term ERLSP. As this was not really used in the context of MPLS-TP, specifically in the RFC’s, we did’t want to include in this draft. Hence,…
OK
> 2. Comment regarding iftype, it was retained as 150 itself. This was done along the lines of GMPLS. ifspeed and operational state could be considered per direction of interface/tunnel.
Using 150 again is fine.. Saying explicitly that you are doing would be 
helpful.
> 3. ’Sparse’ is very much used in MIB and is explicitly identified. We also added this after we received the comment as part of AD review (Ref: Dec 28 2013) that, we didn’t clearly identify ‘sparse’…
I read that comment as saying the same thing as me (i.e., the wrong 
word).  Be that as it may, "sparse" really isn't the right word - it 
just sounds wrong to my ear.  The main dictionary definition is " thinly 
dispersed or scattered." .  As I said previously "limited" or "slight" 
would be (IMO) better if you feel it is necessary but in most of the 
cases the text would not be damaged by leaving it out altogether.  Now 
it is (almost) a standard, whether it is limited or sparse or anything 
else is moot - implementers just have to get on with it!
> 4. Regard ‘non-ip’ security, which in this case could be ICC type. Not sure of what could be added and the identifier RFC 6923 left it for protocol implementers, which in this case will be SNMP and…
Having had a look at RFC 6370, the last para of the security 
considerations states:
>     Protocol specifications that utilize the identifiers defined herein
>     need to consider the implications of guessable identifiers and, where
>     there is a security implication, SHOULD give advice on how to make
>     identifiers less guessable.
If I am not mistaken this draft effectively tells you how to set up 
MPLS-TP tunnels with ICC identifiers , (although of course it won't be 
used for that ;-)  ).  I think maybe this needs a few words about making 
sure you can't guess the identifiers and what would be the result (and 
how to mitigate it) if you did use the MIB to set up tunnels.
> 5. Edited ‘security’ section, referenced RFC3812 and removed duplicated text.
OK
> 6. Changed structure to reflect RFC3812. i.e. sec 6.
I don't think this completely solved the problem.  The table definitions 
now in 6.1.2 et seq are part of the MPLS-TE-EXT-STD-MIB.  To make the 
description of MIB modules complete there should be a new 6.2 that 
describes MPLS-TE-EXT-STD-MIB and the table descriptions should (I 
think) be subsections of 6.2 rather than the summary as they are objects 
in MPLS-TE-EXT-STD-MIB.
> 7. Incorporated English review comments from Tom.
OK
> Thank you again and appreciate your help very much.

Couple of nits:
Tom's updates: s/Textual/textual/g

General: s/uni-directional/unidirectional/g (for consistency - should 
have picked that up!)

s4, last para: s/This document defines four new MIB modules/This 
document defines four additional MIB modules/; s/new MIB 
modules/additional MIB modules/  [My mistake: Using "new" in this 
context is not history-proof! After a while they aren't new - and some 
AD is bound to pick me up on it!]

Otherwise I think we pretty much done.

Cheers,
Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 14 Dec 2014 19:31:25 +0000

OK
OK
OK

Couple of nits:

Cheers,
Elwyn
>
>
>> On Dec 13, 2014, at 8:42 PM, Tom Taylor<[email-masked]>  wrote:
>>
>>>>> On Dec 11, 2014, at 10:36 AM, Elwyn Davies<[email-masked]>  wrote:
>>>>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Dec 2014 19:37:33 -0000

Hi, reading out of context...
 
"Sparse augmentation" is a term of art for MIB modules.
It means that the table rows are not augmented 1:1. Only those rows that are wanted to be augmented, are augmented.
 
A
 
From: Elwyn Davies [mailto:[email-masked]] 
Sent: 14 December 2014 19:29
To: Sam Aldrin; Tom Taylor
Cc: [email-masked]; General area reviewing team; <[email-masked]>
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-te-mib-09
 
3. ’Sparse’ is very much used in MIB and is explicitly identified. We also added this after we received the comment as part of AD review (Ref: Dec 28 2013) that, we didn’t clearly identify ‘sparse’ auguments.
I read that comment as saying the same thing as me (i.e., the wrong word).  Be that as it may, "sparse" really isn't the right word - it just sounds wrong to my ear.  The main dictionary definition is " thinly dispersed or scattered." .  As I said previously "limited" or "slight" would be (IMO) better if you feel it is necessary but in most of the cases the text would not be damaged by leaving it out altogether.  Now it is (almost) a standard, whether it is limited or sparse or anything else is moot - implementers just have to get on with it!

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 15 Dec 2014 01:19:35 +0000

OK.  Sorry - that one had passed me by.

Thanks Adrian for putting me straight.

I'll shut up about sparse.

/E

On 14/12/14 19:37, Adrian Farrel wrote:
> It means that the table rows are not augmented 1:1. Only those rows 
> that are wanted to be augmented, are augmented.
>
> A
>
> *From:*Elwyn Davies [mailto:[email-masked]]
> *Sent:* 14 December 2014 19:29
> *To:* Sam Aldrin; Tom Taylor
> *Cc:* [email-masked]; General area 
> reviewing team; <[email-masked]>
> *Subject:* Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-te-mib-09
>
> just sounds wrong to my ear.  The main dictionary definition is " 
> thinly dispersed or scattered." .  As I said previously "limited" or 
> "slight" would be (IMO) better if you feel it is necessary but in most 
> of the cases the text would not be damaged by leaving it out 
> altogether.  Now it is (almost) a standard, whether it is limited or 
> sparse or anything else is moot - implementers just have to get on 
> with it!
>

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 14 Dec 2014 19:19:32 -0800

[Resending as the message reached max size]

Hi Elwyn,

Thanks again.

Comments inline. 
Also attached txt and diff files. We plan to commit the updated ID in few hours. Hope this version address all the comments received thus far.

> On Dec 14, 2014, at 11:29 AM, Elwyn Davies <[email-masked]> wrote:
> 
> Using 150 again is fine.. Saying explicitly that you are doing would be helpful.
Done.
> I read that comment as saying the same thing as me (i.e., the wrong word).  Be that as it may, "sparse" really isn't the right word - it just sounds wrong to my ear.  The main dictionary definition…
Resolved over email.
> Having had a look at RFC 6370, the last para of the security considerations states:
> If I am not mistaken this draft effectively tells you how to set up MPLS-TP tunnels with ICC identifiers , (although of course it won't be used for that ;-)  ).  I think maybe this needs a few words about making sure you can't guess the identifiers and what would be the result (and how to mitigate it) if you did use the MIB to set up tunnels.
Added new text. 
> I don't think this completely solved the problem.  The table definitions now in 6.1.2 et seq are part of the MPLS-TE-EXT-STD-MIB.  To make the description of MIB modules complete there should be a new 6.2 that describes MPLS-TE-EXT-STD-MIB and the table descriptions should (I think) be subsections of 6.2 rather than the summary as they are objects in MPLS-TE-EXT-STD-MIB.
Changed. Hope it is ok now.
> General: s/uni-directional/unidirectional/g (for consistency - should have picked that up!)
> 
> s4, last para: s/This document defines four new MIB modules/This document defines four additional MIB modules/; s/new MIB modules/additional MIB modules/  [My mistake: Using "new" in this context is not history-proof! After a while they aren't new - and some AD is bound to pick me up on it!]
> 
made the above changes.

thanks
-sam

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 15 Dec 2014 08:11:43 +0000

On 15/12/14 03:08, Sam Aldrin wrote:
> Hi Elwyn,
>
> Thanks again.
>
> Comments inline.
> Also attached txt and diff files.
>
Hi, Sam.

<Snipping all the history>

Thanks for all the work on this and apologies for the lack or 
understanding around 'sparse'.

I think you are good to go on this version as far as my issues were 
concerned.

Cheers,
Elwyn

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 15 Dec 2014 00:14:30 -0800

Thanks, Elwyn, much appreciated for all the help.
Thanks to Tom as well.

cheers
-sam
> On Dec 15, 2014, at 12:11 AM, Elwyn Davies <[email-masked]> wrote:
> 
> Thanks for all the work on this and apologies for the lack or understanding around 'sparse'.
> 
> I think you are good to go on this version as far as my issues were concerned.
> 
> Cheers,
> Elwyn

---

From: Tom Taylor <[email-masked]>
Date: Mon, 15 Dec 2014 20:32:29 -0500

> On 14/12/14 16:50, Sam Aldrin wrote:
...
>> 3. ’Sparse’ is very much used in MIB and is explicitly identified. We
>> also added this after we received the comment as part of AD review
>> (Ref: Dec 28 2013) that, we didn’t clearly identify ‘sparse’ auguments.

"Sparse" is a term of art -- see RFC 4181 Section 4.6.4, first bulklet.

Tom

...

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Dec 2014 08:21:03 -0500

Elwyn - many thanks for your review, and thanks to everyone else on working on this…

I have placed a no-obj ballot position for this document.

Jari