Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Jul 2003 11:53:23 -0500

I think there has been some misunderstandings about the charter and the 
IETF process(es).

An ID that is to become a BCP does so after WG consensus, this ID clearly 
hasn't achieved that consensus - therefore I question its movement towards 
an Informational publication at this point.

This ID calls for specific changes to existing protocols which have been 
stated as only a matter of local policy, therefore the existing protocols 
aren't really changed - this is *not* correct. An existing protocol is one 
that requires nothing new to be done to it; a form of implement "as is in 
RFC XXXX".

Take SDP for example, if someone were to implement RFC 2327 "as is", would 
they get what you are calling for? The answer would be "no". You have 
called for an extension to that protocol within your ID - and that is not 
appropriate without the WG that is responsible for SDP to reach consensus 
on that extension. This is where a requirement(s) ID should be generated by 
the IEPREP WG into the MMUSIC WG to extend the SDP protocol. This would 
allow (perhaps almost force) MMUSIC to look at this requirements ID and 
decide if further work was necessary (through WG discussions). If further 
work was deemed necessary to satisfy this/these requirements, then a 
extension mechanism ID would be generated by someone as a Standards Track 
ID (in MMUSIC) to (hopefully) become a Standards Track RFC. Only at that 
point can a BCP (anywhere) reference it this capability.

I read at least 5 different extensions that are needed to different 
protocols from your ID.

I almost feel as if this ID was the conclusions of a gap analysis. That 
isn't a bad thing. My belief is that the conclusions of a gap analysis 
should generate one or more requirements IDs to be RFCd and put forth into 
the appropriate WGs for their discussions (just as in the SDP example 
mentioned above).

One idea from this ID is to turn it backwards into a requirements ID with 
what you conclude as the probable answers to the requirements. For example 
with SDP, you state that there should be two new attributes (x-NatETS and 
x-IntETS). In this new requirements ID, you (someone) can clearly state why 
the existing SDP (upon a careful review of specific referenced RFCs) cannot 
satisfy what you envision these new attributes accomplishing, and thus 
require "something" be done to satisfy these new capabilities that SDP MUST 
provide (that it currently doesn't).

This will lead to pointed discussions about SDP, and will allow community 
review of the requirements before deciding on the appropriate mechanism so 
satisfy the requirements. Having this requirements ID be a separate ID for 
SDP would allow specific energy to be directed at the ID by those that know 
SDP. This would be in contrast to an all-encompassing requirements ID that 
covers (at least) 5 different protocols requiring people to sift through 
what they are not interested in to get to what they are interested in. This 
also saves the sanity of the authors *not* having to keep one document 
together that makes sense    ;-)

Similar approaches should be taken with all protocols mentioned within this 
ID (Diffserv, MPLS, SIP, MEGACO).

Now to a point of correction, there is indeed a SIP Priority Header, but it 
is not used in a fashion you appear to think it does. The SIP Priority 
Header does NOT cause anything to be processed any differently, it is 
merely an indication to the receiving user (and not the user agent) of the 
importance of the session. This was why Henning and I needed to propose an 
extension to the SIP protocol for resource priority of SIP entities between 
the requesting and responding UAs. This effort had to be in a separate ID, 
after a requirements ID was agreed upon (RFC 3487). Once a Resource 
Priority header is created via a Standards Track RFC, vendors should 
interpret any priority in that header to also mean a priority indication to 
the called user (via the UI).

In your ID's reference to the SIP Priority header, it gives the syntax of 
the Resource Priority Header (without referencing that ID, BTW). This, too, 
is incorrect.

At 10:09 AM 7/3/2003 -0400, Gunn, Janet wrote:

>Scott, Ran,
>
>Thanks for your comments.  I think we understand your specifics and can 
>aggregate them into the following views:
>
>1)      It would be better to develop the guidance as an informational RFC 
>versus an official BCP, and then maybe later, if its application and 
>experience warrants, advance it as a BCP.
>
>I think we agree with this approach.  We certainly agree that our 
>objective to provide guidance to our providers does not have to be met 
>with "standards", but can be met with less "official" documents.  We just 
>want to gain as much as possible community review and consensus on how 
>best to implement an ETS.  The BCP description in the Charter sounded like 
>the right thing, but if an informational RFC is more appropriate, then 
>that is ok.
>
>2)      If we are trying to develop a BCP, then the "suggested" work 
>initiatives should be removed and developed separately as IEPREP 
>requirements products for input to the protocol WGs.
>
>We agree, and if the document is continued as a BCP initiative, we will 
>edit accordingly.  I also presume that if the document is an informational 
>RFC, then it may be more appropriate to discuss the work in progress and 
>its potential application, but that we should nonetheless initiate 
>requirements docs for the work in progress we want to support and / or refine.
>
>3)      We should not try to bypass the normal review process for 
>assignment of values to variables.
>
>We agree and that was not our intent.  Rather, we were trying to align 
>with the notion that a BCP should deal only with what can be done with 
>existing protocol standards, and not with protocol extensions.  Thus, we 
>were advocating use of consistent local practices in variable value 
>assignments as permitted in the standards until such assignments could be 
>properly reviewed and advanced as standard.  If we make the document an 
>informational RFC versus a BCP, are we on better ground to suggest such 
>local practice consistency in variable value assignment?
>
>We do not remember any document as you describe from Fred and if you could 
>give us a pointer to it, that would be much appreciated.  If he has not 
>yet released a draft, then we would endorse your encouragement of him to 
>do so.
>
>Finally, as a point of info, page 174 of the SIP RFC 3261 describes the 
>Priority header (which is separate from the Resource-Priority header that 
>is only in draft status and may have been what you were thinking of).
>
>Thanks again for the comments.  I think the above summarizes the view, but 
>if we missed some point or got a point wrong, please let us know.
>
>-----Original Message-----
>From: Scott Bradner [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Wednesday, July 02, 2003 9:31 PM
>To: Berg, Dennis; [email-masked]; [email-masked]
>Cc: [email-masked]; Gunn, Janet; [email-masked]; Kaczmarek,
>Richard NE
>Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP
>Telep hony
>
> > Would appreciate your specific feedback, specifically on our views of how
> > the ID's recommendations are in scope for a BCP.
>
>if the doc is designed to ask other IETF working groups to explore
>how to meet requirements that teh IEPREP WG feels need to be
>met to support emergency traffic then it can not be a BCP by definition
>and I agree with James that the odc should be split unto individual
>documents that provide ieprep requirements on a per technology nasis
>
>if the doc is intended to tell ISPs and enterprises what the IEPREP
>thinks is the best way to meet the needs of emergency traffic it must
>be based on technology that the ISPs or enterprises have or can get
>thus, if the doc suggests changes or additions to other IETF
>technologies (including having a SIP recource header) then it
>can not be published as a BCP until those changes have been accepted,
>and woudl have to be revised based on what the other IETF WGs actually do
>
>to your specific points
>
> > In our ID, we have tried to separate "RECOMMENDED" practices from
> > "suggested" work items for the IEPREP WG.   As noted below, all the
> > "RECOMMENDED" practices (we believe) have been checked for feasibility 
> with
> > existing protocols without protocol extensions, and can be applied via 
> local
> > administration.  The "RECOMMENDED" practices do include specifics for such
> > local administration, but we understand this is consistent both with BCP
> > intent and with the needs of our ETS service providers.  We recognize that
> > use of local and experimental values limits the implementation to a single
> > domain; however, the scope of the ID is just a single domain, which is the
> > scope of our discussions with the service providers.
> > Where we have seen protocol gaps, we have "suggested" (the flag word 
> versus
> > "RECOMMENDED" for actual BCP recommendations) IEPREP initiatives to 
> address,
> > and probably should be more explicit in characterizing such initiatives as
> > efforts to develop Requirements that can then be used as input to the
> > appropriate protocol WG.
>
>I think a BCP should just say what is recommended to meet the needs
>and think teh difference between RECOMMENDED and "suggested" is too
>fine a difference to be clear to the reader
>
> > On a more detailed level, our "RECOMMENDED" practices and why we consider
> > them within scope are noted below:
> >
> > 1.  ETS call signaling should use the basic signaling protocol stack 
> assumed
> > for the reference topology (Conventional SS7 [SS7] from AT to STP to SG 
> and
> > SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC.)
> > *  This recommends the use of specific existing protocols for carrying SS7
> > over IP, and so clearly meets the BCP scope of specifying what can be done
> > with existing protocols.
>
>if indeed it points to existing RFCs saying how to transport the
>particular SS7 functions over SCTP then this is in scope
>
> > 2.  There should be direct mapping of the CSN (international and / or
> > national) ETS call marking(s) and associated SS7 congestion priorities.
> > *  Recommends that two specific parameters of interest to ETS should be
> > mapped ("preserved" probably would have been a better choice of words) 
> at a
> > signaling gateway. I.e., the SG should function just like an STP and send
> > out only what it receives without modifying the input.
>
>I may be confused but if its just SS7 stuff I'm not sure the IETF is
>right place to make recommendations
>
> > 3.  For an ETS call the same mapping and translation should be applied to
> > the call setup IAM being sent from the IP network to the CSN upon 
> egress as
> > was applied to the IAM sent from the CSN to the IP network upon ingress,
> > e.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC)
> > and, if present, the optional Precedence parameter.
> > *  Recommends that the mapping and translation function - as specified for
> > the ETS parameters of interest in (2) - at ingress and egress to the
> > signaling gateway be symmetrical, i.e., that the network should be
> > transparent.
>
>if this is a recommendation on how a SIP field should be used then
>it should be done by the SIP WG - ieprep could tell sipping that
>there is a need to transport the  NSEP codepoint to the gateway
>and the SIP wg can think about the best way to do that
>
> > 4.  The MPT3 congestion priority of the received IAM be propagated 
> unchanged
> > in the outgoing IAM, (e.g., in the U.S., IAMs with NSEP set have a
> > congestion priority of one whereas all other IAMs have a lower congestion
> > priority of zero).
> > *  Specifically, recommends that the congestion priority of the IAM at
> > ingress not be changed at egress.
>
>I do not know how this actually applies to transporting things
>over IP networks - if it saying that data needs to be carried from the
>gateway to the IP end node then the comment for #3 applies -
>
> > 5.  Assign two values from the experimental and local use pool of Diffserv
> > codepoints to designate and differentiate International ETS and National
> > ETS.
> > *  Our understanding is that the use of experimental and locally
> > administrable items within a single domain is a practice, not a protocol
> > extension.
>
>I do not think that we can reasonabally avoid the normal review process
>for this type of thing by saying its just a local matter - this is defining
>a specific use of a value and any such definition should go thorugh
>the normal process for that variable - anything else distorts the
>review process that has been properly established for the variables
>
> > 6.  Correlate the two Diffserv codepoints with a PHB constructed by
> > "copying" the EF PHB, but perhaps changing some parameter values.
> > *  Our understanding is that defining a PHB for a Diffserv local and
> > experimental codepoint is matter of practice.
>
>see # 5
>
> > 7.  Use the following specific experimental and local pool Diffserv
> > codepoints: assignments: National Emergency = 011111, International
> > Emergency = 011011
> > *  This recommendation just calls out specific values for convenience in
> > order to coordinate usage of the Diffserv values from this pool.
>
>see # 5
>
> > 8.  Separate ETS traffic treatment, both signaling and data, from other
> > traffic treatment by the use of a dedicated MPLS Diff-serv codepoint in
> > E-LSPs
> > *  We understand that MPLS codepoints and E-LSPs are matters of local
> > administration.  We intend to clarify this recommendation to specify that
> > one of the two unused MPLS Diffserv codepoints should be used 
> (specifically
> > 6, since we understand that common practice is to use 7 for network
> > management).  Based upon the current practice of using 7 for network
> > management, we conclude that we are able to recommend the practice of 
> using
> > 6 for ETS within a single administrative domain.
>
>see #5
>
> > 9.  Associate the Diffserv PHB with the MPLS Diffserv codepoint as is used
> > for Diffserv in general.
> > *  Again, if we can define the MPLS Diffserv codepoint at a matter of
> > practice, it would seem that we can also define its PBH as a matter of
> > practice.
>
>see #5
>
> > 10.  ETS calls should be specified by use of the SIP Priority header 
> with a
> > designation of "emergency".
> > *  We are not recommending changing the use of this field for notifying 
> the
> > user.  We're just saying, for ETS calls, use it for its intended purpose.
>
>I do not think there is a "SIP Priority header" yet approved
>
> > 11.  Use SDP attribute parameters to specify ETS sessions as either 
> National
> > Emergency sessions using the attribute parameter value "x-NatETS" 
> (where the
> > leading "x" is understood to be customary to designate non-standard 
> values)
> > or International Emergency sessions using the attribute parameter value
> > "x-IntETS".
> > *  Since we are recommending locally administrable values, we understand
> > this to be a matter of practice for a single administrable domain, rather
> > than protocol extension.
>
>see #5
>
> > 12.  Use the MEGACO ContextRequest parameter for "emergency" (Boolean) to
> > indicate "emergency" and the MEGACO ContextRequest parameter for 
> "priority"
> > with priorities 0-4.
> > *  Our understanding here is that these parameters are already defined and
> > their use is a matter of local practice.
>
>see #5
>
> > Note that we do not include the SIP RPH in any of our recommendations.  We
> > recognize that the SIP section is there for information and that the ETS
> > namespace position needs to be officially pursued as a separate effort.
> >
> > We are at the stage of discussions with vendors and carriers that requires
> > real (and preferably official) guidance on how we would like them to 
> address
> > our ETS needs in their new IP deployments.  We understand a BCP carries 
> with
> > it the endorsement of the IETF, and although it is not a standard, it 
> has a
> > lot more weight than other non-standard RFCs.  We recognize that some 
> could
> > raise the question of whether or not the IETF should advocate a practice
> > without a firm experiential base for knowing if it is the best (or even a
> > good) practice.  Our view, at least at the moment, is that an expert 
> view of
> > what seems to be a "best practice in the absence of experience" is still a
> > lot better in meeting our needs than no view at all.
>
>but that does not qualify a RFC to be designated a BCP - it could
>be designated experimental but without any indication that
>things would actually do what is needed it clearly can not be a BCP
>
>and again, I agree with James that the right way forward for these
>recommendations is to agree on documents that have the requirements
>for the other WGs and send them off to those WGs
>
>the idea behind the BCP deliverable in the charter came from the
>1st BOF where it was pointed out that there were some things
>that were actually being done in today's networks and it was
>pointed out that it woudl be useful to write them down - Fred Baker
>did a pass on this and I've suggested to him that he revive that
>ID for further consideration now that the other work is mostly
>done
>
>Scott

cheers,
James

                                *******************
                    The answer is "42", what's the question?

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

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Thu, 3 Jul 2003 18:10:55 -0500

>> We do not remember any document as you describe from Fred 
>> and if you could give us a pointer to it, that would be 
>> much appreciated. 
>
>draft-ietf-ieprep-packet-marking-policy-01.txt
>
>but the ID has expired 

http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-00.txt 

This does have more technical content (particularly, traffic categories) than
expired ieprep-packet-marking-policy. I don't know whether it updates the
marking policy draft or it is something all together different.