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

[Italo Busi <[e-mail]>]

Hi Med,

I am getting a bit confused about the requirements in RFC 8407

How would you suggest to reconcile this with the following text in section 3.9 of RFC 8407 (and of RFC 8407-bis)?

For every normative reference statement that appears in a module contained in the specification that identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. The reference SHOULD correspond to the specific document version actually used within the specification.

It is not clear to my why this is a SHOULD and not a MUST and therefore under which circumstance we can deviate from the SHOULD

Thanks, Italo

From: [e-mail] <[e-mail]>
Sent: lunedì 14 ottobre 2024 10:18
To: [e-mail]; '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

Hi all,

For the first point below, as this one is still in the WG state and it is not used in an import, I think that it is better to follow this part from 8407 and move that I-D to be listed as informative:

      Be sure citations for all imported modules are present somewhere
      in the document text (outside the YANG module).  If a YANG module
      contains reference or "description" statements that refer to an
      I-D, then the I-D is included as an informative reference.

Cheers,
Med



Orange Restricted
De : Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 11 octobre 2024 21:29
À : 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc : 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Objet : [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?
  *   Do we really need normative references to such a long list of Informational RFCs?
  *   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.
  *   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.
  *   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.

  *
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.

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

____________________________________________________________________________________________________________

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.