Subject: Re: [sfc] I-D Action: draft-ietf-sfc-proof-of-transit-06.txt

From: t petch <[email-masked]>
Date: Fri, 7 Aug 2020 11:19:14 +0100

There is quite a lot wrong with this I-D from the YANG point of view.  I
am surprised that it passes YANG validation, as the data tracker
reports, but that is validation for you!  Most of these comments derive
from YANG Guidelines RFC8407.

Tree diagram is now standardised as RFC8340 and is not normally regarded
as CODE

YANG version 1 was replaced in 2016

Prefix ietf-pot-profile is cumbersome - 3-5 characters is more than
enough for a prefix

Contact needs Editors

Copyright 2018 (feels about right:-)

Revision reference must reference this I-D/RFC2be

A grouping that is only used once increases size and complexity for no
benefit but in this case pot-profile is imported by IPPM; worth a 
mention somewhere.

List identifiers are conventionally plural.

IANA considerations are mandatory - if the module is not registered with
IANA there is no module

Security Considerations for YANG are mandatory - YANG Guidelines points
to the current text albeit trivial compared with those for POT:-).

These two Considerations will pull in another half a dozen Mandatory
references.

Key Words is ood - see RFC8174

When MTU is Maxiumum Transmission Unit, then it is a recognised
abbreviation and does not need expanding.

HMAC is Hashed ...in the RFC Editor list

Abstract/Introduction should mention that there is a YANG module, that
it conforms to NMDA and reference RFC7950.  IANA Considerations on the
other hand should reference RFC6020.

IPPM import this module so I copy that list.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 16, 2020 10:01 AM
Subject: I-D Action: draft-ietf-sfc-proof-of-transit-06.txt

>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Service Function Chaining WG of the
IETF.
>
>         Title           : Proof of Transit
>         Authors         : Frank Brockners
>                           Shwetha Bhandari
>                           Tal Mizrahi
>                           Sashank Dara
>                           Stephen Youell
> Filename        : draft-ietf-sfc-proof-of-transit-06.txt
> Pages           : 29
> Date            : 2020-06-16
>
> Abstract:
>    Several technologies such as Traffic Engineering (TE), Service
>    Function Chaining (SFC), and policy based routing are used to steer
>    traffic through a specific, user-defined path.  This document
defines
>    mechanisms to securely prove that traffic transited a defined path.
>    These mechanisms allow to securely verify whether, within a given
>    path, all packets traversed all the nodes that they are supposed to
>    visit.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-06
>
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-proof-of-transit-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-proof-of-transit-06
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/[sfc] I-D Action:
draft-ietf-sfc-proof-of-transit-06.txt
> [email-masked] Tue, 16 June 2020 12:52 UTCShow header
>
>
>
>
>
>
>
> ftp://ftp.ietf.org/

---

From: <[email-masked]>
Date: Fri, 7 Aug 2020 12:54:19 +0000

Hi Tom, 

FWIW, the authors are working on an updated version that will fixes many of the points you raised. Some of the issues (e.g., the grouping) are clarified here: https://mailarchive.ietf.org/arch/msg/sfc/ZOf8Yb_JK68v9O40PbD2MSjqJ48/ 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de t petch
> Envoyé : vendredi 7 août 2020 12:19
> À : [email-masked]; [email-masked]
> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-proof-of-transit-06.txt
> 
> There is quite a lot wrong with this I-D from the YANG point of view.
> I am surprised that it passes YANG validation, as the data tracker
> reports, but that is validation for you!  Most of these comments
> derive from YANG Guidelines RFC8407.
> 
> Tree diagram is now standardised as RFC8340 and is not normally
> regarded as CODE
> 
> IANA considerations are mandatory - if the module is not registered
> with IANA there is no module
> 
> Security Considerations for YANG are mandatory - YANG Guidelines
> points to the current text albeit trivial compared with those for
> POT:-).
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

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.