Subject: [sidr] WG adoption for draft-pmohapat-sidr-pfx-validate-07

From: Sandra Murphy <[email-masked]>
Date: Wed, 12 May 2010 17:23:44 -0400 (Eastern Daylight Time)

Pradosh Mohapatra has requested that the working group adopt the draft 
draft-pmohapat-sidr-pfx-validate-07.txt as a work item.

This work has been presented at IETF 73, IETF 75, and IETF 77.

It is available at 
http://tools.ietf.org/html/draft-pmohapat-sidr-pfx-validate-07

Recall that active support for adoption is necessary for the wg chairs to
judge acceptance as a working group work item, so silence works against
adoption.  The wg chairs also want to know who would be willing to work on
the draft.

Please respond to the list, giving your recommendation for or against
adoption of the draft as a wg work item as well as your intention to work
on the draft if adopted.  The call for adoption will end in two weeks on 
May 26.

--Sandy, speaking as wg chair

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 May 2010 23:36:35 +0200

> draft-pmohapat-sidr-pfx-validate-07.txt as a work item.

support

---

From: Terry Manderson <[email-masked]>
Date: Mon, 17 May 2010 22:49:19 -0700

I support the adoption and willing to review..

..and I have some concerns about the terms of "valid", "invalid". ("Unknown"
I like).

This may only be semantics, but the valid and invalid terms convey more than
a preference level. IE if a database prefix set covers an UPDATE prefix then
the UPDATE route, in my mind, would be preferred over one that was, using
the draft notation, 'invalid'.

It may be that my concern shouldn't be covered in pfx-validate, or the use
of valid and invalid should be constrained to just talking about the RPKI
validation result, and different terminology used when matching UPDATE
prefixes to RPKI validation result sets. Or the section on policy might need
to be expanded.

Cheers
Terry

On 13/05/10 7:23 AM, "Sandra Murphy" <[email-masked]> wrote:

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

---

From: Robert Kisteleki <[email-masked]>
Date: Tue, 18 May 2010 08:37:26 +0200

> prefixes to RPKI validation result sets. Or the section on policy might need

I agree with Terry on this one. I'd personally be much happier with 
verified/unverified instead of valid/invalid. These terms are much closer to 
what we really mean.

Robert

---

From: Pradosh Mohapatra <[email-masked]>
Date: Fri, 21 May 2010 07:46:01 -0700

Hi Terry, Robert,

> I agree with Terry on this one. I'd personally be much happier with verified/unverified instead of valid/invalid. These terms are much closer to what we really mean.

Ack. We will make this terminology change in the next revision of the draft.

- Pradosh

---

From: Geoff Huston <[email-masked]>
Date: Sat, 22 May 2010 07:19:08 +1000

> Ack. We will make this terminology change in the next revision of the draft.

I disagree with this terminology change - there are three states that are potential outcomes of the process, not two and the proposed terminology does not accommodate this. I request that no change be made in terminology.

---

From: Robert Kisteleki <[email-masked]>
Date: Sat, 22 May 2010 12:08:27 +0200

On 2010.05.21. 23:19, Geoff Huston wrote:
>>> verified/unverified instead of valid/invalid. These terms are much
>>> closer to what we really mean.
>>
> I disagree with this terminology change - there are three states that are
> potential outcomes of the process, not two and the proposed terminology
> does not accommodate this. I request that no change be made in
> terminology.

Geoff, you misunderstood. We proposed varified/unverified/unknown instead of 
valid/invalid/unknown.

Robert

---

From: Robert Loomans <[email-masked]>
Date: Sat, 22 May 2010 22:30:08 +1000

On 22/05/2010, at 20:08, Robert Kisteleki wrote:

> Geoff, you misunderstood. We proposed varified/unverified/unknown instead of valid/invalid/unknown.

I also prefer valid/invalid/unknown.

I don't believe that the term "unverified" has quite the desired meaning.

"verified" is a positive assertion ("yup, all ok"), "unknown" is a null ("pass, I have no idea"), and the third state should reflect that it is the _opposite_ of "verified" (ie, *known* to be incorrect), so "verify failed" (or "failed verification", or simply "failed") would, I believe, be more accurate than "unverified"...

... at which point, it seems to me that valid/invalid/unknown is less cumbersome.

To look at it from another angle: If you wanted to order the update in order of preference, you would have to prefer "valid" updates over "unknown", and "unknown" over "invalid".

[ If you were to base a comparison function for sorting on this DB lookup, I believe it would have to look like this:

    valid  =  1
  unknown  =  0
  invalid  = -1
]

I don't think that "unverified" quite cuts it in this context, as it is not the negative counterpart to the positive "verified" assertion. A naive reader/implementer might believe that "unverified" is less dubious than "unknown", and incorrectly order the values. 

Rob

-- 
Robert Loomans                         email:       [email-masked]
Senior Software Engineer, APNIC        sip:    [email-masked]
http://www.apnic.net/                  phone:         +61 7 3858 3100

---

From: Geoff Huston <[email-masked]>
Date: Sun, 23 May 2010 08:14:51 +1000

> Geoff, you misunderstood. We proposed varified/unverified/unknown instead of valid/invalid/unknown.

I don't believe so at all. My objection was to point out I see insufficient semantic distinction between 'unverified' and 'unknown' - 'unverified' says to me "did not verify" as distinct from the more precise statement that "I have in my possession objects that explicitly 'include' the prefix being tested, and these objects have failed to validate the route", or, more succinctly, "verification failed". I feel that the appropriate adjective for such routes that have failed an active test (as distinct from not have any relevant RPKI objects at hand that can be tested against the route) is "invalid".

An alternate terminology that I can see as also making an appropriate distinction between failure of validation tests as distinct from not being able to test at all can be found in draft-bates-bgp4-nlri-orig-verif-00.txt. There the terms are "Authenticated", "Authentication Failed" and "Unauthenticated"

If one were to use "verify" as the base term, then the appropriate distinction is "Verified", "Verification Failed", and "Unverified" respectively.

I trust this longer explanation is clearer for you.

And yes, my objection to the proposed terminology change still stands.

  Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sun, 23 May 2010 08:16:50 +1000

> I don't think that "unverified" quite cuts it in this context, as it is not the negative counterpart to the positive "verified" assertion. A naive reader/implementer might believe that "unverified"…

Or if my followup explanation is still unclear, then "What Rob said here" is what I was intending to convey

  Geoff

---

From: Terry Manderson <[email-masked]>
Date: Sun, 23 May 2010 16:57:18 -0700

Folks,

Sorry, had weekend away from the keyboard.

> Ack. We will make this terminology change in the next revision of the draft.

Lets not be hasty :-)

I think "verified" goes closer to what is intended. Thus, one would talk
about a verified route as having a valid and matching ROA.

Although un-verified is amiss. Calling on my poor grasp of english I think
the natural antonym of 'verify' is 'refute'. I would propose 'refuted' in
the place of unverified. Thus, based on the existence of a valid ROA a route
can be refuted if originating from a spurious ASN (for example). That is we
are disproving the route was intended but not asserting, in broad
statements, that the route can't exist under some policy construct.

You could, I think, leave "unknown" in place. However "unverified" strikes
me as a better place to be, such that an unverifiable route does not have
any existing valid ROAs to match against and not statement can be made about
the route in any form.

In an order of preference one might (when asserting their routing policy)
choose:

Verified, over
Unverified, over
Refuted.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Sun, 23 May 2010 17:15:57 -0700

> believe it would have to look like this:

Does 
[
          Verified  =  1
Unknown/unverified  =  0
           Refuted  =  -1
]

work in your mental map?

I find that the valid / invalid statements when applied to routing
terminology far from palatable. Especially when explaining or deconstructing
the SIDR work to policy makers and other interested parties. Some of which
actually do have significant routing experience and start thinking that we
are somehow *changing* the BGP protocol itself and applying these (almost)
black and white states.

Cheers
Terry

---

From: Robert Loomans <[email-masked]>
Date: Mon, 24 May 2010 11:40:25 +1000

"Refuted" definitely has the right connotations.

I'm not fond of "unverified"... if "unknown" is not acceptable,  
perhaps "undetermined" is a good term.

I still have reservations about using different terms than other  
drafts. I would prefer to see one set of terminology for results from  
the RPKI. Hopefully, one that doesn't conflict with other PKI usage.

Rob

-- 
Robert Loomans

On 24/05/2010, at 10:15, Terry Manderson <[email-masked]>  
wrote:

>> [ If you were to base a comparison function for sorting on this DB  
>> lookup, I
>> believe it would have to look like this:
>>
>>    valid  =  1
>>  unknown  =  0
>>  invalid  = -1
>> ]
>>
>
> Does
> [
>          Verified  =  1
> Unknown/unverified  =  0
>           Refuted  =  -1
> ]
>
> work in your mental map?
>

---

From: Pradosh Mohapatra <[email-masked]>
Date: Sun, 23 May 2010 19:24:00 -0700

> [ If you were to base a comparison function for sorting on this DB lookup, I believe it would have to look like this:

This is exactly what is defined in draft-pmohapat-sidr-origin-validation-signaling-00, though slightly different values:

                  +-------+-----------------------------+
                  | Value | Meaning                     |
                  +-------+-----------------------------+
                  |   0   | Lookup result = "valid"     |
                  |   1   | Lookup result = "not found" |
                  |   2   | Lookup result = "invalid"   |
                  +-------+-----------------------------+

with:

      When comparing a pair of routes for a BGP destination, the route
      with the lowest "validation state" value is preferred.

- Pradosh

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 24 May 2010 10:04:41 +0200

> And yes, my objection to the proposed terminology change still stands.

My command of English is inherently inferior compared to yours, so I'll have 
to give in in whatever you guys agree on.

Our difference of opinion may be because we're in different contexts. When 
validating a *ROA*, I'm perfectly fine with valid/unknown/invalid. But when 
using a ROA to inform a routing decision, the *update* (as per section 2 of 
the draft if I'm reading it right) can be verified/unknown/unverified. In 
this light I'm not concerned if this draft uses a different terminology 
compared to ROA, certificate, etc. drafts.

If I'm not reading the draft right (in terms of whether it refers to ROAs, 
routes or updates), then some clarification text may be useful.

Robert

---

From: Terry Manderson <[email-masked]>
Date: Mon, 24 May 2010 02:11:16 -0700

> perhaps "undetermined" is a good term.

I can live with "unknown".

> the RPKI. Hopefully, one that doesn't conflict with other PKI usage.

One problem I think exists is that the desire to take strong security
constructs and taxonomies seen in PKI models where a certificate status is
binary (it either validates or does not) doesn't, in my opinion, mesh
perfectly to the routing system where we have all these fantastic grey areas
that involve preferences, policy, contracts, and so forth.

I agree that whenever you speak of a PKI certificate validation you should
use the matching language - but when it spills onto the PKI::Routing merge
I'm decidedly uncomfortable with the valid/invalid terms.

(aside: as a navel-gazing exercise I've wondered about the wisdom of linking
the allocation system to the routing system ... I digress, sorry)

Cheers
Terry

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 May 2010 15:13:41 +0200

i like good, bad, and ugly

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 May 2010 11:17:55 -0400

At 2:11 AM -0700 5/24/10, Terry Manderson wrote:
>...

Actually, in typical PKI contexts, the situation is not binary :-).

A cert may be valid, expired, or revoked. There is also a big gray 
area associated with revocation status info for the cert in question 
(or for ancestor certs).

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 24 May 2010 13:49:05 -0400 (Eastern Daylight Time)

I remind everyone discussing the terminology in the draft that the current 
question before the working group is whether the work should be adopted as 
a work item.

It would be helpful if the terminology discussion could be separated from 
the thread concerning adoption.

It would also be helpful if people would state their support or lack of 
support for adoption of the draft.  The call for adoption ends on May 26. 
There have not been many responses to that call, despite the flurry of 
messages regarding the draft.

--Sandy

---

From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" <[email-masked]>
Date: Mon, 24 May 2010 19:55:23 +0200

> messages regarding the draft.
I support adoption of the draft.

  Ruediger

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 24 May 2010 14:27:46 -0400 (Eastern Daylight Time)

Forgot to say "speaking as wg chair"

On Mon, 24 May 2010, Sandra Murphy wrote:

> question before the working group is whether the work should be adopted as a 
> work item.
>
> It would be helpful if the terminology discussion could be separated from the 
> thread concerning adoption.
>