Subject: Re: [MBONED] issues in draft-ietf-mboned-routingarch-07

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Jun 2007 16:06:34 +0300 (EEST)

Hi,

I've waited for further input on this, but none so far.  Any more 
thoughts?

Some comments inline:

On Wed, 18 Apr 2007, Peter Koch wrote:
> your questions seem far more process oriented or RFC Editor related than
> subject to WG consensus, but here are my two cents:
>
>>  1) BCP vs Informational.  This was discussed mostly between myself
>>     and David and wider input would be useful.  BCPs express wide IETF
>>     community consensus and reviews are conducted in more depth.
>>     Given that the document makes statements about the usefulness and
>>     applicability of a lot of protocols (also outside this WG), having
>>     broad consensus seems very important.  When the document is
>>     updated in the future (likely in this case), BCP number does not
>>     need to change.  On the other hand, informational is easier to
>>     achieve and can also go through IETF Last Call (though people will
>>     likely not review the document at the same detail).
>
> I do not think that the level of review you'd like to see should determine
> the document status, but it is the other way round. A reason for BCP
> would be, e.g., adding or changing IANA instructions, but if I read the
> draft correctly it does not have IANA considerations (read: instructions)
> on its own. Informational seems fine to me and asking the ADs to issue
> an IETF LC is the way to get broader review.

The document status implies how high a bar the document must pass 
before a reviewer is satisfied with it.  A BCP document requires a 
higher bar than an Informational RFC, even if the informational 
document were to be IETF last called.

My point is that I believe it is important to get a high level of 
scrutiny at this point (implying BCP) so that we can be sure the 
document should represent as wide IETF consensus as possible. 
Informational RFC does not carry the equal weight.

I think reasonable people can disagree on whether trying to achieve 
such a higher bar is worth the trouble given an Informational RFC 
would be sufficient from process point of view; I'm not sure if there 
is anything else to disagree on.

>>  2) Document Obsoletes and reclassifies Historic 5 RFCs *).
>>     Obsoletes tag was used to create a forward reference in the RFC
>>     index.  However, as this specification doesn't "replace" the
>>     earlier RFC, it seems Obsoletes is maybe not appropriate.
>>
>>     Unless there are comments indicating otherwise, I'm going to
>>     revise the draft to only reclassify the RFCs Historic, not
>>     Obsolete them.
>
> There is inconsistent precedent for this question (and as the author of
> 4223 you probably knew that already), with the most recent trend in
> favor of obsoleting the RFC that is reclassified.
> A pragmatic argument for this might be that this way the RFC index contains
> a pointer from the "Historic" spec to a document that provides some reason
> for the status.

Right.  Unfortunately, others have not provided their opinion on this 
(mostly procedural) question.  Unless I hear otherwise, I'll stick 
with what the document already has and change it later if there is 
pushback.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Jun 2007 16:06:34 +0300 (EEST)

Hi,

Some comments inline: