Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS)

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 6 Jan 2016 08:26:56 +0000

Dear Jari,

Thank you. Please see my reply in line.

> -----Original Message-----
> From: P2PSIP [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Thursday, December 17, 2015 3:20 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with
> DISCUSS)
> 
> Jari Arkko has entered the following ballot position for
> draft-ietf-p2psip-diagnostics-19: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Per Alexey's Gen-ART review and my own read, Section 9.1 is inconsistent with
> Section 5.3. The document says earlier that first and last bits are reserved. This
> is not shown in the table at all. What's perhaps causing the confusion is that
> there are special values (all 0s and all 1s) that convey nothing is requested and
> that everything is requested. This does not appear to be the same as having
> two reserved bits. You may want one or the other or both, but as it stands 9.1
> or 5.3 do not seem to be saying the same thing.

In Section 5.3, it says "The dMFlags field described above is a 64 bit field that allows initiator nodes to identify up to 62 items of base information to request in a request message (the first and last flags being reserved)." 62 bits can be used to indicate up to 62 diagnostic Kinds, but dMFlags reserves all "0"s that means nothing is requested, and all "1"s that means everything is requested. But at the same time, the first and last bits cannot be used for other purposes.

> 
> Also, Section 5.3 uses "delimited" when it probably should have said
> "terminated", unless there's more substructure in the SOFTWARE_VERSION
> string than is identified by the text.

It is the language problem and accepted. 

BR,
-Haibin Song

> 
> 
> 
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Jari Arkko <[email-masked]>
Date: Thu, 7 Jan 2016 02:34:31 +0200

> In Section 5.3, it says "The dMFlags field described above is a 64 bit field that allows initiator nodes to identify up to 62 items of base information to request in a request message (the first an…

Right. Can that be explained somewhere, and can Section 9.1 show the two aspects? That is, the all 0s/1s *and* first and last bits being reserved? The current text does not reserve the first and last bits. It only reserves the all 0s and all 1s…

    +-------------------------+------------------------------+----------+
    |  diagnostic information |diagnostic flag in dMFlags    | RFC      |
    |-------------------------+------------------------------+----------|
    |Reserved                 | 0x 0000 0000 0000 0000       |RFC-[TBDX]|
    |STATUS_INFO              | 0x 0000 0000 0000 0001       |RFC-[TBDX]|
    |ROUTING_TABLE_SIZE       | 0x 0000 0000 0000 0002       |RFC-[TBDX]|
    |PROCESS_POWER            | 0x 0000 0000 0000 0004       |RFC-[TBDX]|
    |UPSTREAM_BANDWIDTH       | 0x 0000 0000 0000 0008       |RFC-[TBDX]|
    |DOWNSTREAM_ BANDWIDTH    | 0x 0000 0000 0000 0010       |RFC-[TBDX]|
    |SOFTWARE_VERSION         | 0x 0000 0000 0000 0020       |RFC-[TBDX]|
    |MACHINE_UPTIME           | 0x 0000 0000 0000 0040       |RFC-[TBDX]|
    |APP_UPTIME               | 0x 0000 0000 0000 0080       |RFC-[TBDX]|
    |MEMORY_FOOTPRINT         | 0x 0000 0000 0000 0100       |RFC-[TBDX]|
    |DATASIZE_STORED          | 0x 0000 0000 0000 0200       |RFC-[TBDX]|
    |INSTANCES_STORED         | 0x 0000 0000 0000 0400       |RFC-[TBDX]|
    |MESSAGES_SENT_RCVD       | 0x 0000 0000 0000 0800       |RFC-[TBDX]|
    |EWMA_BYTES_SENT          | 0x 0000 0000 0000 1000       |RFC-[TBDX]|
    |EWMA_BYTES_RCVD          | 0x 0000 0000 0000 2000       |RFC-[TBDX]|
    |UNDERLAY_HOP             | 0x 0000 0000 0000 4000       |RFC-[TBDX]|
    |BATTERY_STATUS           | 0x 0000 0000 0000 8000       |RFC-[TBDX]|
    |Reserved                 | 0x FFFF FFFF FFFF FFFF       |RFC-[TBDX]|
    +-------------------------+------------------------------+————+

But maybe I’m missing something.

I thought the text above should be something like this instead:

    +-------------------------+------------------------------+----------+
    |  diagnostic information |diagnostic flag in dMFlags    | RFC      |
    |-------------------------+------------------------------+----------|
    |Reserved All 0s value   | 0x 0000 0000 0000 0000       |RFC-[TBDX]|
    |Reserved First Bit    | 0x 0000 0000 0000 0001       |RFC-[TBDX]|
    |STATUS_INFO              | 0x 0000 0000 0000 0002       |RFC-[TBDX]|
    |ROUTING_TABLE_SIZE       | 0x 0000 0000 0000 0004       |RFC-[TBDX]|
    |PROCESS_POWER            | 0x 0000 0000 0000 0008       |RFC-[TBDX]|
    |UPSTREAM_BANDWIDTH       | 0x 0000 0000 0000 0010       |RFC-[TBDX]|
    |DOWNSTREAM_ BANDWIDTH    | 0x 0000 0000 0000 0020       |RFC-[TBDX]|
    |SOFTWARE_VERSION         | 0x 0000 0000 0000 0040       |RFC-[TBDX]|
    |MACHINE_UPTIME           | 0x 0000 0000 0000 0080       |RFC-[TBDX]|
    |APP_UPTIME               | 0x 0000 0000 0000 0100       |RFC-[TBDX]|
    |MEMORY_FOOTPRINT         | 0x 0000 0000 0000 0200       |RFC-[TBDX]|
    |DATASIZE_STORED          | 0x 0000 0000 0000 0400       |RFC-[TBDX]|
    |INSTANCES_STORED         | 0x 0000 0000 0000 0800       |RFC-[TBDX]|
    |MESSAGES_SENT_RCVD       | 0x 0000 0000 0000 1000       |RFC-[TBDX]|
    |EWMA_BYTES_SENT          | 0x 0000 0000 0000 2000       |RFC-[TBDX]|
    |EWMA_BYTES_RCVD          | 0x 0000 0000 0000 4000       |RFC-[TBDX]|
    |UNDERLAY_HOP             | 0x 0000 0000 0000 8000       |RFC-[TBDX]|
    |BATTERY_STATUS           | 0x 0000 0000 0001 0000       |RFC-[TBDX]|
    |Reserved Last Bit              | 0x 8000 0000 0000 0000       |RFC-[TBDX]|
    |Reserved All 1s Value       | 0x FFFF FFFF FFFF FFFF       |RFC-[TBDX]|
    +-------------------------+------------------------------+————+

> It is the language problem and accepted.

Thanks!

Jari

---

From: "Songhaibin (A)" <[email-masked]>
Date: Sat, 30 Jan 2016 06:46:58 +0000

Dear Alexey and Jari,

Accept the text what Jari suggested. And now it is clear.

BR,
-Haibin Song

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, January 07, 2016 6:36 PM
> To: Jari Arkko; Songhaibin (A)
> Cc: The IESG; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19:
> (with DISCUSS)
> 
> Hi,
> 
> > On 7 Jan 2016, at 00:34, Jari Arkko <[email-masked]> wrote:
> >
> >
> >> In Section 5.3, it says "The dMFlags field described above is a 64 bit field
> that allows initiator nodes to identify up to 62 items of base information to
> request in a request message (the first and last flags being reserved)." 62 bits
> can be used to indicate up to 62 diagnostic Kinds, but dMFlags reserves all "0"s
> that means nothing is requested, and all "1"s that means everything is
> requested. But at the same time, the first and last bits cannot be used for
> other purposes.
> >
> > Right. Can that be explained somewhere, and can Section 9.1 show the
> > two aspects? That is, the all 0s/1s *and* first and last bits being
> > reserved? The current text does not reserve the first and last bits.
> > It only reserves the all 0s and all 1s...
> 
> I thought the same.
> >
> >    +-------------------------+------------------------------+----+
> >
> > But maybe I'm missing something.
> >
> Exactly my point. If what Jari suggests is not true, then the text needs even
> more work.
> >
> >    +-------------------------+------------------------------+----+
> >
> >>
> >>>
> >>> "terminated", unless there's more substructure in the
> >>> SOFTWARE_VERSION string than is identified by the text.
> >>