Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Randy Bush]

>> i just pushed -08 with what i believe to be all fixes from comments on
>> -07. it may be time to push the button on this one.
> Actually, Joe did that on 2023-11-29, and it is sitting in Rob
> Wilton's AD queue…

doh.  

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Warren Kumari]

On Sat, Jan 13, 2024 at 2:37 PM, Randy Bush  wrote:

> i just pushed -08 with what i believe to be all fixes from comments on
> -07. it may be time to push the button on this one.
>


Actually, Joe did that on 2023-11-29, and it is sitting in Rob Wilton's AD
queue…

W



> randy
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

Hi Adrian,
thank you for your kind consideration of my notes. Please find my follow-up
notes below tagged by GIM>>.

Regards,
Greg

On Fri, Jan 12, 2024 at 11:25 AM Adrian Farrel  wrote:

> Hi Greg,
>
>
>
> Thanks for your thoughtful inspection of our draft.
>
>
>
> Carlos and I wanted to be sure that all of the discussions of this draft
> were indexed on one list, and we wanted to avoid multiple copies going to
> people who are subscribed to multiple lists. So we asked that follow-ups
> went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC on
> this email.
>
GIM>> Thank you.

>
>
> It was certainly not our intent to disparage any work that was being done
> in any other working group, and I understand the effort that has gone into
> the DetNet OAM Framework to ensure that the terminology is clear and
> unencumbered in the DetNet context.
>
>
>
> Our concern was, however, that different contexts are applying different
> definitions of the terms “in-band” and “out-of-band”. Those definitions are
> (often) clear and precise, but they are not consistent across contexts.
> Thus, a water-tight definition in the DetNet context is not universally
> applicable, and a reader coming to DetNet from another context may bring
> with them their own understanding of the terms.
>
GIM>> Although the wording in the DetNet OAM Framework is indeed specific
for DetNet environment, for example, the reference to DetNet service
sub-layer and PREOF, the authors and the WG strived to make the definitions
generic. I believe that we achieved a reasonable level of generality
because the interpretation of "in-band/out-of-band" terminology in RAW OAM
was based on our work in DetNet. I believe that it could be a reasonable
way of building common understanding through a discussion of existing terms
instead of fork-lifting and trying to invent something different that has
not been used by any WG.

>
>
> Our intent, therefore, is to select a finer-grained set of terms that have
> universal applicability and that can be selected within a context without
> loss of generality.
>
GIM>> I agree with that wholeheartedly.

>
>
> This is a tricky little subject and I know that Carlos and I expected it
> to generate more than a little discussion. If we end up with “everything is
> OK and nothing needs to change” that will be OK with us. If we discover
> that some work is using terms too generally, while others already have
> perfect definitions, that will lead to something similar to this document
> to bring the good into the light.
>
>
>
> Further comments in line…
>
>
>
>
>
> *From:* Greg Mirsky 
> *Sent:* 12 January 2024 00:09
> *To:* Carlos Pignataro ; Adrian Farrel <
> adr...@olddog.co.uk>
> *Cc:* Ops Area WG ; IETF IPPM WG ; mpls <
> m...@ietf.org>; spring ; DetNet WG 
> *Subject:* Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"
>
>
>
>- Hi Carlos and Adrian,
>
> thank you for starting this work. I believe that having a common
> dictionary helps in having more productive discussions. I took the liberty
> of inviting all the WGs which you invited to review the document and added
> DetNet WG. Please feel free to trim the distribution list.
>
> I've read the document and have several general questions to start our
> discussion:
>
>- It seems that the motivation of this document is the assumption that
>"in-band OAM" and "out-of-band OAM" are not representative or cannot be
>understood or correctly attributed, interpreted by the IETF community. Is
>that correct?
>
> I think the wording here would be “cannot be reliably understood
> consistently”. That is, without looking at a context-specific definition
> (such as that which you supply in the DetNet OAM Framework), the use of the
> terms may be misinterpreted.
>
> This is an assertion, but one (we think) is founded on observation of
> recent conversations on mailing lists, and also of witnessing many years of
> people talking passed each other.
>
>- As we discuss and try to establish (change) the IETF dictionary, it
>is important to analyze the terminology used by other SDOs. I believe that
>it is beneficial to maintain consistent terminology which will minimize
>misunderstandings among experts with different experiences of working at
>different centers of technological expertise.
>
> This is a good point. It is certainly true that if other SDOs working with
> packet networks have established terminology that we can agree with and
> which is not, itself, subject to context-specific definitions, then there
> is no reason to choose other terms. Do you have any suggested sources?
>
IEEE 802.1Q 2014 uses in-band/out-of-band

> It is notable that the ITU-T has long worked with non-packet transport
> networks and has used the terms in-band and out-of-band. But even there we
> see some fragmentation with terms such as “in-fibre, but out-of-band”
> becoming necessary.
>
>- I that DetNet OAM Framework
>

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-common-ac-02

[Ebben Aries]

Thx Med for addressing my comments.  The updates look good to me.

/ebben

On 2024-01-11 14:30:09, mohamed.boucad...@orange.com wrote:
> [External Email. Be cautious of content]
> 
> 
> Hi Ebben,
> 
> Thank you for the review.
> 
> Updated the spec to take into account your comments as you can see at: 
> https://urldefense.com/v3/__https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-teas-common-ac_2=https:**Aboucadair.github.io*attachment-circuit-model*draft-ietf-opsawg-teas-common-ac.txt__;Ly8vLw!!NEt6yMaO-gk!DFSr2_ATQcCtt5PSDds7C4uS-HfuciT-F6O_lx3_dBJOFrX_WcRuzQ9NokZvhNBpfw0WB1Xwbh2xNcK3YEwuwywW$
> 
> Please see inline for more context.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Ebben Aries via Datatracker 
> > Envoyé : mercredi 10 janvier 2024 23:57
> > À : yang-doct...@ietf.org
> > Cc : draft-ietf-opsawg-teas-common-ac@ietf.org;
> > opsawg@ietf.org
> > Objet : Yangdoctors early review of draft-ietf-opsawg-teas-
> > common-ac-02
> >
> > Reviewer: Ebben Aries
> > Review result: On the Right Track
> >
> > 1 module in this draft:
> > - ietf-ac-com...@2023-11-13.yang
> >
> > YANG compiler errors or warnings (pyang 2.6.0, yanglint 2.1.128,
> > yangson 1.4.19)
> > - No compiler errors or warnings
> >
> > NOTE: This module was reviewed and validated (stub instance-data)
> > in conjunction with draft-ietf-opsawg-teas-attachment-circuit-03
> > and I did my best to separate comments out to each even though
> > validation crosses the 2 reviews
> >
> 
> [Med] Thank you.
> 
> > General comments on the draft:
> > - Section 3: There is reference to the tree and the tree being
> > too long but
> >   this module is solely groupings, identities and typedefs thus
> > there is no
> >   implementation of a standalone data tree in this common module.
> > Is this
> >   moreso in reference to a tree output that might include
> >   `--tree-print-groupings` as seen in a subsequent section?
> 
> [Med] Yes because we were assuming that the reader is familiar with 
> rfc8340#section-3.2. Added a note to make this explicit.
> 
> > - Section 4: Move the "file" declaration in  up to
> > align and
> >   quote "ietf-ac-com...@2023-11-13.yang" otherwise published IETF
> > tooling will
> >   fail to parse correctly
> 
> [Med] Fixed.
> 
> >
> > General comments on the module:
> > - Suggestion: Insert appropriate line breaks throughout module
> > statements for
> >   readability
> 
> [Med] I think that we are already following the practices for published 
> modules in that matter: no line breaks inside the groupings/containers.
> 
> > - L#509: must statement needs to qualify identities as 'ac-
> > common:slaac' and
> >   'ac-common:provider-dhcp-slaac' otherwise the imports/uses will
> > assume
> >   localization (Suggest auditing all 'when' and 'must' statements
> > that
> >   reference identities to ensure full qualification for any
> > future imports)
> 
> [Med] Fixed.
> 
> > - L#1329: Address/remove comment
> 
> [Med] Fixed.
> 
> > - L#1404: s/type\{/type \{/
> 
> [Med] Fixed.
> 
> > - Minor nit: s/Indciates/Indicates/ -> "Indciates the actual date
> > and time
> >   when the service"
> 
> [Med] Fixed.
> 
> > - For "vlan-id" related leaves, should these be scoped in the
> > uint16 space?
> 
> [Med] Yes, they should. Thanks for catching this. Fixed.
> 
> > - For the `pseudowire` and `vpls` groupings, there is a
> > duplication of nodes.
> >   Does it make sense to consolidate as much as possible and only
> > diverge where
> >   necessary?
> >
> 
> [Med] I don't think there is value to do that here as we only have one common 
> leaf. Thanks.
> 
> 
> 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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Randy Bush]

i just pushed -08 with what i believe to be all fixes from comments on
-07.  it may be time to push the button on this one.

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-08.txt

[internet-drafts]

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

   Title:   Finding and Using Geofeed Data
   Authors: Randy Bush
Massimo Candela
Warren Kumari
Russ Housley
   Name:draft-ietf-opsawg-9092-update-08.txt
   Pages:   26
   Dates:   2024-01-13

Abstract:

   This document specifies how to augment the Routing Policy
   Specification Language inetnum: class to refer specifically to
   geofeed comma-separated values (CSV) data files and describes an
   optional scheme that uses the Resource Public Key Infrastructure to
   authenticate the geofeed data files.  This document obsoletes RFC
   9092.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-9092-update-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-9092-update-08

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


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Intdir early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Dirk Von Hugo via Datatracker]

Reviewer: Dirk Von Hugo
Review result: Ready with Nits

Hello,
I am an assigned INT directorate reviewer for
draft-ietf-opsawg-ipfix-tcpo-v6eh. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
 Based on my review, if I was
on the IESG I would ballot this document as NO OBJECTION.

Although not being an expert on OPSAWG I agrre that the document is helpful
forhandling IPv6 extension headers and TCP options. I agree with prior
reviewers that IPFIX RFCs should be referenced already in sect. 1 as well as
maybe the corresponding draft draft-ietf-opsawg-ipfix-fixes on further details
on the described issues, if I understood it correctly. In addition the
following very minor nits should be corrected:

p.3:
Cover the full extension headers range => Cover the full extension headers'
range which do no correspond => which do not correspond

p.4:
these limitations can't be addressed  these limitations cannot be addressed

p.5:
packet of this Flow contained the respective => packet of this Flow contains
the respective

p.8:
these limitations can't be addressed =>  these limitations cannot be addressed

p.10:
that it does no support, => that it does not support,

p.12:
Let's consider a TCP Flow => Let us consider a TCP Flow

Thanks and best regards
Dirk


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg