[Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

[Italo Busi <[e-mail]>]

Hi Adrian,

Thanks for your review and for spotting this issue

Some Informative References have been moved to Normative based on a WG LC comment

In fact, according to RFC 8407 (as well as RFC 8407-bis), the I-D SHOULD have a normative reference for any document normatively referenced in the YANG model

It is not clear to me why this is SHOULD and not a MUST

>From the comments I have received on other drafts, I had the feeling that some people have interpreted the requirement as a MUST for any reference rather than a SHOULD only for the normative references and for this reason we have decided for a blind move to Normative.

I have started a detailed analysis of the current DOWNREFs in github and noted that in some cases, the Informative RFC defines a configurable system behavior rather than a protocol behavior. Since the YANG models can be used to configure also the system behavior, it seems reasonable to consider these reference within the YANG module as normative.

Should we manage these cases as a justified DOWNREF or make the Informative as a deviation to the SHOULD in RFC 8407 (and bis)?

See some replies to your detailed points in line

Thanks, Italo

From: Adrian Farrel <[e-mail]>
Sent: venerdì 11 ottobre 2024 21:29
To: 'OSCAR GONZALEZ DE DIOS' <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc: 'TEAS WG Chairs' <[e-mail]>
Subject: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Thanks for the opportunity, Oscar.

I always look at idnits. I see that it is warning about a lot of downrefs. Downrefs aren't necessarily a bad thing, but there really are a lot here, and it made me wonder.
So...

  *   Does this document really need to be gated by draft-ietf-pce-sid-algo which is currently only 4th in the queue for WGLC in PCE?

[Italo Busi]

This reference in YANG model looks normative

However, I share your concern about this dependency also because there are many I-Ds which are depending from RFC8776-bis

Can we deviate from the SHOULD in RFC 8407 with the objective to avoid this dependency and make it Informative?

[\Italo Busi]


  *   Do we really need normative references to such a long list of Informational RFCs?

[Italo Busi]

See explanation above

[\Italo Busi]



  *   RFC 4115 seems like a *really* bad thing to include as a normative reference from an IETF standards track RFC given that it is an Independent Stream publication with a fairly assertive IESG note.

[Italo Busi]

I think we can remove any YANG statement referencing RFC 4115 together with the reference.

Vendor-specific identities can be defined by those who are implementing RFC 4115 bandwidth profiles

[\Italo Busi]


  *   RFCs 4125 and 4126 are a bit shaky as normative references. I'm not sure what the status of the experiments described is. Certainly, no one thought it worth moving them on to the Standards Track.

[Italo Busi]

RFCs 4125, 4126 and 4126 are used to define some bc-model-type derived identifies, e.g., bc-model-nam identity (Maximum Allocation Bandwidth Constraints Model type)

These references in the YANG model look normative.

I agree with you that it would be good to know why these RFCs are still Experimental. However, it is worth noting that the corresponding YANG definitions already existed in RFC 8776 but these references were listed as Informative

Can we deviate from the SHOULD in RFC 8407 to keep consistency with RFC 8776?

[\Italo Busi]


  *   RFC 4427 is a fine document, and explains a lot of stuff. But I don't think it defines any process or protocol behaviour. So does a normative reference actually give it too much weight? Should we be using the RFCs that actually define the different recovery protocol behaviours? For example:
     identity clear {
       base protection-external-commands;
       description
         "An action that clears the active near-end lockout of a
          protection, forced switchover, manual switchover, WTR state,
          or exercise command.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
                    for Generalized Multi-Protocol Label Switching
                    (GMPLS)";
     }
The term "WTR" or "WTR state" is not found in RFC 4427, although "Wait To Restore time" is in 4.16.
On the other hand, "Wait-To-Restore (WTR)" is in 6.1 of RFC 4428 and 6.2 has "a local Wait-to-Restore (WTR) state". Mind you, 4428 is also Informational.
RFC 6378 begins to put some behavioural substance behind the concept of a WTR timer, and the state machine has a WTR State.

  *

[Italo Busi]

I think we should expand the WTR acronym to be Wait To Restore (WTR)

The references to RFC 4427 in the YANG model look normative.

The intention here was to reference something generic and independent from a specific protocol (RFC 6378 applies only to MPLS-TP)

ITU-T G.808.1 is a possible alternative but there was some preference for an IETF reference when possible (the Exercise command was the only exception)

Do you think it is better to add normative references to RFC 6378 (and maybe also RFC 7271) to make RFC 4427 just informative?

[\Italo Busi]

I'm not going to go through all of the references and check them. It is possible that some downrefs are a good idea (and will need to be called out in the shepherd write-up and the IETF last call unless they are already in the downref registry). The authors might want to check carefully.

[Italo Busi]

I have done an initial analysis in github:

https://github.com/tsaad-dev/te/issues/293

[\Italo Busi]

Otherwise, this looks like a solid (if rather large) piece of work. Well done to the authors!

I think that the Security Considerations given here are correct. This is the equivalent of a family of typedefs. Of themselves, there is no security risk. It all depends how other YANG modules use them.

Cheers,

Adrian

From: OSCAR GONZALEZ DE DIOS <[e-mail]<mailto:[e-mail]>>
Sent: 11 October 2024 13:36
To: 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Dear TEAS WG colleagues,

       As a result of the comments during the WG LC of draft-ietf-teas-rfc8776-update-10, the authors made several changes. The current version is draft-ietf-teas-rfc8776-update-13.

      This email starts a second working group last call on https://datatracker.ietf.org/doc/draft-ietf-teas-rfc8776-update/.

    As the focus is on the changes from -10 to -13, the duration will be one week. Hence, the second working group last call ends on October 18th 2024.

    Please send your comments to the working group mailing list. To facilitate the review, please find the diff here: Diff: draft-ietf-teas-rfc8776-update-10.txt - draft-ietf-teas-rfc8776-update-13.txt<https://author-tools.ietf.org/iddiff?url1=draft-ietf-teas-rfc8776-update-10&url2=draft-ietf-teas-rfc8776-update-13&difftype=--html>

Thank you,
              Oscar


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição