Re: [netmod] MD5 in ianach ex-RFC7317

[Juergen Schoenwaelder]

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...

/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

Re: [netmod] MD5 in ianach ex-RFC7317

[Kent Watsen]

> 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. 

K.

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

Re: [netmod] MD5 in ianach ex-RFC7317

[tom petch]

From: Juergen Schoenwaelder 
Sent: 09 February 2021 17:12

On Tue, Feb 09, 2021 at 05:06:38PM +, Kent Watsen wrote:
> Hi Tom,
>
> > MD5 has long been deprecated as in RFC6151, RFC8573(NTP).
> >
> > The NTP YANG I-D, ntp-yang-data-model, imports ianach without any 
> > constraint and so goes against RFC8573.
> >
> > I think we should update ianach to deprecate MD5 by adding a status clause. 
> >  This is a permitted update per YANG and the module is Expert Review so I 
> > believe that with the consensus of the NETMOD WG, IANA could be asked to 
> > add 'status deprecated' to MD5.
> >
> > Thoughts?
>
> I agree, but it takes an I-D to do the update, yes?

I believe the process is that someone submits an update request to
IANA and IANA will then contact the Expert for Review and then the
Expert does whatever she does. "The designated expert is not required
to personally bear the burden of evaluating and deciding all requests,
but acts as a shepherd for the request, enlisting the help of others
as appropriate." (RFC 5226, BCP 26)


I agree but think the Expert Reviewer, as appointed by IANA, would be helped 
along their way if they had the consensus of the NETMOD WG in favour of this.

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

Re: [netmod] MD5 in ianach ex-RFC7317

[Juergen Schoenwaelder]

On Tue, Feb 09, 2021 at 05:06:38PM +, Kent Watsen wrote:
> Hi Tom,
> 
> > MD5 has long been deprecated as in RFC6151, RFC8573(NTP).
> > 
> > The NTP YANG I-D, ntp-yang-data-model, imports ianach without any 
> > constraint and so goes against RFC8573.
> > 
> > I think we should update ianach to deprecate MD5 by adding a status clause. 
> >  This is a permitted update per YANG and the module is Expert Review so I 
> > believe that with the consensus of the NETMOD WG, IANA could be asked to 
> > add 'status deprecated' to MD5.
> > 
> > Thoughts?
> 
> I agree, but it takes an I-D to do the update, yes?

I believe the process is that someone submits an update request to
IANA and IANA will then contact the Expert for Review and then the
Expert does whatever she does. "The designated expert is not required
to personally bear the burden of evaluating and deciding all requests,
but acts as a shepherd for the request, enlisting the help of others
as appropriate." (RFC 5226, BCP 26)

/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

Re: [netmod] MD5 in ianach ex-RFC7317

[tom petch]

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

Hi Tom,

> MD5 has long been deprecated as in RFC6151, RFC8573(NTP).
>
> The NTP YANG I-D, ntp-yang-data-model, imports ianach without any constraint 
> and so goes against RFC8573.
>
> I think we should update ianach to deprecate MD5 by adding a status clause.  
> This is a permitted update per YANG and the module is Expert Review so I 
> believe that with the consensus of the NETMOD WG, IANA could be asked to add 
> 'status deprecated' to MD5.
>
> Thoughts?

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.

Tom Petch
K.



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

Re: [netmod] MD5 in ianach ex-RFC7317

[Kent Watsen]

Hi Tom,

> MD5 has long been deprecated as in RFC6151, RFC8573(NTP).
> 
> The NTP YANG I-D, ntp-yang-data-model, imports ianach without any constraint 
> and so goes against RFC8573.
> 
> I think we should update ianach to deprecate MD5 by adding a status clause.  
> This is a permitted update per YANG and the module is Expert Review so I 
> believe that with the consensus of the NETMOD WG, IANA could be asked to add 
> 'status deprecated' to MD5.
> 
> Thoughts?

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

K.


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

[netmod] YANG Versioning Weekly Call Minutes - 2021-02-09

[Sterne, Jason (Nokia - CA/Ottawa)]

YANG Versioning Weekly Call Minutes - 2021-02-09

Agenda bashing:
- drive to updated YANG Versioning and Semver drafts (deadline is ~2 weeks)
- Balazs & T1 (state & NBC)
- whitespace
- 3GPP / ORAN update

Updates to YANG Versioning:
- T3: filenames & chars: [Reshad] update draft & send to Weekly Call Group
- T2: [Rob] to do a pull request with draft text & to NETMOD list
- Import by revision: impact of changing import statements: did we post back to 
the WG?  Said it was BC (but you can mark it NBC if you wanted to)
- NBC/BC for config false
- Prio 2: [Reshad] see if any other github issues are closed and could be 
folded in

[Balazs] NBC/BC for Config false:
- reduce value space for optional or mandatory nodes is BC.
- increasing value space (within the type) for optional or mandatory nodes is 
BC.
- type change is NBC
- optional->mandatory is BC.  mandatory->optional is NBC.
- systems can be more tolerant to state changes, no validation on outgoing state
- trying to accomodate what most clients can handle (otherwise too many changes 
will be flagged NBC, too much noise)
- be strict with NBC in config, but less strict in state
- draft document text, pass snippets to the WG

[Jason] Put this under definition of NBC marker:
- changes can be marked NBC any time if the author thinks there is a compat. 
issue that impacts most clients

[Jan] Whitespace:
- publisher (in the act of publishing) would always give a new version #
- what if a user (non-owner) of a module adds annotations (e.g. yang 
extensions, comments), etc (e.g. aids for GUI generation).  What is the 
version/label of that derived result?  It is a different version or even a 
different module (different entity than the original owner).
- can you republish module with same date making some whitespace changes. No. 
You must give a new version.
- publish with linux then republish with dos: different versions.
- how to define/describe publish ?
- tools may say that 2 versions have no changes (if the tool ignores whitespace 
and line endings).  But that's acceptable.

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

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

[Reshad Rahman]

Tried pyang and yanglint.

pyang warns about filename: should consist of "[_A-Za-z][._\-A-Za-z0-9]*" (see 
warning below).  

yanglint warns about mismatch between filename and module name also.

Basically, both accept the characters we want to allow, they treat @ as 
delimiter for the module-name and don’t recognize # as such (as expected).

 

Regards,

Reshad 

$ pyang test#1.0.0.yang  
test#1.0.0.yang:1: warning: filename "test#1.0.0.yang" suggests invalid module 
name "test#1.0.0", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#{1\,0\,\0}.yang 
test#{1,0,0}.yang:1: warning: filename "test#{1,0,0}.yang" suggests invalid 
module name "test#{1,0,0}", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#{1.0.0}.yang
test#{1.0.0}.yang:1: warning: filename "test#{1.0.0}.yang" suggests invalid 
module name "test#{1.0.0}", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#1.0.0+.yang
test#1.0.0+.yang:1: warning: filename "test#1.0.0+.yang" suggests invalid 
module name "test#1.0.0+", should match "[_A-Za-z][._\-A-Za-z0-9]*"

 

$ yanglint test#1.0.0.yang
libyang warn: File name "test#1.0.0.yang" does not match module name "test".

$ yanglint test#{1\,0\,0}.yang  
libyang warn: File name "test#{1,0,0}.yang" does not match module name "test".

$ yanglint test#{1.0.0}.yang   
libyang warn: File name "test#{1.0.0}.yang" does not match module name "test".

$ yanglint test#1.0.0+.yang  
libyang warn: File name "test#1.0.0+.yang" does not match module name "test".

 

Regards,

Reshad.

 

From: netmod  on behalf of Jan Lindblad 

Date: Wednesday, February 3, 2021 at 10:06 AM
To: "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-02-02

 

Tried out confdc/yanger behavior with filenames containing quirky characters. 
In order to make this somewhat realistic, I used a Darwin/MacOS (utf-8 aware) 
command line invoked with "double quoted" filenames, and a Makefile to do the 
building.

 

Category 1: Characters that just work

ascii-alphabetic numerals period comma _ + - ~ @ # % ^ : { } [ ]

Anything behind the @ is not considered part of the module name

 

Category 2: Characters that need to be specifically \ escaped in the shell, but 
then work

( ) ; & *

 

Category 3: Characters that need to be doubly escaped or similar, but then work

backtick space singlequote doublequote \ | $ ! ? * < > =

 

Category 4: Characters that do not work

forwardtick slash

non-ascii alphabetical (e.g. swedish, german, japanese characters)

 

Best Regards,

/jan

 

 

 

 



On 2 Feb 2021, at 23:46, Sterne, Jason (Nokia - CA/Ottawa) 
 wrote:

 

YANG Versioning Weekly Call Minutes - 2021-02-02

 

Agenda bashing:

- quick recap on 4 topics

- status of topics from previous interim

- updates needed to yang versioning and yang semver drafts

- whitespace

- continue through Github issues

 

Deadline on draft sunmissions is 3 weeks from now.  Try to get first cut in 2 
weeks max.

 

Summary of where we left off yesterday on the Virtual Interim topics:

 

T3:

- get feedback from WG on acceptable chars (especially highlight new ones)

- no semicolon

- 2 sets of files is acceptable, but systems will work with one in general

- try with a few tools ( Reshad to try pyang and yanglint, Jan try confd which 
includes yanger,

- someone try Yuma?  (or ask Andy?)

- try google tools ?  maybe not worth it

- Reshad to update draft with weekly call group & send updated snippets to WG

 

T2:

- Lou asked to post comments on list. People happy with direction being 
proposed.

- try drafting text to indicate when IANA owns a module vs a WG

- Rob to propose text to WG

 

T1:

- nobody objected to defining NBC rules for config false

- mix of opinions still?

- deleting a leaf is NBC (to stay in sync with 7950 on this point, and likely 
more common expectations)

- decreasing value space on optional leafs is BC (but decreasing it on 
mandatory leafs is NBC ?)

- this should also be considered in YANG NEXT

- rules we define need to separate optional vs mandatory elements

- Balasz to propose specific text to weekly call group first

 

T4:

- mostly aligned with slides

- not recommended having gaps or removing history, but we won't disallow it

- Joe to propose text to WG 

 

First interim topics:

(A) import by revision or derived

- not using revision-or-derived-compatible

- impact of changing import statements: did we post back to the WG?  Said it 
was BC (but you can mark it NBC if you wanted to)

- Reshad the draft with the results

 

(B) Whitespace

 

>From the first virtual interim:

 

   JS: we need to decide if the version represents 

   the file or the underlying YANG statements

   JC: no matter what we do, we’ll need YANG-aware 

   tooling (to go to the next level of analysis to 

   see if what actually changed in the API)

   JL: time is almost up. Summary: no clear consensus

 

- got rid of

[netmod] MD5 in ianach ex-RFC7317

[tom petch]

MD5 has long been deprecated as in RFC6151, RFC8573(NTP).

The NTP YANG I-D, ntp-yang-data-model, imports ianach without any constraint 
and so goes against RFC8573.

I think we should update ianach to deprecate MD5 by adding a status clause.  
This is a permitted update per YANG and the module is Expert Review so I 
believe that with the consensus of the NETMOD WG, IANA could be asked to add 
'status deprecated' to MD5.

Thoughts?

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