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

[Tissa Senevirathne <[e-mail]>]

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 <[e-mail]>
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, [e-mail]
>
> *“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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lime
>
>