[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ccamp-gmpls-egress-control-00.txt
Hi Guys,
Administrative question - if this comes out as a BCP,
does the RFC table note this as some kind of update
to 3473?
I'd be a little worried if there is no notation against
the RFC to point people to the clarification.
Thanks,
Lyndon
-----Original Message-----
From: Lou Berger [mailto:lberger@movaz.com]
Sent: Thursday, April 08, 2004 2:11 PM
To: Adrian Farrel
Cc: Berger, Lou; ccamp@ops.ietf.org
Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt
Adrian,
See responses below.
At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote:
>Hi Lou,
>
> > >Please give the intended category of the work...
> > >Proposed Category: Best Common Practice
> >
> > this is normally done outside of the draft.
>
>Hmmm.
>The draft needs to indicate its intended status so that folks can review
>it with that in mind.
>If you don't want to say that the proposed status is BCP then please at
>least say informational.
will put into draft - I've always seen this in the last call announcement -
but whatever...
>
> > >Please correct draft name as it appears in the title and footers.
> > ><draft-ccamp-gmpls-egress-control-00.txt
> > > >draft-ietf-ccamp-gmpls-egress-control-00.txt
> >
> > fixed last week.
>
>Hah! But the secretariat has published it according to your first submission.
>Actually, the version on the LabN site is also wrong.
>
>I don't mean the document name, I mean the draft name as it appears
>throughout the document.
will be fixed in next rev...
>[...]>
> > >Compare with section 2.2 which is more general.
> > >
> > > To support Egress Control, an egress checks to see if the received
> > > ERO contains an outgoing/downstream interface. If it does, the type
> > > of the subobject or subobjects following the interface are examined.
> > > If the associated LSP is unidirectional, one subobject is examined.
> > > Two subobjects are examined for bidirectional LSPs. If the U-bit of
> > > the subobject being examined is clear (0), then the value of the
> > > label is copied into a new Label_Set object. Note, this Label_Set
> > > object is for internal use only. This Label_Set object indicates the
> > > label value that MUST be used for transmitting traffic associated
> > > with the LSP on the indicated outgoing/downstream interface.
> > >Not withstanding "this Label_Set object is for internal use only", I
> > >find this text a bit peculiar!
> > >You really just want to say that this subobject is used to specify the
> > >label that the egress MUST apply to traffic that it forwards from this
> > >LSP. (Compare with the next paragraph where you do not describe
> > >creating an Upstream_Label object for internal use only.)
> > >If you insist on talking about the Label_Set object, you will have to be
> > >far more specific because there are four different varieties of that
> > >object.
> >
> > I think the wording is consistent with RFC3473 and unambiguous. Please
> > suggest alternate wording.
>
>Well! I can't be held responsible for the failings of the editor of that
>RFC :-)
>
>Section 5.1.1 says with respect to the ERO Label Subobject...
> If the U-bit of the
> subobject being examined is clear (0), then value of the label is
> copied into a new Label_Set object. This Label_Set object MUST be
> included on the corresponding outgoing Path message.
>
>So I see where you are coming from, but I think this text is aimed at
>specifying how you build the outgoing Path message, not how you
>manage the label allocation on your downstream interface. It is
>wrong to suggest that an implementation must create a protocol
>object for this purpose if no Path message is to be sent.
>
>In fact, since there is no corresponding Resv with a Label Object
>we need to pin this text down a little more clearly. How about the
>following edit...
>
> To support Egress Control, an egress checks to see if the received
> ERO contains an outgoing/downstream interface. If it does, the type
> of the subobject or subobjects following the interface are examined.
> If the associated LSP is unidirectional, one subobject is examined.
> Two subobjects are examined for bidirectional LSPs. If the U-bit of
> the subobject being examined is clear (0), then the value of the
> label MUST be used for transmitting traffic associated with the LSP
> on the indicated outgoing/downstream interface.
Done!
> > > including if the listed label(s) are not acceptable or cannot be
> > > supported in forwarding, SHOULD result in the generation of a PathErr
> > > message containing a "Bad EXPLICIT_ROUTE object" error.
> > >I'd prefer you to be more explicit...
> > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error.
> > sure, will use phrasing from rfc3209.
> >
> > >3. Security Considerations
> > >
> > >< This note clarifies procedures defined in [RFC3473]. As such, no new
> > >< security considerations are introduced.
> > > > This note reiterates procedures defined in [RFC3473], but does not
> > > > define any new procedures. As such, no new security considerations
> > > > are introduced.
> > okay.
> >
> > ><5. References
> > > >5. Normative References
> > >
> > >Need BCP 78, and 79 as informational references.
> > >Also RFC 3668.
> >
> > will do, but do you really want me to reference BCP 79 and RFC 3668?
>
>It is unclear whether this is a requirement, but since the boilerplate
>text makes these references it seems reasonable to include them in the list.
ahh, you fell for my trick question! (they're the same document ;-)
>
> > >8. Intellectual Property
> > >
> > >Missing the personal disclaimer...
> > > By submitting this Internet-Draft, I certify that any applicable
> > > patent or other IPR claims of which I am aware have been disclosed,
> > > and any of which I become aware will be disclosed, in accordance with
> > > RFC 3668.
> > sure.
> >
> > >Don't need the footer...
> > >Generated on: Mon Mar 15 10:52:32 2004
> >
> > picky, picky, picky...
>That's what I'm paid for.
>
>Thanks, Lou. Looking forward to seeing the revision published.
>
>Adrian
>
Thanks again.
submitting in a few minutes...
Lou