----- Original Message -----
From: "Geoff Huston" <[email protected]>
Sent: Tuesday, November 28, 2017 10:01 AM
> Reject - in the context of resource certificates the resources may
contain
> both IP addresses _AND_ AS numbers.
Precisely; it is a 'may' whereas the current text
"Given two IP address and AS number sets,"
has overtones of requiring both to be present. The later phrase,
"for every contiguous range of IP addresses or AS numbers elements in
set Y,"
does imply one or the other or both, so I am on the side of 'Accept'.
Note, too, that the two earlier definitions, ' more specific' and
'equal', both say
" Given two contiguous IP address ranges or two contiguous AS
number ranges, ..."
Why should 'encompass' be different?
Tom Petch
> > On 28 Nov 2017, at 8:04 pm, RFC Errata System
<[email protected]> wrote:
> >
> > The following errata report has been submitted for RFC6487,
> > "A Profile for X.509 PKIX Resource Certificates".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5187
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Nikolai Malykh <[email protected]>
> >
> > Section: 7.1
> >
> > Original Text
> > -------------
> > encompass
> > Given two IP address and AS number sets, X and Y, X
> > "encompasses" Y if, for every contiguous range of IP
addresses
> > or AS numbers elements in set Y, the range element is either
> > "more specific" than or "equal" to a contiguous range
element
> > within the set X.
> >
> >
> > Corrected Text
> > --------------
> > encompass
> > Given two IP address or two AS number sets, X and Y, X
> > "encompasses" Y if, for every contiguous range of IP
addresses
> > or AS numbers elements in set Y, the range element is either
> > "more specific" than or "equal" to a contiguous range
element
> > within the set X.
> >
> >
> > Notes
> > -----
> >
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC6487 (draft-ietf-sidr-res-certs-22)
> > --------------------------------------
> > Title : A Profile for X.509 PKIX Resource Certificates
> > Publication Date : February 2012
> > Author(s) : G. Huston, G. Michaelson, R. Loomans
> > Category : PROPOSED STANDARD
> > Source : Secure Inter-Domain Routing
> > Area : Routing
> > Stream : IETF
> > Verifying Party : IESG
>
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
