Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

[Christopher Morrow <[e-mail]>]

On Mon, Oct 15, 2012 at 9:21 AM, Andy Newton <[e-mail]> wrote:
> On 10/12/12 10:53 AM, "Christopher Morrow" <[e-mail]> wrote:
>
>>I think if, in the end, the wg decides to abandon the work that's also
>>fine, but we should have a more structured chat about the topic, that
>>happens around a draft.
>
>
> As the person who specifically asked of the chairs that the draft authors
> be allowed to address the issues raised, I'd like specifics on this more
> structured chat. I ask because it is not apparent that the normal means of

I hope (and I think co-chairs hope) that the authors and commentors
can discuss what the problem attempting to be documented is, add the
right words to the document and then we can all decide if documenting
something in an informational RFC that describes a capability that
exists in the system today (and the downsides of executing that
capability) is appropriate.

it'd be nice, really, to know at the end if there is a reason to NOT
publish something along those lines as well, and if the wg things not
publishing is best, then we'll just wander off and leave the kitten by
the lake on it's own.

> IETF discussion were attempted. Of the 38 messages regarding the draft
> directly, the draft author only responded 3 times, nor did the author
> engage in any of the side discussions. And the draft submitted as a
> working group document addresses NONE of the issues raised (it is just a
> re-spin with the dates and file name changed). If normal IETF discourse is

that's fine though, right? the author and commentors can work out the details.

> being set aside especially when it was not fully engaged, we should also
> be given the exception criteria under which this scenario qualifies when
> others do not.

don't think there's anything special going on, there was a bunch of
discussion, keep on discussing and if this ends up being publishable
'ok', if not 'ok'.

Some of the discussion was along the lines of 'you shouldn't do this
because its bad' or 'doing this circumvents the point of the
system'... that's also fine to document. the system seems to have the
capabilities, it'd be nice to know when not to pull the trigger (while
aimed at foot) and when TO pull trigger (downrange is clear).