[OPSAWG]Re: shepherd review for draft-boro-opsawg-teas-common-ac

[Rokui, Reza]

Thanks Med.

Reza

From: mohamed.boucad...@orange.com 
Date: Wednesday, May 15, 2024 at 3:41 PM
To: Rokui, Reza , Joe Clarke (jclarke) , 
opsawg@ietf.org , Wubo (lana) , Richard 
Roberts , Oscar González de Dios 
, samier.barguil_gira...@nokia.com 

Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac
Hi Reza,

Thank you for the review.

We don’t provide the full structure but snippets per the guidance in 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-tree-diagrams
 
[datatracker.ietf.org].

We provided the following in Section 4:

==
   The full tree diagram of the module can be generated using the
   "pyang" tool [PYANG] with "-f tree --tree-print-groupings" command-
   line parameters.  That tree is not included here because it is too
   long (Section 3.3 of [RFC8340]).  Instead, subtrees are provided for
   the reader's convenience.

  The full tree of the "ietf-ac-common" module is available at
  [AC-Common-Tree].
==

Cheers,
Med

De : Rokui, Reza 
Envoyé : mercredi 15 mai 2024 21:29
À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke 
(jclarke) ; opsawg@ietf.org; Wubo (lana) 
; Richard Roberts ; Oscar González 
de Dios ; 
samier.barguil_gira...@nokia.com; Rokui, Reza 
Objet : Re: shepherd review for draft-boro-opsawg-teas-common-ac


Thanks Med.

One more question.

9. Based on the shepherd's review of the document, is it their opinion that this
   document is needed, clearly written, complete, correctly designed, and ready
   to be handed off to the responsible Area Director?

[Reza]  The document is well-written. Having said that the following suggestion 
communicated with authors.
- Any reason that the tree format of "module ietf-ac-common" is not included. 
IMO, it provides more clarity to the reader.

Reza

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, May 14, 2024 at 9:05 AM
To: Rokui, Reza mailto:rro...@ciena.com>>, Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>, Wubo (lana) 
mailto:lana.w...@huawei.com>>, Richard Roberts 
mailto:rrobe...@juniper.net>>, Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>,
 samier.barguil_gira...@nokia.com 
mailto:samier.barguil_gira...@nokia.com>>
Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac
Hi Reza,

Thank you for preparing the writeup.

Please see inline.

Cheers,
Med

De : Rokui, Reza mailto:rro...@ciena.com>>
Envoyé : lundi 13 mai 2024 21:35
À : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; 
opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Wubo 
(lana) mailto:lana.w...@huawei.com>>; Richard Roberts 
mailto:rrobe...@juniper.net>>; Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 samier.barguil_gira...@nokia.com; 
Rokui, Reza mailto:rro...@ciena.com>>
Objet : shepherd review for draft-boro-opsawg-teas-common-ac


Hi authors,

I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the 
shepherd writeup and have following questions.

Question 8. Describe reviews and automated checks performed to validate 
sections of the
   final version of the document written in a formal language, such as XML code,
   BNF rules, MIB definitions, CBOR's CDDL, etc;

[Med] pyang is integrated in our tooling to validate the YANG module. This is 
also reflected in the Datatracker: 0 errors, 0 warnings 
[datatracker.ietf.org]


Referring to  
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt
 
[author-tools.ietf.org]
 . It seems there a few warnings and errors. Are these resolved? If so, please 
send a summary.


[Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate 
text. Will remove it in the next iteration.

Question 15. Should any informative references be normative or vice-versa? See 
the [IESG
Statement on Normative and Informative References][16].

Please confirm this

[Med] I think we are OK, but please let us know if we misclassified any.

Question 16. List any normative references 

[OPSAWG]Re: shepherd review for draft-boro-opsawg-teas-common-ac

[mohamed . boucadair]

Hi Reza,

Thank you for the review.

We don’t provide the full structure but snippets per the guidance in 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-tree-diagrams.

We provided the following in Section 4:

==
   The full tree diagram of the module can be generated using the
   "pyang" tool [PYANG] with "-f tree --tree-print-groupings" command-
   line parameters.  That tree is not included here because it is too
   long (Section 3.3 of [RFC8340]).  Instead, subtrees are provided for
   the reader's convenience.

  The full tree of the "ietf-ac-common" module is available at
  [AC-Common-Tree].
==

Cheers,
Med

De : Rokui, Reza 
Envoyé : mercredi 15 mai 2024 21:29
À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke 
(jclarke) ; opsawg@ietf.org; Wubo (lana) 
; Richard Roberts ; Oscar González 
de Dios ; 
samier.barguil_gira...@nokia.com; Rokui, Reza 
Objet : Re: shepherd review for draft-boro-opsawg-teas-common-ac


Thanks Med.

One more question.

9. Based on the shepherd's review of the document, is it their opinion that this
   document is needed, clearly written, complete, correctly designed, and ready
   to be handed off to the responsible Area Director?

[Reza]  The document is well-written. Having said that the following suggestion 
communicated with authors.
- Any reason that the tree format of "module ietf-ac-common" is not included. 
IMO, it provides more clarity to the reader.

Reza

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, May 14, 2024 at 9:05 AM
To: Rokui, Reza mailto:rro...@ciena.com>>, Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>, Wubo (lana) 
mailto:lana.w...@huawei.com>>, Richard Roberts 
mailto:rrobe...@juniper.net>>, Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>,
 samier.barguil_gira...@nokia.com 
mailto:samier.barguil_gira...@nokia.com>>
Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac
Hi Reza,

Thank you for preparing the writeup.

Please see inline.

Cheers,
Med

De : Rokui, Reza mailto:rro...@ciena.com>>
Envoyé : lundi 13 mai 2024 21:35
À : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; 
opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Wubo 
(lana) mailto:lana.w...@huawei.com>>; Richard Roberts 
mailto:rrobe...@juniper.net>>; Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 samier.barguil_gira...@nokia.com; 
Rokui, Reza mailto:rro...@ciena.com>>
Objet : shepherd review for draft-boro-opsawg-teas-common-ac


Hi authors,

I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the 
shepherd writeup and have following questions.

Question 8. Describe reviews and automated checks performed to validate 
sections of the
   final version of the document written in a formal language, such as XML code,
   BNF rules, MIB definitions, CBOR's CDDL, etc;

[Med] pyang is integrated in our tooling to validate the YANG module. This is 
also reflected in the Datatracker: 0 errors, 0 warnings 
[datatracker.ietf.org]


· Referring to  
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt
 
[author-tools.ietf.org]
 . It seems there a few warnings and errors. Are these resolved? If so, please 
send a summary.


[Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate 
text. Will remove it in the next iteration.

Question 15. Should any informative references be normative or vice-versa? See 
the [IESG
Statement on Normative and Informative References][16].

· Please confirm this

[Med] I think we are OK, but please let us know if we misclassified any.

Question 16. List any normative references that are not freely available to 
anyone. Did
the community have sufficient access to review any such normative
references?

· [ISO10589]. Is this reference essential to be part of the RFC?
[Med] Yes, because this is the authoritative ref for ISIS.

Question 17. Are there any normative downward references (see [RFC 3967][9] and 
[BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.
-  Please comment on following normative RFCs:
RFC 8174 category is BCP
RFC 7348 category is Informational 

[OPSAWG]Re: shepherd review for draft-boro-opsawg-teas-common-ac

[Rokui, Reza]

Thanks Med.

One more question.

9. Based on the shepherd's review of the document, is it their opinion that this
   document is needed, clearly written, complete, correctly designed, and ready
   to be handed off to the responsible Area Director?

[Reza]  The document is well-written. Having said that the following suggestion 
communicated with authors.
- Any reason that the tree format of "module ietf-ac-common" is not included. 
IMO, it provides more clarity to the reader.

Reza

From: mohamed.boucad...@orange.com 
Date: Tuesday, May 14, 2024 at 9:05 AM
To: Rokui, Reza , Joe Clarke (jclarke) , 
opsawg@ietf.org , Wubo (lana) , Richard 
Roberts , Oscar González de Dios 
, samier.barguil_gira...@nokia.com 

Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac
Hi Reza,

Thank you for preparing the writeup.

Please see inline.

Cheers,
Med

De : Rokui, Reza 
Envoyé : lundi 13 mai 2024 21:35
À : Joe Clarke (jclarke) ; opsawg@ietf.org; BOUCADAIR 
Mohamed INNOV/NET ; Wubo (lana) 
; Richard Roberts ; Oscar González 
de Dios ; 
samier.barguil_gira...@nokia.com; Rokui, Reza 
Objet : shepherd review for draft-boro-opsawg-teas-common-ac


Hi authors,

I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the 
shepherd writeup and have following questions.

Question 8. Describe reviews and automated checks performed to validate 
sections of the
   final version of the document written in a formal language, such as XML code,
   BNF rules, MIB definitions, CBOR's CDDL, etc;

[Med] pyang is integrated in our tooling to validate the YANG module. This is 
also reflected in the Datatracker: 0 errors, 0 warnings 
[datatracker.ietf.org]


· Referring to  
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt
 
[author-tools.ietf.org]
 . It seems there a few warnings and errors. Are these resolved? If so, please 
send a summary.


[Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate 
text. Will remove it in the next iteration.

Question 15. Should any informative references be normative or vice-versa? See 
the [IESG
Statement on Normative and Informative References][16].

· Please confirm this

[Med] I think we are OK, but please let us know if we misclassified any.

Question 16. List any normative references that are not freely available to 
anyone. Did
the community have sufficient access to review any such normative
references?

· [ISO10589]. Is this reference essential to be part of the RFC?
[Med] Yes, because this is the authoritative ref for ISIS.

Question 17. Are there any normative downward references (see [RFC 3967][9] and 
[BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.
-  Please comment on following normative RFCs:
RFC 8174 category is BCP
RFC 7348 category is Informational and is already in DOWNREF registry
RFC 3688 category is BCP
RFC 2119 category is BCP

[Med] ACK. I confirm in particular that 7348 is already in the DOWNREF registry.

Question 19. Will publication of this document change the status of any 
existing RFCs? If
so, does the Data tracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

· IMO the answer is NO. Please confirm.

[Med] ACK.

Reza






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 

[OPSAWG]Re: [Last-Call] Intdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

[Aitken, Paul]

Med, Joe,




 - Reduced-size encoding per RFC7011 does not apply, unless you are 
restricting them to 64, 32, 16, and 8.
[Med] There is no such restriction because of this part in the base spec:


   This behavior is indicated by the Exporter by specifying a size in

   the Template with a smaller length than that associated with the

   assigned type of the Information Element.

That paragraph only explains how RSE is done. The document is silent on whether 
or not RSE can be applied to new types.

I see no difficulty allowing RSE of 128 or 256 bit types. I think it would be 
expected.

Whether the text in section 8.2 of the draft needs a slightly different form of 
words, I think the gist is correct:

Reduced-Size encoding (Section 6.2 of [RFC7011]) applies to this data type.

P.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-11.txt

[internet-drafts]

Internet-Draft draft-ietf-opsawg-ntw-attachment-circuit-11.txt is now
available. It is a work item of the Operations and Management Area Working
Group (OPSAWG) WG of the IETF.

   Title:   A Network YANG Data Model for Attachment Circuits
   Authors: Mohamed Boucadair
Richard Roberts
Oscar Gonzalez de Dios
Samier Barguil Giraldo
Bo Wu
   Name:draft-ietf-opsawg-ntw-attachment-circuit-11.txt
   Pages:   104
   Dates:   2024-05-15

Abstract:

   This document specifies a network model for attachment circuits.  The
   model can be used for the provisioning of attachment circuits prior
   or during service provisioning (e.g., VPN, Network Slice Service).  A
   companion service model is specified in the YANG Data Models for
   Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf-
   opsawg-teas-attachment-circuit).

   The module augments the base network ('ietf-network') and the Service
   Attachment Point (SAP) models with the detailed information for the
   provisioning of attachment circuits in Provider Edges (PEs).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-ntw-attachment-circuit-11.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ntw-attachment-circuit-11

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: Shepherd review for draft-ietf-opsawg-ntw-attachment-circuit

[Krzysztof Szarkowicz]

Hi Med,

Looks good now. From my perspective, no further changes are required.

Cheers,
Krzysztof

On May 15, 2024, at 17:08, mohamed.boucad...@orange.com wrote:

[External Email. Be cautious of content]


Hi Krzysztof,

Thank you for the review.

Can you please check and let us know if any further change is needed: 
https://urldefense.com/v3/__https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ntw-attachment-circuit_2=https:**Aboucadair.github.io*attachment-circuit-model*draft-ietf-opsawg-ntw-attachment-circuit.txt*__;Ly8vLz8!!NEt6yMaO-gk!DkQJWv6uzEQEP65hEQsVEdtBOKjK5LJ7hLQTVJeas9NBcwHpETrWQ_i9pqj-nnpCPb5fUucenj425kmWHJwdDnvFF6VwdZY0$
  Thanks.

Please see inline.

Cheers,
Med

-Message d'origine-
De : Krzysztof Szarkowicz
mailto:kszarkowicz=40juniper@dmarc.ietf.org>>
Envoyé : mercredi 15 mai 2024 14:41
À : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; 
opsawg@ietf.org
Cc : opsawg-cha...@ietf.org
Objet : [OPSAWG]Shepherd review for draft-ietf-opsawg-ntw-
attachment-circuit


Resending to the WG list



On May 2, 2024, at 11:26, Krzysztof Szarkowicz
 wrote:

Hi,


I have been asked to do the shepherd's review for draft-ietf-
opsawg-ntw-attachment-circuit document, with the intended traget
status "Standards Track". "Standards Track" is the appropriate
track for drafts defining Yang models, so it is appropriate for
this draft.

In general, the document is in a good shape. It is clearly
written, complete, correctly designed, and ready to be handed off
to the responsible Area Director. I believe this draft (in
combination with 3 other AC related drafts: I-D.ietf-opsawg-teas-
common-ac, I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-
opsawg-ac-lxsm-lxnm-glue) for AC provisioning, which decouples
the bearer from the services itself is very useful for service/AC
provisioning, including use cases like for example network
slicing or services with SLA provisioning.

Feedback in the WG mailing list for this draft is positive, and
there is a broad agreement for support of this draft, without
strong controversy or extreme discontent.

The OPSA WG AC work was discussed externally and is cross-
referenced by 3GPP (3GPP TS 28.541 Rel 18.5 onwards), O-RAN
Alliance (O-RAN.WG9.XTRP-MGT.0-R003-v08.00 onwards) and TEAS WG
draft-ietf-teas-ietf-network-slice-nbi-yang. This draft has
undergone RTGDIR LC, as well as Yangdoctors early reviews, which
declared the draft to be ready.

[Med] I would mention in the writeup the following as well:

To ensure cross-WG reviews:

* The call for adoption and WGLC for the document were also cced to TEAS WG.
* Progress status of the specification effort was shared with TEAS WG during 
IETF#116 
(https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-circuits-saps-00)IETF*117__;Iw!!NEt6yMaO-gk!DkQJWv6uzEQEP65hEQsVEdtBOKjK5LJ7hLQTVJeas9NBcwHpETrWQ_i9pqj-nnpCPb5fUucenj425kmWHJwdDnvFF1qqf14p$
 ) and 
(https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/117/materials/slides-117-teas-attachment-circuits-updates-next-steps-00__;!!NEt6yMaO-gk!DkQJWv6uzEQEP65hEQsVEdtBOKjK5LJ7hLQTVJeas9NBcwHpETrWQ_i9pqj-nnpCPb5fUucenj425kmWHJwdDnvFFy9ou1_8$
 ).


The IPR call for the draft was issued, with responses from
relevant parties (authors, contributors). Authors/contributors
agreed to be listed in the draft. There are five authors listed
in the draft, which adheres to general IETF rule fo maximum five
authors.

One of the normative reference [IEEE802.1Qcp] might not be
freely available to anyone. However, typically, the community
have sufficient access to review this reference. Two other
normative references are IETF drafts. However, undergoing WG LC
at the same time as this draft.

Publication of this draft will not change status of existing
RFCs. All aspects of the draft requiring IANA assignments are
associated with the appropriate reservations in IANA registries.
Any referenced IANA registries have been clearly identified. Each
newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).



I have just some nits and some minor clarification questions.






Section 1

Figure 1 must be corrected in html version of the document
(near right SAP in PE1 and two right SAPs in PE4). In text
version this figure is OK.


[Med] Tweaked the figure so the aavg rendering works.


Section 4

s/Typically, AS Border Routers (ASBRs) of each network is
directly connected to an ASBR of a neighboring network/Typically,
AS Border Routers (ASBRs) of each network are directly connected
to ASBRs of a neighboring network

Figure 4 in html version connects network 2# and Network 3#,
while in text version doesn't interconnect these networks. Must
be fixed in html version.


[Med] ACK.


Section 5.1

s/a SAP is an abstraction of the network reference points/a SAP
is an abstraction of the network reference point

[OPSAWG]Re: Secdir last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

[Benoit Claise]

Tero,

We could potentially ask the RFC-editors to do this task?
Or maybe they do it automatically?

Regards, Benoit

On 5/14/2024 4:31 PM, Tero Kivinen wrote:

mohamed.boucad...@orange.com writes:

In section 8.3 change

This type MUST be encoded per
Section 6.1.1 of [RFC7011].  Reduced-Size encoding (Section
6.2 of
[RFC7011]) applies to this data type.

to

This type MUST be encoded per
Section 6.1.1 of IPFIX specification [RFC7011]. Reduced-Size
encoding (Section 6.2 of IPFIX specification [RFC7011])
applies to
this data type.

--

[Med] This is a matter of editing taste. I'm not fun of expanding
the ref title.

I think it is important for lowering the bar to getting people
involved in the IETF protocols. If you need to learn mapping of
tens or hundreds of rfc numbers to the actual titles, before you can
easily read documents it makes it much harder to read the document,
and causes extra work for the reader.

Expanding it by the author once, will save that mapping to be done by
people who read it. There are RFCs where there is less readers than
writers, but I hope that is exception not a norm.

When I was reviewing that draft, I had to google the RFC numbers
multiple times (even the same ones) just to make sure which one is
which.

Also it is bad form of using reference as a noun. It makes [1] to [2]
text when some of the [3] is not near the part using it.

[1] https://dictionary.cambridge.org/dictionary/english/difficult
[2] https://dictionary.cambridge.org/dictionary/english/read
[3] https://dictionary.cambridge.org/dictionary/english/text


Section 9.1 [IANA-EH] url is wrong, it points to the "Next Header
Types" registry, not to the "IPv6 Extension Header Types"
registry.

[Med] This is on purpose because the RFC Editor does not cite the specific 
URLs, only the URL of the registry group.


Correct url is
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fwww.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-
parameters.xhtml%23extension-
header=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce04d445565
be47dc729308dc703d9ca0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
%7C638508657119400747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
a=sAElkvoUqJFN0K5eFgX%2F73LEbbqAWqerHq0IDzQsy%2Bo%3D=0

The link I provided pointed directly to the registry you referenced
to. If yo go to the registry itself the beginning of it has table of
contents, which provides links to exact registries.


___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: Shepherd review for draft-ietf-opsawg-ntw-attachment-circuit

[mohamed . boucadair]

Hi Krzysztof, 

Thank you for the review.

Can you please check and let us know if any further change is needed: 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ntw-attachment-circuit_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ntw-attachment-circuit.txt?
 Thanks.

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Krzysztof Szarkowicz
> 
> Envoyé : mercredi 15 mai 2024 14:41
> À : Joe Clarke (jclarke) ; opsawg@ietf.org
> Cc : opsawg-cha...@ietf.org
> Objet : [OPSAWG]Shepherd review for draft-ietf-opsawg-ntw-
> attachment-circuit
> 
> 
> Resending to the WG list
> 
> 
> 
> > On May 2, 2024, at 11:26, Krzysztof Szarkowicz
>  wrote:
> >
> > Hi,
> >
> >
> > I have been asked to do the shepherd's review for draft-ietf-
> opsawg-ntw-attachment-circuit document, with the intended traget
> status "Standards Track". "Standards Track" is the appropriate
> track for drafts defining Yang models, so it is appropriate for
> this draft.
> >
> > In general, the document is in a good shape. It is clearly
> written, complete, correctly designed, and ready to be handed off
> to the responsible Area Director. I believe this draft (in
> combination with 3 other AC related drafts: I-D.ietf-opsawg-teas-
> common-ac, I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-
> opsawg-ac-lxsm-lxnm-glue) for AC provisioning, which decouples
> the bearer from the services itself is very useful for service/AC
> provisioning, including use cases like for example network
> slicing or services with SLA provisioning.
> >
> > Feedback in the WG mailing list for this draft is positive, and
> there is a broad agreement for support of this draft, without
> strong controversy or extreme discontent.
> >
> > The OPSA WG AC work was discussed externally and is cross-
> referenced by 3GPP (3GPP TS 28.541 Rel 18.5 onwards), O-RAN
> Alliance (O-RAN.WG9.XTRP-MGT.0-R003-v08.00 onwards) and TEAS WG
> draft-ietf-teas-ietf-network-slice-nbi-yang. This draft has
> undergone RTGDIR LC, as well as Yangdoctors early reviews, which
> declared the draft to be ready.

[Med] I would mention in the writeup the following as well:

To ensure cross-WG reviews:

* The call for adoption and WGLC for the document were also cced to TEAS WG.
* Progress status of the specification effort was shared with TEAS WG during 
IETF#116 
(https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-circuits-saps-00)IETF#117)
 and 
(https://datatracker.ietf.org/meeting/117/materials/slides-117-teas-attachment-circuits-updates-next-steps-00).
  

> >
> > The IPR call for the draft was issued, with responses from
> relevant parties (authors, contributors). Authors/contributors
> agreed to be listed in the draft. There are five authors listed
> in the draft, which adheres to general IETF rule fo maximum five
> authors.
> >
> > One of the normative reference [IEEE802.1Qcp] might not be
> freely available to anyone. However, typically, the community
> have sufficient access to review this reference. Two other
> normative references are IETF drafts. However, undergoing WG LC
> at the same time as this draft.
> >
> > Publication of this draft will not change status of existing
> RFCs. All aspects of the draft requiring IANA assignments are
> associated with the appropriate reservations in IANA registries.
> Any referenced IANA registries have been clearly identified. Each
> newly created IANA registry specifies its initial contents,
> allocations procedures, and a reasonable name (see RFC 8126).
> >
> >
> >
> > I have just some nits and some minor clarification questions.
> >
> >
> >
> >
> >
> >
> > Section 1
> >
> > Figure 1 must be corrected in html version of the document
> (near right SAP in PE1 and two right SAPs in PE4). In text
> version this figure is OK.
> >

[Med] Tweaked the figure so the aavg rendering works.

> >
> > Section 4
> >
> > s/Typically, AS Border Routers (ASBRs) of each network is
> directly connected to an ASBR of a neighboring network/Typically,
> AS Border Routers (ASBRs) of each network are directly connected
> to ASBRs of a neighboring network
> >
> > Figure 4 in html version connects network 2# and Network 3#,
> while in text version doesn't interconnect these networks. Must
> be fixed in html version.
> >

[Med] ACK.

> >
> > Section 5.1
> >
> > s/a SAP is an abstraction of the network reference points/a SAP
> is an abstraction of the network reference point
> >
> > s/Indicate for each individual ACs one or a subset of the
> CEs/Indicate for each individual AC one or a subset of the CEs
> >

[Med] ACK

> >
> > Section 5.3.
> >
> > IS-IS link metric is 24-bit, while IS-IS path/prefix metric is
> 32-bit long (in the model uint16 is used) -> this must be fixed
> in the model
> >
> > IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases
> (IS-IS and OSPF), 'mode' (e.g. active/passive) is meaningful.
> Further, another type of interface mode is e.g. point-to-point,

[OPSAWG]Shepherd review for draft-ietf-opsawg-ntw-attachment-circuit

[Krzysztof Szarkowicz]

Resending to the WG list



> On May 2, 2024, at 11:26, Krzysztof Szarkowicz  
> wrote:
> 
> Hi,
> 
> 
> I have been asked to do the shepherd's review for 
> draft-ietf-opsawg-ntw-attachment-circuit document, with the intended traget 
> status "Standards Track". "Standards Track" is the appropriate track for 
> drafts defining Yang models, so it is appropriate for this draft.
> 
> In general, the document is in a good shape. It is clearly written, complete, 
> correctly designed, and ready to be handed off to the responsible Area 
> Director. I believe this draft (in combination with 3 other AC related 
> drafts: I-D.ietf-opsawg-teas-common-ac, 
> I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-opsawg-ac-lxsm-lxnm-glue) 
> for AC provisioning, which decouples the bearer from the services itself is 
> very useful for service/AC provisioning, including use cases like for example 
> network slicing or services with SLA provisioning.
> 
> Feedback in the WG mailing list for this draft is positive, and there is a 
> broad agreement for support of this draft, without strong controversy or 
> extreme discontent. 
> 
> The OPSA WG AC work was discussed externally and is cross-referenced by 3GPP 
> (3GPP TS 28.541 Rel 18.5 onwards), O-RAN Alliance 
> (O-RAN.WG9.XTRP-MGT.0-R003-v08.00 onwards) and TEAS WG 
> draft-ietf-teas-ietf-network-slice-nbi-yang. This draft has undergone RTGDIR 
> LC, as well as Yangdoctors early reviews, which declared the draft to be 
> ready.
> 
> The IPR call for the draft was issued, with responses from relevant parties 
> (authors, contributors). Authors/contributors agreed to be listed in the 
> draft. There are five authors listed in the draft, which adheres to general 
> IETF rule fo maximum five authors. 
> 
> One of the normative reference [IEEE802.1Qcp] might not be freely available 
> to anyone. However, typically, the community have sufficient access to review 
> this reference. Two other normative references are IETF drafts. However, 
> undergoing WG LC at the same time as this draft.
> 
> Publication of this draft will not change status of existing RFCs. All 
> aspects of the draft requiring IANA assignments are associated with the 
> appropriate reservations in IANA registries. Any referenced IANA registries 
> have been clearly identified. Each newly created IANA registry specifies its 
> initial contents, allocations procedures, and a reasonable name (see RFC 
> 8126).
> 
> 
> 
> I have just some nits and some minor clarification questions.
> 
> 
> 
> 
> 
> 
> Section 1
> 
> Figure 1 must be corrected in html version of the document (near right SAP in 
> PE1 and two right SAPs in PE4). In text version this figure is OK.
> 
> 
> Section 4
> 
> s/Typically, AS Border Routers (ASBRs) of each network is directly connected 
> to an ASBR of a neighboring network/Typically, AS Border Routers (ASBRs) of 
> each network are directly connected to ASBRs of a neighboring network
> 
> Figure 4 in html version connects network 2# and Network 3#, while in text 
> version doesn't interconnect these networks. Must be fixed in html version.
> 
> 
> Section 5.1
> 
> s/a SAP is an abstraction of the network reference points/a SAP is an 
> abstraction of the network reference point
> 
> s/Indicate for each individual ACs one or a subset of the CEs/Indicate for 
> each individual AC one or a subset of the CEs
> 
> 
> Section 5.3.
> 
> IS-IS link metric is 24-bit, while IS-IS path/prefix metric is 32-bit long 
> (in the model uint16 is used) -> this must be fixed in the model
> 
> IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases (IS-IS and 
> OSPF), 'mode' (e.g. active/passive) is meaningful. Further, another type of 
> interface mode is e.g. point-to-point, broadcast, ... Again, in both cases 
> (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be 
> included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.
> 
> 
> Section 5.4
> 
> Model covers l2-tunnel-types like pseudowire, vpls or vxlan. What about EVPN?
> 
> 
> 
> Section 5.5
> 
> For IPv6 two address allocation schemes are mentioned: dynamic and static. 
> What, if automatically assigned IPv6 link-local addresses are used/desired? I 
> think, some discussion about modelling IPv6 link-local addresses would be 
> beneficial.
> 
> Section 5.6.3
> 
> IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases (IS-IS and 
> OSPF), 'mode' (e.g. active/passive) is meaningful. Further, another type of 
> interface mode is e.g. point-to-point, broadcast, ... Again, in both cases 
> (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be 
> included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.
> 
> 
> Section 5.6.4
> 
> IS-IS link metric is 24-bit, while IS-IS path/prefix metric is 32-bit long 
> (in the model uint16 is used) ->  this must be fixed in the model
> 
> Another type of interface mode is e.g. point-to-point, broadcast, ... Again, 
> in both cases 

[OPSAWG]Re: WG LC: Attachment circuits work

[Joe Clarke (jclarke)]

We would like to thank the WG (and TEAS) for the reviews and comments during WG 
LC.  LC has concluded, and comments have been addressed (today) for issues 
raised.

We are still pending a couple of shepherd write-ups, but once we get them we 
can move these drafts forward to the IESG.

Joe

From: Joe Clarke (jclarke) 
Date: Friday, April 19, 2024 at 10:40
To: opsawg@ietf.org 
Cc: Traffic Engineering Architecture and Signaling Discussion List 

Subject: WG LC: Attachment circuits work
Thanks to efforts by the WG and cross-collaboration with TEAS, these four 
drafts are at the point to run a WG LC.  All currently reported issues have 
been resolved by the authors, and we are grateful to have four volunteers for 
shepherds.

The Attachment Circuits work is divided into four documents:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Given the size of the work, we will run for a three-week LC period (closing on 
May 10), and we are copying teas@ for additional reviews.  Please reply on-list 
with comments.

Joe
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: [Last-Call] Intdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

[mohamed . boucadair]

Hi Joe,

Thank you for the follow-up.

A candidate version can be seen at: Diff: draft-ietf-opsawg-tsvwg-udp-ipfix.txt 
- 
draft-ietf-opsawg-tsvwg-udp-ipfix.txt

Please see inline.

Cheers,
Med

De : to...@strayalpha.com 
Envoyé : mercredi 15 mai 2024 04:13
À : BOUCADAIR Mohamed INNOV/NET 
Cc : int-...@ietf.org; draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; 
last-c...@ietf.org; opsawg@ietf.org
Objet : Re: [Last-Call] Intdir last call review of 
draft-ietf-opsawg-tsvwg-udp-ipfix-08

Hi, Med,

I still have issue with the same two key parts:

1. This doc refers to unsigned192.

[Med] Before defining the unsigned192, I first considered reusing unsigned256 + 
mandate that 64bits to be always set to zero. These leading zeros will thus be 
dropped per the reduced size encoding.

 - That is not a native data type of any known computer. It needs 
to be defined.
[Med] Unsigned192 structure is used in many contexts (e.g., U192 in 
crypto_bigint - Rust 
(bsx.fi)).
 - Reduced-size encoding per RFC7011 does not apply, unless you are 
restricting them to 64, 32, 16, and 8.
[Med] There is no such restriction because of this part in the base spec:


   This behavior is indicated by the Exporter by specifying a size in

   the Template with a smaller length than that associated with the

   assigned type of the Information Element.

2. Neither unsigned64 nor unsigned192 are compatible with octetArray as used in 
this document, AFAICT
 - octetArray would be for a sequence of unsigned64s, for example,
 but not for bytes that might be interpreted in different ways 
depending on length

It would be useful to explain why the safe and unsafe options are split (i.e., 
to support reduced-size encoding when both are in use).
[Med] Added a note about this.

The only approach that I think is compatible with RFC7011 is:

 - use an octetArray and explain its length and mapping (e.g., of 
unsigned8 values), representing the values 0…256 as consecutive groups of 8, 
truncated when the remaining bytes are all zeros

[Med] This is not an option. All bitfield IEs in IPFIX are defined as unsigned 
data types.
OR
 - define safe as three unsigned64s, each potentially using 
reduced-size encoding
[Med] We already considered this in the past 
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/03/, 
but changed the design because Benoît Claise rightfully pointed to a an issue 
with reordering in IPFIX.

==
   *  Description: Observed UDP options of a Flow.  The information is
  encoded in a set of bit fields.  Multiple instances of the
  udpOptions IE are included to cover the 0-255 range (Figure 2);
  each 64 values are mapped to an IE with th order preserved.
  Options are mapped to bits according to their option numbers.
  Option number X is mapped to bit X[64] of the IE instance
  determined by the order "1+1[X/64]".  A bit is set to 1 (or 0) if
  the corresponding UDP option is observed (or not).  A udpOptions
  IE instance MAY be ommited if there is no ambiguity to determine
  the position of an observed UDP option.  For example, (1) if only
  option kinds =<63 are observed, then only one udpOptions IE
  instance is included, (2) if only option kinds =<127 are observed,
  then two udpOptions IEs instances are included, (3) if some option
  kinds =<63 while others are >=192 are observed, then four
  udpOptions IE instances are included with the second and third IE
  instances are both set to 0, etc.

   *  Abstract Data Type: unsigned64
==

See additional notes below.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com


On May 13, 2024, at 8:46 AM, 
mohamed.boucad...@orange.com wrote:

Hi Joe,

Thank you for the excellent review.

The changes to address the review can be seen here: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt_2=https://boucadair.github.io/udp-ipfix/Joe-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt

Please see inline for more context.

Cheers,
Med


-Message d'origine-
De : Joseph Touch via Datatracker mailto:nore...@ietf.org>>
Envoyé : mercredi 8 mai 2024 06:06
À : int-...@ietf.org
Cc : 
draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org;
 last-
c...@ietf.org; opsawg@ietf.org
Objet : Intdir last call review of draft-ietf-opsawg-tsvwg-udp-
ipfix-08


Reviewer: Joseph Touch
Review result: Ready with Issues

Note that I previously