ArchiveOrangemail archive

Transport Area Working Group


tsvwg.ietf.org
(List home) (Recent threads) (187 other Internet Engineering Task Force (IETF) lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 1,179 messages, beginning Mar 2011
  • 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

A question about draft-saldana-tsvwg-tcmtf-02

Ad
Jose Saldana 1332919012Wed, 28 Mar 2012 07:16:52 +0000 (UTC)
The other day, reading RFC Tao, y read this sentence in the introduction of
7.3:

There are some informal rules for Internet-Draft naming that have evolved
over the years. Internet-Drafts that revise existing RFCs often have draft
names with "bis" in them, meaning "again" or "twice"; for example, a draft
might be called "draft-someone-rfc2345bis-00.txt".

The question is: Should we change the name of the draft (in the next
version) to:

draft-saldana-tsvwg-tcmtf-rfc4170bis-02

Perhaps it is too late for that. In addition, it is an informal rule.

Any opinion about it?

Regards,

Jose
James M. Polk 1332920782Wed, 28 Mar 2012 07:46:22 +0000 (UTC)
Jose

<chair hat on>

"bis" named documents are intended to replace existing RFC(s) (i.e., 
make an existing RFC obsolete (if, and) when this new draft is 
published as an RFC. This -rfcXXXbis- designation is intended to give 
context to what this new draft is about, but does not indicate any 
changes in solution/direction/whatever this new draft is attempting to achieve.

A good example from TSVWG is when the original SCTP base spec RFC 
(2960) was rewritten to update and correct any known errors (mistakes 
or omissions) that draft was draft-*-tsvwg-2960bis-... when in WG 
draft form. This draft reached consensus within this WG and the 
community to become RFC 4960, which is a proposed standard currently. 
If, and when, SCTP needs to progress towards Internet Standard (IS) 
along the standards track, it (likely) will start with  a filename 
with "...-tsvwg-4960bis-..." in it.

Does this make sense?

If you follow that (and no one disagrees with it), do you believe 
your draft qualifies as an intended rewrite of RFC 4170? It is 
important what you as an author believes about this, as well as what 
the WG believes about this. If consensus is reached whether (or not) 
this draft should be considered a rewrite of RFC 4170, the filename 
can change then (usually at the direction of the WG chairs). The 
draft title does not need to change, and in fact often does not.

James
<chair hat on>At 02:16 AM 3/28/2012, Jose Saldana wrote:
>The other day, reading RFC Tao, y read this sentence in the 
>introduction of 7.3:
>
>There are some informal rules for Internet-Draft naming that have 
>evolved over the years. Internet-Drafts that revise existing RFCs 
>often have draft names with "bis" in them, meaning "again" or 
>"twice"; for example, a draft might be called 
>"draft-someone-rfc2345bis-00.txt".
>
>The question is: Should we change the name of the draft (in the next 
>version) to:
>
>draft-saldana-tsvwg-tcmtf-rfc4170bis-02
>
>Perhaps it is too late for that. In addition, it is an informal rule.
>
>Any opinion about it?
>
>Regards,
>
>Jose
Wesley Eddy 1332921015Wed, 28 Mar 2012 07:50:15 +0000 (UTC)
On 3/28/2012 3:16 AM, Jose Saldana wrote:
> 
> The question is: Should we change the name of the draft (in the next
> version) to:
> 
> draft-saldana-tsvwg-tcmtf-rfc4170bis-02
> 
> Perhaps it is too late for that. In addition, it is an informal rule.
> 
>Hi Jose; by my understanding, your proposal is significantly
different from 4170, and not just a set of changes to it, so
I don't think it would strictly be a "bis" document to 4170.
This is just my opinion :)

I have a related question on the document.  Since it allows
for multiple options at each "layer" of the tunneling and
compression, how do you get agreement at each end about what
it's okay to use, and what actually is used?  Is it just
assumed to be a matter of management out of band?
Home | About | Privacy