Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

[Kenneth Vaughn]

All of the edits related to idnits have been addressed in 
draft-ietf-opsawg-tlstm-update-10. As discussed below, I tweaked the wording 
for SnmpTLSAddress to require conformance to 1123 and 5890 when it is intended 
to represent  a hostname and I made those normative references. The only issues 
that the indits tool shows now are two "comments" about obsolete informational 
references, but these references are needed because:
1. The definition of the proposed hash table needs to reference RFC 5246 
2. The revision history of the MIB contains a revision clause that indicates it 
originated in RFC 5953

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com

> On Oct 7, 2022, at 8:25 AM, Joe Clarke (jclarke)  wrote:
> 
> I’ve always been told (and it makes sense) that one must understand normative 
> references so to implement the given spec.
>  
> This is a weird case.  The TLS address doesn’t need to be a hostname and, if 
> it is, it doesn’t need to be an i18n hostname.  So, one wouldn’t need to 
> understand RFCs 1123 and 5890 to implement this spec if they only used IP 
> addresses.
>  
> But for completeness, I would recommend doing option #4 below (as you added 
> normative language to v4 and v6 addresses already).
>  
> Joe
>  
> From: Kenneth Vaughn mailto:kvau...@trevilon.com>>
> Date: Thursday, October 6, 2022 at 4:27 AM
> To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
> Cc: opsawg@ietf.org   >, tom petch  >
> Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
> 
> Joe, et al.
>  
> I am working in a draft that includes the text suggested by Tom (e..g, "This 
> module makes reference to"). I have also ensured that the list of references 
> is accurate and properly classified between normative and informative.  While 
> doing this, I noticed that RFC 6353 seems to treat two RFCs differently, 
> despite the text referring to them in a similar fashion. Specifically, the 
> MIB contains the following text, which is repeated in the updated MIB:
>  
> A hostname is always in US-ASCII (as per RFC 1123); internationalized 
> hostnames are encoded as A-labels as specified in  
> RFC 5890. 
> 
> Neither of these RFCs are referenced in any other way in RFC 6353, but RFC 
> 1123 is listed as a normative reference while RFC 5890 as an informative 
> reference. It seems to me that the two documents should be referenced in the 
> same fashion, but I am not sure which type is most correct. A basic reading 
> of the text implies that this is just an informative fact; but I believe the 
> intent is that the "is always" and "are" expressions are intended to be "MUST 
> be" expressions - and parallel the prior paragraphs that describe IPv4 and 
> IPv6 addresses. So I see the following options; I know what ISO would like, 
> but I am interested in hearing which option is the best to conform with IETF 
> rules...
> 1) leave as is (i.e., no change to MIB module, keep RFC 1123 as normative and 
> EFC 5890 as informative)
> 2) no change to MIB module, make both RFC 1123 and RFC 5890 normative
> 3) no change to MIB module, make both RFC 1123 and RFC 5890 informative
> 4) Replace the "is always" and "are" in the text above with "MUST be" and 
> make both RFC 1123 and RFC 5890 normative
>  
> Thanks for your advice
> 
> Regards,
> Ken Vaughn
>  
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-571-331-5670 cell
> kvau...@trevilon.com 
> www.trevilon.com 
> 
> 
> On Oct 5, 2022, at 4:53 AM, tom petch  > wrote:
>  
> From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
> behalf of Joe Clarke (jclarke)  >
> Sent: 04 October 2022 17:45
> 
> Thanks, Ken.  I saw your updates, and I agree with you on 5246.
> 
> But now that I am done with my shepherd write-up, I notice that there are a 
> slew of references in the MIB that are not reflected in the document 
> references (e.g., 1123, 5890, etc.).  Given that the full MIB is included in 
> this new document, you should include the same references in the Norm/Inform.
> 
> 
> This has been a problem with YANG for years and the accepted solution is to 
> include a section 4.1 'This module makes references to [RFC1123], [RFC5890] 
> etc '
> 
> Consistency with YANG would be good:-)
> 
> Tom Petch
> 
> Joe
> 
> From: Kenneth Vaughn mailto:kvau...@trevilon.com>>
> Date: Tuesday, October 4, 2022 at 10:37
> To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
> Cc: opsawg@ietf.org   >
> Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
> I've updated the document; the only items that remain in the id-nits check 
> 

[OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Updates to the TLS Transport Model for SNMP
Author  : Kenneth Vaughn
  Filename: draft-ietf-opsawg-tlstm-update-10.txt
  Pages   : 32
  Date: 2022-10-08

Abstract:
   This document updates RFC 6353 "Transport Layer Security (TLS)
   Transport Model for the Simple Network Management Protocol (SNMP)",
   to reflect changes necessary to support Transport Layer Security
   Version 1.3 (TLS 1.3) and Datagram Transport Layer Security Version
   1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".  This
   document is compatible with (D)TLS 1.2 and is intended to be
   compatible with future versions of SNMP and (D)TLS.

   This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.


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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-10.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-10


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

Re: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code point allocation

[Joe Clarke (jclarke)]

Sure, this would be fine.  And I’ve seen the back and forth with IANA.

Joe

From: thomas.g...@swisscom.com 
Date: Saturday, October 8, 2022 at 2:28 AM
To: Joe Clarke (jclarke) , opsawg-cha...@ietf.org 

Cc: opsawg@ietf.org , pierre.franc...@insa-lyon.fr 
, benoit.cla...@huawei.com 

Subject: RE: draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code 
point allocation
Dear Joe,


My apology for late reply. That works for us.



We are in touch with IANA and the IPFIX doctors to clarify the points raised by 
Med in regards to the srhFlagsIPv6 and the srhSegmentEndpointBehavior registry. 
Once this has been clarified we will publish -02 version.



We would like to request a 15min slot for IETF 115 to present an update on the 
latest document updates and some feedback on two running code implementations 
from the hackathon where we use IPFIX entities from the PEN space. Could we 
raise the question to the WG in this slot wherever we have consensus that early 
allocation is warranted or not?



Best wishes

Thomas

From: Joe Clarke (jclarke) 
Sent: Friday, September 23, 2022 7:49 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
opsawg-cha...@ietf.org
Cc: opsawg@ietf.org; pierre.franc...@insa-lyon.fr
Subject: Re: draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code 
point allocation

Hey, Thomas.  I’m a wee bit nervous declaring stability since IETF 115 hasn’t 
happened yet, but I do think you’re on track, and I can request of the WG their 
thoughts as to whether there is consensus that early allocation is warranted.

So, I think a, b, and d from Section 2 are met (speaking for ADs on d).  I just 
want to make sure we’re not bit by anything at the ‘thon at 115.

In terms of process, once we are satisfied that c is met, it is on us (chairs) 
to request approval from the ADs.  You do not need to contact IANA.  If this is 
approved, we will make that request.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Date: Friday, September 23, 2022 at 8:27 AM
To: opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>
Cc: opsawg@ietf.org 
mailto:opsawg@ietf.org>>, 
pierre.franc...@insa-lyon.fr 
mailto:pierre.franc...@insa-lyon.fr>>
Subject: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early 
code point allocation
Dear OPSAWG chairs,

We believe that the draft is reaching stable state. At IETF 115 hackathon in 
November we will have one open-source and one closed-source implementation of 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Therefore we believe we are satisfying the conditions for early allocation of 
code points as described 
https://www.rfc-editor.org/rfc/rfc7120#section-2.

With your permission we would like to go ahead an get in contact with IANA and 
clarify Med's comments on the

srhFlagsIPv6
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.1

and

srhSegmentEndpointBehavior
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.11

registry commented at 

[OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11

[Qin Wu]

Hi, authors:
I have read the latest version of this draft, it is well written, thank for 
that.
Here is the identified minor issues during document shepherd review of 
draft-ietf-opsawg-sbom-access-11:

1.   Abstract said:
"
It may optionally be discovered through manufacturer usage descriptions.

"

[Qin] This sentence is not clear. Are you saying MUD extensions transparency 
can be discovered using extensions defined in section 3.9 of RFC8520?
Or software transparency and vulnerability information can be discovered by 
using ACL example defined in section 5.4 of this draft? I assume it is the 
latter. Please clarify.


2.   Section 1 said:
"
   The mechanisms specified in this document are meant to satisfy
   several use cases:

   *  A network-layer management system retrieving information from an
  IoT device as part of its ongoing lifecycle.  Such devices may or
  may not have query interfaces available.

"
[Qin] How many use cases do we specify here? I believe it is two, how about be 
specific about the number of use cases here, s/several use cases/the following 
two use cases


3.   Section 1 said:
"   In the first case, devices will have interfaces that permit direct
   retrieval.  Examples of these interfaces might be an HTTP 
[RFC9110],
   or COAP [RFC7252] endpoint 
for retrieval.  There may also be private
   interfaces as well.

   In the second case, when a device does not have an appropriate
   retrieval interface, but one is directly available from the
   manufacturer, a URI to that information MUST be discovered.

   In the third case, a supplier may wish to make an SBOM or
   vulnerability information available under certain circumstances, and
   may need to individually evaluate requests.  The result of that
   evaluation might be the SBOM or vulnerability itself or a restricted

"
[Qin] I believe the first case, the second case, the third case are 
corresponding to three ways to discover object instead of two key use cases 
listed in section 1? Therefore there are confusing to be introduced here.

I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method


4.  Section 1.1

[Qin] s/in either/either in

5.  Section 1.1 said:

" The MUD semantics provide a way for manufacturers

to control how often tooling should check for those changes through

the cache-validity node. "

[Qin] Can you provide a reference section in RFC8520 about such MUD semantics.

6.  Section 3 N.B.

[Qin] What N.B. stands for? Can you provide a reference or change in other 
words.

7.  Section 5.4 said:

" 
5.4.
  With ACLS



Finally, here is a complete example where the device provides SBOM

and vulnerability information, as well as access-control information.



{

"ietf-mud:mud": {

"mud-version": 1,

"extensions": [
"ol",

"transparency"
], "


[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other words, how 
sbom access work together with Ownership and licensing statements in YANG 
described in draft-ietf-opsawg-ol-01.

If 'ol' extension is needed, I think a informative reference is needed here.


8.  Section 6 said:

"N.B., for MUD, the mandatory method of retrieval is TLS. "

[Qin] New fashion of acronym,:)


9.  Section 6 said:

"

One example may be to issue a certificate to the client for

this purpose after a registration process has taken place.  Another

example would involve the use of OAUTH in combination with a
federations of SBOM servers. "

[Qin] I feel there is disconnection between the fifth sentence and the sixth 
sentence in the paragraph 9 . Two examples are provided here, I am wondering 
which security risk are addressed by which example?



10. Section 6 said:

"

Vulnerability information is generally made available to such

databases as NIST's National Vulnerability Database. "

[Qin] Do we need to list the Database Name developed by specific entity in the 
security section as normative text?



11. Do we have implementation that pertains to this draft?

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

Re: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code point allocation

[Thomas.Graf]

Dear Joe,


My apology for late reply. That works for us.



We are in touch with IANA and the IPFIX doctors to clarify the points raised by 
Med in regards to the srhFlagsIPv6 and the srhSegmentEndpointBehavior registry. 
Once this has been clarified we will publish -02 version.



We would like to request a 15min slot for IETF 115 to present an update on the 
latest document updates and some feedback on two running code implementations 
from the hackathon where we use IPFIX entities from the PEN space. Could we 
raise the question to the WG in this slot wherever we have consensus that early 
allocation is warranted or not?



Best wishes

Thomas

From: Joe Clarke (jclarke) 
Sent: Friday, September 23, 2022 7:49 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
opsawg-cha...@ietf.org
Cc: opsawg@ietf.org; pierre.franc...@insa-lyon.fr
Subject: Re: draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code 
point allocation

Hey, Thomas.  I'm a wee bit nervous declaring stability since IETF 115 hasn't 
happened yet, but I do think you're on track, and I can request of the WG their 
thoughts as to whether there is consensus that early allocation is warranted.

So, I think a, b, and d from Section 2 are met (speaking for ADs on d).  I just 
want to make sure we're not bit by anything at the 'thon at 115.

In terms of process, once we are satisfied that c is met, it is on us (chairs) 
to request approval from the ADs.  You do not need to contact IANA.  If this is 
approved, we will make that request.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Date: Friday, September 23, 2022 at 8:27 AM
To: opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>
Cc: opsawg@ietf.org 
mailto:opsawg@ietf.org>>, 
pierre.franc...@insa-lyon.fr 
mailto:pierre.franc...@insa-lyon.fr>>
Subject: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early 
code point allocation
Dear OPSAWG chairs,

We believe that the draft is reaching stable state. At IETF 115 hackathon in 
November we will have one open-source and one closed-source implementation of 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Therefore we believe we are satisfying the conditions for early allocation of 
code points as described 
https://www.rfc-editor.org/rfc/rfc7120#section-2.

With your permission we would like to go ahead an get in contact with IANA and 
clarify Med's comments on the

srhFlagsIPv6
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.1

and

srhSegmentEndpointBehavior
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.11

registry commented at 
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/pull/15/commits/470424596d9eeaa368a497a1a53f19573b764df9

first and then go ahead with the IPFIX entity early allocation.

Best wishes
Thomas


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