Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 7 Mar 2022 17:10:53 +0100

Kent,

I have posted -12, which fixes the bugs that have been reported to me
and removes the percentage types.

I have also removed the revision-identifier type since it is better
defined in the YANG versioning module (and it should be called
revision-date and not revision-identifier). This change was not
suggested during the last call, I only noticed that this definition
could be moved while reviewing the YANG versioning I-Ds over the
weekend. This change probably requires a check with the WG. (If we
were to put it back, I would still suggest to call it revision-date as
this is also how this thing is called in RFC 7950).

/js

On Mon, Feb 28, 2022 at 11:34:19PM +0000, Kent Watsen wrote:
> Thank you everyone that participated, the Last Call for this draft is closed successfully!
> 
> Authors, please let the chairs know when the issues have been resolved and the draft is ready to be progressed for IESG review.
> 
> Kent
> 
> 
> 
> > On Feb 3, 2022, at 9:54 PM, Kent Watsen <[email-masked]> wrote:
> > 
> > Dear NETMOD WG,
> > 
> > This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th.  Here is a direct link to the HTML version of the draft:
> > 
> > 	https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html
> > 
> > Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.
> > 
> > Thank you,
> > Kent (as co-chair)
> > 
> > _______________________________________________
> > netmod mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Björklund <[email-masked]>
Date: Tue, 08 Mar 2022 09:52:23 +0100 (CET)

Hi,

While reviewing draft-ietf-opsawg-sap-02, I had to study the type
inet:uri again.

I assume that the type "uri" is supposed to mean the type that is
defined by the ABNF rule "URI" in RFC 3986.  If my assumption is
correct I think we should make this clear in 6991bis.  If my
assumption is not correct, then we definitely should add some text
that describes what is meant.

Since (?) inet:uri is defined simply as "string" w/o any pattern, some
RFCs have been published with URIs such as "D1" and "1-0-1" (RFC
8345).

/martin

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 8 Mar 2022 10:01:56 +0100

Martin,

the problem is finding a pattern that is guaranteed to not exclude
anything valid and which is simple enough to be understood and put in
a YANG module. People on the Internet tried to literally capture the
ABNF rules of RFC 3986 leading to regular expression monsters.

I am open for concrete suggestions. ;-)

/js

---

From: Martin Björklund <[email-masked]>
Date: Tue, 08 Mar 2022 11:20:57 +0100 (CET)

Hi,

You didn't answer my first question about what we actually mean - do
we mean the "URI"

I agree with you re the problem with pattern in this case.

The simplest pattern would be:

      pattern "[a-z][a-z0-9+.-]*:.*"; // matches the mandatory scheme

but I think you will say that either we have a complete correct
pattern, or no pattern at all ;-)

/martin

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 8 Mar 2022 12:00:18 +0100

> You didn't answer my first question about what we actually mean - do

        "The uri type represents a Uniform Resource Identifier
         (URI) as defined by STD 66. [...]"

STD 66 resolves to RFC 3986. Maybe I do not understand your question.
 
> pattern, or no pattern at all ;-)

I personally do not believe that a pattern needs to catch every
nuance. The only requirement is that a pattern must not reject any
valid values. For me, the description ultimately defines the type and
a pattern merely helps to catch some of the syntactic details in an
automated fashion.

My experience is that people have different ideas about how many
details a pattern should capture and hence pattern have a tendency to
grow increasingly complex over time.

I am happy to add the proposed pattern since covering the scheme part
is apparently better than having nothing (but I am sure this will be
the beginning of a journey and not its end).

/js

---

From: Martin Björklund <[email-masked]>
Date: Tue, 08 Mar 2022 12:12:36 +0100 (CET)

> STD 66 resolves to RFC 3986. Maybe I do not understand your question.

RFC 3986 defines the syntax for "URI" and "URI-reference", see
specifically section 4 and 4.1 of RFC 3986.  To avoid confusion, I
suggest:

     "The uri type represents a Uniform Resource Identifier
      (URI) as defined by the rule 'URI' in RFC 3986.

or "the ABNF rule 'URI'..."

(side note, is it better to refer to STD 66 rather than the RFC?)

/martin

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 8 Mar 2022 12:25:17 +0100

> or "the ABNF rule 'URI'..."

OK
 
> (side note, is it better to refer to STD 66 rather than the RFC?)

I have no idea. Since this is the only usage of STD in the document
(ignoring the references), I am fine to replace it with an RFC
reference. (The description has been "inherited" from the Uri TC
description in RFC 5017 and it used STD 66.)

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Mar 2022 23:33:44 +0000

All,

1) If you provided WGLC comments on this draft, please review the -12 diff <https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt> to ensure that the updates made are good.

2) Juergen notes below that he also removed the "revision-identifier" typedef, as it is better
defined in the YANG versioning module.  Any objections?

On both points above, if no objections are raised in the next week, we'll assume consensus to move forward.

Juergen, you will be posting a -13 containing Martin's URI "pattern" statement when the submission window reopens?

Kent // as co-chair and shepherd

> On Mar 7, 2022, at 11:10 AM, Jürgen Schönwälder <[email-masked]> wrote:
> 
> Kent,
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Mar 2022 17:21:01 -0700

On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen <[email-masked]> wrote:

> All,
>
> 1) If you provided WGLC comments on this draft, please review the -12 diff
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt> to
> ensure that the updates made are good.
>
Sorry for the late comment.
I think Juergen listed one option as "rename to revision-date and leave it
in this module".
I support this option.

There is no chance that the revision date format will be changing any time
soon.
This is useful for general applications because revision date is widely
used.

Andy

> Juergen, you will be posting a -13 containing Martin's URI "pattern"
> statement when the submission window reopens?
>
> On Mar 7, 2022, at 11:10 AM, Jürgen Schönwälder <
> [email-masked]> wrote:
>
> Kent,
>
> Authors, please let the chairs know when the issues have been resolved and
> the draft is ready to be progressed for IESG review.
>
> Kent
>
>
>
> This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11
> ending on Friday, February 18th.  Here is a direct link to the HTML version
> of the draft:
>
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
>
> Thank you,
> Kent (as co-chair)
>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 15 Mar 2022 14:01:37 +0100

> This is useful for general applications because revision date is widely

The ietf-yang-library module (RFC 8525) currently uses its own
definition of revision-identifier. While this module could adopt a
common definition, the value of such a change is minor.

The question where we place the definition of revision-date is likely
a matter of which role we expect the versioning work to play in the
future. I am relatively neutral on the placement.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Mar 2022 08:42:31 -0700

On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
[email-masked]> wrote:

> > > <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt> to
Not that important I guess.
One would think the "date" typedef already in the draft would be useful,
but it isn't, and therefore not used.
There is no typedef for the pattern YYYY-MM-DD.

/js

Andy

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 22 Mar 2022 08:11:33 +0100

So we have the following options:

a) Leave revision-date to be defined in ietf-yang-revisions.

b) Define revision-date in ietf-yang-types.

c) Define a date-no-zone type (derived from the date type) which does
   not have the optional time zone offset. 

I am leaning towards option c), having a generic type for a date
without a time zone is the most general type we can provide. If
additional specific revision date semantics are necessary, they can be
provided in ietf-yang-revisions. (Looking at the definition of the
type revision-identifier in RFC 8525, this is really date-no-zone.)

/js

---

From: tom petch <[email-masked]>
Date: Thu, 24 Mar 2022 17:17:42 +0000

From: netmod <[email-masked]> on behalf of Jürgen Schönwälder <[email-masked]>
Sent: 22 March 2022 07:11

<tp>

Yes, I like c) for its simplicity and its adequacy

Tom Petch

/js