Skip to main content

Finding and Using Geofeed Data
draft-ietf-opsawg-9092-update-11

Revision differences

Document history

Date Rev. By Action
2024-05-07
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2024-02-27
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-02-27
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-02-27
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-02-27
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-02-26
11 (System) RFC Editor state changed to EDIT
2024-02-26
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-02-26
11 (System) Announcement was received by RFC Editor
2024-02-26
11 (System) IANA Action state changed to In Progress
2024-02-26
11 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-02-26
11 Cindy Morgan IESG has approved the document
2024-02-26
11 Cindy Morgan Closed "Approve" ballot
2024-02-26
11 Cindy Morgan Ballot approval text was generated
2024-02-26
11 (System) Removed all action holders (IESG state changed)
2024-02-26
11 Robert Wilton IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2024-02-26
11 Robert Wilton Ballot approval text was generated
2024-02-22
11 Paul Wouters
[Ballot comment]
Thanks for the discussion on the items raised. I've updated my ballot to No Objection (I did not ballot 'Yes' because I did …
[Ballot comment]
Thanks for the discussion on the items raised. I've updated my ballot to No Objection (I did not ballot 'Yes' because I did not find all my raised points addressed, but these issues did not raise to the level requiring further discussion)
2024-02-22
11 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss
2024-02-22
11 (System) Changed action holders to Robert Wilton (IESG state changed)
2024-02-22
11 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-22
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-02-22
11 Randy Bush New version available: draft-ietf-opsawg-9092-update-11.txt
2024-02-22
11 (System) New version approved
2024-02-22
11 (System) Request for posting confirmation emailed to previous authors: Massimo Candela , Randy Bush , Russ Housley , Warren Kumari
2024-02-22
11 Randy Bush Uploaded new revision
2024-02-15
10 Murray Kucherawy
[Ballot comment]
All of the SHOULDs in Section 3 seemed to lack some prose about why one might legitimately deviate from the advice presented.  Absent …
[Ballot comment]
All of the SHOULDs in Section 3 seemed to lack some prose about why one might legitimately deviate from the advice presented.  Absent that, I'm wondering why they aren't all MUSTs.

===

Feedback from Orie Steele, incoming ART AD:

"An optional utterly awesome but slightly complex means for authenticating geofeed data is also defined in ..."

Not sure how I feel about that many modifiers in front of security topics, such as "authenticating".

Thanks for the ARTART review, given the emphasis on UTF-8, it would be nice to see samples that include international names, and characters.

"This SHOULD NOT be used for bulk retrieval of geofeed data."

Under what circumstances SHOULD it be used for bulk retrieval?

In Section 5:

"It is a digest of the main body of the file signed by the private key of the relevant RPKI certificate for a covering address range."

I think you mean digest of the canonicalized UTF-8 bytes produced according to the procedure that follows.

"For robustness, any non-printable characters MUST NOT be changed by canonicalization."

This seems risky, is there a common understanding of non printable characters?

"Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markers MUST NOT be covered by the digital signature."

This mounts to a deny list, that is not specified... seems risky.

I suspect many signatures might fail to validate due to differences in the canonicalization implementations, it would be good to provide a complete set of test vectors for this approach.
2024-02-15
10 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-02-15
10 (System) Changed action holders to Randy Bush, Massimo Candela, Warren Kumari, Russ Housley (IESG state changed)
2024-02-15
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-02-15
10 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2024-02-14
10 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record
2024-02-14
10 Murray Kucherawy
[Ballot comment]
All of the SHOULDs in Section 3 seemed to lack some prose about why one might legitimately deviate from the advice presented.  Absent …
[Ballot comment]
All of the SHOULDs in Section 3 seemed to lack some prose about why one might legitimately deviate from the advice presented.  Absent that, I'm wondering why they aren't all MUSTs.
2024-02-14
10 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-02-14
10 Roman Danyliw
[Ballot comment]
Thank you to Tim Hollebeek for the SECDIR review.

** Section 3. Editorial.  Consider this clarification.
OLD
  At the time of publishing …
[Ballot comment]
Thank you to Tim Hollebeek for the SECDIR review.

** 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 community.

** Section 3.

  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
  intetnum: object, the geofeed: attribute SHOULD be used.

Is there a reason that the second SHOULD, to prefer the geofeed: attribute isn’t a MUST?  Otherwise, there isn’t deterministic behavior on which attribute will be used and geofeed: won’t necessarily be preferred.

** Section 3
  For inetnum:s covering the same address range, or an inetnum: with
  both remarks: and geofeed: attributes, a signed geofeed file SHOULD
  be preferred over an unsigned file.

Is the net result of this guidance that when encountering a both types of attributes, and despite preferring the geofeed, an implementation still needs to download both and see which one is signed?  Effectively:

If there is more than one type of attribute in the intetnum: object, the geofeed: attribute SHOULD be used unless the remarks: is signed?

** Section 4.

  To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP
  [RFC0959] services SHOULD be used for large-scale access to gather
  inetnum:s with geofeed references.  This uses efficient bulk access
  instead of fetching via brute-force search through the IP space.

This guidance was in RFC9092 (July 2021).  Has anything changed in the ecosystem that would allow the use of at least SFTP?
2024-02-14
10 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-02-13
10 Éric Vyncke
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-9092-update-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT …
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-9092-update-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *BUT* it lacks the justification of the intended status.

Other thanks to Sheng Jiang, the Last Call Internet directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-opsawg-9092-update-06-intdir-lc-jiang-2023-11-20/ (and I have seen interactions with the draft authors)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## No IPv6 Examples

I can only strongly regret, esp knowing the authors, that the examples are IPv4 only.

Note: this issue prevents me to strongly support this document with a YES ballot.

## Section 3

Should the text be more normative rather than plain text
```
The migration not only implies that the RIRs support the geofeed:
attribute, but that all registrants have migrated any inetnum:
ojects from remarks: to geofeed: attributes
```
2024-02-13
10 Éric Vyncke Ballot comment text updated for Éric Vyncke
2024-02-13
10 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this specification.

I support Paul's discuss on the point of securing FTP.
2024-02-13
10 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-02-13
10 John Scudder
[Ballot comment]
Thanks for this document. I confined myself to reviewing the diff versus RFC 9092. I have just one minor question and an …
[Ballot comment]
Thanks for this document. I confined myself to reviewing the diff versus RFC 9092. I have just one minor question and an even-more-minor nit.

The question:

In RFC 9092 you have,

  Any particular inetnum: object MUST have, at most, one geofeed
  reference, whether a remarks: or a proper geofeed: attribute when it
  is implemented.  If there is more than one, all are ignored.

In this document, you have liberalized from "all are ignored" and now allow them to coexist:

  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
  intetnum: object, the geofeed: attribute SHOULD be used.
 
As far as I'm concerned, this is just fine and indeed an improvement, who doesn't like coexistence after all? But I wonder what changed that made it OK? (I think we might have debated this a bit when 9092 was approved, but I'm too lazy to go back and check...)

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.)
2024-02-13
10 John Scudder [Ballot Position Update] New position, Yes, has been recorded for John Scudder
2024-02-13
10 Paul Wouters
[Ballot discuss]
"Handling Ballot Positions" - see https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I have a number of DISCUSSes, none of which should be hard to address or talk out …
[Ballot discuss]
"Handling Ballot Positions" - see https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I have a number of DISCUSSes, none of which should be hard to address or talk out :)

#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 as Informational. But of course that would raise the issue
that an Informational would Obsolete a Standards Track document. Some discussion on this would be good.


#2 Transport Security

There are quite a few sentences scattered through the document about transport security that are not aligned, see:

        The URL uses HTTPS, so the WebPKI provides authentication
       
So is HTTPS mandatory? I guess not since (see below) FTP is allowed as URL too.

      the RIR's FTP [RFC0959] services SHOULD be used

To speak in the words of the great Monty Python, "An active or passive swallow?"

More seriously, can we avoid SHOULDing the FTP protocol?
Are these resources not made available over HTTP? If they are, can we
SHOULD that instead?  Note the paragraph above it says: "Historically,
[...] often without consistent authentication". I wouldn't call that
"Historically" if you are are promoting FTP and allow "unsigned" files.

        The geofeed files MUST be published via and fetched using HTTPS [RFC9110].

Uhm. So what about FTP now?

The Security Considerations could bundle all the talk about HTTPS and FTP and put
in one clear clause here, mentioning that due to lack of universal signing, it is
sadly super important to have transport security protection (eg HTTPS, not FTP)


#3 Signature and white space requirements are a bit troubling

        Trailing blank lines MUST NOT appear at the end of the file.

That's rather strong. Should the file be rejected if a blanc line appears
at the end? If not, I wonder why to even mention this, especially with 2119 force.
Based on:

        If the authenticator is not in the canonical form described above,
        then, the authenticator is invalid.

That is a "yes the file should be rejected if it has a trailing blanc line". I think
that is unwise, I would like to hear the reasoning behind this.

        When present, such end-of-file markers MUST NOT be covered by the digital signature.

This is going to cause problems if people make detached signatures of the file. What
is the reason for this requirement?

      The CMS signature does not cover the signature lines.

This gets really complicated now, when we read the above item on blanc lines.
Does this mean the blanc line MUST NOT appear before these # comments? Or not
after these comments? Or both? Can there be a blanc line between geofeed content
and signature? How about two blanc lines?

#4 Misc. Security comments

      The address range of the signing certificate MUST cover all
        prefixes in the signed geofeed file.

I vaguely remember huge problems with such similar requirement. The document is not
clear what to do when this is not the case? Reject everything? Or only accept those
entries that ARE covered? More guidance is needed here.

        The signing certificate MUST NOT include the Autonomous System
        Identifier Delegation certificate extension [RFC3779].

What must one do if this does include it?

        As with many other RPKI signed objects, the IP Address Delegation
        certificate extension MUST NOT use the "inherit" capability
        defined in Section 2.2.3.5 of [RFC3779].

What must one do if this does include it?

        The Certificate Authority (CA) SHOULD sign only one geofeed file
        with each generated private key and SHOULD generate a new key
        pair for each new version of a perticular geofeed file. The CA
        MUST generate a new End Entity (EE) certificate for each signing
        of a particular geofeed file.

When can these SHOULDs be ignored? Eg it _is_ possible to use the same key but
a different EE cert? Also, what is the reason for needing to generate a new EE
cert per geofeed version file? What issue is solved by not allowing a long lived
EE cert to do this job?

        When using data from a geofeed file, one MUST ignore data outside
        the referring inetnum: object's inetnum: attribute address range.

How does this "MUST ignore" combine with the above mentioned "failed validation" ?
eg here it would seem an entry to 0.0.0.0/0 must be ignored, but earlier text said
to invalidate the entire file, not just the entry. So how would we ever get here?

        If and only if the geofeed file is not signed per Section 5,
        then multiple inetnum: objects MAY refer to the same geofeed
        file, and the consumer MUST use only lines in the geofeed file
        where the prefix is covered by the address range of the inetnum:
        object's URL it has followed.

We normally call this a downgrade attack. Strip the signature and modify the file?
Are there any counter measures that can be used to prevent this attack?

        Importing datasets produced and/or processed by a third-party
        places ill-advised trust in the third-party.

I don't think you can call all third-parties "ill-advised" by definition.
eg is "google DNS" and ill-advised third-party for DNS ?
2024-02-13
10 Paul Wouters
[Ballot comment]
        Since geofeed_1 contains geolocation data about 192.0.2.0/29,
        it is discarded because 192.0.2.0/24 is within the …
[Ballot comment]
        Since geofeed_1 contains geolocation data about 192.0.2.0/29,
        it is discarded because 192.0.2.0/24 is within the more specific
        inetnum: covering the address range and that inetnum: has a
        geofeed reference.

This reads a bit odd, a 192.0.2.0/29 comes out of nowhere. I guess you meant
to say "a client looking for geofeed data for 192.0.2.0/29" ?
2024-02-13
10 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2024-02-12
10 Éric Vyncke
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-9092-update-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT …
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-9092-update-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *BUT* it lacks the justification of the intended status.

Other thanks to Sheng Jiang, the Last Call Internet directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-opsawg-9092-update-06-intdir-lc-jiang-2023-11-20/ (and I have seen interactions with the draft authors)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## No IPv6 Examples

I can only strongly regret, esp knowing the authors, that the examples are IPv4 only.

Note: this issue prevents me to strongly support this document with a YES ballot.

## Section 3

Should the text be more normative than the plain text
```
The migration not only implies that the RIRs support the geofeed:
attribute, but that all registrants have migrated any inetnum:
ojects from remarks: to geofeed: attributes
```
2024-02-12
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-02-10
10 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-opsawg-9092-update-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-opsawg-9092-update-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5

* "... processing is too hard."

  Perhaps there's a better wording that might be found here.  "imposes
  significant computational complexity" or something?
2024-02-10
10 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2024-02-08
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-02-07
10 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-02-05
10 Warren Kumari [Ballot comment]
immanorther...
2024-02-05
10 Warren Kumari Ballot comment text updated for Warren Kumari
2024-02-05
10 Warren Kumari [Ballot comment]
imanorther...
2024-02-05
10 Warren Kumari [Ballot Position Update] New position, Recuse, has been recorded for Warren Kumari
2024-02-05
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-02-05
10 Randy Bush New version available: draft-ietf-opsawg-9092-update-10.txt
2024-02-05
10 Randy Bush New version accepted (logged-in submitter: Randy Bush)
2024-02-05
10 Randy Bush Uploaded new revision
2024-02-05
09 Cindy Morgan Placed on agenda for telechat - 2024-02-15
2024-02-05
09 Robert Wilton Ballot has been issued
2024-02-05
09 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2024-02-05
09 Robert Wilton Created "Approve" ballot
2024-02-05
09 Robert Wilton IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-02-05
09 Robert Wilton Ballot writeup was changed
2024-02-05
09 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-02-01
09 Christer Holmberg Request for Last Call review by GENART Completed: Ready. Reviewer: Christer Holmberg. Sent review to list.
2024-01-31
09 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2024-01-31
09 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-01-31
09 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-9092-update-09. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-9092-update-09. If any part of this review is inaccurate, please let us know.

IANA has a question about this document.

IANA understands that, upon approval of this document, there are no IANA Actions that need completion. We request that the IANA Considerations section of the document remain in place upon publication.

However, in the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

there is an existing registration for:

Decimal: 47
Description: id-ct-geofeedCSVwithCRLF

This registration is mentioned in the section (6) of the draft called Authenticating Geofeed Data. Should the reference be changed to the new [ RFC-to-be ], since the current draft proposes to obsolete RFC9092? If so, should the IANA Considerations section of the draft reflect this?

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-01-30
09 Spencer Dawkins Request for Last Call review by ARTART Completed: Ready. Reviewer: Spencer Dawkins. Sent review to list.
2024-01-27
09 Barry Leiba Request for Last Call review by ARTART is assigned to Spencer Dawkins
2024-01-26
09 Tim Hollebeek Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tim Hollebeek. Sent review to list.
2024-01-25
09 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2024-01-22
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-01-22
09 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-02-05):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-9092-update@ietf.org, mcr+ietf@sandelman.ca, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com …
The following Last Call announcement was sent out (ends 2024-02-05):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-9092-update@ietf.org, mcr+ietf@sandelman.ca, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Finding and Using Geofeed Data) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Finding and
Using Geofeed Data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies how to augment the Routing Policy
  Specification Language inetnum: class to refer specifically to
  geofeed comma-separated values (CSV) data files and describes an
  optional scheme that uses the Resource Public Key Infrastructure to
  authenticate the geofeed data files.  This document obsoletes RFC
  9092
.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8805: A Format for Self-Published IP Geolocation Feeds (Informational - Independent Submission)



2024-01-22
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-01-22
09 Cindy Morgan Last call announcement was generated
2024-01-20
09 Robert Wilton Last call was requested
2024-01-20
09 Robert Wilton Ballot approval text was generated
2024-01-20
09 Robert Wilton Ballot writeup was generated
2024-01-20
09 Robert Wilton IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-01-20
09 Robert Wilton Last call announcement was generated
2024-01-20
09 (System) Changed action holders to Robert Wilton (IESG state changed)
2024-01-20
09 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-20
09 Randy Bush New version available: draft-ietf-opsawg-9092-update-09.txt
2024-01-20
09 Randy Bush New version accepted (logged-in submitter: Randy Bush)
2024-01-20
09 Randy Bush Uploaded new revision
2024-01-17
08 Robert Wilton Waiting on authors to reply to comments.
2024-01-17
08 (System) Changed action holders to Robert Wilton, Randy Bush, Massimo Candela, Warren Kumari, Russ Housley (IESG state changed)
2024-01-17
08 Robert Wilton IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-01-13
08 Randy Bush New version available: draft-ietf-opsawg-9092-update-08.txt
2024-01-13
08 Randy Bush New version accepted (logged-in submitter: Randy Bush)
2024-01-13
08 Randy Bush Uploaded new revision
2023-11-29
07 Joe Clarke
Document Shepherd Write-Up for Group Documents:  draft-ietf-opsawg-9092-update-06
This template is dated 4 July 2022.
The is VERSION 1.0 of the shepherd write-up, from 2023-11-27.

Document …
Document Shepherd Write-Up for Group Documents:  draft-ietf-opsawg-9092-update-06
This template is dated 4 July 2022.
The is VERSION 1.0 of the shepherd write-up, from 2023-11-27.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

There seem to be quite a few poeple reading and commenting on the document,
and it seems to be a good update.

> Was there controversy about particular points, or were there decisions where
> the consensus was particularly rough?

No great controversy.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document? Have a significant number of potential implementers indicated
> plans to implement? Are any existing implementations reported somewhere,
> either in the document itself (as RFC 7942 recommends) or elsewhere
> (where)?


>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

The document interacts with RIR databases, but this interaction has already
been taken into account.

>Describe how the document meets any required formal expert review criteria,
>such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

> If the document contains a YANG module, has the final version of the module

No YANG module.

>Document Shepherd Checks
>Based on the shepherd's review of the document, is it their opinion that this
>document is needed, clearly written, complete, correctly designed, and ready
>to be handed off to the responsible Area Director?

The document seems complete, and represents a small, but significant
increment over RFC9092.

>What type of RFC publication is being requested on the IETF stream (Best
>Current Practice, Proposed Standard, Internet Standard,
>Informational, Experimental or Historic)? Why is this the proper type
>of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is correctly slated as Standards Track.
The DT has not been updated.

>Have reasonable efforts been made to remind all authors of the intellectual
>property rights (IPR) disclosure obligations described in BCP 79? To
>the best of your knowledge, have all required disclosures been filed?

Yes.

>Has each author, editor, and contributor shown their willingness to be
>listed as such? If the total number of authors and editors on the front page
>is greater than five, please provide a justification.

All seems fine.

>Document any remaining I-D nits in this document. Simply running the idnits
>tool is not enough; please review the "Content Guidelines" on
>authors.ietf.org. (Also note that the current idnits tool generates
>some incorrect warnings; a rewrite is underway.)

idnits has some nits, lack of IPv6, abstract needs work.

>Should any informative references be normative or vice-versa? See the IESG
>Statement on Normative and Informative References.

They look fine.

>List any normative references that are not freely available to anyone. Did
>the community have sufficient access to review any such normative
>references?

None.

> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so,
> list them.

There seem to be some downref's missing, that should have been added for
RFC9092, but which were not.  Specifically, RFC5485, and RFC8805.

> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear state?
> If so, what is the plan for their completion?

No.

> Will publication of this document change the status of any existing RFCs?
> If

Yes, it will obsolete RFC9092.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

There are no IANA considerations, and no registries created or extended.




2023-11-29
07 Joe Clarke IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2023-11-29
07 Joe Clarke IESG state changed to Publication Requested from I-D Exists
2023-11-29
07 (System) Changed action holders to Robert Wilton (IESG state changed)
2023-11-29
07 Joe Clarke Document is now in IESG state Publication Requested
2023-11-28
07 Joe Clarke Tag Revised I-D Needed - Issue raised by WG cleared.
2023-11-28
07 Randy Bush New version available: draft-ietf-opsawg-9092-update-07.txt
2023-11-28
07 Randy Bush New version accepted (logged-in submitter: Randy Bush)
2023-11-28
07 Randy Bush Uploaded new revision
2023-11-27
06 Warren Kumari Shepherding AD changed to Robert Wilton
2023-11-27
06 Warren Kumari Changed consensus to Yes from Unknown
2023-11-27
06 Warren Kumari Intended Status changed to Proposed Standard from None
2023-11-27
06 Michael Richardson
Document Shepherd Write-Up for Group Documents:  draft-ietf-opsawg-9092-update-06
This template is dated 4 July 2022.
The is VERSION 1.0 of the shepherd write-up, from 2023-11-27.

Document …
Document Shepherd Write-Up for Group Documents:  draft-ietf-opsawg-9092-update-06
This template is dated 4 July 2022.
The is VERSION 1.0 of the shepherd write-up, from 2023-11-27.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

There seem to be quite a few poeple reading and commenting on the document,
and it seems to be a good update.

> Was there controversy about particular points, or were there decisions where
> the consensus was particularly rough?

No great controversy.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> For protocol documents, are there existing implementations of the contents of
> the document? Have a significant number of potential implementers indicated
> plans to implement? Are any existing implementations reported somewhere,
> either in the document itself (as RFC 7942 recommends) or elsewhere
> (where)?


>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

The document interacts with RIR databases, but this interaction has already
been taken into account.

>Describe how the document meets any required formal expert review criteria,
>such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

> If the document contains a YANG module, has the final version of the module

No YANG module.

>Document Shepherd Checks
>Based on the shepherd's review of the document, is it their opinion that this
>document is needed, clearly written, complete, correctly designed, and ready
>to be handed off to the responsible Area Director?

The document seems complete, and represents a small, but significant
increment over RFC9092.

>What type of RFC publication is being requested on the IETF stream (Best
>Current Practice, Proposed Standard, Internet Standard,
>Informational, Experimental or Historic)? Why is this the proper type
>of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is correctly slated as Standards Track.
The DT has not been updated.

>Have reasonable efforts been made to remind all authors of the intellectual
>property rights (IPR) disclosure obligations described in BCP 79? To
>the best of your knowledge, have all required disclosures been filed?

Yes.

>Has each author, editor, and contributor shown their willingness to be
>listed as such? If the total number of authors and editors on the front page
>is greater than five, please provide a justification.

All seems fine.

>Document any remaining I-D nits in this document. Simply running the idnits
>tool is not enough; please review the "Content Guidelines" on
>authors.ietf.org. (Also note that the current idnits tool generates
>some incorrect warnings; a rewrite is underway.)

idnits has some nits, lack of IPv6, abstract needs work.

>Should any informative references be normative or vice-versa? See the IESG
>Statement on Normative and Informative References.

They look fine.

>List any normative references that are not freely available to anyone. Did
>the community have sufficient access to review any such normative
>references?

None.

> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so,
> list them.

There seem to be some downref's missing, that should have been added for
RFC9092, but which were not.  Specifically, RFC5485, and RFC8805.

> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear state?
> If so, what is the plan for their completion?

No.

> Will publication of this document change the status of any existing RFCs?
> If

Yes, it will obsolete RFC9092.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

There are no IANA considerations, and no registries created or extended.




2023-11-22
06 Bo Wu Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Bo Wu. Sent review to list.
2023-11-20
06 Jenny Bui This document now replaces draft-ymbk-opsawg-9092-update, draft-ymbk-9020-update instead of draft-ymbk-opsawg-9092-update
2023-11-20
06 Sheng Jiang Request for Last Call review by INTDIR Completed: Ready with Nits. Reviewer: Sheng Jiang. Sent review to list.
2023-11-15
06 Joe Clarke Tag Revised I-D Needed - Issue raised by WG set.
2023-11-15
06 Joe Clarke IETF WG state changed to In WG Last Call from WG Document
2023-10-26
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tim Hollebeek
2023-10-25
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bo Wu
2023-10-23
06 Bernie Volz Request for Last Call review by INTDIR is assigned to Sheng Jiang
2023-10-23
06 Joe Clarke Requested Last Call review by OPSDIR
2023-10-23
06 Joe Clarke Requested Last Call review by INTDIR
2023-10-23
06 Joe Clarke Requested Last Call review by SECDIR
2023-10-23
06 Randy Bush New version available: draft-ietf-opsawg-9092-update-06.txt
2023-10-23
06 Randy Bush New version accepted (logged-in submitter: Randy Bush)
2023-10-23
06 Randy Bush Uploaded new revision
2023-10-16
05 Randy Bush New version available: draft-ietf-opsawg-9092-update-05.txt
2023-10-16
05 Randy Bush New version accepted (logged-in submitter: Randy Bush)
2023-10-16
05 Randy Bush Uploaded new revision
2023-09-24
04 Randy Bush New version available: draft-ietf-opsawg-9092-update-04.txt
2023-09-24
04 (System) New version approved
2023-09-24
04 (System) Request for posting confirmation emailed to previous authors: Massimo Candela , Randy Bush , Russ Housley , Warren Kumari
2023-09-24
04 Randy Bush Uploaded new revision
2023-09-20
03 Randy Bush New version available: draft-ietf-opsawg-9092-update-03.txt
2023-09-20
03 (System) New version approved
2023-09-20
03 (System) Request for posting confirmation emailed to previous authors: Massimo Candela , Randy Bush , Russ Housley , Warren Kumari
2023-09-20
03 Randy Bush Uploaded new revision
2023-09-18
02 Randy Bush New version available: draft-ietf-opsawg-9092-update-02.txt
2023-09-18
02 (System) New version approved
2023-09-18
02 (System) Request for posting confirmation emailed to previous authors: Massimo Candela , Randy Bush , Russ Housley , Warren Kumari
2023-09-18
02 Randy Bush Uploaded new revision
2023-09-13
01 Randy Bush New version available: draft-ietf-opsawg-9092-update-01.txt
2023-09-13
01 (System) New version approved
2023-09-13
01 (System) Request for posting confirmation emailed to previous authors: Massimo Candela , Randy Bush , Russ Housley , Warren Kumari
2023-09-13
01 Randy Bush Uploaded new revision
2023-08-26
00 Joe Clarke Notification list changed to mcr+ietf@sandelman.ca because the document shepherd was set
2023-08-26
00 Joe Clarke Document shepherd changed to Michael Richardson
2023-08-24
00 Joe Clarke This document now replaces draft-ymbk-opsawg-9092-update instead of None
2023-08-24
00 Randy Bush New version available: draft-ietf-opsawg-9092-update-00.txt
2023-08-24
00 Joe Clarke WG -00 approved
2023-08-24
00 Randy Bush Set submitter to "Randy Bush ", replaces to draft-ymbk-opsawg-9092-update and sent approval email to group chairs: opsawg-chairs@ietf.org
2023-08-24
00 Randy Bush Uploaded new revision