Hi Matt, Thanks for the feedback; the group working on this are quite good. Right now we're dividing the field list into a set of mandatory and a set of optional fields. Hopefully this approach will make implementation easier. I'd like to get input from both the IX community and carriers; so far we're lacking in representation from those areas.
We may also come up with a way for vendors to extend the standard with their own locally defined fields for the super hip operators. Erik On Tue, Mar 17, 2015 at 6:36 PM, Matt Peterson <[email protected]> wrote: > Erik - This looks great, super extensive - I'd be very impressed if > carriers would provide all of this information. It may be easier to start > courting the IX operators, as they tend to be a bit more hip to adjusting > the status quo for their communities. > > --Matt > > On Tue, Mar 17, 2015 at 2:00 PM, Erik Klavon <[email protected]> > wrote: > >> Hi Matt, >> >> What we have so far is in this document: >> >> https://cloud.box.com/s/rz2kimfnd8bhihrrjwah0wuwykmwfcls >> >> Erik >> >> On Tue, Mar 17, 2015 at 1:54 PM, Matt Peterson <[email protected]> wrote: >> >>> My suggestion would be to send iCal attachments via email, this is >>> already a well established conduit for receiving these sorts of notices and >>> many mail clients can parse iCal natively. I fear many organizations can >>> subscribe to an CalDAV end point, even if that's the proper way to >>> 'subscribe' for notices in a pull vs. push model. >>> >>> Do you have a draft to share of the common fields? >>> >>> --Matt >>> >>> On Tue, Mar 17, 2015 at 1:50 PM, Erik Klavon <[email protected]> >>> wrote: >>> >>>> Hi Matt and Chris, >>>> >>>> Our focus so far has been on identifying common fields. Maintenance >>>> impact is a common field we've identified. >>>> >>>> vCal/iCal/CalDAV are good suggestions. We'll look into these standards >>>> when we take up the format question. If you know anyone who is has >>>> experience with these protocols and might be interested in helping out >>>> please send them my way. >>>> >>>> Thanks, >>>> >>>> Erik >>>> >>>> On Tue, Mar 17, 2015 at 1:36 PM, Chris Woodfield <[email protected]> >>>> wrote: >>>> >>>>> Was about to chime in with a similar thought myself. Do we have to >>>>> re-invent the wheel here WRT protocol? Can the “machine-parsable template” >>>>> simply be CalDAV, with some standard logic around mapping calendar >>>>> “Guests” >>>>> to various services/circuits a customer may have with a vendor? >>>>> >>>>> -C >>>>> >>>>> On Mar 17, 2015, at 1:31 PM, Matt Peterson <[email protected]> wrote: >>>>> >>>>> This seems like a great idea, were you thinking of using vCal/iCal >>>>> <https://en.wikipedia.org/wiki/ICalendar> and/or another format for >>>>> sharing or describing these events? It would also be useful to have some >>>>> attributes such as "you may be impacted by this work" vs "you will be >>>>> impacted". >>>>> >>>>> --Matt >>>>> >>>>> On Tue, Mar 17, 2015 at 12:40 PM, Erik Klavon <[email protected]> >>>>> wrote: >>>>> >>>>>> Greetings >>>>>> >>>>>> We all generate and consume communications on maintenance activities. >>>>>> I’ve put in my time manually processing these communications, converting >>>>>> time zones, adding entries to calendars, opening tickets, and – as with >>>>>> any >>>>>> manual process – introducing the occasional error along the way. Much of >>>>>> the time these notifications are carried in an email, the format of which >>>>>> varies from sender to sender. I’d love to have some conventions for the >>>>>> formatting of the information in these emails. Such conventions would >>>>>> make >>>>>> it simple to create tools that eliminate the more boring and error prone >>>>>> aspects of processing these emails. >>>>>> >>>>>> I’m shepherding a BCOP effort to identify common forms of >>>>>> notification, their common content, and propose machine parsable >>>>>> templates >>>>>> for notifications. Operators may include completed instances of these >>>>>> templates in their notifications to aid in their digestion. Thanks to the >>>>>> work of Randy Neals, who first championed this idea, we have a couple >>>>>> subject matter experts from the community who have signed on to this >>>>>> effort. We’re looking for additional people to get involved, especially >>>>>> people with programming experience. Reach out to me if you’re interested. >>>>>> >>>>>> Erik >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> BCOP mailing list >>>>>> [email protected] >>>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> BCOP mailing list >>>>> [email protected] >>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>>> >>>>> >>>>> >>>> >>> >> >
_______________________________________________ BCOP mailing list [email protected] http://mailman.nanog.org/mailman/listinfo/bcop
