Subject: [Gen-art] Re: Gen-Art Review: draft-ietf-pwe3-satop-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Dec 2005 13:45:14 +0100

Sasha,

You can make a normative reference to a BCP if you wish.
But it is the registry itself that is the true target,
so making the document an informative reference seems OK.

    Brian

Sasha Vainshtein wrote:
> Elwyn, Stewart and all,
> Yaakov and I will provide a detailed response soon. Meanwhile, a few minor
> comments/questions:
> 
> 1. My I-D Tracker shows that PWE3-IANA has been already sent to the RFC
> Editor as a BCP
>     (and not as a PS). Taking this into account, what kind of reference does
> it make? 
> 
> 2. "CE-bound" (as the traffic direction from the PSN towards the CE) is
> defined in RFC 3985. 
>      "PSN-bound" can be also found there (one occurrence), but it seems to
> have been replaced by
>      "PE-bound" (for the opposite traffic direction).  To the best of my
> recollection, PSN-bound
>      has been used in several version of the PWE3 architecture draft before
> being eventually
>      reverted to PE-bound. Is it correct to assume that replacing
> "PSN-bound" with "PE-bound" in the
>      text resolve the problem?
> 
> 3. Is it really necessary to expand the term "MTU"? Searching the RFC
> database for this term in the RFC title
>     provides 7 hits, ad some of them (e.g., RFC 2923) do not define this
> term (rather, they contain a reference to 
>     RFC 1191 where this term is explicitly defined as "maximum transmission
> unit".
> 
> 4. Lots of thanks for catching the "smoothless" typo. Of course the
> intention has been for "seamless"...
>     
> With best regards,
> 				Sasha 
> 
>    
>     
> 
> 
>>-----Original Message-----
>>From: Elwyn Davies [mailto:[email-masked]]
>>Sent: Monday, December 12, 2005 2:00 PM
>>To: Stewart Bryant
>>Cc: [email-masked]; Yaakov Stein; [email-masked]; 
>>Danny McPherson; Sasha Vainshtein; Mary Barnes
>>Subject: Re: Gen-Art Review: draft-ietf-pwe3-satop-03.txt
>>
>>
>>
>>
>>Stewart Bryant wrote:
>>
>>
>>>Some points about normative references:
>>>
>>>
>>>>
>>>>References:
>>>>PWE3-ARCH, PWE3-IANA, PWE3-TDM-CONTROL and PWE3-VCCV are normative 
>>>>IMO as the protocol cannot be implemented without 
>>
>>knowledge of these 
>>
>>>>items.
>>>>
>>>>
>>>
>>>PWE3-ARCH = RFC3985 is only informational so I do think that it can
>>>be normative in a stds track RFC. RFC3985 should not 
>>
>>contain anything 
>>
>>>that this
>>>RFC should regard as normative - is there any text that you 
>>
>>have in mind
>>
>>>as being a normative dependency?
>>
>>Oh, dear!  Real problem, wrong solution! This is actually something I 
>>spotted previously and didn't get fixed in this version of 
>>the draft.  
>>The text in s4.3 would create a normative ref but the s5.4.4 isn't in 
>>RFC3985 any more!  From my previous comments:
>>
>>s4.3: s5.4.4 of RFC3985 does not exist.  Archaeology suggests that it 
>>was removed between the -06 (final) version of the draft and the RFC 
>>publication.  I take it the ref should either be to 
>>draft-bryant-mcpherson-pwe3-cw-00.txt or 
>>draft-ietf-pwe3-cw-05.txt, but 
>>this latter explicitly applies to MPLS control words.
>>
>>There SHOULD be a normative reference to one or more of 
>>these! In which 
>>case the architecture is indeed informative.
>>
>>
>>>PWE3-IANA creates a number of registries that this draft 
>>
>>uses, it the 
>>
>>>registries
>>>that are really normative - not the RFC. The draft is in the 
>>>RFC-editor's queue
>>>and we have asked IANA to expedite the registry creation.
>>
>>An interesting question:  The IANA draft creates the registry 
>>maintenance mechanisms which are normally in a PS.  Ask your 
>>AD for advice!
>>
>>
>>>PWE3-TDM-CONTROL  is new work. A SAToP PW can be setup by manual
>>>configuration and that is the way SAToP PWs are currently deployed.
>>
>>You are right - the normative link is in the other direction only.
>>
>>
>>>PWE3-VCCV is not normative in any of the encap drafts, 
>>
>>because although
>>
>>>an OAM protocol is useful, it is not essential - there are many 
>>>deployed PWs that
>>>do not run an OAM. What is essential is that the SAToP 
>>
>>design is such 
>>
>>>that
>>>that VCCV cab run over the PW. That requirement is fulfilled.
>>
>>The last paragraph of s4.3.1 creates a relationship with VCCV 
>>which is 
>>at least on the surface normative.
>>
>>Regards,
>>Elwyn
>>
>>
>>>Regards
>>>
>>>Stewart
>>>
>>
> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 13 Dec 2005 14:54:20 +0200

Brian,
Lots of thanks for a prompt response.

I needed this clarification since the point raised by Elwyn and Stewart
looked as if the type of reference were derived from the track of the 
referenced RFC (PS-->Normative, Informational-->Informational). 
SAToP being my (so far) first draft approaching (hopefully) the
RFC status, I wanted to be aware of ALL possible ramifications.

Regards,
			Sasha

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, December 13, 2005 2:45 PM
> To: Sasha Vainshtein
> Cc: 'Elwyn Davies'; Stewart Bryant; [email-masked]; 
> Yaakov Stein; General Area Review Team; Mary Barnes; Danny McPherson