Re: [Teas] teas-yang-rsvp wasRe: TEAS WG Document Status Reports

[Tarek Saad <[e-mail]>]

Hi Tom/WG,

We have published revision -16 of I-D that addresses the below comments. Let us know if there further comments.
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-16

Regards,
Tarek

On 9/7/20, 6:56 AM, "tom petch" <[e-mail]> wrote:

    [External Email. Be cautious of content]


    From: Tarek Saad <[e-mail]>
    Sent: 04 September 2020 03:19

    Hi Tom,

    Thanks. We posted version -15 that addresses the new comments. Please see inline below.

    On 7/29/20, 7:13 AM, "tom petch" <[e-mail]> wrote:

        From: Tarek Saad <[e-mail]>
        Sent: 27 July 2020 13:29

        Hi Tom,

        Thanks for your review of ID: draft-ietf-teas-yang-rsvp and for the your comments. We have posted version https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-14__;!!NEt6yMaO-gk!Uuuyk1W5q3esw_NUF5cFLOm0yIZceYc_AGI4mkCAzpkZYDXorduSaYa_0Cdxfw$
        Which addresses those comments.

    <tp>
    Mostly :-)
    You still have a prefix mismatch beteen module and IANA.

    In passing, XPath should be XPath and not xpath

    But my main concern is that I struggle to understand what the model is trying to do; I can reverse engineer the YANG but would like more description to check against and this is especially true of the split between base and extended.  The English is quirky and will need seeing to - the IESG are rather hot on this at present - and in at least one place seems wrong.  s.3.2 'For example' well no it looks like the list of all the core model features not just examples thereof and the next sentence 'configuration for optional features that are not must for ...' is not English and I do not understand 'optional features'; what are they?  I want a list of what is included in base and what extended adds.  From the YANG it looks as if everything is in base and that extended adds the ability to configure those mandatory features, such as refresh reduction, and also to add statistics for them.  So I want a description of what really is in base and what extended adds.

    In this context, the tree diagram for extended has two YANG augment that have no parallel in the extended module AFAICT.  Seems apt somehow:-)

    Tom Petch

        <tp>
        Mostly:-)
        You still have  a prefix mismatch between module and IANA.
    [TS]: I corrected the typo:
    OLD:
          prefix:     rsvp-extendeed
    NEW:
          prefix:     rsvp-extended

        I suspect you will get asked for examples at some stage

        s.3.1 The augments diagrams use 'o' to show augmentation.  Other I-D use '>' but use it in different senses.  My take is
        A----->B
        means A augments B.
    [TS]: OK, replaced 'o' with '>'

        3.3 I think that filters need references.  Subtree is 6241 but XPATH is probably 8639 since that specifies the context thereof which is not obvious.
    [TS]: I added the references above.

    Regards,
    Tarek

        Tom Petch









        Please see inline (look for TS) for more details.

        >>>>>>>>>>

            2. draft-ietf-teas-yang-rsvp-11
            Current Status:

            <tp>
            teas-yang-rsvp-12 would benefit from some tweaks
            Abstract confused me into thinking that the Extended model was elsewhere - I think that this needs an explicit mention.
        TS: revised abstract to address this.


            Introduction ditto.
        TS: revised Introduction to address this.

            Introduction should mention RFC7950 and RESTCONF

            Introduction should mention NMDA support
        TS: Addressed.

            1 is wrong
            rt-type I am not familiar with but rt-types is in RFC8294
            key-chain is RFC8177
        TS: corrected.

            2.4 lists two RPC but tree diagram lists three, one of which is authentication but authentication is a feature of extended not base - this confuses me
        TS: corrected and added the third.

            revision description
            should be 'Initial version' in both modules

            the rpc should probably be NACM default deny all
        TS: added.

            IANA Considerations
            URI lack registrant contact
            prefix are not those used in the modules
        TS: updated.

            Security
            alsocontrols
        TS: corrected.

            RFC5495 needs adding to I-D References
        TS: updated references.

        Again, thanks much for the comments.

        Regards,
        Tarek

            Tom Petch






               *   Version -10 was reviewed by YANG Dr. and received comments

              *   Authors published version -12 which addressed all outstanding comments
              *   Authors followed up with YANG Dr. reviewer on closing comments
            Open Issues:

              *   None
            Next Steps:

              *   Proceed to WGLC


            3. draft-ietf-teas-yang-rsvp-te-07
            Current Status:

              *   Version -07 was reviewed by YANG Dr. and received comments
            Open Issues:

              *   Authors working on addressing YANG Dr. comments
            Next Steps:

              *   Folllow-up with YANG Dr. reviewer to close on comments
              *   Proceed to WGLC after addressing

            4. draft-ietf-teas-yang-te-mpls
            Current Status:

              *   Authors discussing augmentation of this module for MPLS-TP
              *   A new module and model is expected
            Open Issues:

              *   Close on MPLS-TP modeling
            Next Steps:

              *   Publish a new revision
              *   Ask for YANG Dr. review



            _______________________________________________
            Teas mailing list
            [e-mail]
            https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Uuuyk1W5q3esw_NUF5cFLOm0yIZceYc_AGI4mkCAzpkZYDXorduSaYZE_6t5pA$


Juniper Business Use Only