Deferred: IETF mail service outage planned for 1200 UTC on 27 June 2024

[Robert Sparks]

The IETF mail service outage planned for today has been deferred. No 
change to the mail systems has been made. This transition will be 
rescheduled at a future date.


Robert Sparks

Tools Team Project Manager

On 6/25/24 2:47 PM, Robert Sparks wrote:


As part of the overall transition of IT infrastructure, we are 
planning an outage of the IETF mail processing system starting around 
1200 UTC on 27 June 2024. The outage window is from 1200 UTC to 1500 
UTC. The actual outage duration is expected to last no more than 1 hour.



During the outage, delivery of messages to email lists at ietf.org, 
iab.org, irtf.org and rfc-editor.org will be paused. Messages sent to 
lists during the outage will be queued for delivery at the end of the 
outage. The web interface for Mailman3 also will be unavailable.



Non-list mail delivery is expected to be uninterrupted.


Persons sending email to the IETF system for the first time may 
encounter problems confirming the new address during this period.



This transition moves our primary mail sending to be through AWS. The 
relevant SPF records have already been updated.



An update will be provided once the work is complete, and no later 
than 1500 UTC 27 June.



RjS


IETF Tools Project Manager
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

IETF mail service outage planned for 1200 UTC on 27 June 2024

[Robert Sparks]

As part of the overall transition of IT infrastructure, we are planning 
an outage of the IETF mail processing system starting around 1200 UTC on 
27 June 2024. The outage window is from 1200 UTC to 1500 UTC. The actual 
outage duration is expected to last no more than 1 hour.



During the outage, delivery of messages to email lists at ietf.org, 
iab.org, irtf.org and rfc-editor.org will be paused. Messages sent to 
lists during the outage will be queued for delivery at the end of the 
outage. The web interface for Mailman3 also will be unavailable.



Non-list mail delivery is expected to be uninterrupted.


Persons sending email to the IETF system for the first time may 
encounter problems confirming the new address during this period.



This transition moves our primary mail sending to be through AWS. The 
relevant SPF records have already been updated.



An update will be provided once the work is complete, and no later than 
1500 UTC 27 June.



RjS


IETF Tools Project Manager
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Planned Key IETF service transitions complete

[Robert Sparks]

The June 20 transition of the following services to our new cloud 
infrastructure is complete:


   • the IETF Datatracker,
   • the www.ietf.org website,
   • the IETF Mailarchive, and
   • the IMAP and rsync services.

The transition took approximately 2 hours.

These services are fully functional at this point, and normal use should 
proceed.


Posting new Internet-Drafts (I-Ds) to the IETF repository is now 
available as before.


If you encounter issues, please report them as you normally would:

 * open an issue at the relevant github repository (linked on each
   applications pages),
 * send email to tools-h...@ietf.org for login issues,
 * send email to tools-disc...@ietf.org for general issues,

    or

 * send email to supp...@ietf.org for urgent matters

Thank you for your patience during this transition.

Robert Sparks

IETF Tools Project Manager
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Final Reminder: Key IETF service outages during transition to new infrastructure on 20 June

[Robert Sparks]

We are on track to make these changes and will begin at the scheduled 
time below. Another message will be sent when we are finished.


On 6/19/24 11:49 AM, Robert Sparks wrote:


Reminder of the planned outage:

On 6/12/24 10:02 AM, Robert Sparks wrote:


As part of moving to a new cloud infrastructure, the IETF Datatracker 
and related services will be unavailable starting at 1800 UTC on 
Thursday 20 June. The outages are expected to last no more than 4 
hours; updates will be posted when availability resumes.



The following services will transition to the new cloud infrastructure:


   • the IETF Datatracker,

   • the www.ietf.org website,

   • the IETF Mailarchive, and

   • the IMAP and rsync services.


IMPORTANT: Please do not plan to rely on the IETF Datatracker or the 
affected systems during the 4-hour window starting at 1800 UTC on 
Thursday 20 June.



Any service that relies on IETF Datatracker also will be affected. 
The following services will not be available:



   • the IETF meeting registration system, and

   • any interim meeting sessions that use MeetEcho integrated with 
the IETF Datatracker.



The following services will be impaired, with any features requiring 
logging in unavailable:



   • the IETF Notes service (editing notes will not be possible)

   • IETF wikis, including wiki.ietf.org and chairs.ietf.org (editing 
wiki pages will not be possible)


   • The IETF Zulip service (any new connection will not work)


OF PARTICULAR NOTE: Posting Internet-Drafts (I-Ds) to the IETF 
repository will be unavailable during the outage; this includes 
automated posting of I-Ds via the IETF Datatracker API, such as via 
Github actions in repositories used to develop I-Ds.



Please see this blog post for more details:


https://www.ietf.org/blog/it-infrastructure-outage-2024-06-20/ 
<https://www.ietf.org/blog/it-infrastructure-outage-2024-06-20/>



The blog post will be updated once this phase of the IT 
infrastructure transition is complete.



RjS


IETF Tools Project Manager
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Reminder: Key IETF service outages during transition to new infrastructure on 20 June

[Robert Sparks]

Reminder of the planned outage:

On 6/12/24 10:02 AM, Robert Sparks wrote:


As part of moving to a new cloud infrastructure, the IETF Datatracker 
and related services will be unavailable starting at 1800 UTC on 
Thursday 20 June. The outages are expected to last no more than 4 
hours; updates will be posted when availability resumes.



The following services will transition to the new cloud infrastructure:


   • the IETF Datatracker,

   • the www.ietf.org website,

   • the IETF Mailarchive, and

   • the IMAP and rsync services.


IMPORTANT: Please do not plan to rely on the IETF Datatracker or the 
affected systems during the 4-hour window starting at 1800 UTC on 
Thursday 20 June.



Any service that relies on IETF Datatracker also will be affected. The 
following services will not be available:



   • the IETF meeting registration system, and

   • any interim meeting sessions that use MeetEcho integrated with 
the IETF Datatracker.



The following services will be impaired, with any features requiring 
logging in unavailable:



   • the IETF Notes service (editing notes will not be possible)

   • IETF wikis, including wiki.ietf.org and chairs.ietf.org (editing 
wiki pages will not be possible)


   • The IETF Zulip service (any new connection will not work)


OF PARTICULAR NOTE: Posting Internet-Drafts (I-Ds) to the IETF 
repository will be unavailable during the outage; this includes 
automated posting of I-Ds via the IETF Datatracker API, such as via 
Github actions in repositories used to develop I-Ds.



Please see this blog post for more details:


https://www.ietf.org/blog/it-infrastructure-outage-2024-06-20/ 
<https://www.ietf.org/blog/it-infrastructure-outage-2024-06-20/>



The blog post will be updated once this phase of the IT infrastructure 
transition is complete.



RjS


IETF Tools Project Manager
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Key IETF service outages during transition to new infrastructure on 20 June

[Robert Sparks]

As part of moving to a new cloud infrastructure, the IETF Datatracker 
and related services will be unavailable starting at 1800 UTC on 
Thursday 20 June. The outages are expected to last no more than 4 hours; 
updates will be posted when availability resumes.



The following services will transition to the new cloud infrastructure:


   • the IETF Datatracker,

   • the www.ietf.org website,

   • the IETF Mailarchive, and

   • the IMAP and rsync services.


IMPORTANT: Please do not plan to rely on the IETF Datatracker or the 
affected systems during the 4-hour window starting at 1800 UTC on 
Thursday 20 June.



Any service that relies on IETF Datatracker also will be affected. The 
following services will not be available:



   • the IETF meeting registration system, and

   • any interim meeting sessions that use MeetEcho integrated with the 
IETF Datatracker.



The following services will be impaired, with any features requiring 
logging in unavailable:



   • the IETF Notes service (editing notes will not be possible)

   • IETF wikis, including wiki.ietf.org and chairs.ietf.org (editing 
wiki pages will not be possible)


   • The IETF Zulip service (any new connection will not work)


OF PARTICULAR NOTE: Posting Internet-Drafts (I-Ds) to the IETF 
repository will be unavailable during the outage; this includes 
automated posting of I-Ds via the IETF Datatracker API, such as via 
Github actions in repositories used to develop I-Ds.



Please see this blog post for more details:


https://www.ietf.org/blog/it-infrastructure-outage-2024-06-20/ 




The blog post will be updated once this phase of the IT infrastructure 
transition is complete.



RjS


IETF Tools Project Manager
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Updated subscription and management for IETF, IRTF, IAB, and RFC-Editor email lists

[Robert Sparks]

Following the transition to the mailman3 system for email lists, a new 
web-based interface (Postorius) is used to manage list subscriptions and 
for list moderator and owner actions. Previous mailman2 list passwords 
are no longer operative and may be deleted.


Action is required to create a Postorius account.

Details about managing email list subscriptions are available at:

https://www.ietf.org/participate/lists/#managing 



Please be sure to skim the "Important notes" section at that link.

Further details about list moderator tasks are available at:

https://chairs.ietf.org/en/mailing-lists#list-management 



If you have issues creating and managing your Postorious account contact 
supp...@ietf.org.


Discussion should take place at tools-disc...@ietf.org

RjS
___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Missing messages to lists from May 6 to May 9 will appear later today.

[Robert Sparks]

During a period from May 6 to May 9, there were a number of email 
messages intended for lists that were accepted by our email service, but 
not forwarded to the list members or the list archives.


We believe we have identified those messages and will be re-injecting 
them so that they are delivered to the current list subscribers and to 
the archives. They are unmodified. They will contain their original Date 
header and will appear at that the date and time in that header in the 
archives. But of course, the related transport headers for the messages 
delivered to list members will reflect the time of re-injeciton.


We have taken care not to re-inject a message that is already in the 
archives (by Message-ID). Note, however, that participants may already 
have sent new messages with similar content.


We will re-inject these messages shortly after this announcement is 
available in the archives.


If you see anything that doesn't look right after the messages have been 
sent, please let us know at supp...@ietf.org.


We apologize for any problems this may have caused and thank you for 
your patience in waiting for a solution.


RjS



___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Re: Brief outage for the RPC infrastructure tomorrow (15May)

[Robert Sparks]

This is complete. Apologies for any inconvenience encountered during 
this change.


RjS

On 5/14/24 4:58 PM, Robert Sparks wrote:
We will be making changes to the infrastructure supporting the RFC 
Editor tomorrow, 15May starting around 1200 UTC.


It is expected that most web pages at the RFC Editor websites, 
particularly www.rfc-editor.org, will serve from cache during these 
changes, but there will be a brief period where interactive pages will 
not be available. Non-HTTP-based services, such as rsync and ftp, will 
also not be available during this brief outage. Should you encounter a 
disruption during this time, please be patient and retry your query 
later in the day.


An update will be sent when these changes are complete.

RjS



___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Mailing lists delivery issues update

[Robert Sparks]

(see also https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/).

During the period from 6May to 9May, not all messages sent to the 
mailing lists for the IETF, IRTF, IAB, IESG, and RFC-Editor were 
delivered. The issues preventing delivery have been addressed. All new 
mail is being delivered as it should be.


If you sent a message to a list during that time, and it does not appear 
in that list's archives at https://mailarchive.ietf.org, please resend 
the message at your earliest convenience.


We will continue to try to recover any messages that failed to deliver 
during that time, but request you resend anything missing now anyhow as 
that may take significantly more time.


There are a few remaining issues with list administrivia and details of 
list configuration that are being addressed.


Any questions, or reports of further issues, should be sent to 
tools-disc...@ietf.org


RjS


___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Brief outage for the RPC infrastructure tomorrow (15May)

[Robert Sparks]

We will be making changes to the infrastructure supporting the RFC 
Editor tomorrow, 15May starting around 1200 UTC.


It is expected that most web pages at the RFC Editor websites, 
particularly www.rfc-editor.org, will serve from cache during these 
changes, but there will be a brief period where interactive pages will 
not be available. Non-HTTP-based services, such as rsync and ftp, will 
also not be available during this brief outage. Should you encounter a 
disruption during this time, please be patient and retry your query 
later in the day.


An update will be sent when these changes are complete.

RjS

___
IETF-Announce mailing list -- ietf-announce@ietf.org
To unsubscribe send an email to ietf-announce-le...@ietf.org

Mailman3 transition will take place 24 Apr (with 25 Apr as a fallback).

[Robert Sparks]

We will again attempt to transition our mailing lists to mailman3 on Apr 
24, starting around 1300 UTC. If we encounter difficulties, we will 
retry on Apr 25.


As noted in earlier announcements:

This migration will not disrupt list traffic - all lists and 
subscriptions will carry forward. The interaction with the web interface 
for individual subscription management and list management and 
moderation will change. Using the new web interface (Postorius) will be 
intuitive. There will be a step at first login where you will have to 
prove the ability to receive mail at the address you are logging in 
with, and at that point you will establish a new password. If you would 
like to see what this looks like, consider exploring the Python and 
Mailman lists themselves at, e.g., 
https://mail.python.org/mailman3/lists/python-announce-list.python.org/.


Our mail archives will not change. The archives will remain at 
https://mailarchive.ietf.org. We will not be using Mailman 3’s archiving 
interface (HyperKitty).


If you are an owner or moderator of an existing list, please skim 
https://mailarchive.ietf.org/arch/msg/tools-discuss/bXO3KGX6neczV5RqWqqsrydeVuQ/ 
where I've described the account creation task in a little more detail.


You will not be able to create mailman3 accounts at this time. I will 
send another announcement when the transition is complete and it is time 
to do so.


Robert Sparks
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Brief notes.ietf.org outage 3Apr

[Robert Sparks]

We expect to move the notes.ietf.org service onto the new IT 
infrastructure tomorrow 3Apr in the afternoon (North America). This will 
involve a small amount of service unavailability, which we currently 
expect to be around 10 minutes in length.


Robert Sparks / Tools team project manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Mailman3 transition will take place just after IETF 119

[Robert Sparks]

We will transition our mailing lists to mailman3 just after the IETF 119 
meeting.


From earlier announcements of the mailman3 migration plan:

This migration will not disrupt list traffic - all lists and 
subscriptions will carry forward. The interaction with the web interface 
for individual subscription management and list management and 
moderation will change. Using the new web interface (Postorius) will be 
intuitive. There will be a step at first login where you will have to 
prove the ability to receive mail at the address you are logging in 
with, and at that point you will establish a new password. If you would 
like to see what this looks like, consider exploring the Python and 
Mailman lists themselves at, e.g., 
https://mail.python.org/mailman3/lists/python-announce-list.python.org/.


Our mail archives will not change. The archives will remain at 
https://mailarchive.ietf.org. We will not be using Mailman 3’s archiving 
interface (HyperKitty).


If you are an owner or moderator of an existing list, please skim 
https://mailarchive.ietf.org/arch/msg/tools-discuss/bXO3KGX6neczV5RqWqqsrydeVuQ/ 
where I've described the account creation task in a little more detail.


You will not be able to create mailman3 accounts at this time. I will 
send another announcement when the transition is complete and it is time 
to do so.


Robert Sparks

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Mailing lists will transition to mailman3 on 12 Feb.

[Robert Sparks]

We plan to transition all of our email lists from mailman2 to mailman3 
on 12 Feb.


This migration will not disrupt list traffic - all lists and 
subscriptions will carry forward. The interaction with the web interface 
for individual subscription management and list management and 
moderation will change. Using the new web interface (Postorius) will be 
intuitive. There will be a step at first login where you will have to 
prove the ability to receive mail at the address you are logging in 
with, and at that point you will establish a new password. If you would 
like to see what this looks like, consider exploring the Python and 
Mailman lists themselves at, e.g., 
https://mail.python.org/mailman3/lists/python-announce-list.python.org/.


Our mail archives will not change. The archives will remain at 
https://mailarchive.ietf.org. We will not be using Mailman 3’s archiving 
interface (HyperKitty).


Robert Sparks

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Re: Datatracker Downtime (Was: Significant datatracker update will be deployed 12 Dec)

[Robert Sparks]

All -

We have the datatracker running again, and believe the upgrade to be 
correct. However, the process required mid-flight correction. Please be 
sure to report issues as early as possible. Watch, in particular, for 
issues with RelatedDocument and RFCs (updates, obsoletes, and 
informative/normative references). We know of a few spurious history 
entries that were made that we will correct.


My apologies for the extended downtime and ongoing cleanup. Our mistake 
(entirely mine) was not remembering to turn off a particular set of cron 
jobs that ran mid-migration over a partially migrated database. The 
ability to _make_ this mistake is being removed by design as part of our 
work to move to the new infrastructure where deployment is done by code, 
not by a persons fingers-at-keyboard.


RjS

On 12/12/23 3:37 PM, Cindy Morgan wrote:

All,

We are experiencing unexpected downtime with today's Datatracker 
update. The Tools Team is working to restore service as soon as 
possible. We apologize for the inconvenience.


Best regards,
Cindy

Cindy Morgan / Associate Director / IETF Secretariat
5177 Brandin Court / Fremont CA 94538 / USA
T: +1.510.492.4085 / F: +1.510.492.4001 / https://www.ietf.org
--
Association Management Solutions (AMS) - https://www.amsl.com
Management, Meetings and Events, Technology


Begin forwarded message:

*From: *Robert Sparks 
*Subject: **Significant datatracker update will be deployed 12 Dec*
*Date: *December 6, 2023 at 1:01:28 PM PST
*To: *ietf-announce@ietf.org
*Reply-To: *tools-discuss 

We've been working for several months on making RFCs first-class 
objects in the datatracker instead of modeling them as an artificial 
version of a draft.


This change lets us better represent, and work with references to, 
RFCs and the subseries: STD, BCP, and FYI.


It simplifies the code and database operations, resulting in quicker 
datatracker response for most views.


The migration is significant. The deployment of this version will 
involve 15 +/- minutes of datatracker unavailability.


We currently plan to deploy this release shortly after 2030 UTC on 12 
Dec : 
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231212T2030


Users of the v1 API should note this version brings a breaking change 
- it removes the DocAlias model entirely. The RelatedDocument objects 
target will be Document objects instead of DocAlias objects. It adds 
Document types for RFCs, BCPs, STDs, and FYIs. Internet-Drafts that 
became RFCs are attached to the RFC through a RelatedDocument object 
of type "became_rfc". See the changes to the model files at 
https://github.com/ietf-tools/datatracker/compare/main...feat/rfc for 
details.


Questions/discussion should be directed to tools-disc...@ietf.org.

RjS

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce



___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Significant datatracker update will be deployed 12 Dec

[Robert Sparks]

We've been working for several months on making RFCs first-class objects 
in the datatracker instead of modeling them as an artificial version of 
a draft.


This change lets us better represent, and work with references to, RFCs 
and the subseries: STD, BCP, and FYI.


It simplifies the code and database operations, resulting in quicker 
datatracker response for most views.


The migration is significant. The deployment of this version will 
involve 15 +/- minutes of datatracker unavailability.


We currently plan to deploy this release shortly after 2030 UTC on 12 
Dec : 
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231212T2030


Users of the v1 API should note this version brings a breaking change - 
it removes the DocAlias model entirely. The RelatedDocument objects 
target will be Document objects instead of DocAlias objects. It adds 
Document types for RFCs, BCPs, STDs, and FYIs. Internet-Drafts that 
became RFCs are attached to the RFC through a RelatedDocument object of 
type "became_rfc".  See the changes to the model files at 
https://github.com/ietf-tools/datatracker/compare/main...feat/rfc for 
details.


Questions/discussion should be directed to tools-disc...@ietf.org.

RjS

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Datatracker downtime April 12

[Robert Sparks]

We have identified the issue that prevented yesterday's migration. We 
will work to complete the migration today, again just after 21:00 UTC. 
We expect a much shorter downtime.


Apologies for the very short notice and the additional disruption. 
Finishing the transition has urgency.


Please let me know by direct email if the particular time is overly 
disruptive for you.


RjS

On 4/11/23 4:46 PM, Robert Sparks wrote:
We were not successful in making the transition to postgres during 
today's outage. We will digest the errors that we ran into and 
schedule another outage soon to retry.


Apologies for the inconvenience.

RjS

On 3/29/23 11:33 PM, Robert Sparks wrote:
We are on track to move the datatracker onto postgres on 11 April 
just after 21:00 UTC.


We still expect downtime to be less than thirty minutes.

RjS

On 1/11/23 8:22 AM, Robert Sparks wrote:
We have discovered issues that prevent shifting the datatracker to 
postgresql on 19Jan.


These will take long enough to remedy that we will be in the active 
pre-IETF 116 period by the time we are ready, so we are rescheduling 
the shift until after that meeting.


This outage is now scheduled for Tuesday 11Apr2023 just after 21:00 
UTC.


The essence of the issue is in the different collation between MySQL 
and Postgresql. Our initial tests indicated that we were safe 
proceeding to Postgresql's case-sensitive collation with the code 
changes we've already made, but more detailed work in December and 
early January have shown that more are necessary.


Robert Sparks

Tools Project Manager


On 12/19/22 3:23 PM, Robert Sparks wrote:
We plan to take the datatracker offline Thursday 19Jan2023 just 
after 21:00 UTC to shift the underlying database to postgresql.


This change will bring some immediate performance improvements, and 
more as we continue to tune after the transition.


We currently expect at most 30 minutes (probably much less) of 
downtime. I'll refine the time estimate as the date grows closer.


Cloudflare will continue to serve cached pages for users who are 
not logged in during that time.


Please direct any questions directly to me or to 
tools-disc...@ietf.org


Robert Sparks

Tools Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Transition deferred (was Re: Reminder: Datatracker downtime April 11)

[Robert Sparks]

We were not successful in making the transition to postgres during 
today's outage. We will digest the errors that we ran into and schedule 
another outage soon to retry.


Apologies for the inconvenience.

RjS

On 3/29/23 11:33 PM, Robert Sparks wrote:
We are on track to move the datatracker onto postgres on 11 April just 
after 21:00 UTC.


We still expect downtime to be less than thirty minutes.

RjS

On 1/11/23 8:22 AM, Robert Sparks wrote:
We have discovered issues that prevent shifting the datatracker to 
postgresql on 19Jan.


These will take long enough to remedy that we will be in the active 
pre-IETF 116 period by the time we are ready, so we are rescheduling 
the shift until after that meeting.


This outage is now scheduled for Tuesday 11Apr2023 just after 21:00 UTC.

The essence of the issue is in the different collation between MySQL 
and Postgresql. Our initial tests indicated that we were safe 
proceeding to Postgresql's case-sensitive collation with the code 
changes we've already made, but more detailed work in December and 
early January have shown that more are necessary.


Robert Sparks

Tools Project Manager


On 12/19/22 3:23 PM, Robert Sparks wrote:
We plan to take the datatracker offline Thursday 19Jan2023 just 
after 21:00 UTC to shift the underlying database to postgresql.


This change will bring some immediate performance improvements, and 
more as we continue to tune after the transition.


We currently expect at most 30 minutes (probably much less) of 
downtime. I'll refine the time estimate as the date grows closer.


Cloudflare will continue to serve cached pages for users who are not 
logged in during that time.


Please direct any questions directly to me or to tools-disc...@ietf.org

Robert Sparks

Tools Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Reminder: Datatracker downtime April 11

[Robert Sparks]

We are on track to move the datatracker onto postgres on 11 April just 
after 21:00 UTC.


We still expect downtime to be less than thirty minutes.

RjS

On 1/11/23 8:22 AM, Robert Sparks wrote:
We have discovered issues that prevent shifting the datatracker to 
postgresql on 19Jan.


These will take long enough to remedy that we will be in the active 
pre-IETF 116 period by the time we are ready, so we are rescheduling 
the shift until after that meeting.


This outage is now scheduled for Tuesday 11Apr2023 just after 21:00 UTC.

The essence of the issue is in the different collation between MySQL 
and Postgresql. Our initial tests indicated that we were safe 
proceeding to Postgresql's case-sensitive collation with the code 
changes we've already made, but more detailed work in December and 
early January have shown that more are necessary.


Robert Sparks

Tools Project Manager


On 12/19/22 3:23 PM, Robert Sparks wrote:
We plan to take the datatracker offline Thursday 19Jan2023 just after 
21:00 UTC to shift the underlying database to postgresql.


This change will bring some immediate performance improvements, and 
more as we continue to tune after the transition.


We currently expect at most 30 minutes (probably much less) of 
downtime. I'll refine the time estimate as the date grows closer.


Cloudflare will continue to serve cached pages for users who are not 
logged in during that time.


Please direct any questions directly to me or to tools-disc...@ietf.org

Robert Sparks

Tools Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Re: Discontinuing Jabber support after IETF 115

[Robert Sparks]

A reminder, and notification:

The jabber-zulip bridges and the IETF jabber service are being taken 
down now.


Robert Sparks

On 9/7/22 12:06 PM, Robert Sparks wrote:


After a series of trials used to gather feedback from the community, 
the IETF has switched from Jabber to Zulip as its chat service.



For the last few meetings we provided Jabber bridges from the jabber 
rooms used for each session to the related Zulip stream. Initially, 
this bridged MeetEcho chat into Zulip, but as of IETF 114, MeetEcho 
chat was built on Zulip, and the bridges carried the chat into Jabber. 
The bridges were kept in place for IETF 114, and will be for IETF 115. 
They will be removed at the end of that meeting. The Multi User Chat 
service at jabber.ietf.org will also be taken down at that time. The 
logs of the jabber rooms at [1] will be preserved at that location.



We are implementing the capture of the chat logs as meeting artifacts 
stored in the datatracker for each meeting starting with IETF 114. As 
noted in the Zulip implementation plan at [2] we are also 
investigating other mechanisms for making the Zulip chat logs 
available without login.



After the bridges are removed, it will become possible to explore 
Zulip’s topic organization structure more thoroughly during group 
meetings.



Robert Sparks

IETF Tools Project Manager


[1] https://jabber.ietf.org/jabber/logs/

[2] 
https://github.com/ietf-tools/service-plans/blob/main/zulip-service-plan.md
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Rescheduled Datatracker Outage to 11Apr2023 (was Datatracker outage 19Jan2023 to shift database engines)

[Robert Sparks]

We have discovered issues that prevent shifting the datatracker to 
postgresql on 19Jan.


These will take long enough to remedy that we will be in the active 
pre-IETF 116 period by the time we are ready, so we are rescheduling the 
shift until after that meeting.


This outage is now scheduled for Tuesday 11Apr2023 just after 21:00 UTC.

The essence of the issue is in the different collation between MySQL and 
Postgresql. Our initial tests indicated that we were safe proceeding to 
Postgresql's case-sensitive collation with the code changes we've 
already made, but more detailed work in December and early January have 
shown that more are necessary.


Robert Sparks

Tools Project Manager


On 12/19/22 3:23 PM, Robert Sparks wrote:
We plan to take the datatracker offline Thursday 19Jan2023 just after 
21:00 UTC to shift the underlying database to postgresql.


This change will bring some immediate performance improvements, and 
more as we continue to tune after the transition.


We currently expect at most 30 minutes (probably much less) of 
downtime. I'll refine the time estimate as the date grows closer.


Cloudflare will continue to serve cached pages for users who are not 
logged in during that time.


Please direct any questions directly to me or to tools-disc...@ietf.org

Robert Sparks

Tools Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Datatracker outage 19Jan2023 to shift database engines

[Robert Sparks]

We plan to take the datatracker offline Thursday 19Jan2023 just after 
21:00 UTC to shift the underlying database to postgresql.


This change will bring some immediate performance improvements, and more 
as we continue to tune after the transition.


We currently expect at most 30 minutes (probably much less) of downtime. 
I'll refine the time estimate as the date grows closer.


Cloudflare will continue to serve cached pages for users who are not 
logged in during that time.


Please direct any questions directly to me or to tools-disc...@ietf.org

Robert Sparks

Tools Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Re: Major datatracker change will be deployed, requiring a short outage, just after IETF 115

[Robert Sparks]

This deployment is complete. Please report any issues using the 
mechanisms indicated on each datatracker page.


Robert Sparks

On 11/2/22 5:23 PM, Robert Sparks wrote:
The tools team has been working for many months to make the 
datatracker's database become timezone aware, and we are ready to 
deploy the result just after IETF 115.


This deployment will require taking the datatracker offline for 15-30 
minutes while the underlying database is significantly altered.


We plan to deploy this change the afternoon of Monday November 14 
around 1900 UTC.


The time (and the date) are subject to several preconditions 
(including successful travel, and the continued health of everyone 
involved) coming together - if they do not, we will try again at the 
same time on Tuesday November 15.


This step is a necessary precondition for moving the datatracker onto 
postgresql and more modern versions of Django.


For the curious:

The changes are extensive, and can be seen here: 
https://github.com/ietf-tools/datatracker/compare/main...feat/tzaware


The best place to start to understand the underlying issue this 
addresses is at 
https://github.com/ietf-tools/datatracker/blob/feat/tzaware/ietf/utils/migrations/0002_convert_timestamps_to_utc.py


Robert Sparks

Tools Team Project Manager




___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Major datatracker change will be deployed, requiring a short outage, just after IETF 115

[Robert Sparks]

The tools team has been working for many months to make the 
datatracker's database become timezone aware, and we are ready to deploy 
the result just after IETF 115.


This deployment will require taking the datatracker offline for 15-30 
minutes while the underlying database is significantly altered.


We plan to deploy this change the afternoon of Monday November 14 around 
1900 UTC.


The time (and the date) are subject to several preconditions (including 
successful travel, and the continued health of everyone involved) coming 
together - if they do not, we will try again at the same time on Tuesday 
November 15.


This step is a necessary precondition for moving the datatracker onto 
postgresql and more modern versions of Django.


For the curious:

The changes are extensive, and can be seen here: 
https://github.com/ietf-tools/datatracker/compare/main...feat/tzaware


The best place to start to understand the underlying issue this 
addresses is at 
https://github.com/ietf-tools/datatracker/blob/feat/tzaware/ietf/utils/migrations/0002_convert_timestamps_to_utc.py


Robert Sparks

Tools Team Project Manager




___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Removing mailing list mirrors in Zulip

[Robert Sparks]

We are making a change to the Zulip service plan and the configuration
of the zulip.ietf.org service.

To date, we have been configuring Zulip with a stream that ingests the
mailing list for each group.

It has effectively created a second, partial, archive of the WG mailing
list in the Zulip database, which is problematic for operations and
integrity.

The IESG has directed the tools team to work towards only having a
single archive to facilitate administration and ensure integrity of
that archive. As such, we will be removing the mailing list mirror
streams in our zulip instance in the next few days.

Please send any comments to tools-disc...@ietf.org.

Robert Sparks
Tools project manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Discontinuing Jabber support after IETF 115

[Robert Sparks]

After a series of trials used to gather feedback from the community, the 
IETF has switched from Jabber to Zulip as its chat service.



For the last few meetings we provided Jabber bridges from the jabber 
rooms used for each session to the related Zulip stream. Initially, this 
bridged MeetEcho chat into Zulip, but as of IETF 114, MeetEcho chat was 
built on Zulip, and the bridges carried the chat into Jabber. The 
bridges were kept in place for IETF 114, and will be for IETF 115. They 
will be removed at the end of that meeting. The Multi User Chat service 
at jabber.ietf.org will also be taken down at that time. The logs of the 
jabber rooms at [1] will be preserved at that location.



We are implementing the capture of the chat logs as meeting artifacts 
stored in the datatracker for each meeting starting with IETF 114. As 
noted in the Zulip implementation plan at [2] we are also investigating 
other mechanisms for making the Zulip chat logs available without login.



After the bridges are removed, it will become possible to explore 
Zulip’s topic organization structure more thoroughly during group meetings.



Robert Sparks

IETF Tools Project Manager


[1] https://jabber.ietf.org/jabber/logs/

[2] 
https://github.com/ietf-tools/service-plans/blob/main/zulip-service-plan.md
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Reminder: chat service trials

[Robert Sparks]

As noted below, we are continuing with the chat services trial through 
IETF 110.


If you have been using a chat service other than xmpp at, for instance, 
interim meetings, please share your experiences at tools-disc...@ietf.org


We would like to see more discussion of these questions:

* Is providing local jabber accounts and a web interface to jabber 
sufficient to address the access issues encountered in the past?


* Are there features that matrix or zulip provide that are truly helpful 
for progressing IETF work? If so, please describe how they are helping.


Please explore the services during IETF 110. We anticipate taking them 
down and making a decision about what we will support in the long run 
shortly after.


RjS

On 12/11/20 1:00 PM, Robert Sparks wrote:


We have been running trial zulip, matrix, and xmpp services since 
October.

See
<https://mailarchive.ietf.org/arch/browse/ietf-announce/?q=%22trial%20chat%22> 



As noted in those announcements, the issue that we are trying to 
address is the difficulty people have been reporting obtaining jabber 
services and clients. We are hopeful that these trials will help the 
community develop a better sense of whether to focus on improving the 
experiences with xmpp or to pursue other chat solutions. We are also 
open to the possibility that these other solutions may be worth 
operating in addition to improving the experiences from xmpp.


However, usage and feedback so far has not been sufficient to inform 
what services we should run in the future.


We had around 50 local jabber accounts created on 
xmpp-trial1.ietf.org, and around 40 accounts were created on each of 
the matrix and zulip services.
Few rooms have been created on the matrix service other than those 
bridging to xmpp.
Few streams were created on the zulip service other than those 
bridging to xmpp and those ingesting a few mailing lists.


We are not aware of anyone trying to use the zulip or matrix servers 
for ietf work outside the main meeting.


If you've used the services, please take a few minutes to provide 
feedback at tools-disc...@ietf.org.


Is providing local jabber accounts and a web interface to jabber 
sufficient?
Are there features that matrix or zulip provide that are truly helpful 
for progressing IETF work? If so, please describe how they are helping.


To collect more feedback, we are planning to extend the trials through 
IETF 110. Please take advantage of these services between now and then 
(at interim meetings for example) and let us know what you find to be 
effective.


If you are interested in using these services more directly for your 
group's day-to-day communication, and are willing to test one or both 
of these services on a primary basis for a while, please coordinate 
with the appropriate leadership and let the tools team know so we can 
help accommodate.  Please consider using these services for ad-hoc, 
design-team meetings, and even interims (again, coordinating with the 
appropriate leadership).


If you have had issues using Jabber in the past, please take some time 
now to work with these new services and describe whether they improve 
your experience.


We need more feedback about these services to develop a sense of what 
will best meet the community's needs going forward. Please engage in 
exploring and discussing them at tools-disc...@ietf.org.


While exploring, feel free to use the trial1-feedback room on Matrix 
and the trial1-feedback stream on Zulip.


Thanks again to the volunteers that have been helping configure these 
services and keep them going.


Robert Sparks, Tools Team Chair

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Cancelled: Datatracker maintenance outage Saturday 16 Jan 2021

[Robert Sparks]

We found an issue that requires deferring the timezone-aware migration. 
We will reschedule after it is addressed.


The scheduled outage below is cancelled.

Robert Sparks - Tools Team Project Manager

On 1/8/21 11:12 AM, Robert Sparks wrote:


A reminder - the datatracker will be down 16 Jan for an extended 
period of maintenance as described below.




 Forwarded Message 
Subject:Datatracker maintenance outage Saturday 16 Jan 2021
Date:   Tue, 15 Dec 2020 14:11:13 -0600
From:   Robert Sparks 
To: ietf-announce@ietf.org



The datatracker will be down from 1600-2000 UTC on Saturday 16 Jan, 2021.

This extended outage is necessary to convert each timezone record in 
the datatracker's database from timezone-naive to be timezone-aware.


The current database has a mix of naive timestamps recorded implicitly 
in server-local time (PST8PDT, or America/LosAngeles), and naive 
timestamps recorded implicitly in meeting local time for various IETF 
meetings, making a value-by-value conversion taking the context of 
each record into account necessary.


This conversion will greatly simplify time calculations and 
presentation of information in different timezones going forward.


We currently anticipate being able to keep the authentication services 
running during this outage, so services like the imap server and 
codimd will allow logins during the transition.


Robert Sparks - Tools Team Project Manager


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Reminder: Datatracker maintenance outage Saturday 16 Jan 2021

[Robert Sparks]

A reminder - the datatracker will be down 16 Jan for an extended period 
of maintenance as described below.




 Forwarded Message 
Subject:Datatracker maintenance outage Saturday 16 Jan 2021
Date:   Tue, 15 Dec 2020 14:11:13 -0600
From:   Robert Sparks 
To: ietf-announce@ietf.org



The datatracker will be down from 1600-2000 UTC on Saturday 16 Jan, 2021.

This extended outage is necessary to convert each timezone record in the 
datatracker's database from timezone-naive to be timezone-aware.


The current database has a mix of naive timestamps recorded implicitly 
in server-local time (PST8PDT, or America/LosAngeles), and naive 
timestamps recorded implicitly in meeting local time for various IETF 
meetings, making a value-by-value conversion taking the context of each 
record into account necessary.


This conversion will greatly simplify time calculations and presentation 
of information in different timezones going forward.


We currently anticipate being able to keep the authentication services 
running during this outage, so services like the imap server and codimd 
will allow logins during the transition.


Robert Sparks - Tools Team Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Datatracker maintenance outage Saturday 16 Jan 2021

[Robert Sparks]

The datatracker will be down from 1600-2000 UTC on Saturday 16 Jan, 2021.

This extended outage is necessary to convert each timezone record in the 
datatracker's database from timezone-naive to be timezone-aware.


The current database has a mix of naive timestamps recorded implicitly 
in server-local time (PST8PDT, or America/LosAngeles), and naive 
timestamps recorded implicitly in meeting local time for various IETF 
meetings, making a value-by-value conversion taking the context of each 
record into account necessary.


This conversion will greatly simplify time calculations and presentation 
of information in different timezones going forward.


We currently anticipate being able to keep the authentication services 
running during this outage, so services like the imap server and codimd 
will allow logins during the transition.


Robert Sparks - Tools Team Project Manager

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Next steps: chat service trials

[Robert Sparks]

We have been running trial zulip, matrix, and xmpp services since October.
See
<https://mailarchive.ietf.org/arch/browse/ietf-announce/?q=%22trial%20chat%22>

As noted in those announcements, the issue that we are trying to address 
is the difficulty people have been reporting obtaining jabber services 
and clients. We are hopeful that these trials will help the community 
develop a better sense of whether to focus on improving the experiences 
with xmpp or to pursue other chat solutions. We are also open to the 
possibility that these other solutions may be worth operating in 
addition to improving the experiences from xmpp.


However, usage and feedback so far has not been sufficient to inform 
what services we should run in the future.


We had around 50 local jabber accounts created on xmpp-trial1.ietf.org, 
and around 40 accounts were created on each of the matrix and zulip 
services.
Few rooms have been created on the matrix service other than those 
bridging to xmpp.
Few streams were created on the zulip service other than those bridging 
to xmpp and those ingesting a few mailing lists.


We are not aware of anyone trying to use the zulip or matrix servers for 
ietf work outside the main meeting.


If you've used the services, please take a few minutes to provide 
feedback at tools-disc...@ietf.org.


Is providing local jabber accounts and a web interface to jabber sufficient?
Are there features that matrix or zulip provide that are truly helpful 
for progressing IETF work? If so, please describe how they are helping.


To collect more feedback, we are planning to extend the trials through 
IETF 110. Please take advantage of these services between now and then 
(at interim meetings for example) and let us know what you find to be 
effective.


If you are interested in using these services more directly for your 
group's day-to-day communication, and are willing to test one or both of 
these services on a primary basis for a while, please coordinate with 
the appropriate leadership and let the tools team know so we can help 
accommodate.  Please consider using these services for ad-hoc, 
design-team meetings, and even interims (again, coordinating with the 
appropriate leadership).


If you have had issues using Jabber in the past, please take some time 
now to work with these new services and describe whether they improve 
your experience.


We need more feedback about these services to develop a sense of what 
will best meet the community's needs going forward. Please engage in 
exploring and discussing them at tools-disc...@ietf.org.


While exploring, feel free to use the trial1-feedback room on Matrix and 
the trial1-feedback stream on Zulip.


Thanks again to the volunteers that have been helping configure these 
services and keep them going.


Robert Sparks, Tools Team Chair

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Reminder: Trial chat services are running - please expore them.

[Robert Sparks]

Please spend some time exploring the trial chat services and provide 
feedback.

We have deploying these services to gain operational experience and get
community feedback about how well they meet the need for IETF-related chat.

Please send feedback on the services to tools-disc...@ietf.org

See:
https://matrix-trial1.ietf.org
https://zulip-trial1.ietf.org
https://xmpp-trial1.ietf.org

See also the announcement of these services at
https://mailarchive.ietf.org/arch/msg/ietf-announce/UtPuWgXhYbjyf7wHGJh4ax4kQrA/and
https://mailarchive.ietf.org/arch/msg/ietf-announce/B1b71fKWGfAq0ZKJ0KSwxzn7WgI/

Around December, we will assess our experiences and the feedback received to
inform which chat services we provide in the future and how we will operate
them. In January, these trial instances will be taken down. We do not 
intend to

preserve or migrate any account configuration or chat history from the trial
instances as we move forward.

The chat services are intended to be explorational and informal. However,
please treat them as contexts where contribution rules apply (See
https://www.ietf.org/about/note-well/).

Robert Sparks - Tools team project manager



___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Trial chat service: xmpp

[Robert Sparks]

In addition to the trial instances of the matrix and zulip chat services,
we have deployed a trial instance of an xmpp service that allows local 
accounts

to be registered, allows guest account access, and provides a web client.

These services are available at xmpp-trial1.ietf.org.

As noted earlier, we are deploying these services to gain operational
experience and get community feedback about how well they meet the need for
IETF-related chat.

We have clear evidence from the IETF 107 post-meeting survey
(https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) that many
IETF participants find jabber a significant problem.  This is partly due to
difficulties in finding a free jabber service and partly due to client 
issues.

There are two paths to try to resolve these problems, one is to improve the
IETF jabber service and the other is to switch to an alternative groupchat
solution. This addition explores the the first path.

This install has very little local configuration or customization.  As 
with the
other trials, over the next few weeks, we will be exploring 
reconfiguring the

service to use datatracker credentials for sign-in.  Bridging between the
systems is already being explored. Please remember that one consequence of
these explorations is that there will likely be times, outside of meetings,
when accounts will be disrupted or even removed and will have to be 
recreated.


We would like feedback on how well any of these services meet chat needs 
during
meetings, both the full online IETF 109 meeting, interims, adhocs, and 
hallway

conversations.

Around December, we will assess our experiences and the feedback received to
inform which chat services we provide in the future and how we will operate
them. In January, these trial instances will be taken down. We do not 
intend to

preserve or migrate any account configuration or chat history from the trial
instances as we move forward.

The chat services are intended to be explorational and informal. However,
please treat them as contexts where contribution rules apply (See
https://www.ietf.org/about/note-well/).

Please send feedback on the services to tools-disc...@ietf.org

There are several community members who have put in significant effort
helping us to set up these trial instances. Please join me in thanking
Tim April, Matthew Hodgson, and Matthew Wild for their assistance.

Robert Sparks - Tools team project manager


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Infrastructure changes over the next two weeks

[Robert Sparks]

We will be making some changes to the organization of files backing our 
services over the next couple of weeks. We do not expect these changes 
to result in any visible change of behavior of the services, but there 
is always the opportunity for surprise.


We will be focusing on the files that comprise the Internet-Draft 
archive and repository. If you notice anything not working as you 
expect, please let us know (send mail to ietf-action or directly to me).


RjS


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Proposal to discontinue live mp3 audio streams at IETF meetings

[Robert Sparks]

We propose to discontinue producing live mp3 audio streams for IETF 
meetings,

starting with IETF 109 and we want to hear from the community before we do.

At many past meetings we have produced live mp3 streams for each 
session. These

steams have been associated with physical meeting rooms, and appeared before
and during the session as a link on the agenda page to a URL like
'http://mp3.conf.meetecho.com/ietf/ietf.m3u'. 



For the last several meetings, these have only been available as a live 
stream.
Recordings of that stream have not been made available after the 
meeting. The

full video recording provided by Meetecho has served as the way to listen to
(or watch) any given session after the fact.

Further, for the last several meetings, the live streams have seen very 
light

use, on the order of 10 uses for IETF 108.

Now that we are holding more meetings online, we have a requirement to allow
meetings to run outside their scheduled times. Allowing the live streams 
to run
outside their scheduled times will require changing how they are 
represented,
to no longer be associated with "rooms" or "tracks". The code refactor 
at both
the datatracker and at meetecho to support would not be a huge effort, 
but it

also would not be tiny. Instead, we feel that removing this complexity,
recognizing that the regular meetecho connection and recordings satisfy the
need, is the better use of our resources. That holds true even for future
in-person meetings.

There are several points that have been considered while arriving at this
proposal:

* Chairs use the recordings to fill in minutes.

    For the last several meetings, the chairs have been using the Meetecho
    recordings for this purpose. Recordings of the live mp3 streams haven't
    been available.

* Some participants (especially ADs) want to listen to more than one 
meeting at

  a time.

    Meetecho allows joining multiple sessions.

* Some participants may not have the bandwidth or a new enough computer 
to run

  meetecho.

    The use of the mp3 streams has been very low at the last several 
meetings.

    This population isn't using the mp3 streams to address the posited
    limitations.  If this is a concern that some people think they 
will

    experience then we can look at asking Meetecho to allow sending only
    audio (muting all video).

* This removes a mechanism that allowed people to listen to a session in
  real-time without paying a registration fee.

   There will be ongoing discussion and tuning of the meeting registration
   structure. In the meantime, the fee waiver program is available and 
being

   improved.

Please send comments by 16 Oct 2020 either to tools-disc...@ietf.org or
directly to rjspa...@nostrum.com.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Trial chat services: matrix and zulip

[Robert Sparks]

We are deploying trials of the matrix and zulip chat services to gain
operational experience and get community feedback about how well these
services meet the need for IETF related chat.

We have clear evidence from the IETF 107 post-meeting survey
(https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) that many
IETF participants find jabber a significant problem.  This is partly due to
difficulties in finding a free jabber service and partly due to client 
issues.

There are two paths to try to resolve these problems, one is to improve the
IETF jabber service and the other is to switch to an alternative groupchat
solution.  The community has already taken a step on the latter path 
with the

introduction of an IETF Slack space, and we want to ensure that this path is
properly explored by widening the range of options to well established
free/open source tools.

The installs currently have almost no local configuration or customization.
Over the next few weeks, we will be exploring reconfiguring them to use
datatracker credentials for sign-in, and explore bridging between these
systems, Slack, and Jabber. One consequence of these explorations is 
that there
will  likely be times, outside of meetings, when accounts will be 
disrupted or

even removed and will have to be recreated. Initially, we suggest you use an
email address for the username on each service.

We considered running these trials using instances run by the Zulip or 
Matrix
communities. We went with instances operated by the secretariat to learn 
what

would be needed if the community felt self-hosting chat was important in the
long-term.

The services can be found at matrix-trial1.ietf.org and 
zulip-trial1.ietf.org.


Any matrix client can be used with the trial matrix server. There is also
a web client available at at matrix-trial1.ietf.org.

Similarly any zulip client can be used with the trial zulip server, which
has a built in web interface.

We would like feedback on how well each client meets chat needs during
meetings, both the full online IETF 109 meeting, iterims, adhocs, and 
hallway

conversations.

Around December, we will assess our experiences and the feedback received to
inform what chat services we provide in the future and how we will operate
them. In January, these trial instances will be taken down. We do not 
intend to

preserve or migrate any account configuration or chat history from the trial
instances as we move forward.

This does add to the potentially confusing large number of places 
conversation
might take place. We hope to address that with some level of bridging, 
at least
with Jabber, but have been cautioned by the respective development 
communities
that bridging between Zulip and Matrix is unsatisfying since the 
conversation

models in the two applications are so different.

The chat services are intended to be explorational and informal. However,
please treat them as contexts where contribution rules apply (See
https://www.ietf.org/about/note-well/).

We are not, at this time, planning to host jabber accounts. We may 
revisit that

as an option as we continue to gather more feedback.

Please send feedback on the services to tools-disc...@ietf.org


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Datatracker outage : Sunday Jun 16 at 1600 UTC

[Robert Sparks]

The datatracker will be offline for approximately three hours starting 
at 1600 UTC on Sunday Jun 16.


We will be installing a release that significantly changes the database 
structure for Document and DocAlias objects. This will allow us to 
correctly represent BCPs and will generally improve datatracker response 
time. The change requires a set of database migrations that we expect to 
take 2 to 3 hours.


This is an unusual event, and we don't expect more like it in the 
foreseeable future.


Thank you for your patience, and apologies for any inconvenience this 
causes.


RjS

Discontinuing the mhonarc archives January 14

[Robert Sparks]

We will be discontinuing Mhonarc during the day on Monday Jan 14.

As noted below, all existing Mhonarc URLs will redirect to the same 
message in mailarch.


The mbox files available through rsync will continue to be available.

On 11/26/18 2:54 PM, Robert Sparks wrote:

The current plan is to discontinue Mhonarc in early January.

Please continue to exercise the mailarch system and report issues as 
below.


On 10/3/18 1:19 PM, Robert Sparks wrote:

There have been several improvements to the mailarch tool recently.

If you haven't already discovered it, please try out the new "Static 
Mode",

particularly if you frequently use the Mhonarc archives.

See, for example, 
<https://mailarchive.ietf.org/arch/browse/static/ietf/2018-09/>.


To get this view by default when browsing lists, set "Static Mode On" 
in the
Settings menu at top right of the page. This preference is stored in 
a cookie.


Also note that the speed of searching a list, and searching across 
multiple lists
has been significantly improved. The use of whitespace and fonts have 
also been

adjusted.

We are working towards a single copy of the archived mail list 
messages. Currently,
mailarch and IMAP work from the same files, but MonArch uses a 
separate set of files

in another format.

We plan to discontinue the use of Mhonarc soon, likely between IETF 
103 and 104.
When we make that change, all exising URLs into the Mhonarc archives 
will redirect

to the same message in mailarch as discussed in section 2.7 of RFC6778.

Please exercise the mailarch system. If you find issues, report them at
<https://trac.tools.ietf.org/tools/ietfdb/newticket> and choose the
"MailArchive: User Interface Component". Alternatively, you can send 
mail
to mailarch-proj...@ietf.org. 

Discontinuing the mhonarc archives in January

[Robert Sparks]

The current plan is to discontinue Mhonarc in early January.

Please continue to exercise the mailarch system and report issues as below.

On 10/3/18 1:19 PM, Robert Sparks wrote:

There have been several improvements to the mailarch tool recently.

If you haven't already discovered it, please try out the new "Static 
Mode",

particularly if you frequently use the Mhonarc archives.

See, for example, 
<https://mailarchive.ietf.org/arch/browse/static/ietf/2018-09/>.


To get this view by default when browsing lists, set "Static Mode On" 
in the
Settings menu at top right of the page. This preference is stored in a 
cookie.


Also note that the speed of searching a list, and searching across 
multiple lists
has been significantly improved. The use of whitespace and fonts have 
also been

adjusted.

We are working towards a single copy of the archived mail list 
messages. Currently,
mailarch and IMAP work from the same files, but MonArch uses a 
separate set of files

in another format.

We plan to discontinue the use of Mhonarc soon, likely between IETF 
103 and 104.
When we make that change, all exising URLs into the Mhonarc archives 
will redirect

to the same message in mailarch as discussed in section 2.7 of RFC6778.

Please exercise the mailarch system. If you find issues, report them at
<https://trac.tools.ietf.org/tools/ietfdb/newticket> and choose the
"MailArchive: User Interface Component". Alternatively, you can send mail
to mailarch-proj...@ietf.org. 

Improvements to the mailarch tool, and plans to discontinue the mhonarc archives

[Robert Sparks]

There have been several improvements to the mailarch tool recently.

If you haven't already discovered it, please try out the new "Static Mode",
particularly if you frequently use the Mhonarc archives.

See, for example, 
.


To get this view by default when browsing lists, set "Static Mode On" in 
the
Settings menu at top right of the page. This preference is stored in a 
cookie.


Also note that the speed of searching a list, and searching across 
multiple lists
has been significantly improved. The use of whitespace and fonts have 
also been

adjusted.

We are working towards a single copy of the archived mail list messages. 
Currently,
mailarch and IMAP work from the same files, but MonArch uses a separate 
set of files

in another format.

We plan to discontinue the use of Mhonarc soon, likely between IETF 103 
and 104.
When we make that change, all exising URLs into the Mhonarc archives 
will redirect

to the same message in mailarch as discussed in section 2.7 of RFC6778.

Please exercise the mailarch system. If you find issues, report them at
 and choose the
"MailArchive: User Interface Component". Alternatively, you can send mail
to mailarch-proj...@ietf.org.

Grammatical corrections to the headers and boilerplate text

[Robert Sparks]

The IAB recently accepted an erratum 
<https://www.rfc-editor.org/errata/eid5248> that pointed out a 
grammatical error in the boilerplate text templates in RFC 7841.  While 
reviewing the erratum, we noticed a similar error in the text for 
non-standards-track IETF-stream RFCs and verified that the IESG was ok 
correcting that error as well.


The header and boilerplate text is now maintained on a web page, 
<https://www.iab.org/documents/headers-boilerplate>, and we have updated 
that page and requested update of the relevant tools maintained by the 
IETF.   If you have your own tools for the generation of this text, 
please update them to reflect the update text.


Robert Sparks
for the IAB

IAB approves RFC format-related drafts for publication

[Robert Sparks]

On 3 August 2016, the IAB approved the drafts [1] documenting the 
requirements for the new RFC format for publication. The RFC Format 
project goals include:


 * Supporting XML as the unchanging, underlying format
 * Creating TXT, PDF/A-3, and HTML as the outputs
 * Allowing SVG line art (black and white) as per a limited SVG profile
 * Allowing Non-ASCII characters in a controlled fashion

An FAQ about the new RFC Format is available online: 
https://www.rfc-editor.org/rse/format-faq/


With the approval of the drafts, an RFP will be posted shortly covering 
the tools required to make this new format a reality. The RFP will be 
posted on the IETF announce list, rfc-interest, and will be found on the 
IAOC's RFP website (https://iaoc.ietf.org/rfps.html). As the tools are 
developed, tested, and used, all the existing documents will go through 
a -bis process to capture what we learn through implementation. Please 
join rfc-inter...@rfc-editor.org to participate in the discussion on the 
new format.


Many thanks to the RFC Format Design Team for their extraordinary efforts!

Nevil Brownlee (ISE), Heather Flanagan (RSE), Tony Hansen, Joe 
Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice 
Russo, Robert Sparks (Tools Team liaison), Dave Thaler


[1] Format Document reading order:

# The big picture

 * Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and
   Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013,
   <http://www.rfc-editor.org/info/rfc6949>.

 * Flanagan, H., “RFC Format Framework”, Work in Progress,
   draft-iab-rfc-framework-06
   <https://datatracker.ietf.org/doc/draft-iab-rfc-framework/>, June 2016.

# The underlying vocabulary

 * Hoffman, P., “The ‘XML2RFC’ version 3 Vocabulary”, Work in Progress,
   draft-iab-xml2rfc-04
   <https://datatracker.ietf.org/doc/draft-iab-xml2rfc/>, June 2016.

# The outputs

 * Hildebrand, J. and P. Hoffman, “HyperText Markup Language Request
   For Comments Format”, Work in Progress, draft-iab-html-rfc-02
   <https://datatracker.ietf.org/doc/draft-iab-html-rfc/>, February 2016.

 * Flanagan, H. “CSS Requirements for RFCs”, Work in Progress,
   draft-iab-rfc-css-01
   <https://datatracker.ietf.org/doc/draft-iab-rfc-css/>, July 2016.

 * Flanagan, H., “Requirements for Plain Text RFCs”, Work in Progress,
   draft-iab-rfc-plaintext-03
   <https://datatracker.ietf.org/doc/draft-iab-rfc-plaintext/>, May 2016.

 * Hansen, T., Masinter, L., and M. Hardy, “PDF for an RFC Series
   Output Document Format”, Work in Progress,
   draft-iab-rfc-use-of-pdf-02
   <https://datatracker.ietf.org/doc/draft-iab-rfc-use-of-pdf/>, May 2016.

 * Brownlee, N., “SVG Drawings for RFCs: SVG 1.2 RFC”, Work in
   Progress, draft-iab-svg-rfc-02
   <https://datatracker.ietf.org/doc/draft-iab-svg-rfc/>, February 2016.

# Generalized requirements

 * Flanagan, H., “The Use of non-ASCII Characters in RFCs”, Work in
   Progress, draft-iab-rfc-nonascii-02
   <https://datatracker.ietf.org/doc/draft-iab-rfc-nonascii/>, April 2016.

# Workflow and tools

 * Hildebrand, J. and P. Hoffman, “RFC v3 Prep Tool Description”, Work
   in Progress, draft-iab-rfcv3-preptool-02
   <https://datatracker.ietf.org/doc/draft-iab-rfcv3-preptool/>,
   September 2015.

 * Hoffman, P. and T. Hansen, “Examples of the ‘XML2RFC’ Version 2 and
   3 Vocabularies”, Work in Progress, draft-hoffman-rfcexamples-04
   <https://datatracker.ietf.org/doc/draft-hoffman-rfcexamples/>, May
   2015. *Not to be published as an RFC.*

Gen-Art LC review for draft-cotton-rfc4020bis-01

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-cotton-rfc4020bis-01
Reviewer: Robert Sparks
Review Date: 2013-09-11
IETF LC End Date: 2013-09-24
IESG Telechat date: not scheduled

Summary: This draft is on the right track but has open issues, described 
in the review.


(That summary was taken from the options in RFC6385. I would prefer to say
There is one minor issue that is bigger than a nit, but it should be 
easy to straighten out)


Issue : Section 2 is very confusing. It starts out listing 4 things that 
look like they all have to be met. But then the last sentence confuses 
things. Is just reinforcing that both a and b have to be met (if so, 
then wouldn't things also stop if c and d weren't met? (see 3.1 step2)).
I suggest replacing If conditions (a) or (b) with If any of the above 
conditions


Nit 1: Section 3.1 reads harshly at the transition from step 4 to step 
5.  It leaves it implicit that the AD has to approve.
Step 3 has  if steps 2 and 3 are satisfied. 4020 said with the 
approval of the Area Director(s). Adding that text  to step 5 would 
address the nit.


Nit 2: The introduction contains a bit of text that it carried forward, 
slightly modified, from 4020 for which I suggest further modification:

replace
the IETF community wishes to retain tight control of the protocol
with
the IETF community has consensus to retain tight control of the 
registry content


That way this document is reflecting the actual process point that would 
lead to a tighter registration policy without trying to speculate what 
motivated that consensus.


Nit 3: Several reviewers have pointed to a lack of clarity in section 2 a.
I suggest taking the change John Klensin proposed (with tweaks as below)

The code points must normally be from a space designated
as RFC Required, IETF Review, or Standards Action.
In addition, code points from a Specification
Required space are allowed if the specification will be
published as an RFC.

Re: Anyone having trouble submitting I-Ds?

[Robert Sparks]

On 8/18/13 4:04 PM, John Levine wrote:

The anti-hijacking feature causes the confirmation email to
only go to the authors listed on the previous version of the document, so
mail was not sent to me and things are working as expected.

This behavior is not documented to the user when they submit the document
and is therefore a bug.

It's sort of documented somewhere, but I agree that it's a bug that it
doesn't tell the submitter what happened.

I reported it as a bug a while ago, dunno where it is in the tracker.

I remember that report, but am not finding the corresponding ticket with 
a quick search, so I've entered another to make sure this gets addressed:

http://trac.tools.ietf.org/tools/ietfdb/ticket/1097

If it turns out that's a duplicate, that's easy to fix.

RjS

Re: Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34

[Robert Sparks]

Hi Magnus -

Thanks for your careful treatment of these comments - I think you're on 
a good path with all the suggestions below.

Responses to questions and a few comments inline:

On 6/18/13 6:42 AM, Magnus Westerlund wrote:

Hi Robert,

Thanks for the massive review. A number of really good comments in here.
Below you will find my answers, comments, questions and in most cases
clarifications what I see us doing with your comment. These covers your
major and minor comments. The nits we will simply implement as we see
fit, if we have questions we will comeback with those.

WG, there are a number of issues in here that would be greatly helped by
your input!

On 2013-06-05 23:56, Robert Sparks wrote:

Document: draft-ietf-mmusic-rfc2326bis-34
Reviewer: Robert Sparks
Review Date: 05-Jun-2013
IETF LC End Date: 04-Jun-2013
IESG Telechat date: not yet on a telechat


The document is very long, and the structure is unusual - much of the
definition of the protocol itself is in the appendices. You are missing
an opportunity to make this document much shorter (thereby likely
increasing its effectiveness). Much of the jump in from RFC2326 was
importing the description of headers and responses from HTTP, tailoring
them to RTSP. That was a good exercise in that it highlights some issues
that would otherwise be non-obvious (and raises a few questions below).
But you followed the style from HTTP perhaps too closely - much shorter
descriptions without examples might have done the job better. Overall,
separating exposition and examples from the protocol definition would
make it much easier for an implementer to find the definition of the
protocol, and use the document as a reference when diagnosing a failure
to interoperate.

Agree, it would be differently structure if we wrote it from scratch
today. But it is an document that is 10 years in the making with dual
heritage in RFC 2326 and RFC 2068.


Major Issues

I'm not seeing what instructs an RTSP element on how to find the server
it would try to open a connection to given an rtsp or rtsps URI? Are you
assuming it would be doing A or  DNS lookups?

Yes, using A or  DNS records are assumed. No problem making that
explicit.

Should this protocol

use NAPTR/SRV?

Potentially, but as everyone have been using A records for all these
years, I think it is not worth defining it at this stage.

The document should be explicit. On a related note, (and

maybe I missed this), but where do you talk about what an element should
check in the server's certificate when connecting over TLS? Are you
assuming a common name match? Or are you expecting some SubjectAltName
processing?

This draft says in Section 19.2 the following regarding this:

RTSP MUST follow the same guidelines with
regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818].

Where section 3.1 (Server Identity) of RFC 2818 contains the following:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used.

Isn't that clear enough on that matter?

Yes - I was worried that I might have missed it before.



The document should say more about when connection reuse is appropriate,
particularly when the connections happened because of an rtsps uri. Two
different names might resolve to the same IP address - reusing a
connection formed when looking at the first name (and verifying the
server's cert) is dangerous. A new connection needs to be formed (and
verified) instead.

I want to check my understanding of the issue you are seeing here. So a
client looks ups foo.example.org, gets an ip address A and establishes
an TCP/TLS connection and verifies that there are a SubjectAltName that
matches foo.example.org works. Then client is going to open
bar.example.com and looks up that address and gets the same IP address A.
Client matches A against existing connections and simply sends a request to
bar.example.com. Thus bypassing the certificate verification.

If we clarify that in the process of opening rtsps://bar.example.com the
client MUST verify that the server certificate for the TLS connection it
considers re-using has an SubjectAltName of bar.example.com, does that
resolve your concerns. If not, please explain the concern further.

You understood what I intended, and your resolution looks sufficient.




The text talks about the option to queue S-C requests if there isn't a
connection to the client available. Ostensibly, this means the request
can go down some future connection. It's not clear how the server can
tell the right client connected. In particular, when using rtsps, how do
you prevent a malicious client from getting such a queued message that
wasn't meant for him?


Okay, this security issue I have totally missed but it is clearly
serious. I don't see any easy way of fixing this. Thus I would suggest
that we simply make it clear that a server

Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at


http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments 
you may receive.


Document: draft-ietf-mmusic-rfc2326bis-34
Reviewer: Robert Sparks
Review Date: 05-Jun-2013
IETF LC End Date: 04-Jun-2013
IESG Telechat date: not yet on a telechat

Summary: This draft is on the right track but has open issues, described 
in the review.


I have not reviewed this document at the level of detail I prefer for 
Gen-art reviews, but have tried to be thorough in the sections I have 
reviewed.


In particular,
I didn't verify the tables and the text agree
I didn't carefully check the ABNF
I haven't thought about possible edge cases and race conditions as much 
as I would have liked
I didn't closely review the security mechanisms in section 19 or the 
specialized MIKEY keying mechanism in the appendix - both need careful 
review from security experts.


One observation I would like to make before calling out issues and nits:

The document is very long, and the structure is unusual - much of the 
definition of the protocol itself is in the appendices. You are missing 
an opportunity to make this document much shorter (thereby likely 
increasing its effectiveness). Much of the jump in from RFC2326 was 
importing the description of headers and responses from HTTP, tailoring 
them to RTSP. That was a good exercise in that it highlights some issues 
that would otherwise be non-obvious (and raises a few questions below). 
But you followed the style from HTTP perhaps too closely - much shorter 
descriptions without examples might have done the job better. Overall, 
separating exposition and examples from the protocol definition would 
make it much easier for an implementer to find the definition of the 
protocol, and use the document as a reference when diagnosing a failure 
to interoperate.


Major Issues

I'm not seeing what instructs an RTSP element on how to find the server 
it would try to open a connection to given an rtsp or rtsps URI? Are you 
assuming it would be doing A or  DNS lookups? Should this protocol 
use NAPTR/SRV? The document should be explicit. On a related note, (and 
maybe I missed this), but where do you talk about what an element should 
check in the server's certificate when connecting over TLS? Are you 
assuming a common name match? Or are you expecting some SubjectAltName 
processing?


The document should say more about when connection reuse is appropriate, 
particularly when the connections happened because of an rtsps uri. Two 
different names might resolve to the same IP address - reusing a 
connection formed when looking at the first name (and verifying the 
server's cert) is dangerous. A new connection needs to be formed (and 
verified) instead.


The text talks about the option to queue S-C requests if there isn't a 
connection to the client available. Ostensibly, this means the request 
can go down some future connection. It's not clear how the server can 
tell the right client connected. In particular, when using rtsps, how do 
you prevent a malicious client from getting such a queued message that 
wasn't meant for him?


Given that the text talks about queuing S-C requests, it should 
explicitly call out whether a server can queue a response if the 
connection the associated request arrived on is no longer available. I 
think what you want to say is that such a response must not be queued, 
and must be dropped.


There are several places in the text that talk about using a 503 
response with a Retry-After header to push back on traffic from an 
element (the first is section 10.7).
* It's not clear what the subject of a 503 is. Is it intended to be 
scoped to requests to the resource in the RURI of the associated 
request? Is it intended to be scoped to the domain in that resource? Or 
is it, like in SIP, intended to be scoped to the server issuing the 
response, independent of what the RURI contained?
* If the intent is that the 503 talks about the server, then you should 
clarify that a proxy doesn't simply forward 503 responses (after 
rewriting CSeqs), and should probably have a response of its own. 
Otherwise, clients that might be talking to two different servers 
through one proxy would lose access to both of them when one of the 
servers 503ed.


Section 4.9.1 lists values the Seek-Style header can take, but 18.45 
lists a completely different set (which most of the rest of the document 
uses). Should 4.9.1 be changed to use the values in 18.45? Are the right 
strings being used in sections 13.4.4 through 13.4.6? Those appear to be 
using strings from 4.9.1.


The document will not stand if you delete some of the appendices. They 
aren't supplementary material. Please consider restructuring the 
normative sections back into the main document, or clearly identifying 
which ones define protocol and which

Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

[Robert Sparks]

Thanks Bing -

The updates make the document better, and I appreciate the resolution of 
referencing Tim's expired draft.
I think you've addressed all my comments except for the one on section 
5.1, but that's ok.


For completeness and ease on the ADs, here's an updated summary:

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: May 10, 2013
IETF LC End Date: April 10, 2013
IESG Telechat date: May 16, 2013

Summary: Ready



On 5/2/13 6:02 AM, Liubing (Leo) wrote:

Hi, Robert

Thanks a lot for your continuous careful review.
Please see replies inline.


-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Wednesday, May 01, 2013 12:33 AM
To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
Cc: gen-...@ietf.org; ietf@ietf.org
Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: April 1, 2013
IETF LC End Date: April 10, 2013
IESG Telechat date: May 16, 2013

Summary: Ready with nits (that border on minor issues)

This update improved the readability significantly, and addressed my
major concern about being able to build a list of the gaps. Thank you.

There are a few issues from my last call review that are still not
addressed.
I have left the classification of minor issue vs nits the same as the
original review to make referring to the earlier review easier,
but please consider all of these Nits. The IESG will need to decide
whether to escalate them.

I've trimmed away the points that were addressed.

On 4/1/13 3:46 PM, Robert Sparks wrote:

--
Minor issues:

The document currently references
draft-chown-v6ops-renumber-thinkabout several times.
That document is long expired (2006). It would be better to simply
restate what is
important from that document here and reference it only once in the
acknowlegements
rather than send the reader off to read it.

This version still references that long expired draft. There was also
conversation on apps-discuss
about making that reference normative. IMHO, this is not the right way
to treat the RFC series, and
strongly encourage moving the text that you want to reference into
something that will
become an RFC.

[Bing] Maybe Brian's suggestion of putting some texts into an appendix is a 
good way. We'll discuss this problem when make the next time update.


Should section 8 belong to some other document? It looks like
operational renumbering
advice/considerations, but doesn't seem to be exploring renumbering
gaps, except for
the very short section 8.2 which says we need a better mechanism
without much explanation.

Afaict, this wasn't addressed at all. In particular, we need a better
mechanism is still all that
section 8.2 says.

[Bing] Sorry for leaving it out. Will do in next update.


Section 5.1, first bullet. The list below the impact of ambiguous M/O
flags says things like
there is no standard and it is unspecified. I think you are trying
to say that there is
ambiguity in what's written, not that nothing's written. This entire
list would benefit from
being recast in terms of what needs to be done (what are the gaps?).

This text remains unmodified.

[Bing] We made revision focusing on explaining what are the gaps, but the 
texts change was omitted, will do in next update.


--
Nits/editorial comments:

There are a few sentences ending with etc. in the document. Please
consider deleting the
word from the list - it doesn't help each sentence make its point.

There were some changes, but mostly these still exist. I'll leave
pressing this point further to the RFC Editor.

[Bing] A professional language/editorial check would be helpful.


Seciton 7.1: The first bullet does not parse. If I guess its meaning
correctly
(that it would be benificial to tell hosts that local DNS has been
updated and
they may want to make fresh queries), please be careful with the
wording. The
hosts don't know which names are likely to resolve locally.

This text remained unchanged, and when coming back to the document for a
re-review
(which is somewhat like coming back to an RFC you've read before just
for reference),
it's even harder to understand what it's trying to say than it was when
reading the document
linearly.

I think you are trying to say
A notification mechanism may be needed to indicate _to_ hosts that a
renumbering event has _changed how local recursive DNS servers will
respond_. That mechanism may also need to indicate that such a change
will happen at a specific time in the future.

[Bing] I think it's a better description. Will update, thanks much.


Section 7.1, third bullet - This isn't

Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

Looks good to me. Thanks!
RjS

On 5/6/13 3:02 AM, mohamed.boucad...@orange.com wrote:


Dear Robert,

I updated the document to cover the comments you raised. You can check 
the diff available at: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06


Cheers,

Med

*De :*dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] *De la 
part de* Robert Sparks

*Envoyé :* vendredi 26 avril 2013 17:42
*À :* dh...@ietf.org; ietf@ietf.org; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org

*Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, 
described in

  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 
6.3.

I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the 
content of RECONFIGURE-REQUEST message it issues (e.g., update the 
Client Identifier list).  This decision is local to the relay (e.g., 
it may be based on observed events such as one or more clients were 
reconfigured on their own).



introduces a race-condition that could lead to an erroneous state. If 
a relay's first message included client A, then the retransmission 
included clients A and B, but that retransmission crosses with a 
success RECONFIGURE-REPLY to the request that only included client A, 
the relay will think it succeeded in asking A and B to be reconfigured.


Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be 
supported, but are not discussed in this document.


places a requirement on a relay (even though it's not using a 2119 
MUST). Is there some other document that defines this requirement that 
you can reference? If not, the requirement should be discussed in this 
document. Alternatively, you could change the sentence to talk about 
the consequences of not having a proprietary means for recovering state.


Nits/editorial comments:

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Robert Sparks]

On 4/2/13 4:58 AM, Brian E Carpenter wrote:

Just picking a couple of points for further comment:

On 02/04/2013 08:46, Liubing (Leo) wrote:

Hi, Robert

...


-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]

...

The document currently references
draft-chown-v6ops-renumber-thinkabout
several times.
That document is long expired (2006). It would be better to simply
restate what is
important from that document here and reference it only once in the
acknowlegements
rather than send the reader off to read it.

[Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap 
analysis. Although the draft is expired, most of the content are still valid.
draft-chown is a more comprehensive analysis, while the gap draft is focusing 
on gaps in enterprise renumbering. So it might not easy to abstract several 
points as important from draft-chown to this draft. We actually encourage 
people to read it.

Robert is right, though, sending people to a long-expired draft is a bad idea.
Of course we have to acknowledge it, but maybe we should pull some of its text
into an Appendix.

Tim Chown, any opinion?
The most recent version (and the one slated for the next telechat) still 
has this long-expired draft referenced.


RjS

Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: April 1, 2013
IETF LC End Date: April 10, 2013
IESG Telechat date: May 16, 2013

Summary: Ready with nits (that border on minor issues)

This update improved the readability significantly, and addressed my 
major concern about being able to build a list of the gaps. Thank you.


There are a few issues from my last call review that are still not 
addressed.
I have left the classification of minor issue vs nits the same as the 
original review to make referring to the earlier review easier,
but please consider all of these Nits. The IESG will need to decide 
whether to escalate them.


I've trimmed away the points that were addressed.

On 4/1/13 3:46 PM, Robert Sparks wrote:

--
Minor issues:

The document currently references 
draft-chown-v6ops-renumber-thinkabout several times.
That document is long expired (2006). It would be better to simply 
restate what is
important from that document here and reference it only once in the 
acknowlegements

rather than send the reader off to read it.
This version still references that long expired draft. There was also 
conversation on apps-discuss
about making that reference normative. IMHO, this is not the right way 
to treat the RFC series, and
strongly encourage moving the text that you want to reference into 
something that will

become an RFC.



Should section 8 belong to some other document? It looks like 
operational renumbering
advice/considerations, but doesn't seem to be exploring renumbering 
gaps, except for
the very short section 8.2 which says we need a better mechanism 
without much explanation.
Afaict, this wasn't addressed at all. In particular, we need a better 
mechanism is still all that

section 8.2 says.



Section 5.1, first bullet. The list below the impact of ambiguous M/O 
flags says things like
there is no standard and it is unspecified. I think you are trying 
to say that there is
ambiguity in what's written, not that nothing's written. This entire 
list would benefit from

being recast in terms of what needs to be done (what are the gaps?).

This text remains unmodified.


--
Nits/editorial comments:

There are a few sentences ending with etc. in the document. Please 
consider deleting the

word from the list - it doesn't help each sentence make its point.
There were some changes, but mostly these still exist. I'll leave 
pressing this point further to the RFC Editor.



Seciton 7.1: The first bullet does not parse. If I guess its meaning 
correctly
(that it would be benificial to tell hosts that local DNS has been 
updated and
they may want to make fresh queries), please be careful with the 
wording. The

hosts don't know which names are likely to resolve locally.
This text remained unchanged, and when coming back to the document for a 
re-review
(which is somewhat like coming back to an RFC you've read before just 
for reference),
it's even harder to understand what it's trying to say than it was when 
reading the document

linearly.

I think you are trying to say
A notification mechanism may be needed to indicate _to_ hosts that a 
renumbering event has _changed how local recursive DNS servers will 
respond_. That mechanism may also need to indicate that such a change 
will happen at a specific time in the future.




Section 7.1, third bullet - This isn't obviously about notification. 
Why is it

in this section? What's the gap this is trying to identify?

This text was unchanged.


Section 9.4 - what is it about these that make them gaps, much less 
unsolvable gaps.

Is this discussion in the wrong section of the document?
This is now section 10.3 and is mostly unchanged. It's still not clear 
why this discussion is in the unsolvable gaps section.

Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

On 4/29/13 12:59 AM, mohamed.boucad...@orange.com wrote:

Robert,

Ted suggested a wording which is better than the one I proposed. I made the 
following changes my local copy:

(1)

OLD:
When retransmission is required, the relay may decide to correct the
content of RECONFIGURE-REQUEST message it issues (e.g., update the
Client Identifier list).

NEW:
The relay MAY remove clients from the client identifier list in
subsequent retransmissions, but MUST NOT add clients to the client
identifier list.

(2)

OLD:
Furthermore, means to recover state in failure events must be
supported, but are not discussed in this document.

NEW:
Furthermore, means to recover state in failure events (e.g.,
[RFC5460]) must be supported, but are not discussed in this document.

Is this better?

1 is better.

2 is an improvement, I might say such as instead of e.g. to even more
strongly avoid someone thinking you are _requiring_ implementation of
RFC5460.  Even then, it's still not clear whether you're trying to say

Something that doesn't do this is does not conform to this specification

or

Something that doesn't do this isn't as good a tool as it can be and 
may create a condition that operators and users will not like much.


You chose not to use MUST in that sentence. Can you make it less likely 
that someone will assume you meant to?


Cheers,
Med



-Message d'origine-
De : Bernie Volz (volz) [mailto:v...@cisco.com]
Envoyé : samedi 27 avril 2013 06:24
À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN
Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
dhc-triggered-reconfig...@tools.ietf.org
Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

Robert:

The reason to allow this is that otherwise client A will be unnecessarily
reconfigured many times. (It is also possible that a client might Renew on
its own just as this is happening and thus it can also be removed from the
Reconfigure.)

I think the text should be cleaned up to indicate that allowing removal of
already reconfigured clients is recommended (to prevent unnecessary
reconfigures) when retransmitting the Reconfigure-Request.

Note that if clients are added, that is not a retransmission but requires a
new message (new XID).

- Bernie

-Original Message-
From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of
Robert Sparks
Sent: Friday, April 26, 2013 12:19 PM
To: mohamed.boucad...@orange.com
Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
dhc-triggered-reconfig...@tools.ietf.org
Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:

Dear Robert,

Thank you for the review.
Please see inline.

Cheers,
Med

De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de
Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril
2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review
Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review:
draft-ietf-dhc-triggered-reconfigure-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools
.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described

in

the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section

6.3.

I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the

content of RECONFIGURE-REQUEST message it issues (e.g., update the Client
Identifier list).  This decision is local to the relay (e.g., it may be
based on observed events such as one or more clients were reconfigured on
their own).

introduces a race-condition that could lead to an erroneous state. If a

relay's first message included client A, then the retransmission included
clients A and B, but that retransmission crosses with a success
RECONFIGURE-REPLY to the request that only included client A, the relay
will think it succeeded in asking A and B to be reconfigured.

Med: This example does not apply for that text.

Really? What text constrains how you change what's in the retransmission?

   In fact, the example should be the other way around. Perhaps, this can

be made clearer if we change (e.g., update the Client Identifier list) to
(e.g., remove a client from the Client Identifier list).
If I understand you correctly, you need more than just changing a
parenthetical e.g.. I think you're

Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer: Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

   When retransmission is required, the relay may decide to correct the
   content of RECONFIGURE-REQUEST message it issues (e.g., update the
   Client Identifier list).  This decision is local to the relay (e.g.,
   it may be based on observed events such as one or more clients were
   reconfigured on their own).


introduces a race-condition that could lead to an erroneous state. If a 
relay's first message included client A, then the retransmission 
included clients A and B, but that retransmission crosses with a success 
RECONFIGURE-REPLY to the request that only included client A, the relay 
will think it succeeded in asking A and B to be reconfigured.


Minor issues:

This sentence:

   Furthermore, means to recover state in failure events must be
   supported, but are not discussed in this document.

places a requirement on a relay (even though it's not using a 2119 
MUST). Is there some other document that defines this requirement that 
you can reference? If not, the requirement should be discussed in this 
document. Alternatively, you could change the sentence to talk about the 
consequences of not having a proprietary means for recovering state.


Nits/editorial comments:

Re: RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:

Dear Robert,

Thank you for the review.
Please see inline.

Cheers,
Med

De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert 
Sparks [rjspa...@nostrum.com]
Date d'envoi : vendredi 26 avril 2013 17:42
À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
   the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the content of 
RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier 
list).  This decision is local to the relay (e.g., it may be based on observed 
events such as one or more clients were reconfigured on their own).

introduces a race-condition that could lead to an erroneous state. If a relay's 
first message included client A, then the retransmission included clients A and 
B, but that retransmission crosses with a success RECONFIGURE-REPLY to the 
request that only included client A, the relay will think it succeeded in 
asking A and B to be reconfigured.

Med: This example does not apply for that text.

Really? What text constrains how you change what's in the retransmission?

  In fact, the example should be the other way around. Perhaps, this can be made clearer if we 
change (e.g., update the Client Identifier list) to (e.g., remove a client from 
the Client Identifier list).
If I understand you correctly, you need more than just changing a 
parenthetical e.g.. I think you're saying that you are constraining the 
message changes to be such that if anything earlier in the 
retransmission sequence succeeded, the request in the retransmission 
would also have succeeded. But why do you need that much complexity? Do 
you have it already with any other request?


Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be supported, but 
are not discussed in this document.
places a requirement on a relay (even though it's not using a 2119 MUST). Is 
there some other document that defines this requirement that you can reference?

Med: I'm not aware of any; but if there is one we can cite it.

  If not, the requirement should be discussed in this document. Alternatively, 
you could change the sentence to talk about the consequences of not having a 
proprietary means for recovering state.

Med: Will consider that option if you think this is really needed.

Nits/editorial comments:

Re: Missing requirement in draft-sparks-genarea-imaparch?

[Robert Sparks]

On 4/1/13 6:49 PM, Sam Hartman wrote:

May I suggest that the specific details of this be left to the
implementation effort.  What is easy to implement in this area depends
significantly on what platform (and here I mean more imap libraries and
imap server technology than say python vs ruby vs .net vs C) A simple
requirement like the implementation should consider how to handle abuse
of message marking.
Sam - I agree, and was taking a very similar approach in my working copy 
already.

Let me know if you think -06 has it right.

RjS

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Robert Sparks]

On 4/2/13 4:54 AM, Alexey Melnikov wrote:

Hi Eric,
I am sorry if I sound pedantic below, but I think your suggestion can 
be misinterpreted and thus needs improving:


On 28/03/2013 12:13, Burger Eric wrote:
Rather than guessing all of the bad things that could happen, I would 
offer it would be better to say what we mean, like:
The IMAP interface MUST NOT provide any IMAP facilities that 
modify the underlying message and message metadata, such as mailbox, 
flags, marking for deletion, etc. If the client is authenticated and 
authorized, the IMAP interface MUST provide per-user marking of the 
underlying message as read or flagged.
One way to implement this is in an IMAP server is to always fail 
commands for modifying message metadata. Another way of implementing 
this is to allow them, but ignore (don't persist) results. Both ways 
were used in the past and they have different effect on IMAP clients. 
I hope the requirement is intended to allow for either.


Another thing to consider is that for IMAP servers that implement IMAP 
ACL, the easiest way to meet the intended requirement is by not 
allowing unauthorized users to access some commands on a mailbox. 
Again, a possible reading of your suggested text is that that is not 
allowed.


So, my suggestion is to change MUST NOT provide any IMAP facilities 
... to MUST disallow any IMAP facilities 
I think I found a way to say this that strikes a good balance in -06. 
Let me know what you think.

Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: April 1, 2013
IETF LC End Date: April 10,2013
IESG Telechat date: Not yet scheduled for a telechat

Summary: This document is not ready for publication as an Informational RFC.
 It may be on the right track, but there issues both in substance
 and form that need to be addressed.

Major issues:

The document doesn't provide what its title and abstract claim it will 
provide.
For instance, the abstract claims a gap analysis is presented following 
a renumbering
event procedure summary, but neither appear in the draft. There are a 
few places
in the text that say this is a gap, but usually it's not clear what 
this means.


The stated intent is to identify missing capabilities (gaps) and the work
needed to provide them. The document should lay these out very clearly. 
As the

document is currently written, it is difficult to pull out a simple list of
identified gaps. While addressing that, it would help more to provide some
sense of the relative importance of addressing each of the gaps identified.

There are several significant issues with clarity. I will point to the most
difficult in a section below.

--
Minor issues:

The document currently references draft-chown-v6ops-renumber-thinkabout 
several times.
That document is long expired (2006). It would be better to simply 
restate what is
important from that document here and reference it only once in the 
acknowlegements

rather than send the reader off to read it.

RFC4076 seems to say very similar things to this document. Should it 
have been referenced?


Section 5.3 punts discussion of static addresses off to RFC 6866. That 
document was scoped
only to Enterprise Networks. The scope of this document is larger. Are 
there gaps because
of that difference in scope that were missed? Would it make sense to 
summarize any gaps

RFC 6866 identified that are relevant to this document here?

Should section 8 belong to some other document? It looks like 
operational renumbering
advice/considerations, but doesn't seem to be exploring renumbering 
gaps, except for
the very short section 8.2 which says we need a better mechanism 
without much explanation.



--
Text needing clarity (more than nits):

Section 4.1, second paragraph: The first sentence needs to be 
simplified. Something like
Delegation routers may need to renumber themselves with new delegated 
prefixes perhaps.
The second sentence speaks of the router renumbering issue as if it's 
clear which particular
issue you're actually talking about. Is there a gap here? If so, 
consider replacing the entire

paragraph with an explicit description of the gap.

Section 5.1, first bullet, 2nd paragraph: The third sentence (starting 
In ND protocol,)

makes no sense. The fourth sentence is also hard to parse.

Section 5.1, first bullet. The list below the impact of ambiguous M/O 
flags says things like
there is no standard and it is unspecified. I think you are trying 
to say that there is
ambiguity in what's written, not that nothing's written. This entire 
list would benefit from

being recast in terms of what needs to be done (what are the gaps?).

Section 5.2, last paragraph. It's not clear what you are trying to say 
here. Is it simply
that the natural pressures in an ISP make it more likely that an ISP 
would choose to use
DNS names as part of configuration than an enterprise would? If so, can 
you list what some

of those pressures are? What gap is this discussion trying to identify?

Section 6.1, first paragraph, first sentence (starting For DNS records 
update) - this sentence
does not parse. What is it trying to say, and what's the gap you are 
trying to point to?


Section 6.3, 6th paragraph. So there's a big gap for configuration 
aggregation is
unclear. Is it that configuration isn't stored in one place, or that it 
can't be

found through one place, or something different?

Section 7.1 second bullet. Taking this partial quote from RFC4192 
destroyed the meaning
of the sentence. The original sentence said The suggestion applies - 
this misquote says
reducing the delay applies. There's no benefit to quoting 4192 
directly - say what you

mean and reference 4192.


--
Nits/editorial comments:

There are a few sentences ending with etc. in the document. Please 
consider deleting the

word from the list - it doesn't help each sentence make its point.

Introduction: Future efforts may be achieved in the future. doesn't 
add anything

to the document. I suggest deleting the sentence.

Section 3.2: Consider deleting basically from an IPAM is basically used

Section 5.1: draft-ietf-dhc-host-gen-id

Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Robert Sparks]

All -

draft-sparks-genarea-imaparch has been revised to address comments from
Pete Resnick and Barry Leiba. Jari Arkko has suggested that the security 
considerations
section contain something like what RFC6778 contained about potential 
risks to CPU

and I/O utilization. I plan to make that change in the next version.

While looking at it, I noticed we don't explicitly say that this IMAP 
interface MUST NOT
allow messages in the archive to be deleted or moved to other mailboxes, 
and MUST NOT
allow messages to be inserted. I plan to add those as requirements in 
the next version.


RjS

On 3/26/13 3:45 PM, internet-dra...@ietf.org wrote:

A new version (-05) has been submitted for draft-sparks-genarea-imaparch:
http://www.ietf.org/internet-drafts/draft-sparks-genarea-imaparch-05.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-sparks-genarea-imaparch/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-sparks-genarea-imaparch-05

IETF Secretariat.

Re: Last Call: draft-ietf-bmwg-sip-bench-term-08.txt (Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices) to Informational RFC

[Robert Sparks]

Reviews of draft-ietf-bmwg-sip-bench-term-08 and 
draft-ietf-bmwg-sip-bench-meth-08


Summary: These drafts are not ready for publication as RFCs.

First, some of the text in these documents shows signs of being old, and the
working group may have been staring at them so long that they've become 
hard to
see.  The terminology document says The issue of overload in SIP 
networks is

currently a topic of discussion in the SIPPING WG. (SIPPING was closed in
2009). The methodology document suggests a flooding rate that is orders of
magnitude below what simple devices achieve at the moment. That these 
survived
working group last call indicates a different type of WG review may be 
needed

to groom other bugs out of the documents.

Who is asking for these benchmarks, and are they (still) participating 
in the

group?  The measurements defined here are very simplistic and will provide
limited insight into the relative performance of two elements in a real
deployment. The documents should be clear about their limitations, and 
it would
be good to know that the community asking for these benchmarks is 
getting tools
that will actually be useful to them. The crux of these two documents is 
in the

last paragraph of the introduction to the methodology doc: Finally, the
overall value of these tests is to serve as a comparison function between
multiple SIP implementations.  The documents punt on providing any 
comparison

guidance, but even if we assume someone can figure that out, do these
benchmarks provide something actually useful for inputs?

It would be good to explain how these documents relate to RFC6076.

The terminology tries to refine the definition of session, but the 
definition
provided, The combination of signaling and media messages and processes 
that
support a SIP-based service doesn't answer what's in one session vs 
another.
Trying to generically define session has been hard and several working 
groups

have struggled with it (see INSIPID for a current version of that
conversation). This document doesn't _need_ a generic definition of 
session -
it only needs to define the set of messages that it is measuring. It 
would be
much clearer to say for the purposes of this document, as session is 
the set
of SIP messages associated with an INVITE initiated dialog and any 
Associated

Media, or a series of related SIP MESSAGE requests. (And looking at the
benchmarks, you aren't leveraging related MESSAGE requests - they all 
appear to

be completely independent). Introducing the concepts of Invite-initiated
sessions and non-invite-initiated sessions doesn't actually help define the
metrics. When you get to the metrics, you can speak concretely in terms of a
series of INVITEs, REGISTERs, and MESSAGEs. Doing that, and providing a 
short

introduction pointing folks with PSTN backgrounds relating these to Session
Attempts will be clearer.

To be clear, I strongly suggest a fundamental restructuring of the 
document to
describe the benchmarks in terms of dialogs and transactions, and remove 
the IS

and NS concepts completely.

The INVITE related tests assume no provisional responses, leaving out the
effect on a device's memory when the state machines it is maintaining 
transition
to the proceeding state. Further, by not including provisionals, and 
building
the tests to search for Timer B firing, the tests insure there will be 
multiple
retransmissions of the INVITE (when using UDP) that the device being 
tested has
to handle. The traffic an element has to handle and likely the memory it 
will
consume will be very different with even a single 100 trying, which is 
the more

usual case in deployed networks. The document should be clear _why_ it chose
the test model it did and left out metrics that took having a provisional
response into account. Similarly, you are leaving out the delayed-offer 
INVITE
transactions used by 3pcc and it should be more obvious that you are 
doing so.


Likewise, the media oriented tests take a very basic approach to simulating
media. It should be explicitly stated that you are simulating the 
effects of a
codec like G.711 and that you are assuming an element would only be 
forwarding

packets and has to do no transcoding work. It's not clear from the documents
whether the EA is generating actual media or dummy packets. If it's actual
media, the test parameters that assume constant sized packets at a constant
rate will not work well for video (and I suspect endpoints, like B2BUAs, 
will

terminate your call early if you send them garbage).

The sections on a series of INVITEs is fairly clear that you mean each 
of them

to have different dialog identifiers.  I don't see any discussion of varying
the To: URI. If you don't, what's going to keep a gateway or B2BUA from
rejecting all but the first with something like Busy? Similarly, I'm not
finding where you talk about how many AoRs you are registering against 
in the
registration tests. I think, as written, someone could write this 

Re: Last Call: draft-ietf-bmwg-sip-bench-meth-08.txt (Methodology for Benchmarking SIP Networking Devices) to Informational RFC

[Robert Sparks]

Please see my response to the last call message for 
draft-ietf-bmwg-sip-bench-term. That review covered this document and 
that one at the same time.


RjS

On 1/16/13 3:47 PM, The IESG wrote:

The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'Methodology for Benchmarking SIP Networking Devices'
   draft-ietf-bmwg-sip-bench-meth-08.txt as Informational RFC

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
ietf@ietf.org mailing lists by 2013-01-30. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document describes the methodology for benchmarking Session
Initiation Protocol (SIP) performance as described in SIP
benchmarking terminology document.  The methodology and terminology
are to be used for benchmarking signaling plane performance with
varying signaling and media load.  Both scale and establishment rate
are measured by signaling plane performance.  The SIP Devices to be
benchmarked may be a single device under test (DUT) or a system under
test (SUT).  Benchmarks can be obtained and compared for different
types of devices such as SIP Proxy Server, SBC, and server paired
with a media relay or Firewall/NAT device.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/ballot/


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

Re: Issues relating to managing a mailing list...

[Robert Sparks]

The current plan is to investigate both a web based archive access 
mechanism and an IMAP based one.


I split the requirements for them into two drafts so the projects could 
be pursued separately.

See also https://datatracker.ietf.org/doc/draft-sparks-genarea-imaparch/



On 3/15/12 12:57 PM, Cyrus Daboo wrote:

Hi Pete,

--On March 15, 2012 10:49:25 AM -0500 Pete Resnick 
presn...@qualcomm.com wrote:



Along those lines how about setting up an IETF IMAP server with
mailboxes for each mailing list hosted by the IETF?


There has been a discussion under way for some time to get that to
happen. I believe RFP's are being thought about (or written).


Right, so isn't this, 
http://tools.ietf.org/html/draft-sparks-genarea-mailarch-05, 
entirely satisfiable via IMAP? At the very least I think that draft 
needs another requirement:


* Users must be easily able to reply to archived messages using their 
email client of choice. In particular, replies need to preserve 
threading information in the form of References and In-Reply-To email 
headers.

Ack.

Re: Paris IETF Codesprint

[Robert Sparks]

If you are planning to join this codesprint, please make sure you've let 
us know by

adding yourself to this page:
http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83SprintSignUp
so we can provision correctly.

If you've not thought about the codesprint, take a couple of minutes now 
to look over

the kinds of things we're planning to work on:
http://trac.tools.ietf.org/tools/ietfdb/wiki/EnhancementIdeas
Please add to that list if there's something important to you that you 
see missing.
If see something there you'd really like to have, please join us and 
make it happen.


RjS

On 1/15/12 2:12 PM, IETF Chair wrote:

Paris IETF Codesprint

When:  Saturday, 24 March 2012, starting at 9:30 AM

Where: IETF Hotel

What:  A bunch of hackers get together to work on code for the IETF.
 All code will become part of the open source IETF tools.

Who:   Hopefully you can help

Many of the results of previous codesprint activities are being
used every day by the IETF community.  Shortly before the Paris
meeting, we will transition from the current database schema to a
new one.  We believe that the new schema will make many tasks
much easier.  No doubt, the transition will uncover new bugs.
Work to polish or improve existing tools, fix bugs, or make new
tools.  All efforts are appreciated and most welcome.

Steve Conte will be helping with advance planning.  Henrik Levkowetz
will be coordinating the event in Paris.  You can find more information
here:

  http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83Sprint

If you are able to participate, please sign up on the wiki at:

  http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83SprintSignUp

Please support the tools development effort,
  Russ

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Proposal to remove three datatracker pages (https://datatracker.ietf.org/iesg/ann/ind/, /new, and /prev

[Robert Sparks]

There are three pages exposed at the datatracker that have become stale 
or are producing erroneous information.

https://datatracker.ietf.org/iesg/ann/ind/
https://datatracker.ietf.org/iesg/ann/new/
https://datatracker.ietf.org/iesg/ann/prev/

Has anyone been using those links?

The first link, in particular has not been updated to reflect RFC5742, 
and is currently showing an incomplete set.


All of the information on those pages is available in other locations 
(at the very least at

http://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html.

Unless someone has been relying on these links, I propose removing them.

RjS
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: meeting slots

[Robert Sparks]

I understand Dave's concern, but I think it would be valuable to make it easy 
to see
what has been requested. Any changes to the conflict list would still have to 
come 
through the chairs, encouraging that distributed work model.

I've entered this as an idea that someone might pick up for work at a 
codesprint:
http://trac.tools.ietf.org/tools/ietfdb/ticket/710

RjS

On Oct 12, 2011, at 8:53 PM, John C Klensin wrote:

 
 
 --On Wednesday, October 12, 2011 11:11 -0700 Dave CROCKER
 d...@dcrocker.net wrote:
 
 On 10/12/2011 10:27 AM, Margaret Wasserman wrote:
 I was not picturing everyone adding their own conflicts.
 However, I thought this might help us avoid some of the
 issues we've had in the past, where obvious group-level
 conflicts are omitted, and meetings have to be rescheduled at
 the last moments.
 
 I'll suggest a more distributed model:
 
 Chairs circulate among their wg, the conflicts they believe
 should be avoided. When that discussion settles down, the
 chairs submit their set to ietf staff. IETF staff and ietf
 main list are thereby spared the effort, but each set gets
 review beyond the chairs.
 
 Of course, some WGs / Chairs have been doing this, or variations
 on it. for some years now.   I'd venture that it works better in
 some WGs than others... much like many other things.
 
   john
 
 
 
 
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Robert Sparks]

Scott -

Didn't RFC 5657 address your point 2?

The current proposal no longer requires this report during advancement, but it 
does not disallow it.
I hope it's obvious that I believe these reports are valuable, but I am willing 
to accept the proposed
structure, with the hope and expectation that  communities that are serious 
about producing and 
refining protocols will be producing these reports anyhow.

RjS

On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:

 
 this is better than the last version but
 
 1/ I still see no reason to think that this change will cause any
 significant change in the percent of Proposed Standards that move up the
 (shorter) standards track since the proposal does nothing to change the
 underlying reasons that people do not expend the effort needed to
 advance documents
 
 2/ one of the big issues with the PS-DS step is understanding what
 documentation is needed to show that there are the interoperable
 implementations and to list the unused features - it would help a lot to
 provide some guidance (which I did not do in 2026 - as I have been
 reminded a number of times :-) ) as to just what process is to be
 followed
 
 could be
   a spread sheet showing features  implementations
   an assertion by the person proposing the advancement that the
 requirements have been met
 or something in between
 
 Scott
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Late comment on draft-ietf-sippping-sip-offeranswer-14

[Robert Sparks]

I believe the current text in the draft reflects the discussion from 2007 at
http://www.ietf.org/mail-archive/web/sipping/current/msg13812.html

To summarize, while we think there may be implementations that interpret a 
change of session-id as a session reset,
RFC3264 doesn't support the notion. The top-level assumption of 3264 is that 
there is one SDP session associated
with a SIP dialog. (See in particular:
http://www.ietf.org/mail-archive/web/sipping/current/msg13845.html
http://www.ietf.org/mail-archive/web/sipping/current/msg13870.html
and
http://www.ietf.org/mail-archive/web/sipping/current/msg13912.html)

The thread explores places where some folks would like to things to be 
different, but those
things will need normative updates, probably to more than one RFC.

I believe the text in the draft is consistent with what our current specs say.

For the normative updates we would need to make for this particular topic, I 
think 
restarting the debate on the RAI list (with pointers to SIPCORE and MMUSIC) is 
the right thing to do.

RjS

On Apr 26, 2011, at 8:37 AM, Elwell, John wrote:

 I know last call finished already, but the following has just been brought to 
 my attention:
 
 In section 5.2.5
 Changing the o-line,
  except version number value, during the session is an error case.
  The behavior when receiving such a non-compliant offer/answer SDP
  body is implementation dependent. 
 I would content this is NOT an error situation, or at least not an error in 
 the case where a NEW session is being signalled.
 
 Consider a 3PCC situation along the lines described in section 7 of RFC 3725. 
 The controlling B2BUA converts a session between UA A and UA B into a session 
 between UA B and UA C. Prior to this conversion, UA B has received UA A's SDP 
 (SDP A). As a result of the conversion, UA B receives UA C's SDP (SDP C).
 
 SDP C is likely to be completely different from SDP A. Therefore just a 
 change of version number in the o-line is insufficient and would probably 
 violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only 
 one m-line, the change from 2 m-lines to 1 m-line is not permitted according 
 to RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting 
 version numbers, that is insufficient in some cases.
 
 The text of 5.2.5 then goes on to say:
 The behavior when receiving such a non-compliant offer/answer SDP
  body is implementation dependent.
 It is not clear what this fails to comply with. I can find nothing in RFC 
 3264 that stops you sending a new o-line if there is a new session. Yes, it 
 would be non-compliant if only modifying an existing session, but how does 
 the recipient know whether or not it is a new session, and therefore whether 
 or not it is valid?
 
 It then goes on to recommend use of Replaces in this situation (i.e. change 
 of session):
 If a UA needs to negotiate a
  'new' SDP session, it should use the INVITE/Replaces method.
 But Replaces is not feasible if the UA concerned does not support it (and 
 hence should, presumably). So there will still be cases where a controlling 
 B2BUA is forced to change the o-line (not just the version) in order to 
 comply with RFC 3264.
 
 So there needs to be a mechanism for changing to a 'new' session without 
 relying on Replaces. As far as I can see, there is no standards track RFC 
 that forbids changing the o-line to achieve this, so this new Informational 
 draft should not attempt to make that change, and in particular should not do 
 so without proposing an alternative solution.
 
 A simple fix would be to delete the entire bullet beginning In the o-line, 
 only the version number may change.
 
 John
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-genarea-charter-tool-07.txt (Requirements for a Working Group Charter Tool) to Informational RFC

[Robert Sparks]

Hi Paul -

In section 2.2, I would prefer either using the names the tracker currently 
uses for IESG evaluation:
Discuss and Comment, or some set of words that do not intersect those, 
perhaps Blocking and
Not-Blocking. The current set (discuss and regular) will lead to 
confusion.

In section 2.7, you don't specifically capture WGs that currently exist, but 
are not rechartering at the moment.
I think you meant to as part of the second paragraph, but the last phrase could 
be read to be exclusive.

(As an aside - do you intend that for existing working groups, this history 
will go all the way back to when
the group was formed? Will we be able to count on foo-charter-00 being the 
charter that the working group
formed with for all foo?)

In section 3.1 - It would be better to have the ability to override the tool's 
rejection of a name because some
previous effort (particularly abandoned ones) had the same name. If someone 
thought about using a name
5 years ago, but never took it even to the point of Internal Review, why should 
the tool force it not be be used now?
This is a place that human judgement should be allowed to be exercised.

Also, we should make sure the tool doesn't unintentionally make reopening a 
closed WG harder than intended.

It would help to clarify in the first bullet in 3.1 that the tool should prompt 
the AD, but not prevent them from
completing the move if that's the right thing to do. (The tool is providing a 
reminder, not enforcing a rule).

In the 4th bullet of that list, you ask the tool to send a note to the 
scretariat to schedule discussion on a telechat.
In practice today, this happens as part of the transition into External Review. 
I suggest moving the sentence into
the 3rd bullet.

In section 3.2's second bullet, it is possible, I believe, to directly approve 
a recharter from internal review. The tool
should allow that transition.

I'm a little concerned about taking working groups for which a recharter is 
being considered out of the state named
WG Exists. Semantically, if you aren't in that state, it implies the WG 
doesn't exist, and I could see someone
drawing the wrong conclusion from a search. The best way to avoid this might be 
to rename the WG Exists state
to something like WG Chartered - no rechartering effort currently in progress 
(which I realize is too wordy).


RjS








On Mar 11, 2011, at 4:11 PM, The IESG wrote:

 
 The IESG has received a request from the General Area Open Meeting WG
 (genarea) to consider the following document:
 - 'Requirements for a Working Group Charter Tool'
  draft-ietf-genarea-charter-tool-07.txt as an Informational RFC
 
 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
 ietf@ietf.org mailing lists by 2011-03-25. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-genarea-charter-tool/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-genarea-charter-tool/
 
 
 
 No IPR declarations have been submitted directly on this I-D.
 ___
 IETF-Announce mailing list
 ietf-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf-announce

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-genarea-datatracker-community-06.txt (Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC

[Robert Sparks]

Paul -

1) If we publish this as an RFC, note that imgur.com will only keep an image if 
it's viewed at least once every three months.

2) In the list of things constituting an update to an RFC, could you call out 
marking an RFC as Historic, and changing the
maturity level of an RFC in place (such as was done for 5652)

3) 2.1.2 talks of the ease of use to create a datatracker account. I think we 
have that already through the tools system.
Are you thinking this will require the creation of a different system?

RjS

On Mar 4, 2011, at 4:46 PM, The IESG wrote:

 
 The IESG has received a request from the General Area Open Meeting WG
 (genarea) to consider the following document:
 - 'Requirements for Internet-Draft Tracking by the IETF Community in the
   Datatracker'
  draft-ietf-genarea-datatracker-community-06.txt as an Informational
 RFC
 
 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
 ietf@ietf.org mailing lists by 2011-03-18. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
 
 
 
 No IPR declarations have been submitted directly on this I-D.
 ___
 IETF-Announce mailing list
 ietf-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf-announce

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-genarea-datatracker-community-06.txt (Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC

[Robert Sparks]

One additional thought -

How much would the list of attributes in 2.1.6 need to be expanded to make one 
of these user-defined lists
enough to satisfy the initial Reporting Requirements in section 4.3 of 
draft-ietf-genarea-datatracker-iana-rfced-extns-00?
Should we add the ability to match against the values (or absence of value) of 
a state for the various state machines tracked by the tracker?

RjS

On Mar 14, 2011, at 4:26 PM, Robert Sparks wrote:

 Paul -
 
 1) If we publish this as an RFC, note that imgur.com will only keep an image 
 if it's viewed at least once every three months.
 
 2) In the list of things constituting an update to an RFC, could you call 
 out marking an RFC as Historic, and changing the
 maturity level of an RFC in place (such as was done for 5652)
 
 3) 2.1.2 talks of the ease of use to create a datatracker account. I think we 
 have that already through the tools system.
 Are you thinking this will require the creation of a different system?
 
 RjS
 
 On Mar 4, 2011, at 4:46 PM, The IESG wrote:
 
 
 The IESG has received a request from the General Area Open Meeting WG
 (genarea) to consider the following document:
 - 'Requirements for Internet-Draft Tracking by the IETF Community in the
  Datatracker'
 draft-ietf-genarea-datatracker-community-06.txt as an Informational
 RFC
 
 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
 ietf@ietf.org mailing lists by 2011-03-18. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
 
 
 
 No IPR declarations have been submitted directly on this I-D.
 ___
 IETF-Announce mailing list
 ietf-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf-announce
 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Fwd: [Sip] New version of draft-ietf-sip-ipv6-abnf-fix

[Robert Sparks]

fyi

Begin forwarded message:

 From: Vijay K. Gurbani v...@bell-labs.com
 Date: May 3, 2010 9:45:53 AM CDT
 To: IETF SIP List s...@ietf.org
 Cc: Brian E Carpenter brian.e.carpen...@gmail.com, Brett Tate 
 br...@broadsoft.com
 Subject: [Sip] New version of draft-ietf-sip-ipv6-abnf-fix
 
 Folks: A new version (-05) of draft-ietf-sip-ipv6-abnf-fix
 is ready to be sent to the IESG.
 
 The summary of changes is as follows:
 
 1) Minor typo and grammatical fixes.
 2) Added a new S4 in -05 to serve as a reference point to
   draft-ietf-6man-text-addr-representation-07, a draft on
   how to generate a canonical IPv6 textual representation.
 
   draft-...-addr-representation is now referenced using a
   normative SHOULD and has been made a normative reference.
   This should not delay the release of draft-...-ipv6-abnf-fix
   since draft-...-addr-representation is now in RFC Ed Queue.
 
 The relevant links are:
 New version (-05):
 http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-05.txt
 
 Diff from previous version:
 http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-ipv6-abnf-fix-05
 
 Thanks,
 
 - vijay
 -- 
 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
 Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
 Web:   http://ect.bell-labs.com/who/vkg/
 ___
 Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
 This list is essentially closed and only used for finishing old business.
 Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP 
 implementation.
 Use dispa...@ietf.org for new developments on the application of sip.
 Use sipc...@ietf.org for issues related to maintenance of the core SIP 
 specifications.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Sparks]

John, Jari -

I was one of the folks expressing the concern Jari points to below,  
and it's
a small facet of a larger worry I have about a potential (and I think  
likely)
unintended consequence of the header/boilerplate changes. To capture  
that
in this thread (with apologies for walking through old discussions) :  
specifically,
I think we're making it even harder for people who are not deeply  
steeped in

IETF arcana to tell the difference between the output of a working group
(or any other IETF product) and the output of an individual. By  
downplaying
that distinction, we are also making it easier for people with the  
motivation
to champion technologies that compete with IETF products to convince  
those

non IETF-arcana-steeped folks around them to follow.

But, that's water under the headers and boilerplate consensus building  
bridge.


I think it should be more _routine_ than we are making it for _some_  
body

representing IETF consensus to shine a light on that distinction when
necessary. The escalation process you point to is a fairly high bar  
and it
puts providing the required energy on the wrong parties. I'm sensitive  
to

the 'how it has always been' argument, but we are exactly in the process
of changing to a new RFC-editor model.

I've also been asking a few regular contributors and some chairs what
they thought about this, and am very frustrated with how little  
attention

the entire change this small conversation is part of appears to have
received in the greater community. I don't know what to do to improve  
that
beyond what we're doing now (through calls like this and through  
individual

prodding).

RjS

On Aug 31, 2009, at 9:37 AM, John C Klensin wrote:




--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
jari.ar...@piuha.net wrote:


I would like to get some further input from the community on
this draft.
...
And now back to the input that I wanted to hear. I would like
to get a sense from the list whether you prefer (a) that any
exceptional IESG note is just a recommendation to the RFC
Editor or (b) something that is always applied to the
published RFC. Please reply before the next IESG meeting on
September 10. Some e-mails on this topic have already been
sent in the Last Call thread -- I have seen those and there is
no need to resend.


Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
(always == since the IESG was created and long before it
started writing notes) been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.


...


   regards,
 john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reminder: Tools codesprint at IETF74

[Robert Sparks]

If you are planning to join the codesprint at IETF74, please add  
yourself to the wiki page at

http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF74SprintSignUp

to help us build a rough idea of how many folks will be present. More  
information about this sprint can be found at


http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF74Sprint

If you can't work with the wiki for some reason, please drop me a note.

Thanks,

RjS


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

[Robert Sparks]

I support conducting this experiment.

RjS

On Jul 17, 2008, at 4:33 PM, IETF Chair wrote:


The IESG is considering an experiment for IETF 73 in Minneapolis, and
we would like community comments before we proceed.  Face-to-face
meeting time is very precious, especially with about 120 IETF WGs
competing for meeting slots.  Several WGs are not able to get as much
meeting time as they need to progress their work.  As an experiment,
we are considering adding two Friday afternoon one-hour meeting slots.
The proposed Friday schedule would be:

  0900-1130 Morning Session I
  1130-1300 Break
  1300-1400 Afternoon Session I
  1415-1515 Afternoon Session II

Please share your thoughts about this proposed experiment.  The
proposed experiment will be discussed on the IETF Didcussion mail
list (ietf@ietf.org).


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: SHOULD vs MUST

[Robert Sparks]

fwiw -

I have, for many SIPits (a rather large interop event for SIP  
implementations) worked to get the people writing code from these  
documents to understand that MUST means MUST and SHOULD means MUST ... 
(very long pause)... unless you _really_ know that not following the  
SHOULD won't result in very bad things.


They typically respond with MUST means MUST unless they're sure they  
can get away without it most of the time, and that SHOULD means its in  
some future release that will get funding maybe someday. Some of that  
response is tongue-in-cheek - some of it isn't.


I see a strong trend for unadorned SHOULDs to remain unimplemented.  
SHOULDs that have a very clear, and explicitly called out even when  
they seem incredibly obvious, explanation of the bad things that can  
happen if you don't follow them get implemented.


So, at least for the documents I edit, I work really hard to explain  
the SHOULDs to help motivate the implementors to actually build things  
that conform to it.


RjS



On Jun 25, 2008, at 12:02 PM, Scott Brim wrote:


On 6/25/08 8:24 AM, John C Klensin allegedly wrote:

--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
[EMAIL PROTECTED] wrote:

... and draft authors should include explanations in their
drafts of the reasons an implementor might legitimately have
for not implementing the should.  For example, an older
operating system that does not support a new capability.



Do you really mean, e.g., 	... where feasible and, in the author's  
judgment,

appropriate, it is desirable to include explanations or
illustrations of the exception cases in drafts that use
SHOULD.
???
I've run into a number of situations over the years in which
there are known edge cases that prevent a MUST but where those
edge cases are rare and obscure enough that describing them
would require extensive text.


My rule of thumb is: when you're writing the draft if something is  
not a MUST, ask yourself why not? and write down your answer.  You  
can be brief but make it clear that the SHOULD is a MUST with  
exceptions.


There's no way we should have strict process rules about this.  The  
IETF has enough rules as it is.  However, explanations of SHOULDs do  
make better standards.  The point is to give guidance to  
implementors.  I did an informal survey last year and found that  
some implementors treat every SHOULD as a MUST, but more of them  
just treat a SHOULD as a MAY, essentially to be ignored.  An  
explanation of the circumstances surrounding a SHOULD will lead to a  
lot more consistency in implementation.  Many SHOULDs in RFCs are  
because there are old implementations that need to be taken into  
account, or because some capability isn't widely possible yet but  
will be within the lifetime of the standard.  If a MUST becomes a  
SHOULD to take that into account, and you explain it, your chances  
of getting rid of non-MUST-capable implementations eventually goes  
up tremendously.  So, to reiterate, when you're writing the draft if  
something is not a MUST, ask yourself why not? and write down your  
answer.



___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Sip] NOTIFY on call transfer procedure

[Robert Sparks]

Section 6 of RFC3515 calls out why REFER is constructed this way.

The root cause is the fixed length of any SIP non-INVITE transaction.
The approach you sketch won't work as provisional responses to 
non-INVITE requests do _not_ lengthen the transaction.

If you want a more detailed description, look at
http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-00.txt
and
http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-00.txt

RjS


On Thu, 2004-05-06 at 23:55, Thomas Ackermann wrote:
 Hi all,
 
 can anybody tell me why the transfer procedure needs NOTIFY message
 with application/sipfrag message body?
 
 Why not simply keep the REFER transaction open by sending:
  - a provisional response instead of the 202/Accepted and
  - a final 200/OK response instead of NOTIFY(200 OK) ?
 Just like the INVITE transaction with all its intermediate responses.
 
 Or even more simple:
 The Transferee sends the BYE by itself instead of asking the Transferor
 to terminate the call?
 
 Do you know the reason why the NOTIFY transaction has been added to
 call transfer procedure?
 
 Thanks for your help,
 Thomas
 
 ___
 Ietf mailing list
 [EMAIL PROTECTED]
 https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf