Skip to main content

SIDR Operations
charter-ietf-sidrops-01

Yes

(Alexey Melnikov)
(Alia Atlas)

No Objection

(Stephen Farrell)
(Suresh Krishnan)

Note: This ballot was opened for revision 00-03 and is now closed.

Ballot question: "Is this charter ready for external review?"

Alvaro Retana Yes

Comment (2016-09-28 for -00-03)
1. "SIDR operational and deployment issues with Interdomain Routing Protocols are the primary responsibility of the IDR working group.  The sidr-ops Working Group may provide input to that group, as needed, and cooperate with that group in reviewing solutions to SIDR operational and deployment problems."

Yes.  Depending on what the issue is, grow should be involved too.  Mention of grow would be nice.

2. "Future work items within this scope will be adopted by the Working Group if there is a substantial expression of interest from the community and if the work (for example protocol maintenance clearly does not fit elsewhere in the IETF."

Which protocol are you talking about?

BGPSEC, which is an extension to BGP, should be the responsibility of idr.  In the worst case, it shouldn't be changed without close coordination with idr.  

Other protocols such as the rtr-to-rpki protocol, or the delta protocol don't clearly fit elsewhere and are only really used for sidr, so that is ok.

(Alexey Melnikov; former steering group member) Yes

Yes (for -00-03)

                            

(Alia Atlas; former steering group member) Yes

Yes (for -00-03)

                            

(Deborah Brungard; former steering group member) Yes

Yes (2016-09-28 for -00-03)
+1 on Spencer's suggestion for first sentence. I'm interested in Joel's
response to Jari's proposed change to the second sentence as my
interpretation of the work was to avoid two separate networks
(i.e. keep the original sentence).

I had difficulty parsing the 3rd sentence:
sidrops works to ensure as secure a routing system as possible,
through encouraged deployment of the SIDR technologies.
Suggest:
Sidrops is responsible for encouraging deployment of the
SIDR technologies while ensuring as secure of a global
routing system, as possible, during the transition.

Also difficult parsing the sentence:
"In the space of sidr-ops, the term operators will encompass more
than just network operators: CA Operators, Regional/National and
Local Internet Registries, Relying Party software developers as well
as the research/measurement community all have relevant
operational experience or insight that this working group will
consider in its work."
Suggest:
In the space of sidrops, the term operators will encompass a range
of operational experience: Network Operators, CA Operators,
Regional/National and Local Internet Registries, Relying Party
software developers, as well as the research/measurement
community, all have relevant operational experience or insight
that this working group will consider in its work.

"1. Solicit input from all operators"  (and "2") is probably
overzealous, how about:
"Solicit input from a range of operators"

(Jari Arkko; former steering group member) Yes

Yes (2016-09-27 for -00-03)
This work should definitely go forward!

A couple of text suggestions though:

Isn't this a potentially too simple description:

  The global deployment of RPKI, Origin Validation of BGP announcements
  and BGPSEC, collectively called SIDR, is underway, creating an Internet
  Routing System consisting of SIDR-aware and non-SIDR-aware networks.
  This deployment must be properly handled to avoid the division of
  the Internet into separate networks.

Isn't the issue more complicated, though? Traditionally, you'd
also have the issue of being able to benefit from added security
while also having to work with those parts of the system that
haven't been upgraded. The traditional security incentives
questions.

I'd probably have written this, for instance, as:

  The global deployment of RPKI, Origin Validation of BGP announcements
  and BGPSEC, collectively called SIDR, is underway, creating an Internet
  Routing System consisting of SIDR-aware and non-SIDR-aware networks.
  This deployment must be properly handled to ensure that the Internet
  can have both types of networks while benefitting from the increasing
  deployment of the SIDR technology.

I'd also change "sidrops works to ensure as ..." to say "This working group works to ensure as ..."

(Spencer Dawkins; former steering group member) Yes

Yes (2016-09-27 for -00-03)
I was struggling a bit to parse "The global deployment of RPKI, Origin Validation of BGP announcements and BGPSEC, collectively called SIDR, is underway". I wondered if "The global deployment of SIDR, consisting of RPKI, Origin Validation of BGP announcements, and BGPSEC, is underway" might be clearer, especially with an Oxford comma. Am I reading that right? I saw that Jari also wordsmithed this paragraph, but don't think my proposed text clashes with his.

I liked Benoit's suggestion to expand SIDR on first use.
  
Is sidrops the same thing as sidr-ops? If so, it would be clearer if only one term was used.

In this text:

  Future work items within this scope will be adopted by the Working
  Group if there is a substantial expression of interest from
  the community and if the work (for example protocol maintenance 
  clearly does not fit elsewhere in the IETF.
  
I think there's a missing closing paren after "maintenance".

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-09-28 for -00-03)
Couple of suggestions for readability:

OLD
The main focuses of the SIDR Operations Working Group are to:
  
    o Discuss deployment and operational issues related to SIDR technologies
      in networks which are part of the global routing system.
    o Gather and discuss deployment experiences with the SIDR technologies in
      networks which are part of the global routing system, as well as the 
      repositories and CA systems that also form part of the SIDR architecture

NEW
The sidrops working group is focused on deployment and operational issues and experiences with SIDR technologies that are part of the global routing system, as well as the repositories and CA systems that form part of the SIDR architecture.

OLD
  3. Operational olutions for identified issues should be developed
  in sidr-ops and documented in informational or BCP documents.

NEW
  3. Develop operational solutions for identified issues and document them in informational or BCP documents.

(Ben Campbell; former steering group member) No Objection

No Objection (2016-09-28 for -00-03)
"SIDR operational and deployment issues with Interdomain Routing Protocols
  are the primary responsibility of the IDR working group.  The
  sidr-ops Working Group may provide input to that group, as needed, and
  cooperate with that group in reviewing solutions to SIDR operational and
  deployment problems."

Is "may" the right term here? I assume any wg "may" provide cooperate with any other wg without a need for permission. Is the point to actually encourage that cooperation?

"There must be a continuous expression of interest for the Working
  Group to work on a particular work item. If there is no longer
  sufficient interest in the Working Group in a work item, the item
  may be removed from the list of Working Group items."

 Is this not true for all groups? Or do you mean "must" or "should" be removed, which would connect better to the idea that "There must be a continuous expression..."

I agree with several of the readability and other editorial comments from other ADs; I will not duplicate them here, but will add the comment that "/ " should not substitute for "and" or "or".

(Benoît Claise; former steering group member) No Objection

No Objection (2016-09-27 for -00-03)
On top of Mirja's feedback, I would expand SIDR in the WG name. And in the description as well.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-09-27 for -00-03)
Interested to see the discussion from Jari's first question.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-09-19 for -00-03)
1) Is the timeline of the milestones correct? All drafts (that already exist) will be adopted in July 2017 (10 months from now) and then send to the IESG only 2 month later (Sep 2017)...?

2) I thought this is true for all wgs:
"Future work items within this scope will be adopted by the Working
  Group if there is a substantial expression of interest from
  the community and if the work (for example protocol maintenance 
  clearly does not fit elsewhere in the IETF.

  There must be a continuous expression of interest for the Working
  Group to work on a particular work item. If there is no longer
  sufficient interest in the Working Group in a work item, the item
  may be removed from the list of Working Group items."
Is there an actually reason to write this down for this wg?

3) Could the charter say something more about the drafts that are listed already in the milestones...?
The charter says:
"The SIDR Operations Working Group (sidrops) develops guidelines for
  the operation of SIDR-aware networks, and provides operational guidance
  on how to deploy and operate SIDR technologies in existing and new networks."
However at least draft-kklf-sidr-route-server-rpki-light seems to provide more than just 'guidance'...
Is this in scope with the current charter?

Nits:
- still some occurrences of sidr-ops instead sidrops
- s/3. Operational olutions/3. Operational solutions/
- missing bracket:
"(for example protocol maintenance 
  clearly does not fit elsewhere in the IETF."

(Stephen Farrell; former steering group member) No Objection

No Objection (for -00-03)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -00-03)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (2016-09-28 for -00-03)
There a philosophical item that I find concerning about SIDR, its global adoption, and the global accuracy / "uniqueness" / of IP number resources. The best way I can describe this is as "building a castle on sand". The IAB have been quite clear about how to ensure that the properties related to uniqueness are maintained, and several in the (old) SIDR-WG seem share that view. However there seems to be a inherent struggle between the RIR community and that very substantial ideal. Operationally where does that leave the deployment of SIDR should the underlying RPKI structure falter through a dilution of the architecture? (which was originally designed this way to provide assurances of uniqueness)

Moving forward into an assessment of  deployment I would very much like this item called out, and addressed, as an operational concern.