Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)

From: Randy Presuhn <[email-masked]>
Date: Fri, 10 Jan 2014 11:28:08 -0800 (GMT-08:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Jan 10, 2014 7:16 AM
>To: Jernej Tuljak <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
...
>IMO, current wording permits three defensible interpretations:
>
>1. "\*" == '\*'
>2. "\*" == '*'
>3. "\*' is an error
>
>So this should be clarified.
>
>As I wrote, I'd prefer #3 because it would be the same as
>the behaviour of "\" in regex patterns.

Option #3 would also be the safest in case the need ever arises
in the future to define additional escape sequences, since doing
so would not change the meaning of any existing valid sequence.

Randy

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 Jan 2014 16:17:34 +0100

Dear all,

On this errata, I'm unclear whether a clarification is needed.
If it's the case, please update the errata and let me know.

Regards, Benoit
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Jan 2014 18:09:08 +0100

> If it's the case, please update the errata and let me know.

It depends - if we can agree that option #1 below is the expected behaviour, then the erratum can be rejected, otherwise it should be accepted.

The single-quoted string works in any case though.

Lada 

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Benoit Claise <[email-masked]>
Date: Wed, 15 Jan 2014 11:03:48 +0100

> It depends - if we can agree that option #1 below is the expected behaviour, then the erratum can be rejected, otherwise it should be accepted.
So what's the next step? An agreement from this community?

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jan 2014 10:51:02 +0100

> So what's the next step? An agreement from this community?

Yes, I guess. Or, alternatively, the errata could be accepted as Jernej sent them because the single-quoted string is correct in any case.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 11:38:08 +0100

> Yes, I guess. Or, alternatively, the errata could be accepted as Jernej sent them because the single-quoted string is correct in any case.

Makes sense to me. My take is that the behavior of backslashes in
double quoted strings that are not defined escape sequences is not
well enough defined in RFC 6020 and as such avoiding this is a good
thing to improve interoperability (and luckily we can avoid it).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 12:08:37 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> > Yes, I guess. Or, alternatively, the errata could be accepted as
> > Jernej sent them because the single-quoted string is correct in any
> > case.
> > 
> 
> Makes sense to me.

So what does it mean that the YANG module is modified by an errata?
The YANG file that people use will have the revison 2012-02-22.  Are
you saying that there are now two slightly different versions of this
revision?

I do agree that we should avoid this situation in future modules.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jan 2014 12:12:53 +0100

> you saying that there are now two slightly different versions of this

That’s a good question. I think the revision should be bumped, too, because the two versions might potentially behave differently.

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 16 Jan 2014 12:16:46 +0100

> That’s a good question. I think the revision should be bumped, too, because the two versions might potentially behave differently.

Would this be a valid YANG module update (Section 10)?

Jernej

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 12:17:05 +0100

> you saying that there are now two slightly different versions of this

Are you suggesting there never can be any erratum to any YANG module
ever since this essentially creates a new version?

I do not see that this change introduces a technical difference -
except that with the erratum applied, the likelihood increases that
YANG parsers will show the same behaviour.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jan 2014 12:23:33 +0100

> YANG parsers will show the same behaviour.

On the other hand, a parser can exhibit different behaviour with each version, depending on its approach to double-quoted escapes.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 12:29:06 +0100 (CET)

> ever since this essentially creates a new version?

I think so.  The new version should have a new revision.

Has this situation happened with MIBs?

> YANG parsers will show the same behaviour.

If two parsers behave differently, and we think that they both are
6020 compliant, then we did introduce a technical difference.

IMO it would be better to publish an errata to 6020, like Jernej
suggested.  (He suggested:

   Within a double-quoted string (enclosed within " "), a backslash
   character may introduce a special character, which depends on the
   character that immediately follows the backslash:
)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 12:29:44 +0100

> That’s a good question. I think the revision should be bumped, too, because the two versions might potentially behave differently.

I do not think we should go there. Then I propose to mark this erratum
as "Held for Document Update" and to move on. I do not think we should
use errata to create revisions of YANG modules - this will be hard to
track.

If we conclude that RFC 6020 is not fully clear about the
interpretation of non-escape backslash sequences, I would expect that
implementations will be prepared to make a reasonable decision, which
may involve throwing warnings but not errors and to process the module
using a 'best guess' interpretation or resorting to user input instead
of a machine generated 'best guess'.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 12:36:32 +0100

> Has this situation happened with MIBs?

I am reasonably sure. I do not recall that I have seen an update of
the LAST-UPDATE clause for that reason in an erratum.
 
> 6020 compliant, then we did introduce a technical difference.

My take is that 6020 is ambiguous here. So as a matter of that, two
deployed parsers may happen to behave differently - this is what you
get our of RFC 6020.

> suggested.

So far I have not see a clear resolution what the intended behaviour
is. Apparently implementations deal with this differently - so how do
we manage to declare some of them not compliant?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 13:59:06 +0100 (CET)

> the LAST-UPDATE clause for that reason in an erratum.

Ok, searching the Errata I found a few.  Even this:

http://www.rfc-editor.org/errata_search.php?eid=334

I noticed that the mib that gets distributed with libsmi doesn't have
this change.  This is of course the risk of doing such changes...

One might argue that the fix we're talking about is much less
intrusive...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jan 2014 13:59:40 +0100

> we manage to declare some of them not compliant?

I think an erratum to sec. 6.1.3 should clearly state the behaviour wrt to escapes that are not explicitly listed. Jernej’s proposed text IMO isn’t clear enough.

I assume that an accepted erratum becomes part of the RFC, so implementations that behave differently will be non-compliant and should be updated. But maybe there are some guidelines how to deal with technical ambiguity in RFCs.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 15:04:41 +0100

> this change.  This is of course the risk of doing such changes...

I am simply not able to track errata for ~300 MIB modules the IETF has
published (a remarkable number). That said, if someone would send me
an email saying a certain MIB module has a bug and points to an
approve errata for it, I would apply the patch without thinking much.

These things are trade-off decisions and in this particular case, I
personally believe the change is trivial enough to not warrant a new
version and to simply do it. The 'patched' variant will clearly
interoperate, the 'unpatched' variant may trigger undefined
behaviour. People struggling with the variant triggering undefined
behaviour likely will likely move to the 'patched' variant. For the
rest, it does not matter. But that is just my personal opinion...

/js