>>> 3. The definition of canonicalization refers to section 2.2 of RFC
>>> 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is
>>> this disparity an issue?
>>
>> russ, how do you want to handle?
>
> This is really about line endings, but it would probably be best to
> assign a
thanks ggm for a stunningly thorough shepherd's report. i have an -03
revsion in an emacs buffer addressing your comments which i will publish
when you, the wg chairs, or ... tell me to do so.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
> please push the 03. I think it is very likely to close all the low-level Nits.
done
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> But if a lookup process was interested in finding a geofeed for an IP
> address within B, would it have any reason or automated means to
> backtrack and lookup knowledge of the signed geofeed for A? Do
> inetnum lookups return all superprefix inetnums as well? (asking for
> a friend)
whoops!
i have reverted the doc in my emacs buffer. -03 stands
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> target="https://sobornost.net/~job/using_geofeed_authenticators.txt;>
>
> Example on how to use rpki-client to authenticate a signed
> Geofeed
>
>
>
>
thanks
>>> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to
>>> each
>>> Ah, ok. For both RSC and RTA distinct properties are listed such as
>>> "applicable in long run", "usable", "complex code"; if no comparison is
>>> intended I'd just remove the two paragraphs about RTA & RSC.
>>
>> we seem to be at cross-purposes here. the point was not comparison at
>> all.
> please resubmit this draft as draft-ietf-opsawg-9092-update-00
> replacing draft-ymbk-opsawg-9092-update. Do not make any other
> changes to the document text.
done. thanks.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
ok, i am trying to make some time for this. thanks for the review!
> In section 8 'Implementation Status', a reference could be added to
> https://www.rpki-client.org/. I extended this RPKI validator
> implementation to have the ability to cryptographically verify a given
> RPKI-signed Geofeed
authors pushed latest revision of $ubject. would very much like some wg
members, or anyone actually. to have a look and comment before we decide
if it is time to ask for wglc.
thavanceanks
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
> authors pushed latest revision of $ubject. would very much like some
> wg members, or anyone actually. to have a look and comment before we
> decide if it is time to ask for wglc.
well, that elicited only one poke (thanks ggm) :(
chairs, think a wglc will elicit more?
randy
> I will work on items 1-4 for the next version.
thanks. and thanks job for the careful eyeballs
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Small nit: the “Error: Spurious zero bits in bitstring.” line in the
> dumpasn1 output in Appendix A can be removed, to avoid confusing the
> reader. I suspect that particular error message is a bug in dumpasn1
> rather than in the encoding example.
thanks. fixed. not worth a new push unless
definitely adopt, please
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> As an contributor, I rather like the simpler TLS encap over T+
> approach described in the tls13 draft. I’d personally not
> over-engineer something that isn’t immediately required. T+ has been
> around for a while and is heavily used. I don’t know that we need to
> spend time adding
> - The TACACS+ authentication is extended to allow the TACACS+ client
> to request the public keys from the TACACS+ server, to ease ssh-key
> management
delivered signed by the private key for proof of posession, yes?
randy
___
OPSAWG mailing
hi med,
>>> (4) Note sure we can mandate by spec how the data can be
>>> "consumed". I'm afraid the NEW sentence in the Sec Cons>> isn't
>>> useful. I would at least avoid the use of normative language
>>> there.
>>
>> you mean
>>
>> The consumer of geofeed data SHOULD fetch and
hi med,
yay! much thanks for the review.
> (1) As a complement to the discussion in the first para of the
> Introduction, I would add a note that the source address does not
> necessary point to the user. You may add a pointer to
> https://datatracker.ietf.org/doc/html/rfc6269#autoid-14 when
> I’ve read the original draft and the diff mentioned below.
thanks. reviews are hard to find these days.
> I think you’ve misspelled RIR as IRR in the diff.
do you mean
Absent implementation of the geofeed: attribute in a particular IRR
database
if so, it was intentional. perhaps
> Absent implementation of the geofeed: attribute in a particular IRR
> database
>
> if so, it was intentional. perhaps s/IRR/Whois/?
>
> JMC: Yep. I see what you’re saying now. I was reading as RIR. I
> think IRR is fine, but perhaps it should be expanded like you do RIR
> earlier.
No, I'm not aware of any IPR that applies to this draft
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
-01 was just published. the authors believe it is ready for adoption by
the opsawg.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
we have pushed draft-ymbk-opsawg-9092-update-01, see
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/
and asked to have a few minutes for it on the agenda next month.
as the document says
Changes from [RFC9092] include the following:
* It is no longer assumed that a geofeed
>>> The consumer of geofeed data SHOULD fetch and process the data
>>> themselves. Importing datasets produced and/or processed by a third-
>>> party places significant trust in the third-party.
>>
>> this is in sec cons already. you want it moved up or duplicated? i
>> kinda like it
thanks roman,
> ** Section 3. Editorial. Consider this clarification.
> OLD
>At the time of publishing this document, change control effectively
>lies in the operator community.
>
> NEW
> At the time of publishing this document, change control of RPSL effectively
> lies in the operator
>>Any particular inetnum: object SHOULD have, at most, one geofeed
>>reference, whether a remarks: or a proper geofeed: attribute when it
>>is implemented. A geofeed: attribute is preferred, of course, if the
>>RIR supports it. If there is more than one type of attribute in the
> Suggested edits:
>
>The address range of the signing certificate MUST cover all prefixes
>in the signed geofeed file. If not, the authenticator is invalid.
>
>The signing certificate MUST NOT include the Autonomous System
>Identifier Delegation certificate extension [RFC3779].
thanks erik,
> * "... processing is too hard."
>
> Perhaps there's a better wording that might be found here. "imposes
> significant computational complexity" or something?
how about
processing would be quite complex and error prone
randy
thanks for review, paul
> #1 document track
>
> The document is Standards Track, and so are the docs is
> Obsoletes/Updates ([RFC2725] and [RFC4012]), but the document also
> claims "change control effectively lies in the operator community".
> Normally, that would mean the IETF publishes this
> The nit:
>
> 192.0.2.0/12 (in Section 3) isn’t what I consider a well-formed prefix, since
> the third octet has a set bit but isn’t under the mask. I would’ve said
> 192.0.0.0/12. (Or better still 192.0/12, but that form seems to be
> disfavored.)
nit? looks like a full grown bug to me.
i just pushed -08 with what i believe to be all fixes from comments on
-07. it may be time to push the button on this one.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
>> i just pushed -08 with what i believe to be all fixes from comments on
>> -07. it may be time to push the button on this one.
> Actually, Joe did that on 2023-11-29, and it is sitting in Rob
> Wilton's AD queue…
doh.
randy
___
OPSAWG mailing list
hi rob,
thanks for review. appreciated.
> (1) p 4, sec 3. inetnum: Class
>
>Any particular inetnum: object SHOULD have, at most, one geofeed
>reference, whether a remarks: or a proper geofeed: attribute when it
>is implemented. If there is more than one, the geofeed: attribute
>
hi
> 1. Abbreviations
> Severl abbreviations in the newly added text is better to be expanded
> on the first use, including Certification Authority (CA), EE
> (end-entity), Certificate Revocation List (CRL) and Autonomous System
> (AS).
done, i hope
> 2. Content seems repetitive
> Section 3:
>
tim:
> (1) The following paragraph appears twice in the document (looks like just a
> copy/paste error when moving stuff around):
>
> "Identifying the private key associated with the certificate and
>getting the department that controls the private key (which might be
>stored in a
> Q1: There are a few places where the document says "Currently". I'd
> prefer to instead say something like "At the time of publishing this
> document". I do realize this issue already exists in RFC 9092.
sure. thanks.
randy
___
OPSAWG mailing list
> Please push -09, and I’ll push to the IETF LC.
done
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
hi med,
thanks a million for the time reviewing
> * Abstract: add "This document obsoletes RFC 9092.
sure; in my emacs buffer for -07. aside: is this sort of doc tracking
in abstracts a fashion?
> * Abstract: s/datafiles/data files
doh. thanks.
> * The changes vs 9092 lists
thanks, med. all in emacs buffer for -07.
this is wglc. would appreciate more constructive reviews.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
how about rewording to remove second must so we don't need to argue over
it? :)
OLD:
and the file geofeed_1 contains geolocation data about 192.0.2.0/29,
this MUST be discarded because 192.0.2.0/24 is within the more
specific inetnum: covering the address range and that inetnum: has a
hi
> Reviewer: Sheng Jiang
> Review result: Ready with Nits
>
> Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
> Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286)
fixed. thank you!
> Downref: Normative reference to an Informational RFC: RFC 8805
been to this
> https://scholar.google.com/scholar_url?url=https://dejankosticgithub.github.io/documents/publications/netconfeval-conext24.pdf=en=X=7785844682567625222=DLI-Zr27FsuNy9YPtfamqA8=AFWwaebA2r_Fw4okI0irTPrMsu7W=scholaralrt=LiEm55wJ:3177637049449935640:AFWwaeY5VE3Htr-mPxtni0xheb_1==2=rel
worth a
paul
you may, or may not, like -11. we tried to clarify some things a bit
better,
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
101 - 143 of 143 matches
Mail list logo
