Subject: [stir] Eric Rescorla's Discuss on draft-ietf-stir-certificates-16: (with DISCUSS)

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Dec 2017 15:58:12 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-stir-certificates-16: 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-stir-certificates/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

   national policies.  The count field is only applicable to start	
   fields' whose values do not include "*" or "#" (i.e., a	
   TelephoneNumber that does not include "*" or "#").  count never	
   overflows a TelephoneNumber digit boundary (i.e., a	
   TelephoneNumberRange with TelephoneNumber=10 with a count=91 will	
   address numbers 10-99).

This text doesn't seem very clear. When you say "never overflows a digit
boundary" do you mean "doesn't extend the integer to the left"? Because
you sure seem to be overflowing the 1s place here.

Is the algorithm that you are given the input TN, Count, and TN
consists D digits that the range is:

  MIN(TN + Count, 10^D - 1)

That would be consistent with your example here, but I don't think consistent
with your text. Or do you mean something else?

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Dec 2017 10:24:44 -0600

> you sure seem to be overflowing the 1s place here.

Based on the in-room conversation in Singapore, the notion here seems to 
be that the number does not increase in length.

> with your text. Or do you mean something else?

Your formula above matches my understanding, and I think including it in 
the document as the formal definition of how 'count' behaves would be 
the best way to address the lack of clarity you cite.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Dec 2017 08:29:00 -0800

On Wed, Dec 13, 2017 at 8:24 AM, Adam Roach <[email-masked]> wrote:

> the document as the formal definition of how 'count' behaves would be the
> best way to address the lack of clarity you cite.

That would be fine. As long as people are onboard with this, I'm happy to
withdraw my discuss and let you and the WG handle this.

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Wed, 13 Dec 2017 11:36:50 -0500

> On Dec 13, 2017, at 11:24, Adam Roach <[email-masked]> wrote:
> 
> Based on the in-room conversation in Singapore, the notion here seems to be that the number does not increase in length.

Yep.

> Your formula above matches my understanding, and I think including it in the document as the formal definition of how 'count' behaves would be the best way to address the lack of clarity you cite.

Agreed.  How about this change:

OLD:

    count never overflows a TelephoneNumber digit
    boundary (i.e., a TelephoneNumberRange with
    TelephoneNumber=10 with a count=91 will address
    numbers 10-99).

NEW:

    count never makes the number increase in length
    (i.e., a TelephoneNumberRange with TelephoneNumber=10
    with a count=91 will address numbers 10-99); formally,
    given the inputs count and TelephoneNumber of length D
    the end of the TelephoneNumberRange is:
    MIN(TelephoneNumber + count, 10^D - 1)

spt

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Dec 2017 09:05:30 -0800

>     MIN(TelephoneNumber + count, 10^D - 1)

This seems fine.

-Ekr