Subject: Re: [CCAMP] RFC 4207 LMP Erratum

From: Vishwas Manral <[email-masked]>
Date: Sun, 1 Nov 2009 20:03:05 -0800

Hi Adrian,

I think the BNF format below is ambiguous as it does not tell which
part is repeatetive (only trace or others too):

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                              <LOCAL_INTERFACE_ID>
                              <TRACE> ...

If we want to be consistent with the other messages in the RFC it should be:

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                              <LOCAL_INTERFACE_ID>
                              <TRACE> [<TRACE> ...]

However the best representation would be:

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                              <LOCAL_INTERFACE_ID> <TRACE_LIST>

   <TRACE_LIST> ::= <TRACE> [<TRACE_LIST> | ]

Thanks,
Vishwas

On Fri, Oct 30, 2009 at 2:45 AM, Adrian Farrel <[email-masked]> wrote:
> Hi CCAMP,
>
> Can I please have your help in resolving an Erratum raised against the LMP
> spec RFC 4207.
>
> You can see the full details at
> http://www.rfc-editor.org/errata_search.php?rfc=4207&eid=167
>
> The essence of the question is: how many <TRACE> objects may be present on a
> <TraceMonitor Message>?
>
> The BNF in section 4.1.1 currently implies just one. But the text could be
> interpreted to man more than one.
>
>
> While you are looking at this, can you say whether any other messages should
> also allow more than one <TRACE> object?
>
> Many thanks,
> Adrian
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 1 Nov 2009 20:16:31 -0800

Modifying the best BNF format a bit.

>   <TRACE_LIST> ::= <TRACE> [<TRACE_LIST> | <empty> ]
>
> Thanks,
> Vishwas
>

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 02 Nov 2009 16:06:50 +0800

Hi Adrian and Vishwas,

I think Vishwas's suggestions are very good  if we want to allow multiple <TRACE> objects in a <TraceMonitor Message>. 

However, when we investigate how many <TRACE> objects may be presented on a <TraceMonitor Message>, I think it is natural to include only one <TRACE> ojbect in <TraceMonitor Message>,  because the following format of <TraceMonitor Message> makes the programmer to do that without deep consideration.
  <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                                                     <LOCAL_INTERFACE_ID> <TRACE>

Therefore, I think it depends on how to correct the descriptions of RFC4207 to decide how many <TRACE>objects should be presented in the <TraceMonitor Message>.

When we look at other messages, I think <Test> message should also be taken into accout, besides <xxTracexx> messages.

(1)Test Message: I think only one <TRACE> object should be included.

<Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
                                  <VERIFY_ID> <TRACE>

(2) TraceMonitor Message: discussed above. 

If there are multiple <TRACE> objects in this message, and then there are multiple "Trace Messages". In some cases, if all the Trace objects are processed correctly, we can understand that there is no Trace Mismatch. But if some of them are correct and some of them are incorrect, how to handle that? (i.e.,  in the latter case,  for a specific Local_Interface_ID, is it mismatched  or matched?  Obviously, we must  change <TraceMonitorNack>  or extend ERROR_CODE. ) 
  :-)~~~

(3) TraceReport Message: I think only one <TRACE> should be included in the <TraceReport Message>.

If we look at the format of <TraceReq Message> and <TraceReport Message>, we can get the answer.
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
                                             <LOCAL_INTERFACE_ID> <TRACE_REQ>

<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
   The TraceReport message (Message Type 27) is sent over the control channel after receiving a TraceReq message.

(4) InsertTrace Message: I think only one <TRACE> should be included in the <InsertTrace Message> for the following description.

The InsertTrace message (Message Type 29) is sent over the control channel and is used to request a remote node to send "a specific trace message" over a data link (this assumes that the remote knows the mapping between the local and remote interface_Ids before fulfilling such request).

Thanks

Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 2 Nov 2009 08:29:22 +0100 (MEZ)

>    <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>

No!
See Section 2.2.5 of RFC 5511, an RFC which expressly was targetted
to codify "existing practice" (so it seems legitimate to apply it):

 2.2.5.  Repetition

   ...

   Meaning:
     May repeat the preceding object, intermediate construct, or
     construct.

   Encoding:
     Three dots ("...").

"<TRACE>" is an intermediate construct; thus it is unambiguously
the item being repeated.

>> also allow more than one <TRACE> object?

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Dieter Beller <[email-masked]>
Date: Mon, 2 Nov 2009 15:41:25 +0100

Hi Alfred,

could you please explain why multiple <TRACE> objects for a single

interface are needed? I fail to understand what the application is that

requires this.

Thanks,

Dieter

[email-masked] wrote:

Vishwas Manral wrote:

Hi Adrian,

No!

2.2.5. Repetition

...

Meaning:

Encoding:
Three dots ("...").

Thanks,
Vishwas

Hi CCAMP,

Many thanks,
Adrian

Kind regards,
Alfred HÎnes.

--

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 2 Nov 2009 16:40:33 +0100 (MEZ)

Dieter,

Your message almost has been scrubbed as spam at our provider,
because of the lack of 'normal' content.  ("HTML-only" is one
of the most efficient criteria in spam filtering today!)
However, I have managed to 'de-HTLMize' the message ...   :-)

> Hi Alfred,
> could you please explain why multiple <TRACE> objects for
> a single interface are needed? I fail to understand what the
> application is that requires this.
> Thanks,
> Dieter

First of all, I would like to refer you to the public errata report,
which -- you might have observed -- is almost 4(!) years old:

http://www.rfc-editor.org/errata_search.php?rfc=4207&presentation=records

I apologize for not having the time to fully re-read RFC 4207 now,
due to current overload, but I hope that the reasoning presented in
the Errata Report in 2005 is still valid.  I do not recall all the
details, but I'm quite sure it had not been based on specific
application scenarios, but rather on lack of consistency with other
parts of the RFC.  Please check and let me know if something's
wrong there.  If there indeed are good arguments against the
conclusion in the Errata Note, the quoted other parts of the RFC
might need reconsideration/clarification instead.

In short: either _all_ parts of the RFC should use plural for
TRACE object(s) in a TraceMonitor Message, or _none_.

Below, I have attached the original report once sent to the
authors of RFC 4207, which did not solicit a response those days
and has been entered later into the new RFC Errata database
by busy beavers at the RFC-Ed...

Kind regards,
  Alfred Hönes.

-- 

--------  begin forwarded message  --------

> From: <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Message-Id: <[email-masked]>
> Date: Tue, 20 Dec 2005 18:01:34 +0100 (MEZ)
> Subject: RFC 4207 (LMP SDH Test)

Hello,

I've been stuck in an apparent inconsistency in the recently
published RFC 4207 authored by you.

RFC 4207 defines the syntax of the TraceMonitor message in Section
4.1.1, on page 6.
Similarly, the TraceMonitorAck and TraceMonitorNack Messages are
specified in Sections 4.1.2 and 4.1.3, respectively, on page 8.

While the former specifies a single <TRACE> object to appear
in a TraceMonitor message, the latter specs uses wording like
"all of the TRACE Objects in a TraceMonitor message" or
"TRACE object value(s)".

IMHO, it makes much sense to indeed allow multiple TRACE Objects
(with different trace types, but all related to a single Interface)
in a single TraceMonitor Message.

To resolve the inconsistency, I therefore propose to submit an
Errata Note for RFC 4207 aimed at adapting the syntax specified
in section 4.1.1 to the remainder of the specification:

------ cut here ------

RFC 4207, in Section 4.1.1, near the bottom of page 6, specifies:

           [...]  The format of the TraceMonitor message is as
  follows:

It should say:

           [...]  The format of the TraceMonitor message is as
  follows:

------ cut here ------

If you agree with this Errata Note, please forward your consent
to the RFC-Ed.

[Note:
 I purposely have inserted the additional line break to emphasize
 that the repetition is to be applied to <TRACE> only; and I have
 used the more conventional style of repetition indication, '...',
 not the ABNF (RFC 4234) style "1*<TRACE>", to remain consistent
 in style with the basic LMP specification (RFC 4204) and because
 there is no ref. to RFC 4234 in RFC 4207.
 You might wish to change these details however, if you prefer.
]

Best regards,
  Alfred Hönes.

-- 

--------  end forwarded message  --------

---

From: Dieter Beller <[email-masked]>
Date: Mon, 2 Nov 2009 17:47:58 +0100

Alfred,

this message is formatted as plain text message ;-)

> TRACE object(s) in a TraceMonitor Message, or _none_.
I would advocate *all singular*, i.e., there's exactly one TRACE object in a
TraceMonitor Message and not multiple.

Thanks,
Dieter

-- 
------------------------------------------------------------------------

---

From: Lou Berger <[email-masked]>
Date: Tue, 03 Nov 2009 18:32:58 -0500

All,

I propose that the errata be set to type Editorial and that a note be
added stating that the wording "all of the TRACE Objects in a
TraceMonitor message" while technically accurate is misleading, and that
changing the all plural references to "TRACE Objects" to the singular
will eliminate this particular issue.

Read on if you're interested in details.

Dieter,
	I concur that only a single <TRACE> should be allowed.  The errata
quotes two issues.  Let's look at each:

"all of the TRACE Objects in a TraceMonitor message"

While this phrasing certainly implies there may be more than one object,
I think everyone will agree that "all" should be read to also cover the
singular case.  Given this, the phrase is technically accurate, but
nonetheless misleading.

"TRACE object value(s)".

Looking at the object, we see that it includes multiple fields each of
which carries a value.  If we look at the phrase in context we find:
   This
   could be because the trace monitoring requested is not supported or
   there was an error in the TRACE object value(s).

It seems to me there may be an error in any of the fields, so "value(s)"
is technically correct.  An equivalent phrasing is "an error in any of
the fields carried in a received TRACE object".  That said, I personally
don't see a difference or an issue with the current language.

Thank you for the input!

Lou

---

From: Dieter Beller <[email-masked]>
Date: Wed, 4 Nov 2009 11:46:19 +0100

Lou,

your proposed resolution looks good!

Thanks,

Dieter

Lou Berger wrote:

All,

Dieter,

"TRACE object value(s)".

Thank you for the input!

Lou

Alfred,

If the issue is:

I would advocate *all singular*, i.e., there's exactly one TRACE object
in a
TraceMonitor Message and not multiple.

Thanks,
Dieter

[email-masked] wrote:

Dieter,

Hi Alfred,

Kind regards,
Alfred HÎnes.

--