Subject: [i2rs] Comments on draft-clarke-i2rs-traceability

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Apr 2014 20:01:47 -0400

Authors,

While reviewing draft-clarke-i2rs-traceability, one big thing jumped out at
me that will require a bit more consideration: ABNF is only ASCII-friendly.
Since one of the data modeling languages we're considering is Yang, we need
to have support for unicode (UTF-8, e.g.).

I don't have a specific suggested fix at this time.  I suspect this is a
bigger issue than just ours as it impacts other consumers of ABNF.

-- Jeff

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 15 Apr 2014 09:44:15 -0400

> bigger issue than just ours as it impacts other consumers of ABNF.

Thanks for the feedback, Jeff!  We've been waiting for some :-).  Yes, 
ABNF is ASCII-friendly.  When we originally wrote this, we were going 
off of what was in the architecture.  I have some updates planned for 
this, and I will work on updating the model to reflect current WG status.

Any other comments or suggestions are very much welcome.

Joe

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 15 Apr 2014 18:09:52 +0000

Joe,

Besides having the same comment as Jeff, here is one more and think some additional clarification is needed

Actor Identifier:   This is an opaque identifier that may be known to
      the Client from a northbound controlling application.  This is
      used to trace the northbound actor driving the actions of the
      Client.  The Client may not provide this identifier to the Agent
      if there is no external actor driving the Client.  However, this
      field MUST be logged.  If the Client does not provide an actor ID,
      then the Agent MUST log an empty field.
I can see that Actor ID can be useful to report back to Client operator about rouge Actor. WRT logging Actor ID, when the Actor ID is not provided by Client, instead of logging an empty field, I would suggest to log UNKNOWN or NOT FOUND or NOT PROVIDED, as it is easier to search for a keyword then just empty field.

Dean

On Apr 15, 2014, at 9:44 AM, Joe Marcus Clarke <[email-masked]> wrote:

> Thanks for the feedback, Jeff!  We've been waiting for some :-).  Yes, ABNF is ASCII-friendly.  When we originally wrote this, we were going off of what was in the architecture.  I have some updates planned for this, and I will work on updating the model to reflect current WG status.
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
> 
>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 15 Apr 2014 14:50:59 -0400

> I can see that Actor ID can be useful to report back to Client operator about rouge Actor. WRT logging Actor ID, when the Actor ID is not provided by Client, instead of logging an empty field, I wo…

Thanks, Dean.  The searchability is a good point.  Of the three you 
propose, I think "NOT PROVIDED" is the only correct option.  What do 
others think?  Admittedly, this might evolve into some kind of 
enumeration where we might need values like "NOT PROVIDED" and "UNKNOWN" 
to accommodate different states.

Joe

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 15 Apr 2014 19:02:54 +0000

As Joe mentioned, we're certainly open to expanding to UTF-8.  To your (valid) point regarding YANG, would the group prefer to see the trace log syntax expressed in YANG instead of ABNF? We stuck with BNF-based out of sheer habit. If we did this, for the sake of consistency, would we also want the syntax updated (RBNF->YANG) in Nitin's RIB IM draft as well?

Gonzalo

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Apr 2014 15:11:58 -0400

The question about languages mixes three very different spaces.

1) Is the format of a (potentially binary) packet on the wire, in this 
case the trace log syntax.
2) Is the data model for the command exchanges.
3) Is the language used for information modeling.

Taking them in reverse order, ABNF (or RBNF) is absolutely the wrong 
thing to use for item 3.  I would prefer to use UML.  If we decide (as 
seems likely) to use YANG for the data modeling, then I can live with 
skipping the UML step and going directly to YANG.

Item (2) is the domain of the protocol discussion the chairs are trying 
to wrap up.  I expect the mailing list to endorse the conclusion that we 
should use YANG for this.

Item 1 could be seen as similar to item 2.  But only if you constrain 
the format to match what YANG can talk about.  In describing a general 
format (with details of the final binding to the wire deferred or 
specified as we choose) ABNF / RBNF are very well suited to this 
problem.  And produce very clear descriptions of packets.

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Apr 2014 09:35:17 -0400

[Speaking with my chair hat off...]

On Tue, Apr 15, 2014 at 03:11:58PM -0400, Joel M. Halpern wrote:
> 1) Is the format of a (potentially binary) packet on the wire, in
> this case the trace log syntax.
[...]
> Item (2) is the domain of the protocol discussion the chairs are
> trying to wrap up.  I expect the mailing list to endorse the
> conclusion that we should use YANG for this.

It isn't fully clear to me that for our traceability mechanism that we must
use the same data modeling language as the language we use for the rest of
I2RS.  Yes, there are potentially significant benefits to doing that, but I
wouldn't preclude other considerations.

The single biggest benefit addressing my original point is that if we chose
Yang, the traceability could similarly use Yang (or even simply an XML
document fragment).  This would address the unicode consideration.

There are two potential impacts that would have that may not beneficial:
1. Input and output would have to be modeled after CDATA anyway.  The trace
mechanism MUST be able to deal with malformed input and output.  This means
the useful structured bits of the trace in XML format are largely wrappers,
not the data.  Basically, trying to interpret the inputs to the trace using
the same code is hazardous and needs to be called out as specifically
discouraged.

2. There are some nice benefits to log formats that are effectively "single
line".  And yes, I'll immediately contrast this to formats that effectively
split the outputs across multiple line and require some sophisticated
cleanup in log parsers.  Basically, the question begged is how syslog
friendly are we concerned about in the base trace mechanism or are there
considerations for a separate syslog format?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 13:30:51 -0400

On Tue, Apr 15, 2014 at 02:50:59PM -0400, Joe Marcus Clarke wrote:
> enumeration where we might need values like "NOT PROVIDED" and
> "UNKNOWN" to accommodate different states.

Reserved values may be the appropriate answer, although they should be
scarcely used since they suggest that the reserved name is unavailable in
other portions of other systems.

As we resolve the discussion about data model for this component, we might
find that the data modeling language provides some help here.  For example,
a "string" component may permit arbitrary Actor Identifiers, while a type of
"enueration" in the same field could have reserved components.  This would
of course depend on whether typed fields are even an option.

-- Jeff