Subject: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

From: Greg Mirsky <[email-masked]>
Date: Sun, 12 Nov 2017 21:58:09 +0800

Dear All,
I was under impression that that question of oam-neighboring-tps has been
discussed and since authors couldn't produce technical rationale for this
object we've agreed that it will be removed altogether from the grouping
connectionless-oam-tps. But authors just changed name from level to
position but had missed to synchronize descriptions in the model and in
section 3.3. The later still refers to vertical layers:

                     "List of related neighboring test points in adjacent
                     layers up and down the stack for the same interface
                     that are related to the current test point.";

while the model insists that it is peering relationship:

        description
          "The relative position
           of neighboring test point
           corresponding to the current
           test point. Level 0 indicates no neighboring
           test points placed before or after the current

           test point in the same layer.-1 means there is
           a neighboring test point placed before the current
           test point in the same layer and +1 means there is
           a neighboring test point placed after the current
           test point in same layer.";

So, what is it? Perhaps it is time to remove list oam-neighboring-tps
altogether also because having it s fixed size list is plain wrong. (Sorry
for being so blunt but I commented too many times on the same to no avail
from the authors).

Regards,
Greg

On Thu, Oct 26, 2017 at 9:26 AM, Qin Wu <[email-masked]> wrote:

> Thanks Greg, will consider that.
>
>
>
> -Qin
>
> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2017年10月25日 20:55
> *收件人:* Qin Wu
> *抄送:* [email-masked]; [email-masked];
> Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise;
> [email-masked]
> *主题:* Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt>
> (Generic YANG Data Model for Connectionless Operations, Administration, and
> Maintenance(OAM) protocols) to Proposed Standard
>
>
>
> Hi Qin,
>
> thank you for your thoughtful consideration of my comments.
>
> I agree to leave mechanism of overrun indication to implementation but I
> believe that it will be really helpful to add a sub-section that highlights
> specific of running tests in forever mode and points to issues that require
> particular attention.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Oct 24, 2017 at 8:06 PM, Qin Wu <[email-masked]> wrote:
>
> Thanks Greg for feedback, please see my reply inline below.
>
> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2017年10月24日 23:18
> *收件人:* Qin Wu
> *抄送:* [email-masked]; [email-masked];
> Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise;
> [email-masked]
>
> *主题:* Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt>
> (Generic YANG Data Model for Connectionless Operations, Administration, and
> Maintenance(OAM) protocols) to Proposed Standard
>
>
>
> Hi Qin,
>
> thank you for your expedient and careful consideration of my comments. I'm
> glad that we've already in agreement on so many. I've added notes on those
> that, in my view, need some more discussions. Please find them in-line
> tagged GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Oct 22, 2017 at 8:31 PM, Qin Wu <[email-masked]> wrote:
>
> Thanks Greg for providing additional input to help make the model more
> extensible and reusable.
>
> Please see my reply inline below.
>
>
>
> -Qin
>
> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2017年10月20日 20:34
> *收件人:* [email-masked]; [email-masked]
> *抄送:* Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise;
> [email-masked]
> *主题:* Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt>
> (Generic YANG Data Model for Connectionless Operations, Administration, and
> Maintenance(OAM) protocols) to Proposed Standard
>
>
>
> Dear All,
>
> please kindly consider my comments on draft-ietf-lime-yang-connectionless-oam
> presented below:
>
>    - 1. Introduction
>
>
>    - clear and technical definitions of connection-oriented (CO) and
>       connectionless (CL) network are absent. Note that referenced RFC 7276 does
>       not provide that either as differentiation based on amount of configuration
>       required to instantiate a network changes, decreases as result of further
>       progress in network operation automation. I propose to use definitions CO
>       and CL forwarding paradigms provided in section 6.3.1 G.800 Unified
>       functional architecture of transport networks, as these are clear,
>       technical and are broadly used in the industry.
>
> [Qin]: I believe RFC7276 and G.800 share the similar paradigms but capture
> the different aspect of the key difference between CO and CL, I would
> suggest to harmonize the different aspect of these key differences together
> and add another reference to G.800 as follows:
>
> NEW TEXT:
>
> “
>
> In connection-oriented technologies,
>
>    a connection is established prior to the transmission of data.  After
>
>    connection is established, no additional control information such as
>
>    signaling or operations and maintenance information is required to
>
>    transmit the data.  In connectionless technologies, data is
>
>    typically sent between end points without prior arrangement, but
>
>    control information is required to identify destination
> [G.800][RFC7276].
>
> ”
>
> GIM>> If we consider, for example, MPLS-TP domain and L3VPN over IP/MPLS
> domain, then the configuration aspect, in my opinion, becomes less distinct
> while the forwarding paradigm is invariant, remains the same.
>
>
>
> [Qin]: Thanks.
>
>
>    - characterization of the subject of the document as "YANG Data model
>       for connectionless OAM protocols" is not accurate considering CO/CL
>       definitions in G.800. I propose to refer to "OAM protocols for
>       connectionless networks" since the same OAM protocols may be used in both
>       CO-PS and CL-PS networks, e.g. LSP Ping used in both MPLS-TP and IP/MPLS
>       networks.
>
>       [Qin]: Okay ,Sounds good to me.
>
>    - 3. Overview of the Connectionless OAM Model
>
>
>    - "... the 'test-point-location-info', is a common aspect of every
>       'test-point-location' - there's no YANG object test-point-location in the
>       presented data model.
>
>    [Qin]: It is Typo. It should be ‘test-point-locations’, fixed. Thanks.
>
>    - 3.3 OAM Neighboring Layers
>
>
>    - I find this part of the model under-developed. First, the
>       terminology - layers imply vertical, client-server relationship while
>       downstream/upstream - peering relationship on the same layer. Second, the
>       limited visibility due to technology-level limitation that supports only
>       reference to the immediate neighboring layer but not to next-to-next
>       neighbor. I consider this to be major problem for common model that
>       intended for multi-layer environment.
>
> [Qin]: We discussed this before, I revisit this section and understand
> your concern now , I would like to suggest to remove layer related text
> since it introduce confusion, I would suggest to change technology-level
> into position since what we try to define are OAM Neighboring Test points
> list. We will focus on test points related to one single layer. One can use
> position to capture of order of these test points and also identify test
> point at the left layer boundary and test point at the right layer
> boundary. The proposed changes as follows:
>
> “
>
> 3.3.  OAM neighboring test points
>
>
>
>    As typical networks have a multi-layer architecture, the set of OAM
>
>    protocols similarly take a multi-layer structure; each layer may has
>
>    its own OAM protocol [RFC7276] and is corresponding to specific
>
>    administrative domain and has associated test points.  OAM
>
>    neighboring test points are referred to a list of neighboring test
>
>    points in the same layer that are related to current test point.
>
>    This allows users to easily navigate between related neighboring
>
>    layer to efficiently troubleshoot a defect.  In this model,
>
>    'position' leaf defines the relative position of neighboring test
>
>    point corresponding to the current test point in the same layer , and
>
>    is provided to allow correlation of faults at different location . If
>
>    there is one neighboring test point placed before the current test
>
>    point, 'position' leaf is set to -1.  If there is one neighboring
>
>    test point placed after the current test point, 'position' leaf is
>
>    set to 1.  If there is no neighboring test point placed before or
>
>    after the current test point, 'position' leaf is set to 0.
>
>
>
>                 list oam-neighboring-tps {
>
>                   key "index";
>
>                   leaf index {
>
>                      type uint16 {
>
>                         range "0..65536";
>
>                      }
>
>                     description
>
>                      "Index of a list of neighboring test points
>
>                       in the same layer ";
>
>                   }
>
>                   leaf position {
>
>                       type int8 {
>
>                            range "-1..1";
>
>                       }
>
>                       description
>
>                         "The relative position
>
>                         of neighboring test point
>
>                         corresponding to the current
>
>                         test point";
>
>                   }
>
>                   description
>
>                      "List of related neighboring test points in the same
> layer.";
>
>               }
>
> ”
>
> GIM>> I think that if we concentrate on OAM on particular network layer,
> then reference to multi-layer character of modern networks is unnecessary
> and somewhat artificial. As for test points in the same layer, then
> traceroute suppose to return ordered list of Test Points between the Sender
> and Receiver. Because there could be ECMP sub-domains along the path, model
> should be able to differentiate with some entropy key. OAM visibility into
> other administrative domains obviously brings security consideration issues
> and, I'd expect, be carefully controlled and try to hide identity of the
> domain. Hence, I think that 'position' is hardly usable parameter.
>
>
>
> [Qin]: Thanks for your comments on this, yes recording test point list in
> the same layer is not good use case, harmonizing with your comments and
> Gen-art review comments, we have removed same layer and rewrite this
> section based on Gen-art reviewer’s input and suggestions. Thanks again.
>
>
>    - 3.4 Test Point Locations Information
>
>
>    - reference to non-existent "tp-tool" and "OAM-neighboring Layers"
>        groupings
>
>              [Qin]: It is typo, oam-neighboring layers should be corrected
> as “oam-neighboring-tps” now.
>
>    - 4. YANG OAM Model
>
>
>    - I think that use of prefix 'coam' for data model of OAM in
>       connectionless networks is limiting considering that there should be
>       another model of OAM in connection-oriented networks. Acronyms CL and CO
>       usually used to refer to connectionless and connection-oriented networks
>       respectively. Thus I suggest to use 'cl-oam' as prefix for the data model
>       presented in this document and 'co-oam' instead of 'goam'
>       in draft-ietf-lime-yang-connection-oriented-oam-model.
>
>                 [Qin]:Good proposal, I like it.
>
>    - I find time-resolution to be superfluous and thus overcomplicating
>       the model. I suggest use time-interval-type instead and consider
>       for the update of yang:ietf-yang-types defined in RFC 6991.
>
>               [Qin]:  Time resolution is referred to time unit, sure we
> can change it into time-interval-type as you suggested.
>
> o    session-delay-statistics and session-jitter-statistics are too limiting in many dimensions - no support to reflect one-way (far-end and near-end) and round-trip measurements for the same test session, and too few metrics., e.g. no report of percentile.
>
>              [Qin]: We have protocol-id and protocol-id-meta-data to be defined in draft-ietf-lime-yang-connectionless-oam-methods-09 which can be used to indicate whether it is one way measurement, or two way
>
> measurements. Please see my reply for loss ration for report of percentile.
>
> o    session-delay-statistics does not reflect type of delay variation being calculated. As analyzed in RFC 5481, PDV and IPDV characterize different conditions (Section 5) and at least reflecting which one being calculated and reported is very informative.
>
>                 [Qin]: We have protocol-id and protocol-id-meta-data to be defined in draft-ietf-lime-yang-connectionless-oam-methods-09 which can be used to indicate whether IPDV is used or PDV is used, Based on Brian’s
>
>    suggestion, we could set IPDV as default for jitter measurement.
>
> o    I cannot find anything that directly reports packet loss statistics (packet loss and packet loss ratio) for the given test session. Is that intentional? ICMP ping is capable to report number of lost packets in round-trip.
>
>               [Qin]: We do have a parameter ‘packet-drops-count’ for packet-loss, we can change it into “packet-loss-count” as you suggested, in addition, we can add a new parameter for packet loss ration as follows:
>
> “
>
>       leaf packet-loss-count {
>
>         type uint32 {
>
>         range "0..4294967295";
>
>         }
>
>        default "0";
>
>         description
>
>           "Total received packet drops count.
>
>           If the value is 4294967295, it indicates
>
>           packet drops count is overrun.";
>
>       }
>
>
>
>           leaf loss-ratio{
>
>                         type uint8{
>
>                                 range 0..100;
>
>                         }
>
>                 description
>
>                  "Loss ratio of the packets. Express as percentage
>
>                  of packets lost with respect to packets sent.";
>
>                 }
>
>
>
> ”
>
> GIM>> Packet loss and, as result, loss ratio in modern networks is very
> low. I suggest changing loss-ratio type from uint8 to new type percentage,
> defined as:
>
>    typedef percentage {
>
>         type decimal64 {
>
>                 fraction-digits 5;
>
>         }
>
>         description "Percentage";
>
>    }
>
>
>
> [Qin]: Good proposal, accepted.
>
>  GIM>> I think that counter overrun case indicator requires separate
> parameter. Using 4294967295 may produce negative false when running in
> forever mode.
>
>
>
> [Qin]: Note that counter  is unsigned integer, it will not produce
> negative false, in my understanding. I doubt we should add such complexity
> to data model by introducing another parameter, we can leave this to
> implementation details.
>
>
>
>
>
> o    using uint32 in session-packet-statistics seems risking overrun of counters especially for test sessions running  forever.
>
> [Qin]: Good point, we could set up-limit for session-packet-statistics data, if statistics data reach up-lmit, it wil indicate counter overrun happens.
>
> o    I believe that using 0 to indicate that the parameter is not being reported, throughout several statistics groupings, creates problem when the true value is 0, e.g. rx-bad-packet;
>
> [Qin]:Good point, we will remove to use 0 to indicate the parameter is not being reported.
>
> o    connectionless-oam-layers - what considerations were discussed to arrive to liming number of neighboring test points to 128?
>
> [Qin]: Okay, we can change uint8 into uint16 to support more test points that can be recorded. But please note that each test point actually only record his neighboring test points, if each test points record a complete
>
> List of test points in one test, that will result in a lot of duplicated data associated with each test point.
>
> o    tp-tools:continuity-check you may add RFC 8029 to the list of references
>
> [Qin]: Accepted, thanks.
>
> o    tp-tools:path-discovery RFC 8029 obsoletes RFC 4379 as standard for LSP Ping
>
> [Qin]: Accepted, thanks.
>
> o    timestamp grouping is limited to PTPv2 Truncated and NTPv4 64-bit format [RFC5905]. What about other formats, e.g. ICMP Timestamp, NTPv4 32-bit, a.k.a. short, or PTPv2 80-bits long?
>
> [Qin]: Here is the proposed change to address your comments:
>
> “
>
>   grouping timestamp {
>
>     description
>
>       "Grouping for timestamp.";
>
>     leaf timestamp-type {
>
>       type identityref {
>
>       base timestamp-type;
>
>       }
>
>       description
>
>         "Type of Timestamp, such as Truncated PTP, NTP.";
>
>     }
>
>     container timestamp-64bit {
>
>         when "derived-from-or-self(../type, 'cl-oam:truncated-ptp')"+
>
>        "or derived-from-or-self(../type,'cl-oam:ntp64')" {
>
>          description
>
>           "Only applies when Truncated NTP or 64bit NTP Timestamp.";
>
>         }
>
>       leaf timestamp-sec {
>
>       type uint32;
>
>       description
>
>         "Absolute timestamp in seconds as per IEEE1588v2
>
>          or seconds part in 64-bit NTP timestamp.";
>
>        }
>
>       leaf timestamp-nanosec {
>
>       type uint32;
>
>       description
>
>         "Fractional part in nanoseconds as per IEEE1588v2
>
>          or Fractional part in 64-bit NTP timestamp.";
>
>       }
>
>       description
>
>       "Container for 64bit timestamp.";
>
>     }
>
>     container timestamp-80bit {
>
>         when "derived-from-or-self(../type, 'cl-oam:ptp80')"{
>
>          description
>
>           "Only applies when 80bit PTP Timestamp.";
>
>         }
>
>           if-feature ptp-long-format;
>
>       leaf timestamp-sec {
>
>       type uint64 {
>
>      range "0..281474976710656";
>
>       }
>
>       description
>
>         "48bit Timestamp in seconds as per IEEE1588v2.";
>
>        }
>
>       leaf timestamp-nanosec {
>
>       type uint32;
>
>       description
>
>         "Fractional part in nanoseconds as per IEEE1588v2
>
>          or Fractional part in 64-bit NTP timestamp.";
>
>       }
>
>       description
>
>       "Container for 64bit timestamp.";
>
>     }
>
>        container ntp-timestamp-32bit {
>
>         when "derived-from-or-self(../type, 'cl-oam:truncated-ntp')"{
>
>          description
>
>           "Only applies when 32 bit NTP Short format Timestamp.";
>
>         }
>
>           if-feature ntp-short-format;
>
>       leaf timestamp-sec {
>
>       type uint16;
>
>       description
>
>         "Timestamp in seconds as per short format NTP.";
>
>        }
>
>       leaf timestamp-nanosec {
>
>       type uint16;
>
>       description
>
>         "Truncated Fractional part in 16-bit NTP timestamp.";
>
>       }
>
>       description
>
>       "Container for 64bit timestamp.";
>
>     }
>
>      container icmp-timestamp-32bit {
>
>         when "derived-from-or-self(../type, 'cl-oam:icmp-ntp')"{
>
>          description
>
>           "Only applies when Truncated NTP or 64bit NTP Timestamp.";
>
>         }
>
>           if-feature icmp-timestamp;
>
>       leaf timestamp-millisec {
>
>       type uint32;
>
>       description
>
>         "timestamp in milliseconds for ICMP timestamp.";
>
>        }
>
>       description
>
>       "Container for 32bit timestamp.";
>
>     }
>
>   }
>
>
>
> ”
>
>
>    - 5.1.1.2 Test point attributes extension
>
>
>    - reference to non-existing "test-point-location" list
>
> [Qin]: Same typo as you mentioned above, it should be “
> test-point-locations”.
>
>    - 5.1.2 Schema Mount
>
>
>    - reference to non-existing "test-point-location" list
>
> [Qin]: Same as above, fixed.
>
>    - 5.2.1.2 Test point attributes extension
>
>
>    - reference to non-existing "test-point-location" list
>
> [Qin]: Same as above, fixed.
>
>    - 5.2.2 Schema Mount
>
>
>    - reference to non-existing "test-point-location" list
>
> [Qin]: Same as above, fixed.
>
> In summary, I find several serious issues with the current version of the
> data model presented in the document, e.g. use of 0 to indicate unreported
> parameter and underdeveloped layering model.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Wed, Oct 11, 2017 at 6:40 AM, The IESG <[email-masked]> wrote:
>
>
> The IESG has received a request from the Layer Independent OAM Management
> in
> the Multi-Layer Environment WG (lime) to consider the following document: -
> 'Generic YANG Data Model for Connectionless Operations, Administration,
>    and Maintenance(OAM) protocols'
>   <draft-ietf-lime-yang-connectionless-oam-11.txt> 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
> [email-masked] mailing lists by 2017-10-25. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document presents a base YANG Data model for connectionless
>    Operations Administration, and Maintenance(OAM) protocols.  It
>    provides a technology-independent abstraction of key OAM constructs
>    for connectionless protocols.  The base model presented here can be
>    extended to include technology specific details.  This is leading to
>    uniformity between OAM protocols and support both nested OAM
>    workflows (i.e., performing OAM functions at different or same levels
>    through a unified interface) and interacting OAM workflows ( i.e.,
>    performing OAM functions at same levels through a unified interface).
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-
> connectionless-oam/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
>
>
>
>
>
>
>
>
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 27 Nov 2017 23:40:10 +0100

Hello Greg,

I agree with you that the current (version 18) text in section 3.3
is very confusing.

Authors:

If I look at the definition of TP in section 2.2 I think a TP is
similar

to a maintenance point as defined for Ethernet. Am I correct?

I don't understand why there are TPs with no neighboring TPs,

where will their initiated OAM test be sent? Or where are OAM

tests they react to initiated?

It is IMHO also possible that there are TPs with a neighboring

TP before AND a neighboring TP after the current TP.

Please explain.

Regards, Huub.

---------

Dear All,

I was under impression that that question of oam-neighboring-tps has been
discussed and since authors couldn't produce technical
rationale for this object we've agreed that it will be
removed altogether from the grouping
connectionless-oam-tps. But authors just changed name from
level to position but had missed to synchronize descriptions
in the model and in section 3.3. The later still refers to
vertical layers:

description
"The relative position

So, what is it? Perhaps it is time to remove list oam-neighboring-tps
altogether also because having it s fixed size list is plain
wrong. (Sorry for being so blunt but I commented too many
times on the same to no avail from the authors).

Regards,

Greg

--
================================================================
Always remember that you are unique...just like everyone else...

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Nov 2017 08:36:35 +0100

Huub,

For your information, the document is now in the RFC editor queue, ready 
to be published.
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/

Regards, Benoit
> Hello Greg,
>
> I agree with you that the current (version 18) text in section 3.3 is 
> very confusing.
>
> Authors:
>
> If I look at the definition of TP in section 2.2 I think a TP is similar
>> I was under impression that that question of oam-neighboring-tps has 
>> been discussed and since authors couldn't produce technical rationale 
>> for this object we've agreed that it will be removed altogether from 
>> the grouping connectionless-oam-tps. But authors just changed name 
>> from level to position but had missed to synchronize descriptions in 
>> the model and in section 3.3. The later still refers to vertical layers:
>> altogether also because having it s fixed size list is plain wrong. 
>> (Sorry for being so blunt but I commented too many times on the same 
>> to no avail from the authors).
>>
>> Regards,
>> Greg
>
>
> -- 
> .

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 28 Nov 2017 11:21:42 +0100

Hello Benoit,

You reply:

For your information, the document is
now in the RFC editor queue, ready to be published.

I had not seen any response from the authors to the email from Greg

(I checked the archive) so I assumed that the issue was still being

discussed.

Other on-line comments were addressed by the authors.

I also checked for updates to version 18, but did not find any, so I

don't know how the issue has been resolved.

So now I have to wait until the RFC is published.

Regards, Huub.

=========

Hello Greg,

I agree with you that the current (version 18) text in section
3.3 is very confusing.

Authors:

If I look at the definition of TP in section 2.2 I think a TP
is similar

Please explain.

Regards, Huub.

---------

Dear All,

I was under impression that that question of oam-neighboring-tps has been
discussed and since authors couldn't produce technical
rationale for this object we've agreed that it will be
removed altogether from the grouping
connectionless-oam-tps. But authors just changed name
from level to position but had missed to synchronize
descriptions in the model and in section 3.3. The later
still refers to vertical layers:

while the model insists that it is peering
relationship:

description
"The relative position

So, what is it? Perhaps it is time to remove list oam-neighboring-tps
altogether also because having it s fixed size list is
plain wrong. (Sorry for being so blunt but I commented
too many times on the same to no avail from the
authors).

Regards,

Greg

.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 28 Nov 2017 12:04:52 +0000

Hello, Huub,

Additionally, please see https://www.ietf.org/rfcdiff?url1=draft-ietf-lime-yang-connectionless-oam-17&url2=draft-ietf-lime-yang-connectionless-oam-18, which shows the changes relevant to that specific comment.

I believe the authors are using text suggested by Greg.

Like Benoit said, the document is approved and in the RFC Editor queue:
https://mailarchive.ietf.org/arch/msg/lime/qyhKwFkE4VB9HA0S04tOWPDFK9Q

Best,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Nov 28, 2017, at 5:21 AM, Huub van Helvoort <[email-masked]<mailto:[email-masked]>> wrote:

Hello Benoit,

You reply:
For your information, the document is now in the RFC editor queue, ready to be published.

Regards, Huub.

=========

Hello Greg,

I agree with you that the current (version 18) text in section 3.3 is very confusing.

Authors:

Please explain.

Regards, Huub.

---------

Dear All,
I was under impression that that question of oam-neighboring-tps has been discussed and since authors couldn't produce technical rationale for this object we've agreed that it will be removed altogether from the grouping connectionless-oam-tps. But authors just changed name from level to position but had missed to synchronize descriptions in the model and in section 3.3. The later still refers to vertical layers:

        description
          "The relative position

So, what is it? Perhaps it is time to remove list oam-neighboring-tps altogether also because having it s fixed size list is plain wrong. (Sorry for being so blunt but I commented too many times on the same to no avail from the authors).

Regards,
Greg

.

---

From: Qin Wu <[email-masked]>
Date: Thu, 30 Nov 2017 05:55:09 +0000

Nice to hear from Tissa, same wish for you. Thanks Greg in Singapore to help address last comment together, also thanks Greg a lot of inputs to this work all along the way. Appreciated as well.
I should have sent a note out earlier during busy IETF week, sorry about that.

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年11月30日 13:18
收件人: Tissa Senevirathne
抄送: [email-masked]; Carlos Pignataro (cpignata); [email-masked]; Ronald P. Bonica; [email-masked]; The IESG; Benoit Claise (bclaise); [email-masked]; Qin Wu; [email-masked]
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Hi Tissa,
thank you for your kind words, much appreciated. Wish you all success in your endeavors and hope you'll find opportunity to return to IETF work sooner than later.

Best regards,
Greg

On Wed, Nov 29, 2017 at 2:40 PM, Tissa Senevirathne <[email-masked]<mailto:[email-masked]>> wrote:
I have been out of IETF for a while but still receives LIME WG emails.

As the original author of the connectionless draft I deliberately avoided making any comments as I do not have adequate time to do a good job.

However, I have been reading, with great respect, the comments Greg Mirsky was making to make these drafts better both technically and editorially. I want to extend a well deserved thank you to Greg. Thank You Greg.

Also I do not agree with Carlos comments on Hubbs observations, i.e. Oh Draft is in IETF editors queue and it is too late. May be time to pull it out from the queue or create errata if the changes are significant enough.

If either of these happens I do like to suggest two things

1. Appoint an editor who can shepherd edits and presentation aspects of the draft
2. Provide adequate time and be transparent to share with the WG on what is agreed or appoint a technical panel

On Wed, Nov 29, 2017 at 12:39 PM, Huub van Helvoort <[email-masked]<mailto:[email-masked]>> wrote:
Hello Carlos,

Thank you for the additional information.

As I mentioned I already looked at version 18 because that was mentioned
in Gregs response.

I have understood that this draft was discussed in Singapore.
Unfortunately the agreed resolution was not reported on the list.
That is why I missed (part of) the discussion.

I will have no further comments.

Best regards, Huub.

-----------

Best,

—

Hello Benoit,

You reply:

Regards, Huub.

=========

Hello Greg,

Authors:

Please explain.

Regards, Huub.

---------
Dear All,

        description

          "The relative position

Regards,
Greg

--

_______________________________________________
Lime mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Nov 2017 21:06:50 +0000

Dear Huub,

Thanks for the response – glad to see this loop is closed.

Best,

-- Carlos.

From: Huub van Helvoort <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, November 29, 2017 at 3:38 PM
To: "Carlos Pignataro (cpignata)" <[email-masked]>
Cc: Benoit Claise <[email-masked]>, Greg Mirsky <[email-masked]>, Qin Wu <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Ronald Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Hello Carlos,

Best regards, Huub.

-----------

Best,

—

Hello Benoit,

You reply:

Regards, Huub.

=========

Hello Greg,

Authors:

Please explain.

Regards, Huub.

---------
Dear All,

        description

          "The relative position

Regards,
Greg

--

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 29 Nov 2017 21:18:01 -0800

Hi Tissa,
thank you for your kind words, much appreciated. Wish you all success in
your endeavors and hope you'll find opportunity to return to IETF work
sooner than later.

Best regards,
Greg

On Wed, Nov 29, 2017 at 2:40 PM, Tissa Senevirathne <[email-masked]>
wrote:

> As the original author of the connectionless draft I deliberately avoided
> making any comments as I do not have adequate time to do a good job.
>
> However, I have been reading, with great respect, the comments Greg Mirsky
> was making to make these drafts better both technically and editorially. I
> want to extend a well deserved thank you to Greg. Thank You Greg.
>
> Also I do not agree with Carlos comments on Hubbs observations, i.e. Oh
> Draft is in IETF editors queue and it is too late. May be time to pull it
> out from the queue or create errata if the changes are significant enough.
>
> On Wed, Nov 29, 2017 at 12:39 PM, Huub van Helvoort <[email-masked]>
> wrote:
>
>> Hello Carlos,
>>
>> Additionally, please see https://www.ietf.org/rfcdi
>> ff?url1=draft-ietf-lime-yang-connectionless-oam-17&url2=
>> draft-ietf-lime-yang-connectionless-oam-18, which shows the changes
>> relevant to that specific comment.
>>
>> Carlos Pignataro, [email-masked]
>>
>> *“Sometimes I use big words that I do not fully understand, to make
>> myself sound more photosynthesis."*
>>
>> On Nov 28, 2017, at 5:21 AM, Huub van Helvoort <[email-masked]>
>> wrote:
>>
>> Hello Benoit,
>>
>> You reply:
>>
>> been discussed and since authors couldn't produce technical rationale for
>> this object we've agreed that it will be removed altogether from the grouping

---

From: Tissa Senevirathne <[email-masked]>
Date: Wed, 29 Nov 2017 14:40:07 -0800

1. Appoint an editor who can shepherd edits and presentation aspects of the
draft
2. Provide adequate time and be transparent to share with the WG on what is
agreed or appoint a technical panel

On Wed, Nov 29, 2017 at 12:39 PM, Huub van Helvoort <[email-masked]>
wrote:

> Additionally, please see https://www.ietf.org/
> rfcdiff?url1=draft-ietf-lime-yang-connectionless-oam-17&
> url2=draft-ietf-lime-yang-connectionless-oam-18, which shows the changes
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 29 Nov 2017 21:39:22 +0100

Hello Carlos,

As I mentioned I already looked at version 18 because that was
mentioned

in Gregs response.

Best regards, Huub.

-----------

Additionally, please see https://www.ietf.org/rfcdiff?url1=draft-ietf-lime-yang-connectionless-oam-17&url2=draft-ietf-lime-yang-connectionless-oam-18,
which shows the changes relevant to that specific comment.

I believe the authors are using text suggested by
Greg.

Like Benoit said, the document is approved and in
the RFC Editor queue:

Best,

—

“Sometimes I use big words that I do not fully
understand, to make myself sound more photosynthesis."

On Nov 28, 2017, at 5:21 AM, Huub van Helvoort
<[email-masked]>
wrote:

Hello Benoit,

You reply:

For your information, the
document is now in the RFC editor queue, ready to be
published.

I had not seen any response from the authors to the
email from Greg

(I checked the archive) so I assumed that the issue was
still being

discussed.

I also checked for updates to version 18, but did not
find any, so I

Regards, Huub.

=========

Hello Greg,

I agree with you that the current (version 18)
text in section 3.3 is very confusing.

Authors:

If I look at the definition of TP in section 2.2 I
think a TP is similar

to a maintenance point as defined for Ethernet. Am
I correct?

I don't understand why there are TPs with no
neighboring TPs,

where will their initiated OAM test be sent? Or
where are OAM

It is IMHO also possible that there are TPs with a
neighboring

TP before AND a neighboring TP after the current
TP.

Please explain.

Regards, Huub.

---------

Dear All,

I was under impression that that
question of oam-neighboring-tps has
been discussed and since authors couldn't
produce technical rationale for this object
we've agreed that it will be removed
altogether from the grouping
connectionless-oam-tps. But authors just
changed name from level to position but had
missed to synchronize descriptions in the
model and in section 3.3. The later still
refers to vertical layers:

while the model insists that it is
peering relationship:

description
"The relative position

So, what is it? Perhaps it is time
to remove list oam-neighboring-tps
altogether also because having it s fixed
size list is plain wrong. (Sorry for being
so blunt but I commented too many times on
the same to no avail from the authors).

Regards,

Greg