Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12

[Joe Clarke (jclarke)]

On T4 (gaps in revision numbers and revision history), I have some proposed 
text for both draft-ietf-netmod-yang-module-versioning and 
draft-ietf-netmod-yang-semver.  See these diffs (some changes are due to 
xml2rfc changes, but you'll note the more substantive text additions).  
Thoughts:

module-versioning : 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-module-versioning&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-module-versioning.txt

yang-semver : 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-semver&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-semver.txt

Joe

On 1/12/21 13:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
YANG Versioning Weekly Call Minutes - 2021-01-12

Topics and owners for Feb virtual interim:

Reshad - editor for YANG versioning draft
Jason - coordinate virtual interim, agenda. Do introduction at VI.

T1) Definition/meaning of BC vs NBC for config false nodes
https://github.com/netmod-wg/yang-ver-dt/issues/15
- Balazs

T2) IANA considerations: how are final RFC revision labels assigned ?
https://github.com/netmod-wg/yang-ver-dt/issues/59
- Rob

T3) YANG file naming when revision labels are being used (symbolic links? 
@) ?
- Reshad to prepare material, TBD to present/lead at VI

T4) SemVer: gaps in history, removing revision statements
https://github.com/netmod-wg/yang-ver-dt/issues/61
- Joe

We spent most of the time discussing Balazs' rules for backwards compatibility 
of config false nodes (T1 above):
- clients SHOULD be able to deal with (not crash) unexpected output
- some changes to config false nodes should be BC (increasing value space 
within the same type), some will be NBC (e.g. removing mandatory, changing type)
- the YANG author can mark a change that increases value space as NBC if they 
feel it is significant & breaks compatibility

We also talked briefly about Rob's proposal for IANA considerations (T2 above).
- we may also want some guidance for RFC editors (coordinate with authors on 
final SemVer for example)

Next week we'll continue focus on the four Virtual Interim topics.

Other topics we need to get back to at some point:
- whitespace
- github issues (left off at #15)

Jason


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

Re: [netmod] MD5 in ianach ex-RFC7317

[Juergen Schoenwaelder]

RFC 8407:

4.  YANG Usage Guidelines

   Modules in IETF Standards Track specifications MUST comply with all
   syntactic and semantic requirements of YANG 1.1 [RFC7950].

The rule you quoted does not apply since we are talking about an IANA
document.

/js

On Wed, Feb 10, 2021 at 05:25:26PM +, Kent Watsen wrote:
> 
> 
> > On Feb 10, 2021, at 11:46 AM, tom petch  wrote:
> > 
> > Not quite for me.  The current version is that on the IANA website, RFC7317 
> > is history at least for IANACH so I think that the YANG reference for the 
> > update should be to the IANA website.
> > 
> 
> Please provide OLD/NEW text.
> 
> FWIW, RFC8407 says:
> 
>A "revision" statement MUST be present for each published version of
>the module.  The "revision" statement MUST have a "reference"
>substatement.  It MUST identify the published document that contains
>the module.
> 
> So what is the “document”?
> 
> revision 2021-MM-DD {
>   description
> “Deprecated the 'crypt-hash-md5’ feature per RFC 6151.";
>   reference
> "RFC 6151:
>  Updated Security Considerations for the MD5
>  Message-Digest and the HMAC-MD5 Algorithms";
> }
> 
> But note that 6151 was published long before 7317 and, besides, it doesn’t 
> “deprecate” MD5.
> 
> We can’t reference 8573 because it's NTP-specific.  Perhaps iana-crypt-hash 
> is fine, and instead ntp-yang-data-model should be republished, augmenting in 
> the desired “status” while referencing 8573.
> 
> K.
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] MD5 in ianach ex-RFC7317

[Kent Watsen]

> On Feb 10, 2021, at 11:46 AM, tom petch  wrote:
> 
> Not quite for me.  The current version is that on the IANA website, RFC7317 
> is history at least for IANACH so I think that the YANG reference for the 
> update should be to the IANA website.
> 

Please provide OLD/NEW text.

FWIW, RFC8407 says:

   A "revision" statement MUST be present for each published version of
   the module.  The "revision" statement MUST have a "reference"
   substatement.  It MUST identify the published document that contains
   the module.

So what is the “document”?

revision 2021-MM-DD {
  description
“Deprecated the 'crypt-hash-md5’ feature per RFC 6151.";
  reference
"RFC 6151:
 Updated Security Considerations for the MD5
 Message-Digest and the HMAC-MD5 Algorithms";
}

But note that 6151 was published long before 7317 and, besides, it doesn’t 
“deprecate” MD5.

We can’t reference 8573 because it's NTP-specific.  Perhaps iana-crypt-hash is 
fine, and instead ntp-yang-data-model should be republished, augmenting in the 
desired “status” while referencing 8573.

K.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] MD5 in ianach ex-RFC7317

[tom petch]

From: Kent Watsen 
Sent: 10 February 2021 16:15

The more interesting bit is what IANA has to say about this registry:

iana-crypt-hash YANG Module RFC 7317
   Expert Review (Expert: Unassigned)

Perhaps we should focus more on finding a volunteer willing to take
the role of the Designated Expert...

I'm aware that IESG made a designation in 2019, but it's not reflected here.  
It appears to be just that IANA didn’t update the page, so I pinged them about 
that.



That is several steps ahead of us and, as and when it arises, that is the job 
of the IESG, not us.

The first task, for us or for the NTP WG (who want it to happen) or ... is to 
reach a consensus on whether or not the module is fit for purpose, or whether 
it needs updating.

This?

NEW:

 feature crypt-hash-md5 {
   status deprecated;
   description
 "Indicates that the device supports the MD5
  hash function in 'crypt-hash' values.";
   reference "RFC 1321: The MD5 Message-Digest Algorithm";
 }

And also:

 revision 2021-MM-DD {
   description
 “Deprecated the 'crypt-hash-md5’ feature.";
   reference
 "RFC 7317: A YANG Data Model for System Management";
 }

And publish the result as 
iana-crypt-h...@2021-mm-dd.yang

Works for me.


Not quite for me.  The current version is that on the IANA website, RFC7317 is 
history at least for IANACH so I think that the YANG reference for the update 
should be to the IANA website.

Tom Petch

Kent


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

Re: [netmod] MD5 in ianach ex-RFC7317

[Kent Watsen]

> 
> The more interesting bit is what IANA has to say about this registry:
> 
> iana-crypt-hash YANG Module RFC 7317
>Expert Review (Expert: Unassigned)
> 
> Perhaps we should focus more on finding a volunteer willing to take
> the role of the Designated Expert...

I'm aware that IESG made a designation in 2019, but it's not reflected here.  
It appears to be just that IANA didn’t update the page, so I pinged them about 
that.

> 
> 
> That is several steps ahead of us and, as and when it arises, that is the job 
> of the IESG, not us. 
> 
> The first task, for us or for the NTP WG (who want it to happen) or ... is to 
> reach a consensus on whether or not the module is fit for purpose, or whether 
> it needs updating.

This?
 
NEW:

 feature crypt-hash-md5 {
   status deprecated;
   description
 "Indicates that the device supports the MD5
  hash function in 'crypt-hash' values.";
   reference "RFC 1321: The MD5 Message-Digest Algorithm";
 }

And also:

 revision 2021-MM-DD {
   description
 “Deprecated the 'crypt-hash-md5’ feature.";
   reference
 "RFC 7317: A YANG Data Model for System Management";
 }

And publish the result as iana-crypt-h...@2021-mm-dd.yang

Works for me.

Kent

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

Re: [netmod] MD5 in ianach ex-RFC7317

[Kent Watsen]

> 
> It happens in the TLS WG, for example, where the registries of security 
> options are Expert Review and when an e-mail comes to IANA, which may be from 
> outside the IETF, the reviewers raise it on the TLS list and if they are 
> satisfied with the support, tell IANA to go ahead.

Gotcha.  Reviewer raises on list and returns result to IANA.  No I-D needed.

Thanks,
Kent

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

Re: [netmod] MD5 in ianach ex-RFC7317

[tom petch]

From: Kent Watsen 
Sent: 09 February 2021 17:47

I agree, but it takes an I-D to do the update, yes?


I don't see why; the registry is expert review and we are doing a change that 
comes under permitted changes for a YANG module, ie a status change.

My understanding is that a publication of a draft altering an IANA registry 
will trigger an “expert review”, if that registry was created with the 
update-policy set that way. The draft itself doesn’t request an expert review, 
the expert review happens in the background. I’m not familiar with this being 
done without an I-D, in order to show WG consensus.


It happens in the TLS WG, for example, where the registries of security options 
are Expert Review and when an e-mail comes to IANA, which may be from outside 
the IETF, the reviewers raise it on the TLS list and if they are satisfied with 
the support, tell IANA to go ahead.

No I-D needed, no decision for the WG Chair to make.  The whole point of Expert 
Review is to have a process which is not as heavy-weight as a (Standards Track) 
RFC.

Tom Petch

K.


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

Re: [netmod] MD5 in ianach ex-RFC7317

[tom petch]

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: 09 February 2021 19:10

On Tue, Feb 09, 2021 at 05:47:28PM +, Kent Watsen wrote:
>
> > I agree, but it takes an I-D to do the update, yes?
> >
> > 
> > I don't see why; the registry is expert review and we are doing a change 
> > that comes under permitted changes for a YANG module, ie a status change.
>
> My understanding is that a publication of a draft altering an IANA registry 
> will trigger an “expert review”, if that registry was created with the 
> update-policy set that way. The draft itself doesn’t request an expert 
> review, the expert review happens in the background. I’m not familiar with 
> this being done without an I-D, in order to show WG consensus.
>

My understanding is that IANA reviews all documents during the
publication process and while performing this review they will notice
that something is requested to be added/changed in a registry that
requires expert review and then they will go and run the procedure.

My understanding is this is _one_ way to make a request to IANA but
not the only way to make a request to IANA.

The more interesting bit is what IANA has to say about this registry:

iana-crypt-hash YANG Module RFC 7317
Expert Review (Expert: Unassigned)

Perhaps we should focus more on finding a volunteer willing to take
the role of the Designated Expert...


That is several steps ahead of us and, as and when it arises, that is the job 
of the IESG, not us. 

The first task, for us or for the NTP WG (who want it to happen) or ... is to 
reach a consensus on whether or not the module is fit for purpose, or whether 
it needs updating.

Tom Petch

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

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