[OPSAWG] FW: Comments on draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

[Thomas.Graf]

Dear Al,

Thank you very much for the review and the comments. Much appreciated. I merged 
them in the next -01 version as following:

https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt

Best wishes
Thomas

From: MORTON JR., AL 
Sent: Monday, October 31, 2022 2:22 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
benoit.cla...@huawei.com; i...@ietf.org
Subject: Comments on draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

Hi Thomas and Benoit,

I reviewed your draft at
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-inband-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt


I like the fact that you have appreciated the IPPM work and IPfix work that 
precedes your efforts.  This draft is fully useful in ippm and the OPSarea, IMO.

You might mention that Section 2 uses the template of RFC8911 and the 
Performance Metrics Registry. Your draft is the first to adopt this template – 
now that the RFC is fully published!

I’ll add some notes as I scan through:

End of 2.3.1
   The Traffic Filter at the OP is configured to observe a single IP
   connection.
We don’t have connections at the IP-layer, only a stream of datagrams...

BTW, when I used the simplifying convention of
2.4.2.5.  Metric Units

   The  of one-way delay is expressed in seconds, where
is one of:

   *  Mean
...

in RFC 8912, I ultimately had to help IANA prepare complete and separate 
sections for each . So, while I completely agree with re-using the 
 simplification in the draft, be prepared to create the 4 new 
versions of Section 2, one for each , when this eventually reaches 
IANA for implementation. 

and that’s it for now!

I can easily see how much research and work you have committed to this draft. 
There seem to be some other comments to address, but the solutions appear 
within reach.

regards,
Al




smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Status of T+/TLS work

[heasley]

Mon, Oct 31, 2022 at 04:59:33PM +, Joe Clarke (jclarke):
> Thanks for the summary, heas.
> 
> I re-read the text, and, yes, you do cover a number of the situations 
> (including potential ways to handle clients with TLS going forward).  On 
> another doc I reviewed as part of the OPS DIR, it was decided that grouping 
> text about (in that case) forward-looking considerations was worth it.
> 
> In this case, the document is short, and perhaps that isn’t needed.  I defer 
> to the general views of the WG and the authors on this.

Super; thanks!  I will publish the current version with the other fixes that
you requested later today.

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

Re: [OPSAWG] Status of T+/TLS work

[Joe Clarke (jclarke)]

Thanks for the summary, heas.

I re-read the text, and, yes, you do cover a number of the situations 
(including potential ways to handle clients with TLS going forward).  On 
another doc I reviewed as part of the OPS DIR, it was decided that grouping 
text about (in that case) forward-looking considerations was worth it.

In this case, the document is short, and perhaps that isn’t needed.  I defer to 
the general views of the WG and the authors on this.

Joe

From: heasley 
Date: Thursday, October 20, 2022 at 14:14
To: Joe Clarke (jclarke) 
Cc: draft-ietf-opsawg-tacacs-tl...@ietf.org 
, opsawg@ietf.org 
Subject: Re: Status of T+/TLS work
Tue, Oct 18, 2022 at 12:14:39PM +, Joe Clarke (jclarke):
> Hello, authors.  Ahead of IETF 115, we’d like to get an update on the status 
> of this work.  Since adoption, on-list traffic has been silent (though there 
> has been discussion on the SSH work).
>
> I believe there are still some outstanding edits to make on this work based 
> on adoption feedback, and we’d like to continue to progress this.  When do 
> you think you’ll have a -01 ready for review?

Hey Joe,  You had raised 3 questions/requests.  Of these, we have addressed
two in unpublished text, but the third we find ourselves unsure about what
you want.

You'd asked for an operators considsrations sections.  More specifically,
fallback to legacy T+ and migration to certificates.  We feel that some,
perhaps most, of this is covered in various sections of the current
document, particularly the security considerations section.

So, we want to ask if the existing text is sufficient (excluding the
omission of migration to certificates) or if you would like duplication of
these detail in an operations consideration section?  We also considered
splitting the Security considerations section, trying to separate ops from
implementation.  There also might be opportunity to point to existing
documents.  Please guide us.

Alan DeKok raised two TLS-related questions.  No one else commented about
these, so we are asking some other TLS experts to comment.

Douglas is drafting a more complete description of the alternative SSH
pubkey syntax & process, to which WG response was more positive than the
original proposal.

We have not received any comments besides what was on the WG maillist.  We
have solicited comment from a few vendors about both drafts, which has been
positive and supports the approach of limiting change, compared to
re-engineering the protocol for a more modern approach.

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