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

[Greg Mirsky <gregimirsky@xxxxxxxxx>]

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 <tsenevir@xxxxxxxxx> 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 <huubatwork@xxxxxxxxx> 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.

-----------

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, carlos@xxxxxxxxx

“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 <huubatwork@xxxxxxxxx> wrote:

Hello Benoit,

You reply:

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/

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
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:

                     "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

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

_______________________________________________
Lime mailing list
Lime@xxxxxxxx
https://www.ietf.org/mailman/listinfo/lime