[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IESG comments on generalize MPLS documents
Inline
> > > >6. From section 9.1.1 towards the end, I get the impression
> > > > that [MPLS-UNNUM] is normative too? Status?
> > >
> > > one reference has been removed, the other is still there. I think
> > > informative is accurate for the new text.
> > >
> >Will check when I see the text
>
> IP Address: 32 bits
>
> The IP address field may carry either an IP address of a
> link, or an IP address associated with the router ID,
> where router ID may be the value carried in the router ID
> TLV of routing.
>
> Interface ID: 32 bits
>
> For type 3 usage, the Interface ID carries an interface
> identifier, see [MPLS-UNNUM].
>
that to me seems to make it normative, no?
> For types 4 and 5, the Interface ID indicates a bundled
> component link. The special value 0xFFFFFFFF can be used
> to indicate the same label is to be valid across all
> component links.
>
>
> > > >some less serious, but now that you are at it anyway...
> > > >
> > > >7. Intro lists 4 types of interfaces (PSC, TDM, LSC, PSC)
> > > > Architecture doc (still and I-D) lists L2SC as well.
> > > > Would it not be better if they are in sync?
> > >
> > > L2SC is really a sub/special-case of PSC. Other documents also don't
> > > explicitly call it out.
> > >
> >The Architecture doc DOES spell it out.
> >When I read "Architecture" then I always think it is guiding any other
> >documents in that space.
>
> If this is a "less serious" comment, then I can use my judgement as
> editor. (which I've done.) If this an IESG requirement then I'll make
> whatever change is required. Is there a required change from
> the IESG here?
Nope... I was just doing due dilligence trying to get consistency in the
whole set of documents. This for the better of the intended audience.
But you seem to take the editorial liberty to ignore your audience.
>
> >[...]
> > > >
> > > >
> > > >13. the document could have been 5 pages shorter if it had not
> > > > bothered to explain how it is different from "old" MPLS,
> > > > and just concentrated on what it was doing.
> > > > I guess a ptr to the old MPLS doc would have been sufficient?
> > >
> > > I think we should just keep this as is.
> > >
> >So you are asking me to defend that in the IESG.
> >Not sure how successfull I will be. Up to you to take the risk
> >
>
> same comment. Is there a required change from the IESG here?
>
Same comment. IESG member(s) had suggested this as a way to make the
document faster to read (with a ptr to the MPLS doc that described
the "old" MPLS. If you prefer to waste more bytes on the wire when people
download the doc, or to waiste more trees when they print it...
That I guess is again your editorial liberty.
> > > >14. Cannot implement section 9 (interface identification) - the
> > > > info on which end's interfaces are being talked about, and
> > > > how one end identifies which of its interfaces match
> > > > corresponding interfaces at the other end simply doesn't
> > > > seem to be there.
> > > > (generalized-rsvp-te specifies that the downstream interface
> > > > is sent in a PATH message.....this is a matchup, but not sure
> > > > which way it matches).
> > >
> > > The whole document can only be implemented when combined with
> > > one of the protocol specific documents. I think the 21 responses
> > > to the implementation survey speaks for itself. (Also, this
> > > document does clearly states: "In all cases the choice of the data
> > > interface is indicated by the upstream node using addresses and
> > > identifiers used by the upstream node.")
> > >
> >So maybe adding a note to it to explain that might alleviate the
> >concern. Of course I can try to defend based on the 21 responses,
> >that is indeed a strong point. But often adding a one or wto line
> >explanation helps to fuse the push back
>
> I'm happy to do this. I went to add more text and found the text that I
> was going to add was already present. Please propose some text and it'll
> be included.
>
So what is the text that you think makes it clear enough?
> >[...]
> > >
> > > ><draft-ietf-mpls-generalized-cr-ldp-06.txt>
> > > >
> > > >1. IANA asks:
> > > > Seems OK but which registry should these assignments
> > > > be going in.
> > > > So please specify.
> > >
> > > Took me a second to figure out what was needed here, the
> > > reference was
> > > broken (said 3031 not 3036.) With a proper reference, the registry
> > >
> >
> (<http://www.iana.org/assignments/ldp-namespaces>
> > should be clear.
> > >
> >I would strongly recommend to also add that web ptr. It will Help
> >IANA a lot, and it will just smooth the further processing of the
> >document. It also helps later readers to quickly find the place
> >where values are registered.
>
> My understanding is that URLs are discouraged in RFCs, but if
> that's what the IESG want's...
>
Well, we do prefer to not have (unstable) URLs in the references section.
Otherwise just say ldp-namesapces.
The IANA URLs are pretty stable (we believe).
> > > >4. IANA Considerations starts with:
> > > > This draft uses the LDP [RFC 3031] name spaces, which require
> > > > assignment for the following TLVs.
> > > > Do you mean to reference 3036 instead of 3031?
> > > >
> > >
> > > yes. same issue as comment 1.
> > >
> >same as above. pls add the web ptr to the registry
>
> sure, it's the same sentence (do you want it twice?)
>
Nope... not if it is in same doc, in same section.
I thinbk you know what I mean. You want to help the IANA
function to be able to quickly find the proper place to
do assignments. You should not assume IANA knows all the
ins and out of all the name-spaces by head.
..
> > > >1. This doc says "just use IPsec". A clearer statement is needed,
> > > > specifying the necessary IPsec selectors (per RFC 2401) and the
> > > > way the cryptographically protected endpoints are related to
> > > > the authorization model, i.e., who can do what.
> > >
> > > can you provide an example of what you'd like to see?
> > >
> >
> >I am checking with Security ADs.
>
> thanks.
>
no answer yet, will forward as soon as I have it.
Also feel free to check with SEC ADs Steve Bellovin and Jeff Schiller
yourself, then I do not have to function as a smtp relay
...
Bert