Hi,
There is a list of acronyms at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
Those marked with a star do not need to be expanded in any new I-D or RFC.
Those not marked need to be expanded on first use in the Abstract and in the
main body of the text (the Abstract is supposed to be free-standing).
Over time, the RFC Editor adds stars. I suspect they are susceptible to
lobbying.
Cheers,
Adrian
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Eric
Rosen
Sent: 28 October 2010 20:07
To: James M. Polk
Cc: ietf(_at_)ietf(_dot_)org; ice(_at_)cisco(_dot_)com;
tme(_at_)multicasttech(_dot_)com; danny(_at_)tcb(_dot_)net;
ycai(_at_)cisco(_dot_)com; erosen(_at_)cisco(_dot_)com
Subject: Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
James> perhaps this needs to be stated (that the Type 4 is created by
James> this doc for your purpose)?
I think the doc already makes this clear, maybe I'm not sure what you are
asking.
James> You can probably imagine how many SIP and RSVP protocol
James> extensions there are (70+ and about 20 respectively off the top
James> of my head), and yet every one of them have to state "Session
James> Initiation Protocol (SIP)" and "ReSource ReserVation Protocol
James> (version-1) (RSVPv1)" the first time they appear, no matter how
James> big the community of interest is.
And this makes sense to you?
Okay, I will expand the occurrence of "S-PMSI" in the abstract.
On the issue of the maximum UDP packet size, I think that is an implementation
issue and I don't think it is appropriate to raise it in this document.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf