[Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt

[[e-mail]]

Hi Italo, 

Thanks for taking care of the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Italo Busi <[e-mail]>
> Envoyé : samedi 9 novembre 2024 12:13
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]
> Objet : RE: New Version Notification for draft-ietf-teas-rfc8776-
> update-14.txt
> 
> 
> Thanks Med
> 
> I have updated the draft in github to address most of your
> comments. You can check the diff at:
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-teas-rfc8776-
> update-
> 14%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-
> dev%2Fte%2Frefs%2Fheads%2Fmaster%2Fdrafts%2Fte-types-
> update%2Fdraft-ietf-teas-rfc8776-
> update.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C35f037
> 43b5324ccf4fbd08dd00af9341%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C638667476300995946%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fJlu8LBEMlX9Vh6MB2FOfqajgBtRa3eX3
> 4NJeGMz38o%3D&reserved=0
> 
> These are the comments for which I would need more input from the
> TEAS WG:
> 
> > * " The derived identities SHOULD describe the ..": I wouldn't
> > surprised if you receive a comment about why this is not a
> MUST. You
> > may explain an exception in the text if you have one in mind.
> 
> An exception is the number of hops which do not have a
> measurement unit, so it cannot be a MUST. Spelling out the
> exception is not future proof: we do not wish to precluding
> future definitions of other identities similar which do not have
> measurement units.
> 

[Med] I'm afraid you misread my comment. This is not about listing every exception but indicating an example of when the SHOULD can be ignored. Listing the # of hops as an example would be great.

As a reminder, RFC2119 says the following:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

> > * I like this text, but is this used by other standard models
> outside IETF?
> >
> > CURRENT:
> >          The container has been renamed as 'explicit-route-
> objects'.
> >          This change is not affecting any IETF standard YANG
> models
> >          since this grouping has not yet been used by any YANG
> model
> >          defined in existing IETF RFCs.
> >
> 
> The text reflects the decision based on the discussion on the
> list:
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fmailarchive.ietf.org%2Farch%2Fmsg%2Fteas%2Fcmf7KsRBxFQZ6oaf-
> mzWTdZxAYQ%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C35f
> 03743b5324ccf4fbd08dd00af9341%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C638667476301021706%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yy0Y10Irdm9SFG8vuVzgotO1cENNHj
> y%2FD7XVyJ84Uow%3D&reserved=0
> 
> IMHO, it is quite unlikely that other SDOs are importing this
> grouping from RFC 8776 but I do not think we can write anything
> about this in an IETF draft/RFC so better to keep silent on this
> point

[Med] I wasn't asking for any change here but interested to hear if this was used outside. Thanks

> 
> > * I still find identifiers such as "
> > path-computation-error-destination-unknown-
> > in-domain" to be toooooo long, but...
> 
> At this stage, there is nothing I can do.
> 

[Med] :-)

> Just a side comment:
> 
> > * "revision  2024-10-30" and file name should be consistent.
> Fix the date.
> 
> This is another example of why I do not like duplicated
> information to be manually kept updated: this duplicated
> information quickly gets out of synch if authors or reviewers are
> not carefully enough to double check it
> 
> An automatic tool to automatically keep this text in synch or, at
> least, flag the nit before submission would be very useful
> 

[Med] Agree.

> Italo
> 
> > -----Original Message-----
> > From: [e-mail]
> <[e-mail]>
> > Sent: venerdì 8 novembre 2024 08:18
> > To: Italo Busi <[e-mail]>; [e-mail]
> > Subject: RE: New Version Notification for
> > draft-ietf-teas-rfc8776-update-14.txt
> >
> > Hi Italo,
> >
> > Many thanks for the effort put in this document.
> >
> > I used a diff vs the original RFC to do a final check:
> https://author-
> > tools.ietf.org/diff?doc_1=rfc8776&doc_2=draft-ietf-teas-
> rfc8776-update
> > -
> > 14&wdiff=1
> >
> > For the record, I consider the comments I raised as closed.
> >
> > FWIW, find below some nits/comments that you can consider for a
> future
> > iteration when you will have other reviews:
> >
> > * I would invert the ordering of 1.2/1.3 so that mapping with
> 8776 is
> > preserved
> > * Introduction: s/ YANG models and obsoletes/ YANG modules and
> > obsoletes (or YANG data models and obsoletes)
> > * Section 3.1: To ease referring by future documents, you may
> convert
> > the text starting with " The "xxx" module contains the
> following "
> > into subsections
> > * Idem as previous comment for Section 3.2
> > * Section 3.1: s/No standard LPS provisioning/No standard LP
> > provisioning
> > * " The derived identities SHOULD describe the ..": I wouldn't
> > surprised if you receive a comment about why this is not a
> MUST. You
> > may explain an exception in the text if you have one in mind.
> > * Don't be restrictive in how this will be used:
> >
> > OLD:
> >    path-computation-error-reason:  A base YANG identity for
> reporting
> >       path computation error reasons as defined in Section
> 3.1.1.
> >
> > NEW:
> >    path-computation-error-reason:  A base YANG identity for
> indicating
> >       path computation error reasons as defined in Section
> 3.1.1.
> >
> > (idem in the wording in 3.1.1)
> >
> > * These entries are listed as identities, while these are
> groupings.
> > Please fix
> > that:
> >
> > CURRENT:
> >
> >    The "ietf-te-types" module contains the following YANG
> reusable
> >    identities:
> >    ...
> >    explicit-route-hop:  A YANG grouping that defines supported
> explicit
> >       routes as defined in [RFC3209] and [RFC3477].
> >    ...
> >
> >    encoding-and-switching-type:  This is a common grouping to
> define the
> >       LSP encoding and switching types.
> >
> > * Explicit this is to clarify what an IANA module is not used
> here
> >
> > OLD:
> >    The derived identities are defined in the "ietf-te-types"
> module
> >    because there are error reasons which are:
> >
> > NEW:
> >    The derived identities are defined in the "ietf-te-types"
> module
> >    instead of an IANA-maintained module because there are error
> > reasons which are:
> >
> > * Section 3.2: I would split the identities vs groupings
> > * I like this text, but is this used by other standard models
> outside IETF?
> >
> > CURRENT:
> >          The container has been renamed as 'explicit-route-
> objects'.
> >          This change is not affecting any IETF standard YANG
> models
> >          since this grouping has not yet been used by any YANG
> model
> >          defined in existing IETF RFCs.
> >
> > * "revision  2024-10-30" and file name should be consistent.
> Fix the date.
> > * I still find identifiers such as "
> > path-computation-error-destination-unknown-
> > in-domain" to be toooooo long, but...
> > * " "At least one node identifier MUST be present.";  I don't
> think
> > you need the normative language here as you already have a must
> statement.
> > * Idem in
> >
> > "                 "At least one node identifier and at least
> one Link
> >                  Termination Point (LTP) identifier MUST be
> present."; "
> >
> >
> > Cheers,
> > Med
> >
> >
> > Orange Restricted
> >
> > > -----Message d'origine-----
> > > De : Italo Busi <Italo.Busi=[e-mail]>
> > > Envoyé : mardi 5 novembre 2024 00:10 À : [e-mail]
> Objet :
> > > [Teas] FW: New Version Notification for draft-ietf-teas-
> > > rfc8776-update-14.txt
> > >
> > > Dear TEAS WG and chairs,
> > >
> > > I have just uploaded an updated version of the draft
> addressing all
> > > the comments received during the second Working group last
> call of
> > > draft-ietf-teas-rfc8776-update-13 and discussion on the WG
> mailing
> > > list
> > >
> > > I believe the draft is not ready to go to IESG
> > >
> > > Thanks, Italo (on behalf of co-authors/contributors)
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] <[e-mail]>
> > > > Sent: martedì 5 novembre 2024 01:05
> > > > To: Aihua Guo <[e-mail]>; Igor Bryskin
> > > > <[e-mail]>; Italo Busi <[e-mail]>;
> > > Tarek Saad
> > > > <[e-mail]>; Xufeng Liu
> <[e-mail]>
> > > > Subject: New Version Notification for
> > > > draft-ietf-teas-rfc8776-update-14.txt
> > > >
> > > > A new version of Internet-Draft draft-ietf-teas-rfc8776-
> update-
> > > 14.txt
> > > > has been successfully submitted by Italo Busi and posted to
> the
> > > IETF repository.
> > > >
> > > > Name:     draft-ietf-teas-rfc8776-update
> > > > Revision: 14
> > > > Title:    Common YANG Data Types for Traffic Engineering
> > > > Date:     2024-11-05
> > > > Group:    teas
> > > > Pages:    154
> > > > URL:
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-teas-rfc8776-
> update-
> > >
> >
> 14.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf5
> > 2
> > >
> > 2b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> > C0
> > > %7C638663622429788248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDA
> > >
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> > >
> > a=hApMC%2Bb%2FKohyTzQJBIZ9ac0tKOzIqFZoVFo14Erf0IM%3D&reserved=0
> > > > Status:
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-rfc8776-
> > >
> > update%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c4
> > 42c
> > >
> >
> f522b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> > >
> > 7C0%7C638663622429807585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAw
> > >
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> > s
> > >
> > data=2%2FJV94ILkIg0Gr6M29gWhYPnsVMFv5%2F7YM9dsZs%2Bs7c%3D&rese
> > rve
> > > d=0
> > > > HTMLized:
> > > >
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Fdata
> > > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-rfc8776-
> > > &data=05%7C02%
> > > >
> > >
> > 7Cmohamed.boucadair%40orange.com%7C26c442cf522b4778426208dcfd2e
> > 47
> > > 16%7C
> > > >
> > >
> > 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638663622429822216%
> > 7CU
> > > nknow
> > > >
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLC
> > > >
> > >
> > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xYJwo5A14GdYtVLDsrzVXxHSigD1js
> > g1w
> > > Jx9tL
> > > > FoMEo%3D&reserved=0
> > > > update
> > > > Diff:
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-teas-
> rfc8776-
> > >
> > &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf522b4
> > 778
> > >
> > 426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> > 638
> > >
> > 663622429836473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > LCJQI
> > >
> >
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hFW
> > a
> > > ZMR8jikNKAVcwSRrPYk%2FXPnzkc%2FQSlW2225ZksM%3D&reserved=0
> > > > update-14
> > > >
> > > > Abstract:
> > > >
> > > >    This document defines a collection of common data types,
> > > identities,
> > > >    and groupings in YANG data modeling language.  These
> derived
> > > common
> > > >    data types, identities and groupings are intended to be
> > > imported by
> > > >    other modules, e.g., those which model the Traffic
> > > Engineering (TE)
> > > >    configuration and state capabilities.
> > > >
> > > >    This document obsoletes RFC 8776.
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > >
> > > _______________________________________________
> > > Teas mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> _________________________________________________________________
> > ___________________________________________
> > Ce message et ses pieces jointes peuvent contenir des
> informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce
> message
> > par erreur, veuillez le signaler a l'expediteur et le detruire
> ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message
> a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the
> sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages
> that have
> > been modified, changed or falsified.
> > Thank you.
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.